|| Home || IT Security || Smart cards || Resources || Links || switch_to_cz

Last actualization: 18.10.2009

Internal format of .NET smart card communication

Unlike with JavaCard smart cards, programming and communication with application uploaded on .NET-enabled smart card is not done with APDU (Application Protocol Data Unit) commands in the responsibility of developer. For the first look, application on the .NET smart card is viewed as server with its URI (Uniform Resource Identificator) whose methods are called. No APDU command construction is ever done by .NET developer, only server methods are called. Still, APDU commands are present on the lower level but shielded from developer by automatically generated stub library responsible for wrapping and unwrapping of method calls into APDU commands. Basic inspection of APDU format for .NET method calls is described here.

USB logging software was used to capture the traffic between .NET card and communication application on USB level. Modified winscard.dll library was also used to capture the relevant PC/SC traffic.

Based on communication observation, following format of underlying APDU commands of .NET calls was inferred (all content values are written in hexadecimal form, data are encoded in little endian fashion). Methods of on-card application can be invoked separately by APDU command with format described below.
  • Smart card applications manager is selectable application with AID a0 00 00 00 30 80 00 00 00 00 28 01 01

  • .NET server calls are translated into the sequence of standard APDU commands (usually one per method call). Stub dll library containing code responsible for translation between method call and APDU commands (named card_application_name_stub.dll) is generated. E.g., call to on-card method:
    public bool verifyPassword(string passwordToVerify); 
    is realized via automatically generated stub function with prototype:
    u1 CryptoService::verifyPassword(string* passwordToVerify){
    	u1 _u1 = 0;
    	Invoke(1, 0xEA4A, MARSHALLER_TYPE_IN_STRING, passwordToVerify, MARSHALLER_TYPE_RET_BOOL, &_u1);
    	return _u1;
    where 0xEA4A is unique ID used in method APDU command (see below).

APDU format

  • APDU contains standard APDU header (5 bytes), .NET header (10 bytes), URI length (2 bytes), on-card server application URI (URI length bytes) and parameters with no separating character.

  • APDU header (5 bytes): E.g., 80 C2 00 00 LC

  • .NET header (10 bytes): D8 00 02 6F 00 58 C2 81 80 95 (fixed content for our cards, but with unknown meaning yet)

  • Method ID (2 bytes): E.g., 15 01 (unique ID for each method, randomly generated during application compilation)

  • URI length (2 bytes): E.g., 00 11 (length of server URI identificator)

  • URI (URI length bytes): E.g., 11 43 72 79 70 74 6F 53 65 72 76 69 63 65 2E 75 72 69 (server URI identificator, is send again inside every APDU command. E.g., here 'CryptoService.uri')

  • Method parameters. No description of data type of method parameters or special separator character between parameters is used. Raw sequence of APDU bytes is therefore interpreted with the knowledge of expected parameters on card application. Following format of data types is used:

    1. String - 2 bytes length + string characters in ASCII encoding without end zero. E.g. '00 0B 68 65 6C 6C 6F 20 77 6F 72 6C 64 ' - eleven characters string containing 'hello world'.

    2. Integer number - 4 bytes length. E.g., 00 00 00 04 is equal to 4.

    3. Boolean value - 2 bytes length. E.g., 01 01 for TRUE.

Security considerations

  • No communication channel encryption is enforced on the apdu commands level. Value of methods parameters can be obtained from traffic unless encrypted channel is build and maintained.

  • No integrity of method parameters is enforced and therefore method parameters might be intensionally modified on the lowest APDU level. Corrupted parameters might affect execution of on-card application on two levels: a) Method parameters umarshalling before method is called, and b) method parameters interpretation inside method code. Robust parameter changing therefore needs to be performed.

.NET smart card cryptographic capabilities

CardConfig.xml positioned in root directory on smart card (C:\CardConfig.xml) contains a lot of relevant information about smart card configuration. It is a XML file with self-explanatory tag names. An example from Gemalto .NET v2:

Please, report any bugs or suggestions to my mail (see footer of the page). Thank you!

OpenPGP key : 0x89CEB31C