Smart cards. Part 2. APDU
Hi, Giktayms!
After the general information described in the first part , today we will talk about APDUs in the format described in the ISO7816-4 standard.
APDU (application protocol data unit) is a format for communication between a card and a terminal. The terminal sends a Command APDU (C-APDU), and the card responds with a Response APDU (R-APDU).
')
The C-APDU format is:
Each element of the header is stored on one byte and is required. Back to the title later, now let's talk about the body command.
Body elements are as follows:
Lc and Le, if present, can occupy 1 (Short Length) or 3 bytes (Extended Length) each. With Short Length, values from 1 to 256 are encoded. The data length of 256 bytes is recorded as “00”. With Extended Length, values from 1 to 65536 are encoded. The first byte is always “00” and the remaining 2 bytes are a number in Big Endian format. When Lc or Le is “00 00 00”, then the data length is 65536 bytes.
Depending on the presence or absence of the command body elements can be divided into 4 categories:
I will show examples of commands later. Now back to the header.
Since my series of articles is aimed at reviewing in detail the Global Platform, I will describe the value of CLA in the context of the Global Platform.
CLA byte with a logical channel from 0 to 3
CLA byte with logical channel from 4 to 19
b7 determines if the CLA format is as in the first or as in the second table. When a logical channel is in the range from 0 to 3, its value is recorded in bits 1 and 2. Otherwise, the number written in bits 1-4 encodes the number from 4 to 19 (0 = 4, 1 = 5, ..., 15 = 19).
b5 in ISO7816-4 stands for Command Chaining. Not used in the Global Platform.
The format of the R-APDU is:
Body is present in the successful execution (with or without comments) of commands from the category Case 2 and Case 4. Its content depends on the specific command. Trailer is always there and contains the so-called Status Word, that is, a result code, positive or negative. The status can be one of the following:
Errors from the 69XX and 6AXX series are often used in the Global Platform and will be described in detail in parts of the Global Platform article.
The statuses from the 61XX and 6CXX series require special attention. The 61XX code is possible when the card executed a command from the category Case 2 or Case 4 and sent an incomplete answer. In this case, SW2 encodes the length of the remainder of the response (“00” = 256). In response, the terminal may send a GET RESPONSE command in order to receive the remaining data. This procedure can be repeated several times, until the card sends a full response. This Status Word is the status contained in the last response to the GET RESPONSE command. This situation occurs mainly when the APDU is transmitted through the ISO7816-3 T = 0 protocol due to the peculiarity of the transfer of commands from the Case 4 category (we will talk about this later). The 6CXX code occurs when the specified Le does not match the actual length of the response. It should be noted that in this case, the card does not send any data to the R-APDU, but requires the terminal to repeat the command with Le equal to the number encoded in SW2.
The T = 0 protocol is very common, as it is used in SIMs. Its feature is that the header always consists of 5 bytes: CLA, INS, P1, P2, P3. P3 can be used to encode Lc or Le. It turns out that it will be superfluous for Case 1 teams, suitable for Case 2 and Case 3 teams, but not sufficient for Case 4 commands, where both Lc and Le are needed. How can this problem be solved?
In the following way. Case 4 commands are transmitted with P3 = Lc, as if it were a Case 3 command. Then the map, if the command was successfully executed, responds with no data, but with the status 61XX. In turn, the terminal sends a GET RESPONSE command (from the Case 2 category), and then the card sends the real answer.
GET RESPONSE
Finally, we come to the most interesting part of the article - examples.
GET DATA (Card Production Life Cycle)
Team GET DATA (Case 2) reads information from the card. Which one is determined by the parameters P1 and P2. The answer is in BER-TLV format (subject of the next part of the article). Here we see how at the beginning the team was sent with the wrong Le and the map, in turn, responded with the status of 6C 2D. After repeating the command with Le = 2D, the card sent the answer and the final status of 9000, indicating successful execution.
GET STATUS via T = 1
The GET STATUS (Case 4) command provides information on the life cycle of the map and applications. In this example, Lc = 8, Data = 4F 06 31 32 33 34 35 36 and Le = 9. At this stage I will not delve into explaining the meaning of this data, since this is not so important. The card responds by sending data 06 31 32 33 34 35 36 07 00 and status 9000. Below, we will see exactly the same command, only sent via the T = 0 protocol.
GET STATUS via T = 0
Here we see that GET STATUS is sent without Le. The protocol does not allow us this, since Lc is specified in P3. In response, the map will tell us the length of the data we need to receive. Then we send the GET RESPONSE command with Le = 9. After that, the map finally sends us the corresponding response.
So we come to the end of this part. If someone has questions, you can write them in the comments. The next part of the article will be about BER-TLV, since this data encoding format is used for almost everything related to smart cards.
Part 1. Principles of work
Part 3. TLV
After the general information described in the first part , today we will talk about APDUs in the format described in the ISO7816-4 standard.
APDU (application protocol data unit) is a format for communication between a card and a terminal. The terminal sends a Command APDU (C-APDU), and the card responds with a Response APDU (R-APDU).
')
C-APDU
The C-APDU format is:
| Header | Body |
|---|---|
| CLA INS P1 P2 | [Lc field] [Data field] [Le field] |
Each element of the header is stored on one byte and is required. Back to the title later, now let's talk about the body command.
Body elements are as follows:
- Lc : Data element length in bytes.
- Data : data commands.
- Le : The expected length of the response data in bytes, excluding the length of the Status Word.
Lc and Le, if present, can occupy 1 (Short Length) or 3 bytes (Extended Length) each. With Short Length, values from 1 to 256 are encoded. The data length of 256 bytes is recorded as “00”. With Extended Length, values from 1 to 65536 are encoded. The first byte is always “00” and the remaining 2 bytes are a number in Big Endian format. When Lc or Le is “00 00 00”, then the data length is 65536 bytes.
Depending on the presence or absence of the command body elements can be divided into 4 categories:
- Case 1 : Body is completely missing, that is, the command does not contain any data and no data is expected from the card when it is answered.
- Case 2 : Only Le is present in the body, that is, the command does not contain any data, but it is expected to receive data from the map.
- Case 3 : The body contains Lc and Data, that is, the command contains data, but no data is expected from the map.
- Case 4 : In the body there are all the elements, which means the team contains the data and is expected to receive data from the map.
I will show examples of commands later. Now back to the header.
| Element | Value |
|---|---|
| CLA | Class bytes . Contains command metadata (logical channel, secure messaging, etc.). |
| INS | Instruction bytes . Instruction code This is a hexadecimal number, the highest nibble of which cannot be 6 or 9. At the same time, the low nibble is always an even number. |
| P1 | The first parameter of the command . If it is not needed, then its value is “00”. |
| P2 | The second parameter is the command . If it is not needed, then its value is also “00”. |
Since my series of articles is aimed at reviewing in detail the Global Platform, I will describe the value of CLA in the context of the Global Platform.
CLA byte with a logical channel from 0 to 3
| b8 | b7 | b6 | b5 | b4 | b3 | b2 | b1 | Value |
|---|---|---|---|---|---|---|---|---|
| 0 | 0 | 0 | 0 | - | - | - | - | ISO7816-4 standard team |
| one | 0 | 0 | 0 | - | - | - | - | Global Platform Specification Team |
| - | 0 | 0 | 0 | 0 | 0 | - | - | No secure messaging |
| - | 0 | 0 | 0 | 0 | one | - | - | Secure Messaging on the Global Platform |
| - | 0 | 0 | 0 | one | 0 | - | - | Secure Messaging to ISO7816-4 without C-MAC |
| - | 0 | 0 | 0 | one | one | - | - | Secure Messaging ISO7816-4 with C-MAC |
| - | 0 | 0 | 0 | - | - | X | X | Logical channel |
CLA byte with logical channel from 4 to 19
| b8 | b7 | b6 | b5 | b4 | b3 | b2 | b1 | Value |
|---|---|---|---|---|---|---|---|---|
| 0 | one | - | 0 | - | - | - | - | ISO7816-4 standard team |
| one | one | - | 0 | - | - | - | - | Global Platform Specification Team |
| - | one | 0 | 0 | - | - | - | - | No secure messaging |
| - | one | one | 0 | - | - | - | - | Secure Messaging by Global Platform or ISO7816-4 |
| - | one | - | 0 | X | X | X | X | Logical channel |
b7 determines if the CLA format is as in the first or as in the second table. When a logical channel is in the range from 0 to 3, its value is recorded in bits 1 and 2. Otherwise, the number written in bits 1-4 encodes the number from 4 to 19 (0 = 4, 1 = 5, ..., 15 = 19).
b5 in ISO7816-4 stands for Command Chaining. Not used in the Global Platform.
R-APDU
The format of the R-APDU is:
| Body | Trailer |
|---|---|
| [Data field] | SW1 SW2 |
Body is present in the successful execution (with or without comments) of commands from the category Case 2 and Case 4. Its content depends on the specific command. Trailer is always there and contains the so-called Status Word, that is, a result code, positive or negative. The status can be one of the following:
| SW1SW2 | Value |
|---|---|
| Successful execution | |
| 9000 | OK. |
| 61XX | OK, but there are still XX data bytes. |
| The execution ended with comments. | |
| 62XX | SW2 clarifies the reasons for the remark. Permanent memory has not been changed. |
| 63XX | SW2 clarifies the reasons for the remark. Permanent memory has been changed. |
| Errors in command execution | |
| 6400 | The command was not executed. Permanent memory has not been changed. |
| 65XX | The command was not executed. The constant has been changed. |
| 66XX | The team was not executed for security reasons. |
| Command format errors | |
| 6700 | Incorrect command length. |
| 6881 | The card does not support the specified logical channel. |
| 6882 | The card does not support the specified type of secure messaging. |
| 69XX | Team not allowed. |
| 6AXX | Invalid command parameters. |
| 6B00 | Invalid command parameters. |
| 6CXX | Wrong Le. |
| 6D00 | Unknown ins. |
| 6E00 | Unknown CLA. |
| 6F00 | Error without description. |
Errors from the 69XX and 6AXX series are often used in the Global Platform and will be described in detail in parts of the Global Platform article.
The statuses from the 61XX and 6CXX series require special attention. The 61XX code is possible when the card executed a command from the category Case 2 or Case 4 and sent an incomplete answer. In this case, SW2 encodes the length of the remainder of the response (“00” = 256). In response, the terminal may send a GET RESPONSE command in order to receive the remaining data. This procedure can be repeated several times, until the card sends a full response. This Status Word is the status contained in the last response to the GET RESPONSE command. This situation occurs mainly when the APDU is transmitted through the ISO7816-3 T = 0 protocol due to the peculiarity of the transfer of commands from the Case 4 category (we will talk about this later). The 6CXX code occurs when the specified Le does not match the actual length of the response. It should be noted that in this case, the card does not send any data to the R-APDU, but requires the terminal to repeat the command with Le equal to the number encoded in SW2.
Features of the transfer of commands in the category Case 4 through the protocol T = 0
The T = 0 protocol is very common, as it is used in SIMs. Its feature is that the header always consists of 5 bytes: CLA, INS, P1, P2, P3. P3 can be used to encode Lc or Le. It turns out that it will be superfluous for Case 1 teams, suitable for Case 2 and Case 3 teams, but not sufficient for Case 4 commands, where both Lc and Le are needed. How can this problem be solved?
In the following way. Case 4 commands are transmitted with P3 = Lc, as if it were a Case 3 command. Then the map, if the command was successfully executed, responds with no data, but with the status 61XX. In turn, the terminal sends a GET RESPONSE command (from the Case 2 category), and then the card sends the real answer.
GET RESPONSE
| Element | Value |
|---|---|
| CLA | as the previous command, but without Secure Messaging and bit8 = 0 (although cards accept bit8 = 1) |
| INS | C0 |
| P1 | 00 |
| P2 | 00 |
| Lc | - |
| Data | - |
| Le | XX (usually SW2 of the previous answer) |
Examples of communication with the card
Finally, we come to the most interesting part of the article - examples.
GET DATA (Card Production Life Cycle)
C-APDU => 80 CA 9F 7F 00
R-APDU <= 6C 2D
C-APDU => 80 CA 9F 7F 2D
R-APDU <= 9F 7F 2A 47 90 50 40 47 91 81 02 31 00 83 58 00 11 68 91 45 81 48 12 83 65 00 00 00 01 2F 31 30 31 31 36 38 00 00 00 00 00 00 00 00 90 00
Team GET DATA (Case 2) reads information from the card. Which one is determined by the parameters P1 and P2. The answer is in BER-TLV format (subject of the next part of the article). Here we see how at the beginning the team was sent with the wrong Le and the map, in turn, responded with the status of 6C 2D. After repeating the command with Le = 2D, the card sent the answer and the final status of 9000, indicating successful execution.
GET STATUS via T = 1
C-APDU => 80 F2 40 00 08 4F 06 31 32 33 34 35 36 09
R-APDU <= 06 31 32 33 34 35 36 07 00 90 00
The GET STATUS (Case 4) command provides information on the life cycle of the map and applications. In this example, Lc = 8, Data = 4F 06 31 32 33 34 35 36 and Le = 9. At this stage I will not delve into explaining the meaning of this data, since this is not so important. The card responds by sending data 06 31 32 33 34 35 36 07 00 and status 9000. Below, we will see exactly the same command, only sent via the T = 0 protocol.
GET STATUS via T = 0
C-APDU => 80 F2 40 00 08 4F 06 31 32 33 34 35 36
R-APDU => 61 09
C-APDU => 00 C0 00 00 09
R-APDU <= 06 31 32 33 34 35 36 07 00 90 00
Here we see that GET STATUS is sent without Le. The protocol does not allow us this, since Lc is specified in P3. In response, the map will tell us the length of the data we need to receive. Then we send the GET RESPONSE command with Le = 9. After that, the map finally sends us the corresponding response.
So we come to the end of this part. If someone has questions, you can write them in the comments. The next part of the article will be about BER-TLV, since this data encoding format is used for almost everything related to smart cards.
The rest of the article
Part 1. Principles of work
Part 3. TLV
Source: https://habr.com/ru/post/367241/
All Articles