SCP03 provisioning and secure-channel architecture for secure elements.
SCP03 is the AES-based GlobalPlatform secure channel that protects applet loading, key injection and key rotation on a secure element. This guide is about provisioning: personalisation lines, issuer security-domain key sets, key rotation and the boundary between factory, OEM firmware and back end. It covers the key hierarchy, session establishment, security levels and the provisioning lifecycle at architecture level. It contains no keys, no diversification data and no proprietary commands.
What is SCP03?
SCP03 (Secure Channel Protocol ‘03’) is defined in GlobalPlatform Card Specification Amendment D. It gives an off-card entity — a personalisation station, a card-management back end, a loader tool — and a security domain on the card two things: mutual authentication from a shared set of static AES keys, and secure messaging for the commands that follow, with integrity, optional confidentiality and protection against replay and reordering.
It replaces SCP02, which is built on Triple DES, for new deployments. The protocol shape is similar; the cryptography is AES with AES-CMAC, and session keys come from a standard key-derivation function rather than a bespoke one.
1. Why a secure channel is needed
The commands that manage a secure element are the most sensitive it will ever receive: load this code, install this applet, replace these keys, write this identity. They travel through infrastructure nobody should have to trust — a station PC, a reader, a network relay, a host MCU’s bus.
SCP03 removes that infrastructure from the security argument. A relay can see and forward the traffic but cannot authenticate to the card, forge or reorder a command, or, at the higher security levels, read the data. Only the two endpoints that hold the static keys can run the channel.
2. The key hierarchy
SCP03 works with two tiers of keys. The static tier is long-lived and provisioned; the session tier exists for one channel and is then discarded.
| Static key set | Each security domain holds one or more key sets. A set is three AES keys of the same length (128, 192 or 256 bits): K-ENC and K-MAC, from which session keys are derived, and K-DEK, which protects key material sent to the card. A key version number (KVN) identifies the set, so a card can hold an old and a new set during rotation. |
|---|---|
| Per-card keys | Issuers normally diversify each card’s static keys from a master key held in an HSM, so one extracted card key does not open any other card. The diversification method and its inputs are issuer-specific and are not described here. |
| Session keys | S-ENC (command encryption), S-MAC (command MAC) and S-RMAC (response MAC) are derived fresh for every channel from K-ENC and K-MAC and both parties’ challenges. |
| Derivation function | The key-derivation function of NIST SP 800-108 in counter mode, with AES-CMAC as the pseudo-random function. Its input binds a derivation constant (a different one per session key and per cryptogram), the output length, and the context — the host challenge followed by the card challenge. Different constant, different key; different challenges, different session. |
The SCP03 helper reproduces this derivation in the browser with test values, so the session keys and cryptograms can be followed byte by byte.
3. How is an SCP03 session established?
Two commands open the channel. Both sides prove possession of the static keys without either key crossing the link.
- INITIALIZE UPDATE carries the key version to use and a random host challenge. The card answers with its key diversification data, key information (key version, protocol ‘03’ and its implementation options), a card challenge and a card cryptogram. Depending on those options the card challenge may be pseudo-random, driven by a sequence counter.
- Both sides derive the session keys from the static keys and the two challenges. The off-card entity recomputes the card cryptogram; a match proves the card holds the same static keys.
- EXTERNAL AUTHENTICATE carries the host cryptogram and the security level the host wants for the rest of the session, and is itself protected by a C-MAC. A match on the card proves the host holds the keys, and the session is open.
The SCP03 session walkthrough annotates the same exchange step by step.
4. Security levels and secure messaging
The security level is chosen in EXTERNAL AUTHENTICATE. Response protection is only available where the card’s implementation options say it is supported.
| C-MAC | Every command carries an 8-byte MAC computed with S-MAC over the command and a chaining value carried from the previous command. Commands cannot be altered, replayed or reordered. Data is visible. |
|---|---|
| C-DECRYPTION + C-MAC | Command data is also encrypted with S-ENC in AES-CBC, using an initial vector derived from a per-command counter. The minimum for anything carrying secrets. |
| + R-MAC | Responses carry a MAC under S-RMAC, so the host knows the answer came from the card unaltered. |
| + R-ENCRYPTION | Response data is encrypted as well. Requires C-DECRYPTION and R-MAC. |
Separately from session encryption, key values sent to the card — in PUT KEY or in personalisation data — are encrypted under the static K-DEK, so even a session compromise does not expose them in clear. Because MACs are chained, an error that aborts the session ends it: the host opens a new channel rather than trying to resume. The CMAC length reference covers MAC truncation and padding.
5. The provisioning lifecycle
SCP03 is the tool; provisioning is the process it protects. A typical sequence, from the chip vendor to the field:
Initial keys
The chip ships with an initial ISD key set, delivered to the issuer under the vendor’s own key-exchange process. These keys are transport keys, not production keys.
Key replacement
The first SCP03 session replaces the initial set with the issuer’s diversified keys (PUT KEY, a new key version), generated and wrapped inside an HSM.
Load and personalise
Load files are loaded, applets installed and made selectable, keys and identity written, then the card is set to its field lifecycle state.
Rotate and update
Key rotation and applet updates go back through SCP03 from an authorised back end, under a new key version, with the old set removed afterwards.
Where an OEM or application provider needs its own control, GlobalPlatform supplementary security domains let it hold separate keys and run its own SCP03 channel, under delegated or authorised management, without receiving the issuer’s keys. Draw the boundary explicitly:
| Factory / personalisation line | Opens SCP03 to the ISD with HSM-held keys. Loads applets, injects or generates keys, writes certificates, sets lifecycle. Keeps an auditable per-card record. |
|---|---|
| OEM product firmware | Talks to the provisioned applet. Holds no ISD keys and no SCP03 static keys; it cannot reopen the management channel. Where field updates are routed through the device, the firmware relays the back end’s SCP03 traffic to the secure element without being able to read or forge it. |
| Back-end card management | The only party that can run SCP03 after shipment, from HSM-backed keys, for rotation and updates. |
The same protocol also protects remote management of eSIM and eUICC profiles, where the channel runs over the air rather than on a personalisation line; that case is covered in what an SCP03-protected OTA channel does and does not protect.
How the provisioned chip is then used by a device’s microcontroller is covered in integrating a secure element with a host MCU.
6. Test keys, and what must never ship
Development and sample cards commonly carry well-known GlobalPlatform test key sets, and their values are widely published. That makes them useful on a bench and worthless as security. A card still on a test key set has no secure channel in any meaningful sense.
- Replace test and initial key sets before a card leaves the lab or the line, and verify the replacement by reading back the key information.
- Never paste a production key into a web page, including ours. The SCP03 tools on this site are for test values only.
- Keep static keys and session keys out of logs, crash dumps and support bundles. Log key versions and outcomes, not key material.
- Keep SCP03 wrapping inside the HSM rather than reimplementing it in station software that sees clear keys.
7. Common SCP03 integration failures
| Card cryptogram does not match | Wrong key version, wrong diversification, wrong key length, or the challenges concatenated in the wrong order. Check the key information the card returned before suspecting the KDF. |
|---|---|
| EXTERNAL AUTHENTICATE rejected | Host cryptogram computed with the wrong derivation constant, or the C-MAC on the command itself is wrong. Repeated failures can lock the security domain; stop after the first. |
| Second command fails after a good first one | The MAC chaining value or the encryption counter was not carried forward. |
| Response MAC errors | R-MAC requested where the card’s options do not support it, or verified with S-MAC instead of S-RMAC. |
8. Where AmbiSecure fits
- Java Card applet development delivers a signed CAP file ready for SCP03 load by a customer’s personalisation line or by our loader.
- Multi-Card Applet Loader loads CAP files across multiple readers over GlobalPlatform 2.3.1 with Amendment D SCP03, with HSM-backed issuer master keys, per-card derivation and key-version tracking.
- Smart-card personalisation runs applet load, register, personalise and lock under SCP03, with diversification inside the HSM.
Standards referenced
- GlobalPlatform Card Specification Amendment D — Secure Channel Protocol ‘03’
- GlobalPlatform Card Specification 2.3.1 — security domains, lifecycle, PUT KEY.
- NIST SP 800-108 — key derivation using pseudorandom functions.
- RFC 4493 — the AES-CMAC algorithm.
- GlobalPlatform reference on this site.
Frequently asked questions
What is SCP03 used for?
SCP03 protects the commands that manage a secure element: loading and installing applets, writing keys and identity data, and rotating keys. It authenticates the off-card entity and the card to each other and then protects every command that follows.
What is the difference between SCP02 and SCP03?
SCP02 is built on Triple DES. SCP03, defined in GlobalPlatform Amendment D, uses AES keys, AES-CMAC and the NIST SP 800-108 key-derivation function, and adds optional response encryption. New deployments use SCP03.
Which keys does SCP03 use?
A static key set of K-ENC, K-MAC and K-DEK, identified by a key version number, and three session keys derived for each channel: S-ENC, S-MAC and S-RMAC. K-DEK protects key values sent to the card.
Does a device's host MCU need the SCP03 keys?
Normally not. The SCP03 static keys belong to the personalisation line and the back-end card-management service, held in HSMs. Product firmware talks to the provisioned applet and cannot reopen the management channel.
Planning an SCP03 provisioning flow?
Tell us the chip, the applets, the key custody model and who needs control after shipment. We will map the security domains and the line.