Key destruction is a critical part of effective cryptographic key management. It ensures that keys are securely removed when no longer needed to minimize the risk of compromise. Key destruction processes must take into account relevant legal and regulatory requirements.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the full matrix here. It aligns with other industry standards and best practices for key management, such as NIST SP 800-57. For more background, check out the AWS Key Management Service Deep Dive video.

Who should care?

• Security engineers responsible for cryptographic key management
• Compliance officers needing to meet regulatory requirements around key destruction
• Developers using cryptographic keys in their applications

What is the risk?

Failure to properly destroy cryptographic keys can lead to:

• Unauthorized access to sensitive data if old keys are compromised
• Regulatory non-compliance if keys are not destroyed in accordance with requirements
• Increased attack surface from retaining unnecessary keys Proper key destruction practices can significantly mitigate these risks by ensuring keys are securely removed as soon as they are no longer needed. However, key destruction alone is not sufficient - it must be combined with other key management best practices.

What's the care factor?

For organizations dealing with regulated sensitive data (e.g. financial, healthcare), key destruction is a top priority to maintain compliance. For others, it's still important for minimizing risk but may be a lower priority than other security controls. The more sensitive the data and the more keys in use, the higher the priority key destruction should be.

When is it relevant?

Key destruction is relevant whenever cryptographic keys are no longer needed, such as:

• When data encrypted with a key is deleted
• When a cryptographic system is retired or replaced
• On a regular schedule based on key lifetime/crypto-period It may not be relevant for certain use cases like long-term data archival requiring key retention. Public keys also generally don't require secure destruction.

What are the trade-offs?

Secure key destruction requires additional processes, tools, and training which takes time and effort to implement. Overly frequent key destruction can become burdensome. There may be cases where keys need to be retained for decryption of archived data. Balancing security and usability is important.

How to make it happen?

1. Identify all key storage locations (HSMs, software, backups, etc)
2. Document key lifecycle including when destruction should occur
3. Implement secure deletion for software keys (overwrite with random data)
4. Use HSM secure key destruction commands (e.g. deleteKey)
5. Physically destroy offline key backups (shred, incinerate)
6. Update key inventory and notify stakeholders on destruction
7. Verify deletion through auditing/testing restored backups
8. Train staff on key destruction policies and procedures

What are some gotchas?

• Keys stored in an HSM often require special permissions to destroy
• Backups and old copies of keys can be easily overlooked
• Legal/regulatory requirements may mandate minimum key retention periods
• Notifying stakeholders is critical to avoid unexpected application downtime
• Verify HSM supports secure deletion (AWS CloudHSM docs)

What are the alternatives?

Rather than deleting keys, an alternative is to revoke them by maintaining a revocation list (e.g. CRL). This retains the key but marks it as invalid. Another option is to implement auto-expiring keys that become unusable after a set time period. However, these don't actually remove the key material like destruction does.

Explore further

• NIST SP 800-57 Pt. 1 Rev. 5 - Recommendation for Key Management
• NIST SP 800-88 Rev. 1 - Guidelines for Media Sanitization
• CIS Controls v8 3.11 - Data Disposal
• AWS Key Management Service Best Practices Whitepaper

‍