Key Management Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:38:01Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-14T13:00:47Z

Migration to GitHub

Show changes

Peter Mosmans: Add link to cheat sheet

2018-06-19T01:53:35Z

Add link to cheat sheet

Peter Mosmans: Add link to cheat sheet

2018-06-19T01:52:51Z

Add link to cheat sheet

Jmanico: promoted out of draft status

2018-03-01T20:48:54Z

promoted out of draft status

Susanna Bezold at 23:32, 4 June 2016

2016-06-04T23:32:22Z

Susanna Bezold at 18:15, 1 May 2016

2016-05-01T18:15:45Z

Show changes

Brian Russell: /* Standards */

2015-07-21T21:00:00Z

‎Standards

Brian Russell: /* Escrow and Backup */

2015-07-21T20:59:47Z

‎Escrow and Backup

Brian Russell: /* Trust Stores */

2015-07-21T20:50:05Z

‎Trust Stores

← Older revision		Revision as of 14:38, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/Key_Management_Cheat_Sheet.md Key Management Cheat Sheet] to see the latest version of the cheat sheet.	+	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.

@@ Line 72: / Line 72: @@
 Plan for the recovery from possible corruption of the memory media necessary for key or certificate generation, registration, and/or distribution systems, subsystems, or components as recommended in NIST SP 800.57.
 ==Perfect Forward Secrecy==
-Ephemeral keys can provide perfect forward secrecy protection, which means a compromise of the server's long term signing key does not compromise the confidentiality of past sessions. Refer to [[https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet OWASP Transport Layer Protection Cheat Sheet]].
+Ephemeral keys can provide perfect forward secrecy protection, which means a compromise of the server's long term signing key does not compromise the confidentiality of past sessions. Refer to [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet OWASP Transport Layer Protection Cheat Sheet].
 ==Proxy Handling==

@@ Line 72: / Line 72: @@
 Plan for the recovery from possible corruption of the memory media necessary for key or certificate generation, registration, and/or distribution systems, subsystems, or components as recommended in NIST SP 800.57.
 ==Perfect Forward Secrecy==
-Ephemeral keys can provide perfect forward secrecy protection, which means a compromise of the server's long term signing key does not compromise the confidentiality of past sessions. Refer to OWASP Transport Layer Protection Cheat Sheet.
+Ephemeral keys can provide perfect forward secrecy protection, which means a compromise of the server's long term signing key does not compromise the confidentiality of past sessions. Refer to [[https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet OWASP Transport Layer Protection Cheat Sheet]].
 ==Proxy Handling==
 ==Key Usage==

← Older revision		Revision as of 20:48, 1 March 2018
Line 1:		Line 1:
−	~~= DRAFT CHEAT SHEET - WORK IN PROGRESS =~~
−
	=Introduction=		=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:		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:

@@ Line 105: / Line 105: @@
 ==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 at least 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.
 ==Accountability and Audit==
 Accountability involves the identification of those that have access to, or control of, cryptographic keys throughout their lifecycles. Accountability can be an effective tool to help prevent key compromises and to reduce the impact of compromises once they are detected. Although it is preferred that no humans are able to view keys, as a minimum, the key management system should account for all individuals who are able to view plaintext cryptographic keys. In addition, more sophisticated key-management systems may account for all individuals authorized to access or control any cryptographic keys, whether in plaintext or ciphertext form.

← Older revision		Revision as of 21:00, 21 July 2015
Line 124:		Line 124:

	= Cryptographic Module Topics =		= Cryptographic Module Topics =
−
−	~~= Standards =~~

	= Cryptographic Key Management Libraries =		= Cryptographic Key Management Libraries =

@@ Line 105: / Line 105: @@
 == Escrow and Backup ==
-=== Key Escrow ===
+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.
-=== Key Backup ===
+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 ==

@@ Line 115: / Line 115: @@
 = Trust Stores =
-== Population ==
+<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>
-== Secure Update ==
+<li> Implement integrity controls on objects stored in the trust store.</li>
 = Cryptographic Module Topics =