Improving Offline Wallets (i.e. cold-storage)

[Sukrim]

What if the "offline" PC is only a passive listener in a network, e.g. WLAN?

That way, it would simply sniff network traffic until a certain transaction flies by that it could sign - it would sign it and store the signed transaction.
No bandwidth issues there and since no sending communication is allowed, there's no way that an attacker can do anything else than let it sign a transaction - something that's possible with any other method too. No way to get to the private keys though.

To get back the signed transactions (or even just the signatures, if you need to transmit even less data) you just select the ones to export and transfer them to the online machine using a write-once medium (e.g. QR code on paper, CD-R, morse code over the air...).

Using the "selective listener" approach, you just need to broadcast unsigned transactions in your network and they will be picked up and to get the signature, you'll get seomthing from the secure station that has never been in any other computer, so no way for infected USB sticks that get transferred between 2 PCs. The attack vector then would be that the secure station's network interface can be taken over/infected by passively listening to (potentially pre-filtered to only contain Armory relevant traffic by a hardware firewall) transaction data.

[markm]

There is always printer port connection possible too, typically no getty running on those ports.

-MarkM-

[etotheipi]

There is always printer port connection possible too, typically no getty running on those ports.

I've seen that mentioned a few times... it seems that the python-parallel package is in the Ubuntu repos, and the cables are not necessarily expensive.  Is there an equivalent way to hook up two systems?  i.e. the equivalent of the two USB-port adapters and a null-modem adapter.  I am assuming this would not be overly expensive...

[Sukrim]

Probably this would require some weird/special hardware, but what about display ports (VGA/HDMI/DP/...)? On the other hand I guess a standard SmartCard should be OK for a lot of things already - my government ID (that can even be activated for SIM cards on mobile phones) is good enough for my bank to autorize transfers of up to 50k EUR.

Other than that RFID/NFC are other potential interfaces to bridge an air gap - though I like the ideas with light (flicker codes/QR codes + webcam) and sound (similar to credit card microphone jack readers) the most. The more specialized/weird hardware (already smartcard readers are by far not common household items!) is used, the fewer people will actually use it and use a far less secure method instead.

Maybe even just encoding transactions in a port-knocking sequence over LAN could be enough, no need to accept a single packet, just listen to the ports accessed. The code interpreting this needs to be watertight though, and one still risks that the OS itself is somehow able to accept a malicious packet.

[oakpacific]

- Most newer systems do not have serial ports [/li][/list]

Incorrect, it is trivial to buy a Serial-To-USB cable. It also works under Linux. Checked myself.

Just my 2 cents/satoshis.

I know, that's why I posted, a few responses back more ideas for executing serial connections.  I already have two USB-serial cables and a null-modem connector and have been playing with them.  What I was hoping was to brainstorm on any possible, remaining attack surface exposed by it.  The getty's are a "hidden" snafu in the whole process, but easily disabled.  I am searching for more experience with this... since serial ports used to be "the cool thing", I'm sure there's tons of auto-enable subsystems that try to make your life easier by detecting and doing something when the serial device is plugged in.  

Hence why I liked the pure-software solution of destroying the usual device/file that is used for serial communications, and remaking it somewhere that no other subsystem can find it or use it.  This would seem to resolve any remaining "unknowns".

Unfortunately, the USB-serial cables are not cheap, but they're not ludicrously expensive, either if you are protecting a lot of money.  Maybe 2 * $20 plus a $2 null-modem connector.  In the long-run, it's actually a very reasonable solution for serious bitcoiners...

Would a flash drive that could only be read/written in the RAW mode by Armory work? Most of the work needs to be done should be on the software side, in fact, maybe you can even build a custom LiveCD with FAT32 filesystem support in kernel removed to further eliminate the risk of something on the USB stick getting executed.

[justusranvier]

You can't rely on obscurity to protect cold storage wallets.

Before long malware is going to start targeting Armory directly.

[etotheipi]

Would a flash drive that could only be read/written in the RAW mode by Armory work? Most of the work needs to be done should be on the software side, in fact, maybe you can even build a custom LiveCD with FAT32 filesystem support in kernel removed to further eliminate the risk of something on the USB stick getting executed.

I really like the idea, except that it requires root access to do it (because, if you R/W raw volumes, you can access any files on your harddrive, even ones that you don't have permission to access).  That complicates Armory a bit, which shouldn't run with root priveleges, but there are environments where that is acceptable.  I'll have to think about that one.

[oakpacific]

Would a flash drive that could only be read/written in the RAW mode by Armory work? Most of the work needs to be done should be on the software side, in fact, maybe you can even build a custom LiveCD with FAT32 filesystem support in kernel removed to further eliminate the risk of something on the USB stick getting executed.

I really like the idea, except that it requires root access to do it (because, if you R/W raw volumes, you can access any files on your harddrive, even ones that you don't have permission to access).  That complicates Armory a bit, which shouldn't run with root priveleges, but there are environments where that is acceptable.  I'll have to think about that one.

Yes, that's definitely a concern, maybe a script that creates an account with the privilege to access nothing but the usb device file will do the magic?

[Tirapon]

What if you partition your USB stick into sections just big enough to save an offline transaction? Or something along those lines... i.e. enough space to save transactions when transferring between machines, but not for malware to be written onto it. (I don't really have much understanding of these things)

[Tirapon]

Anyone? My initial thought was: What if I could use a USB drive which would be full once a transaction was saved onto it? I guess this would mean a few kB size, which I'm guessing doesn't exist (could it be made?) so my next though was to partition a USB drive into sections around this size, if this would have the same effect? But my technical knowledge isn't great so I was hoping someone cold tell me if this would work.

[Blowfeld]

I'm not an Armory user, but I like the concept!  I'm not sure the problems you are trying to solve are articulated and enumerated well.  Perhaps if each point of concern were individually called out, it would make following this thread a little easier.

Anyway, here are a few comments, directly relating to recent posts:

First off, I don't care for security by obscurity, although it might be OK if you are trying to protect your private installation (with no other insiders except yourself) against a generic piece of malware.  It is no longer obscure if everybody is using the same technique or if insiders can spill the beans.

-- Removing standard /dev files and replacing them with misnamed device files may not do any good.  Wouldn't a smart piece of malware use the major and minor numbers to determine which devices to attack?  Couldn't a smart piece of malware with superuser access simply create its own device files or access the drivers directly?

-- IBM sold what was essentially a null modem for parallel printer ports during the heyday of their Personal System/2 machines (circa 1987-1992).  They were sold with a floppy disk containing software to help you move your files from your old PC to their new PS/2 systems.  The block had a DB-25 on one end (to plug into your new PS/2), and a female centronics on the opposite side (to plug into a standard parallel port cable).  Parallel ports on the pre-PS/2 computers were generally write-only.  The new PS/2 systems introduced R/W parallel ports.  (At least for IBM's line.)  I believe other manufacturers had something similar.  Not recommended due to high cost and obscurity.

-- Are you worried about malware changing the TX request between when it is generated and when it is signed?  Clearly, the TX request should be displayed to the operator on the secure computer before the secure computer operator applies the signature.  Humans will readily spot changed amounts.  Humans will less-readily spot a changed destination address, especially one that resembles the intended destination address.  Or perhaps the operator should be asked to manually enter the most relevant parts of the transaction (especially amount and destination addresses) for confirmation, before any opportunity is given to sign the transaction.  The cleanroom computer must take a more active roll than simply signing any transaction that is presented.

-- Are you worried about the destination address being changed before your insecure computer prepares the transaction?  This is a tough problem, given the bitcoin protocol.  For privacy reasons, the intended recipient cannot sign the public hash.  So, the public hash must be obtained outside the bitcoin protocol.  I think this problem is outside the scope of Armory, but if $50M transactions are expected, somebody better figure out how to prevent my request to send the money to address X from being changed by (somebody who hacks the Web site; someone who has a successful man-in-the-middle attack against SSL, for example; or someone who gets malware on the machine that constructs the transaction; or etc.) to address X', which might have been generated by a vanity miner to look a lot like address X.

-- Anything that goes across USB, LAN, serial, or parallel ports is a potential vector for malware, is subject to manipulation, and is subject to side-channel leakage.  As someone else hinted, any channel bigger than the size of a transaction has the potential to deliver malware to the cleanroom computer and/or leakage from the cleanroom computer.  Even QR codes (and barcodes) are basically unreadable by a human, so are also subject to manipulation and some side-channel leakage.  It's hard to avoid any risk of manipulation or leakage without forcing an operator to retype what the other computer display or prints.  I suppose you could use an OCR font on each screen, read by a Webcam on the other machine's screen.  But, now you have to worry whether malware on the dirtyroom computer isn't watching the operator type the password on the cleanroom computer.  A similar threat exists if sounds are exchanged by speaker and microphone, as attacks have been published that allow an adversary to determine what is being typed on the keyboard by sound alone.

-- I think the best idea mentioned is the secure Armory OS.  Build it off of something small and stable.  No dependencies on any software the Armory team hasn't written or inspected.  As they say, though, treat every line of code as a potential security vulnerability.  Can one write a perfect Armory OS / signing component?  Not in the short term, I suspect.

-- Another possibility to help avoid some attacks might be to have the operator enter valid destination keys into the cleanroom computer by hand.  If the destination address isn't in the cleanroom computer, the transaction won't be signed.

-- Also, it might not be unreasonable to have an operator enter all aspects of an expected transaction on the cleanroom computer AND the dirtyroom computer.  Every aspect of the transaction must match or the transaction will not be signed.  This method would remove the need to send any data from dirtyroom computer to cleanroom computer.  Only a one-way channel for sending the signed TX from cleanroom to dirtyroom is required.  [A serial cable with the cleanroom's Rx signal cut might do the trick.]  Here, nothing dirty ever touches the clean computer.  The cleanroom computer keeps track of transactions it has spent.  When the owner of the system wants to move funds from the dirtyroom computer to the cleanroom computer, the transaction (at least the output script) that loads up a (new?) account must be manually entered into the cleanroom computer.

[etotheipi]

@ Tirapon:

The problem is there is an enormous range of size of data that needs to be moved.  Most transactions will be a couple kB.  Some tx, and all the all the supporting tx, will be MB.  I wouldn't consider any device with less than 5MB of space, sufficient for 100% of transactions.    Even if that was sufficient for avoiding malware (which I don't think it is), it would be pretty tough to find 5 MB USB keys.

@Blowfeld

I just want to clarify this is not "security through obscurity" -- moving the /dev objects around for the serial port is not for confusing malicious threats on the offline computer, it is about confusing innocent, latent threats.  We are operating under the assumption that the offline computer is not compromised, not under malicious control.  Moving the /dev devices around is about confusing pre-existing software/modules that are part of the OS/kernel, that might otherwise kick in automatically when it detects a serial port and expose attack surface.  Learning about tty logins scared the crap out of me me, because it took something that was theoretically very safe, and turned it into a security disaster (I would wager that 30%+ of users will use a login on the offline computer that is stored in their saved passwords in their online webbrowser -- this means that an infected online computer needs only a couple seconds to tty login over serial and take the wallet).  

The tty logins on the offline computer are not "malicious", they are simply trying to make a shortcut for what kernel developers 20 years ago expected we wanted:  which is that we connected the serial port so that we could login from a different device.  That is clearly counterproductive to our goal with offline wallets, and it's the reason I didn't want to blindly recommend serial ports, because of the risk that impatient/low-attention-span users would actually decrease their own security instead of increase it.

If your offline computer is already compromised, well there's not much we can do about that.  Anything we could do, would only be a temporary relief until the threat adapts and the next person's compromised system already defeats the new security procedure.  This is more about disarming the rich subsystem of modules that are pre-built into the kernel, to "try to help out" when you plug in a device.  Perhaps a custom OS is the right procedure... but I'm no an OS developer/packager/distirbutor.  It is also at odds with my goal for "easy" and "transparent."  The solution not only has to be secure, but it should be trusted -- a custom OS leaves room for all sorts of shenanigans, which some users may not trust, and instead go for lower-security-but-with-higher-certainty solutions.  The nice thing about the serial port idea is that it's strictly a software solution that applies to anyone's favorite/trusted *nix OS, and is easy to review the code that moves devices around. (and if they're using some obscure OS that the default script doesn't handle, well they have enough obscure *nix knowledge to translate the process for their OS).

The address changing problem is actually one for the payment protocol.  That was thoroughly discussed on the mailing list, and I suspect it's something that will come to fruition soon.  It's not a sure-shot, but it definitely avoids most of these problems:  you would now send money to receipts@bitcoinarmory.com, and even the offline computer would be able to verify that there is a trusted CA signature confirming the underlying (invsible-to-the-user) address.  It's not a certainty, but it shouldn't be used for $1mil+ transactions, the same that you don't [shouldn't] use SSL for $1mil+ operations.  Bitcoin can still be used there, but it would be done with a higher, manually-verified level of checking.   I think it's a perfectly acceptable solution for small-to-medium transactions.

Please don't go off on a tangent here discussing CAs and SSL security and how it shouldn't be merged with Bitcoin, etc.  I can point you to other discussions if you want to insert your two cents about it.  I'm of mixed opinion about it, but I do believe it is the lesser of all evils for small-to-medium sized transactions (status-quo being the evilest), and I'm happy to support it if everyone else does.

[Blowfeld]

@etotheipi:  Thank you for the clarifications.

[Tirapon]

etotheipi, thanks for your response. Out of interest, if I am able to keep my transactions to a few kB would I be able to use my initial suggestion to offer any additional security? Sending a donation your way btw, keep up the good work 

[behindtext]

@ etotheipi

i didn't see this explicitly stated in the thread, but is the goal with using serial ports for communication to avoid firmware exploits on the NICs?

never a good idea to store valuable data on a machine that doesn't use disk crypto, it has saved my ass on several occasions.

[etotheipi]

etotheipi, thanks for your response. Out of interest, if I am able to keep my transactions to a few kB would I be able to use my initial suggestion to offer any additional security? Sending a donation your way btw, keep up the good work 

I personally don't believe it would.  I'm not all that experienced with malware, but I know the actual executable code tends to be tiny.  According to wikipedia, "Stuxnet was unusually large [for a virus] at 500 kB".

Also, while your individual transaction may be small, Armory has to transfer all the supporting transactions so it can verify the transaction fee (it makes me wish Satoshi had done one tiny thing differently to avoid this necessity).  Because of that, you don't necessarily have control over it:  someone may send you coins in a 200 kB transaction, which will then have to be couriered to your offline machine along with the one you want to sign.  If your wallet consists of lots of little inputs (like a donation wallet), then you will end up with enormous transactions.  I've seen 3+ MB, before.

Unfortunately, I have to accommodate that in this solution, as it will actually be more common than I initially realized.  A company that does business with even 10 customers a day, will have a 70-input transaction once a week in order to move the coins.  Theoretically, you could have a 100 kB transaction with something like 600 inputs each of which is about 100 kB -- that would lead to 60 MB to be transferred (based on the fact that the network may be making >100kB non-standard for tx).

i didn't see this explicitly stated in the thread, but is the goal with using serial ports for communication to avoid firmware exploits on the NICs?

never a good idea to store valuable data on a machine that doesn't use disk crypto, it has saved my ass on several occasions.

The disk crypto doesn't help in this case, because either (1) you use full-disk-encryption, which will be unlocked while the system is on, so a "copy" will copy the unencrypted data, or (2) The wallet file is encrypted only, in which they only need to keylog your passphrase to get it.  Though, I have received some good ideas for helping with keylogging, but any malware advanced enough to compromise your offline computer could easily pull your crypto key out of RAM next time you unlock the wallet. 

The goal is to avoid getting to that point at all:  a serial connection that doesn't possibly induce any subsystems to kick in and try to help out.

[chrisrico]

What do you think of the Trezor? Is building Trezor or other specially designed offline wallet functionality into Armory an easier solution than all this? At least then, the onus is on the wallet manufacturer to design a secure system to protect the keys. The user's software just has to provide a good interface to it.

[behindtext]

i didn't see this explicitly stated in the thread, but is the goal with using serial ports for communication to avoid firmware exploits on the NICs?

never a good idea to store valuable data on a machine that doesn't use disk crypto, it has saved my ass on several occasions.

The disk crypto doesn't help in this case, because either (1) you use full-disk-encryption, which will be unlocked while the system is on, so a "copy" will copy the unencrypted data, or (2) The wallet file is encrypted only, in which they only need to keylog your passphrase to get it.  Though, I have received some good ideas for helping with keylogging, but any malware advanced enough to compromise your offline computer could easily pull your crypto key out of RAM next time you unlock the wallet. 

The goal is to avoid getting to that point at all:  a serial connection that doesn't possibly induce any subsystems to kick in and try to help out.

suffice it to say i have spent many moons doing computer security work and i cannot get a good idea of what your threat model is here.

in order to spend your coins, at some point the corresponding wallet must be on a computer, which i am assuming is offline in your threat model. in order to have some reasonable assurance that the computer's drive has not been tampered with while off, presumably stored in a safe or similar, you should use disk encryption. to suggest that disk encryption doesn't help reduce the chance of a compromise here is incorrect, afaict.

of course, if your machine is rooted, the attacker has DMA. the usual means of defeating keyloggers is authentication tokens, but that is only of limited use on an offline machine.

[runeks]

I'd like to share something that the poster losermcfail noted me of on Reddit: http://stephendnicholas.com/archives/310

This is basically an animated QR code, changing with 15 FPS, and he made an Android app that can read each frame and reconstitute the encoded data. At this rate it can transfer 43 KB/s, but I gather that with a larger QR code we'd be able to achieve a higher rate.

So if we can make a secure QR reader, we'd avoid the pitfalls of a USB stick.

[justusranvier]

So if we can make a secure QR reader

Just realize this is not a solved problem yet. Existing QR code applications and libraries do not appear to have been written with security hardening in mind:

http://www.kisc.meiji.ac.jp/~ethicj/USEC13/submissions/usec13_submission_02.pdf