Proposal: Describe and monitor known security risks #87

New Issue

2025-01-17T04:54:50+08:00

erikschul commented

2025-01-17 04:54:50 +08:00

(Migrated from github.com)

I've looked into many different devices, and they all seem heavily overpriced (e.g. 50-70 USD or more), or have firmware issues.
I think your project is very relevant, especially with devices costing 10 USD, which might provide sufficient protections (e.g. OTP).

But as a user of this project, it is hard to gauge the risks.

I therefore propose that the website/github README is more forthcoming about what investigations you have done, and which protections are believed to work correctly, as well as way of being alerted if that changes, since the security is so central to the projects purpose.

For example, my sole motivation for using a security key is to protect against digital theft, e.g. malware stealing ssh keys.
Therefore, it is also critical that a security key cannot have its secrets stolen via USB.
Vulnerabilities related to physical tampering are acceptable to me.
But USB-related vulnerabilities aren't.

For example, you added this feature. And the feature list on the github readme is long.

But I was hoping for more like a table that lists common attacks and whether various hardware (RP/ESP32 chips) + this software project are thought to be safe against those attacks. And for example whether the announced RP2350 attacks could possibly leak the secrets over USB.

Another point is that open source benefits from these open conversations, much better than we can expect from big corporations who have strong incentives to keep vulnerabilities secret.

Thanks!

I've looked into many different devices, and they all seem heavily overpriced (e.g. 50-70 USD or more), or have firmware issues. I think your project is very relevant, especially with devices costing 10 USD, which might provide sufficient protections (e.g. OTP). But as a user of this project, it is hard to gauge the risks. I therefore propose that the website/github README is more forthcoming about what investigations you have done, and which protections are believed to work correctly, as well as way of being alerted if that changes, since the security is so central to the projects purpose. For example, my sole motivation for using a security key is to protect against digital theft, e.g. malware stealing ssh keys. Therefore, it is also critical that a security key cannot have its secrets stolen via USB. Vulnerabilities related to physical tampering are acceptable to me. But USB-related vulnerabilities aren't. For example, you added [this feature](https://github.com/polhenarejos/pico-fido/issues/62). And the feature list on the github readme is long. But I was hoping for more like a table that lists common attacks and whether various hardware (RP/ESP32 chips) + this software project are thought to be safe against those attacks. And for example whether the announced RP2350 attacks could possibly leak the secrets over USB. Another point is that open source benefits from these open conversations, much better than we can expect from big corporations who have strong incentives to keep vulnerabilities secret. Thanks!

polhenarejos commented

2025-01-17 19:51:14 +08:00

(Migrated from github.com)

These are security barriers to make it harder. I cannot ensure you that the firmware has not any vulnerability. I am meticulous by analyzing it through security tools, preventing stack overflows or memory corruptions that might lead to an accidental key exposure.
Doing a USB attack is really hard. Assuming your computer has been infected by a malware, it should be able to send USB packets (easy) in such a way that exploits some vulnerability in my code. However, this is not trivial. The keys are encrypted in the flash memory and are only decrypted when they are used. The process is like this:

You introduce the PIN. The hash of this PIN is saved in the RAM, so an attacker is not able to recover the PIN even in the case is able to dump the RAM.
Keys are stored in flash encrypted by a double hash of the PIN.
On a signature, after the security checks, the hash of the PIN resident in the memory is hashed again to decrypt the master key of the device.
This master key is used to decrypt the targeted key you are invoking.
The signature is performed.
Immediately, after the signature, the RAM region where the key is stored is cleared, even before outputting the result (OK or KO).

An attacker should be able to stop the program in between the signature and memory clear by injecting/corrupting the stack via USB packet injection in such a way that the program jumps to another region of the memory to output the key.
Furthermore, when the stack is corrupted is detected by the program after returning the function, so it usually crashes. I cannot ensure 100% it is impossible but you can figure out the difficulties.

I wouldn't be worried about USB hijacking. The weakest part is when you loose the Pico device or it's stolen. Then you must assume your keys have been compromised and exposed.

These are security barriers to make it harder. I cannot ensure you that the firmware has not any vulnerability. I am meticulous by analyzing it through security tools, preventing stack overflows or memory corruptions that might lead to an accidental key exposure. Doing a USB attack is really hard. Assuming your computer has been infected by a malware, it should be able to send USB packets (easy) in such a way that exploits some vulnerability in my code. However, this is not trivial. The keys are encrypted in the flash memory and are only decrypted when they are used. The process is like this: - You introduce the PIN. The hash of this PIN is saved in the RAM, so an attacker is not able to recover the PIN even in the case is able to dump the RAM. - Keys are stored in flash encrypted by a double hash of the PIN. - On a signature, after the security checks, the hash of the PIN resident in the memory is hashed again to decrypt the master key of the device. - This master key is used to decrypt the targeted key you are invoking. - The signature is performed. - Immediately, after the signature, the RAM region where the key is stored is cleared, even before outputting the result (OK or KO). An attacker should be able to stop the program in between the signature and memory clear by injecting/corrupting the stack via USB packet injection in such a way that the program jumps to another region of the memory to output the key. Furthermore, when the stack is corrupted is detected by the program after returning the function, so it usually crashes. I cannot ensure 100% it is impossible but you can figure out the difficulties. I wouldn't be worried about USB hijacking. The weakest part is when you loose the Pico device or it's stolen. Then you must assume your keys have been compromised and exposed.

👍 3

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dearsky/pico-fido#87