> The researchers said that it’s capable of locating and leaking a Linux computer’s root password hash from physical memory in about 28 minutes when running the Intel CPUs and in about 6 minutes for AMD CPUs.
Given this attack vector, it makes some sense for relatively static secrets like these to be moved into something like the Secure Enclave where the CPU can perform signature verification but never store the secret itself in memory or cache. I know other ARM-based SoCs have these too. So presumably Intel and AMD offer something like this in their latest-generation CPUs?
Intel's Software Guard Extensions were supposed to run at a higher, inaccessible privilege level on consumer CPUs and that turned out to be susceptible to side channel attacks. ARM TrustZone was defeated through cache latency measurements on Android in 2016, though that specific flaw might have been patched since.
Perhaps with an entirely separate chip running its own OS with its own RAM and IO, you could work with secrets, but traditional secure chips have so far been far from a silver bullet.
I think the Intel Management Engine is close enough to the system CPU that it is probably affected by side channel attacks, but perhaps AMD's PSP is removed far enough to nullify the effect.
SGX was patched to solve those issues though. This is one of the issues with the security and side channels space: often there are mitigations powerful enough to stop attacks, but people don't remember them being rolled out. They recall the attack, say "oh well that is broken forever" and never re-visit the issue.
As I mention elsewhere, an enclave is a good construct to use here because you're explicitly signalling to the CPU that the memory space has unusually sensitive secrets and you're willing to lose performance to protect them.
That's true, but the point is that simply relying on security extensions is no guarantee for safety. If it was broken before, the theoretical separation isn't complete enough to guarantee it won't be broken again.
SGX is already being phased out by Intel for consumer/workstation products so I think they've given up on the concept themselves. I don't think they're supporting an alternative on consumer products either. Even if their server/enterprise implementation is secure enough, it won't protect against developers having their SSH keys exfiltrated by a game running in their browser during their downtime.
I think externalising the security mechanism is a good idea, but the current implementations simply aren't good enough to combat this issue.
Well, Intel are introducing new features built on SGX so it's definitely not abandoned. Their encrypted VM feature is built on it for instance.
I used to work quite closely with Intel on SGX related stuff. My understanding is, the issue on the client side is not really that Intel itself don't believe in it. They do. The issue is that it requires extensive kernel support. Microsoft never committed the resources to fully implement SGX or make it useful. What little support they shipped wasn't actually workable, especially as Intel updated SGX to address market feedback. Servers run Linux and there Intel were able to write their own drivers and do the necessary work for it themselves, so were less constrained by what Microsoft wanted to do. It's also an easier pitch in the cloud - there are more ideas for use cases.
W.R.T. SSH keys I don't quite understand the threat model you have in mind there. The point of SGX is that root access to the server where the enclave runs is unimportant. The attacker is assumed to have root throughout.
Their disabling of SGX is now preventing Blurays from being played and educational test stalkerware that tries to detect cheaters from being run on 12th gen Intel. What little support Intel had now seems to have evaporated completely.
Their decision to turn SGX into an enterprise feature seems more like another product segmentation strategy to me, same with ECC RAM support. I don't see the point of dropping support entirely for a feature that's still actively being used by consumer products but maintaining the feature in more expensive chips.
WRT ssh keys: in a perfect world, authentication systems such as FIDO key stores, password managers and SSH agents live on a secure coprocessor, signing key material for applications on the main chip and loading their decryption keys from a secure chip like a TPM. If the code is written well, this would make it impossible for even an attacker with root access to gain access to the key material, you'd need physical probes on the motherboards to steal keys. Even kernel modules shouldn't affect the secrecy of the system once it's been initialized correctly. Without a separate, secure system, an attacker in a sufficiently performant browser writing their own timers can now extract data from the kernel (like, say, a process map) and make their way into SSH agent memory, extracting data at kilobytes per second in some processors, all through side channel attacks. A browser tab running 100% CPU for a while wouldn't even be that strange these days, for all you know it's Microsoft Teams or Slack running in the background.
I see. So you're saying you'd want to run the whole SSH client in an enclave?
Beyond the Windows issue, one reason SGX on the client didn't make it is that to really meet the threat model of a compromised OS/kernel, you need a secure input/output path. Video decoding had that, albeit wrapped behind NDAs, but keyboard input doesn't (as far as I know). So whilst you could protect the SSH connection itself inside an enclave, the actual screen/keyboard IO couldn't be defended. It'd not be useless, but it's not quite the convincing win it can be on the server where IO is all encrypted network packets or file system read/writes.
In my setup, a minimal SSH agent daemon would run in an enclave, only the necessary parts for key operations. The rest of the agent (protocol parsing etc.) would run in normal userspace and communicate over a channel (through the kernel or some other API, I don't know enough about low level system's programming to come up with the right abstraction).
Even if the user mode side of the agent would be hijacked, all it could do is ask the secure part to sign requests; the key itself would never leave the enclave. The same would be true for other authentication protocols, such as FIDO2/U2F daemons. In effect, once you've found out about a malicious program, you wouldn't need to worry about someone else reusing your key afterwards. Just analyse, then kill all the open sessions for that user and you don't even need to roll over your keys if you trust the enclave well enough.
For password managers the main key store would he handles by the enclave and only the necessary passwords would leave the enclave and cross over to system space. This way you can't just keylog the passphrase and upload the key store to a server, you could at most extract a few passwords per minute by having a malicious daemon run in the background. Granted, this is a lot less practical or secure than the other methods.
The biggest challenge for this all is to get some kind of secret into the system that the normal CPU can't see, but the secure enclave can. I theorise that the TPM would be an excellent place to do this in, but an enclave can contain its own secret store for all I care. If the enclave can do encrypted I/O with its super secret key, the files on the file system would be difficult to tamper with and configuration and state could even be stored safely on a non-encrypted disk! Reusing old, valid credentials would work, of course, but for that a secure counter or whatever may be implemented to mitigate that. The enclave would also need to run each program in complete isolation of each other (basically no multi threading or caches to prevent side channel attacks) but your average computer wouldn't be running more than two or three daemons anyway. Another challenge is to prevent modification of the loaded agent code itself but that again could be secured by a hash stored on the TPM after the program first loads. Associate the secret key with the hash of the program and allow a hash-secured program to upgrade the hash and you've got a pretty difficult to break system, I reckon, without necessitating the use of manufacturer provided certificates and keys like Intel likes to require. You would need a code execution bug in isolated program on the enclave.
I don't really see how you could lock down a secure input path unless you use PS/2. USB input devices are complex and need some level of drivers to work right, especially ones that do more than your cheap plastic office keyboard. I believe Intel does have such a system when their iGPU is used, I believe it has to do with its enterprise remote access tools, but I think this would be too much of an attack surface for general purpose use.
You can do that sort of thing with SGX very easily indeed. SGX enclaves can generate key material internally that's accessible only to themselves, sealed under the enclave identity, so no TPM is necessary. Actually SGX obsoletes TPMs for some use cases, they're independent technologies.
The way it'd work is you'd just use the public key emitted by the enclave. Grab a Xeon workstation and you can even do such a thing from your desktop.
If you want, you can even prototype such a thing right now. My guess is I could implement that in about an afternoon's worth of work using Conclave:
The thing is, if all it's doing is avoiding key rotation in case of compromise it's a bit hard to justify. Yes, HSM vendors have built a whole business on that, but in practice I'm not sure people are willing to rely on it. Compromised CAs get revoked, right, root store ops don't say "well luckily the HSM means the compromise was only temporary".
Intel did in the past prototype USB keyboards that could do a D/H key exchange and submit encrypted keystrokes. Likewise, apps can do D/H key exchange to tunnel encrypted bitmaps to the GPU where they get composited onto the screen, that's secure video path. Unfortunately there is a long history of them running out of steam before managing to get this stuff deployed in the real world. Seems to be the general PC problem of too many different vendors too coordinate, and PC vendors mostly care about cost reduction rather than new features. Apple is in a better place to do such tech but their whole model is closed-by-default, so they have a secure enclave like tech but only they are allowed to use it. Intel is still the best bet.
Unfortunately the developer experience without something like Conclave is pretty terrible, still. Disclaimer: I started the Conclave project, though I don't work on it anymore.
Here's how Apple describes their design of the Secure Enclave. I'd figure that Qualcomm, NXP, AMD, etc have a similar design.
> The Secure Enclave Processor provides the main computing power for the Secure Enclave. To provide the strongest isolation, the Secure Enclave Processor is dedicated solely for Secure Enclave use. This helps prevent side-channel attacks that depend on malicious software sharing the same execution core as the target software under attack.
> The Secure Enclave Processor runs an Apple-customized version of the L4 microkernel. It’s designed to operate efficiently at a lower clock speed that helps to protect it against clock and power attacks. The Secure Enclave Processor, starting with the A11 and S4, includes a memory-protected engine and encrypted memory with anti-replay capabilities, secure boot, a dedicated random number generator, and its own AES engine.
Given this attack vector, it makes some sense for relatively static secrets like these to be moved into something like the Secure Enclave where the CPU can perform signature verification but never store the secret itself in memory or cache. I know other ARM-based SoCs have these too. So presumably Intel and AMD offer something like this in their latest-generation CPUs?