Send sequence counter
Using a send sequence counter mechanism for secure messaging does not by itself constitute a security mechanism. It only makes sense to use a send sequence counter in combination with the authentic mode or combined mode procedure, since otherwise any modification of the count by an attacker would remain undetected. The working principle of a send sequence counter is that each APDU contains a sequence number that depends on when it is sent. This allows the deletion or insertion of an APDU in the course of the procedure to be immediately noticed, so that appropriate measures (terminating the communications) can be taken by the recipient. This function is based on a counter that is initialized with a random number. This number is sent to the terminal by the card at the start of the communications process, in response to a request from the terminal. The counter is incremented each time an APDU is sent. The counter should not be too short, but it should also not be too long, in order to avoid generating excessive transmission overhead. The following description assumes the commonly used value of two bytes, but longer counters may be used in practice. There are two basic ways to incorporate a sequence count into command and response APDUs. The counter value can be placed directly in the APDU as a numerical value in a data object, or the counter value may be XOR-ed with a matching amount of data in the APDU, following which a cryptographic checksum is computed and the modified data are restored to the APDU. The recipient of this APDU knows the expected counter value, and can use this value to modify the APDU in the same way as the sender. After this it can compute the cryptographic checksum and check the correctness of the received APDU.

The following process takes place during communications. The terminal first requests an initial counter value from the smart card. The smart card returns a two-byte random number to the terminal. The terminal then sends the first secured command to the card, accompanied by a send sequence count. Either the authentic mode or combined mode procedure can be used to protect the counter and the body. The card receives the protected APDU and first checks whether there is any sign of manipulation, based on the authentic mode or combined mode procedure. It then compares the counter value to the expected value. If these values match, no APDU has been inserted or deleted during the transmission. It is apparent that using a send sequence counter is attractive not only when several commands have to be executed in a particular order, but also for individual commands, since each session is made unique if a counter is used. Using a counter primarily provides protection against ‘replaying’ previously sent APDUs and deleting APDUs. If a send sequence counter is used together with the combined mode procedure, each encrypted block is different, which creates a condition known as diversity. This is the result of incrementing the counter for each APDU and the fact that with a good encryption algorithm, changing a single bit in the plaintext affects the appearance of the entire ciphertext block.

In smart cards containing several independent applications, it is optionally possible to address these applications via logical channels. If logical channels are used, up to four applications in a single card can concurrently exchange data with the terminal. The existing single serial interface is still used, but the applications can be addressed individually at the logical level. Two bits in the class byte (bit 1 and bit 2) are used to determine which command belongs to which application.23 This permits up to four logical channels,24 so up to four sessions with applications in the card can run in parallel. However, there is a limitation with regard to communicating with the various applications in the smart card, which is that the external processes that access the card must be mutually synchronized and are not allowed to interleave their commands, since the response APDU from the card does not contain any information about the logical channel of the originating command. This means that it is impossible to externally determine which return code has been sent back in response to which command. Due to the absence of channel identification, no new command can be sent until the response to the previous command has been received. The primary application for this very powerful mechanism is using several applications in parallel. For example, suppose a cardholder is conducting a telephone conversation using the GSM application in a multiapplication smart card. In order to confirm an appointment with the other party, she needs to briefly consult her personal organizer, which is located in the same card. Using a second logical channel, the terminal searches for a file in the personal organizer application, in parallel with the GSM application, and then tells our highly stressed manager whether she can agree to the proposed date. This is a typical use of logical channels. Another conceivable example is securely transferring electronic funds between two electronic purses in the same card. The potential utility of logical channels for applications is matched by the difficulties that their management entails for the smart card operating system. In principle, each logical channel represents nothing less than a separate smart card, with all of its states and conditions. This effectively means that the operating system must concurrently manage all the data for several parallel sessions within its memory. The associated costs should not be underestimated, and in particular this requires microcontrollers with large amounts of RAM. If secure messaging and all possible types of authentication are also required for each logical channel, the amount of memory needed very quickly rises to a level that can only be met by the highest-performance types of currently available smart card microcontrollers.