SCP03 helper for GlobalPlatform
An educational companion to the SCP03 walkthrough: derive the S-ENC, S-MAC, and S-RMAC session keys plus the host and card cryptograms from static keys and challenges, using AES-CMAC and the SP 800-108 KDF entirely in your browser.
How to use this tool
What it does
Derives the SCP03 session keys (S-ENC, S-MAC, S-RMAC) and host/card cryptograms from static keys and challenges using AES-CMAC and the SP 800-108 KDF.
When to use it
Use it as a companion to the SCP03 walkthrough when learning how a GlobalPlatform secure channel authenticates.
Worked example
Enter static keys and the two challenges to watch the session keys and cryptograms fall out step by step.
Input
Derived values
What this tool does
SCP03 is GlobalPlatform's AES-based Secure Channel Protocol: the handshake a host (a card-management tool or backend) and a secure element run to agree on fresh session keys before exchanging confidential, integrity-protected APDUs. This helper reproduces the cryptographic core of that handshake so you can follow the maths with concrete numbers. Given the two static base keys and the two challenges, it computes the three session keys and both cryptograms exactly as GlobalPlatform Amendment D specifies.
Under the hood, every value is produced by a NIST SP 800-108 counter-mode key-derivation function whose pseudo-random function is AES-CMAC. Because the Web Crypto API ships AES but no CMAC, the tool implements RFC 4493 itself — generating the K1/K2 subkeys and the MAC on top of crypto.subtle AES-CBC with a zero IV. The CMAC implementation reproduces the published RFC 4493 AES-128 test vectors, so the building block underneath the KDF is verifiable rather than hand-waved.
When to use it
Reach for this when you are learning or debugging an SCP03 flow: checking why a card rejected your EXTERNAL AUTHENTICATE, confirming that your own KDF produces the same session keys as a reference, or teaching the difference between S-ENC, S-MAC, and S-RMAC. It pairs naturally with the step-by-step SCP03 walkthrough, which narrates the protocol exchange, while this page gives you the numbers. If you only need the MAC-length or padding rules, the CMAC length reference is lighter weight.
Inputs and outputs
The four inputs are all hexadecimal. K-ENC and K-MAC are the static base keys provisioned on the card; each is a 16-, 24-, or 32-byte AES key (AES-128/192/256) and both must be the same length. The host challenge and card challenge are each exactly 8 bytes — the host generates one, the card returns the other, and their concatenation (host || card) forms the KDF context.
Session keys
S-ENC (constant 0x04), S-MAC (0x06), and S-RMAC (0x07), each derived to the base-key length.
Cryptograms
Card cryptogram (0x00) and host cryptogram (0x01), each 8 bytes, derived under the freshly computed S-MAC.
Context
The 16-byte host || card challenge concatenation that ties every derivation to this one session.
Common mistakes
- Swapping the two cryptograms. The card returns the card cryptogram in INITIALIZE UPDATE; the host sends the host cryptogram in EXTERNAL AUTHENTICATE. They are derived with different constants (
0x00vs0x01) and are not interchangeable. - Reversing the challenge order. The context is
host || card, notcard || host. Reversing it changes every output. - Mismatched key lengths. SCP03 uses the same AES key length for K-ENC and K-MAC; mixing a 16-byte and a 24-byte key is not a valid configuration.
- Treating this as production crypto. There is no channel state, no command counter, and no key wrapping here. It is a calculator for the derivation, not a secure channel.
- Pasting real keys. Even though everything runs locally, a webpage is the wrong place for production key material — use throwaway test values.
Related tools
SCP03 walkthrough
Step-by-step narration of the SCP03 protocol exchange and APDUs.
Key diversification
How per-card keys are derived from a master key in a SAM.
Frequently asked questions
What does this SCP03 helper compute?
From a static S-ENC and S-MAC key plus an 8-byte host challenge and 8-byte card challenge, it derives the SCP03 session keys (S-ENC, S-MAC, S-RMAC) and the host and card cryptograms. The derivation uses AES-CMAC as the PRF inside the NIST SP 800-108 counter-mode key-derivation function, following GlobalPlatform Amendment D.
How is AES-CMAC implemented without a native CMAC primitive?
Web Crypto exposes AES but not CMAC, so the tool implements RFC 4493 itself on top of crypto.subtle. Single AES blocks are encrypted via AES-CBC with a zero IV, then the CMAC subkeys K1/K2 and the final MAC are computed in JavaScript. The implementation matches the published RFC 4493 test vectors for AES-128.
Is this safe to use with production keys?
No. This is an educational developer aid, not a certified GlobalPlatform secure-channel implementation. It does no key wrapping, channel-state tracking, or sequence-counter handling, and runs in a webpage. Use only pseudo-random or test keys; production SCP03 keys must stay inside an HSM or SAM.
Why must the host and card challenges be 8 bytes?
SCP03 fixes both challenges at 8 bytes (64 bits). The host challenge is sent in INITIALIZE UPDATE and the card challenge is returned by the card; their concatenation forms the KDF context used to derive every session key and cryptogram, so the tool rejects any other length.
Does anything I enter leave my browser?
No. All AES-CMAC and key derivation runs locally in JavaScript using the browser Web Crypto API. Nothing is uploaded or logged. Even so, treat any key you paste as compromised and use throwaway test values only.