Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 261. (Read 965789 times)

@Ente

I think it caters for a pretty wide niche : people who do not know what a private key is and are not interested in finding out.

If they are fairly techy they can set one up themselves and it should be plug and play with their desktop bitcoin wallet.

I imagine we are all informal IT support for our family. For people who trust you, you could set one up for them and keep the mnemonic phrase in a sealed envelope. They can use it and not think about private keys. Then if/ when they call you for help because they have lost their WhateverItIsCalled you can sort them out.

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.

Excellent point!
I didn't even think of this yet. But now I fully agree!
I would be wary to trust my long-long-term bitcoin savings to anything. My paperwallet works and is pretty secure. If I can import my own keys I would feel much more secure to put larger amounts of Bitcoin into a third-party-device.

So, what is the niche for this hardwarewallet?
-Small amounts and amounts to spend on burgers and beer: android, bitinstant, mtgox
-Long-term and large amounts: offline (paper) wallets

Ente

Well, it's going to be fairly easy to bypass CRP Level 1 via the exact method they suggest unless you put a fair amount of effort into preventing this. Not sure about higher levels though.

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

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.

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

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.

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?

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.

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.

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

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.


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

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

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.

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

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.

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

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

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