Question: reader to card communication

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Question: reader to card communication

Markus Schatzl-2
Hi list,

I would be glad if someone could provide some information or
links regarding contemporary reader to card communication. I
didn't really find anything recent by searching the net.

"Secure Messaging" obviously negotiates a secure channel between
the reader and the smartcard, so that the signals cannot be
wiretapped. What I ask myself is how this channel is built.
There must be either a symmetric secret (which doesn't make that
much sense given the plethora of devices and cards), or an
assymetric mode. I gather that the reader requests a public
encryption key from the card and sets up the symmetric
communication keys by that. But I don't really have an idea if
that matches reality.

Some new models also seem to extend that approach to
application-to-smartcard communication.

I appreciate any help on this topic.

Thanks in advance,
/Markus

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question: reader to card communication

Andreas Jellinghaus-2
not 100% sure, never used it myself, these are only my best guesses.

Markus Schatzl wrote:
> "Secure Messaging" obviously negotiates a secure channel between
> the reader and the smartcard, so that the signals cannot be
> wiretapped. What I ask myself is how this channel is built.

The secure channel is Host/Software <-> Card, not Reader <-> Card.

> There must be either a symmetric secret (which doesn't make that
> much sense given the plethora of devices and cards), or an
> assymetric mode. I gather that the reader requests a public
> encryption key from the card and sets up the symmetric
> communication keys by that. But I don't really have an idea if
> that matches reality.

There is not. Man in the middle is possible as far as I know.
Usualy it is only a matter of:
  - get challange (i.e. ask the card for some random bytes)
  - encrypt command to send with that data
  - send as encrypted command.

for real world code take a look at the gpk driver which uses secure
messaging.

of course secure communication can also be used with real secrets I
guess, for example a PIN to be verified that way. (or transport keys
or ...).

and I heard that some cards can even do RSA or certificate based
authentication, so for example a reader could have a smart
card inside too (or the host), and could proove its authenticity
to the card with his rsa key and the x.509 certificate, and the
card could both check the certificate against some rootca and
check the rsa key. but never saw a card that actualy did that.

also it is kind of silly, the crypto is simple as we know, but
the key management is not, and card can neither store CRL lists
nor ask some server to check a certificate against a CRL so the
usefulness of such an approach is quite limited

> Some new models also seem to extend that approach to
> application-to-smartcard communication.

I think application to smartcard is more common, e.g. storing
private keys over an encrypted line is a good idea, even if
the mechanism isn't man in the middle resistant.

and once you have contact less smart cards, you should encrypt
all communication anyway...

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Question: reader to card communication

Tarasov Viktor
Andreas Jellinghaus a écrit :
> not 100% sure, never used it myself, these are only my best guesses.
>
> Markus Schatzl wrote:
>> "Secure Messaging" obviously negotiates a secure channel between
>> the reader and the smartcard, so that the signals cannot be
>> wiretapped. What I ask myself is how this channel is built.
>
> The secure channel is Host/Software <-> Card, not Reader <-> Card.
You can look the Global Platform's specification of Secure Channel.
http://www.globalplatform.org/specificationview.asp?id=card

>
>> There must be either a symmetric secret (which doesn't make that
>> much sense given the plethora of devices and cards), or an
>> assymetric mode. I gather that the reader requests a public
>> encryption key from the card and sets up the symmetric
>> communication keys by that. But I don't really have an idea if
>> that matches reality.
>
> There is not. Man in the middle is possible as far as I know.
> Usualy it is only a matter of:
>  - get challange (i.e. ask the card for some random bytes)
>  - encrypt command to send with that data
>  - send as encrypted command.

Oberthur java card (that conforms to GP) has at least one key-set that
contains three 128-bit DES keys,
used to calculate three session keys:
for the card<->host mutual authentication and key encryption
(authentication),
for data encryption (confidentiality);
and for MAC calculation (integrity).
Transaction is (rather can be -- there are tree possible levels of SM)
protected from the 'man in the middle'.

>
> for real world code take a look at the gpk driver which uses secure
> messaging.
>
> of course secure communication can also be used with real secrets I
> guess, for example a PIN to be verified that way. (or transport keys
> or ...).
In case of the Oberthur's card, Verify PIN command is not protected with
secure messaging,
but the other commands that use PIN (unblock, change) can use it.
>
> and I heard that some cards can even do RSA or certificate based
> authentication, so for example a reader could have a smart
> card inside too (or the host), and could proove its authenticity
> to the card with his rsa key and the x.509 certificate, and the
> card could both check the certificate against some rootca and
> check the rsa key. but never saw a card that actualy did that.
Internal/External Authentication ACL implemented by Oberthur, Cyberflex,
IAS, (other ?) cards.
It can use RSA, DES, (other ?) keys for the mutual authentication.

>
> also it is kind of silly, the crypto is simple as we know, but
> the key management is not, and card can neither store CRL lists
> nor ask some server to check a certificate against a CRL so the
> usefulness of such an approach is quite limited
>
>> Some new models also seem to extend that approach to
>> application-to-smartcard communication.
>
> I think application to smartcard is more common, e.g. storing
> private keys over an encrypted line is a good idea, even if
> the mechanism isn't man in the middle resistant.
>
> and once you have contact less smart cards, you should encrypt
> all communication anyway...
>
> Regards, Andreas
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

Kind wishes,
Viktor.

>
>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel