GBA

Generic Bootstrapping Architecture

Security →
Introduced in Rel-6 Also in: Core Network, Services

GBA is a security framework that lets a user device and a network application server establish shared keys by leveraging the 3GPP AKA protocol to bootstrap security for applications over HTTP.

Category
Security
Introduced
Rel-6
Where
Security
Also touches
2 segments
Specifications
42 specs
GBA Description Purpose Related Classification Detected Changes Specifications

Description

The Generic Bootstrapping Architecture (GBA), also referred to as Generic Authentication Architecture (GAA), is a standardized security framework defined by 3GPP that provides a method for user equipment (UE) and network application servers (NAFs) to derive shared session keys. It reuses the robust authentication and key agreement (AKA) procedures already established between the UE and the mobile network's Home Subscriber Server (HSS). The core idea is to 'bootstrap' application-layer security from this proven network-layer authentication, creating a trusted security association for services without requiring users to manage additional usernames and passwords.

The architecture involves several key functional entities: the Bootstrapping Server Function (BSF), the Network Application Function (NAF), the Home Subscriber Server (HSS), and the User Equipment (UE). The process begins with a bootstrapping procedure between the UE and the BSF. The UE and BSF perform a mutual authentication using the 3GPP AKA protocol, facilitated by the HSS which provides authentication vectors. Upon successful authentication, both the UE and the BSF derive a shared, session-specific key called the Bootstrapping Transaction Identifier (B-TID) and a related key material, Ks. The B-TID serves as a reference to this shared secret.

Subsequently, when the UE needs to access a service provided by a NAF (e.g., a streaming server or a corporate portal), it presents the B-TID to the NAF. The NAF, in turn, contacts the BSF using the Zn interface, providing the B-TID. The BSF verifies the B-TID and, if valid, derives a NAF-specific key, Ks_NAF, from the master key Ks and the NAF's identifier. The BSF then sends this Ks_NAF securely to the NAF. Now, both the UE (which can independently derive the same Ks_NAF) and the NAF possess a shared secret key. They can use this key to secure their communication, for instance, by using it within TLS-PSK (Pre-Shared Key) or to generate keys for encryption and integrity protection at the application layer. This entire process allows for single sign-on-like experience across different services hosted by different NAFs, all secured by the user's SIM card credentials.

Purpose & Motivation

GBA was created to address the growing need for secure authentication to internet-based application services (like video streaming, email, or banking) accessed from mobile devices, without forcing users to remember and enter separate credentials for each service. Before GBA, application servers either relied on weak username/password combinations, required complex public key infrastructure (PKI) deployment on UEs, or had no integrated security with the mobile operator's trust domain. This led to poor user experience, security vulnerabilities, and fragmented identity management.

The primary motivation was to leverage the strong, SIM-based authentication already present in mobile networks. The 3GPP AKA protocol provides mutual authentication and strong key establishment between the UE and the network core. GBA repurposes this infrastructure to create a generic key distribution service for the application layer. This solves the problem of credential proliferation and allows mobile operators to offer value-added services with built-in, high-grade security derived from the SIM.

Furthermore, GBA enables new business models by allowing third-party application providers (the NAFs) to rely on the mobile operator's authentication infrastructure. A content provider can offer a service securely to a subscriber without needing to operate its own authentication system; it simply integrates with the operator's BSF. This created a trusted ecosystem, facilitated the deployment of IP Multimedia Subsystem (IMS) services, and provided a foundation for secure machine-to-machine (M2M) communication, addressing the limitations of previous ad-hoc and less secure application authentication methods.

Classification

Part ofAKA
Specific typesCCMGAAGPIGUSSMV
Related approachesBSFNAFHSSUSIMIMS

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 1 change

In Release 15, the GBA function was updated to resolve an Editor's Note concerning the application identifier for the ANDSF GBA Push procedure. This change provided specific clarification for this application ID, contributing to the ongoing work for uniform trust establishment mechanisms.

  • Resolving Editor's Note on application ID for ANDSF GBA Push TS 24.302CR0695
Rel-17 6 changes

In Release 17, the GBA was enhanced to support a GBA-based shared secret with Pre-Shared Key (PSK) authentication in TLS 1.3 and introduced GBA key re-negotiation using TLS 1.3. It also added the GBA Push Info (GPI) for the 5G ProSe direct link security mode control procedure and deprecated the use of SHA-1. Furthermore, the release provided mechanisms for choosing between AKMA and AKA-based GBA at both the UE and Application Function sides.

  • GBA-based shared secret with PSK authentication in TLS 1.3 TS 24.109CR0071
  • Introducing the GBA Push Info (GPI) in the 5G ProSe direct link security mode control procedure TS 24.554CR0067
  • SHA-1 deprecation in GBA TS 33.220CR0207
  • GBA key re-negotiation with TLS 1.3 TS 33.222CR0056
  • GBA Reference points TS 23.501CR3267
  • Choosing between AKMA and AKA-based GBA at both UE and AF sides TS 24.109CR0073
Rel-18 7 changes

In Release 18, the GBA function was enhanced by defining a new GBA Ua protocol based on DTLS and by specifying the use of IETF OSCORE as a GBA Ua protocol. Furthermore, the release introduced OAuth2 scopes into the Nbsp_GBA API and expanded test coverage, particularly for the GBA_U API and its GBAUCipher and GBAUSignature classes.

  • OAuth2 scopes in the Nbsp_GBA API TS 29.309CR0005
  • GBA_U API test case TS 31.213CR0022
  • GBA_U API test cases on GBAUCipher and GBAUSignature TS 31.213CR0046
  • Test cases for the getCipherAlgorithm method in GBAUCipherClass of the GBA_U API TS 31.213CR0052
  • Add a new Annex about GBA Ua protocol based on DTLS to TS 33.220 TS 33.220CR0220
  • IETF OSCORE as GBA Ua protocol TS 33.220CR0223

+ 1 more changes

Explore further

Broader topics and technologies where GBA plays a role.

Defining Specifications

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

SpecificationTitleRelease
TR 22.978 vj00 Feasibility of All-IP Network (AIPN) in 3GPP Rel-19
TS 23.501 vk00 5G System Architecture Stage 2 Rel-20
TS 23.862 vc00 Interworking Solutions for Mobile Operators & Data Apps Rel-12
TS 24.109 vj00 HTTP Digest AKA & GAA Stage 3 Rel-19
TS 24.229 vj50 IMS call control protocol based on SIP and SDP Rel-19
TS 24.259 vj00 Personal Network Management (PNM) Protocol Details Rel-19
TS 24.302 vj00 Access to EPC via non-3GPP networks; Stage 3 Rel-19
TS 24.554 vj40 5G Proximity Services (ProSe) Protocols Rel-19
TS 26.517 vj10 5G MBS User Service Protocols and Formats Rel-19
TR 26.946 vj00 MBMS User Services Overview Rel-19
TS 29.109 vj00 GAA Bootstrapping Interfaces (Zh, Dz, Zn, Zpn) Rel-19
TS 29.309 vj10 Nbsp Service Based Interface for GBA BSF Rel-19
TS 31.213 vi30 Test specification for (U)SIM Rel-18
TR 31.822 vi10 Technical Report on GBA_U based APIs Rel-18
TS 32.808 v1800 Common User Profile Storage Framework Rel-8
TS 33.107 vj00 Lawful Interception Architecture & Functions Rel-19
TS 33.110 vj00 UICC-Terminal Key Establishment Rel-19
TS 33.141 vj00 Security for Presence Service (Ut reference point) Rel-19
TS 33.179 vdc0 MCPTT Security Architecture and Procedures Rel-13
TS 33.180 vk00 Security of Mission Critical (MC) Service Rel-20
TS 33.185 vj00 V2X Security in LTE Rel-19
TS 33.220 vj00 Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) Rel-19
TS 33.221 vj00 Subscriber Certificate Distribution via GBA Rel-19
TS 33.222 vj00 Secure HTTP Access in GAA Rel-19
TS 33.223 vj00 GBA Push Function Specification Rel-19
TS 33.224 vj00 Generic Push Layer (GPL) Specification Rel-19
TS 33.246 vj00 MBMS Security Specification Rel-19
TS 33.259 vj00 Key Establishment between UICC Hosting & Remote Device Rel-19
TS 33.303 vj00 ProSe Security Specification for EPS Rel-19
TS 33.310 vj50 3GPP Authentication Framework for Network Nodes Rel-19
TS 33.503 vj20 Security for Proximity Services (ProSe) in 5G Rel-19
TS 33.533 vj00 Security for 5G Ranging & Sidelink Positioning Rel-19
TR 33.739 vi10 Study on security enhancement of support for Rel-18
TS 33.804 vc00 Non-UICC SSO using SIP Digest credentials Rel-12
TS 33.822 v1800 Security Architecture for Inter-Access Mobility Rel-8
TS 33.823 vc20 GBA Web Browser Integration Study Rel-12
TS 33.835 vg10 Study on authentication and key management for apps Rel-16
TS 33.863 ve20 Security for Battery-Efficient IoT Device to Enterprise Rel-14
TR 33.919 vj00 GAA Overview TR Rel-19
TR 33.924 vj00 GBA-OpenID Interworking Specification Rel-19
TR 33.980 vj00 GAA & Liberty Alliance Interworking Guidelines Rel-19
TS 34.229 vj21 IMS SIP/SDP UE Conformance Testing for 5GS Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.