Hardware question

[erikschul]

Thanks for a very relevant project!

I have a few concerns about the hardware.

• Do I understand correctly that the ESP32-S3 has wifi/bluetooth but the RP2350 does not? Is that significant? Could the hardware be malicious, ignore the program, and activate radio anyway? Such that the RP2350 is much safer?
• What's the difference between N16R8 and N8R2 (ESP32-S3), and are they compatible?
• Are the pins necessary, or is all programming done over USB? (I'd like a tiny device without pins)
• How fast do they perform FIDO2 signing (ecdsa)? I saw the HSM page was describing operating times of 4-1000 seconds, so I just want to be sure.
• Have you experimented with enclosing it in epoxy or similar to make it more physically resistant / portable?

[polhenarejos]

• It's hard to say. If an attacker is able to make a malicious hardware, then you can assume whatever you want. If we assume a legit MCU, Pico Fido doesn't need the radio for anything. There's no single line in the code related with Wifi/BLE. So, even if the radio is not fully turned off, Pico Fido will not listen/handle any packet at all. I wouldn't say RP2350 is much safer than ESP32-S3. 10 days ago it was discovered a vulnerability that allows to access to secrets in the OTP. Pico Fido relies on the PIN introduced by the user and leverages the security aspects to the user, but you can figure out what is happening in the hardware world.
• N16R8 has 16 MB flash and 8 MB RAM; N8R2 has 8 MB flash and 2 MB RAM. Pico Fido works well in both.
• PINs are not used. All communication is done by USB.
• I didn't make any benchmark. But for normal use is fine. If you need todo intensive tasks of signing, then the numbers probably will not be impressive.
• I heard some projects that enclosed it but I didn't follow them. I like tiny/mini boards without PINs, just USB.

[erikschul]

I just read the report, although the consequences are not entirely clear to me. A physical attack (evil maid) is hard to protect against, but the use case I'm trying to protect against is specifically digital theft of keys.

By issuing a normal reboot command to the USB bootloader, and injecting a fault (in this case by glitching the supply voltage) so that an instruction is skipped just at the right time, it is possible to trick the reboot API into believing that REBOOT_TYPE_PC_SP was requested.

IIUC, there is an attack that loads a new firmware, but it requires manipulation of the port voltage, which isn't normally possible when connected to a PC?

IIUC, malware overwriting the existing firmware would require physical interaction with the BOOT button?
In this case, would it make sense to use a different button, so that the BOOT button is only ever used when intentionally flashing new firmware?

I was thinking if it would be possible to add capacitative touch sensing. IIRC, I did that many years ago with an Arduino Uno sensing analog voltage.
This would also allow the device to be fully encased, having one or two wires sticking out that can be pressed.

But for normal use is fine.

Sorry for repeating the question: is it as responsive as any other FIDO2 key (like 1 second), slightly slower (1-2 seconds), or significantly slower (e.g. 4 seconds).

[polhenarejos]

All the vulnerabilities put in common the fact that a physical access and a manipulation is needed. If you loose your device or it stolen, then you must assume your keys have been exposed and should be revoked as soon as possible. Therefore, you must keep your device with you all the time. You cannot leave it unattended. If you have your device with you all time, then your keys are safe, at least at the present.

I didn't measure or compare the time with other keys but the response is fast, at least for the price you are paying.