5 ms·

Towards a More Open Secure Element Chip

214 points by zdw 4y ago

mindslight 4y ago
What I don't see touched on in this post is the high-level trust model. What generally makes trusted computing a non-starter for libre software is that it contains privileged keys baked in by the manufacturer. A secure element chip does not need a completely libre/open design to support software freedom, but it does need to allow end-owners to run whatever software they would like - not subject to a third party's approval. To that end: 1. The chip needs to be able to be completely erased, having all keys zeroed out, at which time new keys can be loaded and/or internally generated. Signature verification keys are zeroed out to establish a new root of trust, and program/memory keys are zeroed out to maintain the security of information previously entrusted to the chip. 2. Resetting the chip should take a configurable amount of time (days to a month), either based on internally counting the clock or external proof of work, to protect against evil maid attacks by those with temporary possession of the hardware. 3. If there is any remote attestation functionality, then the reset procedure must output the attestation signing keys, including the private parts. This way the manufacturer (or any downstream integrators) cannot record the public identity of the shipped attestation keys to create a trust relationship that would prevent the ultimate owner from running software of their choosing. For software freedom, these aspects are much more important than the design and licensing of the computation core(s). Let them ship ARM. Let them ship only ARM. Let them ship a proprietary ISA that needs to be painstakingly reverse engineered over a decade. Spend your social capital making sure the ultimate end-owners of the chip remain in control of their own devices! This is what is critical for open source.
- josephcsible 4y ago
  Exactly. In particular, see the "Powerful, Reliable Software Can Be Bad" section of <https://www.gnu.org/philosophy/open-source-misses-the-point.en.html https://www.gnu.org/philosophy/open-source-misses-the-point....>. It'll take careful engineering to keep this from being useful for DRM, which I'm worried won't get done.
  - mindslight 4y ago
    Actually even with the requirements I laid out, DRM would still work. A manufacturer could ship a device with decryption keys for DRM content. If the end-owner decided to liberate their device, then the decryption keys would be erased and DRM content could no longer be played. The owner would be left with a blank device ready to accept new software, likely open source, and the device wouldn't be relegated to becoming e-waste.
    - p_l 4y ago
      That's how it works with some of the hw backed DRM schemes that for example try to use remote Attestation with TPM, or secure media pathways on intel me or AMD PSP. The DRM software simply stops working, while you get to run everything you build yourself still.
    - cryptonector 4y ago
      There's no stopping walled gardens -- not with technology as the vendors would choose not to use such technology. The most choice users will ever get to make (per-device) is whether to be locked-into or locked-out-of the walled gardens.
    - josephcsible 4y ago
      Huh, good point. I wonder how that would be fixable too.
      - mindslight 4y ago
        Does it need to be? I'm a staunch supporter of libre software, but I don't see the harm.
        mschuster91 4y ago
        > I'm a staunch supporter of libre software, but I don't see the harm. The harm is we're still perpetuating DRM crap. The music industry has accepted that Spotify's DRM can be trivially broken and completely given up trying to police BitTorrent... it's time for the movie industry to realize the same. Sadly, Netflix failed to get enough dominance to bend over and cane the movie industry into submission, and regulatory agencies worldwide just accepted happily that movie studios went all-in on vertical integration again.
- cryptonector 4y ago
  > What I don't see touched on in this post is the high-level trust model. What generally makes trusted computing a non-starter for libre software is that it contains privileged keys baked in by the manufacturer. Keys don't have to be open source. Re (2), the way you defeat evil maid attacks on boot or wake is by using a TPM and measuring every bit of firmware and software loaded (to some point) so that local storage decryption is not possible unless you're running golden code. The hard part is stopping evil maid attacks on running systems. Re (3), for open systems you really need any remote attestation to be at the option of the end user or the operating system that they choose to run (but the end user must have the option to run an operating system of their choice, which then might not implement remote attestation). TPMs got these things right, but they're not SEs. TPMs could be SEs, but they're missing necessary functionality. I'm imagining a BPF-style system where you'd get to send bytecode to be interpreted with access to various loaded key objects (handles), and which would be able to execute TPM commands (subject to policy) and use their outputs without exposing them to the user, with the program's execution and availability of its final outputs being conditional on satisfying some relevant policy. Because so many systems have a TPM, a TCG TPM standard update that allows for a very limited and TPM-centric SE to be implemented with a TPM firmware update would be very interesting. > For software freedom, these aspects are much more important than the design and licensing of the computation core(s). Let them ship ARM. Let them ship only ARM. Let them ship a proprietary ISA that needs to be painstakingly reverse engineered over a decade. Spend your social capital making sure the ultimate end-owners of the chip remain in control of their devices! This is what is critical for open source. Yes, the amount of software built to run in SEs is minute, therefore it's not that big a deal to expect vendors to recompile that software if a new version of the SE were to use a different ISA. I'm a bit surprised at the focus on RISC-V, but I'm not annoyed by it -- if it really costs them little, then I don't see the problem, and having the option is certainly interesting.
  - ignaloidas 4y ago
    I think the focus on RISC-V is in large part because of the focus of RTL-level verification. You can't release ARM core's RTL, and some may fear that backdoors might be hidden there. But you can easily release RISC-V core's RTL, and let people verify that there is no backdoors in there.
- JoachimS 4y ago
  The Tillitis TKey may provide a solution to this. You can (will be very soon) able to buy TKey devices that are not provisioned by Tillitis. Using the TKey programmer you can build your own FPGA bitstream (using the open toolchain). And then, using the provisioning tool or manually generate and insert your own Unique Device Secret (UDS). This also means that you can get two (or more) blank TKey devices and provision them with the same UDS, creating a backup key that you can put in a safe place. I'd recommend to at least have different Unique Device Identities, to allow you to see which of the devices you use when connecting it to the host. The bitstream, with the UDS is stored and locked in the FPGA non volatile configuration memory. It will not protect against a prepared evil maid-attack that gives the attacker enough time to dismantle the casing and perform a warm-boot attack. We are working on ways to make that attack harder, less feasible.
godelmachine 4y ago
>>Cramium (still in stealth mode), approached me to advise on open source strategy Why is a stealth mode company interested in an open source strategy? Isn't that counter intuitive and purpose-defeating?
- mhh__ 4y ago
  People want the allure of stealth while also having the street cred of.open source, apparently.
  - godelmachine 4y ago
    I wonder how many stealth mode companies have actually delivered anything? Magic Leap used to be in stealth mode back in 2016 and there was so much frenzied speculation around it in the media. Last I heard, they had delivered some headsets of industrial process automation and that's about it.
- adg001 4y ago
  Counter intuitive, perhaps, but not necessarily purpose-defeating, because a stealth mode company can choose to release its open source components only a later moment in time, when it is ready to generate positive cash flow.
- detaro 4y ago
  Because it doesn't intend to remain in "stealth mode" forever?
  - ZiiS 4y ago
    Arguably given a front-page story they are not in "Stealth mode" now?
- bunnie 4y ago
  Stealth mode simply refers to a stage in a company's evolution, not an on-going state of operation. For example, because the company is not yet fully formed, it doesn't have a website -- nobody has made one, because it's not the most pressing thing to do right now. I don't even think the company has an official logo yet. They are basically walking and chewing gum by trying to put together their advisory board, while they also put together the details of the corporate entity. In essence most startups go through a "stealth mode" phase because many disclosable details simply do not exist. It's perfectly consistent to say "we want to do open source", but also not have prepared a logo, a website, and an overall corporate narrative.
foolfoolz 4y ago
there is no value right now in open secure element. secure element is arguably the most secure hardware platform in the world to deploy at scale. - secure element is in every credit card - secure element is in every cell phone - secure element is in every modern passport these aren’t simple use cases. these have national security implications. i foresee this going the opposite direction as more critical things rely on secure element more individual proprietary implementations will emerge. it’s still a standard. you can still develop on top of secure element. but who really benefits from it being open?
- adg001 4y ago
  The civil society would benefit, because it is hard to entrust our business and affairs to systems whose degree of trustworthiness is moot at best.
- sounds 4y ago
  Reduction in e-waste and reduction in forced obsolescence: the more open this secure element is, the more it sets a standard. Then that creates a robust ecosystem around it. (For example, see the Raspberry Pi which helped spur an ecosystem. Also, even the original Pi 1 can still be useful today.) Those secure elements in credit cards (Java Card platform) and cell phones (SIM) have an open standard. This is natural growth in that standard.
- JoachimS 4y ago
  One obvious is trust. Secure Elements are validated against Common Criteras, often at very high level (6+). Yet, there have been problems. An example is bad RSA implementations. Developing for SEs normally require signing boatloads of NDAs. This makes it hard do talk about weaknesses, things that simply could easily be improved (in support libraries for example). By having open designs, open source more people can review and decide for themselves if they are ready to trust the SE. And hopefully more bugs can be found, issues can be fixed and things can be improved faster. This will benefit the users and the societies as a whole.
ggm 4y ago
Feels like https://cryptech.is https://cryptech.is people would be in this space. They did an FPGA HSM but a secure element with an open design is in the street, a neighbour idea maybe?
- JoachimS 4y ago
  Some of us from the CrypTech core team are involved in Tillitis and the TKey device. Compared to the Cryptech HSM, the TKey is closer to a secure element (it started its life as an embedable root of trust module for VPN relays). https://tillitis.se/ https://tillitis.se/ https://github.com/tillitis https://github.com/tillitis The TKey is basically a tiny, RISC-V based System on Chip in a tiny FPGA. The SoC has a minimal interface to the host, a simple context based memory map and a FW to allow loading applications and generate application base secrets.
hlandau 4y ago
This is long overdue. I've long been intensely frustrated at the way the secure element industry keeps everything behind NDAs, even just basic datasheets. The SEs you can get without NDAs are invariably fixed-function models which you can't program yourself, which aren't interesting at all to me. There shouldn't be such a thing as an "OpenPGP smartcard" (yet there is), there should just be generic programmable smartcards I can program with an application of my choice. The sad thing is such smartcards do exist, you're just not allowed to have them because they're all locked behind NDAs (e.g. the ST32 line - not to be confused with the popular STM32 microcontrollers by the same company). These typically feature a 32-bit ARM core and flash, and are used for bank cards and so on. And you can't have one. Literally all I want from a secure element is: - Some nonvolatile storage which can only be accessed by the code on the device - A way to flash a new program to a device in a way which causes all data on the device to be securely erased - Smartcard-like physical hardening If bunnie makes this happen I'll be very happy. But his mention of "if we release an updatable chip" sounds... concerning? It sounds like he is focusing on people being able to audit the code they're shipping rather than ship their own applications. Perhaps he could clarify what "non-updatable" means for the normal SKU? One additional issue is the availability of non-volatile storage. To my knowledge "high-performance" processes can't actually use flash, and flash requires a specialised process. This leads to SoCs (as opposed to MCUs) tending to use OTP eFuses to program security keys, which is very troublesome as it makes it largely impractical to use them in an owner-controlled way. You essentially have to permanently "damage" the chip to enable secure boot. The ability to wipedown the device fully, as described above, is essential to a device which is practical to use. I'm not sure how MCUs with on-board flash get around this; perhaps they are just built outright on a flash process. They could be multi-die but that would presumably add cost. The mention of using ReRAM is interesting, I wonder what's motivating that. (The STM32 line of MCUs, while not hardened for security purposes, does at least have readout protection. But frustratingly, it can't be disabled once enabled, which prevents the "wipedown" scenario mentioned above. I also suspect that Oxide's work on using off-the-shelf MCUs for boot security processes, which has resulted in them discovering all of the dubious and frustrating things about these MCUs from a security perspective, means they'll be quite interested in the development described in this article.)
- bunnie 4y ago
cassonmars 4y ago
Interesting post. One thing stood out to me: > The performance of older processes is also not sufficient for the latest cryptographic systems, such as Post Quantum algorithms or Multiparty Threshold ECDSA with Identifiable Aborts. On the upside, one could understand the design down to the transistor level using this process. It would be great to see support for PQ and MPC algorithms, but what would make that easier would be SE programmability with access to the base primitives. The specific title reference implies GG-20 (which the original paper is broken, revealed in later papers such as the Alpha-Rays attack), so that would suggest a need for an SE that could expose field element arithmetic (both for DKG and signature creation) and support for Paillier, but even just having the former would be a major boon, as you could implement MPC protocols that rely only on base DLog assumptions like DKLs18 and 19 which use oblivious transfer (albeit with some matrix operations). Any news on this that can be shared at this time?
- bunnie 4y ago
  One goal of an open-SDK SE is for all the base primitives to be open, precisely because stuff like GG-20 gets broken. I don't think it's realistic to think that we're at a point where we could burn such a novel and complicated class of algorithms into a chip, and expect it to have no revisions. The specific citation was provided because MPC algorithms span a pretty big range of computational difficulty, depending on the features you require and the primitives you assume. Narrowing it down to an exemplar algorithm (even if broken) helps pin the analysis to a given complexity range. It's also interesting to note that some MPC algorithms assume some amount of secure and real-time communication with an oracle to assist with key distribution, which means you're possibly having to stuff a TLS stack into the SE.
deleted 4y ago
[deleted]
gchadwick 4y ago
Interesting to see more potential entrants into this space. I work on OpenTitan https://opentitan.org/ https://opentitan.org/ which I believe will do much (indeed maybe everything) of what Cramium and Bunnie are aiming for (of course being a stealth startup hard to know what their plans actually are). We're at an advanced stage of development and being open you can take a look at our work right now https://github.com/lowRISC/OpenTitan https://github.com/lowRISC/OpenTitan our nightly regression dashboards demonstrate the project's maturity https://reports.opentitan.org/hw/top_earlgrey/dv/latest/report.html https://reports.opentitan.org/hw/top_earlgrey/dv/latest/repo... and https://reports.opentitan.org/hw/top_earlgrey/dv/summary/latest/report.html https://reports.opentitan.org/hw/top_earlgrey/dv/summary/lat...
- artemonster 4y ago
  I’ve been following the project for a really long time. As an digital design engineer, I really envy you, you got such an interesting project at hand. Kudos for what you are doing!
- hlandau 4y ago
  OpenTitan looks interesting. I guess my main question though is, how does it support owner controlled applications, i.e. applications where the device owner (not the OEM) can provision and modify all code, rather than it being OEM-signed? Is it efuse-based or does it have nonvolatile storage on board?
- no_time 4y ago
  Huh neat. When are you adding user override to prevent corporations from having complete control over the devices we own?
kanzure 4y ago
Glad to see progress on this. For those interested in contributing I'd recommend the Silicon Salon workshops https://www.siliconsalon.info/ https://www.siliconsalon.info/ see https://diyhpl.us/wiki/transcripts/silicon-salon/ https://diyhpl.us/wiki/transcripts/silicon-salon/ for the transcripts. Another distantly related project I'm watching in this area is https://libre-soc.org/ https://libre-soc.org/ && https://diyhpl.us/wiki/transcripts/silicon-salon/libre-soc/ https://diyhpl.us/wiki/transcripts/silicon-salon/libre-soc/
rkagerer 4y ago
It would be nice if he also pushed for a fuse or other self-destruct button for the non-open-source portion of the silicon.

214 points by zdw 4y ago

What I don't see touched on in this post is the high-level trust model. What generally makes trusted computing a non-starter for libre software is that it contains privileged keys baked in by the manufacturer. A secure element chip does not need a completely libre/open design to support software freedom, but it does need to allow end-owners to run whatever software they would like - not subject to a third party's approval. To that end: 1. The chip needs to be able to be completely erased, having all keys zeroed out, at which time new keys can be loaded and/or internally generated. Signature verification keys are zeroed out to establish a new root of trust, and program/memory keys are zeroed out to maintain the security of information previously entrusted to the chip. 2. Resetting the chip should take a configurable amount of time (days to a month), either based on internally counting the clock or external proof of work, to protect against evil maid attacks by those with temporary possession of the hardware. 3. If there is any remote attestation functionality, then the reset procedure must output the attestation signing keys, including the private parts. This way the manufacturer (or any downstream integrators) cannot record the public identity of the shipped attestation keys to create a trust relationship that would prevent the ultimate owner from running software of their choosing. For software freedom, these aspects are much more important than the design and licensing of the computation core(s). Let them ship ARM. Let them ship only ARM. Let them ship a proprietary ISA that needs to be painstakingly reverse engineered over a decade. Spend your social capital making sure the ultimate end-owners of the chip remain in control of their own devices! This is what is critical for open source.

josephcsible 4y ago
Exactly. In particular, see the "Powerful, Reliable Software Can Be Bad" section of <https://www.gnu.org/philosophy/open-source-misses-the-point.en.html https://www.gnu.org/philosophy/open-source-misses-the-point....>. It'll take careful engineering to keep this from being useful for DRM, which I'm worried won't get done.
- mindslight 4y ago
  Actually even with the requirements I laid out, DRM would still work. A manufacturer could ship a device with decryption keys for DRM content. If the end-owner decided to liberate their device, then the decryption keys would be erased and DRM content could no longer be played. The owner would be left with a blank device ready to accept new software, likely open source, and the device wouldn't be relegated to becoming e-waste.
  - p_l 4y ago
    That's how it works with some of the hw backed DRM schemes that for example try to use remote Attestation with TPM, or secure media pathways on intel me or AMD PSP. The DRM software simply stops working, while you get to run everything you build yourself still.
  - cryptonector 4y ago
    There's no stopping walled gardens -- not with technology as the vendors would choose not to use such technology. The most choice users will ever get to make (per-device) is whether to be locked-into or locked-out-of the walled gardens.
  - josephcsible 4y ago
    Huh, good point. I wonder how that would be fixable too.
    - mindslight 4y ago
      Does it need to be? I'm a staunch supporter of libre software, but I don't see the harm.
      - mschuster91 4y ago
        > I'm a staunch supporter of libre software, but I don't see the harm. The harm is we're still perpetuating DRM crap. The music industry has accepted that Spotify's DRM can be trivially broken and completely given up trying to police BitTorrent... it's time for the movie industry to realize the same. Sadly, Netflix failed to get enough dominance to bend over and cane the movie industry into submission, and regulatory agencies worldwide just accepted happily that movie studios went all-in on vertical integration again.
cryptonector 4y ago
> What I don't see touched on in this post is the high-level trust model. What generally makes trusted computing a non-starter for libre software is that it contains privileged keys baked in by the manufacturer. Keys don't have to be open source. Re (2), the way you defeat evil maid attacks on boot or wake is by using a TPM and measuring every bit of firmware and software loaded (to some point) so that local storage decryption is not possible unless you're running golden code. The hard part is stopping evil maid attacks on running systems. Re (3), for open systems you really need any remote attestation to be at the option of the end user or the operating system that they choose to run (but the end user must have the option to run an operating system of their choice, which then might not implement remote attestation). TPMs got these things right, but they're not SEs. TPMs could be SEs, but they're missing necessary functionality. I'm imagining a BPF-style system where you'd get to send bytecode to be interpreted with access to various loaded key objects (handles), and which would be able to execute TPM commands (subject to policy) and use their outputs without exposing them to the user, with the program's execution and availability of its final outputs being conditional on satisfying some relevant policy. Because so many systems have a TPM, a TCG TPM standard update that allows for a very limited and TPM-centric SE to be implemented with a TPM firmware update would be very interesting. > For software freedom, these aspects are much more important than the design and licensing of the computation core(s). Let them ship ARM. Let them ship only ARM. Let them ship a proprietary ISA that needs to be painstakingly reverse engineered over a decade. Spend your social capital making sure the ultimate end-owners of the chip remain in control of their devices! This is what is critical for open source. Yes, the amount of software built to run in SEs is minute, therefore it's not that big a deal to expect vendors to recompile that software if a new version of the SE were to use a different ISA. I'm a bit surprised at the focus on RISC-V, but I'm not annoyed by it -- if it really costs them little, then I don't see the problem, and having the option is certainly interesting.
- ignaloidas 4y ago
  I think the focus on RISC-V is in large part because of the focus of RTL-level verification. You can't release ARM core's RTL, and some may fear that backdoors might be hidden there. But you can easily release RISC-V core's RTL, and let people verify that there is no backdoors in there.
JoachimS 4y ago
The Tillitis TKey may provide a solution to this. You can (will be very soon) able to buy TKey devices that are not provisioned by Tillitis. Using the TKey programmer you can build your own FPGA bitstream (using the open toolchain). And then, using the provisioning tool or manually generate and insert your own Unique Device Secret (UDS). This also means that you can get two (or more) blank TKey devices and provision them with the same UDS, creating a backup key that you can put in a safe place. I'd recommend to at least have different Unique Device Identities, to allow you to see which of the devices you use when connecting it to the host. The bitstream, with the UDS is stored and locked in the FPGA non volatile configuration memory. It will not protect against a prepared evil maid-attack that gives the attacker enough time to dismantle the casing and perform a warm-boot attack. We are working on ways to make that attack harder, less feasible.

godelmachine 4y ago

>>Cramium (still in stealth mode), approached me to advise on open source strategy Why is a stealth mode company interested in an open source strategy? Isn't that counter intuitive and purpose-defeating?

mhh__ 4y ago
People want the allure of stealth while also having the street cred of.open source, apparently.
- godelmachine 4y ago
  I wonder how many stealth mode companies have actually delivered anything? Magic Leap used to be in stealth mode back in 2016 and there was so much frenzied speculation around it in the media. Last I heard, they had delivered some headsets of industrial process automation and that's about it.
adg001 4y ago
Counter intuitive, perhaps, but not necessarily purpose-defeating, because a stealth mode company can choose to release its open source components only a later moment in time, when it is ready to generate positive cash flow.
detaro 4y ago
Because it doesn't intend to remain in "stealth mode" forever?
- ZiiS 4y ago
  Arguably given a front-page story they are not in "Stealth mode" now?
bunnie 4y ago
Stealth mode simply refers to a stage in a company's evolution, not an on-going state of operation. For example, because the company is not yet fully formed, it doesn't have a website -- nobody has made one, because it's not the most pressing thing to do right now. I don't even think the company has an official logo yet. They are basically walking and chewing gum by trying to put together their advisory board, while they also put together the details of the corporate entity. In essence most startups go through a "stealth mode" phase because many disclosable details simply do not exist. It's perfectly consistent to say "we want to do open source", but also not have prepared a logo, a website, and an overall corporate narrative.

foolfoolz 4y ago

there is no value right now in open secure element. secure element is arguably the most secure hardware platform in the world to deploy at scale. - secure element is in every credit card - secure element is in every cell phone - secure element is in every modern passport these aren’t simple use cases. these have national security implications. i foresee this going the opposite direction as more critical things rely on secure element more individual proprietary implementations will emerge. it’s still a standard. you can still develop on top of secure element. but who really benefits from it being open?

adg001 4y ago
The civil society would benefit, because it is hard to entrust our business and affairs to systems whose degree of trustworthiness is moot at best.
sounds 4y ago
Reduction in e-waste and reduction in forced obsolescence: the more open this secure element is, the more it sets a standard. Then that creates a robust ecosystem around it. (For example, see the Raspberry Pi which helped spur an ecosystem. Also, even the original Pi 1 can still be useful today.) Those secure elements in credit cards (Java Card platform) and cell phones (SIM) have an open standard. This is natural growth in that standard.
JoachimS 4y ago
One obvious is trust. Secure Elements are validated against Common Criteras, often at very high level (6+). Yet, there have been problems. An example is bad RSA implementations. Developing for SEs normally require signing boatloads of NDAs. This makes it hard do talk about weaknesses, things that simply could easily be improved (in support libraries for example). By having open designs, open source more people can review and decide for themselves if they are ready to trust the SE. And hopefully more bugs can be found, issues can be fixed and things can be improved faster. This will benefit the users and the societies as a whole.

ggm 4y ago

Feels like https://cryptech.is https://cryptech.is people would be in this space. They did an FPGA HSM but a secure element with an open design is in the street, a neighbour idea maybe?

JoachimS 4y ago
Some of us from the CrypTech core team are involved in Tillitis and the TKey device. Compared to the Cryptech HSM, the TKey is closer to a secure element (it started its life as an embedable root of trust module for VPN relays). https://tillitis.se/ https://tillitis.se/ https://github.com/tillitis https://github.com/tillitis The TKey is basically a tiny, RISC-V based System on Chip in a tiny FPGA. The SoC has a minimal interface to the host, a simple context based memory map and a FW to allow loading applications and generate application base secrets.

hlandau 4y ago

This is long overdue. I've long been intensely frustrated at the way the secure element industry keeps everything behind NDAs, even just basic datasheets. The SEs you can get without NDAs are invariably fixed-function models which you can't program yourself, which aren't interesting at all to me. There shouldn't be such a thing as an "OpenPGP smartcard" (yet there is), there should just be generic programmable smartcards I can program with an application of my choice. The sad thing is such smartcards do exist, you're just not allowed to have them because they're all locked behind NDAs (e.g. the ST32 line - not to be confused with the popular STM32 microcontrollers by the same company). These typically feature a 32-bit ARM core and flash, and are used for bank cards and so on. And you can't have one. Literally all I want from a secure element is: - Some nonvolatile storage which can only be accessed by the code on the device - A way to flash a new program to a device in a way which causes all data on the device to be securely erased - Smartcard-like physical hardening If bunnie makes this happen I'll be very happy. But his mention of "if we release an updatable chip" sounds... concerning? It sounds like he is focusing on people being able to audit the code they're shipping rather than ship their own applications. Perhaps he could clarify what "non-updatable" means for the normal SKU? One additional issue is the availability of non-volatile storage. To my knowledge "high-performance" processes can't actually use flash, and flash requires a specialised process. This leads to SoCs (as opposed to MCUs) tending to use OTP eFuses to program security keys, which is very troublesome as it makes it largely impractical to use them in an owner-controlled way. You essentially have to permanently "damage" the chip to enable secure boot. The ability to wipedown the device fully, as described above, is essential to a device which is practical to use. I'm not sure how MCUs with on-board flash get around this; perhaps they are just built outright on a flash process. They could be multi-die but that would presumably add cost. The mention of using ReRAM is interesting, I wonder what's motivating that. (The STM32 line of MCUs, while not hardened for security purposes, does at least have readout protection. But frustratingly, it can't be disabled once enabled, which prevents the "wipedown" scenario mentioned above. I also suspect that Oxide's work on using off-the-shelf MCUs for boot security processes, which has resulted in them discovering all of the dubious and frustrating things about these MCUs from a security perspective, means they'll be quite interested in the development described in this article.)

bunnie 4y ago

cassonmars 4y ago

Interesting post. One thing stood out to me: > The performance of older processes is also not sufficient for the latest cryptographic systems, such as Post Quantum algorithms or Multiparty Threshold ECDSA with Identifiable Aborts. On the upside, one could understand the design down to the transistor level using this process. It would be great to see support for PQ and MPC algorithms, but what would make that easier would be SE programmability with access to the base primitives. The specific title reference implies GG-20 (which the original paper is broken, revealed in later papers such as the Alpha-Rays attack), so that would suggest a need for an SE that could expose field element arithmetic (both for DKG and signature creation) and support for Paillier, but even just having the former would be a major boon, as you could implement MPC protocols that rely only on base DLog assumptions like DKLs18 and 19 which use oblivious transfer (albeit with some matrix operations). Any news on this that can be shared at this time?

bunnie 4y ago
One goal of an open-SDK SE is for all the base primitives to be open, precisely because stuff like GG-20 gets broken. I don't think it's realistic to think that we're at a point where we could burn such a novel and complicated class of algorithms into a chip, and expect it to have no revisions. The specific citation was provided because MPC algorithms span a pretty big range of computational difficulty, depending on the features you require and the primitives you assume. Narrowing it down to an exemplar algorithm (even if broken) helps pin the analysis to a given complexity range. It's also interesting to note that some MPC algorithms assume some amount of secure and real-time communication with an oracle to assist with key distribution, which means you're possibly having to stuff a TLS stack into the SE.

deleted 4y ago

[deleted]

gchadwick 4y ago

Interesting to see more potential entrants into this space. I work on OpenTitan https://opentitan.org/ https://opentitan.org/ which I believe will do much (indeed maybe everything) of what Cramium and Bunnie are aiming for (of course being a stealth startup hard to know what their plans actually are). We're at an advanced stage of development and being open you can take a look at our work right now https://github.com/lowRISC/OpenTitan https://github.com/lowRISC/OpenTitan our nightly regression dashboards demonstrate the project's maturity https://reports.opentitan.org/hw/top_earlgrey/dv/latest/report.html https://reports.opentitan.org/hw/top_earlgrey/dv/latest/repo... and https://reports.opentitan.org/hw/top_earlgrey/dv/summary/latest/report.html https://reports.opentitan.org/hw/top_earlgrey/dv/summary/lat...

artemonster 4y ago
I’ve been following the project for a really long time. As an digital design engineer, I really envy you, you got such an interesting project at hand. Kudos for what you are doing!
hlandau 4y ago
OpenTitan looks interesting. I guess my main question though is, how does it support owner controlled applications, i.e. applications where the device owner (not the OEM) can provision and modify all code, rather than it being OEM-signed? Is it efuse-based or does it have nonvolatile storage on board?
no_time 4y ago
Huh neat. When are you adding user override to prevent corporations from having complete control over the devices we own?

kanzure 4y ago

Glad to see progress on this. For those interested in contributing I'd recommend the Silicon Salon workshops https://www.siliconsalon.info/ https://www.siliconsalon.info/ see https://diyhpl.us/wiki/transcripts/silicon-salon/ https://diyhpl.us/wiki/transcripts/silicon-salon/ for the transcripts. Another distantly related project I'm watching in this area is https://libre-soc.org/ https://libre-soc.org/ && https://diyhpl.us/wiki/transcripts/silicon-salon/libre-soc/ https://diyhpl.us/wiki/transcripts/silicon-salon/libre-soc/

rkagerer 4y ago

It would be nice if he also pushed for a fuse or other self-destruct button for the non-open-source portion of the silicon.