Security Header

Description

The Security Header is a fundamental component of the Secured Packet structure defined in 3GPP TS 22.048 and TS 23.048, which together specify the security mechanisms for remote management of the (U)SIM application toolkit. A Secured Packet consists of two logical parts: a Security Header and the protected payload (Command/Response data). The Security Header holds all the security information necessary for the receiving entity — typically the card — to verify and process the packet. This includes a counter to prevent replay attacks, a key identification field that tells the card which key set and algorithm to use, an indication of the security level requested (which combinations of integrity, authenticity, confidentiality, and replay protection apply), and a checksum or Digital Signature used for integrity and authentication verification.

Architecturally, the Security Header sits between the transport layer and the application payload in the over-the-air (OTA) messaging chain. When a Remote Application Management (RAM) or Remote File Management (RFM) server sends a command to a (U)SIM card, the command is packaged into a Secured Packet whose Security Header is generated according to the Security Parameters selected for that particular application. The card parses the Security Header first, extracts the relevant cryptographic material and control fields, validates the packet, and only then dispatches the enclosed command to the target application or file system.

The security information carried in the header is directly coupled to the set of Security Parameters associated with the destination applet or application. This coupling ensures that a single generic transport mechanism (the Secured Packet) can serve applications with very different security needs: from low-sensitivity configuration updates requiring only integrity checking, to high-value payment or identity applications requiring full confidentiality and cryptographic authentication. The counter field is especially important in the SCP80/SCP81 secure channel context, where monotonically increasing counters prevent an attacker from replaying previously observed legitimate commands.

The Security Header also enables interoperability. Because the format and semantics of the header are standardised, an OTA platform from one vendor can securely manage cards from any manufacturer, provided both implement the SCP80/SCP81 algorithms and the SPI (Security Parameter Indicator) mechanism defined in the specifications. The key identification field allows multiple keys or key versions to be active simultaneously, supporting key rotation and staged deployment of new security material without disrupting existing services.

From an operational perspective, the Security Header is generated by the OTA server or the network's security gateway and validated on the card. Failures to validate — due to an incorrect counter, unknown key ID, or mismatched signature — cause the packet to be rejected and appropriate error responses to be returned to the server. This design gives network operators visibility into security events and supports automated retry or key-refresh procedures. Overall, the Security Header is the enabler of trustworthy remote management of SIM-based services.

Purpose & Motivation

The Security Header exists to make remote management of (U)SIM applications trustworthy. Before its introduction, over-the-air provisioning and card management commands could be sent without standardised protection, making them vulnerable to eavesdropping, tampering, and replay attacks. Because a (U)SIM card is the root of trust for subscriber identity and often for payment or authentication services, unprotected remote commands represented a serious security gap.

The header solves this by defining a standard container for all the cryptographic control information needed to secure a command or response. It decouples the security logic from the application logic: any application can be managed remotely using the same Secured Packet mechanism, with an appropriate security level selected per application. This avoided the need to build bespoke security into every applet and made the overall system manageable and certifiable.

Historically, the mechanism was first standardised in Release 5 as part of the broader push to enable operator-controlled, vendor-independent OTA management of SIM cards. The standardised Security Header and the associated SCP80/SCP81 secure channels became the foundation for remote applet installation, file management, and credential provisioning that remain in use in later releases.