Microsoft Codename “Trust Services” Usage Overview (en-US)

Introduction
Components and user roles in this release
- Components
- User roles
Usage Flow
Quick Links

Introduction

Microsoft Codename “Trust Services” is an application-level encryption framework that can be used to protect sensitive data stored on Windows Azure Platform. Data encrypted with Trust Services can only be decrypted by authorized data consumers. This empowers data publishers to freely distribute and share data by first encrypting it using the Trust Services. Consumers of sensitive data encrypted with Trust Services can have full confidence in the privacy of the data and the knowledge that the data has not been viewed by anyone else.

The basic scenario involves 2 steps:

• Data publishers use Trust Services to encrypt sensitive data and store it in Windows Azure storage or SQL Azure

• Authorized data consumers can decrypt data after it is read from storage

Using Trust Services helps address data security, privacy, and sovereignty issues that might block or limit typical scenarios, such as distributing data to branch offices, making data accessible to mobile employees or customers, sharing data across businesses, and leveraging cloud scale for computation and analytics.

Two common scenarios supported by Microsoft Codename “Trust Services” are:

Trusted Data Store – An on-premise application, with some data identified as sensitive, uses Windows Azure as a trusted store for this data. Typically, in this case, the customer has applications running in Windows Azure that operate on the non-sensitive data. The Windows Azure Platform store serves as a disaster recovery solution and a secure data store for leveraging the flexibility of the Windows Azure Platform.
Trusted Data Hub – Multiple parties use Windows Azure store as a trusted hub to exchange data. Typically, an on-premise application (data publisher) with local data store wants to share this data selectively with multiple data consumers. Some of the data, identified as sensitive, is accessible by designated consumers via the Windows Azure store.

Components and user roles in this release

Components

Trust Server
An instance of Trust Services is called a Trust Server. Trust Services provide a web portal (Trust Services Portal) for creating and managing Trust Servers and managing user access to the servers. Users of Trust Server are represented by public X.509 certificates.
Trust Services SDK
Trust Services also provides a Software Development Kit (SDK) containing a .NET library and a PowerShell snap-in so that applications can manage and enforce data policies, and so that authorized data consumers can encrypt and decrypt data.
The SDK can store user public certificates, signed and encrypted data policies and metadata, signed and encrypted intermediate keys in Trust Server. When reading these objects from Trust Server, the SDK validates the integrity - thus ensuring that the policies were not tampered with. The SDK also performs data transformations when data is crossing trust boundaries, i.e. before moving data from trusted to untrusted location, or after reading it from untrusted location. When transforming data to untrusted location, the SDK checks that there is a policy for this data and of course that the policy itself is trusted. When transforming data from untrusted location, if the data was enciphered, the SDK fetches and decrypts the intermediate encryption keys and decrypts that data. Only authorized users are able to perform this decryption.
Your application
Once you've created a Trust Server, and granted users access to in using Trust Services Portal, users can start accessing it using applications that utilitize Trust Services SDK via .NET or PowerShell scripting.
The application defines Trust Policies, performs data transformations using Trust Services SDK and copies or moves the data to/from cloud. Trust Services SDK is responsible for data enciphering when the data crosses the trust boundaries, but the actual data movement is responsibility of the application.

User roles

Trust Services Administrator (TSA) – The customer that holds a Windows Azure Subscription and manages Trust Services for the organization. The TSA identifies the need to secure sensitive data in the cloud and subscribes and provisions a Windows Azure store. The TSA authenticates using a Window Live ID. The TSA performs these actions on the Trust Services portal.
- Sign-up and register for a Trust Services service.
- Manage Trust Servers associated with his account - The TSA identifies users of Trust Services (TSPA, data publishers and data consumers) with X.509 certificates (referred to as Principal Certificates). These certificates (containing the public keys) are uploaded by the TSA. This process is referred to as User Certificate Management.

Trust Services Policy Administrator (TSPA) – The TSPA can define and manage policies of the Trust Server. These policies are based on the data entity associated with the Trust Server. In Trust Services, a data entity is identified by a uniform resource identifier (URI). A TSPA defines the Data Authorization Policy for the Trust Server; identifying the data entity (URI) as sensitive (protected with encryption) or non-sensitive (left as plain text) and designates the users that are authorized to access (decrypt) the sensitive data entity. These users are identified by their Principal Certificates uploaded in the User Certificate Management step above.
The TSPA performs these actions (also referred to as Policy Management).

Note:

In many cases, the TSA & TSPA roles are filled by same user. The main difference between the two roles is that the TSA role performs operations on the Trust Services portal while the TSPA role performs operations on the client machine using the Trust Services SDK (.NET library or PowerShell snap-in).

Data Publisher – The user that encrypts the data on the client machine based on the policies defined by the TSPA. The data publisher performs encryption (based on policies set by TSPA) and uploading of data to Windows Azure (or more generally to any store). The data publisher uploads the encrypted data to Windows Azure outside of the Trust Services system. Typically, the data publisher would upload data using the interfaces provided by Windows Azure (blob, table, or SQL Azure) in an application or tool. The data publisher performs the encryption step (also referred to as Policy Enforcement) using the Trust Services SDK (.NET library or PowerShell snap-in).
Data Consumer – The user that decrypts the data on the client machine based on the policies defined by the TSPA. The data consumer downloads the data from Windows Azure and decrypts the data after download. The data consumer performs the decryption step (also referred to as Policy Enforcement) using the Trust Services SDK (.NET library or PowerShell snap-in).

Usage Flow

The overall-basic usage flow is described below. The flow is not exhaustive and focuses on a basic Trust Services usage of creating a Trust Services instance, defining a data policy and sharing protected data between a data publisher and a data consumer. In the process below, the data being shared is a blob. The Trust Services service enables clients to encrypt and decrypt data. The action of storing the protected data in Windows Azure is assumed to be performed by the application.

Create a Trust Server

The first step in using the Trust Service is to create a Trust Server for the application scenario and associating the participants. This step is performed by the TSA.

A customer reads about Trust Services on Sql Azure Labs page and chooses to sign in to Trust Services Portal.
Signing in redirects him to the Windows Live ID login page. If the Windows Live ID of the user is not already registered with Trust Services, the user is re-directed to the registration page.
Registration: The Registration Page gathers information about the user and also displays the Terms of Service. The data collected about the user includes:
1. First Name
2. Last Name
3. E-mail Address
4. Registration Code
To request the registration code, the user must complete the form.
Sign-In: After registering, the user is re-directed to the Trust Services home page. On this page, the user can:
1. Create a Trust Server – This enables the user to instantiate a Trust Server. A Trust Server is the unit of management of Trust Services. The customer can define, manage and enforce Trust Services policies per Trust Server.
2. List all Trust Servers – This lists all the Trust Servers associated with this account. For each of the Trust Servers, the site lists the User Certificates associated with the Trust Server.
The user clicks on the Create New Server button. This creates a new server with an auto-generated name. The user becomes the Trust Services Administrator (TSA) of the new Trust Server.
User Certificate Management: To associate users with this Trust Server the TSA visits the Trust Services home page. The TSA must associate Certificates to a Trust Server. The X.509 certificates enable those users (clients) that have the specified certificates to define, manage and execute Trust Services polices for the specific Trust Server. These certificates are also referred as Principal Certificates.
The options he is provided with are:
1. Upload a User Certificate to a Trust Server – The TSA can upload a certificate from his local file system. The file formats supported is .cer. These certificate files should not have Private Keys.
2. List all the Principal Certificates of a Trust Server – In this option, he can list all the User Certificates associated with a Trust Server. The Certificate details listed include Thumbprint, Subject, Issuer (CN), and Expiration time.
The TSA clicks on the Upload User Certificate button to add users to the selected Trust Server.

Once user certificates are uploaded, the Trust Server is ready for the TSPA to perform the administration step.

Create a Data Policy

The next step is to identify the data entities to be protected and create data policies on the Trust Server for all entities, protected and clear. This step is performed by the TSPA role on his machine.

The TSPA downloads and installs the SDK. This SDK has both a .NET library and a PowerShell snap-in for performing management operations. Using this SDK, The TSPA defines Data Policy and Authorization policies for the Trust Server.
Establish his identity using his Certificate – The TSPA uses his X.509 certificate to identify himself. To do this step, he must instantiate a PrincipalCertificate using an instance of X509Certificate2 .NET class. The X509Certificate2 can be instantiated by loading a .pfx file (with both public & private keys) or by locating the certificate in Windows Certificate store.
Instantiate Policy Administration for the Trust Server – The TSPA then instantiates PolicyAdministration by specifying the Trust Server he is managing and his PrincipalCertificate. The Trust Server should have been created by the TSA and the public key of his certificate should have been uploaded for this server by the TSA.
Manage Data Policy – The TSPA creates a protection policy for a data entity and associates users to this data entity for authorization. The steps he needs to perform are in the context of the PolicyAdministration object created above. They are:
1. Add users for his administration – The TSPA creates PrincipalCertificate per user that he wants in his data policy. The TSPA instantiates PrincipalCertificate by using X509Certificate2. The user certificates should already be linked with the Trust Server by the TSA (as part of User Certificate Management). The certificates loaded here should only contain the public key. The TSPA finally invokes the AddPrincipalCertificate method.
2. Create Data Policy – The TSPA creates a data policy by performing an AddDataPolicy method call in. The TSPA specifies the data entity’s URI. (The TSPA must define (create) a URI that represents the data.)
3. Add Data Authorization – The TSPA adds the authorized users by doing a AddDataAuthorization method call.

At this point, the Trust Server now has a data policy defined; identifying a data entity with a set of authorized users. Now, the Data Publisher can encrypt the data on his machine.

Encrypt data based on Data Policy

In this step, the Data Publisher (application) encrypts the data as identified by the TSPA in his data policy. This encryption step is performed in the Data Publisher’s machine.

The data publisher downloads and installs the SDK.
Protect Data - The data publisher application (using the Trust Services API), executes the policies defined by the TSPA:
1. Establish the data publishers identity using a certificate – The data publisher uses a X.509 certificate to identify himself. To do this step, the data publisher must instantiate a PrincipalCertificate using an instance of X509Certificate2 .NET class. The X509Certificate2 can be instantiated by loading a .pfx file (with both public & private keys) or by locating the certificate in Windows Certificate store.
2. Identify the Policy Administrator – The data publisher identifies the TSPA whose policy he is implementing. The data publisher does this by instantiating a PrincipalCertificate using X509Certificate2. The X509Certificate2 can be instantiated with the TSPA’s public key by loading a .cer file that contains the TSPA’s public key.
3. Instantiate Policy Decision Point for the Trust Server – The data publisher instantiates PolicyDecisionPoint by specifying the Trust Server the data publisher is accessing for the policy, PrincipalCertificate of the data publisher, and the PrincipalCertificate that identifies the Policy Administrator (TSPA).
4. Encrypt the Data – The data publisher encrypts the data using the PolicyDecisionPoint . The data publisher first gets the ITransformation object by invoking the GetTransformation method specifying the Data entity (URI) and a PolicyContext. The PolicyContext is used to indicate that the data is to be encrypted (flag of ToUntrusted). Using the ITransformation object, the Transform method is called with the data passed as input. The Transform method returns the encrypted data.

Now, the application can move the encrypted data to Windows Azure storage.

Decrypt data based on Data Policy

In this last step, the Data Consumer (application) decrypts the encrypted data as identified by the TSPA in his data policy. The encryption is performed by the Data Publisher in the step above. This decryption step is performed in the Data Consumer’s machine. It is assumed that the Data Consumer application downloads the encrypted data first from the Windows Azure storage (placed by the Data Publisher) prior to this decrypt step.

The data consumer downloads and installs the SDK.
Unprotect Data - The data consumer application (using the Trust Services API), executes the policies defined by the TSPA:
1. Establish the data consumers identity using a Certificate – The data consumer uses a X.509 certificate to identify himself. To do this step, the data consumer must instantiate a PrincipalCertificate using an instance of X509Certificate2 .NET class. The X509Certificate2 can be instantiated by loading a .pfx file (with both public & private keys) or by locating the certificate in Windows Certificate store.
2. Identify the Policy Administrator – The data consumer identifies the TSPA whose policy the data consumer is implementing. The data consumer does this by instantiating a PrincipalCertificate using X509Certificate2. The X509Certificate2 can be instantiated with the TSPA’s public key by loading a .cer file that contains the TSPA’s public key.
3. Instantiate Policy Decision Point for the Trust Server – The data consumer instantiates PolicyDecisionPoint by specifying the Trust Server the data consumer is accessing for the policy, PrincipalCertificate of the data consumer, and the PrincipalCertificate that identifies the Policy Administrator (TSPA).
4. Decrypt the Data – The data consumer unprotects (decrypts) the data using the PolicyDecisionPoint. The data consumer first gets the ITransformation object by invoking the GetTransformation method specifying the Data entity (URI) and a PolicyContext. The PolicyContext is used to indicate that the data is to be decrypted (flag of ToTrusted). Using the ITransformation object, the Transform method is called with the encrypted data (received from Windows Azure) passed as input. The Transform method returns the decrypted data.