Recognizing that there is a great deal of concern of storing sensitive data in the cloud and having it accessible to hackers, the NSA, industrial espionage, etc. Microsoft has invested significant efforts to offer (to be launched in July) in a complete encrypted storage offering for Office 365 and One Drive. This is in addition to the platform level security features already in Office 365.
Fort Knox is Microsoft’s encrypted storage offering for Office 365. Microsoft has published some additional technical details in one of their SharePoint conference sessions. The video for this session is here. Here are the key technical details.
Fort Knox is like Remote Blob Storage
SharePoint has supported storage of content outside the default SQL server based content database since SharePoint 2010. Fort Knox takes a similar approach but improves on the architecture.
Files are stored encrypted in Azure Blob storage transparently to the end user accessing the file from SharePoint.
Fort Knox is Highly Fragmented by Design for Security and Performance
When a Fort Knox file is stored in Azure, it is split in several fragments. Each fragment is encrypted (using AES 256 bits encryption) with its own key. Each of these fragments are stored in separate Azure containers that are generated on demand.
This shredding architecture allows for massive scalability of storage and more importantly, very strong security at the file level. Imagine the challenge of having to reconstruct a set of fragments spread across dozens of containers, each encrypted with its own key.
These keys are also regenerated every day, making it even more difficult to gain access to the raw storage.
A master key is used to encrypt keys used to encrypted each of the fragments. These encrypted keys are stored in the content database, and the master key is stored in a separate key store.
Fort Knox’s Achilles Heal: The Master Key?
With a master key stored online in Microsoft’s key store, this still allows someone with access to this master key to decrypt all the fragment keys and then use these keys to decrypt the underlying storage. This is less of an issue for a hacker scenario (although possible, given the level of fragmentation between tiers tougher to accomplish) but more of an issue of an NSA style “request” for your data. Assuming Microsoft were to comply with the request, they could ultimately still provide them access to your master key and decrypt the information.
The only real solution is to have master keys generated off the grid so that they could not be requested at all and not be in your cloud providers hands to hand over on request…however this would be difficult to implement and still have a useable business productivity portal because you would still need the master key to decrypt the files.
