Protecting “Cloud” Secrets With Grendel by Sam Quigley (Square, Inc) and Coda Hale (Yammer, Inc.)
Everyone stores private data. Passwords, credit cards, documents, etc. But also personal conversations, personal histories, usage patternns – that’s all private too. So you store private info – yes you – so how do you protect it? Firewalls and VPNs? Passwords? Bah. They are useful against last decade’s attacks.
Application level attacks are the new hotness – see the OWASP Top 10. What you want to do is encryption. But that’s complex. Veracode has analyzed a lot of apps and crypto problems are the #1 problem.
What do we do? Here’s some ideas.
Grendel
It is a secure document storage system. Open and does minimal/simple. It does data storage, authentication, and access control using the OpenPGP message format and a RESTful interface, it’s in Java, and uses a normal DB backend.
OpenPGP – mature, flexible. It’s for confidentiality and integrity. It uses asymmetric keys. The keys are stored encrypted with passphrases. The keys are used to encrypt documents to one or more recipients.
REST API – http native. Why REST? For all the reasons everyone uses REST. Ubiquitous, well understood, simple, easily debugged (charles), free features.
Java 1.6 + RDBMS. Java because it’s fast and stable and well understood. Uses hibernate. RDBMS because you already have one.
Grendel is simple. One config file. DB location and password and some c3p0 stuff.
java -jar grendel.jar schema -c database.properties
generates a schema. Three tables; users, documents, and links.
java -jar grendel.jar server -c database.properties -p 8080
starts it.
The API has users, docs, links, and linked docs. JSON based.
You can create a user, which makes a new key set behind the scenes.
You can store a document. PUT /users/name/documents/docname with a basic auth header. It decrypts the user’s keys, signs and encrypts the doc, and stores it.
GET /users/name/documents gets you a JSON list. Or get the document and you get the document (duh).
Then you can link the document to another user to share it with them.
So what’s the big deal?
Self defending data. The data itself enforces the access control rules. And business logic is enforced with math.
He didn’t even mention the brilliance of this related to scenarios like things like subpoenas causing Amazon to give up your S3 data to people…
Authentication done right. It’s hard to do it right. Adaptive hashing. A centralized service model. Resistant to modern attacks.
It makes it “sudo for the Web.” You can grant long lived session coolies, and re-auth for privileged access. Yeah, we do that in general not with encryption… Like Amazon.com remembers you but when it’s purchase time you have to reauth securely.
It also mitigates XSS/CSRF attacks, kinda.
This creates a privacy wall. You the admin are locked out of the data. Insider threat defeated.
In the future…
Support for sessions. OAuth 2.0. And spreading the idea in general!
How is this better than symmetric encryption with the user’s password? Since you’re proxying it anywhere. Because you can’t share then.
I guess one downside is that you can’t see inside the docs to search index, etc.
You could use client side certs instead of passwords right? No.
Does it have support for password change? Yes.
I personally am psyched about this – I think we have a product underway that could really benefit from using it.
the agile admin 