Common Challenges with Key Management: Governance (Part 6 of 6)

Image credit: Photo by blocks on Unsplash

The Importance of Governance in Key Management Solutions

The passage and implementation of the European Union’s General Data Protection Regulation (GDPR) kicked off a wave of new data privacy regulations. Now, new laws like the California Consumer Privacy Act (CCPA) mandate that organizations protect a growing range of sensitive data. This is in addition to the requirements of existing laws, such as the Payment Card Industry Data Security Standard (PCI DSS) and the Health Insurance Portability and Accessibility Act (HIPAA), that are designed to protect sensitive data within certain industries.

The specific requirements of these laws can vary greatly, but the protection of sensitive data using encryption is a common one. In some cases, a regulation may mandate the use of a particular algorithm or suite of algorithms (such as the suite of algorithms approved by NIST), while others leave the details up to the business.

Common Key Management Mistakes

Organizations need to meet the requirements of data privacy laws in order to continue operating within their jurisdictions using the sensitive data that they protect. However, taking a “check the box” approach to compliance can do more harm than good. While the use of a particular algorithm may enable a company to pass an audit, if that algorithm is implemented or used incorrectly, it can provide little or no protection against data breaches.

Encryption Misuse

Cryptography can be complicated, and many developers don’t have a deep cryptographic background. As a result, they may take an approach to cryptography that is guided by answers on internet forums (such as Stack Overflow) or focused on getting the code to compile without errors, instead of ensuring that code free of security defects, and implemented solutions to cryptographic problems are properly vetted.

However, cryptography can be fragile, and cryptographic algorithms are designed to be used for specific purposes. Using the wrong algorithm for a given application or using the right algorithm in the wrong way can eliminate any security benefits that it could provide and may place the sensitive data or encryption key at risk of exposure.

Insecure Implementation

Commonly used cryptographic algorithms like the Advanced Encryption Standard (AES) or Rivest-Shamir-Adleman (RSA) are openly published. This transparency is a key part of their security because it allows them to be peer-reviewed and tested for any potential weaknesses and exploitable vulnerabilities.

Open publication also makes it possible for developers to create their own implementations of these algorithms or the creation of new protocols based upon them. However, this can introduce additional risk. While these algorithms are designed to be secure, an implementation error or using them within a custom or broken protocol could undermine their security and place the encryption key and encrypted data at risk of exposure.

Poor Key Storage

Data protection laws or corporate policy often mandate that encryption be used for sensitive data. However, this is of limited utility if the secret keys used to encrypt the sensitive data are exposed to an attacker.

If encryption keys are insecurely stored, such as being embedded within an application, then they could be exposed to an attacker. This attacker can then use these keys to decrypt the sensitive data, placing the organization at risk of a data breach and regulatory non-compliance.

Encryption Workarounds

Cryptographic protocols can be difficult to implement correctly and securely. Additionally, the use of strong encryption and secure key management may be inconvenient to a developer if it interferes with the desired workflows and operation of their application.

As a result, developers may try to work around the requirements to ensure that they meet the requirements just enough to “check off a compliance box” while achieving their intended purpose. However, this may compromise the security of the encryption algorithm and the data that it protects.

Case Study: Zerologon

Zerologon is a recent and high-impact vulnerability in Microsoft’s domain controllers. The vulnerability would allow an attacker with access to a vulnerable domain controller to dump all user credentials stored within it or to achieve domain administrator-level permissions on the network managed by the domain controller.

This vulnerability was created by Microsoft’s use of a custom encryption protocol. While the company used a secure encryption algorithm (AES), it used it in a non-standard way to enable encryption of a single byte of data at a time. This unconventional use of AES, combined with some other details of the vulnerable Winlogon protocol made it possible to completely compromise a network with a vulnerable domain controller.

This incident demonstrates the danger of “rolling your own crypto”. For more details on how the vulnerability worked and its potential impacts, check out this blog article.

Improving Governance for Key Management Solutions with Ubiq

Achieving and maintaining compliance with data protection regulations and internal data security policies requires secure, usable encryption and key management. If an algorithm is insecurely implemented or incorrectly used, it can compromise security, but an overly complex encryption system can become unusable and impact operational efficiency.

Ubiq provides developers with access to encryption algorithms that meet regulatory standards and are simple to use. Strong encryption is implemented as libraries within a number of different common languages, and keys can be easily generated and managed via Ubiq’s API-based developer platform. To see Ubiq’s encryption and key management solution in action, check out this demo.