Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: ability (but not enforced) to clear (or R/W) CDI #186

Open
cobratbq opened this issue Mar 20, 2024 · 4 comments
Open

Idea: ability (but not enforced) to clear (or R/W) CDI #186

cobratbq opened this issue Mar 20, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@cobratbq
Copy link

I'm posting this idea from software-development perspective. I may ask something that's hard to achieve or just an exceptional case.

Would it be possible to allow writing to the CDI addresses from the loaded program-binary? That would allow initialization to do the necessary processing, then afterwards clear the CDI. (An alternative would be to allow clearing the MMIO address pointers, although strictly speaking this introduces obscurity rather than security.)

The threat I'm thinking of, is when an attacker manages to manipulate a pointer address such that the CDI is addressed rather than any other arbitrary piece of memory. I can compute values on-the-fly and securely wipe them, but the CDI remains available.

I suspect one can argue for and against this idea. I suspect it depends on the way a program is developed whether this feature is useful.

@dehanj
Copy link
Member

dehanj commented Mar 21, 2024

It is possible to make the CDI writable in app-mode. It is also quite easy hardware wise.
What we do today is to simply check if we are in fw-mode or in app-mode. If we are in app-mode we remove the write_enable for the CDI, so it becomes read-only.

We have discussed this internally as well, to keep the CDI writable, but we have not landed in any decision.
You bring up a good point, to have it writable simply for the reason of removing access to sensitive data, once the app has used it for whatever its purpose is.

@cobratbq
Copy link
Author

To make explicit what has not been said: CDI is intended to be the root of any number of derived secrets. It enables programs to become deterministically unpredictable. To erase/replace CDI after deriving secrets ("branches" in this tree), we cut off the source/root. This prevents extracting the CDI and recreating the device's execution in software.

@secworks
Copy link
Contributor

secworks commented Mar 25, 2024

We could allow an app to mark the CDI as read, used - which would then block any further read access from app mode. We could also trigger a wipe, zeroisation too, to ensure that the CDI is not present in the FPGA at all.

@secworks
Copy link
Contributor

Draft PR #204 adds the ability for device apps to lock down access to the CDI. The PR adds a new API-address ADDR_CDI_DONE. When written to will enforce that any future reads to the CDI returns an all zero value. The device must be reset to enable CDI read again.

@secworks secworks self-assigned this Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants