FCS_CKM.6: Clarification of memory erase options

[JDavid-Thompson]

“Block erase” should be clarified. Flash memory, a common form of wear-leveled memory, only allows reading and writing whole blocks, so requiring a block erase might be interpreted as erasing the block the key is stored in. But that is not adequate. Since our intent is to require erasing all the data blocks on the device, that should be made explicit.

There are two options for erasing all the data blocks: 1) erasing all the physical blocks and 2) erasing all the logical blocks. The difference is that a logical erase does not erase the index table, which preserves the bad-block information. However, in the case where a block has been written with sensitive data and is later marked as bad, it may not get erased during a logical erase. Good blocks can become bad after a high number of write cycles, hence the wear leveling. If that is a concern, then we should only allow the physical erasing and verification of all blocks.

Contrary to Application Note 4, after either a logical or physical erase, a read-verify can be performed. If a physical erase of all blocks was done, verify it with a physical read of all blocks. If a logical erase of all indexed blocks was done, verify it with a logical read of all indexed blocks. The vendor / users should be allowed either option (except if there is concern about sensitive data getting into bad blocks, as mentioned earlier). Erasing anything less than all the logical blocks is not adequate.

Application Note 4 says the only non-volatile memory to which block erase applies is “flash memory”. It should use the more general term “wear-leveled memory”.

Also, note:

• that garbage collection in volatile memory usually does not cause the immediate erasure of the collected data objects unless an explicit request is made for it to do so. Collected data objects are often queued for erasure when the system is idle or during re-allocation.
• that while power off will erase volatile memory, it may take some time, depending on environmental factors.
• that it is not always obvious when power has been removed from a volatile memory, such as in a cell phone, whose computer is never actually off unless the batteries are removed, some of which are not easy to access.

I will submit a Pull Request with suggested updates to FCS_CKM.6 and Application Note 4, when I figure out how to do that, and if a Pull Request is the right method.

[woodbe]

Be aware there have been a lot of debates on this over time, and for wear-leveled storage, in many cases there is not a direct delete, just a deletion of the reference, and then the system is configured to always report it is empty (whether it is overwritten with 0 or not, the storage will return a blank value to a request).

Also note that I have moved this to a different repo, the one where you placed this is for maintaining our website, not the documents.

[JDavid-Thompson]

Brian,

I have experience working with flash memory at the chip level, and you can definitely write to specific blocks with a physical address, and read them back. The wear-leveling is done at a higher level and it’s plausible that only that higher level is exposed by certain interfaces. Seems like a vendor should be able to expose the lower levels, if necessary, or implement an internal zeroization function that worked at the physical level. Perhaps a configuration option on the flash drive could require blocks to be overwritten with zeros before being de-referenced. That would reduce performance and the life of the flash, but it might be worth it if the device is to store sensitive data. Flash memory wear is also getting to be less of an issue as the technology improves, so we might also promote a configuration option that turns off wear-leveling. Another option might be to allow data storage in the non-flash parts of the drive where the indexes are stored and to provide a method for storing keys there (although not all flashes have this design). We could help motivate these options.

The comment in the PP about not being able to read-verify blocks after the index is erased implies exposure of the physical addressing, in order to have erased the index, which would not be erased by a logical overwrite. So, there are still some disconnects.

I will review the previous debates, if I can find them 😉.

Thanks for moving my issue to the correct repo.

I got half a dozen messages about my post from github that I don’t understand, so I have a lot to learn about github. My limited git experience is with git on a local system, not with github.

Thanks.

-Dave

From: Brian Wood @.> Sent: Monday, January 29, 2024 8:09 PM To: DSC-iTC/cPP @.> Cc: J David D Thompson @.>; Assign @.> Subject: Re: [DSC-iTC/cPP] FCS_CKM.6: Clarification of memory erase options (Issue #224)

Be aware there have been a lot of debates on this over time, and for wear-leveled storage, in many cases there is not a direct delete, just a deletion of the reference, and then the system is configured to always report it is empty (whether it is overwritten with 0 or not, the storage will return a blank value to a request).

Also note that I have moved this to a different repo, the one where you placed this is for maintaining our website, not the documents.

— Reply to this email directly, view it on GitHubhttps://github.com/DSC-iTC/cPP/issues/224#issuecomment-1915871388, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BFSTVCM6GBLIAIUG7RJAKYDYRBB4LAVCNFSM6AAAAABCQMD2KCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJVHA3TCMZYHA. You are receiving this because you were assigned.Message ID: @.***>

[JDavid-Thompson]

Summary:

• Assured erasure of load-leveled devices is problematic.
• Is erasure through the load-leveled logical interface consistent with the DSC target assurance level?
• Application Note 4: remove comment about the impossibility of doing a read-verify.

I looked at FCS_CKM_EXT.4 and .5 in PP_MDF. The methods specified there generally coincide with what is now in DSC, but they do not seem adequate. Overwriting with zeros or writing a zero-filled block to a wear-leveled flash is not guaranteed to erase the previous data. It's true that the key will not be accessible through the logical wear-leveled interface after that, and that may be an acceptable result. However, that protection is lost if the flash drive can be opened in a non-wear-leveled mode, or if the flash drive is removed from the TOE and opened in an attacker's computer.

The only way to ensure that a key is erased using a wear-leveled interface, is to erase the entire device by overwriting all blocks, which I agree is kind of extreme. A wear-leveled interface could provide a function to perform erasure of a specific block without remapping it to a new physical block. Or it could provide the physical address of a wear-leveled block and allow a direct write to that block without remapping. They both sound like reasonable solutions to the flash erasure problem, which comes up in many circumstances. We might add options to these SFRs to encourage such technical solutions.

Is a wear-leveled erase function, where the critical data may remain on the device but is not accessible through the wear-leveled interface, consistent with the assurance level we are trying to achieve? I will hold off suggesting a change to FCS_CKM.6 until this question is answered.

In any case, the sentence "A block erase does not require a read verify, since the mappings of logical addresses to the erased memory locations are erased as well as the data itself" in Application Note 4 should be deleted. It implies having done a physical write over the mapping table, which is inconsistent with using a logical erase. No matter how the writing was done, a read-verify is possible.

[JDavid-Thompson]

The assurance level is clarified in FDP_RIP.1, which counters O.PURGE_PROTECTION and requires that SDOs and SDEs be purged from unallocated memory, especially when they are keys. So, FCS_CKM.6.2, as is, does not meet that requirement with respect to wear-leveled flash memory. Perhaps FCS_CKM.6.2 should prohibit keys from being stored in wear-leveled flash memory unless the vendor can provide a rationale that the memory is capable of meeting FDP_RIP.1 and that the TOE’s usage is conformant.

[JDavid-Thompson]

I suggest the SFR be altered as follows (in AsciiDocs with changes highlighted):

FCS_CKM.6.2

The TSF shall destroy cryptographic keys and keying material specified by FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method [selection:

. For volatile memory, the destruction shall be executed by a [selection: .. single overwrite consisting of [selection: ... a pseudo-random pattern using the TSF’s RBG, ... zeroes, ... ones, ... a new value of a key, ... [assignment: some value that does not contain any CSP]], .. removal of power to the memory, #if that can be done reliably#, .. removal of all references to the key directly followed by a request for garbage collection #that includes the immediate erasure of the collected data objects#]; . For non-volatile memory [selection: .. that employs a wear-leveling algorithm, the destruction shall be executed by a [selection: ... #overwrite of the block containing the key with data consisting of [selection: zeroes, ones, pseudo-random pattern, [assignment: some value that does not contain any CSP] using a method that meets the requirements of FDP_RIP.1, followed by a read-verify operation on the overwritten block (See App Note 4)#], ... #erasure of all logical blocks in the memory device (all physical blocks except the index blocks, if they can be reliably identified) followed by a read-verify operation on all logical blocks#]; .. that does not employ a wear-leveling algorithm, the destruction shall be executed by a [selection: ... [selection: single, [assignment: ST author defined multi-pass]] overwrite consisting of [selection: zeros, ones, pseudo-random pattern, a new value of a key of the same size, [assignment: some value that does not contain any CSP]] followed by a read-verify. If the read-verification of the overwritten data fails, the process shall be repeated up to [assignment: number of times to attempt overwrite] times, whereupon an error is returned. ... block erase #followed by a read-verify. If the read-verification of the overwritten data fails, the process shall be repeated up to [assignment: number of times to attempt overwrite] times, whereupon an error is returned.#]

]] that meets the following: [no standard].

Application Note 4

In the case of volatile memory, the selection "removal of all references to the key directly followed by a request for garbage collection" is used in a situation where the TSF cannot address the specific physical memory locations holding the data to be erased and therefore relies on addressing logical addresses (which frees the relevant physical addresses holding the old data) and then requesting the platform to ensure that the data in the physical addresses is no longer available for reading (i.e. the "garbage collection" referred to in the SFR text).

_#In the case of wear-leveled non-volatile memory, the entire memory must be erased when a key is deleted unless the TOE has an erasure mechanism that meets FDP_RIP.1 and the vendor provides a rationale that the TOE uses it in a conformant way. FDPRIP.1 requires that keys not remain in unallocated memory after a key delete operation, a capability that wear-leveled non-volatile memory normally does not provide.#

[woodbe]

@JDavid-Thompson can you create a pull request with this? It will be easier to see that way. Make it from the working branch.

[JDavid-Thompson]

I tried earlier and got an entry window with Markdown instead of AsciiDocs. I’ll give it another try.

From: Brian Wood @.> Sent: Thursday, February 1, 2024 9:13 AM To: DSC-iTC/cPP @.> Cc: J David D Thompson @.>; Mention @.> Subject: Re: [DSC-iTC/cPP] FCS_CKM.6: Clarification of memory erase options (Issue #224)

@JDavid-Thompsonhttps://github.com/JDavid-Thompson can you create a pull request with this? It will be easier to see that way. Make it from the working branch.

— Reply to this email directly, view it on GitHubhttps://github.com/DSC-iTC/cPP/issues/224#issuecomment-1921426510, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BFSTVCK2EEXPZBE56MKHY4LYROPHRAVCNFSM6AAAAABCQMD2KCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRRGQZDMNJRGA. You are receiving this because you were mentioned.Message ID: @.***>

[JDavid-Thompson]

cPP_FDE_AA_V2.0E does not allow plaintext keys to be stored in non-volatile memory. If we did that in DSC, it would eliminate the problem of persistence of data in wear-leveled non-volatile flash memory. That seems like a reasonable requirement for protecting keys in any case. If we still want to allow storage of plaintext keys in non-volatile storage, we could at least exclude wear-leveled flash.

cPP_FDE_EE_V2.0E has the application note that we currently have in DSC that allows block erase as an option and says verification is not required because the indexes will have been wiped out. "Block erase" is ambiguous and the comment about verification is wrong and adds further confusion regarding logical vs physical block addressing.

cPP_USB_v0.10 has the same misleading wording contained in cPP_FDE_EE_V2.0E.

NIAP PP_USB_FD_v1.0 does not address protection of plaintext on flash drives, as it requires encryption of all data on the drive.