Armory - Discussion Thread

[etotheipi]

I am trying to build Armory from source (linux openSUSE 12.2, 32bit) and have a problem making Swig - it requires a static libpython which I do not have on my system ... libpython.2.7.so exists, but no static library ... is it possible to link dynamically ?

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. 

wow that was simple    I changed the assignment of STATICPYTHON to .so and now Armory runs offline on a bootable USB stick that has never seen a network - and I created my first wallet !

next step will be recompiling the kernel to get rid of all network and bluetooth modules to be safe when booting on a machine with a network connection ....

many thanks for the help 

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.

[chrisrico]

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

I think he's running this off a USB drive and wants to be able to boot untrusted computers (which may have network connectivity).

[dellech]

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

I think he's running this off a USB drive and wants to be able to boot untrusted computers (which may have network connectivity).

yes, that is my intent 

USB Stick has a small FAT partition for exchanging the transactions and exporting the watching only wallets,
 a boot partition and LVM on a Luks encrypted partition for the OS

I want to be able to boot it on any computer or even a VM and be sure to cut any links to the evil world 

[etotheipi]

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

I think he's running this off a USB drive and wants to be able to boot untrusted computers (which may have network connectivity).

yes, that is my intent  

USB Stick has a small FAT partition for exchanging the transactions and exporting the watching only wallets,
 a boot partition and LVM on a Luks encrypted partition for the OS

I want to be able to boot it on any computer or even a VM and be sure to cut any links to the evil world  

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

[cypherdoc]

as a general option for the rest of us, it would be cool to have a USB version of Armory that is easy to implement.  i'm not sure though once the USB is connected to desktop/laptop how its protected from malware residing on the desktop/laptop.

[dellech]

as a general option for the rest of us, it would be cool to have a USB version of Armory that is easy to implement.  i'm not sure though once the USB is connected to desktop/laptop how its protected from malware residing on the desktop/laptop.

this is the reason why I boot from the USB and no storage component of the host computer is part of the file system in the running OS

[cypherdoc]

as a general option for the rest of us, it would be cool to have a USB version of Armory that is easy to implement.  i'm not sure though once the USB is connected to desktop/laptop how its protected from malware residing on the desktop/laptop.

this is the reason why I boot from the USB and no storage component of the host computer is part of the file system in the running OS

so then how do get access to the unsigned tx; a second USB stick?

[dellech]

as a general option for the rest of us, it would be cool to have a USB version of Armory that is easy to implement.  i'm not sure though once the USB is connected to desktop/laptop how its protected from malware residing on the desktop/laptop.

this is the reason why I boot from the USB and no storage component of the host computer is part of the file system in the running OS

so then how do get access to the unsigned tx; a second USB stick?

I have the full Linux system with offline Armory in an encrypted partition on the same stick as the fat32 partition I use for transaction exchange.
- when a system is booted from the stick no processes on the possibly infected system are running
- when the stick is inserted into a running system everything except the data partition is encrypted and can't be changed
- malware on the online computer could destroy my offline OS but not install anything into it

[cypherdoc]

as a general option for the rest of us, it would be cool to have a USB version of Armory that is easy to implement.  i'm not sure though once the USB is connected to desktop/laptop how its protected from malware residing on the desktop/laptop.

this is the reason why I boot from the USB and no storage component of the host computer is part of the file system in the running OS

so then how do get access to the unsigned tx; a second USB stick?

I have the full Linux system with offline Armory in an encrypted partition on the same stick as the fat32 partition I use for transaction exchange.
- when a system is booted from the stick no processes on the possibly infected system are running
- when the stick is inserted into a running system everything except the data partition is encrypted and can't be changed
- malware on the online computer could destroy my offline OS but not install anything into it

so the unsigned tx has is located in the unencrypted data portion of the USB stick and can be accessed after you've booted up a desktop computer from the encrypted Linux OS on the USB stick, correct?  but where is the Satoshi client/blockchain that you need Armory to access?

[dellech]

...

so the unsigned tx has is located in the unencrypted data portion of the USB stick and can be accessed after you've booted up a desktop computer from the encrypted Linux OS on the USB stick, correct?  but where is the Satoshi client/blockchain that you need Armory to access?

running two separate computers is the very idea of Armory (one for the offline wallet and one for the watching-only wallet).

With my USB stick I could do everything on the same PC:
- boot normally from harddisk: internet connection, bitcoind and Armory watching-only wallet. Create unsigned tx and save to the fat partition on the stick
- boot from USB, sign the tx with offline Armory (this needs no block chain)
- reboot from harddisk and send the signed transaction

whenever the system is booted from its harddisk the wallet on the encrypted part of the stick is securely hidden

[Stephen Gornick]

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

A QR code can hold up to 4K of alphanumeric data.

 - http://stackoverflow.com/a/3964342


[Edit:

Online Armory --> Offline Armory could be 100Kb+.  Thus not a workable plan.  Thus was described here:

the data you're moving from online to offline is the bulkiest (could be 100kb+, not quite right for QR codes

The rest of my argument is invalid.]


A USB barcode/QR code scanner acts as a USB keyboard:

 - http://bitcointalk.org/index.php?topic=105824.0

Maybe a QR code could be an alternative for shuttling the offline transaction that would be more secure than mounting a USB storage device?


If the online and offline systems are not sitting right next to each other then the QR code would need to be transported over somehow. If that's needed then a $100 Android (or any other) mobile smartphone works for scanning the QR code displayed by Armory on the online system and then the mobile's display will present the QR code to the barcode/QR code scanner connected to the offline Armory:


Or a little $50 thermal printer could print the QR codes for transfer to the scanner for the offline Armory:

 - http://learn.adafruit.com/mini-thermal-receipt-printer


Then the Android mobile could scan the QR of the signed transaction and send it without even needing Armory by sending it as a raw transaction like is available from Blockchain.info/pushtx or the raw transaction feature of BrainWallet.org right?

 - http://blockchain.info/pushtx
 - http://brainwallet.org/#tx  [Edit: Looks like the signed transaction from Armory is its own format, and not compatible with raw transaction ?]

[molecular]

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

Why not specifically ask the windows-crowd to donate for that. They're used to paying for proprietary bloated shit. They should cough up the bill for using the crap.

Sorry for the rant, this shit still gets to me.

[molecular]

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

bitmit to the rescue: https://www.bitmit.net/de/q/?q=raspberry

[etotheipi]

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

Why not specifically ask the windows-crowd to donate for that. They're used to paying for proprietary bloated shit. They should cough up the bill for using the crap.

Sorry for the rant, this shit still gets to me.

Meh, I've already received a ton of donations from a vast array of users, well in excess of the cost of the certificate.  It's not only unnecessary to ask for it, it seems kind of beggar-y.  Really, that was part of the original intent of the donations anyway -- not just to help me work less at my job, but cover related expenses.  And this is purely a software project (no hardware), so I hardly have to spend money on anything else.  

So, while I won't turn down any donations, I don't need to solicit any.  After all, I do still have a real job

And now that you bring it up, maybe I should stop procrastinating and actually do it!  I figure I'll do it at some point...

[Stephen Gornick]

Maybe a QR code could be an alternative for shuttling the offline transaction that would be more secure than mounting a USB storage device?

I now see that something like this has already been considered ...

I had considered this idea for Armory's offline wallets (webcams to move data around between offline and online devices).  It turns out to be kind complicated and cumbersome, and subject to driver issues because webcams do not always work easily on every OS.

[...]

Webcams + QR codes would theoretically work, but honestly I think it would be a mess.  Multiple sequential QR codes, driver issues, designing a real-time-feedback UI for using the camera, resolution issues, wires everywhere,

[Edit: But then re-considered here as well ....

Absent a dedicated device/dongle, I am still interested in other ways that might work.  The webcam+QR idea is in the right direction, but there's a variety of reasons why it's not good for the general user (I've mentioned it before).

]

[chrisrico]

What were the drawbacks of RS232 again? The possibility of opening a terminal through the connection? I seem to remember that was fairly easily mitigated, but I can't find the thread now. I just ordered a Raspberry Pi (actually two, one from BitMit, one from Newark) to set up as an offline wallet storage box. Eventually I wanted to connect it to my main computer via RS232 and play with that idea.

[etotheipi]

What were the drawbacks of RS232 again? The possibility of opening a terminal through the connection? I seem to remember that was fairly easily mitigated, but I can't find the thread now. I just ordered a Raspberry Pi (actually two, one from BitMit, one from Newark) to set up as an offline wallet storage box. Eventually I wanted to connect it to my main computer via RS232 and play with that idea.

That's basically it.  You can say that it's easily mitigated, but it's a potential disaster if it's not.

Take this for example:  someone wants to do offline transactions, hearing that Armory is a super-secure way to do it.  So they download Ubuntu, grab some RS232 hardware, and set everything up.  The problem is they downloaded the wrong Ubuntu version, and it comes with drivers or modules that they weren't expecting.  Or they're just oblivious anyway because they heard about how secure Armory is, what could go wrong?

You might say:  "Well, even if they get the login prompt, it would take a while for someone to figure out how to compromise it."  I guarantee you that a large number of users (correlated with the same ones that do the previous part carelessly), their login and password for the offline computer and wallet will be one of the dozens of website logins&passwords they have saved in Firefox (Edit->Preferences->Security->Saved Passwords->Show Passwords).  And the attacker probably got there because the user never changed their primary computer password after the same one they used at Mt. Gox got compromised last year.

I don't mean to suggest that the RS232 link is useless.  It's just something that I can't promote as a general solution because of the counter-risk associated with doing it incorrectly.  Most of the other solutions proposed here, if you do it incorrectly, no one gets signatures from the offline computer, including the intended user.  The wallet will remain secure, just inaccessible until they figure it out.

As I've said in other posts: I end up with most of the blame when a compromise does happen, so while it's easy for others to say "ahh, careless users are not your problem"... well I disagree.  I'd like to think that part of the reason Armory is successful is because I try really really hard to prevent newbies from shooting themselves in the foot (as evidenced by the endless warning dialogs and corner-case checking).

[chrisrico]

I understand your hesitation to include features that might get you blamed for theft of bitcoins.

Instead of explicitly defining the hardware layer, would it be possible to have Armory be agnostic about such things? I'm not sure how/if this would work in Windows, but I'm imagining that a *nix user could set up a device (/dev/foo) on each computer that when read from/written to would communicate with the other computer. Then in Armory, the user would just specify which device should be used for communication. The user would be liable for making sure that connection was secure, and Armory would attempt to communicate with itself through that device, failing gracefully if unable.

[kjj]

You could make your own live distribution that has the serial getty lines properly disabled in the inittab...

[chrisrico]

Quick question... I sent a transaction at roughly the same time my modem lost its connection, now it's sitting there in sent/unconfirmed status. Is there any way to force a transaction to be rebroadcast? That could be a useful advanced feature to have.

Also, it just so happens the transaction in question was to address 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv