Topic: Armory Hardened: DIY Armory Hardware Wallet for $29 (Read 9798 times)

Well, that's a cool projet, it would deserve more attention!

I spoke with INF.
He also does not have the time to develop this any further.

So sorry guys!

Inf hasnt been active in >1yr.

The new signing method broke it.
Just gonna have to break down and get a trezor!

I'd have to have time to go over it. Not my priority atm sorry. If someone else takes over that project, I'd be happy to assist them.

I really wish this worked with your new Armory goatpig...

INF:
Have you made it so it can export the FULL rootkey to the SD yet?
My current version says:

Make rootkey file:
Disabled.
SW0:B

This looks quite amazing... I'll be definitely checking this from time to time, hope to see good progress

I basically just reverted back to 0.92.x.
I dont want to have to use 2 different Armory's tbh.
Im not trying to use another version of armory to do the signing, im trying to use this device.

Armory makes unsigned transaction -> save it to device -> sign it -> Open saved signed tx to finalize.

Now i having problems with the AVR... 

I'm not sure what your setup is, nor what you are trying to achieve. I'm assuming you want to use some build of Armory on your hardware wallet as an offline signer. For that purpose, you do not need to go with 0.93. Any transaction 0.93 will create, 0.92 can sign.

0.92 doesn't use C++11, so I expect it will be a lot easier to cross compile it for the hardware wallet's platform.

If you are going to use 0.92 as your signer, it doesn't mean you have to use it for your online machine as well. You can use 0.93 for your online PC, and offline 0.92 on the custom signer.

0.93 has a completely different DB engine and format than 0.92, so they will both try to build their own. Not sure why you want to get online with 0.92 though.

Im using the same bitcoin blockchain download.
I just installed an older version of Armory to a different directory.
And it wanted to make a new armory database for the older non-0.93.

You don't need the old Armory DB. A DB from 0.93.x will create transaction that 0.92.x will sign.

Yeah.
Im going to revert back to an older armory for now.
I dont want to loose any more coins to malware, and i dont want to setup an offline pc for signing and using a usb stick back and forth...

Back to building the databases for the old armory...

You should use 0.92.x for signing. The code base doesn't diverge significantly from 0.91 to 0.92. We use C++11 starting 0.93 so that has a good chance of tripping your compiler.

This project is dead on new versions of Armory.
In order to use this, you will have to run Armory 0.91.x

I have contacted inf and offered him a BTC bounty for updating the code, but he is very busy with real life at the moment.

Right. Thats what i thought.
I was trying to use it on 0.93.1
When going to sign, it tells me that the method has changed. Thats what tipped me off on what it was.

That's true. If you're trying to use a pre 0.92.x signing method on the device, it won't be compatible with a online Armory client that is 0.92.x or above.

If i had to guess, armory changed their method for signing offline transactions.
Attempting to contact Inf to see if he can help out.

Am i the only one interested in this?

I seem to have everything up and going.
My only problem is, once i try to send funds from my watch only wallet, i save the unsigned tx to the AVR, and then go to sign it.
I get the following error...


What am i doing wrong here?

Should be easy to do and integrate into the build process using the xcodebuild and/or xcrun tool.  GPG and all that is great, but this is a check that every Mac performs so it would be great to support it.

I only found this now. Great project, hooray for small, secure, cheap hardwarewallets!
Amazing how much you can actually do with those tiny µC, with specs being measured in kb and Mhz.

For me, personally, this sounds too tiny. I'd need more wallets, larger tx size (just to feel comfortable), and maybe a bigger screen ;-)
I'll gladly pay more than that tiny price for it too.

The real art, of course, is to get it running on such tiny specs. "Larger" is simple.
So, hats off to you!

Ente

Interesting project.  I was wondering whether you have seen http://www.inversepath.com/usbarmory.html ? coincidentally also called armory...

Sounds like a really interesting project. I can only apologise for not noticing it before!

This concept has advantages (and disadvantages) compared to a hardwallet that transmits the signed tx over the USB bus. This concept would take more steps/time to compose your transaction, but with a security improvement as a trade off (harder for malware on the online box to fool you into signing a fraudulent tx)

Which crypto library are you using? I ask because I'm wondering whether timing based attacks would be more difficult when the USB connection can only be used to power the device. I guess it almost doesn't matter if timing attacks are eliminated by design.

If i think i understand what your looking for,
Have you looked into a Teensy 3.1 board yet?
It is very compact, has micro usb, and one button.

https://www.pjrc.com/store/teensy31.html

I would love to help you with your programing.
I have multiple Teensy 3.1 laying around.

Anything i can help with, feel free to ask.

Although I already answered Corey via PM, I will add some more/new info:

Because no one cared here so far , I did not write any manuals yet. I will do so now in the next days.

I also continued to improve the code:

- Multi wallet support
- Obfuscated wallet import with Trezor-like shuffled character map
- Unlimited tx-size possible now with dynamic bytestreams
- On-chip wallet creation with RNG via floating analog/digital converter (randomness not proven yet in any way, just a concept)
- Many minor improvements

I also plan to shift as much control as possible back to the PC via USB serial port (CDC) and a host software (which could eventually, just in theory, be integrated in Armory itself) for wallet management, PIN entering etc, to get away from those aweful hardware buttons. I just want one hardware button to be left for confirmation actions. After realizing this as a concept, I want to migrate to a (much faster) ARM processor with better crypto support and build my own hardware in USB-drive-style. Much work to do and searching for fellow co-programmers

I have my atmel otw, and will be more than happy to try it when it gets here.

Disclaimer: I am not and this project is not related to Armory Technologies, Inc in any way other than the fact it is made particularly to work with their software interfaces and so contains the word "Armory" in the (preliminary?) name.
-
Find a TL;DR in the foot note.

Intro

So, after posting a short video 2 weeks ago I would like to present some more insights today!

I am a huge fan of Armory and use it for a significant portion of my funds. I always wanted to use the offline-signing feature, but was not willing to maintain 2 computers and run around between them with a USB drive (or use a modem). Would it not be better to have the offline Armory directly on the USB drive?

So because of that and because I wanted to learn all things Bitcoin while doing something useful, I decided to build my own "Armory Trezor". Even though I am an electrical engineer, I decided against the effort of building my own hardware first without knowing whether I will ever succeed with the software (and getting ECC to work on 8 bits took me 4 weeks alone).

Also I want everyone else to be able to buy the same hardware anywhere in the world and just flash the software to make it a wallet device.

I found a perfectly fitting evaluation board with an intentionally low-level (even lower than Trezor) µC, the Atmel XMEGA-C3 Xplained (http://www.atmel.com/tools/XMEGA-C3XPLAINED.aspx).
It features

• A 32 MHz 8 bit processor (tweakable to 48), 32 KB RAM, 384 KB Flash, 4 KB EEPROM
• A small OLED display
• A micro SD card reader (2 GB card included!)
• 4 buttons
• Means to collect real world entropy: light sensor, temp sensor, voltage sensing, open wire noise sensing
• USB connection and powering
• Programming-over-USB capability

and, last but not least, only costs $29 in the Atmel online store.

Per definition it is possible to flash the device simply over USB with a free Atmel tool, but some series have an older boot loader not enabling this. You then need an extra programming device. I will soon publish a manual how to both ways.


Now I dare to release the source and call it Armory Hardened (which I think is funny in at least 3 ways ), and I don't lie if I say I am more an Armory expert than a Bitcoin expert now!

At the current development level the device offers at least the security of a not encrypted paper wallet but almost the convenience of a password-less online wallet.

Wallet setup

So far you still need a trustable computer to set up a wallet. You have to provide a decrypted full wallet file or a text file with the paper wallet seed data.
The root key will be extracted and saved to EEPROM, the original file will be overwritten (securely erased) and deleted. You can then optionally generate a file with watch-only public data on the device for import in the online Armory.
Lastly you have to permanently store a watch-only copy of the wallet permanently on the device for key chaining (see below why).

Please keep in mind, this first proof of concept focuses on tx manipulation and security against internet attacks. I will improve wallet handling and physical security in upcoming versions (see priorities list below).

Signing

To sign a transaction, connecting the device will provide a removable USB storage (with the SD card as underlying memory). Create an unsigned transaction in Armory as usual and save it as an *.unsigned.tx file to the USB storage. Open the tx on the device, check the outputs, fee and Armory tx ID on the display and confirm (or abort) the signing (2 button clicks process).

The tx will be signed (which takes whopping ~4 sek per input) by searching the position of the needed public key in the watch-only copy, deriving the corresponding private key from the on-chip-stored root key and put out as a *.signed.tx file on the USB storage again.

I chose this way because it takes several (3-4) seconds to derive each public key from the private key or the public key chain (which both are ECC point multiplications) but only some ms to chain the private keys. All n-1 public keys in the chain are needed to generate the n-th private key. Yeeahh, this sucks. Keeping all public keys in on-chip memory (EEPROM) would quickly exceed the 4 KB. Another option would be to keep it in internal flash memory (which is larger, but still finite), but for that the boot loader needed to be customized (what you immanently would need a programming device for).

Anyways, now hit "continue" in Armory, open the new signed file on the USB storage, check the Armory tx ID again, check for the green "all signatures valid" and hit "broadcast". That's it Almost the convenience of an online wallet with the security of a paper wallet. No changes in Armory necessary (in contrary to Trezor :p).

Demo & Source

• See an a bit deprecated quick and dirty demonstration video here: http://youtu.be/0ezhxStpvhg
• Some more up to date pictures here: http://imgur.com/a/RSVR9
• Find the code and soon the manual how to set up and use Armory Hardened here: https://github.com/btc-inf/armory-hardened

Safety & Security

None of your secret data can get lost (because you always keep another backup, right?) or stolen by malware (because there is no access via the mass storage interface to the on-chip non-volatile memories).
The worst thing to happen would just be the tx not being properly signed but this doesn't make you lose anything. Also Armory will not let you broadcast erroneous tx's (often enough it isn't even able to show any info about them anymore).

I identified 2 weak points outside the chip so far:

• A poorly generated random "k" in the signing process, but that's bulletproof with deterministic RFC 6979 (tested against python-ecdsa's test vectors).
• Malware injecting its own public key as the change output address in the unsigned tx file. But that would invalidate the Armory tx ID (which you should always compare before signing) or require to manipulate the values displayed in the Armory UI itself.

Limitations

Please keep in mind, this is just a proof of concept yet:

• You can sign for any outputs, but only P2PKH inputs so far
• I use a 3 KB buffer in RAM for the raw Armory tx data, so you can sign tx files up to the size of roughly 4 KB (because of the Base64 overhead). This is changeable easily and I am already working on a dynamic buffer.
• Your data is digitally but not physically secure yet (someone else could just use the device with your Armory or read out the not encrypted raw key data from the EEPROM with a programmer/debugger).
• Not all exceptions are catched yet, so providing corrupted or non-compatible file systems or files could lead to an undefined state and behavior (which will corrupt nothing on your computer).

But, I am working on improvements!

Upcoming

Priorities for upcoming development (likely in this order):

• Clean-up and documentation in- and outside the existing code
• Private data encryption + power-up lock screen
• Multi-wallet support
• Manual paper backup data import; on-chip wallet creation
• Message signing
• P2SH support
• Custom hardware after the next bubble

I would be very glad if anyone here would actually try and use this himself (as it is thought to be)! Of course I will keep you up to date with improvements and would love to answer questions and to discuss in this thread.

And: Thanks to the awesome people at Armory!


TL;DR: Programmed an offline signing µC software for Armory, implemented it on a ready-to-use, off-the-shelf $29 device (http://www.atmel.com/tools/XMEGA-C3XPLAINED.aspx), made a demonstration (http://imgur.com/a/RSVR9, http://youtu.be/0ezhxStpvhg), published the source code (https://github.com/btc-inf/armory-hardened), will publish a manual how to set up and use your own soon and would be glad if you try so!