Explain APDU secure messaging

[Papa Carder]

Overview of APDU and Secure Messaging​

APDU, or Application Protocol Data Unit, is the fundamental communication unit used between a smart card (or similar device like an NFC tag) and a reader or host system. It follows standards like ISO/IEC 7816-4, which defines the structure for commands sent from the reader to the card and responses sent back. An APDU consists of two main types:

• Command APDU (C-APDU): Sent from the reader to the card. It includes a header (CLA for class byte, INS for instruction, P1 and P2 for parameters) and optional data field, plus expected response length (Le).
• Response APDU (R-APDU): Sent from the card to the reader. It includes optional data and a status word (SW1-SW2, e.g., 0x9000 for success).

APDUs enable operations like reading data, authenticating, or updating files on the card. However, standard APDUs are transmitted in plain text, making them vulnerable to eavesdropping, replay attacks, or tampering in insecure environments.

Secure Messaging (SM) addresses these vulnerabilities by adding layers of security to APDU exchanges. It provides end-to-end protection through confidentiality (encryption), integrity (message authentication codes or MACs), and authentication (ensuring the sender's identity). SM is not a single protocol but a framework implemented in various standards, such as GlobalPlatform for Java Cards, ICAO 9303 for ePassports, or EMV for payment cards. It transforms plain APDUs into protected ones, often called "wrapped" or "secured" APDUs.

How Secure Messaging Works​

SM typically requires an initial secure channel setup, followed by securing each subsequent APDU. Here's a step-by-step breakdown:

1. Session Establishment (Mutual Authentication and Key Derivation):
   • Before secure APDUs can be exchanged, the card and reader must authenticate each other and derive session keys. This is often done using commands like INITIALIZE UPDATE and EXTERNAL AUTHENTICATE in GlobalPlatform's Secure Channel Protocol (SCP).
   • Process:
     • The reader sends an INITIALIZE UPDATE command with a host challenge (random data).
     • The card responds with its own card challenge and a cryptogram (MAC computed over combined challenges using a static key).
     • The reader verifies the card's cryptogram, computes its own (host cryptogram), and sends it via EXTERNAL AUTHENTICATE.
     • Upon success, both sides derive session keys for encryption (ENC) and MAC computation using the challenges and static keys (e.g., via 3DES or AES in SCP02/SCP03).
   • This establishes a secure session with keys that are unique per session, preventing replay attacks.
2. Securing Command APDUs (C-APDU Wrapping):
   • Once the session is active, plain C-APDUs are modified:
     • CLA Byte Modification: The class byte (CLA) is altered to indicate SM mode. For example, in ISO 7816, specific bits in CLA signal secure messaging (e.g., bit 3 for proprietary SM, or values like 0x0C for SM with MAC).
     • Data Protection:
       • If confidentiality is required, the data field is encrypted using the session ENC key (e.g., DES, 3DES, or AES).
       • A MAC is computed over the header and (encrypted) data using the session MAC key, then appended (typically 4-8 bytes).
     • Chaining: For large data (>255 bytes), commands can be chained, with CLA indicating continuation.
   • The secured C-APDU might look like: Header (modified CLA) + Encrypted Data + MAC + Le.
3. Securing Response APDUs (R-APDU Wrapping):
   • The card processes the command and secures the response similarly:
     • Data is encrypted if needed.
     • A MAC is computed over the response data and status word, then appended.
     • The reader verifies the MAC, decrypts the data, and checks the status word.
   • If verification fails (e.g., MAC mismatch), the session may terminate for security.
4. Security Levels:
   • SM can be configured for different protections:
     • No SM: Plain APDU.
     • MAC Only: Integrity and authentication (e.g., SCP01).
     • MAC + ENC: Full confidentiality, integrity, and authentication (common in SCP02/SCP03).
   • In ICAO 9303 (for Machine Readable Travel Documents like ePassports), SM follows a similar pattern but uses specific algorithms like Triple-DES for older versions or AES for Secure Messaging v3.

Examples of APDU with Secure Messaging​

• Plain SELECT FILE Command APDU (no SM): CLA=00, INS=A4, P1=04, P2=00, Lc=0E, Data=(file AID), Le=00.
• Secured Version (simplified, with MAC): CLA=0C (indicating SM), INS=A4, P1=04, P2=00, Lc=(length + MAC size), Data=(encrypted AID + MAC), Le=00.
• Status words in responses might indicate SM errors, like 0x6982 for "Security status not satisfied."

Applications and Standards​

• GlobalPlatform: Used in Java Cards for applet management; SM ensures secure loading/deletion of applets.
• ICAO 9303: For ePassports; SM protects biometric data reads.
• EMV: In contactless payments (e.g., via ISO 14443), SM secures transaction data.
• FIDO UAF: Maps authenticator commands to APDUs with SM for secure authentication.

Implementation Considerations​

• Libraries and Tools: In software, libraries like OpenSC handle SM transformations. For C#, implementations often follow ICAO or GlobalPlatform specs.
• Challenges: Key management is critical; static keys must be diversified per card. Session lifetimes can vary (e.g., per transaction or persistent).
• Transport Independence: SM works over contact (T=0/T=1) or contactless (ISO 14443) interfaces, as it's protocol-agnostic.

For deeper technical details, refer to ISO/IEC 7816-4 for APDU basics and GlobalPlatform specifications for SM protocols. If you're implementing this, ensure compliance with the specific card's secure channel protocol version.