Revision as of 20:42, 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

Key Escrow

Key Backup

Tracking and Audit

Key Compromise and Recovery

Trust Stores

Population

Secure Update

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