You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I fail to see how this proves to me, that a device was not tampered with during shipping?
Because this is what your lingo suggests.
From your description, this is a TOFU scheme that is intended to provide continuity from the first "verification" onwards.
This hinges on your fpga architecture being inside the physical object as described.
A faked device could emulate this behaviour.
Am I wrong?
The text was updated successfully, but these errors were encountered:
It's correct that tkey-verification doesn't verify device integrity. The program doesn't verify the entire FPGA bitstream. It does, however, verify the Unique Device Secret part of the bitstream.
tkey-verification verifies that running a particular device app on the TKey gives the same identity on this particular TKey now as it did when we provisioned it. It also verifies that in the same part of the memory map as expected the same firmware is present. That's all it does. If that isn't clear from the README we should update it.
I think I made it pretty clear in this talk at sec-t:
I fail to see how this proves to me, that a device was not tampered with during shipping?
Because this is what your lingo suggests.
From your description, this is a TOFU scheme that is intended to provide continuity from the first "verification" onwards.
This hinges on your fpga architecture being inside the physical object as described.
A faked device could emulate this behaviour.
Am I wrong?
The text was updated successfully, but these errors were encountered: