Phillip Hallam-Baker's Web Security Blog

Yesterday we observed that all our requirements could be met by S/MIME encryption if we applied it to disk storage instead of email transport. What does that mean in practice and how might such a system meet the 'zero overhead' requirement?

Lets start by imagining the process from the point where a consumer buys or an employee is issued a new machine.

Logging in for the first time and starting up the word processor, the new employee is informed that her employer has a security policy for document management that she is required to make herself aware of and that documents created using the built in document templates will be automatically managed under one of those policies. If she creates a document in the 'company confidential' template it will be encrypted by default and can only be exchanged with other employees and with people outside the organization under specified conditions.

How did this information arrive? In the enterprise the security policy may be picked up from the corporate DNS, LDAP directory or pushed out to the client machine as application configuration data. In the small business or consumer environment the user is going to have to make the decision to 'turn on' content level encryption.

But regardless of the environment the user should not be required to manage credentials or be aware that they exist at all except to the extent that this becomes necessary in the consumer case where the consumer is in effect their own system administrator and needs to be 'in the loop' to take meaningful key management decisions.

Let us bracket the consumer conversation for the time being and concentrate on the enterprise.

Let us stipulate that enterprise IT have purchased some number of 'key management' applicances, racked and installed them and created directory entries to announce their presence (e.g. DNS SRV records). Let us further stipulate that the trust chain this process may be adequately secured and anchored to some ubiquitous trust point (e.g. via DNSSEC).

The first problem we face is key management. We have two basic requirements:

• Decrypt documents intended for this user to read on this machine
• Enable a key management infrastructure to grant read access to other parties as determined by policy

The first choice concerns the user key. Should the user have one key that is shared between machines or a different key for each machine? I prefer an architecture that allows us to insist that each key is known in exactly one place and nowhere else. That means treating the problem of transferring data from one machine to another in exactly the same way that we treat transfering data from one user to another. It may make for somewhat more work but it is surely the right approach.

The next consideration is whether we should employ key escrow. But key escrow requires us to break the principle that each key appear in exactly one place and requires us to think about escrow protocols. Worse, key escrow creates a situation where a critical security consideration relies on the correct execution of a little exercised exception condition. As someone who recently spent a week rebuilding the RAID array on my home machine, I would like to eliminate such dependencies wherever possible.

A simpler means of meeting the same need is to require encrypted data to contain a decryption block for the key server in addition to whatever local keys might be required. This approach was applied in an early version of PGP. This has the additional advantage that it greatly simplifies the design of the key server as it only needs to keep track of one keypair for the system rather than a separate keypair for each individual user.

So to recap:

• The CLE system is built into every application that is to read or write the protected content.
• On first startup the application is able to obtain the site security policy by a trustworthy, automated means. As a minimum the site security policty states that content level encryption should be turned on.
• On first startup an encryption pair is generated for each machine-user combination.
• We do not perform key escrow, instead we require each encrypted data packet to contain decryption blocks for the key management server

So much for configuration. Next week we should be in a position to actually encrypt some data.