Authorization mechanism is vulnerable to CRC32 collisions about nitrokey-pro-firmware HOT 3 CLOSED

The Nitrokey is not supposed to be secure agains MITM attacker on the USB connection. This is the same as with local smart cards which receive the PIN in cleartext.

AFAIK the idea of the temporary password is to minimize the time the actual PIN needs to be available (stored in RAM) on the client computer. But this would come as a bonus and doesn't provide guaranteed security (in case of malware for instance).

from nitrokey-pro-firmware.

I'm still not quite understanding the design here.

Yes, the idea with the temporary password to protect the pin makes a lot of sense. What I find surprising is to have both the authorization via temp password and then getting the code using a command with the authorized CRC as a two step process.
Transmitting the password as part of GET_CODE would be sufficient. Why the detour using the CRC32?

The USER_AUTHORIZE detour in the protocol still makes this vulnerable, even without MTIM, because the CRC32 of authorization requests is fairly predictable. The attacker doesn't need to be a MITM.

A possible mitigation strategy would be to fill the GET_CODE command with random data in the unused bytes. That would protect against faked GET_CODE commands with up to 32bit entropy.

However, 32bit is still not all that much, especially given the fact that using the 200bit password directly would provide much more security while simplifying the protocol quite a bit.

from nitrokey-pro-firmware.

I would like to note that the audit of the storage firmware notes the same issue (fixed in Storage firmware): "NK-01-007 OTP commands can be used without authorization"
The described attack is a little more straightforward than what I had in mind (wish I would have thought of their example...), but the underlying issue is the same (reversibility of CRC32).

The suggested fix is also the same: "It is recommended to send temp_user_password with every report that requires it and remove the CRC32 code."

I think this can be fixed in a backwards compatible manner if the app just does both and USER_AUTHORIZE does nothing in the fixed firmware. Just in case you want to avoid bumping the version (sounds like a bad idea though imo).

from nitrokey-pro-firmware.