In Part 1 I talked about the ready reversibility of application encryption. At the root of that problem is how encryption keys are managed. In most applications, encryption keys must be readily available so the application can decrypt and encrypt any of its data at any moment. When this availability is combined with a successful spear phishing attack on an administrator, it is only a matter time before any or all application data is decrypted and exfiltrated.
In direct contrast, DAE defends much more effectively against this threat scenario. Black hats can have complete run of your infrastructure and yet still not be able to decrypt sensitive data. DAE achieves this with a trade-off: ready accessibility vs. encryption durability.
While typical application level encryption stores a handful of encryption keys in config files or HSM modules and uses them in different functional areas of the application and database, DAE manages one encryption key per user. This means that, rather than organizing encryption by functional or database area (for instance, by protecting all Social Security Numbers in the app or targeting columns of a particular table), encryption is organized and employed on a per-user basis.
When a user is added to the system, a random encryption key (the User Master Key) is generated for that particular user by the server. This User Master Key is used to reversibly encrypt and decrypt any sensitive data related to that user. When the User Master Key is at rest, it is encrypted with the User Session Key. The User Session Key is derived from the user's plaintext password when it is presented during account creation or later during sign-in.
Operationally, the User Master Key is “unlocked” whenever a user signs in. During sign-in, the user presents their plain text password to the server, the server generates the User Session Key and decrypts the User Master Key. At this point the User Master Key is now encrypted with an Application Master Key (which itself is stored in a config file) and stored as an Unlocked Session Cookie in the user’s web session. The User Master Key is now “unlocked” while the plain text password and the User Session Key are discarded.
Each time a user makes a request to the server, the user’s session provides the Unlocked Session Cookie with the request. If access to that user’s encrypted data is needed, the server can decrypt the Unlocked Session Cookie with the Application Master Key to get the User Master Key. The User Master Key can then be used to encrypt or decrypt the relevant user data. When the request is completed, the User Master Key is discarded. When the user’s sign-in session ends, the Unlocked Session Cookie is removed from the session.
The following diagram goes into these scenarios in greater detail.
In Part 3 we’ll discuss the pros, cons and other implications of DAE.