The most sensitive information in the LI system is the target list. This is the list of all the subjects in the network currently under surveillance, whether active, suspended or in any other state. The security measures used by the carrier to ensure unauthorized access to this list is not subject to standardization, but the architectural choices made in the design of the LI system do impact the security of the target list directly.
Since completeness of the interception product is a legal requirement in most jurisdictions, the LI system shall ensure that no events that are lawfully authorized for interception are missed (or collected in error). To ensure that no events are missed there are two architectural alternatives.
A carrier may choose to deploy the full target list at all POIs, such that when a UE arrives in the network and commences registration, the POI is fully armed and in position to recognize if the target identifier is in the target list. The choice to push the full list to every node is the simplest, and arguably the riskiest, since the compromise of any node will leak the complete target list.
A Communication Service Provider (CSP) may choose to selectively distribute specific target identifiers to specific POIs, rather than distributing the full target list to all POIs. This choice introduces a race condition. When the UE appears, the POI shall query the ADMF/LICF to find out if the user identifier is part of the target list. As the registration sequence progresses, the NF POI is waiting for a response from the ADMF/LICF. When the reply arrives, the POI can take action if the reply is positive. If the reply is negative, the POI's involvement ends.
If the reply is positive, depending on how long the POI-(ADMF/LICF)-POI round trip for the query/reply took, it is possible that some reportable events are missed. To mitigate this there are two further alternatives:
the carrier may choose to delay completion of the registration for all users for the time it takes the ADMF/LICF to answer, thus inducing a registration delay in all registrations, whether the user is a target or not, or
the carrier may choose to cache the reportable registration events while the POI-(ADMF/LICF)-POI query is running, and either report them if the answer is positive, or delete them if the answer is negative.
These are choices at the discretion of the CSP, but the trade-off cannot be avoided.
When a new target is provisioned in the LI system, after the target is already registered in the CSP network, the CSP will be faced with the race condition consequences of the implementation choice made as described in Clause 8.2.1 and Clause 8.2.2. The ADMF has a choice to either wholesale pre-arm every POI with the new target (and expect every POI to immediately start interception on the new target, as in clause 8.2.1), or, the ADMF can poll every serving UDM POI for all target UEs, and arm the associated POI (and start interception, as in clause 8.1.2) only if a target UE is discovered to be served by that particular NF. The second approach would take comparatively longer and would be expected to miss more of the on-going target interactions with the network than the first approach.
The ADMF is responsible for overall management of the LI system as defined in clause 22.214.171.124. The ADMF is responsible for creating and managing intermediate, client and root certificates used for both identity verification and establishing encrypted communications between LI components.
The ADMF shall implement an LI Certificate Authority (LI CA) which shall be used as the issuing CA for all LI components.
By default, the LI CA shall be a sub-CA of the CSP root CA, and may issue intermediate certificates.
The LI CA shall be responsible for creating, maintaining and revoking all identity verification and encryption certificates and root keys used by LI components communicating on LI_X interfaces. It may also be responsible for issuing certificates and root keys for LI_HI interfaces if these are not issued by the LEA/LEMF.
For virtualised implementations, the LICF shall support automated certificate enrolment for POIs, TFs and MDFs. For non-virtualised deployments, support for automatic certificate enrolment is optional.
The LICF shall maintain a list of all valid LI components for which the LI CA has generated certificates. The LICF shall instruct the LI CA to revoke any certificate belonging to LI components that are removed from the system (e.g. de-instantiated).
The LI CA shall provide a single certificate for each LI component. The LI component shall generate individual session keys for each LI_X link.
LI functions as defined in the present document when virtualised shall include the use of one or more HMEEs as defined in ETSI GS NFV-SEC 012  or equivalent specification, to protect as a minimum:
LI target lists.
Any LI dynamic selectors used internally within the NF to select target communications to be intercepted.
Any cryptographic keys and LI_X1/LI_X2/LI_X3 end points.
During runtime, NFs containing LI functions should not share NFVI hosts with any other NF, VNF or VNFC.
During runtime, NFs containing LI functions shall not share NFVI hosts with any other NF, VNF or VNFC which does not contain other authorised LI functions.
The NF runtime restriction requirements do not prevent hosts being used for different NFs over the lifetime of the NFVI, following termination of the previous VNF instances. However, both where hosts are newly allocated for LI use and when subsequently released, host memory and storage secure erase procedures as defined in ETSI GS NFV-SEC 012  or equivalent specification shall be used.
Where containers are used for implementing LI functionality, and when images corresponding to those containers are required to be stored at runtime in a system wide container cache, the LI Controller shall ensure that each time the container image is retrieved from the cache, the integrity of the image is validated. In addition, when the image is no longer required by a live running Network Function, the image is erased from the cache.
CSPs use a wide range of 3GPP NFs to provide services to users. In order to intercept a service, POIs are associated with specific NFs, as depicted in Figure 8.5-1. The manner the POI obtains the required information from the NF depends on the service and can range from something as simple as a copy-and-forward mechanism, to sophisticated isolation and filtering. The POI may be embedded in the NF or external to the NF, connected to its interfaces. The choice of one, the other, or both approaches is service specific.
[not reproduced yet]
Figure 8.5-1: Embedded vs. external POIs
In figures that follow the POI will be depicted straddling the edge of the NF to simultaneously indicate both approaches. Figure 8.5-2 shows the basic job of a POI: to obtain the state, or communicated user data, of the intercepted service. As the NF changes state, or as additional user data is generated or forwarded, in the course of providing the service, the appropriate interceptable events or real-time content are transferred into the POI.
[not reproduced yet]
Figure 8.5-2: POI state capture
Although the POI has access to service state in the NF and information flows in and out of the NF, the NF shall not be able to access data in the POI, for obvious security reasons, as depicted in Figure 8.5-3. If the POI is embedded, LI data leakage from the POI back into the non-secure area of the NF shall be prohibited. If the POI is not embedded, the implementation shall prohibit LI data leakage back into the NF.
The same requirements apply to TFs.
[not reproduced yet]
Figure 8.5-3: POI state capture security
Generally, embedded POIs have full access to the state machine of the service they intercept, while external POIs have to infer the state of the intercepted service from the events detected on the interfaces or externally applied traffic filtering criteria.
This clause introduces CC-PAG (CC-POI Aggregator) as an architectural extension that is located between the MDF3 and CC-POI. The CC-PAG performs the function of aggregating the xCC from different CC-POIs towards the MDF3 and is shown in Figure 8.6-1.
[not reproduced yet]
Figure 8.6-1: LI architecture showing CC-PAG.
The CC-PAG is an optional LI function and may be deployed in networks that need aggregation of xCC from potentially large number of different CC-POIs towards the MDF3. The CC-PAG may be deployed closer to the UPFs, to reduce the impact of latencies, packet drops, and buffering on UPFs for lawful interception of highspeed user plane traffic. The system resources such as hardware interfaces, CPUs and memory for the CC-PAG node may be tuned to balance the forwarding/reception capabilities of CC-POI and MDF3.
As shown in figure 8.6-1, the CC-POI is triggered by the CC-TF to deliver the xCC (on a per flow basis) to the CC-PAG (via LI_X3A interface) or to the MDF3 (via LI_X3 interface as described in clause 6.2.3).
In the option where CC-PAG is involved, the LIPF configures the CC-PAG with the appropriate MDF3 address. The CC-PAG address is provided to the CC-POI using one of the two methods:
pre-provisioned (e.g. by LIPF over LI_X0 interface) while instructed to use the pre-provisioned address over LI_X1;
as a part of the CC intercept trigger by the CC-TF which in turn is provisioned by the LIPF over LI_X1.
The CC-PAG aggregates the xCC received from different CC-POIs before forwarding the same to the MDF3. The xCC is not modified. The LI_X3A interface is the same as LI_X3 interface on the application level but may be used with other transport protocol options as described in ETSI TS 103 221-2 .