SCP02 vs SCP03 (GlobalPlatform)

SCP02 vs SCP03 (GlobalPlatform Secure Channel)

SCP02 and SCP03 are the two dominant Secure Channel Protocols defined by GlobalPlatform for authenticating and encrypting communications between an off-card entity (a Card Management System, a Trusted Service Manager, or an OTAOTAPersonalizationRemote card management via mobile network.Click to view → server) and the on-card GlobalPlatform Card Manager. Both protocols serve the same purpose — establishing a mutually authenticated, integrity-protected, and encrypted channel for applet loading, key injection, and card content management — but they differ in their cryptographic primitives, key derivation mechanisms, and the security properties those choices produce.

Overview

SCP02 was introduced in GlobalPlatformGlobalPlatformSoftwareCard application management standard.Click to view → Card Specification v2.1 (2001) and uses 3DES3DESCryptographyLegacy triple-DES symmetric cipher in payment smart cards.Click to view → (Triple Data Encryption Standard) as its sole cryptographic primitive. SCP02 derives session keys from static keys using a simple 3DES-based derivation function. It remains the most widely deployed GlobalPlatform secure channel — supported by virtually every JavaCard platform manufactured in the past 20 years, and still operational in a vast installed base of cards. SCP02 is a channel encryption protocol (not just authentication), providing data confidentiality, integrity, and mutual authentication between card and host.

SCP03SCP03SoftwareAESAESCryptographyNIST symmetric block cipher for smart card encryption.Click to view →-based secure channel protocol.Click to view → was introduced in GlobalPlatform Amendment D (2009) and standardized in GP Card Spec v2.2+. SCP03 replaces all 3DES operations with AES (AES-128 or AES-256), uses CMAC (Cipher-based Message Authentication Code) for integrity, and employs a more robust key derivation function (CMAC-based counter mode KDF). SCP03 is mandatory for new GlobalPlatform deployments, required by EMV specifications for card personalization infrastructure, and mandated by GSMA for eSIM Remote SIMSIMApplicationSmart card for mobile network authentication.Click to view → Provisioning.

Key Differences

• Symmetric algorithm: SCP02 — 3DES (112-bit effective security); SCP03 — AES-128/256 (128 or 256-bit security)
• MAC algorithm: SCP02 — Retail-MAC (CBC-MAC with 3DES); SCP03 — CMAC (AES-based, stronger proof)
• Key derivation: SCP02 — 3DES-based derivation using derivation data; SCP03 — AES/CMAC counter-based KDF
• C-MAC length: SCP02 — 8 bytes; SCP03 — 8 bytes (truncated CMAC)
• Key set structure: SCP02 — ENC, MAC, DEK (3 separate 3DES keys); SCP03 — ENC, MAC, DEK (3 separate AES keys)
• Security strength: SCP02 — 112 bits effective (3DES); SCP03 — 128 bits (AES-128) or 256 bits (AES-256)
• NIST status: 3DES deprecated by NIST SP 800-131A after 2023; AES approved through at least 2030+

Technical Comparison

Cryptographic Weaknesses of SCP02

SCP02's reliance on 3DES exposes it to several known weaknesses:

Sweet32 attack (3DES birthday bound): 3DES has a 64-bit block size. The birthday attack (Sweet32) demonstrates that after approximately 2^32 blocks (~32 GB) of data encrypted under the same key, a statistical collision-based attack becomes feasible. For card personalization (which transfers much less data), this is rarely a practical concern, but it disqualifies 3DES from being used in high-volume secure channels by current NIST guidance.

Retail-MAC vs CMAC: SCP02's Retail-MAC is a CBC-MAC construction using 3DES. CBC-MAC without proper length prefixing has known extension vulnerabilities (though SCP02's usage is structured enough to limit practical exploitation). CMAC (used in SCP03) is a provably secure MAC construction with a clean security reduction to the underlying block cipher — a stronger theoretical foundation.

NIST SP 800-131A Revision 2 (2019): NIST disallowed 3DES for new applications after December 31, 2023. Systems using SCP02 in environments subject to NIST compliance (US federal, FIPS 140FIPS 140ComplianceUS government cryptographic module security standard.Click to view →-3 contexts, FedRAMP) now face a compliance issue that SCP03 resolves.

Key Derivation Comparison

SCP02 key derivation: Session keys are derived by encrypting a derivation data block (containing a sequence counter and a derivation constant) with the static base key using 3DES-ECB. This derivation is simple but has been criticized for not providing full independence between session keys and for the theoretical possibility of related-key attacks.

SCP03 key derivation: Session keys are derived using a CMAC-based PRF in counter mode (NIST SP 800-108 KDF in counter mode). This is a standardized, well-analyzed key derivation function with a clean security proof. SCP03 also adds a sequence counter to the derivation data, providing better session key independence.

Use Cases

SCP02 is encountered in: - Deployed JavaCard infrastructure where the card batch predates SCP03 support (pre-2012 chips) - Legacy Card Management System (CMS) installations that have not been upgraded - Some national ID card programs and transit card personalization systems still running 3DES infrastructure - Test environments and academic study (SCP02 is simpler to implement for research purposes) - Any context where installed cards support SCP02 but not SCP03, and card replacement is not yet complete

SCP03 is used in: - All new GlobalPlatform card deployments (chips shipping since ~2012 universally support SCP03) - GSMA SGP.22 eSIM Remote SIM Provisioning — SCP03 is mandatory for SM-DP+ to eUICC secure channel - EMV payment card personalization (Visa, Mastercard bureau requirements) - Apple Pay and Google Pay token provisioning infrastructure (OEM SE applet loading via SCP03) - Enterprise smart card token personalization (PIVPIVIdentityUS federal identity card standard.Click to view → card bureau, Yubico personalization) - Any PCI-DSS compliant card data environment (3DES deprecation forces SCP03 migration)

When to Choose Each

Choose SCP03 for all new implementations without exception. SCP03 is the current GlobalPlatform standard, mandated by payment schemes, GSMA, and increasingly required for NIST/FIPS compliance. All smart card chips manufactured in the past decade support SCP03. The only complexity is ensuring the Card Management System and HSMHSMSecurityPhysical device for key management.Click to view → supporting the GlobalPlatform infrastructure are updated to generate and use AES SCP03 key sets — a software/HSM configuration change, not a hardware change.

Maintain SCP02 support only as a backward-compatibility mode for managing deployed cards that predate SCP03 chip support. SCP02 should be removed from new card designs and new CMS deployments.

Migration path: Dual-protocol CMS systems support both SCP02 and SCP03, selecting based on the card's supported key set. Key set version (KVN) negotiation in the INITIALIZE UPDATE / EXTERNAL AUTHENTICATE sequence allows the CMS to detect which protocol the card supports before committing to a session.

Conclusion

SCP02 and SCP03 solve the same problem — authenticated, encrypted card management channels — but SCP03 does so with a cryptographic foundation that meets current security standards. SCP02's 3DES heritage is a technical liability that is becoming a compliance problem as NIST deprecates 3DES usage. For any new smart card program, CMS deployment, or HSM configuration in 2025, SCP03 with AES-128 or AES-256 is the unambiguous choice. SCP02 support is a backward-compatibility requirement for managing existing deployed cards, not a design option for new systems.