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. During use firmware on Tillitis Key derives a unique key for each application it runs by measuring it before execution. This is done by combining an application’s hash value with a unique per device secret. Applications are loaded onto the device from the host computer during use, and are not stored persistently on the device.
A user- or host-supplied secret can also be mixed into the key derivation function, providing further protection. A sophisticated physical attacker should be assumed to have knowledge of the target application’s hash, and will likely eventually succeed in extracting the UDS from the hardware. By adding a host-supplied secret, knowledge of the application used as well as the security key’s UDS is not sufficient to produce the application secret. This makes the security impact of a lost or stolen Tillitis Key less than for conventional security keys.
Device applications can be chain-loaded where the first application stage hands off its secret to the second stage. This improves user experience as it makes it possible for the application secret (and its public key) to remain the same even if a device application is updated. It also enables developers to define their own software update trust policies. A simple first-stage application might do code signing verification of the second stage, whereas a more advanced one will require m-of-n code signatures, or a Sigsum inclusion proof. Sigsum was designed with embedded use cases in mind.
Tillitis Key is and always will be open source hardware and software. Schematics, PCB design and FPGA design source as well as all software source code can be found on GitHub.
> The DICE Architectures Work Group is exploring new security and privacy technologies applicable to systems and components with or without a TPM. The goal is to develop new approaches to enhancing security and privacy with minimal silicon requirements. Even simple silicon capabilities combined with software techniques can establish a cryptographically strong device identity, attest software and security policy, and assist in safely deploying and verifying software updates.
So basically a pluggable HSM? Curious if this should be considered more similar to the Yubi HSM 2 [0] (think dedicated HSM, not very useful for anything else but very secure) or the USB Armory [1], very adaptive small arm SBC with a USB port? (for this thread option 3 - more similar to a bone stock Yubikey?)
Also curious if there are plans to support BLS signatures natively?
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.
Ah, so for example challenge-response/public key? The first stage knows the second stage’s public key, and can verify that it knows the private key.
That would make it less secure ("only" as secure as the private key), which is the trade-off the developer made in exchange for an upgradable app, correct?
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?
> 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?
> The things you have listed are indeed very nice, but they are not new kind, as they are available elsewhere.
Really? I wasn't aware that there is another USB security key with measured boot-based key derivation. Please provide a link!
> Can you give a bit more compare and contrast to the original question?
Except for Tillitis Key, all USB security keys I'm aware of either boot any software, or only boot software that has been signed with a key pair. Tillitis Key is different in that it measures the application, and uses that measurement to derive a secret specific to the application as well as the stick it's running on.
No, the integrity is within the device. You load the small (64k) apps onto the key and the content of the apps with the unique key for the device can be used by the app to perform cryptography and their integrity can be audited. This is similar to JavaCard with cryptographic integrity of the applets. Read more at: https://github.com/tillitis/tillitis-key1/blob/main/doc/syst...
> 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.
> 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. During use firmware on Tillitis Key derives a unique key for each application it runs by measuring it before execution. This is done by combining an application’s hash value with a unique per device secret. Applications are loaded onto the device from the host computer during use, and are not stored persistently on the device.
So the idea here is:
* General purpose, reprogrammable security coprocessor
* If you save secrets with application A, then install evil application B, it can't access the secrets from A.
* And if you revert back to A, those saved secrets will still be there.
* Therefore, it's more practical to run two different applications - and safer to experiment with your own applications, because you won't lose all your website logins.
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.
Something like 'Secure Boot' / 'Measured Boot' on modern PCs, I imagine.
A bootloader will checksum the current application before running it, checking its digital signatures and version and whatnot, and deriving an encryption key based on that.
(For full disclosure I am the primary FPGA designer of TillitisKey.)
It also perform a measurement of the application being loaded. And the measurement together with the Unique Device Secret (UDS) will generate the primary secret applications can use to derive keys etc it needs. This means that you can verify the application integrity.
For now, yes. But as Fredrik (kfreds) has written in another comment. What is possible to do is a two stage approach with an application (which gets measured) loading other applications.
Yes. The hash of the application code and the 256 bit Unique Device Secret is hashed to generate a primary secret, which then the application can use to derive the secrets it needs.
You can additionally supply a secret from the host (the User Supplied Secret). This means that the keys generated are tied to the specific device (the UDS), that the integrity of the application is correct, and to you as a user.
It's the same as "Google Authenticator" being used instead of TOTP. I think it's reasonable for apps' documentation to meet users on their turf to aid understanding.
This is because the fido2 libraries follows a lot of defacto standardisation: either to match yubikey or windows hello as the only real implementations in the wild. Fido2 ctap extensions would support all the use cases of the new device except you won't be able to use them e.g. in windows because vendors are ignorant about all the openess to push their own agenda.
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. During use firmware on Tillitis Key derives a unique key for each application it runs by measuring it before execution. This is done by combining an application’s hash value with a unique per device secret. Applications are loaded onto the device from the host computer during use, and are not stored persistently on the device.
A user- or host-supplied secret can also be mixed into the key derivation function, providing further protection. A sophisticated physical attacker should be assumed to have knowledge of the target application’s hash, and will likely eventually succeed in extracting the UDS from the hardware. By adding a host-supplied secret, knowledge of the application used as well as the security key’s UDS is not sufficient to produce the application secret. This makes the security impact of a lost or stolen Tillitis Key less than for conventional security keys.
Device applications can be chain-loaded where the first application stage hands off its secret to the second stage. This improves user experience as it makes it possible for the application secret (and its public key) to remain the same even if a device application is updated. It also enables developers to define their own software update trust policies. A simple first-stage application might do code signing verification of the second stage, whereas a more advanced one will require m-of-n code signatures, or a Sigsum inclusion proof. Sigsum was designed with embedded use cases in mind.
Tillitis Key is and always will be open source hardware and software. Schematics, PCB design and FPGA design source as well as all software source code can be found on GitHub.
https://www.tillitis.se
https://github.com/tillitis/
(Full disclosure: I'm Fredrik Stromberg, cofounder of Mullvad VPN and co-designer of Tillitis Key)