Cryptographic Key Storage Options

Original author: Govind Yadav
  • Transfer
PKI-based solutions continue to grow in popularity - more and more sites are switching to HTTPS, enterprises are introducing digital certificates for authentication of users and computers, S / MIME is proving its worth for email encryption, and as a way to check the message source to prevent phishing. But encryption and authentication in these applications are practically meaningless without proper key management.

Each time you issue a digital certificate from a certification authority (CA) or a self-signed certificate, you need to generate a pair of private and public keys. According to best practices, your private keys must be protected and, well ... secret! If someone receives them, they can, depending on the type of certificate, create phishing sites with your organization’s certificate in the address bar, authenticate themselves in corporate networks, impersonating you, sign applications or documents on your behalf, or read your encrypted emails .

In many cases, secret keys are personal identities of your employees (and, therefore, part of the organization’s personal data), so protecting them is equivalent to protecting fingerprints using biometric credentials. You won’t let the hacker get your fingerprint? Same thing with secret keys.

In this article, we will discuss options for protecting and storing private keys. As you will see, these options may vary slightly depending on the type of certificate (s) and how you use it (for example, recommendations for SSL / TLS certificates differ from recommendations for end-user certificates).

Certificate / key stores in OS and browsers

Examples: Windows certificate store, Mac OS keychain

Some operating systems and browsers have certificate or key stores. These are software databases that locally on your computer store a pair of private and public keys as part of the certificate. Such key storage is quite popular: many applications automatically immediately look for keys here, and you do not need to manually specify a certificate file each time, so this is a pretty convenient option.

Another plus of this option is that it is quite easy to configure. You can enable / disable the export of the private key, enable reliable protection for it (entering a password each time you use the certificate), and you can create backup copies if the private key is exported. In addition, when you enable profile roaming in Windows, the certificate is attached to the profile and becomes available when you log on to another computer with this profile.

If you decide to choose this option, then you should consider several aspects. Firstly, even if you mark the private key as non-exportable, some utilities can bypass this protection (that is, the inability to export is not guaranteed). In addition, if someone worked under your account, and you did not enable strong private key protection (password when using a certificate), then they can use your certificate. Finally, if your private key is marked as exportable, then someone at your computer will be able to export it. Even if you have private key protection enabled, the password is not asked when exporting.

Last but not least: Chrome and IE use the Windows certificate store, while Firefox has its own certificate store (from Mozilla). This means that if you import the certificate into the Windows store, then Chrome and IE will automatically find it, but Firefox will not.

Typical applications:

  • Digitally signed applications (such as Adobe Acrobat, Microsoft Outlook, and Office will access the Windows certificate store [custom]).
  • The Microsoft IIS server also looks for SSL certificates in the Windows certificate store [common to the computer].
  • Authentication of the client (user or computer), depending on the settings, most often accesses the Windows certificate store.
  • Signing code on Windows (applications and drivers).

.Pfx and .jks files (keystores)

The PKCS # 12 files (.pfx or .p12) and .jks * (created by the Java Keytool tool) contain your private and public keys. Unlike local storages for OS and browsers, these files can be located almost anywhere, including remote servers, and are always password protected (that is, every time you use your secret key, you need to enter a password). Another attractive feature: since these are just files, it is easy to send out copies for several people who need to use a certificate.

If you decide to save the file on a remote server, you should especially take care of restricting access to it. If someone gets access, they can use your certificate. Similarly, one should be especially careful with the easy copying and distribution of these files. Although this is a great convenience for you, it will also be easy for an attacker to make a copy if he gains access to your keystore. The private key password is still needed for efficient use of the copied file. This is another reason to use strong passwords of 15 or more characters, containing uppercase letters, numbers and special characters. With this storage option, one more thing needs to be taken into account: the end user has more responsibility in terms of where the file is located and whether it is stored correctly.

If you can’t use cryptographic equipment or the Windows keystore (described above), but still want to increase security (instead of just placing the keystore file on your computer), you can write this file to a USB flash drive, which will be in a safe place . Of course, some convenience is lost here, so if you need to use the signature often, then you probably want to store the file locally for easy access.

Typical applications:

  • Signing Windows or Java code.
  • FDA ESG and IRS IDES use .pfx to securely contact US government agencies.
  • Some web servers (e.g. Apache Tomcat or Jboss).

* Note: Java has recently migrated from JKS to PKCS # 12 as the default keystore type.

Cryptographic Tokens and Smart Cards

As casually mentioned above, you can increase security by storing the secret key on separate equipment. But there is a big difference between using cryptographic tokens or smart cards and standard flash drives. With cryptographic equipment, the key is generated on the equipment itself and is not exported. The private key never leaves the device, which makes it difficult for an outsider to gain access and compromise.

Note: if you want to further secure the private key that has already been generated earlier (i.e., not on the token itself), then you can import the .pfx file into the token, and then delete the original .pfx.

With a token, every time you use a certificate, you need to enter a password. This means that even if someone receives your token, they will still need a password. Storing a key in a token means that you can safely use the same certificate on multiple computers without having to create multiple copies and go through the export / import process. Cryptographic equipment complies with FIPS , which is required for some industry and government regulations.

Of course, there are some other considerations to keep in mind if you decide to choose one. In addition to the additional difficulties of managing tokens, this option may not work with automatic assemblies due to the requirement to enter a password each time you use a certificate. There is also no way to back up the certificate, since the private key is not exported (lack of additional security). Finally, in some scenarios, this storage option is simply not possible. For example, if specialized devices do not support tokens or smart cards. Or in situations where employees do not have physical access to the computer, but work from remote terminals.

Typical applications:

As a rule, all the use cases listed for storages in the OS / browser (signing documents and code, client authentication, Windows IIS) support crypto tokens or smart cards - if there are corresponding drivers. However, this is not always practical (for example, in web servers or automated build systems for signing code, which will require a password every time you apply a signature).

Regulatory compliance is one of the main reasons for using cryptographic tokens.

  • Mandatory for signing an Extended Validation (EV) code as recommended by the CA / Browser forum .
  • Recommended for standard code signing in accordance with the minimum requirements of the CA Security Council . Certificate authorities are required to recommend cryptographic equipment as the primary option for issuing certificates. If cryptographic equipment is not issued, the client must sign an agreement that he will keep the private key on some removable equipment (which is removed after signing).
  • Required for digital signature and trusted status in Adobe programs, in accordance with the requirements of the Adobe Approved Trust List (AATL) .
  • Industry rules, such as the CFR 21 Part 11 from the FDA and digital signature requirements in individual countries, often indicate a secret key that is held solely by the owner. Storage on cryptographic equipment meets these requirements.

Hardware Cryptographic Modules (HSM)

HSM is another hardware key storage solution, especially if you don't want to rely on individual tokens or it seems too burdensome. While tokens are more focused on manual input or individual applications (for example, signing a small amount of documents or code, authentication in VPN or other networks), HSMs provide APIs, support automated workflows and automated assembly. They also comply with FIPS requirements and usually provide a higher rating than tokens.

Traditionally, HSMs are local physical devices that require qualified resources to manage and provide basic requirements and SLAs. HSM service can be expensive and time consuming, which in the past has hindered the spread of this technology. Fortunately, in recent years, HSM cloud modules have emerged that provide many of the benefits of on-premises HSMs without the need for on-premises maintenance.

An example is the familiar Key Vault service in the Microsoft Azure cloud, which stores cryptographic keys in Microsoft's cloud HSM. If you have a small organization that cannot afford to purchase and manage your own HSM, then this is a great solution that integrates with public certification authorities, including GlobalSign .

If you are considering the option of signing documents, we recently launched a new Digital Signing Service, which also uses HSM cloud storage for private keys. It is worth noting that the new service supports the individual signatures of all employees. In the past, most HSM signature solutions only supported identifiers at the department or organization level (e.g., bookkeeping, marketing, finance), and not individuals (e.g., John Doe). Therefore, to work at the individual employee level, organizations had to deploy token infrastructure, which, as we noted above, can be burdensome. With this new service, digital signatures of individual employees are implemented without the need to independently manage HSMs (and without the risk of employees losing tokens).

Typical applications:

  • Signature of documents or code in large quantities.
  • SSL (depending on server configuration).
  • The infrastructure of the CA for the operation of its own CA (root CA, subordinate CA, RFC 3161 timestamp server) offline or online (the root CA, as a rule, works offline).

Future Key Storage Methods

We examined the main options that have been used for many years. But it seems that nothing in the world of information security, including key storage, is immune from the influence of IoT, so new options are being developed.

As more and more devices connect to the network with the need for authentication and secure data exchange, many developers and manufacturers are turning to PKI-based solutions. In turn, this leads to new considerations, requirements, and technologies for protecting private keys. Below are two trends that we see in this area.

Trusted Platform Module (TPM)

TPMs are not new in themselves, but are increasingly being used to protect private keys. The trusted platform module can be used to store (or transfer) the root key and protect additional keys created by the application. Application keys cannot be used without TPM, making it a very useful authentication method for endpoints such as laptops, servers, and IoT device manufacturers. While many laptops already come with TPM, so far this technology is not too widely used in the corporate sector. However, in the IoT world, they are often used to securely identify devices as the hardware root of trust .

IoT created a problem where many anonymously interacting devices make it easier for hackers to intercept messages or impersonate devices. TPM module is introduced at the production stage to protect the cryptographic key and, therefore, for reliable identification of the device.

During production, a pair of private and public keys is generated. The public key is sent to a certification authority to sign and issue a digital certificate. The private key never leaves the device. It is stored on a chip and cannot be exported / copied / destroyed. Now the certificate is a device passport, and the protected private key forms the hardware root of trust.

We work closely with Infineonto develop IoT solutions combining PKI-based device identification with TPM-based trusts. For more information, check out the proof of concept: “Secure Authentication and Equipment Management with Infineon’s GlobalSign and OPTIGA TPM Certificate Cloud Services.”

Physically Unclonable Functions (PUF)

Physically Nonclonable Feature Technology (PUF) is a paradigm shift in key protection. Instead of storing keys (with the probability of a physical attack), they are generated from the unique physical properties of the SRAM static memory of a particular chip and exist only when the power is turned on. That is, instead of reliable storage of the private key, the same key is restored again and again on demand (until the device fails). This key is guaranteed to be unique because the generation uses the inherent uncontrolled disorder in the silicon structure of the chip.

PUF technology combined with Trusted Execution Environment (TEE) is an attractive solution for low-cost, easy-to-integrate, and ultra-secure key protection. PUFs together with PKIs constitute a comprehensive identification solution.

Our partner Intrinsic ID has developed such a key preparation system based on SRAM PUF, which produces unique hardware-protected device identifiers that are protected from counterfeiting and copying. Using our certification services, we translate these identifiers into digital identities, adding PKI capabilities. Thus, each device is assigned a unique, key-protected key pair that is not stored on the device in the off state, but the device is able to recreate this key upon request. This protects against attacks on a turned off device.

For more information about our collaborative IoT
device identification solution, see the recent webinar, “Persistent SRAM PUF Based Device Identifiers with Certificates” .

Do not lose the (secret) keys to your castle!

Private key storage should not be black magic. Ultimately, the correct option depends on who uses the certificates for what, what standards must be observed, what is the price, current environment and internal resources. I hope this article helps in your decision.


Protect all subdomains with one certificate!

Save up to 30 thousand rubles when buying a Wildcard SSL certificate for 2 years!
Promo code: WC001HRFR

The offer is valid for GlobalSign blog subscribers until June 15, 2018.

For more information, please contact GlobalSign managers by phone: +7 (499) 678 2210 or by filling out a form on the website indicating the promo code.

Also popular now: