Topic: Air gapped wallet printer (Read 6348 times)

As a bookend to this thread, further discussion here:


Physical device to generate public/private key pairs
 - https://bitcointalksearch.org/topic/physical-device-to-generate-publicprivate-key-pairs-117054

Duly noted, and thanks!

I'll be back on the road next week, and will thus have lots of time to meditate on this. When winter rolls around again and I find myself indoors with a soldering iron and lots of free time, this might just be the project I take up. And if before then I find myself struck by sudden inspiration (or a pallet of cheap printers) I'll let y'all know.

Thanks again, everybody, for all of the great ideas, refinements, and discussion!

-Mo

PS - It's a credit to this forum that so many pillars of the community hang out here in the newbies section!

Not connected to the network.

There actually are varying degrees of this though even.   You could have a desktop Windows system with the network cable unplugged and no wif-fi and try to call that airgapped, but it isn't.  Because if that system was compromised by a keystroke capture or malware that read the wallet.dat file as then that malware could transmit when the network connectivity is eventually restored.

So the more secure air gapped device doesn't have connectivity and won't.  Since you don't want to have to have around an extra PC or other device just for Bitcoin, a less-capable, specialized system like this wallet printer idea might be more useful.

 - http://en.wikipedia.org/wiki/Air_gap_(networking)

Pardon my ignorance but what does "air gapped" mean exactly?

Well, just as a closing comment I'd like to say that I disagree with the highlighted text above.

I still believe your initial idea, of just printing one-address wallets from an offline, air-gapped device is still very valuable. If it were available right now, for the right price (<$20) I'd be looking to get one or two ASAP, and I'm not worried that my system is compromised yet. I can handle my own transaction sending. But a quick and easy way to spit out addresses for storage (with accompanying private key) greatly simplifies things.

Just my 0.02btc.

'Cause I was a newbie when I started it.


It would. But I think I've learned what I wanted to know from this thread, so I'm going to summarize it and, after a little time for comments, close it. I'll then organize my thoughts and start a new topic in the appropriate forum later, probably when I've got a prototype (unless my flights of fancy take me elsewhere...).


Well, while these things are all excellent and useful; I think the easiest way to make them happen would be for someone42 to add printer support to his ongoing project. I haven't read more than the first few posts of his thread, but from the sound of things it already does most of what's been discussed here in terms of connecting to a computer and dealing with transactions, etc. I need to read the rest and get up to date.

Also, it sounds like a POS term would be the easiest and cheapest OTS hardware for this purpose, so maybe casascius and someone42 should be collaborating on the best and most cost-effective hardware wallet around? Or...competition is always good...

But the device I had in mind is truly air gapped. It never connects to a computer, and it doesn't even store keys. It's a wallet generator, not a wallet. Some folks don't like paper wallets, and I can understand that, but I do.

A hardware wallet is a replacement for a checking account or a real wallet full of cash. They don't have nearly the attack surface of a general purpose computer, but they do have an attack surface. Think of my proposed device as a savings account generator instead. It makes wallets which never have and never will touch a networkable device until the moment you're ready to transfer the entire balance elsewhere. When you want to do so, you boot your computer with your handy live CD and generate an offline transaction and when it's gone through you throw away the old paper wallet. Since the paper wallet is a one-time thing, you might not even need the live CD/offline transaction hassle if you're reasonably sure nobody will be able to snarf your private key and empty your wallet before your own transaction goes through.

So I guess the point of this thread, for me, was to see if anybody would be interested in dedicated hardware to do what GP hardware and a dedicated live boot CD already does very well. It seems to me that if you generate enough wallets with a CD boot you won't need to reboot to generate wallets as often as you'll need to reboot to generate transactions. So there probably isn't a market for an air gapped wallet generator unless it also generates air gapped transactions.

However, there does seem to be quite a potential market for hardware wallets. Someone42 and casascius seem to be on similar paths for a convenient but reasonably secure daily-use type hardware wallet. I'll keep thinking about how a proper savings account generator should work, and whether one is even useful versus something like a brain wallet or just CD booting a computer once in a while.

Maybe I'll just put together a bitcoin-tailored live CD. :-P

-Mo

PS - Feel free to post your closing comments, but I'd like to close this topic soon so if there's a good discussion to be had it should have its own topic.

Why is this topic in the Newbies section by the way?
Wouldn't it fit better in the Alternative clients section, like the other one about the Hardware Wallet?

The barcode is a good idea. Two people both using this device could safely send money to one another.

Concerning the keyboard, it doesn't need to be embedded. You may have just an USB port to connect a keyboard to. Such port could be used both to input the encryption password and to write out the encrypted wallet seed into a memory stick.
Such port could also be used to connect to some external software that would provide transactions to be signed. That would still be vulnerable to the risks described here, which can be considerably mitigated by what jim said just after.

Actually, if you manage to make the printer "detachable", or make it capable of connecting to an USB-printer instead of having its own, than your device may be really small. By that I mean "portable". Improve it with p2p wireless communication like that bitcoincard thing, and hidden volumes for plausible deniability, and you've got the best bitcoin storage and payment device.

Yes, several models (e.g. Vx570) have a USB port which can accept an external keyboard, to which you'd attach a keyboard-wedge 2d barcode scanner that supports QR codes.

Having the credit card terminal approve and sign transactions sent by a computer (either via RS232 or USB) is also a very useful application.  (When connected to a computer, it will look like a serial port over USB, as it supports serial port emulation).

Actually, I kinda had in mind users who are already so distrustful of their computers as to boot from a live CD every time they create new wallets, and even to create transactions if those wallets are intended for more than one use. This device would simply be a more convenient way to do the same thing.


All true. I would love for the device to generate transactions, too, but like you said, manual input of addresses is problematic and adding a camera or the like increases the complexity beyond what I had in mind. But I'll keep brainstorming. Manual input, annoying as it is, wouldn't add too much complexity if the device already had a keyboard and screen (like casascius's POS terminals). Hmm...casascius, do your POS terms support a barcode scanner? Maybe the printer could output an old fashioned barcode instead of/in addition to a QR code...?


Thanks for the link, I hadn't seen that thread yet. Looks like I've got some more prior art reading to do!


Are you really gonna make me finally learn C? I've managed to avoid doing so for over 20 years now...

-Mo

Even his computer he booted from a live CD?  or his computer that has never been connected to the internet since the OS was freshly installed?

If someone could create a module in C that exposed a function which took 32 random bytes and gave me a bitcoin address and base58 private key in a buffer I provide, with no dependency on any libs or 3rd party stuff (100% self contained code), I could PROMPTLY produce a downloadable program for the VeriFone VX credit card machines that would issue addresses as QR codes on receipt paper and on screen.  That means all bignumber math and ECC math would have to be implemented right there.  Such a C function would not need to be responsible for entropy, I can handle that, I can provide the 32 random bytes to be used for the private key.  Open source OK as I plan on publishing source to it all.

I've thought a little more about it, and there's an issue with the air gapped printer idea.

If we're talking about an air gapped device, that's because we cannot trust our other devices. So, let's assume somebody has one of these printers, but all of his computers are compromised with bitcoin-stealing malware.
While he uses the printer to generate addresses, and only gives these addresses to those that should credit him, he should be safe - assuming the malware is not advanced enough to also tamper the messages where the user sends his addresses to others.

But what would this user do when he wants to spend the money he has in these safe addresses? If he loads the private key into any of his computers, he loses the money.

For such a device to be complete, it should be able to generate offline transactions as well. But that would probably require a way to scan QR-codes. Manually inputing addresses is error prone and annoying.
Anyway, this increases the complexity of what you're trying to do...


Suggestion: talk with someone42, who started this topic: https://bitcointalk.org/index.php?topic=78614.msg879194;topicseen#msg879194
He's trying to do something similar, but purely digital instead of paper printer. I tend to prefer it since I'm not a big fan of paper wallets anyway. But I guess the printing part is not the hard part.

Good ideas, I like 'em both. I don't think either would be difficult to incorporate into a system that's already got the horsepower to do the hashing in the first place. It might take a little more memory, but it'd be worth the extra expense IMO.

Thanks, and keep those ideas rolling! It sounds like there's a market for something like this, and you guys are really helping me flesh out some specs, so I might just do this thing.

-Mo

PS - Casascius, I hope you're looking for the code you need to make a POS term work, 'cause competition is good! Also, if you open-source it (and I don't wimp out and use a basic stamp), I might steal some of your code.

I would happily buy such a device, but I'd like it to have a feature that I find important: ask for a strong password and use it to encrypt a copy of the key, and print this encrypted copy, so that I could scan it on my computer and safely back it up in a service like Wuala, plus different medias of mine.
I believe backups should be geographically separated, and it's much easier and cheaper to accomplish that with digital data than with paper.

Maybe it should use deterministic key generation, as some clients are already doing, so that I only have to backup an encrypted copy of the seed.

What do you think?

Damn, I read past that too. Anyway, if you only take the least-significant bit of each sample from the ADC, you'll get complete randomness (from background noise) regardless of what an attacker is trying to transmit (since it's an analog signal, there'll always be some level of background noise that's outside the attacker's control). The same trick works with a microphone, for the same reason.

Very true, it's probably not a practical attack vector. However, from a marketing perspective, I'd like to be able to say the device can't be influenced in any way by outside forces.

But your idea certainly has merit. I might go the really simple route by using a plain microphone and leaving it up to the user what to feed into it, if adding sound input is cheaper than other alternatives. The circuitry to turn sound into bits is pretty simple if fidelity isn't important.

-Mo

An attacker could bias your device from afar, but he'd also need to know precisely when you pushed the 'start' button.   And if you were using a normal radio to do it, you could hear the attempt at screwing with it.  Although it's technically possible, the practical means of influencing the entrophy in this fashion is pretty remote.

Good thinking! I must've read right past that, sorry. The only thing I'd worry about is an adversary having a transmitter nearby and therefore overriding the unpredictability of the seed. Since I plan on keeping the specs and software open on this design, an adversary who knows you have it knows how it works.

But you're on the right track. I've been trying to think of a good, cheap RNG (besides button-mashing) that's hard to either eavesdrop on or influence from afar. So far I've avoided actually researching it so I don't muddy up my thought process, but soon I'll see what's commercially available.

-Mo

Well, that's exactly why I mentioned an am receiver tuned to static.  Pipe that into the stereo mic-in jack of a small computer, mash the resulting bitstream up with some hashing algos, and you've got a pretty decent RNG hardware on the cheap. 

Well, the expensive stuff has always been faster than the cheap stuff (otherwise why would anyone buy it?), but you don't really need speed. "Awfully slow" these days means a few kilobytes of entropy per second. That's more than enough to generate a bitcoin address in less time than it takes to print it, and in any case is much, much faster than mashing the keyboard to produce entropy.