Armory - Discussion Thread

[SimonBelmond]

I don't know somebody wrote to here or not.
But i think the Armory and other programs could have a potential vulnerability.

For example what if your computer with installed Armory (watch-only wallet mode) is infected and trojan/virus which modifies a receiving address in Armory's interface? How can i trust to my online watch-only computer that all generated addresses are my addresses? What if trojan/virus modifies installed DLLs/Shared libraries of Armory and substitute watch-only generated addresses or seed to hacker things? If i will send to money to generated address how can i sure that this address is my address for private key at offline computer? :-/

What do developers think about this?

I jsut double check the address before broadcasting. That's more or less all I can do. Of course you could take appart the unsigned and signed transaction before broadcasting. However, as long as I don't hear anything else I consider it safe enough...

[1714167054]

1714167054

[1714167054]

1714167054

[1714167054]

1714167054

[segeln]

What about antimalware/antiviruses programs like Norton,kaspersky,avira.Mc affee?
Could they detect those malicious software,when they are widespread and known ?

No.

USB firmware exploits happen outside the control of the CPU and any software that may be running on it.

For now, you should probably use CD-Rs to move unsigned transactions across the air gap discard them after each use.

There might not be any exploitable CD drive firmware vulnerabilities that can be triggered by malicious data on a disc. Maybe.

thanks,justusranvier

[Newar]

What about antimalware/antiviruses programs like Norton,kaspersky,avira.Mc affee?
Could they detect those malicious software,when they are widespread and known ?

No.

USB firmware exploits happen outside the control of the CPU and any software that may be running on it.

For now, you should probably use CD-Rs to move unsigned transactions across the air gap discard them after each use.

There might not be any exploitable CD drive firmware vulnerabilities that can be triggered by malicious data on a disc. Maybe.

There's audio too, easier on the planet: https://bitcointalk.org/index.php?topic=735111.0

[cypherdoc]

Stupid (maybe not) question.

I want to update Armory, should I update Bitcoin Core as well?

You don't have to but latest core is more critical than latest armory

so latest Bitcoin Core is compatible with ARmory 0.92.1?

[bitpop]

Stupid (maybe not) question.

I want to update Armory, should I update Bitcoin Core as well?

You don't have to but latest core is more critical than latest armory

so latest Bitcoin Core is compatible with ARmory 0.92.1?

Yeah the bitcoin rpc i dont think ever had deprecation

[Perlover]

I jsut double check the address before broadcasting. That's more or less all I can do. Of course you could take appart the unsigned and signed transaction before broadcasting. However, as long as I don't hear anything else I consider it safe enough...

I am about getting from Armory the address for receiving bitcoins. It's not neeeded for broadcasting...
As i think you about a sending of bitcoins...

[Ente]

I don't know somebody wrote to here or not.
But i think the Armory and other programs could have a potential vulnerability.

For example what if your computer with installed Armory (watch-only wallet mode) is infected and trojan/virus which modifies a receiving address in Armory's interface? How can i trust to my online watch-only computer that all generated addresses are my addresses? What if trojan/virus modifies installed DLLs/Shared libraries of Armory and substitute watch-only generated addresses or seed to hacker things? If i will send to money to generated address how can i sure that this address is my address for private key at offline computer? :-/

What do developers think about this?

I totally agree on that.
So, I try to pay a bitcoin to my landlord.
How do I get his adress? Via his website, or mail, or I noted it down in my Armory adressbook.
All of these can be easily replaced, without noticing, by malware.
Malware might also change stuff so the change adress isn't mine, but his. Not sure about that though.

That is no Armory-specific or even Bitcoin-specific problem. Same problem arises with regular bank account transfer, if I don't know the account details by heart.

The only thing Armory can secure, and does so well, is that you only lose that one transaction. As soon as your landlord kicks your butt, you know something is wrong with your computer. All other coins should still be safe on the offline computer.

Please, someone tell me what I overlooked here?

Ente

[cypherdoc]

can someone remind me how to check the signature of the offline *.deb installer?

i'm able to check the sha256sum of the initial downloaded *.tar.gz file but can't remember how to check the sig. is it done on the online or offline computer?  

Edit: running the dpkg-sig against the armory*.deb extracted from the *.tar.gz for 0.92.1 is unsuccessful.

[etotheipi]

can someone remind me how to check the signature of the offline *.deb installer?

i'm able to check the sha256sum of the initial downloaded *.tar.gz file but can't remember how to check the sig. is it done on the online or offline computer?  

Edit: running the dpkg-sig against the armory*.deb extracted from the *.tar.gz for 0.92.1 is unsuccessful.

I'll have to double-check the release scripts.  It's possible that it's bundling the .deb before it signs it.  If that's the case, then just grab the correct .deb not from the offline bundle.  It's the same thing, but should be signed.   

On the other hand, if you check the hashes file, that will be accurate.  That lists the hash of the tar.gz with whatever .debs are in there, signed or not.  Even though the .deb itself was not signed, the bundle was created on the same secure machine, hashed, and put in the sha256 file which is signed.

[etotheipi]

Armory Version 0.92.3 Released

We have officially released 0.92.3.  It's not on the website yet (that's not automated in our release process yet), but it will be shortly.

This release not only officially brings the Tor/Privacy fix out of testing, it also fixes a rather scary-but-actually-benign bug that we found in the Armory code related to random number generation when signing Bitcoin messages (not transactions, just message signing).  For more details about this, read the full report here:

https://s3.amazonaws.com/bitcoinarmory-media/CVEs/ArmoryCVE-2014-002.pdf

Armory Tech has pretty thoroughly investigated the incident and believes that no action is needed by anyone, even if you have signed thousands of messages.  Armory Technologies itself would be the most vulnerable since we use that feature to sign all of our releases.  We have determined that no exposure has occurred and still consider our offline signing key 100% safe.  Nonetheless, we have fixed the issue in this release.

Before asking lots of questions please read the above PDF which I spent an exceptional amount of time writing.  It is extremely thorough, both in terms of our own analysis and concerns raised by Sergio Del Lerner, whom we contacted to provide an independent third-party opinion.  We also posted this to the our recently-formed Security Working Group and received positive feedback from two members, and no one raised any concerns about the analysis.

On that note, here's the download links for the new version, but as always, we encourage you to use the secure downloader to get the new version if possible  (at this point most people should have 0.91+ and can use the secure downloader).


  Armory 0.92.3 for Windows XP, Vista, 7, 8+ (32- and 64-bit)
  Armory 0.92.3 for MacOSX 10.7+ (64bit)
  Armory 0.92.3 for Ubuntu 12.04+ (32bit)
  Armory 0.92.3 for Ubuntu 12.04+ (64bit)
  Armory 0.92.3 for RaspberryPi  (armhf)


  Armory 0.92.3 Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.92.3 Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.92.3 Offline Bundle for RaspberryPi  (armhf)

  Armory 0.92.3: Signed hashes of all installers



GOOD NEWS:  The latest Bitcoin Core release relaxed the isStandard() logic, so you should be able to up to 7-of-7 Armory Lockboxes on mainnet.  I haven't actually tested this, but I expect by now that a critical mass of miners have upgraded to Core 0.9.3, so spending 7-of-7 (or smaller) coins should work. 

The only requirement is that you upgrade your own version of Core to 0.9.3 -- which has been updated in the secure downloader as well!


Other fixes: 

• URI handling bug fix (Coinbase-generated links were not working with Armory)
• Raspberry Pi install script and offline bundle was hosed.  Some empty debs have been replaced, and the double-click script should work properly now.  Please test it out for me!
• The Ubuntu offline bundles have been upgraded to support 12.04.5 now (since 12.04.3 was difficult to find).

[K1773R]

Armory Version 0.92.3 Released

We have officially released 0.92.3.  It's not on the website yet (that's not automated in our release process yet), but it will be shortly.

This release not only officially brings the Tor/Privacy fix out of testing, it also fixes a rather scary-but-actually-benign bug that we found in the Armory code related to random number generation when signing Bitcoin messages (not transactions, just message signing).  For more details about this, read the full report here:

https://s3.amazonaws.com/bitcoinarmory-media/CVEs/ArmoryCVE-2014-002.pdf

Armory Tech has pretty thoroughly investigated the incident and believes that no action is needed by anyone, even if you have signed thousands of messages.  Armory Technologies itself would be the most vulnerable since we use that feature to sign all of our releases.  We have determined that no exposure has occurred and still consider our offline signing key 100% safe.  Nonetheless, we have fixed the issue in this release.

Before asking lots of questions please read the above PDF which I spent an exceptional amount of time writing.  It is extremely thorough, both in terms of our own analysis and concerns raised by Sergio Del Lerner, whom we contacted to provide an independent third-party opinion.  We also posted this to the our recently-formed Security Working Group and received positive feedback from two members, and no one raised any concerns about the analysis.

On that note, here's the download links for the new version, but as always, we encourage you to use the secure downloader to get the new version if possible  (at this point most people should have 0.91+ and can use the secure downloader).


  Armory 0.92.3 for Windows XP, Vista, 7, 8+ (32- and 64-bit)
  Armory 0.92.3 for MacOSX 10.7+ (64bit)
  Armory 0.92.3 for Ubuntu 12.04+ (32bit)
  Armory 0.92.3 for Ubuntu 12.04+ (64bit)
  Armory 0.92.3 for RaspberryPi  (armhf)


  Armory 0.92.3 Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.92.3 Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.92.3 Offline Bundle for RaspberryPi  (armhf)

  Armory 0.92.3: Signed hashes of all installers



GOOD NEWS:  The latest Bitcoin Core release relaxed the isStandard() logic, so you should be able to up to 7-of-7 Armory Lockboxes on mainnet.  I haven't actually tested this, but I expect by now that a critical mass of miners have upgraded to Core 0.9.3, so spending 7-of-7 (or smaller) coins should work. 

The only requirement is that you upgrade your own version of Core to 0.9.3 -- which has been updated in the secure downloader as well!


Other fixes: 

• URI handling bug fix (Coinbase-generated links were not working with Armory)
• Raspberry Pi install script and offline bundle was hosed.  Some empty debs have been replaced, and the double-click script should work properly now.  Please test it out for me!
• The Ubuntu offline bundles have been upgraded to support 12.04.5 now (since 12.04.3 was difficult to find).

when can we expect a git update + signed tag?

[laurentb]

when can we expect a git update + signed tag?

Yes, please provide at least a git tag.
A while back I asked for simple tarballs, but at least with the git tag I can get them from GitHub.
You're making it impossible for distribution packagers - and this is why 0.92.2 didn't end up in the Gentoo Overlay.

[josephbisch]

Yes, please provide at least a git tag.
A while back I asked for simple tarballs, but at least with the git tag I can get them from GitHub.
You're making it impossible for distribution packagers - and this is why 0.92.2 didn't end up in the Gentoo Overlay.

I agree. I am working on getting Armory into Debian and the git tag or a tarball makes my job easier.

[RoadStress]

The only requirement is that you upgrade your own version of Core to 0.9.3 -- which has been updated in the secure downloader as well!

I have an issue with 0.9.3 because this thread https://bitcointalk.org/index.php?topic=799967.msg9017618#new seems to have stopped. I haven't bothered to learn how to check the sigs on the bitcoin Core and that thread made me realize that I don't know who signs the bitcoin Core client. I will not touch my Core client until I figure stuff out.

[etotheipi]

About the git tag... that's coming.  0.92.2-testing got about zero people testing it, so I never did a real release of it until 0.92.3 came along and I decided to skip the 0.92.2 release and focus on that.  Furthermore, my release script failed to create the signed tag, and I decided I would fix it later rather than further delaying the release.

I'll see if I can get the signed tag out today.  Sorry for the delay.

As for the 0.9.3 signatures:

http://pgp.mit.edu/pks/lookup?search=laanwj%40gmail.com&op=index

Wladimir has taken over the Core release signing process.  It used to be Gavin (0x1FC730C1), but this time the SHA256SUMS file is signed by Wladimir's key (0x2346c9a6).  I trust that key because it is signed by Gavin's key (0x1FC730C1) which has been used for every prior release as far back as... 2011?

I have checked the signatures on all Core downloads and have made them part of the Secure Downloader within Armory, so you can download them without having to check the signatures.  If you trust me to check the signatures properly then you can trust the downloads in the Secure Downloader.  This is one of the reasons I made the secure downloader, to transfer some of the burden of checking signatures from you to me!

[cypherdoc]

If that's the case, then just grab the correct .deb not from the offline bundle.  It's the same thing, but should be signed.  

On the other hand, if you check the hashes file, that will be accurate.  That lists the hash of the tar.gz with whatever .debs are in there, signed or not.  Even though the .deb itself was not signed, the bundle was created on the same secure machine, hashed, and put in the sha256 file which is signed.

in regards to a fresh install of offline bundle:

hash is good for *.tar.gz:

Code:

cypher@ubuntu:~/Downloads$ sha256sum armory_0.92.3_offline_ubuntu_12.04-32.tar.gz 
1702a46db8263411ca0e639943f7e7cf33ad8dea365c9252457b8288b149c057  armory_0.92.3_offline_ubuntu_12.04-32.tar.gz

but, if not in the extracted Offline Bundle folder, where do i grab the armory_0.92.3_offline_ubuntu_12.04-32.deb against which i can run the dpkg-sig --verify *.deb?

[etotheipi]

If that's the case, then just grab the correct .deb not from the offline bundle.  It's the same thing, but should be signed.  

On the other hand, if you check the hashes file, that will be accurate.  That lists the hash of the tar.gz with whatever .debs are in there, signed or not.  Even though the .deb itself was not signed, the bundle was created on the same secure machine, hashed, and put in the sha256 file which is signed.

in regards to a fresh install of offline bundle:

hash is good for *.tar.gz:

Code:

cypher@ubuntu:~/Downloads$ sha256sum armory_0.92.3_offline_ubuntu_12.04-32.tar.gz 
1702a46db8263411ca0e639943f7e7cf33ad8dea365c9252457b8288b149c057  armory_0.92.3_offline_ubuntu_12.04-32.tar.gz

but, if not in the extracted Offline Bundle folder, where do i grab the armory_0.92.3_offline_ubuntu_12.04-32.deb against which i can run the dpkg-sig --verify *.deb?

I'm saying, if you verified the hash, that's all you need to do.  The signed hash and the signed .deb file come from the same secure environment. 

The .deb in the bundle was supposed to be signed, but strictly unnecessary if you check the signed hashes file.  Alternatively, you could skip the signed hashes, and just grab the .deb from the website (not the offline bundle), verify that with dpkg-sig, and then copy it into the bundle. 

But the signed hashes is better, since the hash covers every file in the .tar.gz, not just the .deb.

I know it's confusing, because there's many ways to check the validity of these things.  What I can tell you is that:

(1) If the signed hash is correct, everything in the archive is good
(2) Alternatively, get it from the secure downloader.  You can download any of the releases for any OS from the secure downloader, and it does all this work for you.  Obviously, you need to do the GPG thing the first time you install Armory anywhere (since you need a trusted versino of Armory to use the secure downloader), but after that you can get all packages through the secure downloader, including offline bundles and versions for other OSes.

[RoadStress]

About the git tag... that's coming.  0.92.2-testing got about zero people testing it, so I never did a real release of it until 0.92.3 came along and I decided to skip the 0.92.2 release and focus on that.  Furthermore, my release script failed to create the signed tag, and I decided I would fix it later rather than further delaying the release.

I'll see if I can get the signed tag out today.  Sorry for the delay.

As for the 0.9.3 signatures:

http://pgp.mit.edu/pks/lookup?search=laanwj%40gmail.com&op=index

Wladimir has taken over the Core release signing process.  It used to be Gavin (0x1FC730C1), but this time the SHA256SUMS file is signed by Wladimir's key (0x2346c9a6).  I trust that key because it is signed by Gavin's key (0x1FC730C1) which has been used for every prior release as far back as... 2011?

I have checked the signatures on all Core downloads and have made them part of the Secure Downloader within Armory, so you can download them without having to check the signatures.  If you trust me to check the signatures properly then you can trust the downloads in the Secure Downloader.  This is one of the reasons I made the secure downloader, to transfer some of the burden of checking signatures from you to me!

Got it. Thank you! You are the best!

[cypherdoc]

---

ok, got it.

but i have to say, this whole section on your website needs to be re-written and clarified if you want to stop getting these questions:

GPG-Verifying Armory Installers

Update: If you already have a verified copy of Armory version 0.91 or higher, you can use the new secure downloader feature to get upgrades and/or installers for other systems.  See the next section for more info.   If you don't have a verified copy of Armory yet, you should follow these instructions to verify the first Armory installer you download via GPG.

Armory is used by some of the most heavily-invested, and most paranoid Bitcoin enthusiasts for maximum privacy and security.  If you are in this category, it is recommended you verify that your Armory installers have not been altered in any way.  Armory Ubuntu/Debian packages (*.deb files) are signed directly using our Offline Signing Key (GPG) (0x98832223).  And each release comes with a signed file containing the SHA256 hashes of each installer.   Unfortunately, it is not easy to verify these signatures unless you have access to a Linux machine.  At the moment, the verification procedure on Windows is very difficult. To verify in Linux, “cd” to the directory containing the installer (usually Downloads), download and import the Armory signing key from the ubuntu key-server, install the signature verification program, and then use it verify the signatures on the *.deb files:

$ cd Downloads   # the directory containing the *.deb
$ gpg --recv-keys --keyserver keyserver.ubuntu.com 98832223
$ sudo apt-get install dpkg-sig
$ dpkg-sig --verify *.deb

If everything goes smoothly, you will see the following output:

$ gpg --recv-keys --keyserver keyserver.ubuntu.com 98832223
gpg: requesting key 98832223 from hkp server keyserver.ubuntu.com
gpg: key 98832223: public key "Alan C. Reiner (Offline Signing Key) <alan@bitcoinarmory.com>"

$ dpkg-sig --verify *.deb
Processing armory_0.85-beta_amd64.deb...
GOODSIG _gpgbuilder 821F122936BDD565366AC36A4AB16AEA98832223 1353699840

Notice the "98832223" at the end of the "GOODSIG" line. That is the key "Fingerprint" and if it does not match, do not use that installer! To be extra sure, you can check the last 16 characters, which should be "4AB16AEA 98832223".  The last set of digits (1353699840) is simply a timestamp indicating when the signature was made.  This will be different for every new and can safely be ignored.

[etotheipi]

---

ok, got it.

but i have to say, this whole section on your website needs to be re-written and clarified if you want to stop getting these questions:

...

Yes, that should still work for the regular non-offline-bundle installers.  And it was supposed to work with the debs inside the bundle, but it seems that I make the bundles before I sign the .debs (so the bundle ends up with the non-signed version).  But the whole tar.gz gets signed anyway, so the dpkg-sig signature is redundant, and the fact that I screwed up the redundant sig is what threw you off.  It's better to use the hash anyway, since it covers all the files in the .tar.gz, not just the Armory installer itself.

I'd like to make this simpler, but there's just so many OSes, so many signature layers, and a complex web of operations performed to make sure everything is consistent (such as making sure that the installers are signed before making the hashes file, which needs to be signed, before creating the announce digest, that needs to be signed, so the secure downloader gets the right file with a valid signature.  I wish we could just use the secure downloader for everything, but the fact is that people have to somehow verify the first version of Armory that they get, which requires the GPG stuff.