Share via

Trust Services: Usage Overview

  • Article

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) – This is the Live ID user that manages the Trust Services account for the organization. The TSA performs the following actions on the Trust Services portal.
    • Sign-up for a Trust Services service.
    • Create and Manage Trust Servers associated with the account - The TSA creates a Trust Server and identifies a Trust Services Policy Administrator with an X.509 certificate (referred to as Principal Certificate) for the server. This certificate (containing only the public key) is uploaded by the TSA.

  • Trust Services Policy Administrator (TSPA) – The TSPA performs the following actions within a Trust Server using Trust Services SDK :  

    • Manage users: Identifies the publisher/subscribers associated with a Trust Server and uploads their certificates (containing only the public key).
    • Define & Manage Policies: Defines policies for data entities, identifying the data entity (URI) as sensitive (protected with encryption) or non-sensitive (left as plaintext). In Trust Services, a data entity is identified by a uniform resource identifier (URI). 
    • Define & Manage the Data Authorization: Authorizes users to access (decrypt) the sensitive data entity. 
    • TSPA certificate rolling: Uploads a new TSPA certificate to designate a new TSPA.

  • 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).

Streaming

Streaming API allows transforming large amounts of data with high performance and low memory footprint. Streaming API also provides ongoing checksums to ensure data integrity.
For ease of use, streaming API exposes .NET Stream class implementation and supports both read and write modes. See Trust Services SDK Help for API details.

Search in Encrypted Data

The “search in encrypted data” feature allows TSPAs to define searchable policies on data. A searchable data policy enables authorized publishers to transform the associated data into an index that can be stored in an appropriate data structure in the cloud. Authorized subscribers can use the index to search, filter and join the data. 

The searchable transformation is: 

  • deterministic, i.e. a specific data policy always produces the same ciphertext for a given plaintext. However, distinct data policies produce different ciphertext for a given plaintext.
  • irreversible, i.e. the ciphertext cannot be decrypted back to the plaintext.

To enable join operation between data transformed by distinct policies, policies can be grouped together to produce the same ciphertext for a given plaintext. This grouping can be implemented using the SearchSpace property of the data policy.

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.

  1. A customer reads about Trust Services on Sql Azure Labs page and chooses to sign in to Trust Services Portal.
  2. 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.
  3. 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. 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.
  5. The user clicks on the Create New Server button. This creates a new server with an auto-generated name.
  6. The user clicks on the Set TSPA button and uploads X.509 certificate (containing only the public key) of Trust Services Policy Administrator for the server.
    Additional data users, i.e. data publishers and data consumers, are created by TSPA in the next step.

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. 

  1. 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.
  2. 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.
  3. 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.
  4. 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 (data publishers and data consumers) 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.

  1. The data publisher downloads and installs the SDK.
  2. 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.

  1. The data consumer downloads and installs the SDK.
  2. 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.

To get additional information on Trust Services, see [[Learn More about Microsoft Codename "Trust Services"|Learn More]] page.

To get started, follow [[Microsoft Codename "Trust Services" Getting Started Tutorial|Getting Started Tutorial]].

  • [[Learn More about Microsoft Codename "Trust Services"|Learn More]]

  • [[Microsoft Codename "Trust Services" Getting Started Tutorial|Getting Started Tutorial]]

  • Download "Trust Services" SDK

  • Access "Trust Services" Portal

  • [[Microsoft Codename “Trust Services” Samples|Samples]]

  • [[Microsoft Codename “Trust Services” Troubleshooting|Troubleshooting]]

  • SQL Azure Labs Forums

  • [[Microsoft Codename "Trust Services" Glossary|Glossary]]