GlobalPlatform कार्ड प्रबंधन
{# Answer-first lead — frontend-gold-standard §1.1. Expects `lead` (plain text, already resolved by apps.content.leads). Rendered directly under the h1 so the self-contained answer is the first prose a reader, a SERP snippet, or an AI extractor meets. No curated-data gate: the view always supplies either curated content_summary or a computed fallback. #}Managing applets and security domains on smart cards. It covers GlobalPlatform Card Management, Card Manager and Issuer Security Domain, Security Channels: SCP03 and Predecessors, Applet Lifecycle, and AID Namespace and Applet Selection. The guide is part of the Standards & Protocols series and about 4 minutes of reading.
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, GlobalPlatform 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.
| Entity | Role |
|---|---|
| Card Manager | GP runtime, lifecycle state machine |
| Issuer Security Domain (ISD) | Root SD; holds issuer keys; authenticates all management sessions |
| Supplementary Security Domain (SSD) | Delegated SD; holds third-party keys for their applets |
| Authorised Management Domain | SSD with restricted install/load rights |
| Controlling Authority SD | SD that issues tokens allowing SSD delegation |
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 3DES; SCP03 — the current mandatory baseline for new deployments — uses AES-128 or AES-256.
| Protocol | Algorithm | Session keys | MAC coverage |
|---|---|---|---|
| SCP01 | 3DES-ECB | 2 × 3DES | Data + MAC |
| SCP02 | 3DES-CBC | 3 × 3DES | Data + MAC + DEK |
| SCP03 | AES-CBC / CMAC | 3 × AES | Full APDU; counter replay protection |
An SCP03 session begins with INITIALIZE UPDATE (card returns a challenge and card-unique key diversification 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
| State | Meaning |
|---|---|
| Loaded | CAP file contents written to card EEPROM/flash |
| Installed | Applet object instantiated, AID registered |
| Selectable | Applet can be SELECT-ed by the host |
| Personalized | Applet has received its personalisation data (keys, cardholder data) |
| Blocked | Applet temporarily disabled (e.g., PIN lockout) |
| Terminated | Applet permanently disabled; cannot be re-enabled |
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 RID 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 TEE 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.
(frontend-gold-standard §1.7): the answer text is in
the initial HTML and stays reachable with JavaScript disabled, so crawlers and
AI extractors read answer-shaped chunks without depending on Alpine. #}
Frequently Asked Questions
What does the Issuer Security Domain control?
The Issuer Security Domain is the pre-loaded root security domain holding the card issuer's keys, and it authorises every management session on the card. It is the only entity that can create or delete other security domains. Applets loaded outside the issuer's own domain must be sponsored by a delegated Supplementary Security Domain whose keys the applet provider controls.
How does an SCP03 session begin?
The host sends INITIALIZE UPDATE, and the card replies with a challenge and card-unique key diversification data. EXTERNAL AUTHENTICATE follows, in which the host proves possession of the static AES base key by computing the host cryptogram. Every subsequent APDU is then C-MAC protected, with C-ENC and R-MAC available as options.
Which states does an applet pass through?
GlobalPlatform models each managed object as a state machine running from Loaded, where the CAP file contents are written to card memory, through Installed, Selectable, and Personalized. Blocked disables an applet temporarily, as after a PIN lockout, while Terminated disables it permanently with no route back.
Can a security domain install an applet under any AID?
No. Each applet is registered under an AID derived from the RID of its loading security domain, and a Supplementary Security Domain may install only under AIDs sharing its own RID prefix. An exception requires a signed token from the Controlling Authority. This constraint is what prevents AID collisions between independent applet providers on one card.
Who are the smart card guides written for?
Our guides cover a range of experience levels. Getting Started guides introduce smart card fundamentals. Security guides address Common Criteria certification and key management. Programming guides target developers working with APDU commands, JavaCard applets, and GlobalPlatform card management.
Frequently Asked Questions
What does the Issuer Security Domain control?
The Issuer Security Domain is the pre-loaded root security domain holding the card issuer's keys, and it authorises every management session on the card. It is the only entity that can create or delete other security domains. Applets loaded outside the issuer's own domain must be sponsored by a delegated Supplementary Security Domain whose keys the applet provider controls.
How does an SCP03 session begin?
The host sends INITIALIZE UPDATE, and the card replies with a challenge and card-unique key diversification data. EXTERNAL AUTHENTICATE follows, in which the host proves possession of the static AES base key by computing the host cryptogram. Every subsequent APDU is then C-MAC protected, with C-ENC and R-MAC available as options.
Which states does an applet pass through?
GlobalPlatform models each managed object as a state machine running from Loaded, where the CAP file contents are written to card memory, through Installed, Selectable, and Personalized. Blocked disables an applet temporarily, as after a PIN lockout, while Terminated disables it permanently with no route back.
Can a security domain install an applet under any AID?
No. Each applet is registered under an AID derived from the RID of its loading security domain, and a Supplementary Security Domain may install only under AIDs sharing its own RID prefix. An exception requires a signed token from the Controlling Authority. This constraint is what prevents AID collisions between independent applet providers on one card.
Who are the smart card guides written for?
Our guides cover a range of experience levels. Getting Started guides introduce smart card fundamentals. Security guides address Common Criteria certification and key management. Programming guides target developers working with APDU commands, JavaCard applets, and GlobalPlatform card management.