Revision as of 20:59, 21 July 2015

DRAFT CHEAT SHEET - WORK IN PROGRESS

Introduction

This Key Management Cheat Sheet provides developers with guidance for implementation of cryptographic key management within an application in a secure manner. It is important to document and harmonize rules and practices for:

• key life cycle management (generation, distribution, destruction)
• key compromise, recovery and zeroization
• key storage
• key agreement

across the organization.

Key Management General Guidelines and Considerations

Formulate a strategy for the overall organization's cryptographic strategy to guide developers working on different applications and ensure that each application's cryptographic capability meets minimum requirements and best practices. Identify the cryptographic and key management requirements for your application and map all components that process or store cryptographic key material.

Use only reputable crypto libraries that are well maintained and updated, as well as tested and validated by 3rd party organizations (e.g., NIST/FIPS)

Key Selection

Selection of the cryptographic and key management algorithms to use within a given application should begin with an understanding of the objectives of the application. For example, if the application is required to store data securely, then the developer should select an algorithm suite that supports the objective of Data-At-Rest (DAR) security. Applications that are required to transmit and receive data would select an algorithm suite that supports the objective of Data-in-Transit security. We have provided recommendations on the selection of crypto suites within an application based on application and security objectives.

Application developers oftentimes begin the development of crypto and key management capabilities by examining what is available in a library. However, an analysis of the real needs of the application should be conducted to determine the optimal key management approach. Begin by understanding the security objectives of the application which will then drive a determination of the cryptographic protocols that should be used.

For example, the objectives of the application may be: - Confidentiality of data at rest - Confidentiality of data in use - authenticity of data origin - authenticity of the end device - Integrity of data in transit - Confidentiality of data in transit

Once the understanding of the security needs of the application is achieved, developers can determine what protocols and algorithms are required. Once the protocols and algorithms are understood, you can you can begin to define the different types of keys that will need support the application's objectives. There are a diverse set of key types and certificates to consider, for example:

Encryption: - Symmetric encryption keys - Asymmetric encryption keys (public and private)

Authentication of End Devices: - Pre-shared symmetric keys - Trusted certificates - Trust Anchors

Data Origin Authentication - HMAC

Integrity Protection - Message Authentication Codes (MACs)

Key Encryption Keys

Key Strength

Review NIST SP 800-57 (Recommendation for Key Management) for recommended guidelines on key strength for specific algorithm implementations. Also, consider these best practices:

1. Establish what the application's minimum computational resistance to attack should be. Understanding the minimum computational resistance to attack should take into consideration the sophistication of your adversaries, how long data needs to be protected, where data is stored and if it is exposed. Identifying the computational resistance to attack will inform engineers as to the minimum length of the cryptographic key required to protect data over the life of that data. Consult NIST SP 800-131a for additional guidance on determining the appropriate key lengths for the algorithm of choice.

2. When encrypting keys for storage or distribution, always encrypt a cryptographic key with another key of equal or greater cryptographic strength.

3. When moving to Elliptic Curve-based algorithms, choose a key length that meets or exceeds the comparative strength of other algorithms in use within your system. Use NIST SP 800-57 Table 2

Formulate a strategy for the overall organization's cryptographic strategy to guide developers working on different applications and ensure that each application's cryptographic capability meets minimum requirements and best practices.

Memory Management Considerations

Perfect Forward Secrecy

Proxy Handling

Key Management Lifecycle Best Practices

Generation

Distribution

EndPoint Authentication

Algorithms and Protools

Integrity and Confidentiality

Storage

• Developers must understand where cryptographic keys are stored within the application. Understand what memory devices the keys are stored on.
• Keys must be protected on both volatile and persistent memory, ideally processed within secure cryptographic modules.
• Keys should never be stored in plaintext format.
• If you are planning on storing keys in offline devices/databases, then encrypt the keys using Key Encryption Keys (KEKs) prior to the export of the key material. KEK length (and algorithm) should be equivalent to or greater in strength than the keys being protected.
• Ensure that keys have integrity protections applied while in storage (consider dual purpose algorithms that support encryption and Message Code Authentication (MAC)).

Escrow and Backup

Data that has been encrypted with lost cryptographic keys will never be recovered. Therefore, it is essential that the application incorporate a secure key backup capability, especially for applications that support data at rest encryption for long-term data stores. When backing up keys, ensure that the database that is used to store the keys is encrypted using a FIPS 140-2 validated module.

It is sometimes useful to escrow key material for use in investigations and for re-provisioning of key material to users in the event that the key is lost or corrupted. Never escrow keys used for performing digital signatures, but consider the need to escrow keys that support encryption. Oftentimes, escrow can be performed by the Certificate Authority (CA) or key management system that provisions certificates and keys, however in some instances separate APIs must be implemented to allow the system to perform the escrow for the application.

Tracking and Audit

Key Compromise and Recovery

Trust Stores

• Design controls to secure the trust store against injection of 3rd party root certificates. The access controls are managed and enforced on an entity and application basis
• Implement integrity controls on objects stored in the trust store.
• Do not allow for export of keys held within the trust store without authentication and authorization.
• Setup strict policies and procedures for exporting key material from applications to network applications and other components.
• Implement a secure process for updating the trust store

Cryptographic Module Topics

Standards

Cryptographic Key Management Libraries

This article is focused on providing application security testing professionals with a guide to assist in managing cryptographic keys.

Authors and Primary Editors

Brian Russell - russellbri[at]leidos.com

Drew Van Duren - drew.f.van.duren[at]leidos.com

Vanessa Amador - vanessa.c.amador[at]leidos.com

Other Cheatsheets

OWASP Cheat Sheets Project Homepage

• OWASP Cheat Sheet Series