cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: cayenne-crypto
Date Mon, 07 Apr 2014 08:42:27 GMT
I can’t “name names”, but I can answer in general terms. This is to protect sensitive
business data. Not (yet) about any specific gov. compliance. This protects pieces of data
against DBA’s, QA and developers who have legitimate access to production DB and its backups.
As well as hackers who may steal such a backup from someone’s laptop.

The app server will keep unencrypted data in memory, so hacking an appserver and taking a
memory dump will leak some of the data. With default KeySource it will also reveal the key.
A more secure version (certificate-based logins?) might keep user-specific keys in a session,
reducing the attack time window. This improvement may also serve as an authorization tool
- different users have different keys, so they can only decrypt the data they are authorized
for.

> Are you seeing the AES encryption performance to be symmetrical between select and insert?

Meaning the speed of encryption vs. decryption? Will need to check. I only did a combined
test now. But I suspect both will be of the same order.

Andrus



On Apr 7, 2014, at 11:14 AM, Aristedes Maniatis <ari@maniatis.org> wrote:
> Out of curiosity, if you can discuss, what are you using this for? Is this some sort
of PCI DSS compliance, or privacy or health? Do you get any real security (since all the objects
must exist in plain text everywhere between Cayenne/html rendering engine/servlets/container/proxy
until the SSL layer kicks in). Or is this to prevent the DBA from poking their nose where
it should not be?
> 
> Are you seeing the AES encryption performance to be symmetrical between select and insert?
> 
> 
> Ari
> 
> 
> On 7/04/2014 4:56pm, Andrus Adamchik wrote:
>> Also some early performance data. In my tests with a local DB and a mix of select/insert
operations using AES with 128-bit key wasn’t noticeably slower than using no encryption
at all. Using 256-bit key resulted in 10% overhead. While these are great results, take it
with a grain of salt for now until we get more use cases and start using it in production.
>> 
>> Andrus
>> 
>> 
>> On Apr 4, 2014, at 3:21 PM, Andrus Adamchik <andrus@objectstyle.org> wrote:
>> 
>>> So the crypto module is done and available on trunk. Here is a minimal configuration
that will do AES/CBC encryption:
>>> 
>>> 1. Create a keystore and generate a secret key in it:
>>> 
>>> keytool -genseckey -keystore /tmp/ks1.jceks -storetype JCEKS -alias mykey
>>> 
>>> 2. Start Cayenne with crypto:
>>> 
>>> // this can also be a URL or a String representing URL
>>> File keyStore = new File("/tmp/ks1.jceks”); 
>>> 
>>> // obtain this somehow
>>> char[] keyPassword = .. 
>>> 
>>> // “mykey” is the key alias in #1
>>> Module crypto = new CryptoModuleBuilder().keyStore(keyStore, keyPassword, “mykey").build();
>>> 
>>> // this will enable encryption/decryption for all columns matching ^CRYPTO_ regex
>>> // those must be either character or binary columns
>>> ServerRuntime  runtime = new ServerRuntime(“cayenne-myproject.xml", crypto);
>>> 
>>> 
>>> So just 3 lines of code give you the encryption. Of course it is fully customizable.
See ‘CryptoModuleBuilder’ for what can be extended. Also the code is pretty raw, so it
may break or may be refactored as we find bugs. I still need to study the performance and
tweak as needed. Also there are certain strategies are not yet available. E.g. we only support
block ciphers in CBC mode (as this is what I am planning to use in my apps). We will add support
for ECB and also streaming ciphers eventually.
>>> 
>>> But … everyone is free to give it a try ;) 
>>> 
>>> Andrus
>>> 
>>> 
>> 
> 
> -- 
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> 


Mime
View raw message