Hacker News Reader

> 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.

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.

> 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.

FWIW it's a bit of a different game with TPMs than with secure elements in general - imagine how much would it cost a bank in credit card replacement costs if the firmware on them could be erased by anyone, making the card useless. That's not something that should be wipeable.

Sure, because the bank probably doesn't charge customers for the cost of the replacement card, so customers could get a free smartcard for other purposes. What do these cost nowadays?

> 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.

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.

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.

> 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

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.

> why would anyone want to implement cryptography in BASIC?

The cryptography for these cards is usually provided by the OS or even in custom hardware, mostly for performance reasons: The underpowered 8-bit MCUs that were commonly used for them can't run e.g. RSA in a reasonable timeframe, so they have custom coprocessors for that.

> "I want a smartcard where I can program the actual CPU, not in some VM." [...] 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.

I'm unfortunately not aware of such a thing in the smartcard world, but if you think about it, this just pushes the problem of trust down one layer. At some point, you'll have to trust the hardware RNG to supply actual randomness (and not just the output of a known-seed PRNG).

I suppose it could be useful in some scenarios to get rid of the proprietary OS/VM implementation if you are concerned about bugs there, but in the end, you are still ultimately trusting your hardware vendor.

Or are you mainly interested in being able to use a stack other than Java Card?

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