CryptoCollaboration Version Alpha Released

Encryption while by all popular means with collaboration systems remains a somewhat esoteric subject, is nonetheless crucial for maintaining privacy, security, and data integrity. While the native SharePoint security functions do indeed provide some level of these concepts, it is limited in the sense that it is tailored around hiding items that you don’t have appropriate rights to, for most organizations this layer is simply not enough because the data still exists in a poolable format.

Typically industrial strength privacy collaboration environments generally instead require that an encryption solution be in place to couple appropriately with native security functions so as to ensure that the data itself remains unreadable to certain users. This is the purpose of CryptoCollaboration.

I have recently published the deployable project on CodePlex, at the following location:

It has already gone through one quick revision through the MVP group that gave me some good feedback regarding the interface and some brief functionality. If you want to see what the application itself looks like, you can view some brief screen shots on the CodePlex site.

Anyways, I feel like I have done enough typing about this project for the time being, so I will let the CodePlex site do the talking. If you have any suggestions, I would love to hear them. I am currently recording them on the issues list on CodePlex.


Caveats of Protecting Your SharePoint Environment with Microsoft Data Protection Manager

* This article was written in the context of System Center Data Protection Manager 2006 (SCDPM), a technology now considered deprecated with the introduction of System Center Data Protection Manager 2007. Variations may exist. *
Caveats of Protecting Your SharePoint Environment with Microsoft Data Protection Manager 
There are certain caveats that exist when using Microsoft Data Protection Manager within your SharePoint environment that have to be taken into consideration when planning your deployment and disaster recovery strategy. These caveats are very important when considering the impact that they might have on your enterprise environment and disaster recovery.
The Largest Caveat
The largest caveat that exists with a marriage of DPM and SharePoint is support for SQL backups (minus using the backup feature to export and flat file exportation) is not currently supported. This feature is planned to be built in the second half of 2007. 
Hardware Requirements for Microsoft Data Protection Manager
Firstly, you have to look at the actual server itself that you are using as your DPM environment. Running DPM requires using Windows Server 2003 with at the very least SP1 applied, and because you will require two volumes for DPM to function correctly you will need to have two different hardrives.  If you attempt to install DPM on a server with only one harddrive, you will get an exception thrown during the setup dialog. You can optionally add this volume at a later date. The reason that there are two harddrives required is the first will be the OS and relevant DPM program files, and the second will be used for data backups, and nothing else. Putting other program files on the second harddrive could possibly cause the DPM server to crash. Make sure that you also meet over the hardware requirements as well. Allocate at least:
  1. A 2 GHz or faster processor
  2. 2 GB of RAM
  3. 3 times the harddrive space as the estimated protected data
These are over the Microsoft recommendations, however when backing up SharePoint farms it can be a rather resource intensive process and therefore is better to plan over estimations that are more tailored to environments where DPM is mainly used as a file share backup mechanism. As well, SharePoint typically will increase the amount of data stored within its repositories dramatically from initial implementation to full production use by organizational virtual teams, and will only get larger as time progresses and more users adopt to using it. Multiplying your estimates by three is a guess, and the amount of disk space that you use should be on a company by company basis. 
Constantly Changing Data In Exported Backup Files
Remember that similar to SharePoint, Data Protection Manager will keep different revisions of its backups. Content housed within SharePoint is changed extremely frequently, since initial document creation can be housed there through an arbitrary amount of changes with an arbitrary amount parties involved. This can be from a single to a triple digit number depending on the nature of the documentation or object. One must plan accordingly with this in mind. Although DPM will only keep revision of the changes, it still can be a large amount when considering the environment we are tailoring DPM for is SharePoint. 
Ensuring Server Compliance Requirements for Data Protection Manager
Secondly, you have to look at the servers that you have available to assimilate into your DPM environment. Within a SharePoint environment, it is fairly atypical to have any other servers other than Windows Server 2003 running, however with some networks there are often other versions of servers such as Windows Server 2000. If you are using a Windows 2000 machine for your data storage, you should firstly install Service Pack 4. If you have other breeds of servers within your environment such as Unix and Linux, these servers are obviously not supported as data stored for DPM as well, as well, you can’t deploy agents to these servers since they won’t be compatible with the executables.
For Fresh Windows Server 2003 Installations 
Once you have Windows 2003 installed, it will bring up an .hta file which will allow you to configure server roles. Role implementation can also be launched by selecting the manage server roles selection out of the program files menu, or can be manually configured using the add/remove program dialog. You can configure the server with any role you choose besides a domain controller. Since the server will be querying other servers within the environment for disk-to-disk backups, it must be a member of the domain that your SharePoint server and SQL cluster reside on. It is not wise to put other software on this server as well, try to keep it as built down as possible so as not to interfere with other DPM processes.
Say No to Encryption with DPM
With SharePoint, the files that we are mostly concerned with protecting will be the exported SQL backup files and SharePoint file stores. There are some file types that are impossible for DPM to backup however, most notably those that are already encrypted, such as documents encrypted with PGP or other relevant encryption engines. When doing system restores of your SharePoint servers, there are other assets that will not stored within the backup, such as:
  • Paging Files
  • The Recycle Bin
  • Volume Information Folder
With SharePoint, there is typically not an end-to-end encryption solution in place because storing encrypted document within SharePoint repositories will confuse the gatherer and searching since it can’t correctly flag the data within the document. An end-to-end encryption solution for SharePoint that carries the encryption cipher is a piece of software currently being developed at ARB Security Solutions.
With the default package of DPM, there are the possibilities of using three different agents, for three different servers, purchasing more agents is relatively inexpensive if you need to protect more assets within your environment.

Native Cryptography in SP Doc Libs and Lists (RSA WebPart Test)

Privacy is important, especially in a collaborative environment such as SharePoint where users are heavily empowered with actions that can directly effect sensitive files and file containers. The most typical way to protect privacy for file types is to implement a form of Multi-Level Access Control, and/or native encryption components that are easy for users to understand, ones that are perferably built directly into familiar toolsets such as Office (as is the case with IRM).

End to end encryption solutions aren’t a native thing to SharePoint (outside of WRM / IRM, which aren’t “native” in the sense in that they aren’t outright built into the product COTS, they require further configuration). Furthermore, there are a lot of side effects of going down a standard encryption road when examining a collaborative cryptographic solution, most we see when using IRM encryption envelopes. When I say standard road, I mean just using a client level encryption solution (something running on a user desktop), an arbitrary scramble method / encryption algorithm, by which I mean something like:

Symmetric Encryption

(Block and Stream Ciphers)

Asymmetric Encryption






Elliptic Curve Techniques


Paillier Cryptosystem




Vectors and Salts

and then re-upload the document to a document library whereby you are responsible for key maintenance between an unknown amount of parties. The most obvious problem that is spawned is encrypted content cannot be read by the SharePoint gatherer since it does not sponsor anything besides plain-text reads.

For my final paper for my Masters (I am doing my degree in Applied Mathematics / Cryptography) I received approval from my professor to move forward with creating /verifying an end-to-end cryptography solution that solves all these issues and stays within the native SharePoint framework. I am not sure how / what it will look like yet, how it will be invoked, or any of the architectural considerations of it yet. My only stipulation is that it is easy, and directly available from within the SharePoint interface.

The aggregate objective of the solution, eventually (this is probably down the road a little bit), is to exhibit the feasibility of extending a native Microsoft Windows Server operating system and Microsoft Office SharePoint Server (MOSS) environment such that it enhances global security of federal Multi-Level Security (MLS) systems which are historically built on the Bell-LaPueda model. This technique should eventually leverage a lattice MAC (Mandatory Access Control) based Multi-Policy Access Control (MACM) object labeling controls regulated by comprehensive security policy implementation. The standard notion of Discretionary Access Controls (DAC) that the Microsoft Server System currently provides are incontestably bound to native Windows Identities, allowing users management of individual objects, expressed as P=SxOxA where s translates to the subject, O to an arbitrary set of objects, and A to access modes. Use MAC MACM this instead promotes M=(S,O,A,SA,f,R), such that S is the set of subjects, O is the set of objects, A is the access mode set when a subject accesses object: SxO {, {r},{w},{e},{a},…..}, SA is the security attribute, f is the security functions, R is the set of security rules that prescribe the constraints conditions of how subjects access objects. Using this model, it is possible to procure the federal notion of no-read-up and no-write-down.

The security attribute can be defined in tuple format: SA={L,A} such that: L is the security level of an entity, denoting the security right of the entity. Different security levels are comparable. Defining “” is a partially ordered on the set of the security level, if the security level of entity i ()

This promotes a new-read-up rule denoting that a subject s S is granted read access to object o iff f(o) f(s). No write-down rule denotes that a subject s S is granted write access to object o iff f(s) (f(o)

I started toying with the idea last night, just working with getting an RSA encryption engine to take a sample plain text string in a TextBox child control. Most importantly I spent some time building some foundational abstract base classes to provide a Multiple-precision shared library (for for multiple-precision floating-point computations) and a Barrett modular reduction library to implement Barrett’s Modular Reduction Method for RSA . Although the encryption exponent is pretty tiny for the test, the plain text conversion for my shared components was successful, however this is only 10% of the battle obviously (I was mainly interested in the web basd encryption performance, I would like to eventually integrate instruction level parallelism). What I plan on ultimately doing is building this concept into a complete multi-level system with the native encryption components. In aggregate, the solution should facilitate Enterprise Content Management (ECM) and Team Virtualization (eTV) using Microsoft technologies as the institutional foundation using partitioned layers of classification as well as native encryption features. The purpose of the encryption functions with Microsoft Office Server System will be to provide practical applied cryptographic functions (again, taking into account instruction level parallelism and memory bandwidth) while maintaining the two most important concepts to cryptography, privacy and correctness. Below is my example SharePoint WebPart that I have been playing around with.

(Select Image To Expand)

I started to push the data back and forth between list items and as I expected, the universal issue of not gathering encrypted items was encountered. I am pretty sure I can get around this with floated carrying key tokens however, so that the gatherer will basically have a Skelton key to the documents that it wishes to implement full-text indexing against, which although will need to be looked at for security vulnerabilities, is really the only feasible solution that comes to mind. I think for most organizations, this will be a good solution. Although I was just pushing the data back and further programmatically, I plan on making the encryption option a item-level context menu or something along those lines.

As always, good security software is always open-source. When this project (which, for the paper / research thesis is taking on the name CryptoCollaboration) becomes production and has been somewhat tested for my grading, it will be released to the public open at no cost, probably under a GNU license.