[cryptography] Keyspace: client-side encryption for key/value stores
https://github.com/livingsocial/keyspace tl;dr: Keyspace provides least authority client-side encryption for key/value stores using NaCl's crypto_secretbox (XSalsa20 + Poly1305) and Ed25519 as part of a capability-based security model. One problem I've dealt with quite frequently when deploying web applications is how to keep sensitive configuration files (e.g. database credentials) secret. I've longed for a system that provides end-to-end confidentiality and data integrity. I think a reasonable goal is to never store secrets on disk in plaintext form, and try to isolate all secret management to the heap of the process in question. It's not perfect, and an attacker could still get keys out of RAM, but it's certainly better than plaintext on disk guarded by file permissions alone, which is the status quo as far as I can tell. I originally developed my project Keyspace as a sort of software key manager, an alternative to Chef's Encrypted Data Bags which were one of the few other solutions I knew of at the time except for Zookeeper .The Chef solution does not authenticate the ciphertexts, something I wasn't really happy with. Keyspace is also designed so that all encryption happens client-side. The server knows no keys except a public Ed25519 key which is tied to each vault and is used to verify that incoming ciphertexts are authentic. Each ciphertext is signed along with a plaintext timestamp which the server can use to prevent replays of old ciphertexts (coming soon! ;) If implemented correctly, an attacker can compromise the credential server and not be able to read the credentials or alter the system configuration. The more I hacked on Keyspace, the more I realized it's useful for more than just storing a handful of credentials. It provides a full-fledged backend independent client-side encryption model any key/value store which is supported by the underlying libraries. The storage backend is built on Moneta (https://github.com/minad/moneta), an abstract API for key/value stores, and therefore supports a number of SQL and NoSQL databases as backends, including all SQL databases supported by ActiveRecord, Redis, Riak, Cassandra, CouchDB, and MongoDB, among others. This should make it quite easy to persist encrypted data to whatever backend you wish, with minimal attack surface since the data being persisted is ciphertext before it even hits the wire. Keyspace borrows heavily on Tahoe-LAFS's idea of controlling access using crypto capabilities, and separates access into write capability (can publish new data), read capability (can read existing data), and verify capability (can determine ciphertexts are authentic, but can't read them). A question about crypto-capabilities is: how do you share them securely? Fortunately I think a system like Keyspace can bootstrap itself, providing a vault per user which stores the capabilities they have access to. NaCl's Crypto::Box can be used to allow users to publish public keys they can give to a system administrator who can then give them an encrypted capability to their user-specific capability vault. I'd also eventually like to implement a client-side cache which can be used to mitigate DoS attacks by taking the server down, and also identify replay attacks when an attacker in control of the Keyspace server attempts to publish a ciphertext older than what's in the local client cache. Anyway, have a look, I'd love some feedback ;) -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Keyspace: client-side encryption for key/value stores
On Thu, Mar 21, 2013 at 2:52 AM, Tony Arcieri tony.arci...@gmail.com wrote: https://github.com/livingsocial/keyspace tl;dr: Keyspace provides least authority client-side encryption for key/value stores using NaCl's crypto_secretbox (XSalsa20 + Poly1305) and Ed25519 as part of a capability-based security model. One problem I've dealt with quite frequently when deploying web applications is how to keep sensitive configuration files (e.g. database credentials) secret. I've longed for a system that provides end-to-end confidentiality and data integrity. I think a reasonable goal is to never store secrets on disk in plaintext form, and try to isolate all secret management to the heap of the process in question. It's not perfect, and an attacker could still get keys out of RAM, but it's certainly better than plaintext on disk guarded by file permissions alone, which is the status quo as far as I can tell. On Windows and Apple platforms, one usually defers to the OS. For Windows, you would use the Data Protection API (DPAPI) (http://msdn.microsoft.com/en-us/library/ms995355.aspx). For Apple, you would use a Keychain (https://developer.apple.com/library/mac/#documentation/security/Reference/keychainservices/Reference/reference.html). Android 4.0 and above also offer a Keychain (http://developer.android.com/reference/android/security/KeyChain.html). If using a lesser version, use a Keystore (http://developer.android.com/reference/java/security/KeyStore.html). Some of Apple's Keychains appear to be broken at the moment, so its hit or miss whether the secret is actually protected. Confer: http://lists.apple.com/archives/apple-cdsa/2013/Mar/msg00038.html and http://lists.apple.com/archives/apple-cdsa/2013/Mar/index.html. Linux has not warmed up to the fact that userland needs help in storing secrets from the OS. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Keyspace: client-side encryption for key/value stores
Keyspace is a bit different from an OS keychain in that it's a networked system, designed to be centrally managed by the holders of a writecap, accessed by holders of the readcap, and with the verifycap on the server to determine the authenticity of values published by administrators with writecaps. My initial (and continued) goal is to use it to centrally manage secure configuration data, but again, I think it's generally applicable as client-side security for distributed key/value databases. That definitely transcends whatever secure key storage an OS provides for a single node. On Thu, Mar 21, 2013 at 12:07 AM, Jeffrey Walton noloa...@gmail.com wrote: On Thu, Mar 21, 2013 at 2:52 AM, Tony Arcieri tony.arci...@gmail.com wrote: https://github.com/livingsocial/keyspace tl;dr: Keyspace provides least authority client-side encryption for key/value stores using NaCl's crypto_secretbox (XSalsa20 + Poly1305) and Ed25519 as part of a capability-based security model. One problem I've dealt with quite frequently when deploying web applications is how to keep sensitive configuration files (e.g. database credentials) secret. I've longed for a system that provides end-to-end confidentiality and data integrity. I think a reasonable goal is to never store secrets on disk in plaintext form, and try to isolate all secret management to the heap of the process in question. It's not perfect, and an attacker could still get keys out of RAM, but it's certainly better than plaintext on disk guarded by file permissions alone, which is the status quo as far as I can tell. On Windows and Apple platforms, one usually defers to the OS. For Windows, you would use the Data Protection API (DPAPI) (http://msdn.microsoft.com/en-us/library/ms995355.aspx). For Apple, you would use a Keychain ( https://developer.apple.com/library/mac/#documentation/security/Reference/keychainservices/Reference/reference.html ). Android 4.0 and above also offer a Keychain (http://developer.android.com/reference/android/security/KeyChain.html). If using a lesser version, use a Keystore (http://developer.android.com/reference/java/security/KeyStore.html). Some of Apple's Keychains appear to be broken at the moment, so its hit or miss whether the secret is actually protected. Confer: http://lists.apple.com/archives/apple-cdsa/2013/Mar/msg00038.html and http://lists.apple.com/archives/apple-cdsa/2013/Mar/index.html. Linux has not warmed up to the fact that userland needs help in storing secrets from the OS. Jeff -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Keyspace: client-side encryption for key/value stores
Jeffrey Walton noloa...@gmail.com writes: Android 4.0 and above also offer a Keychain ( http://developer.android.com/reference/android/security/KeyChain.html). If using a lesser version, use a Keystore ( http://developer.android.com/reference/java/security/KeyStore.html). What Android gives you is pretty rudimentary, it barely qualifies to use the same designation as Apple's Keychain. Linux has not warmed up to the fact that userland needs help in storing secrets from the OS. There's KWallet and Gnome Keyring, last time I looked KWallet was also pretty primitive (about the level of Android's Keychain) and not being updated much, but the Gnome Keyring seems to be actively updated. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Keyspace: client-side encryption for key/value stores
On 21/03/13 09:52 AM, Tony Arcieri wrote: https://github.com/livingsocial/keyspace tl;dr: Keyspace provides least authority client-side encryption for key/value stores using NaCl's crypto_secretbox (XSalsa20 + Poly1305) and Ed25519 as part of a capability-based security model. ... A question about crypto-capabilities is: how do you share them securely? Using a crypto-capability for secure sharing. Which leads to a boot-strapping problem, of course, but that's part of the fun. A partial answer from capabilities is found in YURLs which are URLs that can't be futzed with by an attacker. But this still doesn't solve the issue of who you send them too... The high-level helicopter answer is that you bootstrap relationships into key exchanges [0], and the hidden assumption here is that you have relationships of some form, which means you are now in application space -- the market area -- not in systems space. Fortunately I think a system like Keyspace can bootstrap itself, providing a vault per user which stores the capabilities they have access to. NaCl's Crypto::Box can be used to allow users to publish public keys they can give to a system administrator who can then give them an encrypted capability to their user-specific capability vault. In terms of server - user path, the authentication finding mechanism is generally interrelated. You typically need to start from some well known and self-authenticating mechanism which is sometimes called a root. Some examples: websites are found by the DNS system which root is built into the net stack, secure websites are authenticated by a root inside the browser that overlays the DNS system. In my Ricardo system, the root is a financial instrument that you've found from some trading partner which points to the managing server. For S/MIME it is necessary to use a corporate server of some form to keep keys fresh. What is happening here is that you are leaving the strong crypto area and entering into the weak/vague/untethered world of user marketing. In this area you have to look at your chosen market space and leverage the relationships that already exist. For this reason, in order to do this successfully, you must already have chosen a market space. Systems like PGP try to do it without choosing their market space (and going user - user with no servers). Hence, to use PGP, they have a particular thing called a PGP key signing party which is a generic one-size-suits-all way to create those paths. It works, but it is not patterned after any particular trading patterns, so it doesn't work well enough. Reflections of this are found in Zooko's Triangle: There is no way to create a cryptographically secure, global and human-memorable identifier. To square the triangle, you need to be in application space, so that you can bootstrap relationships into key exchanges. iang [0] http://iang.org/ssl/h2_divide_and_conquer.html#h2.5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Keyspace: client-side encryption for key/value stores
On 21/03/13 10:07 AM, Jeffrey Walton wrote: On Thu, Mar 21, 2013 at 2:52 AM, Tony Arcieri tony.arci...@gmail.com wrote: https://github.com/livingsocial/keyspace tl;dr: Keyspace provides least authority client-side encryption for key/value stores using NaCl's crypto_secretbox (XSalsa20 + Poly1305) and Ed25519 as part of a capability-based security model. One problem I've dealt with quite frequently when deploying web applications is how to keep sensitive configuration files (e.g. database credentials) secret. I've longed for a system that provides end-to-end confidentiality and data integrity. I think a reasonable goal is to never store secrets on disk in plaintext form, and try to isolate all secret management to the heap of the process in question. It's not perfect, and an attacker could still get keys out of RAM, but it's certainly better than plaintext on disk guarded by file permissions alone, which is the status quo as far as I can tell. On Windows and Apple platforms, one usually defers to the OS. To play the devil's advocate, this is only a partial solution, and I wonder why so many developers 'defer' so easily? Using the OS secrets store has a number of drawbacks: 1. what happens when you lose the laptop? 2. what happens when the OS store gets updated and a bug loses your data? 3. what happens when you need to use two platforms? A phone and a laptop? Or, any combination where there is incompatibility, impedance or absence? 4. what happens when your enemy has insiders inside the OS provider? 5. what happens when your app wants to store something that the OS store can't handle? As an application provider, you may find that it is easy enough to use the OS store, if you can afford to support all the platforms. But if something goes wrong, you're still on the hook. No customer of your application really cares what the excuse is, they want their data back. Now, for my money, any application that has already developed a great crypto security set can probably more easily do the primary secret storing itself better and more cost-effectively (measured in code time) than by using the OS store. And, in the process, it can provide the user's backup context... Linux has not warmed up to the fact that userland needs help in storing secrets from the OS. :) A singular observation. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Keyspace: client-side encryption for key/value stores
Peter Gutmann wrote: Jeffrey Walton noloa...@gmail.com writes: Android 4.0 and above also offer a Keychain ( http://developer.android.com/reference/android/security/KeyChain.html). If using a lesser version, use a Keystore ( http://developer.android.com/reference/java/security/KeyStore.html). What Android gives you is pretty rudimentary, it barely qualifies to use the same designation as Apple's Keychain. Linux has not warmed up to the fact that userland needs help in storing secrets from the OS. There's KWallet and Gnome Keyring, last time I looked KWallet was also pretty primitive (about the level of Android's Keychain) and not being updated much, but the Gnome Keyring seems to be actively updated. I would say these things (I hesitate to qualify them as IT security mechanisms or schemes) address an impossible task, for which apparent success is possible only in a proprietary environment (just making the reverse engineering harder). Client-side storage of long-term secrets can only be secured by dedicated client-side hardware. Your mileage may vary. - Thierry ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] List test
___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Keyspace: client-side encryption for key/value stores
On 2013-03-21 5:59 PM, ianG wrote: On 21/03/13 09:52 AM, Tony Arcieri wrote: A question about crypto-capabilities is: how do you share them securely? Using a crypto-capability for secure sharing. Which leads to a boot-strapping problem, of course, but that's part of the fun. A partial answer from capabilities is found in YURLs which are URLs that can't be futzed with by an attacker. But this still doesn't solve the issue of who you send them too... The high-level helicopter answer is that you bootstrap relationships into key exchanges [0], and the hidden assumption here is that you have relationships of some form, which means you are now in application space -- the market area -- not in systems space. Or to say the same thing in different words, UI is the hard part of crypto, and usually the place where the holes are. Zooko's triangle is a system level description of a user interface. In terms of server - user path, the authentication finding mechanism is generally interrelated. You typically need to start from some well known and self-authenticating mechanism which is sometimes called a root. Otherwise known as a single point of failure. Let us imagine that browsers supported yurls, and that links in advertisements and business pages were usually yurls, with the result that your bookmarks were usually yurls. And, let us imagine that email and im addresses were also yurls, and usually to be found in web pages themselves secured by yurls, with the result that the from address on email was unforgeable, that a from address was also a link to the one true home page corresponding to that email address. Then any web page identified by yurl and containing yurls would have the functionality of a certificate, rendering certificates as such irrelevant. The entire web would largely consist of certificates, and search engines would be certificate servers. The downside would be that secure email addresses and yurls would be impossible to communicate over the phone, or in non web advertisements, thus people would tend to default to insecure mode, and could thus easily be suckered into using insecure mode To leverage from insecure mode to secure mode, one needs a preshared secret, which only the highly motivated will bother with. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
