[ESHOP launched] Trezor: Bitcoin hardware wallet

[slush]

It can be turned off, it can be bypassed by the Shift key (afaik), but tell me who is doing this. My mum even don't know there's autorun possibility :-/.

Although we're targeting to common users which are using potentially compromited machines, using hacked token definitely *is* a problem. Distributor can expect that somebody who's buying bitcoin wallet will handle significant bitcoin amounts on that machine. Using trusted distributor is definitely the only way to go.

[slush]

Regards to my previous post, users should even refuse offers like "bitcoin token with USB mouse as a free gift" ;-).

[Photon939]

Is autorun still on by default on some machines?

Since upgrading from XP to Win7 I notice that autorun is no longer on by default. Inserting a disk or drive with autorun will bring up the box that asks you what you want to do (browse files, run autorun, etc) but does not launch anything without your command.

[CIYAM]

Yup

Is autorun still on by default on some machines?

Actually I think even my XP machine does this (although I might have turned autorun off in the registry anyway).

[slush]

Inserting a disk or drive with autorun will bring up the box that asks you what you want to do (browse files, run autorun, etc) but does not launch anything without your command.

Hm, I just checked this and you're correct, Win7 ask for the action. At least we can hope that average user won't run malicious code from the token by accident :-).

[Ente]

How can we be sure that some reseller isn't slipping us a modified version and what could he potentially do with that approach?

Yes, this may be possible issue. Malicious distributor can buy few devices, make alternative PCB, use modified firmware and pack it with "official" casings. There's just a small chance that customers will notice the difference. Buying the device from trusted distributor would be better choice than ordering it from random guy on Silk Road.

Technically this is not a big problem as device itself cannot communicate with the world on its own. So as far as user will connect that hacked stick into official release of Bitcoin wallet (Electrum, Multibit), the chance of a theft is minimal (as far as official clients will cross check signed transaction if it has not been modified by the stick itself).

By the way, there has been successful hacks with modified USB mouses (given to company employees as a gift). Mouse acting as mass device with autorun file and 90% of Windows users are screwed. This is a problem of "universal serial bus", unfortunately using USB is the only reasonable choice if we target to common users.

That's also the reason why we're building Raspberry Pi shield for hardcore geeks; it is much easier to recompile everything from sources to be sure there isn't any malicious code.

How about we reduce the "talking" between the wallet and the computer as much as possible?

The same problem is/was with electronic banking and tan(-passwords). It is now solved via a small device which signs a transaction (via your banking card, which you put in). The bankingsoftware/bankpage produces a challenge. It comes as a "flicker code", which the device reads in directly from the screen. You see the transfer details on the devices' screen to verify. The device then "signs" the "transaction" and shows a generated tan on its screen. You type the tan into your software/page.

The software easily finds out if anything was altered, because then the generated tan doesn't match, and/or the info on your (infected) computer and on the devices' screen don't match.

I love that thing! Quick, easy, and pretty cheap hardware - five photodiodes and some software.

https://upload.wikimedia.org/wikipedia/commons/d/dc/ChipTan_comfort.gif
https://upload.wikimedia.org/wikipedia/commons/f/fa/SmartTAN_optic-Gadget.jpg
https://www.youtube.com/watch?v=U7PnC1S-j4I

Yes, we have a slightly different setup here. Maybe some nifty idea comes out of this?

Ente

[Ente]

I had similar plans, for a Bitcoin "vault". It was more aimed at companies, for automatic tx signing. With focus on hardware security (IDS, heartbeat, key purging etc). Heavy use of PKI. With a custom ruleset for automatic signing, manual approval and selfdestruction.
Interested in a "corporate version"? I bet a lot of the hardware and software could be used for both!

I've been thinking about such boxes after I've been hacked on Linode. It may be standard computer with minimal linux distro and custom software with extremely limited interface to the rest of the world and with possibility to define own rulesets will make attacks much harder. At this stage we're working on standard wallet which hopefully fit needs of the most users, but later we can think about other related projects as well...

Sure, it is "easy" to build such a box. And you bet most big players around here have.
But building such a box from scratch for this use, custom hardware, custom hardened software, (close to) no attack vectors from outside even when under physical attack, I think there is a market. And from building one to building a dozen it's no big difference.

Yep, one after another! Maybe we'll do something together later then!

Ente

[slush]

How about we reduce the "talking" between the wallet and the computer as much as possible?

In contrary to chipTAN, we need bi-directional communication between wallet and the computer. There are some possibilities like communicating with QR codes, but both device and computer needs a camera. I'm not aware of any other usable interface than USB, and plugging USB into the computer is like having an unprotected intercourse. It is perfect for the most of the time, but it's never 100% safe :-(.

I can imagine some workaround solutions which will skip the USB requirement, but everything will affect usability in significant way. I still think that there's no simple solution and the advice "don't connect untrusted gadgets to your computer" will work for the best in the real world.

[DeathAndTaxes]

Is it still the case that if you hold down the shift key whilst plugging in a USB that no autorun stuff will occur (in Windows)?

You can.  You can also disable that feature and you can lock that option down using group policies.  However slush has the right mindset.  Assume the user (or at least some of the users) is not technically competent and the host machine IS compromised (not that it might be or could in a minority of cases). 

Assume every single time the device is connected to a host it is done so by an average facebook users AND every single machine it connects to has been horribly compromised giving the attacker complete control of everything on the host.  If you can make it safe even then well you have a winner and likely will sell tens of thousands units (and if/when Bitcoin grows like millions).

[Mike Hearn]

This is cool and 2-factor auth is definitely the right direction. We've been discussing it a lot in #bitcoin-dev lately with Gavin.

I think it's worth focusing on much simpler attacks than most of the ones listed here (side channel, etc). The simplest attack is simply substitution - wait until the user is trying to make a payment over a certain amount and then swap the address for one owned by the virus author. The user won't see anything suspicious because the address they see on their compromised host PC and the address they see on the hardware device will be the same, and addresses are opaque random numbers. You can't tell good from bad.

Obviously even if this attack is possible, it's still an upgrade over no second factor at all.

I'm not working on this and real implementations win. But the way I'd start is by making the whole 2-factor flow work well with Android phones, and try to develop a payment protocol that adds identity to the Bitcoin ecosystem in parallel. The thing the user sees on screen should be "pay bitmit.net 12 BTC" not "pay 1AbCd... 12 BTC". It's just much easier to put together a solution when the hardware device is a real computer with network access, a good CPU, etc. It also means you can focus entirely on the software side of things - which is still a huge amount of work!

You may object that using a smartphone as a second factor is less secure, because smartphones can get viruses. I would disagree. If you buy a new phone, install a single app on it and never do anything else with it (so the only data moving on/off the phone is payment requests), then there's no difference between this and a dedicated device. Super cheap Androids are becoming available (<$100 no-contract phones are now available in Africa) and the prices are falling constantly. That's not quite as cheap as a Raspberry Pi but you get a display, touch screen and wifi with it. If you want to have own-brand devices you could just purchase these phones and reflash them to a custom OS build that just runs your single app after doing the development with regular phones.

The advance is, as always, less work so it's more likely to actually ship.

[slush]

... There are some possibilities like communicating with QR codes ...

When you think about it a bit more, even such solution doesn't save your ass when you have hacked token and compromited machine. At least until you have deep understanding of wire format and you can manually decode and check payload of the QR code. So absolute safety is mostly impossible or impractical if you cannot trust any piece of your hardware :-).

[slush]

I'm not working on this and real implementations win. But the way I'd start is by making the whole 2-factor flow work well with Android phones, and try to develop a payment protocol that adds identity to the Bitcoin ecosystem in parallel. The thing the user sees on screen should be "pay bitmit.net 12 BTC" not "pay 1AbCd... 12 BTC".

As far as I know, there's no formal proposal of some payment protocol which address this, correct? I know that sipa wanted to work on something like this and I like the idea. I also think that it should be possible to implement such payment protocol into the device as well.

The advance is, as always, less work so it's more likely to actually ship.

I absolutely agree and we also considered this. We rejected it for many minor reasons, mostly that software stack is much more complicated there and it's harder to do formal security audit of the token software. And it's something we're aiming for in the future...

[molecular]

Regards to my previous post, users should even refuse offers like "bitcoin token with USB mouse as a free gift" ;-).

or "100 BTC plus TrustKee hardware wallet as free gift"

[SgtSpike]

How about we reduce the "talking" between the wallet and the computer as much as possible?

In contrary to chipTAN, we need bi-directional communication between wallet and the computer. There are some possibilities like communicating with QR codes, but both device and computer needs a camera. I'm not aware of any other usable interface than USB, and plugging USB into the computer is like having an unprotected intercourse. It is perfect for the most of the time, but it's never 100% safe :-(.

I can imagine some workaround solutions which will skip the USB requirement, but everything will affect usability in significant way. I still think that there's no simple solution and the advice "don't connect untrusted gadgets to your computer" will work for the best in the real world.

Thanks for that. Now I'm going to think of that every time I go to plug in anything via USB.

On another note, Windows XP patched to SP3 also has autorun disabled.  But I agree - build the security for the lowest common denominator or the device will fail.

[flipperfish]

Is it still the case that if you hold down the shift key whilst plugging in a USB that no autorun stuff will occur (in Windows)?

I'm not a windows user, but can't one just turn this off completely?

In Win 7 and afaik in XP SP3 autorun is completely disabled. It's even impossible to turn on. Only "Autoplay" is active. That's the little window that pops up and asks, what you want to do with the newly inserted device. For USB devices and hard disks it's not possible to run a program from this window. The only actions allowed are opening an explorer-window or media player, etc. For CDs the program in autorun.inf can be run from there, too.

[someone42]

Hello all!

Today we'd like to announce a project I and stick have been working on for the last couple of weeks. We decided that we want to keep the development open since the beginning.

We are creating a hardware bitcoin wallet, basically a device that is a secure place to store private keys to your bitcoin addresses. Because all transactions are signed in the device itself, the keys never leave the device and thus cannot be stolen by a virus, malicious code or an attacker.

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.

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. There are some example packets (.bin files you can send over a serial link) in https://github.com/someone42/hardware-bitcoin-wallet/tree/master/avr/tester. What do you think?

[etotheipi]

Are you not interested in being compatible with Armory?  Or rather, getting Armory compatible with it?   Armory offline wallets basically already do this, they just require bigger hardware (laptop), and less secure transfer method (USB transfer using bulky operating systems).  I always wanted to expand to dedicated hardware just like this, but my hardware skills are nil.

I'll offer my advice anyway, even though no one asked for it:  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. 

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.

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. 

The device could also have a separate memory bank for downloading the watching-only wallet from it.  This isn't ideal, since it tells an attacker how much money it's protecting (if they didn't already know), but it provides excellent versatility.  Maybe not the best idea, but good food for thought.

This stuff is already available in Armory, it just uses a different wallet format and data transfer format (BIP 10).  Theoretically, if you adopted both, it would work with Armory right now, and you'd have the rest of the cold-storage software infrastructure completed already.  Of course, standardizing on BIP 32 is the path forward, and Armory will be implementing that...  Also, I've been seeking people to help design a new BIP 10, so maybe you'll be inspired to help.  You need to make sure that you accommodate multi-sig transactions, too ... make sure the transfer protocol accommodates pushing P2SH scripts, and the device knows how to sign them.

[Ente]

Absolutely!
I wondered too why Armory wasn't mentioned yet.
You want security? Go Armory! :-)

And yes: At this time in the development of clients, of hardware and Bitcoin in general, standardtizing is a top priority! We are too small to already fall apart.
Thank you, someone42 and etotheipi for your offers and work toward a secure (hardware) standard!

Ente

[etotheipi]

By the way, I already started implementing BIP 32 in the "newwallet" branch of Armory.  I didn't realize anyone else was looking at it, yet.  I have some HMAC and CKD unit tests in Test_HMAC() in BlockUtilsTest.cpp.  I was waiting for sipa to get back to me with his results, but so far no one else had implemented BIP 32 to measure against.

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.   (it sounds like there's no hurry)

Please keep me in the loop so that I can help accommodate users who want to use this HW with Armory.

[etotheipi]

After talking to Jim via PM, I wanted to clarify and expand a point about my recommendation for a hardware switch to upload wallets.  I think it should be considered:

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

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.   

In the absence of the device communicating the private keys out some side-channel, this makes the device trustworthy to a much wider base of security-focused users.    Yes, some users would use the built-in entropy generator.  But there are plenty of users for whom the extra key-input channel would improve both security/confidence, as well as convenience (to make backups and watch-wallets).