Release 15: the first 5G security architecture, and what it changed

Release 15 arrived in two steps, and the distinction still matters when reading claims about 5G security. The first specified a new radio operating in front of an existing fourth-generation core, so that operators could deploy 5G radio quickly without replacing the core underneath. The second specified the standalone configuration, with the 5G core behind it.

Almost all of the security architecture belongs to the second. The new key hierarchy, the concealment of the subscriber identifier, the protection of the core’s internal interfaces and the roaming controls are properties of the 5G core, not of the radio. A deployment that took the first step and not the second is 5G by every marketing measure and retains the earlier generation’s security properties, including the identity disclosure that a false base station depends on.

This is the most common source of confusion about when 5G security protections became real. The specification date and the deployment date are years apart, and the two-stage structure means a network can be on the later release for radio purposes and the earlier architecture for security purposes at the same time.

The change with the widest consequence is the smallest to describe. The permanent subscriber identifier is encrypted on the device, to a key belonging to its home operator, before it is transmitted, and the value that goes over the air is fresh on each computation. A listener therefore cannot resolve it to a subscription and cannot match two sightings to each other.

Because the encryption is to the home operator, whose key the network in front of the device does not hold, the property holds even against the network the device is currently attached to. That is what makes it effective against a device impersonating a cell: impersonation gets the attacker into the position of the serving network, and the serving network is not able to read the identifier either.

The limits are set out on the concealment page, and the important one is that a null option exists and its use is an operator configuration decision. Release 15 makes concealment available and mandatory to support; it does not make it observable to the subscriber whether it is in force.

The second change is structural. The key hierarchy was reworked so that the material anchoring a subscriber’s security is held in a defined function in the home network and derived downwards from there, which gives cleaner separation between what a visited network holds and what only the home network holds. Primary authentication was specified in two variants, one an evolution of the previous mechanism and one built on a general extensible framework, which matters for the non-handset device classes that the preceding releases had added.

The third is the consequence of the core being redesigned as a collection of services that call one another instead of a set of dedicated interfaces between named elements. This is a substantial gain in flexibility and a substantial change in exposure: a call between services on a shared fabric cannot inherit trust from the topology, because the topology no longer says anything. So the interfaces are protected in their own right, with transport protection and an authorisation model that decides which service may invoke which.

Alongside that, interconnection between operators received a dedicated element at each network’s edge, whose job is to protect signalling that crosses the boundary and to police what a partner network is permitted to ask for. Roaming interconnect had been the route for a long series of practical attacks in earlier generations, and treating it as an untrusted boundary is the change of assumption that the whole design turns on. What the two releases after this one did with that architecture is covered on the Release 16 and 17 page.