Zeroizing Data in TickV

[AndrewImwalle]

My team is using TickV to store cryptographic keys on an embedded security device. We have a need to immediately clear these keys from storage, selectively. The Invalidate Key operation does not satisfy the security requirements as the value, or cryptographic key data, still exists and can continue to exist after Garbage Collection if any other entries are still valid. Is there a plan to include a feature like this? If not, I would be interested in creating a Zeroize Key command and upstream it to the repo. Any guidelines or processes I should follow to meet both of our expectations?

[alevy]

Hi @AndrewImwalle, I don't believe there is currently such a plan, but that seems like a particularly useful feature (this is indeed a similar example use case to one we are concentrating on---a 2FA device, and I agree this sounds important). The most clear tension with the current design is that TikV (somewhat) tries to avoid the performance and flash degradation affects of modifying flash pages in place (because the whole page has to be rewritten generally).

A good step might be to write down the specific requirements of such a zeroize key (describing the application and/or the application requirements might be worthwhile since it might help clarify why alternative designs might not be better), and, optionally, a sketch of a feature design.

Here might be a reasonable to place to start sketching that out in-lieu of directly opening an issue or a proposal.

[alistair23]

Great idea! I didn't think of that.

The header of the key would remain intact, but the value would be all 0s and the space would not be freed until garbage collection is called

Yep! That is exactly the way to do it. You can basically just copy the existing invalidate function and expand the amount of zeroes we set.

The only issue is that I'm not sure what guarantees flash hardware makes about recovering that data. It might be easier to recover compared to a full erase. But that's probably up to a board designer as an erase could have the same problems anyway

[AndrewImwalle]

I have a pull request prepared that adds the Zeroize Key option. Thinking about the feature, we may not want to carry the option to both Invalidate and Zeroize.

• There is no way to recover a key after Invalidate Key has been called
• From the embedded implementation mindset, we would not want to carry extra code
• The extra commands would make the interface unnecessarily complex
• From a security standpoint, there is no instance to Invalidate rather than Zeroize

I believe it would be in TickV's best interest to outright replace Invalidate with Zeroize. What are your thoughts?

[alistair23]

Zeroise will wear the flash more, so I think keeping both makes sense.

We could split them into separate HILs. As maybe not all future Tock KV implementations support zeroise

[wright-joe]

I understood wear occurs from erasing. Often writing is thought to cause wear because it is usually required to erase first. For TicKV, we use Sequential Writes to cascade down a Flash page (page being a subdivision of a Sector, the minimum erasable area).

Andrew's approach is to zeroize, not "Erase" in the Flash sense.

[alevy]

My understanding is similar to @wright-joe's, though I'm no low-level flash expert, unfortunately. There is certainly a question of whether "zeroize" should be an explicit part of the interface to KV stores, a guarantee that the interface provides, a default feature of a particular implementation, or something else. I suggest that, for the moment, a description in an RFC-style issue or a PR is a good starting point.

[alistair23]

This is a really difficult problem.

The issue is that the flash will have a relatively large erase size compared to the data. So for example you might have to erase pages on a 2K granularity, while if your data is only 128 bytes you could have 16 key/values per flash page.

So zeroising becomes tricky if you want to clear one entry. As you need to zeroise an entire page but there could potentially be other data there which would be lost.

So the process would be something like:

1. Decide to zeroise key A
2. Find the flash page key A is in
3. Backup all data in the page to a different page
4. Zeroise page A
5. Copy the backed up data back
6. Zeroise the backup

You couldn't really do all of that in userspace, because you might not have permissions to access all of the data in the page. So it's something that would have to be added to the kernel.

The hard part is backing up the keys while avoiding writing to the same flash page all of the time (wear leveling).

I do think a command could be added to the kernel to do the above. We would want to do it in a way where just calling zeroise() would handle all of the complexity for you, while still not loosing data. The process would also need to be recoverable to avoid data loss on a power loss.

One much simpler way would be to make sure all key/values are the size of a flash page. That way you can easily erase the entire page.

[alevy]

Both tradeoffs, in principle seem reasonable (either do a somewhat subtle backup and overwrite, as well as have zeroizable keys/values padded to a page). It's possible wear leveling is less of a concern in some case (e.g. if cryptographic keys are overwritten/erased, but rarely).

So helpful to understand the specific use case.

[alevy]

This is now implemented in #3715 & #3721.

However, those PRs do not make it the default. Should it be the default? I.e., should deleting or modifying a key always zeroize previous values?

[alistair23]

I just realised @AndrewImwalle isn't using Tock, so I guess this is completed for them!

[alevy]

I just realised @AndrewImwalle isn't using Tock, so I guess this is completed for them!

No, I think this is for Tock, so I guess this still needs to be used/exposed in the HIL/capsules/etc

[alevy]

Future KV stores might not support a zeroise

They may not need to. In particular, one implementation of a KV interface could promise to zeroize, but that need not be a promise of the high-level interface. An analogy is that unlink doesn't promise to erase data from disk, but some file-system implementations do, and it's reasonable to rely on that property end-to-end in a system.

and the extra wear on flash is not worth it for all use cases

I'm not sure we resolved that there is extra practical wear on flash. In particular, it doesn't change the number of page-erases that eventually happen.

[brghena]

I'm not sure we resolved that there is extra practical wear on flash.

Given that the erases are the high-voltage operation, I strongly suspect that writing zeros does NOT cause additional wear on the flash.

[alistair23]

They may not need to. In particular, one implementation of a KV interface could promise to zeroize, but that need not be a promise of the high-level interface. An analogy is that unlink doesn't promise to erase data from disk, but some file-system implementations do, and it's reasonable to rely on that property end-to-end in a system.

That seems brittle for a crypto interface. I think we should explicitly say "this command zeroises OR returns an error". Having a command that might zeroise important data seems like a way to accidentally leak data.

Given that the erases are the high-voltage operation, I strongly suspect that writing zeros does NOT cause additional wear on the flash.

Reading https://www.ti.com/lit/an/slaa334b/slaa334b.pdf?ts=1698709005672 it does seem like writing doesn't have long term effects

Writing to the same row too many times can result in write disturb, and erased bits will be programmed as
well. This produces no physical damage and, after erase, the disturbed bits are programmable as before.
No long term effects are known.

I thought I remembered seeing that write does have some life cycle impact, but I can't seem to find it again.

Writing more data does take more time though, so there is a cost