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

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

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
addressed?  

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
   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 (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
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. 

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 (EXPANDED)

* 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.