Rethinking stored document encryption: Part 7
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.
