|
|
|
|
|
by sitharus
659 days ago
|
|
> Could the protocol have been better designed to resist this local cloning attack? I don't see how, the attacker is cloning the secrets used to sign the request, if they have those secrets there's no way of distinguishing the clone from the original device. The whole security model of secure elements is preventing the keys from being extracted, if you can do that there's no more security than saving the key to a file on your computer. Of course to get the key they need to physically open the device, so unless someone actually takes your key it's more secure than saving them on you computer. |
|
These would be stored by the device and combined with the next sessions' request data before signing. The login site does it's own combining before checking the signature.
This way any clone usage would be obvious. If the attacker uses the clone before you, your key wouldn't work for that site anymore. The site could even warn you if it keeps track of previous values.
Likewise it limits the timeframe the attacker can use the clone.
I guess even just 16 bits of data should make it quite resistant to guessing by the attacker.
This requires some non-volatile storage to keep the "future bits", but at 16 bits you can do quite a few logins before having to do a single page erase.
Then again, not my field so perhaps there's something I'm missing.