Re: PD 0135: "Overwriting" in the Context of Non-Disk Memory (Medium Robustness Profiles)
- Subject: Re: PD 0135: "Overwriting" in the Context of Non-Disk Memory (Medium Robustness Profiles)
- From: "Observation Decisions Review Board" <firstname.lastname@example.org>
- Date: Mon, 27 Aug 2007 10:55:38 -0700
- Content-description: Mail message body
- Content-transfer-encoding: 7BIT
- Content-type: text/plain; charset=US-ASCII
- Priority: normal
In response to a recent OD, as well as some internal review comments,
the ODRB is revising PD-0135. The basic resolution is not changing, but
the updated PD will be made more clear in its applicability to a broader
range of PPs, and will attempt to capture the different overwriting
approaches in a better manner.
The revised PD is as follows:
ISSUE (no changes)
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
RESOLUTION (completely replaced and simplified)
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
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 (completely replaced and expanded)
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
* 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
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
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
Note: This PD may also be applicable to Medium Robustness profiles that
are under development, or were in development and never completed the
PD Created (March 2007 ODRB Agenda Item 3.a.ii)
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)
* 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,
* PP_OS_SL_MR_V1.22: Protection Profile for Single-level Operating
Systems in Environments Requiring Medium Robustness Version 1.22, May
* PP_BVM_MR_V1.0: U.S. Government Biometric Verification Mode Protection
Profile for Medium Robustness Environments Version 1.0, November 15,
* 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.
Date Index |
Thread Index |
Problems or questions? Contact email@example.com