pull down to refresh
Coming back to this, because my answer above was too vague. I've written up a proper threat model since:
https://github.com/ndssigner/nds-signer/blob/main/docs/threat-model.md
The honest answer to "weakest part": what runs before NDS-Signer (DSi firmware, Unlaunch, TWiLight Menu++, all from the SD card), which it can't verify. After that, the QR decoding in C, which hasn't been fuzzed yet, and the scribble + mic entropy, which has no measured number. Dice are the safe option for now.
I opened issues for each of these: https://github.com/ndssigner/nds-signer/labels/audit
Also, the demo video is on Odysee now instead of mega: https://odysee.com/@ndssigner:9/nds-signer-demo:2
Thank you for your comment.
There are some threat vectors like the following:
- The ROM is launched by an external bootloader. It is the current standard for the nds homebrew scene.
- The NDS itself embeds a WiFi module.
As long as the user downloads the official ndssigner.nds ROM properly checked against its SHA256 signature, the threats above are minimal: the software switches off the WiFi module, it does not store any permanent data and the RAM is wiped out before the console switches off.
Unlike smartphone apps or computer software, NDS does not use any upper layer acting as OS. It is not multitasking. The software running goes on its own, so, in that sense, the direct access to the hardware provides an additional security feature.
QR parsing is slow compared with modern hardware (phone cameras, etc) but it works. Occasionally some adjustments are necessary, like changing the brightness of the QR emitting screen (sometimes darker is better to compensate the exposure of the camera). Another sacrifices have been made to allow a faster detection: weird angles are not easily recognized by the software.
As for the entropy, it implements almost the same entropy generation sources from SeedSigner: dices and camera signal. The second one is a variation from SeedSigner's original code, made in order to fit NDSi's hardware limitations. Additionally, a nds-signer's "proprietary" (its opensource) entropy generator has been implemented: mic input + scribbling over the touch screen.
Nevertheless, entropy generation is used only in two cases: brand new seed generation and, with a simplified method using only mic input, PIN generation for seed backup/exchange via DTMF (telephone tones).
This document explains the actual motivations for this project, focused basically on the thread models of legacy systems. The purpose of nds-signer is to enable cheap vintage hardware to become a SeedSigner and, most importantly, to go unnoticed, not only against the $5 wrench attack but also against screenings (airports, etc).
The “going unnoticed” aspect is probably the most interesting part of this project. A Nintendo DSi looks far less like a Bitcoin signing device than a dedicated hardware wallet.
The main thing I’d still want to understand is the bootloader trust model. Even if the ndssigner ROM itself is verified by SHA256, how much does security ultimately depend on the external bootloader being trustworthy and untampered with?
For a device intended to cross borders unnoticed, that seems like one of the most important parts of the threat model.
This is a really clever use of old hardware, especially the idea of making the device look like an ordinary DSi.
For real-world use, what do you consider the weakest part of the threat model: the DSi hardware itself, the QR parsing, or the entropy generation?