Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · Security

GPI

GBA Push Information

Security →

GPI is a GBA security mechanism that enables a network application server to securely push bootstrap information to a UE to initiate communication setup.

Introduced
Rel-8
Where
Security
Specifications
9 specs
Also in
Services
GPI Description Purpose What changed Neighbours Detected Changes Specifications

Description

GBA Push Information (GPI) is a component of the 3GPP Generic Bootstrapping Architecture (GBA), which provides a standardized method for mutual authentication and key agreement between a User Equipment (UE) and a Network Application Function (NAF). While standard GBA relies on the UE initiating the bootstrapping procedure, GPI enables a 'push' model. In this model, a NAF (e.g., a service provider's server) can proactively send essential bootstrapping information to the UE, allowing the UE to subsequently establish a secure connection with that NAF. This information is contained within a GPI message, which is itself a secure object.

Architecturally, GPI involves several key entities defined in GBA: the UE, the Bootstrapping Server Function (BSF), the NAF, and the Home Subscriber Server (HSS). The process begins when a NAF determines it needs to push information to a specific UE. The NAF requests a GPI from the BSF. The BSF, which shares a trust relationship with the HSS, generates the GPI. This GPI contains critical data such as a Bootstrapping Transaction Identifier (B-TID), the NAF's identity, key lifetime information, and potentially other parameters. Crucially, this GPI is cryptographically protected using keys derived from the subscriber's long-term credentials stored in the HSS, ensuring its integrity and authenticity. The BSF sends the GPI to the NAF, which then delivers it to the UE via a push channel, which could be an IP-based push mechanism like SIP Push or an SMS bearer.

Upon receiving the GPI, the UE processes it. The UE can verify the GPI's authenticity because it can derive the same cryptographic keys from its own identity module (USIM/ISIM) and the parameters in the GPI. Once verified, the UE extracts the B-TID and other information. The UE can then contact the BSF using this B-TID to perform a standard GBA bootstrapping run, resulting in the establishment of shared session keys (Ks_NAF) specifically for use with that NAF. Finally, the UE establishes a secure connection (e.g., using TLS) with the NAF using these keys. This mechanism allows services like firmware updates over-the-air (FOTA), instant messaging service activation, or emergency alert systems to securely initiate contact with a device that has not previously interacted with the service server.

Purpose & Motivation

GPI was created to address a limitation in the original GBA model, which was purely 'pull'-based, requiring the UE to always initiate contact with the BSF. Many emerging mobile services, however, are server-initiated (push services). For example, a service provider may need to send a configuration update or an alert to a device. Without a pre-established security context, initiating such communication securely is challenging. GPI solves this by allowing the server to securely push the initial bootstrap 'invitation' to the UE.

Historically, before standardized push security mechanisms, services used less secure methods like plain SMS for activation or relied on pre-provisioned keys, which were difficult to manage at scale. Introduced in 3GPP Release 8 alongside GBA enhancements, GPI leveraged the existing, robust security of the GBA infrastructure (rooted in the USIM) to enable secure server-initiated services. It filled a critical gap in the service enablement ecosystem, allowing for secure, scalable, and standardised push-based service delivery without requiring modifications to the UE's SIM card for each new service.

What changed in its specifications

The latest release-to-release comparison of specifications that define GPI. Each summary describes the whole specification, not only this term.

TS 24.109Rel-16 → Rel-17

Standalone security aspects update HTTP references and specify authentication algorithm values. AKMA adds TLS usage over Ua* with new definitions, and GBA updates authentication algorithm and TLS version details for 5GC bootstrapping.

Full comparison in TS 24.109 →
TS 24.334Rel-18 → Rel-19

Rel-19 brings only minor changes to TS 24.334: 0 clauses changed, with no change attributed to a release feature.

Full comparison in TS 24.334 →

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (2 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 1 change
Rel-17 1 change
  • Introducing the GBA Push Info (GPI) in the 5G ProSe direct link security mode control procedure TS 24.554CR0067

Defining Specifications

3GPP specifications that define or reference GPI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 24.109 vj00 HTTP Digest AKA & GAA Stage 3 Rel-19 read
TS 24.334 vj00 ProSe Protocols and Procedures Rel-19 read
TS 24.554 vk10 5G ProSe Protocols and Procedures Rel-20 read
TS 29.109 vj00 GAA Bootstrapping Interfaces (Zh, Dz, Zn, Zpn) Rel-19 read
TS 33.223 vj00 GBA Push Function Specification Rel-19 read
TS 33.224 vj00 Generic Push Layer (GPL) Specification Rel-19 read
TS 33.503 vk00 5G ProSe Security Specification Rel-20 read
TS 33.843 vf10 Security Study for ProSe UE-to-Network Relay Rel-15 read
TR 33.924 vj00 GBA-OpenID Interworking Specification Rel-19 read