Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tillitis Key – Mullvad spin-off inspired by measured boot and DICE

tillitis.se

Post reply on HN
Print view View original

101–110 of 123 posts

Re: Tillitis Key – Mullvad spin-off inspired by measured boot and DICE

#101

Post by Perseids »

dbrgn wrote: post #74

Are you aware of Trussed, an initiative by SoloKeys and Nitrokey? https://solokeys.com/blogs/news/trussed-announcement / https://trussed.dev/ From what I understand, this is an API to write applications against a common interface, which can run on different hardware devices. An abstraction layer for security key apps. Similar to Java Card, but in a more modern way. Is this something that would or could be compatible…

A bit off-topic: Can anyone recommend a platform that is production ready today, if I want to (develop and) deploy a custom Smartcard / HSM application in small scale? JavaCard seems to fit the bill, but I've not yet found an approachable tutorial.

Re: Tillitis Key – Mullvad spin-off inspired by measured boot and DICE

#102

Post by MaKey »

mwcampbell wrote: post #52
kfreds wrote: post #35

Earlier quoted context omitted.

The Tillitis Key is a new kind of USB security key inspired by measured boot and DICE. Tillitis Key’s design encourages developers to experiment with new security key applications and models in a way that makes adoption easier and less risky for end-users. It offers both security and flexibility by being end-user programmable while also preventing applications loaded onto the device from knowing each other’s secrets.…

IIUC, popular security key devices like the YubiKey securely store a private key, but only allow it to be used for specific authentication applications (e.g. OTP or U2F). Would the Tillitis Key be able to securely store a private key, then with appropriate authentication from the host, use that key for encryption and decryption?

Devices like the YubiKey can also be used for encryption (e. g. with LUKS or OpenPGP), digital signatures and SSH authentication.

Re: Tillitis Key – Mullvad spin-off inspired by measured boot and DICE

#103

Post by craggyjaggy »

xani_ wrote: post #85
timando wrote: post #50

Earlier quoted context omitted.

It would have to hash to the same value as app A

The device is not checking app's hash tho, it has no way to verify that the usb frame containing that hash is really from app A

The app runs on the USB device. The code is loaded from the host, and if it hashes to the correct value, it will be able to access the secrets on the Tillitis.

Re: Tillitis Key – Mullvad spin-off inspired by measured boot and DICE

#104

Post by Semaphor »

kfreds wrote: post #35
Havoc wrote: post #4

Am I right in thinking that this is basically like a yubikey except with openness as key differentiator? Or is it’s function something else ?

The Tillitis Key is a new kind of USB security key inspired by measured boot and DICE. Tillitis Key’s design encourages developers to experiment with new security key applications and models in a way that makes adoption easier and less risky for end-users. It offers both security and flexibility by being end-user programmable while also preventing applications loaded onto the device from knowing each other’s secrets.…

One question, with the two-stage approach, isn’t that a security risk? App 1 gets measured and can’t change, but it needs to identify app 2 in a way that still allows it to be updatable, invalidating the whole security chain.

I’m probably not understanding something, so I’d love an explanation (preferably one that non-cryptographers understand)

Re: Tillitis Key – Mullvad spin-off inspired by measured boot and DICE

#105

Post by VTimofeenko »

irusensei wrote: post #63

Quick question about such devices: can I use stuff like Yubikey or similar to luksOpen a crypt device during boot or operation? Thanks in advance.

Yes, there's multiple ways. Systemd offers systemd-cryptenroll that works with FIDO2 and X509 certificates on the hardware key to unlock a drive.

The key is embedded as a luks header into the partition.

The information about the key and the device is passed to initrd through /etc/crypttab for unlocking during boot.

I wrote a couple of posts describing how this can be sort-of-handrolled with nitrokey and gpg key for x509 cert:

https://vtimofeenko.com/posts/unlocking-luks2-with-x509-nitr...

Re: Tillitis Key – Mullvad spin-off inspired by measured boot and DICE

#107

Post by JoachimS »

AviKav wrote: post #99
kfreds wrote: post #35

Earlier quoted context omitted.

The Tillitis Key is a new kind of USB security key inspired by measured boot and DICE. Tillitis Key’s design encourages developers to experiment with new security key applications and models in a way that makes adoption easier and less risky for end-users. It offers both security and flexibility by being end-user programmable while also preventing applications loaded onto the device from knowing each other’s secrets.…

> A user- or host-supplied secret can also be mixed into the key derivation function To clarify, this secret does not affect the program's hash, right? (e.g. to prove liveness, the parameter is a nonce to be signed with a deterministic private key)

No, the USS would be used (mixed in as kfreds stated) during the hash operation. So the hash result would be based in (1) the hash of the application, (2) the unique device secret, and (3) the user supplied secret. The result is called Compound Device Identity in DICE parlance. And is basically

CDI = Hash(UDS, Hash(application) + USS)

If the application would use the result (called CDI - Compound Device Identity in DICE parlance) to derive a pair of keys, the keys would thus be based on the hardware (the specific device you have), the integrity of the application and what you know.

Re: Tillitis Key – Mullvad spin-off inspired by measured boot and DICE

#108

Post by kfreds »

Semaphor wrote: post #104
kfreds wrote: post #35

Earlier quoted context omitted.

The Tillitis Key is a new kind of USB security key inspired by measured boot and DICE. Tillitis Key’s design encourages developers to experiment with new security key applications and models in a way that makes adoption easier and less risky for end-users. It offers both security and flexibility by being end-user programmable while also preventing applications loaded onto the device from knowing each other’s secrets.…

One question, with the two-stage approach, isn’t that a security risk? App 1 gets measured and can’t change, but it needs to identify app 2 in a way that still allows it to be updatable, invalidating the whole security chain. I’m probably not understanding something, so I’d love an explanation (preferably one that non-cryptographers understand)

> One question, with the two-stage approach, isn’t that a security risk? App 1 gets measured and can’t change, but it needs to identify app 2 in a way that still allows it to be updatable, invalidating the whole security chain.

It doesn't invalidate it if it works as the application developer intended. The essential idea is that the first mutable boot stage contains a trust policy which somehow verifies the second stage. Let's say that's a valid signature over the hash value of the second mutable stage. The trusted public key in contained in the first stage.

What we've done there is first used measured boot, and then verified boot.

Measured boot is basically load-hash-measure-execute, where "measure" means "store the hash value of whatever I'm about to execute somewhere safe where the soon executed thing won't be able to undo my storing of its hash".

Verified boot on the other hand is about verifying the next stage and only execute it if it verifies as valid by the trust policy.

> I’m probably not understanding something, so I’d love an explanation (preferably one that non-cryptographers understand)

Honestly I'm beginning to realize it's not all that simple to explain.

Re: Tillitis Key – Mullvad spin-off inspired by measured boot and DICE

#109

Post by kfreds »

fleventynine wrote: post #97

From the photo, that looks like a stock iCE40 FPGA, which does not support hardware attestation of the loaded bitstream. How does the user verify that the FPGA loaded the expected bitstream instead of something with a backdoor? A DICE chain that is not rooted in physical, immutable hardware isn't very useful.

> From the photo, that looks like a stock iCE40 FPGA, which does not support hardware attestation of the loaded bitstream.

Which FPGA models support _attestation_ of the loaded bitstream? Do any?

> How does the user verify that the FPGA loaded the expected bitstream instead of something with a backdoor?

It's a Lattice ice40up5k, which contains a programmable and lockable NVCM memory in-package. The engineering samples we handed out today at OSFC store the FPGA configuration bitstream on a SPI flash memory though.

> A DICE chain that is not rooted in physical, immutable hardware isn't very useful.

When we start selling them we'll likely sell both security keys with pre-provisioned bitstreams in NVCM as well as unprovisioned security keys so you can provision your own.

Re: Tillitis Key – Mullvad spin-off inspired by measured boot and DICE

#110

Post by kfreds »

filleokus wrote: post #72

Cool! Always nice to see extra competition in this space. One thing I've wanted for a while is a way to properly backup a webauthn token. An approach I discussed a couple of weeks ago [1] was: 1: Generate on-hardware webauthn master key on device A. 2: Generate on-hardware key-pair on device B 3: Export B’s public key, import to A 4: On Device A: Encrypt master key with B’s public key 5: Export encrypted master key t…

Hi! Interesting. Which company do you work for?

Yes, that'd be possible. I don't know how webauthn works, but if it relies on ECC you could probably do ECDH between all security keys you wanted to carry your master key, and then use the combined ECDH values as the master key.

Post reply on HN