Armory - Discussion Thread

[runeks]

I have a few questions regarding the security of Armory.

First of all, what kind of experience do you have in secure programming? I remember you said you were the one who found the "plain text key leak from encrypted Satoshi wallet"-bug. That's very impressive! Thanks for discovering this. Do you have a link that explains in detail what caused this bug? I've tried searching for an explanation of how this bug came to be, but I haven't been able to find anything.

I'm beginning to take an interest in computer security myself, so I'd like to know more about the design choices of Armory. Regarding the Python/C++ combination, is that related to the security of the final application, or is it just because it's easier/saves time?

[torusJKL]

Updated installation instructions are on Pastebin.
Building Bitcoin Armory on Mac OS X 10.6.x using Homebrew

I managed to make Armory running using homebrew to compile the dependencies on Mac OS X 10.6.8

The brew packages I installed

Code:

brew install python
brew install cryptopp
brew install swig
brew install sip
brew install qt
brew install pyqt

To get twisted for python2.7 install it using easy_install

Code:

easy_install-2.7 twisted

I had to set the following for the environment

Code:

export PYTHONPATH=/usr/local/lib/python:$PYTHONPATH
export CFLAGS="-arch x86_64"
export ARCHFLAGS="-arch x86_64"

I also had to create a symbolic link to point to the homebrew python 2.7 directory

Code:

sudo ln -s /usr/local/Cellar/python/2.7.2/include/python2.7 /usr/include/python2.7

and then compile swig

Code:

cd cppForSwig
make swig

[etotheipi]

torus,

That looks great.  You make it seem like it was so easy!  I think I'll be getting my hands on a Snow Leopard machine 10.6.7, so I will try these instructions when I get it, and I will update the webpage with this information, too.

Are you familiar with py2app?  I would like to create Mac binaries, if possible, and that seems like a good option for it, especially for Mac where compiling has been so difficult.  Are such binaries likely to work on all Mac systems?  Only 10.6.X systems?  


runeks,

I have quite a bit of experience with cryptography, but not specifically secure programming.  The python/C++ mix probably "hurts" security a bit due to not respecting the memory-management rules I designed into the C++ code (i.e. the SecureBinaryData container).  But I believe there are very few attacks that would be able to take advantage of sloppy python garbage collection that wouldn't also be able to take advantage of a solid, pure C++ solution -- if they have access to your local process-memory or DMA, you're pretty much screwed no matter what solution you have implemented.  There's a slightly higher risk that keying data could be left in memory and then written to swap space, but again, they would need low-level access to your HDD to get it, which again usually implies the whole system has been compromised.  In nearly all cases, if they can leverage one of those attacks, they already have enough access to the system to install a keylogger on the system, and then get your encryption passphrase and wallet next time you unlock.

The other major point of failure would be what you mentioned: actual wallet-encryption.  Here is the post about it, which I updated recently for-the-record:
    

• https://bitcointalk.org/index.php?topic=51474.0

This was the inspiration for Armory's wallet files, which were designed to be straightforward for other developers to implement, while at the same time guaranteeing in-place overwriting of key data, or blanking of deleted data.  I was frustrated with the difficulty of accessing wallet information, as well as the general uncertainty about how BSDDB was handling the data.  I figured, a manual binary solution, with error-correction and manual ACID-like operation was not terribly difficult.  Mainly because the access patterns for a wallet are much simpler than an arbitrary application:  usually only appending key data and comments, or overwriting data with equal-sized strings.

Some might say that your OS/filesystem might not actually delete stuff, and instead rewrite the whole wallet to a new location and leaving the old one (much like the BSDDB bug described in the other post).  The Bitcoin devs themselves acknowledge such concerns are outside the scope of the application.  They/I could spend months coming up with something 1% more robust against specific kinds of attacks, for a specific filesystem types, but in the end, the user error/laziness will dominate the security concerns.  

My attitude was that you should do everything you can to protect online wallets, but you'll never fully succed.  Enter offline wallets.  If the keys never touch the online computer, the available attack vectors are two orders-of-magnitude harder, and require much more specialized viruses.  Those might even be avoided by using pure visual communication (QR code exchange via dual webcams, or IR tx/rx of binary transaction information).  But in the end, I think that's tremendously more complexity than necessary to keep yourself secure (it would confuse people more than it would add security).

Finally, python development is about 3x faster than C++.   And it already took me 3-4 months, as-is, to produce the existing python codebase (the rest of the time was spent on the underlying C++ code).  I'm not sure if Armory would even exist if I hadn't done most of it in python.  I'm a patient person, but I'm not *that* patient (which means you should give a lot of credit to Satoshi, for having been able to do it by himself, and took him 2 years).

[runeks]

^ Interesting read all of it. I didn't find the post you linked to when I searched for the wallet encryption bug previously so that was very handy information.

It seems to me that Bitcoin is not only suffering from a lack of software developers, but also from a lack of hardware developers. The perfect savings account for me would be a small USB stick-type device, with a small screen, that with the touch of a button generates a new random key on the device. The USB stick contains no wireless communication chips - it only communicates with a host computer via USB. Whenever you want to spend money from your savings account (which is a key, or multiple keys, generated on this device) you connect the device to your computer, send a transaction to the device using some application, a message pops up on the device saying "Do you want to send X bitcoins to <address>" and if I press the OK button on the device it signs the transaction and sends it back to the host computer. The key never leaves the device; the device can only sign transactions. If we can implement a secure hardware device like this, the only way to steal the money on your savings account would be to steal the device itself. And if you have to steal the device itself, we can get no better security, if you ask me.

Until this type of device enters the market though, I'm going with your offline laptop-method. I've just paid for a used laptop that I'm going to be using as an offline wallet. I will pull the WiFi card out, install Ubuntu and Armory on it, and shuttle offline transactions to on a USB stick until I'm comfortable with sending my entire savings account to it. That seems like it can't get much safer either. Much like the aforementioned device, only a lot bigger and with a smell of old laptop.

[etotheipi]

It seems to me that Bitcoin is not only suffering from a lack of software developers, but also from a lack of hardware developers. The perfect savings account for me would be a small USB stick-type device, with a small screen, that with the touch of a button generates a new random key on the device. The USB stick contains no wireless communication chips - it only communicates with a host computer via USB. Whenever you want to spend money from your savings account (which is a key, or multiple keys, generated on this device) you connect the device to your computer, send a transaction to the device using some application, a message pops up on the device saying "Do you want to send X bitcoins to <address>" and if I press the OK button on the device it signs the transaction and sends it back to the host computer. The key never leaves the device; the device can only sign transactions. If we can implement a secure hardware device like this, the only way to steal the money on your savings account would be to steal the device itself. And if you have to steal the device itself, we can get no better security, if you ask me.

I believe what you're looking for is TPM Chips.  I don't know much about them, but I know a lot of laptops actually come with them.  However, you would need a customized TPM chip, specifically for accommodating multiple private keys, and ECDSA operations which are not usually part of the onboard encryption ops.  Actually, I guess you could have one master key, and use a deterministic key generation algoritm with random access.  Then the device takes the data to be signed, and a list of "key indices."  Then, generating the correct keys will just be a preprocessing step of the signing algorithm.  (btw, I believe the IronKey is a TPM-like device... all encryption/decryption happens on the device itself)

At least, the nice thing about an offline computer is that you could technically do other stuff with it.  It might be slightly less convenient for Bitcoin ops, but as long as you have it, you might as well do financial stuff on it that you would prefer to be offline, anyway.  I'm sure there's other things you can do that would be appropriate for a crappy, offline laptop

[mcorlett]

Yubico makes these Hardware Security Modules which may be suited to the task: https://store.yubico.com/store/catalog/product_info.php?products_id=56

[SgtSpike]

Would just like to say, that there NEEDS to be a wallet import option in the future for Satoshi wallets.  If I am going to use this wallet solely, I don't want to have to risk not getting payments made to my older addresses.  I don't care if you make it hard to get to, it just needs to be there somewhere.

I have a variety of old addresses everywhere.  I may or may not receive donations or payments to those addresses in the future.

Examples:
- Hard-locked deepbit mining payout address.
- Operation fabulous payout address.
- Firstbits address that I use for many transactions.  Also have it posted on the forum.
- Addresses hardcoded into software for donations.

You get the idea.  Anyway, I cannot switch fully over to armory until it has wallet.dat importing, so I hope you plan to have that option!

[cypherdoc]

It seems to me that Bitcoin is not only suffering from a lack of software developers, but also from a lack of hardware developers. The perfect savings account for me would be a small USB stick-type device, with a small screen, that with the touch of a button generates a new random key on the device. The USB stick contains no wireless communication chips - it only communicates with a host computer via USB. Whenever you want to spend money from your savings account (which is a key, or multiple keys, generated on this device) you connect the device to your computer, send a transaction to the device using some application, a message pops up on the device saying "Do you want to send X bitcoins to <address>" and if I press the OK button on the device it signs the transaction and sends it back to the host computer. The key never leaves the device; the device can only sign transactions. If we can implement a secure hardware device like this, the only way to steal the money on your savings account would be to steal the device itself. And if you have to steal the device itself, we can get no better security, if you ask me.

I believe what you're looking for is TPM Chips.  I don't know much about them, but I know a lot of laptops actually come with them.  However, you would need a customized TPM chip, specifically for accommodating multiple private keys, and ECDSA operations which are not usually part of the onboard encryption ops.  Actually, I guess you could have one master key, and use a deterministic key generation algoritm with random access.  Then the device takes the data to be signed, and a list of "key indices."  Then, generating the correct keys will just be a preprocessing step of the signing algorithm.  (btw, I believe the IronKey is a TPM-like device... all encryption/decryption happens on the device itself)

At least, the nice thing about an offline computer is that you could technically do other stuff with it.  It might be slightly less convenient for Bitcoin ops, but as long as you have it, you might as well do financial stuff on it that you would prefer to be offline, anyway.  I'm sure there's other things you can do that would be appropriate for a crappy, offline laptop

I believe I mentioned I do use Ironkeys to store my offline wallet.  It does have its own built in encryption chip along with a lot of other cool features.  I'd explain more but i'm on my phone now.  If anyone has questions about it I'd be happy to try and help.

[etotheipi]

Would just like to say, that there NEEDS to be a wallet import option in the future for Satoshi wallets. 

... I cannot switch fully over to armory until it has wallet.dat importing, so I hope you plan to have that option!

I absolutely plan to have that, but not until Armory can be used without the Satoshi client running with the same wallet.  I found out yet another thing that can go wrong when you have multiple apps using the same wallet (I've got 8.2 BTC locked by the Satoshi client right now, possibly due to such issues)...

[SgtSpike]

Would just like to say, that there NEEDS to be a wallet import option in the future for Satoshi wallets. 

... I cannot switch fully over to armory until it has wallet.dat importing, so I hope you plan to have that option!

I absolutely plan to have that, but not until Armory can be used without the Satoshi client running with the same wallet.  I found out yet another thing that can go wrong when you have multiple apps using the same wallet (I've got 8.2 BTC locked by the Satoshi client right now, possibly due to such issues)...

Ok. 

[mcorlett]

Would just like to say, that there NEEDS to be a wallet import option in the future for Satoshi wallets. 

... I cannot switch fully over to armory until it has wallet.dat importing, so I hope you plan to have that option!

I absolutely plan to have that, but not until Armory can be used without the Satoshi client running with the same wallet.  I found out yet another thing that can go wrong when you have multiple apps using the same wallet (I've got 8.2 BTC locked by the Satoshi client right now, possibly due to such issues)...

How can I manually import a private key? This is from a paper wallet and I accept any risks.

[runeks]

I believe what you're looking for is TPM Chips.  I don't know much about them, but I know a lot of laptops actually come with them.  However, you would need a customized TPM chip, specifically for accommodating multiple private keys, and ECDSA operations which are not usually part of the onboard encryption ops.

The problem here is that it's fine that we have a chip that does the signing without revealing the key. But I have no way of knowing if the program I'm using to create transactions that are signed is telling me the truth.
Say I want to create a transaction on my infected computer of 2 BTC to address 1Jks... and the modified program actually sends a transaction of 1000 BTC to address 1H4xor... to the TPM chip which happily signs it and my money is gone.
That's why we need to have a separate device that displays the address(es) and amount(s) from the transaction it's been sent before letting the user affirm with a button whether he approves or not.

How can I manually import a private key? This is from a paper wallet and I accept any risks.

Create a new wallet, go into "Wallet Properties" and click "Import Private Key".

I believe I mentioned I do use Ironkeys to store my offline wallet.  It does have its own built in encryption chip along with a lot of other cool features.  I'd explain more but i'm on my phone now.  If anyone has questions about it I'd be happy to try and help.

How does it work exactly; does it behave like the hypothetical device I explained above?

[etotheipi]

The problem here is that it's fine that we have a chip that does the signing without revealing the key. But I have no way of knowing if the program I'm using to create transactions that are signed is telling me the truth.
Say I want to create a transaction on my infected computer of 2 BTC to address 1Jks... and the modified program actually sends a transaction of 1000 BTC to address 1H4xor... to the TPM chip which happily signs it and my money is gone.
That's why we need to have a separate device that displays the address(es) and amount(s) from the transaction it's been sent before letting the user affirm with a button whether he approves or not.

That was the fundamental issue I had when developing BIP 0010 for offline/multisig transactions.  How do you verify that the what you're signing is absolutely what you intended?  I do not support a device that blindly signs txs, and that's why I went a step further with BIP 0010 and made sure that input values can be verified (without it, someone can't steal your money, but they can have all your funds emptied into your next transaction's fee).  I wanted to make sure that the signing device has the capability to understand (and verify!) what is being signed and present it to the user.  If someone wants to create a device that blindly signs it... well that's their choice, but I won't be using it.

In the case of offline computers, there might be a way for someone to use my computer to inject a USB virus which infects the offline computer, and then uses that trick my offline computer to show the same incorrect/malicious data.  That's orders of magnitude less likely than someone simply breaking into open ports on my internet connected computer, but a TPM-device would close that gap:  the TPM chip was designed without the ability to modify the software, and without the ability to pull off the private keys.  It's simply a hardware-like black-box wallet with a display. 

I believe Bitcoin needs these devices, but offline systems will do, for now.  As I found out when I sent out an email at my work about spare, ancient laptops:  everyone seems to have one they want to get rid of.  Perhaps Armory gives them a reason to keep it and use it

[torusJKL]

That looks great.  You make it seem like it was so easy!  I think I'll be getting my hands on a Snow Leopard machine 10.6.7, so I will try these instructions when I get it, and I will update the webpage with this information, too.

Are you familiar with py2app?  I would like to create Mac binaries, if possible, and that seems like a good option for it, especially for Mac where compiling has been so difficult.  Are such binaries likely to work on all Mac systems?  Only 10.6.X systems?  

I was trying to create a binary app with py2app but was not successful. It links to some python files that are not at the specified location.
I will keep trying but if someone else has more knowledge on how to do this then don't wait for me.
As for compatibility I guess it should be fine for 10.6.x and 10.7.x when compiled on 10.6.x.
If you compile a binary I can test it on both systems.

[...]
I believe Bitcoin needs these devices, but offline systems will do, for now.  As I found out when I sent out an email at my work about spare, ancient laptops:  everyone seems to have one they want to get rid of.  Perhaps Armory gives them a reason to keep it and use it

Given the ancient laptops have enough memory to keep the blockchain in RAM. :-)

[etotheipi]

[...]
I believe Bitcoin needs these devices, but offline systems will do, for now.  As I found out when I sent out an email at my work about spare, ancient laptops:  everyone seems to have one they want to get rid of.  Perhaps Armory gives them a reason to keep it and use it

Given the ancient laptops have enough memory to keep the blockchain in RAM. :-)

Actually, the offline systems have no RAM requirement at all, as long as it can run a modern OS.   Simply because there is no blockchain to hold.  It only has to hold your wallet.

[etotheipi]

Are you familiar with py2app?  I would like to create Mac binaries, if possible, and that seems like a good option for it, especially for Mac where compiling has been so difficult.  Are such binaries likely to work on all Mac systems?  Only 10.6.X systems?  

I was trying to create a binary app with py2app but was not successful. It links to some python files that are not at the specified location.
I will keep trying but if someone else has more knowledge on how to do this then don't wait for me.
As for compatibility I guess it should be fine for 10.6.x and 10.7.x when compiled on 10.6.x.
If you compile a binary I can test it on both systems.

The other option I saw was BundleBuilder.  That might be worth looking into as another option.  Unfortunately, I still don't have any OSX system yet.  But I'm working on it...

[bitclown]

Armory doesn't show my outputs from P2Pools generation transactions. Is this related to the "strange" output script that always appears first in these transactions?

[etotheipi]

Armory doesn't show my outputs from P2Pools generation transactions. Is this related to the "strange" output script that always appears first in these transactions?

Actually, yes!  Until now, I haven't run into any "strange" transactions that "regular" users would be encountering, but this appears to be an exception.  As I look back to the code, I see that once I hit a strange TxOut, the code skips the entire tx, marking it as "Non-standard."  In hindsight, I don't see why I can't just skip that TxOut and keep going.  When I originally wrote the code, I guess I expected the "transaction" to be non-standard or not... didn't consider the individual inputs and outputs.

Could you give me the address (just the address string, no private keys), of an address that receives coins from at least one of these transactions, but also has a few other regular transactions in the blockchain?  There may be a one-line fix to the C++ blockchain utilities, but I won't know for sure until I do some testing with a relevant address.  

I'll look into it ASAP! (PM it to me, so you don't have to advertise any extra addresses to the forum!)

[etotheipi]

Armory doesn't show my outputs from P2Pools generation transactions. Is this related to the "strange" output script that always appears first in these transactions?

Actually, yes!  Until now, I haven't run into any "strange" transactions that "regular" users would be encountering, but this appears to be an exception.  As I look back to the code, I see that once I hit a strange TxOut, the code skips the entire tx, marking it as "Non-standard."  In hindsight, I don't see why I can't just skip that TxOut and keep going.  When I originally wrote the code, I guess I expected the "transaction" to be non-standard or not... didn't consider the individual inputs and outputs.

Could you give me the address (just the address string, no private keys), of an address that receives coins from at least one of these transactions, but also has a few other regular transactions in the blockchain?  There may be a one-line fix to the C++ blockchain utilities, but I won't know for sure until I do some testing with a relevant address.  

I'll look into it ASAP! (PM it to me, so you don't have to advertise any extra addresses to the forum!)

It appears that there really is a one-line fix, or very close to it.  I confirmed it only saw 2/13 tx before, and sees 13/13 with the fix.   But it will have to be more thoroughly tested, so I'll throw it in with the other updates I've been working on, for the next round of testing.  I hope that Armory provides plenty of satisfaction even with the bug, until the next release.

[btc_artist]

I tried compiling and running Armory on Ubuntu 11.10 and got the following error.  I followed your instructions to the T, and get this:

Code:

********************************************************************************
Loading Armory Engine:
   Armory Version:       0.50
   PyBtcAddress Version: 1.00
   PyBtcWallet  Version: 1.35
Detected Operating system: Linux
   User home-directory   : /home/me
   Satoshi BTC directory : /home/me/.bitcoin/
   Satoshi blk0001.dat   : /home/me/.bitcoin/blk0001.dat
   Armory home dir       : /home/me/.armory/
***ERROR:  C++ block utilities not available.
           Make sure that you have the SWIG-compiled modules
           in the current directory (or added to the PATH)
           Specifically, you need:
                  CppBlockUtils.py     and
                  _CppBlockUtils.so
Traceback (most recent call last):
  File "ArmoryQt.py", line 39, in <module>
    from armoryengine import *
  File "/home/me/BitcoinArmory/armoryengine.py", line 330, in <module>
    TheBDM = Cpp.BlockDataManager().getBDM()
NameError: name 'Cpp' is not defined

Both of the files mentioned in the error message are in the BitcoinArmory directory (where I run python ArmoryQt.py).