This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Key Management Cheat Sheet"

From OWASP
Jump to: navigation, search
(Trust Stores)
m (Point to the official site)
 
(8 intermediate revisions by 5 users not shown)
Line 1: Line 1:
= DRAFT CHEAT SHEET - WORK IN PROGRESS =
+
__NOTOC__
 +
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
  
= Introduction =
+
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!
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:  
 
  
<ul>
+
Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html Key Management Cheat Sheet] to see the latest version of the cheat sheet.
<li>key life cycle management (generation, distribution, destruction)</li>
 
<li>key compromise, recovery and zeroization</li>
 
<li>key storage</li>
 
<li>key agreement</li>
 
</ul>
 
 
 
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 ==
 
 
 
<ul>
 
 
 
<li> Developers must understand where cryptographic keys are stored within the application. Understand what memory devices the keys are stored on.</li> 
 
 
 
<li> Keys must be protected on both volatile and persistent memory, ideally processed within secure cryptographic modules.</li>   
 
 
 
<li> Keys should never be stored in plaintext format.</li>   
 
 
 
<li> 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.</li>   
 
 
 
<li> Ensure that keys have integrity protections applied while in storage (consider dual purpose algorithms that support encryption and Message Code Authentication (MAC)).</li> 
 
 
 
</ul>
 
 
 
== Escrow and Backup ==
 
 
 
=== Key Escrow ===
 
 
 
=== Key Backup ===
 
 
 
== Tracking and Audit ==
 
 
 
== Key Compromise and Recovery ==
 
 
 
= Trust Stores =
 
 
 
<ul>
 
<li> 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 </li>
 
<li> Implement integrity controls on objects stored in the trust store.</li>
 
<li> Do not allow for export of keys held within the trust store without authentication and authorization.</li>
 
<li> Setup strict policies and procedures for exporting key material from applications to network applications and other components.</li>
 
<li> Implement a secure process for updating the trust store</li>
 
</ul>
 
 
 
= 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<br/>
 
 
 
Drew Van Duren - drew.f.van.duren[at]leidos.com
 
 
 
Vanessa Amador - vanessa.c.amador[at]leidos.com
 
 
 
= Other Cheatsheets =
 
 
 
{{Cheatsheet_Navigation}}
 
 
 
[[Category:Cheatsheets]]
 
 
 
{{OWASP Builders}}
 

Latest revision as of 14:38, 15 July 2019

Cheatsheets-header.jpg

The Cheat Sheet Series project has been moved to GitHub!

Please visit Key Management Cheat Sheet to see the latest version of the cheat sheet.