WO2024079498A1

WO2024079498A1 - Zero-knowledge remote security checking method

Info

Publication number: WO2024079498A1
Application number: PCT/IB2022/000780
Authority: WO
Inventors: Renaud LIFCHITZ
Original assignee: Holiseum
Priority date: 2022-10-10
Filing date: 2022-10-10
Publication date: 2024-04-18

Abstract

An access control method for checking a security compliance of a remote equipment (EQ) to security requirements, the method including steps of: obtaining (51) a zero-knowledge proof protocol depending on the security requirements, receiving (52) from the remote equipment (EQ) a zero-knowledge proof computed using the zero-knowledge proof protocol and security parameters related to said remote equipment (EQ), said zero-knowledge proof being signed by a trusted module of the remote equipment (EQ), authorizing (58) an access for said remote equipment (EQ) at least if it is assessed that (53, 54, 55): - the signed zero-knowledge proof is related to an authorized entity related to the trusted module of the remote equipment (EQ), - the signed zero-knowledge proof has been computed according to the zero-knowledge proof protocol; and - the signed zero-knowledge proof demonstrates that the security compliance of the remote equipment (EQ) is valid.

Description

Title : ZERO-KNOWLEDGE REMOTE SECURITY CHECKING METHOD

Field of disclosure

[1] The present disclosure relates to the field of cybersecurity and digital trust. More particularly, the present disclosure relates to secure access control methods for electronic devices.

Background

[2] The increasing global mobility has led to an expanded usage of solutions enabling remote access such as cloud or Virtual Private Networks (or VPNs). Such remote access also applies for remote working and Bring Your Own Device (or BYOD) trends. Such context raises new security and digital trust issues as traditional approaches solely based on perimeter defense become obsolete. For example, in the case of business computer networks, many issues raise in resource access control, as confidential resources (e.g., services, assets, data...) of a company’s information system (or IS) are to be shared with a plurality of users (e.g., employees) on a plurality of remote machines.

[3] In such context, digital trust solutions have been developed so as to integrate a zero-trust security policy of the network. The main principle of zero-trust is to avoid implied trust in all users as well as in computer equipment, and to allow access (or at least a privileged level of access) to the company assets only if such systems have been assessed to be legitimate and authorized of access by a server of the company’s information system.

[4] However, the zero-trust principle is arduous to effectively apply in practice. Indeed, it relies on a framework which is supposed to systematically collect and assess proof information provided by proving computer equipment throughout digital interactions with such equipment. Yet, guaranteeing the concurrent accuracy, confidentiality and integrity of such proof information remains a challenge.

[5] Indeed, in order to assess the compliance of an equipment, many existing digital trust solutions rely on a blacklisting approach, which focuses on threat detection. A blacklisting access control approach consists in identifying potentially suspicious or malicious activities running on an equipment. To that end, blacklisting access control may include checking for suspicious heuristic behaviors, viral signatures and/or Indicators of Compromise (or loC) based on a blacklist of malicious software (e.g., viruses, worms, Trojan horses, spyware, malware, ...). The non-detection of such suspicious or malicious activities leads, by default, to a granted access for the equipment. Yet, such blacklisting approach does not positively check the security level (since it is threat-centric, thus a negative check) of the end-point equipment which enrolls into the company’s computer network and accesses its confidential assets. Companies may have many security constraints of different sources (e.g., company policy, contractual or regulatory constraints...) and different granularities (e.g., services and assets may require different levels of security and/or focus on different security aspects). There is thus an issue for access control solutions to check that a given computer equipment is effectively compliant to specific security requirements of a company’s IS for a specific access request. [6] Moreover, there is a predominant challenge for existing access control solutions to assess the authenticity of the proof information provided via the equipment, that is, to ensure that the provided security proof, regardless of the nature of its result, has not been altered of forged and that the access control solution is performed based on genuine information originating from a genuine proving equipment.

[7] Plus, the proof information provided by a proving equipment in the context of an access control protocol may potentially contain sensitive data, since proof information reflects (or may reflect) a level of vulnerability of the proving equipment. The transmission and the storage of such sensitive information thus encounter a confidentiality issue, notably in regard to risks of data interception and compromise of the server receiving such proof information.

[8] As a consequence, existing digital trust and access control protocols to assess the security level of remote devices raise many compliance, integrity and confidentiality issues.

Summary of disclosure

[9] This disclosure addresses such issues and proposes a solution.

[10] According to a first aspect of the disclosure, it is proposed an access control method for checking a security compliance of a remote equipment to security requirements, the access control method including steps of: obtaining a zero-knowledge proof protocol depending on the security requirements, receiving from the remote equipment a zero-knowledge proof computed using the zeroknowledge proof protocol and security parameters related to said remote equipment, said zeroknowledge proof being signed by a trusted module of the remote equipment, authorizing an access for said remote equipment at least if it is assessed that:

- the signed zero-knowledge proof is related to an authorized entity related to the trusted module of the remote equipment,

- the signed zero-knowledge proof has been computed according to the zeroknowledge proof protocol; and

- the signed zero-knowledge proof demonstrates that the security compliance of the remote equipment is valid.

[11] As a consequence, the proposed access control method provides a positive, whitelisting approach for assessing the security compliance of a remote equipment with respect to predetermined security requirements. The proposed method thus enables a controlling device performing the access control method to grant access to pieces of remote equipment which positively meet specific preset criteria. Such approach is notably more restrictive and targeted than existing blacklist-based access control methods, which grant a by-default access to remote devices when no suspicious activity or behavior is detected. [12] Thus, the proposed access control method enables a company’s server (e.g., a controlling device) performing the method to specify tailored security requirements, which may vary depending on the server, the company and/or the nature of the resource to be accessed for instance.

[13] Moreover, the proposed access control method enables to protect the confidentiality of the proof information provided by the remote equipment whose security compliance is assessed. Indeed, by relying on a zero-knowledge proof protocol and a resulting zero-knowledge proof, the proposed method avoids revealing data related to a level of security (or a level of risk) of the remote equipment while still enabling the latter to prove its compliance to a given level of security requirement. Thus, the proposed method advantageously anticipates security breaches both during the transmission of the proof information (i.e., in case of data interception in the communication channel between the remote equipment and the receiver of the proof) and during the reception, storage and/or analysis of the proof information by the receiver (e.g. in case of compromise of the controlling device verifying the accuracy of such proof). In the context of the proposed method, a malicious access to the proof information does not leak confidential security information regarding the remote equipment.

[14] Advantageously, the proposed access control method enables a cumulative security check of the remote equipment. Indeed, the proposed method concurrently checks that the proof information comes from a legit remote device (that is, the proof information indeed comes from an expected or authorized proving device), that the proof information has been computed using the expected proof protocol and infrastructure, and that the proof information actually complies with the security requirements (e.g., set by the verifying side). Shall any of such criteria not be satisfied, the proposed method denies access to the remote equipment. The proposed method thus avoids scenarios of forged proof information and/or proof information computed by a remote equipment yet claimed by another remote device.

[15] By an access control method, it may be understood a process to check the security compliance of a given remote equipment before granting (or authorizing) an access to such remote equipment. The access control method (or access granting method) may be performed by a verifying device, such as a company’s server (e.g., a router, a firewall), generically referred to as a controlling device. Such controlling device may then check the compliance of each remote equipment before routing data from and/or to the remote equipment.

[16] By checking a security compliance of a remote equipment to security requirements, it may be understood assessing that a given remote equipment complies with security criteria known by the controlling device performing the proposed method. In particular, checking a security compliance of a remote equipment to security requirements may involve checking both the remote equipment proving its security compliance and the proof of the compliance itself. The checking of a security compliance of a remote equipment may thus involve checking proof information provided by the remote equipment. Such checking may then involve checking notably the provenance of the proof, the accuracy of the proof, the computation of the proof, the result of the proof. [17] By security requirements, it may be understood preset, preconfigured and/or predefined criteria which, when met by a remote equipment, lead to a granted access for such remote equipment. Such security requirements may for example relate to expected hardware and/or software identifiers, capabilities, updates, features, versions, security means (e.g., firewalls, antivirus) of a remote device. Such security requirements may also relate to user’s credentials, level of privilege on the remote equipment. Such security requirements may be set by the controlling device and/or by an information system including the controlling device. Such security requirements may be related to business, service, contractual or regulatory constraints for example. Such security requirements may be related to specific services, assets and/or resources to be accessed. Such security requirements may be related to requirements of a secure private network.

[18] By a remote equipment, it may be understood any electronic device, such as a computer device, a smartphone, a tablet, a laptop, an Internet of Thing (or loT) device for example. The remote equipment may notably belong to an information system, for example a company’s information system. The remote equipment may be connected to a private and/or public communication network. The remote equipment may be outside of the perimeter of a company’s network. The remote equipment may be a company device or a personal device, for example in the context of a Bring Your Own Device (BYOD) or a remote working policy. The remote equipment may intend to connect to a private communication network of the company, for example by accessing a Virtual Private Network (or VPN) deployed by the company. The remote equipment may intend to access a specific service, resource and/or asset managed by the company. For example, the remote equipment may require to remotely access a virtual private cloud file or a service such as a videoconference, a chat, a mailing.

[19] By authorizing an access for said remote equipment, it may be understood opening a data flux between the remote equipment and a server providing a service, resource, asset. The access may also be understood by an access to a secure service requiring a compliance to given security requirements. The authorization (or grant) of an access for said remote equipment may also be understood as resources allocated to the remote equipment. Authorizing an access for said remote equipment may imply that the remote equipment is authorized to send, receive, access, consult and/or join a secure service and/or data managed by a secure server.

[20] By a zero-knowledge proof protocol, it may be understood an algorithmic protocol used by both a prover (i.e., a remote equipment) and a verifier (i.e., a controlling device performing the proposed access control method) for assessing a compliance of the prover to requirements known the verifier without providing results, information, details, values about parameters enabling to assess such compliance. Such zero-knowledge proof protocol may be computed by a trusted device having computational capabilities for computing a zero-knowledge proof protocol. The zeroknowledge proof protocol may notably be a non-interactive zero-knowledge proof protocol, so that the proof computation and verification using the zero-knowledge proof protocol may be performed offline and without interactions (e.g., via several queries and answers) between the prover and the verifier. The zero-knowledge-proof protocol may rely on a secure infrastructure set by a trusting third party and used by both the prover and the verifier. Plus, the zero-knowledge proof protocol enables to guarantee a confidentiality and an accuracy of the proof information provided by the remote equipment for being granted an access by the verifying device. Such zero-knowledge proof protocol is notably computed independently from any blockchain securing, in contrary to most prior art security applications of zero-knowledge proof.

[21] By security parameters related to said remote equipment, it may be understood parameters of the remote equipment and expected by security requirements for assessing the security compliance of the remote equipment. For example, such security parameters may relate to hardware and/or software identifiers, capabilities, updates, features, versions, security means (e.g., firewalls, antivirus) of the remote equipment.

[22] By a zero-knowledge proof being signed by a trusted module of the remote equipment, it may be understood proof information computed and signed by the remote equipment based on a zeroknowledge proof protocol received by the remote equipment. Such zero-knowledge proof may notably be computed offline without interaction with the controlling device performing the access control method. In particular, the zero-knowledge proof may notably be signed using a cryptographic key associated to a trusted module of the remote equipment. In other words, the zero-knowledge proof comprises a signature proper to the trusted module of the remote equipment, so that the computation of the zero-knowledge proof is guaranteed to be sourced from the trusted module of the remote equipment. Such trusted module of the remote equipment may for example be understood as a hardware or software module of the remote equipment comprising a secure execution environment. The zero-knowledge proof may for example be signed using a private cryptographic key obtained or generated by the trusted module of the remote equipment. The zeroknowledge proof may also be signed using a cryptographic key associated to a digital certificate issued to the trusted module of the remote equipment.

[23] By assessing that the signed zero-knowledge proof is related to an authorized entity related to the trusted module of the remote equipment, it may be understood that the controlling device performing the proposed method checks that the signature of the zero-knowledge proof is valid. A signature of the zero-knowledge proof may be considered valid if it associated to a trusted module of the remote equipment which is known or recognized by the controlling device. For example, the controlling device may have stored signature information associated (e.g., via an IP address, a hardware identifier) to the trusted module. The signature of the zero-knowledge proof may also be considered valid if it is associated to a digital certificate or public key certificate issued by an entity trusted by the controlling device. Thus, by the signed zero-knowledge proof being related to an authorized entity related to the trusted module, it may be understood that the zero-knowledge proof includes a signature certified by an authorized entity to belong to the trusted module, such authorized entity being trusted by the controlling device. Such authorized entity may for example be a trusted device or a Certification Authority for example.

[24] By assessing that the signed zero-knowledge proof is computed according to the zeroknowledge proof protocol, it may be understood that the access control method includes checking that the zero-knowledge proof has accuracy. In the context of a non-interactive zero-knowledge proof, such assessment may comprise checking that a common reference string and/or a common secure infrastructure has been used by both the prover and the verifier of the zero-knowledge proof to check the accuracy of the zero-knowledge proof. Such common reference string and/or a common secure infrastructure may be computed by a trusted device distinct from both the prover and the verifier.

[25] By assessing that the signed zero-knowledge proof demonstrates that the security compliance of the remote equipment is valid, it may be understood that the access control method includes checking that the zero-knowledge proof actually proves that the remote equipment complies with security requirements. Such checking may also include checking a completeness and/or a soundness of the zero-knowledge proof. Such assessment that the signed zero-knowledge proof demonstrates that the security compliance of the remote equipment is valid may also be understood as a zero-knowledge compliance score being assessed, for example with respect to a predefined or preconfigured compliance threshold.

[26] According to a second aspect of the disclosure, it is proposed an access granting method performed by a trusted module of a remote equipment for being granted an access by proving a security compliance of the remote equipment to security requirements, the access granting method comprising steps of: obtaining data related to a zero-knowledge proof protocol, said zero-knowledge proof protocol depending on the security requirements, gathering, in the trusted module, data related to security parameters related to the remote equipment, determining, in the trusted module, a zero-knowledge proof based on said security parameters and on the zero-knowledge proof protocol, signing the zero-knowledge proof using a cryptographic key stored in the trusted module, transmitting the signed zero-knowledge proof to a controlling device, receiving, in response to the transmission of the signed zero-knowledge proof value, data related to an authorization of access for the remote equipment.

[27] As a consequence, the proposed access granting method enables a remote equipment to positively prove its security compliance to specific security requirements known by a verifying device corresponding to the controlling device. Providing that such compliance is validated by the controlling device, the remote equipment is able to access a secure service and/or secure information, data, assets, resources. The remote equipment is thus able to positively, in a whitelisting approach, prove that it meets the required conditions for being granted an access.

[28] Moreover, the proposed access granting method provides the remote equipment with means for computing a zero-knowledge proof, so that the remote equipment is able to prove its security compliance to the controlling device without revealing any information related to a level of security of the remote equipment. The confidentiality of the remote equipment’s information is thus guaranteed.

[29] Advantageously, the proving process of the remote equipment is computed and signed by a trusted module of the remote equipment. Thus, the proposed access granting method enables to guarantee the accuracy of the proof information transmitted by the remote equipment. In particular, the proposed method avoids, in case of compromise of the remote equipment for example, forged, altered or modified proof information, since the proving process is exclusively performed by and within the trusted module of the remote equipment. Indeed, by gathering data related to security parameters in the trusted module and determining the zero-knowledge proof in the trusted module, the proposed method guarantees that the computed proof information relies on legit information on the remote equipment.

[30] Plus, the signature of the zero-knowledge proof by using a cryptographic key stored in the trusted module enables to guarantee that the proof information is legit and originates from such trusted module.

[31] By an access granting method, it may be understood a method performed by a remote equipment for being granted an access by a verifying or controlling device. The access request may take the form of a proof information transmission by the remote equipment in order to prove a security compliance of the remote equipment.

[32] By obtaining data related to a zero-knowledge proof protocol, it may be understood that the trusted module of the remote equipment obtains data such as a reference string, parameters of a multivariate function, parameters of requirement constraints and/or algorithmic parameters based on which the trusted module is able to determine a zero-knowledge proof. Based on such data related to a zero-knowledge proof protocol, the trusted module is able to apply the zero-knowledge proof protocol to determine a zero-knowledge proof. Such data related to the zero-knowledge proof protocol may notably by obtained from an authorized (trusted) entity which has compiled such protocol beforehand.

[33] By gathering data related to security parameters related to the remote equipment, it may be understood that the trusted module initiates a set of function calls in order to obtain parameter values related to the functioning, the hardware and/or the software structure of the remote equipment. The trusted module may also gather information related to a security state of the remote equipment. The gathered security parameter values may correspond to booleans, identifiers, numbers, character strings etc.

[34] By signing the zero-knowledge proof using a cryptographic key stored in the trusted module, it may be understood that the trusted device guarantees the accuracy of the zero-knowledge proof by joining a signature to the proof information. The trusted module indeed has a secure cryptographic key associated to the trusted module and which accuracy is thus guaranteed. The cryptographic key may for example be generated by the trusted module and/or certified by an authorized entity such as an entity trusted by both the remote equipment and the device verifying the proof information.

[35] By receiving data related to an authorization of access for the remote equipment, it may be understood that the remote equipment obtains an opened flux to secure service, resources, data and/or assets provided authorized by the controlling device, so that the remote equipment is able to access, receive and/or transmit information to or via such secure service, resources, data and/or assets. Such data related to the authorization of access may be an explicit confirmation message sent by the controlling device and/or an implicit authorization of access, for example by providing access to the requested resources or service. By receiving data related to an authorization of access for the remote equipment, it may also be understood that the remote equipment receives a message denying the access, for example when the zero-knowledge proof is assessed to be invalid. By receiving data related to an authorization of access for the remote equipment, it may also be understood that the remote equipment receive time-related information or a timer information, which may indicate a time expiration. Such time expiration may indicate an implicit grant or denying of access for the remote equipment.

[36] By receiving data related to an authorization of access in response to the transmission of the zero-knowledge proof value, it may be understood that no access is granted (or authorized) for the remote equipment before the transmission of the signed zero-knowledge proof. A time gap may occur between such transmission and the reception of data related to an authorization of access. Thus, the proof computation may be performed offline and without interaction with the controlling device, so that the reception of data related to an authorization of access may be delayed.

[37] Moreover, the following embodiments may be optionally performed:

[38] In an embodiment of the first aspect of the disclosure, the authorized entity is related to an element among:

- a trusted device certifying the trusted module of the remote equipment,

- a Certification Authority certifying the trusted module of the remote equipment.

[39] As a consequence, the signature of the zero-knowledge proof may be assessed by the proof verifier, since such zero-knowledge proof contains a signature which may be associated to a trusted entity from the verifying (or controlling) device’s perspective. The controlling device may for example have performed an enrollment procedure to such authorized entity and/or may has acknowledge such authorized entity as a trusted entity.

[40] In an embodiment of the first aspect of the disclosure, it is assessed that the signed zeroknowledge proof is related to the authorized entity by using a first cryptographic key associated with the trusted module of the remote equipment, said first cryptographic key being certified by the authorized entity.

[41] As a consequence, the access control method advantageously relies on a secure key infrastructure (e.g., a Public Key Infrastructure or PKI) set and managed by a trusted entity (i.e., the authorized entity) in order to assess the accuracy of the zero-knowledge proof and that such zeroknowledge proof has indeed been computed and transmitted by an expected or certified trusted emitter. The proposed method is thus based on a trusted third-party distinct from both the prover and the verifier.

[42] By assessing that the signed zero-knowledge proof is related to the authorized entity by using a first cryptographic key, it may be understood that the controlling device performing the access control method verifies the signature of the zero-knowledge proof using a known (first) cryptographic key possessed by the controlling device. In particular, such first cryptographic key may be certified by the authorized entity. Such first cryptographic key may for example be a public cryptographic key generated and transmitted by the trusted module of the remote equipment, such public cryptographic key being certified beforehand by the authorized entity. Such used first cryptographic key may also be associated to a digital certificate issued by the authorized entity.

[43] In an embodiment of the first aspect of the disclosure, it is assessed that the signed zeroknowledge proof has been computed according to the zero-knowledge proof protocol using a second cryptographic key associated with the authorized entity.

[44] As a consequence, the proposed access control method relies on information issued by a commonly-trusted entity (i.e., the authorized entity) for both the prover (which generates the zeroknowledge proof) and the verifier (which assesses such proof). Thus, by relying on a second cryptographic key associated with the authorized entity, the proposed access control method guarantees that a zero-knowledge proof protocol compiled by such authorized entity and a zeroknowledge proof obtained by applying such zero-knowledge proof protocol match. The zeroknowledge proof thus has completeness and is valid. Such second cryptographic key may for example be a public cryptographic key generated by the authorized entity and transmitted to both the prover and the verifier for applying the zero-knowledge proof protocol.

[45] In an embodiment of the first aspect of the disclosure, it is assessed that the signed zeroknowledge proof demonstrates that the security compliance of the remote equipment is valid by at least comparing a value of the zero-knowledge proof with a predefined accuracy value.

[46] As a consequence, the proposed access control method enables to check that the zeroknowledge proof effectively proves a security compliance of the remote equipment.

[47] By a predefined accuracy value, it may be understood any preset, stored, predefined value to be expected by the verifying device to assess that the zero-knowledge proof is valid.

[48] In an embodiment of the first aspect of the disclosure, the access control method comprises, before receiving the zero-knowledge proof protocol,: enrolling to the authorized entity, obtaining a second cryptographic key associated with the authorized entity.

[49] As a consequence, the proposed access control method relies on an initialization of a secure infrastructure (e.g., a Public Key Infrastructure or PKI) managed by a trusted third-party to which the controlling device performing the access control method has enrolled before assessing the zero-knowledge proof. By enrolling to such authorized entity, the controlling device thus considers information certified by (or comprising a signature of) such authorized entity to be accurate and valid. Indeed, during (or following) the enrollment to such authorized entity, the controlling device obtains a second cryptographic key associated to the authorized entity, which may relate to a public cryptographic key and/or a digital certificate which can be stored and further used and/or recognized by the controlling device.

[50] In an embodiment of the first aspect of the disclosure, the access control method further comprises: receiving a user authentication value, the access for said remote equipment being furthermore authorized if it is further assessed that the user authentication value matches data of a stored user authentication database.

[51] As a consequence, the proposed access control method enables the controlling device to check that the physical user of the remote equipment is a genuine (or expected) user before providing access to the remote equipment. Indeed, assessing the security compliance of the remote equipment may also include assessing that the remote equipment is used by an authenticated user or by a user having the credentials for being authorized an access. For example, a company’s controlling device may assess that, not only does the remote equipment comply to security requirements of the company, but also that the user of the remote equipment genuinely is an employee of the company before authorizing an access to secure resources and assets of the company.

[52] By a user authentication value, it may be understood as multi-factor authentication values involving knowledge (what the user knows), possession (what the user has) and/or self-being (who the user is) authentication for example. Thus, the authentication value may relate to a password provided by the user of the remote equipment. The authentication value may also relate to a key or a security token possessed by the user of the remote equipment. The authentication value may also relate to biometric data provided by the user of the remote equipment.

[53] By data of a stored user authentication database, it may be understood authentication data pre-stored by a server linked to or included in the controlling device. Such data may notably be compared to the user authentication value inputted by the user of the remote equipment as a match-list.

[54] In an embodiment of the first aspect of the disclosure, the zero-knowledge proof protocol relates to the Zero-Knowledge Succinct Non-Interactive Argument of Knowledge - ZK-SNARK - proof protocol.

[55] In an embodiment of the second aspect of the disclosure, the access granting method is computed in a secure execution environment of the remote equipment. [56] As a consequence, the proposed access granting method relies on an isolated execution environment. In the context of the present disclosure, information computed by and within such secure execution environment is assumed to be accurate.

[57] In an embodiment of the second aspect of the disclosure, the secure execution environment of the remote equipment relates to an element among:

- a Trusted Execution Environment - TEE - of the remote equipment, and

- a hardware Trusted Platform Module - TPM - of the remote equipment.

[58] As a consequence, the secure execution environment may be physically isolated from the rest of the hardware modules of the remote equipment, for example as a distinct chip of the remote equipment. Such distinct chip may notably correspond to a Trusted Platform Module, or TPM. Such TPM may commonly be found on electronic devices using the Windows 11 system for example. In the absence of such hardware TPM, an isolated execution environment software may also be used. The trusted module of the remote equipment may thus be understood as such (hardware preferably, or software) secure execution environment.

[59] In an embodiment of the second aspect of the disclosure, the security parameters are related to an element or a combination of elements among at least:

- a serial number of a hardware component of the remote equipment,

- a version of the operating system of the remote equipment,

- an update level of the operating system of the remote equipment,

- an antivirus software of the remote equipment,

- an update level of the antivirus software of the remote equipment,

- a firewall of the remote equipment,

- a configuration of the firewall of the remote equipment,

- hardware drivers of the remote equipment, and

- Endorsement Key - EK - of a Trusted Platform Module - TPM - of the remote equipment.

[60] As a consequence, the security parameters gathered in the context of the proposed access granting method provide information related to the remote equipment and more particularly, to features, security parameters (e.g., firewall, antivirus) of the remote equipment. The use of such information for computing a zero-knowledge proof enables to provide a positive, exhaustive information about the security compliance of the remote equipment to preset security requirements. Indeed, a remote equipment having satisfying security parameters (that is, which match the security requirements) is guaranteed to match the criteria of the controlling device for being granted an access.

[61] In an embodiment of the second aspect of the disclosure, the cryptographic key relates to at least: - a digital certificate issued by an authorized entity and certifying the trusted module of the remote equipment, and/or

- a private cryptographic key generated by the trusted module of the remote equipment.

[62] As a consequence, the proposed method relies on a secure key infrastructure for guaranteeing the accuracy of the proof information provided by the remote equipment. The cryptographic key used to sign the zero-knowledge proof may thus be associated to the trusted module, for example via a private cryptographic key generated by the trusted module. In such case, a corresponding public cryptographic key may be known by the other devices for verifying signed information using such private cryptographic key. Moreover, a digital certificate associated to the trusted module may be used when signing the zero-knowledge proof, so that the latter is acknowledged to be accurate since the digital certificate is issued by an authorized entity for the controlling device and is thus recognized by the controlling device.

[63] In an embodiment of the second aspect of the disclosure, the access granting method comprises, before obtaining data related to a zero-knowledge proof protocol,: enrolling to an authorized entity, obtaining a digital certificate issued by said authorized entity and certifying the trusted module of the remote equipment.

[64] As a consequence, the proposed access granting method relies on a secure infrastructure (e.g., a Public Key Infrastructure) initialized and certified by a trusted device (or authorized entity) managed by a trusted third-party to which the remote equipment enrolls to before computing the zero-knowledge proof. Such authorized entity may notably issue a digital certificate to the trusted module of the remote equipment. For example, the authorized entity may certify a public cryptographic key generated and/or stored by the trusted module. Thus, further information signed by the remote equipment (e.g., the zero-knowledge proof) using a cryptographic key certified by a digital certificate issued by the authorized entity is guaranteed to be accurate.

[65] In an embodiment of the second aspect of the disclosure, the zero-knowledge proof protocol relates to the Zero-Knowledge Succinct Non-Interactive Argument of Knowledge - ZK-SNARK - proof protocol.

[66] As a consequence, the proposed method may be computed based on the computational capabilities of the ZK-SNARK. Moreover, the ZK-SNARK protocol is not patented.

[67] In an embodiment of the second aspect of the disclosure, the access granting method comprises, before receiving data related to the authorization of access: providing a user authentication value to the controlling device via a human-machine interface of the remote equipment.

[68] As a consequence, the proposed access granting method advantageously enables to assess that the physical user using the remote equipment is a genuine, registered or expected user of the remote equipment. Thus, the access granting method enables both the remote equipment to prove its security compliance to security requirements and its user to authenticate him/herself.

[69] According to another aspect of the disclosure, it is proposed a controlling device comprising at least a processing circuit for performing the access control method.

[70] According to another aspect of the disclosure, it is proposed a computer program product comprising program instruction code stored on a computer-readable medium for the execution of the access control method. According to another aspect of the disclosure, it is proposed a computer-readable medium storing program instruction code for the execution of the access control method.

[71] According to another aspect of the disclosure, it is proposed a remote equipment comprising at least a processing circuit for performing the access granting method.

[72] According to another aspect of the disclosure, it is proposed a computer program product comprising program instruction code stored on a computer-readable medium for the execution of the access granting method. According to another aspect of the disclosure, it is proposed a computer-readable medium storing program instruction code for the execution of the access granting method.

[73] In an embodiment of such aspect of the disclosure, the program instruction code only relies of native-defined functions.

[74] As a consequence, the proposed access granting method enables to avoid forged, altered or modified proof information, as the whole access granting method and the proof computation process are exclusively performed within the trusted module and using the native code of the trusted module. Thus, the proposed access granting method avoids risks of malicious use of hooking and/or other types of information compromise which may alter the accuracy of the proof information.

Brief description of drawings

[75] Other features, details and advantages will be shown in the following detailed description and on the figures, on which:

Fig. 1

[76] [Fig. 1] shows a schematic framework of an access control protocol in prior art.

Fig. 2

[77] [Fig. 2] shows a schematic framework of an access control protocol according to a possible embodiment of the disclosure.

Fig. 3

[78] [Fig. 3] shows a schematic architecture of a controlling device according to a possible embodiment of the disclosure. Fig. 4

[79] [Fig. 4] shows a schematic architecture of a remote equipment according to a possible embodiment of the disclosure.

Fig. 5

[80] [Fig. 5] shows steps of an access control method performed by a controlling device according to a possible embodiment of the disclosure.

Fig. 6

[81] [Fig. 6] shows steps of an access granting method performed by a remote equipment according to a possible embodiment of the disclosure.

Fig. 7

[82] [Fig. 7] shows steps of an enrollment method performed by a trusted device according to a possible embodiment of the disclosure.

Detailed description of embodiments

[83] It is now referred to figure 1. Figure 1 shows a schematic framework of an access control protocol according to prior art. In such context of an access control protocol, a remote equipment EQ, also referred to as the proving equipment, requires an access to a secure service SS. Such secure service SS may for example be provided by a computer information system (or IS) served by a telecommunications network including a computer network. Such network may for example correspond to a private network of a company C. The remote equipment EQ may be used by an individual, that is a physical user P, for example an employee of the company C. The secure service SS may notably include resources, data or assets provided by the company C. In particular, the access to such company secure service SS requires a predefined level of privilege granted to the equipment accessing such secure service SS. For example, the access to the secure service SS may require a user access or a higher level of privilege than a user access, such as an administrator access. In particular, the access to a secure service SS may require the remote equipment EQ to pass an access control protocol. Such access control protocol generally refers to the remote equipment EQ providing proof information to a server of the company IS - referred to as the routing device RD, which may be for example a router or a firewall - that the remote equipment EQ has a trusted level of security for accessing to the secure service SS. In case of a validated proof information, the routing device RD authorizes and routes an access to the secure service SS for the remote equipment EQ. Such routing device RD may be a trusted server of the company C. In particular, such routing device RD may act as a firewall of the company computer network, so that the no access to the secure service SS is possible without access grant by the routing device RD. Existing access control protocols may also include an authentication of the user P of the remote equipment EQ. In particular, existing access control protocols may also rely on a blacklisting access control. [84] A blacklisting access control protocol is a threat-centric protocol: blacklisting aims at detecting and/or identifying suspicious or malicious software activities. Thus, if a blacklisted element is identified on the remote equipment EQ, such remote equipment EQ is denied access to the secure service SS by the routing device RD. On the contrary, if no suspicious or malicious behavior has been detected, the remote equipment EQ is granted access to the secure service SS by the routing device RD. To that end, existing blacklisting access control protocols may rely on seeking a body of indicators pointing to traces of malicious activities running on the remote equipment EQ. For example, antivirus dynamic or static malware checking and Indicators of Compromise (loC) checking may be performed on the remote equipment EQ in the context of a blacklisting access control protocol. The detection of viral signatures in files of the remote equipment EQ, heuristic analysis of the remote equipment EQ software and/or blacklisted IP address detection may also be performed on the remote equipment EQ in the context of the blacklisting access control protocol. Referring to figure 1 , the remote equipment EQ provides the routing device RD with proof information of the remote equipment EQ. Such proof information may notably reflect a level of risk of the remote equipment EQ. The routing device RD may then assess the proof information received from the remote equipment EQ. If no blacklisted element has been detected, or equivalently, if the proof information reflects a level of risk below a predefined threshold value for example, the remote equipment EQ is considered as a trusted equipment and granted an access to the secure service SS. Secure resources related to such secure service SS may then be transmitted to the remote equipment EQ via the routing device RD.

[85] In such blacklisting access control protocol, the access to the secure service SS is granted by default, that is on the basis of an absence of indication of compromise of the remote equipment EQ. Yet, blacklisting does not enable the company C system information to check, in a positive way, that specific security criteria based on which an access to the secure service SS should be granted have been met by the remote equipment EQ. Indeed, the company C may have specific security requirements for devices being authorized an access to the secure service SS. The company C thus requires to be able to positively assess the security level of a remote equipment EQ according to such positive security criteria before access granting.

[86] Plus, the proof information provided by the remote equipment EQ potentially contains sensitive information, since it reflects a level of risk of the remote equipment EQ. Such blacklisting access control protocol thus raises major confidentiality issues, as data interception on the channel between the remote equipment EQ and the routing device RD or a compromise of the server of the routing device RD may leak critical information about the vulnerability state of the remote equipment EQ.

[87] Moreover, in the context of such blacklisting access control protocol, the network provides no efficient means to assess the integrity of the proof information provided by the remote equipment EQ. Indeed, in case of a compromised remote equipment EQ, the proof information provided by such remote equipment EQ may be altered, for example by forging fake values of Indicators of Compromise (or loC) or a fake output proof information to be systematically sent to the routing device RD, regardless of the genuine level of vulnerability of the remote equipment EQ. Thus, such existing access control protocol still requires, at some extent of digital interactions between the network and the remote equipment EQ, an implicit trust in the remote equipment EQ. The company has thus no means to guarantee that either the received proof information genuinely originates from the remote equipment EQ, nor that the result (or value) of such proof information has not been forged or altered at the stage of its reception by the routing device RD.

[88] It is now referred to figure 2. Figure 2 shows a schematic framework of an access control protocol according to an embodiment of the proposed disclosure. In particular, such schematic framework of figure 2 addresses the limits of existing access control protocols as aforementioned.

[89] The schematic framework of the present disclosure comprises a remote equipment EQ, a company C infrastructure comprising at least a controlling device CD, a third-party T infrastructure comprising at least a trusted device TD and a resource server, for example belonging to the company C infrastructure, providing a secure service SS.

[90] The remote equipment EQ requires an access to the secure service SS provided by the company C. To that end, the present disclosure proposes an access control protocol involving on the company’s perspective, an access control process (or method) performed by the controlling device CD and, on the remote equipment EQ’s perspective, an access request process (or method) performed by a trusted module of the remote equipment EQ. In other words, the controlling device CD will check, via the access control process, that the remote equipment EQ is conform to the security requirements expected by the controlling device CD. Such access control and access request protocols may notably be performed by enrolling to a trusted device TD, which is a server trusted by the controlling device CD (and by the trusted module of the remote equipment EQ) and having the computing resources for compiling the algorithmic protocol for the proposed access control and request protocols.

[91] The trusted device TD may be a third-party server system managed by a trusted third party T distinct from the user entity P using the remote equipment EQ and from the company C entity managing the controlling device CD. The trusted device TD may interact with the controlling device CD and the remote equipment EQ as a digital trust service provided by the third party T to which the company C has previously subscribed for performing access controls on remote equipment EQ. Such subscription may include an enrollment of the controlling device CD to the trusted device TD. Such enrollment may notably include an exchange of cryptographic keys and/or digital certificates respectively associated to each of the trusted device TD and the controlling device CD. Similarly, an initial enrollment may occur between the remote equipment EQ and the trusted device TD and include an exchange of cryptographic keys and/or an issuance of digital certificates respectively associated to each of the trusted device TD and the remote equipment EQ. In particular, the trusted device TD may be a trusted third-party managing a Public Key Infrastructure (or PKI) used by both the remote equipment EQ and the controlling device CD when performing the access control and access request protocols. [92] A detailed schematic architecture of a controlling device CD, to be understood as a verifying device, is represented on figure 3. As shown on figure 3, the controlling device CD comprises at least a communication interface COM, a storage memory unit MEM, a processing unit PROC and a compiling unit COMPL. Such controlling device CD may for example be a router or a firewall device of the company C.

[93] The communication interface COM is configured to exchange information notably with other servers devices within the company C information system, with remote devices such as the remote equipment EQ and with authorized entities such as the trusted device TD. The controlling device CD may communicate with other server systems using a secure private network of the company C for example. In order to communicate with a remote device such as the remote equipment EQ, an enrollment of such remote device to the secure private network of the company C may have previously occurred.

[94] The storage memory unit MEM of the controlling device CD is able to store information received from the trusted device TD and from the remote equipment EQ via the communication interface COM. The storage memory unit MEM of the controlling device CD is also able to store information processed by the processing unit PROC of the controlling device CD. The storage memory unit MEM of the controlling device CD may also store preconfigured or preset information, such as security requirements expected from the company C policy or contractual constraints. To such ends, the storage memory unit MEM of the controlling device CD may comprise a volatile storage memory (e.g., a Random Access Memory or RAM) and a non-volatile storage memory (e.g., a Read Only Memory or ROM). In particular, the non-volatile storage memory may store digital certificates and/or cryptographic keys associated with the trusted device TD, with the remote equipment EQ, with the controlling device CD itself, and/or any other devices enrolled in the company secure network and/or to which the controlling device CD has enrolled for example.

[95] The processing unit PROC of the controlling device CD is configured to execute one or several sets of source code instructions. Such instructions may be executed to perform steps of an access control method, which will be further described in figure 5. In an embodiment of the disclosure, the processing unit PROC of the controlling device CD may notably comprise a key check unit KY CHK, a protocol check unit PTC CHK and a proof check unit PF CHK. The key check unit KY CHK of the controlling device CD is configured to unseal (that is, verify a signature of) signed information received by the controlling device CD, such information being for example signed (or sealed) by the emitter of such signed information using a (private) cryptographic key ky, ks of the emitter. The protocol check unit PTC CHK of the controlling device CD is configured to check an integrity between a proof protocol and a proof information, that is, to verify if such proof protocol has been genuinely followed so as to obtain the proof information. The proof check unit PF CHK of the controlling device CD is configured to perform an accuracy check of the proof information received by the controlling device CD. Such proof accuracy may for example include a comparison of such proof information with stored information of the controlling device CD in the storage memory unit MEM, or a verification that the proof information matches expected stored accuracy information. Optionally, the processing unit PROC of the controlling device CD may also include an authentication check unit (not represented on figure 3), configured to check authentication credentials of a user P of the remote equipment EQ.

[96] Referring to figure 2, such controlling device CD is configured to communicate with the trusted device TD. Such trusted device TD may notably include a key generation unit, a protocol generation unit and a compiling unit (not represented on figure 2). The key generation unit of the trusted device TD is configured to generate a cryptographic element, such as a pair of cryptographic keys ky, KT and/or a digital certificate, associated with the trusted device TD. Such cryptographic element ky, KT may be generated and used by the key generation unit of the trusted device TD to sign information emitted by the trusted device TD and or sign digital certificates issued via the trusted device TD to another device (e.g., the remote equipment EQ). The protocol generation unit is configured to generate and deploy a proof algorithmic protocol based on input criteria obtained by the trusted device TD. Such input criteria may for example include security requirements of the company C provided to the trusted device TD by the controlling device CD. The protocol generation unit may notably be configured to generate and deploy a Zero-Knowledge Proof (or ZKP) algorithmic protocol. The generation of such ZKP protocol will be further described in the present disclosure. The compiling unit of the trusted device TD is configured to compile or translate the source code used by the protocol generation unit into an object code, a machine code, bytecode or a high-level programming code language. The output code of the compiling unit may then be transmitted, via a communication unit of the trusted device TD, to the remote equipment EQ, the controlling device CD or any other device enrolled in the trusted device TD for execution. The trusted device TD may also set a Public Key Infrastructure (or PKI) using its own cryptographic element ky, KT, and enroll remote devices (such as the remote equipment EQ) and company servers (such as the controlling device CD) so as to act as a trusted third-party T (similarly to a Certification Authority) to both the user P and the company C entities.

[97] Referring to figure 2, the schematic framework for performing an access control to the secure service SS managed by the controlling device CD also involves a remote equipment EQ. The remote equipment EQ, to be understood as a proving equipment, is a computer entity having digital interactions with a trusted computer device of the company C information system, such as a router, a firewall or the controlling device CD. The remote equipment EQ may notably be outside of the network perimeter of the company secure network. The remote equipment EQ may correspond to company device such as a company laptop, tablet, cell phone or any other digital device. In such case, the remote equipment EQ may have an IP address known by the controlling device CD. The remote equipment EQ may also correspond to a personal digital device belonging to an individual P, such as a personal mobile phone or a personal laptop, notably in the context of a BYOD policy. Considering a genuine utilization of the remote equipment EQ, the individual P may for example be an employee of the company C or an individual who is a genuine recipient of the secure service SS. The remote equipment EQ may be connected to the company secure network (for example, after enrolling in the secure network). In the context of the present disclosure, the remote equipment EQ requires an access to the secure service SS. Such secure service SS may comprise resources and assets provided by the company C. Such secure service SS may for example be internal resources provided to employees of the company C, such as a shared storage cloud or file server for example. Such secure service SS may also be a videoconference or chat session that the individual P requests to join using the remote equipment EQ.

[98] A simplified schematic architecture of a remote equipment EQ according to a possible embodiment of the disclosure is represented on figure 4. Such remote equipment EQ comprises a plurality of hardware modules HW-M and software modules SW-M. Hardware modules HW-M may notably comprise various chips and a human-machine interface. Software modules SW-M may notably include executable software applications. In particular, the remote equipment EQ comprises a trusted module. Such trusted module may refer to a hardware trusted module offering a secure execution environment for the remote equipment EQ. Such hardware trusted module may for example correspond to a Trusted Platform Module, or TPM. In the case of a hardware trusted module, the secure execution environment of the remote equipment EQ is physically isolated from the main execution environment, for example on a different chip component of the remote equipment EQ. Such TPM includes a processing unit PROC-T, a storage memory unit MEM-T and a communication interface INT-T which are physically-isolated from other processing circuits in the hardware modules HW-M of the remote equipment EQ. The trusted module may also refer to a software trusted module providing a secure execution environment for the remote equipment EQ. Such software trusted module may for example correspond to a Trusted Execution Environment, or TEE. As a difference with the TPM, the TEE is not a physically-isolated execution environment but refers to a virtually-secure area of the main processing circuit and thus includes a virtually-isolated execution environment of the remote equipment EQ. The TEE include trusted applications T-APP and a trusted operating system T-OS which are virtually-isolated from the main applications APP and operating system OS-M.

[99] The trusted module of the remote equipment EQ enables the remote equipment EQ to present integrated cryptographic keys and to execute instructions in a secure execution environment. Such cryptographic keys may be generated by the trusted module of the remote equipment EQ. For example, such generated cryptographic key may be a private cryptographic key ks associated to the TPM of the remote equipment EQ. The cryptographic key may also relate to a digital certificate associated to the trusted module of the remote equipment EQ, such certificate being issued by an authorized entity such as a Certification Authority. In an embodiment of the present disclosure, the cryptographic key associated to the trusted module of the remote equipment EQ may be certified by the trusted device TD during an initial enrollment of the trusted module of the remote equipment EQ to the trusted device TD. During such enrollment, the trusted device TD may issue a digital certificate associated to the private cryptographic key ks generated by the trusted module of the remote equipment EQ, such digital certificate being signed by the trusted device using its own cryptographic element k , KT. [100] It is now referred to figure 5. Figure 5 shows steps of an access control method performed by a controlling device CD. Such access control method is notably performed in the context of figure 2 for authorizing an access to a secure service SS for a remote equipment EQ.

[101] At an initial step 50, the controlling device CD may perform an initial enrollment to a trusted device TD managed by a trusted third-party T. During such enrollment, the controlling device CD may be part of a Public Key Infrastructure (or PKI) set by the trusted device TD. During step 50, the controlling device CD may obtain data related to a cryptographic element including a protocol public key KT, associated with the trusted device TD. Such enrollment step to the trusted device TD enables the controlling device CD to perform the access control method using the PKI set by the trusted third-party T, which acts as an authorized entity for the controlling device CD. During step 50, the controlling device CD may also receive other cryptographic elements associated to remote devices, such as an equipment public key KE associated with the trusted module of the remote equipment EQ. Such cryptographic elements associated with remote devices may notably be certified by the trusted device TD via digital certificates issued to such remote devices.

[102] At a step 51 , the controlling device CD obtains a zero-knowledge proof protocol. Such zeroknowledge proof protocol may be received by the controlling device CD from the trusted device TD to which the controlling device has previously enrolled, such trusted device TD having compiled such zero-knowledge proof protocol beforehand. In particular, such zero-knowledge proof protocol depends on specific security requirements. Such security requirements may relate to criteria expected by the controlling device CD for authorizing an access to the secure service SS. In other words, such security requirements relate to a level of security required for a remote equipment EQ to be granted an access to the secure service SS. For example, the security requirements may concern the update version of the operating system or of the antivirus of the remote device requiring the access. Such security requirements may for example have been transmitted by the controlling device CD to the trusted device TD after the enrollment of the controlling device CD at step 50. In an embodiment of the present disclosure, the received zero-knowledge proof protocol is signed by the trusted device TD using a protocol private key k? associated to the trusted device TD.

[103] At a step 52, the controlling device CD receives a zero-knowledge proof from the remote equipment (EQ). Such zero-knowledge proof is signed using a cryptographic key. In particular, such cryptographic key relates to a trusted module of the remote equipment EQ, for example the TPM or the TEE. Such cryptographic key used to sign the zero-knowledge proof may for example correspond to an equipment private key ks generated by the trusted module of the remote equipment EQ. Such cryptographic key used to sign the zero-knowledge proof may also relate to a digital certificate associated with the trusted module of the remote equipment EQ. Such digital certificate may in particular be issued by a Certifying Authority or by the trusted device TD. In other words, the zero-knowledge proof may be signed using the PKI set by the trusted device TD.

[104] After receiving the zero-knowledge proof at step 52, the controlling device CD proceeds to a security check of the remote equipment EQ based on such zero-knowledge proof. Such security check consists in several distinct checking steps: a signature check at a step 53, a protocol check at a step 54, a proof check at step 55 and optionally, an authentication check at step 57.

[105] At step 53, the controlling device CD performs a signature check, which aims at assessing the integrity of the device sending the zero-knowledge proof. In other words, step 53 aims at checking that the emitter of the zero-knowledge proof genuinely is the trusted module of the remote equipment EQ. To that end, the controlling device CD may use an equipment public key KE associated with the trusted module of the remote equipment EQ, notably if the zero-knowledge proof has been signed by the trusted module using its equipment private key ks. In an embodiment, the signature check at step 53 may involve checking the digital certificate used to sign the zeroknowledge proof. The signature is assessed to be valid if the controlling device CD manages to unseal the signed zero-knowledge proof using the equipment public key KE: in other words, the controlling device CD may validate the signature check step by assessing that a successful unsealing of the zero-knowledge proof using the equipment public key KE guarantees that the trusted module of the remote equipment EQ is the genuine emitter of the received signed zeroknowledge proof. In an embodiment, the signature is assessed to be valid if the controlling device CD acknowledges the certificate as being emitted by a recognized authorized entity: in other words, a valid and authentic certificate issued used to sign the zero-knowledge proof guarantees that the trusted module of the remote equipment EQ is the genuine emitter of the received signed zero-knowledge proof.

[106] If at step 53, the signature of the zero-knowledge proof is not recognized by the controlling device CD and/or not related to a digital certificate issued by an authorized entity known by the controlling device CD, the signed zero-knowledge proof is considered invalid due to a prover integrity failure. In such case, the access to the secure service SS is denied at a step 56.

[107] If, at step 53, the signature of the zero-knowledge proof is assessed to be valid, the controlling device CD proceeds to a step 54. At step 54, the controlling device CD performs a protocol check, which aims at assessing the integrity of the zero-knowledge proof. In other words, step 54 aims at checking that the received zero-knowledge proof has genuinely been computed or calculated using the zero-knowledge proof protocol compiled by the trusted device TD. To that end, the controlling device CD may check that the signed zero-knowledge proof protocol and that the signed zero-knowledge proof have both been computed based on the PKI set by the trusted device TD. In other words, at step 54, the controlling device CD may check that the cryptographic element KT, ky generated by the trusted device TD has been used to generate the received zero-knowledge proof. Such protocol check step thus aims to check the soundness of the zero-knowledge proof.

[108] If, at step 54, the controlling device CD assesses that the zero-knowledge proof does not match the zero-knowledge proof protocol received by the controlling device CD, the signed zeroknowledge proof is considered invalid due to a proof integrity failure. In such case, the access to the secure service SS is denied at a step 56.

[109] If, at step 54, the controlling device CD assesses that the zero-knowledge proof matches the zero-knowledge proof protocol, the controlling device CD proceeds to step 55. At step 55, the controlling device CD performs a proof check, which aims at assessing the accuracy of the zeroknowledge proof with the security requirements. In other words, step 55 aims at checking that the result of the received zero-knowledge proof reflects a sufficiently satisfying level of security of the remote equipment EQ for accessing the secure service SS. To that end, the controlling device CD may compare a value (or result) of the zero-knowledge proof with a predefined accuracy value. In such context, the zero-knowledge proof may for example be a compliance score to be assessed by the controlling device CD.

[110] If, at step 55, the zero-knowledge proof is not conform with the predefined accuracy value stored by the controlling device CD, the signed zero-knowledge proof is considered invalid due to a proof accuracy failure. In such case, the access to the secure service SS is denied at a step 56.

[111] If, at step 55, the zero-knowledge proof is conform with the predefined accuracy value stored by the controlling device CD, the controlling device CD may determine that the remote equipment EQ satisfies the security requirements for accessing the secure service SS. Thus, the controlling device CD may authorize, or grant, an access for the remote equipment EQ at a step 58.

[112] Optionally, after step 55, if the zero-knowledge proof is conform with the predefined accuracy value stored by the controlling device CD, the controlling device CD further proceeds with an authentication check at step 57, which aims at assessing the identity of the user of the device sending the zero-knowledge proof. In other words, step 57 aims at checking that the individual P using the (genuine, as assessed in step 53) remote equipment EQ is himself a genuine user. To that end, the controlling device CD may require an authentication value from the user of the remote equipment EQ, for example by proceeding to a multi-factor authentication. Such authentication check may be based on one or several authentication values presented by the individual P on a human-machine interface of the remote equipment EQ. Such authentication values may for example include knowledge factors (such as a password), possession factors (such as a specific hardware component to be linked to a port of the remote equipment EQ) and/or biometric factors (such as voice recognition, fingerprints, palmprints, iris scanning, face scanning...). Such authentication values are then compared by the controlling device CD with authentication data stored by the controlling device CD, for example in an employee or staff whitelist authentication database.

[113] If, at step 57, the authentication values are not identified in the authentication database of the controlling device CD, the signed zero-knowledge proof is considered invalid due to an authentication failure. In other words, it is considered that the individual P using the remote equipment EQ does not have the credentials to access the secure service SS, notably because such individual P is not identified as a known individual by the controlling device CD. In such case, the access to the secure service SS is denied at a step 56.

[114] If, at step 57, the authentication values are identified in the authentication database of the controlling device CD, the controlling device CD may determine that the remote equipment EQ is used by a genuine user P and satisfies the security requirements for accessing the secure service SS. Thus, the controlling device CD may authorize, or grant, an access for the remote equipment EQ at a step 58.

[115] It is now referred to figure 6. Figure 6 shows steps of an access granting method performed by a trusted module of the remote equipment EQ. Such access granting method is notably performed in the context of figure 2 for a remote equipment EQ to be granted authorizing of access to a secure service SS.

[116] At an initial step 60, the remote equipment EQ may perform an initial enrollment to a trusted device TD managed by a trusted third-party T. During such enrollment, the remote equipment EQ may be part of a Public Key Infrastructure (or PKI) set by the trusted device TD. During step 60, the remote equipment EQ may obtain data related to a cryptographic element including a protocol public key KT, associated with the trusted device TD. Such enrollment step to the trusted device TD enables the remote equipment EQ to perform the access granting method using the PKI set by the trusted third-party T, which acts as an authorized and identified entity for the remote equipment EQ. During such enrollment step at step 60, the trusted module of the remote equipment EQ may have a cryptographic key associated to the trusted module of the remote equipment EQ certified by the trusted device TD. To that end, the trusted module of the remote equipment EQ may obtain, during step 60, a digital certificate associated to the trusted module issued by an authorized entity such as the trusted device TD. In particular, such digital certificate may be associated to the cryptographic key associated to the trusted module of the remote equipment EQ. The digital certificate associated to the trusted module of the remote equipment EQ obtained by the latter at step 60 is notably signed by the trusted device TD using its own cryptographic element KT, kr

[117] Such enrollment to the trusted device TD by the remote equipment EQ may for example take the form of a downloading and/or the execution of a trusted application T-APP on the remote equipment EQ, such trusted application being run by the trusted third party T. At step 60, the trusted module of the remote equipment EQ may then have access to a cryptographic key stored in the storage memory MEM-T of the trusted module. Such cryptographic key may correspond to an equipment private key generated by the trusted module of the remote equipment EQ. Such cryptographic key may also be related to a digital certificate issued by a Certifying Authority to the trusted module of the remote equipment EQ.

[118] At a step 61 , the remote equipment EQ receives data related to a zero-knowledge proof protocol. Such data related to the zero-knowledge proof protocol may for example relate to executable instructions for calculating a multivariate function requiring a plurality of input parameters so as to obtain an output zero-knowledge proof. Based on such received data related to the zero-knowledge proof protocol, the remote equipment EQ is able to compute or execute the zero-knowledge proof protocol. In an embodiment, the received data related to the zero-knowledge proof protocol is signed by the trusted device TD which has compiled the zero-knowledge proof protocol beforehand. Such received data related to the zero-knowledge proof protocol may be signed by the trusted device TD using the protocol private key kT of the trusted device TD. Such received data related to the zero-knowledge proof protocol may also be signed using a digital certificate associated to the trusted device TD. Step 61 may thus include verifying the validity of the signature of the received data related to the zero-knowledge proof protocol. Such signature verification may be performed by the trusted module of the remote equipment EQ using the protocol public key KT. Such signature may also be performed by verifying the validity of the certificate associated to the trusted device TD.

[119] At a step 62, the trusted module of the remote equipment EQ proceeds to gather security parameters of the remote equipment EQ. In particular, such security parameters may for example be:

- a serial number of a hardware component of the remote equipment (EQ),

- a version of the operating system of the remote equipment (EQ),

- an update level/version of the operating system of the remote equipment (EQ),

- an antivirus software/version of the remote equipment (EQ),

- an update level/version of the antivirus software of the remote equipment (EQ),

- a firewall of the remote equipment (EQ),

- a configuration of the firewall of the remote equipment (EQ),

- hardware drivers of the remote equipment (EQ), and/or

- Endorsement Key - EK - of a Trusted Platform Module - TPM - of the remote equipment (EQ).

[120] Such security parameters may relate to the operating system - OS - of the remote equipment EQ. Such security parameters thus reflect an aspect of the security or trustworthiness level of the remote equipment EQ. The selection of the security parameters to be gathered at step 62 notably depend on the zero-knowledge proof protocol received at step 61 .

[121] In particular, the gathering of the security parameters is executed by the trusted module of the remote equipment EQ within a secure execution environment (e.g., within a TEE or TPM). Thus, the trusted module of the remote equipment EQ proceeds to step 62 based on native code and native function calls only. In particular, such security parameter gathering being performed within such secure execution environment of the remote equipment EQ, the integrity of the values of such gathered security parameters may be guaranteed. Indeed, such step being performed by the trusted module of the remote equipment EQ, the gathered security parameters have a guaranteed integrity and do not present forged (that is, possibly falsified) values.

[122] At a step 63, the trusted module of the remote equipment EQ proceeds to calculate a zeroknowledge proof based on the gathered security parameters and on the data related to the zeroknowledge proof protocol received from the trusted device TD. In particular and similarly to step 62, step 63 is executed by the trusted module of the remote equipment EQ within the secure execution environment (e.g., within a TEE or TPM). Thus, the zero-knowledge proof determined by the trusted module at step 63 has a guaranteed integrity and does not present a forged (that is, possibly falsified) value. Such zero-knowledge proof may notably be understood as a compliance score of the remote equipment EQ to the security requirements.

[123] At a step 64, the trusted module of the remote equipment EQ signs the zero-knowledge proof determined at step 63. Such zero-knowledge proof may be signed using the equipment private key ks stored by the trusted module of the remote equipment EQ, for example after generating it. The zero-knowledge proof may notably be signed using the cryptographic key related to a digital certificate issued by the trusted module or another Certifying Authority. Such signature of the zeroknowledge proof by the trusted module of the remote equipment EQ thus enables to identify that such specific trusted module of the remote equipment EQ (or such type of trusted module for which a digital certificate was issued) is the genuine emitter of the zero-knowledge proof. In particular, based on the previous enrollment step 60, the signature of the zero-knowledge proof using the certified cryptographic key ensures that the emitter of such signed zero-knowledge proof is the trusted module of the remote equipment EQ as genuinely identified by the trusted device TD during the initial enrollment step 60.

[124] At a step 65, the remote equipment EQ sends the signed zero-knowledge proof to the controlling device CD. By sending such signed zero-knowledge proof, the remote equipment provides the controlling device CD with proof information to assess a security compliance of the remote equipment EQ with security requirements. In particular, the zero-knowledge nature of such sent zero-knowledge proof enables to do so without actually transmitting a security level information of the remote equipment EQ. Thus, the signed zero-knowledge proof transmitted at step 65 does not provide any sensitive information about the remote equipment EQ yet enables to prove to the controlling device CD whether or not the remote equipment EQ presents a security compliance to the security requirements.

[125] At an optional step 66, the remote equipment EQ emits at least one authentication value to the controlling device CD via a human-machine interface of the remote equipment EQ. Such authentication values are inputted by the individual P using the remote equipment EQ, for example on request of the controlling device CD after checking the zero-knowledge proof sent by the remote equipment EQ at step 65. Thus, at step 66, the remote equipment EQ may send data related to knowledge factors (such as a password), possession factors (such as a specific hardware component to be linked to a port of the remote equipment EQ) and/or inherence factors (such as biometrics like fingerprints, face scanning...) to the controlling device CD.

[126] At a step 67, the remote equipment EQ may obtain data related to an authorization of access from the controlling device CD. For example, such data related to the authorization of access may be a confirmation of granted access or a notification of denied access from the controlling device CD. Such data related to an authorization of access may also be opened resources and assets of the served service provided to the remote equipment EQ, meaning that an authorization of access has been granted for the remote equipment EQ.

[127] It is now referred to figure 7. Figure 7 shows steps for compiling a zero-knowledge proof protocol in the access control context of the present disclosure. Such protocol compilation may be performed by a trusted device TD which acts as a trusted third-party for all devices involved in the access control context. For example, the trusted device TD may compile the zero-knowledge proof protocol in the context of a controlling device CD and a remote equipment EQ enrolled to a trusted third party T for performing a zero-knowledge proof-based access control, the controlling device CD being a verifying device and the remote equipment EQ being the proving device.

[128] Thus, at an initial step 70, each of the remote equipment EQ and the controlling device CD may have performed an initial enrollment step to the trusted device TD. During such enrollment steps, as previously detailed at steps 50 and 60 of respective figures 5 and 6, the trusted device TD have identified the controlling device CD and the trusted device TD. In particular, the cryptographic key ks, KE associated to the trusted module of the remote equipment EQ has been certified to genuinely identify the trusted module of the remote equipment EQ, by a digital certificate issued to the trusted module of the remote equipment EQ during the enrollment step 60. Thus, at step 70, cryptographic keys have been exchanged and/or digital certificates have been presented between the devices TD, CD, EQ involved in the Public Key Infrastructure set by the trusted third- party T. In particular, during such enrollment step 70, the controlling device CD may have obtained data related to a protocol public key KT associated with the trusted device TD (e.g., via a digital certificate associated with the trusted device TD). Such enrollment step of the controlling device CD to the trusted device TD may for example involve a subscription by the controlling device CD to a zero-knowledge proof-based access control service proposed by the trusted third-party T. The trusted device TD may compile the zero-knowledge proof protocol in the context of an enrollment of the remote equipment EQ to the trusted third party T for performing a zero-knowledge proof-based access request. During such enrollment step, the remote equipment EQ may have received a protocol public key KT associated with the trusted device TD. Such enrollment step of the remote equipment EQ to the trusted device TD may for example involve a downloading of an application launched by the trusted third-party T on the remote equipment EQ.

[129] At a step 71 , the trusted device TD obtains security requirements from the enrolled controlling device CD. Such security requirements may for example relate to criteria set or configured by the controlling device CD for authorizing an access to the secure service SS. Such security requirements may be proper to the controlling device CD. In such case, the controlling device CD may send the security requirements once, for example after the enrollment step 70. In another embodiment, the security requirements may vary, for example depending on time or on the secure service SS managed by the controlling device CD. In such case, the controlling device CD may send periodic or more generally, several sets of security requirements to the trusted device TD.

[130] At a step 72, the trusted device TD compiles a zero-knowledge proof protocol based on the obtained security requirements. Such zero-knowledge proof protocol relies on a zero-knowledge encryption technique. For example, the trusted device TD may compile the zero-knowledge proof protocol based on the Zero-Knowledge Scalable Transparent Knowledge Argument (ZK-STARK) protocol. Preferably, the trusted device TD may compile the zero-knowledge proof protocol based on the Zero-Knowledge Succinct Non-Interactive Knowledge Argument (ZK-SNARK) protocol. Indeed, ZK-SNARKS protocols may rely on the Public Key Infrastructure initialized by the trusted device TD. Moreover, ZK-SNARKS protocols present sufficient computation capabilities in the context of the aforementioned proof-based security check and request methods.

[131] At a step 73, the trusted device TD may proceed to sign the zero-knowledge proof protocol. Such signature by the trusted device TD may rely on the protocol private key k? generated by the trusted device TD. Such signature by the trusted device TD may also rely on a protocol digital certificate associated with the trusted device TD and known to the enrolled remote equipment EQ and controlling device CD.

[132] At a step 74, the trusted device TD proceeds to send such signed zero-knowledge proof protocol to the controlling device CD in the context of the access control method.

[133] At a step 75, the trusted device TD proceeds to send such signed zero-knowledge proof protocol to the remote equipment EQ, in the context of the access granting method to be performed by the remote equipment EQ.

[134] Steps 74 and 75 may be interchangeably or concomitantly performed.

List of references

- T : trusted third-party

- P: individual using the remote equipment

- C: company

- TD: trusted device

- CD: controlling device

- EQ: remote equipment

- SS: secure service

- RD: router

- KT: protocol public key

- k?: protocol private key

- KE: equipment public key

- ks: equipment private key

Claims

1. An access control method for checking a security compliance of a remote equipment (EQ) to security requirements, the access control method including steps of: obtaining (51) a zero-knowledge proof protocol depending on the security requirements, receiving (52) from the remote equipment (EQ) a zero-knowledge proof computed using the zeroknowledge proof protocol and security parameters related to said remote equipment (EQ), said zeroknowledge proof being signed by a trusted module of the remote equipment (EQ), authorizing (58) an access for said remote equipment (EQ) at least if it is assessed that (53, 54, 55):

- the signed zero-knowledge proof is related to an authorized entity related to the trusted module of the remote equipment (EQ),

- the signed zero-knowledge proof has been computed according to the zero-knowledge proof protocol; and

- the signed zero-knowledge proof demonstrates that the security compliance of the remote equipment (EQ) is valid.

2. The access control method according to claim 1 , wherein the authorized entity is related to an element among:

- a trusted device (TD) certifying the trusted module of the remote equipment (EQ),

- a Certification Authority certifying the trusted module of the remote equipment (EQ).

3. The access control method according to any one of the precedent claims, wherein it is assessed that the signed zero-knowledge proof is related to the authorized entity by using a first cryptographic key (KE) associated with the trusted module of the remote equipment (EQ), said first cryptographic key being certified by the authorized entity.

4. The access control method according to any one of the precedent claims, wherein it is assessed that the signed zero-knowledge proof has been computed according to the zero-knowledge proof protocol by using a second cryptographic key (KT) associated with the authorized entity.

5. The access control method according to any one of the precedent claims, wherein it is assessed that the signed zero-knowledge proof demonstrates that the security compliance of the remote equipment (EQ) is valid by at least comparing a value of the zero-knowledge proof with a predefined accuracy value.

6. The access control method according to any one of the precedent claims further comprises, before receiving the zero-knowledge proof protocol,: enrolling (50) to the authorized entity, obtaining a second cryptographic key (KT) associated with the authorized entity.

7. The access control method according to any one of the precedent claims further comprises: receiving a user authentication value, wherein the access for said remote equipment (EQ) is authorized if it is further assessed (57) that the user authentication value matches data of a stored user authentication database.

8. The access control method according to any one of the precedent claims, wherein the zero-knowledge proof protocol relates to the Zero-Knowledge Succinct Non-Interactive Argument of Knowledge - ZK-SNARK - proof protocol.

9. A controlling device (CD) comprising at least a processing circuit (PROC, MEM, COM) for performing the access control method according to any one of claims 1 to 8.

10. A computer program product comprising program instruction code stored on a computer-readable medium for the execution of the access control method according to any one of claims 1 to 8.

11. An access granting method performed by a trusted module of a remote equipment (EQ) for being granted an access by proving a security compliance of the remote equipment (EQ) to security requirements, the access granting method comprising steps of: obtaining (61) data related to a zero-knowledge proof protocol, said zero-knowledge proof protocol depending on the security requirements, gathering (62), in the trusted module, data related to security parameters related to the remote equipment (EQ), determining (63), in the trusted module, a zero-knowledge proof based on said security parameters and on the zero-knowledge proof protocol, signing (64) the zero-knowledge proof using a cryptographic key stored in the trusted module, transmitting (65) the signed zero-knowledge proof to a controlling device (CD), receiving (67), in response to the transmission of the signed zero-knowledge proof, data related to an authorization of access for the remote equipment (EQ).

12. The access granting method according to claim 11 , wherein said access granting method is computed in a secure execution environment of the remote equipment (EQ).

13. The access granting method according to claim 12, wherein the secure execution environment of the remote equipment (EQ) relates to an element among:

- a Trusted Execution Environment - TEE - of the remote equipment (EQ), and

- a hardware Trusted Platform Module - TPM - of the remote equipment (EQ).

14. The access granting method according to any one of claims 11 to 13, wherein the security parameters are related to an element or a combination of elements among at least:

- a serial number of a hardware component of the remote equipment (EQ),

- a version of the operating system of the remote equipment (EQ),

- an update level of the operating system of the remote equipment (EQ),

- an antivirus software of the remote equipment (EQ),

- an update level of the antivirus software of the remote equipment (EQ),

- a firewall of the remote equipment (EQ),

- a configuration of the firewall of the remote equipment (EQ),

- hardware drivers of the remote equipment (EQ), and

15. The access granting method according to any one of claims 11 to 14, wherein the cryptographic key relates to at least :

- a digital certificate issued by an authorized entity and certifying the trusted module of the remote equipment (EQ), and/or

- a private cryptographic key (ks) generated by the trusted module of the remote equipment (EQ).

16. The access granting method according to any one of claims 11 to 15 further comprises, before obtaining data related to a zero-knowledge proof protocol,: enrolling (60) to an authorized entity (TD), obtaining a digital certificate issued by said authorized entity (TD) and certifying the trusted module of the remote equipment (EQ).

17. The access granting method according to any one of claims 11 to 16, wherein the zero-knowledge proof protocol relates to the Zero-Knowledge Succinct Non-Interactive Argument of Knowledge - ZK-SNARK - proof protocol.

18. The access granting method according to any one of claims 11 to 17 further comprises, before receiving (67) data related to the authorization of access: providing (66) a user authentication value to the controlling device (CD) via a human-machine interface of the remote equipment (EQ).

19. A remote equipment (EQ) comprising at least a processing circuit for performing the access granting method according to any one of claims 11 to 18.

20. A computer program product comprising program instruction code stored on a computer-readable medium for the execution of the access granting method according to any one of claims 11 to 18.

21. The computer program product according to claim 20, wherein the program instruction code only relies of native-defined functions.