I was just investigating USB auto-run vulnerabilities, and was surprised by the number of attack vectors that Ubuntu has (mainly due to tendency to "auto" do stuff for the convenience of the user, despite exposing attack surface).  I bet the USB viruses could be completely a non-issue if you compiled away all the auto-everything that is normally part of the kernel and/or desktop manager.  The only thing I want the USB key to do when I plug it in is mount automatically and don't do anything else (also disabling file browser icons, which were a source of previous vulnerabilities -- injecting code that exploits an evince bug into the icon of a file, which will automatically get loaded when the file browser pops and up loads the icons to display the files).  

I never considered that the answer to remaining attack surface of the USB method could just be a custom-compiled distro...

Of course, I have no experience with that, but I'm sure someone else does

Many times you can disable all that stuff in the BIOS and don't need a special kernel.  If the devices are disabled at the hardware level, it doesn't really matter if the modules are there or not

Glad it worked for you!  I'll see if I can tie that into a Makefile update somehow.

Please excuse me that I don't speak Russian, but I will answer your question based on google translate's version of your post

The "root key" is the first private key in your wallet.  Since Armory wallets are "deterministic" all other private keys are based on that first key, and Armory uses an extra piece of information ("chain code") to get the next private key in the sequence.  The chain code can also be used with the first public key to produce the next public key in the sequence without knowing the private key. 

Therefore:
The first private key + chaincode makes up your full wallet
The first public key + chaincode makes up your watching-only wallet


Here's google translate back into Russian for you!

I made Armory for doing exactly this.  Create the full wallet offline, create a watching-only copy to put online (main computer and/or webserver).  The watching-only wallet only has public keys.  And it can generate an infinite number of new public keys, for which the offline computer has the private keys.  And using the interface, you can manually execute transactions using a USB key to take a transaction to the offline computer for signing.  It takes about 60 seconds to move the coins.

There's more information about using Armory via python scripts in this thread.
And more information about offline wallets on the website.

There's lot of other great benefits, such as being able to print off a backup once that protects your wallets forever (no matter how many addresses you generate).  Please PM if you have questions.  This use-case was my inspiration for making Armory.

The coins aren't lost, but they can be "stuck".  Your client declares the coins spent, but the network doesn't ever include it in the blockchain.  By default, you can't send the coins elsewhere, because the client doesn't believe you own them anymore.   However, if you clear your client's memory pool,  or can import your wallet into another program, you can try re-sending with a higher fee.  Once that new transaction makes it into the blockchain, then your client will see that and invalidate the old transaction.

Also, I have no intention to bash bitcoinj, but I'm curious why the fees aren't implemented yet..?  The way I did it in Armory is very simple and seems to work very reliably.  It's also very close to what the network expects (ignoring block-fill considerations).  Here's the relevant code in Armory.

In order for a transaction to be free, three conditions must be met:

--Transaction is less than 3.5 kB (approx)
--Transaction does not have any dust outputs (<0.01 BTC)
--Transaction inputs have priority-sum greater than 1 bitcoin-day-per-250-bytes

If the transaction cannot be free, then use the folllowing fee:
--If transaction is less than 3.5 kB, use fee 0.0005 BTC
--Otherwise, use (0.0005 * roundup(numkB))

There are more fees required to get it into the next block, if there's already a lot of transactions being included in the next block.  But this fee will always get it included in one of the next blocks.  So far, I haven't experienced any users (or myself) getting coins stuck in Armory.  

It is, and people do it.  I keep forgetting to go into the Makefile and try to figure out how to auto-detect this situation to avoid these problems.

For now, I believe you can just change any libpython2.X.a to libpython2.X.so in the Makefile.  I think that's what other non-Ubuntu compilers have been doing.

And before you ask why I'm static compiling:  it's because the compiled swig module depends on the version of python being used at runtime.  If I compile the .deb packages to distribute to users with dynamic python linking, then it only works for users that have the same version of python on their system.  This caused endless problems in the past.  However, for compiling it for yourself, it doesn't matter. 

(1) Of course it's possible to do this, but I never figured it out using the MSI-creator program I'm using (War Setup).  It can't be hard, I just have to dig through the options.  I'll add that to my list of things to look into next time I'm waiting for something to compile.

(2) The 64-bit version is not a testing version.  It's part of the official release.  In the past, Armory didn't work on 32-bit OS except for offline mode, so I always compiled two different versions.  Only recently did I realize that the 32-bit version (which now works online, too) works on 64-bit Windows, so why bother compiling them separately anymore?  I was asking users to help me test the 32-bit version in 64-bit Windows to make sure that there was no surprises.  In the near term, though, I will continue compiling both for official releases, until I am sure that there is no issues running the 32-bit version on 64-bit OS.

The client won't always construct a "repeat" transaction the same way.  If it's multiple devices, they will probably use different change addresses.  Sometimes it's just the user re-creating a tx that didn't go through and the client will reconstruct using different inputs and a different change address.  If you assume that the one output that changed is the change address, well that could just be someone keeping their change address the same but swapping the intended recipient.  In other words, there's no way to distinguish legit double-spends from accidental.

Btw, I actually implemented a double-spend detector in Armory.  Basically to provide a warning that conflicting transactions were received and it's especially important for the user to wait for 6 confirmations.  Besides the fact that it doesn't in Armory (because it goes through the Satoshi client which drops any conflicting transactions so Armory never sees them), gmaxwell pointed out a very potent argument about how "bad people" will get around this.

(1) Someone sets up a special (dark) mining pool which controls some proportion of the global hash rate (say 5%). 
(2) This pool does not forward any transactions.
(3) Users who pay to be part of this pool get an app that, for every tx they send, it also sends the pool a replacement transaction to start mining
(4) The recipient will never see the double-spend because it doesn't get forwarded
(5) 5% of the time they succeed
(6) Because there is no extra effort to do this for one transaction vs thousands, there will necessarily be services that pop up and can offer people this service for dirt cheap.  Not to mention they get money for mining. 

In other words, it's not unreasonable to believe, that large swaths of users would contribute to such a pool because they get 5% off everything and it hardly costs the pool anything once it's setup.

It's not the same effectiveness as double-broadcasting regularly, but it is a credible equilibrium point of the system/economy.

Fantastic!  This is one step up for those users who want offline wallets, but can't find an old laptop, or don't want to deal with an old laptop ... $35 for a RaspberryPi is pretty awesome.  Plus, it might be fun to mess around with it (for some of us ).  However, my understanding is that supply is limited, so it may be many weeks before new customers can get their hands on one...

On a slightly-related note, I just got a request about improving USB security on offline linux machines.  I don't know what window manager is used by default on the RPi, but I bet the process is similar.  I posted a starter discussion about it in the "Improving offline wallets" thread.  Any extra recommendations are welcome!

Also:  thanks for the patch and instructions, Filo!  It looks like it will be fairly easy to integrate most of the updates directly into the project.

Along the lines of improving USB-based Armory, I stumbled on an article that had good advice for disabling autorun stuff in Linux.  This is something worth doing if you are using Ubuntu/Gnome on your offline machine.  In fact it is quite simple, and provides a lot of extra security for very little effort.

Open a terminal and type "gconf-editor".  You'll end up with something that looks like the Windows registry. Navigate through the tree:  apps->nautilus->preferences.  There are 2 media-related keys that should be modified:

   media_automount_open  (OFF)
   media_autorun_never (ON)

The automount_open basically determines whether nautilus will open a file browser when the USB key is inserted.  This was the source of a small vulnerability at one point, and it's been patched, but for offline wallets you don't need it anyway.  

autorun_never should be self-explanatory:  there's a whole host of things that the system will try to do as a convenience to the user, when you insert media with images, videos, audio, etc.  There's no need for any of it, though, unless you want the convenience of being able to pop a DVD into your offline computer and watch it "offline"  However, it sounds like nothing really auto-runs anyway quoting the article:


You could also disable automount, but that is actually quite useful, and you have to mount the drive anyway when you insert the USB key.  There might be an advantage to doing it manually, I don't know.  Since I don't know if it's actually useful, I won't go through the process of explaining it, because it can be complicated depending on the USB filesystem and device ordering (in other words, I wouldn't do it unless you already know all the command line calls for it).


For windows, there is Panda USB Vaccine.  You can use it to hard-disable the autorun.inf file, such that a program needs to reformat the drive to put anything useful in there.  It also applies a set of removable-media settings on your Windows computer, to disable mostly-unnecessary operations when a key is inserted.

Any other recommendations are welcome!

Admittedly, there aren't many brands that have a write-protect switch: we use them at work all the time (a requirement on some systems).  So it's possible, but I don't know how much it would improve security...


Admittedly, I considered this idea seriously before determining that there was increased risk for many users, instead of decreased.  The ubiquity of drivers and subsystems that automatically run on serial ports on many systems is scary.  I was surprised to find out that some flavors of linux will allow telnet/ssh sessions by default over serial, even an IR link!  Obviously, things can be done to avoid this, but I don't know if it's the best idea to recommend to the general user that may not take the appropriate precautions to prevent it.

My ultimate goal will be to team up with someone and make a dedicated device that only receives transactions, shows confirmation on a little screen and waits for a button press, and spits out signatures.  No way to pull the keys out of it.  It would basically be a handheld TPM.  However, I'm a long way off from that.  Until then, I might look into the audio-coupling idea jim618 proposed. 

In the meantime, this device may provide those with a lot of money to spend on protecting their coins, some improvement.  I just have to have Armory display a QR code containing the necessary signatures once it is signed.

This might be an expensive but effective way to execute offline transactions with Armory, but you would need two of them.  Since you need to send the offline computer the transaction, and then send the signature back.  (but it's not really different than the manual ways that people attempt to synchronize the blockchain with the offline computer...)   

The only problem is that there will be the few transactions that will require dozens of bar codes... could be annoying.

Perhaps the best thing to do is get a USB key with a write-protect switch.  Use that to transfer offline-transactions to the offline computer, and then use this device to send the signatures back to the online computer.  The signatures are almost guaranteed to fit in a single bar-code, though the original transaction will not.  This would remove a large portion of the attack surface, since most attacks on Armory cold storage would be through USB drivers of some sort.  A virus can't write your private keys to the USB if it's write-protected...

Ahh, perfect.  I should've known that GPG keys were not "accepted" in the MS world.

The blog article you linked is old, but it is good discussion.  There's definitely no more $80/yr special, it looks like $180/yr to get a signing certificate.  It's probably worth swallowing my pride, and paying into the system and move on with life.  After all, I did receive a lot of donations, I guess this is an appropriate thing to spend that on

I wonder if I can generate my own certificate, offline, and send them the public key to sign...?  Do you know if they always generate the full key for you?  I'd prefer that no one else has the private key, but maybe that's a level of service I can't expect at the <$200/yr level.

Someone just asked me how to verify the digital signatures on the above packages.  

I don't know how to do this in Windows without installing bloat-y software.  But it's built-in, in Linux, and it's quite easy.  And once you have the Armory public key downloaded and imported to your offline computer, it's one command to verify the signatures.  

NOTE: if someone knows how to "build-in" a GPG signature into a Windows installer (*.msi file), that would be great.  For now, I'm just signing the hash of the .msi file.

---

Use linux to verify the authenticity of the Armory installers you download

• (1) Download the Armory Signing Public Key.  It can also be retrieved via a public key server.  Just search for "Armory" and you will find it.
• (2) Download the installers you want to verify (links at the bottom of this post).  You only need the md5.asc file (signed MD5 hashes) if you want to verify the Windows installer
• (3) Put all the downloaded files onto a USB and take to your offline linux computer (skip this step if you're already in Linux!)
• (4) Go to Applications-->Accessories-->"Passwords and Encryption Keys".  Go to File-->Import....  Select the Alan_C_Reiner_ArmorySigningPublic.asc
• (5) VERIFY THE KEY ID: Once the key is imported, click the "Other Keys" tab.  You should see:  Alan C. Reiner alan.reiner@gmail.com 'Armory Signing Key' | 98832223 .   Do not continue if it does have 98832223! (backwards, that is 32223889)

Now the key is imported and you can skip the previous steps on future releases.  Here's how to verify the *.deb files:

(1) Open a terminal, and navigate to the USB key where the installers are located (probably /media/usbkey or something like that)
(2) To verify the *.deb files, type "dpkg-sig --verify *.deb".  You should see something like this:

The "GOODSIG" is all you need!  To verify the windows MD5 hash file, you use regular GPG:


The MD5 file is now confirmed to be legitimate.  The last thing is to make sure the .msi file has the same hash as is listed in the .md5.asc we just verified:


If you open the md5.asc file, you will see the hashes for each of the files:



Here's the download links:
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-alpha_win32_and_win64.msi
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-1_amd64.deb
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-1_i386.deb
Signed MD5 hashes (mainly for Windows; the *.deb files have the signatures built-in)

Sorry to keep harping on this but this is exactly why I made Armory.  As far as I know, there is just no simpler, safer way to use offline wallets than using Armory.   I use a 10-year-old laptop for the offline wallets, but the Raspberry Pi is the perfect compliment to Armory:

Setup offline wallet:
(1) Generate Armory wallet on offline machine (Raspberry Pi)
(1a) Print off a paper-backup of the wallet:  all coins can be recovered any time in the future with the 64-bytes on one sheet of paper (not encrypted)
(2) Click "Create Watching-Only Copy", import to online computer (no private keys)
(3) Online computer can now generate infinite number of payment addresses and monitor incoming transactions/payments
(4) Online computer only has public keys, wallet cannot be compromised.

Even if other solutions/methods succeed in the above, nothing is easier than Armory for spending those coins:
(1) With the watching-only wallet, click "Prepare Offline Transaction"
(2) Fill out transaction exactly as you would with a regular wallet.  It will ask you to save it to a USB key.
(3) Take USB to offline computer and go to "Sign Offline Transactions"
(4) Review transaction, sign it, it will add the signature(s) to the transaction on the USB key
(5) Take back to online computer and broadcast

You can generate infinite addresses/public keys, and monitor incoming transactions just as you would a full wallet.  And it takes less than 60 seconds to execute a transaction (once you have some practice).  Quite a bargain for the peace of mind that your private keys have never been near an internet connection.  Also, the wallets are encrypted using AES and scrypt-based key-strengthening.  And your single paper-backup protects you for forever (minus imported private keys).

Armory is technically still in alpha, but it's due to setup and usability concerns, not security or stability.  In the 8 months since Armory has been public, and with 1,500 downloads per month, still no reports of anyone ever losing money with it.  Some users have reported using Armory with 10K+ BTC.  It will be beta soon, but most users treat is as beta+ already.   (P.S. - of course Armory is OSS and comes with the usual "I am not liable for anything" clauses, I'm just commenting on its track record)

The point of this story:
(1) If you want cold storage, look into Armory
(2) If you want cold storage, but don't want to deal with laptops, RaspberryPi will soon be your answer
(3) Someone will soon be posting instructions for using it on RPi

Someone just contacted me to let me know he got Armory running offline on the Raspberry Pi.  He emailed to ask if I can get him off the newbie list so he can post:

https://github.com/etotheipi/BitcoinArmory/issues/19

If you can get ahold of him, see if you can get him to post here, then give him the bounty





Steve, you should really look into Armory.  You can do everything you just requested with it, except for the encrypted QR-code thing.  But if you're going to backup the encrypted version online, you might as well just make a copy of the encrypted wallet.  It uses scrypt-based key-strengthening as part of the encryption.  Or grab the rootkey and chaincode, and encrypt it yourself, however you see fit.

As for the second point, I recently added a feature in Armory in Expert-usermode.  It allows you specify your change address for each transaction.  You can either use two recipients -- the recipient + your other offline wallet, and use the "MAX" button to specify your remaining balance to your other wallet after you've entered the recipient.  Or you can specify the recipient only, and use the options on the bottom left to specify the change (which will not necessarily sweep the entire balance, but only send the change from the transaction to the new wallet).

I finally got 64-bit Windows VM back up.  I can now compile 64-bit apps again.  However, I'd like to keep all Windows users using 32-bit, if it doesn't cause problems...

Windows users:  please use the 32-bit version unless you have problems with it.  If you experience an issue with the 32-bit version on 64-bit windows, please install the 64-bit version only to check whether the problem goes away.  If the problem goes away, please report it here, and I will go back to making separate versions for 32- and 64-bit windows.

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-alpha_win64.msi

Fwhew!  Please don't hesitate to tell me if things are working, since I usually only hear when things are not working, and get stressed out that Armory is falling apart!  So, thanks Molec!

No there is not, but fear not, the next major release (with multi-threading) will do away with the splash screen completely!  I'm just finishing butchering the code base to get the multi-threading code implemented.  There will be lots of testing, but hopefully only another week or two before it's done. 

---------

Bugfixes Bugfixes Bugfixes
Version 0.82.4-alpha

Three fixes:  Network fix (already in 0.82.3), URL handling, and some issues with the send & receive buttons on the main window.

Also:  I'm testing signing the installers again with my offline GPG key.  Please test it -- details at the bottom of this post!


http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-alpha_win32_and_win64.msi
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-1_amd64.deb
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-1_i386.deb

I'm continuing to get reports of strange behaviors in Windows.  Perhaps the Win32 version doesn't actually work as well on Windows 64-bit...?  If you are currently using an old 64-bit version and it does work, then please try this one for me.  I need some empirical evidence to suggest whether this is a good or bad idea!

---

You should be able to verify the following signature with the Armory Signing Key (98832223) (which should also be distributed to the major key servers by now, so you don't have to trust a forum link if you don't want to):

The signed MD5 hashes are below: or download it directly, here