3 ms·

Basically, SGX: https://github.com/signalapp/SecureValueRecovery https://github.com/signalapp/SecureValueRecovery The enclave is hardened against Spectre and L

by kijiki 6y ago

Basically, SGX: https://github.com/signalapp/SecureValueRecovery https://github.com/signalapp/SecureValueRecovery The enclave is hardened against Spectre and LVI with this (BOLT/LLVM based), and other techniques: https://github.com/signalapp/BOLT https://github.com/signalapp/BOLT The last build step before signing is a verifier that checks that there are no missed mitigations, built using Intel Xed, to try to avoid potential missing mitigations due to an LLVM or BOLT bug.

JoshTriplett 6y ago
I'm familiar with Signal's usage of enclaves. The case I'm wondering about is what happens if someone seized (or surreptitiously accessed) Signal's servers, ran the unmodified enclaves, but fed in different PIN requests to those enclaves in a brute-forcing attempt. What prevents that?
- kijiki 6y ago
  The enclaves will flush the data (much like the hardware you mention in your first post) after some number of wrong PIN guesses. To do this securely made the whole thing quite difficult, because it means we can never persist anything outside the enclave, or an attacker could unpersist into 1000 unmodified enclaves (who would never know about each other) and get 1000*N guesses.
  - JoshTriplett 6y ago
    That was precisely the kind of architecture I was hoping to see documented, yes. So you're locking data not just to the code running in the enclave but to the specific hardware the enclave runs on, and further doing something to prevent replay? And at the same time, providing resilience against hardware failure of the machine any given enclave runs on, and providing persistence?
    - kijiki 6y ago
      Yeah, there is a 32 byte random serviceid generated inside the enclave when it starts in "new" mode, so it is locked to the serviceid, not the HW, so we can migrate off failing/failed hardware. The only way to get a non-random serviceid is to have keyspace transferred to you from an existing enclave, after mutual attestation. Clients verify the serviceid after attestation verifies the enclave. Each partition of the keyspace lives on a 5 node cluster, running RAFT inside the enclaves to ensure the pin guess count is consistent. If a node fails, or is failing, or we need to do maintenance, we transfer the partition from the old nodes to new ones, which transfers the serviceid as well. If you start a new enclave from scratch, it'll generate a new serviceid, and clients won't talk to it, and existing partitions will refuse to transfer to it since it already has a serviceid. In fact, it won't even be listening for incoming transfers, since it thinks it owns the entire keyspace. We can also do a partial partition transfer that leaves the source cluster live, which we use to split up the keyspace more when we need to scale up. There is no persistence (wouldn't be secure, attackers could do many parallel enclave resumes to get extra guesses), so the 5 nodes in the cluster live in geographically separated data centers, and we're real careful about things that could kill a node or process.
- ccktlmazeltov 6y ago
  if it's anything like what other big players are doing: the attempts are limited and the code will destroy its knowledge of the key once you reach this limit. Looking at the code quickly I see that nothing is documented and it's not clear what code gets executed there. So good luck understanding what they're doing. But it seems to be using Raft, probably to bring several HSMs to consensus on what's the state of the number of attempts. And it does seem to erase stuff if you reach some threshold of attempts: https://github.com/signalapp/SecureValueRecovery/blob/00d023abcaf16d7ea664f9e6f1dd8b2aff4da915/enclave/kbupd_enclave/src/service/replica/partition_data.rs#L518 https://github.com/signalapp/SecureValueRecovery/blob/00d023... My follow up question is: what prevents someone from destroying your account's backup key by entering wrong PINs for your account?
  - kijiki 6y ago
    That isn't quite how it is implemented, there are no HSMs, we use SGX for that function instead. See my reply to Josh's follow up for details. You need a random id not the phone number, so other users can't do guesses unless they get that random id somehow. The ID is stored on the phone, and if you lose it, when you reinstall Signal, the signal server will give it to you after SMS phone # verification. A sim-jacker could nuke your key, but that seems like a lot of work for griefing. Signal of course, has the plaintext random id, so they could nuke your backup, but there are tons of ways Signal can DoS attack their own service. Stopping paying for the servers, for one.

by kijiki 6y ago

JoshTriplett 6y ago

I'm familiar with Signal's usage of enclaves. The case I'm wondering about is what happens if someone seized (or surreptitiously accessed) Signal's servers, ran the unmodified enclaves, but fed in different PIN requests to those enclaves in a brute-forcing attempt. What prevents that?

kijiki 6y ago
The enclaves will flush the data (much like the hardware you mention in your first post) after some number of wrong PIN guesses. To do this securely made the whole thing quite difficult, because it means we can never persist anything outside the enclave, or an attacker could unpersist into 1000 unmodified enclaves (who would never know about each other) and get 1000*N guesses.
- JoshTriplett 6y ago
  That was precisely the kind of architecture I was hoping to see documented, yes. So you're locking data not just to the code running in the enclave but to the specific hardware the enclave runs on, and further doing something to prevent replay? And at the same time, providing resilience against hardware failure of the machine any given enclave runs on, and providing persistence?
  - kijiki 6y ago
    Yeah, there is a 32 byte random serviceid generated inside the enclave when it starts in "new" mode, so it is locked to the serviceid, not the HW, so we can migrate off failing/failed hardware. The only way to get a non-random serviceid is to have keyspace transferred to you from an existing enclave, after mutual attestation. Clients verify the serviceid after attestation verifies the enclave. Each partition of the keyspace lives on a 5 node cluster, running RAFT inside the enclaves to ensure the pin guess count is consistent. If a node fails, or is failing, or we need to do maintenance, we transfer the partition from the old nodes to new ones, which transfers the serviceid as well. If you start a new enclave from scratch, it'll generate a new serviceid, and clients won't talk to it, and existing partitions will refuse to transfer to it since it already has a serviceid. In fact, it won't even be listening for incoming transfers, since it thinks it owns the entire keyspace. We can also do a partial partition transfer that leaves the source cluster live, which we use to split up the keyspace more when we need to scale up. There is no persistence (wouldn't be secure, attackers could do many parallel enclave resumes to get extra guesses), so the 5 nodes in the cluster live in geographically separated data centers, and we're real careful about things that could kill a node or process.
ccktlmazeltov 6y ago
if it's anything like what other big players are doing: the attempts are limited and the code will destroy its knowledge of the key once you reach this limit. Looking at the code quickly I see that nothing is documented and it's not clear what code gets executed there. So good luck understanding what they're doing. But it seems to be using Raft, probably to bring several HSMs to consensus on what's the state of the number of attempts. And it does seem to erase stuff if you reach some threshold of attempts: https://github.com/signalapp/SecureValueRecovery/blob/00d023abcaf16d7ea664f9e6f1dd8b2aff4da915/enclave/kbupd_enclave/src/service/replica/partition_data.rs#L518 https://github.com/signalapp/SecureValueRecovery/blob/00d023... My follow up question is: what prevents someone from destroying your account's backup key by entering wrong PINs for your account?
- kijiki 6y ago
  That isn't quite how it is implemented, there are no HSMs, we use SGX for that function instead. See my reply to Josh's follow up for details. You need a random id not the phone number, so other users can't do guesses unless they get that random id somehow. The ID is stored on the phone, and if you lose it, when you reinstall Signal, the signal server will give it to you after SMS phone # verification. A sim-jacker could nuke your key, but that seems like a lot of work for griefing. Signal of course, has the plaintext random id, so they could nuke your backup, but there are tons of ways Signal can DoS attack their own service. Stopping paying for the servers, for one.