Topic: Physical device to generate public/private key pairs (Read 4668 times)

If the device is yours and never connects to a network, it's not going to be a big deal.  Even if it had a backdoor, if it never goes online, how is it ever going to snitch to command central?  Same goes for your printer if its only connection is USB.


They'd find a lot of dirty diapers, but that's about it.  Maybe soon it will have chocolate bitcoins.  When I produced private keys, I made sure to produce exactly one copy.  Each sheet was hand-inspected to insure uniqueness and conformity with the planned sequence.  There were overprints, naturally, because those buggers are hard to line up in the printer on the first try, but they were overzealously destroyed and won't be found in the trash.

Most of them I destroyed by pulping with water in a commercial blender.  My other thought was to torch them in the outdoor barbecue, but I didn't want people coming and digging through the ashes of my barbecue looking for private keys!

I am worried about electronic traces of previous key generation being detectable.
Hardware backdoors could save the keys in memory.
Keyloggers, etc., could keep some trace of the keys.
If the device could be made cheaply enough and destroyed, it would provide that much more peace of mind. 

For this reason I don't even like to use an external printer for paper wallets, but write keys down by hand.
Obviously, this is not a scalable solution.

I'm wondering, has anybody destroyed any items for security? 

I would imagine that Casascius' trash might have some people going through it...   

The above output is from where I forgot to pass -static to the linker. With that option the file is 2.0 MB and this is the output of strings:


But I'm not sure this is relevant, as it's not me who will be building the code. It should be built with the SDK for whichever machine is to be used. casascius mentioned that the SDK he has used includes headers like stdio.h, string.h, stdlib.h and math.h, so I presume this would work as a replacement for glibc, and the dynamic linker that my build depends on.

maximum security would be open code...not necessarily your being able to trash the device

ld-linux.so is the dynamic linker and libc.so is the Standard C Library. All of these are specific to that ABI and therefore wont work on anything else.

Watching development here in the keypair generation space.
I want these things to be disposable after use for maximum security. 

I've put up the code on GitHub, in case you want to take a stab at it casascius

https://github.com/runeksvendsen/sbag

The file grows to 2.0 MB when I statically link it.

Thank you very much for the offer! I would have no idea what to do with one of those machines though, so we're probably better off leaving the building and transferring of the binaries to either yourself or casascius.

Haha! Doh! I was using the Debug build. The Release build is 1.1 MB.

EDIT: Hmm. I see references to .so files when I check the executable via strings:

It seems I got it to work without libdl. The executable is now 2.2 MB. Though I'm not sure how to test if it's completely self-contained.

You're right that it must be possible to get it below 1 MB, but it's not easy when I use OpenSSL, as far as I can figure out. I've researched it a bit, and the general consensus is that you have to manually edit Makefiles, headers and possibly source files to not include unneeded functions.

I haven't been able to find an open source bignum, SHA256, RIPEMD160 and EC math implementations for C either. Let me know if you know any.

Whatever ended up being the successful result would have to be a module consisting strictly of code plucked from the libraries so nothing is in there that isn't called.  Sort of how bitaddress.org works.  I figure it must be possible - it's got a minimal bignumber and EC point doubling/adding and it fits in mere kilobytes.

I'm pretty sure we have a half-dozen or so credit card machines in stock. Love to find you some dev equipment....

I can get an executable statically linked to libcrypto down to 2.3 MB. But I can't get it to compile without depending on libdl.so.

A device like this on the lowest end typically has 1-2 MB RAM and 1-2 MB Flash.

It's not constructed like a typical computer though.  The CPU can execute programs directly from flash without copying them into RAM, and the RAM is battery-backed and is the main file system.

^ How much storage space and memory is available on the device? Perhaps one could compile libcrypto and libssl and statically link them with the program. libcrypto.a and libssl.a are 5.1 MB in total.

stdio.h, string.h, stdlib.h, math.h should all be available.

Entropy has to come from a combination of the keypad and timer.  In addition to scraping system-specific data, during initialization we have the user mash the keyboard to initialize the entropy pool.  Using the key scan codes of the key strokes as well as the precise timing between them (system tick counter with resolution in the millisecond range) as well as the system clock, we get enough entropy to start generating keys.  Each keypress is used to add entropy to the pool, and we persist the entropy to the file system (which is saved as battery-backed RAM).

It is a whole lot like what bitaddress.org does to acquire entropy when you first load it, other than we can a) do it for longer because b) given persistent storage, we only have to exhaustively do it once.

Finally, as you might notice in my bitcoin address utility:  I prefer to generate private keys by using the SHA256 hash of a string that is partly system generated, and partly provided by the user.  The system generates a long random string (80+ characters) and then the user is invited to insert keyboard mash into the middle of it.  SHA256 is done on the resulting string plus n, where n is an incrementing number.  This provides simple auditability that the RNG isn't rigged (or if it somehow is, it won't be harmful), and allows the user a decent chance to "cut the deck", without too much worry that the user's gibberish won't have enough entropy.

For additional discussion on that:

Air gapped wallet printer
 - https://bitcointalksearch.org/topic/air-gapped-wallet-printer-77930


Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices
 - http://bitcointalk.org/index.php?topic=78614.60


Offline Paper Wallet Creator - Raspberry Pi?
 - https://bitcointalksearch.org/topic/offline-paper-wallet-creator-raspberry-pi-74615


Casascius Bitcoin POS system
 - http://bitcointalk.org/index.php?topic=46366.20

So obviously ... there is demand for such an item if it were to exist and be commercially available.

If you're interested in learning ECC, Certicom has a lot of information that is reasonably easy to understand. It isn't really as complex as it may sound. Just a lot of equations.

http://www.certicom.com/images/pdfs/WP-ECCprimer.pdf
http://www.certicom.com/index.php/10-introduction

How would one get entropy on such a device? Creating a standalone console app that can create an address from a private key is relatively simple. It might be something I would be up to.

It would require a standalone implementation of SHA256, RIPEMD160, EC math and BIGNUMs.

EDIT: Looking at OpenSSL's BIGNUM implementation, this depends on things as stdio.h and assert.h. What is actually available on this credit card machine?

I'm not sufficiently skilled to do the work with what I know now...although I'm sure I could figure it out, I haven't the time -- and surely there are people around here who know how to make it happen.  Just seems like a good idea and a good money maker for someone who can pull it off...

Their SDKs are payware and their binaries must be signed.

But the majority of the work isn't hardware dependent.

If you can come up with a console app that will run under Linux, perhaps takes some entropy or a 32-byte private key and prints a single bitcoin address to the console, I can convert it to run on the credit card machine.  I can also provide the part that sends QR codes to the printer, given just the string to encode.

Importantly, it can't depend on having the whole openssl suite available, nor any libraries.  Whatever it is has to be pretty much self-contained, sort of like bitaddress.org is completely self contained.  These are machines with single digit megabytes of memory.

I just don't understand the inner workings of the EC math to go at it myself, but if that part were self-contained I'd have no problem producing the binary.  Possibly the best way is to surgically remove the relevant code from openssl and isolate it into its own module.