Hacker News new | past | comments | ask | show | jobs | submit login

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 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.

[1] https://www.tillitis.se/




* 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.

What stops app B from pretending it's an app A ?


1. The hardware contains a UDS (unique per device secret) which can only be read once per boot cycle.

2. Firmware in ROM does unconditional measurement of the first mutable boot stage, which is loaded from the host, over USB.

The KDF used for measurement is Blake2s(UDS, Blake2s(application), USS).

Note that when I say hardware I mean FPGA hardware design.


Again, what stops malicious app B from just taking the A's id and presenting it to device ? token doesn't know who sent USB packet


I'm not sure I understand your question.

If you're asking about applications running on the device (Tillitis Key) the answer is measured boot. You can read more on tillitis.se.


I think the app is installed on the stick itself, kind of like how you install coin apps on a Ledger.


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.


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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: