A smart card console with an emulator is available here:
VSCEmuSetup.exe (468,97 kb)
By such an emulator, the reader can make practice and become familiar with ISO7816 APDUs.
The emulator supplies a virtual smart card reader providing connection to a virtual T = 1 microprocessor smart card which accept ISO7816 APDUs. Also, by such an emulator the reader could read data from own SIM card (see paragraph 8.4.5).
Figure below shows the console that allows communicating with the virtual smart card. On the top left there is a drop-down menu to select the smart card reader. You could select “Ugo’s Virtual Smart Card Reader” to use the virtual smart card, otherwise, if on your workstation there is a real PC/SC reader, you could select it to send commands to an actual smart card.
Screenshot of Virtual Smart Card Emulator console
On top left you find CLA, INS, P1, P2, LC and DATA fields to specify the APDU being submitted clicking the Send button. The Reset button sends the homonymous signal. Finally, the central panel displays the log of the sent APDU. The values of the Command ADPU fields must be typed in hex (as shown in Figure 3.7). Likewise, Response APDUs appear on the central pane in hex. To maintain consistency with emulator’s notation, all numeric values in the following sections are in hex notation.
Setup
To install the emulator you just simply run the setup file to show the setup wizard.
The virtual smart card
The smart card emulator offers a very simple smart card, fully compliant with ISO 7816 specifications. Using such a software the reader could train himself with APDUs as described in previous sections. The virtual smart card is meant just for simulate real smart card functionalities. While conforming to ISO 7816 standard, the virtual smart card supports just a subset of standard APDUs, some of which, for the sake of simplicity, had been furthermore simplified or partly implemented respect to the corresponding full versions of ISO 7816 specifications. The reference guide of the virtual smart card is reported in the Appendix A along with all supported commands.
For who could be interested, an actual smart card, identical to virtual smart card, is available on demand.
Smart card lifecycle
The virtual smart card’s lifecycle denotes two states: unformatted and formatted. On unformatted status smart card’s EEPROM memory is empty and most of the commands are disabled. In this status the virtual smart card must be formatted using a special formatting command which initializes the EEPROM, creates the Master File and switches the smart card in the formatted status.
After installing the emulator, you found the virtual smart card in the unformatted status. In such a state, it replies just to GET_DATA and FORMAT commands.
To know the smart card’s current status you must submit a GET_DATA APDU with mode = 83, as reported here (see also Appendix A):
APDU Command: (GET DATA)
- CLA=00, INS=CA, P1=00, P2=80, LC=00, LE=00
- DATA=
Issuing the command using the emulator’s console you get:
APDU Response:
- SW1=90, SW2=00
- DATA=10
SW1=90 and SW2=00 indicate a successful execution of the APDU, while the value 10 in the field DATA indicates the unformatted status. Conversely, a value of 20 means a formatted status.
To switch the smart card from unformatted to formatted status you must send a FORMAT command, while to switch from formatted to unformatted status you must send an ERASE EEPROM command (see Section 3.7.5).
Microchip Information
Using the GET_DATA APDU you could get all information relating the microchip and the installed operating system. For example, setting mode = 80 you obtain vendor-related information, along with the operating system version, microchip’s manufacturing date and copyright data. Instead, setting mode = 81 you get the microchip’s identification (unique) code:
Command APDU: (GET DATA)
- CLA=00, INS=CA, P1=00, P2=80, LC=00, LE=00
- DATA=
Response APDU:
- SW1=90, SW2=00
DATA=55676F2773205669727475616C20536D61727420436172642C2076312E302E302C2031382F3
1302F30332C20436F707972696768742028432920323030332062792055676F204368697269636F
=U.g.o.’.s. .V.i.r.t.u.a.l. .S.m.a.r.t. .C.a.r.d.,.
.v.1...0...0.,. .1.8./.1.0./.0.3.,. .C.o.p.y.r.i.g.h.t.
.(.C.). .2.0.0.5. .b.y. .U.g.o. .C.h.i.r.i.c.o.
Command APDU: (GET DATA)
- CLA=00, INS=CA, P1=00, P2=81, LC=00, LE=00
- DATA=
Response APDU:
- SW1=90, SW2=00
- DATA=41303030303030303030303030303031
=A.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.
Formatting the Smart Card
Assuming that the virtual smart card is found in a unformatted status (see Section 3.7.3) you must format it using the FORMAT command:
Command APDU: (FORMAT)
- CLA=C0, INS=41, P1=00, P2=00, LC=0A, LE=00
- DATA=30313233343536373839
=0.1.2.3.4.5.6.7.8.9.
Response APDU:
- SW1=90, SW2=00
The DATA field of the previous APDU must hold the formatting key, which in the case of that virtual smart card is 0123456789. Typically, with real-word smart cards, the formatting key is provided by the vendor and usually you must keep it in a safe place to avoid that a malicious user could use it to init other smart cards.
Consequently to the FORMAT command a Master File is created on the smart card. Since then you could create and populate all Elementary Files and Dedicated Files needed to build-up your application.
File System Creation
Once formatted, the smart card is ready to use, but it is empty. So you must create all suitable data structures to store all information needed. As an example, one would build a file system as depicted in Figure 3.2. First, you create the user PIN with id 01 and the PIN administrator, usually said PUK, with an id 02. Second, you create two Security Data Objects with id 01 and 02 (representing PIN and PUK, respectively), assigning them the values 12345 and 12345678, using the PUT_DATA command (mode 01):
Command APDU: (PUT DATA) - Creates the PIN -
- CLA=00, INS=DA, P1=00, P2=10, LC=0D, LE=00
- DATA=010003FF000200053132333435
= .../.ÿ... ... .1.2.3.4.5.
Response APDU:
- SW1=90, SW2=00
The value of the DATA field assumes the following meaning:
• 01 Security Environment Object id;
• 00 reserved for future extensions;
• 03 max number of wrong attempts;
• FF Access Condition Change always granted, in that PIN could be changed using a CHANGE REFERENCE DATA ADPU;
• 00 Access Condition Write always denied, in that it’s impossible directly overwrite the Security Environment Object value;
• 02 Access Condition Unblock related to the checking of the Security Environment Object with id 02 (PUK), in that you could unblock the PIN (using the RESET RETRY COUNTER ADPU) only after the PUK checking;.
• 0005 length of the value being assigned to the object (5 ASCII chars);
• 313233343536 ASCII encoding of the value “12345” (PIN);
Command APDU: (PUT DATA) - Creates the PUK -
- CLA=00, INS=DA, P1=00, P2=10, LC=10, LE=00
- DATA=02000AFF000200083132333435363738
=....ÿ... ... .1.2.3.4.5.6.7.8.
Response APDU:
- SW1=90, SW2=00
Then you create a Dedicated File 3100 and two Elementary Files (3131 and 3132) inside it using the command CREATE FILE:
Command APDU: (CREATE FILE)
- CLA=00, INS=E0, P1=00, P2=00, LC=0A, LE=00
- DATA=00310000FFFF00000000
=..1.0...ÿ.ÿ.........
Response APDU:
- SW1=90, SW2=00
With reference to the DATA field of the previous APDU, bytes assume the following meaning:
• 00 indicates a DATA field in a proprietary format not compliant with ISO 7816 standard;
• 3100 file’s ID being created;
• 00 file type; 00 indicates a Dedicated File;
• FF Access Condition Create always granted;
• FF Access Condition Write always granted. Always you could create a file under the Dedicated File;
• 00 Access Condition Delete always denied, in that you could not delete the Dedicated File
• 00 Access Condition Activate always denied, in that you are not able to disable the Dedicated File;
• 0000 for a Dedicated File always must be 00.
The following APDUs create Elementary Files 3131 and 3132 both of binary type (01) and with a size of 1024 bytes (0400)
Command APDU: (CREATE FILE)
- CLA=00, INS=E0, P1=00, P2=00, LC=0A, LE=00
- DATA=00313101010100000400
=..1.1. . . ..... ...
Response APDU:
- SW1=90, SW2=00
Command APDU: (CREATE FILE)
- CLA=00, INS=E0, P1=00, P2=00, LC=0A, LE=00
- DATA=00313201010100000400
=..1.2. . . ..... ...
Response APDU:
- SW1=90, SW2=00
Creating the remaining Dedicated Files and Elementary Files as depicted in Figure 3.2 is up to you, as an exercise. Though, the completion of the file system shown in Figure 3.2 requires a couple of cryptographic keys denoted by the id 10. First, you select which current Dedicated File contains the Master File where the couple of keys are to be created:
Command APDU: (SELECT)
- CLA=00, INS=A4, P1=00, P2=00, LC=00, LE=00
- DATA=
=
Response APDU:
- SW1=90, SW2=00
- DATA=3F0000FFFFFFFF
=?.....ÿ.ÿ.ÿ.ÿ.
Then, the GENERATE KEY PAIR ADPU, as shown below, creates a couple of keys putting the private part in the Security Data Object denoted by the id 10 and the public part in the binary EF 1010. Also, it relates access conditions for using the key to the user PIN 01:
Command APDU: (GENERATE KEY PAIR)
- CLA=00, INS=46, P1=00, P2=00, LC=0A, LE=00
- DATA=101010800100
= . . .€. ...
Response APDU:
- SW1=90, SW2=00
For a better understanding of the DATA field’s meaning you could refer to GENERATE KEY PAIR command in Appendix A.
Populating the Smart Card
Once created the smart card’s file system, you can populate Elementary Files with data. For example, writing on file 3100 with owner’s personal data you must first select the file using the SELECT command, then check the PIN using the VERIFY command to get the needed access permissions and finally write the contents on the binary EF using the UPDATE BINARY command:
Command APDU: (SELECT)
- CLA=00, INS=A4, P1=00, P2=00, LC=04, LE=00
- DATA=31003131
=1...1.1.
Response APDU:
- SW1=90, SW2=00
- DATA=3F00310031310101010000
=1...1.1.?...1...1.1. . . .....
Command APDU: (VERIFY)
- CLA=00, INS=20, P1=00, P2=01, LC=05, LE=00
- DATA=3132333435
=1.2.3.4.5.
Response APDU:
- SW1=90, SW2=00
Command APDU: (UPDATE BINARY)
- CLA=00, INS=D6, P1=00, P2=00, LC=0S, LE=00
- DATA=4D6172696F20526F7373692000
=M.a.r.i.o. .R.o.s.s.i. ...
Response APDU:
- SW1=90, SW2=00