SECURITY HANDLING IN A LAWFUL INTERCEPTION SYSTEM

TECHNICAL FIELD

The present disclosure relates to handling of security breaches in a Lawful Interception system.

BACKGROUND

Attestation is a fundamental mechanism to establish trust over software systems. Telecom operators are required by the legal authorities to be able to prove the trustworthiness of the telecom operators’ networks in a number of countries. This trend is expected continue to grow with deployment of Fifth Generation (5G) and Sixth Generation (6G) networks.

The Lawful Interception (LI) network function standard ETSI TS 101 158 VI.3.1 (2014-02) provides requirements to have a trusted environment for running Virtual Network Functions (VNF) and cloud-native network functions payload. Remote attestation procedure during Network Function Virtualization (NFV) start up phase has been detailed in, for example, “Requirements for Network Functions” LI(22)P59032. At present, it is not clear what happens in a LI system if, during the continuous measurement and monitoring of a VNF, the VNF becomes untrusted.

SUMMARY

An object of the invention is to improve security handling in a communication network.

To achieve said object, according to a first aspect there is provided a method performed in a Lawful Interception, LI, system. The method comprises obtaining an indication of trust regarding an entity operating in a communication network. The method comprises evaluating a security breach associated with the entity based on the indication. The method comprises, based on the evaluation of the security breach, performing an action to manage the security breach.

According to a second aspect there is provided a device for a Lawful Interception, LI, system. The device comprises a memory and a processor. The memory contains instructions which when executed on the processor cause the device to: obtain an indication of trust regarding an entity operating in a communication network; evaluate a security breach associated with the entity based on the indication; and based on the evaluation of the security breach, perform an action to manage the security breach.

In an embodiment according to the first and the second aspects, the indication of trust is a trust score.

In an embodiment according to the first and the second aspects, evaluating the security breach comprises checking whether the trust score is below a threshold value.

In an embodiment according to the first and the second aspects, the indication of trust includes at least one of the following: measurement information for one or more measurements performed on a hardware on which the entity is executing; measurement information for one or more measurements performed on an operating system, OS, associated with the entity; and measurement information for one or more measurements performed on software code of the entity.

In an embodiment according to the first and the second aspects, evaluating the security breach comprises determining a level of the security breach.

In an embodiment according to the first and the second aspects, the level of the security breach is at least one of: low, medium and high.

In an embodiment according to the first and the second aspects, the indication of trust includes measurement information for one or more measurements performed on software code of the entity, and a low level security breach is determined based on one or more failures of a validation of the one or more measurements performed on software code of the entity.

In an embodiment according to the first and the second aspects, the indication of trust includes measurement information for one or more measurements performed on an operating system, OS, associated with the entity, and a medium level security breach is determined based on a failure of a validation of the one or more measurements performed on the OS; or the indication of trust includes measurement information for one or more measurements performed on software code of the entity, and a medium level security breach is determined based on at least one of the following: a pre-defined number of failures of a validation of the one or more measurements performed on the software code of the entity within a pre-defined time period; a number of simultaneous failures of a validation of the one or more measurements performed on the software code of the entity.

In an embodiment according to the first and the second aspects, the indication of trust includes measurement information for one or more measurements performed on a hardware on which the entity is executing, and a high level security breach is determined based on a failure of a validation of the one or more measurements performed on the hardware; or the indication of trust includes measurement information for one or more measurements performed on software code of the entity, and a high level security breach is determined based on at least one of the following: a pre-defined number of failures of a validation of the one or more measurements performed on the software code of the entity within a pre-defined time period; a number of simultaneous failures of a validation of the one or more measurements performed on the software code of the entity; or the indication of trust includes measurement information for one or more measurements performed on an operating system, OS, associated with the entity, and a high level security breach is determined based on at least one of the following: a pre-defined number of failures of a validation of the one or more measurements performed on the OS within a pre-defined time period; a number of simultaneous failures of a validation of the one or more measurements performed on the OS.

In an embodiment according to the first and the second aspects, the action is performed based on the level of the security breach.

In an embodiment according to the first and the second aspects, evaluating the security breach comprises determining that the security is breached and that the entity is not trusted.

In an embodiment according to the first and the second aspects, performing the action comprises sending a control signal to indicate at least one action to be performed.

In an embodiment according to the first and the second aspects, performing the action comprises at least one of: sending an alarm in the communication network informing about the security breach; inserting an indication in Intercept Related Information, IRI, or Content of Communication, CC, informing that a security breach is ongoing and that the IRI or CC may not be trusted; storing at least one X2 IRI or X3 CC received from the entity in a buffer for analysis before sending the IRI/CC to a Law Enforcement Monitoring Facility, LEMF; discarding information from the entity and/or refraining from sending information to the entity; and sending a new certification list to one or more other entities in the communication network wherein the new certificate list does not list an Internet Protocol, IP address of the entity.

In an embodiment according to the first and the second aspects, the entity is an Element of LI, ELI, and wherein performing the action comprises sending a new certificate list to one or more other entities in the communication network wherein the new certificate list does not list an IP address of the entity.

In an embodiment according to the first and the second aspects, the entity is a Mediation and Delivery Function, MDF, and wherein performing the action comprises sending a message instructing forwarding of all traffic from the MDF to a trusted MDF.

In an embodiment according to the first and the second aspects, the entity is a Network Function, NF, and wherein performing the action comprises sending a message instructing a cancellation of a task without waiting for a response message.

In an embodiment according to the first and the second aspects, the action is performed using the XI interface.

In an embodiment according to the first and the second aspects, performing the action comprises sending a request message over the X0 interface.

In an embodiment according to the first and the second aspects, the request message is a message indicating removal of an entity from the communication network, the request message comprising a command field.

In an embodiment according to the first and the second aspects, the command field comprises a value indicating discarding traffic from the entity when the entity is a MDF that is not trusted and wherein the request message is sent to one or more trusted entities. In an embodiment according to the first and the second aspects, the command field comprises a value indicating stopping traffic to or from the entity when the entity is a NF that is not trusted and wherein the request message is sent to one or more trusted entities.

In an embodiment according to the first and the second aspects, the method comprises receiving a response message acknowledging the reception of the request message.

In an embodiment according to the first and the second aspects, performing the action comprises: revoking a connection with the entity that is not trusted; and establishing a connection with a new entity, wherein the new entity is trusted.

In an embodiment according to the first and the second aspects, the connection is revoked by sending a message indicating removal of the entity that is not trusted entity from the communication network and the establishing the connection comprises receiving an acknowledgment message from one or more entities that are trusted in the communication network including the new trusted entity.

In an embodiment according to the first and the second aspects, performing the action comprises: establishing a new entity to substitute the entity that is not trusted, wherein the new entity is trusted, or sending a request to a Management and Orchestration, MANO, node to establish a new entity, wherein the new entity is trusted.

In an embodiment according to the first and the second aspects, performing the action comprises removing the entity that is not trusted from the communication network.

In an embodiment according to the first and the second aspects, the method is performed by or the device is a LI Security Engine.

In an embodiment according to the first and the second aspects, the method is performed by or the device is a LI Control Function.

In an embodiment according to the first and the second aspects, the method is performed by or the device is a LI Administration Function. In an embodiment according to the first and the second aspects, the entity is one of: a MDF, NF, ELI and I-ELI.

According to a third aspect, there is provided a computer program comprising instructions which, when executed on a device for a Lawful Interception system, cause the device to carry out a method according to any one of the embodiments of the first and/or the second aspects.

According to a fourth aspect, there is provided a computer program product comprising a computer readable storage means on which the computer program according to the third aspect is stored.

One or more embodiments of the present disclosure are associated with the following advantages:

Securing sensitive information in the trusted part of the communication network.

Isolating an untrusted part of the communication network.

- Enabling revocation actions according to severity of security breaches.

Quick response to a security breach.

- Enable in reducing total monitoring outage of the communication network.

- Enables automatic and dynamic trusted network management topology.

Improving trust in a communication network.

Synergies with Network Function Virtualization Infrastructure architecture which provides attestation mechanism.

BRIEF DESCRIPTION OF THE DRAWINGS

In what follows, example embodiments will be described in greater detail with reference to the accompanying drawings.

Figure 1 illustrates a Lawful Interception system in 5G according to one or more embodiments.

Figure 2 illustrates a sequence diagram of messages exchanged when a security breach in a network function is discovered according to one or more embodiments.

Figure 3 illustrates a sequence diagram of messages exchanged when a security breach in a mediation and delivery function is discovered according to one or more embodiments. Figure 4 illustrates a sequence diagram of messages exchanged for configuring a Lawful Interception system comprising an untrusted network function according to one or more embodiments.

Figure 5 illustrates a sequence diagram of messages exchanged for configuring a Lawful Interception system comprising an untrusted mediation and delivery function according to one or more embodiments.

Figure 6 illustrates a flowchart for performing actions when a security breach is detected, according to one or more embodiments.

Figure 7 illustrates a flowchart for configuring a Lawful Interception system according to one or more embodiments.

Figure 8 illustrates a method performed in a Lawful Interception system according to one or more embodiments.

Figure 9 illustrates a device in a Lawful Interception system according to one or more embodiments.

Figure 10 illustrates a device in a Lawful Interception system comprising at least one functional unit according to one or more embodiments.

All the figures are schematic, not necessarily to scale, and generally only show parts which are necessary in order to elucidate the respective embodiments, whereas other parts may be omitted or merely suggested. Any reference number appearing in multiple drawings refers to the same object or feature throughout the drawings, unless otherwise indicated.

DETAILED DESCRIPTION

As described above, the remote attestation flow is detailed for the NFV startup phase according to, for example, “Requirements for Network Functions” LI(22) P59032. At present, it is not clear what happens in a LI system if, for example, during the continuous measurement and monitoring of a VNF, the VNF becomes untrusted.

It is proposed herein a mechanism to assess the severity of a security breach in an entity or element of LI (ELI), and to perform actions to protect one or more other trusted entities of an LI system and/or to fix the security breach. An assessment of trust of an entity may be carried out by a verifier such as a policy rule engine that determines a trust score of the entity or ELI for which security is breached.

At least some embodiments of the present invention enable a continuous and automatic trust monitoring of one or more entities. At least some embodiments of the invention enable identifying a security breach in one or more entities, performing actions to isolate the breached entity, and maintaining trust of the LI system.

It is proposed herein a new X0 interface by which sensitive data may be communicated to one or more entities in the LI system. Using the X0 interface, a security breach may be addressed in an easier and faster manner. Additionally or alternatively, it is proposed to use the existing XI interface of the LI system for the purposes of addressing a security breach in the LI system. One or more embodiments propose a mechanism to communicate between LI entities in a trusted manner.

Thus, embodiments are proposed herein for enabling a mechanism to handle a security breach in an LI system or a communication network.

Figure 1 illustrates an LI system in a 5G network according to one or more embodiments. A similar LI system could potentially be used also in future generation networks, such as 6G networks. A communication network 200 comprises the LI system and the 5G/6G network, but it will be appreciated that the communication network 200 may include more parts than those shown in Figure 1.

Overview of LI system in a communication network

The communication network 200 of Figure 1 comprises one or more trust domains namely: Trust Domain A (TD-A), Trust Domain Bl (TD-B1), Trust Domain B2 (TD-B2), Trust Domain B3 (TD-B3) and Trust Domain C (TD-C). Elements belonging to the same trust domain may be trusted within that trust domain. For example, the LI Control Function (LICF) 102a and the Lawful Interception Certificate Authority (LICA) 102d are trusted within TD-B1. Similarly, the Mediation and Delivery Function (MDF) 103 and the Lawful Interception Routing Proxy Gateway (LRPG) 109 are trusted within the TD-B3. However, it may be that the elements belonging to different trust domains may not, as such, trust each other. As referred to herein, an element may be any hardware or software part of the LI system and/or part of any generic NF. An element may, for example, be the LICF 102a or the LRPG 109 or an Operation Support System (OSS) / Business Support System (BSS) 106 or a verifier 111. The trust domains, shown as dotted perimeter boxes in Figure 1, represent highest-level abstraction overlaid on the functions and interfaces of the communication network 200. Elements belonging to a trust domain have common trust attributes such as access control and confidentiality restrictions.

TD-A is a network trust domain that includes OSS/BSS 106 and all the standard network functions (NF), e.g. NF 104, that make up a communication network. Layer-wise included here are both the infrastructure/virtualization layer managed by the Management and Orchestration (MANO) / Container Infrastructure Service Management (CISM) 107, as well as the application layer NFs, implemented as virtual functions that actually provide the communication services to an end-user. The TD-A further comprises an ELI 105, an Intranetwork Element of LI (I-ELI) 105a, a LI Network Control (LINC) 108 and one or more attesters 110. The components or elements of the TD-A will be described later in the application.

TD-B (not shown in the Figure 1) is an LI trust domain. It comprises highly sensitive and correlated information on LI agencies, warrants, targets, and in-network Ll-cleared administrator accounts. Functions in this domain may be virtualized in their own segregated cloud for better isolation. The TD-B comprises the domains TD-B1, TD-B2 and TD-B3, shown in Figure 1.

TD-B1 includes a state of LI in the network (for example: warrant, targets, Law Enforcement Agencies (LEAs)). The TD-B1 may comprise an LI Administrative Function (ADMF) 102 and the LICF 102a. The TD-B1 may include the LI Certificate Management (LICM) function (not shown in the Figure 1) comprising the LI Certificate Authority (LICA) 102d which manages certificates for the LI domain. The TD-B1 may include a Relying Party function belonging to an attestation domain implemented as the device 100 as, for example, in Figure 1. The TD-B1 may further comprise a LI Security Engine (LISE) 102b. The components or elements of the TD-B1 will be described later in the application.

TD-B2 is a buffer domain that firewalls TD-B1 from the network at large. TD-B2 comprises LI Gateway (LIGW) 102e, which receives input via a standard, non-LI interface, and the LI Provisioning Function (LIPF) 102c, which firewalls LI functions distributed throughout the network. The components or elements of the TD-B2 will be described later in the application.

TD-B3 also belongs to the LI trust domain but differs in that it connects to LEAs outside the network. An MDF 103 in this domain may collect information from ELIs throughout the network, filter/format/package the information according to warrant parameters, and distribute the interception product to the requesting LEA. The TD-B3 may further comprise the LRPG 109 and at least one attester 110. The components or elements of the TD-B3 will be described later in the application.

TD-C may belong to an attestation trust domain and may also be part of the network domain TD-A. However, Ll-related attributes are managed and only visible to Ll-cleared administrators from TD-B. The TD-C may comprise a verifier 111 and a ground truth I l la unit. The components or elements of the TD-C will be described later in the application.

The LINC 108 converts MANO 107 events for the LI system. The LIGW 102e in the ADMF 102 takes a standard OSS-MANO interface and converts it into the LI domain. The I-ELI 105a consumes a standard network interface and produces an XI interface for the LI system.

The ADMF 102 is comprised in two trust domains TD-B1 and TD-B2. The ADMF comprises two top level functions, the LICF 102a and the LIPF 102c, along with the LICA 102d that plays the role of root of trust for the LI system.

LICF 102a manages the lifecycle of warrants and comprises the authoritative record of the most highly sensitive and correlated information on LI agencies, warrants, targets in the network. The LICF 102a also maintains and authorizes the lifecycles of all LI functions in the network, along with logs and audits.

The LISE 102b manages the network-wide security primitives (keys, nonces, salts, etc.) needed by the LI system functions. The LISE 102b may be the Relying Party (or the device 100) in the attestation layer.

LIPF 102c acts as a secure proxy between the LICF 102a and the rest of the network, facilitating provisioning and other LI events.

LICM (not shown in Figure) comprises a list of approved and revoked certificates in the network and includes the LICA 102d.

The LICA 102d is the root of trust of the LI system. This may be deployed as a stand-alone trust tree, or as an intermediate certificate authority (CA) to the root CA in the OSS/BSS 106. If the choice is made to implement the LICA 102d as an intermediate CA to the root OSS/BSS CA, the root OSS/BSS administrators may have to be fully trusted by the LI trust domain.

LIGW 102e is a function which translates a standard NFV interface for LI use. The NF 104 is a virtual network function that is composed into network services.

ELI 105 may perform an LI function, such as Points of Interception (POIs), Triggering Functions (TFs), Mediation and Delivery Functions (MDFs) as defined in, for example, 3 GPP TS 33.127 vl8.1.0 (2022-09).

I-ELI 105a is an ELI 105 that is comprised in the network and exposes towards a network element, and to the LI system. It queries or interacts with the NF similar to other elements, and interfaces with the LI system to communicate intercepted data.

The OSS/BSS 106 are the top-level functions in the network, from which the most fundamental events, such as spawning or creating a new function, may be initiated.

The MANO is part of the NFV architecture. The CISM performs its function alongside MANO 107.

The LINC 108 may convert MANO/CISM NFV events into events usable by the LI system overlay to ensure that the correct POIs are paired with the correct NFs both at the virtual and application layers. It translates virtual network outputs from ETSI NFV deployments, raw Kubernetes deployments, or others, into the standard Li -NO interface to the ADMF.

The MDF 103 may package the LI data coming from ELIs for delivery and fan-out to the requesting LEAs.

The LRPG 109 may hide the LEMF end point addresses and routing information from an overt network, that is not authorized to know about LI. The LRPG 109 may be placed at the edge of the NFV network/SDN where a physical hidden secure connection to the LEMF 112 may be implemented. The LRPG 109 may be placed at the edge of the NFV network/SDN when a dedicated LI SDN cloud connection may be established and which connection does not need to be visible to the Communication Service Provider (CSP) NFV network/SDN.

The Law Enforcement Monitoring Function (LEMF) 112 may be managed by the LEA and is outside the CSP network.

Attestation

An attestation environment or an attestation trust domain may comprise the relying party or the device 100, the verifier 111, and one or more attesters 110. In LI, the relying party may for example be the ADMF 102 or be comprised in the ADMF 102. The verifier I l l is part of an attestation environment that includes more than just LI. The attester 110 may for example be the ELI 105. The attester 110 may for example be comprised in the MDF 103 or the NF 104.

The attestation environment may perform the verification function by comparing the field information from the attester 110 against ground truth 11 la that is trusted.

In attestation, previous or historic measurement may be considered as the ground truth I l la. The previous measurement may, for example, be a verified hash of a vendor software image. The previous measurement may, for example, be related to an attester 110. The previous measurement may, for example, be related to an ELI 105 or an MDF 103 or an NF 104. The previous measurement may be stored in a secure database of the ground truth I l la. At every run, a state of a software image may be checked against the stored measurement and a decision may be made whether to run the software or not. The verifier 111 may then determine that a trusted software is running on trusted hardware. The verifier may use ground truth to appraise evidence and provide attestation results to the relying party or the device 100.

Interfaces

The Os-Ma-Nfvo interface may pass information from the OSS/BSS 106 to the MANO 107. It is a standard interface defined by ETSI NFV.

The Oss-LI interface may pass information received from OSS/BSS 106 through the LIPF 102c to the LI state machine in the LICF 102a.

The Ll-Operation Support (Li-Os) interface may be used for information exchanges between the MANO/CISM 107 and the LINC 108, which information include lifecycle management events, status information, security policy enforcement and VNF management information for network services. The ETSI NFV-defined interfaces that correspond to LI-Os may, for example, be Sc-Or and Sc- Vi.

The LLNetwork Output interface (Li-NO) may be used for information exchange between the LINC 108 and the state machine in the LICF 102a, through the LIPF 102c. The information may include lifecycle management events, status information, security policy enforcement and VNF management information for network services.

The LIPF-Control (LIPF-C) interface is used by the LICF 102a to control the LIPF 102c. The X0 interface prepare the ELIs 105, 105a to receive target identifiers by establishing trust, rooted in hardware, and attested remotely. It also is the interface over which the attestation system performs its functions.

The XI interface may provision the target and session level identifiers required to isolate, duplicate, and route the target communications towards the LEMF 112.

The X2 interface may convey Intercept Related Information (IRI) related to target communications from the network to the LEMF 112.

The X3 interface may convey Communication Content (CC) from the network to the LEMF 112.

The HI-1 interface may be used to send warrant and other interception request information between the LEA and the CSP. The LEA may send the warrant and the LEA may be represented by 113 in the Figure 1.

The HL2 interface may be used to send IRI from the MDF to the LEMF.

The HL3 interface may be used to send CC from the MDF to the LEMF.

The term entity

As used herein, the term entity 101 may refer to a software embedded in an NF for LI purposes. The entity 101 may, for example, be a software comprised in an element of the communication network 200. The entity 101 may, for example, be at least one of: an MDF 103, an NF 104, an ELI 105 and an I-ELI 105a. The entity 101 may, for example, be any hardware capable of running a software for LI purposes. The entity 101 may, for example, comprise the attester 110.

Example embodiments

The above paragraphs dealt with definitions and functions of the one or more elements of the communication network 200. The following paragraphs, firstly, briefly summarize the solution proposed herein according to one or more embodiments, while further aspects of the invention shall be described later in the application with respect to remainder of the Figures starting from Figure 2.

Each entity 101 (such as the MDF 103 or the NF 104) has an attester 110 that is connected to the verifier 111. The verifier 111 may check the trustworthiness of the entity 101 and inform the device 100 via the LIPF 102c about the trustworthiness of the entity 101. If the entity 101 is trustworthy, the LICF 102a may distribute the certification list via the LICM/LICA 102d. The LI system may be started once an initial trustworthiness of the one or more entities have been established.

In existing solutions, after the LI system is started, no recovery action is foreseen if the entity 101 becomes not trustworthy, even if the verifier 111 discovers a security breach and informs the device 100.

It is proposed herein a mechanism to handle the untrusted entities and/or address a security breach of the entity 101, when the LI system has already started functioning.

In further detail, the device 100 may be notified about the trust of an entity 101. The trust indication may be propagated to the LICF 102a. The LICF 102a or the device 100 comprised in the LICF 102a may evaluate that a security breach has occurred in the communication network 200 and may determine a severity of the security breach. Based on the level of severity of the security breach, the device 100 may perform actions to overcome the security breach. The procedure may further include rebuilding a complete and trustworthy LI system without the untrusted entity.

The LICF 102a information may be propagated to other trusted entities in the network via the LIPF 102c. New messages sent over the new X0 interface and/or new/existing messages sent over the XI interface may be used. In case X0 messages are used, a direct X0 connection between the LIPF 102c and other trusted entities may be introduced. Using the X0 interface, a security breach may be addressed in an easier and faster manner. The X0 interface may enable sending messages that indicate removal of untrusted entities from the communication network 200.

Figure 2 illustrates a sequence diagram of messages exchanged when a security breach is discovered according to one or more embodiments.

In Figure 2 is shown one or more actions performed in the communication network 200 when an entity such as the NF 104 is discovered as not trustworthy. The result of an evaluation of a security breach may be that the security breach is regarded as having high severity level or medium severity level or low severity level.

Step 1: After an initial positive attestation of the one or more entities 101 in the communication network 200, the connections among the entities are started and the LI system is running. The NF 104 and the MDF 103 may be connected via the X2 and X3 interfaces. Step 2: The NF 104 may be connected via the XI interface to the LIPF 102c.

Step 3: The NF 104 is connected via the X0 interface to the verifier 111. The verifier 111 may obtain information about the NF 104 and perform an attestation of the NF 104.

Step 4: During the attestation procedure, the verifier 111 may discover that the NF 104 is not trustworthy anymore. This may, for example, be based on the NF 104 information not matching the information stored in the ground truth I l la. The verifier 111 may send the attestation result to the LIPF 102c using the X0 interface. The attestation result may, for example, be obtained according to one or more procedures described above in relation Figure 1 under the section ‘Attestation’. The verifier 111 may include a trust score wherein the trust score is calculated based on the measurements described under the section ‘Attestation’. The attestation result may, for example, include one or more measurements performed on at least one of: the hardware, the operating system and the software code, of the entity 101.

Alternatively, the verifier 111 may send the attestation result comprising the one or more measurements to the LIPF 102c but not including the trust score. In this case, the trust score may be determined based on the one or more measurements.

Step 5: The LIPF 102c may forward the attestation result to the device 100 or the relying party via the X0 interface.

Step 6: The device 100 or the relying party may verify that the NF 104 is no longer trustworthy. The device 100 may verify this based on the attestation result received from the LIPF 102c. This may, for example, be based on determining that a trust score of the NF 104 is not reaching a threshold value. The threshold value may for example be a percentage value from the range 0% to 100%. The threshold value may for example be an integer. The trust score may, for example, be determined by the device 100 based on the one or more measurements received in the attestation result. As will be described further below in relation to Figure 8, the attestation result may for example include measurement information for one or more measurements performed on a hardware on which the entity is executing, and/or measurement information for one or more measurements performed on an operating system, OS, associated with the entity, and/or measurement information for one or more measurements performed on software code of the entity.

Alternatively, the trust score may be received from the verifier 111 via the LIPF 102c. That is, the attestation result from the LIPF 102c may include a trust score for the NF 104 and the device 100 may verify if the NF 104 is trustworthy or not based on the trust score. For example, the device 100 may verify that the NF 104 is not trusted based on the trust score not reaching a threshold value.

The device 100 may further inform the LICF 102a that the NF 104 is not trustworthy.

Step 7: The LICF 102a may evaluate that a security breach has occurred in the communication network 200 based on the indication that NF is not trustworthy. The LICF 102a may further evaluate a severity level of the security breach. The severity level or level of the security breach may, for example, be any one of low, medium and high. As an example, when the NF 104 is not trusted, the level of the security breach may be evaluated as high. In general, the more trustworthy the entity is, the lower the severity of security breach. In other words, a high trust score may indicate a low level of security breach and vice versa.

Step 8: The LICF 102a may then perform an action to address the security breach. The LICF 102a may, for example, raise an alarm in the communication network 200 depending on the level of the security breach to inform other trusted entities in the communication network 200, for example the MDF 103, about the security breach. The LICF 102a may, for example, stop the LI functionalities and/or inform the other trusted entities in the communication network 200 that the LI functionality is stopped.

Step 9: The LICF 102a may request the LIPF 102c to deactivate all tasks on the breached or untrusted NF 104. The task may relate to any LI task performed in relation to the NF.

Step 10: The LIPF 102c may send a DeactivateAllTasksRequest message to the untrusted NF 104 to request deactivation of one or more tasks related to the untrusted NF.

Step 11: The LICF 102a may request the LIPF 102c to revoke the connection to the untrusted NF 104. The LICF 102a may send a message instructing the LIPF 102c to revoke the connection to the untrusted NF 104. The message may further indicate discarding the traffic received from the untrusted NF 104. The message may, for example, be referred to as RemoveUntrustEliRequest message.

Step 12: The LIPF 102c may revoke the connection with the untrusted NF 104 using the XI interface, at the reception of the message. The ‘X’ in the Figure 2 depicts revoking or breaking of the connection. Step 13: The LIPF 102c may inform a trusted entity in the communication network 200 about the security breach. The LIPF 102c may forward the request to revoke the connection with the untrusted NF 104 and/or discard received traffic from the untrusted NF 104, to a trusted entity such as the MDF 103. At least step 13 enables a mechanism wherein a trusted entity is informed of an ongoing security breach in the communication network 200 as well as provided with instructions to handle the security breach, thereby improving security in the communication network 200.

Step 14: The trusted entity such as the MDF 103 may stop the X2 and X3 connections towards the untrusted NF 104, upon receiving the request to revoke the connection with the untrusted NF 104. The ‘X’ in the Figure 2 depicts revoking or breaking of the connection. The request message that is received may, for example, be referred as a RemoveUntrustEliRequest message. Table 1 describes example fields comprised in the RemoveUntrustEliRequest message.

Table 1. RemoveUntrustEliRequest message Step 15: The trusted entity such as the MDF 103 may respond to the LIPF 102c with a message acknowledging the execution of the connection revocation and discarding traffic from the untrusted NF 104. The response message may, for example, be referred as a RemoveUntrustEliResponse message. Table 2 describes example fields comprised in the RemoveUntrustEliResponse message. RequestState State of the received request. The Relying

Table 2. RemoveUntrustEliResponse message

Step 16: The LIPF 102c may forward the response message to the LICF 102a.

It may be noted that the action referred to in step 8 may in fact comprise one or more of the other steps 9-16 of Figure 2.

Figure 3 illustrates a sequence diagram of messages exchanged when a security breach is discovered according to one or more embodiments.

In Figure 3 is shown one or more actions performed in the communication network 200 when an entity such as the MDF 103 is discovered as not trustworthy. The result of an evaluation of a security breach may be that the security breach is regarded as having high severity level or medium severity level or low severity level.

Steps 1 to 8 of Figure 3 follow a similar procedure as Steps 1 to 8 of Figure 2 except that in Figure 3 the MDF 103 is an untrusted entity and the NF 104 is a trusted entity. The remaining steps of Figure 3 are described below.

Step 9: The LICF 102a may send a request message to the LIPF 102c requesting to revoke the connection to the untrusted entity such as the MDF 103. The request message may further indicate to stop sending traffic to the untrusted entity such as the MDF 103. The request message may, for example, be a RemoveUntrustEliRequest message as described in Table 1.

Step 10: The LIPF 102c at reception of the request message, may stop the XI connection with untrusted entity such as the MDF 103 and/or stop sending traffic to the untrusted entity such as the MDF 103. The ‘X’ in the Figure 3 depicts revoking or breaking of the connection.

Step 11: The LIPF 102 may forward the request to a trusted entity such as the NF 104, instructing to stop sending traffic to the untrusted entity such as the MDF 103.

Step 12: The trusted entity such as the NF 104 may stop the X2 and X3 connections towards the untrusted MDF 103, upon receiving the request. The ‘X’ in the Figure 3 depicts revoking or breaking of the connection. The request may, for example, be received as a RemoveUntrustEliRequest message as described in Table 1. Step 13: The trusted entity such as the NF 104 may respond to the LIPF 102c with a message acknowledging the execution of the connection revocation and stopping sending traffic to the untrusted MDF 103. The response message may, for example, be a RemoveUntrustEliResponse message as described in Table 2.

Step 14: The LIPF 102c may forward the response message to the LICF 102a.

Figure 4 illustrates a sequence diagram of messages exchanged for configuring a LI system according to one or more embodiments. More specifically, Figure 4 illustrates a mechanism for rebuilding a trustworthy system after a security breach has been detected. In this example, the NF1 104a is identified as not being trustworthy while the MDF 103 and the NF2 104b are trusted entities.

Note that the Steps illustrated in Figure 2 may be performed prior to the execution of the steps described in Figure 4.

Step 1: The LICF 102a may request the LIPF 102c to inform the MANO 107 about the security breach of the NF 104. The LICF 102a may further request an instantiation of a new trusted NF, for example NF2 104b.

Step 2: The LIPF 102c may inform the MANO about the security breach of the NF 104 and request an instantiation of the new trusted NF2 104b.

Step 3: The device 100 or the relying party may inform the LICF 102a that the new NF2 104b is trustworthy, after the new NF2 104b is created and its security is attested by the verifier 111 as in Figure 1.

Step 4: The LICF 102a may request the LICM/LICA 102d to produce an update of the certification list, wherein the IP address of the untrusted NF1 104a is removed and the IP address of the trusted NF2 104b is added to the list. The updated certification list may further be provided to other trusted entities in the communication network 200.

Step 5: The LICM 102d may update the certification list with the allowed NF IP address, removing the NF 1 104a IP address and adding NF2 104b IP address. The updated certification list may be sent to the MDF 103.

Step 6: The LICF 102a may send a request message to the LIPF 102c requesting deactivation of all the tasks related to the untrusted NF 1 104a. Step 7: The LIPF 102c may send the untrusted NF1 104a a message instructing deactivation of all existing tasks using existing XI interface. The message may, for example, be a DeactivateAllTasksRequest message. A Task may be a monitoring order that an LI, e.g. ADMF 102, receives from the LEA and forwards to an NF, e.g. NF1 104a or NF2 104b. A task may include an identity for which the NF may report xIRI or xCC to the MDF 103. The ADMF 102 may comprise a database with all active tasks. It may not be needed to wait for a response message, since the NF 1 104a is not trustworthy anymore.

Step 8: The LICF 102a may update the certification list with the allowed NF IP address, removing the NF 1 104a IP address and adding NF2 104b IP address. The LICF 102a may send the certification list comprising allowed IP addresses to the LIPF 102c.

Step 9: The LIPF 102c may revoke the connection to the untrusted NF1 104a over the XI interface. The ‘X’ in the Figure 4 depicts revoking or breaking of the connection.

Step 10: The LIPF 102c may start a new connection to the trusted NF2 104b.

Step 11: The MDF 103 may receive the allowed IP address list from the LIPF 102c.

Step 12: The MDF 103 may revoke the connection with the untrusted NF1 104a over the X2 and X3 interfaces. The ‘X’ in the Figure 4 depicts revoking or breaking of the connection.

Step 13: The MDF 103 may initiate a new connection with the trusted NF2 104b over the X2 and X3 interfaces.

Step 14: The MDF 103 may send a message to the LIPF 102c acknowledging the inclusion of the NF2 104b IP address in the Allowed NF IP address list. The MDF 103 may further acknowledge setting up a connection with the NF2 104b over the X2 and X3 interfaces.

Step 15: The LIPF 102c may forward the acknowledgment message from the MDF 103 to the LICF 102a.

Step 16: The LICF 102a may request the LIPF 102c to activate all existing tasks on the trusted NF2 104b, using existing XI messages. When a new trusted NF2 104b is created, the ADMF 102 or the LIPF 102c may provide to the new trusted NF2 104b all tasks that were previously requested (existing) by the LEA. This is done to align the new trusted NF2 104b in the communication network. After that when the LEA requests a new monitoring order, another task is activated and forwarded to the new trusted NF2 104b. Step 17: The LIPF 102c may send one or more ActivateTaskRequest messages to the trusted NF2 104b and may cease the waming/alarm previously raised for the security breach.

It may be noted that the messages between the LICF 102a and the LIPF 102c as well as among the LIPF 102c and the MDF 103 may be exchanged via Xl intemal interface.

Figure 5 illustrates a sequence diagram of messages exchanged for configuring a Lawful Interception system according to one or more embodiments. More specifically, Figure 5 illustrates a mechanism for rebuilding a trustful system after a security breach has been detected.

Note that the steps illustrated in Figure 3 may be performed prior to the execution of the steps described in Figure 5. In this example, the MDF1 103a may not be trusted while the MDF2 103b and the NF 104 may be trusted.

Step 1: The LICF 102a may instantiate a new trusted MDF, for example MDF2 103b.

Step 2: The device 100 or the relying party may inform the LICF 102a that the new MDF2 103b is trustworthy, after the new MDF2 103b is created and its security is attested by the verifier 111.

Step 3: The LICF 102a may request the LICM/LICA 102d to produce an update of the certification list, wherein the IP address of the untrusted MDF1 103a is removed and the IP address of the trusted MDF2 103b is added to the list. The updated certification list may further be provided to other trusted entities in the communication network 200.

Step 4: The LICM 102d may update the certification list with the allowed MDF IP address, removing the MDF1 103a IP address and adding MDF2 103b IP address. The updated certification list may be sent to the NF 104.

Step 5: The LICF 102a may update the certification list with the allowed MDF IP address, removing the MDF1 103a IP address and adding MDF2 103b IP address. The LICF 102a may send the certification list comprising allowed IP addresses to the LIPF 102c.

Step 6: The LIPF 102c may revoke the connection to the untrusted MDF1 103a. The ‘X’ in the Figure 5 depicts revoking or breaking of the connection.

Step 7: The LICF 102a may request the LIPF 102c to modify the destination address from the untrusted MDF1 103a to trusted MDF2 103b in order to send all IRI/CC to the trusted MDF2 103b. Step 8: The LIPF 102c may initiate a new connection with the trusted MD2 over the XI interface.

Step 9: The LIPF 102c may forward the request to modify the destination address to the NF 104. The request may be included in a ModifyDestinationRequest message. The ModifyDestinationRequest may comprise a Destination Identifier (DID) that identifies a destination and a delivery address. The fields comprised in the ModifyDestinationRequest may, for example, be found in ETSI TS 103 221-1 VI.11.1 (2022-03), Clause 6.1.3.2, Table 15. The ModifyDestinationRequest message may thus be used to modify or change the IP address of a previously defined DID. For example, using the ModifyDestinationRequest message, the IP address of MDF2 may be associated with a MDF1 DID wherein the MDF1 DID indicates the identifier previously used for MDF1. It may be noted that at least one task that is active on the NF has an associated DID, so changing an address (e.g. IP address) associated to the DID automatically changes the address of all tasks.

Step 10: The NF 104 may revoke the connection with the untrusted MDF1 103a over the X2 and X3 interfaces. The ‘X’ in the Figure 5 depicts revoking or breaking of the connection.

Step 11: The NF 104 may establish a new connection with the trusted MDF2 103b over the X2 and X3 interfaces.

Step 12: The NF 104 may send a message to the LIPF 102c acknowledging the inclusion of the MDF2 103b IP address in the Allowed NF IP address list. The NF 104 may further acknowledge setting up a connection with the MDF2 103b over the X2 and X3 interfaces.

Step 13: The LIPF 102c may forward the acknowledgment message from the NF 104 to the LICF 102a.

It may be noted that the messages between the LICF 102a and the LIPF 102c may be exchanged via Xl intemal interface.

Figure 6 illustrates a flowchart for performing actions when a security breach is detected, according to one or more embodiments.

At 600, the LI system is started.

At 601, the device 100 may obtain the indication of trust, for example, from the verifier 111. At 602, the device 100 may evaluate if a security breach has occurred in the communication network 200 or the LI system.

At 603, the device 100 may determine a level of security breach in the communication network 200. The device 100 may perform actions depending on a level of the security breach in the communication network 200. The level of the security breach may for example be one of: low, medium and high.

Low level security breach

At 604, the device 100 may perform an action of raising an alarm to inform about the detected security breach. The alarm may indicate a level of the security breach. For example, the alarm may include an indication Tow’ to indicate a low level security breach. The alarm may indicate a priority level for an action to be performed to address the security breach.

At 605, the device 100 may perform an action of inserting in all IRI/CC to be sent to LEMF, a flag indicating a possible data corruption due to the security breach.

Medium level security breach

At 606, the device 100 may perform an action of raising an alarm to inform about the detected security breach. The alarm may indicate a level of the security breach. For example, the alarm may include an indication ‘medium’ to indicate a medium level security breach. The alarm may indicate a priority level for an action to be performed to address the security breach.

At 607, the device 100 may further initiate the storing of the IRI/CC in a buffer. The IRI/CC may be analyzed before sending the IRI/CC to the LEMF. The device 100 may further initiate storing of all the xIRI/xCC to be sent to LEMF in a buffer. The LEMF may not receive IRI/CC until the security breach is fixed.

At 608, the LI may continue to work with the limitation due to the low level and/or medium level security breach until a new LI secure network is started, for example according to procedures described above in Figure 4 and 5.

High level security breach

At 609, the device 100 may perform an action of raising an alarm to inform about the detected security breach. The alarm may indicate a level of the security breach. For example, the alarm may include an indication ‘high’ to indicate a high level security breach. The alarm may indicate a priority level for an action to be performed to address the security breach. The device 100 may further inform that all IRI/CC are lost.

Depending on the entity that is breached, the device 100 may perform different actions. This is illustrated by 610.

At 611, in case of security breach in the NF 104, the device 100 may request to the LIPF 102c to deactivate all tasks in the breached NF via the existing XI message.

At 612, in case of security breach in the NF 104, the device 100 may request to the LIPF 102c to discard received traffic from breached NF, via new X0 message.

At 613, in case of security breach in the MDF 103, the device 100 may request to the LIPF 102c, via new X0 message, to stop sending traffic to the breached MDF.

At 614, the LI may stop working due to the breach until a new secure LI system is started.

Figure 7 illustrates a flowchart for configuring a Lawful Interception system according to one or more embodiments. It may be noted that procedure of Figure 7 may take place after Step 608 of Figure 6 (which corresponds to Step 701 of Figure 7) and/or Step 614 of Figure 6 (which corresponds to Step 702 of Figure 7).

The device 100 may perform other actions to create a new trustworthy LI system. The actions may for example be related to the type of the breached entity 101. This is illustrated by 703.

NF security breach

At 704, the device 100 may inform the MANO 107 about the NF breach and request to fix the security breach by starting a new NF.

At 705, the device may wait for the MANO 107 to start the new NF.

At 706, when new trustworthy NF is available:

- At 707, the device 100 may request via XI message to delete all tasks on the breached NF.

- At 708, the device 100 may request to generate new allowed IP address list.

- At 709, the device 100 may send the generated list to the LIPF 102c to propagate to all trusted entities.

- At 710, the device may request to the LIPF 102c to activate one or more tasks on the new trustworthy NF via existing XI messages. At 717, the warning and/or alarm may be ceased if the security breach has been addressed.

At 718, the LI system may be restarted after the security breach and/or after a new trusted entity has been instantiated.

MDF security breach

At 711, the device 100 may start a new MDF 103.

At 712, the device may wait for the MANO 107 to start the new trusted MDF 103.

At 713, when new trusted MDF is available:

- At 714, the device 100 may generate new allowed IP address list.

- At 715, the device 100 may send the generated list to the LIPF 102c to be propagated to all trusted entities.

- At 716, the device 100 may request to the LIPF 102c to change destination from breached MDF to the new trustworthy MDF via existing message sent on the XI interface.

At 717, the warning and/or alarm may be ceased if the security breach has been addressed.

At 718, the LI system may be restarted after the security breach and/or after a new trusted entity has been instantiated.

Figure 8 illustrates a method performed in a Lawful Interception system according to one or more embodiments. The method comprises: at Step S800, obtaining an indication of trust regarding an entity operating in a communication network 200; at Step S801, evaluating a security breach associated with the entity based on the indication; and

- based on the evaluation of the security breach, at Step S802, performing an action to manage the security breach.

Steps 4 and 5 of Figures 2 and 3 are examples of Step S800. Further, step 601 of Figure 6 is also an example of Step S800.

Step 7 of Figures 2 and 3 is an example of Step S801. Further, step 602 of Figure 6 is also an example of Step S801. Steps 8-16 of Figure 2 and steps 8-14 of Figure 3 are examples of Step S802. Steps 3, 5, 6 and 8 of Figure 4 are examples of Step S802. Steps 2,4,5 and 7 of Figure 5 are examples of Step S802. Steps 604-614 of Figure 6 are also examples of Step S802. Steps illustrated in Figure 7 are also examples of Step S802.

In one or more embodiments, the indication of trust is a trust score. The trust score may for example be a percentage value from the range 0% to 100%. The trust score may for example be an integer.

In one or more embodiments, evaluating the security breach comprises checking whether the trust score is below a threshold value. Step 6 of Figures 2 and 3 is an example of this step.

In one or more embodiments, the indication of trust includes at least one of the following: measurement information for one or more measurements performed on a hardware on which the entity is executing; measurement information for one or more measurements performed on an operating system, OS, associated with the entity; and measurement information for one or more measurements performed on software code of the entity.

The measurement on the hardware may be performed by calling the hardware application programming interface (API) and obtaining the signature of the hardware.

The measurement information for measurements performed on the OS may comprise at least one of: OS version, enclave version, and installation or onboarding date. The OS may, for example, run the entity 101 (for example the NF 104).

The measurement information for measurements performed on the software code may include a hash of the image of the entity’s software code as installed in an enclave.

In one or more embodiments, evaluating the security breach comprises determining a level of the security breach. Step 7 of Figures 2 and 3, step 603 of Figure 6 are examples of this step.

In one or more embodiments, the level of the security breach is at least one of: low, medium and high. In general, there may be any number of levels defined, for example, 2 levels, 3 levels, or more than 3 levels. A level may be defined for a range of values falling between an upper threshold and a lower threshold. As an example, a low level security breach may be defined by a trust score falling within a range of values on a scale of 0-100. It will be appreciated that the levels of security breach could also be called other things than low, medium, and high, such as a first level, a second level, a third level, etc.

In one or more embodiments, the indication of trust includes measurement information for one or more measurements performed on software code of the entity and a low level security breach is determined based on one or more failures of a validation of the measurements performed on software code of the entity. A failure of a validation of measurements performed on software code of the entity may be regarded as less serious than if the hardware or the operating system were compromised, so a low level security breach may be appropriate.

In one or more embodiments, the indication of trust includes measurement information for one or more measurements performed on an operating system, OS, associated with the entity, and a medium level security breach is determined based on a failure of a validation of the one or more measurements performed on the OS. A failure of a validation of measurements performed on the operating system may be regarded as less serious than if the hardware were compromised, so a medium level security breach may be appropriate.

In one or more embodiments, the indication of trust includes measurement information for one or more measurements performed on software code of the entity, and a medium level security breach is determined based on at least one of the following: a pre-defined number of failures of a validation of the one or more measurements performed on the software code of the entity within a pre-defined time period; a number of simultaneous failures of a validation of the one or more measurements performed on the software code of the entity.

In one or more embodiments, the indication of trust includes measurement information for one or more measurements performed on a hardware on which the entity is executing, and a high level security breach is determined based on a failure of a validation of the one or more measurements performed on the hardware. A failure of a validation of measurements performed on the hardware may be regarded as a serious security breach, so a high level security breach may be appropriate.

In one or more embodiments, the indication of trust includes measurement information for one or more measurements performed on software code of the entity, and a high level security breach is determined based on at least one of the following: a pre-defined number of failures of a validation of the one or more measurements performed on the software code of the entity within a pre-defined time period; a number of simultaneous failures of a validation of the one or more measurements performed on the software code of the entity.

In one or more embodiments, the indication of trust includes measurement information for one or more measurements performed on an operating system, OS, associated with the entity, and wherein a high level security breach is determined based on at least one of the following: a pre-defined number of failures of a validation of the one or more measurements performed on the OS within a pre-defined time period; a number of simultaneous failures of a validation of the one or more measurements performed on the OS.

In one or more embodiments, the action is performed based on the level of the security breach. Steps 603-614 of Figure 6 are examples of this step.

In one or more embodiments, evaluating the security breach comprises determining that the security is breached and that the entity is not trusted.

In one or more embodiments, performing the action comprises sending a control signal to indicate at least one action to be performed. As an example, the device 100 may send the LICF 102a the control to indicate which action to be performed.

In one or more embodiments, the step S802 of performing the action comprises at least one of sending an alarm in the communication network 200 informing about the security breach. Steps 604, 606 and 609 Figure 6 are examples of this step; inserting an indication in IRI or CC informing that a security breach is ongoing and that the IRI or CC may not be trusted. Step 605 of Figure 6 is an example of this step; storing at least one X2 IRI, xIRI, or X3 CC, xCC, received from the entity in a buffer for analysis before sending the IRI/CC to a LEMF. Step 607 of Figure 6 is an example of this step; discarding information from the entity and/or refraining from sending information to the entity. Steps 612 and 613 of Figure 6 are examples of this step; and sending a new certification list to one or more other entities in the communication network wherein the new certificate list does not list an Internet Protocol, IP, address of the entity. Step 4 of Figure 4, Step 5 of Figure 5, Step 709 and Step 715 of Figure 7 are examples of this step.

The action at step S802 may for example be performed by at least one of: the device 100, ADMF 102 and LICF 102a. The alarm may for example indicate a level of security breach. The indication in the IRI or CC may, for example, be a flag.

In one or more embodiments, the entity is an ELI 105 and performing the action comprises sending a new certificate list to one or more other entities in the communication network, wherein the new certificate list does not list an IP address of the entity. Step 5 of Figure 4, Step 4 of Figure 5, Step 709 and Step 715 of Figure 7 are examples of this step.

In one or more embodiments, the entity is an MDF, and performing the action comprises sending a message instructing forwarding of all traffic from the untrusted MDF to a trusted MDF. Step 7 of Figure 5 and Step 716 of Figure 7 are examples of this step.

In one or more embodiments, the entity is a Network Function, NF, and wherein performing the action comprises sending a message instructing a cancellation of a task without waiting for a response message. Step 6 and Step 7 of Figure 4, Step 611 of Figure 6 and Step 707 of Figure 7 are examples of this step.

In one or more embodiments, the action is performed using the XI interface.

In one or more embodiments, performing the action comprises sending a request message over the X0 interface.

In one or more embodiments, the request message is a message indicating removal of an entity from the communication network, and the request message comprises a command field. The removal of entity may, for example, include at least one of: disconnecting the entity from the communication network, disconnecting a connection with the entity, terminating the software execution of the entity, isolating the execution of the entity and decommissioning of the hardware on which the entity is executing.

In one or more embodiments, the command field comprises a value indicating discarding traffic from the entity when the entity is a NF that is not trusted and wherein the request message is sent to one or more trusted entities. Step 11 and Step 13 of Figure 2, Step 612 of Figure 6 are examples of this step. The trusted entity may for example be a trusted MDF or a trusted NF. In one or more embodiments, the command field comprises a value indicating stopping traffic to or from the entity when the entity is a MDF that is not trusted and wherein the request message is sent to one or more trusted entities. Step 9 and Step 11 of Figure 3, Step 613 of Figure 6 are examples of this step. The trusted entity may for example be a trusted MDF or a trusted NF.

In one or more embodiments, the method comprises receiving a response message acknowledging the reception of the request message. Step 15 of Figure 2 and Step 13 of Figure 3 are examples of this step.

In one or more embodiments, the step S802 of performing the action comprises: revoking a connection with the entity that is not trusted. Steps 11-13 of Figure 2, Steps 9-10 of Figure 3, Step 9 of Figure 4, Step 6 of Figure 5 are examples of this step.

The step S802 of performing the action may further comprise establishing a connection with a new entity, wherein the new entity is trusted. Step 10 of Figure 4 and Step 8 of Figure 5 are examples of this step.

In one or more embodiments, the connection is revoked by sending a message indicating removal of the entity that is not trusted entity from the communication network and the establishing the connection comprises receiving an acknowledgment message from the new trusted entity.

In one or more embodiments, the step S802 of performing the action comprises: establishing a new entity to substitute the entity that is not trusted, wherein the new entity is trusted. Steps 711 and 712 of Figure 7 are examples of this step. or sending a request to a MANO 107 node to establish a new entity, wherein the new entity is trusted. Steps 704 and 705 of Figure 7 are examples of this step.

In one or more embodiments, the step S802 of performing the action comprises removing the entity that is not trusted from the communication network 200.

In one or more embodiments, the method is performed by a LISE 102b.

In one or more embodiments, the method is performed by a LICF 102a.

In one or more embodiments, the method is performed by a ADMF 102. In one or more embodiments, the entity is one of: a MDF 103, NF 104, ELI 105, and ELI 105a.

Figure 9 illustrates a device 100 for use in a Lawful Interception (LI) system according to one or more embodiments. It will be appreciated that although the device 100 is intended for use in a LI system, the device 100 may be located elsewhere before or after being used in the LI system. The device 100 may be comprised in one or more of the following: a LISE 102b, a LICF 102a, a LIPF 102c, an ADMF 102, a trust domain Bl, a trust domain B and an LI system. As such, the device 100 may also be any of the following: the LISE 102b, the LICF 102a, the LIPF 102c and the ADMF 102. The device 100 may comprise the LICA/LICM 102d, the LICF 102a and the LIPF 102c.

Referring to Figure 9, the device 100 may have storage and/or processing capabilities. The device 100 may be configured to control any one of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed. The device 100 may comprise processor 903. Processor 903 corresponds to one or more processors for performing the device 100 functions described herein. The device 100 may include memory 901 or computer readable storage medium 901 that is configured to store data, programmatic software code and/or other information described herein. In particular, in addition to a traditional processor 903 and memory 901, the device 100 may comprise integrated circuitry for processing and/or control, for example, one or more processors and/or processor cores and/or Field Programmable Gate Array (FPGAs) and/or Application Specific Integrated Circuitry (ASICs) adapted to execute instructions. The processor(s) 903 may be configured to access, for example, write to and/or read from the memory 901 or the computer readable storage medium 901, which may comprise any kind of volatile and/or non-volatile memory, for example, cache and/or buffer memory and/or Random Access Memory (RAM) and/or Read- Only Memory (ROM) and/or optical memory and/or Erasable Programmable Read-Only Memory (EPROM).

The memory 901 or the computer readable storage medium 901 may include instructions which, when executed by the one or more processors 903, cause the device 100 to perform the processes described herein with respect to the device 100, for example method(s) described in relation to Figures 1-8. The instructions may be software (SW) or a computer program associated with the device 100.

Thus, the device 100 may further comprise SW or a computer program, which is stored in, for example, the memory 901 or the computer readable storage medium 901 at the device 100, or stored in external memory, for example, database, accessible by device 100. The SW or computer program 902 may be executable by the one or more processors 903.

A computer program product (CPP) 904 in the form of a computer readable storage medium 901 may comprise any form of volatile or non-volatile computer readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, RAM, ROM, mass storage media (for example, a hard disk), removable storage media, for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD), and/or any other volatile or non-volatile, non-transitory device readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by one or more processors 903. Computer readable storage medium 901 may store any suitable instructions, data or information, including a computer program, software, an application including one or more of logic, rules, code, tables, etc. and/or other instructions capable of being executed by one or more processors 903. Computer readable storage medium 901 may be used to store any calculations made by one or more processors 903. In some embodiments, one or more processors 903 and the memory/computer readable storage medium 901 may be considered to be integrated.

Figure 10 illustrates a device for use in a Lawful Interception system comprising at least one functional unit according to one or more embodiments. It will be appreciated that although the device 100 is intended for use in a LI system, the device 100 may be located elsewhere before or after being used in the LI system.

Figure 10 discloses a device 100 which comprises functional units 1000A, 1000B, and 1000C. Referring to Figure 10, in general terms, each functional unit 1000A, 1000B, and 1000C, i.e. the obtain unit 1000 A, the evaluate unit 1000B and the perform unit 1000C, may be implemented in hardware or in software. Preferably, one or more or all functional units 1000A- 1000C may be implemented by the one or more processors 903, possibly in cooperation with the computer readable storage medium 901 or the memory 901. The one or more processors 903 may thus be arranged to fetch instructions, from the computer readable storage medium 901 or the memory 901, as provided by a functional unit 1000A-1000C and to execute these instructions, thereby performing any steps of the device 100 as disclosed herein, for example steps disclosed in relation to Figures 1-8. More specifically, in an embodiment, the obtain unit 1000 A is configured to perform step S800 of Figure 8. Further, the evaluate unit 1000B is configured to perform step S801 of Figure 8. Furthermore, the perform unit 1000C is configured to perform the steps S802 of Figure 8.

The person skilled in the art realizes that the proposed approach presented in the present disclosure is by no means limited to the preferred embodiments described above. On the contrary, many modifications and variations are possible. For example, the methods described above with reference to Figs. 2-8 may be combined to form further embodiments.

Additionally, variations to the disclosed embodiments can be understood and effected by those skilled in the art. It will be appreciated that the word "comprising" does not exclude other elements or steps, and that the indefinite article "a" or "an" does not exclude a plurality. The word “or” is not to be interpreted as an exclusive or (sometimes referred to as “XOR”). On the contrary, expressions such as “A or B” covers all the cases “A and not B”, “B and not A” and “A and B”. The mere fact that certain measures are recited in mutually different dependent embodiments does not indicate that a combination of these measures cannot be used to advantage.