PKI-based solutions continue to grow in popularity - more and more websites are switching to HTTPS, enterprises are introducing digital certificates for authenticating users and computers, S / MIME is proving its ability to encrypt email, and as a way to verify the source of messages to counter phishing. But encryption and authentication in these applications is practically meaningless without proper key management.

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

In many cases, secret keys are your employees' personal IDs (and, therefore, part of the organization’s personal data), so their protection equals fingerprint protection when using biometric credentials. You will not allow a hacker to get the imprint of your finger? The same 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, the recommendations for SSL / TLS certificates differ from those for end-user certificates).

Certificate / Key Store in OS and Browsers

Examples: Windows Certificate Store, Mac OS Keychain

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

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

If you decide to choose this option, you should consider several aspects. First, even if you mark a private key as non-exportable, some utilities can bypass this protection (that is, the impossibility of exporting is not guaranteed). In addition, if someone worked under your account, and you did not include strong private key protection (password when using the 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 the private key protection enabled, the password is not asked when exporting.

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

Typical applications:

• Digital signatures (for example, Adobe Acrobat, Microsoft Outlook, and Office will access the Windows [custom] certificate store).
• Microsoft IIS Server is also looking for SSL certificates in the Windows certificate store [shared for computer].
• Client (user or computer) authentication, depending on the settings, most often refers to the Windows certificate store.
• Signature code in Windows (applications and drivers).

.Pfx and .jks files (keystores)

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

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

If you cannot use cryptographic equipment or 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 flash drive, which will be in a safe place. . Of course, some convenience is lost here, so if you need to frequently use a signature, you would rather want to store the file locally for easier access.

Typical applications:

• Signing Windows or Java code.
• FDA ESG and IRS IDES use .pfx to communicate securely with US government agencies.
• Some web servers (for example, Apache Tomcat or Jboss).

* Note: Java recently switched 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 hardware. 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 hardware 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 additionally secure the private key that has already been generated earlier (that is, not on the token itself), then you can import the .pfx file to the token, and then delete the original .pfx.

With a token, every time you use a certificate, you must enter a password. This means that even if someone gets your token, they still need a password. Keeping 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 this option. In addition to the additional difficulties of managing tokens, this option may not work with automatic builds due to the requirement to enter a password every time the certificate is used. 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 use cases listed for storage in OS / browser (signature of documents and code, client authentication, Windows IIS), support crypto tokens or smart cards - if there are appropriate drivers. However, this is not always practical (for example, in web servers or automated assembly systems for code signing, which will require a password to be entered each time a signature is applied).

Compliance with regulatory requirements is one of the main reasons for using cryptographic tokens.

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

Cryptographic Hardware Modules (HSM)

HSM is another hardware key storage solution, especially if you don’t want to rely on individual tokens or this seems too burdensome. While tokens are more focused on manual input or individual applications (for example, signing a small number of documents or code, authenticating with 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 support basic requirements and SLAs. HSM maintenance can be an expensive and resource-intensive process, which in the past has prevented the spread of this technology. Fortunately, in recent years, cloud-based HSM modules have emerged that provide many of the advantages of local HSM without needing local maintenance.

An example would be the familiar Key Vault service in the Microsoft Azure cloud, which stores cryptographic keys in the cloud-based HSM from Microsoft. If you have a small organization that does not allow itself to purchase and manage its own HSM, then this is an excellent 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 the HSM cloud storage for private keys. It is worth noting that the new service supports individual signatures of all employees. In the past, most signature-based HSM solutions supported only identifiers at the level of departments or organizations (for example, accounting, marketing, finance) and not for individuals (for example, John Doe). Therefore, to work at the level of individual employees, organizations had to deploy the infrastructure of tokens, which, as we noted above, can be burdensome. With this new service, digital signatures of individual employees are introduced without the need to independently manage HSM (and without the risk of employees losing tokens).

Typical applications:

• Signature of documents or code in large quantities.
• SSL (depending on server configuration).
• The CA infrastructure for running your own CA (root CA, subordinate CA, RFC 3161 time stamp server) is offline or online (the root CA usually works offline).

Future key storage methods

We considered the main options that have been used for many years. But it seems that nothing in the world of information security, including the storage of keys, is immune to 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 increasingly they are used to protect private keys. The TPM 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, which makes it a very useful authentication method for endpoints such as laptops, servers, and IoT device manufacturers. While many laptops are already shipped with TPM, this technology is not 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 has created a problem when many anonymously interacting devices make it easier for hackers to intercept messages or impersonate devices. The TPM module is implemented 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 for signing and issuing 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 Infineon to develop Internet of Things solutions that combine PKI based device identification with TPM-based trust roots. For more information, read the proof of concept: "Secure authentication and hardware management using Infineon's GlobalSign and Cloud Certificate Service OPTIGA TPM."

Physically uncloneable functions (PUF)

The technology of physically non-cloning functions (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 static SRAM of a particular chip and only exist when the power is turned on. That is, instead of storing the private key securely, 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 uncontrollable disorder in the silicon structure of the chip.

PUF technology combined with a trusted execution environment (TEE) is an attractive solution if you need low-cost, easy-to-integrate and ultra-secure key protection. PUFs, along with the PKI, constitute a comprehensive identification solution.

Our partner Intrinsic ID has developed a key preparation system based on SRAM PUF, which produces unique, tamper-proof and copy-protected device identifiers at the hardware level. Using our certification services, we translate these identifiers into digital identities, adding PKI capabilities. Thus, each device is assigned a unique key pair protected from cloning, which is not stored on the device in the off state, but the device is able to recreate this key upon request. This protects against an attack on a switched off device.

More about our joint identification solution.
IoT devices; see a recent webinar: “Persistent Device Ids with SRAM PUF Certificates” .

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

Keeping a private key should not be black magic. Ultimately, the correct option depends on who and what uses the certificates, what standards you have to follow, what the price is, the current environment and internal resources. I hope this article will help in your decision.

_______________________________________________________

---

PROMOTION GLOBALSIGN: Wildcard SSL + 1 YEAR AS A GIFT
Protect all subdomains with one certificate!

Save up to 30 thousand rubles when you buy Wildcard SSL certificate for 2 years!
Promotional Code: WC001HRFR

The promotion is valid for subscribers of the blog GlobalSign 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 promotional code.