Hi,

Am Donnerstag, 9. Juni 2011 schrieb Justin Scott:

talking about java garbage collection: the garbage collector copies
long-lived objects between heap regions during their lifetime
(see http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
for a detailed explanation). So zeroing over the data will not
really help (but doesn't hurt, of course).

Also, if you're planning a clustered application with session
replication you'll be transmitting the unprotected keys across
your intra-cluster-network.

Bye,
Peter

Peter Conrad
Tivano Software GmbH
Bahnhofstr. 18
63263 Neu-Isenburg
Tel: 06102 / 8099070
Fax: 06102 / 8099071
HRB 11680, AG Offenbach/Main
Geschäftsführer: Martin Apel

Hi,

An alternative you could consider is to have the client generate the
encryption key during account setup, and for this never to leave the
client. They encrypt everything before it goes to your server, and
decrypt it when it comes back. In this case they are (almost) completely
protected against a server compromise. However, it would stop your
server being able to do any processing of that data.

With the scheme you propose, a dedicated attacker could sit quietly on
the compromised server, and record encryption keys as they are used -
eventually being able to access all the client data.

Some would argue that the encryption key file is still "something they
know". But either way, this is certainly stronger than single-factor
authentication.

An arrangement somewhat similar to what I propose is used by Firefox
Sync, but for different reasons. It's primarily intended as a privacy
mechanism - so the servers never see your browsing data. The protection
against server compromise is somewhat incidental. Apart from that, this
isn't an arrangement I've seen in any production system. I suggest you
think carefully - and ideally produce a written risk assessment - about
how sensitive your data really is. Most organisations are happy with
HTTPS encryption for data in transit, and for particularly sensitive
data, full disk encryption of data at rest. Key management for these
scenarios is well understood.

Regards,

Paul

--
Pentest - When a tick in the box is not enough

Paul Johnston - IT Security Consultant / Tiger SST
Pentest Limited - ISO 9001 (cert 16055) / ISO 27001 (cert 558982)

Office: +44 (0) 161 233 0100
Mobile: +44 (0) 7817 219 072

Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
Registered Number: 4217114 England & Wales
Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK

I agree to points by Paul.

In my view there are things to answer.

• Does your application need to decrypt the data from the database and
  show it onto the web application: If No, then what you are looking at is Pre
  Internet Encryption (PIE) where your client is just using you as a data
  store. In this case you don't need to do lot of things and follow as Paul
  mentions above.
• If you need to decrypt the data that comes from the client then, i
  don't see a reason why they have to encrypt and send to you, and also share
  the key. I would rather take the data and encrypt it myself before it goes
  in the database.

I would say that if you want to do any kind of encryption/decryption your
side, you should consider using HSM and let it do the task of managing the
keys and encrypt/decrypt. This will isolate tasks and not do everything on
one server.

I am not a sales guy for SafeNet, but I have seen this getting used in some
places.

http://www.safenet-inc.com/products/data-protection/hardware-security-modules-hsms/

Gautam

On Fri, Jun 10, 2011 at 1:55 AM, Paul Johnston
paul.johnston@pentest.co.ukwrote:

--

Regards,

Gautam

Yes, though we only need access to the data while their session is
open.  Once they log out (or time out) we no longer need access to the
data or the encryption key.  In our current proposed model we store
the data, encrypted, in a local database accessible to the web server
and have the user provide the key at the start of their session so we
can access their data.

The user is only providing the key, we would be encrypting and
decrypting on our end.  The transport between the web browser and web
server would be protected by standard SSL.

That would certainly be a more standard solution, and one that we
proposed to the client.  Their concern is that if we store both the
encryption keys (even in a key management system or other device or
server) and the encrypted data, and an attacker were able to
compromise the server, they could simply run code which would feed the
encrypted data through the key manager and run away with the results
fairly quickly.  Having the user store and provide their own key file
helps to further mitigate that risk.  Someone pointed out that an
attacker could sit quietly on the server and do the same thing as the
sessions were opened and closed, but it would be less exposure than if
we did have the data and keys accessible to the application at all
times.

-Justin Scott

IMHO, data encryption at rest is best accomplished between the
application and data tier. Generally speaking, passing an encryption
key to the client isn't a good idea. Relying on the client side at all
to protect the integrity of data (or encryption keys) is just bad
form. So the data should be encrypted at the application before it
gets to the database, and decrypted at the application before it goes
to the client. Then use standard SSL/TLS to protect the data in
transit. The database information is now secure and you only need to
protect the encryption keys at the application layer - which is a
completely different conversation...

Kevin

On 6/10/11, Paul Johnston paul.johnston@pentest.co.uk wrote:

--
Kevin G. Stewart

Precisely, their proposed model does exactly what you said, and their
method for storing the keys is, well, not to store them; just pass the
key off to the end-user and have them keep it stored on their end and
provide them to the application when needed.  The people who want the
application built are very risk-averse and don't trust the keys to be
stored anywhere that the server/application/staff has direct access to
them.  Personally, I'd prefer a more standard key management system
but the thought of us even having both the encrypted data and the keys
makes the business very, very nervous.  Eventually the data and keys
have to come together, so there is always some risk, they just want it
to be as reduced as possible and still get the application built.

-Justin

Since this is for a high-assurance/low-risk app....

The only slight risk with this mechanism (if it is a Java system)  is
how little you can depend on garbage collection. The other problem
involves strings getting stored in the JVM string pool for a
non-deterministic amount of time. You may want to do your crypto
operations in a separate process that kills the JVM right after each
individual crypto action.

• Jim