About the protocol itself - we're implementing generic class HID device, which has some benefits (like no need for driver installation). The wire protocol itself is Google's Protocol Buffers, providing perfect message-oriented serialization, which can generate bindings for every major platform (C/C++, Java, .NET, Python).
Current draft of protobuf messages (still under construction) is here: https://github.com/slush0/bitkey-python/blob/master/bitkey_proto/bitkey.proto I'm not sure how easy is to understand high level purpose of the protocol just from protobuf specs, but I'll provide some comments soon.
Currently I'm working on device emulator in Python, which will be also used for that Raspberry Pi version. When I'll have some working prototype, I'll demonstrate it's capabilities and I'll open the discussion about decision which I made. However I want to have some working code to talk about, instead of theoretical discussion about "what features should such token have".
Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 260. (Read 966173 times)
It is possible that this platform will be standard design for BTC hardware wallets in the future. Better, at least, take in account the possibility to add security and plan some reliability for the platform, like batter battery backup, option to backup one wallet to a new one, option to add 3G modem, etc.
Look at most used software wallet.
Look at most used software wallet.
Adding battery backup and 3G modem is far over current project goals. But as far as the communication protocol isn't tied with the implementation, it will be definitely possible to build 3G+battery powered devices, compatible with current device.
1. (clarification) The ability for the user to upload keys does/should not have to be the only way to use the device. But simply one of a couple different options for initializing the device. This accommodates all types of users, especially pursuant to my next point...
Currently there'll be two ways how to initialize the device: Load custom seed into it (over trusted computer) or generate the seed directly into the device (with the seed appearing on the display for backup purposes). I think these choices are the most flexible and easy for initial setup. You don't need to have trusted machine for initialization, but you'll be still able to use custom seed if you really want...
Quote
2. (extra point) As we know, Bitcoin users of all backgrounds have a tendency to not trust anyone or anything but themselves. For this reason, they may not be inclined to trust this device that could've been malciously designed, or tampered with to produce keys that can be predicted by someone else. However, if they can use any application of their choosing to upload their own source of entropy, the device would have no choice but to use the user's trusted entropy instead of its own. Not to mention that users doing this would be much better prepared to create paper backups and watching-only wallets.
The device will probably have the choice to combine entropy source from it's hardware and from the computer. The worst case (when you'll have hacked machine): The entropy will be as strong as the hardware RNG (which should be still enough for common use) and there won't be a way how to malicious machine can guess the seed . In standard case: You'll have perfect entropy created by combination of hardware generator and your entropy source provided by the computer.
Just keep it simple and support the Electrum format and BIP32.
I expect by the time your hardware wallet is production ready everybody will have implemented BIP32 wallets.
I expect by the time your hardware wallet is production ready everybody will have implemented BIP32 wallets.
Sweet Project
Armory won't have BIP 32 supported for a bit, but it would be nice to iron that out before I continue with my new wallet implementation.
I plan the support for BIP32, because I think it will be the standard soon. I'm also implementing Electrum's way for deterministic wallet, just because I quite understand Electrum's code and I want to test device with it. I don't fully understand that Armory's wallet algorithm differences, so I'm not yet decided if I'm right now going to support current Armory's wallet.
Are you not interested in being compatible with Armory?
I'm interested in being compatible with any existing and future bitcoin wallet, including Armory. I'm working on library written in python for interfacing with the device, so implementing it into the Armory should be super trivial. I'm aware of Armory's offline wallets and I think there's almost everything prepared for such type of device.
The reason why I contacted Jim instead of you is because Multibit is written in Java and I need some clarification that he's interested in such kind of device and that there's a way how to talk with this device from Java.
Quote
there are lots of ways to do this kind of device, but there's one mode of operation I think it should have: the device has a hardware switch on the back behind a little door that is accessible, but impossible to flip by accident. The switch allows for uploading new wallet data. Data that is uploaded to the secure chip is not downloadable -- it's a one-way channel.
Although "downloading" the seed from the device into the computer won't be possible, there'll be a way how to upload custom seed from attached computer. There won't be any need for special hardware switch on the device, it just displays request if you want to rewrite current seed by that provided by the computer.
Quote
The user creates their full wallet using Armory/Multibit/Electrum on a temporarily-offline computer (live session), they print off a couple paper copies, create a watching-only copy, then they flip the switch to allow uploading the wallet to the device. Copy the watching-only wallet to the online computer, stash your paper copy in a safe-deposit box, and then flush the original copy on the computer by rebooting. Now you're ready to go.
Yes, this would be possible (except that hardware switch, as I mentioned above.
Quote
There's other modes of operation to consider, but I think the flexibility of managing the wallet initially from a laptop/desktop is ideal. This gives lots of options for watching-only wallets, making address lists, etc.
Device will handle just the master private key and it will derive every address from it. It won't allow you to handle private keys for custom address. This is limitation which will make the interface much easier.
Quote
The device could also have a separate memory bank for downloading the watching-only wallet from it.
I don't plan this. Device will just provide master public key to the computer and then it will be just able to sign for addresses derived from this master key.
Quote
This stuff is already available in Armory, it just uses a different wallet format and data transfer format (BIP 10).
I wasn't aware of BIP10. I'll read it and maybe I'll have some more questions. I'm also going to support P2SH, but maybe I'll need some help with it...
but the teensy 3.0 is ARM (Cortex-M4), really small and usb powered, around $30:
I'm not getting anything Cortex-M even if it is free. I really need to be able to run classic ARM code, not just Thumb.Allright, got it. I'm not into that stuff much so I don't even know what "thumb" is.
Slush showed this to me and I looked at the code. Protocol seems to be very low-level for what we need. But I'll keep your project in mind ...
It is indeed low-level (perhaps a bit too low level). But that's because it's a wire protocol for an embedded device. The need for abstraction is diminished greatly because a lot of the low-level details (eg. transaction format) of Bitcoin aren't likely to change, and if they do, any embedded devices will become incompatible by virtue of their essentially fixed firmware.
Here's a bit of the motivation behind the wire protocol. By separating transfers into type-length-value packets, the device can skip any unrecognised packets. This allows for some extensibility. For example, if a new wallet feature is implemented which requires an extra byte in the "new wallet" packet, old wallets will see this extra byte, skip the entire packet and return "unrecognised command" to the host. The host can then tell the user "your device doesn't support this new feature" and perhaps fall back to not using the new feature.
IMHO, the biggest flaw with the wire protocol I've proposed is that it is quite specific to certain use cases. Thus I'd like your opinion on generalising it. But I'm quite averse to unnecessary abstraction.
Well, gl.. LM4F120H5QR is very buggy, just read the errata, it has some retarded memory alignment issues.. Almost to trow it away first day when I tried to compile something which was not their example.. 
PS: In case you are looking for alternatives to ARM, there is PIC32, a cheap MCU based on MIPS. Has some bugs too, not as much as TI lm4f120, and runs at 80Mhz.
PSS: I was looking over microchip product page, and they have this new board based on new low cost family (I think running at 40Mhz):
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en555947
Board will be available in November and will cost $109.
PS: In case you are looking for alternatives to ARM, there is PIC32, a cheap MCU based on MIPS. Has some bugs too, not as much as TI lm4f120, and runs at 80Mhz.
PSS: I was looking over microchip product page, and they have this new board based on new low cost family (I think running at 40Mhz):
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en555947
Board will be available in November and will cost $109.
You're free to use any of the code in https://github.com/someone42/hardware-bitcoin-wallet. It's (mostly) BSD licensed. My current prototype uses the NXP LPC11U24 microcontroller; I believe it is very similar to the chips in the LPC134x series. Thus there could be some useful stuff in the lpc11uxx/ directory.
Slush showed this to me and I looked at the code. Protocol seems to be very low-level for what we need. But I'll keep your project in mind ...
That MCU family does not seem designed for secure applications. There are probably 100 ways to read it, despite CRP/ERM/xRR (whatever) level. You should look for a smartcard if you want some protection.
Please don't get too hooked on LPC13xx thingie. I was experimenting with this platform, because that's what I have pretty good knowledge of. Now we are trying with TI Stellaris Launchpad (LM4F) and this might or might not be the final platform. MCUs evolve too quickly and if there is a better alternative for our usecase and it's not too late to switch we'll use it.
That said, what about using old, obsolete devices as a target platform? E.g. I have an old iphone 3g sitting around here, doing nothing. The advantage is that using obsolete devices from an ongoing series (androids, iphones, etc...) would offload the device creation to established companies. As a business you'd buy old devices for low cost and install all the necessary gadgets to augment it into a hardware wallet...
We had this discussion already. Search the past posts of etotheipi, Jan and ThomasV for the analysis of various problems with these choices.
That said, what about using old, obsolete devices as a target platform? E.g. I have an old iphone 3g sitting around here, doing nothing. The advantage is that using obsolete devices from an ongoing series (androids, iphones, etc...) would offload the device creation to established companies. As a business you'd buy old devices for low cost and install all the necessary gadgets to augment it into a hardware wallet...
We had this discussion already. Search the past posts of etotheipi, Jan and ThomasV for the analysis of various problems with these choices. It is possible that this platform will be standard design for BTC hardware wallets in the future. Better, at least, take in account the possibility to add security and plan some reliability for the platform, like batter battery backup, option to backup one wallet to a new one, option to add 3G modem, etc.
Look at most used software wallet.
I have to repeat to you: hardware choice is secondary. The good protocol design comes first. The available hardware in the ARM space changes so furiously fast that it simply doesn't make sense to choose it now. Post the communication protocol level suggestions, not the hardware suggestions.Look at most used software wallet.
I'm still browsing around and I've found a ready made LPC11U37 kit with an LCD display for €69 and various other expansion options:
http://www.embeddedartists.com/products/app/lowpower_oryx
but the teensy 3.0 is ARM (Cortex-M4), really small and usb powered, around $30:
I'm not getting anything Cortex-M even if it is free. I really need to be able to run classic ARM code, not just Thumb.That said, what about using old, obsolete devices as a target platform? E.g. I have an old iphone 3g sitting around here, doing nothing. The advantage is that using obsolete devices from an ongoing series (androids, iphones, etc...) would offload the device creation to established companies. As a business you'd buy old devices for low cost and install all the necessary gadgets to augment it into a hardware wallet...
It is possible that this platform will be standard design for BTC hardware wallets in the future. Better, at least, take in account the possibility to add security and plan some reliability for the platform, like batter battery backup, option to backup one wallet to a new one, option to add 3G modem, etc.
Look at most used software wallet.
I have to repeat to you: hardware choice is secondary. The good protocol design comes first. The available hardware in the ARM space changes so furiously fast that it simply doesn't make sense to choose it now. Post the communication protocol-level suggestions related to the hardened crypto devices, not the hardware suggestions.Look at most used software wallet.
I'm still browsing around and I've found a ready made LPC11U37 kit with an LCD display, 8 touch sensors instead of buttons and various other expansion options for €69 and still within the 128kB limit of the free LPCXpresso IDE:
http://www.embeddedartists.com/products/app/lowpower_oryx
It has everything required to build a secure Bitcoin wallet without a need to solder a single wire. Only programming talent is required.
but the teensy 3.0 is ARM (Cortex-M4), really small and usb powered, around $30:
I'm not getting anything Cortex-M even if it is free. I really need to be able to run classic ARM code, not just Thumb. For me none of those choices is good because the Cortex-M processors in those controllers don't execute the legacy ARM code, only the new-fangled Thumb code. So I'm still looking for a nice small USB-powered ARM development board.
sorry for offtopic. http://www.kickstarter.com/projects/paulstoffregen/teensy-30-32-bit-arm-cortex-m4-usable-in-arduino-a/posts/343893
My brother recently got one of these, I've been playing around with it. Don't know if this counts as a "development board", but the teensy 3.0 is ARM (Cortex-M4), really small and usb powered, around $30:
It is possible that this platform will be standard design for BTC hardware wallets in the future. Better, at least, take in account the possibility to add security and plan some reliability for the platform, like batter battery backup, option to backup one wallet to a new one, option to add 3G modem, etc.
Look at most used software wallet.
Look at most used software wallet.
At least use a smart card to store secure key while the device is powered off, not the MCU flash. When device is powered on, require some password (add device unique key) and read the secure part from smartcard (or some other secure device).
Too complex. The real problem here is that most of the Bitcoin software developers are not familiar with the restrictions and challenges of bare metal embedded programming.The choices of someone42/slush/stick are so great and so beautiful because anyone who tries them will have their first trivial embedded project working on the same evening that the package was delivered.
The real challenge now is not to be super-secure. It to to agree to a common hardware wallet protocol that could be sensibly implemented bare-metal on a simple hardware, not a discared Intel laptop or obsolete Android phone/tablet with their attendant problem of the security of the underlying OS.
That MCU family does not seem designed for secure applications. There are probably 100 ways to read it, despite CRP/ERM/xRR (whatever) level. You should look for a smartcard if you want some protection.
I on the other hand think that sitck and slush made excellent choice. I only have an issue with the original claim that it is impossible to extract the keys from the device after a theft. Just reduce the claim somewhat and you'll be more than fine.The main problem with using "real smartcard" device lies in the unvieldy development process for the "real crypto stuff".
At least use a smart card to store secure key while the device is powered off, not the MCU flash. When device is powered on, require some password (add device unique key) and read the secure part from smartcard (or some other secure device).
That MCU family does not seem designed for secure applications. There are probably 100 ways to read it, despite CRP/ERM/xRR (whatever) level. You should look for a smartcard if you want some protection.
I on the other hand think that sitck and slush made excellent choice. I only have an issue with the original claim that it is impossible to extract the keys from the device after a theft. Just reduce the claim somewhat and you'll be more than fine.The main problem with using "real smartcard" device lies in the unvieldy development process for the "real crypto stuff".
On the other hand the choice displayed here (looks like LPCXpresso LPC1343) and in the similar thread https://bitcointalksearch.org/topic/hardware-bitcoin-wallet-a-minimal-bitcoin-wallet-for-embedded-devices-78614 (mbed LPC11U24) is an excellent starting point for learning and development. It is important to stress that anyone involved in Bitcoin development will be about €30-€60 away from being able to actively test and develop the future Bitcoin wallet device protocol.
I always wanted to expand to dedicated hardware just like this, but my hardware skills are nil.
It would be a good idea to agree on a common wire protocol, for the sake of Bitcoin client developers. My current wire protocol is documented here: https://github.com/someone42/hardware-bitcoin-wallet/blob/master/PROTOCOL.
I know this forum is full of people capable of programming (or willing to learn programming) therefore I'm going to post some links for the people who may find this project interesting from the purely programmatic side, disregarding for now the actual design of the hardware.
The good starting devices are the two following: mbed LPC11U24 and LPCXpresso LPC1347 (LPCXpresso LPC1343 is now obsolete). The first one comes with an online IDE suite at http://mbed.org/handbook/mbed-Compiler , the second one is supported by a free (as in beer) LPCXpresso IDE http://www.code-red-tech.com/RedSuite5/lpcxpresso-5.php .
Both boards seem to be the designs from http://www.embeddedartists.com/ , they just differ in how they are marketed.
You probably will not be well served by buying the higher end mbed LPC1768 or LPCXpresso LPC1769 boards because they lack the on-chip EEPROM (a.k.a. parallel, byte-erasable NOR flash). You don't want to go into the tribulations of programming NAND flash in your first embedded project.
For me none of those choices is good because the Cortex-M processors in those controllers don't execute the legacy ARM code, only the new-fangled Thumb code. So I'm still looking for a nice small USB-powered ARM development board.
Jump to: