Security Parameters

Description

Security parameters, as defined in 3GPP TS 31.213 and TS 51.013, specify the minimum security requirements that must be met during the applet installation process. In the context of the (U)SIM Application Toolkit and the UICC platform, applets are small applications loaded onto the card to provide services such as payment, authentication, or operator-specific functions. The installation process involves loading the applet code, linking it, and making it selectable. Because a malicious or tampered applet could compromise the card and the subscriber's credentials, the specifications impose security requirements on how installation is authorised and executed.

These security parameters cover several dimensions. First, they set the required level of authentication for the entity requesting installation — typically the card must verify that the request comes from an authorised OTA server using the secure messaging mechanisms of SCP80/SCP81. Second, they define integrity requirements: the applet code and associated data must be protected against modification in transit. Third, they specify confidentiality requirements where the applet or its personalisation data are sensitive. Finally, they establish access-control rules that determine which keys, security domains, or privileges are needed to install a given applet.

The parameters are typically associated with a Security Domain on the card. A Security Domain is a privileged application that holds the keys and enforces the security policy for a group of applets. When an installation command arrives, the card's GlobalPlatform-compliant runtime checks whether the incoming request satisfies the security parameters of the target Security Domain. If not, installation is refused. This architecture allows a card to host applets from multiple parties (e.g., the mobile operator and a bank) with distinct, independently enforced security policies.

Operationally, security parameters are provisioned during card personalisation and can be updated later via secure OTA management. They are closely linked to the Security Header and Security Parameters of the Secured Packet mechanism: the header identifies the keys and the security level used, while the security parameters define what minimum level is required for a particular operation such as applet installation. Together they ensure that even if an attacker can send packets to the card, only correctly authenticated and protected installation requests are accepted.

The term appears in TS 31.213, which addresses the UICC application programming interface and the loading, installation, and removal of applications, and in TS 51.013, the equivalent for the SIM/ME interface in earlier generations. This dual specification reflects the transition from SIM to UICC and the need to maintain consistent security expectations across card generations. For engineers, understanding security parameters is essential when designing applet deployment flows, defining Security Domain policies, and certifying cards for payment or identity use cases.

Purpose & Motivation

Security parameters exist to guarantee that any applet installed on a (U)SIM/UICC card meets a defined minimum level of security. Without such requirements, the applet installation process would be a weak link: an attacker who could install an applet could potentially intercept authentication credentials, manipulate files, or impersonate the subscriber. Because SIM cards are increasingly multi-application platforms hosting payment, transport, and identity applets, a uniform, certifiable baseline for installation security became essential.

The parameters solve this by translating abstract security goals into concrete, enforceable requirements checked by the card's runtime environment during installation. They allow different stakeholders — operators, banks, service providers — to express their security expectations per Security Domain, and they let card vendors and OTA platforms implement a single enforcement mechanism.

Historically, the concept emerged in Release 8 as part of the maturing of the UICC application platform, complementing the earlier Secured Packet and Security Header work. Its stability across releases reflects a mature, widely adopted security model rather than a rapidly changing technology.