You've heard of HTTPS. Now get a load of HTTPA: Web services in verified remote trusted environments? Two Intel staffers believe web services can be made more secure by not only carrying out computations in remote trusted execution environments, or TEEs, but by also verifying for clients that this was done so. Software engineer Gordon King, and Hans Wang, a research scientist at Intel Labs, proposed the protocol to make that …
if anyone tells me there is a certificate transparency log I'll laugh...
basically you need a way to establish trust and frankly that requires a root or offline signing party and expensive safes (you know what they do for DNS party)
this has been rehashed (boom boom) so many times
I'd be quite happy with DNSSEC protected text records providing the public key for any service.
It's completely out of band and of all the groups in the world we have come to trust... those looking after the DNS root are pretty high on the list, and actually so are the major TLD bodies (theiving scum they might be, but they have historically provided a pretty good technical service in terms of DNS at any rate)
I might be more interested in this if it didn't come from Intel, a company that constantly skimps on security in order to market segment (they're the reason consumer computers don't have ECC by default), whose 'security' features just open up buttloads more security holes (IME), and are desperate because they completely botched the last chip transition.
And the whole 'trust' thing seems pretty easily fakeable by bad actors anyhow.
> And the whole 'trust' thing seems pretty easily fakeable by bad actors anyhow
This! ^^
Criminals have been faking Microsoft's code signatures for several years, the very ones which were flaunted as the ultimate anti-virus weapon... This is no different, I guess it will be cracked before initial implementation is even finished.
It's just an attempt to sell more Intel CPUs.
"Criminals have been faking Microsoft's code signatures for several years"
Faking as in signing with Microsoft's keys or faking as in throwing together a self-signed certificate in the name of "Microsoft". I think the former would be og considerable interest to the cryptographic community whereas the latter ... just doesn't count.
> Faking as in signing with Microsoft's keys
Well, it's right here at El Reg that I read recently again about some strand of malware which is signed with Microsoft keys so it can run under the radar. Sorry, don't recall the details, and don't know how exactly they did it since the article didn't mention it.
Anyway, my (not perfect I admit) memory seems to tell me it's not the first time. I think other big "gatekeeper" signatures have been successfully faked (somehow) in the past, and this doesn't really surprise me, there is always a long way from a perfect (looking) theory to the usually quite imperfect implementation.
Unless I'm much mistaken, at least in the commercial domain a big proportion (if not the majority) of attacks are initiated client side.
The real problem still remaining to be solved is how to ensure secure processing on an untrustworthy client.
If Intel can't get their systems secure just for a simple OS, how can we trust that they do their entire computation on your behalf, including a large set of services, in a secure manner?
Frankly, the concept is interesting but the devil is in the details. Moreover, it is just not possible for Intel to execute anything securely. Their bean counters will be pushing for higher speeds and will run over their security people.
Secure enclaves (which seem to be a part of this proposed enhancement) should not really be required. If the address space segregation of the OS and the hardware it runs on is adequate, then it should not be possible for one process to spy on another, much less alter the memory contents.
Of course, it your processor or memory segregation had flaws which weaken the OS's protections, as has been repeatedly demonstrated on Intel (and other) processor families, then this may be a mitigation.
So it sounds like a hack to overcome other flaws in their own processors.
The other issue of trusting the code that runs is a different issue, and there are many ways of doing this. What this protocol does is allow a client to check that the server-side code is untainted, which may have some merit if you can't trust that the servers you're talking to. But it seems to rely on a third party (the CA), and that has issues such as denial of service attacks.
And what about the bugs of the secure enclaves?
Oh, you need to buy a new processor to fix those? I see, it's a win-win situation, for Intel...
Not that I have anything against Intel. Writing this on an Intel computer. Still sounds like a stupid "lets find a problem for this solution" type idea.
Not really sure why or what perceived problem this is solving.
Not trusting the environment that the server is running in. This is not even on my top 10 list of concerns.
Looks to me like someone who has been focusing on the side channel issues with CPUs is trying to make the fact the server is now running in a fixed envinronment is something you seriously care about. Either they are so deep into the issue that they can't see anything else, or it is Intel trying to make new CPU versions "important".
S and A are next to each other on many English, if not international keyboards. Many browsers also don't bother showing the URL protocol and prefix anymore in the address bar.
Am I the only one sensing a perfect way to impersonate something, without being the thing intended at all?
Technologically the idea is sound but from a very, very basic user perspective one can poke holes quite easily.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
