TKey – Security for the New World

Thank you for mentioning that. Yes.

There's also Glasklar Teknik AB and Karlstad Internet Privacy Lab AB.

Glasklar does:

- Sigsum, a transparency log design

- System Transparency, a security architecture for transparent systems

- Hosts and maintains the Debian Snapshot service, an archive of the past decade of released Debian packages

KIPL does traffic analysis defense against AI-based classifiers, which Mullvad recently integrated into the VPN app.

https://www.glasklarteknik.se

https://www.sigsum.org

https://www.system-transparency.org

What's the sentiment towards Mullvad?

> how can a device with Soft-CPU implemented on FPGA can be secure?

> FPGA configuration (NVCM). The only secret is UDS, 256 random bits that are baked into FPGA configuration stream, and they are protected by FPGA's read-out protection.

Correct. Here are some more interesting details:

- we're using the Lattice iCE40 UltraPlus FPGA, which is supported by open tooling and has been for a long time. During the course of the project we also had the configuration and locking protocol reverse engineered so that one can configure and lock the FPGA with open tooling.

- the iCE40's Non-Volatile Configuration Memory (NVCM) uses anti-fuse technology for storing the configuration bits, where the 0s and 1s are stored in vias on the die. The physics of how these vias are modified to represent a 0 or a 1 make it very hard to read out information using X-ray, unlike on-die storage implemented using "horizontal" e-fuses. That's the gist of it.

- the FPGA's boot state machine is unfortunately designed such that you can get it to boot an external bitstream from SPI even after you've configured and locked NVCM, and the state of EBRs (block memory) is retained across warm reboots of the FPGA. We took several steps to mitigate this limitation, which, now that I think about it, would make several interesting blog posts. The UDS memory itself is in LCs, you can mix in key material from the host, the exact timing of that is randomized, RAM (implemented in EBR) is has both address and data randomization... and a few more things.

- physical security is hard, and the TKey won't be able to stand up against any and all physical attacks, but I don't think there is any security hardware in the world that is as open and inspectable as the TKey.

I think some form of anti brute force could still be done using something like https://blog.trailofbits.com/2018/10/12/introduction-to-veri...

> 2922 (305 points, 119 comments)

Dude. Can I borrow your time machine?

(I work at Tillitis)

Yes, OpenTitan is cool.

The philosophical discussion about FPGAs and ASICs in the context of security is interesting.

For the TKey FPGA design you can inspect both the design (https://github.com/tillitis/tillitis-key1/tree/main/hw/appli...) and the toolchain (Icestorm: https://github.com/tillitis/tillitis-key1/blob/main/doc/tool... that contains synthesis, place&route, NVCM programming tools). However, the internal FPGA fabric—consisting of the logic cells, memory, and interconnects—remains proprietary.

Most Open Source ASICs I am aware of provide open-source RTL designs, but the tool chains are usually proprietary. Hard macros, memories, security mechanisms, etc are typically also closed source. And then there is the manufacturing process itself that is not transparent.

There isn’t a definitive answer as to what constitutes “enough” openness for security inspections. Individuals have different thresholds for what they consider acceptable.

So far we chose as much open source as possible.

their approach is a one which is fully stateless on the chip (see their documentation for why)

theoretically this is quite desirable but various protocols aren't build in a way enabling it

e.g. TOTP pushes a secret from the server to the client, instead of having some form of deterministic key exchange

similar while FIDO protocols and passkeys could have been designed in a way which can work fully stateless they are not

now it doesn't mean you can't make it work with tkeys but it can get more complex e.g. for TOTP using TKey to guard a local password vault which then does the TOTP instead of having the TOTP on the key directly (but then while TOTP is better then SMS 2FA it's still pretty bad compared to what technically is possible, like much worse then a lot of people realize)

We're working on it. Our next hardware should have USB HID, FIDO2, and persistent storage. The persistent storage will be per device app. Well, that's the idea anyway. I'm not sure when we'll be done but check our website in a few months, or join our mailing list.

You can get Nitrokey HSM for $100: https://shop.nitrokey.com/shop/nkhs2-nitrokey-hsm-2-7?catego...

> I really want one. I just currently don't know how to write device driver stuff

Ease into it. We have fairly good documentation and some getting started material you can read (tillitis.se, dev.tillitis.se, GitHub) to gauge your level of understanding. The design is also meant to have the bare minimum complexity necessary to accomplish its functionality. It seems to have potential as a learning platform for college students who want to understand computers from the gates and up.

always remember the FIDO standard is more about validating identities than authorization.

No firm plans for USB-A. A USB-C to USB-A converter works, but maybe not so elegant.