Hacker News Reader

Comment by jeroenhd | Hacker News Reader

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?

View on HN

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.

You can read more on tillitis.se or in the comment I made below.

Tillitis Key will allow you to chain-load applications. This means that you could have a thin loader which does code signing verification of the next application stage, and hand off the secret to it. Basically it's a trust policy that defines under what circumstances the next application stage gets the secret.

Another trust policy the loader could have is requiring m-of-n code signatures, or perhaps that as well as transparency log inclusion. Check out sigsum.org.

This comment explains it: https://news.ycombinator.com/item?id=32897307

The app key would need to stay the same, but I can't think of a mechanism that would deny one app trying to pretend it's another.

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

I believe the only thing needed is someone writing a PKCS #11 driver for it, then it should be interoperable.

We used to use the same version of applications for years.

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.

Reply on news.ycombinator.com