[cryptography] Keyspace: client-side encryption for key/value stores

Tony Arcieri tony.arcieri at gmail.com
Thu Mar 21 02:52:42 EDT 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130320/78836585/attachment.html>


More information about the cryptography mailing list