The Towelie Encryption Principle

Ok, I made them up, but I think they are useful ways of thinking about encryption, someone else may have also made them up, but mine are better branded :)

There is a lot of talk about mass encryption these days, notebook encryption, Vista BitLocker, native SQL 2005 row level encryption, nearly everything supporting SSL, IPSec etc. Many people seem to misunderstand what encryption buys you, and that depending on the level at which it is implemented, has certain exposures that may conflict with the requirement for encryption.

As for a justification, it may be best to start with some examples. If you are trying to decide on sub-OS or OS-level hard drive encryption for your mobile users, many have argued for full disk encryption (even Gartner). However, sub-OS full disk encryption would expose data to administrators with rights to the machine, anyone with access to open shares exposing the data etc. However, OS aware encryption could enforce authorisation defined by the OS and could prevent administrators from accessing the data or users accessing an open share from reading the data in addition to the protection sub-OS full disk encryption would provide i.e. preventing low level reads of the hard drive exposing the data.

By an application stack, I mean the following:

1. Application
2. Database
3. Operating Systems
4. Hardware

Thus, when deciding where to place the encryption start at the top, and move down once possibilities have been eliminated. For example, if the application can't implement the required encryption, do it at the database level. The only caveat is that if the data you want to encrypt doesn't reside at a tier, then the top can move, for example, if you want to encrypt the page/swap file, the application and database tiers don't exist. The principle was named as such after the "Wanna get high", Towelie character from South Park.

A nice way to think about encryption, is to imagine it as enforcing authorisation. For example, current permission systems e.g. file system/table ACLs, security groups etc. can usually be bypassed by accessing the data at a level lower that they are enforced. For example, if you want to get around database permissions, just copy the file in which the database stores the data, or even lower, do a low level read of the hard drive. With encryption, the enforcement of the ACLs can be down at each tier below the tier at which they are defined. In fact, we need a new catchy phrase for this effect ... ladies and gentlemen, the underground fortress effect.