Phillip Hallam-Baker's Web Security Blog

The launch of Mozilla Prism has many people thinking about the possibilities of Site-Specific browsers. With many applications such as GMail and Google Documents being packaged up as hosted Web applications today, a site specific browser provides a quck and easy means of making a network application look just like a local applications. User Interface components designed to support browsing such as the address bar, bookmarks and such are unnecessary clutter and the forward/back buttons a positive hazzard when using a Web application.

Site specific browsers are also a useful security tool, particularly when setting up a browser environment for use by a three year old girl who wants to visit the 'Dora the Explorer' game on the Web. A site specific browser allows an account to be created that can access precisely the sites that are age appropriate. This is as much a usability issue as a security issue, avoiding the situation where the mouse clicks on the wrong thing causing another site to load, ruining the game.

Making the browser site-specific is certainly one means of achieving the 'secure browsing mode' that many banks have been asking for, But users have enough trouble downloading an installing one browser. How can they be expected to download, install and maintain a different site specific browser for each bank and brokerage they might use (I have two of each plus a 401K retirement fund and a life assurance policy making six in all).

A recent paper by D.K. Smetters and Paul Stewart suggests a neat solution to the problem. In their scheme, a user is told to access security sensitive sites from a 'secure launchbar' that causes a site specific browser to be launched in a separate process. Instead of having to have a different site-specific application for each bank, all we need is a site-specific secure bookmark.

Clearly, for such a scheme to be trustworthy, the secure bookmarks must be limited to trustworthy sites. Smetters and Stewart suggest various means of achieving this, but I am sure nobody will be surprised to learn that Exetended Validation certificates with embedded subject logos (aka Secure Internet Letterhead) would be my choice.

To complete such a scheme, agreement would be necessary on a standard set of capabilities for 'secure-site-specific' browsers. Traditional W3C specifications describe the features that MUST be supported. This specification would also need to specify which features MUST NOT be specified. Or at least provide the launch bar application with a means of specifying the features to be activated in the site-specific browser. Cross-site scripting attacks have much less power when the user is accessing a site with plug-in extensions disabled and no ability to follow links that lead off-site.

Posted by Phillip Hallam-Baker at 5:51 AM | Permalink | Comments (0)

We have one remaining issue to consider but it is probably the most difficult of all: deployment.

Designing and building software is easy. Establishing a critical mass of users is the hard part.

At this point we need to go back and consider what advantages CLE provides that existing schemes such as whole disk encryption or directory level encryption do not. In my view the answer is that storage level encryption can provide security when used correctly, CLE makes it much harder to make the type of mistake that can lead to a breach. Whole disk encryption is good but it only works as long as the authorized user does not copy the data to a USB thumb drive. Directory level encryption is even more fragile and can fail when an application unexpectedly makes a copy of the sensitive data in an unencrypted location.

A part of any CLE deployment strategy must be developing programming toolkits that allow an existing application to be CLE enabled with minimal effort. One of the reasons that SSL has become so popular is the fact that by design the API for SSL toolkits look almost identical to the traditional BSD socket API.

We have most of the PKI infrastructure required to support CLE. All we are missing at this point is the key management server. If we are going to make CLE a reality though we need to establish a critical mass of applications.

Although I have focused on the 'network CLE' problem, this is in fact a superset of the single user CLE problem and even applied at the single user level, CLE provides considerable value. I would like to be able to copy files to a USB thumb drive without worrying about creating copies of possibly confidential information.

Ubiquitous deployment of CLE will take many years, perhaps a decade or more. But in the meantime niche deployment of CLE can address the most difficult, highest risk activities.

For example, the typical data breach occurs when an auditor loses a laptop or thumb drive containing sensitive personnel data. Why is it always an auditor? Possibly because they are the only people who confess. But regardless, deployment of CLE to every desktop in an enterprise is hard. Integrating CLE into the export function of the HR database and insisting that the auditor install an open standards based plug-in into their spreadsheet is much easier.

Another area that might be the killer application of CLE that creates the necessary critical mass is CAD/CAM. A large part of the CAD/CAM market is involved in classified government work or designs that are commercially sensitive and unlike the office applications market, the market for CAD/CAM applications is fiercely competitive.

Posted by Phillip Hallam-Baker at 6:33 AM | Permalink | Comments (0)

My original expectation in starting this series is that it would be done in three posts. It is almost two weeks later and we are still going.

At this point the technology described is adequate to meet the original use cases. This is the point at which protocol design traditionally stops. But in the new security model this is the point where the really difficult work starts: usability.

If a CLE system is going to be any use it is going to have to be used and it is not going to be used unless use is effortless [Is zero-effort security a better tag line for what I am attempting to achieve than Zero-overhead?].

To make CLE effortless, it must be possible for system administrators to take on all the heavy lifting required for configuration and the impact on day to day use must be negligible except in the exceptional case where the user is actually focused on the specific issue of security.

What this means in my view is that the CLE system needs to be tightly integrated into the applications that create CLE controlled content. The application must be able to determine the security policy to be employed from the document template used to create the document. The application must be able to seamlessly acquire rights to content when the user attempts to open the file.

At the same time we should probably consider the document storage lifecycle as a whole and come to terms with the fact that the Xerox Parc files and folders paradigm is simply not working any more.

Files and folders were a sensible method of organizing content when we had one machine that we used exclusively for editing documents and managing data. Today I use at least two computers every day, three if you count the iPhone and every one of them doubles as a communication device. That puts valuable work product documents at risk of compromise by network applications.

What I would prefer is to completely isolate by network interaction workflow from my document editing workflow. Or at the very least isloate them to the greatest degree possible. When I save a document I want it to be stored in my virtual document repository in the cloud and I want to be able to access it from any computer I might work on later.

The Xerox Parc files and folders approach treats the local storage on my laptop as a disk drive for primary storage of files and folders. This is a problematic approach with any laptop if you frequently switch between laptop and desktop machines. It is particularly problematic if you have a MacBook Air and have to live inside an 80Gb drive.

A better approach is to treat the local storage on the machine as a cache for the main storage in-the cloud. Windows Vista attempts to do this to some extent with its replication feature, but that particular interface is broken as it attempts to adapt the files and folders approach rather than reinvent the underlying concept.

Posted by Phillip Hallam-Baker at 6:05 AM | Permalink | Comments (0)

Last time we stopped with Alice wanting to share a confidential document with Carol who works in a different company. Why would Alice want to do this, if a document is confidential it should not leave the company, right?

Looking at my own use of company confidential documents, the exact reverse is applied. In fact as a general rule virtually every document that I handle that is company confidential is also going to be shared outside the company by virtue of its intended function. Patent applications must be shared with outside counsel, responses to customer RFPs must be shared with the customer.

There are of course some company confidential documents that should never be shared outside the enterprise, but these are rather less likely to result in immediate catastrophic damage if disclosed. I would not want an outsider to know the exact configuration of my internal networks or have access to the ATLAS source. But the consequences of unintended disclosure are unlikely to be as severe as disclosure of a bid submitted to a customer.

My point here is that if we are going to produce a Content Level Encryption infrastructure that is going to meet real needs we need to design it to allow it to cross organizational trust boundaries from the start, not as an afterthought.

The first and most important constraint that this places on our design is that there is no value to a CLE scheme unless it is built on open, unencumbered standards. A clever scheme encumbered by patents is less likely to be of utility than a simpler scheme based on older technology. To do that we need to ideally work with technologies that are described in patents that have either expired already or are close to expiry.

Next we have to consider the security concerns of the receiving organization as opposed to Carol. Traditional PKI architectures focus on Alice and Carol as if they are the ultimate decision makers. But when Alice and Carol work for different companies we are dealing with four parties, not just two. The sending organization wants to be able to assure itself that it is willing to disclose the information, the recipient organization needs to be able to assure itself that it wishes to accept responsibility for accepting the data, to check that it is not contaminated by malware, that it is not unintended spam and so on.

End to end security still matters of course, but there are four ends to this communication, not just two. If we are to meet the real end-to-end security requirements it must be possible for the sending and receiving organizations to scan the messages on their incoming and outgoing messaging gateways.

What this means, is that the sending gateway needs to decide whether the content of the file is data that it wishes to release to the recipient organization. Depending on the security policy governing the data this may mean checking that an NDA has been registered with the recipient organization.

The sending gateway then needs to obtain the encryption key of the recipient organization, create the corresponding decryption block and pass the data along. On receipt the recipient must determine if the content is acceptable and if so create the necessary decryption block for Carol.

Posted by Phillip Hallam-Baker at 5:19 AM | Permalink | Comments (0)

So Alice has saved her encrypted Word document. How does she read the document on the same machine, a different machine or share a copy with Bob?

Reading the document on the machine used to create it is straightforward. By default the document is saved with a decryption block for the machine-user key and a decryption block for the key management system. The application simply requests that the cryptography sub-system decrypt the decryption block under the machine-user key.

Reading the document on a different machine requires a little more effort. When Alice attempts to open the file the application will need to identify the security policy under which the document is controlled and forward the decryption block to the key management server which must securely determine the security policy to be applied, evaluate the access control request and return either a decryption block for the new machine-user key or a refusal response.

If Alice is going to make a habit of using the same document on multiple machines it may be appropriate to create decryption blocks for each of the machine-users that may require access. Contrawise, if the document is very sensitive it may be desirable to only create a decryption block for the key management server and not for the local user-machine key. This approach may be appropriate where the machine in question is a laptop and there is a possibility of it being carried through customs. If a document is extremely sensitive it might not be readable on the laptop at all.

The same principles may be extended to allow Bob to read the file and we can even automatically create a decryption block for Bob and Carol if there is an expectation that there will be a need to read the data on those machines as well.

If Bob is in the same organization as Alice there really is no difference. But if Alice wants to share the document with Carol who works for another company we need to deal with the fact that we are crossing a trust boundary and that has consequences that may be very significant indeed.

Posted by Phillip Hallam-Baker at 1:06 PM | Permalink | Comments (0)

Continuing our series on content level encryption we are finally in a position where we can encrypt something. How does the user go about this?

If we want the user to actually use encryption on a regular basis, the answer is going to have to be that the user will have to do as little as is possible, ideally nothing whatsoever.

Ideally we would want the security policy to be inferred automatically from the user's normal workflow. If the user starts a new document using the 'Company Confidential' template this should automatically cause the appropriate security policy to be set for that document, including causing the document to be saved in encrypted form by default.

DRM schemes typically take the view that in order to talk about security policy it is necessary to have a language to express the security policy that is understood by every potential policy enforcement point. This then segues into a highly proprietary policy descruiption language and an equally proprietary mechanism for distribution of the same.

But CLE is not DRM and since the type of control we wish to provide involves distributing confidential documents to typically tens, rarely hundreds and very exceptionally thousands of recipients we do not need to make every potential document reader a policy enforcement point. Accordingly we have no requirement to standardize the policy description langauge or to distribute it amongst the policy enforcement points.

We do however have a requirement to be able to reference the security policy description so as to allow statements of the form 'this content is to be controlled under the X security policy',

Fortunately this is where the World Wide Web comes to the rescue. A security policy is just a resource like any other and is thus described by means of a URI.

For example, BizyBank might have the following security policies defined:

http://secpolicy.bizybank.com/confidential

Company confidential, document may only be circulated inside the company or with outside partners under a specified NDA

http://secpolicy.bizybank.com/unrestricted

The document may be shared without restriction

http://secpolicy.bizybank.com/executive

The document may only be read by the author and the executive team

http://secpolicy.bizybank.com/customer

The document an only be read by the author and the specified customer

In each case the summary descriptions of the security policies omit a great deal of detail that becomes essential in a real-world situation. In practice, every document is in the final analysis property of the company rather the individual and there will be a need for exceptions and for processes to manage the exceptions.

There would also be a need for security policy to be considered as an aspect of the overall document process model. In most cases 'public' is a property that a document will only achieve at the end of its development lifecylce, if ever. In the typical case a document intended for publication will begin life as a confidential document, undergo a process of editing and internal review. If management of the security policy is to be transparent it must be driven by the processes that support the review cycle.

From this we may deduce that in the enterprise a document should be encrypted by default and that it is the conversion to enclair that should require affirmative intervention.

But this conclusion is not the same as saying that by default a document should be considered company confidential. On the contrary, if we are to take company confidential status seriously we must accept that this entails considerations of process.

When Alice creates a new document in Word or OpenOffice the default should be that the document file created be encrypted with decryption blocks for Alice and the key management system and giving Alice complete control over who is granted read access.

A stricter security is only required if Alice is in a position of specific responsibility that requires greater control or explicitly selects a particular security policy (e.g. by selecting a specific document template). Contrawise, if Alice wishes to save the document without encryption she must make an explicit decision to do so.

By default the files are protected against the primary negligence risks identified at the start of this series. The files saved to disk can be safely exchanged via email or USB thumdrive without concern.

Protected content may be flagged to advise applications that they should not allow the user to change the security policy under which they are controlled but we do not insist on the implementation of an infrastructure to ensure compliance. As with paper documents, an authorized reader may defect but this requires an intentional act such as disabling the malware scanner on the machine or loading a deliberately compromised application.

What we have not done so far is to allow Alice to share the file with anyone other than herself. That is the next step.

Posted by Phillip Hallam-Baker at 12:06 PM | Permalink | Comments (0)

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.

Posted by Phillip Hallam-Baker at 11:07 AM | Permalink | Comments (1)

Having set out our objectives and in particular our non-objectives it is finally time to start thinking about the technology. In particular the use cases we are going to meet.

Less is more, and not just because certain parites have attempted to create a thicket of IPR covering all and every application of DRM. The fact is that complexity only rarely provides functionality. If a feature is too complex for the typical user to use it might as well be avoided.

Traditional security use case analysis has tended to revolve around attacks. That is important of course but it tends to drive us towards a mode of thinking where the user is primarily focused on thwarting the attack rather than their actual job.

The use cases then should be simple:

• Alice creates a confidential file
• Alice wishes to share her confidential file with Bob
• Alice wishes to share her confidential file with Carol who works for a different company
• Alice wishes to share her confidential file with anyone authorized to do so under an enterprise specified security policy
• Alice has a large number of confidential files to manage and wishes to define a security policy of her own
• Alice looses her access credentials and wishes to regain access to all her confidential files

What is striking about these particular use cases is that practically all of them fall within the exsiting scope of S/MIME if we make one simple change: Apply S/MIME to disk storage rather than email transport. More on that tommorow.

Posted by Phillip Hallam-Baker at 10:46 AM | Permalink | Comments (0)

Having decided yesterday to focus on the problem of preventing the unintentional disclosure allows us to avoid a large number of issues that are certainly intractable without trustworthy hardware and quite probably intractable in any case:

Consider the commonly occuring use case for DRM: Alice and Bob are doctors, Alice sends confidential patient records to Bob who may make use of them himself but must not forward them to Ingrid the insurer.

Designing a system that makes it impossible for Bob to forward the records is a very hard problem. We can imagine any number of ways in which Bob might subvert his personal computer to provide access to an unrestricted copy of the information. And even if the possibility of application tampering, malware or the like are excluded, preventing Bob from printing out the data or using hardware screen capture requires a whole additional level of trustworthy hardware which can in any case be circumvented through use of a digital camera.

But in most cases Bob is not the enemy. Designing a system for Bob to use every day that is proof against attack by Bob is a very hard problem. But designing a system that makes it difficult for Bob to disclose the data unintentionally is much easier.

Rather than preventing Bob from disclosing the record to Ingrid, we would like to achieve the same level of security that is afforded by use of paper records: We will attempt to prevent unintentional disclosure and attempt to mitigate intentional disclosure but accept the fact that we cannot provide an absolute guarantee that Bob will not disclose the records without insisting on security measures that Alice and Bob are both likely to find intollerable.

Posted by Phillip Hallam-Baker at 10:26 AM | Permalink | Comments (0)

So lets start thinking about the basic requirements for confidentiality in the workplace. In particular let us consider the principal causes of unintended disclosure:

1. Failure to delete data stored on decommissioned drives
2. Lost or stolen USB drives
3. Lost or stolen laptops
4. Compromised machines
5. Unintended disclosure through email forwarding
6. Malicious employees

We have no means of accurately evaluating the relative importance of these factors in actual attacks. While conventional wisdom holds that '60%' of all attacks come from within the enterprise the evidence for this claim appears to be anecdotal and is almost certainly out of date in any case.

Now that Internet crime is professional, the traditional approach to risk evaluation must be abandonded. It no longer makes sense to ask what the 'probability of loss' will be. The probability of loss will be close to one if an attacker realizes a means of making a profit from an attack and close to zero otherwise.

As the adverts say: past results are no guarantee of future performance. The rate of loss from any given cause is going to depend on the ability of an attacker to make a profit. This argues for the external threat facilitated by internal negligence being the primary concern as that is the type of attack that the professional crime rings are going to invest their research dollars in facilitating.

We conclude therefore that intentional malpractice by employees is certainly a cause of unintentional disclosure, it is not the only cause and almost certainly not the most serious cause. Any employee can be careless but only a small number are actually corrupt.

And regardless of whether intentional disclosure is the most serious cause or not, it is certainly a substantial cause that deserves attention in its own right regardless of whether the much harder problem of dealling with the malicious employee is to be addressed.

Posted by Phillip Hallam-Baker at 8:15 AM | Permalink | Comments (0)

Some years ago at the height of the crypto-wars the FBI argued that commercial implementations of PKI would need escrow. Opponents of Freeh's proposals argued against this notion at the time. It was several years after US government restrictions on export of strong cryptography were lifted that key escrow was accepted as a genuine requirement: Nobody wants to tell the CEO that the loss of their private key means that documents they stored on their hard drive are irrecoverable.

For some years I have been arguing that a similar situation applies to deployment of DRM techniques. It is obvious to me that if the CFO creates a highly confidential financial analysis in an Excell spreadsheet that the data should be stored in encrypted form throughout its life cycle. And applying the end-to-end doctrine to this approach leads us naturally to an architecture where the document file itself is encrypted.

And here we come to the impasse where people start leaping up and down and screaming their heads off about the MPAA and the RIAA as if the primary purpose of a security mechanism should be to thwart the advocates of the copyright industry rather than a potential attacker. And then we have people screaming that 'DRM cannot possibly work', that it 'has been proven not to work' and it becomes very difficult to have a rational debate.

Which is a pity because having considered the real needs of content level encryption (CLE), I think that there is another parallel to the key-escrow debate: The requirements that lead to the controversy have little or nothing to do with the requirements of enterprise security.

The particular step that gave rise to controversy in the key escrow debate was the point where the FBI received a copy of the key. The particular point which appears to raise controversy in the DRM debate is the employment of trusted hardware, in particular trusted hardware that limits the control of the owner.

This is an important debate and Zittran makes a compelling argument in 'The Future of the Internet' that deserves serious attention. But there is absolutely no reason that security need be incompatible with 'generativity'.

The fact is that most enterprise confidentiality requirements can be solved without recourse to secure hardware at all. The only case in which secure hardware is essential is if we cannot trust either the user of the machine or the machine itself.

So over the course of this week I am going to be posting an alternative view of content level encryption, one that is narrowly tailored to the most urgent enterprise security needs and involves the absolute bare minimum of new infrastructure.

Posted by Phillip Hallam-Baker at 7:46 AM | Permalink | Comments (0)