Use old out-of-service smartphones for BTC offline storage+signing transactions

[Michael_S]

[Android, iPhone, old smarthpones, offline wallet, hardware wallet, HW wallet, offline storage, bitcoin, secure, private key, sign transactions, mass adoption, mainstream]

Hello,

I use an EeePC with Electrum bitcoin client as offline storage. But the EeePC is expensive and difficult to set up, so this won't be done easily by a "normal person" from the street. On the other hand, installing a smartphone app is as easy as a click, and more and more people have old smartphones that they do not use any more.

So today there already exist solutions for secure offline storage of private keys on offline computers. On such an offline computer you are able to sign transactions created on a corresponding online computer. The transfer of the (un)signed transaction data back and forth between the two computers is typically done via USB stick. (examples: Armory or Electrum bitcoin clients, or the "S-Electrum" Linux user front-end for Electrum).


The problem that avoids mass-adoption of this scheme: People need to own an extra computer (the offline PC). This is an investment that most don't want to make (e.g. a Linux EeePC >= 200 USD). Also, such an extra EeePC needs some space in your flat (at least more space than a small smartphone), and you might be tempted to use that neat new netbook for other purposes than just "bitcoin-banking", which you shouldn't.

On the other hand, more and more people (me included) have old "worn-out" smartphones that they do not use any more, because too little memory, or too slow, or a scratched screen. So the solution is quite evident:

Use your OLD worn-out SMARTHPONE as OFFLINE STORAGE!

Idea: Create an open-source Android app (preferable compatible with OLD versions of Android down to version 1.6 or 2.0) that has the following features:

• Generate new private key(s) [by collecting random data from physical sensors, like mic/gyroscope/compass/camera/touch-screen input, or a combination thereof, compare how "TrueCrypt" is doing it when creating a new encrypted container!]
• Store the private keys encrypted (AES256) on this smartphone
• Display the (encrypted) private keys on screen (plain text or QR code) for backup purposes
• Export the encrypted(!) private keys to micro-SD card
• Import an (encrypted) private key (or many together) from reading a QR code, or from µSD-card (to restore the same instance on a second (old) smartphone)
• Export of the corresponding Bitcoin Addresses, to be used in a corresponding "online version" of this app (or another app) - via QR code or µSD card
• Ability to detect if this smartphone has ever gone online any time since the app was installed (I suspect there are some data from the Android/iOS system that can be queried to find this out). If yes show a BIG warning message to indicate to the users that this is not what he/she should have done and that the private keys could be compromised now. (see end of this posting for what the app should do in this case)

And then, of course these features:

• Import of an "unsigned" transaction, by reading a corresponding QR-code or via ASCII file from µSD-card
• Display the transaction details of the imported unsigned transaction on the screen
• Sign the unsigned transaction with the private keys (requires entering the passphrase to unlock the private key(s) [offline wallet]).
• Generate an ASCII string of the signed transaction and display it as QR code, or export to text file on µSD-card.

The import/export format of ASCII strings for the list of bitcoin addresses, the "unsigned" and the "signed" message should be STANDARDIZED, such that other apps (that are the online-counterpart only running the online wallet without the private keys) can interoperate with this app!
So this interface should be documented somewhere. An example is to use today's Electrum format as the standard, I don't know if Armory uses the same.

So furthermore, there must be a corresponding ONLINE-instance of a bitcoin client that is used by the user to administer his/her wallet, watch his/her current balance, administer his/her address book, and last but not least initiate unsigned transactions or send out signed transactions. Before sending out a signed transaction, the client should show the user in human readable format the details of the signed transaction that he/she is about to send out to the bitcoin network.

This online instance of the client could be for example...
- the same app, just running in "online-mode" instead of "offline mode",
- any other app that supports the standardized interface for exchange of (un)signed transactions and bitcoin addresses,
- an interface-compliant client on any personal computer.

I hope that such a project starts some time in the near future - this would make mass adoption of SECURE bitcoin usage possible, and make sure people make reasonable use of their OLD smartphones, and people won't have to bother about any malware on their online PCs stealing their bitcoins!



Note that after installing this app on the old smartphone, it should go offline FOREVER! Remove SIM card, delete the WLAN password (to avoid unintentionally going online) etc., and the app should push the user to do so by corresponding screen displays in a very naggy and paranoid way, and it should check as much as possible that the user has done so, e.g. check if the user has not yet deleted all WLAN passwords or has not yet removed the SIM card, the app shall reject creating or importing any private keys until this is the case! Also, when the app detects any time later (when everything has been set-up) that the user has again entered a WLAN passsword, entered a SIM card or has been online ANY time since (e.g. in Android the 2G/3G/WLAN data counters could be queried), the app should from this moment ALWAYS display a NAG SCREEN that tells the user that this app is not safe any more because the phone was online in the meantime.

If this happens, there could be a way that the app proposes the user to re-establish secure operation: It asks the user to go offline and delete all WLAN passwords etc., then to create NEW private key(s), and initiate a transaction that transfers all funds of the current (possibly compromised) private keys to the new generated address(es). Also it should ask the user to create a new passphrase for protecting the private key(s). This is a new special operation that requires an additional specific signed message to be transferred from the offline to the online client instance, such that the online client can then actually initiate this transfer as a new normal unsigned transaction (only the online client knows the current balance and can actually initiate the transaction). So this extra message also needs to be STANDARDIZED, as a signed message (signed by the old and NEW private key(s), and including the bitcoin address(es) of the new private key(s)) that acts as a "transaction creation request" from the offline PC (=old phone's app) towards the online PC.


PS: The offline-storage app I am talking about could ideally save the private keys in encrypted containers that can (optionally!) have hidden volumes. This would provide plausible deniability, like in TrueCrypt, i.e. if someone forces you to give the password to your offline keys, you disclose this "alibi password" for the outer volume containing only some keys with a fraction of your overall savings, while the hidden volume contains all your keys.

[drazvan]

Have you seen my recent thread at https://bitcointalk.org/index.php?topic=210371.0 ? At $50 for an Android 4.3 inch tablet with capacitive screen and WiFi and camera and Android 4.0.4 on board it's probably cheaper than most second-hand phones. WiFi on it can be completely disabled in the bootloader so that Android doesn't even seen it when it boots up and can't re-enable it.

And you don't have to go through microSD cards, you can simply use QR codes while the wallet stays offline.

[icellan]

I love it. I wish I could help :-(

I would potentially mate this with a sister application that runs on a modern phone (with network connectivity) that can create and later transmit the transaction to the network. They could both just communicate via QR codes.

Good luck with the project!

[Michael_S]

I love it. I wish I could help :-(

I would potentially mate this with a sister application that runs on a modern phone (with network connectivity) that can create and later transmit the transaction to the network. They could both just communicate via QR codes.

Good luck with the project!

Oops, I think this is a misunderstanding...

When I wrote "I hope that such a project starts some time in the near future", I did not mean that I am personally going to start such a project, I just wanted to say that I hope (in the interest of the bitcoin project, for the people's security, and for giving purpose to worn-out smartphones) that someone is taking this idea and makes a project of it him/herself.

However, if people find together willing to work on such a project (maybe starting by working on an Android app that takes the job of the safe offline wallet [the online-side can be done later, if the interface spec is clear]), I am willing to join the team. I am not an Android programmer myself, but I can contribute in terms of co-ordination, conceptual work and documentation/specification.

[drazvan]

Michael, have you looked at VisualBTC (I mentioned the link above: https://bitcointalk.org/index.php?topic=210371.0 )? It's that offline Android app you're talking about, the online side is just a webpage (no server side stuff, just HTML + JavaScript). We're currently running it on a cheap Android tablet, but it runs on any Android device (as long as it has a camera and a screen).

We're in the process of raising some seed money to allow us to work full time on this, keep your fingers crossed .

[Michael_S]

Have you seen my recent thread at https://bitcointalk.org/index.php?topic=210371.0 ? At $50 for an Android 4.3 inch tablet with capacitive screen and WiFi and camera and Android 4.0.4 on board it's probably cheaper than most second-hand phones. WiFi on it can be completely disabled in the bootloader so that Android doesn't even seen it when it boots up and can't re-enable it.

And you don't have to go through microSD cards, you can simply use QR codes while the wallet stays offline.

Hi drazvan,

in fact I have not seen your "VisualBTC" project before I started this thread. Thanks for pointing to it, it is quite interesting. I can imagine that you have put some time and efforts into it.

There are indeed similarities to my concept idea, but also some important differences that are key in terms of value for the user, see below.

I also propose the data exchange via QR code as primary means. I like the idea of "animated QR codes" - clearly the most evident solution that comes to mind for transferring strings that are too long to fit in a single QR code - this will probably be the preferred method in my concept as well.

I mentioned the "µSD card option" as additional optional means of data exchange, to make the app more "complete", because there definitely do exist use-cases where the "µSD card option" is needed, e.g. when the online client is a PC (w/o webcam) and not another smartphone, or when you want to export your (long) list of own btc addresses in one bunch, e.g. to be able to watch them in an app like "wallet balance", or for your online wallet app/PC client.

What I do not like at all about your app is the fact that it requires a central server (your server). If you happen to stop maintaining this server, the app becomes useless (single point of failure). Moreover, I cannot be sure that the animated QR code sequence that your app shows on my smartphone to your server does not include the private key amongst the series of animated QR codes - I guess your app is closed-source, right? So it is not trustworthy by design and therefore cannot be used as a serious secure offline wallet solution (I am not claiming you want to steal keys, but a concept design is only safe if even a SW programmer with bad intentions cannot cheat the user).

My concept does not have these two heavy drawbacks.

So after all, I do not see the value proposition of your solution. Who should really use your solution (except because it is technically interesting and innovative)?

• Users that are in need for really safe offline storage of big amounts of bitcoins for cold storage would not use it because they cannot be sure that the QR codes don't unveil the private keys to your server from time to time.
• So your solution is left for smaller amounts of bitcoin that I can carry with me and that I can "afford to loose" if it comes to the worst. But then it is easier to use a solution like the well-known and very well working app "bitcoinspinner" [my preferred one, very stable lightweight app], or "bitcoin wallet" [needs more phone resources], both of which can be installed on the user's primary smartphone or tablet. Or even blockchain.info's wallet or other online wallets (where the priv key is in the cloud of course), depending on the user's personal risk/comfort trade-off

Unfortunately, I do not really see the niche that your solution should be filling, from a user perspective.

My concept has the following value proposition:

• Pure offline storage (cold storage) with at least the same degree of safety as a paper wallet
• Spending any part of the balance of a private key is possible without exposing the private key at any time --> much safer than a paper wallet
• Spending any part of the balance of a private key is more comfortable than with a paper wallet
• Exporting AES256-encrypted (container files of the) private keys to µSD-card or QR code allows easy and secure backup of private keys at multiple places to avoid loss of bitcoin by hardware failure or physical loss/damage - again superior to unencrypted paper wallets
• Optional printing of paper wallets (export of printable text file / QR code of (un)encrypted private keys) is not precluded. Also generation of n-of-m outputs of private keys can be possible (e.g. using Linux' "ssss" scheme re-implemented in this app)
• Open source to avoid fraud by secretly displaying private keys as QR code
• Open interface for exchange of unsigned/signed transactions or export of addresses/import of private keys --> interoperability with other programmers' apps and clients. Example: Support of the "Electrum" and/or "Armory" formats.
• Independent from any single point of failure like a central server or individual person or company.
• A HW wallet with zero hardware costs for all those who own a worn-out no-more-used old (Android) smartphone.

In a nutshell - it combines ease of use with highest security, it combines all positive traits of paper wallets plus much more, plus a simple means of spending without ever exposing the priv key (provably by source code), and without relying on a single point of failure.

drazvan, I think you would have the programming skills to make this concept a reality, some parts of your app could certainly be well re-used, so I would welcome you (or anyone else reading this) to jump in and make this real. But maybe you are following other (commercial) interests with your solution? - In this case you have of course all right to do so, and I wish you good luck.

[drazvan]

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)

[drazvan]

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.

[Michael_S]

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)

1. Your Youtube video says at 1:15 "scan this at www.visualbtc.com" and at 1:35 "Server Side Transaction Confirmation", so I suppose there is a "server" involved. Now you are saying this is pure HTML/javacript without PHP or alike? So I can save the HTML file/JS files on my harddisk and open "file://localhost/home/michael/visualbtc.html" in my firefox browser without setting up a webserver myself, and it will work equally well? Which Bitcoin server's API will the javascript code use to submit the transmission to the network? It will not contact another server in the background?

3. I was expecting this reply. Sure I could verify this once or twice until I think I am "sufficiently reassured for my peace of mind" that no cheating takes place, but that is not enough for me! If there is no private key once, it doesn't mean there is never any private key mixed between the QR code sequence. So this is far from being the same as having the open source code of the app.

-------------

The follwing part is about kind of smartphone used for offline wallet, irrespective of "your" or "my" concept:

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.

These are really questions of secondary interest and should rather be tackled by smart app features as follows, to allow the user to make their own choice which HW to use:

1. Even with a brand-new phone, one must be naive or insane not to save backups of one's Bitcoin "life savings". Note that new phones fail typically more often than mid-age phone (bath tub curve of failure of technical devices!), and I am convinced that a brand new 50$ device is more likely to fail in the next 3 months than a 2 year old Sony or Samsung phone (also speaking from own experience, but never owned any LG...).

2. First of all, phones don't connect to 2/3/4G without SIM card (except emergency voice number), so it has also "only WiFi" like this 50$ device. Of course, being able to disable WiFi in the bootloader is nice to self-discipline the user a little more.

Proposal to self-discipline the user further (in case he/she re-sets the bootloader setting again to enable WiFi, to download AngryBirds "just for a bit"), I propose the following:

* The offline wallet app (no matter whether "yours" or "mine" ) should have an intent that it auto-starts at "boot complete" and immediately checks the connectivity status and airplane mode, and if these are not set to "as much offline as possible" (also airplane mode should be enforced, just to be on the safe side!), it should switch all this off (or ask the user to do so if not possible without user interaction in Android), and a nag screen should come up again and again utmost frequently (possibly every second or so) if wlan is not switched off or airplane mode is not activated, rendering the Smartphone unusable for any "connectivity-purposes". Then the user will soon stop being tempted about doing any "online-things" with this device. This would be an efficient "enforced educational means" in the sole interest of the user's own security
* Likewise, the phone shall not be able to start the offline wallet app at all and show this nag screen all the time as long as any SIM card is inserted into the phone!

[drazvan]

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.

[Michael_S]

Coming back to the question whether the QR code may convey any private key infos from your app:

Another possible attack scenario came to my mind that is possible if the app is closed-source and cannot even be proven to take place:

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

Actually, even if I "read them with any application and reassemble the big content" and the generic QR code reader reconstructs the expected info correctly, I still cannot exclude for sure that the QR codes convey private key infos "piggyback" on top of the "official" QR code infos!!!

I can still think of two attack vectors:

(1) Attack 1: QR codes are constructed with lots of redundancy for error protection. Depending on their error correction level, a substantial part of the QR code area can be modified arbitrarily and the original QR code can still be decoded correctly by "any application" that reads standardized QR codes. Now these modified bits and bytes can be manipulated in such a way that they convey other undocumented data acc. to a proprietary protocol, and this can be exploited by a malicious app to convey private keys.

(2) Attack 2: One could apply very small (hardly visible) modifications of the QR-codes raster pixels, invisible for the human eye, but still detectable by a high-resolution web cam, and by such modifications one can convey additional data like a private key "piggyback" via a proprietary protocol.

So one should not trust any offline wallet smartphone app that communicates to the outside world with QR codes or alike, as long as the app is closed source. Sure I could use it for storing smaller amounts (not my life savings), but then I do not need an offline wallet at all but can also use a standard wallet app as it exists today.

[Michael_S]

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

Thanks for the clarification. So this seems fine as long as the user is really never tempted to use a website like visualbtc.com with this app but only a pre-downloaded and code-reviewed version saved to his own computer. (However, practically, code review by the normal user is more complicated here than it is in open source projects where you have intrinsic security thanks to peer-reviews amongst developers).

So I have still some practical doubts. Also saving the html/JS code on the own computer etc. is no practical solution for the "normal" user. Such users are not used to saving websites to hard disk and then open local files "file://localhost/.../myfile.html" instead of URLs "http://provider.com/remotefile.html".

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?

You are generally questioning the benefit of open source for secure and backdoor-free SW. I do not want to lead this basic discussion here, it goes beyond the scope of this thread and has been made elsewhere many times. If you think that closed source is safer, or at least not less safe, than open source projects, any discussion is pointless of course. I am of different opinion. Even if I (or the average grandma) did not read every line of the source code myself, I (or she) can have trust that the code peer-reviews that are carried out in open source projects by the developers make sure sufficiently well that there are no undiscovered backdoors in the software.

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.

So good luck, because then you will have lots of nightmares.
You cannot enforce the HW platform that users install your app on, and you write yourself that it runs on other Android devices, too. You can give recommendations how people should use the app, but if they do not abide by it, it is out of your control. This is exactly a problem of your project, so your nightmares are pre-programmed. Users of your app will use other hardware than the 50$ tablet you are recommending, potentially even install it on their normal "online" phone, whether you like it or no. So you can prepare for your "commercial nightmares" already now!

If you want to avoid your nightmares, you should look at my last post's proposals how to add features to the offline wallet app (applicable to both "your" and "my" app concept). This can efficiently avoid wrong/unsafe usage of the app for the normal user (irrespective of what HW they are using), much better than if you just "recommend" buying a certain type of 50$ tablet from an unknown vendor and have no control were the users will really install your app.

I suppose you did not react on my proposals because this would destroy the business model that users purchase this special 50$ tablet.

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

Wait, you are mixing together many different things here.
Firstly we are talking about the OFFline wallet side here, so no malware can simply "send the private keys away".
Secondly, your cheap "unknown-vendor 50$ tablet" might be just as easily rootable as other Android phones. Maybe it has malware even pre-installed, who knows.
Thirdly, your (or my) app could have SW features that recommends a factory-reset before installation, or could even check if the device is rooted and if too many other non-system-apps are installed, and could reject its work until the phone is "clean". So SW features of your app can get around these vulnerabilies that you are listing, if you really think they are relevant.

Finally, in my concept the user is never requested to visit any website to which he/she should show the QR codes to, so this attack scenario that you are outlining here applies solely to your app concept, not to mine. (And just to mention another attack scenario: hijacking visualbtc.com by a DNS attack or by hacking the web host server which is out of your control)

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.

I would rather have an app that makes sure that the average user does not use it in a way it is not intended to be used, by the well-realizable app feature proposals I have given in this and in my previous post. This would work irrespective of a particular phone hardware. And most users, even those without any savings, and irrespective of whether they have much or little technical knowledge, will welcome if they have a choice whether to use a new $50 tablet or a more ecological and even cheaper solution of using their old smartphones.


So I am still hoping that someone reads this threads and says: "Hey, great Idea, I will join the project and program this!"

I think that my concept, as outlined in this thread (particularly in my first post) is what the bitcoin world needs - a community open-source Android offline wallet (i.e. a "hardware wallet" realised by software) using open interfaces to exchange transaction data and addresses and keys with possibly 3rd party software.

[drazvan]

Thanks for the clarification. So this seems fine as long as the user is really never tempted to use a website like visualbtc.com with this app but only a pre-downloaded and code-reviewed version saved to his own computer. (However, practically, code review by the normal user is more complicated here than it is in open source projects where you have intrinsic security thanks to peer-reviews amongst developers).

So I have still some practical doubts. Also saving the html/JS code on the own computer etc. is no practical solution for the "normal" user. Such users are not used to saving websites to hard disk and then open local files "file://localhost/.../myfile.html" instead of URLs "http://provider.com/remotefile.html".

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 are generally questioning the benefit of open source for secure and backdoor-free SW. I do not want to lead this basic discussion here, it goes beyond the scope of this thread and has been made elsewhere many times. If you think that closed source is safer, or at least not less safe, than open source projects, any discussion is pointless of course. I am of different opinion. Even if I (or the average grandma) did not read every line of the source code myself, I (or she) can have trust that the code peer-reviews that are carried out in open source projects by the developers make sure sufficiently well that there are no undiscovered backdoors in the software.

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 .

So good luck, because then you will have lots of nightmares.
You cannot enforce the HW platform that users install your app on, and you write yourself that it runs on other Android devices, too. You can give recommendations how people should use the app, but if they do not abide by it, it is out of your control. This is exactly a problem of your project, so your nightmares are pre-programmed. Users of your app will use other hardware than the 50$ tablet you are recommending, potentially even install it on their normal "online" phone, whether you like it or no. So you can prepare for your "commercial nightmares" already now!

If you want to avoid your nightmares, you should look at my last post's proposals how to add features to the offline wallet app (applicable to both "your" and "my" app concept). This can efficiently avoid wrong/unsafe usage of the app for the normal user (irrespective of what HW they are using), much better than if you just "recommend" buying a certain type of 50$ tablet from an unknown vendor and have no control were the users will really install your app.

I suppose you did not react on my proposals because this would destroy the business model that users purchase this special 50$ tablet.

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.

Wait, you are mixing together many different things here.
Firstly we are talking about the OFFline wallet side here, so no malware can simply "send the private keys away".
Secondly, your cheap "unknown-vendor 50$ tablet" might be just as easily rootable as other Android phones. Maybe it has malware even pre-installed, who knows.

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

Thirdly, your (or my) app could have SW features that recommends a factory-reset before installation, or could even check if the device is rooted and if too many other non-system-apps are installed, and could reject its work until the phone is "clean". So SW features of your app can get around these vulnerabilies that you are listing, if you really think they are relevant.

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

I would rather have an app that makes sure that the average user does not use it in a way it is not intended to be used, by the well-realizable app feature proposals I have given in this and in my previous post. This would work irrespective of a particular phone hardware. And most users, even those without any savings, and irrespective of whether they have much or little technical knowledge, will welcome if they have a choice whether to use a new $50 tablet or a more ecological and even cheaper solution of using their old smartphones.

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.

[drazvan]

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.

[Michael_S]

Hi drazvan,

it has become clear now that we have quite different views. I think it does not make sense to discuss your solution for a commercial and (partly) closed-source product any further in this thread which suggests an open source Android-based solution for a secure offline wallet. Let's use your thread for this, instead.

I think the two solutions do not compete against each other, because the value propositions are too different, i.e. the targeted users and use cases are too different.

Anyway, some short anwsers between the lines below, and I am trying not to go off-topic.

Good luck for your project,
Michael

Thanks for the clarification. So this seems fine as long as the user is really never tempted to use a website like visualbtc.com with this app but only a pre-downloaded and code-reviewed version saved to his own computer. (However, practically, code review by the normal user is more complicated here than it is in open source projects where you have intrinsic security thanks to peer-reviews amongst developers).

So I have still some practical doubts. Also saving the html/JS code on the own computer etc. is no practical solution for the "normal" user. Such users are not used to saving websites to hard disk and then open local files "file://localhost/.../myfile.html" instead of URLs "http://provider.com/remotefile.html".

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 .

It matters because if I visit the website, the owner of the site can change the code any time, can even switch from browser-side code to server-side code elements without the user knowing. Also, the site can be hacked by attacking the web host's server or a DNS attack, but I wrote this in last post already.

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

I disagree completely: For an offline wallet solution I do not want to put any trust (not even a _little_) into anybody who offers a related web service where my Bitcoin life savings depend on! Also I do not want to need to put trust in the programmer of the related closed-source app! If I want to use a service where I need to put some trust, I can use online wallet solutions or online wallet providers as they exist today, but only for a small fraction of my bitcoin "life savings".

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

Don't leave the context - I just made this point because you had suggested that an "old" phone may contain malware, so I said that also a new tablet may contain malware. Personally, I am quite sure that neither the new 50$ tablet nor the old phone (the old phone even less so!) contains malware that is able to compromise your android app (or my "yet-to-be-written" app) in the sense that it could steal the priv key.

You are generally questioning the benefit of open source for secure and backdoor-free SW. I do not want to lead this basic discussion here, it goes beyond the scope of this thread and has been made elsewhere many times. If you think that closed source is safer, or at least not less safe, than open source projects, any discussion is pointless of course. I am of different opinion. Even if I (or the average grandma) did not read every line of the source code myself, I (or she) can have trust that the code peer-reviews that are carried out in open source projects by the developers make sure sufficiently well that there are no undiscovered backdoors in the software.

You mean the average grandma will go reading open-source peer reviews before she purchases it?

No, I wrote the opposite, read my previous post, Please! Again: I said that the grandma can rely on the process of peer-reviews in open source projects! But again (I said it before!), I do not want to make this BASIC discussion about advantages and disadvantages of open source in gerneral in THIS thread, I consider this off topic, and we will certainly not resolve this by further discussion here!

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. 

Again: I do not demand this degree of security from solutions for online-wallets were users are supposed to have a small fraction of their bitcoins, like Android wallet. HOWEVER, for OFFline wallet solutions designed to put life savings on it, I demand much higher standards. Specifically, since you were asking for it, Electrum has an active development community comprising many programmers, and I am sufficiently confident that they do not insert malicious "key-stealer" code and mutually review their code. For a new open-source project like the one intended to be initiated in this thread, I expect a similar kind of community development of course.

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 .

You are going completely off-topic here - this is a ridiculous troll argument - stay serious, please! We are not talking about traditional banking here, but about bitcoin. If the bank makes a mistake and loses funds due to credit card frauds (which happens all the time), it will fully compensate the grandma for it. To be able to pay out such refunds, banks take considerable credit card fees for example (retailers pay roughly 3-5%). This is completely different in the bitcoin world, and I am sure you know that very well.

So good luck, because then you will have lots of nightmares.
You cannot enforce the HW platform that users install your app on, and you write yourself that it runs on other Android devices, too. You can give recommendations how people should use the app, but if they do not abide by it, it is out of your control. This is exactly a problem of your project, so your nightmares are pre-programmed. Users of your app will use other hardware than the 50$ tablet you are recommending, potentially even install it on their normal "online" phone, whether you like it or no. So you can prepare for your "commercial nightmares" already now!

If you want to avoid your nightmares, you should look at my last post's proposals how to add features to the offline wallet app (applicable to both "your" and "my" app concept). This can efficiently avoid wrong/unsafe usage of the app for the normal user (irrespective of what HW they are using), much better than if you just "recommend" buying a certain type of 50$ tablet from an unknown vendor and have no control were the users will really install your app.

I suppose you did not react on my proposals because this would destroy the business model that users purchase this special 50$ tablet.

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.

Wait, you are mixing together many different things here.
Firstly we are talking about the OFFline wallet side here, so no malware can simply "send the private keys away".
Secondly, your cheap "unknown-vendor 50$ tablet" might be just as easily rootable as other Android phones. Maybe it has malware even pre-installed, who knows.

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 see. So this attack scenario works if both sides (the offline wallet app and the corresponding peer (online) side - website or online wallet app/client on another device) co-operate, i.e. are equally malicious. In "my" solution it would mean both device would need to be hacked. In your solution it would mean that the website and the closed-source phone app have malicious code.

Thirdly, your (or my) app could have SW features that recommends a factory-reset before installation, or could even check if the device is rooted and if too many other non-system-apps are installed, and could reject its work until the phone is "clean". So SW features of your app can get around these vulnerabilies that you are listing, if you really think they are relevant.

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

See above, you are putting this out of context again, I made this point in the context of saying that not necessarily only old phones may have malware (as you had suggested).

I would rather have an app that makes sure that the average user does not use it in a way it is not intended to be used, by the well-realizable app feature proposals I have given in this and in my previous post. This would work irrespective of a particular phone hardware. And most users, even those without any savings, and irrespective of whether they have much or little technical knowledge, will welcome if they have a choice whether to use a new $50 tablet or a more ecological and even cheaper solution of using their old smartphones.

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.

"X-Ray"... Again off-topic trolling here. Please stop that!

As to the SAFE, I am also of a different opinion: I think the safe is less secure, because its tangible contents can be robbed much more easily. However, an AES-256 encrypted private key is military-grade secured and cannot be robbed by anyone, so the safe (with gold or money or plain-text paper wallet in it) is the worse solution - not only to my opinion, but probably to most of those who secure their bitcoin wallets/private keys by strongly encrypting them and saving them at several different places, including the cloud.

I am also absolutely convinced that a today's old Android phone's software does not have a malware installed that is able to manipulate the functioning of a future(!) app (an app that has not yet been written!) and will be able for example to manipulate the QR output of that app in a sense that enables it to steal a private key. If you seriously think otherwise (and only in this case), you should be so consequent as to also consider that the same malware is also installed on our brand-new 50$ tablet.
Personally I am so convinced that such malware does not exist on my old phones, that I would even put my bitcoin life savings at risk for that. I have much less trust however in an app whose programmer and whose source code I do not know, and which sends data to a web site whose creator and whose web hoster I do not know. This is just much less transparent for me, the user.

--------------------

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.

This is another problem: A cautious user would never trust key generation to a hardware that he cannot look into. Nobody can guarantee that the keys are statistically well generated (one needs quite advanced maths and should also use some physical(!) random number generator for that), or even malicious. Also, the hardware may fail, and then the key is gone, and so are the funds, unless there is a possibility to backup the key. But from your next sentence below I take that it is not planned that the key can be backed up (note: in my last post already I called this approach "naive or insane" - and already underlined it).

My advice to you: Don't follow this concept - it is deemed to fail, and many others before you have tried to make such bitcoin smartcards, nobody came up with a viable commercial solution.

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.

"Contractual guarantee"? You can't be serious. Like mybitcoin, bitcoinica, bitmarket.eu and all the others? You must be a Multi-Multi-Billion-Dollar-Company with huge amounts of liquidity to be able to give such a guarantee. Otherwise, such a "guarantee" is not worth a penny!

Nobody will trust in that! A user can transfer an ARBITRARY amount of bitcoins to this smartcard's address. If the smartcard gets corrupted or fails due to HW reasons, how do you want to guarantee to re-imburse the lost bitcoins? Such a guarantee is simply not possible! Imagine the Winklevoss twins transfer their 100,000 bitcoins to that smartcard, and in the meantime 1 BTC becomes worth 10,000 USD? Will you be able to reimburse the 100,000 BTC or at least the equivalent of 10 Bill USD then?

Anyway - this makes ultimately evident the fundamentally different philosophy between your commercial solution and my open source solution concept. They have really hardly anything in common:

• I am thinking of a simple open-source Android-based offline wallet as alternative to existing offline wallet solutions like Armory or Electrum, i.e. a similar concept with a comparable degree of safety, just running on Android, and using open interfaces for data exchange, with clearly defined useful yet limited features. Purpose is saving big amounts of bitcoins in a very secure way, yet being able to make payments comfortably from time to time, if needed.
• You are talking about a rather sophisticated commercial solution with lots of different features, involving partly proprietary software (requiring trust into the company making this SW) and partly even proprietary hardware. Also, parts of this basket of many different solutions relies on trust into your company's ability to have enough liquidity to pay arbitrary amounts of bitcoins to customers whose bitcoin-smartcards have hardware failures.

Now that this difference is clear, I would no longer like to discuss your commercial solution in this thread.

From here on, this thread should be confined to discussing the open-source Android solution that I would like to initiate.

I will send further replies concerning your solution in your thread, to stay focused and on-topic in this thread.

[drazvan]

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

[ISAWHIM]

I am going to tattoo my QR code on my ass... Then I only have to fear the doctor seeing it.

I'll do it with a mirror, so it doesn't work for him, if he scans it!

Hope I don't slide down a mountain and rub my ass-skin off!

Why such a complex thing, for something that should be so uncomplex?

Adding more layers just makes people NOT want to use it MORE.

I got a bank, you have to bring three body-guards, a camera, five forms of ID, your mother, the doctor who birthed you, and the person you want to give money to, also has to do the same. You both talk to me, not to each other, and give the money to Guido, who will run to your secret-tree in the woods, and bury it, then tell Sarah where he put it, in code, so she can tell the person who gave the money to you, that the money is really there...

You want proof of a deposit, just look at the address in the block-chain. They gave you the address, and you know yours, so it is already "confirmed". If you are trying to stop others from spending your coins, how exactly will that stop them from jacking your phone, or your credentials, after you submit them on the "device you use to submit"...

In the end, you are not protecting crap, because your layer is NOT PART OF THE TRANSACTION, it is a layer prior to a transaction. Nothing stops the actual transaction process that exists, from being manipulated. Just use cash and a real bank.

No, wait... convince everyone to do this... I want those lost coins to stay lost forever, when the phone breaks, when the sim fails, when the dog eats it, when a thief jacks the smart-phone, when you forget how to unlock it, when the battery dies and it can't be replaced, when the program you use to protect the code fails due to some memory corruption and completely locks you out and has no possible chance to unlock your funds...

Bitcoins could use another boost like that.

[drazvan]

You want proof of a deposit, just look at the address in the block-chain. They gave you the address, and you know yours, so it is already "confirmed". If you are trying to stop others from spending your coins, how exactly will that stop them from jacking your phone, or your credentials, after you submit them on the "device you use to submit"...

In the end, you are not protecting crap, because your layer is NOT PART OF THE TRANSACTION, it is a layer prior to a transaction. Nothing stops the actual transaction process that exists, from being manipulated. Just use cash and a real bank.

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 .

[Michael_S]

I did not get ISAWHIM's point.

[Michael_S]

My vision has become reality, thanks to the "bither.net" team!

https://bitcointalk.org/index.php?topic=696626.msg7868637#msg7868637