31–40 of 123 posts
It strikes me that open source hardware should be more common. It's surely much easier to monetise than open source software: you just sell the hardware, because noone wants to build one themselves. Why isn't it?
Mullvad means mole (for the tunnelling more than planted spy connotations, hopefully), and the "Tillit" part of the name means trust.
They're working on some IKEA style naming, which I enjoy.
It strikes me that open source hardware should be more common. It's surely much easier to monetise than open source software: you just sell the hardware, because noone wants to build one themselves. Why isn't it?
It's almost certainly a good time to update https://lwn.net/Articles/736231/
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 ?
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.
(Full disclosure: I'm Fredrik Stromberg, cofounder of Mullvad VPN and co-designer of Tillitis Key)
I'm not sure what problem this solves. I see per-application keys based on the hash of the application, but wouldn't this prevent updates of those applications without key loss? It's clear to me that this device can be used for _some_ kind of cryptographic operation/verification mechanism, but I'm at a loss for what problem this is actually designed to solve. What's the practical application of this key?
Also the fact it doesn't emulate smartcard means every single software supporting it would have to make a special client so yeah, that's a problem.
"Just" smartcard allows for at the very least GPG signing and SSH agent without much fuss, and also HTTPS client cert auth
The name sounds like a disease.
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 ?
According to [1] > 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 t…
* And if you revert back to A, those saved secrets will still be there.
What stops app B from pretending it's an app A ?
I'm not sure what problem this solves. I see per-application keys based on the hash of the application, but wouldn't this prevent updates of those applications without key loss? It's clear to me that this device can be used for _some_ kind of cryptographic operation/verification mechanism, but I'm at a loss for what problem this is actually designed to solve. What's the practical application of this key?
It's OK to say this has a serious limitation in that it can't easily support updating applications, but that hardly rules out it being useful at all.