Secure-element provisioning over GlobalPlatform SCP02 and SCP03.
AmbiSecure engineers the host side of GlobalPlatform secure-channel provisioning: SCP03 over AES and SCP02 over 3DES, the APDU layer, key-custody boundaries and production-line integration. Ambimat has deployed GlobalPlatform secure-channel provisioning using SCP02/3DES and SCP03/AES with customer systems, including NXP P71D600 and Infineon secure elements. This anonymised case study describes that engineering pattern. A sanitised reference implementation is public on GitHub.
The requirement
A connected-product team has chosen a secure element. Every unit leaves the chip vendor with default issuer-security-domain keys. Between the factory and the field, three things must happen without any secret crossing an untrusted host in clear:
- the default keys are replaced with the product owner’s keys;
- applets are loaded, installed and personalised;
- the card lifecycle is locked.
It has to work on a production line, at volume, and the device must stay manageable after it ships.
Host ↔ secure element architecture
MCU or application processor
Talks to the secure element over ISO/IEC 7816, ISO/IEC 14443 or the vendor’s SPI/I²C transport, confirmed per project. Runs the APDU layer and the secure-channel wrapper.
Java Card / GlobalPlatform
The issuer security domain authenticates the host and enforces the secure-channel security level on every following command.
Owner’s HSM or KMS
Holds the master keys. The line and the host firmware never see static keys in clear; they receive wrapped, per-device material.
SCP02/3DES and SCP03/AES
Both protocols authenticate the host to the card’s security domain, then protect every following command with a MAC and, at higher security levels, encryption. They are different protocols, not one protocol with two ciphers.
| SCP02 (3DES) | SCP03 (AES) | |
|---|---|---|
| Where it is used | Legacy cards and installed fleets | Current secure elements |
| Session keys | 3DES-CBC over a constant and the card’s sequence counter | NIST SP 800-108 counter-mode KDF with AES-CMAC over both challenges |
| Cryptograms | Full 3DES CBC-MAC | 8-byte values from the same KDF |
| Command MAC | ISO/IEC 9797-1 retail MAC with a chained, optionally encrypted ICV | AES-CMAC with a 16-byte chaining value |
| Command encryption | 3DES-CBC | AES-CBC with ICV = AES(S-ENC, counter) |
The security level (C-MAC, C-DECRYPTION, R-MAC, R-ENCRYPTION) is chosen per step against the threat model: MAC-only for status reads, encryption wherever key or personalisation data crosses the link.
Key lifecycle and custody
- The chip vendor delivers default transport keys.
- Key replacement under a secure channel installs the owner’s key set as a new key version, wrapped with the data-encryption key.
- Optional per-device diversification derives each card’s keys inside the HSM, so one compromised card does not expose a fleet.
- Field rotation uses PUT KEY under the secure channel with the next key version.
- Retirement locks or terminates the security domain.
Provisioning flow at APDU level
1. SELECT the issuer security domain
2. INITIALIZE UPDATE (host challenge)
-> key information, card challenge, card cryptogram
3. Verify the card cryptogram; derive the session keys
4. EXTERNAL AUTHENTICATE (host cryptogram, security level)
5. INSTALL [for load] -> LOAD blocks -> INSTALL [for install and make selectable]
6. PUT KEY / STORE DATA for owner keys and personalisation, MACed and encrypted
7. SET STATUS to lock the lifecycle
Failure and recovery
- Interrupted LOAD. Delete the partial package and restart under a fresh session.
- Session lost during PUT KEY. Re-authenticate with the key version the card actually reports in INITIALIZE UPDATE. Never guess.
- MAC failure. Tear the session down. A response that fails R-MAC verification is discarded, never used.
- Counters. Watch the SCP02 sequence counter and authentication retry counters on the line; a locked security domain cannot be recovered.
- Logging. Record key versions, card serials and status words. Never write static, diversified or session key bytes to a log.
Migrating a fleet from SCP02 to SCP03
Installed fleets often mix legacy SCP02 cards with newer SCP03 parts. The host reads the SCP identifier and key version from the INITIALIZE UPDATE response and selects the protocol per card rather than per batch. Where the card platform supports SCP03, moving it from a 3DES key set to an AES key set needs a new key version and a cut-over plan for devices already in the field. The HSM keeps both key sets until the last legacy card is retired.
Testing and validation
- Known-answer tests for the KDF, cryptograms, MAC chaining and encryption ICVs.
- Negative tests: wrong card cryptogram, bad R-MAC, wrong key version.
- On-target integration on the customer’s secure element before line release.
The public reference library is software-verified: 39 tests on synthetic data, and it reproduces the 30 published GlobalPlatform values in osmocom pySim’s unit tests.
Platform experience
- NXP P71D600: GlobalPlatform secure-channel provisioning deployed with customer systems.
- Infineon secure elements: secure-channel provisioning deployed with customer systems.
No customer names, keys, proprietary commands or vendor-confidential configuration appear on this page or in the public repository.
What AmbiSecure delivers
- SCP03 / SCP02 provisioning architecture and key-custody design.
- Host-side secure-channel and APDU integration on your MCU or line PC.
- Applet load, install and personalisation scripts.
- Line integration, key-version register and field key-rotation runbook.
This work is delivered through AmbiSecure’s secure-element integration service. Applet work is covered by Java Card applet development.
Public reference implementation
ambisecure-gp-secure-channel is a small Python library for the host side of SCP03 (AES-128) and SCP02 (3DES), released under Apache-2.0. It uses only the public GlobalPlatform test key and synthetic challenges. It is not a key-management system.