Javacard discussion

[Ugljesa Jovanovic]

Ludwig did some research, and at the moment java card based smart
cards look like the way to go, so lets discuss Java Cards here and
later aggregate that to the wiki.

[Smartcard Guy]

I agree that near term Javacard is the way to go, I have spoken to Athena, a smart card company I have worked with in the past and confirmed they support arbintrary curves (the bitcoin curve is not super common) and provide a P11 interface that should be integratable into OpenSSL via the engine interface.

 

I have ordered some samples, if this path sounds reasonable we should agree on a design, assign work and I can send cards to folks that would need them.

 

Ryan

[Ludwig Maes]

Sounds like very fast progress! keeps us up to date :D

[Ludwig Maes]

I think Ryans approach now is better than mine, not sure why I
prioritised button+display javacards above general javacard.
Its indeed probably better to start development on general javacard
(tackle 1 problem at a time) such that later after seeing how big the
applet is and how fast it runs we will know better what to require
should we try to find SC with Buttons and Display.

I looked at the specification and am pleased to see that quite a lot
of information is provided with considerable detail, however more
never hurts:

I would like to know more about the specific microcontrollers present,
what main microcontroller and what crypto coprocessor is present?
Are data sheets of these available?

for development purpouses I do not insist on crypto hardware
acceleration, but it would be interesting for the future to know what
cards are available with hardware acceleration for our needs.

I read in the spec sheet under silicon:

"32-bit Cryptographic Accelerator for
Public Key Operations with GF(2n)"

Looking at key lengths and javacard platform everything looks great, I
think we can sign secp256k1 on these cards, however with only this
documentation I believe there will be no hardware acceleration since
sec_p_256k1 uses ECDSA over prime fields p and not 2^n
This is often written as GF(p) vs GF(2n). However advertising presence
of GF(2n) doesnt automatically exclude presence of GF(p) word
operations accelerator. It would be interesting to inquire if they
have similar products or if this product indeed accelerates GF(p), or
up in the supply chain.

Their support would also be really welcome.

As the motivation to use smart card is the "compromised computer"
thread model, the security border must be assumed to ly between
computer/SC and not be blurred into the middleware (belgian eid is
partially fucked up, because some of the security is partially encoded
in middleware, such that malware could simply decide not to link
agains middleware but against general purpouse PC/SC interface, i.e.
beid Card allows to sign indefinite amount of hashes, but the
(optional) middleware "prevents" this)

[Uglješa Jovanović]

I'm still catching up with the jargon and the technology involved,
started reading Java Card SDK so other than nodding in approval oh how
well this is going I can currently do no more. Where I can help now is
maybe organize our thoughts, so lets start with the important thing, i
thing we agree we are going to develop the following:

- Java card based smart card, that will contain Bitcoin keys and
unredeemed bitcoins.
+ The main purpose of this card will be to provide a physical wallet
for Bitcoins, this card is not meant to replace the main Bitcoin
wallet
* This card will be able to on request and with proper authorization
sign and provide requested outgoing (spending) Bitcoin transaction
* This card will also be able to provide upon request a receiving
address for incoming Bitcoin transaction

Further development may include:
- Developing a smart card with display and keypad for increased security

I would also like to point out a feature that could be included
- To prevent loss of bitcoins in event of losing the card a backup
will be made, this backup AFAIK is valid for all received and spent
bitcoins until the time of the backup, but in the event of significant
time between backups, and subsequent loss of card, change from spent
bitcoins which was not backed up may be lost. (I'm still not clear on
this, so I might be wrong)
Official bitcoin client prevents this by precomputing 100 addresses
and storing them. Since the use case for our card includes a lot of
small transaction this limit can be easily exceeded. So I propose that
on card initialization, a larger number of income addresses is
precomputed by the initializing pc and then stored in the card, this
number of course depends on available space on card.

Other thing i would like to propose, and yet again I am not sure if
this is doable is a main wallet bitcoin card, this card would contain
only the keys while the rest of operations would be on the middleware
(bitcoin client). User would need to authorize transactions by
entering appropriate pin after validating the requested transaction.
The reasoning for this is protection from keylogers etc... Of course a
strong encrypted backup of the keys placed on an external media is
needed in unlikely case of card loss (You wouldn't take this card from
home often)

Comment on everything, consider the proposed features as non
essential, when we reach an agreement i'll put the definition on wiki

This is going well :D

[rmesc...@gradiant.org]

Hi,

has anyone found a Javacard with display and buttons though? I have been looking for it for a long time.