search

SeedSigner / seedsigner

Use an air-gapped Raspberry Pi Zero to sign for Bitcoin transactions! (and do other cool stuff)
MIT License
661 stars 152 forks source link

[feature] USB Smartcard reader support #231

Open openoms opened 2 years ago

openoms commented 2 years ago

There are only so many Specter Shileds around, but storing secrets on smartcards has become my favourite method. Consider the convenience of the cheap, PIN protected, encrypted storage which is very well suited for travel (especially compared to plaintext seed words or QRcodes).

Since the SeedSigner currently runs a full linux distro the driver support should be fairly straightforward through USB.

The setup in mind:

Parts: Cards: https://www.alibaba.com/product-detail/JCOP-Dual-Interface-Support-RSA4096-ECC_1600070838098.html

The reader pictured: ACS ACR39U-N1 PocketMate II USB Smart Card Reader https://www.amazon.co.uk/dp/B0758TS5JR/

Notes to install the card reader and initialize a smartcard on Debian/Ubuntu: https://gist.github.com/openoms/510b2876cab19e15c4190456ea8aad82

Code in Specter DIY: https://github.com/cryptoadvance/specter-diy/blob/master/src/keystore/memorycard.py Issue about supporting other USB or hard-wired card readers: https://github.com/cryptoadvance/specter-javacard/issues/1

SeedSigner commented 2 years ago

It's an interesting concept though I don't have any practical experience in working with smart-cards. Do you have any information on the data-storage expected lifespan of the smart cards? Are there incidents where they can malfunction or their stored data becomes corrupted or otherwise inaccessible? I'm leery of recommending users store PKs in digital format without some kind of secondary backup (usually an analog one). But if there is good information on their reliability / durability, and the quorum is large enough, I could potentially see using them as a primary / solitary PK storage mechanism. Also open to any thoughts that @kdmukai or @newtonick may have.

openoms commented 2 years ago

However smartcards are generally used widely for years without any corruption issue (doesn't even compare with the magstripes on bank cards) agree that any digital media shouldn't be the only, non redundant backup. They are basically disposable secure chips which lock permanently after 10 failed unlock attempts (as configured for the Specter).

Marc-Gee commented 2 years ago

A smart card reader used like this would have to be dedicated, to maintain the air gap. I was reading a fascinating article by Brian Krebs on how the USA military ended up having .mil users buy their own insecure readers to be used (with malware infected drivers). Awful situation, but it highlights that the card reader can arrive pre-infected. (not the card is infected necessarily).

The proliferation of .mil service members buying MITM devices unwittingly/NMP is awful to see. 🤔

So I would worry about that angle. Thoughts? M

openoms commented 1 year ago

A smart card reader used like this would have to be dedicated, to maintain the air gap. I was reading a fascinating article by Brian Krebs on how the USA military ended up having .mil users buy their own insecure readers to be used (with malware infected drivers). Awful situation, but it highlights that the card reader can arrive pre-infected. (not the card is infected necessarily).

The proliferation of .mil service members buying MITM devices unwittingly/NMP is awful to see. thinking

So I would worry about that angle. Thoughts? M

All components can be added to the threat model. It is about optionality and I think a dedicated smart card reader (just as a dedicated Rpi0, screen, camera and SDcard(s)) is a realistic requirement.

The advantage to have a general purpose, unbranded, but PIN protected and encrypted card holding a seed versus a plain text QRcode or seed backup is huge.

SeedSigner commented 1 year ago

Still curious to hear any thoughts that @kdmukai or @newtonick may have?

newtonick commented 1 year ago

I'm not against the seedsigner project exploring this idea. I agree with @openoms about adding optionality. DIY signing devices are a perfect place for folks to explorer different solutions for different threat models. I personally have no experience with smartcards and won't likely spend the time to explore this rabbit hole in the near future. Adding support for a smart card reading in SeedSigner OS will likely be more time consuming than adding it to the Raspberry Pi OS.

I'd love to see someone do a POC via manual build steps. This would help show what development steps would be required and gauge seedsigner user interest.

3rdIteration commented 9 months ago

Is anyone here still interested in this? I've been playing around with the satochip and seedkeeper smartcard based devices and adding an integration that allowed both seed storage and also on-card signing would actually be trivial, as both the java applets and a python API is already available. (It would simply be a matter of adding the UX elements) I'm just in the process of writing a cli for the API to familiarize myself with it all, but could certainly give some time to this in the coming months.

I'm happy to knock up a proof of concept if there is any interest.

jdlcdl commented 9 months ago

...a proof of concept if there is any interest.

I will certainly follow any work you do on this, however it feels not so seedsigner-ish, at least to me, for my following opinion:

I've come to enjoy the half-duplex control that I have when transmission of information is via qrcode. I get to control who is talking and who is listening... and if I want to, I can put another airgapped-or-not device in between to make sure that what is being said is what I want to be said... without the other listener hearing.

Do I believe that normal people would do this? Of course not... but that I CAN is what matters to me... so that I can do this now and again, and so that the rest of the time I know that I'm still controlling who is talking and who is listening.

With electronic transmission, wifi/bluetooth/usb, the user never knows what is being said, whether or not there was two way communications, or the amount of information transmitted.

Still, if you work on this, because the tech interests me... you will certainly have my interest and my feedback.

kdmukai commented 9 months ago

@3rdIteration an on-card signing use case wouldn't make any sense for SeedSigner. TapSigner and anything of similar functionality exists as a parallel hww-lite alternative.

As @Marc-Gee noted, back-dooring a smart card reader makes much more sense as an attack vector than trying to back door a Raspi Zero that might end up just controlling someone's Christmas lights or an NES emulator or who knows what. We'd be stepping into a much more aggressive adversarial arena. I'm not convinced the benefits are worth it.

@openoms:

The advantage to have a general purpose, unbranded, but PIN protected and encrypted card holding a seed versus a plain text QRcode or seed backup is huge.

I don't deny that there is a use case, but overall I think the risk of plaintext mnemonic backup or SeedQR is strictly tied to the problems inherent with single sig. Yes, lots of people use single sig (and, of course, it makes sense as an initial destination when first taking self-custody), but all of the single sig security solutions just feel like band-aids. There is a spectrum, X is better than Y, but I just don't think that even Y is totally sufficient. So rather than trying to incorporate incrementally better Ys (that still aren't sufficient), I think the main focus should always be on encouraging multisig and making it as easy as possible.

As a tiny team of volunteers, @newtonick has the right take.

3rdIteration commented 9 months ago

I'll finish writing a cli for this and knock up a basic PoC that just does seed storage with a USB connected reader, as this is trivial to implement. (Implementation via GPIO could come later if there is interest)

3rdIteration commented 7 months ago

Demo code is here: https://github.com/3rdIteration/seedsigner

Video demo here: https://youtu.be/WHVWqJJBNdA

Installation guide assumes that you have followed the official docco for a manual installation and can be found here: https://github.com/3rdIteration/seedsigner/blob/dev/docs/smartcard_support_installation.md

If anyone would prefer a pre-made image then I can also provide one. (Though it will be a fairly large file with a long boot time, typical of older pre-SeedSignerOS releases)

Everything is just running nicely on x86 (Which I thought would be an issue for the GPIO connected NFC reader) and it basically "just works" with any standard USB smartcard reader as well. (Some types of cards don't flash super reliably over the $5 GPIO connected NFC reader)

jdlcdl commented 7 months ago

Neat!

3rdIteration commented 7 months ago

I also just updated the documentation and repo to support cheap SIM readers like the ones here: https://www.aliexpress.com/item/1005003979274884.html?spm=a2g0o.productlist.main.3.13ecrvWsrvWs22&algo_pvid=7528ad1f-8607-4ec5-8a02-30f3d7ae6fd6

If you have any of those kicking around it will also work, though you will need a smart card in the SIM form factor. (I have a J3R180 sim cut from the Satochip store that works very nicely)

To be clear, you can get proper modern readers for a few bucks more that will be less hassle, but you can also build these ones from scratch... (So are useful for reference, education and supply chain backup) That said, if anyone wants to wire up a SIM card reader directly to the Pi GPIO, this would be a cheap/easy way . (Schematic here: https://circuitsarchive.org/circuits/smartcard/smartcard-pc-serial-reader-writer-phoenix/)

Demo video here: https://youtu.be/uG44Fw3rOLg

openoms commented 7 months ago

Update: I have managed to install and use the Satochip and the Seedkeeper applet on the same javacard which was used for the SpecterDIY. They also have different, independent PIN codes. See my notes here for Linux (started for Specter, now extended): https://gist.github.com/openoms/510b2876cab19e15c4190456ea8aad82

Started to test the Satochip setup with Sparrow Wallet by initializing the card, storing a seed and changing the PIN right from the GUI there.

Doing the initialization and signing on a self-built, stateless SeedSigner will be such a good use case, thank you very much for sharing this @3rdIteration

3rdIteration commented 6 months ago

Added an updated version of the code here: https://github.com/3rdIteration/seedsigner/releases/tag/0.7.0%2BSatochip-Alpha1

Changes from previous alpha and some cases to 3d print are also included in the release info.

3rdIteration commented 4 months ago

Just a heads up that I have pushed a more detailed video here: https://www.youtube.com/watch?v=Rhs9z5uL7qg

And a proper beta release here: https://github.com/3rdIteration/seedsigner/releases (Running on buildroot now)

Difference from Stock SeedSigner

Future Features & Improvements