3 ms·

> The mention of using ReRAM is interesting, I wonder what's motivating that. Your previous paragraph succinctly addresses the motivation: high performance pro

by bunnie 4y ago

> The mention of using ReRAM is interesting, I wonder what's motivating that. Your previous paragraph succinctly addresses the motivation: high performance processes can't use flash. However, ReRAM is already qualified for use in these processes. Since ReRAM is non-volatile (with a storage lifetime measured in 100+ years) and dense, you can get the benefits of flash and of OTP, and also in a high performance process. By implementing "OTP" as a bank of ReRAM (with a write-protect bit, but still an erase-all mode), the option to do a full device wipe-down is theoretically available with an OTP-like behavior.

hlandau 4y ago
Very cool. Sounds like you have the right idea in terms of the requirements I discuss above and which people are mentioning elsewhere in this thread. I look forward to reading the datasheets when this is announced.
hlandau 4y ago
As an aside, I've always wanted a device that supports trusted boot using something like the following model: - Secret generated inside the device in nonvolatile memory (e.g. during manufacturing) - During boot, a boot ROM reads the initial boot block, computes KDF(secret, boot block), then sets a lock bit to prevent read/write of the secret in nonvolatile memory - Boot the boot block, with the secret passed to it (or loaded into a cryptographic glovebox for application use, etc.) This scheme is remarkably simple, yet can be used to bootstrap basically anything else, since you can write your own bootblock to derive further keys as you wish. Essentially every bootblock gets its own unique secret. You can't change the bootblock, but if manufacturers can commit to an immutable mask ROM, people can commit to an immutable bootblock with enough effort. A managed bootblock upgrade protocol in which a bootblock can choose to endorse a successor based on some arbitrary policy it implements could probably be designed with enough effort. Not sure if this is compatible with what you're going for though. I could see some people not wanting this kind of thing or not liking a secret they can't access. I guess you could make it erasable and let people set their own secret. Just some random ideas floating around in my head.

by bunnie 4y ago

hlandau 4y ago

Very cool. Sounds like you have the right idea in terms of the requirements I discuss above and which people are mentioning elsewhere in this thread. I look forward to reading the datasheets when this is announced.

hlandau 4y ago

As an aside, I've always wanted a device that supports trusted boot using something like the following model: - Secret generated inside the device in nonvolatile memory (e.g. during manufacturing) - During boot, a boot ROM reads the initial boot block, computes KDF(secret, boot block), then sets a lock bit to prevent read/write of the secret in nonvolatile memory - Boot the boot block, with the secret passed to it (or loaded into a cryptographic glovebox for application use, etc.) This scheme is remarkably simple, yet can be used to bootstrap basically anything else, since you can write your own bootblock to derive further keys as you wish. Essentially every bootblock gets its own unique secret. You can't change the bootblock, but if manufacturers can commit to an immutable mask ROM, people can commit to an immutable bootblock with enough effort. A managed bootblock upgrade protocol in which a bootblock can choose to endorse a successor based on some arbitrary policy it implements could probably be designed with enough effort. Not sure if this is compatible with what you're going for though. I could see some people not wanting this kind of thing or not liking a secret they can't access. I guess you could make it erasable and let people set their own secret. Just some random ideas floating around in my head.