Forming the idea

[Ugljesa Jovanovic]

So, lets start. The idea is crating an opensource hardware/software
platform for accessing, well pretty much anything, with emphasis on
bitcoin support. Let the brainstorming begin!

I have no experience in designing hardware components other than a
course in electronics at my uni, which i already forgot, and also my C/
C++ skills are rusty, but that can be sorted. I'm currently java/scala/
android developer. Summa summarum, i can help on the software side of
this project

Regards,
Ugljesa

[r2k-in-the-vortex]

the calculator type seems like a good way to go, cheap display, simple
keypad, cheap ucontroller,
for controller i would wager avr(simpler, slow 8bit, little memory,
but cheap) or arm(more memory for code, more powerful, 32bit, costs
bit more)

[L]

I consider the following setup:

(possibly compromised) computer with smart card reader, running our
software package that can propose (possibly malicious) transactions to
smart cards.

upon receiving proposed transaction, smart card is removed and
remembers the proposal.

the calculatorlike token has lcd screen and keypad. it displays the
proposed transaction adress and amount, user can accept deny or edit
transaction. before signing a pin is required.

the smartcard is now removed from the calc token and reentered in
possibly infected computer, the signed transaction is communicated to
be broadcast on the network

[L]

Also: the proposal must not originate from the computer at home,
computer at store,... one could just as well type the transaction on
the token and then insert smart card...

[r2k-in-the-vortex]

ah, smartcard as the communication media, not bad, it only needs to
store the payment request one way and tx other way
other communications that might work could be
* native usb (not that simple in controller side software)
* virtual serial over usb (very simple on controller side, not exactly
plug-n-play pc side)
* actual serial(cumbersome, bit out of date but cheap and simple),
* bluetooth(expensive)
* wifi (even more expensive but could be very convenient)

physical connection between infeted machine and payment module does
not mean that infection can spread to payment module, as long as
reasonable security practices are kept
its probably a good idea to keep program memory
protected(unfortunately means no rewrites, so no software updates)
along with decryption keys(no read back from onchip prom), and keep
the wallet data encrypted in eeprom(offchip memory would probably be
used)

[Uglješa Jovanović]

On the hardware side, at the moment i cant provide any input other
than general design, I'll do some research and than be somewhat more
competent to discuss this point.

On the usability side:

I propose that this card contains a separate unique wallet which can
be recharged from the computer with the users main wallet (this could
be supported trough official bitcoin client) so that even in the case
of card loss the damage is limited.

Also the card should be able to provide the receiving address for the
main wallet, in case the transaction is not paying but receiving
bitcoins and we don't want to store it in the card wallet (i'm not to
sure on this)

[Rassah]

A loadable card totally unconnected from the network will lead to more
and more Bitcoin being lost. I know bitcoin attrition makes everyone a
bit richer, but we don't want to go overboard.

[Uglješa Jovanović]

On Tue, Jun 21, 2011 at 12:21 AM, r2k-in-the-vortex <rkor...@gmail.com> wrote:
> ah, smartcard as the communication media, not bad, it only needs to
> store the payment request one way and tx other way
> other communications that might work could be
> * native usb (not that simple in controller side software)
> * virtual serial over usb (very simple on controller side, not exactly
> plug-n-play pc side)
> * actual serial(cumbersome, bit out of date but cheap and simple),
> * bluetooth(expensive)
> * wifi (even more expensive but could be very convenient)

What about NFC?
And also ince this is an open source project, we could try to be as
modular as possible to support different designs.

>
> physical connection between infeted machine and payment module does
> not mean that infection can spread to payment module, as long as
> reasonable security practices are kept
> its probably a good idea to keep program memory
> protected(unfortunately means no rewrites, so no software updates)
> along with decryption keys(no read back from onchip prom), and keep
> the wallet data encrypted in eeprom(offchip memory would probably be
> used)
>

We should start a few different threads with discussions related to
Hardware, Software (on-card, and desktop support), Security, Use
cases?

[Uglješa Jovanović]

the wallet file (the private key used for transactions) stored in the
card will also be backed up on the desktop, so in case the card is
lost, all of the bitcoins are still available (please correct me if
i'm wrong here)

2011/6/21 Rassah <ras...@xnicole.com>:

[Rassah]

You mentioned separate unique wallet. I guess you meant that wallet will be backed up when you "initiate" your key.

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

[Ugljesa Jovanovic]

Yes! I'm still new to bitcoin terminology and system functions (i
discovered bitcoins a week ago in the height of 30$ hype) so if I am
mistaken at some point please tell me.

I would need r2k to check if my reasoning is valid and possible,
because of eeprom programming, but this would be the initialization
scenario:
1. User obtains a BitCoin Card
2. First time it connects it to his computer the card is "initialized"
with a keypair (actually forming a new wallet)
3. That new wallet is backed up
4. The card is ready to receive bitcoins :)

Offtopic / I made some threads, where we should group the discussion
to keep things simpler

On Jun 21, 12:33 am, Rassah <ras...@xnicole.com> wrote:
> You mentioned separate unique wallet. I guess you meant that wallet will be
> backed up when you "initiate" your key.
>

> 2011/6/20 Uglješa Jovanović <ionsp...@gmail.com>

[r2k-in-the-vortex]

i see no reason why the wallet file couldnt be rewritten at any time
by user, but in that case pin code should also be requiered, so that
wallet cannot be overwritten by anyone

one very real attack vector with all keyboards:
most used keys wear off while unused ones still look new. attacker can
easily see what numbers the pin code is made up of if the pin code is
not changed often

so the pin code should be changeable after all.

here is how i would guarantee security
decryption key would be stored along with program memory,
many ucontrollers have a feature where you can lock the controller
after programming so that program data cannot be read off it other
than for onchip excecution,
if rewrite is desired(sometimes that too can be locked and some
controllers can only be written once) all old program data(and in our
case decryption key) must be erased and new program data,
new key and new wallet must be written to use the device again
probably some self destruction mechanism can be deviced in case of
multiple incorrect pin code entry(through memory self erase for
example) otherwise user only has to connect the keyboard to digital io
and try until success(doesnt take long considering numeric keypad)
or some 0.5-1 second delay with every try would also win user some
time to recover bitcoins from a copy af the wallet in case token is
lost(7 digit password with 1s delay gives avarage crack time of 5+
days)

[Uglješa Jovanović]

Great!
On the key durability issue, maybe the pin could have an expiry date
(of course notifying the user several days in advance that he should
change the pin code) and also force a different pin code on change.

Offtopic: I'm really excited about this project. If enough people
participate in this, this could become a real thing.

I'll write more tomorrow, it's after midnight here, and i need to get
to work in the morning :)

2011/6/21 r2k-in-the-vortex <rkor...@gmail.com>:

[Rassah]

If this will be for a secondary wallet with just some carry on cash, and people won't be expected to load it with more than $20 to $100 worth, is keypad security really that necessary? If someone loses it, they can run home and hope that they can still pull the money out through the backup, which is way more than you can do if you lose a wallet with a few $20 bills.

[Rassah]

Actually, I guess the question is, are you guys thinking of a key card that will store all your bitcoin, and be more secure than a wallet stored on your PC due to security measures (s you can carry all your money with you, or use it to secure your savings)? Or are you thinking of a card that will be used like a wallet you load up with a bit of cash from your main account before you go shopping?

[L]

obviously the latter, security wise from less safe to more safe:

*standard bitcoin client and wallet (malware can simply copy
wallet.dat)
*bitcoin client with passphrase to decrypt wallet at send time
(malware can copy wallet.dat from RAM memory at buy time, or keylogger
can record passphrase)
*our smartcard without display and pin token, giving pin at buy time
(malware can log pin at buy time and from then on succesfully propose
transactions to smartcard whenever SC is present in reader)
*our SC with seperate pin token device (malware must either corrupt
token firmware at version updates OR exploit smartcard to place
exploit for pin token (requires 2 vulnerabilities on device with
little functionality hence easier to audit for vulnerabilities))

[L]

So to answer your question: for larger amounts the last setup would be
safer, for pocket money (occasionally sent thru last method to pocket
money wallet) the previous to last method would be quite secure

[Ugljesa Jovanovic]

I think we should decide between options 3 and4

Option 3, smartcard with no display, requesting PIN (almost completely
like some credit/debit cards today)
Pros:
- Cost efficient
- Existing hardware
- Security on par with existing credit/debit card protocols (at least
i believe it would be)
- Familiar usage to most users (just like credit/debit smart card with
pin
Cons:
- Lower security than option 4 (card with keypad on it)
- No way to ensure the amount of transaction, except for the amount
read on terminal, which could be malicious
- Pin could be logged by terminal

* Pin logging could be prevented by having an separate hardware pin
generator for that particular transaction (like bank token or whatever
it is called) but i think that would be an overkill for this option

Option 4 - Card with a display and a keypad:
Pros:
- Secure (if we implement it well)
- Could provide more information and options to user even trough
simple segment display (Transaction amount, amount left on card,
chose if you want to receive transaction on the bitcoin-card or
provide the address of the main wallet etc)
- It'd look nice :)
Cons
- Cost of designing new hardware, both on the card and terminal side
(If we don't find some already existing solution that could be applied
to our problem)
- Users would need to learn how to use the new system
- Security stuff r2k pointed out

I'd like option 4 more, but maybe 3 seems more realistic.
And another thing, yesterday sipa mentioned on irc that bitcoin is too
young for this, and i agree, but if we start designing and planning on
time, we well have a solution at the time bitcoins mature enough.

[Uglješa Jovanović]

I just bought btc-card.com and btc-card.org, somebody already took
bitcoincard and btccard :)
I'll set up something on those domains later, or i'll leave
administration to someone else

[Ludwig Maes]

yesterday I found some relatively cheap (44 euros or so) terminals
with pinpad and display, if these displays can be controlled by
smartcard instead of computer, then thats really the way to go (since
secure pinpadless, screenless smartcard reader like i have was 15
euros or so) thats after a quick search, and the relative price is
like 3x more expensive, and can be expected to drop as market volume
of home users wishing to perform secure banking at home increases. It
would be hard to beat that price. I posted some of the quick search
results on the wiki...

assuming that the SC decides what the screen says, I think this has
become a purely smartcard and pc programming task...

Im going to shy away from the project btw :D

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

[Rassah]

Just had a thought about something that's not even out yet. What's cheaper, a screen, a keypad, or just a plain touch screen/mousepad?

What if one side of the card was like a mouse pad, and instead of having to touch the keys or type in a pin, you would unlock your card by simply swiping your finger from one corner to the next in a predetermined pattern, similar to how Android phones are unlocked? That would be better for wear and harder to crack than just buttons, may be cheaper to implement, and if the touch area is large enough (almost the whole side of the card), would be much easier to use for people with fat/old fingers.

[Rassah]

Sorry, by "mouse pad" I meant touch pad, like the type laptops use.

[Uglješa Jovanović]

Great find! I started reading some tutorials about smart card
programming, so i'll share more information when i understand
everything better.
I do still think we should keep considering the option of custom
hardware for a more serious security/transfer, but i'm really liking
the smart card approach

Why are you going away from the the project? :(

[Uglješa Jovanović]

I understand what you're proposing, and maybe r2k will answer that
better than i can, but from my experience touch pads (at least from my
lap top) are thick, and I don't know about power consumption. But
still, I'm not competent to answer :)

[Uglješa Jovanović]

Looking at link Ludwig provided
http://www.citala.com/index.php/Application-Solutions/Smart-Cards.html
, in the customization section they mention pushbuttons, that could be
the way to go?

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

[Uglješa Jovanović]

I need to read more carefully, Ludwig already mentioned that on wiki :)

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

[Smartcard Guy]

I have been thinking about doing a similar project, see
http://forum.bitcoin.org/index.php?topic=20933.0; my intention was to
start withnwhat you called 3, and later evolve it to something like
your 4.

I was thinking it would be most cost effective to start with the DoD
smart card, it supports the right crypto algorithms (mostly) and in
scale can be had inexpensively. However it turns out it doesn't
support the curve that was chosen for btc so it would be necessary to
at a minimum donanderivation, maybe this token -
http://www.athena-scs.com/pdf/Athena%20IDProtect%20Key%20v2%20LASER%20(01022011).pdf

The majority of the work is in the bit coin client to enable their
use, it will require minor wallet refactoring, crypto configuration
and possibly a custom engine for OpenSSL. Additionally supporting card
initialization, provisioning, wipe, block, unblock will be needed.

I have requests into several manufacturers right now to see who has
the closest card to what would be necessary, IMHO the majortiynof the
work needs to be in the bitcoin client if there is a goal to see many
cary these cards, cost in scale is very important.

[Smartcard Guy]

I own coindefender.com ;)

[Uglješa Jovanović]

Hi Smartcard Guy, and welcome to the discussion!

I'm sorry i didn't notice your project before, otherwise i would have
gladly joined. It's great that you are an expert in this area, and I
think that should really help the development. I myself am a software
engineer, and i will mostly work on the desktop-client side, and maybe
in some part on card software development, although i need to freshen
up my C/C++ skills. I'll take a look at the links you posted later,
and give you some feedback, but keep in mind that I am just starting
to learn about smartcards/tokens.

On the other note, is someone willing to take the responsibility of
managing the wiki? :)

[Ludwig Maes]

If I understand correctly, most crypto-enabled smartcards would allow
ECDSA signing, I see crypto framework with ECDSA signaturing in
JavaCard specification, and I am quite sure Global Platform supports
it too. I think there is a wide range of choices, and I think its
better to choose a card that can be produced by many companies than by
a few (not sure how many companies are allowed to make DoD cards, btw
are you talking about CAMAC?). Not only for competition, but also for
safety (we dont want backdoors on the smart card OS, hardware or
software).

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

[Ludwig Maes]

By the way check out:
http://www.gooze.eu/feitian-pki-free-software-developer-card

They offer a symbolically free (0.5 euro) smart card, if you develop
for opensmart card, they propose projects to enhance, or you can make
your own proposal (BitCoin wallet)

The card doesnt seem to have accelerated ECDSA capabilities (but I
dont see a real specification sheet, so maybe it does). And Im not
quite sure if javacard can still perform ECDSA using the chip as a
general purpouse processor, or if javacard crypto apis depend on
hardware implementation (which would be strange, since then all
combinations, and all existent card models must be present in the API
headers..., and also that would require that you compile applets for a
specific card, completely against javacard reduced bytecode
instruction set, so I tend to believe that if the card supports
javacard applets, AND if its memory is big enough, it can compute
ECDSA keys, and testing will only tell how fast this is...)

[Ludwig Maes]

hmm my last sentence is quite long so to rephrase:

I think if the card supports javacard applets, you can try to write
any cryptographic functions as long as you stay within memory bounds,
and are satisfied with your card's specific performance (for which
some cards have develloped dedicated crypto coprocessors).

the ECDSA signing as I said is already present in javacard api, so
only testing will tell.

otherwise these cards cost 12.9 euros

[Ludwig Maes]

Also dont forget these cards have a limited rewrite cycle of about 100
000 times (not sure if this is per memory cell, or already taking into
account the clever algorithms that memory sticks implement to extend
lifetime, since changes rarely change the whole memory, distributing
the changes evenly)

[Smartcard Guy]

The DoD cards are one of the most deployed and used in the world.

The standard is hspd12 and virtually all card companies make them, the
standards are public and royalty free. To be clear I am thinking a
derivative of this standard would be most appropriate, this would make
it possible to get hardware very cheap and we would benefit from the
work that is done to secure the DoD cards.

The derivative would be necessary for a few reasons one being bit coin
uses an odd curve not used by most systems, the other being it is a
read only card (keys a minted at initialization only). These are some
of the reasons I worked othat GIDS specification it's intended to be a
more flexible one.

My goal for this project was to get this working as quick as possible,
as such I wanted to find an off the shelf card that supports the curve
btc uses and was read/write so the walled could be written to the
card.

This would allownone to focus on the changes to the client to enable
the scenario vs esoteric card stuff, if done right the client could
would with virtually any card that supported some basics and the card
edge could be thought about separately.

On Jun 22, 8:56 am, Ludwig Maes <ludwig.m...@gmail.com> wrote:
> If I understand correctly, most crypto-enabled smartcards would allow
> ECDSA signing, I see crypto framework with ECDSA signaturing in
> JavaCard specification, and I am quite sure Global Platform supports
> it too. I think there is a wide range of choices, and I think its
> better to choose a card that can be produced by many companies than by
> a few (not sure how many companies are allowed to make DoD cards, btw
> are you talking about CAMAC?). Not only for competition, but also for
> safety (we dont want backdoors on the smart card OS, hardware or
> software).
>

> 2011/6/22 Uglješa Jovanović <ionsp...@gmail.com>:

>
>
>
> > Hi Smartcard Guy, and welcome to the discussion!
>
> > I'm sorry i didn't notice your project before, otherwise i would have
> > gladly joined. It's great that you are an expert in this area, and I
> > think that should really help the development. I myself am a software
> > engineer, and i will mostly work on the desktop-client side, and maybe
> > in some part on card software development, although i need to freshen
> > up my C/C++ skills. I'll take a look at the links you posted later,
> > and give you some feedback, but keep in mind that I am just starting
> > to learn about smartcards/tokens.
>
> > On the other note, is someone willing to take the responsibility of
> > managing the wiki? :)
>

> > On Wed, Jun 22, 2011 at 4:20 PM, Smartcard Guy <smartcard...@gmail.com> wrote:
> >> I have been thinking about doing a similar project, see
> >>http://forum.bitcoin.org/index.php?topic=20933.0;my intention was to
> >> start withnwhat you called 3, and later evolve it to something like
> >> your 4.
>
> >> I was thinking it would be most cost effective to start with the DoD
> >> smart card, it supports the right crypto algorithms (mostly) and in
> >> scale can be had inexpensively. However it turns out it doesn't
> >> support the curve that was chosen for btc so it would be necessary to
> >> at a minimum donanderivation, maybe this token -

> >>http://www.athena-scs.com/pdf/Athena%20IDProtect%20Key%20v2%20LASER%2...

[Smartcard Guy]

Java and .net cards will most typically do the math in software, these
cards are typically slow and expensive (have more processing power)
cards that get broadly deployed are usually not as flexible, they do
the math, etc.

I looked at this card doesn't like like it supports the right ECC
curve.

On Jun 22, 9:53 am, Ludwig Maes <ludwig.m...@gmail.com> wrote:
> By the way check out:http://www.gooze.eu/feitian-pki-free-software-developer-card
>
> They offer a symbolically free (0.5 euro) smart card, if you develop
> for opensmart card, they propose projects to enhance, or you can make
> your own proposal (BitCoin wallet)
>
> The card doesnt seem to have accelerated ECDSA capabilities (but I
> dont see a real specification sheet, so maybe it does). And Im not
> quite sure if javacard can still perform ECDSA using the chip as a
> general purpouse processor, or if javacard crypto apis depend on
> hardware implementation (which would be strange, since then all
> combinations, and all existent card models must be present in the API
> headers..., and also that would require that you compile applets for a
> specific card, completely against javacard reduced bytecode
> instruction set, so I tend to believe that if the card supports
> javacard applets, AND if its memory is big enough, it can compute
> ECDSA keys, and testing will only tell how fast this is...)
>

> On 22 June 2011 17:56, Ludwig Maes <ludwig.m...@gmail.com> wrote:
>
>
>
> > If I understand correctly, most crypto-enabled smartcards would allow
> > ECDSA signing, I see crypto framework with ECDSA signaturing in
> > JavaCard specification, and I am quite sure Global Platform supports
> > it too. I think there is a wide range of choices, and I think its
> > better to choose a card that can be produced by many companies than by
> > a few (not sure how many companies are allowed to make DoD cards, btw
> > are you talking about CAMAC?). Not only for competition, but also for
> > safety (we dont want backdoors on the smart card OS, hardware or
> > software).
>

> > 2011/6/22 Uglješa Jovanović <ionsp...@gmail.com>:

> >> Hi Smartcard Guy, and welcome to the discussion!
>
> >> I'm sorry i didn't notice your project before, otherwise i would have
> >> gladly joined. It's great that you are an expert in this area, and I
> >> think that should really help the development. I myself am a software
> >> engineer, and i will mostly work on the desktop-client side, and maybe
> >> in some part on card software development, although i need to freshen
> >> up my C/C++ skills. I'll take a look at the links you posted later,
> >> and give you some feedback, but keep in mind that I am just starting
> >> to learn about smartcards/tokens.
>
> >> On the other note, is someone willing to take the responsibility of
> >> managing the wiki? :)
>

> >> On Wed, Jun 22, 2011 at 4:20 PM, Smartcard Guy <smartcard...@gmail.com> wrote:
> >>> I have been thinking about doing a similar project, see
> >>>http://forum.bitcoin.org/index.php?topic=20933.0;my intention was to
> >>> start withnwhat you called 3, and later evolve it to something like
> >>> your 4.
>
> >>> I was thinking it would be most cost effective to start with the DoD
> >>> smart card, it supports the right crypto algorithms (mostly) and in
> >>> scale can be had inexpensively. However it turns out it doesn't
> >>> support the curve that was chosen for btc so it would be necessary to
> >>> at a minimum donanderivation, maybe this token -

> >>>http://www.athena-scs.com/pdf/Athena%20IDProtect%20Key%20v2%20LASER%2...

[Ludwig Maes]

"> I looked at this card doesn't like like it supports the right ECC
> curve."

you mean the feitian one? or the DoD one? the feitian one could use
any curve, as you say it can be implemented in software...
write would also be very desirable future, how else do you store
failed pin attempts etc? if "the fed" lays its hands on your card itll
try every possible pin combo (or smarter use timing attacks...), a
card could increase a counter before signing it after which it needs a
different PIN to let user confirm its really been so many signatures
ago and not an attack, to try detect statistical sidechannel attacks
(lots of attempts at signing without explanation (PIN))

what makes you think these cards are cheaper than javacards? is it a
significant difference?
I fully agree the security protocol should be worked out first, so
that different people can implement them. first versions seldom hit
the target though.

except for your experience with the card, will it be able to sign
using the secp256k1? if not will a new production line of processors
be started? what makes you think that the first version for a small
community of bitcoin users are going to be willing to pay that? I
think most will want to use smartcards since the proposer2card
protocol will likely change a lot in the first few versions...

first functionality then speed no? and those who are willing to pay
for faster more capable smartcards let them, they can load the same
applets.

what chip is in the fips 201 hspd12 cards? whats the card OS? whats
the card platform? does it support javacard, openplatform, ...? what
vendor specific hardware implemented functions does it provide? how
many were deployed? in belgium the population of 11 million is equiped
with smart card identity cards (javacards, the security architect of
beID published opensource the javacard applet so that other
nations/organizations can simply copy pasta it with their own keys and
CRLs etcetera)

we should do thorough market research, and ask price quotes and spec sheets.
for example the javacards with oncard buttons and flexible display
sounded like really expensive to me, but then again, who knows?

I would kill for a small "gameboy 0.01" capable smart card :D let
alone one which doesnt delegate displaying crucial information to a
device you might not trust (future real life bitcoin shop scenario)

[Ludwig Maes]

I have a hard time finding the hardware specifications of hspd12
cards, could you provide some links?
I can only find info like 2factor authentication (bank cards here were
2factor already for decenia (PIN+RSA))

I was also amazed to recently learn UK first trialled it in 2004?

Im not too old, so I cant really remember how long its been around
here, but from what I read it seemed to be deployed on broad scale in
france pretty early...

FIPS: "bits of security: 40-200" 40?? replace double hashing with
bruteforce and except for a constant factor (approximate 1 (2*64
rounds of about *24 register operations of 32 bits compared to
whatever you want to sign to guessed private key)) the current mining
rate is 2^51 hashes per 10 minutes, so thats 2^(51-40)=2048 expected
succeeding bruteforces per 10 minutes. thats if the bitcoin chain
decided to replace the hashes with providing 30 such signatures to
mint a valid new block.

Im also amazed the bitcoin community doesnt see that they reached the
theoretical attack of 2^51 for sha-1 collisions, if someone
implemented it for gpu's we would be within orders of producing sha1
collisions (the eid cards of belgium and lots of other cards still
sign with sha-1 hashes...)

2011/6/23 Ludwig Maes <ludwi...@gmail.com>:

[Ludwig Maes]

BTW from http://csrc.nist.gov/groups/STM/cavp/documents/dss/ecdsaval.html
perhaps not the final specification, but it seems it uses NIST curves
and not SECG SEC2 curves such as secp256k1.

while writing this I realize this is a NIST website... perhaps SECG
has a similar page where it lists smartcards that support SEC2 curves?

2011/6/23 Uglješa Jovanović <ions...@gmail.com>:
> I am also inclined to look into javacards because I'm very familiar
> with java, and from some limited research I have done they are
> available from multiple sources and are widely deployed.
> I found that in this list
> http://csrc.nist.gov/groups/STM/cavp/documents/dss/ecdsaval.html there
> is a Gemalto java card that supports ALL-P ECC, but I'm not sure it
> supports secp256k1, if it doesn't we would have to implement it. I
> haven't looked into the prices, but I may obtain Gemalto java card,
> because i saw here in the company i work at someone is using Gemalto
> hardware, and there are people working with smart card / POS
> developement here, but they are in the other team. I'll look into that
> later. If i can't find gemalto java card here, I'll just ask Gemalto
> for one :)
>
> I agree with everything Ludwig said, and the questions he asked, and i
> also agree that we should start with functionality first, and then
> worry about speed.
>
> Also we could implement SIM card similar PIN/PUK mechanism.
>
> 2011/6/23 Ludwig Maes <ludwi...@gmail.com>:

[Ludwig Maes]

BTW a funny FAQ entry of US: "Why are other countries ahead of the
U.S. in applying smart card technology?"
and the answer is not even an answer more like something "dont worry
we are trying..."
http://www.gemalto.com/companyinfo/smart_cards_basics/headstart.html

2011/6/23 Ludwig Maes <ludwi...@gmail.com>:

[Uglješa Jovanović]

I am also inclined to look into javacards because I'm very familiar
with java, and from some limited research I have done they are
available from multiple sources and are widely deployed.
I found that in this list
http://csrc.nist.gov/groups/STM/cavp/documents/dss/ecdsaval.html there
is a Gemalto java card that supports ALL-P ECC, but I'm not sure it
supports secp256k1, if it doesn't we would have to implement it. I
haven't looked into the prices, but I may obtain Gemalto java card,
because i saw here in the company i work at someone is using Gemalto
hardware, and there are people working with smart card / POS
developement here, but they are in the other team. I'll look into that
later. If i can't find gemalto java card here, I'll just ask Gemalto
for one :)

I agree with everything Ludwig said, and the questions he asked, and i
also agree that we should start with functionality first, and then
worry about speed.

Also we could implement SIM card similar PIN/PUK mechanism.

2011/6/23 Ludwig Maes <ludwi...@gmail.com>:

[Ludwig Maes]

Googled the obvious : ' secp256k1 "smart card" '
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Reporte06/0639_ma1b_pdf.pdf?__blob=publicationFile

wide range of SHA including SHA-256
wide range of ECC including secp256k1

card OS and platform unknown (I think the card manufacturer writes a
card specific OS, on top of which JavaCard or OpenPlatform can be
implemented)

has dedicated crypto coprocessor for RSA and ECC

if this is commercially available at reasonable price, and can be got
with javacard this one seems like a winner,
but was also in top3 results of google.

instead of these lets get crackin crazy ideas we should just enquire
with different companies what options and estimated prices are for
proposable volumes.

I am really curious about the button and flexible display smart cards, we should
A] find out how expensive SC + BUTTONs + DISPLAY cost to design,
develop, produce, massproduce by
1) looking up companies that advertise similar products (some we find
may just be middle companies between us and real company, handing
specifications and communications back and forth, costing more,
delaying progress) dont expect every company to display each product
they have on their website, these guys deal in high volumes with their
clients and their site is just a welcome invitation to pass by for
real business talk...
if it remotely looks like they can do this add them to the list of
companies to enquire with
2) cooperate on the wiki a letter for enquiry, helping them help us
find our way:
clearly state what our goals and needs are (bitcoin security,
market of (un)justly paranoids, need to seperate signing from general
purpouse computing, fixed crypto protocol of bitcoin => specific SC
needs secp256k1, SHA-256, long lifetime memory for wallet read write
cycles,...), open for suggestions, enquire how much "it would cost"
and allow them to describe the most important cost factors in bringing
such a SC to the market.
This part will probably take the most time, since at least I have
little experience in conveying my honestly true interest to managerial
types :D
pretend you sit at your desk at this kind of company and get a mail
from some hyped up bitcoin fans... possibly mentioning bitcoin is a
downer!
3)take a long good look to interpret any answers. the answer will be
something completely different than we expect because we dont know
that industry (if you look at everything we wrote to each other)

B]If no button+display SC is feasible. we should have no problem
buying a random javacard with enough memory to play with. They are not
that expensive.

[Uglješa Jovanović]

A] Ok, I like that plan, lets do that.
B] Agreed

I'll play around with java card SDK when i get home, I'll also start
looking into integration with bitcoinJ, and we should contact the
bitcoin (c/c++ version that everyone uses) developers when we have a
solid proposal for them to implement. As far as i understand, we could
develop support for smart cards with display/keypad as an separate
applet and integrate it with basic smart card applet. We should try to
be as modular as possible, so we can support different standards cards
etc...

2011/6/23 Ludwig Maes <ludwi...@gmail.com>:

[Ludwig Maes]

http://bitcoincard.wikispot.org/EnquiryLetter

youtube was quite effective in finding companies that built otp
display smartcards,
collaborate on a good letter, only send if we can all agree on the contents...

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

[Smartcard Guy]

 

2011/6/23 Ludwig Maes <ludwi...@gmail.com>

"> I looked at this card doesn't like like it supports the right ECC
> curve."

you mean the feitian one? or the DoD one?

The DOD one only uses the NIST random curves so its out.

 

the feitian one could use
any curve, as you say it can be implemented in software...

My understanding from my reading on the web was that the fietan one mentioned is just a generic java card, no canned smarcard logic/behavior that they have have crypto cards (basically the java card with a smart card aplet loaded) also that implement a card edge that supports blocking, amongst other smartcard concepts like native crypto libraries but it doesnt support the desired curve or at least thats what it looks like.

 

 

write would also be very desirable future, how else do you store
failed pin attempts etc? if "the fed" lays its hands on your card itll
try every possible pin combo (or smarter use timing attacks...), a
card could increase a counter before signing it after which it needs a
different PIN to let user confirm its really been so many signatures
ago and not an attack, to try detect statistical sidechannel attacks
(lots of attempts at signing without explanation (PIN))

 

I was thinking the goal was to secure the wallet and if we could us comodoty hardware that has all the card software on it already we would be better off.

 

what makes you think these cards are cheaper than javacards? is it a
significant difference?

 

Generic java cards would require you to write crypto applets, a java or .net crypto card would allow you do do that but an aplet that does the crypto will already be present.

 

As for cost the difference in cost between the two will be negligable when you buy in quantity.

 

 

I fully agree the security protocol should be worked out first, so
that different people can implement them. first versions seldom hit
the target though.

Sigh :)

 

except for your experience with the card, will it be able to sign
using the secp256k1? if not will a new production line of processors
be started? what makes you think that the first version for a small
community of bitcoin users are going to be willing to pay that? I
think most will want to use smartcards since the proposer2card
protocol will likely change a lot in the first few versions...

 

I have spoken to contacts their and confirmed the Athena will support the secp256k1 though in software not in the mask; doing the crypto in hardware means the cards will be more expensive but in volume even they can be had cheap. I would expect samples / singles to run under $50 shipped usd (for a reader/card combo) but when the integration is done and someone (i am thinking of doing this) can buy them in bulk and get them down to 25 or less.

 

See: http://www.athena-scs.com/product.asp?pid=33, http://www.athena-scs.com/product.asp?pid=32 and http://www.scmmicro.com/products-services/smart-card-readers-terminals/smart-card-reader/scr3500.html

 

first functionality then speed no? and those who are willing to pay
for faster more capable smartcards let them, they can load the same
applets.

I agree re functionality and then speed.

 

As for who want faster more capable cards I guess but card management is a PITA and I think most just want this problem sovled making it as turn-key as posible would be necessary for broad use.

 

I guess I am gun shy about card applet work, I have done it and maintinance support and deployability ends up being a killer, as such if its not needed I try to avoid it.

 

 

what chip is in the fips 201 hspd12 cards? whats the card OS? whats
the card platform? does it support javacard, openplatform, ...? what
vendor specific hardware implemented functions does it provide? how
many were deployed? in belgium the population of 11 million is equiped
with smart card identity cards (javacards, the security architect of
beID published opensource the javacard applet so that other
nations/organizations can simply copy pasta it with their own keys and
CRLs etcetera)

I know the Belgium project well;  the DoD cards are most commonly native cards as they can be produced for much less but they can be created in Java, .NET and pretty much any other platform; that said since they dont support the curve we need its out.

 

we should do thorough market research, and ask price quotes and spec sheets.
for example the javacards with oncard buttons and flexible display
sounded like really expensive to me, but then again, who knows?

Agreed, I am getting samples of the Athena sent to me, email me your details and I will send you one.

 

My thinking is if we can get this working quickly with one card, switching to any other that supports the right curves will be nominal; I think to get the onboard display in a standard crypto card that supports this curve will require a special order / egineering work by someone and once we get a proto-type working with crypto on card I think getting this to happen wont be hard.

 

I have looked into the pricing on the javacards with flexible displays, as of a year ago single quantity card only cards were around 40 each; in visa like volumes they claimed they could get to 10 each; these details could have changed but I feel like thats phase 2 or 3 to me.

 

I would kill for a small "gameboy 0.01" capable smart card :D let
alone one which doesnt delegate displaying crucial information to a
device you might not trust (future real life bitcoin shop scenario)

LOL

[Ludwig Maes]

This looks like actually going somewhere!

2011/6/23 Smartcard Guy <smartc...@gmail.com>:

[Rassah]

Is there a basic layman's terms plan on how this is actually going to work?

For instance, will the wallet be stored on the card encrypted? What will tell the card to decrypt the wallet? How will the card be told to pay out a certain amount of Bitcoin? Will the trust be on the card or on the terminal it's inserted into? What will prevent people from having their money stolen by rogue terminals?

-- Rassah

[Smartcard Guy]

In the first version the smart card will be used to generate the keys, use of those keys will require the use of a password/pin.

 

The smart card will enforce this, we will not have to write any smart card code to accomplish this first version.

 

The bitcoin client will pass the transaction to the token to be signed, when this happens the user will need to supply the pin.

 

Hashing will likely still happen on the PC as its costly and the benefit of doing it on the card is negligible in this scenario.

 

This solution will prevent wallet theft both logically and physically.

 

Failure to authenticate to the card (bad pin n times) will result in the card being locked and a secondary password (an admin or recovery password) will be needed to unlock it; failure to enter that password correctly n times will also result in the card being locked. When a card is totally blocked the keys are gone forever.

 

Malware would be able to submit a modified transaction to the card in lieu of a real transaction, until the card has a display or an external pin entry device is used that has a display on it this will be possible. Extending the v1 solution to this is not a huge leap but one must crawl before they can run.

 

Malware would also potentially be able to capture the pin and sign transactions without the users presence if the card is left attached, this too will be mitigated with an external pin entry solution but short term keeping the key/card out of the computer will also address this.

 

This will enable you to take your keys and wallet with you and not worry about them being left accidentally (via page files, etc) and will significantly reduce the chance of fraudulent transactions.

[Rassah]

What about simpler problems, like if I went to buy something, the display showed that I would be paying $4 for the item, I typed in the key, and the card reader asked the card to send $400 instead. What will control and verify how much is actually taken out of the card?

-- Rassah

[Smartcard Guy]

First version is not intended to be a point of sale solution, in those cases the inclusion of a secure pin entry device and/or display would solve that problem because the smartcard controls the display.

 

That said this case is similar to the malware case with modified transactions I mentioned.

 

Ryan

[Ludwig Maes]

Hashing will NOT happen on the pc. The compromised computer could show
a cleartext transaction with valid amount and adress, but supply hash
of malicious transaction, which is then signed by the card.

Trust is laid on the provider of the card (we do not develop IC's and
will have to trust the smart card companies operating system, there
reputation is at stake, and if they betray client trust, they would
loose 99.999999% of their clients, we are the 0.00000000000001%, these
companies are audited, as well as their operating system, if they put
backdoors in smartcards, no bank would use smart cards... developing
microcontrollers is not cheap, they will not develop a new core to
screw us, or so we hope...)

If its not a simple memory card but a smart card, the applet developer
can choose the behaviour, we simply do not implement an interface
method that gives the keys out.

Hashing and signing happen on smart card.

[Ludwig Maes]

It makes very much sense that secure pin entry devices let the
smartcard control the display, but I have actually never found an
answer on wheither this is the case. The pin entry devices are
verified by auditing companies, if you society trusts the entry
devices, these might display the transaction details without the card
controlling the display.

Can you point me to a specification that states the card controls the display?
Or alternatively point me to javacard standard API calls that print to display?
How standardized are the displays and PIN keyboard? we would like to
display bitcoin adresses, left right keys would be usefull

After implementing the first version with normal reader and normal
smartcard, Id seriously consider the display+button cards,

[Ludwig Maes]

Rassah: what you describe will not happen if the hashing and signing
are done on the card and the card has display and pinpad (micro
computer limited communication interface that doesnt allow reading and
writing, just passing data to the applet)

[Uglješa Jovanović]

I wouldn't do the generation of keys on card, but on pc, because we
need to make a backup of the keys in case of card loss. I would
suggest to create a live linux distribution which would contain the
card management software (just a standard bitcoin client with support
for our smart card and advanced keys backup), the this usb started
linux distribution would serve as a secure backup and secure
management/initialization software. This is of course in the case that
if we generate the keys on card, we can't retrieve after generation.

The customized live linux distribution shouldn't be too hard to make.

[Ludwig Maes]

I prefer generating the keys on card, those who distrust their
computer/out of date live cd (which can be vulnerable, for example the
bitcoin live cd in the forums, in theory an attacker can look at the
date of creation of popular bitcoin distro, go to any vulnerability
site like oval.mitre.org and select vulnerabilities of choice since
the creation of the livecd. being connected could expose you. this is
not even a 0day, its a known vulnerability, just not known to your old
distro). people with static IP's who were present on bitcoin network
before are easy targets.

look at the users (A is normal and wants computer backup B is paranoid
and doesnt want backup, at most clone to other card by public key
exchange of cards)
1 generate on pc [optionally send to card]
2 generate on card [optionally send to pc]

A is happy with both (you cant smell in which direction the keys go so
it doesnt bother, you have to connect the smartcard either way if you
are A)
B is happy with 2 and chooses not to send to pc, but not with 1 which
forces him to trust his pc and the live cd (albeit not long)

in security choose the option most users are compatible with, B is not
compatible with 1 due to security reasons. we dont loose A but can
loose B in this decision.

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

[Uglješa Jovanović]

The solution to B's problem is easy, don't include networking
drivers/disable networking in live distro, since we don't need the
network to initialize/mange the card.

So this is the live distro use case:

1. Download the distro from a trusted source, check the md5 sum
or
1. When ordering a key card, you get a bundled key card and usb with
live distro you can trust immideately

2. Create keys, initialize the card with those keys, encrypt them and
store them to the usb the live distro is running on
3. Put the usb in a safe
4. Put the safe in a nuclear fallout shelter :)

I think the backup of the keys is really important because with the
scenario where you generate the keys on card, if you lose the card you
and the bitcoin network lose those bitcoins for ever

This is a issue (losing bitcoins) that i think (If bitcoins live for
that long) will become important at some time generally for the
bitcoin system, but it's out of our scope

[Smartcard Guy]

Well my thinking was this, an attacker who has sufficient permission to modify what is hashed on the host has enough permissions to modify what is sent to the card to be hashed.Thus the value of doing the hashing on the card is negligible.

All other things being equal I would say out of principal do the hashing on the card but the performance / reward trade off is such that I am not sure it makes sense to; don't get me wrong I would rather see it on the card and if the group wants to go that way I am fine, we should just be mindful of the fact we have not removed the vulnerability in question by doing so.

 

On the topic of performance, there are two hashes per bitcoin, that's two passes across the bus (even though these are USB they probably go serial to the chip); the hashing itself wont be super fast on a software implementation of SHA in a Java card; I dont have any good numbers for the card but you can get an idea of relative hash algorithm performance on a PC from http://www.cryptopp.com/benchmarks.html.

[Smartcard Guy]

It is the case, the smart card readers speak something called PC/SC (http://www.pcscworkgroup.com/); I used to be in this standards forum unfortunately after the main interoperability work was done for the basic smart card usage scenarios they kind of petered out so theres not a lot of activity there anymore.

 

Anyway, they do specify how a secure pin entry device works; there are lots of interoperability issues here and selection of readers will take some evaluations if we decide to go that way when we get there.

 

All of the on card display technology is proprietary as is the oncard pin entry stuff; so if we go this way we are kind of stuck with that vendor unless we work to specify how it will work and contribute it to a standards org and get a vendor to implement it, which is possible but time consuming.

 

Ryan

[Smartcard Guy]

Generating the keys outside the card is a non-starter, this removes the one solid promise v1 would give; aka your keys can not be stolen.

 

Any user mode malware in the context of the generation and/or import logic can get the key.

 

For backup I was thinking we would go down one of two paths:

1) Card exports key in cipher text to a backup secret / password

2) Card clones keys to backup card, exchange being done in cipher text

 

With both of these solutions the key is never unprotected, two is more secure than one but comes with the expectation that you have more than one card.

 

In two the applet on each cards negotiate a secure session of sorts so the exchange is allways secure.

 

Ryan

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

[Smartcard Guy]

Initialization is a good topic to cover. When you order cards you define what the card manufacturers call a electrical profile, you can think of this as containing things like:

1. What ATR the card will have (the ATR is how you can identify what kind of card it is / whats on it).

2. What the default administator key is.

3. How many failed attempts to log in brick the card.

4. How unblock of a card is done

5. ...

 

I was thinking that we would have a custom ATR so when we look at a card we can know its our card and that we would have a standard "default" admin pin from the factory.

 

When we see our card we would look for a file in the file system, the presence of this file will tell us that the card has been initialized, if it has not we would begin the initialization.

 

I imagined we would have some configuration file that mapped ATR to default admin password for the card, we would generate a secure password and use the admin password to reset the admin password to this new random password. We would display it and instruct the user to print it and save it off someplace secure because without it they could loose their data later.

 

We would then ask the user to choose the password/pin they will use to authenticate to the card for transactions, we would probably include a top 100 bad password list and a basic password policy that gave guidance on good/bad passwords, I wouldn't stop someone from setting a bad password just let them know they made a bad choice.

 

Once the user pin/password was set we would generate the ecdsa key and wallet.dat, we would display enough information that they could then send money to that key.

This approach means that malware that has access to the machine at provisioning time could have captured the admin and/or user pin so they could wipe the card destroying the key material and any associated keys as well as perform transactions with the keys as long as the card is present. This can be mitigated in a few ways:

1. Use a trusted live distro on cd to do the initialization, this would leave you with the exposure of any hardware/firmware malware that might be on the pc but thats fairly rare.

2. Use a fresh install of your os from trusted media.

3. Use a ped or card with a input device on it to do initialization.

5. Have the cards shipped with unique securly generated pins for both user and admin, this increases per card cost.

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

[Smartcard Guy]

I agree

[Ludwig Maes]

On 24 June 2011 18:39, Smartcard Guy <smartc...@gmail.com> wrote:
> Well my thinking was this, an attacker who has sufficient permission
> to modify what is hashed on the host has enough permissions to modify what
> is sent to the card to be hashed.Thus the value of doing the hashing on the
> card is negligible.

This is a dangerous misconception. if the card does not read the
unsigned cleartext to display to user, and does not hash it itself, it
could be signing the hash of a completely different transaction. I
repeat DISPLAYING and HASHING and SIGNING must BOTH be done ON CARD or
TRUSTED TERMINAL. The threat model is that the computer is not a
trusted terminal. perhaps a secure pinpad is, and a SC with own
display and buttons has even more potential to be so. (Please do not
confuse this with trying to reinvent wheel, this is not trying to
reinvent minicomputer/cellphone/..., the purpouse of crypto smartcards
is secure computation, not flexible multitasking run-it-all). Think
about it, do you sign things you cant read? Do you sign blank cheques?
I we allow the proposal software to save the card from the "work" of
hashing (c'mon theyre built for it, dont project your computers slow
bitcoin hashing rate (~10^~5 per second) to incredibly slow hashing on
smart card, each transaction would only take a few SHA256 hashes or
so).
If you continue this development with hashing done on the compromised
computer (threat model, if you assume opposite, you dont even need
smart cards), I WILL keep reminding bitcoin users of a flawed
implementation, and WILL provide a patch of your future proposal
software to prove it.

[Ludwig Maes]

Let me make myself clear:

> Well my thinking was this, an attacker who has sufficient permission
> to modify what is hashed on the host has enough permissions to modify what
> is sent to the card to be hashed.

The difference is in permission what is displayed as amount and adress
to user. If the cleartext is hashed to smart card the computer can not
control the display of SmartCard nor SecurePinpad Terminal (else the
Terminal should be considered compromised as well)

[Ludwig Maes]

typo:
If the cleartext is hashed on smart card the computer can not....

[Smartcard Guy]

Ludwig, I understand that if the card has a display or if we are using
a secure pin entry device that what you say is true but I understand
the group has agreed to start with commodity hardware which does not
include this.

Without a doubt if we were implementing a a custom applet i would want
to see us implement a simple bitcoin client that not only signed but
hashed as well, in fact I want to see us ultimately get to a simple
client where all wallet management and crypto happens on the card we
just don't have commodity hardware that will do what we need yet and a
variation will be needed for a point of sale solution like you
describe.

So my point was at least in v1, doing hashing on the card likely
represents additional work, additional performance implications and
doesn't improve the security in the scenario we were discussing. I
don't really care one way or another though, since it does help
address the more esoteric attack of a known trusted algorithm
implementation issue.

[Ludwig Maes]

OK then the misconceptions on my part are

On 25 June 2011 18:31, Smartcard Guy <smartc...@gmail.com> wrote:
> Ludwig, I understand that if the card has a display or if we are using
> a secure pin entry device that what you say is true but I understand
> the group has agreed to start with commodity hardware which does not
> include this.
>

I thought the group agreed to the following compromises:

1) if finding a card without the crypto acceleration cheap and
available enough turns out to be too hard, ... then for development
purpouses (or patient bitcoin users) we will start developing for
smart card without the crypto coprocessor acceleration.
I.e. no compromise in security but in speed (from the user
perspective): choose security over speed. once we get it *working*
it's just a matter of finding a card with the silicon acceleration
(crypto coprocessor supporting the right hashes and ECDSA curve).

2) if it turns out that getting (custom, or already existant) smart
cards with display and pin buttons turns out to be too
hard/expensive/slow dev cycle, we can deprioritize this requirement
(display and buttons on smartcard) by trusting secure pinpad terminals
_on the condition_ that the existing standards for these SC readers
with display require the display to be controlled by the smartcard and
not the computer. (we have not done real market research on the
smartcard /w display+buttons, nor have we done real specification
research on wheither these terminal screens are controlled by USB side
or SC side) I am very curious about the answers to these questions.

If the terminal screens are controlled by the smart cards (i.e.
print() functions in the javacard applet, with proof in standards that
the terminal screen are forbidden to be controlled by USB or at least
under certain conditions, i.e. when a SC is present), then yes I of
course dont care if four development purpouses you trust your
computer, but the applet should still control the pinpad display when
present. But you should then provide a disclaimer in the code to warn
people who trust their computer screen that in using the smartcard
setup without dedicated display there is no extra theoretical
protection for them. (only security through obscurity, i.e. no open
security at all)

> Without a doubt if we were implementing a a custom applet i would want
> to see us implement a simple bitcoin client that not only signed but
> hashed as well, in fact I want to see us ultimately get to a simple
> client where all wallet management and crypto happens on the card we
> just don't have commodity hardware that will do what we need yet and a
> variation will be needed for a point of sale solution like you
> describe.
>

In our previous discussions we were worried about the ECDSA signing,
why? because nearly all smart cards provide the hashing functionality,
the smart cards you ordered for example does (check the datasheet pdf
on the link you posted, when we searched for SEC2 ECDSA capable cards,
all of the crypto cards supported some SHA hash, and often SHA256 was
included), its just a matter of calling the SHA256() functions already
present on the card. you are compromising security for what? a few
lines of calling already existant code? not even that: if you dont
write it in the applet, youll write it in the proposal software...
this makes no sense at all.

> So my point was at least in v1, doing hashing on the card likely
> represents additional work, additional performance implications and
> doesn't improve the security in the scenario we were discussing. I
> don't really care one way or another though, since it does help
> address the more esoteric attack of a known trusted algorithm
> implementation issue.
>

Yes doing additional work, not for us (well some code to receive the
tobesigned cleartext transaction, and to print address and amount to
display), not for the users, but for the smartcard (not so much in
time as space to receive the transaction (currently an average
transaction is about 1/4 KB), I would NOT do wallet management on the
card for initial versions, storing all previous transactions will take
a lot of space). That is unless you go down special smartcard/token
route with extra space or support for memory cards.
Assuming thus that the card does not contain a traditional wallet.dat:
The onus/responsibility of scanning the blockchain to stay up to date
and checking if enough is present on the input adresses the card
pronounced, is on the side of the proposal software.

[r2k-in-the-vortex]

mouse touchpads seen in eg laptops are actually very thin(thin plate
under 1mm), all there really is is a capacitive grid layout and the
driver circuitry(usually separate from the sensor plate),
power consumption is definetly greater than plain simple keypad but
nothing grazy, also shouldnt be very excpensive

touchpads are neat, but simple keypads beat them hands down in
simplicity, price and usability.
while touchpads are relatively cheap, keypads cost next to nothing,
also keypads are trivial to program while touchpads are not(more
freedom for user means more difficulty for programmer),
keypads also dont need much special driver circuitry, plain digital io
lines from controller will do arrange your keys in a matrix and hey
presto you have a user interface

pushbuttons for prototypes: http://upload.wikimedia.org/wikipedia/commons/1/11/Tactile_switches.jpg
membrane keyboards for low volume mass production devices
http://img.nobodybuy.com/2010/01/23/judithqiao087/0x0_p986773/numeric-keypad-keypress-membrane-key-tac.jpg
silicon keypads for mass producible device:
http://upload.wikimedia.org/wikipedia/commons/6/60/Silicone_rubber_keypad_example_1.jpg

keypads are also more inituative to use
in such a mass producible device, keypad is the way to go any time
imho

as much as form factor goes maybe we could try and take notes from
plain office calculators, these are ultimate in mass producability,
cheapness, power usage and usability

we should also ask ourself what do we really need
do we need graphic lcd with touchpads and whatnot
or will alphanumeric lcd with keypad do the job and more?

do we really need anything more than a standard alfanumeric lcd +
keypad?
http://www.easybizchina.com/picture/product/200904/15-108d71e3-82e3-4230-9e21-dbc8b58e64c4.jpg


On Jun 21, 10:52 pm, Uglješa Jovanović <ionsp...@gmail.com> wrote:
> I understand what you're proposing, and maybe r2k will answer that
> better than i can, but from my experience touch pads (at least from my
> lap top) are thick, and I don't know about power consumption. But
> still, I'm not competent to answer :)
>
>
>
>
>
>
>
> On Tue, Jun 21, 2011 at 9:45 PM, Rassah <ras...@xnicole.com> wrote:
> > Just had a thought about something that's not even out yet. What's cheaper,
> > a screen, a keypad, or just a plain touch screen/mousepad?
> > What if one side of the card was like a mouse pad, and instead of having to
> > touch the keys or type in a pin, you would unlock your card by simply
> > swiping your finger from one corner to the next in a predetermined pattern,
> > similar to how Android phones are unlocked? That would be better for wear
> > and harder to crack than just buttons, may be cheaper to implement, and if
> > the touch area is large enough (almost the whole side of the card), would be
> > much easier to use for people with fat/old fingers.

[Ludwig Maes]

I think alphanumeric would be enough (i.e. support static const char*
pszBase58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";
from base58.h), and I think discrete keypad would be enough, why go
down the touchpad route?

2011/6/27 r2k-in-the-vortex <rkor...@gmail.com>:

[Bruce Wagner]

Did this idea die?