What is SCP03 in GlobalPlatform?

SCP03 (Secure Channel Protocol 03) is GlobalPlatform's secure channel protocol based on AES-128 encryption. It wraps APDU commands and responses in encryption and MAC integrity, preventing eavesdropping and tampering during card management operations such as installing applets or updating keys.

What is the difference between SCP01, SCP02, and SCP03?

SCP01 uses DES/3DES with a simple key derivation. SCP02 uses 3DES with a more robust key derivation and is the most widely deployed legacy protocol. SCP03 uses AES-128 with CMAC for integrity and counter-based replay protection. SCP03 is the modern standard for new deployments.

Can I manage a Java Card without SCP03?

Yes, but only in development environments. You can send plaintext APDU commands to the card manager without establishing a secure channel. This is acceptable for testing but must never be used in production, as an attacker on the communication channel could intercept or modify management commands.

Disclosure: As an Amazon Associate, CardWise earns from qualifying purchases at no additional cost to you. This does not affect our recommendations.

GlobalPlatform APDU vs SCP03 — Plaintext vs Encrypted Card Management

When you manage a Java Card — installing applets, updating keys, deleting applications — you send APDU commands through the GlobalPlatform Card Manager. These commands can be sent in plaintext (raw APDUs that anyone on the communication channel can read) or wrapped in a secure channel (encrypted and authenticated). SCP03 (Secure Channel Protocol 03) is GlobalPlatform's modern AES-128-based secure channel that protects card management operations from eavesdropping and tampering.

This comparison covers APDU structure, key establishment, encryption, MAC integrity, replay protection, and when each approach is appropriate.

GlobalPlatform Management Commands

GlobalPlatform defines a set of APDU commands for card management:

Command	INS	Function
SELECT	A4	Select an application or security domain
INSTALL	E6	Install/load an applet or create a security domain
DELETE	E4	Delete an applet, package, or key
GET STATUS	F2	Query card contents (applets, keys, SDs)
PUT KEY	D8	Upload or update cryptographic keys
STORE DATA	E2	Send arbitrary data to an application or SD
GET DATA	CA	Retrieve card data (card recognition number, etc.)

In plaintext mode, these APDUs are sent as-is over the communication channel. Anyone with access to the reader-to-card communication can see the commands and responses — including key material during PUT KEY operations.

In SCP03 mode, these same commands are wrapped: the command data is encrypted with a session key, and a MAC (CMAC) is appended for integrity. The card decrypts, verifies the MAC, executes the command, and returns an encrypted response.

SCP03 Architecture

Key Establishment

Pre-shared keys (stored in card's Security Domain):
  K-ENC: AES-128 key for session key derivation
  K-MAC: AES-128 key for MAC computation
  K-DEK: AES-128 key for data encryption

Initialization:
  1. Terminal sends INITIALIZE UPDATE APDU
     - Contains host challenge (random 8 bytes)
  2. Card responds with:
     - Key diversification data
     - Key information (which key version)
     - Card challenge (random 8 bytes)
     - Card cryptogram (proof that card knows K-MAC)

  3. Terminal verifies card cryptogram
  4. Terminal computes session keys:
     S-ENC = AES-CBC(K-ENC, [challenge data])
     S-MAC = AES-CBC(K-MAC, [challenge data])
     S-DEK = AES-CBC(K-DEK, [challenge data])

  5. Terminal sends EXTERNAL AUTHENTICATE
     - Contains host cryptogram (proof that terminal knows K-MAC)
  6. Card verifies host cryptogram
  7. Secure channel established

Secure APDU Wrapping

Original APDU: 80 E6 00 00 2A [install data...]
                      |
                      v
SCP03 wrapping:
  1. MAC = AES-CMAC(S-MAC, [CLA|INS|P1|P2|80|Lc|data])
  2. Encrypted data = AES-CBC(S-ENC, [install data])
  3. Final APDU: 84 E6 00 00 [Lc'] [encrypted data + MAC]

Card processing:
  1. Verify MAC (integrity check)
  2. Decrypt data with S-ENC
  3. Execute original command
  4. Encrypt response with S-ENC
  5. MAC the response with S-MAC

Comparison: Plaintext APDU vs SCP03

Dimension	Plaintext APDU	SCP03 Secure Channel
Encryption	None — all data in the clear	AES-128 CBC encryption
Integrity	None — tampering undetected	AES-128 CMAC per APDU
Replay Protection	None	Counter-based (C-MAC sequence)
Key Exposure	PUT KEY sends new keys in plaintext	New keys encrypted with S-DEK
Authentication	None (no mutual auth)	Mutual (card + terminal prove key knowledge)
Overhead	Minimal (raw APDU)	+16 bytes MAC + encryption padding per APDU
Use Case	Development, testing, lab	Production, personalization, OTA management

Critical security note: In production, never send card management commands in plaintext. An attacker monitoring the reader-to-card communication (or a man-in-the-middle on a remote personalization link) can capture new keys during PUT KEY, install malicious applets during INSTALL, or extract card data during GET STATUS. SCP03 is mandatory for all production card management operations.

SCP Evolution: SCP01, SCP02, SCP03

Protocol	Crypto	Key Derivation	MAC	Replay Protection	Status
SCP01	DES/3DES	Simple	Retail MAC	Sequence counter	Deprecated
SCP02	3DES	Improved (with diversification)	3DES CBC-MAC	Sequence counter	Legacy (still common)
SCP03	AES-128	AES-CBC based	AES-CMAC	Counter + C-MAC	Current standard
SCP10	RSA/ECDH	Public key + symmetric	AES-CMAC	Counter	For mutual PKI auth

SCP03 replaced SCP02 because DES/3DES is deprecated in many security standards (NIST SP 800-131A requires AES for new systems). SCP03 also improved the key derivation and replay protection mechanisms.

SCP03 Key Types and Their Roles

Key	Role	Used For
K-ENC (Static Encryption Key)	Session key derivation	Deriving S-ENC for command/response encryption
K-MAC (Static MAC Key)	Session MAC derivation	Deriving S-MAC for APDU integrity
K-DEK (Static Data Encryption Key)	Data encryption	Encrypting sensitive data in commands (e.g., new keys in PUT KEY)

All three are AES-128 keys, typically diversified per card using the card's unique key set identifier and diversification data. The terminal must know the correct keys for the card's security domain to establish a secure channel.

ACR122U Smart Card Reader — Send GlobalPlatform APDUs to Java Cards for applet installation and key management. Supports SCP03 encrypted sessions via PC/SC. — Check Price on Amazon

When to Use Each

✔ Plaintext APDU mode is acceptable if…

You are in a development lab with a physically isolated reader and card. No attacker can intercept the communication.
You are testing card behavior and need to see the raw APDU data for debugging.
The card is a test/samples card with no production keys or sensitive data.

✔ SCP03 is mandatory if…

You are personalizing production cards. Installing applets, loading keys, and configuring security domains on cards that will be deployed to users.
You are performing OTA (Over-The-Air) management. Remote management of SIM cards, eSIM profiles, or IoT secure elements over a network.
You are in a production environment where the reader-to-card channel could be monitored.
Compliance requires it. Common Criteria, EMVCo, and payment scheme security standards mandate SCP03 for card management.

Related Comparisons

Java Card vs SIM Card — the platforms that GlobalPlatform manages
T=0 vs T=1 Protocol — the transport layer beneath GP APDUs
APDU Builder (Tool) — construct and send GP commands
TLV/BER-TLV Parser Comparison — parsing GP command/response data

Summary

Plaintext APDUs are for development; SCP03 is for production. SCP03 wraps every card management command in AES-128 encryption and CMAC integrity, preventing eavesdropping, tampering, and replay. If you are managing production cards — especially over network connections (OTA) or in environments where the communication channel is not physically secure — SCP03 is non-negotiable.

Want to construct GP APDUs? Try our APDU Builder or the APDU Reference.

← GPO vs AC Commands DESFire EV2 vs EV3 →