Open jeffblank opened 8 years ago
Per 2 Feb concall: One challenge identified with the requirement (which is levied upon the OS software) is that the behavior of the underlying filesystem (indeed the underlying platform) may not be knowable.
We may be reaching a situation where no common filesystem and underlying storage medium can guarantee key destruction in non-volatile memory, as the requirements is currently written.
Possible solutions: 1) levy requirements on hardware (creates difficulty for TOE boundary) 2) limit claims to certain filesystems and underlying hardware 3) limit claims to logical erasure (which limits the extent to which the requirement achieves objectives against certain threats)
These comments are from Steve Grubb:
The feedback that I delivered in person and to the group is as follows:
FCS_CKM_EXT.3 Cryptographic Key Destruction
ISSUE: We need to have clarification as to what's expected for copy on write (COW) filesystems, journaled, snapshotted, versioned, clustered, distributed, and network file systems. There is also uncertainty in solid state drives and flash drives because of wear leveling algorithms. Additionally, would we need to specify drives that support the ATA "security erase" or "enhanced security erase" command built into the controller? Also, what if you hit a bad sector and you cannot write?
Since then, I have had some additional thoughts on the topic...
Perhaps instead of mandating or requiring the key destruction, we should document how effective 3 overwrites would be if used for key destruction and whether its used in common key handling utilities.
Also, if the key store is encrypted, do you really need to overwrite the key 3 times? The act of deleting the key will change the whole file. Also, what if the whole partition is encrypted?
Consensus seems to be using the requirements from the SV PP.
There have been several comments (outside formal feedback) about the key destruction requirement being problematic. So we should discuss with the community.