[Muscle] Protecting a PIN with keyed hashing?

[Joao Pedro]

Hi Andreas,

Andreas Schwier <andreas.schwier at cardcontact.de> wrote:

> Hi Joao,
>
> there is a protocol called PACE (Password Authenticated Connection
> Establishment) that has been introduced with Extended Access Control for
> passports. This does exactly what you are looking for.

That is really interesting, I read a presentation on it just now. But  
one would need an EC capable card, correct?

Regards,
Joao

>
> Andreas
>
> Joao Pedro schrieb:
>> Replying to myself here to leave a note:
>>
>> This mechanism if susceptible to offline attacks, i.e. if an attacker
>> can sniff the challenge and response messages, he/she can try to brute
>> force the PIN.
>>
>> The level of protection offered by this mechanism is directly related
>> with the strength of the PIN, e.g. a PIN like '1234' would be quickly
>> cracked - so a strong password should be selected as the PIN. This, of
>> course, would cause problems with numeric only pinpad readers...
>>
>> Joao Pedro <countzero at sapo.pt> wrote:
>>
>>> Hi all,
>>>
>>> Recently, I've been wondering about ways to mitigate the problem of
>>> the PINs, in the Muscle applet, being transmitted in clear text from
>>> the terminal to the card. The reason is we are seeing more and more
>>> wireless smart card readers and sniffing is a threat that can not be
>>> dismissed.
>>>
>>> A obvious way would be implementing secure messaging and I think one
>>> should look into it, but that solution requires a bigger effort...
>>>
>>> So, what do you think about the idea of protecting PINs in the Muscle
>>> applet using keyed hashing, something along the lines of HMAC-SHA1,
>>> or any other derivative. I think that, in a way, the External
>>> Authentication code in the applet is supposed to do this, but using
>>> keys (DES, 3DES, RSA, etc.).
>>>
>>> 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.
>>>
>>> What do you think of it? Is it stupid/flawed/insecure/reinventing the
>>> wheel and serves no purpose at all. Or could it be used in real life?
>>>
>>> Thank you.
>>>
>>> Regards,
>>> Joao
>>>
>>> _______________________________________________
>>> Muscle mailing list
>>> Muscle at lists.musclecard.com
>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>>
>>
>>
>> _______________________________________________
>> Muscle mailing list
>> Muscle at lists.musclecard.com
>> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
> --
>
>     ---------    CardContact Software & System Consulting
>    |.##> <##.|   Andreas Schwier
>    |#       #|   Schülerweg 38
>    |#       #|   32429 Minden, Germany
>    |'##> <##'|   Phone +49 171 8334920
>     ---------    http://www.cardcontact.de
>                  http://www.openscdp.org
>
>
>