Bring Your Own Key (BYOK) with Azure
Rights Management
Overview Technical Article
Microsoft France
Published: December 2013 (updated: October 2014)
Version: 1.0c
Authors: Philippe Beraud, Arnaud Jumelet (Microsoft France)
Contributors/Reviewers: Peter DiToro, Eric Portrait (Thales e-Security), Enrique Saggese, Sumedh Barde (Microsoft
Corporation)
For the latest information on RMS, please see
www.microsoft.com/rms
Copyright © 2014 Microsoft Corporation. All rights reserved.
Abstract: The Microsoft Azure Rights Management service (Azure RMS) utilizes an important key called the
tenant key at the root of its trust model. The Azure Rights Management service stores and uses these Azure
Rights Management service’s tenant keys with extreme security thanks to its reliance on industry proven,
FIPS compliant Hardware Security Modules (HSMs) from Thales e-Security. It also offers related services such
as the Bring-Your-Own-Key (BYOK) capability that lets customers generate, import, and delegate use
privileges to Microsoft for use in the Microsoft Rights Management cloud-hosted service.
Azure Rights Management service’s customers often need to use a key generated by, archived at, and under
the control of customer security officers. This requirement may be due to compliance reasons, sometimes
because they are migrating from their on-premises AD RMS infrastructure, or simply to best practices in key
custody.
This document provides information about the Bring-Your-Own-Key (BYOK) capability and its various related
options. By following the steps outlined in this document you should be able to successfully prepare your
environment to leverage this BYOK capability, enable it and manage your key over the time, and thus start
using the Azure Rights Management service within your organization to create and consume protected
content in compliance with your own security and IT policies in place.
Table of Contents
NOTICE ............................................................................................................................................................... 2
FEEDBACK ........................................................................................................................................................... 2
INTRODUCTION ................................................................................................................................................. 3
OBJECTIVES OF THIS PAPER ..................................................................................................................................................... 4
NON-OBJECTIVES OF THIS PAPER ........................................................................................................................................... 4
ORGANIZATION OF THIS PAPER .............................................................................................................................................. 5
ABOUT THE AUDIENCE ............................................................................................................................................................. 5
BYOK AT A FIRST GLANCE ............................................................................................................................... 6
UNDERSTANDING THE KEY LIFECYCLE .................................................................................................................................... 6
UNDERSTANDING THE RESTRICTIONS .................................................................................................................................... 7
THALES HSMS AND MICROSOFT ADDITIONS ...................................................................................................................... 8
MANAGING YOUR OWN KEY ........................................................................................................................ 10
PREPARING A DISCONNECTED WORKSTATION WITH THE THALES HSM ......................................................................... 13
GENERATING YOUR KEY ......................................................................................................................................................... 18
TRANSFERRING YOUR TENANT KEY OVER THE INTERNET ................................................................................................... 28
TRANSFERRING YOUR TENANT KEY IN PERSON ................................................................................................................... 56
ENABLING AND USING YOUR AZURE RIGHTS MANAGEMENT SERVICE TENANT ............................................................. 57
GETTING USAGE LOGS FOR YOUR KEY .................................................................................................................................. 59
REVOKING YOUR KEY ............................................................................................................................................................. 60
ROLLING YOUR KEY (RE-KEY) ................................................................................................................................................ 60
BACKING UP AND RECOVERING YOUR KEY .......................................................................................................................... 60
EXPORTING YOUR KEY ........................................................................................................................................................... 61
RESPONDING TO A BREACH .................................................................................................................................................. 62
1
Bring Your Own Key (BYOK) with Azure Rights Management
Notice
For the latest information that pertains the Bring-Your-Own-Key (BYOK) capability as covered in this
document, please refer to the Microsoft TechNet article PLANNING AND OPERATIONS FOR YOUR WINDOWS AZURE
RIGHTS MANAGEMENT TENANT KEY1.
This article constitutes the reference article on this capability.
Feedback
For any feedback or comment regarding this document, please send a mail to AskIPteam@microsoft.com.
PLANNING AND OPERATIONS FOR YOUR WINDOWS AZURE RIGHTS MANAGEMENT TENANT KEY: http://technet.microsoft.com/enus/library/dn440580.aspx#BKMK_ImplementBYOK
1
2
Bring Your Own Key (BYOK) with Azure Rights Management
Introduction
For each organization that subscribes to the Azure Rights Management service, the Azure Rights
Management service holds an important associated key called the tenant key, i.e. the SLC (Server licensor
certificate)2. The Azure Rights Management service utilizes this key at the root of trust of its trust model: all
Azure Rights Management service artifacts in the organization (per-user keys, per-document encryption
keys) are indeed cryptographically chained to that tenant key.
Customer Control
The Microsoft Right Management service requires storage for this high value key3 and offers you (the
customer IT administrator) multiple levels of control over this tenant key so that you can trade off the level
of control you desire versus cost and simplicity.
BYOK
+ Logging
Bring-Your-OwnKey
(BYOK)
Default
(Azure Rights
Management service
manages keys)
Cost to Customer
By default, the Azure Rights Management service generates your tenant key and manages the key lifecycle.
This is the simplest option. You do not even need to know the existence of your tenant key. You just sign up
for the Azure Rights Management service and the rest happens automatically.
As an alternative the KMS offers the Bring-Your-Own-Key (BYOK) capability that let you bring your own
key as the name indicates. Indeed, Azure Rights Management service’s customers often need to use a key
generated by, archived at, and under the control of customer security officers. This requirement may be due
to compliance reasons, sometimes because they are migrating from their on-premises Active Directory
Rights Management Service (AD RMS) infrastructure, or simply to best practices in key custody.
With this option, and thanks to its reliance on industry proven, FIPS compliant4 Hardware Security Modules
(HSMs)5 from our partner Thales:

You generate your tenant key on your premises, using tools of your choice, in compliance with your
own Security and IT policies in place.
2
UNDERSTANDING AD RMS CERTIFICATES: http://technet.microsoft.com/en-us/library/cc753886.aspx
3
HOW AD RMS WORKS: http://technet.microsoft.com/en-us/library/how-adrms-works.aspx
4
Thales nShield HSMs Certifications: http://www.thales-esecurity.com/company/certifications
5
Thales nShield HSMs: http://www.thales-esecurity.com/products-and-services/products-and-services/hardware-security-modules
3
Bring Your Own Key (BYOK) with Azure Rights Management

You securely transfer the key from an HSM in your possession to HSMs in Microsoft’s possession
for the KMS service. The key never leaves the hardware protection boundary. HSMs provide a
hardened, tamper-resistant environment for performing secure cryptographic processing, key
protection, and key management.

While in Microsoft’s possession, your key stays protected by Thales HSMs. Microsoft and Thales
have worked together to ensure your key cannot be recovered from Microsoft’s HSMs.
Considering the above, you are promised assurance that Microsoft operators cannot see or leak the key
during the import as well as during the running steady state.
Optionally, you can sign up to the Near-realtime Logging service and thus receive near real-time usage
logs from the Azure Rights Management service. You can layer this on top of BYOK to see exactly how and
when your key is being used by the Azure Rights Management service.
Note
For additional information, see the whitepaper GET USAGE LOGS FROM MICROSOFT RMS6.
Objectives of this paper
This document provides information about the various options available for protecting your tenant key of
the Azure Rights Management service and controlling its usage. More particularly, it provided an in-depth
description of the Bring-Your-Own-Key (BYOK) capability and how to enable it in your environment and
your related subscription of the Microsoft Rights Management cloud-hosted service to let you generate,
import, and delegate use privileges to Microsoft for use in the Microsoft Rights Management cloud-hosted
service.
Furthermore, by following the steps outlined in this document you should be able to successfully prepare
your environment to leverage the BYOK capability, enable it and efficiently manage your key over the time,
and consequently start using the Azure Rights Management service within your organization to create and
consume protected content in compliance with your own security and IT policies in place.
Non-objectives of this paper
This document doesn’t offer a full description of the Azure Rights Management services offerings. It rather
simply focusses on key aspects in the context of this paper that aims at providing the readers an
understanding on how to leverage and enable the Bring-Your-Own-Key (BYOK) in your environment and
your related subscription of the Microsoft Rights Management cloud-hosted service.
6
4
GET USAGE LOGS FROM MICROSOFT RMS: http://www.microsoft.com/en-us/download/details.aspx?id=40333
Bring Your Own Key (BYOK) with Azure Rights Management
Note
For an overview of the NEW Azure Rights Management services offerings, see the whitepaper
MICROSOFT RIGHTS MANAGEMENT SERVICES7, the online documentation8, the series of whitepapers9 on RMS to which the
current document belong as well as the posts on the RMS Team blog10.
Organization of this paper
To cover the aforementioned objectives, this document is organized by themes, which are covered in the
two following sections:

BYOK AT A FIRST GLANCE.

MANAGING YOUR OWN KEY.
About the audience
This document is intended for IT professionals and system architects who are interested in understanding
the various options available for protecting your tenant key of the Azure Rights Management service and
controlling its usage.
MICROSOFT RIGHTS MANAGEMENT SERVICES: http://blogs.technet.com/b/rms/archive/2013/07/31/the-new-microsoft-rightsmanagement-services-whitepaper.aspx
7
8
Microsoft Rights Management services: http://www.microsoft.com/rms
9
Microsoft Rights Management service (RMS) whitepapers: http://www.microsoft.com/en-us/download/details.aspx?id=40333
10
5
RMS Team blog: http://blogs.technet.com/b/rms
Bring Your Own Key (BYOK) with Azure Rights Management
BYOK at a first glance
With the Bring-Your-Own-Key (BYOK) option:

You generate your tenant key on your premises, per your IT policies.

You securely transfer the key from an HSM in your possession to HSMs that are owned and managed
by Microsoft. Through this process your key never leaves the hardware protection boundary.

When you transfer your key to Microsoft, it stays protected by Thales HSMs. Microsoft has worked
with Thales to ensure your key cannot be recovered from Microsoft’s HSMs.

Optionally, you can sign up to receive near-real-time usage logs from the Azure Rights Management
service. You can layer this on top of BYOK to see exactly how and when your key is being used by
the Azure Rights Management service.
Note
For additional information, see the Microsoft TechNet article MICROSOFT RMS KEY MANAGEMENT
OVERVIEW11.
Understanding the key lifecycle
The following diagram displays the key lifecycle and how the above capabilities fit together.
3
Your key stays protected by Thales HSMs.
Microsoft cannot see or leak your key
Azure Rights
Management service
2
Bring-Your-Own-Key (BYOK) to the Azure
Rights Management service using HSM-toHSM transfer
1
You generate your keys. You keep master
key and control key lifecycle per your
compliance requirements
4
The Azure Rights Management service can use your
key
5
Microsoft can replicate your key for scale /
disaster recovery
6
Microsoft provides you near-realtime log
of how your key is used
On Your Premises
11
6
MICROSOFT RMS KEY MANAGEMENT OVERVIEW: http://technet.microsoft.com/en-us/library/dn440580.aspx
Bring Your Own Key (BYOK) with Azure Rights Management
Understanding the restrictions
Organizations that have an IT-managed Microsoft Azure subscription can use BYOK (and logging) at no
extra charge. (You must however pay for the Microsoft Azure Storage used to store the logs, see the
whitepaper GET USAGE LOGS FROM AZURE RIGHTS MANAGEMENT12).
Organizations that use the free ‘RMS for individuals’ capability (see whitepaper SHARE PROTECTED CONTENT WITH
THE AZURE RIGHTS MANAGEMENT SERVICE13) cannot do BYOK (and logging), as they do not have a tenant
administrator to configure these features.
Almost every application that is integrated with the Azure Rights Management service will work seamlessly
when you do BYOK (and logging).
That includes cloud services such as SharePoint Online (see whitepaper INFORMATION PROTECTION AND CONTROL
(IPC) IN OFFICE 365 WITH AZURE RIGHTS MANAGEMENT14), on-premises Exchange Server 2013 and SharePoint
Server 2013 servers (with the Microsoft Rights Management connector, see whitepaper LEVERAGE THE RIGHTS
MANAGEMENT CONNECTOR FOR YOUR PREMISES15), and client applications such as Office 2013. You will get key
usage logs from all of these contexts.
Azure Rights
Management service
in BYOK mode
Your Exchange, SharePoint,
and file (FCI/DAC) servers
Your employees devices
On Your Premises
However, there is one exception: if you use Exchange Online then you must either set up your Azure Rights
Management service tenant in default mode (i.e. where the Azure Rights Management service generates
and manages your key), or you must separately import your key from an on-premises AD RMS server into
Exchange Online (see whitepaper Information Protection and Control (IPC) in Microsoft Exchange Online
with AD RMS16).
12
GET USAGE LOGS FROM AZURE RIGHTS MANAGEMENT: http://www.microsoft.com/en-us/download/details.aspx?id=40333
13
SHARE PROTECTED CONTENT WITH AZURE RIGHTS MANAGEMENT: http://www.microsoft.com/en-us/download/details.aspx?id=40333
INFORMATION PROTECTION AND CONTROL (IPC) IN OFFICE 365 WITH AZURE RIGHTS MANAGEMENT: http://www.microsoft.com/enus/download/details.aspx?id=40333
14
15
LEVERAGE THE RIGHTS MANAGEMENT CONNECTOR FOR YOUR PREMISES: http://www.microsoft.com/en-us/download/details.aspx?id=40333
INFORMATION PROTECTION AND CONTROL (IPC) IN MICROSOFT EXCHANGE ONLINE WITH AD RMS: http://www.microsoft.com/enus/download/details.aspx?id=30139
16
7
Bring Your Own Key (BYOK) with Azure Rights Management
Note
For additional information, see the Microsoft TechNet article IMPORT-RMSTRUSTEDPUBLISHINGDOMAIN17.
Furthermore, in this case, the logs you receive from the Azure Rights Management service will not include
RMS transactions performed via Exchange Online.
The above exception with Exchange Online is not an impediment in practice. Typically, organizations that
need BYOK (and logging) run their “data applications” (Exchange Server, SharePoint Server, Office) onpremises, and use the Azure Rights Management service for functionality that is not easily available with onpremises AD RMS, for example, collaboration with other companies and access from mobile clients. Both
BYOK and logging work well in this scenario and allow the organization to have full control over their Azure
Rights Management service subscription. The advanced key management capabilities described here are a
great fit for such enterprises.
Thales HSMs and Microsoft additions
The Azure Rights Management service uses Thales FIPS 140-2 level 318 validated hardware security modules
(HSMs) to protect your keys in its possession meaning that Microsoft Azure based HSMs have been
independently validated to the world’s most widely recognized benchmark for cryptographic modules.
Thales solutions currently protect data for 19 of the 20 largest banks (and secure more than 80 percent of
worldwide payment transactions), 4 out of the top 5 aerospace companies, and 22 NATO countries.
Historically, key management privileges in an HSM have been an all-or-nothing model. The privileges to
generate/import a key, to authorize who can use it, to scale out your key across HSMs, and to recover
imported keys go hand-in-hand. This model breaks if you have to let a cloud service such as the Azure Rights
Management service use your key at scale.
Microsoft has worked with Thales to separate these, design and implement a secure key import process that
would accomplish several goals:

Spare you the necessity of purchasing your own HSM and co-locating it in the Azure Rights
Management service data center. Your tenant keys can be loaded into the Rights Management
service’s Thales nShield HSMs and used on your behalf without regard to which HSM is doing the
work.

Securely import your generated key without exposure of key plaintext during the import process
outside of the boundary of a Thales nShield HSM.

Elimination to the greatest degree possible of the ability for Microsoft to recover plaintext copies of
customer keys.
This results today in an effective secure key import process where you can import your key into our HSMs,
we can scale out the key across the Microsoft’s HSMs and manage the Microsoft’s HSMs, and nobody, not
even Microsoft, has the right to recover the keys from the Microsoft HSMs. This is enforced inside the HSMs.
This let the Azure Rights Management service scale up at short notice to meet your organization’s usage
spikes. In addition, you retain control over the key lifecycle since you generate the key and transfer it the
Microsoft’s HSMs.
17
IMPORT-RMSTRUSTEDPUBLISHINGDOMAIN: http://technet.microsoft.com/en-us/library/jj200724(v=exchg.150).aspx
18
More information on the FIPS 140-2 certification scheme can be found at http://csrc.nist.gov/groups/STM/cmvp/standards.html
8
Bring Your Own Key (BYOK) with Azure Rights Management
Together these enhancements create a unique and powerful offer that enables you to get the benefits of
hosted services without relinquishing control over your keys. This required a heavy investment on the part
of Microsoft in using the Thales’ Security World features.
Leveraging the Thales’ Security World as Best Practice
Thales nShield HSMs use a common key management framework: the Thales’ Security World.
Thales’ security world framework delivers cryptographic key management features that can scale, are robust
and are flexible enough to handle real-world deployments. This powerful solution gives the ability to handle
an unlimited number of keys and provides the functions necessary to manage keys throughout the entire
key lifecycle from creation to operational use, back-up, recovery, archival and finally destruction.
Security World delivers a common set of features across all Thales nShield HSMs:

Security. All HSMs are designed to ensure that there is no single point of compromise within the
key management environment. All cryptographic functions take place within validated and certified
HSM. Central to HSM security is two-factor authentication for administrators and split responsibility
or role separation which are supported by threshold sets of smartcards, i.e. the Administrator Card
Sets (ACS).
This means K out of a total of N cards must be presented to authorize a specific cryptographic
function or administrative activity significantly reducing the risk of malicious insiders and superusers within the Azure Rights Management service and the Key Management Service infrastructure.

Scalability. The fundamental requirement of any cloud hosted service is flexibility and scalability
and the Thales security world key management framework provides unique ability to provision keys
and replicate keys across multiple devices to satisfy the capacity requirements of Azure Rights
Management service’s customer.
Security world is replete with functions that simplify the process of securely sharing keys among an
array of disparate types of Thales HSMs joined to a specific security world. This enables Microsoft
to load and use customer keys in the HSMs appropriate to the task at hand dynamically without
customer interaction.

Fine Grained Control of Key Usage. Every key protected by a Thales HSM has an associated Access
Control List (ACL) that defines the allowable uses of that key. Authorization to use individual
application keys can be tightly controlled allowing different levels of security to be assigned to
individual keys in direct relation to their importance.
Together these controls ensure that individual keys or groups of keys can be isolated from one
another through logical separation. These flexible controls help to reinforce the individual
requirements of a given security policy, allowing access to individual keys only by authorized users
or servers, avoiding the need to impose rigid partitioning within an HSM.

9
Resilience. Security world technology ensures that there is no single point of failure in any Thales
HSM deployment. Multiple HSMs can be deployed on a single server or across the network to
provide secure fail-over. If an HSM is damaged or stolen, keys can be recovered easily by initializing
a new module. The security world key management framework has a range of built-in controls to
simplify back-up and recovery – all essential aspects of a robust cloud hosted service such as the
Azure Rights Management service.
Bring Your Own Key (BYOK) with Azure Rights Management
Managing your own key
With the Bring-Your-Own-Key (BYOK) capability, Microsoft set out to create mechanisms that enable you to
import keys generated at your premises while offering assurances that your generated key material cannot
readily be recovered, read, or exported by Microsoft Rights Management hosting services personnel. Thanks
to it, you will generate your own key and maintain the key for long term key recovery purposes.
The pre-requisites for this capability are as follows:
Pre-requisite
Standalone
Azure
Management
subscription
Description
Rights
service
You must have an active subscription to the standalone Azure Rights Management
service SKU.
In this release, we strongly advise you bring in your key using the instructions
in this guide after you subscribe but before you enable the Azure Rights
Management service.
Thales HSM, smartcards, and
support software
You must have access to a Thales nShield Hardware Security Module19 and basic
operational knowledge of Thales nShield HSMs. Any model will do. See the list of
compatible models20, or purchase an HSM if you do not have one.
(Optional) Microsoft
subscription
To exercise the Usage Logging feature, you must have a subscription to Microsoft
Azure and sufficient Azure storage to store your logs.
Azure
The rest of this document will guide you through the entire process to benefit from such a capability.
The procedures to generate and use your own tenant key depend on whether you want to do this over the
Internet or in person:

Over the Internet. This requires some extra configuration steps, such as downloading and using a
dedicated toolset and Windows PowerShell cmdlets.
Thales Hardware Security Modules: http://www.thales-esecurity.com/products-and-services/products-and-services/hardwaresecurity-modules
19
20
10
Ibid
Bring Your Own Key (BYOK) with Azure Rights Management
Note
Windows PowerShell is a task-based command-line shell and scripting language that is
designed for system/service administration and automation. It uses administrative tasks called cmdlets. Each cmdlet
has required and optional arguments, called parameters, that identify which objects to act on or control how the
cmdlet performs its task. You can combine cmdlets in scripts to perform complex functions that give you more
control and help you automate the administration of Windows, applications and services in the Cloud. It has become
a common way to manage the latest generation of Microsoft products and services.
For more information about Windows PowerShell, please see the Windows PowerShell Web site21, the Windows
PowerShell online help22, and the Windows PowerShell Weblog23 Windows PowerShell Software Development Kit
(SDK)24 that includes a programmer’s guide along with a full reference.
However, you do not have to physically be in a Microsoft facility to transfer your tenant key. Security
is maintained by the following methods:

You generate the tenant key from an offline workstation, which reduces the attack surface.

The tenant key is encrypted with a Key Exchange Key (KEK), which stays encrypted until it is
transferred to the Azure Rights Management service’s HSMs. Only the encrypted version of
your tenant key leaves the original workstation.

The toolset sets properties on your tenant key that binds your tenant key to the Azure Rights
Management service’s security world. So after the Azure Rights Management service’s HSMs
receive and decrypt your tenant key, only these HSMs can use it. Your tenant key cannot be
exported. This binding is enforced by the Thales HSMs.

The Key Exchange Key (KEK) that is used to encrypt your tenant key is generated inside the
Azure Rights Management service’s HSMs and is not exportable. The HSMs enforce that
there can be no clear version of the KEK outside the HSMs. In addition, the toolset includes
attestation from Thales that the KEK is not exportable and was generated inside a genuine
HSM that was manufactured by Thales.

The toolset includes attestation from Thales that the Azure Rights Management service’s
security world was also generated on a genuine HSM manufactured by Thales. This proves
to you that Microsoft is using genuine hardware.

Microsoft uses separate KEKs as well as separate security worlds in each geographical
region, which ensures that your tenant key can be used only in data centers in the region in
which you encrypted it. For example, a tenant key from a European customer cannot be
used in data centers in North America or Asia-Pacific.
21
Windows PowerShell Web site: http://www.microsoft.com/powershell
22
Windows PowerShell online help: http://technet.microsoft.com/en-us/library/bb978526.aspx
23
Windows PowerShell Weblog: http://blogs.msdn.com/powershell
24
Windows PowerShell SDK: http://msdn2.microsoft.com/en-us/library/aa830112.aspx
11
Bring Your Own Key (BYOK) with Azure Rights Management
Note
Your tenant key can safely move through untrusted computers and networks because it is encrypted
and secured with access control level permissions, which makes it usable only within your HSMs and Microsoft’s
HSMs for Azure RMS. You can use the scripts that are provided in the toolset to verify the security measures and
read more information about how this works from Thales: HARDWARE KEY MANAGEMENT IN THE RMS CLOUD25.

In person: This requires that you contact Microsoft Customer Support Services (CSS) to schedule a
key transfer appointment for the Azure Rights Management service. You must travel to a Microsoft
office in Redmond, Washington, United States of America to transfer your tenant key to the Azure
Rights Management service’s security world.
Note
For update information, see the Microsoft TechNet article IMPLEMENTING BRING YOUR OWN KEY (BYOK)26.
To generate your tenant key in your own security world thus assuring that this critical key is never exposed
outside of compatible Thales HSMs, you can take advantage of Thales affordable USB connected HSM, the
nShield Edge27. In this case, you can assure that custody of your tenant key is maintained according to the
strictest industry best practices without breaking the budget.
The nShield Edge device combines a full-featured HSM with a smart card reader, which you can use to
securely store and access your organization’s high-value occasional-use keys. The nShield Edge device has
been designed and tested for deployments where one device is used with one workstation or virtual machine
(VM).
The Thales nShield Edge will be used throughout this paper for illustrating the BYOK capability of the Azure
Rights Management service (even though any other model from Thales e-Security will do).
In the outlined configuration, the nShield Edge device will be connected to a disconnected (offline)
workstation. An additional Internet-connected workstation will be consequently needed to perform all
operations that specifically relate to the Azure Rights Management service.
HARDWARE KEY MANAGEMENT IN THE RMS CLOUD: https://www.thales-esecurity.com/knowledge-base/white-papers/hardware-keymanagement-in-the-rms-cloud
25
26
IMPLEMENTING BRING YOUR OWN KEY (BYOK): http://technet.microsoft.com/en-us/library/dn440680.aspx
Thales nShield Edge: http://www.thales-esecurity.com/products-and-services/products-and-services/hardware-securitymodules/general-purpose-hsms/nshield-edge
27
12
Bring Your Own Key (BYOK) with Azure Rights Management
Preparing a disconnected workstation with the Thales HSM
Installing the nCipher (Thales) support software
To install the Security World Software for nShield on your offline workstation, proceed with the following
steps:
1.
Insert the supplied Security World Software for nShield DVD-ROM.
Note
The Security World for nShield DVD-ROM contains a number of documentation items, including i) the
NSHIELD USER GUIDE, which describes how to install and use the Security World Software, and ii) the RELEASE NOTES,
which list the platforms and Security World Software features supported by the nShield Edge device and any known
issues.
13
2.
Right-click the setup program SecWorld-win-use.exe and select Run as administrator. A Security
World Software for nShield Setup wizard appears.
3.
Click Next.
4.
In the License Agreement page, click Yes.
Bring Your Own Key (BYOK) with Azure Rights Management
14
5.
In the Select Features page, uncheck the components nCipher Java Support (including KeySafe)
and nCipherKM JCA/JCE provider classes and click Next.
6.
The Security World Software for nShield Setup wizard now sets up the Thales middleware
including CSP, KSP CNG, PKCS#11, and OpenSSL cryptographic providers.
7.
In the nCipher MSCAPI page, click Next.
Bring Your Own Key (BYOK) with Azure Rights Management
8.
In the nCipherSNMP page, click Next.
9.
The Security Assurance Mechanism (SAM) configures the PKCS#11 library to prevent the use of
insecure keys. In the nCipher PKCS#11 page, ensure Yes is selected and click Next.
10. Click Finish.
Once the setup is completed, we advise to reboot the workstation.
15
Bring Your Own Key (BYOK) with Azure Rights Management
Attaching the Thales HSM
To attach the Thales HSM to the disconnected workstation, proceed with the following steps:
1.
Connect the nShield Edge device to your disconnected workstation using the supplied USB cable.
Always inspect the USB cable and device before use, specifically the Thales logo hologram in the
tamper window shown below. If there are any signs of tampering, do not use the cable and device.
2.
Open an elevated command prompt and run the following command:
C:\Windows\System32> cd C:\Program Files (x86)\nCipher\nfast\bin
3.
Run the following command to query the status of both the middleware and the HSM:
C:\Program Files (x86)\nCipher\nfast\bin> enquiry.exe
16
Bring Your Own Key (BYOK) with Azure Rights Management
C:\Program Files (x86)\nCipher\nfast\bin> enquiry.exe
Server:
enquiry reply flags
enquiry reply level
serial number
none
Six
C1BC-42CD-C501
mode
operational
version
2.67.2
speed index
12
rec. queue
442..642
level one flags
Hardware HasTokens
version string
2.67.2cam5, 2.50.17cam2 built on Sep 29 2010 11:55:33
checked in
00000000487debd5 Wed Jul 16 14:38:45 2008
level two flags
none
max. write size
8192
level three flags
KeyStorage
level four flags
OrderlyClearUnit HasRTC HasNVRAM HasNSOPermsCmd ServerHasP
ollCmds FastPollSlotList HasSEE HasKLF HasShareACL HasFeatureEnable HasFileOp Ha
sLongJobs ServerHasLongJobs AESModuleKeys NTokenCmds JobFragmentation LongJobsPr
eferred Type2Smartcard ServerHasCreateClient HasInitialiseUnitEx
module type code
0
product name
nFast server
device name
EnquirySix version
4
impath kx groups
feature ctrl flags
none
features enabled
none
version serial
0
remote server port
9004
Module #1:
enquiry reply flags
enquiry reply level
serial number
mode
version
none
Six
C1BC-42CD-C501
operational
2.50.17
speed index
12
rec. queue
9..152
level one flags
Hardware HasTokens
version string
2.50.17cam2 built on Sep 29 2010 11:55:33
checked in
000000004856847b Mon Jun 16 17:19:23 2008
level two flags
none
max. write size
2038
level three flags
KeyStorage
level four flags
OrderlyClearUnit HasRTC HasNVRAM HasNSOPermsCmd ServerHasP
ollCmds FastPollSlotList HasSEE HasKLF HasShareACL HasFeatureEnable HasFileOp Ha
sLongJobs ServerHasLongJobs AESModuleKeys NTokenCmds JobFragmentation LongJobsPr
eferred Type2Smartcard ServerHasCreateClient HasInitialiseUnitEx
module type code
11
product name
nC4031Z
device name
#1 Serial port \\.\com4
EnquirySix version
6
impath kx groups
DHPrime1024 DHPrime3072
feature ctrl flags
LongTerm
features enabled
StandardKM
version serial
25
kneti hash
58d8f129f3cfd4aba9e14c979b9554d37996375b
rec. LongJobs queue 8
SEE machine type
ARMtype2
supported KML types DSAp1024s160 DSAp3072s256
C:\Program Files (x86)\nCipher\nfast\bin>
17
Bring Your Own Key (BYOK) with Azure Rights Management
The Server section should be "operational". This means that the hard server, i.e. a service named nfast
server, is running correctly. The second section entitled Module #1 displays the HSM status. The status
should be operational too. If not, restart your workstation.
Generating your key
By default Microsoft generates your keys when you subscribe to the Azure Rights Management service. If
you require higher security, wish to comply with best practices and security standards, and ensure that there
is no single point of compromise within the key management environment, you may manage your own key
material with Thales ‘s HSMs, by following this section to Bring-Your-Own-Key (BYOK).
You generate your key on your own premises with tools provided by Thales or your custom tools. The
procedure described below applies to customers starting from scratch. You will need to customize this
procedure if you need to reuse an existing key (e.g. from an existing on-premises AD RMS server) or if your
organization has specific policies around handling of keys. If this is the case contact the Azure Rights
Management service support for guidance.
Perform all steps in this section on your offline workstation.
Creating a security world
By using Thales security world, the root of trust belongs to the entity, e.g. the customer, who owns
the Security World. This ownership is instantiated technically in several system objects:

The Security World master keys (KMSW, KNSO, etc.). AES 256 keys randomly generated by the
HSM upon creation of the security world.

The World File. A disk file that contains strongly encrypted key tokens for all of the security world
infrastructure keys, i.e. KMSW, KNSO, etc.

The Administrative Card Set (ACS). A set of smart cards that contains the tokens that allow an
nShield to load the infrastructure keys. The ACS tokens are split with a K of N scheme.
During this initialization step, you’ll be prompted to enter three blank cards and pins for each. These cards
will become the Administrator Card Set (ACS) for the new security world. Administrator card sets are
crucial: an unusable card set will render the security world unusable, therefore all keys protected by
that security world would become unusable as well.
Each card set consists in a number of smart cards N, (3 in the illustration below), of which a smaller number
K, (2 in the illustration below), is required to authorize an action. The required number K is usually referred
as the quorum.
18
Bring Your Own Key (BYOK) with Azure Rights Management
Note
As illustrated in the example below, the value for K should be less than N. We do NOT recommend
creating card sets in which K is equal to N in so far as an error encountered on one card would render the whole
card set unusable. If your ACS became unusable through such an error, you would have to replace the Security
World and generate new keys.
In many cases, it is desirable to make K greater than half the value of N (for example, if N is 7, to make K 4 or
more). Such a policy makes it harder for a potential attacker to obtain enough cards to access the Security World.
Choose values of K and N that are appropriate to your situation.
The total number of cards used in the ACS must be a value in the range 1 – 64.
It is advised to clearly identify the card set with stickers indicating for each smartcard, its id, the security
officer it belongs to and any additional information you may consider useful in your own specific situation.
At the end of this step, a world file will be created and stored into your file system at the following location:
%NFAST_KMDATA%\local: C:\ProgramData\nCipher\Key Management Data\local.
To create the Security World, proceed with the following steps:
1.
Change the HSM’s mode to Initialization
a.
A: Mode button
Select a mode - the mode changes only
when you press the Clear button (G).
B: Mode LEDs
Show the current mode or selected
mode
C: B type USB port
For connecting the device to the
workstation
D: Card slot
For inserting the required smart card
E: Card slot LED
Light green when a smart card is inserted
F: Status LED
Show the status of the device
G: Clear button
Clear the device’s memory and changes
the selected mode
Use the Mode button (A) to highlight the required mode and within a few seconds
b. Press and hold the Clear button (G) for a couple of seconds. If the mode changes, the new
mode’s LED stops flashing and remains lit. The Status LED (F) might flash irregularly for a
few seconds and then flashes regularly when the device is ready.
Otherwise, the device remains in the current mode, with the appropriate mode LEDs (B) lit:
2.
19
Red
In Maintenance mode
Red flashing
Maintenance mode selected
Amber
In Initialization mode
Amber flashing
Initialization mode selected
Green
In Operational mode
Green flashing
Operational mode selected
Open a command prompt and navigate to the folder C:\Program Files (x86)\nCipher\nfast\bin.
Bring Your Own Key (BYOK) with Azure Rights Management
3.
Run the following command from the command prompt:
C:\Program Files (x86)\nCipher\nfast\bin> new-world --initialize --km-type=rijndael --module=1 --acs-quorum=2/3
20
4.
When prompted Insert/change card in module (or change module mode), insert the first smart
card (Administrator Card #1) and press ENTER.
5.
When prompted Enter new passphrase, type a PIN value for the first smart card, for example "9351"
and press ENTER. The first smart card is now configured.
Bring Your Own Key (BYOK) with Azure Rights Management
21
6.
When prompted Remove card, remove the smart card.
7.
Insert the second smart card and press ENTER.
8.
When prompted Enter new passphrase, type a PIN value for the second smart card, for example
"9351" and press ENTER. The second smart card is now configured.
Bring Your Own Key (BYOK) with Azure Rights Management
9.
When prompted Remove card, remove the second smart card.
10. Insert the third and last smart card.
22
Bring Your Own Key (BYOK) with Azure Rights Management
11. When prompted Enter new passphrase, type a PIN value for the third smart card, for example
"9351" and press ENTER. The third smart card is now configured.
C:\Program Files (x86)\nCipher\nfast\bin> new-world --initialize --km-type=rijndael --module=1 --acs-quorum=2/3
Create Security World:
Module 1: Select initialization mode and clear unit
11:51:34 WARNING: Module #1: preemptively erasing module to see its slots!
Module 1: 0 cards of 3 written
Module 1 slot 0: empty
Module 1 slot 0: unformatted card
Module 1 slot 0:- passphrase specified - writing card
Module 1: 1 card of 3 written
Module 1 slot 0: remove already-written card #1
Module 1 slot 0: empty
Module 1 slot 0: unformatted card
Module 1 slot 0:- passphrase specified - writing card
Module 1: 2 cards of 3 written
Module 1 slot 0: remove already-written card #2
Module 1 slot 0: empty
Module 1 slot 0: unformatted card
Module 1 slot 0:- passphrase specified - writing card
Card writing complete.
security world generated on module #0; hknso = a2df71a9caf2a50381817410ecb4fbb46
dd09ecb
23
Bring Your Own Key (BYOK) with Azure Rights Management
c:\Program Files (x86)\nCipher\nfast\bin>
12. On the HSM, change the mode back to Operational mode.
13. Finally, run the following command to verify your installation :
C:\Program Files (x86)\nCipher\nfast\bin> nfkminfo.exe
C:\Program Files (x86)\nCipher\nfast\bin>nfkminfo.exe
World
generation 2
state
0x17270000 Initialised Usable Recovery !PINRecovery !ExistingClient
RTC NVRAM FTO !AlwaysUseStrongPrimes SEEDebug
n_modules
1
hknso
hkm
hkmwk
hkre
hkra
hkmc
hkrtc
hknv
hkdsee
hkfto
a2df71a9caf2a50381817410ecb4fbb46dd09ecb
1e1cf012ecc3dc4a7b9783c5451ca9135d32c43a (type Rijndael)
1d572201be533ebc89f30fdd8f3fac6ca3395bf0
bba870bc99c750d36d2547584fd7a3f4540c5539
14404aab49bc8c466074b7197a5ae889fb3437ec
b399a6c6df096ecbe459653a39bcc60e545d5ccf
d6257d85cc8c6fa394f70a28fb2f893a1af1cb56
9594d2ca121b2b3eb41d25265ec888cafadb7890
b772b2471f32a4907eb2c9ab12e04dcd7998ca56
ec7941a880710ff0104c598d05c1d580e074c4cf
hkmnull
ex.client
0100000000000000000000000000000000000000
none
k-out-of-n
2/3
other quora
createtime
nso timeout
ciphersuite
m=2 r=2 nv=2 rtc=2 dsee=2 fto=2
2013-09-20 10:01:28
10 min
DLf1024s160mRijndael
Module #1
generation 2
state
flags
24
0x2 Usable
0x10000 ShareTarget
Bring Your Own Key (BYOK) with Azure Rights Management
n_slots
esn
hkml
2
C1BC-42CD-C501
ed4e070123ee0c65f5cb04dffaf0976fe8da9200
Module #1 Slot
generation
phystype
slotlistflags
state
flags
shareno
shares
TO(PIN)
error
No Cardset
#0 IC 1
1
SmartCard
0x2 SupportsAuthentication
0x4 Admin
0x10000 Passphrase
3
LTNSO(PIN) LTM(PIN) LTR(PIN) LTNV(PIN) LTRTC(PIN) LTDSEE(PIN) LTF
Module #1 Slot
generation
phystype
slotlistflags
state
flags
shareno
shares
error
No Cardset
#1 IC 0
1
SoftToken
0x0
0x2 Empty
0x0
0
OK
OK
No Pre-Loaded Objects
C:\Program Files (x86)\nCipher\nfast\bin>
The above World section corresponds to the aforementioned Security World file “world” on the offline
workstation. This file is located under the path %NFAST_KMDATA%\local, which corresponds to the folder
C:\ProgramData\nCipher\Key Management Data\local.
The first section shows the status of the Security World

state must be marked as Initialised Usable.

Keys’s hashes (hknso, hkm, hkmwk, hkre, hkra, hkmc, hkrtc, hknv, hkdsee, and hkfto) must be
non-zero values.

k-out-of-n is the quorum configured during the new-world process.
The second section marked as Module#1 shows the status of the HSM

state usable indicated that the correct security world is present.
At this stage, backup the world file, the Administrator Card Set, and their PINs into a safe location. It is wise
to have a Security Policy to manage the card set and to keep it well protected. No single person should have
25
Bring Your Own Key (BYOK) with Azure Rights Management
access to more than one card (separation of duties). As already outlined - but it’s worth putting some
emphasis on this - Administrator Card sets are crucial: an unusable card set will render the Security world
unusable, therefore all keys protected by that Security World would become unusable as well.
Installing the Thales CNG provider
You now need to install the Thales CNG provider onto the disconnected workstation as per the Thales
documentation with the Thales cngregister program and point it to the new Security World.
To install the Thales CNG provider, proceed with the following steps:
1.
Open a command prompt and navigate to the folder C:\Program Files (x86)\nCipher\nfast\bin:
2.
Run the following command from the command prompt:
C:\Program Files (x86)\nCipher\nfast\bin> cngregister.exe
EllipticCurve not enabled on module 1
Provider 'nCipher Primitive Provider' registered successfully
Algorithm SHA1 registered successfully
Algorithm SHA224 registered successfully
Algorithm SHA256 registered successfully
Algorithm SHA384 registered successfully
Algorithm SHA512 registered successfully
Algorithm MD5 registered successfully
Algorithm AES registered successfully
Algorithm 3DES registered successfully
Algorithm 3DES_112 registered successfully
Algorithm DES registered successfully
Algorithm RC4 registered successfully
Algorithm RSA registered successfully
Algorithm DSA registered successfully
Algorithm DH registered successfully
Algorithm RNG registered successfully
Provider 'nCipher Security World Key Storage Provider' registered successfully
Interface KEY_STORAGE registered successfully
C:\Program Files (x86)\nCipher\nfast\bin>
Creating a new key
You can now generate a CNG key using the Thales generatekey and cngimport programs. Replace the
label “test” used hereafter in the illustrations with a label of your choice. This label is an identifier of your
key. We advise to use RSA key, with a length of 2048.
Note
We support 1024-bit RSA keys for existing AD RMS customers who have such keys and are migrating
to the Azure Rights Management service.
To generate your key, proceed with the following steps:
1.
Open a command prompt and navigate to the folder C:\Program Files (x86)\nCipher\nfast\bin:
2.
Run the following command from the command prompt:
C:\Program Files (x86)\nCipher\nfast\bin> generatekey simple type=RSA size=2048 protect=module ident=test plainname=test
nvram=no pubexp=
26
Bring Your Own Key (BYOK) with Azure Rights Management
Note
The pubexp is left blank (default) in this illustration, but you can fill in a specific value as per the Thales
documentation.
Please note that it is possible to simply enter generatekey simple and then follow the instructions.
You are guided through the process.
3.
Eventually, run the following command:
C:\Program Files (x86)\nCipher\nfast\bin> cngimport --import -M --key=test -–appname=simple test
Found key 'TEST'
Importing NFKM key.. done
C:\Program Files (x86)\nCipher\nfast\bin>
27

As previously mentioned, replace the label “test” with the same value that was used for the
label of your choice.

Use the “-M” option so that the key is usable at the end. Without this, the resultant key will
be a user-specific key for the current user.
Bring Your Own Key (BYOK) with Azure Rights Management
This will create a Tokenized Key file in your %NFAST_KMDATA%\local folder with a name starting
with
“key_caping_machine--”
followed
by
a
GUID,
e.g.
key_caping_machine—
730009faacba49d54e495b01650d67d54c3293ce. This file contains an encrypted key.
This allow CNG to work with the key you have generated.
4.
List the keys that are available and check the import has been successfully by running the following
command:
C:\Program Files (x86)\nCipher\nfast\bin> cnglist --list-keys
TEST: RSA machine
C:\Program Files (x86)\nCipher\nfast\bin>
5.
Backup this Tokenized Key File in a safe location.
Important note
When you subsequently transfer your key to the Azure Rights Management service, Microsoft
will have a non-recoverable copy of your key. This means that nobody can retrieve your key from the HSMs at
Microsoft. This allows you to retain exclusive control over your key. Therefore it becomes extremely important that
you back up your key and security world safely. Contact Thales for guidance on best practices for this.
Transferring your tenant key over the Internet
If you let Microsoft generate your key (the default) then this section does not apply to you.
If you generated your own key, you must transfer it to the Azure Rights Management service before you use
the Azure Rights Management service.
As outlined before, you have two options available to transfer your key with the highest level of security:
over the Internet or in person. This section covers the former option while the next section covers the latter.
Use the following procedures if you want to transfer your tenant key over the Internet (wire) rather than
travel to a Microsoft facility to transfer the tenant key in person.
28
Bring Your Own Key (BYOK) with Azure Rights Management
If you prefer transferring the tenant key in person, please refer to the procedures outlined in Section §
TRANSFERRING YOUR TENANT KEY IN PERSON.
To transfer the tenant key over the Internet, an Internet-connected workstation will be needed in addition
to the disconnected workstation.
Preparing an Internet-connected workstation
Installing the Rights Management administration cmdlets
The Windows Azure AD Rights Management Administration tool contains the Windows Azure Rights
Management administration module for Windows PowerShell, a set of Windows PowerShell cmdlets28 that
provide administrative (advanced) capabilities for the Azure Rights Management service.
You will need these cmdlets on an on-going basis to manage your Azure Rights Management service’s
tenant, so this is a good time to get this done with.
Note
Even if you have installed the Windows Azure AD Rights Management Administration Tool before,
please upgrade to the latest version as it includes new cmdlets that we will need for this procedure. For additional
information and instructions, see the Microsoft TechNet Article INSTALLING WINDOWS POWERSHELL FOR AZURE RIGHTS
MANAGEMENT29.
Prior installing this tool, you must have Microsoft Online Services Sign-In Assistant (MOS SIA) 7.0 installed.
Note
The Microsoft Online Services Sign-In Assistant (MOS SIA) 7.0 provides sign-in capabilities to the Azure
Rights Management service. The MOS SIA is indeed used to authenticate users to the service through a set of
dynamic link library files (DLLs) and a Windows service as described in the community article DESCRIPTION OF
MICROSOFT ONLINE SERVICES SIGN-IN ASSISTANT (MOS SIA)30.
To install the Microsoft Online Sign-In Assistant (MOS SIA) 7.0, proceed with the following steps:
1.
Open a browsing session and navigate to the following link Microsoft Online Services Sign-In
Assistant for IT Professionals RTW 31 and click Download.
2.
In the Choose the download you want page, select the appropriate version x64 or x86
(msoidcli_64bit.msi or msoidcli_32bit.msi) regarding the workstation configuration and save it locally.
3.
Double-click the downloaded file. The Microsoft Online Services Sign-in Assistant Setup wizard
opens.
28
WINDOWS AZURE RIGHTS MANAGEMENT CMDLETS: http://msdn.microsoft.com/library/windowsazure/dn629398.aspx
29
INSTALLING WINDOWS POWERSHELL FOR AZURE RIGHTS MANAGEMENT: http://technet.microsoft.com/en-us/library/jj585012.aspx
30
DESCRIPTION OF MICROSOFT ONLINE SERVICES SIGN-IN ASSISTANT (MOS SIA): http://community.office365.com/en-us/w/office/534.aspx
Microsoft Online Services Sign-In Assistant for IT Professionals RTW:
http://www.microsoft.com/download/en/details.aspx?id=28177
31
29
Bring Your Own Key (BYOK) with Azure Rights Management
4.
On the license terms page, select I accept the terms in the License Agreement and Privacy
Statement and click Install. A User Account Control dialog pops up.
5.
In the User Account Control dialog, click Yes to execute the setup.
6.
On the completion page, click Finish.
To now install Windows Azure AD Rights Management Administration tool, proceed with the following
steps:
32
30
1.
Open a browsing session and navigate to the following link: Windows Azure AD Rights Management
Administration Tool32 click Download.
2.
In the Choose the download you want page, select the appropriate version x64 or x86
(WindowsAzureADRightsManagementAdministration_x64.exe
or
Windows Azure AD Rights Management Administration Tool: http://go.microsoft.com/fwlink/?LinkId=257721
Bring Your Own Key (BYOK) with Azure Rights Management
WindowsAzureADRightsManagementAdministration_x86.exe)
configuration and save it locally.
31
regarding
the
workstation
3.
Double-click the downloaded file. A Microsoft Rights Management Administration Setup wizard
opens up.
4.
On the Welcome page, select the Next option.
5.
On the End-User License Agreement page, select I accept the terms in the License Agreement
and click Next.
6.
On the Ready to Install page, click Install.
Bring Your Own Key (BYOK) with Azure Rights Management
7.
On the completion page, click Finish.
The cmdlets of the Microsoft Rights Management administration module for Windows PowerShell will be
used in the next section with for getting the current configuration of the Azure Rights Management service.
Retrieving your Azure Active Directory tenant ID
To retrieve the Azure Active Directory tenant ID, proceed with the following steps:
1.
Open an (elevated) Windows PowerShell command prompt, run the following command:
PS C:\Users\Administrator> Import-Module aadrm
PS C:\Users\Administrator> Connect-AadrmService
You will be prompted for your credentials.
2.
32
In the Windows PowerShell Credential Request window that opens up, enter your Azure Rights
Management service’s tenant administrator credentials and wait to be authenticated.
Bring Your Own Key (BYOK) with Azure Rights Management
3.
View the current configuration for the tenant by running Get-AadrmConfiguration cmdlet:
PS C:\Users\Administrator> Get-AadrmConfiguration
This will display information about your Azure Rights Management service’s tenant configuration.
PS C:\Users\Administrator> Get-AadrmConfiguration
BPOSId
: 2971a9f9-454c-4be2-9b86-5b3513ecb22e
RightsManagementServiceId
LicensingIntranetDistributionPointUrl
LicensingExtranetDistributionPointUrl
CertificationIntranetDistributionPointUrl
:
:
:
:
6c8e9100-1168-4085-90f0-22293f9e5a0d
https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/_wmcs/licensing
https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/_wmcs/licensing
https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/
_wmcs/certification
CertificationExtranetDistributionPointUrl : https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/
_wmcs/certification
AdminConnectionUrl
: https://admin.eu.aadrm.com/admin/admin.svc/Tenants/6c8e9100-1168-4085-90f022293f9e5a0d
OnPremiseDomainName
:
Keys
: {22327901-6fdd-4dfc-81c7-04a1eb3c1afb}
CurrentLicensorCertificateGuid
: 22327901-6fdd-4dfc-81c7-04a1eb3c1afb
Templates
: {72fb2c43-cc9d-43ba-a02a-3320b2a869be, 9567b5c8-217d-46d2-b529-28c3a0d1ca7d}
FunctionalState
: Disabled
SuperUsersEnabled
: Disabled
SuperUsers
: {}
AdminRoleMembers
: {}
KeyRolloverCount
: 0
ProvisioningDate
: 12/20/2013 2:57:14 PM
IPCv3ServiceFunctionalSate
: Enabled
DevicePlatformState
: {Windows -> True, WindowsStore -> True, WindowsPhone -> True,
Mac -> True…}
FciEnabledForConnectorAuthorization
: True
4.
33
Save the GUID from the first line (BPOSId). This is your Azure Active Directory tenant ID. You will
need this information when you prepare your key for upload. Considering the above output, our
Azure Active Directory tenant ID is in our configuration 2971a9f9-454c-4be2-9b865b3513ecb22e.
Bring Your Own Key (BYOK) with Azure Rights Management
Downloading the BYOK toolset
To download the BYOK tools for Microsoft Rights Management service (BYOK toolset), proceed with the
following steps:
1.
Open a browsing session and download the BYOK toolset33 for your region from the Microsoft
Download Center. The package is named BYOK-tools-EU.zip for Europe, BYOK-tools-NA.zip for
North America, and BYOK-tools-AP.zip for Asia-Pacific.
This toolset includes the following:
2.

A Key Exchange Key (KEK) package that has a name beginning with "BYOK-KEK-pkg-".

A Security World package that has a name beginning with "BYOK-SecurityWorld-pkg-".

A python script named verifykeypackage.py.

A command line executable named KeyTransferRemote.exe and associated DLLs.

A Visual C++ redistribution package named vcredist_x64.exe.
Copy the toolset content to a USB drive or other portable storage, for example the E: drive in our
illustration.
You will need to install this by plugging the USB drive on your disconnected workstation as per next section.
Installing the BYOK toolset on the disconnected workstation
Perform all steps in this section on your disconnected workstation.
To install the BYOK toolset, proceed with the following steps:
1.
Plug the USB drive on your workstation and copy the previously downloaded BYOK toolset from the
USB drive into any folder on the workstation, for example C:\Program Files\BYOK_TOOLSET in our
configuration. Open a command prompt ant run the following commands:
c:\Users\Administrator>cd %ProgramFiles%
c:\Program Files>mkdir BYOK_TOOLSET
c:\Program Files>robocopy /mir E:\ "%ProgramFiles"
The USB drive correspond to the E: drive letter in our configuration. Adapt the command to reflect
33
34
BYOK tools for Microsoft Rights Management service: http://go.microsoft.com/fwlink/?LinkId=335781
Bring Your Own Key (BYOK) with Azure Rights Management
your current configuration.
2.
From the previous folder, run vcredist_x64.exe to install the Visual C++ runtime components for
Visual Studio 2012. A Microsoft Visual C++ 2012 Redistributable (x64) opens up.
3.
Click I agree to the license terms and conditions, and then click Install.
4.
Click Close.
Validating the downloaded package on the disconnected workstation
This step is optional. You would do this if you have doubts about the integrity of the toolset you downloaded.
On your disconnected workstation, proceed with the following steps:
1.
35
Ensure that the nShield Edge device is connected to your disconnected workstation using the
supplied USB cable, which should be the case at this stage if you’ve followed the instructions in
order. The HSM is indeed required to run the provided tooling to verify the downloaded package.
Bring Your Own Key (BYOK) with Azure Rights Management
Important note
A security world MUST also have been created as per section CREATING A SECURITY WORLD before
in this document. A fully initialized HSM is indeed required to verify the downloaded package. This should also be
normally the case at this stage if you’ve followed the instructions in order.
2.
Open elevated command prompt and run the following command to add the python binary in the
PATH environment variable:
c:\Windows\system32> set PATH=%PATH%;"%nfast_home%\bin";"%nfast_home%\python\bin"
3.
Still from the command prompt, navigate to the folder where the toolset has been copied to:
c:\Windows\system32> cd %ProgramFiles%\BYOK_TOOLSET
c:\Program Files\BYOK_TOOLSET>_
4.
Run the verifykeypackage.py script to validate that:

The Key Exchange Key (KEK) included the toolset is generated in a genuine Thales HSM.

The Azure Rights Management service’s security world, whose hash is included in the
toolset, was generated in a genuine Thales HSM.

The Key Exchange Key (KEK), which will encrypt your key during upload, is non-exportable.
c:\Program Files\BYOK_TOOLSET> python verifykeypackage.py -k .\packages\<KEK> -w .\packages\<SecurityWorldpackage>
Where:


<KEK> is the Key Exchange Key (KEK) package for your region:

BYOK-KEK-pkg-EU-1 for Europe.

BYOK-KEK-pkg-NA-1 for North America.

BYOK-KEK-pkg-AP-1 for Asia-Pacific.
<SecurityWorldpackage> is the Security World package for your region:

BYOK-SecurityWorld-pkg-EU-1 for Europe.

BYOK-SecurityWorld-pkg-NA-1 for North America.

BYOK-SecurityWorld-pkg-AP-1 for Asia-Pacific.
This correspond to the following command in our configuration:
36
Bring Your Own Key (BYOK) with Azure Rights Management
c:\Program Files\BYOK_TOOLSET> python verifykeypackage.py -k .\packages\BYOK-KEK-pkg-EU-1
SecurityWorld-pkg-EU-1
37
Bring Your Own Key (BYOK) with Azure Rights Management
-w .\packages\BYOK-
C:\Program Files\BYOK_TOOLSET>python verifykeypackage.py -k .\packages\BYOK-KEK-pkg-EU-1
SecurityWorld-pkg-EU-1
*****Input Parameters******
Key package file:
World package file:
'.\packages\BYOK-KEK-pkg-EU-1'
'.\packages\BYOK-SecurityWorld-pkg-EU-1'
*****Read Key Package******
Finished reading the required fields from the key package...
*****Read World Package******
Finished reading the required fields from the world package...
*****Verify Warrant for the key******
*****Verify Warrant for the world******
*****Verify generation info for the Key******
Checking ESN in the warrant and key data...
Get KLF from the warrant...
Importing the KLF public key...
Checking the KLF hash...
Verify the module state message using KLF...
Deserialize the module state message...
Get KML from key generation certificate...
Import KML public key...
38
Bring Your Own Key (BYOK) with Azure Rights Management
-w .\packages\BYOK-
Check the KML hash...
Verify the generation certificate using KML...
Deserialize the generation certificate...
Compare key hash from the package and the generation certificate...
Load the public blob for KEK...
Compare KEK hash from the package and the generation certificate...
Verify that KEK ACLs are as expected...
*****Verify generation info for the world******
Checking ESN in the warrant and key data...
Get KLF from the warrant...
Importing the KLF public key...
Checking the KLF hash...
Verify the module state message using KLF...
Deserialize the module state message...
Get KML from key generation certificate...
Import KML public key...
Check the KML hash...
Verify the generation certificate using KML...
Deserialize the generation certificate...
Compare key hash from the package and the generation certificate...
===========================================================================
VERIFICATION SUCCESSFUL
===========================================================================
*
*
*
*
Security world chains up to the Thales root
Key Exchange Key chains up to the Thales root
Key Exchange Key is blobbed to the verified security world
Key Exchange Key ACLs are as expected
===========================================================================
Verified Security World Generation Certificate Information
===========================================================================
Root signer key hash: 59178a47 de508c3f 291277ee 184f46c4 f1d9c639
Verify at http://www.thales-esecurity.com/msrms/cloud
-------------------------------------------------------------KM Hash: b3fc319f b23c9db7 e9248c27 f5967550 da7ecce0
--------------------------------------------------------------
===========================================================================
Verified Key Exchange Key Generation Certificate Information
===========================================================================
Root signer key hash: 59178a47 de508c3f 291277ee 184f46c4 f1d9c639
Verify at http://www.thales-esecurity.com/msrms/cloud
-------------------------------------------------------------Key Exchange Key Identifier: xferwrapping,kek-prod-eu-1
Key Exchange Key Hash:
ede3e33c d1ffda02 3bd1e319 f2bf156a b4b5e90d
-------------------------------------------------------------KeyGenParams.type= RSAPrivate
.params.flags= 0x0
.lenbits= 2048
39
Bring Your Own Key (BYOK) with Azure Rights Management
-------------------------------------------------------------ACLs on the key exchange key private blob:
ACL.groups[0].flags= 0x0
.limits= empty
.actions[0].type= OpPermissions
.details.perms= UseAsBlobKey|GetACL
.actions[1].type= MakeBlob
.details.flags= AllowKmOnly|AllowNonKm0|kmhash_present
.kmhash= b3fc319f b23c9db7 e9248c27 f5967550 da7ecce0
-------------------------------------------------------------Details for key exchange key public blob loaded into the HSM:
Cmd_GetKeyInfoEx_Reply.ver= 0
.flags= 0x0
.type= RSAPublic
.length= 2048
.hash= ede3e33c d1ffda02 3bd1e319 f2bf156a b4b5e90d
--------------------------------------------------------------
******************
Result: SUCCESS
******************
C:\Program Files\BYOK_TOOLSET>
If the packages are successfully validated, the script should display “Result: SUCCESS."
This script validates the signer chain up to the Thales root key. The hash of this root key is embedded in the
script. Its value should be 59178a47 de508c3f 291277ee 184f46c4 f1d9c639. This same hash is also
published on the Thales e-Security website34.
Preparing your key for upload to the Azure Rights Management service
Continue to perform all steps in this section on your disconnected workstation.
Creating a copy of your key with reduced permissions
To reduce the permissions on your tenant key, proceed with the following steps:
1.
Open an elevated command prompt if needed and navigate to the folder where you’ve copied the
BYOK toolset from the USB drive, for example C:\Program Files\BYOK_TOOLSET in our configuration.
2.
From the elevated command prompt, run the following command, replacing test with whatever you
chose as your key identifier in Section § CREATING A NEW KEY. This utility reduces the permissions on
the key.
C:\> KeyTransferRemote.exe -ModifyAcls -KeyAppName simple -KeyIdentifier test -ExchangeKeyPackage <KEK> NewSecurityWorldPackage <SecurityWorldpackage>
34
40
Thales e-Security web site: https://www.thales-esecurity.com/
Bring Your Own Key (BYOK) with Azure Rights Management
Where:


<KEK> is the Key Exchange Key (KEK) package for your region:

BYOK-KEK-pkg-EU-1 for Europe.

BYOK-KEK-pkg-NA-1 for North America.

BYOK-KEK-pkg-AP-1 for Asia-Pacific.
<SecurityWorldpackage> is the Security World package for your region:

BYOK-SecurityWorld-pkg-EU-1 for Europe.

BYOK-SecurityWorld-pkg-NA-1 for North America.

BYOK-SecurityWorld-pkg-AP-1 for Asia-Pacific.
This correspond to the following command in our configuration:
c:\Program Files\BYOK_TOOLSET>KeyTransferRemote.exe -ModifyAcls -KeyAppName simple -KeyIdentifier test -ExchangeKeyPackage
.\packages\BYOK-KEK-pkg-EU-1 -NewSecurityWorldPackage .\packages\BYOK-SecurityWorld-pkg-EU-1
When the command runs, you will be asked to plug in your security world admin cards.
41
Bring Your Own Key (BYOK) with Azure Rights Management
42
Bring Your Own Key (BYOK) with Azure Rights Management
c:\Program Files\BYOK_TOOLSET>KeyTransferRemote.exe -ModifyAcls -KeyAppName simple -KeyIdentifier test -ExchangeKeyPackage
.\packages\BYOK-KEK-pkg-EU-1
-NewSecurityWorldPackage .\packages\BYOK-SecurityWorld-pkg-EU-1
****************
User Information
****************
Machine Name: 20012-EDGEHSM
User Name:
Administrator
User Domain: 20012-EDGEHSM
Getting hashes for module keys...........................SUCCESS
***********
Module Keys
***********
KML Hash: 7143e6df0470577c253d8a96dcec8fe2b3da17e6
KLF Hash: ace6aa4fec202ca5069369c3825aac0fbcd98ef6
KM Hash:
c0021bc96667ccdc0e96f4f3d4e6525b95e34f29
KMWK Hash: 1d572201be533ebc89f30fdd8f3fac6ca3395bf0
Loading user key.........................................SUCCESS
Loading user key's private blob..........................SUCCESS
********
User Key
********
Type:
RSAPrivate
Length:
2048
Key Hash: e2f23fdce7e51ff326bc4d898e5b160da8286e11
ACLs:
.n_groups= 2
.groups[
0].flags= none 0x00000000
.n_limits= 0
.n_actions= 1
.actions[
0].type= OpPermissions
.details.oppermissions.perms= DuplicateHandle UseAsCertificate GetAppData ReduceACL
Decrypt UseAsBlobKey Sign GetACL SignModuleCert 0x0000b52b
.certifier absent
.certmech absent
.moduleserial absent
.groups[
1].flags= certifier_present FreshCerts 0x00000003
.n_limits= 0
.n_actions= 3
.actions[
0].type= OpPermissions
.details.oppermissions.perms= DuplicateHandle ExportAsPlain GetAppData SetAppData
ReduceACL ExpandACL GetACL 0x0000207d
.actions[
1].type= MakeBlob
.details.makeblob.flags= AllowKmOnly AllowNonKm0 AllowNullKmToken 0x00000023
.kmhash absent
43
Bring Your Own Key (BYOK) with Azure Rights Management
.kthash absent
.ktparams absent
.blobfile absent
.actions[
2].type= MakeArchiveBlob
.details.makearchiveblob.flags= none 0x00000000
.mech= Any
.kahash absent
.blobfile absent
.certifier= 20 bytes
a3cfb7d8 006a6f18 aa482258 8706b034 28404271
.certmech absent
.moduleserial absent
Loading exchange key.....................................SUCCESS
********************
Exchange Key Package
********************
Exchange key application name: xferwrapping
Exchange key identifier:
kek-prod-eu-1
Exchange key hash:
ede3e33cd1ffda023bd1e319f2bf156ab4b5e90
d
Public key blob:
System.Byte[]
Generating module's ESN:
3E55-C8BD-46FC
Key creation message:
System.Byte[]
Key creation signature:
NCipher.MCipherText
Module state message:
System.Byte[]
Module state signature:
NCipher.MCipherText
Module warrant:
System.Byte[]
Loading exchange key public blob.........................SUCCESS
************
Exchange Key
************
Type:
RSAPublic
Length:
2048
Key Hash: ede3e33cd1ffda023bd1e319f2bf156ab4b5e90d
ACLs:
.n_groups= 1
.groups[
0].flags= none 0x00000000
.n_limits= 0
.n_actions= 3
.actions[
0].type= OpPermissions
.details.oppermissions.perms= DuplicateHandle ExportAsPlain GetAppData SetAppData
ReduceACL ExpandACL Encrypt Verify UseAsBlobKey GetACL 0x000026fd
.actions[
1].type= MakeBlob
.details.makeblob.flags= AllowKmOnly AllowNonKm0 AllowNullKmToken 0x00000023
.kmhash absent
.kthash absent
.ktparams absent
.blobfile absent
.actions[
2].type= MakeArchiveBlob
.details.makearchiveblob.flags= none 0x00000000
.mech= Any
.kahash absent
.blobfile absent
.certifier absent
.certmech absent
.moduleserial absent
Loading exchange key.....................................SUCCESS
**********************
Security World Package
**********************
Security world key hash:
0da7ecce0
Generating module's ESN:
Security world key creation message:
Security world key creation signature:
Module state message:
Module state signature:
Module warrant:
b3fc319fb23c9db7e9248c27f596755
B3C4-F264-3066
System.Byte[]
NCipher.MCipherText
System.Byte[]
NCipher.MCipherText
System.Byte[]
Insert Admin Card:
Module 1 slot 0: empty
Module 1 slot 0: Admin Card #3
44
Bring Your Own Key (BYOK) with Azure Rights Management
Module 1 slot 0:- passphrase supplied - reading card
Module 1 slot 0: Admin Card #3: already read
Module 1 slot 0: empty
Module 1 slot 0: Admin Card #2
Module 1 slot 0:- passphrase supplied - reading card
Card reading complete.
Loading admin card set...................................SUCCESS
*******
NSO Key
*******
Type:
DSAPrivate
Length:
1024
Key Hash: a3cfb7d8006a6f18aa4822588706b03428404271
ACLs:
.n_groups= 1
.groups[
0].flags= none 0x00000000
.n_limits= 1
.limits[
0].type= Time
.details.time.seconds= 0x00000258 600
.n_actions= 2
.actions[
0].type= OpPermissions
.details.oppermissions.perms= UseAsCertificate ReduceACL GetACL 0x00002022
.actions[
1].type= MakeBlob
.details.makeblob.flags= AllowNonKm0ktparams_present AllowNullKmToken 0x00000032
.kmhash absent
.kthash absent
.ktparams.flags= none 0x00000000
.sharesneeded= 0x00000000 0
.sharestotal= 0x00000000 0
.timelimit= 0x00000000 0
.blobfile absent
.certifier absent
.certmech absent
.moduleserial absent
Modifying ACLs on private key............................SUCCESS
********
User Key
********
Type:
RSAPrivate
Length:
2048
Key Hash: e2f23fdce7e51ff326bc4d898e5b160da8286e11
ACLs:
.n_groups= 1
.groups[
0].flags= none 0x00000000
.n_limits= 0
.n_actions= 4
.actions[
0].type= OpPermissions
.details.oppermissions.perms= DuplicateHandle ReduceACL Decrypt Sign GetACL 0x00003121
.actions[
1].type= MakeBlob
.details.makeblob.flags= AllowKmOnly AllowNonKm0 kmhash_present AllowNullKmToken
0x00000027
.kmhash= 20 bytes
c0021bc9 6667ccdc 0e96f4f3 d4e6525b 95e34f29
.kthash absent
.ktparams absent
.blobfile absent
.actions[
2].type= MakeBlob
.details.makeblob.flags= AllowKmOnly AllowNonKm0 kmhash_present AllowNullKmToken
0x00000027
.kmhash= 20 bytes
b3fc319f b23c9db7 e9248c27 f5967550 da7ecce0
.kthash absent
.ktparams absent
.blobfile absent
.actions[
3].type= MakeArchiveBlob
.details.makearchiveblob.flags= kahash_present 0x00000001
.mech= BlobCryptv2kRSAeRijndaelCBC0hSHA256mSHA256HMAC
.kahash= 20 bytes
ede3e33c d1ffda02 3bd1e319 f2bf156a b4b5e90d
.blobfile absent
.certifier absent
.certmech absent
.moduleserial absent
Making new private key blob..............................SUCCESS
45
Bring Your Own Key (BYOK) with Azure Rights Management
Removing recovery key blob...............................SUCCESS
Saving modified key as C:\ProgramData\nCipher\Key Management Data\loca
l\key_xferacld_test......................................SUCCESS
Saving logfile as c:\Program Files\BYOK_TOOLSET\ModifyAcls-key_xferacl
d_test.log...............................................SUCCESS
Result: SUCCESS
c:\Program Files\BYOK_TOOLSET>
When the command completes, you will see "Result: SUCCESS".
This will create in your %NFAST_KMDATA%\local folder a copy of your tenant key with reduced permissions
in a file named key_xferacId_test, replacing test at the end of the filename with whatever you chose as your
key identifier in Section § CREATING A NEW KEY.
Inspecting the new copy of the key
This step is optional. You can now run the Thales utilities aclprint.py and kmfile-dump.exe to inspect that the
new key has no more permissions than you want to give Microsoft and consequently to confirm the minimal
permissions on your tenant key.
Proceed with the following steps:
1.
From the above command prompt, run the following command with the Thales utility aclprint.py,
replacing test with whatever you chose as your key identifier in Section § CREATING A NEW KEY.
c:\Program Files\BYOK_TOOLSET>"%nfast_home%\bin\preload.exe" -m 1 -A xferacld -K test "%nfast_home%\python\bin\python"
"%nfast_home%\python\examples\aclprint.py"
46
Bring Your Own Key (BYOK) with Azure Rights Management
c:\Program Files\BYOK_TOOLSET>"%nfast_home%\bin\preload.exe" -m 1 -A xferacld -K test "%nfast_home%\python\bin\python"
"%nfast_home%\python\examples\aclprint.py"
Stored Unsure -- multiple objects on module #1
Loaded xferacld test key (RSAPrivate) on modules 1
Executing python C:\Program Files (x86)\nCipher\nfast\python\examples\
aclprint.py
Unsure -- multiple objects
acl.groups[0].flags= 0x0
.actions[0].type= OpPermissions
.details.perms= DuplicateHandle|ReduceACL|Decrypt|Sign|GetACL
.actions[1].type= MakeBlob
.details.flags= AllowKmOnly|AllowNonKm0|kmhash_present|AllowNullKmToken
.kmhash= Admin key: km (c002...)
.actions[2].type= MakeBlob
.details.flags= AllowKmOnly|AllowNonKm0|kmhash_present|AllowNullKmToken
.kmhash= b3fc319f b23c9db7 e9248c27 f5967550 da7ecce0
.actions[3].type= MakeArchiveBlob
.details.flags= kahash_present
.mech= BlobCryptv2kRSAeRijndaelCBC0hSHA256mSHA256HMAC
.kahash= ede3e33c d1ffda02 3bd1e319 f2bf156a b4b5e90d
c:\Program Files\BYOK_TOOLSET>
Note
2.
You should refer to the Thales user guide for how to interpret the output.
From the above command prompt, run the following command with the Thales utility kmfiledump.exe, replacing test in key_xferacId_test with whatever you chose as your key identifier in
Section § CREATING A NEW KEY.
c:\Program Files\BYOK_TOOLSET>"%nfast_home%\bin\kmfile-dump.exe" "%NFAST_KMDATA%\local\key_xferacld_test"
47
Bring Your Own Key (BYOK) with Azure Rights Management
c:\Program Files\BYOK_TOOLSET>"%nfast_home%\bin\kmfile-dump.exe" "%NFAST_KMDATA%\local\key_xferacld_test"
AppName
xferacld
Ident
test
Name
test
HashKA
e2f23fdce7e51ff326bc4d898e5b160da8286e11
BlobKA
Blob format = Module
Module key = KM_sw [c0021bc96667ccdc0e96f4f3d4e6525b95e34f29]
BlobPubKA
Blob format = Module
Module key = KM_wk [1d572201be533ebc89f30fdd8f3fac6ca3395bf0]
CertGenKA
DSA 8a246ef6f4c14e70729c1845431105ad2d089d15 6da5e45ca5d22a82ccb61
4f339bb4c30b242cd87
MesgGenKA
00000000 : 02000000 00000000 02000000 00000000 : ................
00000010 : 00080000 04000000 00000000 00000000 : ................
00000020 : 01000000 01000000 2bb50000 00000000 : ........+.......
00000030 : 01000000 01000000 45d7dc63 abd676d3 : ........E..c..v.
00000040 : 11b13b7e 61fb2e28 3d4cec1f 01000000 : ..;~a..(=L......
00000050 : 01000000 02000000 07000000 c0021bc9 : ................
00000060 : 6667ccdc 0e96f4f3 d4e6525b 95e34f29 : fg........R[..O)
00000070 : 03000000 00000000 03000000 01000000 : ................
00000080 : 7d200000 02000000 23000000 03000000 : } ......#.......
00000090 : 00000000 00000000 a3cfb7d8 006a6f18 : .............jo.
000000a0 : aa482258 8706b034 28404271 00000000 : .H"X...4(@Bq....
000000b0 : 01000000 01000000 a6878933 0bc30b34 : ...........3...4
000000c0 : 9553db87 cdaad379 4c3e3bf4 01000000 : .S.....yL>;.....
000000d0 : 01000000 03000000 01000000 98000000 : ................
000000e0 : 70ca1b37 dca07543 f7cfc5b6 d0be471a : p..7..uC......G.
000000f0 : c6d8c1b4 e2f23fdc e7e51ff3 26bc4d89 : ......?.....&.M.
00000100 : 8e5b160d a8286e11 ******** ******** : .[...(n.********
ESNGen
C1BC-42CD-C501
BlobPubKML
Blob format = Module
Module key = KM_wk [1d572201be533ebc89f30fdd8f3fac6ca3395bf0]
CertKMLaESN
DSA 780712ea6508182a33b137d420bd388bd42bd6f7 6657d0265726e248097eb6d6cf26cbddc29c797a
CertModuleState
DSA b70b99485635e1eea7abca44a4e867889d614e0e a13d2f133e1923b605eb3ebcb8e1cde33f76e1b6
MesgModuleState
00000000 : 04000000 00000000 05000000 02000000 : ................
00000010 : 0f000000 43314243 2d343243 442d4335 : ....C1BC-42CD-C5
00000020 : 30310000 03000000 7143e6df 0470577c : 01......qC...pW|
00000030 : 253d8a96 dcec8fe2 b3da17e6 03000000 : %=..............
48
Bring Your Own Key (BYOK) with Azure Rights Management
00000040
00000050
00000060
00000070
00000080
00000090
000000a0
000000b0
000000c0
000000d0
000000e0
000000f0
00000100
00000110
00000120
00000130
00000140
00000150
00000160
00000170
00000180
00000190
000001a0
000001b0
000001c0
000001d0
000001e0
000001f0
00000200
00000210
00000220
00000230
00000240
00000250
00000260
00000270
00000280
00000290
000002a0
000002b0
000002c0
000002d0
000002e0
000002f0
00000300
00000310
00000320
00000330
00000340
00000350
00000360
00000370
00000380
00000390
000003a0
000003b0
000003c0
000003d0
000003e0
000003f0
00000400
00000410
00000420
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
80000000
0bad776e
e9db692e
604810e0
5be854ed
d601b6c1
68c0a081
5fc3f903
97126ee5
a7e6c6ad
cf819d1b
62ff5662
3eb2e37f
26ad8f83
394d0627
7f0c4827
b39cfd57
fb0bfee7
80000000
08b0375e
f59a0cfb
6e8eede5
db23ccb0
6e49ada0
10c04142
a70be23c
37c44b1d
ec202ca5
03000000
9540f47c
1706a521
986ada1c
f1063748
17518aee
e0b87868
58fff58c
c7fe132b
f798695d
80000000
0901318a
6a817077
88831c1c
e8a4af14
f9b61325
0fd3c920
505e26f0
6340f91a
32ecd98b
6fbb9c29
a0cf6435
3a6e35f4
f891f771
28e1bd59
af8e9b79
fde9b54e
a3cfb7d8
28404271
6fa5c737
59374366
be533ebc
84000000
0e96f4f3
49000000
0b86a077
e6a14ae2
8ad5fa61
2ea75007
f9903688
d6a89336
733a07e6
60533897
14000000
b8261b70
15eafce5
03d9950d
7651ae8d
6ff6c965
88aae424
9aea3a92
556f5425
b96287c1
cd9eaa71
ac767e91
dee1f985
100d67ff
f2dce1be
15890006
e5180d63
a6324be4
0a000000
069369c3
80000000
0bad776e
e9db692e
604810e0
5be854ed
d601b6c1
68c0a081
5fc3f903
97126ee5
a7e6c6ad
cf819d1b
62ff5662
3eb2e37f
26ad8f83
394d0627
7f0c4827
b39cfd57
fb0bfee7
80000000
82c8334d
98ca3938
f9f6d0f1
f4917f8b
4a82970f
337f9107
8599e888
b70f7092
006a6f18
4f4e0000
c0235723
89000000
89f30fdd
25000000
d4e6525b
********
7eb4c40f
b07efee1
5738e855
7b7e5532
8ca3ad35
b957f1e9
e6b3e351
7aaeffc2
b794ab05
036fc6ba
20bc3ff7
3051f50b
8643128e
9c72e0d7
f87afd19
fd0c65b1
3cc2b044
c040d05f
114d888b
f467bff9
7eacc228
eceabe5f
0d12075b
a01fcea7
1ea603b9
99823c31
04000000
825aac0f
0b86a077
e6a14ae2
8ad5fa61
2ea75007
f9903688
d6a89336
733a07e6
60533897
14000000
b8261b70
15eafce5
03d9950d
7651ae8d
6ff6c965
88aae424
9aea3a92
556f5425
b96287c1
1aeab281
5c5b586c
1e7acda7
c4c19146
36a599fd
a46293e0
6a56293d
6f013bb2
0a000000
aa482258
06000000
29720a6e
49000000
8f3fac6c
c0021bc9
95e34f29
********
9540f47c
1706a521
986ada1c
f1063748
17518aee
e0b87868
58fff58c
c7fe132b
f798695d
80000000
0901318a
6a817077
88831c1c
e8a4af14
f9b61325
0fd3c920
505e26f0
6340f91a
eaa85aa7
d82f3f8a
ff9b78d0
a574513b
c15efc30
e9f9e511
19f1d396
9523d971
ace6aa4f
bcd98ef6
7eb4c40f
b07efee1
5738e855
7b7e5532
8ca3ad35
b957f1e9
e6b3e351
7aaeffc2
b794ab05
036fc6ba
20bc3ff7
3051f50b
8643128e
9c72e0d7
f87afd19
fd0c65b1
3cc2b044
c040d05f
1e0d4fc9
9085feeb
ed06ddc4
5a390310
42e1bb36
e13bb06d
5924ca93
59475fe2
05000000
8706b034
03000000
0fbf59f5
1d572201
a3395bf0
6667ccdc
89000000
********
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
c:\Program Files\BYOK_TOOLSET>
49
Bring Your Own Key (BYOK) with Azure Rights Management
.......w~....@.|
..wn..J..~.....!
..i....aW8.U.j..
`H....P.{~U2..7H
[.T...6....5.Q..
.......6.W....xh
h...s:.....QX...
_...`S8.z......+
..n...........i]
.....&.p.o......
........ .?...1.
b.Vb....0Q..j.pw
>...vQ...C......
&...o..e.r......
9M.'...$.z.....%
..H'..:...e....
...WUoT%<..DP^&.
.....b...@._c@..
.......q.M....Z.
..7^.v~..g.../?.
........~..(..x.
n.....g...._.tQ;
.#.........[.^.0
nI..............
..AB...c........
...<.2K...<1.#.q
7.K............O
. ,...i..Z......
...........w~...
.@.|..wn..J..~..
...!..i....aW8.U
.j..`H....P.{~U2
..7H[.T...6....5
.Q.........6.W..
..xhh...s:.....Q
X..._...`S8.z...
...+..n.........
..i].....&.p.o..
............ .?.
..1.b.Vb....0Q..
j.pw>...vQ...C..
....&...o..e.r..
....9M.'...$.z..
...%..H'..:...e.
... ...WUoT%<..D
P^&......b...@._
c@............O.
2.....3M\[Xl....
o..)..98.z......
..d5.......FZ9..
:n5.....6...B..6
...qJ....b...;.m
(..Y3...jV)=Y$..
...y....o.;.YG_.
...N..p.........
.....jo..H"X...4
(@BqON..........
o..7.#W#)r.n..Y.
Y7Cf....I....W".
.S>......?.l.9[.
....%.......fg..
......R[..O)....
I...************
Note
You should refer to the Thales user guide for how to interpret the output.
Encrypting your key to Microsoft’s Key Exchange Key
Proceed with the following steps:
1.
From the above command prompt, run the following command, replacing test with the identifier
you used to generate the key in Section § CREATING A NEW KEY:
c:\Program Files\BYOK_TOOLSET>KeyTransferRemote.exe -Package -KeyIdentifier testkey -ExchangeKeyPackage <KEK> NewSecurityWorldPackage <SecurityWorldpackage> -TenantBposId <GUID> -KeyFriendlyName <FirstKeyLabel>
Where:


<KEK> is the Key Exchange Key (KEK) package for your region:

BYOK-KEK-pkg-EU-1 for Europe.

BYOK-KEK-pkg-NA-1 for North America.

BYOK-KEK-pkg-AP-1 for Asia-Pacific.
<SecurityWorldpackage> is the Security World package for your region:

BYOK-SecurityWorld-pkg-EU-1 for Europe.

BYOK-SecurityWorld-pkg-NA-1 for North America.

BYOK-SecurityWorld-pkg-AP-1 for Asia-Pacific.

<GUID> is your Azure Active Directory tenant ID that you retrieved in Section § RETRIEVING YOUR
AZURE ACTIVE DIRECTORY TENANT ID, for example 2971a9f9-454c-4be2-9b86-5b3513ecb22e in our
configuration.

<FirstKeyLabel> with a label that will be used for your output file name (see below).
This correspond to the following command in our configuration:
c:\Program Files\BYOK_TOOLSET>KeyTransferRemote.exe -Package -KeyIdentifier test ExchangeKeyPackage .\packages\BYOK-KEKpkg-EU-1 -NewSecurityWorldPackage .\packages\BYOK-SecurityWorld-pkg-EU-1 -TenantBposId 2971a9f9-454c-4be2-9b865b3513ecb22e -KeyFriendlyName TestFirstKey
50
Bring Your Own Key (BYOK) with Azure Rights Management
c:\Program Files\BYOK_TOOLSET>KeyTransferRemote.exe -Package -KeyIdentifier test ExchangeKeyPackage .\packages\BYOK-KEKpkg-EU-1 -NewSecurityWorldPackage .\packages\BYOK-SecurityWorld-pkg-EU-1 -TenantBposId 2971a9f9-454c-4be2-9b865b3513ecb22e -KeyFriendlyName TestFirstKey
****************
User Information
****************
Machine Name: 20012-EDGEHSM
User Name:
Administrator
User Domain: 20012-EDGEHSM
Getting hashes for module keys...........................SUCCESS
***********
Module Keys
***********
KML Hash: 7143e6df0470577c253d8a96dcec8fe2b3da17e6
KLF Hash: ace6aa4fec202ca5069369c3825aac0fbcd98ef6
KM Hash:
c0021bc96667ccdc0e96f4f3d4e6525b95e34f29
KMWK Hash: 1d572201be533ebc89f30fdd8f3fac6ca3395bf0
51
Bring Your Own Key (BYOK) with Azure Rights Management
Loading user key.........................................SUCCESS
Loading user key's private blob..........................SUCCESS
****************
User Private Key
****************
Type:
RSAPrivate
Length:
2048
Key Hash: e2f23fdce7e51ff326bc4d898e5b160da8286e11
ACLs:
.n_groups= 1
.groups[
0].flags= none 0x00000000
.n_limits= 0
.n_actions= 4
.actions[
0].type= OpPermissions
.details.oppermissions.perms= DuplicateHandle ReduceACL Decrypt Sign GetACL 0x00003121
.actions[
1].type= MakeBlob
.details.makeblob.flags= AllowKmOnly AllowNonKm0 kmhash_present AllowNullKmToken
0x00000027
.kmhash= 20 bytes
c0021bc9 6667ccdc 0e96f4f3 d4e6525b 95e34f29
.kthash absent
.ktparams absent
.blobfile absent
.actions[
2].type= MakeBlob
.details.makeblob.flags= AllowKmOnly AllowNonKm0 kmhash_present AllowNullKmToken
0x00000027
.kmhash= 20 bytes
b3fc319f b23c9db7 e9248c27 f5967550 da7ecce0
.kthash absent
.ktparams absent
.blobfile absent
.actions[
3].type= MakeArchiveBlob
.details.makearchiveblob.flags= kahash_present 0x00000001
.mech= BlobCryptv2kRSAeRijndaelCBC0hSHA256mSHA256HMAC
.kahash= 20 bytes
ede3e33c d1ffda02 3bd1e319 f2bf156a b4b5e90d
.blobfile absent
.certifier absent
.certmech absent
.moduleserial absent
Loading user key's public blob...........................SUCCESS
***************
User Public Key
***************
Type:
RSAPublic
Length:
2048
Key Hash: e2f23fdce7e51ff326bc4d898e5b160da8286e11
ACLs:
.n_groups= 1
.groups[
0].flags= none 0x00000000
.n_limits= 0
.n_actions= 2
.actions[
0].type= OpPermissions
.details.oppermissions.perms= DuplicateHandle ExportAsPlain GetAppData SetAppData
ReduceACL ExpandACL Encrypt Verify UseAsBlobKey GetACL 0x000026fd
.actions[
1].type= MakeBlob
.details.makeblob.flags= AllowKmOnly AllowNonKm0 AllowNullKmToken 0x00000023
.kmhash absent
.kthash absent
.ktparams absent
.blobfile absent
.certifier absent
.certmech absent
.moduleserial absent
Export public key........................................SUCCESS
Loading exchange key.....................................SUCCESS
********************
Exchange Key Package
********************
Exchange key application name: xferwrapping
Exchange key identifier:
kek-prod-eu-1
Exchange key hash:
ede3e33cd1ffda023bd1e319f2bf156ab4b5e90d
52
Bring Your Own Key (BYOK) with Azure Rights Management
Public key blob:
Generating module's ESN:
Key creation message:
Key creation signature:
Module state message:
Module state signature:
Module warrant:
System.Byte[]
3E55-C8BD-46FC
System.Byte[]
NCipher.MCipherText
System.Byte[]
NCipher.MCipherText
System.Byte[]
Loading exchange key public blob.........................SUCCESS
************
Exchange Key
************
Type:
RSAPublic
Length:
2048
Key Hash: ede3e33cd1ffda023bd1e319f2bf156ab4b5e90d
ACLs:
.n_groups= 1
.groups[
0].flags= none 0x00000000
.n_limits= 0
.n_actions= 3
.actions[
0].type= OpPermissions
.details.oppermissions.perms= DuplicateHandle ExportAsPlain GetAppData SetAppData
ReduceACL ExpandACL Encrypt Verify UseAsBlobKey GetACL 0x000026fd
.actions[
1].type= MakeBlob
.details.makeblob.flags= AllowKmOnly AllowNonKm0 AllowNullKmToken 0x00000023
.kmhash absent
.kthash absent
.ktparams absent
.blobfile absent
.actions[
2].type= MakeArchiveBlob
.details.makearchiveblob.flags= none 0x00000000
.mech= Any
.kahash absent
.blobfile absent
.certifier absent
.certmech absent
.moduleserial absent
Loading exchange key.....................................SUCCESS
**********************
Security World Package
**********************
Security world key hash:
0da7ecce0
Generating module's ESN:
Security world key creation message:
Security world key creation signature:
Module state message:
Module state signature:
Module warrant:
b3fc319fb23c9db7e9248c27f596755
B3C4-F264-3066
System.Byte[]
NCipher.MCipherText
System.Byte[]
NCipher.MCipherText
System.Byte[]
Making wrapped private key blob..........................SUCCESS
Removing recovery key blob...............................SUCCESS
Calculating RMSO key name................................SUCCESS
Saving protected key as C:\ProgramData\nCipher\Key Management Data\loc
al\key_xfer_022971a9f9454c4be29b865b3513ecb22eefc842236a56331e706dedbe
9c51c7ba9fc5c8eb.........................................SUCCESS
Saving key transfer package as c:\Program Files\BYOK_TOOLSET\KeyTransf
erPackage-TestFirstKey.byok..............................SUCCESS
Saving logfile as c:\Program Files\BYOK_TOOLSET\Package-key_xfer_test.
log......................................................SUCCESS
Result: SUCCESS
c:\Program Files\BYOK_TOOLSET>
53
Bring Your Own Key (BYOK) with Azure Rights Management
When the command completes, you will see "Result: SUCCESS". This will create in the current folder a file
called KeyTransferPackage-<FirstKeyLabel>.byok., for example KeyTransferPackage-TestFirstkey.byok in our
configuration.
Copying your key transfer package
Copy the output file KeyTransferPackage-<FirstKeyLabel>.byok from the previous step to your USB drive or
other portable storage.
Uploading your key to the Azure Rights Management service
Perform all steps in this section on your Internet-connected workstation.
To upload the key package, proceed with the following steps:
1.
Plug your USB drive or other portable storage onto your Internet-connected workstation.
2.
Open an (elevated) Windows PowerShell command prompt, run the following commands to
connect to your Azure Rights Management service’s tenant:
PS C:\Users\Administrator> Import-Module aadrm
PS C:\Users\Administrator> Connect-AadrmService
Enter your Azure Rights Management service’s tenant administrator credentials at the prompt.
3.
Upload the key transfer package from your plugged USB drive or other portable storage.
PS C:\Users\Administrator> Add-AadrmKey –KeyFile <PathToPackageFile>
This correspond to the following command in our configuration, once navigating to the USB drive:
PS E:\> Add-AadrmKey -KeyFile E:\KeyTransferPackage-TestFirstKey.byok
54
Bring Your Own Key (BYOK) with Azure Rights Management
The cmdlet will prompt you to confirm you really want to upload this key.
Important note
This action cannot be undone. When you upload a key, it becomes your organization’s
primary key. Over the subsequent weeks, content published by your employees will be protected with the new key.
Note
Adding keys should ideally be done before you have enabled the Azure Rights Management service.
Office 2010 and earlier versions of office do not deal gracefully when you add a second key.
4.
Press "Y".
PS E:\> Add-AadrmKey -KeyFile E:\KeyTransferPackage-TestFirstKey.byok
WARNING: This operation will add a new key and set it as the active key.
Confirm
Are you sure you want to perform this action?
Performing operation "Add-AadrmKey" on Target "current organization".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend
[?] Help(default is "Y"): Y
The Rights management service successfully added the key.
PS E:\>
If the command is successful it will display: "The Rights management service successfully added the key".
It may take a few minutes for the change to propagate to all Azure Rights Management service’s data
centers. You can use the Get-AadrmKeys cmdlet again to see the change in your tenant key, and whenever
you want to see a list of your tenant keys. The tenant keys displayed include the initial tenant key that
Microsoft generated for you, and any tenant keys that you added.
55
Bring Your Own Key (BYOK) with Azure Rights Management
The tenant key that is marked Active is the one that your organization is currently using to protect
documents and files.
You have now completed all the steps required for bring your own key over the Internet and can go to
Section §
AT THIS STAGE, YOU HAVE NOW COMPLETED ALL the steps required for bring your own key in person and can return
to your organization for the next steps.
Enabling and using your Azure Rights Management service tenant.
Transferring your tenant key in person
Use the following procedures if you do not want to transfer your tenant key over the Internet as per previous
section, but instead, transfer your tenant key in person.
This transfer is a manual process that requires you to fly to the Microsoft office in Redmond, WA.
Bringing your key to Microsoft
Contact the Azure Rights Management service support to schedule a key transfer ceremony. Bring the
following artifacts to the Microsoft office in Redmond, Washington, United States of America:
1.
A quorum of your Administrative Cards. If you followed the instruction verbatim in
Section § CREATING A SECURITY WORLD, that is any 2 of your 3 cards.
2.
Personnel authorized to carry your Administrative Cards and pins, typically two (1 for each card).
3.
Your Security World file (%NFAST_KMDATA%\local\world) on a USB drive.
4.
Your Tokenized Key File on a USB drive, a file with a name starting with “key_caping_machine--”
followed
by
a
GUID,
e.g.
key_caping_machine—
730009faacba49d54e495b01650d67d54c3293ce.
Transferring your key to the Azure Rights Management service’s security world
As previously mentioned, the security world technology of Thales HSMs allows a key to be securely
transcrypted from one security world to another within the FIPS 140-2 boundary of an HSM. This requires
Administrative Cards from both security worlds.
The Azure Rights Management service operators will meet your personnel in a Microsoft office in Redmond.
Here:
56

Microsoft will provide an offline workstation with a Thales HSM attached, Thales software installed,
and Azure Rights Management service’s Security World file pre-loaded into the folder
C:\Temp\Destination.

You will load your Security World file and Tokenized Key File from your USB drive into the folder
C:\Temp\Source on this workstation.

The Azure Rights Management service operators will securely transfer your key to the Azure Rights
Management service’s security world using Thales utilities. The last parameter of key-xfer-im in this
example will be replaced by your Tokenized Key File name.
Bring Your Own Key (BYOK) with Azure Rights Management
C:> mk-reprogram.exe --owner c:\Temp\Destination add c:\Temp\Source
C:> key-xfer-im.exe c:\Temp\Source c:\Temp\Destination --module c:\Temp\Source\key_caping_machine—
730009faacba49d54e495b01650d67d54c3293ce
Mk-reprogram will ask you and Azure Rights Management service operators to plug in their respective
Administrator cards and pins.
These commands will output a Tokenized Key File in C:\Temp\Destination which contains your key protected
by the Azure Rights Management service’s security world.
Wrapping up
In your presence, the Azure Rights Management service operators will:

Run a tool that Microsoft co-developed with Thales that removes two permissions – the permission
to recover the key, and the permission to change permissions. Once this is done, this copy of your
key is locked to the Azure Rights Management service’s security world. Thales HSMs will not allow
even the Azure Rights Management service’s operators with their Administrator cards to recover
the plaintext copy of your key.

Copy the resulting key file to a USB drive for subsequent upload to the Azure Rights Management
service.

Factory reset the HSM, wipe the workstation clean.
At this stage, you have now completed all the steps required for bring your own key in person and can
return to your organization for the next steps.
Enabling and using your Azure Rights Management service
tenant
This section applies whether you let Microsoft generate your key (the default) or you generated and
transferred your key to the Azure Rights Management service (over the Internet or in person).
After you have transferred your key (over the Internet or in person), you must enable Azure Rights
Management service. You can do this by using one of the following options.
1.
Enabling your Azure Rights Management service tenant from the Office 365 admin center.
2.
Enabling your Azure Rights Management service tenant for the Azure Management Portal.
-or-
Option 1 - Activating your service tenant from the Office 365 admin
center
To do this, proceed with the following steps:
1.
57
From an online workstation, navigate to the Azure Rights Management service administration portal
such as the Office 365 admin center at https://portal.microsoftonline.com and login and login with
your administrative credentials.
Bring Your Own Key (BYOK) with Azure Rights Management
2.
In the left pane of the administration portal, click Service Settings.
3.
From the Service Settings page, click Rights Management.
Note
If you do not see this option, it might be because your service plan or product version cannot support
Rights Management, or it has not yet been upgraded to support Rights Management.
Use the information in the Cloud subscriptions that support Azure RMS section in the Requirements for Azure
Rights Management topic to confirm support. If your service plan or product version is supported but you do not
see the Rights Management option, it might be because the service is not yet upgraded. For help with this issue,
send an email message to askipteam.
4.
Under Protect your information, click Manage.
5.
Under Rights Management, click Activate. You will get a popup.
6.
When prompted Do you want to activate rights management?, click Activate to confirm you
want to activate. Once the Azure Rights Management service is successfully activated you will see
the following:
Option 2 - Activating the service tenant for the Azure Management
Portal
This option can be used if you have signed up for the Rights Management stand-alone service.
To activate the service tenant, proceed with the following steps:
1.
From an online workstation, navigate to the Azure Management
https://manage.windowsazure.com and login with your administrative credentials.
portal
at
2.
In the left pane of the management portal, click ACTIVE DIRECTORY.
3.
From the active directory page, click RIGHTS MANAGEMENT.
4.
Select the name of your directory to manage, click ACTIVATE at the bottom, and then confirm your
action.
Note
If you see an activation error, it might be because your service plan or product version cannot support
Rights Management.
Use the information in the Cloud subscriptions that support Azure RMS section in the Requirements for Azure
Rights Management topic to confirm RMS support. For help with this issue, send an email message to askipteam.
The RIGHTS MANAGEMENT STATUS should now display Active and the ACTIVATE option is replaced
with DEACTIVATE.
58
Bring Your Own Key (BYOK) with Azure Rights Management
After enabling the service tenant, you can now configure your Exchange servers, SharePoint servers, and
your users’ devices to point to this Azure Rights Management service’s tenant and start using it.
Getting usage logs for your key
You can configure the Azure Rights Management service to generate and give you a log of every request
that the Azure Rights Management service fulfils for your tenant as soon as it happens.
This information is very useful for a variety of reasons:

Analyzing for business insight. The Azure Rights Management service writes logs in W3C Extended
Log (Weblog) format35 into an Azure storage account36 that you provide for this purpose. You can
then feed the logs into a repository of your choice (database, OLAP, Map/Reduce, etc.) in order to
analyze and report.
Examples of insight you can gain are: who is accessing your RMS-protected assets, what are they
accessing, from what devices, from where, are they getting a satisfactory experience, who all has
read a given document etc.

Monitoring for abuse. The Azure Rights Management service shares logs with you in near-realtime
(99.9% of logs available to you within 15 minutes of the action). This allows you to continuously
monitor usage of your Azure Rights Management service’s assets.
You know your employees best and are uniquely qualified to identify an abuse pattern. As an
example, your administrators may want to be alerted if there is a spike in accesses to your assets
during off hours (insider trying to steal a bunch of documents?), or if the same user accesses from
two different IP addresses within 15 minutes (potential password compromise?).

Performing Forensics. When there is an information leak, the top two questions are:
1.
Who recently accessed the specific document that leaked?
2.
What information did a specific suspect access recently?
With the Azure Rights Management service’s architecture, your documents can flow any way you
want (email, cloud storage such as Dropbox, USB, etc.) but recipients must get a license from the
Azure Rights Management service to open and consume those documents. Therefore the Azure
Rights Management service’s logs are a definitive source of information for forensics, as long as
your assets are protected with the Azure Rights Management service.
This feature is available to you whether you let Microsoft generate your key (the default) or you bring your
own key (BYOK). But when you bring your own key, the Azure Rights Management service also logs every
usage of your key in addition to front-end request logs. This allows you to monitor in near real-time
how your key is being used.
35
W3C EXTENDED LOG FILE FORMAT: http://www.w3.org/TR/WD-logfile.html
36
STORAGE: http://www.windowsazure.com/en-us/documentation/services/storage
59
Bring Your Own Key (BYOK) with Azure Rights Management
To turn on logging and get these logs, follow the instructions outlined in the whitepaper GET USAGE LOGS
FROM MICROSOFT RMS37 available on the Microsoft Download Center.
The logs you receive from the Azure Rights Management service will contain every transactions performed
with your tenant key.
Here is an example of a log file displayed in Microsoft Excel. Look for request types Decrypt and SignDigest
that more specifically show the key usage:
Revoking your key
When you unsubscribe from the Azure Rights Management service, the service will stop using your key. This
is true whether you let Microsoft generate your key (the default) or you bring your own key.
Rolling your key (re-key)
We discourage rolling keys unless really necessary. Older clients, notably Office 2010, were not designed to
handle key changes gracefully. You must have users of such clients explicitly clear their Rights Management
state via GPO (Group Policy Object) or equivalent mechanisms.
That said, there are some legitimate events that may force you to roll your key e.g.:

Your company split. When you roll your key, the spun-off company will not have access to new
content that your employees publish. They can in theory access the old content if they have a copy
of the old key.

You believe the master copy of your key (the copy in your possession) was compromised.
If you let Microsoft generate your key (the default), you can roll your key by calling the Azure Rights
Management service support and proving that you are the tenant administrator.
If you brought in your own key, you roll your key by repeating the steps in Section § BRINGING YOUR KEY TO
MICROSOFT.
When you roll your key, new content gets protected to the new key. This happens in a phased manner, so
for a period of time, some new content will continue to be protected with the old key. Previously protected
content stays protected to your old key. Azure Rights Management service retains your old key so that it
can issue licenses for such old content.
37
60
GET USAGE LOGS FROM MICROSOFT RMS: http://www.microsoft.com/en-us/download/details.aspx?id=40333
Bring Your Own Key (BYOK) with Azure Rights Management
Backing up and recovering your key
If you let Microsoft generate your key (the default), then Microsoft is responsible for backing up your key.
If you bring in your own key, then you are responsible for backing up the key. If you generated your key in
a Thales HSM per Section § CREATING A NEW KEY, then to back up the key, just back up the Tokenized Key file,
the World file, and the Administrator Cards.
If you transferred your key by following the procedures in Section § BRINGING YOUR KEY TO MICROSOFT then the
Azure Rights Management service will persist the Tokenized Key File, in order to protect against failure of
any Azure Rights Management service nodes. This should not be viewed as a full backup. For instance if you
ever need a plaintext copy of your key to use outside a Thales HSM, the Azure Rights Management service
will not be able to retrieve it for you as it only has a non-recoverable copy.
Exporting your key
If you bring in your own key, you cannot export your key from the Azure Rights Management service. The
Azure Rights Management service’s copy is non-recoverable. If you let Microsoft generate your key (the
default), then you can export your Azure Rights Management service configuration and key as follows.
Initiating the export
To do this, contact Azure Rights Management service support either by phone or from the Microsoft
Azure/Office 365 administrative portal. You must prove you are an administrator for your Azure Rights
Management service tenant.
Waiting for verification
Microsoft performs the following checks before releasing your key to ensure that the request is legitimate.

The requestor must be an administrator for your Azure Rights Management service tenant.

We will send email to all administrators for your Azure Rights Management service tenant, and
written notice to your mailing address, notifying you of the request and the requestor’s identity. We
will wait a minimum of 5 business days. Microsoft must receive no dissenting response during this
period.

Your organization must have cancelled your Azure Rights Management service subscription. If a
malicious insider in your organization wants to initiate an export, they must first cancel the Azure
Rights Management service subscription for your whole organization, which is a high bar.
Receiving key using instructions from Microsoft RMS support team
The Azure Rights Management service support team (“CSS”) will send you your Azure Rights Management
service configuration and key as encrypted and password-protected TPD file. To achieve this CSS will first
send you (the one who initiated the export) a tool by email. Requestor must run the tool from a command
prompt.
61
Bring Your Own Key (BYOK) with Azure Rights Management
C:\> aadrmtpd.exe –createkey
This generates an RSA key pair and saves the public and private halves as files in the current folder. Respond
to the email from CSS, attaching the file whose name starts with “PublicKey-”.
CSS will next send you a TPD file encrypted to your RSA key. Run the Aadrmtpd tool again from the same
folder where you ran it the first time (so that it has access to the private key).
C:\> aadrmtpd.exe –decrypt yourtpdfile
The output of this command should be two files. One containing the plaintext password for the passwordprotected TPD, and one that is the password-protected TPD itself. Both should have the same GUID as the
public and private key files from before for cross-referencing purposes.

Password-fa29d0fe-5049-4c8e-931b-96c6152b0441.txt

ExportedTPD-fa29d0fe-5049-4c8e-931b-96c6152b0441.xml
You can now import this TPD into ADRMS or save it to your archive.
Responding to a breach
No security system, no matter how strong, is complete without a breach response process. This document
focusses solely on breach of your root key. This may happen with your (master) copy of your key, or from
Microsoft’s possession. Or over the years, vulnerabilities may be found in current generation HSM
technology or current key lengths/algorithms.
Microsoft has a dedicated team to respond to security incidents in our products and services. As soon as
there is a credible report of an incident, this team engages to investigate the scope, root cause, and
mitigations. If this incident affects your assets, then we will notify your Azure Rights Management service
tenant administrators by email at the address you supplied when you subscribed.
The best subsequent action for Microsoft and for you depends on the scope of the breach; Microsoft will
work with you through this process. Below are some situations, and the likely response.
Incident description
Likely response. (Exact response depends on all the information revealed
during the investigation.)
Your root key is leaked
Roll your key per Section § ROLLING YOUR KEY (RE-KEY) above
An unauthorized individual or
malware got rights to use your
key (but the key itself did not
leak)
Rolling key does not help here. This needs to be root-caused. If a process or
software bug caused the unauthorized individual to get access then that hole
needs to be patched.
Vulnerability discovered in
current-generation
HSM
technology.
Microsoft must update HSMs. If there is reason to believe that the vulnerability
exposed keys, then we must have all customers roll their keys.
Vulnerability discovered in RSA
algorithm, or key length, or
brute-force attacks become
computationally feasible
Microsoft must update the Azure Rights Management service system to support
new algorithms and/or longer key lengths that are resilient, and have all customers
roll their keys.
62
Bring Your Own Key (BYOK) with Azure Rights Management
63
Bring Your Own Key (BYOK) with Azure Rights Management
The information contained in this document represents the current view of Microsoft Corporation on the
issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions,
it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the
accuracy of any information presented after the date of publication.
This white paper is for informational purposes only. Microsoft makes no warranties, express or implied, in this
document.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or
for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property.
© 2014 Microsoft Corporation. All rights reserved.
The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and
events depicted herein are fictitious. No association with any real company, organization, product, domain
name, e-mail address, logo, person, place, or event is intended or should be inferred.
Microsoft, list Microsoft trademarks used in your white paper alphabetically are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.
64
Bring Your Own Key (BYOK) with Azure Rights Management