Hacker News Reader

Comment by rwmj | Hacker News Reader

Which FPGA are they using?

Edit: There's a lot to like here, but a lot that is confusing. An FPGA based version of PicoPV32 could be really secure. Your attack vector would be the FPGA vendor doing something at the hardware level (hard to pull off), or the toolchain being compromised.

But what FPGA it is matters, also what toolchain they are using to programme the FPGA (yosys is not mentioned ...). The whole "locked down" FPGA bitstream sounds very fishy as well.

PicoRV32 does fit into Lattice FPGAs and they are fully reverse-engineered and supported by yosys.

View on HN

FPGA: Lattice ice40up5k

Toolchain: Yosys.

For the convenience of most end users we configure and lock the FPGA. This allows them to start using it right away. The core cryptographic technology relies on a Unique per Device Secret (UDS). If we didn't lock the FPGA's configuration memory from reads a physical attacker would be able to read it out in seconds.

Users that want to provision their own hardware design / FPGA configuration / bitstream can simply buy the TKey Unlocked and the TKey Programmer. They can then configure the on-die OTP NVCM and lock the FPGA themselves. Configuration and locking of the ice40up5k was not possible to do with open tooling until we made it happen, as part of the project to create the TKey.

Since you seem knowledgeable it might interest you that:

* The OTCP NVCM uses antifuse technology, so it's most likely not possible to read out the UDS with an electron microscope. The physical attacker will have to circumvent the locking mechanism and read out the NVCM through probing.

* One of the pins can be used to toggle SPI slave configuration mode even after NVCM has been configured and locked. This allows a physical attacker to configure their own bitstream. Unfortunately EBR and SPRAM also keep their state across warm reboots. As mitigations we (1) store the UDS in LCs until it is used by the KD, (2) use our TRNG to randomize when the UDS readout happens, (3) accelerate the hashing (Blake2s G function) in LCs, (4) randomize address and data layout using a non-cryptographic PRP, and some other things I don't remember at the moment. Depending on the user's security concerns we recommend the use of a user-supplied secret in addition to the UDS. In that case the TKey by itself doesn't contain all the key material, making a physical attack insufficient. The KDF can be read in the manual.

Edit: Clarified _physical_ attacker. Added details about the chip.

Supply chain attacks can be mitigated with "golden chip analysis", you destructively analyse a known good chip after measuring various power and timing benchmarks across adversarial configurations, and repeat those measurements across all future chips and check they are within margin of error.

Genuine question: how many transistors and/or logic gates do we need to perform ECDSA and feel more secure than using FPGA or other security elements? I see that security elements used by Ledger crypto wallets is the [1] and an ASIC one would be better to reduce the attack vector? But do they could have memory inside or just cache? I don't know too much about electronics.

[1] https://octopart.com/stm32wb55ccu6-stmicroelectronics-100293...

The answer is, as always, it depends. I'll do my best to characterize the problem:

If we only care about minimizing logic gates we could use SERV, the world's smallest RV32 core, and run a bare metal ECDSA implementation on it. Let's use it without the M extension, so RV32I. I'm not sure what SERV's max clock frequency is, but assuming we configured it on the ice40 and it runs at 40 MHz I'm guessing a single ECDSA signature would take hours to comput.

Due to the math involved in ECC it is quite challenging to make a "hardware-only" ECC signer. The ones I've seen are effectively ECC accelerators with some kind of state machine or microcode to run the algorithm.

In the case of TKey we use picoRV32 configured as RV32ICZmmul (multiply without divide). We use the FPGA's DSPs to accelerate multiplication. On the TKey an Ed25519 signature takes less than a second, which we believe is acceptable for many use cases, and I'm willing to bet there is no Ed25519 signer that is more open source hardware and software than the TKey.

As GP points out using an FPGA is in fact an excellent way to mitigate various supply chain attacks. It's like hardware ASLR, to paraphrase bunnie in his CCC talk.

Thank you! BTW I assume you will support U2F, Crypto, etc in the future? or do you expect third parties to develop on it?

From a quick glance at the product it seems I should buy the unlocked to have full control of the device and in the future could be a device with a display and some more sensors and/or buttons to know what I am signing in?

I am currently in South America so waiting to travel to one of your shipping locations to buy several TKeys.

I believe we already have a U2F prototype for Linux. In general we are quite selective about which applications we take on development and maintenance responsibilities for.

Given that this is the most open source hardware USB authenticator we hope the communities that value this level of openness, design assurance and design verifiability will adopt the TKey and build whatever applications they need for it. Having said that we see lots of opportunities for us to make it easier for developers to build what they need.

Reply on news.ycombinator.com