GlobalPlatform Card Management

GlobalPlatform Card Management

GlobalPlatform is the industry consortium whose specifications define how applets are loaded, installed, managed, and deleted on multi-application smart cards throughout their lifecycle. Where ISO 7816 defines the chip-level protocol, GlobalPlatformGlobalPlatformSoftwareCard application management standard.Click to view → defines the application management layer on top.

Use the APDU Builder to construct GlobalPlatform STORE DATA, INSTALL, LOAD, and DELETE commands for testing.

Card Manager and Issuer Security Domain

Every GlobalPlatform card contains a Card Manager — the privileged runtime responsible for enforcing the card's security policy. The Card Manager is accessed through the Issuer Security Domain (ISD), the pre-loaded root security domain that holds the card issuer's keys and authorises all subsequent management operations.

The ISD is the only entity that can create or delete other security domains. Applets loaded outside the issuer's own SSD must be sponsored by a delegated SSD whose keys are controlled by the applet provider.

Security Channels: SCP03 and Predecessors

All GlobalPlatform management APDUs travel over a Secure Channel Protocol (SCP) session. SCP01 and SCP02 use 3DES3DESCryptographyLegacy triple-DES symmetric cipher in payment smart cards.Click to view →; SCP03 — the current mandatory baseline for new deployments — uses AESAESCryptographyNIST symmetric block cipher for smart card encryption.Click to view →-128 or AES-256.

An SCP03 session begins with INITIALIZE UPDATE (card returns a challenge and card-unique key diversificationkey diversificationSecurityDeriving unique per-card keys from a master key.Click to view → data), followed by EXTERNAL AUTHENTICATE (host proves possession of the static AES base key by computing the host cryptogram). All subsequent APDUs are C-MAC protected; optionally C-ENC and R-MAC as well.

The base keys are derived from a Global Key stored in the HSM at the card management backend, diversified per card using the card's serial number or APDU-derived data.

Applet Lifecycle

GlobalPlatform models each managed object as a state machine:

[Not present] → LOADED → INSTALLED → SELECTABLE → PERSONALIZED
                                                         ↓
                                                     BLOCKED → TERMINATED

The card-level lifecycle also moves through INITIALIZED → SECURED → CARD_LOCKED → TERMINATED states, driven by Card Manager commands from the ISD.

AID Namespace and Applet Selection

Each applet is registered under a unique AID derived from the loading security domain's RID. The SELECT AID APDU command (INS = A4, P1 = 04) activates the matching applet; the card OS routes subsequent APDUs to the selected applet's process() method until a new SELECT or card reset occurs.

Conflicts are prevented by GlobalPlatform's requirement that an SSD can only install applets under AIDs that share its own RIDRIDProtocolFirst 5 bytes of AID identifying provider.Click to view → prefix, unless the Controlling Authority grants an exception via a signed token.

Secure Element and TEE Interaction

On devices with a TEE (Trusted Execution Environment), GlobalPlatform also specifies the TEETEESecurityIsolated secure execution environment.Click to view → Management Framework (TMF) — a parallel structure for managing trusted applications inside the TEE. The same security domain hierarchy and lifecycle concepts apply, though the transport is TEE-internal rather than APDU. Combined SE+TEE deployments (common in payment-capable smartphones) must maintain distinct ISD keys to prevent cross-boundary privilege escalation.

For the cryptographic key management operations that underpin SCP03 sessions, see Key Management for Smart Cards.