9 ms·

TKey is a RISC-V computer in a USB-C case, that can run security applications

204 points by jandeboevrie 3y ago

goodpoint 3y ago
Way too expensive.
- SpaceNoodled 3y ago
  And they couldn't even put application ROM on there.
- rdl 3y ago
  Qty 1, $80 seems tolerable for a dev device. They should explicitly list 10 for $500 and 100 for $3000 or something though. This is competing with $5-30K HSMs as well as $30-400 "hardware wallets" or second factor keys, as well as (free) embedded secure enclaves.
- rwmj 3y ago
  I would guess because of the FPGA. The advantage is it's (somewhat, arguably) more secure than a RISC-V ASIC from some random vendor.
  - charcircuit 3y ago
    Do not forget that they also need to recoup the $$$$$ spent getting it certified. For niche electronics this can be a big percentage of the price. Making something into an actual commercial product, especially globally, results in extra markup.
treyd 3y ago
I'm kinda skeptical of security devices like this that don't have their own screens that let you know what you're authenticating. Obviously there's some applications where it's fine but if the PC it's plugged into is compromised it could be MITMing the auth.
- gorkish 3y ago
  Yes agree the end user needs feedback at the authenticator. This device has an RGB LED and a touch sensor, so there are still some possibilities.
  - rdl 3y ago
    I'd put a key inside my app which then talks out of band to multiple devices (including maybe a trusted one?) -- e.g. "run app on the device, request input using the directly-connected PC, message tunneled out to my phone for confirmation") A screen and 2-3 buttons would be nice, though; also a tamper-evident/tamper-responding package. But my main desired use case for this is a lightweight app-specific HSM so I'd just need to validate integrity of device before connecting it to host. USB Armory II is the main alternative.
- fmajid 3y ago
  Have a look at Bunnie Huang’s Precursor project, but it’s much more expensive.
- kfreds 3y ago
  It's a trade-off. We've thought about adding a screen to a future product, but it begs the question of how much information you want displayed in order to make your authentication decision. And even if a screen gives you more information, are you authenticating an action where the cryptography terminates in the device? If you are authenticating an SSH session for instance, the screen helps you ensure you are authenticating a login to the right server. Once you have authenticated though, nothing prevents the attacker in your local machine from using the established SSH connection.
  - lxgr 3y ago
    Very good point. "What you see is what you sign" is a powerful property, but it does often need some support on the side of the signature verifier to make it possible. Reading through an entire email (maybe MIME multipart encoded) on a small OLED screen isn't fun; on the other hand, something like "confirm transfer of €x to IBAN y from your account z" would be great – but needs support of your bank. That support is incredibly hard to get. Android has supported "protected confirmation" [1] for many years now (on Pixel devices), but I have yet to see support for it by any real-world service I'm using, and I'm not holding my breath, since I can't even use FIDO with any of my banks... [1] https://developer.android.com/privacy-and-security/security-android-protected-confirmation https://developer.android.com/privacy-and-security/security-...
rdl 3y ago
If they could add some hardware tamper-evidence/tamper-response (design-to-meet FIPS 140-3 level 3 or EAL whatever, although no need to actually get certified), this could be super useful as a cheap application-specific HSM (which can run app logic inside, rather than the lobotomized/zombie signing oracle PKCS "HSM" use which is common.) Obviously can prototype without this functionality, and can build out the toolchain/etc. I'm a lot more excited about Tropic Square than most alternatives, but this is shipping now.
- kfreds 3y ago
  Regarding FIPS 140-2 level 2 tamper evidence and level 3 tamper response I'm interested to hear what you (and others here on HN) value and why. Level 2 can be accomplished with nail polish and glitter, or plastic potting. Yubikey's potting is a good example of level 2 tamper evidence. For level 3 tamper response, e.g. of a rack-mounted server case, it is enough to put micro-switches under the lid. For that type of product level 2 tamper evidence could be accomplished by covering the server case's screws with copper cans stamped with serial numbers. When I first learned what is actually required for FIPS 140-2 level 2 and 3 I thought it was security theater. Then I realized that in practice such a server case will be (1) in a locked server cabinet, in a server room with access control, within a building with access control. Add a two-person requirement for entering the room and unlocking the cabinet, and the attacker will have to be quite sophisticated and capable to not be discovered way before any tamper evidence or tamper response comes into play. In other words, if you don't care about FIPS for regulatory reasons, or insurance reasons, or company policy reasons, then how much does level 3 tamper response really matter? Regarding CC EAL, I'll simply say that I don't believe there is any other hardware security product that is more open source hardware and software than the TKey. Thanks to it being FPGA-based it is somewhat protected from various attacks on the supply chain. If you're looking to do an Ed25519 signature I don't believe there is a single device more simple or easily verifiable than the TKey and it's Ed25519 signer application. I'd love to be proven wrong.
  - rdl 3y ago
    I was at ACM Copenhagen although more downstairs at ASHES (which my company sponsored) and DeFi. Ryan Hurst who was there is probably the best person to ask about the specific certification use cases. But overall -- I work for an insurer. Having to document how something was done a year+ after it was done to convince auditors/insurers/large clients is a LOT easier if you can point to a specific piece of hardware vs. a bespoke process. The downside of not having tamper-evidence or tamper-response (ideally) at the hw level is you need to build a lot of other controls around it, and that is expensive, impractical, and difficult to document in a lot of environments. e.g. in a datacenter it's unlikely you can enforce "two man from security/senior executive team in the cage"; it's probably going to be (at best) two ops staff, often contractors, and two-man rule isn't actually that widely used outside CAs themselves. The use cases I'd like for this are application logic, not traditional CAs (who do need FIPS). Add to this lifecycle management of the hardware from production to pickup/delivery to provisioning, pre-deployment storage, deployment, operation, routine audit, replacement, audit, and decommissioning, and it's way easier to put protection into the module. Most of the time I've just seen hardware protection inherited from single-chip vs. module-level protection created, but if there's no certified IC available, module protection it is. Actual FIPS certification would be nice (or a better standard), but challenging in deployment because almost every vendor FIPS certifies with a specific application load and as soon as you run custom applications (which is badly supported in the HSM world), you lose certification anyway. "FIPS rated hardware running a non-FIPS load, audited in appendix A" is insurable, but ideally there would be something better. 99+% of HSM deployments are just used as dumb key signers which are trivially exploitable when you pop the host, though, so I'd certainly take the non-FIPS option. (Today, the state of the art is pretty much SGX or another TEE on the host running custom application logic to evaluate and instruct signing which talks to the FIPS HSM to do key control and actual signing, e.g. what Anchorage does.)
wepple 3y ago
Can anyone comment on the design decision to not store device firmware? Is this common? I would’ve assumed it would generally be safer to have permanent but updatable firmware, to reduce the attack surface of malicious firmware loadings
- wepple 3y ago
  I guess as a follow-up, you possibly can’t actually “update” firmware for this, without it creating entirely new keys that would have to be registered with every application
  - kfreds 3y ago
    You're mostly correct. The immutable firmware derives unique key material for each device+application combination. However, nothing prevents the loaded application from loading another application. This allows the developer to construct their own update logic. For instance, the first application could simply exist to verify a digital signature over some hash, then load an application, hash it, compare it to the trusted hash, and then execute it. The first application could hand over its own key material.
- kfreds 3y ago
  Sure. Specifically regarding not storing firmware: The TKey does have roughly 6 KB of immutable firmware which is responsible for loading device applications sent by the host. This firmware receives and then hashes the application together with the Unique per Device Secret. The resulting hash is handed to the loaded application as key material, which is now unique per device+application combination. This model doesn't prevent storing applications on the device, but to enable the user to have flexibility to load other apps we would need to change things a bit. Regarding security: This is a question of measured vs verified boot. Until the TKey, users of USB authenticators had to choose between security and flexibility. Yubikey is not updatable at all, but several USB authenticators have updatable firmware using signed firmware updates. Some of them are open source software, and of those a few are open source hardware in the sense that they provide BOM, schematics and PCB design. We do all of the above, and in addition we provide the HDL / "chip design" / FPGA configuration. In any case, having a USB authenticator which is updatable using a signed update begs the question of who is allowed to sign updates, which then leads to central control and a long tail of interesting use cases not being signed. TKey aims to combine security, openness and flexibility. We accomplish this thanks to unconditional measured boot as a KDF, as opposed to verified boot. There is more information on our website.
rwmj 3y ago
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.
- kfreds 3y ago
  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.
- wslh 3y ago
josephcsible 3y ago
> Note well: In the end-user version (not TKey Unlocked) the FPGA configuration is locked down. This means you cannot change the FPGA bitstream or read out the bitstream (or the Unique Device Secret, UDS) from the configuration memory, even if you break the case and insert it into a programmer board. That seems like it's only useful for "security" against the owner, rather than for any legitimate form of security.
- AVincentInSpace 3y ago
  How so?
  - josephcsible 3y ago
    Consider a DRM system that does challenge/response against said secret so that only one computer at a time can use something. As the owner of this device, if I want to clone it, I should be able to.
    - its-summertime 3y ago
      You can buy an unlocked version and clone it, no?
    - charcircuit 3y ago
      But then the device could be used by 2 computers at once defeating the security. Another use case would be as a second factor of authentication. Making it impossible to clone is essential for a "something you own" factor.
- FiloSottile 3y ago
  That's the whole point of a TKey as a security device: the secret available to an application depends on both the device it's running on and the application, and can't be extracted, so you can do things like "sign a blob only if it follows these rules" and enforce it in hardware. If the device wasn't locked, you could just... change the rules. How is that not a legitimate form of security?
kfreds 3y ago
I created the TKey together with my colleagues. AMA. :)
- fsflover 3y ago
  How is it better than Precursor? https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.crowdsupply.com/sutajio-kosagi/precursor
  - INTPenis 3y ago
    I'm not affiliated with either but I just looked at the precursor page because I'm a huge nerd and love crowdfunded projects. They seem to be in slightly different leagues. Tkey is small and meant to be easily carried with you to authenticate with ssh, gpg and more. While precursor is a full development board that can probably do everything tkey can, and more.
  - kfreds 3y ago
    Whether TKey or Precursor is better depends on your needs. Here are some differences between them: * TKey uses open tooling for everything. Precursor uses Vivado. * Precursor has a screen and a keyboard, allowing the user to interact directly with the trusted device in a completely different way than the TKey. * The Precursor is bigger than the TKey. * The Precursor costs much more than the TKey. Finally I'd just like to mentiont that bunnie and xobs work on Precursor as well as their other projects have been a great inspiration to the TKey project.
    - fsflover 3y ago
      Thank you!
  - 70rd 3y ago
    Different product at a different price point with different objectives. Security keys are suitable for mass deployment across an entire workforce, precursor aims to be a launchboard for general purpose secure and trustable computation. Even at mass production prices, precursor would likely still cost more than 100$.
7e 3y ago
"There is no way of storing a device application (or any other data) on the TKey. A device app has to be loaded onto the TKey every time you plug it in."
5- 3y ago
hardware wise, looks to be a usbc version of fomu. https://www.crowdsupply.com/sutajio-kosagi/fomu https://www.crowdsupply.com/sutajio-kosagi/fomu
- kfreds 3y ago
  One major difference between TKey and Fomu is that Fomu uses the ice40 for USB hardware logic as well as USB device firmware. TKey uses a dedicated USB chip (CH552, which comes with open source firmware). Fomu could likely not fit USB logic as well as the security-related cores we have. That, and the fact that we don't want the attack surface of the USB firmware running in the same core that handles the KDF. They are very different products for very different use cases.
  - 5- 3y ago
    thanks, that's an important distinction. i like the conceptual purity of fomu, but it does take quite a bit of work to get to the point of talking to it over usb.
    - kfreds 3y ago
      Same here. It was a source of inspiration when we started working on the TKey. Could you expand on what you mean by "take quite a bit of work". I thought Fomu came preconfigured?
      - 5- 3y ago
        yes, sorry, i was referring to writing gateware from scratch. you have to implement a usb device before you get past a blinky.
        kfreds 3y ago
        Right. Speaking of which, do you have any recommendations for good USB cores?
  - 3y ago
anishathalye 3y ago
This is really neat! We've been working on some research to formally verify the hardware/software of such devices [1, 2]. Neat how there are so many shared ideas: we also use a PicoRV32, run on an iCE40 FPGA, use UART for communication to/from the PicoRV32 to keep the security-critical part of the hardware simple, and use a separate MCU to convert between USB and UART. Interesting decision to make the device stateless. Given that the application keys are generated by combining the UDS, USS, and the hash of the application [3], it seems this rules out software updates? Was this an intentional tradeoff, to have a sort of "forward security"? In an earlier project I worked on [4], we had run into a similar issue (no space for this in the write-up though); there, we ended up using the following approach: applications are _signed_ by the developer (who can use any keypair they generate), the signature is checked at application load time, and the application-specific key is derived using the hash of the developer's public key instead of the hash of the application. This does have the downside that if the developer is compromised, an adversary can use this to sign a malicious application that can leak the key. [1]: https://github.com/anishathalye/knox-hsm https://github.com/anishathalye/knox-hsm [2]: https://pdos.csail.mit.edu/papers/knox:osdi22.pdf https://pdos.csail.mit.edu/papers/knox:osdi22.pdf [3]: https://tillitis.se/blog/2023/03/31/on-tkey-key-generation/ https://tillitis.se/blog/2023/03/31/on-tkey-key-generation/ [4]: https://pdos.csail.mit.edu/papers/notary:sosp19.pdf https://pdos.csail.mit.edu/papers/notary:sosp19.pdf
- kfreds 3y ago
  Thank you. Interesting paper! As you've already noted the TKey's KDF is Hash(UDS, Hash(TKey device app), USS), which means every device+application combination gets its own unique key material. As you conclude this means an update to the loaded application changes the key material, which changes any public key the application might derive. This is a hassle and not very user friendly. However, nothing prevents the loaded application (A1) to load another application (A2) in turn. This is a key feature, as it allows A1 to define a verified boot policy of your choice. The immutable firmware would do the KDF using A1's machine code. A1 running accepts a public key, a digital signature and A2 as arguments. A1 measures the public key as context, verifies the digital signature, and then hands off its own contextualized key material to A2. In this example A1 is doing verified boot using some policy, and A2 is the application the end user uses for authentication: FIDO2, TOTP, GPG, etc. Regarding key compromise of the developer's key you might want to look into transparency logs. Another project I'm a codesigner or is Sigsum - a transparency log with distributes trust assumptions. We recently toggled it v1, and it should be small enough to fit into a TKey application. We haven't done it yet though. Too many other things to do. :)
mongol 3y ago
I don't understand the usecase. If the application is loaded from the host, why is this better than the host running the application directly?
- AgentME 3y ago
  The program running on the device is able to access a special Compound Device Identifier secret, which is only available by running that specific program on that specific device. Any different program you run on the device gets its own unique CDI secret, so it's not possible to load a secret-dumper program onto the device and grab the CDI available to a different program. You could use the device to implement a TPM/HSM with application-specific logic, even like a cryptocurrency wallet. A program on the device could be made to generate its own private keypair using the CDI, announce the public key to the connected device, and offer to sign messages using its keypair under some specific conditions enforced within the program.
pierrelf 3y ago
Stoked to see Tkey back on the front page! Bought one when it launched and it's been great fun tinkering with my own apps using their Go library, and the community seems pretty active. Also hardware wise the new injection molded case is a huge step up! I'm really hoping for fully fledged FIDO2 support soon, perhaps on android aswell?
- kfreds 3y ago
  Thank you for your support! I'm pleased to hear you've been tinkering with it. We're working on FIDO2 and will get there one way or another. The current TKey uses CDC ACM as USB device class, which presents some compatibility challenges. I suspect we'll have to change that to USB HID FIDO2, possibly with additional endpoints to simultaneously support loading of applications from the host. We'll get there. :)

204 points by jandeboevrie 3y ago

goodpoint 3y ago

Way too expensive.

SpaceNoodled 3y ago
And they couldn't even put application ROM on there.
rdl 3y ago
Qty 1, $80 seems tolerable for a dev device. They should explicitly list 10 for $500 and 100 for $3000 or something though. This is competing with $5-30K HSMs as well as $30-400 "hardware wallets" or second factor keys, as well as (free) embedded secure enclaves.
rwmj 3y ago
I would guess because of the FPGA. The advantage is it's (somewhat, arguably) more secure than a RISC-V ASIC from some random vendor.
- charcircuit 3y ago
  Do not forget that they also need to recoup the $$$$$ spent getting it certified. For niche electronics this can be a big percentage of the price. Making something into an actual commercial product, especially globally, results in extra markup.

treyd 3y ago

I'm kinda skeptical of security devices like this that don't have their own screens that let you know what you're authenticating. Obviously there's some applications where it's fine but if the PC it's plugged into is compromised it could be MITMing the auth.

gorkish 3y ago
Yes agree the end user needs feedback at the authenticator. This device has an RGB LED and a touch sensor, so there are still some possibilities.
- rdl 3y ago
  I'd put a key inside my app which then talks out of band to multiple devices (including maybe a trusted one?) -- e.g. "run app on the device, request input using the directly-connected PC, message tunneled out to my phone for confirmation") A screen and 2-3 buttons would be nice, though; also a tamper-evident/tamper-responding package. But my main desired use case for this is a lightweight app-specific HSM so I'd just need to validate integrity of device before connecting it to host. USB Armory II is the main alternative.
fmajid 3y ago
Have a look at Bunnie Huang’s Precursor project, but it’s much more expensive.
kfreds 3y ago
It's a trade-off. We've thought about adding a screen to a future product, but it begs the question of how much information you want displayed in order to make your authentication decision. And even if a screen gives you more information, are you authenticating an action where the cryptography terminates in the device? If you are authenticating an SSH session for instance, the screen helps you ensure you are authenticating a login to the right server. Once you have authenticated though, nothing prevents the attacker in your local machine from using the established SSH connection.
- lxgr 3y ago
  Very good point. "What you see is what you sign" is a powerful property, but it does often need some support on the side of the signature verifier to make it possible. Reading through an entire email (maybe MIME multipart encoded) on a small OLED screen isn't fun; on the other hand, something like "confirm transfer of €x to IBAN y from your account z" would be great – but needs support of your bank. That support is incredibly hard to get. Android has supported "protected confirmation" [1] for many years now (on Pixel devices), but I have yet to see support for it by any real-world service I'm using, and I'm not holding my breath, since I can't even use FIDO with any of my banks... [1] https://developer.android.com/privacy-and-security/security-android-protected-confirmation https://developer.android.com/privacy-and-security/security-...

rdl 3y ago

If they could add some hardware tamper-evidence/tamper-response (design-to-meet FIPS 140-3 level 3 or EAL whatever, although no need to actually get certified), this could be super useful as a cheap application-specific HSM (which can run app logic inside, rather than the lobotomized/zombie signing oracle PKCS "HSM" use which is common.) Obviously can prototype without this functionality, and can build out the toolchain/etc. I'm a lot more excited about Tropic Square than most alternatives, but this is shipping now.

kfreds 3y ago
Regarding FIPS 140-2 level 2 tamper evidence and level 3 tamper response I'm interested to hear what you (and others here on HN) value and why. Level 2 can be accomplished with nail polish and glitter, or plastic potting. Yubikey's potting is a good example of level 2 tamper evidence. For level 3 tamper response, e.g. of a rack-mounted server case, it is enough to put micro-switches under the lid. For that type of product level 2 tamper evidence could be accomplished by covering the server case's screws with copper cans stamped with serial numbers. When I first learned what is actually required for FIPS 140-2 level 2 and 3 I thought it was security theater. Then I realized that in practice such a server case will be (1) in a locked server cabinet, in a server room with access control, within a building with access control. Add a two-person requirement for entering the room and unlocking the cabinet, and the attacker will have to be quite sophisticated and capable to not be discovered way before any tamper evidence or tamper response comes into play. In other words, if you don't care about FIPS for regulatory reasons, or insurance reasons, or company policy reasons, then how much does level 3 tamper response really matter? Regarding CC EAL, I'll simply say that I don't believe there is any other hardware security product that is more open source hardware and software than the TKey. Thanks to it being FPGA-based it is somewhat protected from various attacks on the supply chain. If you're looking to do an Ed25519 signature I don't believe there is a single device more simple or easily verifiable than the TKey and it's Ed25519 signer application. I'd love to be proven wrong.
- rdl 3y ago
  I was at ACM Copenhagen although more downstairs at ASHES (which my company sponsored) and DeFi. Ryan Hurst who was there is probably the best person to ask about the specific certification use cases. But overall -- I work for an insurer. Having to document how something was done a year+ after it was done to convince auditors/insurers/large clients is a LOT easier if you can point to a specific piece of hardware vs. a bespoke process. The downside of not having tamper-evidence or tamper-response (ideally) at the hw level is you need to build a lot of other controls around it, and that is expensive, impractical, and difficult to document in a lot of environments. e.g. in a datacenter it's unlikely you can enforce "two man from security/senior executive team in the cage"; it's probably going to be (at best) two ops staff, often contractors, and two-man rule isn't actually that widely used outside CAs themselves. The use cases I'd like for this are application logic, not traditional CAs (who do need FIPS). Add to this lifecycle management of the hardware from production to pickup/delivery to provisioning, pre-deployment storage, deployment, operation, routine audit, replacement, audit, and decommissioning, and it's way easier to put protection into the module. Most of the time I've just seen hardware protection inherited from single-chip vs. module-level protection created, but if there's no certified IC available, module protection it is. Actual FIPS certification would be nice (or a better standard), but challenging in deployment because almost every vendor FIPS certifies with a specific application load and as soon as you run custom applications (which is badly supported in the HSM world), you lose certification anyway. "FIPS rated hardware running a non-FIPS load, audited in appendix A" is insurable, but ideally there would be something better. 99+% of HSM deployments are just used as dumb key signers which are trivially exploitable when you pop the host, though, so I'd certainly take the non-FIPS option. (Today, the state of the art is pretty much SGX or another TEE on the host running custom application logic to evaluate and instruct signing which talks to the FIPS HSM to do key control and actual signing, e.g. what Anchorage does.)

wepple 3y ago

Can anyone comment on the design decision to not store device firmware? Is this common? I would’ve assumed it would generally be safer to have permanent but updatable firmware, to reduce the attack surface of malicious firmware loadings

wepple 3y ago
I guess as a follow-up, you possibly can’t actually “update” firmware for this, without it creating entirely new keys that would have to be registered with every application
- kfreds 3y ago
  You're mostly correct. The immutable firmware derives unique key material for each device+application combination. However, nothing prevents the loaded application from loading another application. This allows the developer to construct their own update logic. For instance, the first application could simply exist to verify a digital signature over some hash, then load an application, hash it, compare it to the trusted hash, and then execute it. The first application could hand over its own key material.
kfreds 3y ago
Sure. Specifically regarding not storing firmware: The TKey does have roughly 6 KB of immutable firmware which is responsible for loading device applications sent by the host. This firmware receives and then hashes the application together with the Unique per Device Secret. The resulting hash is handed to the loaded application as key material, which is now unique per device+application combination. This model doesn't prevent storing applications on the device, but to enable the user to have flexibility to load other apps we would need to change things a bit. Regarding security: This is a question of measured vs verified boot. Until the TKey, users of USB authenticators had to choose between security and flexibility. Yubikey is not updatable at all, but several USB authenticators have updatable firmware using signed firmware updates. Some of them are open source software, and of those a few are open source hardware in the sense that they provide BOM, schematics and PCB design. We do all of the above, and in addition we provide the HDL / "chip design" / FPGA configuration. In any case, having a USB authenticator which is updatable using a signed update begs the question of who is allowed to sign updates, which then leads to central control and a long tail of interesting use cases not being signed. TKey aims to combine security, openness and flexibility. We accomplish this thanks to unconditional measured boot as a KDF, as opposed to verified boot. There is more information on our website.

rwmj 3y ago

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.

kfreds 3y ago
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.
wslh 3y ago

josephcsible 3y ago

> Note well: In the end-user version (not TKey Unlocked) the FPGA configuration is locked down. This means you cannot change the FPGA bitstream or read out the bitstream (or the Unique Device Secret, UDS) from the configuration memory, even if you break the case and insert it into a programmer board. That seems like it's only useful for "security" against the owner, rather than for any legitimate form of security.

AVincentInSpace 3y ago
How so?
- josephcsible 3y ago
  Consider a DRM system that does challenge/response against said secret so that only one computer at a time can use something. As the owner of this device, if I want to clone it, I should be able to.
  - its-summertime 3y ago
    You can buy an unlocked version and clone it, no?
  - charcircuit 3y ago
    But then the device could be used by 2 computers at once defeating the security. Another use case would be as a second factor of authentication. Making it impossible to clone is essential for a "something you own" factor.
FiloSottile 3y ago
That's the whole point of a TKey as a security device: the secret available to an application depends on both the device it's running on and the application, and can't be extracted, so you can do things like "sign a blob only if it follows these rules" and enforce it in hardware. If the device wasn't locked, you could just... change the rules. How is that not a legitimate form of security?

kfreds 3y ago

I created the TKey together with my colleagues. AMA. :)

fsflover 3y ago
How is it better than Precursor? https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.crowdsupply.com/sutajio-kosagi/precursor
- INTPenis 3y ago
  I'm not affiliated with either but I just looked at the precursor page because I'm a huge nerd and love crowdfunded projects. They seem to be in slightly different leagues. Tkey is small and meant to be easily carried with you to authenticate with ssh, gpg and more. While precursor is a full development board that can probably do everything tkey can, and more.
- kfreds 3y ago
  Whether TKey or Precursor is better depends on your needs. Here are some differences between them: * TKey uses open tooling for everything. Precursor uses Vivado. * Precursor has a screen and a keyboard, allowing the user to interact directly with the trusted device in a completely different way than the TKey. * The Precursor is bigger than the TKey. * The Precursor costs much more than the TKey. Finally I'd just like to mentiont that bunnie and xobs work on Precursor as well as their other projects have been a great inspiration to the TKey project.
  - fsflover 3y ago
    Thank you!
- 70rd 3y ago
  Different product at a different price point with different objectives. Security keys are suitable for mass deployment across an entire workforce, precursor aims to be a launchboard for general purpose secure and trustable computation. Even at mass production prices, precursor would likely still cost more than 100$.

7e 3y ago

"There is no way of storing a device application (or any other data) on the TKey. A device app has to be loaded onto the TKey every time you plug it in."

5- 3y ago

hardware wise, looks to be a usbc version of fomu. https://www.crowdsupply.com/sutajio-kosagi/fomu https://www.crowdsupply.com/sutajio-kosagi/fomu

kfreds 3y ago
One major difference between TKey and Fomu is that Fomu uses the ice40 for USB hardware logic as well as USB device firmware. TKey uses a dedicated USB chip (CH552, which comes with open source firmware). Fomu could likely not fit USB logic as well as the security-related cores we have. That, and the fact that we don't want the attack surface of the USB firmware running in the same core that handles the KDF. They are very different products for very different use cases.
- 5- 3y ago
  thanks, that's an important distinction. i like the conceptual purity of fomu, but it does take quite a bit of work to get to the point of talking to it over usb.
  - kfreds 3y ago
    Same here. It was a source of inspiration when we started working on the TKey. Could you expand on what you mean by "take quite a bit of work". I thought Fomu came preconfigured?
    - 5- 3y ago
      yes, sorry, i was referring to writing gateware from scratch. you have to implement a usb device before you get past a blinky.
      - kfreds 3y ago
        Right. Speaking of which, do you have any recommendations for good USB cores?
- 3y ago

anishathalye 3y ago

This is really neat! We've been working on some research to formally verify the hardware/software of such devices [1, 2]. Neat how there are so many shared ideas: we also use a PicoRV32, run on an iCE40 FPGA, use UART for communication to/from the PicoRV32 to keep the security-critical part of the hardware simple, and use a separate MCU to convert between USB and UART. Interesting decision to make the device stateless. Given that the application keys are generated by combining the UDS, USS, and the hash of the application [3], it seems this rules out software updates? Was this an intentional tradeoff, to have a sort of "forward security"? In an earlier project I worked on [4], we had run into a similar issue (no space for this in the write-up though); there, we ended up using the following approach: applications are _signed_ by the developer (who can use any keypair they generate), the signature is checked at application load time, and the application-specific key is derived using the hash of the developer's public key instead of the hash of the application. This does have the downside that if the developer is compromised, an adversary can use this to sign a malicious application that can leak the key. [1]: https://github.com/anishathalye/knox-hsm https://github.com/anishathalye/knox-hsm [2]: https://pdos.csail.mit.edu/papers/knox:osdi22.pdf https://pdos.csail.mit.edu/papers/knox:osdi22.pdf [3]: https://tillitis.se/blog/2023/03/31/on-tkey-key-generation/ https://tillitis.se/blog/2023/03/31/on-tkey-key-generation/ [4]: https://pdos.csail.mit.edu/papers/notary:sosp19.pdf https://pdos.csail.mit.edu/papers/notary:sosp19.pdf

kfreds 3y ago
Thank you. Interesting paper! As you've already noted the TKey's KDF is Hash(UDS, Hash(TKey device app), USS), which means every device+application combination gets its own unique key material. As you conclude this means an update to the loaded application changes the key material, which changes any public key the application might derive. This is a hassle and not very user friendly. However, nothing prevents the loaded application (A1) to load another application (A2) in turn. This is a key feature, as it allows A1 to define a verified boot policy of your choice. The immutable firmware would do the KDF using A1's machine code. A1 running accepts a public key, a digital signature and A2 as arguments. A1 measures the public key as context, verifies the digital signature, and then hands off its own contextualized key material to A2. In this example A1 is doing verified boot using some policy, and A2 is the application the end user uses for authentication: FIDO2, TOTP, GPG, etc. Regarding key compromise of the developer's key you might want to look into transparency logs. Another project I'm a codesigner or is Sigsum - a transparency log with distributes trust assumptions. We recently toggled it v1, and it should be small enough to fit into a TKey application. We haven't done it yet though. Too many other things to do. :)

mongol 3y ago

I don't understand the usecase. If the application is loaded from the host, why is this better than the host running the application directly?

AgentME 3y ago
The program running on the device is able to access a special Compound Device Identifier secret, which is only available by running that specific program on that specific device. Any different program you run on the device gets its own unique CDI secret, so it's not possible to load a secret-dumper program onto the device and grab the CDI available to a different program. You could use the device to implement a TPM/HSM with application-specific logic, even like a cryptocurrency wallet. A program on the device could be made to generate its own private keypair using the CDI, announce the public key to the connected device, and offer to sign messages using its keypair under some specific conditions enforced within the program.

pierrelf 3y ago

Stoked to see Tkey back on the front page! Bought one when it launched and it's been great fun tinkering with my own apps using their Go library, and the community seems pretty active. Also hardware wise the new injection molded case is a huge step up! I'm really hoping for fully fledged FIDO2 support soon, perhaps on android aswell?

kfreds 3y ago
Thank you for your support! I'm pleased to hear you've been tinkering with it. We're working on FIDO2 and will get there one way or another. The current TKey uses CDC ACM as USB device class, which presents some compatibility challenges. I suspect we'll have to change that to USB HID FIDO2, possibly with additional endpoints to simultaneously support loading of applications from the host. We'll get there. :)