Bring Your Own Key (BYOK) with Azure Key Vault for … · Web viewAs an alternative, the integration with Azure Key Vault with the BYOK capability that let you bring your own key
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and AzureOverview technical articleMicrosoft FrancePublished: May 2018Version: 1.1
Authors: Philippe Beraud, Daniel Pasquier (Microsoft France)Contributors/Reviewers: Peter DiToro, Eric Portrait (Thales e-Security), Sumedh Barde (Microsoft Corporation)
For the latest information on Azure Key Vault, please see azure.microsoft.com/en-us/services/key-vault/
Abstract: Azure Key Vault allows organizations of any size to notably store and uses – in accordance to the vault’s access policy - their own keys with extreme security thanks to its reliance on industry proven, FIPS compliant Hardware Security Modules (HSMs) from Thales e-Security. In this context, it offers the Bring-Your-Own-Key (BYOK) capability that lets these organizations generate and import their on-premises key, and delegate use privileges for use to a growing number of Microsoft cloud-hosted Office 365 and Azure services that support the integration with Azure Key Vault for service-side encryption, client-side encryption and/or content encryption to protect their data. Microsoft cloud-hosted Office 365 and Azure services’ customers indeed 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 or simply to best practices in key custody.This document provides information about the Bring-Your-Own-Key (BYOK) capability of Azure Key Vault. 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 them with both the Office 365 and Azure services that leverage this capability within your organization to protect your data in compliance with your own security and IT policies in place.
Table of ContentsNOTICE................................................................................................................
OBJECTIVES OF THIS PAPER................................................................................................6NON-OBJECTIVES OF THIS PAPER.........................................................................................6ORGANIZATION OF THIS PAPER............................................................................................6ABOUT THE AUDIENCE.......................................................................................................7
BYOK AT A FIRST GLANCE...................................................................................8UNDERSTANDING THE KEY LIFECYCLE...................................................................................8UNDERSTANDING THE RESTRICTIONS....................................................................................9THALES HSMS AND MICROSOFT ADDITIONS..........................................................................9
MANAGING YOUR OWN KEY..............................................................................12SIGNING UP FOR AN AZURE TRIAL......................................................................................15PREPARING THE LOCAL ENVIRONMENT FOR AZURE................................................................15CREATING THE AZURE KEY VAULT RESOURCE IN YOUR AZURE SUBSCRIPTION.............................18PREPARING A DISCONNECTED WORKSTATION WITH THE THALES HSM.......................................19GENERATING YOUR KEY...................................................................................................26TRANSFERRING YOUR KEY OVER THE INTERNET TO YOUR HSM-BASED VAULT.............................36
USING YOUR IMPORTED KEY WITH OFFICE 365 AND AZURE SERVICE...................69TENANT KEY WITH AZURE INFORMATION PROTECTION............................................................69ENABLING AND USING YOUR AZURE INFORMATION PROTECTION SERVICE TENANT........................73GETTING USAGE LOGS FOR YOUR KEY.................................................................................74REVOKING YOUR KEY......................................................................................................75ROLLING YOUR KEY (RE-KEY)............................................................................................76BACKING UP AND RECOVERING YOUR KEY............................................................................76EXPORTING YOUR KEY.....................................................................................................77RESPONDING TO A BREACH..............................................................................................77
3 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
NoticeFor the latest information that pertains the Bring-Your-Own-Key (BYOK) capability as covered in this document, please refer to the articles HOW TO GENERATE AND TRANSFER HSM- PROTECTED KEYS FOR AZURE KEY VAULT 1 and PLANNING AND IMPLEMENTING YOUR AZURE INFORMATION PROTECTION TENANT KEY 2.These articles constitute the reference articles on this capability of Azure Key Vault as covered in this paper.
FeedbackFor any feedback or comment regarding this document, please send a mail to [email protected].
1 HOW TO GENERATE AND TRANSFER HSM-PROTECTED KEYS FOR AZURE KEY VAULT: https://docs.microsoft.com/en-us/azure/key-vault/key-vault-hsm-protected-keys2 PLANNING AND IMPLEMENTING YOUR AZURE INFORMATION PROTECTION TENANT KEY: https://docs.microsoft.com/en-us/information-protection/plan-design/plan-implement-tenant-key
4 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Introduction A growing number of Microsoft Office 365 and Azure services offers service-side encryption, client-side encryption or content encryption to protect organizations’ data and provide defense-in-depth against offline attacks. To name a few:
Azure Information Protection (AIP) for the document protection (files and mails), Exchange Online service encryption (mail-box level encryption) in Office 365, SharePoint Online and OneDrive for Business service encryption in Office 365 (per-file
encryption), Dynamics 365 Online service encryption, Azure Data Lake Store service encryption, Azure SQL Always Encrypted, Azure Disk Encryption, Azure Storage Service Encryption, Etc.
In terms of control, those services aim at providing the choice if and when data is encrypted, and in the affirmative between a complete service-managed approach that can be activated by a simple click and the ability to specify a tenant cryptographic key in a customer’s managed vault in Azure Key Vault.Such a (tenant) cryptographic key constitutes the master key and root of trust of its encryption model in so far, regardless of the considered service’s artifacts are indeed cryptographically chained to that key. Even if the implementation details may differ from one service to another, this key is typically used to encrypt keys such as storage account keys, data encryption keys, per-document encryption keys, etc. For instance, all Azure Information Protection3 service artifacts in the organization (per-user keys, per-document encryption keys) are cryptographically chained to that cryptographic key.The integration of the aforementioned services with Azure Key Vault helps safeguard the so-called cryptographic key(s) used by these services once configured to do so. Azure Key Vault streamlines the key management process and enables you to maintain control of keys that access and encrypt your data.
Note For overview information about Azure Key Vault, see article WHAT IS AZURE KEY VAULT? 4.
When generated in a customer’s managed vault in Azure Key Vault, these keys are by design protected by a hierarchy of keys that ends up in hardware security modules (HSMs). For added assurance, you can import (or generate) these keys in HSMs. The import of the key into HSMs for a customer’s managed vault is referred as to the Bring-Your-Own-Key (BYOK) capability.
3 WHAT IS AZURE INFORMATION PROTECTION?: https://docs.microsoft.com/en-us/information-protection/understand-explore/what-is-information-protection4 WHAT IS AZURE KEY VAULT?: https://docs.microsoft.com/en-us/azure/key-vault/key-vault-whatis
5 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
With this option, and thanks to its reliance on industry proven, FIPS compliant5 HSMs6 from our partner Thales:
You generate your tenant cryptographic key on your premises, using tools of your choice, in compliance with your own Security and IT policies in place.
You securely transfer the key from an HSM in your possession to HSMs in Microsoft’s possession for the Azure Key Vault 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, in terms of transparency, you have the ability to view logs at any time related to the keys (along with the protected data if relevant in the context). For that purpose, you can indeed configure near real-time logging and thus receive near real-time usage logs from the Azure Key Vault service. You can layer this on top of BYOK to see exactly how and when your key is being used by the above service.
Note For more information, see article AZURE KEY VAULT LOGGING 7.
The integration of the aforementioned services with Azure Key Vault thus offer you (the customer IT administrator) multiple levels of control over this tenant cryptographic key so that you can trade off the level of control you desire versus cost and simplicity:
As an illustration, and to continue with Azure Information protection that will be further covered at the end of this paper, the Azure Information Protection service generates by default 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 Information Protection service and the rest happens automatically. As an alternative, the integration with Azure Key Vault with the BYOK capability that let you bring your own key as the name indicates. Indeed, Azure Information Protection service’s 5 Thales nShield HSMs Certifications: http://www.thales-esecurity.com/company/certifications6 Thales nShield HSMs: https://www.thalesesecurity.com/products/general-purpose-hsms7 AZURE KEY VAULT LOGGING: https://docs.microsoft.com/en-us/azure/key-vault/key-vault-logging
6 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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 Right Management Services (AD RMS)8 infrastructure, or simply to best practices in key custody.
Objectives of this paperThis document provides information about the various options available for protecting your tenant cryptographic key for supported service(s) in Office 365 and/or Azure 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 to let you generate, import, and delegate use privileges to Microsoft for use in a supported 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 for example Azure Information Protection 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 paperThis document doesn’t offer a full description of the cloud-hosted 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 cloud-hosted service.
Organization of this paperTo 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. USING YOUR IMPORTED KEY WITH OFFICE 365 AND AZURE SERVICE.
About the audienceThis document is intended for IT professionals and system architects who are interested in understanding and using the Bring-Your-Own-Key (BYOK) capability of Azure Key Vault and controlling its usage by a growing number of Office 365 and Azure services that support such an integration path with Azure Key Vault.
8 ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES OVERVIEW: https://technet.microsoft.com/en-us/library/74272acc-0f2d-4dc2-876f-15b156a0b4e0.aspx
7 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
BYOK at a first glanceWith the Bring-Your-Own-Key (BYOK) option of Azure Key Vault:
You create an HSM-based vault for a specific Azure region in a specific geography. You generate your 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 as provided by Azure Key Vault for your vault. 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 and cryptographic attestations are provided to ensure it.
Optionally, you can sign up to receive near-real-time usage logs from Azure Key Vault. You can layer this on top of BYOK to see exactly how and when your key is being used with Azure Key Vault.
Note For additional information, see article HOW TO GENERATE AND TRANSFER HSM-PROTECTED KEYS FOR AZURE KEY VAULT 9.
Understanding the key lifecycleThe following diagram displays the key lifecycle and how the above capabilities fit together.
Azure Key Vault service
On Your Premises
3 Your key stays protected by Thales HSMs. Microsoft cannot see or leak your key
4A service integrated with Azure Key Vault service can use your key (in accordance to the access policy that you #͛ve defined for this service)
5 Microsoft can replicate your key for scale /disaster recovery
1You generate your keys. You keep master key and control key lifecycle per your compliance requirements
2Bring-Your-Own-Key (BYOK) to the Azure Key Vault service using HSM-to-HSM transfer
6 Microsoft provides you near-realtime log of how your key is used
9 HOW TO GENERATE AND TRANSFER HSM-PROTECTED KEYS FOR AZURE KEY VAULT: https://docs.microsoft.com/en-us/azure/key-vault/key-vault-hsm-protected-keys
8 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Understanding the restrictionsOrganizations that have an IT-managed Microsoft Azure subscription can create a vault in Azure Key Vault, and use BYOK (and logging). (A blob storage is required to store the logs, see article AZURE KEY VAULT LOGGING 10).Almost every application or service that are integrated with the Azure Key Vault will work seamlessly when you do BYOK (and logging). That includes cloud services such as:
Azure Information Protection (AIP) for the document protection (files and mails), Exchange Online service encryption (mail-box level encryption) in Office 365, SharePoint Online and OneDrive for Business service encryption in Office 365 (per-file
encryption), Dynamics 365 Online service encryption, Azure Data Lake Store service encryption, Azure SQL Always Encrypted, Azure Disk Encryption, Azure Storage Service Encryption, Etc.
Both BYOK and logging allow the organization to have full control over their keys in their vault in their Azure subscription. The advanced key management capabilities described here are a great fit for such enterprises.
Thales HSMs and Microsoft additionsAzure Key Vault uses Thales FIPS 140-2 level 211 validated hardware security modules (HSMs) (hardware and firmware) 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 21 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 Information Protection 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 Key Vault service data center. Your keys can be loaded into the Azure Key Vault service’s Thales nShield family HSMs and used on your behalf without regard to which HSM is doing the work.
10 AZURE KEY VAULT LOGGING: https://docs.microsoft.com/en-us/azure/key-vault/key-vault-logging11 More information on the FIPS 140-2 certification scheme can be found at http://csrc.nist.gov/groups/STM/cmvp/standards.html
9 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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 Key Vault 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 for the geographic region in which is located your vault.Together these 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 PracticeThales 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 within the Azure Key Vault 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 Key Vault 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
10 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
keys only by authorized users or servers, avoiding the need to impose rigid partitioning within an HSM.
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 Azure Key Vault.
11 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Managing your own keyWith 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 Azure Key Vault 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 Description
Microsoft Azure service subscription
You must have an active subscription to Microsoft Azure.
Azure Key Vault Premium service tier to support HSM-protected keys
You must have created a HSM-based Key Vault (Premium SKU) in the active subscription. For more information about the service tiers and related capabilities for Azure Key Vault, see the Azure Key Vault Pricing Web site12.
Thales HSM, smartcards, and support software
You must have access to a Thales nShield Hardware Security Module13 and basic operational knowledge of Thales nShield HSMs. Any model will do. See the list of compatible models14, or purchase an HSM if you do not have one.
(Optional) Usage logging feature
To exercise the Usage Logging feature, you must have sufficient Azure storage to store your logs in the Azure subscription.
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 key requires some extra configuration steps, such as downloading and using a dedicated toolset and Windows PowerShell cmdlets.
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 site15, the Windows PowerShell online help16, and the Windows PowerShell Weblog17 Windows PowerShell Software Development Kit (SDK)18 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 key. Security is maintained by the following methods:
You generate the key from an offline workstation, which reduces the attack surface.
12 Azure Key Vault Pricing Web site: https://azure.microsoft.com/en-us/pricing/details/key-vault/13 Thales Hardware Security Modules: https://www.thalesesecurity.com/products/general-purpose-hsms14 Ibid15 Windows PowerShell Web site: http://www.microsoft.com/powershell16 SCRIPTING WITH WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/bb978526.aspx17 Windows PowerShell Weblog: http://blogs.msdn.com/powershell18 Windows PowerShell SDK: http://msdn2.microsoft.com/en-us/library/aa830112.aspx
12 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
The key is encrypted with a Key Exchange Key (KEK), which stays encrypted until it is transferred to the Azure Key Vault service’s HSMs that pertain to your HSM-based vault. Only the encrypted version of your key leaves the original workstation.
The BYOK toolset sets properties on your key that binds your key to the Azure Key Vault service’s security world for the corresponding geographic region. So, after the Azure Key Vault service’s HSMs receive and decrypt your key, only these HSMs can use it. Your key cannot be exported. This binding is enforced by the Thales HSMs.
The Key Exchange Key (KEK) that is used to encrypt your key is generated inside the Azure Key Vault 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 BYOK toolset includes attestation from Thales that the KEK is not exportable and was generated inside a genuine HSM that was manufactured by Thales.
The BYOK toolset includes attestation from Thales that the Azure Key Vault 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 key can be used only in data centers in the geographical region in which you encrypted it. For example, a key from a European customer cannot be used in data centers in North America or Asia-Pacific. As of this writing, available geographic regions are as follows:
United States, Europe, Asia, Latin America, Japan, Australia, Azure Government, Canada, Germany, India, United Kingdom
Note Your key can safely move through untrusted computers Microsoft Security Strategy 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 Key Vault. You can use the scripts that are provided in the BYOK toolset to verify the security measures and read more information about how this works from Thales: HOW TO GENERATE AND TRANSFER HSM-PROTECTED KEYS FOR AZURE KEY VAULT 19.
To generate your 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 Edge20. 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 19 HOW TO GENERATE AND TRANSFER HSM-PROTECTED KEYS FOR AZURE KEY VAULT: https://docs.microsoft.com/en-us/azure/key-vault/key-vault-hsm-protected-keys20 Thales nShield Edge: https://www.thalesesecurity.com/products/general-purpose-hsms/nshield-edge
13 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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 Azure Key Vault (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 Key Vault service.
Signing up for an Azure trialIf you do not already have an Azure account and simply would like to test and evaluate the procedure, you can sign up for a free one-month trial21.
Note If you have an MSDN Subscription, see article AZURE BENEFIT FOR MSDN SUBSCRIBERS 22.
Note Once you have completed your trial tenant signup, you will be redirected to the Azure account portal23 and can proceed to the Azure management portal by clicking Portal at the top right corner of your screen.
At this stage, we assume you have a valid Azure subscription with the administrative credentials.
Preparing the local environment for AzureAzure PowerShell is a set of modules that provide cmdlets to manage Azure with Windows PowerShell. You can use the cmdlets to create, test, deploy, and manage solutions and services delivered through the Azure platform. In most cases, the cmdlets can be used for the same tasks as the Azure portal, such as creating and configuring your HSM-based Azure Key Vault in the context of the paper.The configuration of Azure PowerShell on a local computer consists of:
Installing Azure PowerShell, Verifying that Azure PowerShell can run scripts,
Note that this local computer must have Internet connectivity.
21 CREATE YOUR FREE AZURE ACCOUNT TODAY: https://azure.microsoft.com/en-us/free/22 MONTHLY AZURE CREDIT FOR VISUAL STUDIO SUBSCRIBERS: https://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-details/23 Azure account portal: https://account.windowsazure.com/Subscriptions
14 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Installing Azure PowerShell The preferred way to install Azure PowerShell is to use PowerShell Gallery.
Note Installing items from the PowerShell Gallery requires the latest version of the PowerShellGet module, which is available in Windows 10, in Windows Management Framework (WMF) 5.0, or in the MSI-based installer (for PowerShell 3 and 4). If the PowerShellGet module is not already available in your current configuration, it is available at https://www.powershellgallery.com.
To install the latest Azure PowerShell from the PowerShell Gallery, proceed with the following steps:
1. Open an elevated Windows PowerShell or PowerShell Integrated Scripting Environment (ISE) prompt.
2. Run the following command to install the Azure Resource Manager (ARM) modules:
PS C:\> Install-Module AzureRM
Note For information on Azure Resource Manager (ARM), see article AZURE RESOURCE MANAGER OVERVIEW 24.
3. Run the following command to make sure the Azure PowerShell module is available after you install:
PS C:\> Get-Module –ListAvailable
At this stage, you can run the cmdlets from Windows PowerShell or PowerShell Integrated Scripting Environment (ISE) prompt.
Connecting to your Azure subscription with Azure PowerShellTo connect to your Azure subscription with the above cmdlets, proceed with the following steps:
1. Open a Windows PowerShell or PowerShell Integrated Scripting Environment (ISE) prompt.
3. Type “Y”. A Sign in to your account dialog brings up.
4. Type the email address. Depending on your email address, you may be redirected to an alternative sign-in page.
5. Type the password associated with your account and click Sign in.6. Azure authenticates you, saves the credential information, and then closes the dialog.
A message states that your subscription is now selected as the default subscription.7. Once connected to your default subscription, you can use the built-in Help system to
list and get help about the cmdlets in the Azure PowerShell module. To list the available cmdlets for ARM, run the following command:
PS C:\> help AzureRM
16 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
You can then display help about a specific cmdlet by typing help followed by the name of the cmdlet.
Note For additional information, see articles GET STARTED WITH AZURE POWERSHELL CMDLETS 25 and MANAGE AZURE RESOURCES WITH POWERSHELL AND RESOURCE MANAGER 26.
Creating the Azure Key Vault resource in your Azure subscriptionYour first will have to create to an Azure Resource Group and an Azure Key Vault in your Azure subscription.
Creating a new Azure Resource Group for use with Azure Key Vault Before you can create an Azure Key Vault, you must first create an Azure Resource Group.To create an Azure Resource Group, proceed with the following steps:
1. Open an elevated Windows PowerShell or PowerShell Integrated Scripting Environment (ISE) prompt.
2. Connect to your Azure subscription as per section § CONNECTING TO YOUR AZURESUBSCRIPTION WITH AZURE POWERSHELL.
25 GET STARTED WITH AZURE POWERSHELL CMDLETS: https://docs.microsoft.com/en-us/powershell/azureps-cmdlets-docs/26 MANAGE AZURE RESOURCES WITH POWERSHELL AND RESOURCE MANAGER: https://docs.microsoft.com/en-us/azure/azure-resource-manager/powershell-azure-resource-manager
17 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Note In the last command, set the Location argument with your current location.
Creating a new HSM-based Azure Key Vault To create a HSM-based Azure Key Vault in the resource group, run the following command from the previous elevated Windows PowerShell or PowerShell Integrated Scripting Environment (ISE) prompt, run the following command:
Important note The VaultName value must be unique across Azure as each vault will get a Vault URI like https://Litware369KeyVaultHSM.vault.azure.net. You must choose a unique vault name for this command which will be referenced in later commands.
Important note To enable the creation of HSM-stored keys, the Premium Sku must be added when the Azure Key Vault is created.
Preparing a disconnected workstation with the Thales HSMInstalling the nCipher (Thales) support softwareTo 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.
2. Right-click the setup program SecWorld-win-use.exe and select Run as administrator. A Security World Software for nShield Setup wizard appears.
18 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
3. Click Next.
4. In the License Agreement page, click Yes.
19 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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.
20 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
7. In the nCipher MSCAPI page, click Next.
8. 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.
21 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
9. In the nCipherSNMP page, click Next.
10. Click Finish.Once the setup is completed, we advise to reboot the workstation.
Attaching the Thales HSMTo 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
22 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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:
enquiry reply flags none enquiry reply level Six serial number EA67-52ED-38F9
mode operational
version 3.67.11 speed index 12 rec. queue 442..642 level one flags Hardware HasTokens version string 3.67.11cam8, 2.61.1cam5 built on Jul 8 2015 15:00:16 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 ServerHasPollCmds FastPollSlotList HasSEE HasKLF HasShareACL HasFeatureEnable HasFileOp HasLongJobs ServerHasLongJobs AESModuleKeys NTokenCmds JobFragmentation LongJobsPreferred Type2Smartcard ServerHasCreateClient HasInitialiseUnitEx Type3Smartcard HasKLF2 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 none enquiry reply level Six serial number EA67-52ED-38F9 mode operational version 2.61.1
speed index 12 rec. queue 9..152 level one flags Hardware HasTokens version string 2.61.1cam5 built on Jul 8 2015 15:00:16 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 ServerHasPollCmds FastPollSlotList HasSEE HasKLF HasShareACL HasFeatureEnable HasFileOp HasLongJobs ServerHasLongJobs AESModuleKeys NTokenCmds JobFragmentation LongJobsPreferred Type2Smartcard ServerHasCreateClient HasInitialiseUnitEx Type3Smartcard HasKLF2 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 26 kneti hash abc01354f3af2c53333f71aa90fdca586f7009d8 rec. LongJobs queue 8 SEE machine type ARMtype2 supported KML types DSAp1024s160 DSAp3072s256 hardware status unsupported driver C:\Program Files (x86)\nCipher\nfast\bin>
24 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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 keyBy default, Microsoft generates your keys when you subscribe to the Azure Information Protection 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 or if your organization has specific policies around handling of keys. If this is the case contact the Azure Key Vault service support for guidance.Perform all steps in this section on your offline workstation.
Creating a security worldBy 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.
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,
25 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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 InitializationA: 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 deviceG: Clear button Clear the device’s memory and
changes the selected mode
a. 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:
Red In Maintenance modeRed flashing Maintenance mode selectedAmber In Initialization mode
26 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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.
27 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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.
28 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
9. When prompted Remove card, remove the second smart card.10. Insert the third and last smart card.
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.
29 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
security world generated on module #1; hknso = f618d3d2d638ac344622f586fdda03d24d5e1a48
c:\Program Files (x86)\nCipher\nfast\bin>
12. On the HSM, change the mode back to Operational mode.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.
13. Finally, run the following command to verify your installation:
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.
31 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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 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 providerYou 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:
Creating a new keyYou 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 Information Protection 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:
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.
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—dc46f6825026261258ddd8b30b470af68bddadf9. 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:
5. Backup this Tokenized Key File in a safe location.
35 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Important note When you subsequently transfer your key to the Azure Key Vault 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 key over the Internet to your HSM-based vaultIf you generated your own key, you must transfer it to your HSM-based vault in the Azure Key Vault service before you can use it from your vault. This section depicts the procedures to follow in order to transfer your tenant key over the Internet to your HSM-based vault. Transferring the key over the Internet requires an Internet-connected workstation in addition to the disconnected workstation.You must know your Subscription ID.
Downloading the BYOK toolsetTo download the BYOK tools for Microsoft Rights Management service (BYOK toolset), proceed with the following steps:
1. Open a browsing session and from the Microsoft Download Center, download the Azure Key Vault BYOK toolset27 for your geographic region. The package is named KeyVault-BYOK-Tools-Europe.zip for Europe, KeyVault-BYOK-Tools-UnitedStates.zip for the United States, KeyVault-BYOK-Tools-AsiaPacific.zip for Asia-Pacific, etc. As of this writing, eleven packages are currently available for the supported geographic region.Regardless of the packages, this toolset includes the following:
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.
2. 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 workstationPerform 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:
The USB drive correspond to the E: drive letter in our configuration. Adapt the command to reflect your current configuration.
2. From the previous folder, run vcredist_x64.exe to install the Visual C++ runtime components for Visual Studio 2013. A Microsoft Visual C++ 2013 Redistributable
37 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
(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 workstationThis 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. 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.
Important note A security world MUST also have been created as per section CREATING A SECURITYWORLD 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"
38 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
3. Still from the command prompt, navigate to the folder where the toolset has been copied to:
c:\Windows\system32> cd %ProgramFiles%\BYOK_TOOLSETc:\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 Information Protection 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
Where: <KEK> is the Key Exchange Key (KEK) package for your geographic region:
BYOK-KEK-pkg-EU-1 for Europe. BYOK-KEK-pkg-NA-1 for the United States. BYOK-KEK-pkg-AP-1 for Asia-Pacific. Etc.
<SecurityWorldpackage> is the Security World package for your geographic region: BYOK-SecurityWorld-pkg-EU-1 for Europe. BYOK-SecurityWorld-pkg-NA-1 for the United States. BYOK-SecurityWorld-pkg-AP-1 for Asia-Pacific. Etc.
This correspond to the following command in our configuration:
* 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===========================================================================
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 website28.
Preparing your key for upload to the your HSM-based vaultContinue to perform all steps in this section on your disconnected workstation.
Creating a copy of your key with reduced permissionsTo 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.
Where: <KEK> is the Key Exchange Key (KEK) package for your geographic region:
BYOK-KEK-pkg-EU-1 for Europe. BYOK-KEK-pkg-NA-1 for the United States. BYOK-KEK-pkg-AP-1 for Asia-Pacific. Etc.
<SecurityWorldpackage> is the Security World package for your geographic region: BYOK-SecurityWorld-pkg-EU-1 for Europe. BYOK-SecurityWorld-pkg-NA-1 for the United States. BYOK-SecurityWorld-pkg-AP-1 for Asia-Pacific. Etc.
This correspond to the following command in our configuration:
**********************Security World Package**********************Security world key hash: b3fc319fb23c9db7e9248c27f5967550da7ecce0Generating module's ESN: B3C4-F264-3066Security world key creation message: System.Byte[]Security world key creation signature: NCipher.MCipherTextModule state message: System.Byte[]Module state signature: NCipher.MCipherTextModule warrant: System.Byte[]
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 keyThis 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"
54 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Note You should refer to the Thales user guide for how to interpret the output. 2. From the above command prompt, run the following command with the Thales utility
kmfile-dump.exe, replacing test in key_xferacId_test with whatever you chose as your key identifier in Section § CREATING A NEW KEY.
Note You should refer to the Thales user guide for how to interpret the output.
Encrypting your key to Microsoft’s Key Exchange KeyProceed 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:
Where: <KEK> is the Key Exchange Key (KEK) package for your geographic region:
BYOK-KEK-pkg-EU-1 for Europe. BYOK-KEK-pkg-NA-1 for the United States. BYOK-KEK-pkg-AP-1 for Asia-Pacific. Etc.
<SecurityWorldpackage> is the Security World package for your geographic region: BYOK-SecurityWorld-pkg-EU-1 for Europe. BYOK-SecurityWorld-pkg-NA-1 for the United States. BYOK-SecurityWorld-pkg-AP-1 for Asia-Pacific. Etc.
59 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
<GUID> is your Azure Active Directory subscription ID for example 8848a529-9d69-4049-8469-8218547a61e2 in our configuration.
<FirstKeyLabel> with a label that will be used for your output file name (see below). This corresponds to the following command in our configuration:
Loading security world package...................................................................SUCCESS
**********************Security World Package**********************Security world key hash: b3fc319fb23c9db7e9248c27f5967550da7ecce0Generating module's ESN: B3C4-F264-3066Security world key creation message: System.Byte[]Security world key creation signature: NCipher.MCipherTextModule state message: System.Byte[]Module state signature: NCipher.MCipherTextModule warrant: System.Byte[]
Making wrapped private key blob..................................................................SUCCESS
64 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Saving protected key as C:\ProgramData\nCipher\Key Management Data\local\key_xfer_028848a5299d69404984698218547a61e2f5b042b9c3a7dd9333e6a470d1ec2b57fb5c34ad...................................................SUCCESS
Saving key transfer package as C:\Program Files\BYOK_TOOLSET\KeyTransferPackage-TestFirstKey.byok...SUCCESS
Saving logfile as C:\Program Files\BYOK_TOOLSET\Package-key_xfer_test.log........................SUCCESS
Result: SUCCESS
c:\Program Files\BYOK_TOOLSET>
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 packageCopy the output file KeyTransferPackage-<FirstKeyLabel>.byok from the previous step to your USB drive or other portable storage.
Uploading your key to your HSM-based vaultPerform 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.
65 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
2. Open an (elevated) Windows PowerShell command prompt, run the following commands to connect to your Azure Subscription, replacing Your_Vault_Name with your Vault Name identified in section § CREATING A NEW HSM-BASED AZURE KEY VAULT and Key_Label_Name with the value specified in Section “Encrypting your key to Microsoft’s Key Exchange Key”:
3. You can now use this HSM-protected key in your managed key vault. After successfully importing the key into the HSM in Azure Key Vault, copy URL ID for use with the supported service in Office 365 and Azure. See section § USING YOUR IMPORTED KEY WITH OFFICE 365 AND AZURESERVICE .
66 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
View the HSM-protected key from the Azure portalWith the Key Vault user interface in the Azure portal, you can browse existing vaults, create new vaults, set access policies and other attributes, create/edit tags for your key vaults, create and update keys and secrets, view current and older versions of your keys and edit attributes. All your existing managed vaults in Azure Key Vault should automatically show up when you browse resources from the Azure portal. To view the existing HSM-protected key we have just imported, proceed with the following steps:
1. Open a browsing session and navigate to the Azure portal at https://portal.azure.com/.
2. Sign in to the Azure portal as the subscription admin user. This is for instance the same Microsoft Account that you used to sign up for Azure as per previous section.
3. From All Resources search for your Key Vaults, for example Litware369KeyVaultHSM in our illustration, and open it:
4. Under Overview, select Keys to open the Keys container references.
67 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
5. Under Keys, you can see the HSM-protected Key friendly name: TestFirstKey (see section § UPLOADING YOUR KEY TO YOUR HSM-BASED VAULT).Click on it.
6. You can now see the older version and the status. Click on it to open this version.
7. From this window you can see the HSM-protected key references. Note the Key Type= RSA-HSM and URL Key Identifier that can be used with Office 365 and Azure cloud service.
8. Close all windows from the Azure portal.
68 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Using your imported key with Office 365 and Azure serviceFollowing sections illustrate in a non-exhaustive manner a situation where you can benefit from the BYOK capability of Azure Key Vault. For that purpose, Azure Information Protection is taken as an example.
Tenant key with Azure Information ProtectionRegulatory requirements occasionally mandate that customers must have complete control of the encryption keys used in Azure Information Protection. Other times customers simply prefer to maintain control over their secrets and are not prepared to allow Microsoft to control the management of these sensitive objects.
Fulfilling Azure Information Protection prerequisites To use keys stored in HSMs in Azure Key Vault, you must have Azure Information Protection Premium P1 licenses.
Installing Azure Rights Management (or AIP) administration module for Windows PowerShellThe Windows Azure AD Rights Management Administration tool (that can be used for Azure Information Protection) contains the Windows Azure Rights Management (administration module for Windows PowerShell, a set of Windows PowerShell cmdlets29 that provide administrative (advanced) capabilities for the Azure Information Protection service. You will need these cmdlets on an on-going basis to manage your Azure Information Protection 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 MANAGEMENT 30.
Prior installing this tool, you must have Microsoft Online Services Sign-In Assistant (MOS SIA) 7.0 installed.
29 WINDOWS AZURE RIGHTS MANAGEMENT CMDLETS: http://msdn.microsoft.com/library/windowsazure/dn629398.aspx30 INSTALLING WINDOWS POWERSHELL FOR AZURE RIGHTS MANAGEMENT: http://technet.microsoft.com/en-us/library/jj585012.aspx
69 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Note The Microsoft Online Services Sign-In Assistant (MOS SIA) 7.0 provides sign-in capabilities to the Azure Information Protection 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) 31.
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 RTW32 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.
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.
31 DESCRIPTION OF MICROSOFT ONLINE SERVICES SIGN-IN ASSISTANT (MOS SIA): http://community.office365.com/en-us/w/office/534.aspx32 Microsoft Online Services Sign-In Assistant for IT Professionals RTW: https://www.microsoft.com/en-us/download/details.aspx?id=41950
70 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
To now install the Azure AD Rights Management admin cmdlets (AADRM PowerShell module), proceed with the following steps:
1. Open an admin PowerShell command and run:
PS> Save-Module -Name AADRM -Path <path>
All details available from the following link: PowerShell Gallery33.
2. Install the AADTM module by executing the following command:
PS> Install-Module -Name AADRM
The cmdlets of the Microsoft Rights Management administration module for Windows PowerShell will be used in the next section for getting the current configuration of the Azure Information Protection service.33 AADRM PowerShell module: https://www.powershellgallery.com/packages/AADRM/
71 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Configuring Azure Information Protection to use the HSM-based key We will configure the Azure Key Vault to allow Azure Information Protection to access the Key. Finally, we will associate the HSM stored key with Azure Information Protection. To configure Azure Information Protection to use the HSM-based key that you previously imported into the vault thanks to the BYOK procedure, you must provide Azure Information Protection with an access to that key, and then to associate the key with Azure Information Protection. Proceed with the following steps:
1. Open an elevated Windows PowerShell or PowerShell Integrated Scripting Environment (ISE) prompt.
2. Run the following command to log into the Aadrm Service:
PS C:\> Connect-AadrmService
3. Run the following command to set the access policy to the vault:
This will return the details of the imported key from your HSM on-premises.
<INSERT cmdlet output>
Copy the Id field for use in the next command. The Id field should be in the following format:https://Litware369KeyVaultHSM.vault.azure.net/keys/LitwarE369FirstHSMKey/aaaabbbbccccdddd1111222233334444
72 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Enabling and using your Azure Information Protection service tenantThis section applies whether you let Microsoft generate your key (the default) or you generated and transferred your key to the Azure Information Protection service (over the Internet or in person). After you have transferred your key (over the Internet or in person), you must enable Azure Information Protection service. You can do this by using one of the following options.
1. Enabling your Azure Information Protection service tenant from the Office 365 admin center.
-or-2. Enabling your Azure Information Protection service tenant for the classic Azure Portal.
Option 1 - Activating your service tenant from the Office 365 admin centerTo do this, proceed with the following steps:
1. From an online workstation, navigate to the Azure Information Protection service administration portal such as the Office 365 admin center at https://portal.microsoftonline.com and login and login with your administrative credentials.
2. In the left pane of the administration portal, click Service Settings.3. From the Service Settings page, click Rights Management.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 Information Protection service is successfully activated you will see the following:
73 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
Option 2 - Activating the service tenant for the Azure PortalThis 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 classic Azure portal at https://manage.windowsazure.com and login with your administrative credentials.
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 Information Protection topic to confirm AIP 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.After enabling the service tenant, you can now configure your Exchange servers, SharePoint servers, and your users’ devices to point to this Azure Information Protection service’s tenant and start using it.
Getting usage logs for your keyYou can configure the Azure Key Vault service to monitor when and how your key vault assigned to the Azure Information Protection service is accessed and by whom.When Key Vault logging is activated, logs will be stored in an Azure storage account that you provide. A new container named insights-logs-auditevent is automatically created for your specified storage account, and you can use this same storage account for collecting logs for multiple key vaults.Here is the kind of information you can find logged:
All authenticated REST API requests are logged, which includes failed requests as a result of access permissions, system errors or bad requests.
Operations on the key vault itself, which includes creation, deletion, setting key vault access policies, and updating key vault attributes such as tags.
Operations on keys and secrets in the key vault, which includes creating, modifying, or deleting these keys or secrets; operations such as sign, verify, encrypt, decrypt, wrap and unwrap keys, get secrets, list keys and secrets and their versions.
Unauthenticated requests that result in a 401 response. For example, requests that do not have a bearer token, or are malformed or expired, or have an invalid token.
74 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
This information is very useful to detect abnormal situations such as a spike of failed attempts to use the key during off hours (insider trying to reach sensitive documents) or if an illegitimate user attempts to read the AIP Key…. This can also be useful for performing forensics analysis when there is an information leak.This feature is available to you whether you let Microsoft generate your key (the default) or you bring your own key (BYOK). To turn on logging and get these logs, follow the instructions outlined in the article AZURE KEY VAULT LOGGING 34.The logs you receive from the Azure Key Vault will contain every transaction performed with your tenant key.
Note For more information, see article LOGGING AND ANALYZING USAGE OF THE AZURE RIGHTS MANAGEMENT SERVICE 35 and/or whitepaper GET USAGE LOGS FROM AZURE RMS 36.
Revoking your keyWhen you unsubscribe from the Azure Information Protection service, you can revoke your tenant key in the configured managed key vault in Azure Key Vault. So, the Azure Information Protection service will stop using your key.We do not recommend deleting the key, as it will also delete all associated metadata used by cloud services for data encryption; deleting and re-importing the key will not revoke and give again the access to encrypted data handling by cloud services.Keep in mind that even a compromised key can be needed to decrypt old encrypted content that will be re-encrypt with a new key.
Note For more information, see article OPERATIONS FOR YOUR AZURE INFORMATION PROTECTION TENANT KEY 37.
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.
With the Bring-Your-On-Key (BOYK) scenario, you roll your key by repeating the steps in Section § ERROR: REFERENCE SOURCE NOT FOUND.34 AZURE KEY VAULT LOGGING: https://docs.microsoft.com/en-us/azure/key-vault/key-vault-logging35 LOGGING AND ANALYZING USAGE OF THE AZURE RIGHTS MANAGEMENT SERVICE: https://docs.microsoft.com/en-us/information-protection/deploy-use/log-analyze-usage36 GET USAGE LOGS FROM AZURE RMS: http://download.microsoft.com/download/F/6/3/F63C9623-053F-44DD-BFA8-C11FA9EA4B61/Get-Usage-Logs-from-Azure-RMS.docx37 OPERATIONS FOR YOUR AZURE INFORMATION PROTECTION TENANT KEY: https://docs.microsoft.com/en-us/information-protection/deploy-use/operations-tenant-key
75 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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 Information Protection service retains your old key reference so that it can issue licenses for such old content.
Note For more information, see article OPERATIONS FOR YOUR AZURE INFORMATION PROTECTION TENANT KEY 38.
Backing up and recovering your keyIf 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. MicrosoftAfter the Tokenized Key file is imported into the HSM in Azure Key Vault, Microsoft cannot export this key back to you so it’s extremely important that you back up your key and security world safely. Contact Thales for guidance and best practices for backing up your key.
Note For more information, see article OPERATIONS FOR YOUR AZURE INFORMATION PROTECTION TENANT KEY 39.
Exporting your keyIf you bring in your own key, you CANNOT export your key from your HSM-based key vault in Azure Key Vault. The Azure Key Vault service’s copy is non-recoverable.
Responding to a breachNo 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 Information Protection 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.
38 Ibid.39 Ibid.
76 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure
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) aboveAn 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 Information Protection service system to support new algorithms and/or longer key lengths that are resilient, and have all customers roll their keys.
77 Bring Your Own Key (BYOK) with Azure Key Vault for Office 365 and Azure