Training
Module
Azure Key and Certificate Management - Training
In this module, you learn about essential concepts for using encryption keys and digital certificates in Azure to help secure cloud workloads and ensure data sovereignty.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
CNG provides a model for private key storage that allows adapting to the current and future demands of creating applications that use cryptography features such as public or private key encryption, as well as the demands of the storage of key material. The key storage router is the central routine in this model and is implemented in Ncrypt.dll. An application accesses the key storage providers (KSPs) on the system through the key storage router, which conceals details, such as key isolation, from both the application and the storage provider itself. The following illustration shows the design and function of the CNG key isolation architecture.
To comply with common criteria (CC) requirements, the long-lived keys must be isolated so that they are never present in the application process. CNG currently supports the storage of asymmetric private keys by using the Microsoft software KSP that is included with Windows Server 2008 and Windows Vista and installed by default.
Key isolation is enabled by default in Windows Server 2008 and Windows Vista. The key isolation feature is not available on platforms prior to these. Also, third party KSPs are not loaded in the key isolation service (LSA process). Only the Microsoft KSP is loaded in the key isolation service.
The LSA process is used as the key isolation process to maximize performance. All access to private keys goes through the key storage router, which exposes a comprehensive set of functions for managing and using private keys.
CNG stores the public portion of the stored key separately from the private portion. The public portion of a key pair is also maintained in the key isolation service and is accessed by using local remote procedure call (LRPC). The key storage router uses LRPC when calling into the key isolation process. All access to private keys goes through the private key router and is audited by CNG.
As described above, a wide range of hardware storage devices can be supported. In each case, the interface to all of these storage devices is identical. It includes functions to perform various private key operations as well as functions that pertain to key storage and management.
CNG provides a set of APIs that are used to create, store, and retrieve cryptographic keys. For a list of these APIs, see CNG Key Storage Functions.
CNG supports the following key types:
CNG supports the following key algorithms.
Algorithm | Key/hash length (bits) |
---|---|
RSA | 512 to 16384, in 64 bit increments |
DH | 512 to 16384, in 64 bit increments |
DSA | 512 to 1024, in 64 bit increments |
ECDSA | P-256, P-384, P-521 (NIST Curves) |
ECDH | P-256, P-384, P-521 (NIST Curves) |
MD2 | 128 |
MD4 | 128 |
MD5 | 128 |
SHA-1 | 160 |
SHA-256 | 256 |
SHA-384 | 384 |
SHA-512 | 512 |
The Microsoft legacy CryptoAPI CSPs store private keys in the following directories.
Key type | Directories |
---|---|
User private | %APPDATA%\Microsoft\Crypto\RSA\User SID\ %APPDATA%\Microsoft\Crypto\DSS\User SID\ |
Local system private | %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\S-1-5-18\ %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\DSS\S-1-5-18\ |
Local service private | %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\S-1-5-19\ %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\DSS\S-1-5-19\ |
Network service private | %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\S-1-5-20\ %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\DSS\S-1-5-20\ |
Shared private | %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\DSS\MachineKeys |
CNG stores private keys in the following directories.
Key type | Directory |
---|---|
User private | %APPDATA%\Microsoft\Crypto\Keys |
Local system private | %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\SystemKeys |
Local service private | %WINDIR%\ServiceProfiles\LocalService |
Network service private | %WINDIR%\ServiceProfiles\NetworkService |
Shared private | %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\Keys |
The following are some of the differences between the CryptoAPI and CNG key containers.
When persisting a key, CNG can create two files. The first file contains the private key in the new CNG format and is always created. This file is not usable by the legacy CryptoAPI CSPs. The second file contains the same private key in the legacy CryptoAPI key container. The second file conforms to the format and location used by Rsaenh.dll. Creation of the second file only occurs if the NCRYPT_WRITE_KEY_TO_LEGACY_STORE_FLAG flag is specified when the NCryptFinalizeKey function is called to finalize an RSA key. This feature is not supported for DSA and DH keys.
When an application attempts to open an existing persisted key, CNG first attempts to open the native CNG file. If this file does not exist, then CNG attempts to locate a matching key in the legacy CryptoAPI key container.
When you move or copy CryptoAPI keys from a source machine to a target machine with Windows User State Migration Tool (USMT), CNG will fail to access the keys on the target machine. To access such migrated keys, you must use the CryptoAPI.
Training
Module
Azure Key and Certificate Management - Training
In this module, you learn about essential concepts for using encryption keys and digital certificates in Azure to help secure cloud workloads and ensure data sovereignty.