Project plan the bitcoin card

[Smartcard Guy]

So based on the recent threads I think I may miss understand what the
group consensus is so I thought I should write up what I think my
thinking was, unfortunately I am on an iPad and I am sure wha I am
about to write will be riddled with mistakes :)

I think the goal is to develop a solution that would be accessible to
as many people as possible, this means it has to be cheap and easy to
use.

In my experience projects it's rare that projects that set out to
start with the goal of delivering the end all be all in version 1
succeed so I was thinking we would break the project up into phases.

Phase 1 - Basic crypto card solution
Move cryptographic key material to a crypto card, use of keys require
use of a pin. Involves making appropriate changes to the bitcoin
client to allow the wallet.dat to contain references to keys, to
collect pin and pass it to OpenSSL, to use the OpenSSL engine
construct.

At the end of Phase 1 we will have virtually eliminated wallet theft
and reduced the chances of transaction fraud by a making it so that
the card must be present to perform a transaction, we would still be
exposed to transaction modification attacks (host sends 100btc request
to card not the 1btc the UI says.

From a usability standpoint we have added a pin prompt into the
transaction, some ui for dealing with card detection and a card
management experience for:
1. Card initialization and re initialization
2. Admin and user pin change
3. Card unblock

We could also choose to implement a card backup implementation in
phase 1, this could be done by exporting a cipher text blob of ey key
to the filesystem or by cloning the keys from one card to another.

Phase 2 - initial Point of sale solution
In this approach we are basically re implementing the bitcoin client
on a smatcard, we will need to find a cost effective secure pin entry
and secure display solution that is customizable and supports the
crypto we need. Unfortunately this may end up being custom hardware
given the non standard curve the card implements.

We have to work on the existing bitcoin client to create a separation
of the UI from the logic layer so that it is possible for the client
to work in both modes, this is something Gavin is hoping to do in the
next year so we could join that effort and see if we could accelerate
it.

We would need to modify the UI layer in the bitcoin client to probably
have a new transaction UI, that UI would when the card is present deal
with helping the user know how to interact with the external hardware.

We will need to device a card provisioning and updating mechanism here
to, in other words we need to make it so that users can update the
application on the card as it's updated as the bitcoin protocol will
continue to evolve.

In addition we need to do the same card related stuff from the first
phase, though there will likely be some changes.

Wqith this approach we get the benefits of phase 1 plus we get to
address the kernel Malware threat of transaction being modified before
it's sent to the card. Additionally we potentially enable point of
sale transactions if we build a point of sale terminal I addition.

Thoughts?

[Ludwig Maes]

On 25 June 2011 19:01, Smartcard Guy <smartc...@gmail.com> wrote:
> So based on the recent threads I think I may miss understand what the
> group consensus is so I thought I should write up what I think my
> thinking was, unfortunately I am on an iPad and I am sure wha I am
> about to write will be riddled with mistakes :)
>
> I think the goal is to develop a solution that would be accessible to
> as many people as possible, this means it has to be cheap and easy to
> use.

That goal has been achieved by bitcoin, download, install.
The priority is not "develop a solution that would be accessible to as
many people as possible", but "use peer review and open discussion so
that we can provide a mechanism resistant to a much wider threat model
(your computer (and later on -but not yet- also terminal) has been
compromised), growing user base through trust, not form factor
association!"

I do no understand why phase 2 contains "Unfortunately this may end

up being custom hardware given the non standard curve the card
implements."

this was already necessary in phase 1 (either javacard bytecode, or
crypto coprocessor)

[Ludwig Maes]

, growing user base through trust _in widely understood basic
cryptographic principles_, not form factor
association!"

[Smartcard Guy]

On Sat, Jun 25, 2011 at 11:10 AM, Ludwig Maes <ludwi...@gmail.com> wrote:

On 25 June 2011 19:01, Smartcard Guy <smartc...@gmail.com> wrote:
> So based on the recent threads I think I may miss understand what the
> group consensus is so I thought I should write up what I think my
> thinking was, unfortunately I am on an iPad and I am sure wha I am
> about to write will be riddled with mistakes :)
>
> I think the goal is to develop a solution that would be accessible to
> as many people as possible, this means it has to be cheap and easy to
> use.

That goal has been achieved by bitcoin, download, install.

It has not as the "solution" was to secure the very insecure thing that is done today.

 

The priority is not "develop a solution that would be accessible to as
many people as possible", but "use peer review and open discussion

Peer review is how not what.

 

so that we can provide a mechanism resistant to a much wider threat model
(your computer (and later on -but not yet- also terminal) has been
compromised),

Agreed, were discussing the definition of how and I think that is the only point we have not yet aligned on.

 

growing user base through trust,

I agree about growing the user base through trust but think that to do so we need to make the solution availible to as many as posible, e.g. if we build a very secure solution that is hard to use, to expensive to acquire or complicated we will not grow the userbase.

 

not form factor association!"

I dont care about form factor, or technology we choose to employ beyond the goals of being secure and accessible.

 

> With this approach we get the benefits of phase 1 plus we get to

> address the kernel Malware threat of transaction being modified before
> it's sent to the card. Additionally we potentially enable point of
> sale transactions if we build a point of sale terminal I addition.
>
> Thoughts?
>

I do no understand why phase 2 contains  "Unfortunately this may end

up being custom hardware given the non standard curve the card
implements." this was already necessary in phase 1 (either javacard bytecode, or
crypto coprocessor)

Because after calling a dozen card manufacturers none of them have cards that implement this curve, have a display let alone a ped.

[Uglješa Jovanović]

@Ryan
I agree with the approach of dividing the process into two phases, and
i agree with the phases you mentioned, but also Ludwig does make a
good point about the goal of this project. So lets keep that in mind,
and get to work :)

Regards,
Ugljesa

[Uglješa Jovanović]

What kind of computation times are we talking about software (we
implement the secp256k1) vs hardware accelerated?

[Smartcard Guy]

I don't know; it will depend a lot on the card hardware and the software implementation.

 

In the end with this curve we probably allways end up with software implemented secp256k1, the difference is do we end up doing the implementation or do we use one native to the card we build on.

2011/6/26 Uglješa Jovanović <ions...@gmail.com>

[Ludwig Maes]

The only way to know how much slower software is, is to try, that is
what is why smartcard guys ordering of *A* smartcard is a very good
start.
Perhaps its a matter of a fraction of a second, perhaps seconds,
perhaps minutes. Only trying will show. Dont misunderstand me, I
support the pragmatic lets try and see approach. Like I said, I am
backing out of the project, and I will give a lot of critique, not
because you are inherently wrong, but because I know a bit about
security and cryptography, and their protocols. I just speak up where
I see danger. I *still* insist the hashing is done on smartcard, it
already supports it. Consider me the harsh teacher, who is arrogant
enough to point out mistakes without contributing (as I said, I am not
going to actively help develop, I have found another project that I
prioritize...) Still, what you guys are doing is much more usefull and
critical to cryptocurrencies, then what on-computer wallet encryption
guys are doing. Please go ahead, even if I criticise you. I understand
you guys know how to implement and program things, I am only trying to
point out small mistakes (like hashing on computer side). Dont take it
personal. For example SC guy proposed to do it on computer side, but
the same card he proposes already has support to do it on SC, and it
prevents a specific kind of attack in the scenario of a user who
invested in secure pinpad terminal, it doesnt take more coding work,
just call the prefab hash function on smartcard side instead of
computer side.

If I speak up it will either be because I think we did not do enough
market research, or because I see no cryptographic advantage....

that being said, DO go ahead...

[Smartcard Guy]

I got a call from FedEx, the cards will be held for me at the local Kinkos tomorrow.

 

We need to decide who is doing what and those who will comit to working on the project need to get me their mailing details so I can get them cards.

Ryan

[Rassah]

I'm not a programmer, but I have a degree in Business/Finance with some experience in entrepreneurship and international business, and have money. I'm very interested in this project, and would like to help any way I can (even if it's just consulting, or playing a technologically-illiterate devil's advocate)

-- Rassah

[Uglješa Jovanović]

Hey,

Could you send me the exact specification of the card you are getting?
I will be contacting a company developing smartcard solutions here,
one of my colleagues used to work there.

On the note of project I will be working on client (desktop) side, and
as much as i can help with javacard applets (I'm currently Java
machine learning/scalable systems R&D software engineer).

Regards,
Ugljesa

[Smartcard Guy]

Great, Ugljesa can you email me your mailing details and I will get you a card in the post right away.

 

The specifications for the card I was thinking we would start with is: http://www.athena-scs.com/pdf/Athena%20IDProtect%20Key%20v2%20LASER%20(01022011).pdf

 

Some resources that will help us with this project are:

http://openssl.org/

http://www.opensc-project.org/opensc

http://www.opensc-project.org/engine_pkcs11/wiki/QuickStart

http://www.opensc-project.org/engine_pkcs11/

From a client integration standpoint I would start with getting familiar with OpenSSL, engine and the opensc project.

 

Ryan

2011/7/1 Uglješa Jovanović <ions...@gmail.com>

[Smartcard Guy]

Thanks Rassah, I think when we get to v2 there may be a need for your skill set in the mean time feedback is allways desired!

[Ludwig Maes]

fizzle :)

[Smartcard Guy]

Lol, think it's just me now have the cards and will be working on
provisioning them this week.

[Uglješa Jovanović]

Hey,
sorry for being silent, I was overwhelmed with some projects at work
(I still am actually). I think I'll have more time starting next week.

Regards,
Ugljesa

[Bruce Wagner]

Any updates?