APDU SELECT communication on T=0, 1, CL
Outside of the software simulation realm, I am trying to figure out what data communications look like on the low level serial channel when APDU SELECT is sent via T=0, T=1 or T=CL.
I have reference material showing me the APDU (SELECT) packet format. Let's say a javacard is placed in the reader, and the terminal generates SELECT with a certain bytes sequence.
Before being sent over the channel, is the byte sequence (packet) for SELECT encrypted?
I had been skimming Global Platform and saw mention of the "secure channel" but don't understand where that comes into play. Is APDU SELECT wrapped within the secure channel and therefore encrypted?
Before SELECT arrives, there is no active applet so I am trying to figure out who would do the encryption, and with what keys. Or am I missing a layer -- is in fact everything that goes over the physical serial channel encrypted, so no APDUs are ever in the clear?
[947 byte] By [
waterpca] at [2007-11-26 16:45:08]
# 1
> Outside of the software simulation realm, I am trying
> to figure out what data communications look like on
> the low level serial channel when APDU SELECT is sent
> via T=0, T=1 or T=CL.
SELECT command itself for a Java Card / Global Platform card is described on the application layer in the corresponding specifications. On the low level only the protocol (T=0/1: ISO7816-3, T=CL: ISO14443) is described . The APDU structure is described in ISO7816-4. The commands described are not supported with the exception of the GET RESPONSE command (commands are defined in JC/GP).
>
> I have reference material showing me the APDU
> (SELECT) packet format. Let's say a javacard is
> placed in the reader, and the terminal generates
> SELECT with a certain bytes sequence.
>
> Before being sent over the channel, is the byte
> sequence (packet) for SELECT encrypted?
No. For a JC/GP card the SELECT command is never encrypted. It has a well defined structure.
>
> I had been skimming Global Platform and saw mention
> of the "secure channel" but don't understand where
> that comes into play. Is APDU SELECT wrapped within
> the secure channel and therefore encrypted?
>
Secure channel is used to establish a secured connection between the terminal and the card (Security Domain on-card). There are three levels of security (SCP01/02). First one is plain authentication, second is that a MAC is always added to every command (except SELECT, it closes a secure channel) after authentication, third one is that every command (exc. SELECT) is encrypted and MAC added after authentication.
> Before SELECT arrives, there is no active applet so I
> am trying to figure out who would do the encryption,
> and with what keys. Or am I missing a layer -- is in
> fact everything that goes over the physical serial
> channel encrypted, so no APDUs are ever in the clear?
By default the so called CardManager is selected. It is possible to have a default selected Applet or a Supplementary Security Domain as well. The CardManager (on-card representative of the issuer, also called Issuer Security Domain) or a Supplementary SD is handling the secure channel, this would include encryption.
# 2
Thank you very much for the reply.
Regarding this APDU structure, if it is defined in ISO7816-4 (as relating to the contact card specs), does T=CL still use the same APDU structure? Or is the APDU packet format completely redefined in ISO 14443 ?
Apparently these ISO specs are not freely available (they do have a list of freely available ones, but smart card ones are not there). I will have to dig up these low level specs.
