GP Session Key Calculator (SCP02 / SCP03)
GlobalPlatform secure channel protocol Session Key derivation tool. Supports SCP02 (3DES-CBC key derivation + MAC calculation) and SCP03 (AES-CMAC KDF key derivation). Enter static keys and derivation data to obtain S-ENC, S-MAC, S-DEK, S-RMAC session keys. Essential for smart card security domain development and APDU secure messaging.
SCP02 Session Key Derivation
Derive session keys from static keys using 3DES-CBC.
SCP03 Session Key Derivation (AES-CMAC KDF)
Derive session keys from static keys using AES-128-CMAC KDF (NIST SP 800-108).
Secure Messaging MAC Calculator
Calculate APDU secure messaging MAC values. Supports SCP02 Retail-MAC and SCP03 AES-CMAC.
SCP02 vs SCP03
SCP02: Uses 3DES keys (16 bytes / 128-bit double-length), CBC mode session key derivation. Key types: S-ENC (encryption), S-MAC (message authentication), S-DEK (data encryption key). Derivation constant: 0182.
SCP03: Uses AES-128 keys (16 bytes), CMAC-based KDF session key derivation. Key types: S-ENC, S-MAC, S-RMAC (response MAC). KDF Label = "SCP03" (ASCII).
Security Notice
All computation is performed locally in your browser. Key data is never uploaded to any server. Always use in an isolated environment and clear inputs after use. Never enter production keys in a public network environment.
Understanding GlobalPlatform Secure Channel
GlobalPlatform (GP) is the industry standard for smart card application management. When a card issuer, issuer's agent, or service provider needs to communicate securely with a card's Security Domain, they establish a Secure Channel — a cryptographic session that encrypts and authenticates every APDU. The Secure Channel Protocol (SCP) defines how session keys are derived from static keys, how commands are encrypted, and how MAC values are computed to detect tampering.
SCP02: The 3DES Legacy
SCP02, defined in GlobalPlatform Card Specification v2.2, uses 3DES (Triple DES) for all cryptographic operations. Static keys (K-ENC, K-MAC, K-DEK) are 16-byte double-length 3DES keys. Session keys are derived by encrypting a derivation data block with the static key using 3DES-CBC. The derivation data consists of a 4-byte constant (e.g., 0182) followed by a 2-byte sequence counter, padded to 16 bytes. This produces three session keys: S-ENC (for encrypting command data), S-MAC (for computing command MACs), and S-DEK (for encrypting data keys). The ICV (Initial Chaining Vector) for MAC computation is derived from the previous command's MAC, creating a chained authentication chain.
SCP03: The AES Modern Standard
SCP03, defined in GlobalPlatform Card Specification v2.3 / Amendment A, replaces 3DES with AES-128. The key derivation follows NIST SP 800-108 — a counter-mode KDF using AES-CMAC. The KDF input consists of a counter byte (0x01 for S-ENC, 0x02 for S-MAC, 0x03 for S-RMAC), the label "SCP03" in ASCII, a separator byte (0x00), the output length (16 bits = 0x0010), and a 16-byte context (typically the host challenge concatenated with the card challenge). SCP03 introduces S-RMAC — a separate session key for response MACs, which SCP02 lacked, providing mutual authentication of both commands and responses. The MAC algorithm is AES-CMAC (RFC 4493), producing 16-byte authentication codes.
Session Key Derivation Comparison
SCP02 derives keys via 3DES-CBC encryption of a constant + sequence counter — a simple but cryptographically weaker approach. SCP03 uses a proper KDF with AES-CMAC, which is resistant to related-key attacks and provides stronger key separation. SCP03 also supports AES-256 keys (optional), though most deployments still use AES-128. If you are building a new card personalization system or an OTA (Over-the-Air) provisioning service, SCP03 is the recommended protocol. SCP02 should only be used for backwards compatibility with older cards that do not support AES.
The INITIALIZIZE UPDATE / EXTERNAL AUTHENTICATE Flow
The secure channel is established in two APDUs. First, the host sends INITIALIZE UPDATE (INS=50), providing a host challenge (8 random bytes for SCP02, 8 for SCP03). The card responds with key information, the sequence counter, card challenge (8 bytes), and a card cryptogram. The host verifies the card cryptogram (proving the card possesses the correct static keys), derives the session keys, computes the host cryptogram, and sends EXTERNAL AUTHENTICATE (INS=82) with the host cryptogram as MAC. If the card verifies successfully, the secure channel is open. All subsequent commands are encrypted (data field) and MACed.
Practical Use Cases
Card personalization — During card issuance, the personalization system loads applets, keys, and configuration data via SCP02/SCP03 secure messaging. OTA provisioning — Mobile network operators use SCP03 to remotely update SIM/eSIM applets over the air. Key injection — Payment card manufacturers inject payment keys into EMV cards using SCP for key confidentiality. Post-issuance updates — Banks update card parameters (limits, contactless configuration) via SCP without reissuing the card. This tool helps developers verify their session key derivation matches the card's implementation during integration testing.
Debugging Common Issues
The most common SCP02 error is a mismatched sequence counter — the card increments the counter after each successful INITIALIZE UPDATE, and the host must track it. If the host's counter desyncs, all subsequent MACs fail. In SCP03, a mismatched context (host challenge + card challenge) produces wrong session keys with no error message — the MAC simply fails to verify. Always log the exact bytes exchanged during INITIALIZE UPDATE response to trace key derivation issues. For production debugging, use the GP Shell or GPPro tools to verify the card's key set before using this calculator.