ECKey generation and storing in secure elements

[GoogleCodeExporter]

as part of my masters project which is related to android secure elements,  i 
would like to use bitcoin-wallet as one use case by adding some enhancements.

enhancements i would like to add.

- generation and storing of ECKeys in android secure element , these keys could 
be accessed anytime though authenticated channel by bitcoin wallet but would 
not be saved in the wallet file. instead the wallet file stores references to 
ECKeys in the secure element. additional information associated with a key 
object will remain in the wallet file.

have been looking into bitcoinj and wallet source code for couple of days. and 
would be so glad to hear any ideas about the feasibility of these enhancements. 
If this use case could be feasible on the current bitcoin-wallet version,  
would be glad to hear more details on things that need consideration.

tnx a lot in advance

Original issue reported on code.google.com by mytrial4@gmail.com on 28 Sep 2013 at 12:52

[GoogleCodeExporter]

That's a very interesting topic! I suggest taking it to the bitcoinj-devel 
mailing list also. I'm focusing more on user experience and openness of 
development.

- how secure actually is the secure element, compared to the current model of 
storing keys in app private data? Is its implementation open source (and thus 
auditable)?

- how much space does it typically offer in terms of numbers of keys?

- how are backups handled?

- with BIP32 HD wallets coming up, will you store only the master seed or also 
all derived private keys in the secure element?

- can the changes be generic enough to also accomodate for Trezor-style devices?

Original comment by andreas....@gmail.com on 28 Sep 2013 at 1:26

• Changed title: ECKey generation and storing in secure elements
• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Dear Andreas
Tnx a lot for your reply

Security

-concerning security of secure elements one could say they are as secure as the 
current java card technology is secure. A java card applet used for the 
enhancement can restrict access to keys using password based authentication 
methods and more importantly the platform itself provides high protection 
against unauthorized read/writes and physical tampering.

Open Source

The Implementation is open source and thus auditable..  You would find much 
more detail from http://usmile.at/ which is a research dept. in University of 
Applied sciences upper Austria.

Advantages over using app private data to store keys

- App private data can be accessed by malicious applications on rooted devices. 
Even if the private keys in the wallet are encrypted, since the AES keys are 
generated from a password provided by a user it would be either to brutforce or 
launch dictionary attack.
- If a wallet application is uninstalled accidentally the app private data will 
be lost. In rooted phones this can also be done by malicious applications.

Backups 

Backups can also be enhanced by using strong keys which will be kept in the 
secure element. The need for frequent key back up could also be reduced as 
chances of losing a key from a secure element are very rare unless the secure 
element is lost or destroyed physically. In such a case the current back up 
which is based on user provided password is still be very important.

-BIP32 HD wallets 
This is first my first time to hear about BIP32 HD wallets, tnx a lot. From a 
quick look in BIP32 wiki page, the enhancement could still stay use full as it 
can be used to generate and keep safe private parent and private child keys.

Also first time to hear about Trezor-style devices and couldn’t get enough 
information. However currently the implementation will limmited for devices 
with with SuperSmile ROM http://usmile.at/downloads  and devices supported by 
seek for Android http://code.google.com/p/seek-for-android

Tnx a lot again and would be glad to hear from you and bitcoinj developers on 
how ways to realize the enhancements. I found bitcoinj library complicated to 
refactor and apply changes on key, wallet and protobufserializer and other 
objects which are important for the proposed enhancement.

.. will create an issue in bitcoinj with a link to this conversation

Original comment by mytrial4@gmail.com on 28 Sep 2013 at 3:39

[GoogleCodeExporter]

If we don't face technical problems, HD wallets will completely replace the 
current model of multiple independent keys. In order to backup all your keys - 
including those derived in future - you only need to save the root key/seed. 
The introduction of HD wallets will also trigger moving away from the concept 
of tying identities to addresses/keys.

With HD wallets, at least one key is derived for each payment. That can add up 
to a lot of keys, but because it's basically a sequence we can work with a look 
ahead/behind window. This is why I'm asking about space constraints of the 
secure element. Trezor can implement the BIP32 algorithm on-device -- can 
JavaCard secure elements do the same?

I think Mike Hearn (the bitcoinj lead developer) wanted to refactor the ECKey 
class soon anyway. Make sure to connect to him.

Info about Trezor:
http://www.bitcointrezor.com/
https://github.com/trezor/trezor-emu
https://github.com/bitcoin-solutions/trezorj

Original comment by andreas....@gmail.com on 28 Sep 2013 at 4:40

[GoogleCodeExporter]

sorry for not writing about space issues . 
one of the drawbacks on using Secure Elements is memory limitation. for example 
if we take UICCs which are typically 32/64 kb we could assume our applet can 
use maximum of 5-10 kb.  considering 192 or 256 bit ECkey .. would be fairly 
enough keys but if every transaction uses a new key .. it would create a 
bottleneck.

Does the current implementation of bitcoin-wallet use new key for every 
payement?

As you described for HD Wallets. if new key is derived for each payment, then 
there wouldn't be enough memory , but still the secure element could be used to 
store master (root) key and also strong encryption keys that could be used to 
secure wallet file and backups.

Is it possible to recover all child private and public keys .. from the single 
root key pair? if it so, it would be of great importance to keep it inside the 
secure element.

Java card implementation for BIP32.

If the derivation steps are not memory and time intensive ( or if they are 
built from crypto primitives supported by javacard ) then it wont be difficult 
to write BIP32 implementation for Javacard.

Tnx alot again for your reply an for the links on Trezor

Original comment by mytrial4@gmail.com on 28 Sep 2013 at 5:52

[GoogleCodeExporter]

Space issues:

Ok, so we need to either limit secure element storage to just the root key or 
adjust the lookahead/behind window to that the current window fits into the 
secure element. However, it's more complex than that, because in reality BIP32 
wallets are a tree structure (hence the 'hierarchic' in the name). As far as I 
know each branch needs to individually look ahead/behind. Perhaps we need to 
restrict secure element based wallets to just one branch. Its all stuff we need 
to experiment with.

Currently the app creates one key automatically, and the user can create more 
manually as desired. However that's not how Bitcoin is meant to be used so it 
should go away better sooner than later.

I think the BIP32 derivation function is just a matter of applying SHA512 and 
some basic math. It would be great if it can be done inside the secure element. 
After all, you're not supposed to grab private keys from the secure element -- 
so how would an externally implemented derivation function be possible at all?

Original comment by andreas....@gmail.com on 28 Sep 2013 at 6:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

prev. comment edited..

Sure it would have been much better if child keys could be derived in the 
secure element
After a close look on the BIP32 spec, i saw that child key derivations need 
Elliptic curve Group operation (point addition and multiplication). And 
According to the latest java card specification there is no explicit API to 
perform EC group operations. This would limit us from generating child keys in 
reasonable amount of time( if we managed to do it without Hardware support) - 
am not also sure if current secure elements support SHA-512, Even though it has 
been specified since Java card 2.2, it depends on hardware manufactures whether 
to include it or not

About the question "how externally implemented derivation function be possible 
at all?"
If i did get your point, do you mean outside the secure element (on android 
application) 
If you meant that, it would be possible to import parent keys from secure 
element using secure authenticated channel at any time they are needed by the 
application.

However i would like discuss with my colleagues if there could be easier way to 
perform BIP32 on java cards, or in-case if i misunderstood the specification.

tnx a lot for the brief explanation and also Info links about Trezor:

Original comment by mytrial4@gmail.com on 28 Sep 2013 at 10:52

[GoogleCodeExporter]

just checked that SHA-512 is supported by secure elements we are using 
currently; it doesn't seem to be optional.
will keep update on EC group operations which are essential for BIP32 child key 
derivation

I also created an issue with the same topic on Bitcoinj 
https://code.google.com/p/bitcoinj/issues/detail?id=462  would be so great if 
you could let know Mike Hearn about our discussion.

Original comment by mytrial4@gmail.com on 29 Sep 2013 at 1:05