2 ms·

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

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.

jeroenhd 4y ago
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.
- mike_hearn 4y ago
  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.
  - jeroenhd 4y ago
    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.

jeroenhd 4y ago

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.

mike_hearn 4y ago
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.
- jeroenhd 4y ago
  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.