Towards a More Open Secure Element Chip
This is long overdue. I&#x27;ve long been intensely frustrated at the way the secure element industry keeps everything behind NDAs, even just basic datasheets.<p>The SEs you can get without NDAs are invariably fixed-function models which you can&#x27;t program yourself, which aren&#x27;t interesting at all to me. There shouldn&#x27;t be such a thing as an &quot;OpenPGP smartcard&quot; (yet there is), there should just be generic programmable smartcards I can program with an application of my choice.<p>The sad thing is such smartcards <i>do</i> exist, you&#x27;re just not allowed to have them because they&#x27;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&#x27;t have one.<p>Literally all I want from a secure element is:<p>- Some nonvolatile storage which can only be accessed by the code on the device<p>- A way to flash a new program to a device in a way which causes all data on the device to be securely erased<p>- Smartcard-like physical hardening<p>If bunnie makes this happen I&#x27;ll be <i>very</i> happy. But his mention of &quot;if we release an updatable chip&quot; sounds... concerning? It sounds like he is focusing on people being able to audit the code they&#x27;re shipping rather than ship their own applications. Perhaps he could clarify what &quot;non-updatable&quot; means for the normal SKU?<p>One additional issue is the availability of non-volatile storage. To my knowledge &quot;high-performance&quot; processes can&#x27;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 &quot;damage&quot; 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.<p>I&#x27;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&#x27;s motivating that.<p>(The STM32 line of MCUs, while not hardened for security purposes, does at least have readout protection. But frustratingly, it can&#x27;t be disabled once enabled, which prevents the &quot;wipedown&quot; scenario mentioned above. I also suspect that Oxide&#x27;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&#x27;ll be  quite interested in the development described in this article.)