Thanks for the feedback. See also comment https://news.ycombinator.com/item?id=39834820
Note that this device is general purpose security device with no persistence. So the requirements were really specific for that reason.
The device I have in mind, primarily, is tillitis' TKey. The TKey does not have persistence, and offers a 32-byte secret value that is deterministically unpredictable (Blake2s) depending on hardware + program-binary + user-supplied-secret. Because of this, you will need TOFU, because you can only know its identity at first run, or its unique secret for that matter. (Of course, if you rely on the device+program, you would need to store the identity public key for subsequent connects.)
Do you still see an opening for a MitM if you assume TOFU works? There is authentication, just not on first connect. I'd be interested in your view on what I missed.
The exfiltration is of course a concern. Part of the prototype I'm doing, is looking into how much we can protect against this. (See also feedback I left to tillitis regarding access to the assigned secret, <https://github.com/tillitis/tillitis-key1/issues/186>.)
Concerning rotations, absolutely correct. Consider though that any change of program-binary or user-supplied secret or device brings its own secret. Note that because of the lack of persistence on the device, a client would store a data, even if only for use within the device.
Note that the secret is determined at every execution as the program-binary loads. The device, TKey, itself is a general RiscV processing unit with device-firmware that initializes a little bit of device and memory, takes the program sent to the device, then starts executing at the program-binary's entry-point.
(1) the tillitis CA certifies your TKey device platform. You can now trust that it's running a specific firmware version with some platform pubkey.
(2) Your custom software is running and derives a keypair from it's derived secret + program binary hash.
(3) Somehow your custom software's pubkey gets locally certified by the platform's pubkey from (1). (not sure what this looks like w/ the TKey)
You now have a chain of trust from (1) the tillitis CA -> (3) the TKey device platform pubkey @ some specific firmware version -> (2) your custom software pubkey @ some specific version.
Now that we have a trusted pubkey for our service, I would open a secure channel to it via Noise IK or something (https://noiseexplorer.com/patterns/IK/). The TKey platform definitely looks a bit anemic so getting this working might be a challenge...
There is a tool to verify if the device is genuine by mechanism of a signature.
You're outlining most of the process. The question is whether avoiding TOFU is the goal, right? I'm thinking, with the physical device in your hands and during first use, it's quite reasonable to establish the identity for your 'program' + 'user-secret'.
> You now have a chain of trust from (1) the tillitis CA -> (3) the TKey device platform pubkey @ some specific firmware version -> (2) your custom software pubkey @ some specific version.
This does mean you make this a global + centralized effort, right? (Also, it creates a dependency.)
> (3) Somehow your custom software's pubkey gets locally certified by the platform's pubkey from (1). (not sure what this looks like w/ the TKey)
With the specific firmware version: this requires a (possibly centralized) certification-process if only for a keypair, or qualification effort (if any) for the program?
To conclude: I am not convinced yet that TOFU is necessarily a bad thing. However, I do appreciate some ability to authenticate over many uses / longer stretches of time. (Hence the key-exchange + authn.)
It seems there is a trade-off here, TOFU can be eradicated but requires other properties/effort. OTOH, the program-specific secret makes for a very strict form of trust. I'll take your comments into consideration, but it seems whichever way one chooses, there is a trade-off to be made.
That's fine. It is indeed possible to perform a check for genuine hardware. (I'm not sure it qualifies as "attestation".) It does not protect you from malicious program-binaries and swapped devices.
Protecting against "swapped devices" is simple: put a secret key in the device, ask it to produce a signature, check it with the public key. Any device other than yours won't know the secret key.
I'm not sure what attacks you refer to when you say "malicious program-binaries". I'm having trouble imagining something fitting this description which is thwarted by the vendor blowing the programming fuse but isn't thwarted by you blowing the fuse yourself.
The comment is meant to separate the hardware from the protections possible in software. TKey provides a unique secret per device, that transforms into a unique secret per (device + program-binary + user-secret). So, protection against swapped device is possible, just not if you simply check if the device is genuine.
Programs are loaded every time the device is connected by transmitting it to the device. So, you could swap the program binary on the computer, and have it send a malicious binary. Again, a unique secret is assigned to a byte-exact program-binary, so this is detected in the process.
(edit: I'm assuming the device contains the original firmware. I'm referring to programs loaded onto the TKey once programmed. Just to check/avoid confusion.)
The device I primarily had in mind is tillitis' TKey. Essentially a general purpose (slow) processing unit. The secret is 32-bytes long and given no storage, that's essentially all you work with. However, the secret is dependent on device + program-binary + 32-byte-user-secret.
A certificate is also a secret + certified public key, right? So, if you cannot store the certification on the TKey (no persistence) than you're left with the same construction. Right now, I'm skipping the complexity of certs (PKCS11, IIRC) etc. The identity being persistent is in order to authenticate the device.
> However, the secret is dependent on device + program-binary + 32-byte-user-secret.
If this is for anyone but yourself, you're going to need a certificate chain. An FPGA like the TKey can also store a significant amount of data in a ROM and you should have no problem storing it.
To check: did you realize that you plug this device in your USB port, then send a program to it, then start using the device with that program loaded? (This is at run-time, every time, right?) Because the secret is generated for this specific combination, different programs will also have different secrets.
I get that you would want to authn the hardware itself. If that is your point, sure, you're right. However, that aims to address a slightly different problem, because then the certificate chain is tied to the hardware only. Note that part of the charm of the _identity_ generated in the program, is that the identity changes if only a single byte of program-binary is different. So it protects from malicious binaries too. (But not bugs in the program itself.)
1. Be thorough. Be sure you fully understand the issue, instead of jumping to conclusions.
2. Keep asking 'why'. Make sure you understand what the problem (or rather the requested feature) is, instead of being able to parrot what someone else says the problem is. (Even if the conclusion ends up being the same, you need the gained comprehension to determine the right solution.)
3. Separation of concerns. Keep practicing on separating orthogonal concerns that are all seemingly relevant to a problem. Evaluate each concern separately. Drop any of the concerns that are irrelevant in solving the solution. This can save you huge amounts of time, enough to make a deadline you would otherwise never make. (This will also help you to reduce the amount of added complexity.)
- 2019-04-18: Ola Bini's statement, from arbitrary detention, statement discussed in an article. [10]
- 2019-04-16: Ola's parents are able to visit him in prison, Ola has been getting threats in prison. [11]
- 2019-04-16: Press conference organized for parent and lawyer to give updates concerning Ola's situation.
- 2019-04-16: Ola's detention is full of irregularities, as concluded by his lawyers. [12]
- 2019-04-15: Ola's parents on their way now to Quito, address press in Quito.
- 2019-04-15: Charges against Ola Bini are known, judge orders preventitive detention, Ola's lawyers file appeal.
- 2019-04-14: many news sites, communities and research group find out about Ola's detention. Opinions and statements get published in support. (See FreeOlaBini.org)
- 2019-04-12: Ola has finally been able to speak with lawyers, after being detained for 17 hours.
- 2019-04-12: Friends, colleagues start discovering about his detainment. The statement issued by his employer. First news reports. [13]
- 2019-04-11, 15:20h local time: Ola Bini arrested at Quito airport in Ecuador. (Martin Fowler [14])
- 2019-04-11: First signs of trouble, already identified by Ola himself. [15]
- 2019-04-10: Ola announcing his flight to Japan, which was already known 2 weeks prior. This trip will later be explained as "Ola fleeing Ecuador" after Ola has been detained.
