In Part 1 we discussed the problem of reversible application encryption, and, in Part 2, we presented the details of Distributed Application Encryption (DAE), a proposed approach for application-level encryption designed for our current security environment. In Part 3, we cover the pros, cons, and other implications of DAE.
- Encryption Diversity – each user has their own encryption key for their own sensitive data. In order to obtain all data in plaintext, you need to gain access to each and every user’s unencrypted User Master Key. Put another way, cracking the key for one user doesn’t affect the security of another user’s sensitive data.
- Narrow Vulnerability Windows – the User Master Key is only exposed during user requests. Likewise, the Unlocked Session Cookie only exists while the user is logged in.
- Geographic Diversity – Unlocked Session Cookies are stored with users’ web sessions, not on the server. An attempt to collect them on demand would require attacking many different users devices simultaneously.
- Restricted Attack Scenarios – Most attack scenarios involve modifying an application to collect plaintext information. Under DAE, an attack of this type would expose only those user accounts accessed from the point the attack begins until it is finally discovered. Theft of an entire database in plaintext form at any particular point in time would be impossible.
- Transparency and Accountability – Applications that need to access sensitive data must request that users return to the application, establish a session, and make a request to provide the needed Unlocked Session Cookie. This provides transparency for users as to how their sensitive data is being handled, as well as creating an implied-approval process of that handling for the application provider.
- DAE is dependent on a plaintext password sign-in mechanism in order to unlock data.
- Applications implementing DAE are susceptible to code-modification attacks in which surreptitious collection of User Master Keys is added in the request path.
Regardless of the technical pros and cons, adopting DAE imposes a new paradigm for managing sensitive data – a paradigm that requires fundamentally rethinking how applications handle sensitive data.
Applications Should Only “Borrow" Sensitive Data
The new paradigm can be summed up as follows: a DAE application neither owns nor has free access to sensitive data it collects from its users; it must always ask for and be granted that access. To benefit from DAE, application designers and implementers must embrace this principle and implement it elegantly and thoroughly.
A real-world analog to DAE is a safe-deposit box at your local bank. You store valuables in it, and neither you nor the bank can access its contents without mutual coordination (barring court orders, thievery, etc.). This mutual coordination is guaranteed via an access system requiring two keys – yours and the bank's – to unlock the safe-deposit box.
This parallel also highlights the major drawback: valuables are less accessible for both the user and the bank.
For some applications and some types of sensitive data, converting to this information-management system would be simple. For instance, a doctor’s office rarely needs a patient’s Social Security number. Storing it and requesting access to it via DAE seems reasonable for both doctor and patients.
But imagine a financial application that handles sensitive data like account numbers. Many types of transactions (interest accrual, check clearing, bill pay, direct deposit) would prove cumbersome if each required an access request to the customer. There will likely need to be per-user, per-application, and even per-industry analyses and standards establishment as to what is treated as “sensitive data” in a DAE architecture.
DAE variants are also a possibility. Users could grant temporary server-side storage of their Unlocked Session Cookies in order to handle batch and other types of autonomous processing. Application designers might unlock sensitive data and temporarily store it in plaintext for batch processing runs. There are bound to be many other variations possible.
It’s a Process, Not an Event
This series of posts was not intended to define and promote DAE itself. DAE is merely a useful vehicle for defining and promoting the paradigm shift it represents. The real measure of DAE's worth will be apparent in how this paradigm shift is regarded and incorporated into application design in general. While this discussion has assumed a web application environment, the techniques described could apply in many scenarios.
Reasonable technical minds can differ on what exact form the paradigm shift should take. But one fact none can deny is that, as each new data breach makes headlines, it becomes ever more painfully obvious that our current approaches aren’t working.