Topic: Improving Offline Wallets (i.e. cold-storage) - page 3. (Read 19605 times)

I never said that disk encryption is pointless.  But Armory already encrypts your wallet, and guarantees that if your wallet is created encrypted, the unencrypted keys never touch the disk.  By all means, you need encryption, but full disk-encryption is mostly redundant here.  In fact, in some environments, it's inferior -- if you were to use full-disk encryption and unencrypted wallet files, then you are protected the same when your computer is off but the encryption is completely useless while the computer is on (so it can run the OS and access your files).  Someone who gets on your compute for 1 minute can put in a USB key, and copy off the [unencrypted] wallet file to their key.  Ditto for serial.    At least with Armory encryption, the file on disk is always encrypted and inaccessible even when the computer is unlocked. 

The counterpoints to these thoughts are:  just hedge and use both -- disk encryption and Armory encryption.  And in the end it may not matter--anything advanced enough to get to your offline system is probably advanced enough to pull your private keys out of RAM when you unlock your wallet to sign a transaction.  No disk encryption can protect against that.

The security environment is this:  you have an offline computer setup securely, and it has not been compromised in any way.  You have a verified version of Armory installed and know it works perfectly (of course).  However, you assume an attacker has full control of your online computer, and knows you will be using to move data back and forth between your [compromised] online computer, and you're not-yet-compromised offline computer.

If it's a serial connection that's not done correctly, they grab your Firefox password file and try every entry to TTY login to the offline machine.  Once there, they grab the encrypted wallet, and start trying to brute force it (probably also related to one of your firefox passwords...).  Or if that's not enough, they keylog your passphrase and send it back over the serial line to the online computer (which is compromised).

Similarly, if your transfer method is USB keys, there's undoubtedly lots of ways to exploit autorun.  Put a carefully crafted file on the USB key with a payload that gets executed when you plug in the USB key, and it carries your wallet out with it when the user brings the USB key back to their online computer. 

Any mention of Armory flaws, or initial install security is mostly out-of-scope.  We assume the user installed the correct software offline and that the software itself performs exactly as expected. 

Heh.  Autorun.

Also, why do you assume that you have total control over what gets written?

Has anyone mentioned burning the transaction files to CD-R or CD-RW to transfer them between the online and offline computer?  Given that you control exactly what files will be burnt to the disc and that it's finalized/locked immediately afterward, isn't that one way to achieve certainty that you aren't accidentally transfering malicious files between the two machines?

I know it's not an ideal solution, but it's a solution nevertheless and seems pretty simple for the overly-protective user.

Thoughts?

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

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.

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.

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.

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).


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.

@ 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, 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 

@etotheipi:  Thank you for the clarifications.

@ 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 [email protected], 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.

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.

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.

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)

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?

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.

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

Before long malware is going to start targeting Armory directly.

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.

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.