7 ms·

Technology Preview for secure value recovery

157 points by sinak 7y ago

bilal4hmed 7y ago
can someone explain this ....on initial reading it seems this is for backup of messages but I have a feeling this is more than that
- saagarjha 7y ago
  It's an attempt at storage of secrets on a remote server using SGX and consensus protocols. Signal seems to be using this to store people's social graphs "in the cloud".
  - bilal4hmed 7y ago
    thank you
- ignoramous 7y ago
  From what I understand: The blog answers, how does one store a secret without it being subject to brute force (and other offline) attacks [0], with: Generation of the secret (on the client): 1. Generate sk: Key-stretch user-provided pass-phrase to 256 bits using Argon2 [1]. 2. Generate a verifiable auth-token, token = hmac-sha256(sk, "auth key encrpytion") [2] 3. Generate a split secret-key: 3a. split1 = hmac-sha256(sk, "master key encryption") 3b. split2 = high-entropy-random-256-bits 4. Send key-pair (token, split2) to remote machines running BOLTed [3] server code in a SGX enclave [4] that replicate it using raft-consensus protocol [5] over Noise [6] in an hardware-encrypted RAM [7] and never on-disk. 5. Generate master-key = hmac-sha256(split1, split2) 6. Generate as many application-keys as required, and use these to encrypt user's data, for instance, app-key-sge = hmac-sha256(master_key, "social graph encryption") and so on... - Recovery of the secret (by the client): 1. On the client, using user-provided pass-phrase, generate sk, token, and split1, like above. 2. Send the token to a remote machine. If the token is valid, remote lets the client retrieve split2 [8] with which the client can now generate the master-key and app-keys, as before. 3. If the token sent is invalid, remote lets the client retry a very limited number of times before destroying the secret key-pair. --- [0] From the post, ...we’ve been working on new techniques based on secure enclaves and key splitting that are designed to enhance and expand general capabilities for private cloud storage. Our aim is to unlock new possibilities and new functionality within Signal which require cross-platform long-term durable state, while verifiably keeping this state inaccessible to everyone but the user who created it. [1] https://en.wikipedia.org/wiki/Argon2 https://en.wikipedia.org/wiki/Argon2 (end-users prefer shorter passwords but one gets better entropy with longer passwords... which is what Argon2 brings to the table) [2] https://en.wikipedia.org/wiki/HMAC https://en.wikipedia.org/wiki/HMAC [3] https://github.com/facebookincubator/BOLT https://github.com/facebookincubator/BOLT (prevents speculative execution exploits: https://en.wikipedia.org/wiki/Speculative_execution https://en.wikipedia.org/wiki/Speculative_execution) [4] https://blog.quarkslab.com/overview-of-intel-sgx-part-1-sgx-internals.html https://blog.quarkslab.com/overview-of-intel-sgx-part-1-sgx-... (used for strict code and hardware attestation) [5] https://www.youtube-nocookie.com/embed/YbZ3zDzDnrw https://www.youtube-nocookie.com/embed/YbZ3zDzDnrw [6] http://www.noiseprotocol.org/ http://www.noiseprotocol.org/ (Wireguard and WhatsApp use it, too, for end-to-end communication) [7] https://eprint.iacr.org/2016/204.pdf https://eprint.iacr.org/2016/204.pdf [8] Thanks u/jlund: https://news.ycombinator.com/item?id=21839394 https://news.ycombinator.com/item?id=21839394
  - jlund 7y ago
    Nice breakdown! Just to clarify, in step 2 of your "Recovery of the secret (by the client)" section, the client is retrieving `split2`, not `split1`.
- TheOperator 7y ago
  >can someone explain this Gotta love cryptography. I read through the article, read it again, and started googing things I didn't understand.
- IshKebab 7y ago
  It's essentially a way of storing your password hash in the cloud such that nobody - not even the cloud providers - can read the hash and try to brute force it. All anyone can do is send password attempts to the cloud server's SGX system, which in theory is completely private, even to the host OS. It also provides a way for the client to verify the code that is running in the SGX system, so you know you're sending your password attempts to some program that really does do all this fancy stuff. You don't have to take Signal's word for it. It's basically equivalent to the chip in iPhones that stores your PIN and counts failed attempts. Except it's in the cloud and distributed, which is way harder to do.
  - floatboth 7y ago
    > storing your password hash Not really. The goal is to safely store an extra random value that's mixed with the password hash to derive the master key for the account, because they don't want to fully trust the password hash, because some passwords are too weak. Could've just made password requirements stronger, but that doesn't provide an excuse to play with SGX I guess :)
    - IshKebab 7y ago
      I was simplifying.
sneak 7y ago
I still don’t know how we are going to be able to validate the remote attestation comes from the enclave and not, say, a virtualized one that just logs all the secrets but still attests correctly. Are they going to ship intel device hardware pubkeys or certs to the clients?
- Canada 7y ago
  That would be the way to do it.
  - sneak 7y ago
    All of my signal desktop clients seem to update automatically, downloading new code and prompting me to restart the app to run it. With such opaque, basically-RCE privileges assumed by the app, I am not sure what would stop a malicious insider from sending an update to silently replace the sgx keys or certs (or shipping any other targeted secret exfiltration code). Seems to me that with the client autoupdate, this would be a much easier nut to crack than the secure enclave (not to disparage the work on the defense-in-depth). It just seems like a ton of work and complexity to me for not a ton of benefit considering the existing threat models. Good on them for making the attempt, though.
    - cjbprime 7y ago
      This is a super interesting problem! It applies to basically all desktop autoupdaters. Note that App Stores are in a better place -- as far as I know they don't make it possible to target users with malicious updates, you'd have to push the malicious update to everyone at once. Some anonymity wins for desktop apps are downloading updates over Tor (to prevent the update server knowing who you are by your IP) or Bittorrent (to prevent the ability to offer an update to someone without offering it to everyone), and checking that you're being offered a binary whose hash is published publicly (e.g. to a blockchain). But then you start hitting increased code surface problems and those systems not working on some networks. I think Tor's Firefox browser does the anonymous Tor update thing; that's probably the best in class here.
saagarjha 7y ago
How exactly does SGX remote attestation work? From the linked document (https://software.intel.com/en-us/articles/innovative-technology-for-cpu-based-attestation-and-sealing https://software.intel.com/en-us/articles/innovative-technol...) it seems like it hashes execution state, but what's stopping the enclave from emulating the execution while also on the side performing some malicious operation?
- gruez 7y ago
  >but what's stopping the enclave from emulating the execution while also on the side performing some malicious operation? That's what remote attestation is supposed to prevent. https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attes... Basically you're trusting the processor to truthfully attest its execution state. You can't emulate it because the attestation is signed with a key that's burned into the processor.
  - IshKebab 7y ago
    So there's some master SGX private key burned into all Intel processors? Edit: I found a description and it does sound like they store a master key in all CPUs! https://blog.quarkslab.com/overview-of-intel-sgx-part-2-sgx-externals.html https://blog.quarkslab.com/overview-of-intel-sgx-part-2-sgx-... It is stored in e-fuses, which can be read, but it is encrypted using a Physical Unclonable Function, which means to read it you would need the CPU to be running. Very difficult but I'd be surprised if it were impossible.
    - gruez 7y ago
      Not necessarily a master key - it could use a PKI scheme, similar to how TPMs work. >The solution first adopted by the TCG (TPM specification v1.1) required a trusted third-party, namely a privacy certificate authority (privacy CA). Each TPM has an embedded RSA key pair called an Endorsement Key (EK) which the privacy CA is assumed to know. In order to attest the TPM generates a second RSA key pair called an Attestation Identity Key (AIK). It sends the public AIK, signed by EK, to the privacy CA who checks its validity and issues a certificate for the AIK. (For this to work, either a) the privacy CA must know the TPM's public EK a priori, or b) the TPM's manufacturer must have provided an endorsement certificate.) The host/TPM is now able to authenticate itself with respect to the certificate. This approach permits two possibilities to detecting rogue TPMs: firstly the privacy CA should maintain a list of TPMs identified by their EK known to be rogue and reject requests from them, secondly if a privacy CA receives too many requests from a particular TPM it may reject them and blacklist the TPMs EK. The number of permitted requests should be subject to a risk management exercise. This solution is problematic since the privacy CA must take part in every transaction and thus must provide high availability whilst remaining secure. Furthermore, privacy requirements may be violated if the privacy CA and verifier collude. Although the latter issue can probably be resolved using blind signatures, the first remains. https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation
tptacek 7y ago
This is very similar to a design Apple announced for iCloud Keychain several years ago at Black Hat. iCloud Keychain synchronizes keychains across iOS devices, storing their contents encrypted under the user's passphrase on Apple's cloud servers. In theory, Apple has no access to this data, since they don't know the relevant passphrase. In practice, however, passphrases are weak, even under PBKDF2. An attacker that got access to Apple's cloud environment would simply dictionary attack the encrypted blobs, and would probably succeed a lot of the time. So instead of the obvious naive design, Apple stores enough secret data in an HSM so that you can't attempt a decryption without the involvement of the HSM. At the same time, the HSM enforces an attempt counter, preventing brute force attacks. To scale the design, Apple partitions customers into "clubs" of HSMs, with the attempt counter synchronized among the HSMs of the club using a distributed commit algorithm. (Somewhat infamously, Ivan Krstic detailed how they protected the HSMs themselves from malicious attacks by putting their software update signing keys through a "physical hash function" called "Vitamix blender".) What Signal is doing here is essentially what Apple did, but using SGX instead of an HSM, and RAFT as the consensus algorithm to synchronize the counters. You might reasonably prefer the Apple approach to SGX, but at the same time, the data that Signal is storing is a lot less sensitive than the data Apple stores. Probably the biggest end-user takeaway from this announcement is that it's the start of a process where Signal is able to durably and securely store social graph information for its users (without revealing the social graphs directly to Signal itself, unlike virtually every other secure messaging system). Once they can do that, they'll have ended most of their dependence on phone numbers.
- sansnomme 7y ago
  These days however you can do password resets manually with Apple. It is no longer as stringent as before where previously if you lost your password without recovery methods enabled your account is as good as gone. The current Apple account system is a lot weaker.
  - saagarjha 7y ago
    iCloud Keychain isn't tied to password reset; you need to use the recovery code for it.
josh2600 7y ago
This is the tech that would allow the key management we described in section 3.4 of the MobileCoin whitepaper [0] to exist. [0] https://www.mobilecoin.com/whitepaper-en.pdf https://www.mobilecoin.com/whitepaper-en.pdf
tracnar 7y ago
I don't get what prevents an attacker from deleting the secrets of everyone by just guessing? Shouldn't the guesses be time limited instead (e.g. once per hour)? Even then you could easily bring the service down...
- Arbalest 7y ago
  If someone attempted that large an attack, it would be pretty visible, and perhaps there's a mechanism to reset those tries after an amount of time. Targeted attacks on the other hand...
3fe9a03ccd14ca5 7y ago
> These were hardscrabble people, living off of whatever meager storage they could scrounge together. They’d zip things, put them on zip drives, and hope for the best. Then one day almost everyone looked up towards the metaphorical sky and made a lot of compromises. I wish every tech blog was written like this. Light-hearted and serious at the same time, almost like a work of fiction.
gojomo 7y ago
Why does Signal want to make things so complicated? This starting premise about the 'normal approach' is not true: > However, you may want to change devices, and accidents sometimes happen. The normal approach to these situations would be to store data remotely in an unencrypted database, No, the normal approach would be to let authenticated users export their data from their own secure device to a place of their choosing, then let authenticated users also import that data. For paternalistic control-freaks like the Signal team, the data could even only ever be exported in an encrypted format, for encryption-at-rest. Sure, there'd be some risk that the encryption key is not well-protected, or the data-at-rest is subject to brute-force attacks – but many users can manage those risks themselves. So why this strawman premise that the baseline is "remote" and "unencrypted"? Just give me a local export, and import, and I'll protect my data fairly well, thank you. That would solve a major usability disaster of Signal on iOS devices: that even an orderly, planned device upgrade where both devices are in your sole control – and could conceivably do a direct transfer of all sensitive data! – will still lose all your history and Signal-contacts. The cloud-centric strawmen from Signal continue with this related claim: > In the example of a non-phone-number-based addressing system, cloud storage is necessary for recovering the social graph that would otherwise be lost with a device switch or app reinstall. No, again, all a user needs is a local backup/transfer method for that list of usernames/identity-endpoints. (And to be no worse than the current Signal approach of re-using the device's native contact list, this list-at-rest or list-in-transit only needs protection as good as the native contact list, a pretty low bar.)
- mkj 7y ago
  You're describing the zip drive approach that they mention in the article, which isn't competitive with current user expectations. Signal are trying to make a secure mass market product, not just something usable for geeks who will export a backup to their home sftp server.
  - gojomo 7y ago
    They don't really explain any specific problems with what they've slurred as a "zip drive" approach. Offering a self-backup option would be more competitive than Signal's current nothing at all – which means total data loss on any device loss or upgrade, for iOS users. Absolutely, promise users a Signal-quality cloud experience, someday, when this novel development is finished, and when there's an economic model for reliably storing users' opaque data in the cloud – and if users trust Intel SGX. But in the indefinitely-long meantime, why deny users the proven & well-worn path of self-data management? (And shouldn't users have the right to an exportable format of their own contact/messaging data?)
ENOTTY 7y ago
It's not clear to me how the nodes authenticate a new node on node replacement. They say that the nodes check the new node's MRENCLAVE value, so what happens if there is a software update and the MRENCLAVE value has to change? How do the old nodes know what the new MRENCLAVE value should be?
genpfault 7y ago
Is this going to make app backup/restore even more torturous? I already almost got bit by the transition to the current magic number + special in-app export, vs. the previously-working Titanium Backup APK + data snapshot method.
ggm 7y ago
This is inherently good in itself. But, I ask myself if the oft- requested 'can we be people without phone # in signal' is now actually a deliverable, or if they only stated it in hypothesis, and still don't have that as a roadmap outcome? I want to have two (or more) non-phone enabled devices able to be in signal. My tablet, and my computer. I realize there are adjunct methods, but depending on a physically present device to have one thing hooked up isn't actually what we want here, the phone is not a useful second factor, its a hack I believe they worked out to get beyond the 'must be a phone' state without having to re-engineer the back end. So: do we now get phone-less signal identity? This feels like a precursor. Does that definitionally say phone-less identity will follow? (again only from belief, I believe the secure enclave on the phone is bound into identity along with the IDD, so having a secure enclave backed in the cloud breaks one of the two dependencies out a bit)
- Vinnl 7y ago
  I don't think it would make sense for them to now state that they're going to deliver that no matter what, because then 1. You're going to have people asking for timelines on that even more often than people are currently asking for non-phone number authentication, and if you indulge them, they're going to get angry with you for missing it. 2. Who knows what other problems might turn up when implementing it. I'd expect them to announce it very close to it being actually possible. Until then, we'll probably only hear about individual problems they solved on the road to there.
- codethief 7y ago
  It looks like they're working on usernames but, apparently, you'll still need a phone number to sign up: https://community.signalusers.org/t/signal-introducing-usernames/9157 https://community.signalusers.org/t/signal-introducing-usern...
jtolds 7y ago
I'm very puzzled by the consensus group load balancing section. The article emphasizes correctness of the Raft algorithm was super important (to the point that they skipped clear optimizations!!11), but, then immediately follows up with (as far as I can tell) a load-balancer wrapper approach for rebalancing and scaling. My "this feels like consensus bug city" detectors immediately went off. Consensus algorithms (including Raft and Paxos) are notoriously picky and hard to get right around cluster membership changes. If you try to end run around this by sharding to different clusters with a simple traffic director to choose which cluster, how does the traffic director achieve consensus with the clusters that the traffic is going to the right cluster? You haven't solved any consensus problem, you've just moved it to your load balancers. A solution for this problem (to agree on which cluster the data is owned by) is 2-phase commit on top of the consensus clusters. It didn't appear from the diagrams that that's what they did here, so either I missed something, or this wouldn't pass a Jepsen test. Did I miss something? [If you did build 2PC on top of these consensus clusters, you'd have built a significant portion of Spanner's architecture inside of a secure enclave. That's hilarious.]

157 points by sinak 7y ago

can someone explain this ....on initial reading it seems this is for backup of messages but I have a feeling this is more than that

saagarjha 7y ago
It's an attempt at storage of secrets on a remote server using SGX and consensus protocols. Signal seems to be using this to store people's social graphs "in the cloud".
- bilal4hmed 7y ago
  thank you
ignoramous 7y ago
From what I understand: The blog answers, how does one store a secret without it being subject to brute force (and other offline) attacks [0], with: Generation of the secret (on the client): 1. Generate sk: Key-stretch user-provided pass-phrase to 256 bits using Argon2 [1]. 2. Generate a verifiable auth-token, token = hmac-sha256(sk, "auth key encrpytion") [2] 3. Generate a split secret-key: 3a. split1 = hmac-sha256(sk, "master key encryption") 3b. split2 = high-entropy-random-256-bits 4. Send key-pair (token, split2) to remote machines running BOLTed [3] server code in a SGX enclave [4] that replicate it using raft-consensus protocol [5] over Noise [6] in an hardware-encrypted RAM [7] and never on-disk. 5. Generate master-key = hmac-sha256(split1, split2) 6. Generate as many application-keys as required, and use these to encrypt user's data, for instance, app-key-sge = hmac-sha256(master_key, "social graph encryption") and so on... - Recovery of the secret (by the client): 1. On the client, using user-provided pass-phrase, generate sk, token, and split1, like above. 2. Send the token to a remote machine. If the token is valid, remote lets the client retrieve split2 [8] with which the client can now generate the master-key and app-keys, as before. 3. If the token sent is invalid, remote lets the client retry a very limited number of times before destroying the secret key-pair. --- [0] From the post, ...we’ve been working on new techniques based on secure enclaves and key splitting that are designed to enhance and expand general capabilities for private cloud storage. Our aim is to unlock new possibilities and new functionality within Signal which require cross-platform long-term durable state, while verifiably keeping this state inaccessible to everyone but the user who created it. [1] https://en.wikipedia.org/wiki/Argon2 https://en.wikipedia.org/wiki/Argon2 (end-users prefer shorter passwords but one gets better entropy with longer passwords... which is what Argon2 brings to the table) [2] https://en.wikipedia.org/wiki/HMAC https://en.wikipedia.org/wiki/HMAC [3] https://github.com/facebookincubator/BOLT https://github.com/facebookincubator/BOLT (prevents speculative execution exploits: https://en.wikipedia.org/wiki/Speculative_execution https://en.wikipedia.org/wiki/Speculative_execution) [4] https://blog.quarkslab.com/overview-of-intel-sgx-part-1-sgx-internals.html https://blog.quarkslab.com/overview-of-intel-sgx-part-1-sgx-... (used for strict code and hardware attestation) [5] https://www.youtube-nocookie.com/embed/YbZ3zDzDnrw https://www.youtube-nocookie.com/embed/YbZ3zDzDnrw [6] http://www.noiseprotocol.org/ http://www.noiseprotocol.org/ (Wireguard and WhatsApp use it, too, for end-to-end communication) [7] https://eprint.iacr.org/2016/204.pdf https://eprint.iacr.org/2016/204.pdf [8] Thanks u/jlund: https://news.ycombinator.com/item?id=21839394 https://news.ycombinator.com/item?id=21839394
- jlund 7y ago
  Nice breakdown! Just to clarify, in step 2 of your "Recovery of the secret (by the client)" section, the client is retrieving `split2`, not `split1`.
TheOperator 7y ago
>can someone explain this Gotta love cryptography. I read through the article, read it again, and started googing things I didn't understand.
IshKebab 7y ago
It's essentially a way of storing your password hash in the cloud such that nobody - not even the cloud providers - can read the hash and try to brute force it. All anyone can do is send password attempts to the cloud server's SGX system, which in theory is completely private, even to the host OS. It also provides a way for the client to verify the code that is running in the SGX system, so you know you're sending your password attempts to some program that really does do all this fancy stuff. You don't have to take Signal's word for it. It's basically equivalent to the chip in iPhones that stores your PIN and counts failed attempts. Except it's in the cloud and distributed, which is way harder to do.
- floatboth 7y ago
  > storing your password hash Not really. The goal is to safely store an extra random value that's mixed with the password hash to derive the master key for the account, because they don't want to fully trust the password hash, because some passwords are too weak. Could've just made password requirements stronger, but that doesn't provide an excuse to play with SGX I guess :)
  - IshKebab 7y ago
    I was simplifying.

sneak 7y ago

I still don’t know how we are going to be able to validate the remote attestation comes from the enclave and not, say, a virtualized one that just logs all the secrets but still attests correctly. Are they going to ship intel device hardware pubkeys or certs to the clients?

Canada 7y ago
That would be the way to do it.
- sneak 7y ago
  All of my signal desktop clients seem to update automatically, downloading new code and prompting me to restart the app to run it. With such opaque, basically-RCE privileges assumed by the app, I am not sure what would stop a malicious insider from sending an update to silently replace the sgx keys or certs (or shipping any other targeted secret exfiltration code). Seems to me that with the client autoupdate, this would be a much easier nut to crack than the secure enclave (not to disparage the work on the defense-in-depth). It just seems like a ton of work and complexity to me for not a ton of benefit considering the existing threat models. Good on them for making the attempt, though.
  - cjbprime 7y ago
    This is a super interesting problem! It applies to basically all desktop autoupdaters. Note that App Stores are in a better place -- as far as I know they don't make it possible to target users with malicious updates, you'd have to push the malicious update to everyone at once. Some anonymity wins for desktop apps are downloading updates over Tor (to prevent the update server knowing who you are by your IP) or Bittorrent (to prevent the ability to offer an update to someone without offering it to everyone), and checking that you're being offered a binary whose hash is published publicly (e.g. to a blockchain). But then you start hitting increased code surface problems and those systems not working on some networks. I think Tor's Firefox browser does the anonymous Tor update thing; that's probably the best in class here.

saagarjha 7y ago

How exactly does SGX remote attestation work? From the linked document (https://software.intel.com/en-us/articles/innovative-technology-for-cpu-based-attestation-and-sealing https://software.intel.com/en-us/articles/innovative-technol...) it seems like it hashes execution state, but what's stopping the enclave from emulating the execution while also on the side performing some malicious operation?

gruez 7y ago
>but what's stopping the enclave from emulating the execution while also on the side performing some malicious operation? That's what remote attestation is supposed to prevent. https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attes... Basically you're trusting the processor to truthfully attest its execution state. You can't emulate it because the attestation is signed with a key that's burned into the processor.
- IshKebab 7y ago
  So there's some master SGX private key burned into all Intel processors? Edit: I found a description and it does sound like they store a master key in all CPUs! https://blog.quarkslab.com/overview-of-intel-sgx-part-2-sgx-externals.html https://blog.quarkslab.com/overview-of-intel-sgx-part-2-sgx-... It is stored in e-fuses, which can be read, but it is encrypted using a Physical Unclonable Function, which means to read it you would need the CPU to be running. Very difficult but I'd be surprised if it were impossible.
  - gruez 7y ago
    Not necessarily a master key - it could use a PKI scheme, similar to how TPMs work. >The solution first adopted by the TCG (TPM specification v1.1) required a trusted third-party, namely a privacy certificate authority (privacy CA). Each TPM has an embedded RSA key pair called an Endorsement Key (EK) which the privacy CA is assumed to know. In order to attest the TPM generates a second RSA key pair called an Attestation Identity Key (AIK). It sends the public AIK, signed by EK, to the privacy CA who checks its validity and issues a certificate for the AIK. (For this to work, either a) the privacy CA must know the TPM's public EK a priori, or b) the TPM's manufacturer must have provided an endorsement certificate.) The host/TPM is now able to authenticate itself with respect to the certificate. This approach permits two possibilities to detecting rogue TPMs: firstly the privacy CA should maintain a list of TPMs identified by their EK known to be rogue and reject requests from them, secondly if a privacy CA receives too many requests from a particular TPM it may reject them and blacklist the TPMs EK. The number of permitted requests should be subject to a risk management exercise. This solution is problematic since the privacy CA must take part in every transaction and thus must provide high availability whilst remaining secure. Furthermore, privacy requirements may be violated if the privacy CA and verifier collude. Although the latter issue can probably be resolved using blind signatures, the first remains. https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation

tptacek 7y ago

This is very similar to a design Apple announced for iCloud Keychain several years ago at Black Hat. iCloud Keychain synchronizes keychains across iOS devices, storing their contents encrypted under the user's passphrase on Apple's cloud servers. In theory, Apple has no access to this data, since they don't know the relevant passphrase. In practice, however, passphrases are weak, even under PBKDF2. An attacker that got access to Apple's cloud environment would simply dictionary attack the encrypted blobs, and would probably succeed a lot of the time. So instead of the obvious naive design, Apple stores enough secret data in an HSM so that you can't attempt a decryption without the involvement of the HSM. At the same time, the HSM enforces an attempt counter, preventing brute force attacks. To scale the design, Apple partitions customers into "clubs" of HSMs, with the attempt counter synchronized among the HSMs of the club using a distributed commit algorithm. (Somewhat infamously, Ivan Krstic detailed how they protected the HSMs themselves from malicious attacks by putting their software update signing keys through a "physical hash function" called "Vitamix blender".) What Signal is doing here is essentially what Apple did, but using SGX instead of an HSM, and RAFT as the consensus algorithm to synchronize the counters. You might reasonably prefer the Apple approach to SGX, but at the same time, the data that Signal is storing is a lot less sensitive than the data Apple stores. Probably the biggest end-user takeaway from this announcement is that it's the start of a process where Signal is able to durably and securely store social graph information for its users (without revealing the social graphs directly to Signal itself, unlike virtually every other secure messaging system). Once they can do that, they'll have ended most of their dependence on phone numbers.

sansnomme 7y ago
These days however you can do password resets manually with Apple. It is no longer as stringent as before where previously if you lost your password without recovery methods enabled your account is as good as gone. The current Apple account system is a lot weaker.
- saagarjha 7y ago
  iCloud Keychain isn't tied to password reset; you need to use the recovery code for it.

josh2600 7y ago

This is the tech that would allow the key management we described in section 3.4 of the MobileCoin whitepaper [0] to exist. [0] https://www.mobilecoin.com/whitepaper-en.pdf https://www.mobilecoin.com/whitepaper-en.pdf

tracnar 7y ago

I don't get what prevents an attacker from deleting the secrets of everyone by just guessing? Shouldn't the guesses be time limited instead (e.g. once per hour)? Even then you could easily bring the service down...

Arbalest 7y ago
If someone attempted that large an attack, it would be pretty visible, and perhaps there's a mechanism to reset those tries after an amount of time. Targeted attacks on the other hand...

3fe9a03ccd14ca5 7y ago

> These were hardscrabble people, living off of whatever meager storage they could scrounge together. They’d zip things, put them on zip drives, and hope for the best. Then one day almost everyone looked up towards the metaphorical sky and made a lot of compromises. I wish every tech blog was written like this. Light-hearted and serious at the same time, almost like a work of fiction.

gojomo 7y ago

Why does Signal want to make things so complicated? This starting premise about the 'normal approach' is not true: > However, you may want to change devices, and accidents sometimes happen. The normal approach to these situations would be to store data remotely in an unencrypted database, No, the normal approach would be to let authenticated users export their data from their own secure device to a place of their choosing, then let authenticated users also import that data. For paternalistic control-freaks like the Signal team, the data could even only ever be exported in an encrypted format, for encryption-at-rest. Sure, there'd be some risk that the encryption key is not well-protected, or the data-at-rest is subject to brute-force attacks – but many users can manage those risks themselves. So why this strawman premise that the baseline is "remote" and "unencrypted"? Just give me a local export, and import, and I'll protect my data fairly well, thank you. That would solve a major usability disaster of Signal on iOS devices: that even an orderly, planned device upgrade where both devices are in your sole control – and could conceivably do a direct transfer of all sensitive data! – will still lose all your history and Signal-contacts. The cloud-centric strawmen from Signal continue with this related claim: > In the example of a non-phone-number-based addressing system, cloud storage is necessary for recovering the social graph that would otherwise be lost with a device switch or app reinstall. No, again, all a user needs is a local backup/transfer method for that list of usernames/identity-endpoints. (And to be no worse than the current Signal approach of re-using the device's native contact list, this list-at-rest or list-in-transit only needs protection as good as the native contact list, a pretty low bar.)

mkj 7y ago
You're describing the zip drive approach that they mention in the article, which isn't competitive with current user expectations. Signal are trying to make a secure mass market product, not just something usable for geeks who will export a backup to their home sftp server.
- gojomo 7y ago
  They don't really explain any specific problems with what they've slurred as a "zip drive" approach. Offering a self-backup option would be more competitive than Signal's current nothing at all – which means total data loss on any device loss or upgrade, for iOS users. Absolutely, promise users a Signal-quality cloud experience, someday, when this novel development is finished, and when there's an economic model for reliably storing users' opaque data in the cloud – and if users trust Intel SGX. But in the indefinitely-long meantime, why deny users the proven & well-worn path of self-data management? (And shouldn't users have the right to an exportable format of their own contact/messaging data?)

ENOTTY 7y ago

It's not clear to me how the nodes authenticate a new node on node replacement. They say that the nodes check the new node's MRENCLAVE value, so what happens if there is a software update and the MRENCLAVE value has to change? How do the old nodes know what the new MRENCLAVE value should be?

genpfault 7y ago

Is this going to make app backup/restore even more torturous? I already almost got bit by the transition to the current magic number + special in-app export, vs. the previously-working Titanium Backup APK + data snapshot method.

ggm 7y ago

This is inherently good in itself. But, I ask myself if the oft- requested 'can we be people without phone # in signal' is now actually a deliverable, or if they only stated it in hypothesis, and still don't have that as a roadmap outcome? I want to have two (or more) non-phone enabled devices able to be in signal. My tablet, and my computer. I realize there are adjunct methods, but depending on a physically present device to have one thing hooked up isn't actually what we want here, the phone is not a useful second factor, its a hack I believe they worked out to get beyond the 'must be a phone' state without having to re-engineer the back end. So: do we now get phone-less signal identity? This feels like a precursor. Does that definitionally say phone-less identity will follow? (again only from belief, I believe the secure enclave on the phone is bound into identity along with the IDD, so having a secure enclave backed in the cloud breaks one of the two dependencies out a bit)

Vinnl 7y ago
I don't think it would make sense for them to now state that they're going to deliver that no matter what, because then 1. You're going to have people asking for timelines on that even more often than people are currently asking for non-phone number authentication, and if you indulge them, they're going to get angry with you for missing it. 2. Who knows what other problems might turn up when implementing it. I'd expect them to announce it very close to it being actually possible. Until then, we'll probably only hear about individual problems they solved on the road to there.
codethief 7y ago
It looks like they're working on usernames but, apparently, you'll still need a phone number to sign up: https://community.signalusers.org/t/signal-introducing-usernames/9157 https://community.signalusers.org/t/signal-introducing-usern...

jtolds 7y ago

I'm very puzzled by the consensus group load balancing section. The article emphasizes correctness of the Raft algorithm was super important (to the point that they skipped clear optimizations!!11), but, then immediately follows up with (as far as I can tell) a load-balancer wrapper approach for rebalancing and scaling. My "this feels like consensus bug city" detectors immediately went off. Consensus algorithms (including Raft and Paxos) are notoriously picky and hard to get right around cluster membership changes. If you try to end run around this by sharding to different clusters with a simple traffic director to choose which cluster, how does the traffic director achieve consensus with the clusters that the traffic is going to the right cluster? You haven't solved any consensus problem, you've just moved it to your load balancers. A solution for this problem (to agree on which cluster the data is owned by) is 2-phase commit on top of the consensus clusters. It didn't appear from the diagrams that that's what they did here, so either I missed something, or this wouldn't pass a Jepsen test. Did I miss something? [If you did build 2PC on top of these consensus clusters, you'd have built a significant portion of Spanner's architecture inside of a secure enclave. That's hilarious.]