5 ms·

"If Amazon faced a subpoena that required it to keep the order secret, such encryption would be useful to customers. “If the data is encrypted, all we’d be hand

"If Amazon faced a subpoena that required it to keep the order secret, such encryption would be useful to customers. “If the data is encrypted, all we’d be handing over would be the cypher text,” he said." That strikes me as a little misleading. I'm sure the subpoena would request a snapshot of all running VMs's memory & CPU state, from which (I believe) it's relatively easy to extract encryption keys. If the first subpoena didn't, the second one sure would!

dchichkov 13y ago
And I'm sure there would be a third one, stating that it is necessary to keep the warrant canary alive and chirping ;)
- Crito 13y ago
  Where is their warrant canary located?
  - graue 13y ago
    I don't think they have one. The only one I know is rsync.net's: http://www.rsync.net/resources/notices/canary.txt http://www.rsync.net/resources/notices/canary.txt
rdl 13y ago
The terrifying thing is that they could be required to keep doing this in the background indefinitely, compromising both all the data and any future users -- sort of like the Hushmail compromise. Using AWS the way cpercival does for tarsnap (with keys managed outside, and S3 as dumb storage) is reasonable. Using AWS to run a game or other toy app is reasonable. Using AWS if you yourself are a USG entity (and thus immune to lesser legal action) is fine. I can't imagine using AWS (or any outsourced cloud provider) to run sensitive apps using current EC2-type technology in the current legal climate in the US. The other scary thing is AWS is probably among the best providers for technical security, and still has this vulnerability (disclaimer: I haven't yet checked out Google Cloud Engine much). Colocation or managed hosting is borderline in some situations too (particularly if you allow the provider unlimited access to singleuser mode on your boxes, don't encrypt drives, manage keys and credentials through the provider, etc.), but it's a lot better than virtual hosting for anything at all sensitive. It's not just official USG action to fear; it's provider staff or technical compromise as well.
- ra 13y ago
  > sort of like the Hushmail compromise That's interesting. I couldn't find anything that describes the hushmail compromise in this way. Do you have a link that explains it? (Am currently thinking about how to make a more secure email service)
  - rdl 13y ago
    Hushmail had you log in with u/p first, then would serve an applet, which would then download your encrypted private key and you'd decrypt it locally. They used your public key to encrypt incoming mail and store it until you wanted to log in to view it (which is a fundamentally reasonable approach; the problem is compatibility with existing mail clients, and search, but you can solve that by downloading to a local mail client using something "special" and running search locally as well.) The enemy made Hushmail serve a "bad" applet to certain users which (in addition to decrypting) sent back either credentials or key to hushmail (and thus allowed decrypting of the mail). There are ways to address this attack but they're essentially in the realm of release engineering and separation of control; you have one group develop, another group serve, another group execute, and the groups have to be mutually distrustful and audit everything that passes between them. This is hard. The irony is I worked for the company which developed the initial hushmail product back in 1998/1999. It had to be done by non-US Citizens due to export control, so I wasn't involved, but pretty much as soon as it was clear they weren't going to address this (obvious) attack in their threat model, I assumed they were either incredibly incompetent or an active honeypot, so I ceased any involvement and never used the product. (an adequate solution for java applets would have been putting the signing key under neutral third-party control; I don't think a java applet based solution is viable today, since java is such a clusterfuck; I'd just do a secure iOS or Android app instead and stick to mobile users, like silenttext does from silentcircle). I'd personally skip webmail or even desktopmail and just build something which is mobile-secure-mail/messages/voice. Silentcircle is my favorite voice product right now, but it's fundamentally doomed (IMO) due to being commercial on both sides. I'd want something where at most one party in every communication is a paid user, and the counterparty uses a free and lightweight app. And/or something with great group management functionality, which it also doesn't do. The market for discrete individuals who both pay for the service and only communicate with other discrete disconnected individuals is kind of zero.
gulfie 13y ago
It could be worse. They could assume control of the VMs run them for a while. ( http://www.sfgate.com/local/article/FBI-shared-child-porn-to-nab-pedophiles-4552044.php http://www.sfgate.com/local/article/FBI-shared-child-porn-to... ) Could the FEDs incentivize AWS to be quite about it? I'd guess yes.

dchichkov 13y ago

And I'm sure there would be a third one, stating that it is necessary to keep the warrant canary alive and chirping ;)

Crito 13y ago
Where is their warrant canary located?
- graue 13y ago
  I don't think they have one. The only one I know is rsync.net's: http://www.rsync.net/resources/notices/canary.txt http://www.rsync.net/resources/notices/canary.txt

rdl 13y ago

The terrifying thing is that they could be required to keep doing this in the background indefinitely, compromising both all the data and any future users -- sort of like the Hushmail compromise. Using AWS the way cpercival does for tarsnap (with keys managed outside, and S3 as dumb storage) is reasonable. Using AWS to run a game or other toy app is reasonable. Using AWS if you yourself are a USG entity (and thus immune to lesser legal action) is fine. I can't imagine using AWS (or any outsourced cloud provider) to run sensitive apps using current EC2-type technology in the current legal climate in the US. The other scary thing is AWS is probably among the best providers for technical security, and still has this vulnerability (disclaimer: I haven't yet checked out Google Cloud Engine much). Colocation or managed hosting is borderline in some situations too (particularly if you allow the provider unlimited access to singleuser mode on your boxes, don't encrypt drives, manage keys and credentials through the provider, etc.), but it's a lot better than virtual hosting for anything at all sensitive. It's not just official USG action to fear; it's provider staff or technical compromise as well.

ra 13y ago
> sort of like the Hushmail compromise That's interesting. I couldn't find anything that describes the hushmail compromise in this way. Do you have a link that explains it? (Am currently thinking about how to make a more secure email service)
- rdl 13y ago
  Hushmail had you log in with u/p first, then would serve an applet, which would then download your encrypted private key and you'd decrypt it locally. They used your public key to encrypt incoming mail and store it until you wanted to log in to view it (which is a fundamentally reasonable approach; the problem is compatibility with existing mail clients, and search, but you can solve that by downloading to a local mail client using something "special" and running search locally as well.) The enemy made Hushmail serve a "bad" applet to certain users which (in addition to decrypting) sent back either credentials or key to hushmail (and thus allowed decrypting of the mail). There are ways to address this attack but they're essentially in the realm of release engineering and separation of control; you have one group develop, another group serve, another group execute, and the groups have to be mutually distrustful and audit everything that passes between them. This is hard. The irony is I worked for the company which developed the initial hushmail product back in 1998/1999. It had to be done by non-US Citizens due to export control, so I wasn't involved, but pretty much as soon as it was clear they weren't going to address this (obvious) attack in their threat model, I assumed they were either incredibly incompetent or an active honeypot, so I ceased any involvement and never used the product. (an adequate solution for java applets would have been putting the signing key under neutral third-party control; I don't think a java applet based solution is viable today, since java is such a clusterfuck; I'd just do a secure iOS or Android app instead and stick to mobile users, like silenttext does from silentcircle). I'd personally skip webmail or even desktopmail and just build something which is mobile-secure-mail/messages/voice. Silentcircle is my favorite voice product right now, but it's fundamentally doomed (IMO) due to being commercial on both sides. I'd want something where at most one party in every communication is a paid user, and the counterparty uses a free and lightweight app. And/or something with great group management functionality, which it also doesn't do. The market for discrete individuals who both pay for the service and only communicate with other discrete disconnected individuals is kind of zero.

gulfie 13y ago

It could be worse. They could assume control of the VMs run them for a while. ( http://www.sfgate.com/local/article/FBI-shared-child-porn-to-nab-pedophiles-4552044.php http://www.sfgate.com/local/article/FBI-shared-child-porn-to... ) Could the FEDs incentivize AWS to be quite about it? I'd guess yes.