Pages:
Author

Topic: Armory Hardened: DIY Armory Hardware Wallet for $29 - page 2. (Read 9747 times)

member
Activity: 70
Merit: 10
Interesting project.  I was wondering whether you have seen http://www.inversepath.com/usbarmory.html ? coincidentally also called armory...
legendary
Activity: 3430
Merit: 3071
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.
newbie
Activity: 14
Merit: 0
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.
inf
newbie
Activity: 26
Merit: 0
Although I already answered Corey via PM, I will add some more/new info:

Because no one cared here so far Sad, 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 Wink
newbie
Activity: 2
Merit: 0
I have my atmel otw, and will be more than happy to try it when it gets here.
inf
newbie
Activity: 26
Merit: 0
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 Wink ), 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 Smiley 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


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 Wink

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! Cheesy
Pages:
Jump to: