2
$\begingroup$

I'm currently working on a proposal for some secure complete system and one of the things currently lacking is the database security.
However I don't want to roll my own crypto there and thereby need a secure, somewhat reviewed / standard way to cryptographically secure the databases. I had a look at CryptDB for this but it lacks authentication which I consider needed and I couldn't easily find out what ZeroDB provides except "end-to-end" encryption.

What is the best cryptography based database currently specified / available?

My definition of "best" in this case: Provides authenticity and secrecy (most important), provides integrity over the whole database (no silent dropping of data), leaks as less information to the server as possible, doesn't have to hide access patterns, allows for complex (cryptographically enforced) access rules.

It can be assumed that the clients do use / own public / private key pairs and / or passwords and everyone without valid keys is considered an adversary to the data he doesn't have access to, i.e. attackers may not undetected modify, add or drop data or being able to read the data if they have compromised everything except the client.

The server should hold the only copy of the database and should not have to give it out (due to size) if possible. As for the API, more standard APIs (SQL?) are preferred but custom ones are also acceptable as long as they support the usual queries (like ZeroDB and CryptDB do).

$\endgroup$
  • $\begingroup$ What kind of API should the server offer to clients? Do clients download a copy of the database and perform operations locally, with the server only helping with synchronization? $\endgroup$ – CodesInChaos Dec 23 '15 at 10:33
  • $\begingroup$ There is an extension for SQLite providing encrypted storage. That wat you keep the database tot an single file and have an SQL interface. Soms Android applications use this to secure their local storage. $\endgroup$ – Yorick de Wid Dec 23 '15 at 18:56
  • $\begingroup$ What about running your favourite DB on a hardware-encrypted hdd? $\endgroup$ – marstato Dec 24 '15 at 22:59
  • $\begingroup$ @marstato, I'm looking for something at DB level if possible, as I consider this to be superior to transparent encryption (i.e. run it inside an encrypted container). If there exists no good solution I'll go for ZeroDB or CryptDB and I'll probably put them into an encrypted container. $\endgroup$ – SEJPM Dec 25 '15 at 11:14
  • $\begingroup$ @YorickdeWid, so this is something like transparent encryption (but a bit better than container based)? I'm rather looking for something with more granularity . $\endgroup$ – SEJPM Dec 25 '15 at 11:17
4
$\begingroup$

Reading your message, we (in ZeroDB) realize that we need to add some things to our documentation.

Provides authenticity and secrecy (most important)

That one we do have now

provides integrity over the whole database (no silent dropping of data)

We pretty much have it at the level ZODB we base on has (ACID-compliant)

leaks as less information to the server as possible, doesn't have to hide access patterns

We don't leak properties of encrypted data like CryptDB, but we do slowly leak access patterns. Seems suitable for you

allows for complex (cryptographically enforced) access rules

In the version currently on github, access rules are pretty simple (users own their sub-databases, but there are also "admin" users). We have a version with proxy re-encryption and possibility to grant/revoke access in end-to-end encrypted manner, in a granular way (column and row-based).

It can be assumed that the clients do use / own public / private key pairs and / or passwords and everyone without valid keys is considered an adversary to the data he doesn't have access to, i.e. attackers may not undetected modify, add or drop data or being able to read the data if they have compromised everything except the client.

In current implementation, clients by default have their private keys derived from passphrases (trivial to add a possibility to use certificates though). Attackers may not modify or add data, though we need to add some extra protection against dropping data (detecting that an attacker removed piece of your data is possible but currently would take a while).

The server should hold the only copy of the database and should not have to give it out (due to size) if possible.

This is how it works in ZeroDB

As for the API, more standard APIs (SQL?) are preferred but custom ones are also acceptable as long as they support the usual queries (like ZeroDB and CryptDB do).

Seems like you're quite familiar with our query language :-) In future, we're going to add SQL compatibility since many people ask for that. May I ask: what types of queries do you need?

And yeah.. Merry Christmas :-)

$\endgroup$
  • $\begingroup$ Curious if you have any third party security analysis done ? or your technology published in some conference for review $\endgroup$ – sashank Feb 16 '16 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.