A system integrating a degraded mode public key management delegation based on a trust mechanism

Abstract

System integrating a delegation of public key management in degraded mode based on a trust mechanism. This multiple access edge computing system (10) includes: a key management infrastructure (20) having a central instance on a core network (12) and a local instance on a peripheral network (16); a user / administrator (U3) on the peripheral network, storing a key pair (K_U3, k_U3) and a certificate (Certif_U3) signed by the central instance, and having the privilege of being promoted to administrator in case of operation in degraded mode of the peripheral network;a server (S2) on the edge network storing a public key (K_ACL2) of the local instance, the user / administrator can enroll a temporary user (U4) by generating a pair of ephemeral keys (EK_U4, Ek_U4), requesting certification of the ephemeral key pair from the local instance and transmitting the ephemeral key pair and the generated ephemeral certificate (ECertif_U4) to the temporary user to allow them to access a service of the server. Figure for the abbreviation: Figure 1;

Description

Title of the invention: System integrating a degraded mode public key management delegation based on a trust mechanism

[0001] The present invention relates jointly to the field of multi-access edge computing systems - MEC (from the English "Multi-access Edge Computing") and the field of cryptography (more particularly key management infrastructures).

[0002] A MEC system allows services to be moved from a core network to a plurality of edge networks, which are located at the edge of the core network, as close as possible to the users' equipment. Instead of sending all the data from a user back to the core network, the edge network, positioned between that user and the core network, analyzes, processes, and / or stores all or part of the data. Collecting and processing data close to the user's equipment reduces latency and allows for higher bandwidth, which benefits the applications running on the user's equipment.

[0003] A MEC system therefore includes edge computing servers located in edge networks, "at the edge" of the core network. These servers host resources accessible to users belonging to various organizations and holding different types of rights.

[0004] The communication link between a peripheral network and the core network can be of any kind. In particular, for a mobile peripheral network (i.e., embedded in a vehicle), the link may include an air component (GSM, satellite,

[0005] Traditionally, user rights management is handled by a Key Management Infrastructure - KMI.

[0006] In an MEC system, the IGC is composed of several instances: a central instance of the IGC, located for example on a rights management server of the central network, and several local instances of the IGC, each located on a rights management server of an edge network.

[0007] Considering the central instance and the local instances of the IGC, there are several certification authorities - CAs, including a so-called central certification authority, located on the rights management server of the central network, and other so-called local certification authorities, located on the rights management servers of the edge networks.

[0008] The IGC manages several main tasks, including a public key certification service for users, a certificate issuance service for users and servers concerned, and a certificate validation / revocation service.

[0009] Thus, a border server wishing to authenticate a user (or more precisely the equipment used by that user) communicates with the central CA in order to verify the validity of the certificate provided by the user wishing to access the resources offered by that border server.

[0010] However, it may happen that the edge server is temporarily disconnected from the central AC, particularly when communication between the edge network and the central network is lost, for example, during the relocation of the edge network. The edge network is then said to be operating in degraded mode, whereas it was operating in normal or connected mode before the communication interruption.

[0011] By creating a hierarchy of CAs, that is, a local CA in each edge network connected to the central CA, degraded mode operation is possible. Thus, if an edge server can no longer query the central CA, it will query the local CA of the edge network to which it belongs.

[0012] However, a problem arises for a new user wishing to access the resources of a border server when they are not known to the IGC and the edge network hosting this border server is operating in degraded mode. Since the new user does not have a certificate issued by the central or local CA prior to the communication interruption, they cannot access the border server.

[0013] The article by B. Aslam et al., “Distributed certificate and application architecture for VANETs”, IEEE Military Communications Conference (MILCOM), 2009, addresses the case of vehicular ad-hoc networks (VANETs) where the issue arises of verifying certificate validity when the user is mobile and changes administrative regions, i.e., edge networks. This article proposes a system that allows an edge network B to validate the certificate of a user whose certificate was generated in an edge network A, when that user has moved from edge network A to edge network B. To do this, edge network B must contact edge network A to verify that the user's certificate in edge network A is indeed valid.However, the proposed system has two main limitations: the system must be proprietary in order to implement these information retrieval functions between different local certification authorities - CAs; moreover, this system only works in connection mode and does not work when the peripheral network B can no longer contact the peripheral network A.

[0014] The object of the present invention is to solve these mobility problems of the uti- readers to allow degraded operation of a perimeter network.

[0015] For this purpose, according to a first embodiment, the invention relates to a multi-access perimeter computer system comprising a core network and at least one perimeter network, the system comprising: a key management infrastructure, comprising a central instance hosted on the core network and comprising a central certification authority, and a local instance hosted on the perimeter network and comprising a local certification authority;a user / administrator connected to the edge network, storing a public key, a private key and a certificate, signed by the central certification authority, said user / administrator having rights allowing him / her to be promoted to administrator during a failover of the edge network into a degraded mode following a loss of communication with the central instance of the key management infrastructure;a server hosted on the edge network storing a public key of the local certification authority, the user / administrator being able, in degraded mode, to enroll a temporary user by generating a pair of ephemeral keys, comprising an ephemeral public key and an ephemeral private key, to transmit to the local certification authority a certification request for said pair of ephemeral keys, the certification authority being able to issue an ephemeral certificate associated with said pair of ephemeral keys in response to the user / administrator's certification request, the user / administrator being able to transmit the pair of ephemeral keys and the ephemeral certificate to the temporary user in order to allow them to access a service hosted on the server.

[0016] According to a second embodiment, the invention relates to a multi-access edge computer system comprising a core network and at least one edge network, the system comprising: a key management infrastructure, comprising only a central instance hosted on the core network and comprising a central certification authority; a user / administrator connected to the edge network, storing a public key, a private key and a certificate, signed by the central certification authority, said user / administrator having rights allowing him / her to be promoted to administrator during a failover of the edge network into a degraded mode following a loss of communication with the central instance of the key management infrastructure;a server hosted on the edge network storing a public key of the central certification authority, the user / administrator being adapted, in connected mode, to generate a plurality of ephemeral key pairs, each key pair comprising an ephemeral public key and an ephemeral private key and to transmit to the central certification authority a certification request for each pair of ephemeral keys in order to obtain a certificate for each pair of ephemeral keys, the user / administrator being adapted, in mode; degraded, to enroll a temporary user by transmitting to them a pair of ephemeral keys and the corresponding ephemeral certificate in order to allow the temporary user to access a service hosted on the server.

[0017] According to particular embodiments, the system comprises one or more of the following characteristics, taken individually or in all technically possible combinations:

[0018] - the user / administrator includes a key generation module allowing to derive the ephemeral key pair from the user / administrator key pair.

[0019] - the key generation module implements a key derivation algorithm unreinforced.

[0020] - the ephemeral certificate contains a temporary user identifier, the key ephemeral public, a user / administrator identifier and a signature calculated using the local certificate authority's private key or the local certificate authority's private key.

[0021] The invention also relates to a method for enrolling a temporary user implemented in one or the other of the preceding systems, characterized in that it comprises, while the edge network is operating in degraded mode, the steps of: generation by a user / administrator of the edge network of at least one pair of ephemeral keys and certification of said pair of ephemeral keys by a local certification authority or a central certification authority so as to obtain an ephemeral certificate associated with the pair of ephemeral keys; issuance by the temporary user of an enrollment request to the user / administrator of the edge network; and, transmission by the user / administrator to the temporary user of the pair of ephemeral keys and the associated ephemeral certificate.

[0022] According to particular embodiments, the system comprises one or more of the following characteristics, taken individually or in all technically possible combinations:

[0023] - The user / administrator generates the ephemeral key pair and requests the local certification authority, hosted on the edge network, to certify the ephemeral key pair.

[0024] - the user / administrator generates the ephemeral key pair in advance and requests, while the edge network is operating in connected mode, the central certification authority to certify the ephemeral key pair, the user / administrator storing the ephemeral key pair and the corresponding certificate in a vault and selecting from said vault the necessary information when enrolling the temporary user.

[0025] - The user / administrator is suitable for deriving the ephemeral key pair from the user / administrator key pair by implementing a non-strengthened key derivation algorithm so as to be able to trace the user / administrator who participated in the enrollment of a temporary user.

[0026] - the method includes a step of verifying the user's identity temporary by reuser / administrator.

[0027] The invention and its advantages will be better understood upon reading the following detailed description of a particular embodiment, given solely by way of non-limiting example, this description being made with reference to the accompanying drawings in which:

[0028] [Fig-1] Fig. 1 is a schematic representation of one embodiment of a MEC system according to the invention;

[0029] [Fig.2] [Fig.3] Figures 2 and 3 are representations in the form of chro diagrams of an embodiment of a method for operating the MEC system of [Fig. 1] in connected mode; and,

[0030] [Fig.4] [Fig.5] Figures 4 to 5 are representations in the form of chro diagrams of an embodiment of a method of operation of the MEC system of [Fig.1] in degraded mode.

[0031] The method according to the invention allows the management of access of users belonging to various organizations to resources located on an edge server, taking into account the possibility that the edge network hosting this edge server may operate in degraded mode, i.e. be disconnected from the central instance of riGC.

[0032] In particular, the method according to the invention makes it possible to respond to the case of new users wishing to access resources located on the edge server when the edge network hosting this edge server is in degraded mode and these new users have not previously been registered with the central CA or the local CA of the edge network in question and therefore do not have a certificate signed by this central CA or this local CA.

[0033] The method according to the invention allows mobility between edge networks, that is to say the ability for a new user, referred to as a temporary user in what follows, to access other edge networks of the MEC system than the one to which he has just been authorized to access.

[0034] In general, the method according to the invention makes it possible to delegate, in degraded mode, the management of public keys based on a trust mechanism implemented by one or more users / administrators of the edge network.

[0035] This solution allows a user / administrator to generate new temporary, or ephemeral, keys for a temporary user. These ephemeral keys are child keys derived from the user / administrator's parent keys. The user / administrator then issues a certificate request to the local CA. The local CA generates and signs a certificate for this temporary user.

[0036] Advantageously, with the use of unstrengthened ephemeral keys, it is possible to link a child public key to the parent public key from which it originates, and thus find the user / administrator who generated it. This allows for traceability.

[0037] Furthermore, since the parent and child certificates are separate, it is possible to revoke the child certificate without interfering with the parent certificate.

[0038] ARCHITECTURE

[0039] With reference to [Fig.1], the system 10 is an ECM system. It comprises a core network 12 and a plurality of edge networks, for example three edge networks, 14, 16 and 18.

[0040] System 10 is equipped with an IGC, which is the key management infrastructure that allows certificates to be issued to users wishing to access the resources of system 10, including the resources of the various edge networks.

[0041] The core network 12 includes a central instance 20 of 1TGC, which comprises:

[0042] - a central registration authority - AEC 22, which checks whether a user is identified as a legitimate user of the system;

[0043] - a central certification authority - ACC 24, which generates and maintains the certificates for legitimate users; and,

[0044] - a central validation authority - AVC 26, which offers a verification service the validity of a certificate upon request from a server.

[0045] In particular, the ACC 24 stores an ACC identifier, ID_ACC, an ACC key pair (consisting of a public key K_ACC and a private key k_ACC), as well as an ACC certificate, Certif_ACC.

[0046] Each edge network includes a local instance of T IGC which is own. The local TIGC instance supports key management in degraded mode, that is, when communication with the central 20 instance of 1TGC is lost, particularly when communication between the edge network and the core network is lost.

[0047] A local instance of the IGC comprises:

[0048] - a local registration authority, which checks whether a user is identified as a legitimate user of the system;

[0049] - a local certification authority, ACL, which generates and maintains up-to-date certificates credentials for legitimate users; and,

[0050] - a local validation authority, which offers a validity verification service of a certificate upon request from a server.

[0051] According to the invention, the local instance of the IGC is lightweight and essentially comprises only the ACL. The role of the local registration authority is to verify the Training on user identity. The role of local validation authority involves managing the registration and verification of certificates in an LDAP directory. The user who is promoted to edge network administrator in disconnected mode has the permissions / rights required to perform the functions of local registration authority and local validation authority.

[0052] Accordingly, in what follows, "local instance of the IGC" and "local certification authority" are essentially synonymous.

[0053] Thus, the peripheral network 14 has an ACL1, the peripheral network 16 has an ACL2 and the peripheral network 18 has an ACL3.

[0054] A local certification authority, such as FACL2, stores an ACL identifier, ID_ACL2, an ACL key pair (consisting of a public key K_ACL2 and a private key k_ACL2), and an ACL certificate, Certif_ACL2.

[0055] It should be noted that a local certification authority is signed by the central certification authority, so that the chain of trust in the hierarchy of certification authorities is guaranteed.

[0056] Each edge network also includes one or more edge servers, each designed to provide predefined services to users. For example, network 14 includes the SI server, network 16 includes an S2 server, and network 18 includes an S3 server and an S4 server.

[0057] At any given moment in connected mode, none, one or more user(s) are connected to an edge network.

[0058] For example, in [Fig.1], a user U1 and a user U2 are connected to the edge network 14, a user U3 to the edge network 16 and a user U5 to the edge network 18.

[0059] At the moment, user U4 is not connected to any of the edge networks.

[0060] Following the example of user Ul, user 1's equipment stores the in training courses:

[0061] - the user identifier ID_U1, such as their name and TAC code (Type Allocation Code) of the equipment that the user uses to access the resources;

[0062] - a key pair consisting of a public key K_U1 and a private key k_Ul; and

[0063] - a Certif_U 1 certificate.

[0064] The electronic certificate Certif_Ul is issued by the ACC 24 while the edge network 14 is operating in connection-oriented mode. This certificate contains a data set including:

[0065] - the user identifier ID_U1;

[0066] - the public key K_U 1 of user U1;

[0067] - the ID_ACC identifier of the ACC 24 that granted the certificate; and,

[0068] - the signature affixed by the ACC using its private key, k_ACC.

[0069] ACC 24, issuer of the Certif_Ul certificate, can itself be part of a chain of trust, that is to say, a hierarchy of certification authorities.

[0070] The issuing ACC 24 is then certified by a higher certification authority, for example an intermediate certification authority, which itself is certified by a root certification authority of the hierarchy (in an example of a three-level certification hierarchy).

[0071] The issuing ACC 24 therefore has a Certif_ACC certificate issued by the higher certification authority in the chain of trust of which it is a part.

[0072] It is considered that a peripheral network, such as network 16, which was operating in connected mode, switches to degraded mode from the loss of connection with the core network 12.

[0073] User U3 is a historical user, possessing a certificate issued by the central instance of the IGC before the switch to degraded mode.

[0074] User U4 is a new user who connects to the edge network 16 after the latter has already switched to degraded mode. U4 does not possess any certificate issued by the IGC of system 10.

[0075] The local instance of the IGC ensures continuity of service in disconnected mode, that is, when the edge network it equips is no longer connected to the core network 12.

[0076] PROCESS

[0077] Operation in connected mode

[0078] Fig. 2 illustrates the steps of a process 100 for certifying a new user by the central instance of the IGC, such as user U3, when the intermediate edge network to which this user is connected, such as edge network 16, is operating in connected mode.

[0079] The user has an ID_U3 identifier.

[0080] Step 110 corresponds to the assignment of a key pair, a public key K_U3 and a private key k_U3, to the user U3. The method of generating this key pair by the user or another entity that then provides it to the user is not specified. It conforms to the prior art.

[0081] Typically, the user generates their own public / private key pair locally. There are several ways to do this, including using the "OpenSSL" algorithm, which is widely used to generate RSA or DSA keys, typically 2048 bits long. Unlike the generation of ephemeral keys introduced later, the character strings of the generated keys are entirely random and are not linked to each other in any way.

[0082] In step 120, user U3 issues a certification request to the central instance 20 of the IGC, more specifically to the AEC 22. This request includes the user's identifier, ID_U3, and the user's public key K_U3.

[0083] In step 130, AEC 22 verifies the identity of the user on the basis of the ID_U3 identifier present in the request, by consulting an up-to-date database of legitimate users of system 10.

[0084] If user identity verification fails, the certification request is rejected.

[0085] In step 140, following a positive verification of the user's identity, the AEC 22 transmits the certification request to the ACC 24.

[0086] In step 150, the ACC 24 creates a certificate for the new user. The certificate incorporates the user's identifier ID_U3, the user's public key K_U3, and the ID_ACC of the issuing ACC 24. This set of information is then signed to obtain a Certif_U3 certificate. The signature is calculated using the ACC 24's private key k_ACC.

[0087] In step 160, the ACC 24 responds to the user's certification request by transmitting the created Certif_U3 certificate.

[0088] In step 170, the received Certif_U3 certificate is registered on the equipment used by the user.

[0089] In parallel, in step 180, ACC 24 registers the Certif_U3 certificate in a first list of valid certificates. This list includes, in particular, for each certificate, a validity date. ACC 24 also maintains a second list of revoked certificates, or CRL (Certificate Revocation List).

[0090] In practice, the list of valid certificates and the list of revoked certificates can be published by an electronic directory of the type "Lightweight Directory Access Protocol" - LDAP. Such a directory associates the list of users and their certificates with permissions or rights (for example, the authorization to be promoted to user / administrator) and advantageously stores the data of the certificate validation / revocation list.

[0091] ACC 24 regularly transmits (step 185) these two lists to AVC 26.

[0092] In step 190, AVC 26 records the two updated lists received from ACC 24.

[0093] Fig. 3 illustrates the steps of a 200 authentication process with a server, such as server S2, of a user with a certificate, such as user U3, while the edge network through which this user accesses the server is operating in connection mode.

[0094] The method 200 is implemented when the user U3 seeks to access a service offered by the S2 server.

[0095] According to this process, in step 210, the user transmits the Certif_U3 certificate to the S2 server.

[0096] In step 220, the server first verifies the authenticity of the issuer of the Certif_U3 certificate, i.e., the ACC 24, using the ACC 24 public key K_ACC to decrypt the Certif_U3 certificate. The S2 server regularly obtains the public keys of the various certification authorities.

[0097] If the verification of the sender's authenticity fails, the server rejects the user's connection request.

[0098] In step 230, if the authenticity of the certificate issuer is verified successfully, the S2 server then verifies the validity of this Certif_U3 certificate. To do this, the S2 server sends a request to the AVC 26 to verify the validity of the Certif_U3 certificate.

[0099] In step 240, AVC 26 consults the second list of revoked certificates to verify that the Certif_U3 certificate is not revoked, and then the first list of valid certificates to verify if the Certif_U3 certificate is still valid.

[0100] In step 250, AVC 26 responds to the request from the S2 server by indicating whether or not the Certif_U3 certificate is valid.

[0101] If not, the server rejects the user's connection request.

[0102] If so, the S2 server considers authentication successful and uses the information from the Certif_U3 certificate to communicate with the user U3, including encrypting communications using the user's K_U3 public key. The S2 server provides the user with its public key so that the user can encrypt communications using the server's public key.

[0103] Operation in degraded or disconnected mode.

[0104] Each historical user of the system, i.e. before the switchover of an edge network to degraded mode, has a certificate issued by the ACC 24 the central instance 20 of the IGC.

[0105] Furthermore, each server possesses the K_ACC public key of ACC 24, enabling it to verify the authenticity of a certificate issued by that CA. Each server received this public key while the system was operating normally.

[0106] Following the occurrence of a communication breakdown with the central instance 20 of the IGC, the peripheral network, in our example peripheral network 16, switches to degraded mode.

[0107] A historical user of the edge network is then elected administrator, for example user U3 becomes administrator Admin of edge network 16.

[0108] In this embodiment, the user promoted to administrator has permission to query the local certification authority ACL so that they can be created and signed by the latter of certificates for temporary users.

[0109] The user / administrator U3 has an identifier, ID_U3, and a key pair K_U3 and k_U3.

[0110] As a historical user, U3 user / administrator also has a Certif_U3 certificate issued by ACC 24 of central instance 20.

[0111] Fig. 4 illustrates the steps of a 300 process for certifying a temporary user, for example user U4, by a user / administrator of the edge network operating in degraded mode, for example user U3.

[0112] In step 310, the temporary user sends an enrollment request from their equipment to the equipment of user / administrator U3, indicating their identity, ID_U4. More specifically, user U4 sends the enrollment request to the edge network 16. On this network is an electronic directory, for example of the LDAP type, which contains the list of certificates of users authorized to access the edge network 16, along with the permissions of these users. These permissions include, in particular, the historical users of the edge network known as "administrators," who have higher rights than regular historical users, specifically the right to enroll new users in degraded mode and thus to generate new certificates on the fly using the local certificate authority located on this edge network.Based on the information in the electronic directory, the enrollment request is routed to user / administrator U3.

[0113] In step 320, user / administrator U3 verifies the identity of user U4. This is done, for example, visually, with user / administrator U3 recognizing user U4, or by verifying an identification badge presented by user U4 to user / administrator U3. It should be noted that an edge network, particularly a mobile one, such as a tactical bubble, is small in size, so that users are physically close to each other.

[0114] Once the identity of the temporary user has been verified, in step 330, the user / administrator U3 generates a pair of ephemeral keys for the user U4: a public key EK_U4 and a private key Ek_U4. These keys are generated by derivation of the public keys K_U3, k_U3 of the user / administrator U3.

[0115] In a step 340, the user / administrator U3 responds to the enrollment request by transmitting to the user the ephemeral keys EK_U4 and Ek_U4 calculated.

[0116] In a step 350, the ephemeral keys EK_U4 and Ek_U4 are recorded on the equipment used by user U4.

[0117] In parallel, in a step 355, the user / administrator U3 issues a request to the ACL2 indicating the identifier of the user U4 and the ephemeral keys EK_U4 and Ek_U4 generated for this user.

[0118] In step 360, ACL2 accepts the request from user / administrator U3 who has the rights to request the local certification authority ACL2 to generate certificates for the temporary users that this user / administrator has admitted on the edge network.

[0119] ACL2 then creates an ephemeral certificate ECertif_U4 for the temporary user U4. This ephemeral certificate associates the user identifier ID_U4, the ephemeral public key EK_U4 and the certificate signature affixed by ACL2 using its private key, k_ACL2.

[0120] In step 365, ACL2 transmits the created ephemeral certificate ECertif_U4 to user / administrator U3.

[0121] In step 370, user / administrator U3 forwards the ephemeral certificate ECertif_U4 to user U4. User / administrator U3 also updates the LDAP directory with certificate validity / revocation information for user U4.

[0122] In a step 380, the received ephemeral certificate ECertif_U4 is registered on the equipment used by user U4.

[0123] Figure 5 illustrates, in its upper part, the steps of a 400 process for authenticating the user / administrator U3 with the local certification authority, ACL2 (or, more precisely, with the edge server providing the local certification service, i.e., the edge network server on which ACL2 is running). This will then allow the user / administrator U3 to request certification of temporary users from this local certification authority.

[0124] In a step 410, the user / administrator U3 transmits their Certif_U3 certificate to the server.

[0125] In a step 420, the local certification authority, ACL2, verifies the authenticity of the ACC 24 that issued the Certif_U3 certificate using the ACC 24's public key K_ACC, which the local certification authority, ACL2, possesses.

[0126] When the verification fails, the user / administrator's certificate is not recognized as valid and requests from the user / administrator to the local certification authority will not be processed.

[0127] When the verification is successful, the user / administrator U3 is recognized as having permission to send requests to the local certification authority. Information from their certificate is advantageously stored for later use by the local certification authority, including the public key K_U3 of the Certif_U3 certificate.

[0128] A possible subsequent use is, for example, in step 430, for the user / administrator U3 to connect to the LDAP directory to grant rights access to the temporary user U4, such as access rights to all or part of the services offered by the S2 edge server(s) of the edge network.

[0129] Fig. 5 illustrates, in its lower part, the steps of a 500 process for authenticating a temporary user, such as user U4, who has an ephemeral certificate with a server offering a service, such as server S2, of an edge network in degraded mode.

[0130] When the temporary user U4 seeks to access a service offered by the border server S2, then, in a step 550, it connects to the server S2 and transmits its ephemeral certificate ECertif_U4 to it, so that the server S2 can authenticate it.

[0131] In step 560, the S2 server verifies the authenticity of the ephemeral certificate ECertif_U4 by checking the local certificate authority that signed it and, advantageously, the parent that generated the public key EK_U4 from its own key, namely the user / administrator. The S2 server may optionally consult the validity / revocation information contained in the LDAP directory.

[0132] To do this, the S2 server uses the public key of the local certification authority ACL2 that issued the ECertif_U4 certificate, in this case the public key K_ACL2 of PACL2.

[0133] Moreover, advantageously, the S2 server uses the public key K_U3 of Fuser / administrator U3 to check the key derivation, that is to say that there is indeed consistency between the parent public key (that of U3) and child public key (that of U4).

[0134] The S2 server knows the public key K_U3 for example by querying the local LDAP directory.

[0135] When authentication fails, the server rejects the temporary user's login request.

[0136] When authentication succeeds, in a step 570, the server uses the information contained in the ephemeral certificate ECertif_U4 (including the public key EK_U4) to encrypt communications with the temporary user (the server indicating to this user its public key so as to enable it to encrypt communications).

[0137] Alternatively, the S2 server can, after verifying the authenticity of the certificate issuer (step 560), query the LDAP directory to find out if the ephemeral certificate ECertif_U4 is valid and / or is not revoked (step similar to steps 230-240-250).

[0138] It should be noted that it is indeed the K_U3 key which is used for the authentication of the user / administrator U3 with FACL2 and the K_ACL2 key for the authentication of the temporary user U4 with the server S2.

[0139] For the implementation of step 330 of ephemeral key generation by the user / administrator equipment, the latter runs a key derivation module 61.

[0140] In cryptography, a key derivation function is a function that allows one or more keys to be derived using a pseudo-random function. The key derivation function can be used to strengthen keys by stretching them or to obtain keys of a certain format.

[0141] In particular, child key derivation (CKD) algorithms allow the calculation of a child key from the key of a parent and an index i. For example, the "BIP32" algorithm is used.

[0142] Two key derivation operations are performed by the key derivation module 61: the first allows the child public key (i.e. the ephemeral public key EK_U4) to be derived from the parent public key (i.e. the public key K_U3); and the second allows the child private key (i.e. the ephemeral private key Ek_U4) to be derived from the parent private key (i.e. the private key k_U3).

[0143] Two types of child keys can be derived:

[0144] - a "hardened" child key, using an index i > 23i, in which case It is not possible to prove that a child key is linked to a parent key;

[0145] - a normal or non-hardened child key, using a subscript i < 231, in which case we can prove that a child key is linked to a parent key, using only these two keys.

[0146] In the advantageous embodiment of the invention, the key derivation module 61 makes it possible to derive unstrengthened child keys so that it is possible for a server, for traceability purposes, to find the user / administrator who generated the ephemeral key pair for the temporary user, i.e. who identified this temporary user as a legitimate user of the system 10 and allowed him to enroll on the edge network.

[0147] Beyond the certification of ephemeral keys by the ACL, the user / administrator issues the created certificate and revokes and / or updates the ephemeral certificates in service. The functions are similar to those of the central instance of the IGC.

[0148] The possible revocation of a child certificate does not interfere with the validity of the parent certificate.

[0149] When the temporary user U4, having been registered by the user / administrator U3 of the edge network 16 in degraded mode on the local AC, ACL2, of this edge network, moves to another edge network, which is operating in connected mode, for example network 18, the authentication of the user U4 is done in the following way.

[0150] Initially, the S4 server to which user U4 seeks to connect checks the validity of the certificate of user ECertif_U4.

[0151] To do this, the S4 server first derives the parent public key K_U3 from the user / administrator who generated the child public key EK_U4 for the user U4. This is possible when dealing with a non-hardened child key.

[0152] Next, the S4 server verifies that the ECertif_U4 certificate of user U4 was indeed signed by the local PAC of the edge network on which U3 is a user / administrator. The S4 server uses the local PAC public key K_ACL2 for this purpose. This key is known because it is regularly exchanged within the system.

[0153] In addition, the S4 server queries the central instance of IGC 20 to find out if the Certif_U3 certificate of the U3 user / administrator is valid and has not been revoked.

[0154] If all this information is correct, then the temporary ECertif_U4 certificate of user U4 is revoked and the latter must initiate the classic procedure to obtain a certificate from the central instance of the IGC, as is normally the case in connected mode.

[0155] When the temporary user U4, having been registered by the user / administrator U3 of the edge network 16 in degraded mode on the local AC, ACL2, of this edge network, moves to another edge network which is operating this time in disconnected mode, for example network 18, the authentication of the user U4 is done in the following manner.

[0156] If the two edge networks 16 and 18 can communicate with each other, a security context sharing is achieved during the federation of these two edge networks.

[0157] During this context sharing, the public keys of the local certification authorities of the two edge networks are shared in particular (for the validation of ephemeral certificates) and advantageously the public keys of the user s / administrators of each edge network (to verify the parent / child link of the generation of ephemeral keys).

[0158] During this context sharing, it is also preferable to update the rights of temporary users in the LDAP directories of both edge networks and the lists of both edge networks relating to the validity / revocation of certificates of temporary users.

[0159] Thus, when the temporary user U4 connects to the peripheral network 18, there is verification of the validity of the certificate of the temporary user U4 by the local instance of the IGC of the peripheral network 18, ACL3, using the public key K_ACL2 of the local PAC ACL2 of the peripheral network 16 (and advantageously the parent / child relationship of the ephemeral keys), but also verification of the rights of this temporary user to the services offered by the peripheral network 18.

[0160] Thus, the edge network 18, which does not know the temporary user U4 accepted by the edge network 16, can accept this temporary user U4 by verifying the validity of its ephemeral certificate (issued by the edge network 16).

[0161] When a historical user, i.e. already registered by the central instance 20 of the IGC, moves to an edge network in degraded mode, authentication is done in the following way.

[0162] This is for example the case of the user Ul, who seeks to access a resource on the S2 server of the edge network 16 operating in degraded mode.

[0163] All edge networks are aware of the central CA 24's public key K_ACC. This key was pushed during connection-oriented mode. Thus, in disconnected mode, edge network 16 can verify the validity of the historical user Ul's Certif_Ul certificate, provided that this certificate was signed by CA 24.

[0164] In addition, in connected mode, copies of the second list indicating revoked certificates are created each time this list changes and pushed to the local IGC instances present in each edge network. Alternatively, they are stored in the LDAP directory.

[0165] On the other hand, if the certificate of the historical user U4 is revoked while the edge network 16 is already operating in disconnected mode, this edge network will not be able to know about it, as it cannot receive an updated copy of the CRL list maintained by the central instance of the IGC.

[0166] It should be noted that certain users have the privileges required to access the data stored in the LDAP directory and perform necessary operations such as updating another user's rights or synchronizing lists of valid / revoked certificates. These users may be the user / administrator responsible for generating ephemeral keys or another user on the edge network. These users are known in advance, and their identities (for example, by means of a suitable certificate) and privileges are recorded in the LDAP directory.

[0167] VARIANT

[0168] In the primary embodiment described above, the user / administrator has the rights to use the local certification authority, which is part of the chain of trust.

[0169] To avoid exposing such a local certification authority in the edge network (in particular its private key), an alternative embodiment will now be presented.

[0170] While the edge network 16 is operating in connected mode, a user / administrator generates a group of ephemeral key pairs, each ephemeral key pair having an ephemeral public key and an ephemeral private key.

[0171] This group of ephemeral key pairs is stored in a vault on the edge network 16. This vault is, for example, a secure database.

[0172] Then, the user / administrator queries the central instance of the IGC to obtain a certificate for each pair of ephemeral keys in this group.

[0173] The ACC 24 thus generates a certificate containing the ephemeral public key (from which the identity of the user / administrator can be traced, when it is possible to trace back to their public key), the ID_ACC identifier of the central CA 24, and a signature calculated using the private key k_ACC of the central CA. The certificate may advantageously have a validity period defined by the user / administrator.

[0174] The certificate thus generated is sent back to the user / administrator who stores it in the vault with the corresponding pair of ephemeral keys.

[0175] In degraded mode operation, when a temporary user attempts to access network 16, after verifying their identity, the user / administrator selects a pair of ephemeral keys and the corresponding certificate from the vault. This information is then transmitted to the temporary user, who can then use it to access the services of the edge network server(s).

[0176] In this variant, there is no longer a local certificate authority on the edge network. The private key that signs certificates for temporary users is not that of the local CA but that of the central CA. Therefore, the certificate keys are not exposed in the event of a compromise of the edge network.

[0177] Furthermore, this variant allows a temporary user to move between edge networks. A temporary user can move from the edge network on which they were enrolled to another edge network, even when both edge networks are disconnected and cannot communicate with each other (to perform security context sharing). This is because the host edge network can verify the temporary user's certificate since it was signed by the central CA, which is known to the host network.

[0178] If we want to implement the possibility of finding the user / administrator who generated the temporary user's key pair, it is necessary to share the LDAP directories between edge networks while they are operating in connected mode, so that the host network knows the users / administrators of the enrollment network, before these two edge networks switch to disconnected mode and while they cannot communicate with each other (to perform security context sharing).

Claims

Demands

1. A multi-access edge computing system (10) comprising a core network (12) and at least one edge network (16), the system comprising: - a key management infrastructure (20), comprising only a central instance hosted on the core network and comprising a central certification authority (24); - a user / administrator (U3) connected to the edge network, storing a public key (K_U3), a private key (k_U3) and a certificate (Certif_U3), signed by the central certification authority, said user / administrator having rights enabling him / her to be promoted to administrator to perform local registration authority and local validation authority functions, during a failover of the edge network into a degraded mode following a loss of communication with the central instance of the key management infrastructure;- a server (S2) hosted on the edge network (16) storing a public key (K_ACC) of the central certification authority, the user / administrator being adapted, in connected mode, to generate a plurality of ephemeral key pairs, each key pair comprising an ephemeral public key (EK_U4) and an ephemeral private key (Ek_U4), and to transmit to the central certification authority a certification request for each pair of ephemeral keys in order to obtain a certificate for each pair of ephemeral keys, the user / administrator being adapted, in degraded mode, to enroll a temporary user (U4) by transmitting to him a pair of ephemeral keys and the corresponding ephemeral certificate in order to allow the temporary user to access a service hosted on the server (S2).;

2. System according to claim 1, wherein the user / administrator (U3) includes a key generation module (61) enabling the ephemeral key pair to be derived from the user / administrator key pair.

3. System according to claim 2, wherein the key generation module (61) implements an unstrengthened key derivation algorithm, in order to be able to link a child public key to the parent public key from which it is derived, and thus find the user / administrator who generated it.

4. A system according to any one of claims 1 to 3, wherein the ephemeral certificate includes the ephemeral public key (EK_U4), a user / administrator identifier (ID_U3) and a signature calculated using the private key (k_ACL2) of the central certification authority.

5. A method for enrolling a temporary user implemented in a system (10) conforming to any one of claims 1 to 4, characterized in that it comprises the steps of: - generation by a user / administrator (U3) of the edge network of at least one pair of ephemeral keys and certification of said pair of ephemeral keys by a central certification authority so as to obtain an ephemeral certificate associated with the pair of ephemeral keys; and, while the edge network (16) is operating in degraded mode, - issuance (310) by the temporary user (U4) of an enrollment request to the user / administrator (U3) of the edge network; and, - transmission (340, 370) by the user / administrator to the temporary user of the pair of ephemeral keys and the associated ephemeral certificate.

6. A method according to claim 5, wherein the user / administrator generates (330) the ephemeral key pair in advance and requests, while the edge network is operating in connection-oriented mode, the central certification authority to certify the ephemeral key pair, the user / administrator storing the ephemeral key pair and the corresponding certificate in a vault and selecting from said vault the necessary information when enrolling the temporary user.

7. A method according to any one of claims 5 to 6, wherein the user / administrator (U3) is adapted to derive the ephemeral key pair from the user / administrator key pair by implementing an unreinforced key derivation algorithm so as to be able to trace the user / administrator who participated in the enrollment of a temporary user.

8. A method according to any one of claims 5 to 7, comprising a step of verification (320) of a temporary user's identity by the user / administrator.

Images