A decentralized, confidentiality-preserving method and system for remotely certifying the status of a termination point where trust has not been established.

Abstract

The invention relates to a method for remotely certifying the State (S) of a Terminal (E), whose trustworthiness is not established, from a Server (B), involving a Terminal Orchestrator (EO) and at least one Terminal Validator (EV) that attest to the Plausibility (P) of the State (S). The Terminal Validators (EV) are distinct from the Terminal Orchestrator (EO). The State (S) is based on a series of State Validations (SVi) and a State Function (SF), such that S = SF(SVi). The State (S) is known to both the Server (B) and the Terminal (E). The State Function (SF) is known to both the Server (B) and the Terminal (E). The series of State Validations (SVi) are unknown to the Server (B) but known to the Terminal (E). The process includes a step of verifying the Plausibility (P) of the State (S) with the following conditions: the Plausibility (P) represents an analysis of information from the Terminal (E) allowing verification of the accuracy of the State (S);Plausibility (P) is known to the Server (B) via the Terminal Orchestrator (EO); Plausibility (P) is based on a series of Plausibility Validations (PVj) and a Plausibility Function (PF), such that P = PF(PVj); the Plausibility Function (PF) and the Plausibility Validations (PVj) are updated dynamically; the individual Plausibility Validations (PVj) are unknown to the Server (B), to protect the confidentiality of the Terminal (E); the Plausibility Function (PF) and the Plausibility Validations (Pvj) are unknown to the Terminal (E), to make it difficult to falsify Plausibility (P); the Plausibility Function (PF) is calculated by the Terminal Orchestrator (EO); Plausibility Validations (PVj) are calculated by the Terminal Validator (EV) based on a series of Terminal Data (ED) unknown to any component of the system except the Terminal (E).

Description

Title of the invention: DECENTRALIZED METHOD AND SYSTEM PRESERVING CONFIDENTIALITY FOR REMOTELY CERTIFYING THE STATUS OF A TERMINATION POINT WHOSE TRUST IS NOT ESTABLISHED. TECHNICAL FIELD OF THE INVENTION

[0001] The invention relates to a method and a system for remotely certifying the State (S) of a Terminal (E) whose trust is not established. The invention falls within the field of decentralized computing that preserves confidentiality and the certification of the state of terminals (in particular the security posture of terminals).

[0002] The goal is to remotely certify the State (S) of a Terminal (E) whose trust is not established. In particular, it is to certify that the Security Posture (SP) of such a Terminal (E) attempting to access one or more remote Resources (R) complies with the various security policies when it accesses that Resource (R). For example, the security policies may include prerequisites for installed software or system configurations aimed at improving the Security Posture (SP) of the Terminal (E) when it accesses the resource (R). The invention can be applied to other properties describing the State (S) of the Terminal (E) and is not limited to the Security Posture (SP).

[0003] By Security Posture (SP) certification, we mean regularly calculating the Security Posture (SP) but also proving its accuracy and demonstrating its value to the Resource Owner (RO) (R). Thanks to this certification, a Security Posture (SP) that meets the expectations of a Resource Owner (RO) can be used with confidence to dynamically authorize or deny access to the resource (R).

[0004] Unlike existing solutions, we want this certification to be possible for all types of Terminals (E), including Terminals (E) not owned or controlled by the Resource Owner (RO) and therefore not approved by the Resource Owner (RO). We want to do this in a way that is extremely difficult to tamper with, so as to give the Resource Owner (RO) strong confidence in the calculation of the Terminal's Security Posture (SP). And we want to do this while offering a full guarantee of the privacy or confidentiality of the Terminal Data (ED) used to perform said certification.

[0005] CONTEXT OF THE INVENTION

[0006] According to the state of the art, one solution would be to obtain certification from a State (S) for a Terminal (E) as its Security Posture (SP) by allowing arbitrary access and Dynamic Endpoint Data (ED) is managed by the Resource Owner (RO) via a Server (B) combined with a Software Agent (SA) running on the Endpoint (E) for remote attestation and other security analysis mechanisms. Traditionally, the Endpoint (E) would run a Unified Endpoint Management (UEM) solution consisting of a Software Agent (SA) running on the Endpoint (E) and a Server (B), where the Software Agent (SA) is fully controlled by the Server (B).

[0007] However, arbitrary access to Terminal Data (TD) by the Resource Owner (RO) is only possible when: ■ The Terminal (E) belongs to the Resource Owner (RO) and is centrally managed by the Resource Owner (RO); and ■ The Terminal (E) is not used by the Terminal User (EU) for personal reasons, as the control of the Terminal (E) implied by Unified Endpoint Management (UEM) would violate the privacy of the Terminal User (EU), and ■ The Terminal (E) is not used by the Terminal User (EU) to access multiple Resources (R), since the control of the Terminal (E) implied by Unified Endpoint Management (UEM) would violate confidentiality. For example, a Resource (RI) belonging to a Resource Owner (OR1) and another Resource (R2) belonging to a Resource Owner (OR2) would both be accessible to both Resource Owners (OR1) and (OR2).

[0008] A broader solution to this problem, covering Terminals (E) that do not belong to the Resource Owner (RO), involves implementing a process where the Terminals (E) are under the control of a Trusted Third Party (TP), potentially using Unified Endpoint Management (UEM). The Trusted Third Party (TP) could certify the Security Posture (SP) to the Resource Owner (RO) by accessing the Terminal Data (ED) while guaranteeing to the Terminal User (TU) that the Terminal Data (ED) is never exposed to the Resource Owner (RO). However, when using such a Trusted Third Party (TP), direct access to the Terminal Data (ED) by the Trusted Third Party (TP) still presents a high degree of risk to the privacy or confidentiality of the Terminal User (TU).

[0009] One solution to mitigate the risks to confidentiality would be to perform the Security Posture (SP) certification within the Terminal (E) itself. However, the guarantees offered by using the Terminal (E) for its own security analysis are very weak. Indeed, such a process would be extremely easy to falsify, particularly in a scenario where the Terminal (E) does not belong to the Resource Owner (RO).

[0010] Certain prior art techniques are described in US20220329585A1, US20220321362A1 and US20190199530A1.

[0011] US20150327208A1 describes a method for determining if the location provided by A mobile device is deemed reliable and / or trustworthy. This method does not concern itself with the privacy of the mobile device user. Summary of the invention

[0012] The invention aims to provide an improved method and system for remote certification by a State Resource Owner (SRO) of any Terminal (E), in particular Terminals (E) which are under the exclusive control of the Terminal User (TU) and not managed by Unified Terminal Management (UEM) and therefore not approved by the Resource Owner (SRO).

[0013] To this end, the invention relates to a method for remotely certifying the State (S) of a Terminal (E) from a Server (B), involving a Terminal Orchestrator (EO) and a Terminal Validator (EV) to attest to the Plausibility (P) of the State (S), in which: ■ The Terminal Validator (EV) is distinct from the Terminal Orchestrator (EO), ■ the State (S) is based on a series of State Validations (SVi) and a State Function (SF), such that S = SF (SVi), ■ The state (S) is known to the Server (B) and the Terminal (E), ■ The State Function (SF) is known to the Server (B) and the Terminal (E), ■ The series of State Validations (SVi) are unknown to the Server (B) but known to the Terminal (E), and in which the process includes a step of verifying the Plausibility (P) of the State (S) with the following conditions: ■ Plausibility (P) represents an analysis of the information within the Terminal (E) that supports the accuracy of the State (S), ■ Plausibility (P) is known to the Server (B) via the Terminal Orchestrator (EO), ■ Plausibility (P) is based on a series of Plausibility Validations (PVj) and a Plausibility Function (PF), such that P = PF (PVj), ■ The Plausibility Function (PF) and Plausibility Validations (PVj) are updated dynamically, ■ Individual Plausibility Validations (PVj) are unknown to the Server (B), to protect the confidentiality of the Terminal (E), ■ The Plausibility Function (PF) is unknown to the Terminal (E), to make it difficult to falsify the Plausibility (P), ■ The Plausibility Function (PF) is calculated by the Terminal Orchestrator (EO), ■ Plausibility Validations (PVj) are calculated by the Terminal Validator (EV) on the basis of a series of Terminal Data (ED) unknown to any component of the system except the Terminal (E).

[0014] Thanks to the invention, State (S) certification is possible for any Terminal (E), for example, the Security Posture (SP) of Terminals (E) defined by State (S), particularly Terminals (E) that are under the exclusive control of the Terminal User (EU), without Unified Endpoint Management (UEM) or any other control by the Resource Owner (RO). To achieve this, we use a Trusted Third Party (TP) that certifies State (S) without directly accessing Terminal Data (ED). The dynamic certification of the Security Posture (SP) is based on the dynamic calculation of a Plausibility (P) based on Plausibility Validations (PV) performed on Terminal Data (ED).Plausibility Validations (PVs) are performed on Terminal Validators (EVs), running on secure Hosts (Hs), potentially including other Terminals (Es) whose Security Posture (SP) has been previously certified as satisfactory and which we define as Participating Terminals (PEs). Terminal Validators (EVs) only have access to an encrypted version of the Terminal Data (ED) to guarantee the confidentiality of the Terminal (E). The terminals (Es) have no knowledge of the extracted information or the Plausibility Validations (PVs) performed to ensure security. The Trusted Third Party (TP) that orchestrates the Plausibility Validations (PVs) does not have access to the Terminal Data (ED) but does have access to the results of the Plausibility Validations (PVs). The Trusted Third Party (TP) may be audited to ensure that no private and unauthorized information can be inferred from the Plausibility Validations (PVs).

[0015] According to other non-mandatory advantages of the invention, such a process may incorporate one or more of the following features:

[0016] - The Terminal Validator (EV) is composed of one or more Terminals Participants (PE) orchestrated by the Terminal Orchestrator (EO), whose State (S) has been previously certified according to the method described above.

[0017] - The Plausibility Function (PF) and the Plausibility Validations (PVj) are retained secret by the Terminal Orchestrator (EO) but can be audited for compliance with Terminal (E) confidentiality.

[0018] - The Plausibility Function (PF) and the Plausibility Validations (PVj) are defined dynamically by human operators and / or software components.

[0019] - Plausibility Validations (PVj) are calculated using, on the one hand, a series of Terminal Data (EDj) captured according to a series of Terminal Data Specifications (EDSj) on the Terminal (E) and, on the other hand, of a series of Parameters (PAk) known only to the Terminal Orchestrator (EO) to make it difficult to falsify Plausibility (P), in which: ■ PVj = PFj (EDj, PAk), ■ The Terminal Data Specification (EDSj) series and the Parameter Series (PAk) can be audited for compliance with Terminal Confidentiality (E).

[0020] - The Terminal Validator (EV) only has access to an encrypted version of the Data of the Terminal (EDj) and to an encrypted version of the Parameter series (PAk). The Plausibility Function PFj (EDj, PAk) is a function that supports operations on encrypted parameters such as those based on totally homomorphic encryption or multipartite calculus.

[0021] - Plausibility Validations PVj = PF (EDj, PAk) and the Plausibility Function (PF) is a function returning a Result (RE) and a validation calculation history (VCH) which can be used for the stateful calculation of the Plausibility Function (PF) where the validation calculation history (VCH) is sent to the Terminal Orchestrator (EO) and aggregated to the parameter series (PAk) in an encrypted form readable only by the Terminal Validator(s) (EV).

[0022] - Plausibility Validations PVj = PF (EDj, PAk) and the Plausibility Function (PF) is a function enabling pattern filtering preserving the confidentiality of Terminal Data (EDj) and the parameter series (PAk) are patterns to be matched, where the Terminal Validator(s) (EV) only have access to the encrypted version of Terminal Data (EDj) and an encrypted version of the parameter series (PAk).

[0023] The invention also relates to a system for remotely certifying the State (S) of a Terminal (E) from a Server (B), the system comprising a Terminal Orchestrator (EO) and at least one Terminal Validator (EV) to attest to the plausibility (P) of the State (S), in which: ■ The Terminal Validator (EV) is distinct from the Terminal Orchestrator (EO), ■ the State (S) is based on a series of State Validations (SVi) and a State Function (SF), such that S = SF (SVi), ■ The state (S) is known to the Server (B) and the Terminal (E), ■ The State Function (SF) is known to the Server (B) and the Terminal (E), ■ The State Validation Series (SVi) are unknown to the Server (B) but known to the Terminal (E), and in which the system is configured to check the Plausibility (P) of the State (S) with the following conditions: ■ Plausibility (P) represents an analysis of the information within the Terminal (E) that supports the accuracy of the State (S), ■ Plausibility (P) is known to the Server (B) via the Terminal Orchestrator (EO), ■ Plausibility (P) is based on a series of Plausibility Validations (PVj) and a Plausibility Function (PF), such that P = PF (PVj), ■ The Plausibility Function (PF) and Plausibility Validations (PVj) are updated dynamically, ■ Individual Plausibility Validations (PVj) are unknown to the Server (B), to protect the confidentiality of the Terminal (E), ■ The Plausibility Function (PF) is unknown to the Terminal (E), to make it difficult to falsify the Plausibility (P), ■ The Plausibility Function (PF) is calculated by the Terminal Orchestrator (EO), ■ Plausibility Validations (PVj) are calculated by the Terminal Validator (EV) on the basis of a series of Terminal Data (ED) unknown to any component of the system except the Terminal (E). Brief description of the drawings

[0024] The invention will now be explained with reference to the accompanying figures, by way of illustrative examples, without restricting the scope of the invention. In the accompanying figures:

[0025] [Fig.1] is a diagram showing the architecture of a complete solution using the invention to certify a Security Posture (SP) and expose it to Conditional Access Control (CAC) solutions.

[0026] [Fig.2] is a diagram showing the trust relationships between the components of the system.

[0027] [Fig.3] is a diagram showing the system architecture and the implementation of the process.

[0028] [Fig.4] is a diagram showing the knowledge specific to each of the components.

[0029] [Fig.5] is a diagram showing an example of implementation of the method for calculate a Security Posture (SP) where an Endpoint Protection Platform (EPP) is part of the security policies and where the Plausibility (P) of (SP) includes a check of artifacts generated by normal Endpoint Protection Platform (EPP) activity.

[0030] DETAILED DESCRIPTION OF SOME EMBODIMENTS

[0031] Figure 1 illustrates a complete solution using the invention to certify a Security Posture (SP) and export it to a Conditional Access Control (CAC) solution associated with the Resources (R). The solution uses a Software Agent (SA) running on the Terminal (E) consisting of an application and an associated system assistant.

[0032] The invention makes it possible to certify a State (S) of any Terminal (E), for example a Security Posture (SP) of the Terminal (E), in particular Terminals (E) which are under the exclusive control of the Terminal User (EU), and therefore not managed by a Unified Terminal Management (UEM).

[0033] We define the key requirements of the solution as follows: a. A security guarantee from the perspective of a Resource Owner (RO), i. a solution that offers at least the same degree of security for State (S) certification as a solution allowing dynamic and arbitrary access to Terminal Data (ED) as with the use of Unified Endpoint Management (UEM); b. A guarantee of confidentiality from the perspective of the Terminal User (EU) i. a solution that limits the extraction of information from the Terminal (E) by any third party to very simple information such as a boolean or an integer allowing it to define whether the security of the Terminal (E) expected by the Resource Owner (RO) has or has not been achieved, and ii. a solution which ensures that none of its components can directly access Terminal Data (ED) and which limits the information collected internally to well-defined elements and which cannot contain Personally Identifiable Information (PII);

[0034] The architecture for combining these two sets of requirements is defined as the Digital Terminal Arbiter (DTA). The Digital Terminal Arbiter (DTA) dynamically certifies the State (S) to the Resource Owner (RO) via a Server (B) without any component of its architecture being able to directly access the Terminal Data (ED) except for the Terminal (E), and with strict control and auditability of the information extracted from the Terminal Data (ED). Therefore: - The Digital Terminal Arbiter (DTA) is trusted by the Server (B) for security; - The Terminal Digital Arbiter (EDA) is approved by the Terminal (E) for confidentiality.

[0035] In addition, the Digital Terminal Arbiter (DTA) supports a decentralized model in which other Participating Terminals (PEs) can contribute to the State (S) certification process for a given Terminal (E).

[0036] The advantages of the invention are: - It works on all terminals (E), whether owned by the Resource Owner (RO) or not, and fully respects confidentiality and privacy, allowing hybrid personal / professional or multi-employer use of the Terminal (E). - It allows for the highest reliability of State(s) certification. In particular, it can go further than any other existing solution in terms of using Terminal Data (ED) to perform State(s) certification without any risk to the privacy of the Terminal User (EU).

[0037] For example, the invention can calculate a Security Posture (SP) based on Terminal Data (ED) that covers information from a personal environment in which the Terminal (E) would be used, such as the security status of other elements in the Terminal's Local Area Network (LAN). This cannot be achieved with Unified Endpoint Management (UEM) solutions without the Resource Owner (RO) incurring confidentiality and privacy liabilities.

[0038] When using Participating Terminals (PE), the invention minimizes the computing and storage requirements on the central components of the system by using the computing power and storage of the Participating Terminals (PE) and increases the scalability capability of the solution.

[0039] Solution architecture

[0040] The Digital Terminal Arbiter (DTA) includes a Terminal Orchestrator (TO) component responsible for coordinating one or more Terminal Validator (TV) components where: - The Terminal Orchestrator (EO) maintains a list of Terminals (E) and Terminal Validators (EV). - The Terminal Orchestrator (TO) oversees the definition of Terminal Data Specifications (TDS) describing the Terminal Data (TD) to be extracted from the Terminal (T) and the Plausibility Validations (PV) to be performed on them. - The Terminal Orchestrator (EO) and the Terminal Validator (EV) are never able to directly access Terminal Data (ED). - Only Terminal (E) is able to directly access Terminal (ED) Data. - The Terminal Orchestrator (EO) is the only component capable of deducing information from Terminal Data (ED) based on the result of Plausibility Validations (PV). - The information deduced by the Terminal Orchestrator (TO) from the result of the Plausibility Validations (PV) is limited and strictly controllable and auditable.

[0041] Figures 2 to 5 show the system, comprising the Digital Terminal Arbiter (DTA), the Server (B), and the Terminal (E). The Digital Terminal Arbiter (DTA) includes a Terminal Orchestrator (EO) and Terminal Validators (EV), including an Initial Terminal Validator (EVB) and a Terminal Participant (PE). In particular, [Fig.2] illustrates the trust relationships between the system components; [Fig.3] illustrates the system architecture and the implementation of the process; [Fig.4] illustrates the knowledge of the components; and [Fig.5] illustrates an example of process implementation, with a Terminal Protection Platform (EPP).

[0042] Terminal Validators (EVs) can be implemented in any Host (H), i.e., a Participating Terminal (PE) or an Initial Terminal Validator (EVB), whose security has been analyzed and can be guaranteed. We define an Initial Terminal Validator (EVB) as one or more instances of a Terminal Validator (EV) that meet these requirements using secure and controlled components operated within the framework of the Digital Terminal Arbiter (EDA). We use Participating Terminals (PEs) whose Security Posture (SP) has been previously certified as other types of Terminal Validator (EV) instances that meet these requirements. We prohibit the Terminal (E) from acting as a Terminal Validator (EV) for the certification of its own Security Posture (SP).

[0043] Detailed innovations of our solution

[0044] First, we innovate in the way we certify the State (S), for example the Security Posture (SP), of the Terminal (E). The invention could be applied to other properties describing the State (S) of the Terminal (E) and is not limited to the Security Posture (SP). We apply some of the principles of Internet of Things (IoT) device data certification to the concept of evaluating and certifying the Terminal (E) State (S). Just as with IoT device data, we assume that regardless of the data capture and export process—that is, the State (S) in our case—there will always be opportunities to falsify that process. Therefore, we adopt the principle of Plausibility Validations (PVs) to confirm the validity of the measured data. In other words, instead of trusting the State (S) as provided by the Terminal (E), we perform additional Plausibility Validations (PVs), taking the form of a Plausibility Value (P) resulting from capturing information from the Terminal (E) to confirm or refute that the State (S) is valid and has not been falsified.

[0045] Secondly, we innovate by eliminating the risks associated with a Trusted Third Party (TP) directly accessing Terminal Data (ED) within the context of State Validation (SV). To do this, we use a Terminal Orchestrator (EO) which: - Never directly access Terminal Data (ED) using external Terminal Validators (EV). - Nor can it derive unauthorized private or confidential information such as Personally Identifiable Information (PII) from the Terminal (E) through strict control and auditability of its behavior, particularly in the definition and orchestration of Terminal Data Specifications (EDS) and Plausibility Validations (PV).

[0046] Third, we innovate by using techniques such as totally homomorphic encryption or multi-party computation or confidentiality-preserving pattern filtering to perform Plausibility Validations (PV) in Terminal Validators (EV) without the Terminal Data (ED) being directly accessible by the Terminal Validators (EV).

[0047] We solve the following problem from a mathematical point of view. We define the State (S) of the Terminal (E) as a series of State Validations (SVi). We define Plausibility (P) as another series of Plausibility Validations (PVj) giving indications on the validity of the State (S), for its consumption by the Resource Owner (OR) to decide the rights of the Terminal (E) to access the Resources (R).

[0048] State (S) Calculation: The Resource Owner (RO) needs to know the State (S) of the Terminal (E). In its simplest form, the State (S) is a Boolean. For example, a Security Posture (secure / insecure), resulting from the evaluation of a State Function (SF) using a series of Boolean State Validations (SVi) expressing the implementation of specific security policies on the Terminal (E). In this example, this Boolean would be used to allow or deny access to the Resource (R). But the State (S) can also be an integer to allow, for example, granting non-binary (leveled) access control to the Resource (R).

[0049] Calculation of Plausibility (P): The Resource Owner (RO) needs to know the Plausibility (P) of the State (S). In its simplest form, Plausibility (P) is a Boolean (plausible / not plausible). However, Plausibility (P) can also be an integer. Plausibility (P) is calculated by extracting several Terminal Data (EDj) from the Terminal (E) and applying Plausibility Validations (PVj) to the Terminal Data (EDj). For example, Plausibility (P) can be a Plausibility Function (PF) with Plausibility Validations (PVj), as follows: P = PF (PVj) and PVj = PF2 (EDj), where PF2 is a function performing a Plausibility Validation (PVj) on the Terminal Data (Edj).

[0050] Security: The Resource Owner (RO) does not trust the Terminal (E) for the security of the Resource (R). We need the State (S) to be calculated by the Terminal (E) and exposed to the Terminal User (TU) simultaneously for possible correction purposes (e.g., by requesting the Terminal User (TU) to change a specific Terminal (E) configuration to comply with a required security policy), while being verifiable by the Resource Owner (RO) through a Plausibility (P). We want to ensure protection against falsification of the Plausibility (P) by the Terminal (E) by making the Plausibility Function (PF) and the Plausibility Validations (PVj) unknown to the Terminal (E).

[0051] Confidentiality: The Terminal User (EU) does not trust any third party for the confidentiality of the Terminal Data (ED), and we want to prohibit the extraction of unauthorized information from the Terminal (E) by either the Resource Owner (OR), the Digital Terminal Arbitrator (EDA), or the Server (B).

[0052] In the calculation of the State (S), we use the Server (B): - We explicitly expose to the Terminal User (TU) the series of State Validations (SVi) composing a given State (S). - We prohibit dynamic modifications to the State Validation List (SVi) that would allow unwanted information to be deduced from Terminal (E) by using strict change control. - We make the state validations (SVi) unknown to the Resource Owner (OR) and the Server (B), while the State Function (SF) is known to both the Resource Owner (OR) and the Terminal (E).

[0053] In the calculation of Plausibility (P), we use the Numerical Arbiter of Terminals (EDA): We want Plausibility (P) to be calculated by the Endpoint Arbiter (EDA) in a way that uses but never exposes Endpoint Data (ED) to any third party, including the Resource Owner (OR), any components of the Endpoint Arbiter (EDA), or the Server (B). We want Plausibility Validations (PVj) to never allow the inference of unauthorized information from the Endpoint (E), in particular, but not limited to, Personally Identifiable Information (PII), by preventing Plausibility Validations (PV) from being based on unauthorized information through strict control of their definition.

[0054] Detailed description of the technology

[0055] We introduce a new Server (B) concept in the cloud that allows for the definition, dynamic evaluation, and certification of the State (S) of an Endpoint (E). The service uses a decentralized approach that respects confidentiality by preventing the disclosure of Endpoint Data (ED) or the inference of unauthorized information such as Personally Identifiable Information (PII) to the Server (B) or any other third party, and offers enhanced security based on dynamic Plausibility Validations (PV) performed by Participating Endpoints (PE), whose State (S) has been previously validated. When representing a Security Posture (SP), The certified state (S) can be used, for example, to dynamically and securely grant or deny access to specific Resources (R).

[0056] Definition and calculation of a State (S)

[0057] By way of example, to evaluate the Security Posture of a Terminal (E) we define a State (S) of the Terminal (E) by considering a combination of different State Validations (SVi) verifying the existence or absence of specific software or configurations: - According to standardized "threat models" covering, for example: ■ Operational status of the elements of the security stack (Terminal Protection Platform (EPP), Terminal Firewall (E)...) ■ Specific fortified state of the Terminal Operating System (EOS) configuration and services ■ Presence of Terminal Operating System (EOS) configurations / services that would compromise security and / or confidentiality ■ Remote attestation of the Terminal Operating System (EOS) and the Terminal Boot Loader (E), as with remote attestation of the Apple operating system - Consideration of several dimensions, for example: ■ Applications: includes application permissions, proper application signing, the existence of an installed Endpoint Protection Platform (EPP) covering application threats... ■ Network: includes the status of the Terminal (E) firewalls, the Terminal (E) visibility on the Local Area Network (LAN) such as ping response enabled... ■ Credentials: automatic login without password enabled, screen lock without password available... ■ System Integrity: Unified Endpoint Management (UEM) installed and other third-party administration tools, threats facilitating tampering such as hacker administrator kits... ■ System services: threats related to system services (remote access enabled...) - Leveraging standards such as those defined, for example: ■ By the Center for Internet Security (CIS) of the United States of America (USA) ■ And other government bodies (NIST in the USA, ANSSI in France...) - Which can be customized to match specific profiles or requirements imposed by different Resource Owners (ROs). - Which is done in a standardized way (where the same State (S) has the same meaning on different Terminal Operating Systems (EOS))

[0058] The State (S) is calculated locally on the Terminal (E) and is defined as a score and its components, i.e., a series of binary State Validations (SV) of various criticality / weight. The score can be represented as an integer and the validations (SV) can be represented as a vector of booleans with weights.

[0059] Security through dynamic Plausibility Validations (PV)

[0060] Terminal Data (ED) is collected locally on the Terminal (E) in the form of a list of byte sequences (strings, binaries, hashes...) extracted from specific locations defined as Terminal Data Specifications (EDS) describing portions of memory, disk or other Terminal (E) resources.

[0061] Functions implementing various checks on the Terminal Data (ED) are used to calculate the Plausibility (P). The checks include, among others: - Verification of the integrity of dependencies used in the score calculation. For example, considering this verification under macOS: "defaults read / Library / Preferences / com.apple.alf globalstate I grep 0" ° Obtaining the hash, path, and access rights of / bin / defaults (to test them against "normal" properties) ° Obtaining access rights to / Library / Preferences / com.apple.alf (to test them against "normal" properties) ° Obtaining the hash, path, and access rights of the grep binary (to test them against "normal" properties) ° Obtaining the complete binary of / Library / Preferences / com.apple.alf (to test it against the "normal" content) - Analysis of the operating status of the safety battery components. For example: ° The Endpoint Protection Platform (EPP) binary is present A given journal displays content that demonstrates it is active. ° An injection of a test threat shows a valid response - Explicit tamper detection. For example: SSH is disabled, but recent remote SSH access artifacts are present in the logs. ° System integrity protection was disabled and is now enabled, but no corrective action has been taken by the user. - A threat model defining how to calculate the State (S) and Plausibility (P) is stored in the Server (B) with two structures: State Validations (SV) and the logic defining the state (S) (the "public" model). The public model is present on the Terminal (E) (and the Server (B)) in a user-readable form for information and potential troubleshooting. This model is not intended to change frequently and is based on standard profiles. ° The logic defining the Plausibility (P) and Plausibility Validations (PV) to be applied to the Terminal Data (ED) (the "private" model). We call this the Dynamic Plausibility Model (DPM), which is: ■ present on a trusted element of the Terminal Orchestrator (EO) of the Digital Terminal Arbiter (EDA) and is kept secret to ensure the security of the Resources (R) of the Resource Owner (OR); ■ constantly modified by an operational process including humans and / or assistant software in order to maintain an advantage over potential attackers.

[0062] Additional Plausibility Validations (PVs) can be performed by the Endpoint Digital Arbiter (EDA) in other areas (as seen in Identity as a Service (laaS) platforms like Azure AD). For example, these additional Plausibility Validations (PVs) could use IP address reputation (as calculated with https: / / talosintelligence.com / reputation center / ).

[0063] State group propagation (S)

[0064] The State (S) and the Plausibility (P) of the Terminal (E) can: - take into account the State (S) or the Plausibility (P) of other Terminals (E) with which it would be in communication; - be calculated on the basis of the State (S) or the Plausibility (P) of other terminals (E) in the same Local Area Network (LAN); - be calculated on the basis of the State (S) or the Plausibility (P) of the other Terminals (E) participating in the same application or the same project / group.

[0065] Confidentiality using decentralization and encryption.

[0066] Confidentiality is achieved by strictly controlling the information that can be extracted from the Terminal Data (ED) to calculate the State (S) and the Plausibility (P). Each Terminal (E) registered in the system has received a unique device certificate (with its private key) from the Server (B). Registration is performed securely. - By using a trusted certificate for initial authentication, for example, based on a mechanism such as AWS's "Allocated by Claims" (ABC), or by using the Simple Certificate Enrollment Protocol (SCEP) to communicate certificate details with a Public Key Infrastructure (PKI). - By requiring sufficient initial security guarantees for the Terminal (E), for example by requiring a sufficient initial Security Posture (SP) represented by a State (S).

[0067] Each Terminal (E) can distribute Terminal Data (ED) to Terminal Validators (EV) via the Terminal Orchestrator (EO) in a confidentiality-preserving form. The Terminal Data (ED) is encrypted using homomorphic encryption or any other type of ciphertext that supports the calculation of Plausibility Validations (PV) without requiring access to the Clear versions of Terminal Data (ED). The origin IP address and Terminal identity (E) can be masked using intermediate relays, such as the Terminal Orchestrator (EO).

[0068] To calculate the State (S), we use secure communication with the Server (B) where: - Terminal (E) receives from a Server (B) a request corresponding to a given threat model and a Cryptographic Posture Nonce (SPN) - State (S) is calculated locally on the Terminal (E) according to the threat model - to validate State (S), we rely directly on the Server (B).

[0069] Optionally, communication from State (S) to Server (B) can be secured with a Trusted Platform Model (TPM) if available.

[0070] Optionally, some protection against possible falsification of the transmission of the State (S) by the Terminal (E) can be ensured by verifying its consistency with an anonymized version of its components. For example, by taking advantage of the fact that the State (S) is an integer and that the associated State Validations (SVs) are a series of booleans of different weights and using a homomorphic cipher: - Use of fully homomorphic encryption (FHE) of a binary matrix; - Where the State (S) and its properties are transmitted as a single property signed by the private key of a device certificate and encrypted homomorphically - The State (S) is recalculated from its properties in the Server (B) on the encrypted properties and compared with the score received. - If the recalculated score differs from the submitted score, the status (S) is invalidated.

[0071] To calculate the Plausibility (P), we use a decentralized approach involving the Digital Arbiter of Terminals (EDA) where: At the request of the Terminal Orchestrator (EO) and in accordance with the Terminal Data Specifications (EDS), the Terminal (E) locally collects the Terminal Data (ED), in the form of a list of strings, binaries, or hashes to be verified, which represent the set of parameters to be applied to a given Plausibility Validation (PV). It associates a Cryptographic Data Nonce (EDN) with each Terminal Data (ED). The Terminal (E) distributes the Terminal Data (ED), the Cryptographic Data Nonce (EDN), and the Cryptographic Posture Nonce (SPN) to one or more Terminal Validators (EVs) via the Terminal Orchestrator (EO). Optionally, a given Terminal Data (ED) can be sent to multiple Terminal Validators (EVs) to perform additional redundant validation.

[0072] Peer-to-peer communication takes place as follows: - The Terminal Orchestrator (TO) acts as a meeting point for peer-to-peer communications. - When communicating with a given Terminal Validator (EV), the Terminal (E) encrypts its communication using the Terminal Validator's (EV) public key, which will make any message understandable only by the Terminal Validator (EV). The Terminal Orchestrator (EO) cannot read or store Terminal Data (ED) because it only transmits it in an encrypted stream that it cannot decode.

[0073] The Terminal Data (ED) is also encrypted within the encrypted stream between the Terminal (E) and the Terminal Validators (EV) in a form that supports mechanisms such as fully homomorphic encryption, multi-party computation, or confidentiality-preserving pattern filtering where: - Terminal Validators (EV) obtain from the Terminal Orchestrator (EO) the encrypted Plausibility Validations (PV) associated to apply to the encrypted Terminal Data (ED). - And without any possibility for Terminal Validators (EV) to decrypt Terminal Data (ED). - And without any possibility for Terminal Validators (EV) to decipher Plausibility Validations (PV). - And where the result of the Plausibility Validations (PV) is known only to the Terminal Validators (EV). For example, Terminal Data (ED) and Plausibility Validations (PV) are encrypted using keys generated by the Terminal Orchestrator (EO) and securely communicated to the Terminal (E). In another example, Terminal Data (ED) is encrypted using a primary key generated by the Terminal (E) and an associated secondary key generated by the Terminal (E) and communicated by the Terminal (E) to the Terminal Orchestrator (EO) for the encryption of Plausibility Validations (PV), where the encrypted Plausibility Validations (PV) can be applied to the encrypted Terminal Data (ED).

[0074] Plausibility Validations (PV) take Terminal Data (ED) as one of their parameters and can be, for example:

[0075] - an arbitrary multipartite calculus function;

[0076] - a set of encrypted arithmetic operations using a form of encryption totally homomorphic;

[0077] - an encrypted form or an encrypted regular expression to be matched to through pattern-based filtering that preserves confidentiality;

[0078] - a set of encrypted parameters associated with a function and its code.

[0079] - any combination of the above;

[0080] Plausibility Validations (PV) can be: - Stateless: The Plausibility Validation Calculation History (PVCH) has no influence on the result of a given Plausibility Validation (PV). - Stateful: The Plausibility Validation Calculation History (PVCH) is part of the parameters of a given Plausibility Validation (PV). The PVCH can be stored locally on Terminal Validators (EVs). Or, for greater security and flexibility, the PVCH can be sent with the results of Plausibility Validations (PVs) to the Terminal Orchestrator (EO) in encrypted form with a key known only to the Terminal Validators (EVs), and will be part of the parameters of a subsequent Plausibility Validation (PV).

[0081] Terminal Validators (EV) perform a given Plausibility Validation (PV) on given Terminal Data (ED).

[0082] The individual Boolean results together with the Cryptographic Posture Nonce (SPN) and the unique peer identity are encrypted with the peer's private key and returned to the Terminal Orchestrator (EO).

[0083] A Plausibility (P) is calculated by Terminal Orchestrator (EO) by aggregating the results of all Plausibility Validations (PV) of a given Cryptographic Posture Nonce (SPN): if one of the results is FALSE or if one of the peers involved in the calculation has an abnormal score or plausibility, the plausibility is set to FALSE.

[0084] Cryptographic Data Nonce (EDN) is used to verify that all checks have been performed at least once.

[0085] Operation and auditability of software components

[0086] The Terminal Orchestrator (EO) is operated independently of the Server (B) and will ensure the ability to maintain the quality of the State (S) certification using Plausibility (P) via the Dynamic Plausibility Model (DPM) by dynamically defining Terminal Data Specifications (EDS) and Plausibility Validations (PV) in order to make it difficult for an attacker / adversary to falsify the calculation of State (S). The Terminal Orchestrator (EO) can be used by human operators. The operators can be assisted or replaced by assistive software components, including - Software that statistically calculates Terminal Data (ED) and Plausibility Validations (PV). - Software that calculates Terminal Data (ED) and Plausibility Validations (PV) using machine learning.

[0087] The Dynamic Plausibility Model (DPM) is dynamic but must follow a strict set of rules defining what is possible and impossible for Terminal Data Specifications (EDS) and Plausibility Validations (PV). In particular, the Dynamic Plausibility Model (DPM) must not be based on any Personally Identifiable Information (PII).

[0088] The Endpoint Orchestrator (EO) is operated in an environment whose compliance can be audited, including: - The source code of the Endpoint Orchestrator (EO) can be made public without negative impact on the value of the solution. - The Dynamic Plausibility Model (DPM) is kept secret by the Terminal Orchestrator (TO) but is strictly logged and can be audited for compliance with its rules. For example, an audit could verify that the applied Plausibility Validations (PVs) are not based on any Personally Identifiable Information (PII).

[0089] The Software Agent (SA) running on the Terminal (E) can be subject to a compliance audit; in particular, the source code of the Software Agent (SA) can be made public without negatively impacting the value of the solution.

[0090] Building trust and integrating Participating Terminals

[0091] The supply chain of the software components forming the Software Agent (SA), Terminal Orchestrator (EO) and Terminal Validator (EV) is trusted (see threats and mitigation of "Device Digital Arbiter (EDA) supply chain attacks") and the operation of the Terminal Orchestrator (EO) is trusted (see "operation and auditability of software components")

[0092] The Endpoint Orchestrator (EO) is hosted in a secure and controlled location, such as a Trusted Cloud Computing Platform (TCCP) where not only is the execution environment trusted, but also its execution dependencies.

[0093] Terminal Validators (EV) are a combination of Initial Terminal Validator (EVB) and Participating Terminals (PE), for example only Initial Terminal Validators (EVB) and no Participating Terminals (PE), or one or more Initial Terminal Validators (EVB) and several Participating Terminals (PE).

[0094] Participating Terminals (PTs) can be part of a homogeneous group based on a variety of criteria such as belonging to the same region, organization, the Resources (Rs) they seek to access...

[0095] Initial Terminal Validators (EVBs) are the root of a chain of trust for State (S) certification. An Initial Terminal Validator (EVB) is hosted in a secure and controlled location, such as in a Trusted Cloud Computing Platform (TCCP).

[0096] Eligible Participating Terminals (PTs) are Participating Terminals (PTs) with satisfactory security, such that an initial State (S) representing the Security Posture (SP) of the Terminal (E) has been calculated, deemed sufficient, and certified to ensure secure integration as a Participating Terminal (PT). Eligibility may require additional elements beyond a satisfactory State (S), such as a specific Terminal Operating System (EOS) or a specific execution environment...

[0097] When Terminal Validators (EVs) include Participating Terminals (PEs), the solution provides a means for any Participating Terminal (PE) to enable and disable the State Export (S) and Plausibility Validation (PV) mechanisms. The Software Agent (SA) can be installed before the Participating Terminal (PE) is included in the system, and in this passive state, it calculates a standard Terminal State (S) but without any certification and therefore without communication with other elements of the Terminal Digital Arbiter (EDA). During the integration phase, if other Participating Terminals (PEs) are not available to perform the certification process, the solution uses an Initial Terminal Validator (EVB). When a Participating Terminal (PE) is integrated, it enters an active state and communicates with other components of the Terminal Digital Arbiter (EDA).At any time, a participating terminal (PE) can withdraw from the system and, in that case, return to a passive state.

[0098] Dynamic State Certification (S) and link with Conditional Access Control (CAC)

[0099] The State (S) and Plausibility (P) are calculated dynamically according to: - Changes in the definition of the State Function (SF): the Resource Owner (RO) is expected to standardize its State Function (SF) and such a change will essentially occur in the case where the Terminal (E) tries to access a different Resource (R). - Changes in the Plausibility (P) definition: The Terminal Orchestrator (EO) operating processes are responsible for maintaining an advantage against potential attackers and are therefore expected to update Plausibility Validations (PV) and Terminal Data Specifications (EDS) frequently. This could potentially be achieved using an approach that randomly implements at least some of these changes for added protection against tampering. - A predefined frequency compatible with the security and dynamic requirements of the architecture, for example, every 5 minutes. - An indication of a possible falsification of the Terminal Validator (EV) that participated in calculating the Plausibility (P) of a given State (S) of a Terminal (E). For example, when the Plausibility (P) of the State (S) of the Participating Terminal (PE) as Terminal Validator (EV) for Terminal (E) becomes FALSE.

[0100] When State (S) represents the security posture of Terminal (E), State (S) and Plausibility (P) can be used to grant or deny access to enterprise resources using an external Conditional Access Control (CAC) mechanism, controlled by the Resource Owner (RO). - Such as Microsoft Azure AD Conditional Access Control or Microsoft Defender for Cloud Apps, Google Context Aware Access or the use of a device client certificate in addition to user authentication. - Plausibility (P) has a default value of "not plausible": State (S) will be invalidated, triggering for example a refusal of access to company content in case of doubt with State (S) via Plausibility (P). - Using the following algorithm: ■ During integration into the solution, a device client certificate is generated and associated with the device's unique identity. The Root Certification Authority (CA) of the certificate is configured in Conditional Access Control (CAC). ■ When the user wants to access the Resource (R), he explicitly presents his certificate. Conditional access is configured as follows: If supported by Conditional Access Control (CAC), the State (S) is exported by the Server (B) to the Conditional Access Control (CAC) as a custom parameter for use with Conditional Access Control (CAC) rules (such as the device health attribute as defined in Microsoft Endpoint Manager). By default, the Server (B) uses dynamic revocation and reissuance of the certificate to control access.

[0101] Solution threat model and associated mitigations

[0102] Threats and mitigation of “terminal attacks”

[0103] We define "terminal attacks" as the possible exploitation of security vulnerabilities in the Terminal (E) by an attacker for the purpose of compromising the Terminal (E) without being noticed by the Digital Terminal Arbiter (EDA), i.e. without a negative impact on the calculation of the State (S).

[0104] One possible attack consists of altering any System Element (SE) involved in calculating the State (S) to make (S) inaccurate and allow unauthorized access from the Terminal (E) to the Resource (R). We mitigate this by: - by verifying the integrity of the Terminal Operating System (EOS), using the Apple attestation service for macOS for example. - by verifying the integrity of the software binaries associated with the System Elements (SE), using a remote binary attestation for example.

[0105] Another possible attack involves altering System Elements (SEs) without affecting the integrity of the software binaries associated with the System Elements (SEs) or the Terminal Operating System (EOS), for example, by killing the process of a given System Element (SE) or by maliciously configuring the System Element (SE). We mitigate this by verifying the ability of the System Elements (SEs) to function normally, for example, by checking the System Element (SE) logs to determine normal activity, or by injecting controlled test loads into the System Elements (SEs) and verifying the expected outputs.

[0106] Threats and mitigation of "Terminal Digital Arbitrator (EDA) security attacks"

[0107] We define "Terminal Digital Arbiter (EDA) security attacks" as the possible exploitation of Terminal Digital Arbiter (EDA) security vulnerabilities by an attacker for the purpose of unauthorized access to a Resource (R) using the forgery of Terminal Digital Arbiter (EDA) components.

[0108] One possible attack involves compromising the Terminal (E) before the installation of the Software Agent (SA) associated with the Terminal Digital Arbiter (EDA). We mitigate this by integrating the Terminal (E) in a protected manner, for example, by requiring a sufficient Security Posture (SP) defined by a State (S) to complete integration, or by requiring remote attestation of the Terminal Operating System (EOS) before installing the Software Agent (SA).

[0109] One possible attack involves altering the Software Agent (SA) to always expose a certain State (S) to the Server (B). We mitigate this by verifying the integrity of the Software Agent (SA) binaries using signatures, by obfuscating the code responsible for calculating State (S), by validating the integrity of the State (S) calculation using techniques such as flow control attestation, and by implementing other tamper protections / detections in the application such as: - Prevention of score falsification in memory ("Immutability"): the score in memory is obscured / encrypted (represented in memory not as a numerical value but as a complex structure) - The use of secure system enclaves (hardware-based if possible) such as ARM TrustZone when available - Use of Terminal Operating System (EOS) kernel calls or Terminal Operating System (EOS) kernel modules if necessary

[0110] Another possible attack involves disabling the Software Agent (SA) and falsifying the export of the Software Agent (SA) from the State (S) to the Server (B). We mitigate this by using known techniques that prevent replay attacks and enable resistance to Terminal (E) spoofing, for example, by using a Cryptographic Data Nonce (EDN) as proposed above.

[0111] Another possible attack involves compromising the Initial Terminal Validator (EVB) to bypass Plausibility Validations (PV) and falsify Plausibility (P). We mitigate this by having the Initial Terminal Validator (EVB) under a strictly secure and auditable operation.

[0112] Another possible attack involves compromising a given Terminal Validator (EV) to bypass Plausibility Validations (PV) and falsify the plausibility (PV). We mitigate this by using multiple redundant Terminal Validators (EVs) to perform a given Plausibility Validation (PV) and verifying the consistency of the different results. Furthermore, when the Terminal Validator (EV) is a Participating Terminal (PE) whose Security Posture (SP) was previously validated via a State (S), and subsequently shows signs of compromise (the Plausibility (P) is FALSE), we mark it as dangerous and force the revalidation of the associated Security Posture (SP).

[0113] Threats and mitigation of "Terminal Digital Arbitrator (EDA) data attacks"

[0114] We define "Terminal Digital Arbiter (EDA) data attacks" as the possible exploitation of Terminal Digital Arbiter (EDA) security vulnerabilities by an attacker for the purpose of unauthorized access to Terminal Data (ED).

[0115] One possible attack involves reading the Terminal Data (ED) sent to the Participating Terminals (PE). We mitigate this by exporting only the Terminal Data (ED) in encrypted form. We further mitigate this by dividing the Terminal Data (ED) into multiple elements distributed across multiple Participating Terminals (PE).

[0116] Another possible attack involves taking control of the Terminal Orchestrator (TO) to hijack Plausibility Validations (PVs) by using parameters that allow the extraction of unauthorized information such as Personally Identifiable Information (PII). We mitigate this by implementing a mechanism that logs all parameters or artifacts associated with Plausibility Validations (PVs).

[0117] Threats and mitigation of "Terminal Digital Arbitrator (EDA) supply chain attacks"

[0118] We define "Terminal Digital Arbiter (EDA) supply chain attacks" as a breach in the process of creating and publishing one of the critical components of the Terminal Digital Arbiter (EDA), in particular the Terminal-running Software Agent (SA), the Terminal Initial Validator (EVB) and the Terminal Orchestrator (EO).

[0119] One possible attack involves compromising the source code of the Software Agent (SA), the Terminal Orchestrator (EO), or the Initial Terminal Validator (EVB), or their dependencies. We mitigate this by using strict control over code contributions and a modern system for monitoring dependency threats, such as the one provided by the GitHub Enterprise solution.

[0120] Another possible attack involves compromising the delivery of the Software Agent (SA) to the terminals (E). We mitigate this by leveraging secure distribution such as with Apple's Appstore and / or download spoofing prevention techniques, and / or by leveraging remote application attestation when available, such as with the Apple App Attest service.

[0121] Another possible attack involves compromising updates to the Terminal Orchestrator (EO) or Initial Terminal Validator (EVB) binary. We mitigate this by having the Terminal Orchestrator (EO) and the Initial Terminal Validator (EVB) under a strictly secure and auditable operating process.

[0122] Other embodiments not described or illustrated may be implemented within the scope of the invention, which is defined by the set of claims. Furthermore, the technical features of the different embodiments may be combined, in whole or in part. Thus, the method and systems can be adapted to the specific requirements of the application.

[0123] GLOSSARY OF TERMS

[0124] (B) Server

[0125] (CAC) Conditional Access Control

[0126] (DPM) Dynamic Plausibility Model

[0127] (E) Terminal

[0128] (ED) Terminal Data

[0129] (EDN) Cryptographic Data Nonce

[0130] (EDS) Terminal Data Specifications

[0131] (EDA) Digital Terminal Arbiter

[0132] (EO) Terminal Orchestrator

[0133] (EOS) Terminal Operating System

[0134] (EU) Terminal User

[0135] (EV) Terminal Validator

[0136] (EVB) Initial Terminal Validator

[0137] (H) Host

[0138] (OR) Resource Owner

[0139] (PE) Participating Terminal

[0140] (PII) Personally Identifiable Information

[0141] (P) Plausibility

[0142] (PF) Plausibility Function

[0143] (PVj) Plausibility Validations

[0144] (R) Resource

[0145] (SA) Software Agent

[0146] (S) State

[0147] (SE) System Elements

[0148] (SF) State Function

[0149] (SP) Safety Posture

[0150] (SPN) Cryptographic Posture Nonce

[0151] (SVi) State Validations

[0152] (TCCP) Trusted Cloud Computing Platform

[0153] (TP) Trusted Third Party

[0154] (UEM) Unified Endpoint Management

[0155] (VCH) Validation Calculation History

Claims

1. Demands A method for remotely certifying the State (S) of a Terminal (E) from a Server (B), involving a Terminal Orchestrator (EO) and at least one Terminal Validator (EV) to attest to the Plausibility (P) of the State (S), where: • The Terminal Validator(s) (EV) are distinct from the Terminal Orchestrator (EO), • the State (S) is based on a series of State Validations (SVi) and a State Function (SF), such that S = SF (SVi), • the state (S) is known to the Server (B) and the Terminal (E), • The State Function (SF) is known to the Server (B) and the Terminal (E), • The State Validation Series (SVI) are unknown to the Server (B) but known to the Terminal (E), and in which the process includes a step of verifying the Plausibility (P) of the State (S) with the following conditions: • Plausibility (P) represents an analysis of information from the Terminal (E) allowing verification of the accuracy of the State (S), • Plausibility (P) is known to the Server (B) via the Terminal Orchestrator (EO), • Plausibility (P) is based on a series of Plausibility Validations (PVj) and a Plausibility Function (PF), such that P = PF(PVj), • The Plausibility Function (PF) and Plausibility Validations (PVj) are updated dynamically, • The Plausibility Function (PF) and Plausibility Validations (PVj) are unknown to the Server (B), to protect the confidentiality of the Terminal (E), • The Plausibility Function (PF) is unknown to the Terminal (E), to make it difficult to falsify the Plausibility (P), • The Plausibility Function (PF) is calculated by the Terminal Orchestrator (EO), • Plausibility Validations (PVj) are calculated by the Terminal Validator(s) (EV) on the basis of a series of Terminal Data (ED) unknown to any component of the system except the Terminal (E).

2. A method according to claim 1, wherein the Terminal Validator(s) (EV) is composed of one or more Participating Terminals (PE) orchestrated by the Terminal Orchestrator (EO), whose State (S) has been previously certified by the method of claim 1.

3. A method according to any one of claims 1 or 2, wherein the Plausibility Function (PF) and the Plausibility Validations (PVj) are kept secret by the Terminal Orchestrator (EO) but can be audited for their compliance with Terminal (E) confidentiality.

4. A method according to any one of claims 1 to 3, wherein the Plausibility Function (PF) and the Plausibility Validations (PVj) are dynamically defined by human operators and / or software components.

5. A method according to any one of claims 1 to 4, wherein the Plausibility Validations (PVj) are calculated using, on the one hand, a series of Terminal Data (EDj) captured according to a series of Terminal Data Specifications (EDSj) on the Terminal (E) and, on the other hand, a series of parameters (PAk) known only to the Terminal Orchestrator (EO) to make it difficult to falsify the Plausibility (P), wherein: • PVj = PFj (EDj, PAk), • the series of Terminal Data Specifications (EDSj) and the series of Parameters (PAk) are available for a confidentiality compliance audit of the Terminal (E).

6. A method according to claim 5, wherein: • the Terminal Validator (EV) has access only to an encrypted version of the Terminal Data (EDj) and an encrypted version of the Parameter series (PAk) and • the Plausibility Function PFj (EDj, PAk) is a function supporting operations on encrypted parameters such as those based on totally homomorphic encryption or multipartite computation.

7. Method according to claim 6, wherein the Plausibility Validations PVj = PF (EDj, PAk) and the Plausibility Function (PF) is a function returning a Result (RE) and a Validation Calculation History (VCH) which can be used for a stateful calculation of the Plausibility Function (PF) where the validation calculation history (VCH) is sent to the Terminal Orchestrator (EO) and aggregated to the parameter series (PAk) in an encrypted form readable only by the Terminal Validator(s) (EV).

8. A method according to claim 7, wherein the Plausibility Validations PVj = PF (EDj, PAk) and the Plausibility Function (PF) is a function enabling pattern filtering preserving the confidentiality of Terminal Data (EDj), and / or the parameter series (PAk) are patterns to be matched, where the Terminal Validator(s) (EV) have access only to an encrypted version of Terminal Data (EDj) and an encrypted version of the parameter series (Pak).

9. A system for remotely certifying the State (S) of a Terminal (E) from a Server (B), the system comprising a Terminal Orchestrator (EO) and at least one Terminal Validator (EV) to attest to the Plausibility (P) of the State (S), wherein: • the Terminal Validator(s) (EV) are distinct from the Terminal Orchestrator (EO), • the State (S) is based on a series of State Validations (SVi) and a State Function (SF), such that S = SF(SVi), • the State (S) is known to the Server (B) and the Terminal (E), • the State Function (SF) is known to the Server (B) and the Terminal (E), • the series of State Validations (SVi) are unknown to the Server (B) but known to the Terminal (E),and in which the system is configured to verify the Plausibility (P) of the State (S) with the following conditions: • the Plausibility (P) represents an analysis of the information in the Terminal (E) which supports the correctness of the State (S), • the Plausibility (P) is known to the Server (B) via the Terminal Orchestrator (EO), • the Plausibility (P) is based on a series of Plausibility Validations (PVj) and a Plausibility Function (PF), such that P = PF (PVj), The Plausibility Function (PF) and Plausibility Validations (PVj) are updated dynamically; the Plausibility Function (PF) and Plausibility Validations (PVj) are unknown to the Server (B), to protect the confidentiality of the Terminal (E); the Plausibility Function (PF) is unknown to the Terminal (E), to make it difficult to falsify the Plausibility (P). The Plausibility Function (PF) is calculated by the Terminal Orchestrator (EO), Plausibility Validations (PVj) are calculated by the one or more Terminal Validator(s) (EV) on the basis of a series of Terminal Data (ED) unknown to any component of the system except the Terminal (E).

Images