From: Joao Pedro (countzerosapo.pt)
Date: Fri Jul 17 2009 - 08:57:52 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Andreas,

Andreas Jellinghaus <ajdungeon.inka.de> wrote:

> Am Freitag 17 Juli 2009 13:57:18 schrieb Joao Pedro:
>> The idea is the following:
>>
>> If a user wishes to verify its PIN, instead of just using sending a
>> INS_VERIFY_PIN APDU with the PIN clear text, the following would happen:
>>
>> Pre-condition: The card has the PIN stored in clear text.
>>
>> 1. [Terminal] Sends a INS_GET_CHALLENGE message to the card.
>> 2. [Card] Sends a NONCE to the terminal.
>> 3. [Terminal] Computes RT = HMAC-SHA1(PIN, NONCE); sends RT to the card.
>> 4. [Card] Computes RC = HMAC-SHA(PIN, NONCE); RT == RC ? OK : Fail.
>
> so if you sniff the communication, you know both NONCE and RT and can
> calculate RT* for every PIN (one to four or six digits) - woulnd't take
> long with modern CPUs I guess. so this schema doesn't help much against
> brute force.
>
> also this schema can't be used with pinpad readers.
>

I agree with all you said. (plase see my second message regarding this topic).

> I think it is much easier these days to hack a computer, than to modify
> the reader or cables. thus from my perspective this approach helps
> against the less likely attack, and makes some attacks on the host
> computer harder, but not much.
>
> But I have no clue if there are other schemas that help better to protect
> the communication. I know diffie-hellmann key exchange off course, but that
> might be far to complicated for a card applet?

I might be an idea. The JC API supports DH Key Exchange:
http://www.win.tue.nl/pinpasjc/docs/apis/jc222/javacard/security/KeyAgreement.html.

>
> Regards, Andreas
>

_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]