4.2 Accessing Protected Information Example
Accessing protected information requires requesting an authorization policy from the RM server, and then decrypting the protected information.
Client package is deployed.
Deployment of the client package installs binaries on the client machine.<57>
The machine activates locally.
Figure 21: Local machine activation
Activation is the process by which an SPC is generated on the client machine. The SPC represents a pair of keys for the machine that is used to protect the user's keys in a subsequent step.
In the RMS 1.0 client, the activation stage involved contacting a web service run by Microsoft to acquire a binary and some metadata. RMS version 1.0 SP1, 1.0 SP2, and 2.0 clients eliminate the need for this step by providing a form of self-activation that does not contact the server.
The Certify method is called.
Figure 22: Certify message sequence
Certification is the process by which the server issues a RAC. The RAC represents a pair of keys for the user that is used to protect the authorization policy and content keys in subsequent steps. The RAC keys are, themselves, protected by the keys represented by the SPC from step 2.
The call to the Certify web method provides the SPC a form of authentication and a flag that indicates whether to issue a temporary, short-lived RAC or a normal, long-lived RAC. The result of a successful Certify call is a RAC.
The application extracts the usage policy from the protected information.
The application extracts or retrieves the usage policy (signed issuance license) from wherever it is stored. RMS is not responsible for storing the usage policy associated with protected information; that is the responsibility of the application.
The AcquireLicense method is called.
Figure 23: AcquireLicense method sequence
The signed issuance license acquired in step 4 represents the complete usage policy issued by the author of the protected information. For an individual user to access the protected information, the server issues an authorization policy, or UL. This authorization policy expresses what an individual user can do with the protected information.
The client calls the AcquireLicense web method, providing the RAC, the signed issuance license, and passing application data that the application provided.
The server verifies that the RAC and signed issuance license were issued from an entity or entities it trusts, and then identifies the subset of the full usage policy that applies to the specific user. It issues a UL that contains this subset of usage policy and itself. The UL is then returned to the client.
Decryption of protected information using client APIs and authorization policy keys occurs.
Contained within the UL issued in step 5 is the symmetric key used to protect the information. The symmetric key is encrypted to the user's RAC by the server upon issuance of the UL. The application uses the UL and the RM client APIs to decrypt the protected information and to access the information.
Application persists the UL with protected information, as needed.
Finally, the application persists the UL in a location it can access along with the protected information. Whether or not the application persists the UL and where it is persisted is implementation-specific.<58>