Operational Best Practices for Securing Cryptographic Keys
Protecting the millions of gigabytes of data that are created, transmitted, and stored every day is a complex challenge. This data is generally secured with cryptography to make sure would-be attackers cannot read the information that is often sensitive and private. However, even the strongest cryptographic ciphers cannot keep data safe if the cryptographic keys are compromised.
Hackers know this, so rather than trying to break complex ciphers, they often invest their efforts in stealing cryptographic keys instead. Once they have obtained the keys, cyber-criminals can eavesdrop on secure communications, manipulate network transactions, impersonate a user, and even exfiltrate sensitive information.
Increasingly common, and difficult to defend against, are side-channel attacks which exploit indirect, ancillary information to identify and extract cryptographic keys. These types of attacks take many forms including sophisticated differential fault analysis, memory access pattern or cache attacks, timing analysis, and interventions around power usage data.
Another well-known type of side-channel attack exploits speculative execution vulnerabilities. Recent examples include CacheOut and Zombieload, which leak data on Intel processors via cache evictions,
Best practices for securing data with cryptography should focus on three areas—generation, storage, and usage.
Depending on the purpose of the cryptography and the sensitivity of the data being encrypted, the generation of cryptographic keys can change. It is important to employ strong algorithms and to ensure keys are only generated for a single specific purpose rather than for repetitive usage. Data encryption, user authentication, digital signatures, and key wrapping for exchanging keys are examples of single-purpose cryptographic keys.
There are varying strengths to popular cryptographic systems which are typically applied to data based on the sensitivity and importance of the information itself. For instance, symmetric key algorithms such as AES-128, AES-192, and AES-256 are used by the U.S. government for data classified as Top Secret, while soon-to-be deprecated 3DES provides security to a level of around 112 bits.
There is also asymmetric cryptography, which is commonly known as public-key cryptography. It is designed to use agreements formed from a public and private key to create safe ways to exchange and decrypt protected data. Some of these methods, approved by the U.S. National Institute of Standards and Technology (NIST), include Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA), as well as RSA, Diffie-Hellman, and MQV.
A chief vector of attack for hackers looking to steal cryptographic keys is through a compromised device or application. Bad actors can reverse engineer code, analyze how it works, and then determine where and how to extract keys. Device manufacturers and application publishers therefore must fortify the key storage of their product prior to shipment so that it can deal with attacks that occur outside of their secure environments.
From the standpoint of hardware-backed secure key storage, there are a number of hardware protection options for cryptographic keys. This spans hardware security modules (HSM), trusted platform modules (TPM), and trusted execution environments (TEE).
These come in the form of chips, cards, or devices that store cryptographic keys and perform functions such as encryption, decryption, strong authentication, and digital signing. They provide excellent protection for keys but are often considered cumbersome and costly to employ. They are also vulnerable to side-channel attacks and in situations where an attacker has root privileges, like with jailbroken phones.
Major platforms and OSes, such as Android, Microsoft, Apple, and Java, provide their own key stores to guarantee a level of cryptographic key security for their users. These are backed by hardware-based security where available. They are sufficient as a basic level of protection for most operations, especially where high-value or sensitive information is not involved. However, their security strength varies across devices and the lack of standardization means that cryptographic operations must be re-implemented for each platform
White-box cryptography, on the other hand, uses software-based algorithms to provide protection for cryptographic keys no matter where they are, even without hardware support. It is also employed under the assumption of a hostile, compromised environment to protect against reverse engineering and runtime analysis on compromised devices.
For example, a white-box cryptography implementation approach provides a drop-in cryptographic library that ensures cryptographic keys in mobile, desktop, and web apps remain protected even if an adversary gets root access to the device. Implementations can offer cross-platform interoperability and the ability to support a wide range of cryptographic operations.
Among the most critical elements of cryptographic key security is their vulnerability during use. While many security processes may focus on keeping cryptographic keys safe in a device or app, it is during use that they are often most at risk. By nature, cryptographic keys must appear somewhere when they are being used. Unfortunately, there are many weapons in a hacker’s arsenal that seek to steal them at exactly that moment, including malware, malicious apps, and side-channel attacks.
For those reasons, a best practice is to focus on protecting keys while they are performing cryptographic operations. This can be achieved by executing cryptographic functions within hardware-backed security with the same limitations as previously described, or by using white-box cryptography to make sure keys do not appear in the clear during runtime.
As cryptographic ciphers have become stronger and faster, hackers have moved away from trying to crack them. Instead, the focus has shifted to stealing the cryptographic keys that underpin them. Unfortunately, as strong as any algorithm may be, it is only as safe as the keys that are being used. If those can be extracted, an attacker can circumvent protections and decrypt stolen data, pose as an authenticated user, or perform other malicious actions.
Latest posts by Ben Canner (see all)
- Identity Management Experts’ Commentary on the Pixlr Data Exposure - January 21, 2021
- User and Non-User Identities in Your Network: Securing Both is the Key - January 19, 2021
- Solutions Review Releases 2021 Buyer’s Guide for Biometric Authentication - January 13, 2021