From: Joao Pedro (countzerosapo.pt)
Date: Fri Jul 17 2009 - 10:16:13 CDT

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

Hi Tommaso,

Tommaso Cucinotta <cucinottasssup.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
> Musclelists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>

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

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