WO2024080901A1 - Gestion de sécurité dans un système d'interception légale - Google Patents

Gestion de sécurité dans un système d'interception légale Download PDF

Info

Publication number
WO2024080901A1
WO2024080901A1 PCT/SE2022/050935 SE2022050935W WO2024080901A1 WO 2024080901 A1 WO2024080901 A1 WO 2024080901A1 SE 2022050935 W SE2022050935 W SE 2022050935W WO 2024080901 A1 WO2024080901 A1 WO 2024080901A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
trusted
security breach
measurements performed
indication
Prior art date
Application number
PCT/SE2022/050935
Other languages
English (en)
Inventor
Chiara SANTELLA
Daniele GAITO
Ilaria GUARINI
Lorenzo Giuseppe ELISIO
Raffaele De Santis
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/SE2022/050935 priority Critical patent/WO2024080901A1/fr
Publication of WO2024080901A1 publication Critical patent/WO2024080901A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/80—Arrangements enabling lawful interception [LI]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/30—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information
    • H04L63/306—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information intercepting packet switched data communications, e.g. Web, Internet or IMS communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/082—Access security using revocation of authorisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/66—Trust-dependent, e.g. using trust scores or trust relationships

Definitions

  • the present disclosure relates to handling of security breaches in a Lawful Interception system.
  • 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.
  • 5G Fifth Generation
  • 6G Sixth Generation
  • 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.
  • VNF Virtual Network Functions
  • NFV Network Function Virtualization
  • An object of the invention is to improve security handling in a communication network.
  • a method performed in a Lawful Interception, LI, system 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.
  • 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.
  • the indication of trust is a trust score.
  • evaluating the security breach comprises checking whether the trust score is below a threshold value.
  • 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.
  • evaluating the security breach comprises determining a level of the security breach.
  • the level of the security breach is at least one of: low, medium and high.
  • 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.
  • 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.
  • 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
  • the action is performed based on the level of the security breach.
  • evaluating the security breach comprises determining that the security is breached and that the entity is not trusted.
  • performing the action comprises sending a control signal to indicate at least one action to be performed.
  • 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.
  • IRI Intercept Related Information
  • CC Content of Communication
  • 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.
  • 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.
  • 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.
  • the action is performed using the XI interface.
  • performing the action comprises sending a request message over the X0 interface.
  • the request message is a message indicating removal of an entity from the communication network, the request message comprising a command field.
  • 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.
  • the method comprises receiving a response message acknowledging the reception of the request message.
  • 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.
  • 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.
  • 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.
  • MANO Management and Orchestration
  • performing the action comprises removing the entity that is not trusted from the communication network.
  • the method is performed by or the device is a LI Security Engine.
  • the method is performed by or the device is a LI Control Function.
  • the method is performed by or the device is a LI Administration Function.
  • the entity is one of: a MDF, NF, ELI and I-ELI.
  • 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.
  • a computer program product comprising a computer readable storage means on which the computer program according to the third aspect is stored.
  • 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.
  • the remote attestation flow is detailed for the NFV startup phase according to, for example, “Requirements for Network Functions” LI(22) P59032.
  • LI(22) P59032 the remote attestation flow is detailed for the NFV startup phase according to, for example, “Requirements for Network Functions” LI(22) P59032.
  • ELI entity or element of LI
  • 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.
  • a new X0 interface by which sensitive data may be communicated to one or more entities in the LI system.
  • a security breach may be addressed in an easier and faster manner.
  • One or more embodiments propose a mechanism to communicate between LI entities in a trusted manner.
  • 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.
  • 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.
  • the LI Control Function (LICF) 102a and the Lawful Interception Certificate Authority (LICA) 102d are trusted within TD-B1.
  • the Mediation and Delivery Function (MDF) 103 and the Lawful Interception Routing Proxy Gateway (LRPG) 109 are trusted within the TD-B3.
  • the elements belonging to different trust domains may not, as such, trust each other.
  • 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.
  • the 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.
  • LI Security Engine LISE
  • 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.
  • LIGW LI Gateway
  • LIPF LI Provisioning Function
  • 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.
  • CA certificate authority
  • 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).
  • 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).
  • POIs Points of Interception
  • TFs Triggering Functions
  • MDFs Mediation and Delivery Functions
  • 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.
  • CSP Communication Service Provider
  • the Law Enforcement Monitoring Function (LEMF) 112 may be managed by the LEA and is outside the CSP network.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • IRI Intercept Related Information
  • the X3 interface may convey Communication Content (CC) from the network to the LEMF 112.
  • CC Communication Content
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • the verifier 111 may send the attestation result comprising the one or more measurements to the LIPF 102c but not including the trust score.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • Step 16 The LIPF 102c may forward the response message to the LICF 102a.
  • 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.
  • 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.
  • the NF1 104a is identified as not being trustworthy while the MDF 103 and the NF2 104b are trusted entities.
  • 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.
  • 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.
  • 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.
  • the steps illustrated in Figure 3 may be performed prior to the execution of the steps described in Figure 5.
  • 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.
  • DID Destination Identifier
  • 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.
  • 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.
  • an address e.g. IP address
  • 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.
  • 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.
  • the device 100 may obtain the indication of trust, for example, from the verifier 111.
  • the device 100 may evaluate if a security breach has occurred in the communication network 200 or the LI system.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the device 100 may perform different actions. This is illustrated by 610.
  • the device 100 may request to the LIPF 102c to deactivate all tasks in the breached NF via the existing XI message.
  • the device 100 may request to the LIPF 102c to discard received traffic from breached NF, via new X0 message.
  • the device 100 may request to the LIPF 102c, via new X0 message, to stop sending traffic to the breached MDF.
  • 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.
  • the device 100 may inform the MANO 107 about the NF breach and request to fix the security breach by starting a new NF.
  • the device may wait for the MANO 107 to start the new NF.
  • the device 100 may request via XI message to delete all tasks on the breached NF.
  • the device 100 may request to generate new allowed IP address list.
  • the device 100 may send the generated list to the LIPF 102c to propagate to all trusted entities.
  • the device may request to the LIPF 102c to activate one or more tasks on the new trustworthy NF via existing XI messages.
  • the warning and/or alarm may be ceased if the security breach has been addressed.
  • the LI system may be restarted after the security breach and/or after a new trusted entity has been instantiated.
  • the device 100 may start a new MDF 103.
  • the device may wait for the MANO 107 to start the new trusted MDF 103.
  • the device 100 may generate new allowed IP address list.
  • the device 100 may send the generated list to the LIPF 102c to be propagated to all trusted entities.
  • 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.
  • the warning and/or alarm may be ceased if the security breach has been addressed.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • API hardware application programming interface
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the action is performed based on the level of the security breach. Steps 603-614 of Figure 6 are examples of this step.
  • evaluating the security breach comprises determining that the security is breached and that the entity is not trusted.
  • performing the action comprises sending a control signal to indicate at least one action to be performed.
  • the device 100 may send the LICF 102a the control to indicate which action to be performed.
  • 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.
  • 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.
  • the entity is an MDF
  • 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.
  • 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.
  • the action is performed using the XI interface.
  • performing the action comprises sending a request message over the X0 interface.
  • the request message is a message indicating removal of an entity from the communication network
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the step S802 of performing the action comprises removing the entity that is not trusted from the communication network 200.
  • the method is performed by a LISE 102b.
  • the method is performed by a LICF 102a.
  • the method is performed by a ADMF 102.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • RAM random Access Memory
  • ROM Read- Only Memory
  • EPROM Erasable Programmable Read-Only Memory
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Technology Law (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé mis en œuvre dans un système d'interception légale, LI. Le procédé comprend l'obtention (S800) d'une indication de confiance concernant une entité (101) fonctionnant dans un réseau de communication (200). Le procédé comprend l'évaluation (S801) d'une brèche de sécurité associée à l'entité sur la base de l'indication. Le procédé comprend en outre, sur la base de l'évaluation de la brèche de sécurité, l'exécution (S802) d'une action pour gérer la brèche de sécurité.
PCT/SE2022/050935 2022-10-14 2022-10-14 Gestion de sécurité dans un système d'interception légale WO2024080901A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SE2022/050935 WO2024080901A1 (fr) 2022-10-14 2022-10-14 Gestion de sécurité dans un système d'interception légale

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2022/050935 WO2024080901A1 (fr) 2022-10-14 2022-10-14 Gestion de sécurité dans un système d'interception légale

Publications (1)

Publication Number Publication Date
WO2024080901A1 true WO2024080901A1 (fr) 2024-04-18

Family

ID=84044192

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2022/050935 WO2024080901A1 (fr) 2022-10-14 2022-10-14 Gestion de sécurité dans un système d'interception légale

Country Status (1)

Country Link
WO (1) WO2024080901A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10033756B1 (en) * 2017-10-26 2018-07-24 Hytrust, Inc. Methods and systems for holistically attesting the trust of heterogeneous compute resources
WO2018143845A1 (fr) * 2017-02-06 2018-08-09 Telefonaktiebolaget Lm Ericsson (Publ) Sécurité d'interception légale

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018143845A1 (fr) * 2017-02-06 2018-08-09 Telefonaktiebolaget Lm Ericsson (Publ) Sécurité d'interception légale
US10033756B1 (en) * 2017-10-26 2018-07-24 Hytrust, Inc. Methods and systems for holistically attesting the trust of heterogeneous compute resources

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
3GPP TS 33.127, September 2022 (2022-09-01)
OTD: "ETSI TS 101 158TelecoRequirements for Network Functions", vol. TC LI Lawful Interception, 8 April 2022 (2022-04-08), pages 1 - 46, XP014424390, Retrieved from the Internet <URL:https://docbox.etsi.org/LI/LI/05-CONTRIBUTIONS/2022/LI(22)R58010_Requirements_for_Network_Functions.zip LI(22)R58010_Requirements_for_Network_Functions.docx> [retrieved on 20220409] *
OTD: "Requirements for Network Functions", vol. TC LI Lawful Interception, 16 February 2022 (2022-02-16), pages 1 - 26, XP014426164, Retrieved from the Internet <URL:https://docbox.etsi.org/LI/LI/05-CONTRIBUTIONS/2022/LI(22)P59032r1_Requirements_for_Network_Functions.zip LI(22)P59032_Requirements_for_Network_Functions_v6.7_changeMarked.docx> [retrieved on 20220216] *

Similar Documents

Publication Publication Date Title
US12095812B2 (en) Systems and methods for mitigating and/or preventing distributed denial-of-service attacks
US10805330B2 (en) Identifying and handling threats to data compute nodes in public cloud
US11463267B2 (en) Network function virtualization system and verifying method
US10666689B2 (en) Security in software defined network
US11343245B2 (en) Systems and methods for security of network connected devices
US8539570B2 (en) Method for managing a virtual machine
US11201818B2 (en) System and method of providing policy selection in a network
US20200374127A1 (en) Blockchain-powered cloud management system
EP3531332A1 (fr) Architecture de cryptage
AU2017321075A1 (en) Extension of network control system into public cloud
EP2999172A1 (fr) Procédé et dispositifs pour certifier un chemin sécurisé dans un réseau défini par logiciel
EP3977696B1 (fr) Procédé, noeud et programme informatique de systèmes et réseaux d&#39;interception légale
US20180343188A1 (en) Method and server for computing and enforcing a trusted path in a multi domain network
US20150128260A1 (en) Methods and systems for controlling communication in a virtualized network environment
US20240305993A1 (en) Hash Function and Lawful Interception
WO2024080901A1 (fr) Gestion de sécurité dans un système d&#39;interception légale
Lukaszewski et al. Towards software defined layer 4.5 customization
Pashalidis et al. Secure network management within an open-source mobile agent framework
WO2023113661A1 (fr) Dispositifs et procédés de réseau de communication pour la surveillance de trafic d&#39;interception légale
WO2023078546A1 (fr) Configuration d&#39;attestation et de sécurité d&#39;un service
CN118432934A (zh) 可信路径建立方法、装置及存储介质
CN118590216A (zh) 基于零信任的数据安全共享和内容管控方法、装置及系统
CA3070415A1 (fr) Systemes et des procedes d&#39;attenuation et/ou de prevention d&#39;attaques de deni de service distribue

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22797527

Country of ref document: EP

Kind code of ref document: A1