Protecting a PIN with keyed hashing?

[Joao Pedro-3]

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@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Joao Pedro-3]

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@...> 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@...
> http://lists.drizzle.com/mailman/listinfo/muscle
>

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

[Andreas Schwier]

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.

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@...> 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@...
>> http://lists.drizzle.com/mailman/listinfo/muscle
>>
>
>
> _______________________________________________
> Muscle mailing list
> Muscle@...
> http://lists.drizzle.com/mailman/listinfo/muscle

--

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone [phone]
    ---------    http://www.cardcontact.de
                 http://www.openscdp.org


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

[Sébastien Lorquet]

the muscle applet is for global platform javacards right?

Then about the GP secure channel already implemented (org.globalplatform.SecureChannel org.globalplatform.GPSystem.getSecureChannel() ) in these cards for secure messaging? it provides a mac+tdes encryption. also, writing a software implementation is not difficult, if needed (to use other keys than SD's ones)

sebastien

ps: the muscle applet also support strong authentication with a challenge/response exchange. A 128 bits TDES key can be seen as a 16-character PIN, that can be right padded with zeroes or other if needed. what do you think of this?

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

[Miller, Timothy J.]

As I understand it, the symmetric key secured channel is for card management (e.g., PIN unblock, applet load, key injection, etc.), not for normal access.

-- Tim

>-----Original Message-----
>From: muscle-bounces@... [mailto:muscle-
>bounces@...] On Behalf Of Sébastien Lorquet
>Sent: Friday, July 17, 2009 7:56 AM
>To: MUSCLE
>Subject: Re: [Muscle] Protecting a PIN with keyed hashing?
>
>the muscle applet is for global platform javacards right?
>
>Then about the GP secure channel already implemented
>(org.globalplatform.SecureChannel
>org.globalplatform.GPSystem.getSecureChannel() ) in these cards for
>secure messaging? it provides a mac+tdes encryption. also, writing a
>software implementation is not difficult, if needed (to use other keys
>than SD's ones)
>
>sebastien
>
>ps: the muscle applet also support strong authentication with a
>challenge/response exchange. A 128 bits TDES key can be seen as a 16-
>character PIN, that can be right padded with zeroes or other if needed.
>what do you think of this?

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

[Sébastien Lorquet]

I know it, but you can easily write a class implementing the org.globalplatform.SecureChannel interface to mimick the card manager's secure channel, and reuse host-side tools that "talk" this protocol :)

On Fri, Jul 17, 2009 at 3:07 PM, Miller, Timothy J. <tmiller@...> wrote:

As I understand it, the symmetric key secured channel is for card management (e.g., PIN unblock, applet load, key injection, etc.), not for normal access.

-- Tim

>-----Original Message-----
>From: muscle-bounces@... [mailto:...
>bounces@...] On Behalf Of Sébastien Lorquet
>Sent: Friday, July 17, 2009 7:56 AM
>To: MUSCLE
>Subject: Re: [Muscle] Protecting a PIN with keyed hashing?
>
>the muscle applet is for global platform javacards right?
>
>Then about the GP secure channel already implemented
>(org.globalplatform.SecureChannel
>org.globalplatform.GPSystem.getSecureChannel() ) in these cards for
>secure messaging? it provides a mac+tdes encryption. also, writing a
>software implementation is not difficult, if needed (to use other keys
>than SD's ones)
>
>sebastien
>
>ps: the muscle applet also support strong authentication with a
>challenge/response exchange. A 128 bits TDES key can be seen as a 16-
>character PIN, that can be right padded with zeroes or other if needed.
>what do you think of this?

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

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

[Joao Pedro-3]

Thanks Sébastien and everyone else who is participating!

Sébastien Lorquet <squalyl@...> wrote:

> the muscle applet is for global platform javacards right?
>
> Then about the GP secure channel already implemented
> (org.globalplatform.SecureChannel
> org.globalplatform.GPSystem.getSecureChannel() ) in these cards for
> secure messaging? it provides a mac+tdes encryption. also, writing
a
> software implementation is not difficult, if needed (to use other
> keys than SD's ones)
>

I think secure messaging could work well (I'm still trying to  
understand all the mechanisms involved in it).

But, if I'm not mistaken, secure messaging involves the existence of  
pre-shared keys. They can be symmetric (3DES), or assymetric (RSA) +  
Diffie-Hellman parameters to establish the session keys. So, this  
could be a bit of a hassle for users? I.e. the middleware would have  
to know/generate these keys, etc.

> sebastien
>
> ps: the muscle applet also support strong authentication with a
> challenge/response exchange. A 128 bits TDES key can be seen as a
> 16-character PIN, that can be right padded with zeroes or other if
> needed. what do you think of this?

It's an idea, but what are the security implications of just zero  
padding a PIN? It's an honest question :)

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

[Andreas Jellinghaus-2]

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 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?

Regards, Andreas
_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Miller, Timothy J.]

I presume such a scheme would apply a KDF of some kind to the PIN or PIN + nonce (e.g., PBKDF2 from PKCS#5) in order to derive the symmetric key for this secure channel.  This is still subject to simple offline attack because PINs don't have enough entropy on their own, and the nonce would still have to be shared over the insecure channel.  I'd also worry about speed of the KDF on the card, but that's probably minor.

Maybe SRP would be a better solution.

-- Tim

>-----Original Message-----
>From: muscle-bounces@... [mailto:muscle-
>bounces@...] On Behalf Of Sébastien Lorquet
>Sent: Friday, July 17, 2009 8:17 AM
>To: MUSCLE
>Subject: Re: [Muscle] Protecting a PIN with keyed hashing?
>
>I know it, but you can easily write a class implementing the
>org.globalplatform.SecureChannel interface to mimick the card manager's
>secure channel, and reuse host-side tools that "talk" this protocol :)
>
>
>On Fri, Jul 17, 2009 at 3:07 PM, Miller, Timothy J. <tmiller@...>
>wrote:
>
>
> As I understand it, the symmetric key secured channel is for card
>management (e.g., PIN unblock, applet load, key injection, etc.), not
>for normal access.
>
> -- Tim
>
>
>
> >-----Original Message-----
> >From: muscle-bounces@... [mailto:muscle-
> >bounces@...] On Behalf Of Sébastien Lorquet
> >Sent: Friday, July 17, 2009 7:56 AM
> >To: MUSCLE
> >Subject: Re: [Muscle] Protecting a PIN with keyed hashing?
> >
> >the muscle applet is for global platform javacards right?
> >
> >Then about the GP secure channel already implemented
> >(org.globalplatform.SecureChannel
> >org.globalplatform.GPSystem.getSecureChannel() ) in these cards
>for
> >secure messaging? it provides a mac+tdes encryption. also,
>writing a
> >software implementation is not difficult, if needed (to use other
>keys
> >than SD's ones)
> >
> >sebastien
> >
> >ps: the muscle applet also support strong authentication with a
> >challenge/response exchange. A 128 bits TDES key can be seen as a
>16-
> >character PIN, that can be right padded with zeroes or other if
>needed.
> >what do you think of this?
>
>
>
> _______________________________________________
> Muscle mailing list
> Muscle@...
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
>

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

[Ludovic Rousseau]

2009/7/17 Joao Pedro <countzero@...>:
> Hi all,

Hello,

> 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.

What wireless smart card readers do you have in mind? I don't know any
wireless readers.

> 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?

How it is supposed to work with a pinpad reader?

Bye

--
 Dr. Ludovic Rousseau
_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Joao Pedro-3]

Hi Andreas,

Andreas Schwier <andreas.schwier@...> 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@...> 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@...
>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>>
>>
>>
>> _______________________________________________
>> Muscle mailing list
>> Muscle@...
>> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
> --
>
>     ---------    CardContact Software & System Consulting
>    |.##> <##.|   Andreas Schwier
>    |#       #|   Schülerweg 38
>    |#       #|   32429 Minden, Germany
>    |'##> <##'|   Phone [phone]
>     ---------    http://www.cardcontact.de
>                  http://www.openscdp.org
>
>
>

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

[Joao Pedro-3]

Hi,

Ludovic Rousseau <ludovic.rousseau@...> wrote:

> 2009/7/17 Joao Pedro <countzero@...>:
>> Hi all,
>
> Hello,
>
>> 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.
>
> What wireless smart card readers do you have in mind? I don't know any
> wireless readers.
>

Sorry, I meant contacless readers.

>> 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?
>
> How it is supposed to work with a pinpad reader?

It doesn't. Shortly after I sent the first email I sent another  
message describing this problem and also that a simple PIN is too  
small to be used with keyed hashing.

I was hoping to hear better (and more general) solution than the one  
proposed :) The idea was to know if there is any mechanism that  
doesn't depend on pre-shared keys such as Secure Messaging.

Thank you.

Regards,
Joao

> Bye
>
> --
>  Dr. Ludovic Rousseau
> _______________________________________________
> Muscle mailing list
> Muscle@...
> http://lists.drizzle.com/mailman/listinfo/muscle
>


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

[Joao Pedro-3]

Hi Andreas,

Andreas Jellinghaus <aj@...> 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
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Joao Pedro-3]

Hi Timothy,

"Miller, Timothy J." <tmiller@...> wrote:

> I presume such a scheme would apply a KDF of some kind to the PIN or  
> PIN + nonce (e.g., PBKDF2 from PKCS#5) in order to derive the  
> symmetric key for this secure channel.  This is still subject to  
> simple offline attack because PINs don't have enough entropy on  
> their own, and the nonce would still have to be shared over the  
> insecure channel.  I'd also worry about speed of the KDF on the  
> card, but that's probably minor.
>
> Maybe SRP would be a better solution.
Could you please explain, or provide a reference to what SRP is?

Thank you.

Regards,
Joao

>
> -- Tim
>
>
>> -----Original Message-----
>> From: muscle-bounces@... [mailto:muscle-
>> bounces@...] On Behalf Of Sébastien Lorquet
>> Sent: Friday, July 17, 2009 8:17 AM
>> To: MUSCLE
>> Subject: Re: [Muscle] Protecting a PIN with keyed hashing?
>>
>> I know it, but you can easily write a class implementing the
>> org.globalplatform.SecureChannel interface to mimick the card manager's
>> secure channel, and reuse host-side tools that "talk" this protocol :)
>>
>>
>> On Fri, Jul 17, 2009 at 3:07 PM, Miller, Timothy J. <tmiller@...>
>> wrote:
>>
>>
>> As I understand it, the symmetric key secured channel is for card
>> management (e.g., PIN unblock, applet load, key injection, etc.), not
>> for normal access.
>>
>> -- Tim
>>
>>
>>
>> >-----Original Message-----
>> >From: muscle-bounces@... [mailto:muscle-
>> >bounces@...] On Behalf Of Sébastien Lorquet
>> >Sent: Friday, July 17, 2009 7:56 AM
>> >To: MUSCLE
>> >Subject: Re: [Muscle] Protecting a PIN with keyed hashing?
>> >
>> >the muscle applet is for global platform javacards right?
>> >
>> >Then about the GP secure channel already implemented
>> >(org.globalplatform.SecureChannel
>> >org.globalplatform.GPSystem.getSecureChannel() ) in these cards
>> for
>> >secure messaging? it provides a mac+tdes encryption. also,
>> writing a
>> >software implementation is not difficult, if needed (to use other
>> keys
>> >than SD's ones)
>> >
>> >sebastien
>> >
>> >ps: the muscle applet also support strong authentication with a
>> >challenge/response exchange. A 128 bits TDES key can be seen as a
>> 16-
>> >character PIN, that can be right padded with zeroes or other if
>> needed.
>> >what do you think of this?
>>
>>
>>
>> _______________________________________________
>> Muscle mailing list
>> Muscle@...
>> http://lists.drizzle.com/mailman/listinfo/muscle
>>
>>
>>
>
>

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

[cucinotta]

Hi,

Joao Pedro ha scritto:
> I was hoping to hear better (and more general) solution than the one
> proposed :) The idea was to know if there is any mechanism that
> doesn't depend on pre-shared keys such as Secure Messaging.
I think what you actually didn't provide is *what problem* you want to
solve.
It seems from the discussion that you are exclusively concerned about
security
of the PIN, but in the case the PC/Reader/SC communication may be spied
upon,
I think there should be greater concerns around:
1. what about security of the exchanged data: such data might range from
    public-key certificates or personal prefs (no issue at all) to
sensitive data
    like passwords, or even cryptographic keys (think of the ImportKey
APDU);
2. if the attacker may also inject its own messages inside the communication
    (as I actually think it would be possible), then there are plenty of
problems,
    because no matter spying on the PIN: once the legitimate user has
authenticated,
    the attacker has the (unlocked) card at its own disposal for doing
whatever
    with it (i.e., reading sensitive data, using cryptographic keys, etc...;
    with proper equipment, authenticating to a second physical terminal
not too
    far from the other one where the legitimate user is entering, if your
    use-case is control to physical access to systems)

Secure Messaging is more complex because it does not aim to protect the PIN,
but it aims to protect the valuables inside the smart-card
(cryptographic keys
and sensitive user data), and for such purposes you need not only to
authenticate,
but also to establish a session key and encrypt all of the the
subsequent messages
inside the session.

Please, provide details about the typical use-case (scenario/story)
where the
mechanism you are looking for is needed, and what security properties  
(i.e.,
requirements) you would need from such a mechanism.

Regards,

    T.

--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel [phone], Fax [phone]
http://feanor.sssup.it/~tommaso

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

[Miller, Timothy J.]

http://srp.stanford.edu/whatisit.html

-- Tim

>-----Original Message-----
>From: Joao Pedro [mailto:countzero@...]
>Sent: Friday, July 17, 2009 9:01 AM
>To: MUSCLE; Miller, Timothy J.
>Subject: RE: [Muscle] Protecting a PIN with keyed hashing?
>
>Hi Timothy,
>
>"Miller, Timothy J." <tmiller@...> wrote:
>
>> I presume such a scheme would apply a KDF of some kind to the PIN or
>> PIN + nonce (e.g., PBKDF2 from PKCS#5) in order to derive the
>> symmetric key for this secure channel.  This is still subject to
>> simple offline attack because PINs don't have enough entropy on
>> their own, and the nonce would still have to be shared over the
>> insecure channel.  I'd also worry about speed of the KDF on the
>> card, but that's probably minor.
>>
>> Maybe SRP would be a better solution.
>Could you please explain, or provide a reference to what SRP is?
>
>Thank you.
>
>Regards,
>Joao
>
>>
>> -- Tim
>>
>>
>>> -----Original Message-----
>>> From: muscle-bounces@... [mailto:muscle-
>>> bounces@...] On Behalf Of Sébastien Lorquet
>>> Sent: Friday, July 17, 2009 8:17 AM
>>> To: MUSCLE
>>> Subject: Re: [Muscle] Protecting a PIN with keyed hashing?
>>>
>>> I know it, but you can easily write a class implementing the
>>> org.globalplatform.SecureChannel interface to mimick the card
>manager's
>>> secure channel, and reuse host-side tools that "talk" this protocol
>:)
>>>
>>>
>>> On Fri, Jul 17, 2009 at 3:07 PM, Miller, Timothy J.
><tmiller@...>
>>> wrote:
>>>
>>>
>>> As I understand it, the symmetric key secured channel is for card
>>> management (e.g., PIN unblock, applet load, key injection, etc.), not
>>> for normal access.
>>>
>>> -- Tim
>>>
>>>
>>>
>>> >-----Original Message-----
>>> >From: muscle-bounces@... [mailto:muscle-
>>> >bounces@...] On Behalf Of Sébastien Lorquet
>>> >Sent: Friday, July 17, 2009 7:56 AM
>>> >To: MUSCLE
>>> >Subject: Re: [Muscle] Protecting a PIN with keyed hashing?
>>> >
>>> >the muscle applet is for global platform javacards right?
>>> >
>>> >Then about the GP secure channel already implemented
>>> >(org.globalplatform.SecureChannel
>>> >org.globalplatform.GPSystem.getSecureChannel() ) in these cards
>>> for
>>> >secure messaging? it provides a mac+tdes encryption. also,
>>> writing a
>>> >software implementation is not difficult, if needed (to use other
>>> keys
>>> >than SD's ones)
>>> >
>>> >sebastien
>>> >
>>> >ps: the muscle applet also support strong authentication with a
>>> >challenge/response exchange. A 128 bits TDES key can be seen as a
>>> 16-
>>> >character PIN, that can be right padded with zeroes or other if
>>> needed.
>>> >what do you think of this?
>>>
>>>
>>>
>>> _______________________________________________
>>> Muscle mailing list
>>> Muscle@...
>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>>
>>>
>>>
>>
>>

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

[Joao Pedro-3]

Hi Tommaso,

Tommaso Cucinotta <cucinotta@...> wrote:

> Hi,
>
> Joao Pedro ha scritto:
>> I was hoping to hear better (and more general) solution than the  
>> one proposed :) The idea was to know if there is any mechanism that  
>> doesn't depend on pre-shared keys such as Secure Messaging.
> I think what you actually didn't provide is *what problem* you want to solve.
> It seems from the discussion that you are exclusively concerned  
> about security
> of the PIN, but in the case the PC/Reader/SC communication may be spied upon,

Yes, the main focus is the protection of the PIN value.

> I think there should be greater concerns around:
> 1. what about security of the exchanged data: such data might range from
>    public-key certificates or personal prefs (no issue at all) to  
> sensitive data
>    like passwords, or even cryptographic keys (think of the ImportKey APDU);
> 2. if the attacker may also inject its own messages inside the communication
>    (as I actually think it would be possible), then there are plenty  
> of problems,
>    because no matter spying on the PIN: once the legitimate user has  
> authenticated,
>    the attacker has the (unlocked) card at its own disposal for  
> doing whatever
>    with it (i.e., reading sensitive data, using cryptographic keys, etc...;
>    with proper equipment, authenticating to a second physical  
> terminal not too
>    far from the other one where the legitimate user is entering, if your
>    use-case is control to physical access to systems)
>

The main use case, would be a user entering its PIN in an "insecure area".

Assumptions:
Only passive attacks are possible (e.g. sniffing).

Pre-conditions:
The card was previously initialized.
All needed sensitive information is already on the card (e.g. keys).

1. The user tries to validate its PIN.
2. The card emits a challenge.
3. The user sends a hmac message, with key = PIN and the previously  
received challenge.
4. The use case ends.

> Secure Messaging is more complex because it does not aim to protect the PIN,
> but it aims to protect the valuables inside the smart-card  
> (cryptographic keys
> and sensitive user data), and for such purposes you need not only to  
> authenticate,
> but also to establish a session key and encrypt all of the the  
> subsequent messages
> inside the session.
>
> Please, provide details about the typical use-case (scenario/story) where the
> mechanism you are looking for is needed, and what security properties  (i.e.,
> requirements) you would need from such a mechanism.
>

Like you said, there are much more scenarios, that are more likely /  
serious, where exclusively protecting the PIN would not help much, or  
at all.

What I was trying to do, was to stimulate  a conversation to find  
whether is it feasible, or not, for a user to introduce his/her PIN  
code and use the card securely in an hostile environment. This  
mechanism should be as simple as possible and depend on the minimum  
amount of shared information. I left the "threat model" more or less  
vague so that the discussion wouldn't be limited - for that my  
apologies.

One different idea was the user encrypting the PIN value with a public  
key (that belonged to the user) present on the card. This way, only  
the card could decipher it (using the private key) and check its  
validity.

Another idea would be to implement just Diffie-Hellman for the Key  
agreement. This, of course, is vulnerable to man in the middle  
attacks, as DH doesn't provide authentication. Besides, I think DH to  
work in the JC API needs a card with EC support...

The problem, I think, with Secure Messaging is that a user can't use  
its card "anywhere" transparently - it needs an infrastructure  
previously set up. Imagine this: I have the Muscle applet on my java  
card and use OpenSC. This applet has a pair of pre-shared symmetric  
keys with OpenSC: one for MAC the other for encryption of the secure  
channel. This is ok as long as I only use my card with only "my"  
version of OpenSC. If I try to use it in a friends computer, I'll have  
to provide the keys. But, maybe, Secure Messaging its the only  
adequate solution for an "end-to-end" security. Because protecting  
only the PIN, as you said, would not protect against more serious  
attacks.

Thank you for the feedback.

Regards,
Joao

> Regards,
>
>    T.
>
> --
> Tommaso Cucinotta, Computer Engineering PhD, Researcher
> ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
> Tel [phone], Fax [phone]
> http://feanor.sssup.it/~tommaso
>
> _______________________________________________
> Muscle mailing list
> Muscle@...
> http://lists.drizzle.com/mailman/listinfo/muscle
>

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