Re^2: Effective database column level encryption?

During my trial implementation with DBIx::Class::EncodedColumn::Crypt::OpenPGP i've hit on a notion regarding key storage which I'm wary of being security theatre and/or reinventing a wheel and would appreciate some guidance.

Context wise I'm working towards a VPS in a 3rd part data center installation where security is more important than uptime. It's based in Switzerland but that's no reason to be complacent.

Since shared secrets can be stored in a .pm, is there any particular reason said .pm should not be stored on some seperate machine and downloaded, loaded and deleted at initial run time when the system resides in a persistent execution environment e.g. Catalyst? If the key host is switched on solely when the system is manually started I don't see how it would be possible to access the secrets barring physical access to the server and data recovery tools. Furthermore, if this is a good idea someone more experienced than I has surely done it already.

Thoughts?

Comment on Re^2: Effective database column level encryption?

Replies are listed 'Best First'.
Re^3: Effective database column level encryption? by Corion (Patriarch) on Dec 02, 2015 at 12:24 UTC
If this is run within a VPS, you must also trust the VPS provider and the supervisor OS not to have backdoors/faults like Xen and others had discovered recently. If your attacker can become `root` on your VPS, they can also "simply" extract the key by reading the memory of your process: `open my $process, '<', "/proc/$apache/mem"; binmode $process; binmode STDOUT; print $_ while <$process>;` [download] But unless you can store the key on a hardened USB encryption/decryption device and perform decryption on that device, having the key only in memory reduces the attack surface a lot. Your attacker has to attack the live machine(s) instead of for example attacking a backup tape.	[reply] [d/l] [select]
Re^3: Effective database column level encryption? by SimonPratt (Friar) on Dec 02, 2015 at 16:49 UTC
I agree with Corion's comments. I would lean more towards using a tokenisation system (especially if dealing with CC details). I also would not download, load and delete a pm file in the manner you suggest. What I would do is make a fast API interface available on that separate machine. This allows you to tightly restrict access and upgrade your secrets easily (or even implement a completely different system, maybe even to provide one-time secrets), along with giving you some additional logging abilities that loading a pm wouldn't necessarily allow. Imagine if you know that when someone does x on your website that it causes a, b and c to happen, which generates 2 requests to your secrets API. Now if your logging detects that someone doing x has actually generated 4 requests to your secrets API, you've just identified a possible intrusion and you can do something about it before too many customers are potentially compromised.	[reply]
Re^3: Effective database column level encryption? by dallen16 (Sexton) on Dec 03, 2015 at 16:46 UTC
I think what you're getting at is key exchange... secure methods to exchange secret keys. There are well defined solutions but they may fall into your "wary of being security theatre". In general, look at Internet Key Exchange Key exchange works using a key management server. To your need, an authorized consumer of the encrypted data would need to establish a security association with the key management server to gain access to the secret key needed to decrypt the data. You might want to look at Cyrpt::DH or Cyrpt::PK::DH. On CPAN, search for "diffie-hellman".	[reply]