PD 0135: "Overwriting" in the Context of Flash Memory (Medium Robustness

["Observation Decisions Review Board" <faigin@aero.org>]

The following PD was issued by the ODRB during its March 2007 meeting:


PD 0135: "Overwriting" in the Context of Flash Memory (Medium Robustness
Traffic-Filter Firewall PP v1.1, Medium Robustness Firewall PP v1.0, et
al) 

ISSUE

The evolution of technology has resulted in flash memory that can be
used instead of traditional magnetic media. When flash memory is used,
how are the requirements that touch on the idea of "overwriting"
previously stored values (e.g. FDP_RIP, FCS_CKM.4) supposed to be
addressed?  

RESOLUTION

[Note: For text email, the following conventions are used: /strikeout/,
_italics_, *bold*] 

The PPs that are currently written address the overwriting of stored
data (to ensure that it cannot be retrieved) in terms that are
appropriate only for magnetic media. For flash memory, a single
overwrite would suffice (at least up through medium levels of
robustness). 

However, it should be noted that some flash memory is implemented in
such a way that it cannot be determined where precisely values are
stored. In order to prevent any one cell from wearing out, they
distribute the use of cells by internally translating locations to
lesser-used areas, while hiding that fact from the outside. In other
words, the location actually written to is not the location
indicated. So when a data location is written, it must be written
without intervening buffering or mechanisms; if there is buffering or
some other intervening mechanism (wear leveling), the system must ensure
that the only access to the unwritten location would be through physical
access (i.e., removing the device and doing a physical level analysis).  

The U.S. Government Firewall Protection Profile for Medium Robustness
Environments (v1.0, October 28, 2003) and the U.S. Government
Traffic-Filter Firewall Protection Profile for Medium Robustness
Environments (v1.1, January 9, 2006) both include requirements for the
handling, storage, and destruction of cryptographic keys. In order to
accommodate situations where this storage is implemented in  flash
memory, these requirements are updated as follows: 

Cryptographic Key Destruction (FCS_CKM.4)
 
	FCS_CKM.4.1: *Refinement:* The TSF shall destroy cryptographic
	keys in accordance with a *cryptographic key destruction method*
	that meets the following:(fn 1) 
 
		*a) FIPS PUB 140-2, "Security Requirements for
                 Cryptographic Modules"* 
 
		*b) Zeroization of all plaintext cryptographic keys and
                 all other critical cryptographic security parameters
                 shall be immediate and complete.* 

	_Application Note: The term "immediate" here is meant to impart
	some urgency to the destruction: it should happen as soon as
	practical after the key is no longer required to be in
	plaintext. It is certainly permissible to complete a critical
	section of code before destroying the key. However, the
	destruction shouldn't wait for idle time, and there shouldn't be
	any non-determined event (such as waiting for user input) which
	occurs before it is destroyed._ 
 
		*c) For non-volatile memories other than EEPROM and
                 Flash, the zeroization shall be executed by overwriting
                 the key/critical cryptographic security parameter
                 storage area three or more times using a different
                 alternating data pattern each time.* 
 
		*d) For volatile memory and non-volatile EEPROM and
                 Flash memories, the zeroization shall be executed by
                 overwriting the key/critical cryptographic security
                 parameter storage area with a single direct overwrite
                 consisting of a pseudo random pattern, followed by a
                 read-verify.* 

	_Application Note: Although verification of this zeroization of
	a plaintext key/critical cryptographic security parameter is
	desired here (by checking for the final known alternating data
	pattern), it is not required at this time. However, vendors are
	highly encouraged to incorporate this verification whenever
	possible into their implementations._ 
 
	_Application Note: Zeroization of any storage, such as memory
	buffers, that is included in the path of a plaintext
	key/critical cryptographic security parameter is addressed in
	FCS_CKM_EXP.2 (Cryptographic Key Handling and Storage)._ 

*Explicit: Cryptographic Key Handling and Storage (FCS_CKM_EXP.2)* 
 
	_Application Note: NIST Special Publication 800-57,
	"Recommendation for Key Management" contains additional
	protection mechanisms that vendors are encouraged to
	implement. This document should be used as guidance for the key
	handling and storage requirements._ 
 
	*FCS_CKM_EXP.2.1:* The TSF shall perform key entry and output in
         accordance with FIPS PUB 140-2, Level 3. 
 
	*FCS_CKM_EXP.2.2:* The TSF shall provide a means to ensure that
         keys are associated with the correct entities (i.e., person,
         group, or process) to which the keys are assigned. 
 
	*FCS_CKM_EXP.2.3:* The TSF shall perform a key error detection
         check on each transfer of key (internal, intermediate
         transfers). 
 
	_Application Note: A parity check is an example of a key error
	detection check._ 
 
	*FCS_CKM_EXP.2.4:* The TSF shall encrypt or split persistent
         secret and private keys when not in use. 
 
	_Application Note: A persistent key, such as a file encryption
	key, is one that must be available in the system over long
	periods of time. A non-persistent key, such as a key used to
	encrypt or decrypt a single message or a session, is one that is
	ephemeral in the system._ 
 
	_Application Note: "When not in use" is interpreted in the
	strictest sense so that persistent keys only exist in plaintext
	form during intervals of operational necessity. For example, a
	file encryption key exists in plaintext form only during actual
	encryption and/or decryption processing of a file. Once the file
	is decrypted or encrypted the file encryption key is immediately
	covered for protection._ 
 
	*FCS_CKM_EXP_2.5:* The TSF shall destroy non-persistent
         cryptographic keys after a cryptographic administrator-defined
         period of time of inactivity. 
 
	_Application Note: The cryptographic administrator must have the
	ability to set a threshold of inactivity after which
	non-persistent keys must be destroyed in accordance with
	FCS_CKM.4._ 
 
	*FCS_CKM_EXP.2.6:* The TSF shall overwrite each intermediate
         storage area for plaintext key/critical cryptographic security
         parameter (i.e., any storage, such as memory buffers, that is
         included in the path of such data). This overwriting shall be
         performed as follows: 
 
		a) For non-volatile memories other than EEPROM and
		Flash, the overwrite shall be executed three or more
		times using a different alternating data pattern each
		time upon the transfer of the key/critical cryptographic
		security parameter to another location. 
 
		b) For volatile memory and non-volatile EEPROM and Flash
		memories, the overwrite shall be a single direct
		overwrite consisting of a pseudo random pattern,
		followed by a read-verify upon the transfer of the
		key/critical cryptographic security parameter to another
		location. 

	_Application Note: This is related to the elimination of
	internal, temporary copies of plaintext keys created during
	processing, not to the total destruction of a key from the TOE
	which is discussed under Key Destruction. Although verification
	of the zeroization of each intermediate location consisting of
	non-volatile memories, of a plaintext key/critical cryptographic
	security parameter is desired here (by checking for the final
	known alternating data pattern), it is not required at this
	time. However, vendors are highly encouraged to incorporate this
	verification whenever possible into their implementations._ 
 
	*FCS_CKM_EXP.2.7:* The TSF shall prevent archiving of expired
         (private) signature keys. 
 
	_Application Note: This requirement is orthogonal to typical
	system back-up procedures. Therefore, it does not address the
	problem of archiving an active (private) signature key during a
	system back-up and saving the key beyond its intended life
	span._ 
 
--------------- 
fn 1: A deletion of CC text was performed in FCS_CKM.4.1. Rationale: The
words "specified" and the assignment "_[assignment: cryptographic key
destruction method]_" were deleted because FIPS PUB 140-2 does not
provide specific names for the key destruction (zeroization) method. 
 
FCS_CKM.4.1: *Refinement:* The TSF shall destroy cryptographic keys in
accordance with a /specified/ *cryptographic key destruction method*
/[assignment: cryptographic key destruction method]/ that meets...  

RATIONALE

While PPs attempt to be implementation-independent, there are inevitable
assumptions made based upon the prevailing technology available at the
time; as technology advances, solutions in one instance are no longer
necessary, possible, or relevant for later ones. 

Data storage using flash memory has become sufficiently prevalent to
deserve consideration within the scope of PPs. Therefore, this PD
applies to any PP that contains SFRs addressing the overwriting of
previously stored values (e.g. FDP_RIP, FCS_CKM.4), at a maximum of a
medium level of robustness. 

This Resolution results in part from points made in the paper "Data
Remanence in Flash Memory Devices", by Sergei Skorobogatov at Cambridge
University, available at
http://www.cl.cam.ac.uk/~sps32/DataRem_CHES2005.pdf, et al.