It's an Android app, so no, it won't work on the iPhone (any iPhone).

I'll check the Settings menu on my Note II, I have one as well. What happens when you click 10 times or more in quick sequence on the QR code? Does the screen not go red (indicating config mode)? There is no "menu" per se (if you press the Menu key from within the app), there really aren't any settings in the app. Let me know what you'd like to set, maybe a Settings menu is needed after all.

And how is it aggressively monetized? It's FREE! As long as you keep your balance below 1 BTC and transactions below 0.1BTC. So it's free to try it and for small transactions and costs about $25 (at the current exchange rate) if you want to store more than 1 BTC or make larger transactions. I love it how people don't even blink when they hear that the Trezor costs $100 for the standard and $300 for the metal one but run for the hills when we charge nothing for small transactions and $25 for heavy users... .

It does have a camera on the back, what are you talking about??? I have one right here and you can see it taking pictures of the laptop screen in the Youtube video I posted above, where did you expect the camera to be?

You mean like this: https://bitcointalk.org/index.php?topic=210371.0 ?

The users will inherently trust the wallet (at least most of them will - after all, if we wanted to spend their money we could simply modify the recipient and sign the transaction and they wouldn't know). They can also verify the APIs we call - there's a hardware RNG on board, but I guess they could also claim the RNG is bugged to not actually generate random numbers.

I'm just trying to minimize the friction here - give power users the ability to influence the random number generation process, etc. Most users will just click "Generate" and the wallet will create a new address for them. Then click "Sign" and get it to sign a transaction. That would mean they trust us not to send their funds somewhere else. And of course, we would make money by selling the wallets, so we have no interest in security incidents of any kind .

Hi everyone,

I'm working on a hardware wallet for Bitcoin and I am trying to understand the way subliminal channels work for ECDSA signatures and how to prove to our users that we are not leaking their private keys.

I can't say I understand all of the math involved, but here's what I gathered (mostly from http://www.emsec.rub.de/media/crypto/attachments/files/2011/03/subliminal_channels.pdf ).

1. There is a broadband subliminal channel that works by choosing a non-random k value in the signature generation algorithm. However, this method requires that the recipient know the private key (and that's exactly what it would be meant to leak). So I think this one is ruled out.

2. There are two other narrowband channels (1 bit) - not much to worry about since they would take 256 signatures to fully reveal the private key.

3. There is a third narrowband channel that can transmit messages of up to 140 bits or so without requiring the receiver to know the private key, so this one could be used to leak the private key. However, if I understand it correctly, recovering the message would require significant effort on the receiver. According to this paper https://www.google.ro/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0CDsQFjAC&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.11.122%26rep%3Drep1%26type%3Dpdf&ei=_wTBUbaVOM3htQbOzYHoBg&usg=AFQjCNGSNhhwAwY7UULuPYTUUtk7yImtTg , at least 2.71*2^x input values must be tried in order to recover x bits of data. This would make it completely useless for sending a 256-bit private key, provided that the key is truly random. It would be similar to bruteforcing the private key.

So could anyone with a better understanding of ECDSA let me know if I'm missing something? If the private key is random (and I can ensure that by allowing the user to provide random input into the generation process), should my users worry about the implementation leaking their private keys through any of the means above?

Thank you,
Razvan

A credit card doesn't cost $100 in plastic and $300 in metal and the bank will exchange it for free if stolen/damaged. And if they fry the NFC part via EMP, you still have the magstripe. If they also apply a strong magnetic field and erase that as well, you still have the card digits and one of those imprinters would work just fine.

Again, I'm not saying it can't be made secure, I'm just pointing out that it's not as easy as "just plug it into the merchant's USB port and it will work". There's a lot of work that still needs to be done to make that happen and I doubt that any merchant will invest in all this extra hardware just to support a $100-$300 device that people _might_ have on them.

I'm speaking from experience, I've seen what happened to contactless Visa and Mastercard deployments here in Romania. Very few people have contactless cards, so even though the employees get training on how to use the terminals, they forget it if nobody pays that way. They simply ask you to use the card as a normal chip-and-pin card and their contactless readers are either disconnected or broken. Who's going to offer maintenance services for all this extra hardware and how much will it cost the merchant? Will it make sense for them financially to pay that amount (what advantages do they get compared to standard Bitcoin payments)?

Ok, so now the merchant needs a second computer, with a secure interface to the main computer / cash register, with Internet access (since it needs to see the blockchain) and software developed for both the main computer and this computer. Yup, that will work ...

Also, you keep saying that the Trezor doesn't have to trust the computer - you keep forgetting that they have an electrical connection - what if a merchant decides to apply let's say 500V on the +5V line of the USB connector. Poof goes your 1 BTC (or 3 BTC) wallet (unless it has some sort of discharge protection - does it?). The same works in reverse, what if I make a Trezor lookalike with a supercapacitor that discharges over the USB port of whatever I plug it into. Poof goes the super-secure second computer / cash register.

I'd rather have it work over NFC, that's a much better idea.

No worries for who? You or the merchant? Just go into a store tomorrow and ask them if you could plug your Trezor (or a USB stick or a keyboard or something) into their cash register to pay .

I'm not saying it can't be done, I just don't see merchants installing and securing a separate computer for Bitcoin payments (something you could safely (for them) plug any USB device in). Look at that link I've sent you, that rubbery ducky USB flash drive is actually a keyboard that instantly types a set of commands to hack your computer the moment you've inserted it into an USB port. No need for autorun, as far as your system is concerned, it's a keyboard, typing commands. Have a look, it's nice (and scary at the same time).

It may be safe for you, but not for the merchant . It's their computer (possibly the one running the cash register) that you're plugging the Trezor in ... not gonna happen .

It is safe to use on your own computer, even if it's infected with malware/viruses/etc. It's not necessarily safe from physical attacks (and I don't think they ever claimed it would be), it just exposes a Bitcoin signing interface through a very limited interface. It is also not a full Bitcoin wallet, it's just an accessory to one.

What he's saying is that the device could be attacked - obviously not by design, it's designed to not allow the private key to be read by issuing commands to the Trezor. But depending on the chip they've chosen, physical possession of the Trezor by an attacker would allow him to run other types of attacks (power analysis, etc.) to extract the private keys from the memory.

I don't really expect any merchant to allow you to just randomly walk in and plug a device (_any_ device) into an USB port on their computer. Especially one that implements the HID protocol (presents itself as a keyboard). See http://hakshop.myshopify.com/products/usb-rubber-ducky for an example of what I mean.

As far as I understand, the Trezor is meant to keep your private keys secure in case your computer is infected with malware. It's not something you would use at a merchant.

Can you add our offline wallet: https://play.google.com/store/apps/details?id=com.cayennegraphics.visualbtc ? It's a truly offline solution, all communication is done via animated QR codes. Server side is just a webpage in a browser (using HTML5 and JavaScript to read the animated QR codes and post the transaction to the Bitcoin network).

Razvan

If your private key is on a smartcard inserted into your phone and never leaves the card, it only signs transactions, best of luck to the thieves trying to extract it (if you figure out how to do it, NXP and a few 3-letter government agencies would like to talk to you). You really don't get how smartcards work, do you? Also, "nothing stops the actual transaction process that exists, from being manipulated" - oh, yes it does ... it's called an ECDSA signature attached to a raw Bitcoin transaction - good luck manipulating that once it hits the computer reading the QR code.

Michael, he's all yours .

Ok, no problem, I'll move the discussion to the VisualBTC thread. Just one thing: I never said I would reimburse people for hardware failures. In fact, they would be required to present a physically intact and working VisualBTC smartcard with a valid transaction log on it to get their money back. I'm just guaranteeing that their private key will not be leaked and used for transactions without their knowledge. If their smartcard gets stolen, they won't get a penny. However, if their smartcard was not used for the transaction, they will get their money back. It won't be me issuing the refunds, it will be an insurance company that will have full access to the source code and to the specification of the NXP tamper-proof chips we use (under strict NDAs, required both by the smartcard manufacturer and the chip manufacturer - NXP). If we get even a single request for a refund, something went terribly wrong with the hardware security and tamper-proofing of the chip and it's not something NXP will allow to happen (their high profile government and military customers would kill them ).

Take care,
Razvan

One more thing (I should probably post it to the VisualBTC thread but it answers some of your questions as well): our plan is to augment the VisualBTC wallet with a smartcard-based key generation / signing system. Once we have that in place, all key generation and signing will be done on that smartcard and the smartcard will keep track of all the transactions it has signed. Then, we will offer a contractual guarantee to reimburse the users for any transactions performed with their private key but not stored in the smartcard log. If we somehow leak the private key and it is used to sign a transaction without going through the smartcard, we will commit to pay them back (they would of course have to send the card back to us to extract the log). So we would effectively insure them against all loss of Bitcoin due to stolen private keys.

Why does it matter if the user accesses www.visualbtc.com or a locally saved file? All the service does is post a string to blockchain.info/pushtx . Are you trying to make sure that we won't modify the server to somehow activate a hidden flag in the wallet that would send back the private key? What I'm saying is that you will put at least a _little_ trust in some component of the system (unless you design it from the ground up, from hardware to OS to application software). Even with VisualBTC fully open source, there are a lot of components that are not (and definitely not the hardware). As you said, maybe the Chinese tablet manufacturer has already built in backdoors, who knows? Let's all go and design our own hardware for everything to be 100% safe...


You mean the average grandma will go reading open-source peer reviews before she purchases it? I wonder who does code reviews for every version of Bitcoin Wallet for Android released (there have been some 4-5 updates in the past 2 months). People will just happily click the  Update button and go on with their lives. No offense, but please point me to a recent code review for the Android version of Bitcoin Wallet or one for Electrum. Also, please present evidence (if any) of average end-users demanding to see code reviews before they install / update. 

Also, let's tell the average grandma to demand that her bank releases the Internet Banking software and the JavaCard applets powering her chip-and-pin credit card as open source, to make sure they're not stealing her money. Best of luck with that .


Once again, we do not sell that tablet. You buy it from Amazon UK and it's imported by a company called Storage Options from the UK. There's nothing special about it, other than being a known piece of hardware that we can develop against without having to worry about all the tiny hardware differences and firmware releases and everything. If you want security, you want to minimize the variables. Sure, it works on anything, but then it's your job to secure it. It's your choice - use your old smartphone and keep your fingers crossed or pay $50 (not to us, for Christ's sake) and get the recommended platform.


I'm not saying the malware will send the key away. I'm saying it could piggyback on the existing QR communication channel (or replace the app altogether) and tell the user to go a specific site to upload his transaction (or to synchronize).


I thought you said the tablet (or phone) could come with malware pre-installed . Factory reset only resets to whatever was preinstalled on the device (with all factory-installed malwares ).


Ok, next time you go to the hospital and need a CT scan, tell your doctor that you want to have an X-Ray instead on their old X-Ray machine, CT scanners are known to be very power hungry and non-ecological and all. Of course, you might die from radiation overexposure but hey, it's X Rays, it should work "irrespective of the particular hardware" used.

What I'm saying is if you want to secure your money, you buy a SAFE, you don't reuse your old filing cabinet.

I'm not sure what you mean by "verified through an API"... at the time of the payment, the merchant must ensure that the payment comes from a smartcard that is running the correct software that doesn't leak the private keys or allow double spending. The merchant terminal also needs to be online in order to post the transaction to the Bitcoin network, so verifying the address is just an HTTP call to the "green address" list server (or servers).

Also, the split-key scenario must be very carefully designed to prevent the user from reassembling the private key outside the card. Otherwise the user could simply do the double spend from another device loaded with the reassembled private key.

The server involved is blockchain.info - we fetch transaction information from it to verify the transaction "server side" (it's actually "browser side" but I thought that would be confusing in the video). We also use the blockchain.info/pushtx service to push the raw transaction to the Bitcoin network. The HTML and JS files are not fetched from their server (obviously), we only call their APIs via AJAX and you can check that in the code.

About the QR codes, you can check what the webpage (="server") does with them. Even if I were to send the private key, you can check in the source of that webpage that we simply take whatever the VisualBTC wallet sends, post the data to blockchain.info and display the transaction details to the user, then if he agrees we post the raw transaction via blockchain.info/pushtx . This all happens in your browser. It has no connection back to our server (once again, you have the sources, you don't have to take my word for it).

BTW, do you check and understand the sources every time you download an update to Bitcoin-QT? Do you also check and understand the sources every time Google Play Market tells you there's an update to Bitcoin Wallet for Android? Do you expect your average grandma to be able to do the same?

From a commercial point of view, supporting old smartphones as the basis for our wallet would be a complete nightmare. People will use them in unintended ways and will lose their money. You worry about the sources of our Android app, I worry about the sources of everything else that's running on that old smartphone. On most old Android versions, rooting is only a matter of running the proper app _on the phone_, so once you have a rogue app in there it could intercept your keypresses or send your private key away (for instance by telling you that "we've updated the site, go to http://www.ourpirateapp.com/ instead of http://www.visualbtc.com/" and send your key via QR codes).

I would rather have a device that has no WiFi and no way for the average user to re-enable it (if they go into the bootloader via USB cable they're no longer average users and presumably know what they're doing). And most users with significant savings or little technical knowledge will not find the $50 price for the hardware much of a barrier to entry.

Also, the reasons I dislike the idea of reusing old hardware (old smartphones) are:

1. They will fail (sooner or later) and possibly take your life savings with them. I've had relatively recent smartphones go dead on me twice in the last 3 years ("thank you LG"....)

2. If they still have working network connectivity (GSM / GPRS / 3G / WiFi), it's too tempting (and easy) for the user to enable it "just for a bit" to download AngryBirds - wouldn't it be a pity to waste so much processing power just to store Bitcoins ? At that point, they're open to malware and direct attacks. The reason I keep recommending that $50 tablet (that we don't even sell directly) is that it only has WiFi on board that can easily be disabled altogether in the bootloader, making it the perfect candidate for a completely offline Android device. You can still install apps and games on it via USB cable or microSD card but it's not for the average AngryBirds-playing Joe.

Just three things for tonight:

1. VisualBTC does not require a server, the online part is just HTML + JavaScript, if anyone downloads it and hosts it somewhere else it will work just as well. I will probably host a copy of it on Amazon S3 just to show that it's possible to do so and that it does not require any server-side technology (PHP, etc).

2. Since it's just a webpage (HTML5 + JavaScript), you have all the sourcecode right there. It does use quite a few JavaScript files (because it does a lot behind the scenes) but all the JavaScript files are right there for you to read and understand.

3. The animated QR codes are just that - a sequence of QR codes. You can read them with any application and reassemble the big content they're trying to convey by animation. No hidden content or conspiracy here . If you're worried that I'm sending your private key, just read the code sequence with a QR code reader (or enable debugging in the JavaScript code so that it shows you what it reads, see #2, you have the sources)