I wanted to find out how hard it is to manipulate the @SeedSigner
. It was easy as expected. Never give it out of hand! Simple swap to a manipulated sd-card and it logs your seed to it. Later the attacker can collect the sd-card and get your seed words.
Total lines added to the code are six.
Needless to say, it writes the seed also to sd-card if you scan your backup seed.
There is a easy way to prevent this type of attack. Just remove the sd-card after booting the device.
#[3] #[4] this looks like a great reason to implement that feature where the option screen won’t fully boot up until after the SD card is removed.
#[2] that you for the experimentation. I’m a big fan of the #[3] project and am grateful to white hat hackers like yourself that help to harden the device.
Just had a PR for a notification reminder at startup. Some may want to leave the card in to set or adjust persistent settings, but a reminder is a good idea.
At startup is good but in case someone, as you pointed out, wants to adjust persistent settings, having the reminder appear before any create new seed or scan new seed action would be preferable right?
Tricky UI issues because we have a unified scanning mechanism. Perhaps a one-time reminder before any scanning is done, or before any keygen routine is initiated. We'll have to think on the best way, but some kind of reminder mechanism makes sense.
Nice experiment!
I strongly prefer HWW's with anti-exfil. Right now that's only Jade and Bitbox over USB/BLE. QR anti-exfil would be possible but it would need a new standard to be invented with an extra round trip making it annoying to use. I personally trust anti-exfil over USB more than anything else. Stealing from it requires both HWW and host to be exploited which might be harder to pull off.
https://medium.com/blockstream/anti-exfil-stopping-key-exfiltration-589f02facc2e
IMHO USB is worst than exfil, you can deal with the nonce issues with deterministic builds.
Yup. Python can do anything python can do (couldn't play the videos in Iris, but it all sounds right).
A lot of (er, all?) the onscreen security checks people occasionally ask for end up just being security theater since a compromised SD card can show you whatever it wants onscreen. Removing the SD card in the new SeedSigner OS def helps. And when the MicroPython port is done, there'll be firmware-level checks that will make "evil" SD cards much more difficult/impossible(?).
What’s the ETA for the MicroPython port? I’ve been planning to watch your YouTube series on how to get started downloading the project to make enhancements and contributions but should I wait until the port is completed? I’m not a coding expert by any means so it’s takes me a while to figure out how to build what I have in my head 😁
The basic plan is to use as much of the existing SeedSigner code as possible. So almost all of the walkthrough coding vids will still be relevant.
Only the UI/hardware-level code will be branched for Raspi dependencies vs MicroPython/esp32-S2/S3/etc deps.
Think biz logic vs rendering code.
And as for ETA... Oof. Unfortunately my current fiat responsibilities are taking up a lot of my coding time, so progress is so much slower than I thought it would be. Haven't had the luxury of being full-time on SeedSigner since late last year.
However, some of the work I'm doing now in the test suite is actually helping to pave the way for the MicroPython code to move forward. And the next big push on the MicroPython side will/should/hopefully be a gigantic leap forward.
Videos are playing on Iris. Could be a browser or OS related issue unless you have not disabled embeds on Iris Settings.
Dunno. Chrome on macOS.
Impervious (Chromium) on macOS plays that video.
The video is .mov and it seems that Chrome does not handle mov-files. If you copy-paste the video file to Chrome URL-box it just downloads the file (at least on Brave).
That makes sense. You'd think Chrome + macOS would be fine w/.mov since, afaik MOV only exists because of Apple! Actually, I guess the real test in that case would be Safari.
It seems to be the case that Chrome does not like mov:
Ok just a random thought, what about a user could download the seedsigner binary, verify it like normal but than sign the binary using his Nostr or even bitcoin key and part of the signing process is applying a PIN code to the binary. Now he flashes the binary and every time the seedsigner boots he needs to enter his pin or scan a login QR code as a challenge, if correct the ui would show something that only the owner knows if not you know it’s tempered.
Tampered.. heck could even be a standard two factor code that you insert on signing the binary that works with standard OTP Authenticators
Can't do TOTP if the device doesn't know what time it is! There's no Raspi Zero clock battery so it's the beginning of time every time you power it up.
So another idea could be preparing multiple cheap SD cards and each one is hidden in a 3D printed seal that nobody knows contains the SD card. If you don’t use it for longer period you move on to the next sealed SD card.
That would probably introduce enough complications to make an attack improbable, but I think someone could still get around it.
They could basically run your protected version through a secret internal emulator, pass the PIN you enter off to the emulator, and play back what the emulator produces.
This all being said, in most cases these exotic, sophisticated attacks wouldn't even happen; it'd just be a $5 wrench attack if they have physical access into your home.
I was told inflation killed the $5 wrench
would be better to use .mp4 instead of .mov for the video files...
#[2]
