6 ms·
* 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 secre
by xani_ 4y ago
* 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 ?
- michaelt 4y agoSomething 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.
- kfreds 4y ago1. 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.
- xani_ 4y agoAgain, 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
- stavros 4y agoI think the app is installed on the stick itself, kind of like how you install coin apps on a Ledger.
- kfreds 4y agoI'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.
- timando 4y agoIt would have to hash to the same value as app A
- xani_ 4y agoThe 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
- craggyjaggy 4y agoThe 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.
- deleted 4y ago[deleted]