[Muscle] Protecting a PIN with keyed hashing?

[Joao Pedro]

Hi Tommaso,

Tommaso Cucinotta <cucinotta at sssup.it> 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 +39 050 882 024, Fax +39 050 882 003
> http://feanor.sssup.it/~tommaso
>
> _______________________________________________
> Muscle mailing list
> Muscle at lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>