Topic: Proposal: Hardware wallet (Win 3 BTC) (Read 5682 times)
if our wallet is safe then I think we are also save ......................
So how do we protect from cracking the card once it's stolen?
I'm going to say for my project that that's largely out-of-scope and that this allows you to execute physical security. Think of it like a paper wallet in that context.
Fair enough - ok - you make the initial card... and I'll see about the security dongle that does biometrics once you've got specs out on the card's api.
So how do we protect from cracking the card once it's stolen?
I'm going to say for my project that that's largely out-of-scope and that this allows you to execute physical security. Think of it like a paper wallet in that context.
I likely won't even be considering biometrics. It's extremely tricky to revoke an eyeball or fingerprint. My understanding is that the card cannot be dumped (or at least it's an optional setting). If it's possible to dump the card at all (barring scanning electron microscopes), it's not going to work as it will always be possible to find a way but I'm confident that won't be an issue.
Hm - seems like you'd need to setup some second factor auth otherwise you run the risk of having the card stolen and being unable to prevent anyone from using it.
I have been thinking about that. It would likely be a passcode or pin but optional in case you are likely to be using the card on an untrusted system (though even with a keylogger or hacks, you'd still need the wallet physically attached so that may not be a big deal to have mandatory).
Also up for consideration are wallet backups and/or importing external wallets. Likely I would require a passphrase on first use. But in theory, it should be possible to set up a fresh wallet on a compromised system with no security risk.
Right just include the code to generate and address in the program on the card...
I think we've come full circle here tho, if we're going to require a user to enter auth on a device/machine they don't own, and might be unsecure... then we need some sort of security measure in place to prevent malicious action on the part of the vendors machine. If that's a 4(or really even a 10) digit pin... then it's vulnerable to being stolen and cracked... just plug it up to a computer and throw pins at it until it breaks. Which leads us back to a customer owned dongle... or biometric device.
So how do we protect from cracking the card once it's stolen?
Is it too late to suggest a name?
I think it should be called Encrybito!!!!
The Encrypted Bit O' Goodness!!
I think it should be called Encrybito!!!!
The Encrypted Bit O' Goodness!!
Absolutely 
The primary use of the card is to allow secure storage of the private key and on-card signing of transactions. In theory, it would be impossible to obtain the private key from the card without extremely sophisticated techniques (though this does raise some questions about private key backups).
Secondarily, the card may be use to cache transactions known to belong to the private key (keeping a balance if you will). This should not, strictly speaking, be a requirement but will be more of a convenience function.
Most of the functionality will still be in software running on an external computer except for the addition of a usb broker dongle to act as a gatekeeper for approving transactions.
The primary use of the card is to allow secure storage of the private key and on-card signing of transactions. In theory, it would be impossible to obtain the private key from the card without extremely sophisticated techniques (though this does raise some questions about private key backups).
Secondarily, the card may be use to cache transactions known to belong to the private key (keeping a balance if you will). This should not, strictly speaking, be a requirement but will be more of a convenience function.
Most of the functionality will still be in software running on an external computer except for the addition of a usb broker dongle to act as a gatekeeper for approving transactions.
I don't put potato chips into my phone either--technically they are both chips.
once you've got the app running on the card, why not put it in the nfc chip in a mobile phone ?
Totally different use case.
once you've got the app running on the card, why not put it in the nfc chip in a mobile phone ?
it seems a very interesting proposal.
I likely won't even be considering biometrics. It's extremely tricky to revoke an eyeball or fingerprint. My understanding is that the card cannot be dumped (or at least it's an optional setting). If it's possible to dump the card at all (barring scanning electron microscopes), it's not going to work as it will always be possible to find a way but I'm confident that won't be an issue.
Hm - seems like you'd need to setup some second factor auth otherwise you run the risk of having the card stolen and being unable to prevent anyone from using it.
I have been thinking about that. It would likely be a passcode or pin but optional in case you are likely to be using the card on an untrusted system (though even with a keylogger or hacks, you'd still need the wallet physically attached so that may not be a big deal to have mandatory).
Also up for consideration are wallet backups and/or importing external wallets. Likely I would require a passphrase on first use. But in theory, it should be possible to set up a fresh wallet on a compromised system with no security risk.
I likely won't even be considering biometrics. It's extremely tricky to revoke an eyeball or fingerprint. My understanding is that the card cannot be dumped (or at least it's an optional setting). If it's possible to dump the card at all (barring scanning electron microscopes), it's not going to work as it will always be possible to find a way but I'm confident that won't be an issue.
Hm - seems like you'd need to setup some second factor auth otherwise you run the risk of having the card stolen and being unable to prevent anyone from using it.
Well let us know how that goes.
I still like the idea of a encrypting the private key and storing it on the card - then the reader can do the biometric scan, pass that the jvm on the card - along with the amount and desitination address, and the card can pass back a signed transaction - after decrypting the private key.
I guess the important question would be - could the reader be made to snag the entire contents of the card - if so then this wouldn't be secure either. In that case, we need a dongle that the user owns, to make sure that the POS machine can't read out the card - and once we're getting into designing hardware, might as well go fully custom and just use flash.
I likely won't even be considering biometrics. It's extremely tricky to revoke an eyeball or fingerprint. My understanding is that the card cannot be dumped (or at least it's an optional setting). If it's possible to dump the card at all (barring scanning electron microscopes), it's not going to work as it will always be possible to find a way but I'm confident that won't be an issue.
I just ordered several cards and a reader so I'm about to find out
Though I do have a little experience as I ordered the java ibutton kit when it first came out. The card actually runs a Java machine with protected memory etc. It's basically a fairly retarded computer. You can talk to it and it talks back. The cards also have some built-in crypto that may or may not be useful.
The one thing you possibly can't trust is the reader device. It can lie to the card and to the user. Though maybe the reader and the card could be considered as a unit and you would own the reader. It could have the buttons and display but be fairly dumb and the smarts are in the java card. Then you can have multiple cheap wallets you can swap into a relatively more expensive reader. You might trust your friend's reader but then again, maybe only as much as a low-value hot wallet.
Though I do have a little experience as I ordered the java ibutton kit when it first came out. The card actually runs a Java machine with protected memory etc. It's basically a fairly retarded computer. You can talk to it and it talks back. The cards also have some built-in crypto that may or may not be useful.
The one thing you possibly can't trust is the reader device. It can lie to the card and to the user. Though maybe the reader and the card could be considered as a unit and you would own the reader. It could have the buttons and display but be fairly dumb and the smarts are in the java card. Then you can have multiple cheap wallets you can swap into a relatively more expensive reader. You might trust your friend's reader but then again, maybe only as much as a low-value hot wallet.
Well let us know how that goes.
I still like the idea of a encrypting the private key and storing it on the card - then the reader can do the biometric scan, pass that the jvm on the card - along with the amount and desitination address, and the card can pass back a signed transaction - after decrypting the private key.
I guess the important question would be - could the reader be made to snag the entire contents of the card - if so then this wouldn't be secure either. In that case, we need a dongle that the user owns, to make sure that the POS machine can't read out the card - and once we're getting into designing hardware, might as well go fully custom and just use flash.
Smartcards are an interesting idea. Is there any way to prevent someone from being able to extract the private key once it's loaded on the card?
The concern being someone steals a card, drops it into a reader and has full access to whatever's stored on it, including the private key.
Maybe the POS device uses some sort of biometric reading to feed another private key to the card to dectypt the one stored on the card?
That way, the card card could still sign in - but wouldn't have only an encrypted copy of the private key on it...
so without the POS machine, the smart card and the owner's proof of life - nobody would be able to do anything with it.
The concern being someone steals a card, drops it into a reader and has full access to whatever's stored on it, including the private key.
Maybe the POS device uses some sort of biometric reading to feed another private key to the card to dectypt the one stored on the card?
That way, the card card could still sign in - but wouldn't have only an encrypted copy of the private key on it...
so without the POS machine, the smart card and the owner's proof of life - nobody would be able to do anything with it.
I just ordered several cards and a reader so I'm about to find out
Though I do have a little experience as I ordered the java ibutton kit when it first came out. The card actually runs a Java machine with protected memory etc. It's basically a fairly retarded computer. You can talk to it and it talks back. The cards also have some built-in crypto that may or may not be useful.
The one thing you possibly can't trust is the reader device. It can lie to the card and to the user. Though maybe the reader and the card could be considered as a unit and you would own the reader. It could have the buttons and display but be fairly dumb and the smarts are in the java card. Then you can have multiple cheap wallets you can swap into a relatively more expensive reader. You might trust your friend's reader but then again, maybe only as much as a low-value hot wallet.
I am becoming more and more convinced that hardware wallets will be the way to go. I think I'll spend the weekend studying the rockbox project and seeing if it could be leveraged. I'm also wondering about smartcard options
$4, runs Java. There are security issues with these that I don't think would be surmountable but they may be "good enough" for many purposes.
$4, runs Java. There are security issues with these that I don't think would be surmountable but they may be "good enough" for many purposes.
removed the image.
Smartcards are an interesting idea. Is there any way to prevent someone from being able to extract the private key once it's loaded on the card?
The concern being someone steals a card, drops it into a reader and has full access to whatever's stored on it, including the private key.
Maybe the POS device uses some sort of biometric reading to feed another private key to the card to dectypt the one stored on the card?
That way, the card card could still sign in - but wouldn't have only an encrypted copy of the private key on it...
so without the POS machine, the smart card and the owner's proof of life - nobody would be able to do anything with it.
I am becoming more and more convinced that hardware wallets will be the way to go. I think I'll spend the weekend studying the rockbox project and seeing if it could be leveraged. I'm also wondering about smartcard options
$4, runs Java. There are security issues with these that I don't think would be surmountable but they may be "good enough" for many purposes.
$4, runs Java. There are security issues with these that I don't think would be surmountable but they may be "good enough" for many purposes.
- Bitcoinaire.
- Bitplug.
- Bitwallet.
- Coinmaster.
- Coinplug.
- Credstick.
- Kudofob.
- Kudokey.
- Mobiwallet.
- Portawallet.
- Stealthy.
- Transactoid.
Even with all the provided name suggestions in mind, I like where cedivad is going with his post a lot:
If you want my suggestion, don't lose your time asking for a name on a forum. Keep thinking about the design of the thing and the name will come out by its own with a bit of time.
satoshidrive
simplekey
beps (bitcoins electronically-physically secured)
bytecoin
bitmaster
Cool idea. You could see if you could get an arduino circuit modified for the protype possibly! I don't know about once you get to implementation, you may want to have a "secret circuit" for the final piece.
simplekey
beps (bitcoins electronically-physically secured)
bytecoin
bitmaster
Cool idea. You could see if you could get an arduino circuit modified for the protype possibly! I don't know about once you get to implementation, you may want to have a "secret circuit" for the final piece.
Jump to: