WO2020259980A1 - Procedes et dispositifs de securisation d'un reseau de peripherie a acces multiple - Google Patents

Procedes et dispositifs de securisation d'un reseau de peripherie a acces multiple Download PDF

Info

Publication number
WO2020259980A1
WO2020259980A1 PCT/EP2020/065516 EP2020065516W WO2020259980A1 WO 2020259980 A1 WO2020259980 A1 WO 2020259980A1 EP 2020065516 W EP2020065516 W EP 2020065516W WO 2020259980 A1 WO2020259980 A1 WO 2020259980A1
Authority
WO
WIPO (PCT)
Prior art keywords
host module
network
security device
hardware security
mech
Prior art date
Application number
PCT/EP2020/065516
Other languages
English (en)
Inventor
Frédéric FIEAU
Gaël FROMENTOUX
Emile Stephan
Original Assignee
Orange
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 Orange filed Critical Orange
Priority to EP20729764.9A priority Critical patent/EP3991380A1/fr
Priority to US17/622,635 priority patent/US20220360454A1/en
Publication of WO2020259980A1 publication Critical patent/WO2020259980A1/fr

Links

Classifications

    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/009—Security arrangements; Authentication; Protecting privacy or anonymity specially adapted for networks, e.g. wireless sensor networks, ad-hoc networks, RFID networks or cloud networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/108—Source integrity
    • 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/63—Location-dependent; Proximity-dependent

Definitions

  • This description relates to the field of network security. More specifically, aspects of the present disclosure relate to methods and devices for securing a multiple access edge computer network.
  • a difficulty commonly encountered is to be able to guarantee optimum security and reliability of data collected, recorded and exchanged between different partners, for example between a data owner and a provider of services applicable to this data. It is generally appropriate for these partners to agree to use common network infrastructures, the constituent elements of these infrastructures having a level of security that is both sufficient and common for each of the partners.
  • an MEC network provides a computer environment allowing the hosting of applications and services at a level positioned as close as possible to the “user” levels (“end user” in English), which makes it possible to store and process data with faster response time.
  • an MEC network is designed to be compatible with different types of mobile or fixed access, which allows it to be installed physically and directly in base stations or in hardware infrastructures belonging to users or to specific industries.
  • the data collected or used can then be communicated via a higher network and possibly dematerialized.
  • an MEC network comprises a specific module, called a multiple access periphery network host module.
  • This module provides a means of storing and processing data from the MEC network under established conditions of availability, reliability and security. These conditions can be associated with a key or a corresponding electronic signature, in order to guarantee the security of the data.
  • this approach requires deploying a large number of hardware elements near the user levels, which is not systematically possible for reasons of cost and technical feasibility.
  • the hardware elements to be deployed are often of different types and from different manufacturers, which complicates the possibility of defining a common level of security and reliability.
  • the existing methods also do not make it possible to manage or select a host module for a multiple access periphery network in a sufficiently reliable and secure manner.
  • the deployment of signatures or corresponding private keys in such a module is also problematic, in particular in the case of large networks.
  • a hardware security device arranged to be connected to a host module of said network, and the method, implemented by said hardware security device, comprising:
  • a signature of a hardware security device is any private or public type of certificate or key, compatible with the architecture and configuration of a multiple access edge network.
  • an applicant creates a pair of keys, one being public and the other being private and kept secret.
  • a signature may include a certificate signing request, called a CSR (for “Certificate Signing Request”), corresponding to a message sent from a requester to a certification authority, to request a digital identity certificate. If this request is later accepted, the CA returns a digitally signed identity certificate with the private key available to the CA.
  • CSR Certificate Signing Request
  • a signature contains at least one information identifying the requester as well as at least one public key chosen by the requester.
  • said signature does not include the private key corresponding to said public key, but the latter can be used subsequently to implement the signature.
  • a private key corresponding to a public key that the signature comprises can be used to sign a CSR request.
  • Said signature may also include other identification information or proof of identity required by the certification authority.
  • the hardware security device comprises at least one system on chip configured to implement the steps of a security method according to the method or according to any one of the embodiments of the method as described below. after.
  • said request for the presence of the host module in the network is sent by the host module on receipt of a test message sent by a security and confidentiality manager to the host module.
  • test message can reach the host module via one or more other elements of the network, for example via a platform manager of multiple access edge or virtualization infrastructure manager.
  • the security and confidentiality manager is arranged to be connected to the network, for example to the host module or to other elements of the network.
  • the method further comprises determining a level of security of the network as a function of said presence response.
  • said determination of the security level is carried out on receipt of a response to a test message sent by the host module.
  • the determination of the security level is implemented upon receipt of a response to a presence response sent by the hardware security device.
  • the presence request and the response of the hardware security device are respectively received and sent a plurality of times, respectively as a challenge and a response in an iterative operation of authentication of the host module that puts in implement the hardware security device.
  • a challenge and a corresponding response together define a challenge-response authentication (also called a challenge-response authentication).
  • a challenge-response authentication comprises a family of protocols in which a question (the challenge) is presented by one party to another, this other party being invited to provide a valid response (the response) in order to be authenticated.
  • Authentication includes, for example, the use of passwords, and / or preferably, the use of CSR requests and corresponding public and private key pairs, said keys possibly managed by a predefined certification authority.
  • said response is obtained from said respective challenge by a signature of a predetermined number of bits that the respective challenge comprises by means of a security key stored in the hardware security device.
  • the presence request is verified as comprising data representative of an identifier of the host module when it is verified that said identifier is included in a list stored in a memory accessible to the hardware security device.
  • the presence request includes at least one piece of data representative of an identifier selected from the group: proof of attachment, connection information, an operator, an identifier of the host module, information of manufacture or even proof of the presence of the hardware security device in the host module.
  • the method further comprises, on receipt of the presence response by the host module, an implementation of an action, said action being chosen from the group: a verification of said presence response , instantiation of a virtual server in the host module; an installation of a security key in the host module, a designation of a remote hardware security device, a designation of a remote hardware security device, and / or a designation of a virtual server of a host module remote with a security key.
  • a verification of a presence response comprises, for example, a comparison between a signature that includes the hardware security device and a signature that includes the security and confidentiality manager.
  • the signatures compared or to be compared can be security keys.
  • the present invention is also aimed at a hardware security device for securing a multiple access periphery network, said device being arranged to be connected to a host module of said network and comprising a secure processing processor configured for the implementation of the method according to any one of the preceding embodiments of the method.
  • the present invention is also aimed at a computer program comprising instructions for implementing the method according to any one of the preceding embodiments of the method, when these instructions are executed by a processor of a computer processing circuit.
  • said processor or said computer processing circuit comprises the system on chip.
  • said information storage means is a system on a chip designed to be integrated into the hardware security device.
  • Figure 1 shows a schematic view of a network architecture according to one embodiment
  • FIG. 2 shows a schematic view of a network architecture according to another embodiment
  • FIG. 3 shows in the form of a flowchart, the steps of a method of securing a network according to one embodiment
  • FIG. 4 shows, in the form of a flowchart, the steps of a method for securing a network according to another embodiment
  • FIG. 5 represents a flow diagram for steps of a method for securing a network according to one embodiment
  • FIG. 6 represents a schematic block diagram of a computer processing circuit according to one embodiment. Unless otherwise indicated, elements common or similar to several figures bear the same reference signs and have identical or similar characteristics, so that these common elements are generally not described again for the sake of simplicity.
  • Various functional entities involved in the architecture of an MEC network are illustrated. These functional entities are grouped in the MEC network into three levels or layers: a system level SL corresponding to an upper layer, a host level HL corresponding to an intermediate layer, and a network level NL corresponding to a lower layer (not shown) .
  • the NL level provides connectivity from the MEC network architecture to local area networks, cellular networks, and external networks such as the Internet.
  • the HL host level comprises a host module of the multiple access periphery network, called the MECH host module (or "Mobile Edge Computing Host", in English).
  • This MECH host module makes it possible, in particular, to provide a means of storage and processing of information.
  • the MECH host module comprises a multiple access periphery platform, called MEP platform (or "Mobile Edge Platform", in English), a virtual network virtualization infrastructure, called infrastructure VI (or “Virtual Network Function Infrastructure” , in English), as well as at least one application multiple access periphery, called MEA application (or “Mobile Edge Applications”).
  • MEP platform or "Mobile Edge Platform”
  • infrastructure VI or "Virtual Network Function Infrastructure” , in English
  • MEA application or “Mobile Edge Applications”.
  • an MEA application runs as a virtual machine on the VI infrastructure.
  • a MEA application interacts with the MEP platform via at least one Mp1 reference point, which is also used for the implementation of any additional support procedures.
  • An MEA application can indicate the resource or service requirements of the MECH host module, as well as constraints relating to maximum authorized latencies, for example.
  • the VI infrastructure provides compute, storage, and network resources for MEA applications.
  • the infrastructure VI further comprises a switching plane, called the DP data plane (or “Data Plane”), configured to execute the transmission rules received by the MEP platform.
  • DP data plane or “Data Plane”
  • the MEP platform that the MECH module comprises provides a set of basic functionalities for running applications on a host entity and for enabling these applications to use the associated services.
  • These functionalities are used, for example, to organize the routing of data between applications, services and networks interacting with the MEC network or in the latter.
  • the host level HL further comprises other entities external to the MECH host module, such as a host level multiple access periphery platform manager, called MEPM manager (or "Mobile Edge Platform Manager", in English ), or even a virtualization infrastructure manager, called VIM manager (or “Virtual Infrastructure Manager”).
  • MEPM manager or "Mobile Edge Platform Manager”
  • VIM manager or “Virtual Infrastructure Manager”.
  • the MEPM manager receives the traffic transfer rules and notably manages the life cycles of the mobile edge applications and of the management functions.
  • the MEPM manager is connected to the MEP platform via the reference point Mm5 which allows it to transmit instructions. These instructions can be transmitted from the MEP platform to the VI interface via the Mp2 reference point.
  • the MEP platform also supports the configuration of a possible local server, such as a DNS server, which can be used to direct user traffic to desired edge applications.
  • a possible local server such as a DNS server
  • the MEP platform can also communicate with other platforms, for example another MEP2 platform that comprises another MECH2 host module of the HL host level. This communication takes place via an Mp3 reference point, which connects the MECH and MECH2 host modules.
  • the upper layer which corresponds to the SL system level, comprises an operations support system, called an OSS system (or “Operations Support System”), an LCM proxy (or “Life Cycle Manager", in English) and a multi-access orchestrator, called MEO orchestrator (or “Mobile Edge Orchestrator”), which is configured to run mobile edge applications within a network operator.
  • an operations support system called an OSS system (or “Operations Support System”)
  • an LCM proxy or “Life Cycle Manager", in English
  • MEO orchestrator or “Mobile Edge Orchestrator”
  • the MEO orchestrator is arranged to communicate with applications installed on user equipment, called UEA applications (or “User Equipment Applications”, in English), or with a CFS (or “Customer-Facing Service” portal, in English) which serves as an entry point for a third-party application.
  • UEA applications or “User Equipment Applications”, in English
  • CFS or “Customer-Facing Service” portal, in English
  • a UEA application is a web application, that is to say an application that can be handled directly online using a web browser and does not require installation on a client machine.
  • UEA applications make it possible to move applications between external networks, for example cloud networks, and the edge network.
  • a UEA application can be an edge application which is instantiated in an element of the host level HL in response to a request from a device.
  • an execution of a mobile periphery application can be initiated by third-party equipment via a reference point, called point Mx2 (not shown), located between a UEA application and the LCM proxy.
  • point Mx2 located between a UEA application and the LCM proxy.
  • point Mx1 located between the CFS portal and the OSS system.
  • these different elements of the SL level make it possible to implement one or more instantiations of specific applications in the MECH host module, and in particular, at the request of one or more UEA applications of a device. user.
  • a first of these security entities is a hardware security device with a system on chip, called an HSMSOC hardware security device (or "Hardware Security Module System-on-Chip", in English).
  • the hardware security device HSMSOC comprises a hardware security module HSM and a system on chip SOC, said module and said system constituting a single entity equivalent to the hardware security device HSMSOC.
  • the HSMSOC hardware security device comprises a HSM hardware security module and a SOC system on chip, but said HSM hardware security module and said SOC system on chip are separated as as two distinct, individual entities. These two entities are preferably connected to each other.
  • the hardware security device HSMSOC is an entity comprising on the one hand a hardware security module HSM and on the other hand a system on chip SOC, said security module HSM hardware and said SOC system-on-chip being distinct and individual but both present in the HSMSOC hardware security device.
  • the HSMSOC hardware security device and / or the elements that it comprises are arranged to allow a connection with the MECH host module of the MEC network, for example via the DP data plane that includes the VI interface of the MECH host module or directly via the Mp2 interface.
  • a second of these security entities is a security and confidentiality manager, called an SPM manager (or "Security & Privacy Manager", in English).
  • the SPM manager also makes it possible to test and select MECH host modules which meet predetermined security requirements.
  • MECH host module allows at least the delegation of the encryption or of the signature to the HSMSOC hardware security device.
  • a third of these security entities is a security and confidentiality application, called the SPA application (or “Security & Privacy Application", in English).
  • FIG. 3 represents, in the form of a flowchart, an example of steps of a method for securing a network according to one embodiment.
  • a step S20 which follows step S10, concerns the reception of at least one request for the presence of the host module Q1, by the hardware security device HSMSOC.
  • a request for the presence of the host module Q1 is sent by the host module MECH before the implementation of a next step and aims to verify the presence of the hardware security device HSMSOC in the host module MECH.
  • Step S30 which follows step S20, concerns the reception of a presence request, said presence request being received as a challenge by the hardware security module HSM. Such a challenge is issued by the SOC system on chip.
  • Step S40 which follows step S30, relates to the transmission of a response corresponding to a challenge received during step S30, said response to this challenge being sent by the hardware security module HSM and being intended for the SOC system on chip.
  • Step S50 which follows step S40 or which follows a repetition of steps S30 and S40, relates to the transmission of a response R1 corresponding to a request for the presence of the host module Q1 during step S20 .
  • the response R1 is sent by the system on chip SOC and is intended for the MECH host module.
  • Step S60 which follows step S50, concerns the transmission of an R0 response corresponding to a test message Q0 sent by the manager SPM during step S10.
  • This R0 response is sent by the MECH host module and is sent to the SPM manager.
  • an R0 response may be issued by the HSMSOC hardware security device.
  • Step S65 which follows step S60, concerns the verification of the response R0 received by the manager SPM.
  • This verification step S65 can be included in step S60, end all of the previous steps and / or trigger a subsequent action step.
  • one or the other of these action steps is implemented in order to select a MECH host module which respects a predetermined level of encryption and signature, and / or to deploy corresponding private keys in the network.
  • the purpose of these action steps is to prove that one or the other of the elements of the network embeds such a MECH host module and that delegation is not necessary. If said MECH host module is absent, or if it is not possible to prove its presence, one or the other of these action steps makes it possible to implement a delegation, as described below. as an example.
  • FIG. 4 represents, in the form of a flowchart, an example of steps of a method for securing a network according to another embodiment.
  • Step S70 which follows step S60 or step S65, relates to the reception of a command by a third party device, and preferably to an LURK server located in the MEC network.
  • the command is sent by the manager SPM and the action corresponding to this command depends on the result of the verification of the response R0.
  • a LURK server is a server "hidden" in an existing architecture, that is to say a server designed to be ignored by the usual processes taking place in this architecture.
  • Such a LURK server is for example a virtual server instantiated by the manager SPM as a function of the content of the response R0.
  • Step S80 which follows step S70 and may be optional, relates to the transmission, by the third-party device, of a response to the command corresponding to step S70.
  • this response can be an "OK" message sent by a LURK server which was instantiated during a previous step.
  • Steps S70 and S80 will be described in more detail in the remainder of the description.
  • FIG. 5 represents a flow diagram according to an embodiment of a method for securing a multiple access periphery network.
  • the HSMSOC hardware security device has a “co-located” arrangement.
  • the manager SPM is connected to the reference point Mm7 to implement this transmission.
  • Step S10 makes it possible to start the establishment of a proof of co-location.
  • the SPM manager has a list of public keys, these public keys being able to be provided by a manufacturer or by a user of specific hardware security devices.
  • the purpose of transmitting the test message Q0 is to test whether the MECH host module has an HSMSOC hardware security device.
  • the purpose of the QO test message is to verify the location and / or the performance of said HSMSOC hardware security device.
  • the manager SPM is connected to the reference point Mm7 to implement the transmission of the test message Q0.
  • Step S10 thus makes it possible to start the establishment of a proof of co-location.
  • step S20 a challenge is sent from the MECH host module to the HSMSOC hardware security device.
  • said challenge is received by a SOC system on chip that includes HSMSOC.
  • the challenge which is sent from the MECH host module to the HSMSOC hardware security device comprises a transmission of a number "y" of bits to be signed by said HSMSOC hardware security device.
  • the number "y" of bits corresponds to a block of data to be signed by means of a given algorithm, for example by means of message authentication codes (or “Message Authentication Code", MAC, in English) or cryptographic message fingerprint with key.
  • message authentication codes or "Message Authentication Code", MAC, in English
  • cryptographic message fingerprint with key for example by means of cryptographic message fingerprint with key.
  • the number "y" of bits corresponds to a large quantity of data, and is for example greater than or equal to 20, 24, 256 or 2048 bits.
  • the transmitted bits to be signed have a minimum size of 256 bits for keys of the ECDSA type, and a minimum size of 2048 bits for keys of the RSA type.
  • an example of an algorithm used to perform such a signature is an algorithm of the cryptographic hash function type (or "Secure Hash Algorithm", SHA, in English), in particular a SHA-256 algorithm, which allows generate a unique 256-bit (32-byte) hash of fixed size that cannot be decrypted.
  • the cryptographic hash function type or "Secure Hash Algorithm", SHA, in English
  • SHA-256 algorithm which allows generate a unique 256-bit (32-byte) hash of fixed size that cannot be decrypted.
  • the host module MECH increments a counter.
  • the incrementation of this counter can also be carried out on signature of the challenge, and in particular of the number "y" of the aforementioned bits.
  • step S30 comprises sending a local challenge, said local challenge being defined by a given operator of the network, for example.
  • this challenge corresponds to a request to sign a predetermined number "n" of bits to be signed.
  • This signature can be done using one or more algorithms.
  • a local challenge can be issued by the MEP platform and / or by an MEA application in order to perform one or more of the subsequent actions.
  • the signature is implemented by means of a private key, said private key belonging to a manufacturer or to an operator of the HSMSOC hardware security device.
  • the signature is implemented by means of a private key belonging to a manufacturer or to an operator of the MECH host module or of the HSMSOC hardware security device.
  • Step S40 comprises sending a response Ri to the local challenge Qi of step S30.
  • this response comprises the predetermined number "n" of bits, signed with a private key, this private key belonging to the aforementioned network operator.
  • step S50 the system-on-chip S50 sends an R1 presence response to the MECH host module, this response comprising a signature of the hardware security device.
  • the response R1 comprises the number “y” of bits that the request for the presence of the host module Q1 initially included, these bits being signed by at least one private key of the system on chip SOC.
  • the response R1 can also include at least one response time and / or at least one signature, a private key of which belongs to the supplier.
  • the SPM manager has a list of public keys provided by the manufacturer (s) of the HSMSOC hardware security device. During the verification, the SPM manager transmits a challenge to the MEPM manager.
  • the sending of this challenge is implemented by connecting the SPM manager to the MEPM manager via the Mm7 reference point.
  • sending the challenge via the reference point Mm7 allows the VIM manager to interact with the hardware security device.
  • HSMSOC for example to implement a key or certificate installation.
  • the VIM manager thus allows a “back-to-back” connection (or “back-to-back connection”), and in particular, a direct connection between an output / input of the MECH host module and an input / output of the HSMSOC hardware security device.
  • connection can be made via the reference point Mm5.
  • the sending of the challenge via the Mm5 reference point allows the MEP platform and / or an MEA application to perform one or more of the subsequent actions.
  • Examples of such actions include, for example, a distribution or provision of content, in particular via a CDN (or "Content Delivery Network") content distribution network, a delegation of a signature authorization or a delegation of rights for a private or public type certificate.
  • CDN Content Delivery Network
  • connection can be made via the reference point Mm7 and via the reference point Mm5, simultaneously or successively.
  • the challenge may include other elements such as proof of co-location.
  • proof of co-location can be obtained by incrementing a first counter of the MECH host module and signing the result in a file transmitted to the SOC chip system.
  • a second counter can be incremented, the result can be signed by the SOC system on chip and be sent to the MECH host module.
  • the manager SPM can implement various actions.
  • the manager SPM can implement a verification step S65, during which it verifies the content thereof.
  • the SPM manager can verify a response time and / or a signature contained in the presence response R1, and deduce a performance level therefrom.
  • the performance level can be defined as "low”, or "NOK” because indicating a low level of network security.
  • step S70 depending on the presence response R1 obtained from the MECH host module, an action is implemented by the manager SPM to increase the security of the architecture during subsequent use. , or to increase the protection of private keys that will be used later.
  • the SPM manager can implement various actions such as installing a private key in the host module MECH.
  • the SPM manager can instantiate a server, for example a LURK server, in the MECH host module or in a security and confidentiality application SPA onboard said MECH host module. It is then possible to redirect any subsequent requests for storage of private keys to this LURK server.
  • the SPM manager can implement various actions so that the host module MECH obtains keys, for example keys coming from a LURK server instantiated as described previously.
  • FIG. 6 represents a schematic block diagram of a computer processing circuit according to an exemplary implementation.
  • said computer processing circuit is a processor.
  • a computer processing circuit is a system on a chip 1000 arranged to implement a security method according to one or the other of the embodiments described.
  • the system on a chip 1000 implements a method for securing a multiple access periphery MEC network.
  • the system on chip 1000 includes a communication bus connected, for example, to a central processing unit 1010, such as a processor or a microprocessor, and denoted as CPU.
  • the system on a chip 1000 also comprises a random access memory 1020, denoted RAM, for storing the executable code of the securing process as well as the registers suitable for recording the variables and parameters necessary for the implementation of the process according to Of the embodiments, the memory capacity thereof can be supplemented by optional RAM memory connected to an expansion port, for example.
  • RAM random access memory
  • system on a chip 1000 comprises a read only memory 1030, denoted ROM, for storing computer programs for the implementation of the embodiments, as well as a network interface 1040 which is normally connected to a communication network on which digital data to be processed are transmitted or received.
  • ROM read only memory
  • network interface 1040 which is normally connected to a communication network on which digital data to be processed are transmitted or received.
  • the network interface 1040 can be a single network interface, or composed of a set of different network interfaces (for example wired and wireless, interfaces or different types of wired or wireless interfaces).
  • Data packets are sent over the network interface for transmission or are read from the network interface for reception under the control of the software application running in the processor or microprocessor 1010.
  • the system on a chip 1000 comprises a user interface 1050 for receiving inputs from a user or for displaying information to a user, an optional storage medium 1060 denoted HD, and an input-output module 1070, denoted IO, for receiving, sending data from or to external devices such as hard disk, removable storage media or others.
  • the executable code can be stored in a read only memory 1030, on the storage medium 1060 or on a digital removable medium such as for example a disk.
  • the executable code of the programs can be received by means of a communication network, via the network interface 1040, in order to be stored in the storage medium 1060, before being executed.
  • the central processing unit 1010 is suitable for controlling and directing the execution of the instructions or portions of software code of the program or of the programs according to one of the embodiments, instructions which are stored in one of the aforesaid storage means. After power-up, the CPU 1010 is able to execute instructions stored in the main RAM memory 1020, relating to a software application, after these instructions have been loaded from the ROM for example.
  • system on a chip 1000 is a programmable device which uses software.
  • this description can be implemented in any type of hardware (eg, in the form of a specific integrated circuit or ASIC).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Il est décrit un procédé de sécurisation d'un réseau de périphérie à accès multiple, dans lequel on prévoit un dispositif de sécurité matériel (HSMSOC) agencé pour être connecté à un module hôte (MECH) dudit réseau, et le procédé, mis en œuvre par ledit dispositif de sécurité matériel, comportant: - sur réception (S20) d'une requête de présence du module hôte (Q1) dans le réseau, vérifier si ladite requête de présence comprend une donnée représentative d'un identifiant du module hôte, et, dans ce cas, - émettre (S50) une réponse de présence (R1) à destination du module hôte (MECH) comportant une signature du dispositif de sécurité matériel.

Description

Description
Titre : Procédés et dispositifs de sécurisation d’un
réseau de périphérie à accès multiple
Arrière-plan de l’invention
[0001] La présente description se rapporte au domaine de la sécurisation des réseaux. Plus précisément, des aspects de la présente description se rapportent à des procédés et des dispositifs pour sécuriser un réseau informatique de périphérie à accès multiples.
[0002] Aujourd’hui, il est attendu que les domaines de la santé, des transports, de l’énergie, de l’industrie du transport constituent des domaines majeurs d’utilisation des standards 5G en télécommunications, ces domaines étant définis à ce titre comme des « verticaux » de la 5G.
[0003] Dans ce contexte, une difficulté couramment rencontrée est de pouvoir garantir une sécurisation et une fiabilité optimale de données récoltées, enregistrées et échangées entre différents partenaires, par exemple entre un propriétaire de données et un fournisseur de services applicables à ces données. Il convient généralement à ces partenaires de s’accorder pour utiliser des infrastructures réseau communes, les éléments constitutifs de ces infrastructures présentant un niveau de sécurisation qui est à la fois suffisant et commun pour chacun des partenaires.
[0004] Par exemple, pour échanger des données confidentielles issues de capteurs localisés en un ou plusieurs sites de production, un fournisseur d’électricité peut faire appel au matériel et aux services fournis par un opérateur partenaire de télécommunications. Typiquement, deux tels partenaires partagent un jeu commun de clés ou de signatures électroniques, distribuées dans les infrastructures utilisées pour échanger les données, ces clés ou ces signatures pouvant être vérifiées par chacun des partenaires en un instant donné. [0005] Pour ce faire, il est connu des architectures faisant intervenir des réseaux informatiques de périphérie à accès multiples, dits réseaux MEC (ou de « Multi- Access Edge Computing », en anglais). Le groupe ETSI (« European Télécommunications Standards Institute », en anglais) a ainsi défini des spécifications techniques précises et relatives à des architectures réseau compatibles avec les standards de l’informatique de périphérie multi-accès.
[0006] Selon ces normes, un réseau MEC fournit un environnement informatique permettant l'hébergement d'applications et de services à un niveau positionné au plus proche des niveaux « utilisateur » (« end user », en anglais), ce qui permet de stocker et de traiter des données avec un temps de réponse plus rapide.
[0007] En outre, un réseau MEC est conçu pour être compatible avec différents types d’accès mobiles ou fixes, ce qui lui permet d’être installé physiquement et directement dans des stations de base ou dans des infrastructures matérielles appartenant à des utilisateurs ou à des industries spécifiques. Les données collectées ou utilisées peuvent ensuite être communiquées via un réseau supérieur et éventuellement dématérialisé.
[0008] Typiquement, un réseau MEC comporte un module spécifique, dit module hôte de réseau de périphérie à accès multiple. Ce module fournit un moyen de stockage et de traitement des données du réseau MEC suivant des conditions de disponibilité, de fiabilité et de sécurité établies. Ces conditions peuvent être associées à une clé ou une signature électronique correspondante, en vue de garantir la sécurisation des données.
[0009] Lorsque plusieurs utilisateurs ou partenaires échangent des données par l’intermédiaire d’un réseau MEC commun, l’architecture correspondante définit un espace d’échange et de contrôle de données conforme à ces conditions. Dans ce cas, seules les données stockées et traitées par le module hôte conforme à ces conditions seront considérées.
[0010] Toutefois, cette approche présente plusieurs inconvénients.
[0011] Tout d’abord, cette approche nécessite de déployer un grand nombre d’éléments matériels à proximité des niveaux utilisateur, ce qui n’est pas systématiquement possible pour des raisons de coûts et de faisabilité technique. [0012] De plus, les éléments matériels à déployer sont souvent de types et de fabricants différents, ce qui complique la possibilité de définir un niveau de sécurité et de fiabilité commun.
[0013] Ensuite, les réseaux MEC existants et leurs éléments constitutifs ne sont actuellement pas en mesure de contrôler la présence d’un module hôte de réseau de périphérie à accès multiple à l’intérieur d’un réseau MEC donné.
[0014] En outre, il n’est pas possible de sélectionner un module hôte de réseau de périphérie à accès multiple respectant un niveau de chiffrement et un niveau de signature donnés.
[0015] Les procédés existants ne permettent pas non plus de gérer ni de sélectionner un module hôte de réseau de périphérie à accès multiple de manière suffisamment fiable et sécurisée. Le déploiement de signatures ou de clés privées correspondantes dans un tel module est également problématique, en particulier dans le cas de réseaux de grande taille.
Objet et résumé de l’invention
[0016] Afin d’améliorer la situation et de répondre à ce ou à ces inconvénients, il est proposé, de façon générale, un procédé de sécurisation d’un réseau de périphérie à accès multiple, dans lequel on prévoit un dispositif de sécurité matériel agencé pour être connecté à un module hôte dudit réseau, et le procédé, mis en oeuvre par ledit dispositif de sécurité matériel, comportant:
- sur réception d’une requête de présence du module hôte dans le réseau, vérifier si ladite requête de présence comprend une donnée représentative d’un identifiant du module hôte, et, dans ce cas,
- émettre une réponse de présence à destination du module hôte comportant une signature du dispositif de sécurité matériel.
[0017] Dans les présentes, une signature d’un dispositif de sécurité matériel est tout type privé ou public de certificat ou de clé, compatible avec l’architecture et la configuration d’un réseau de périphérie à accès multiple.
[0018] Par exemple, pour générer une signature, un demandeur crée une paire de clés, l’une étant publique et l’autre étant privée et gardée secrète. Une telle signature peut comprendre une demande de signature de certificat, dite demande CSR (pour « Certificate Signing Request », en anglais), correspondant à un message envoyé depuis un demandeur vers une autorité de certification, pour requérir un certificat d'identité numérique. Si cette requête est acceptée ultérieurement, l'autorité de certification retourne un certificat d'identité signé numériquement avec la clé privée dont dispose l'autorité de certification.
[0019] Dans les présentes, une signature contient au moins une information d'identification du demandeur ainsi qu’au moins une clé publique choisie par le demandeur. De préférence, ladite signature ne comprend pas la clé privée correspondant à ladite clé publique, mais celle-ci reste utilisable ultérieurement pour mettre en œuvre la signature.
[0020] Par exemple, une clé privée correspondante à une clé publique que comprend la signature est utilisable pour signer une demande CSR. Ladite signature peut aussi être comprendre d'autres informations d'identification ou des preuves d'identité requises par l'autorité de certification.
[0021] Dans les présentes, le dispositif de sécurité matériel comprend au moins un système sur puce configuré pour mettre en œuvre les étapes d’un procédé de sécurisation selon le procédé ou selon l’une quelconque des réalisations du procédé telles que décrites ci-après.
[0022] Dans une réalisation préférée, ladite requête de présence du module hôte dans le réseau est émise par le module hôte sur réception d’un message de test émis par un gestionnaire de sécurité et de confidentialité au module hôte.
[0023] Dans les présentes, et de manière non limitative, le message de test peut parvenir au module hôte par l’intermédiaire d’un ou de plusieurs autres éléments du réseau, par exemple par l’intermédiaire d’un gestionnaire de plateforme de périphérie à accès multiple ou d’un gestionnaire d’infrastructure de virtualisation.
[0024] Dans les présentes, le gestionnaire de sécurité et de confidentialité est agencé pour être connecté au réseau, par exemple au module hôte ou à d’autres éléments du réseau. [0025] Dans une réalisation préférée, le procédé comporte en outre une détermination d’un niveau de sécurité du réseau en fonction de ladite réponse de présence.
[0026] Dans les présentes, ledit niveau de sécurité est, en particulier, un niveau de sécurité du module hôte.
[0027] Dans une réalisation, ladite détermination du niveau de sécurité est mise en oeuvre sur réception d’une réponse à un message de test émis par le module hôte.
[0028] Dans une réalisation alternative, la détermination du niveau de sécurité est mise en oeuvre sur réception d’une réponse à une réponse de présence émise par le dispositif de sécurité matériel.
[0029] Dans une réalisation préférée, la requête de présence et la réponse du dispositif de sécurité matériel sont respectivement reçue et émise une pluralité de fois, respectivement en tant que challenge et réponse dans une opération itérative d’authentification du module hôte que met en oeuvre le dispositif de sécurité matériel.
[0030] Dans les présentes, un challenge et une réponse correspondante définissent ensemble une authentification challenge-réponse (aussi appelée authentification défi-réponse). De préférence, une authentification challenge- réponse comporte une famille de protocoles dans lesquels une question (le défi) est présentée par une partie à une autre, cette autre partie étant invitée à fournir une réponse valide (la réponse) pour être authentifiée. Une authentification comprend par exemple l’utilisation de mots de passe, et/ou de préférence, l’utilisation de demandes CSR et de paires clés publiques et privées correspondantes, lesdites clés éventuellement gérées par une autorité de certification prédéfinie.
[0031] Dans une réalisation préférée, à chaque itération de l’opération itérative d’authentification du module hôte, ladite réponse est obtenue dudit challenge respectif par une signature d’un nombre prédéterminé de bits que comprend le challenge respectif au moyen d’une clé de sécurité stockée dans le dispositif de sécurité matériel. [0032] Dans une réalisation préférée, la requête de présence est vérifiée comme comprenant une donnée représentative d’un identifiant du module hôte lorsqu’il est vérifié que ledit identifiant est compris dans une liste stockée dans une mémoire accessible au dispositif de sécurité matériel.
[0033] Dans une réalisation préférée, la requête de présence comporte au moins une donnée représentative d’un identifiant sélectionné dans le groupe : une preuve d’attachement, une information de connexion, un opérateur, un identifiant du module hôte, une information de fabrication ou encore une preuve de présence du dispositif de sécurité matériel dans le module hôte.
[0034] Dans une réalisation préférée, le procédé comporte en outre un module d’application de sécurité et de confidentialité agencé pour être connecté au module hôte et pour mettre en oeuvre au moins une signature ou une clé de sécurité.
[0035] Dans une réalisation préférée, le procédé comporte en outre, sur réception de la réponse de présence par le module hôte, une mise en oeuvre d’une action, ladite action étant choisie dans le groupe : une vérification de ladite réponse de présence, une instanciation d’un serveur virtuel dans le module hôte ; une installation d’une clé de sécurité dans le module hôte, une désignation d’un dispositif de sécurité matériel distant, une désignation d’un dispositif de sécurité matériel distant, et/ou une désignation d’un serveur virtuel d’un module hôte distant doté d’une clé de sécurité.
[0036] Dans les présentes, une vérification d’une réponse de présence comporte, par exemple, une comparaison entre une signature que comporte le dispositif de sécurité matériel et une signature que comporte le gestionnaire de sécurité et de confidentialité. En particulier, les signatures comparées ou à comparer peuvent être des clés de sécurité.
[0037] La présente invention vise aussi un dispositif de sécurité matériel pour sécuriser un réseau de périphérie à accès multiple, ledit dispositif étant agencé pour être connecté à un module hôte dudit réseau et comportant un processeur de traitement sécurisé configuré pour la mise en oeuvre du procédé selon l’une quelconque des réalisations précédentes du procédé. [0038] La présente invention vise aussi un programme informatique comportant des instructions pour la mise en oeuvre du procédé selon l’une quelconque des réalisations précédentes du procédé, lorsque ces instructions sont exécutées par un processeur d’un circuit de traitement informatique.
[0039] Dans une réalisation, ledit processeur ou ledit circuit de traitement informatique comprend le système sur puce.
[0040] La présente invention vise aussi un moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un processeur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l’une quelconque des réalisations précédentes du procédé.
[0041] Dans une réalisation, ledit moyen de stockage d’informations est un système sur puce agencé pour être intégré au dispositif de sécurité matériel.
Brève description des dessins
[0042] D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :
[0043] [Fig. 1 ], la figure 1 représente une vue schématique d’une architecture réseau selon une réalisation;
[0044] [Fig. 2], la figure 2, représente une vue schématique d’une architecture réseau selon une autre réalisation;
[0045] [Fig. 3], la figure 3, représente sous forme d’organigramme, des étapes d’un procédé de sécurisation d’un réseau selon une réalisation;
[0046] [Fig. 4], la figure 4, représente sous forme d’organigramme, des étapes d’un procédé de sécurisation d’un réseau selon une autre réalisation;
[0047] [Fig. 5], la figure 5, représente un diagramme de flux pour des étapes d’un procédé de sécurisation d’un réseau selon une réalisation; et
[0048] [Fig. 6], la figure 6, représente un bloc-diagramme schématique d'un circuit de traitement informatique selon une réalisation. [0049] Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
Description des modes de réalisation
[0050] Les dessins et la description ci-après contiennent, pour l’essentiel, des éléments de caractère certain. Ils pourront donc servir à mieux faire comprendre la présente divulgation et à contribuer à sa définition, le cas échéant.
[0051] Il est maintenant fait référence à la figure 1 , qui représente un exemple d’architecture réseau d’informatique de périphérie multi-accès selon une réalisation.
[0052] Différentes entités fonctionnelles impliquées dans l’architecture d’un réseau MEC sont illustrées. Ces entités fonctionnelles sont regroupées dans le réseau MEC en trois niveaux ou couches : un niveau système SL correspondant à une couche supérieure, un niveau hôte HL correspondant à une couche intermédiaire, et un niveau de réseau NL correspondant à une couche inférieure (non représentée).
[0053] Le niveau NL fournit la connectivité de l’architecture du réseau MEC à des réseaux locaux, à des réseaux cellulaires et à des réseaux externes tels que l'Internet.
[0054] Concernant la couche intermédiaire, le niveau hôte HL comprend un module hôte du réseau de périphérie à accès multiple, dit module hôte MECH (ou « Mobile Edge Computing Host », en anglais). Ce module hôte MECH permet, notamment, de fournir un moyen de stockage et de traitement d’informations.
[0055] Le module hôte MECH comprend une plateforme de périphérie à accès multiple, dite plateforme MEP (ou « Mobile Edge Platform », en anglais), une infrastructure de virtualisation de réseau virtuel, dite infrastructure VI (ou « Virtual Network Function Infrastructure », en anglais), ainsi qu’au moins une application de périphérie à accès multiple, dites application MEA (ou « Mobile Edge Applications », en anglais).
[0056] Typiquement, une application MEA s'exécute en tant que machine virtuelle sur l'infrastructure VI. Une application MEA interagit avec la plateforme MEP via au moins un point de référence Mp1 , qui est également utilisé pour la mise en œuvre d’éventuelles procédures de support supplémentaires.
[0057] Une application MEA peut indiquer les besoins en ressources ou en services du module hôte MECH, ainsi que des contraintes relatives à des latences maximales autorisées, par exemple.
[0058] L’infrastructure VI fournit des ressources de calcul, de stockage et de réseau pour des applications MEA. L'infrastructure VI comprend en outre un plan de commutation, dit plan de données DP (ou « Data Plane », en anglais), configuré pour exécuter les règles de transmission reçues par la plateforme MEP.
[0059] Le plan de données DP, qui est généralement compris dans l’infrastructure VI du module hôte MECH, permet, notamment, d’acheminer des données entre les différents services, applications et services associés à l’architecture.
[0060] La plate-forme MEP que comprend le module MECH fournit un ensemble de fonctionnalités de base pour exécuter des applications sur une entité hôte et pour permettre à ces applications d’utiliser les services associés.
[0061] Ces fonctionnalités sont utilisées, par exemple, pour organiser le routage de données entre applications, services et réseaux interagissant avec le réseau MEC ou dans celui-ci.
[0062] Le niveau hôte HL comprend en outre d’autres entités externes au module hôte MECH, telles qu’un gestionnaire de plateforme de périphérie à accès multiple de niveau hôte, dit gestionnaire MEPM (ou « Mobile Edge Platform Manager », en anglais), ou encore un gestionnaire d’infrastructure de virtualisation, dit gestionnaire VIM (ou « Virtual Infrastructure Manager », en anglais).
[0063] Le gestionnaire VIM est relié à l’interface VI par le point de référence Mm7, ce qui permet de gérer les ressources virtualisées du module hôte MECH et/ou pour gérer d’éventuelles instanciations. Il est également utilisé pour conserver des informations sur les ressources disponibles.
[0064] Le gestionnaire MEPM reçoit les règles de transfert de trafic et gère notamment les cycles de vie des applications de périphérie mobile et des fonctions de gestion.
[0065] Le gestionnaire MEPM est connecté à la plateforme MEP via le point de référence Mm5 qui lui permet de transmettre des instructions. Ces instructions peuvent être transmises de la plateforme MEP à l’interface VI via le point de référence Mp2.
[0066] La plate-forme MEP prend aussi en charge la configuration d’un éventuel serveur local, par exemple un serveur DNS, qui peut être utilisé pour diriger le trafic utilisateur vers des applications de périphérie souhaitées.
[0067] La plateforme MEP peut aussi communiquer avec d’autres plates-formes, par exemple une autre plateforme MEP2 que comprend un autre module hôte MECH2 du niveau hôte HL. Cette communication se fait via un point de référence Mp3, qui connecte les modules hôte MECH et MECH2.
[0068] Ceci permet de regrouper plusieurs plateformes, qui forment alors une grille de communication.
[0069] La couche supérieure, qui correspond au niveau système SL, comprend un système de support d’opérations, dit système OSS (ou « Operations Support System », en anglais), un proxy LCM (ou « Life Cycle Manager », en anglais) et un orchestrateur multi-accès, dit orchestrateur MEO (ou « Mobile Edge Orchestrator », en anglais), qui est configuré pour exécuter des applications de périphérie mobile au sein d'un opérateur réseau.
[0070] L’orchestrateur MEO est agencé pour communiquer avec des applications installées sur un équipement utilisateur, dites applications UEA (ou « User Equipment Applications », en anglais), ou avec un portail CFS (ou « Customer- Facing Service », en anglais) qui sert de point d’entrée pour une application tierce. [0071] Dans les présentes, une application UEA est une application web, c’est-à- dire une application manipulable directement en ligne grâce à un navigateur web et ne nécessitant pas d'installation sur une machines cliente.
[0072] Des applications UEA permettent de déplacer des applications entre des réseaux externes, par exemple des réseaux en nuage, et le réseau de périphérie. En particulier, une application UEA peut être une application de périphérie qui est instanciée dans un élément du niveau hôte HL en réponse à une demande d'un équipement.
[0073] Dans les présentes, le proxy LCM est un proxy de gestion du cycle de vie des applications utilisateur, et permet en outre aux applications de requérir l’intégration, l’instanciation, la résiliation d’applications utilisateur ou encore la relocalisation d’applications utilisateur à l’intérieur et à l’extérieur du réseau de périphérie mobile.
[0074] Au niveau système SL, une exécution d’une application de périphérie mobile peut être initiée par un équipement tiers par l’intermédiaire d’un point de référence, dit point Mx2 (non représenté), situé entre une application UEA et le proxy LCM. L’exécution d’une telle application peut aussi être initiée par l’intermédiaire d’un autre point de référence, dit point Mx1 (non représenté), situé entre le portail CFS et le système OSS.
[0075] Selon différents exemples, ces différents éléments du niveau SL permettent de mettre en œuvre une ou plusieurs instanciations d’applications spécifiques dans le module hôte MECH, et en particulier, sur demande d’une ou de plusieurs applications UEA d’un équipement utilisateur.
[0076] L’orchestrateur MEO joue un rôle important dans le niveau système SL. Cet orchestrateur a connaissance de la topologie du réseau MEC, de tous les modules hôte déployés, ainsi que des services et des ressources disponibles dans chaque hôte.
[0077] Le système OSS est quant à lui relié au niveau hôte NL via un point de référence Mm2 le connectant à la plateforme MEPM et conçu pour déclencher l'instanciation et la fermeture d’applications de périphérie mobile du module hôte, par exemple. [0078] Le point de référence Mm2 peut aussi être utilisé pour la gestion des pannes, de la configuration et des performances de la plateforme MEP.
[0079] L’orchestrateur MEO est connecté à la plateforme MEPM via un point de référence Mm3, et est en outre connecté au gestionnaire VIM via un point de référence Mm4.
[0080] La figure 2 représente un exemple de réalisation d’un réseau sécurisé par une ou plusieurs entités de sécurité.
[0081] L’architecture représentée reprend les différentes entités fonctionnelles de la figure précédente, ainsi que plusieurs entités de sécurisation agencées pour être connectés à l’une ou l’autre de ces entités fonctionnelles.
[0082] Une première de ces entités de sécurisation est un dispositif de sécurité matériel avec système sur puce, dit dispositif de sécurité matériel HSMSOC (ou « Hardware Security Module System-on-Chip », en anglais).
[0083] Dans les présentes, le dispositif de sécurité matériel HSMSOC peut être mis en oeuvre selon au moins l’un des trois agencements suivants.
[0084] Dans un premier agencement, dit « fusionné », le dispositif de sécurité matériel HSMSOC comprend un module de sécurité matériel HSM et un système sur puce SOC, ledit module et ledit système constituant une seule et même entité équivalente au dispositif de sécurité matériel HSMSOC.
[0085] Dans un deuxième agencement, dit « distant », le dispositif de sécurité matériel HSMSOC comprend un module de sécurité matériel HSM et un système sur puce SOC, mais ledit module de sécurité matériel HSM et ledit système sur puce SOC sont séparés en tant que deux entités distinctes, individuelles. Ces deux entités sont, de préférence, connectées entre elles.
[0086] Dans un troisième agencement, dit « co-localisé », le dispositif de sécurité matériel HSMSOC est une entité comprenant d’une part un module de sécurité matériel HSM et d’autre part un système sur puce SOC, ledit module de sécurité matériel HSM et ledit système sur puce SOC étant distincts et individuels mais tous les deux présents dans le dispositif de sécurité matériel HSMSOC. [0087] Les présentes ci-dessous décriront de préférence la mise en œuvre de l’invention sous la forme de ce troisième agencement « co-localisé ». De manière non limitative, toutefois, l’un ou l’autre des deux agencements « fusionné » et « distant » peuvent être mis en œuvre de manière similaire.
[0088] Dans tous les cas, le dispositif de sécurité matériel HSMSOC et/ou les éléments qu’il comprend sont agencés pour permettre une connexion avec le module hôte MECH du réseau MEC, par exemple via le plan de données DP que comprend l’interface VI du module hôte MECH ou encore directement par l’interface Mp2.
[0089] Une deuxième de ces entités de sécurisation est un gestionnaire de sécurité et de confidentialité, dit gestionnaire SPM (ou « Security & Privacy Manager », en anglais).
[0090] De préférence, le gestionnaire SPM est agencé pour être embarqué dans la plateforme MEPM.
[0091] Le gestionnaire SPM permet aussi de tester et de sélectionner des modules hôtes MECH qui répondent à des exigences de sécurité prédéterminées.
[0092] Un exemple d’exigence de sécurité est que ledit module hôte MECH permette au moins la délégation du chiffrement ou de la signature auprès du dispositif de sécurité matériel HSMSOC.
[0093] Une troisième de ces entités de sécurisation est une application de sécurité et de confidentialité, dite application SPA (ou « Security & Privacy Application », en anglais).
[0094] L’application SPA est agencée pour être embarquée dans la plateforme MEP ou dans une application MEA. Avantageusement, une application MEA ne partage pas de clé privée avec la plateforme MEP, et permet d’activer une délégation pour mettre en œuvre une signature ou un certificat.
[0095] En outre, l’application SPA permet de mettre en œuvre un ou plusieurs mécanismes de chiffrement, d’échange et de stockage sécurisé de clés pour sécuriser le réseau MEC. [0096] La figure 3 représente, sous forme d’organigramme, un exemple d’étapes d’un procédé de sécurisation d’un réseau selon une réalisation.
[0097] Une étape S10 concerne la réception d’au moins un message de test Q0 par le module hôte MECH du réseau MEC. Ce message de test Q0 est émis par le gestionnaire SPM et vise à tester la présence, la localisation et/ou les performances du module hôte MECH dans le réseau MEC.
[0098] Une étape S20, qui suit l’étape S10, concerne la réception d’au moins une requête de présence du module hôte Q1 , par le dispositif de sécurité matériel HSMSOC. Une telle requête de présence du module hôte Q1 est émise par le module hôte MECH avant la mise en oeuvre d’une étape suivante et vise à vérifier la présence du dispositif de sécurité matériel HSMSOC dans le module hôte MECH.
[0099] L’étape S30, qui suit l’étape S20, concerne la réception d’une requête de présence, ladite requête de présence étant reçue en tant que challenge par le module de sécurité matériel HSM. Un tel challenge est émis par le système sur puce SOC.
[0100] L’étape S40, qui suit l’étape S30, concerne l’émission d’une réponse correspondante à un challenge reçu lors de l’étape S30, ladite réponse à ce challenge étant émise par le module de sécurité matériel HSM et étant à destination du système sur puce SOC.
[0101] Les étapes S30 et S40 visent à authentifier le module hôte et peuvent être répétées de manière itérative pour augmenter la sécurisation d’une telle authentification.
[0102] Ceci permet, entre autres, de vérifier la capacité de calcul du dispositif de sécurité matériel HSMSOC (ou l’un de ses composants), encore de déterminer la distance entre ledit dispositif et d’autres éléments du réseau de périphérie R.
[0103] Lorsque le dispositif de sécurité matériel HSMSOC présente un agencement « fusionné », c’est-à-dire que le module de sécurité matériel HSM et le système sur puce SOC constituent une seule et même entité, les étapes S30 et S40 ne sont pas mises en oeuvre entre le module de sécurité matériel HSM et le système sur puce SOC. [0104] L’étape S50, qui suit l’étape S40 ou qui suit une répétition des étapes S30 et S40, concerne l’émission d’une réponse R1 correspondante à une requête de présence du module hôte Q1 lors de l’étape S20. La réponse R1 est émise par le système sur puce SOC et est à destination du module hôte MECH.
[0105] L’étape S60, qui suit l’étape S50, concerne l’émission d’une réponse R0 correspondante à un message de test Q0 émis par le gestionnaire SPM lors de l’étape S10. Cette réponse R0 est émise par le module hôte MECH et est à destination du gestionnaire SPM. En variante, une réponse R0 peut être émise par le dispositif de sécurité matériel HSMSOC.
[0106] L’étape S65, qui suit l’étape S60, concerne la vérification de la réponse R0 reçue par le gestionnaire SPM. Cette étape S65 de vérification peut être incluse dans l’étape S60, mettre fin à l’ensemble des étapes précédentes et/ou déclencher une étape d’action ultérieure.
[0107] En particulier, l’une ou l’autre de ces étapes d’action est mise en oeuvre afin de sélectionner un module hôte MECH qui respecte un niveau de chiffrement et de signature prédéterminés, et/ou de déployer des clés privées correspondantes dans le réseau.
[0108] En outre, ces étapes d’action ont pour finalité de prouver que l’un ou l’autre des éléments du réseau embarque un tel module hôte MECH et qu’une délégation n’est pas nécessaire. Si ledit module hôte MECH est absent, ou s’il n’est pas possible d’en prouver la présence, l’une ou l’autre de ces étapes d’action permet de mettre en oeuvre une délégation, comme décrit ci-après en guise d'exemple.
[0109] La figure 4 représente sous forme d’organigramme, un exemple d’étapes d’un procédé de sécurisation d’un réseau selon une autre réalisation.
[0110] Cette réalisation reprend l’exemple précédent d’organigramme, auquel s’ajoutent les étapes S70 et S80.
[0111] L’étape S70, qui suit l’étape S60 ou l’étape S65, concerne la réception d’une commande par un dispositif tiers, et de préférence à destination d’un serveur LURK localisé dans le réseau MEC. [0112] De préférence, la commande est émise par le gestionnaire SPM et l’action correspondante à cette commande dépend du résultat de la vérification de la réponse R0.
[0113] Dans les présentes, un serveur LURK est un serveur « dissimulé » dans une architecture existante, c’est-à-dire un serveur agencé pour être ignoré par les processus habituels prenant place dans cette architecture. Un tel serveur LURK est par exemple un serveur virtuel instancié par le gestionnaire SPM en fonction du contenu de la réponse R0.
[0114] L’étape S80, qui suit l’étape S70 et peut être facultative, concerne l’émission, par le dispositif tiers, d’une réponse à la commande correspondante à l’étape S70.
[0115] Par exemple, cette réponse peut être un message « OK » émis par un serveur LURK qui a été instancié au cours d’une étape précédente.
[0116] Les étapes S70 et S80 seront décrites plus en détail dans la suite de la description.
[0117] La figure 5 représente un diagramme de flux selon une réalisation d’un procédé de sécurisation d’un réseau de périphérie à accès multiple.
[0118] Dans le cas présent, on suppose que le dispositif de sécurité matériel HSMSOC présente un agencement « co-localisé ».
[0119] Lors de l’étape S10, le gestionnaire de sécurité et de confidentialité SPM transmet un message de test Q0 au module hôte MECH.
[0120] De préférence, le gestionnaire SPM est connecté au point de référence Mm7 pour mettre en œuvre cette transmission.
[0121] L’étape S10 permet de démarrer l’établissement d’une preuve de co localisation.
[0122] De préférence, le gestionnaire SPM dispose d’une liste de clés publiques, ces clés publiques pouvant être fournies par un fabricant ou par un utilisateur de dispositifs de sécurité matériel spécifiques.
[0123] La transmission du message de test Q0 a pour but de tester si le module hôte MECH dispose d’un dispositif de sécurité matériel HSMSOC. [0124] En particulier, le message de test QO a pour but de vérifier la localisation et/ou les performances dudit dispositif de sécurité matériel HSMSOC.
[0125] De préférence, le gestionnaire SPM est connecté au point de référence Mm7 pour mettre en œuvre la transmission du message de test Q0. L’étape S10 permet ainsi de démarrer l’établissement d’une preuve de co-localisation.
[0126] Lors de l’étape S20, un challenge est envoyé du module hôte MECH au dispositif de sécurité matériel HSMSOC. De préférence, ledit challenge est reçu par un système sur puce SOC que comprend HSMSOC.
[0127] Le challenge qui est envoyé du module hôte MECH au dispositif de sécurité matériel HSMSOC comprend une transmission d’un nombre « y » de bits à faire signer par ledit dispositif de sécurité matériel HSMSOC.
[0128] Typiquement, le nombre « y » de bits correspond à un bloc de données à signer au moyen d’un algorithme donné, par exemple au moyen de codes d’authentification de message (ou « Message Authentication Code », MAC, en anglais) ou d’empreinte cryptographique de message avec clé.
[0129] Le nombre « y » de bits correspond à une grande quantité de données, et est par exemple supérieur ou égal à 20, 24, 256 ou 2048 bits. De préférence, les bits transmis à faire signer ont une taille minimale de 256 bits pour des clés de type ECDSA, et une taille minimale de 2048 bits pour des clés de type RSA.
[0130] De préférence, un exemple d’algorithme utilisé pour effectuer une telle signature est un algorithme de type fonction de hachage cryptographique (ou « Secure Hash Algorithm », SHA, en anglais), en particulier un algorithme SHA- 256, qui permet de générer un hachage de 256 bits (32 octets) unique, de taille fixe, et ne pouvant pas être déchiffré.
[0131] Selon un exemple, et sur réception du message de test Q0, le module hôte MECH incrémente un compteur. L’incrémentation de ce compteur peut aussi être effectuée sur signature du challenge, et en particulier du nombre « y » de bits précités.
[0132] Lors de l’étape S30, le module hôte MECH transmet une requête de présence du module hôte dans le réseau, Qi, au système sur puce SOC. En réponse à cette requête Qi, et lors de l’étape S40, le système sur puce SOC renvoie une réponse Ri au module hôte. La requête de présente et la réponse sont respectivement reçue et émise en tant que challenge Qi et réponse Ri. La répétition, de manière itérative, des étapes S30 et S40 revient à mettre en oeuvre une opération itérative d’authentification du module hôte.
[0133] Ceci permet, entre autres, de vérifier les performances du module hôte, sa présence ou encore sa distance par rapport à d’autres éléments du réseau.
[0134] En particulier, l’étape S30 comprend une émission d’un challenge local, ledit challenge local étant défini par un opérateur donné du réseau, par exemple. De préférence, ce challenge correspond à une requête de signature d’un nombre « n » prédéterminé de bits à signer. Cette signature peut se faire au moyen d’un ou de plusieurs algorithmes.
[0135] Par exemple, il sera décrit dans la suite des présentes qu’un challenge local peut être émis par la plateforme MEP et/ou par une application MEA en vue d’effectuer une ou plusieurs des actions subséquentes.
[0136] Lorsque le challenge local est émis par la plateforme MEP, la signature est mise en oeuvre au moyen d’une clé privée, ladite clé privée appartenant à un fabricant ou à un opérateur du dispositif de sécurité matériel HSMSOC.
[0137] En variante, lorsque le challenge local est émis par une application MEA, la signature est mise en oeuvre au moyen d’une clé privée appartenant à un fabricant ou à un opérateur du module hôte MECH ou du dispositif de sécurité matériel HSMSOC.
[0138] L’étape S40 comprend un envoi d’une réponse Ri au challenge local Qi de l’étape S30. De préférence, cette réponse comprend le nombre « n » prédéterminé de bits, signés avec une clé privée, cette clé privée appartenant à l’opérateur précité du réseau.
[0139] Lors des étapes S30 et S40, une pluralité de requêtes de présence et de réponses peuvent être respectivement reçues et émises une pluralité de fois. A cette pluralité correspond donc un nombre « N » de challenges Q1 , Q2, ... , QN et de réponses R1 , R2, ... , RN émis et reçus de manière itérative afin de mettre en oeuvre une authentification du module hôte MECH. [0140] Les étapes S30 et S40 permettent, notamment, de mettre en œuvre une vérification d’un identifiant du module hôte MECH et/ou d’un identifiant du dispositif de sécurité matériel HSMSOC, par exemple son fabricant. Par exemple, il est possible, lors des étapes S30 et S40, de vérifier simultanément l’identité d’un fabricant du dispositif de sécurité matériel HSMSOC. Ceci peut se faire en envoyant un challenge à signer par le système sur puce SOC, ledit challenge étant par exemple une demande CSR. Une vérification peut ensuite être mise en œuvre au moyen des clés publiques correspondant au fabricant du dispositif de sécurité matériel HSMSOC. Si la présence de clés privées est détectée, une vérification peut être mise en œuvre avec les clés publiques qui sont déjà présentes.
[0141] Lors de l’étape S50, le système sur puce S50 émet une réponse de présence R1 à destination du module hôte MECH, cette réponse comportant une signature du dispositif de sécurité matériel. En particulier, la réponse R1 comprend le nombre « y » de bits que comportait initialement la requête de présence du module hôte Q1 , ces bits étant signés par au moins une clé privée du système sur puce SOC.
[0142] La réponse R1 peut, en outre, comporter au moins un temps de réponse et/ou au moins une signature dont une clé privée appartient au fournisseur.
[0143] En d’autres termes, les étapes S10 à S60 ou, de manière plus générale, les étapes S20 et S50, permettent au gestionnaire SPM de tester un module hôte MECH, et en particulier de vérifier si ledit module hôte MECH dispose d’un dispositif de sécurité matériel HSMSOC.
[0144] Pour effectuer cette vérification, le gestionnaire SPM dispose d’une liste de clés publiques fournies par le ou les fabricants du dispositif de sécurité matériel HSMSOC. Lors de la vérification, le gestionnaire SPM transmet un challenge à destination du gestionnaire MEPM.
[0145] Selon un exemple, l’envoi de ce challenge est mis en œuvre par connexion du gestionnaire SPM au gestionnaire MEPM via le point de référence Mm7.
[0146] Avantageusement, l’envoi du challenge via le point de référence Mm7 permet au gestionnaire VIM d’interagir avec le dispositif de sécurité matériel HSMSOC, par exemple pour mettre en œuvre une installation d’une clé ou d’un certificat.
[0147] Le gestionnaire VIM permet ainsi une connexion « dos à dos » (ou « back- to-back connection », en anglais), et notamment, une connexion directe entre une sortie/entrée du module hôte MECH et une entrée/sortie du dispositif de sécurité matériel HSMSOC.
[0148] Selon un autre exemple, la connexion peut être faite via le point de référence Mm5.
[0149] Avantageusement, l’envoi du challenge via le point de référence Mm5 permet à la plateforme MEP et/ou à une application MEA d’effectuer une ou plusieurs des actions subséquentes.
[0150] Des exemples de telles actions comprennent, par exemple, une diffusion ou une mise à disposition d’un contenu, notamment via un réseau de diffusion de contenu CDN (ou « Content Delivery Network », en anglais), une délégation d’une autorisation de signature ou encore une délégation de droits pour un certificat de type privé ou public.
[0151] Selon encore un autre exemple, la connexion peut être faite via le point de référence Mm7 et via le point de référence Mm5, simultanément ou successivement.
[0152] Selon différents exemples, ledit challenge comprend un identifiant du module hôte MECH, et une preuve de présence du dispositif de sécurité matériel HSMSOC dans ce module hôte MECH, par exemple au point de référence Mp2. La validation de cette preuve de présence permet de déterminer si le dispositif de sécurité matériel HSMSOC est présent dans ce module hôte MECH, s’il est absent ou s’il est situé ailleurs. La validation de cette preuve de présence permet aussi de déterminer la distance séparant le module hôte MECH du dispositif de sécurité matériel HSMSOC, ou encore de déterminer un temps de latence associé.
[0153] En outre, le challenge peut comprendre d’autres éléments tels qu’une preuve de co-localisation. Une telle preuve de co-localisation peut être obtenue via l’incrémentation d’un premier compteur du module hôte MECH et la signature du résultat dans un fichier transmis à destination du système sur puce SOC. Lorsque le système sur puce SOC reçoit ledit fichier, un deuxième compteur peut être incrémenté, le résultat peut être signé par le système sur puce SOC et être envoyé au module hôte MECH.
[0154] Lors de l’étape S60, la réponse de présence R1 est envoyée par le module hôte MECH à destination du gestionnaire SPM.
[0155] Sur réception de la réponse de présence R1 , et selon différents exemples, le gestionnaire SPM peut mettre en œuvre différentes actions.
[0156] Par exemple, le gestionnaire SPM peut mettre en œuvre une étape S65 de vérification, au cours de laquelle il en vérifie le contenu.
[0157] En particulier, le gestionnaire SPM peut vérifier un temps de réponse et/ou une signature contenue dans la réponse de présence R1 , et en déduire un niveau de performance.
[0158] Par exemple, si une signature est valide et si un temps de réponse est suffisamment court par rapport à des conditions prédéterminées, le niveau de performance peut être défini comme « élevé », ou OK.
[0159] Si une signature n’est pas valide et/ou si un temps de réponse est plus grand que ce qui est attendu de conditions prédéterminées, le niveau de performance peut être défini comme « bas », ou « NOK » car indiquant un faible niveau de sécurisation du réseau.
[0160] Le niveau de performance déduit peut être utilisé pour mettre en œuvre des étapes d’actions, en particulier si celui-ci est « bas ».
[0161] Ainsi, lors de l’étape S70, en fonction de la réponse de présence R1 obtenue du module hôte MECH, une action est mise en œuvre par le gestionnaire SPM pour augmenter la sécurité de l’architecture lors d’une utilisation ultérieure, ou pour augmenter la protection de clés privées qui seront utilisées ultérieurement.
[0162] Selon différents exemples, et s’il a été testé positivement que le module hôte MECH dispose d’un dispositif de sécurité matériel HSMSOC, le gestionnaire SPM peut mettre en œuvre différentes actions telles qu’installer une clé privée dans le module hôte MECH. [0163] En variante, le gestionnaire SPM peut instancier un serveur, par exemple un serveur LURK, dans le module hôte MECH ou dans une application de sécurité et de confidentialité SPA embarquée dans ledit module hôte MECH. Il est alors possible de rediriger les éventuelles demandes ultérieures de stockage de clés privées vers ce serveur LURK.
[0164] Selon d’autres exemples, et s’il s’avère que le module hôte MECH ne dispose pas d’un dispositif de sécurité matériel HSMSOC, le gestionnaire SPM peut mettre en oeuvre différentes actions de sorte à ce que le module hôte MECH obtienne des clés, par exemple des clés provenant d’un serveur LURK instancié comme décrit précédemment.
[0165] La figure 6 représente un bloc-diagramme schématique d'un circuit de traitement informatique selon un exemple de mise en oeuvre.
[0166] Selon un exemple, ledit circuit de traitement informatique est un processeur. De préférence, un tel circuit de traitement informatique est un système sur puce 1000 agencé pour mettre en oeuvre un procédé de sécurisation selon l’une ou l’autre des réalisations décrites.
[0167] De manière non limitative, le système sur puce 1000 met en oeuvre un procédé de sécurisation d’un réseau MEC de périphérie à accès multiple. Le système sur puce 1000 comporte un bus de communication connecté, par exemple, à une unité centrale de traitement 1010, tel qu'un processeur ou un microprocesseur, et notée CPU.
[0168] Le système sur puce 1000 comporte aussi une mémoire à accès aléatoire 1020, notée RAM, pour mémoriser le code exécutable du procédé de sécurisation ainsi que les registres adaptés à enregistrer des variables et des paramètres nécessaires pour la mise en oeuvre du procédé selon des modes de réalisation, la capacité de mémoire de celui-ci peut être complétée par une mémoire RAM optionnelle connectée à un port d'extension, par exemple.
[0169] En outre, le système sur puce 1000 comporte une mémoire morte 1030, notée ROM, pour stocker des programmes informatiques pour la mise en oeuvre des modes de réalisation, ainsi qu’une interface réseau 1040 qui est normalement connectée à un réseau de communication sur lequel des données numériques à traiter sont transmises ou reçues.
[0170] L'interface réseau 1040 peut être une seule interface réseau, ou composée d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans fil, interfaces ou différents types d'interfaces filaires ou sans fil).
[0171] Des paquets de données sont envoyés sur l'interface réseau pour la transmission ou sont lues à partir de l'interface de réseau pour la réception sous le contrôle de l'application logiciel exécuté dans le processeur ou le microprocesseur 1010.
[0172] Par ailleurs, le système sur puce 1000 comporte une interface utilisateur 1050 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur, un support de stockage optionnel 1060 noté HD, et un module d’entrée-sortie 1070, noté IO, pour la réception, l'envoi de données depuis ou vers des périphériques externes tels que disque dur, support de stockage amovible ou autres.
[0173] Dans un exemple présenté ici, le code exécutable peut être stocké dans une mémoire morte 1030, sur le support de stockage 1060 ou sur un support amovible numérique tel que par exemple un disque.
[0174] Selon une variante, le code exécutable des programmes peuvent être reçu au moyen d'un réseau de communication, via l'interface réseau 1040, afin d'être stocké dans le support de stockage 1060, avant d'être exécuté.
[0175] L'unité centrale de traitement 1010 est adaptée pour commander et diriger l'exécution des instructions ou des portions de code logiciel du programme ou des programmes selon l'un des modes de réalisation, instructions qui sont stockées dans l'un des moyens de stockage précités. Après la mise sous tension, le CPU 1010 est capable d'exécuter des instructions stockées dans la mémoire RAM principale 1020, relatives à une application logicielle, après que ces instructions aient été chargées de la ROM par exemple.
[0176] Dans l’exemple présenté ici, la système sur puce 1000 est un appareil programmable qui utilise un logiciel. Toutefois, à titre subsidiaire, la présente description peut être mise en œuvre dans n’importe quel type de matériel (par exemple, sous la forme d'un circuit intégré spécifique ou ASIC).

Claims

Revendications
[Revendication 1] Procédé de sécurisation d’un réseau de périphérie à accès multiple (MEC),
dans lequel on prévoit un dispositif de sécurité matériel (HSMSOC) agencé pour être connecté à un module hôte (MECH) dudit réseau,
et le procédé, mis en oeuvre par ledit dispositif de sécurité matériel, comportant:
- sur réception (S20) d’une requête de présence du module hôte (Q1 ) dans le réseau, vérifier si ladite requête de présence comprend une donnée représentative d’un identifiant du module hôte, et, dans ce cas,
- émettre (S50) une réponse de présence (R1 ) à destination du module hôte (MECH) comportant une signature du dispositif de sécurité matériel.
[Revendication 2] Procédé selon la revendication 1 , dans lequel ladite requête de présence du module hôte (Q1 ) dans le réseau est émise par le module hôte (MECH) sur réception (S10) d’un message de test (Q0) émis par un gestionnaire de sécurité et de confidentialité (SPM) au module hôte.
[Revendication 3] Procédé selon l’une quelconque des revendications précédentes, comportant en outre une détermination (S60 ; S65) d’un niveau de sécurité du réseau en fonction de ladite réponse de présence (R1 ).
[Revendication 4] Procédé selon l’une quelconque des revendications précédentes, dans lequel la requête de présence et la réponse du dispositif de sécurité matériel sont respectivement reçue (S30) et émise (S40) une pluralité de fois, respectivement en tant que challenge (Qi) et réponse (Ri) dans une opération itérative d’authentification du module hôte que met en oeuvre le dispositif de sécurité matériel.
[Revendication 5] Procédé selon la revendication 4, dans lequel, à chaque itération de l’opération itérative d’authentification du module hôte, ladite réponse est obtenue dudit challenge respectif par une signature d’un nombre prédéterminé de bits que comprend le challenge respectif au moyen d’une clé de sécurité stockée dans le dispositif de sécurité matériel (HSMSOC).
[Revendication 6] Procédé selon l’une quelconques des revendications précédentes, dans lequel la requête de présence est vérifiée comme comprenant une donnée représentative d’un identifiant du module hôte lorsqu’il est vérifié que ledit identifiant est compris dans une liste stockée dans une mémoire accessible au dispositif de sécurité matériel.
[Revendication 7] Procédé selon l’une quelconques des revendications précédentes, dans lequel la requête de présence comporte au moins une donnée représentative d’un identifiant sélectionné dans le groupe : une preuve d’attachement, une information de connexion, un opérateur, un identifiant du module hôte (MECH), une information de fabrication ou encore une preuve de présence du dispositif de sécurité matériel (HSMSOC) dans le module hôte (MECH).
[Revendication 8] Procédé selon l’une quelconque des revendications précédentes, comportant en outre un module d’application de sécurité et de confidentialité (SPA) agencé pour être connecté au module hôte (MECH) et pour mettre en oeuvre au moins une signature ou une clé de sécurité.
[Revendication 9] Procédé selon l’une quelconque des revendications précédentes, comportant en outre, sur réception de la réponse de présence par le module hôte, une mise en oeuvre d’une action (S70), ladite action étant choisie dans le groupe : une vérification de ladite réponse de présence, une instanciation d’un serveur virtuel (LRK) dans le module hôte, une installation d’une clé de sécurité dans le module hôte, une désignation d’un dispositif de sécurité matériel distant, une désignation d’un dispositif de sécurité matériel distant et/ou une désignation d’un serveur virtuel d’un module hôte distant doté d’une clé de sécurité.
[Revendication 10] Dispositif de sécurité matériel (HSMSOC) pour sécuriser un réseau de périphérie à accès multiple (MEC), ledit dispositif étant agencé pour être connecté à un module hôte (MECH) dudit réseau et configuré pour mettre en œuvre le procédé selon l’une quelconque des revendications précédentes.
[Revendication 11] Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 9, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement informatique.
[Revendication 12] Moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un processeur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 9.
PCT/EP2020/065516 2019-06-26 2020-06-04 Procedes et dispositifs de securisation d'un reseau de peripherie a acces multiple WO2020259980A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP20729764.9A EP3991380A1 (fr) 2019-06-26 2020-06-04 Procedes et dispositifs de securisation d'un reseau de peripherie a acces multiple
US17/622,635 US20220360454A1 (en) 2019-06-26 2020-06-04 Methods and devices for securing a multiple-access peripheral network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1906988A FR3096535A1 (fr) 2019-06-26 2019-06-26 Procédés et dispositifs de sécurisation d’un réseau de périphérie à accès multiple
FRFR1906988 2019-06-26

Publications (1)

Publication Number Publication Date
WO2020259980A1 true WO2020259980A1 (fr) 2020-12-30

Family

ID=68654610

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/065516 WO2020259980A1 (fr) 2019-06-26 2020-06-04 Procedes et dispositifs de securisation d'un reseau de peripherie a acces multiple

Country Status (4)

Country Link
US (1) US20220360454A1 (fr)
EP (1) EP3991380A1 (fr)
FR (1) FR3096535A1 (fr)
WO (1) WO2020259980A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115529144A (zh) * 2021-06-24 2022-12-27 中移(成都)信息通信科技有限公司 通信系统、方法、装置、第一设备、第二设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090300364A1 (en) * 2008-05-29 2009-12-03 James Paul Schneider Username based authentication security
WO2017105733A1 (fr) * 2015-12-18 2017-06-22 Intel Corporation Dispositifs informatiques
US20170251368A1 (en) * 2016-02-25 2017-08-31 ACS (US), Inc. Platform for computing at the mobile edge

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080031965A (ko) * 2005-07-20 2008-04-11 베리메트릭스 인코퍼레이티드 네트워크 사용자 인증 시스템 및 방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090300364A1 (en) * 2008-05-29 2009-12-03 James Paul Schneider Username based authentication security
WO2017105733A1 (fr) * 2015-12-18 2017-06-22 Intel Corporation Dispositifs informatiques
US20170251368A1 (en) * 2016-02-25 2017-08-31 ACS (US), Inc. Platform for computing at the mobile edge

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
NICOLE BERDY: "Device provisioning: Identity attestation with TPM | Azure Blog and Updates | Microsoft Azure", AZURE MICROSOFT COM, 7 November 2017 (2017-11-07), pages 1 - 7, XP055679348, Retrieved from the Internet <URL:https://azure.microsoft.com/en-us/blog/device-provisioning-identity-attestation-with-tpm/> [retrieved on 20200324] *
ROMAN RODRIGO ET AL: "Mobile edge computing, Fog et al.: A survey and analysis of security threats and challenges", FUTURE GENERATIONS COMPUTER SYSTEMS, ELSEVIER SCIENCE PUBLISHERS. AMSTERDAM, NL, vol. 78, 12 November 2016 (2016-11-12), pages 680 - 698, XP085191441, ISSN: 0167-739X, DOI: 10.1016/J.FUTURE.2016.11.009 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115529144A (zh) * 2021-06-24 2022-12-27 中移(成都)信息通信科技有限公司 通信系统、方法、装置、第一设备、第二设备及存储介质
WO2022267994A1 (fr) * 2021-06-24 2022-12-29 中移(成都)信息通信科技有限公司 Système et procédé de communication, appareil, premier dispositif, deuxième dispositif et support de stockage

Also Published As

Publication number Publication date
EP3991380A1 (fr) 2022-05-04
FR3096535A1 (fr) 2020-11-27
US20220360454A1 (en) 2022-11-10

Similar Documents

Publication Publication Date Title
US11165890B2 (en) Secure client-server communication
EP2965192B1 (fr) Configuration et vérification par un fournisseur de confiance
EP3061027B1 (fr) Vérification de la sécurité d&#39;un serveur distant
US12069127B2 (en) Peer-to-peer (P2P) downloading
US8327441B2 (en) System and method for application attestation
US10833859B2 (en) Automating verification using secure encrypted phone verification
EP3937458B1 (fr) Dispositifs de noeud de chaîne de blocs dédiés et procédés et appareils de d&#39;ajout de noeud automatique
US11240043B1 (en) Issuance of certificates for secure enterprise wireless network access
CN112491972A (zh) 资源获取、分发、下载方法、装置、设备及存储介质
US11658963B2 (en) Cooperative communication validation
FR2877521A1 (fr) Dispositif, procede, programme et support de distribution d&#39;informations, d&#39;initialisation, dispositif, procede, programme et support de transfert d&#39;initialisation d&#39;authentification et programme de reception ...
FR2909243A1 (fr) Procede et systeme de controle du verrouillage / deverrouillage des fonctions d&#39;acces reseau d&#39;un terminal a fonctions multiples.
US11979393B2 (en) Customizable authentication system
US11159416B1 (en) Systems and methods of testing virtual private network communications using remote connectivity
US10637829B2 (en) Passport-controlled firewall
CN113039542A (zh) 云计算网络中的安全计数
EP3991380A1 (fr) Procedes et dispositifs de securisation d&#39;un reseau de peripherie a acces multiple
US11032708B2 (en) Securing public WLAN hotspot network access
US10972455B2 (en) Secure authentication in TLS sessions
FR3103987A1 (fr) Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede
WO2022206203A1 (fr) Authentification multifactorielle à résilience de connexion
CN114341799A (zh) 用于基于分布式账本技术的在云计算系统中的服务映像部署的方法和系统
EP3127374B1 (fr) Accès sécurisé à un réseau étendu via un réseau de communication mobile
WO2012156365A1 (fr) Procede de securisation d&#39;une platforme d&#39;authentification, dispositifs materiels et logiciels correspondants
Wentao et al. Trusted remote attestation scheme based on property

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: 20729764

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020729764

Country of ref document: EP

Effective date: 20220126