The 5G security enablers catalogue and the open specifications

The catalogue below is the whole set of 5G security enablers. Each row names a cluster, an enabler and the single concern that enabler was written to address, which is the level at which the set is worth scanning: the point is not that 20 components existed, but that the exposure of a mobile network was divided into problems small enough for a component to answer one of them.

The 5G security enablers divide by concern rather than by layer. Authorization sits between network functions; privacy sits at the subscriber identity; trust sits in the elements and the platforms they run on; monitoring cuts across all of them; network management covers the interfaces an operator uses to change the network. Read down the cluster column and the catalogue is a statement about where a 5G network can be got at.

Four of the privacy enablers deal with the same underlying fact from different sides: a mobile network cannot serve a subscriber it cannot identify, and every identifier it uses is a handle that something else might grab. The specification answer is to conceal the permanent identifier before it leaves the device. That settles the radio link and leaves the rest open, which is what the privacy enablers address.

They split along a useful line. Two of them move work to the device, on the reasoning that a subscriber should not have to trust the network with data the network does not need: device identifier privacy and device-based anonymization both put the decision at the handset. The other two are about verification instead of concealment: whether a stated privacy policy can be checked mechanically, and whether the security state of a connection can be reported to the person using it and not only to the operator.

That last one is easy to overlook and hard to build. A subscriber has almost no way to tell a normally-behaving network from one that has quietly downgraded their connection, and the privacy enablers treat that asymmetry as a design problem rather than an inevitability.

Once network functions are software on shared hardware, a question appears that did not exist for purpose-built equipment: is this function the one it claims to be, running unmodified, on a platform worth relying on? The trust enablers answer parts of it. VNF certification addresses the integrity of a virtualised function; bootstrapping trust covers the moment a new element joins and has no history to be judged on; the trust metric enabler exists so that trust can be expressed as a quantity a decision can be made against, rather than as a yes or no.

The trust enablers are also where the architecture and the catalogue meet most directly. A trust model was written as its own deliverable, twice (a draft and a final), because the model had to settle before components could be specified against it.

One row in the table below carries no link. The security indicator specification was published and its address still resolves, but no copy of the file survives in the archive, so the enabler is listed here without a document.

The remaining three clusters are less visible from outside the network and no less load-bearing. Authorization governs what one network function may ask another to do, which matters more in a service-based architecture where functions talk over a common bus than in a core where the paths were fixed in advance. The IoT enabler belongs here because a constrained device cannot run the same admission machinery as a handset and still needs to be held to a policy.

Security monitoring is the cluster that cuts across the others: collection, detection and correlation, plus a representation of system security state that other components can read. It is deliberately generic: a collector interface that does not care what it is collecting from is worth more across a heterogeneous network than a detector tuned to one element. Network management, finally, is about the operator’s own interfaces: segmentation so that a compromise does not travel, access control on management planes, and a way to check a running configuration against the policy it is supposed to implement.

The catalogue names the enablers; the open specifications define them. Two editions were published, and the second is not a correction of the first so much as a wider net: the earlier edition documents the set as first specified, the later one the set as it stood when the work finished. A separate documentation deliverable describes how the components fit together, and a technical roadmap was issued three times as the picture changed.

Anyone citing an enabler should cite the edition they read. Because the open specifications exist in two versions and the roadmap in three, a claim about what a 5G security enabler does is only checkable against a stated document, and every one of them is held here at the address it was published under.

• D3.2 Security enablers open specifications, v1.0
• D3.6 Security enablers open specifications, v2.0
• D3.4 Security enablers documentation
• PDFCases for including a reference monitor in SDN, a conference poster

All deliverables in the archive