PD-0135: "Overwriting" in the Context of Non-Disk Memory (Medium Robustness Profiles)

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

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

When a Protection Profile requires a cryptographic key or parameter overwriting approach that is incompatible or inappropriate for the type of media under evaluation, the following changes to the PP must be made:

1. The SFRs in question (e.g., FCS_CKM.4) shall be refined to specify an appropriate overwriting or sanitization approach for that form of media.

2. A rationale shall be provided in the TSS or an Application Note that the method chosen provides an adequate level of sanitization for the profile's robustness level.

Support

A number of PPs (see References) currently include the notion of overwriting cryptographic keys in stored data with multiple passes to ensure they cannot be retrieved. However, there are problems with this approach:

• It does not work for all media types. In particular, it is only applicable to random-access magnetic disk media. It doesn't work for magnetic tape, optical media, and either doesn't work or is overkill for various forms of RAM.

• It may be unnecessary, as obtaining such data often requires physical low-level access to the raw media. This is precluded by assumptions restricting physical access to authorized individuals. Further, the requirements of Reference Validation (FPT_RVM) and Domain Separation (FPT_SEP) imply that access to said data will be solely through the provided interfaces.

That said, especially for applications vs. appliances, it is prudent to make a good faith effort to ensure that cryptographic keys and parameters are erased, in order to address the scenario where a malicious user bypasses the application interface. This effort should be appropriate for the physical media type being used by the application or appliance:

1. For random-access magnetic media, at minimum, the data locations should be overwritten three or more times using a different alternating data pattern each time. DoD 5220.22-M (NISPOM) recommends that these patterns be a character, then that character's complement, and finally a random character.

2. For most forms of memory (excluding those erasable using a bulk operation), a single overwrite of the data with a random pattern is usually sufficient. Additional support for this approach can be found 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.

3. For other forms of media, such as magnetic tape, optical media, and other electronically erasable media, the methods vary. DoD 5220.22-M, NIST 800-18, and NIST 800-88 can provide some guidance in this area.

Note also that device drivers may make it difficult to ensure that data is actually overwritten. RAID and other forms of file systems may scatter data across the disk, or may write data in different locations when overwrites occur, using logical mechanisms in the device driver to prevent accessing the old data. Some RAM memory is implemented using a technique called "wear leveling": in order to prevent any one cell from wearing out, these systems 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.

Hence, when dealing with overwriting approaches, the device drivers and media devices must be examined to ensure overwriting actually overwrites the data locations. If this is not possible, there must be a high level of confidence that the only access to the unwritten location would be through physical access (i.e., removing the device and doing a physical level analysis).

Note: This PD may also be applicable to Medium Robustness profiles that are under development, or were in development and never completed the development process.

Modification History:

2007-04-05:

PD Created (March 2007 ODRB Agenda Item 3.a.ii)

2007-08-27:

Updated to better reflect the wide variety of potential peripherals, and to reflect the broader applicability of the decision. (August 2007 Agenda Item 4.a.i)

References:

• PP_FW_MR2.0_V1.0: U.S. Government Firewall Protection Profile for Medium Robustness Environments, Version 1.0, October 28, 2003.
• PP_FW_TF_MR2.0_V1.0: U.S. Government Traffic-Filter Firewall Protection Profile for Medium Robustness Environments, Version 1.0, February 15, 2005.
• PP_FW_TF_MR2.0_V1.1: U.S. Government Traffic-Filter Firewall Protection Profile for Medium Robustness Environments, Version 1.1, January 9, 2006
• PP_OS_ML_MR_V1.22: Protection Profile for Multilevel Operating Systems in Environments Requiring Medium Robustness Version 1.22, May 23, 2001.
• PP_OS_SL_MR_V1.22: Protection Profile for Single-level Operating Systems in Environments Requiring Medium Robustness Version 1.22, May 23, 2001.
• PP_BVM_MR_V1.0: U.S. Government Biometric Verification Mode Protection Profile for Medium Robustness Environments Version 1.0, November 15, 2003.
• PP_DIR_MR_V1.0: US Government Directory Protection Profile For Medium Robustness Environments Version 1.0, September 17, 2004.
• PP_ROUTER_MR_V1.0: U.S. Government Router Protection Profile For Medium Robustness Environments, December 14, 2006.
• PP_VPN_MR_V1.0: U.S. Government Virtual Private Network (VPN) Boundary Gateway Protection Profile For Medium Robustness Environments Version 1.0, February 23, 2006.
• PP_OS_ML_MR2.0_V1.91: US Government Protection Profile for Multilevel Operating Systems in Medium Robustness Environments Version 1.91, March 16, 2007
• PP_OS_SL_MR2.0_V1.91, US Government Protection Profile for Single-Level Operating Systems in a Medium Robustness Environments, Version 1.91, March 16, 2007
• PP_WLAN_CLI_BR_1.0: US Government Wireless Local Area Network (WLAN) Access System Protection Profile For Basic Robustness Environments Version 1.0, May 17, 2006.

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0260