GlobalPlatform SCP02 vs SCP03: Secure Channel Protocol Deep Dive
Contents
1. What Are SCP02 and SCP03?
GlobalPlatform defines secure channel protocols (SCP) for establishing encrypted, authenticated communication between a host and a security domain on a smart card. The two dominant versions are SCP02 (based on 3DES) and SCP03 (based on AES). They serve the same purpose — protecting APDU commands from eavesdropping and tampering — but differ fundamentally in cryptographic primitives, key derivation, and security guarantees.
If you're loading applets, personalizing payment cards, or managing eUICC profiles, you're using one of these protocols. Choosing between them affects your security posture, implementation complexity, and card compatibility.
2. SCP02: 3DES-CBC Key Derivation & Retail-MAC
Key Architecture
SCP02 uses three 16-byte static keys (each being a double-length 3DES key with 112-bit effective strength):
- K-ENC: Static encryption key → derives S-ENC (session encryption key)
- K-MAC: Static MAC key → derives S-MAC (session MAC key)
- K-DEK: Static data encryption key → derives S-DEK (session DEK)
Session Key Derivation
S-ENC = 3DES_CBC(K-ENC, derivation_data)
S-MAC = 3DES_CBC(K-MAC, derivation_data)
S-DEK = 3DES_CBC(K-DEK, derivation_data)
# Derivation data = constant(0182) + counter(2 bytes, big-endian) + padding(10 zero bytes)MAC Computation (Retail-MAC)
SCP02 uses Retail-MAC (aka ISO 9797-1 MAC Algorithm 3): 3DES-CBC encrypt all padded data blocks with an initial chaining vector, then take the last 8 bytes of ciphertext and perform a final 3DES encrypt to produce the 8-byte MAC.
3. SCP03: AES-CMAC KDF & Modern Security
Key Architecture
SCP03 uses three 16-byte AES-128 static keys:
- K-ENC → S-ENC via CMAC-KDF
- K-MAC → S-MAC via CMAC-KDF
- K-RMAC → S-RMAC (response MAC key) via CMAC-KDF
Session Key Derivation (CMAC-Based KDF)
# KDF per NIST SP 800-108 (Counter mode with CMAC)
KDF(static_key, counter, context):
input = counter(1 byte) || "SCP03"(5 bytes) || 0x00 || key_length(2 bytes, big-endian) || context(16 bytes)
return AES_CMAC(static_key, input)
S-ENC = KDF(K-ENC, 0x01, host_challenge || card_challenge)
S-MAC = KDF(K-MAC, 0x02, host_challenge || card_challenge)
S-RMAC = KDF(K-RMAC, 0x03, host_challenge || card_challenge)MAC Computation (AES-CMAC)
SCP03 uses AES-CMAC (RFC 4493): a block-cipher-based MAC that produces a full 16-byte authentication tag. Significantly stronger than SCP02's 8-byte Retail-MAC.
4. Side-by-Side Comparison
| Aspect | SCP02 | SCP03 |
|---|---|---|
| Cipher primitive | 3DES (double-length, 112-bit effective) | AES-128 |
| Key derivation | 3DES-CBC with fixed derivation constant | AES-CMAC KDF (NIST SP 800-108, counter mode) |
| MAC algorithm | Retail-MAC (ISO 9797-1 Alg. 3) | AES-CMAC (RFC 4493) |
| MAC length | 8 bytes | 16 bytes (full block) |
| Session key types | S-ENC, S-MAC, S-DEK | S-ENC, S-MAC, S-RMAC |
| KDF diversity | Single constant (0182) + counter | Label ("SCP03") + context + counter |
| Challenge size | 8 bytes (host) | 8 bytes (host) + 8 bytes (card) |
| PFS (Perfect Forward Secrecy) | No | No (static keys still needed) |
| Standard | GP 2.1.1+ | GP 2.2+ (Amendment D+) |
| Card support | Nearly universal | Modern cards (2015+) |
| Security level | Moderate (112-bit) | Strong (128-bit, quantum-resistant: no Grover speedup on AES like on 3DES) |
| Implementation | Medium complexity | Slightly higher (CMAC KDF) |
5. Migration Guide: SCP02 to SCP03
Migration Checklist
- Verify card support: Check the card's CPLC (Card Product Life Cycle) data or ATR historical bytes for SCP03 capability indicators.
- Rotate keys: SCP03 uses AES-128 keys, not 3DES. Generate new 16-byte AES keys — do not reuse SCP02 3DES keys even if they are also 16 bytes.
- Update key derivation: Replace 3DES-CBC derivation with CMAC-KDF. The derivation constant is replaced by the label "SCP03" and a 16-byte context.
- Update MAC verification: Switch from 8-byte Retail-MAC to 16-byte AES-CMAC. Update all MAC verification code (both host-side and server-side).
- Dual support: During transition, support both SCP02 and SCP03. Use ATR information to determine which protocol the card supports.
- Test thoroughly: MAC mismatches are the #1 migration bug. The CMAC subkey generation (K1/K2) must be implemented correctly.
6. Implementation Details & Pitfalls
SCP02 Common Mistakes
- Using the wrong derivation constant (should be
01 82, not01 82 00 ...) - ICV (Initial Chaining Vector) incorrectly initialized — must be all zeros
- Padding: ISO 9797-1 Method 2 (80 00 00...), not PKCS#7
SCP03 Common Mistakes
- CMAC subkey generation: K1 requires GF(2^128) multiplication by x (left shift + conditional XOR with 0x87)
- Counter byte value: S-ENC uses 0x01, S-MAC uses 0x02, S-RMAC uses 0x03
- KDF input must include separator byte (0x00) and key length (0x00 0x10 for AES-128)
7. Interactive Tools
- GP Session Key Calculator — Derive S-ENC/S-MAC/S-DEK/S-RMAC and compute MACs
- ATR Decoder — Check if a card supports SCP03 from its ATR
- ISO 7816 Complete Guide — Understand the underlying APDU transport