The compliance standard is the ISO 27002 (http://www.iso27001security.com/html/27002.html), specifically under the two sub-sections: "Access
Control" and "Business continuity management". Note that ISO27002 is an abstract
framework, the company then has to implement concrete policies ("key rotation every 24 months") and that too you don't have to implement every recommendation. It's like the Food pyramid - you won't die if you deviate 1:1; but it's a good recommendation
to stick to.
That's what is driving the key rotation concern. I agree that key rotation is a painful problem to solve. Right now our policy is to take databases offline and re-encrypt. An 'online' method would be great. From the top of my head, one could have a KeyVersion
in the crypto metadata to divide all entities into "encrypted with old key" and "already encrypted with new key" space and avoid the cleartext database altogether. To revert back to a fully unencrypted database (if divorcing SecurEntity)
you could have the target encryption as "DoNothing" after decrypting the cipher text off old key.
Regarding integrity checks, it's best to use an authenticated-encryption (AE) modes like GCM or OCB. Generic information about the class of crypto algorithms is at (http://blog.cryptographyengineering.com/2012/05/how-to-choose-authenticated-encryption.html).
AE modes like GCM or OCB are basically new modes (just older CBC) of using existing symmetric ciphers (like AES128) underneath. The good thing is you get data privacy (traditional encryption) + data integrity (HMAC) all in one operation. So a single IV, single
key with double advantage. This means your crypto metadata can drop by 50%!
AE modes are NIST approved and OCB recently (2 weeks back) dropped it's licensing terms to much simpler ones (http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm). On the flip side, these are relatively newer, so fewer implementations out there. I think Microsoft
hasn't implemented a .NET version and there is a library out there that implements OCB (http://www.bouncycastle.org/csharp/index.html).
It's not "my project" but I would add the following 3 items (in decreasing priority)
- Supporting database first model in a documented manner ("you must have a column of type X defined in the table and supply the name of the column to SecurEntities on dB context initialization. All your secure tables must use the same column name you
provide. blah blah")
- Solve the key rotation / 'return database to clear state' problem transparently
- move to AE ciphers
PS: TomJones: "Compromised certs are handled in the usual PKI way (revocation & reissue)". That's fine. For PKI. But for SecurEntity, because of the way it's hardwired into the heart of the certificate, ANY new certificate resets
the masterKey for SecurEntity because it is aesKey = rsaSign(sha512(certificatePublicKey | certificatePublicName)). With your master key reset, how would you
plan on avoiding the decrypt=> encrypt cycle? SecurEntity doesn't really see the KI in PKI, it only consumes the certificate as a bucket of bits for entropy that's used as the key.