3 ms·

> This made sense because SGX design followed security best practices, namely, you should minimize the size of the trusted computing base. More code that's trus

> This made sense because SGX design followed security best practices, namely, you should minimize the size of the trusted computing base. More code that's trusted = more potential for mistakes = more vulnerabilities. So SGX envisions apps having small trusted "enclaves", sort of like protected kernels, that untrusted code then uses. Let's say I was Google building gmail. What would I put in the 'secure enclave' ? Obviously the most important thing is the e-mail bodies, that's the real goldmine. And of course the logins / user session management. The SSL stuff naturally, the certificate for mail.google.com is priceless. And clearly if an attacker could compromise the server's static javascript it'd be game over, security-wise. At that point, is there anything left outside the secure enclave?

mike_hearn 1y ago
Right - it's not obvious, is it? I've spent a lot of time on the question of how to build such architectures and in the past (with a small team) built a platform called Conclave that made enclave development much easier. You could write enclaves in Java or JavaScript and get high level APIs to help architect a secure system. I should try and find time to write up the results of the investigations I did back then as lots of research was done into this topic. There are different threat models. Minimizing redesign costs means just lift'n'shifting into encrypted VMs. You then run cron jobs that connect to them and verify their remote attestations from time to time. This is a very weak approach, but it can help keep out some kinds of nosy neighbours who found a hypervisor/cloud auth exploit like the recent Azure failure, it reduces the number of cloud employees who can hack your stuff, and has a lot of other good benefits. That's why Intel and AMD are focusing on this easier target now. It doesn't provide your users any privacy against the email service provider (ESP), and some cloud employees can still beat you in various ways so it's no protection against a conspiracy e.g. US Gov wants your bytes. But it's got some security value and is a good place to start. But let's now minimize the size of the trusted computing base (TCB) by doing it with small enclaves instead of VMs. There can be networks of cooperating enclaves, that's OK. Thinking about email for a second, the design space is huge and this is an HN comment not a design doc. I will simplify aggressively to save space so we're going retro: IMAP, S/MIME and LDAP. In other words, we start from the basic infrastructure of an end-to-end encrypted email system. Passkeys can be used to set up a key pair that's backed up for the user. We assume slightly upgraded email clients from trusted suppliers that aren't the ESP, like Apple, Microsoft etc. We can then use enclaves to restore features that users expect from hosted email like server-side search and spam filtering. This is just an example of how to design enclave architectures, I'm not trying to show solutions to every threat at once. We will compromise on auth; identity will be supplied by the ESP. If a user wishes to take the ESP's LDAP servers out of the TCB they can exchange S/MIME certificates out of band to verify they match, or upload them to a variety of providers that are then all checked, use certificate transparency logs, etc. (by "the user can" I mean their upgraded email client implements these workflows). So what can we move out of the TCB when using SGX instead of SEV or TDX? The OS, obviously. The database, message queuing. Primary database keys are plaintext and sorted (there are ways to fix this leak), values are encrypted under an enclave key protected with AES-GCM. The value contains the hashed key and column name so we can verify the untrusted world gave us the right value to match a key. There are schemes that extend this to block replay attacks, but they're too large to fit in this margin. What else? We can move out TCP, TLS, IMAP. In other words, enclaves will be treated as semi-pure functions that have encrypted attestable memory spaces and an ability to derive their own private keys. They won't be making system calls or running full blown containers. The software running inside the enclave is designed for enclaves. First problem: how can we do indexing or spam filtering if the email is encrypted under a key the server doesn't have? The answer is obvious: the user uploads their private key to the enclaves! The process is: do a remote attestation with e.g. the spam filtering enclave, as part of which you learn the hash and/or signing key of the code running inside it. You also get a certificate chain showing the enclave is code signed by a trusted security firm that's audited the enclave source code for vulns, ensured it doesn't leak mail and so on. The email client verifies the RA protocol and certificate chain, becoming convinced in the process that the memory space of the spam filtering engine is secure and it will obey the social contract. Having done that it then uploads the user's private key to the enclave in an encrypted message tunnelled through TLS (two layers of encryption), the enclave then re-encrypts it and requests the untrusted world to store it to disk in the database. Now when an email is delivered the delivery and queueing infrastructure (all outside the TCB) hands it off to an (untrusted) spam server which loads the enclave into RAM, gives it the S/MIME message, loads the user's encrypted private key from the database, gives it spam scores for visible metadata like sending domain, hands all that off to the enclave and requests a classification. The enclave decrypts the user's private key, decrypts the S/MIME message, runs some classification on it and returns the result. For indexing it works similarly except the enclave has to encrypt the posting lists. If you want to get really fancy you have to hide access patterns as well to avoid statistical inference of likely email contents by looking at how popular certain posting lists are and such; it gets complicated fast but encrypting whole VMs doesn't actually block such attacks so you have to bite the bullet anyway. Notice how nearly everything about this system runs outside enclaves, yet, the ESP still can't read your mail. You do need help from third parties - someone has to write your upgraded email client, someone has to audit the enclave code the ESP runs, someone has to check the ESP isn't advertising the wrong public key for your username. But this is all quite tractable.

mike_hearn 1y ago

Right - it's not obvious, is it? I've spent a lot of time on the question of how to build such architectures and in the past (with a small team) built a platform called Conclave that made enclave development much easier. You could write enclaves in Java or JavaScript and get high level APIs to help architect a secure system. I should try and find time to write up the results of the investigations I did back then as lots of research was done into this topic. There are different threat models. Minimizing redesign costs means just lift'n'shifting into encrypted VMs. You then run cron jobs that connect to them and verify their remote attestations from time to time. This is a very weak approach, but it can help keep out some kinds of nosy neighbours who found a hypervisor/cloud auth exploit like the recent Azure failure, it reduces the number of cloud employees who can hack your stuff, and has a lot of other good benefits. That's why Intel and AMD are focusing on this easier target now. It doesn't provide your users any privacy against the email service provider (ESP), and some cloud employees can still beat you in various ways so it's no protection against a conspiracy e.g. US Gov wants your bytes. But it's got some security value and is a good place to start. But let's now minimize the size of the trusted computing base (TCB) by doing it with small enclaves instead of VMs. There can be networks of cooperating enclaves, that's OK. Thinking about email for a second, the design space is huge and this is an HN comment not a design doc. I will simplify aggressively to save space so we're going retro: IMAP, S/MIME and LDAP. In other words, we start from the basic infrastructure of an end-to-end encrypted email system. Passkeys can be used to set up a key pair that's backed up for the user. We assume slightly upgraded email clients from trusted suppliers that aren't the ESP, like Apple, Microsoft etc. We can then use enclaves to restore features that users expect from hosted email like server-side search and spam filtering. This is just an example of how to design enclave architectures, I'm not trying to show solutions to every threat at once. We will compromise on auth; identity will be supplied by the ESP. If a user wishes to take the ESP's LDAP servers out of the TCB they can exchange S/MIME certificates out of band to verify they match, or upload them to a variety of providers that are then all checked, use certificate transparency logs, etc. (by "the user can" I mean their upgraded email client implements these workflows). So what can we move out of the TCB when using SGX instead of SEV or TDX? The OS, obviously. The database, message queuing. Primary database keys are plaintext and sorted (there are ways to fix this leak), values are encrypted under an enclave key protected with AES-GCM. The value contains the hashed key and column name so we can verify the untrusted world gave us the right value to match a key. There are schemes that extend this to block replay attacks, but they're too large to fit in this margin. What else? We can move out TCP, TLS, IMAP. In other words, enclaves will be treated as semi-pure functions that have encrypted attestable memory spaces and an ability to derive their own private keys. They won't be making system calls or running full blown containers. The software running inside the enclave is designed for enclaves. First problem: how can we do indexing or spam filtering if the email is encrypted under a key the server doesn't have? The answer is obvious: the user uploads their private key to the enclaves! The process is: do a remote attestation with e.g. the spam filtering enclave, as part of which you learn the hash and/or signing key of the code running inside it. You also get a certificate chain showing the enclave is code signed by a trusted security firm that's audited the enclave source code for vulns, ensured it doesn't leak mail and so on. The email client verifies the RA protocol and certificate chain, becoming convinced in the process that the memory space of the spam filtering engine is secure and it will obey the social contract. Having done that it then uploads the user's private key to the enclave in an encrypted message tunnelled through TLS (two layers of encryption), the enclave then re-encrypts it and requests the untrusted world to store it to disk in the database. Now when an email is delivered the delivery and queueing infrastructure (all outside the TCB) hands it off to an (untrusted) spam server which loads the enclave into RAM, gives it the S/MIME message, loads the user's encrypted private key from the database, gives it spam scores for visible metadata like sending domain, hands all that off to the enclave and requests a classification. The enclave decrypts the user's private key, decrypts the S/MIME message, runs some classification on it and returns the result. For indexing it works similarly except the enclave has to encrypt the posting lists. If you want to get really fancy you have to hide access patterns as well to avoid statistical inference of likely email contents by looking at how popular certain posting lists are and such; it gets complicated fast but encrypting whole VMs doesn't actually block such attacks so you have to bite the bullet anyway. Notice how nearly everything about this system runs outside enclaves, yet, the ESP still can't read your mail. You do need help from third parties - someone has to write your upgraded email client, someone has to audit the enclave code the ESP runs, someone has to check the ESP isn't advertising the wrong public key for your username. But this is all quite tractable.