Towards a More Open Secure Element Chip

https://www.bunniestudios.com/blog/?p=6606

by zdw • 4 years ago

214 69 4 years ago

mindslight8• 4 years 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.

josephcsible3• 4 years ago

Exactly. In particular, see the "Powerful, Reliable Software Can Be Bad" section of <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.

mindslight8• 4 years 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.

cryptonector13• 4 years ago

The TCG got this right in that TPMs do not force you into a DRM world, but they certainly enable it. I say that's right because any TPM-like technology that could let you secure boot could also let the platform vendor lock you into a DRM world -or lock you out of the walled garden if you opt out- but the TCG took a neutral approach that lets the user opt out.

cryptonector13• 4 years 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.

ignaloidas2• 4 years 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.

mindslight8• 4 years ago

TPMs got these things right

How did TPMs get these things right? To me, it seems they've gotten them direly wrong by letting the manufacturers create privileged keys.

I wrote my comment from the perspective of making something better than modern TPM implementations, iff they get the ownership/control issues right.

I don't understand your counterpoint to my (3). It's not enough for the OS to have an option to not perform remote attestation - the owner needs to have the ability to perform a mock remote attestation. Otherwise a remote party can just demand remote attestation be done, and the owners's "choice" will have been nullified.

snvzz• 4 years ago

The ARM CPU is there as a backup, for investors' peace of mind.

It will never be used, unless the RISC-V core turns out defective, which is extremely unlikely.

JoachimS3• 4 years 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.

godelmachine2• 4 years 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__• 4 years ago

People want the allure of stealth while also having the street cred of.open source, apparently.

godelmachine2• 4 years 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.

adg0012• 4 years 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• 4 years ago

Because it doesn't intend to remain in "stealth mode" forever?

ZiiS• 4 years ago

Arguably given a front-page story they are not in "Stealth mode" now?

bunnie4• 4 years 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• 4 years 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?

adg0012• 4 years 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• 4 years 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.

JoachimS3• 4 years 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• 4 years ago

Feels like 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?

JoachimS3• 4 years 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://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.

hlandau8• 4 years 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.)

bunnie4• 4 years 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.

hlandau8• 4 years 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.

hlandau8• 4 years 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.

bunnie4• 4 years ago

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?

This is driven by the paying customer (not the end user: but the entity actually writing checks with lots of zeroes on it and taking in truckloads of chips).

It is a fact that the biggest, highest volume paying customers to date for SEs would assume that such chips could only be updated through means that the customer controls. Thus, a business manager doing volume-driven research to craft a chip specification for such a market would reasonably conclude this is a mandatory checkbox for generating volume orders.

The flip side is the assumption that nobody in their right mind would pay for a chip that could be fully wiped and/or updated by end users. And to a first order, the conclusion is correct: I can't think of anyone who would write a check big enough to fill distribution channels with such a SKU. Keep in mind that chips are run by the wafer, and things don't get interesting until you run about 25 wafers in a single lot, so you're looking for someone to underwrite the cost for upwards of 100k devices until a sustainable market for such fully updateable chips materializes.

This is where the "obviousness" of an open source approach comes crashing into the reality of market-driven hardware economics. It seems pretty obvious to people like you and me that we should have fully updateable SKUs that can be wiped and provisioned by end users. But there's a chicken-and-egg problem of building the hardware, so that OSS developers can write the software stack, then hopefully getting adoption by volume businesses; but volume business wouldn't adopt until the hardware was cheap enough and the software stable enough.

The angle I'm hoping to exploit is that because the chips are done with no OTP and only ReRAM, we can release a fully-open and updateable SKU as a late-binding wafer sort option. So instead of having to buy a whole lot of wafers, we can split out a portion of a larger run as the "open source developer's" SKU, at a volume that could be underwritten with say, a crowdfunding campaign.

Thus, you'd have the same design, fabricated using the same masks and literally on the same wafer, but based on how some ReRAM bits are configured in the factory, one will accept updates, and the other will not. It's a compromise, but that's the angle I'm trying to work, at the very least. And until someone is willing to step in with a few million bucks to make the demands of other paying customers irrelevant, it's maybe the only practical approach I can see at the moment to break the chicken and egg cycle.

I think the team is on-board with the approach, but there's a lot of technical details to work out, which is why there is an "if" qualification. For example, if you totally wipe all the ReRAM, but you need some extant code to write ReRAM in the first place, you again have a chicken and egg problem. This problem is solvable at wafer sort using probe pads that can put the initial code in place to allow bootstrapping, but how to extend this to a convenient user-accessible solution is an open problem. This is particularly troublesome for SKUs that are destined to be packaged in minimal packages, e.g. an 8-pin SO package or a smart card format, where you simply lack the pins to expose a provisioning port. This is also, unfortunately, where all the volume is.

It could be that the open source SKU simply comes in a package with more pins and we burn precious I/O to expose something like a permanent JTAG interface. Muxing over the JTAG pins to other I/O can also help mitigate the challenge, but it adds complexity and verification/shipment risk if the mux circuit is defective, and again, a hardware bug costs millions of dollars in this scenario so no decision can be considered "trivial". Nobody wins if I try to force some clever provisioning solution that turns out to be broken (also keep in mind that smart card I/O is weird and fussy, it's not a generic CMOS I/O cell).

Also keep in mind that creating a version with a larger package could be a non-starter if we don't also have demand from a "paying" customer to fund the R&D and supply chain to push out that package format. Chip packages aren't free, and also come with substantial up-front costs and high minimum volume requirements.

hlandau8• 4 years ago

Very interesting writeup - thanks for going into detail on this. So basically there will be a variant which isn't erasable unless you have the "OEM"'s key and a variant which is always erasable.

Everything above makes sense and I really appreciate how you're trying to make this happen for the open source community by intelligently designing a product for both markets.

I infer from the above that you're intending to avoid having any kind of mask boot ROM that could allow programming via the normal interface used to talk to the SE... trying to avoid a boot ROM is interesting, but this is certainly one of the downsides. I guess you could try and hardcode the logic for a serial download protocol over the standard interface to the SE, if you can validate it well...

Wishing you luck and hope everything goes to plan.

cryptonector13• 4 years ago

The flip side is the assumption that nobody in their right mind would pay for a chip that could be fully wiped and/or updated by end users.

Eh, TPMs are fully erasable -- well, the seeds that matter anyways, but not the public keys that sign firmware updates. There's a big difference between "fully wiped" in the TPM sense and "updated by end users" if the latter means "with their own code", but the latter is still OK if in the process all key material is lost that could be used to impersonate the original device.

I.e., an SE that users can flash with their own software should be OK provided that there is no way to impersonate the original SE after doing so. I've no idea if that can be the case for SEs, but it definitely could be for TPM-like devices.

mschuster912• 4 years ago

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.

Actually, you can. German company ZeitControl sells cards you can program on your own in a BASIC dialect [1]. Been years since I last played around with my set, but they're still well in business.

[1] https://www.zeitcontrol.de/de/produkte/basiccard/basiccard-p...

lxgr2• 4 years ago

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.

That's in fact very possible! I've been doing just that, i.e. running an open source implementation [1] of the OpenPGP smartcard standard [2] on a physical card to which I have the root keys.

The card specifications themselves are presumably behind NDAs, though, so I do have to trust the vendor to not have built in anything nefarious, e.g. a predictable/keyed RNG.

And you can't have one.

I have three :)

The specifications are indeed behind NDAs, but you don't really need those – you can just work with the (publicly accessible) Global Platform application management commands and the Java Card API. The excellent GlobalPlatformPro [3] can take care of much of the former.

[1] https://github.com/anssi-fr/smartpgp

[2] https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3...

[3] https://github.com/martinpaljak/GlobalPlatformPro

hlandau8• 4 years ago

I'm aware of JavaCard (and those BASIC cards, which are even more absurd - why would anyone want to implement cryptography in BASIC?). But JavaCard (or BASIC) isn't the real CPU but a VM. So I guess I should have said, "I want a smartcard where I can program the actual CPU, not in some VM."

May as well add some random smartcard history... I believe historically one of the reasons for this is that most smartcard chips for the longest times were basically an 8051, a made-to-order mask ROM, and a very small amount of flash (too small for much code). So there was a real need to minimise the size of code which needed to be put in nonvolatile storage. I assume JavaCard implementations have their own implementations of standard cryptographic algorithms in mask ROM to avoid the need to put them in the undersized quantity of flash.

But this isn't the case anymore, where you have smartcards with 32-bit ARM cores and which are all flash-based. If there's a way to obtain and program one of these, I'd like to know about it.

lisper3• 4 years ago

there should just be generic programmable smartcards I can program with an application of my choice

Towards a More Open Secure Element Chip

Related Stories