Hi Tommaso,
Tommaso Cucinotta <[email protected]> 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
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
