Apparatus and method for decision making

Abstract

The present invention relates to a decision process. In order to provide an improved decision process with reduced computational complexity, the present invention proposes a PEP. The PEP is configured to receive a request of an entity, generate a first message comprising a challenge and metadata of the request, encrypt the first message using a public key of the entity and a public key of each of a plurality of PDPs, send the encrypted first message over a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at the PEP comprising the plurality of PDPs and ends at the entity, receive a signature on a second message from the entity, wherein the signature on the second message represents one or more decisions on the challenge proposed by the plurality of PDPs, and make a final decision based on the validity of the signature on the second message. The present invention also proposes a PDP and an entity.

Description

Technical Field

[0001] This invention generally relates to decision-making processes, and more particularly to decision-making in distributed systems, i.e., distributed decision-making processes. This invention proposes apparatus and methods for improved distributed decision-making processes. Background Technology

[0002] The decision-making process generally consists of three phases: making a decision request, making a decision, and executing the decision. In a distributed decision-making system, these phases are performed by separate entities. Specifically, the policy decision point (PDP) makes the decision, while the policy enforcement point (PEP) executes it. Access control decisions are among the most common decisions that utilize the decision-making process. Access control can be defined as "security functions that protect shared resources from unauthorized access." Shared resources are data that implements some form of access control. Important issues in distributed access control design include how to express and protect requests and decisions, and how to verify decisions. Cryptographic methods such as encryption and digital signatures are commonly used to protect requests and decisions, and to verify decisions.

[0003] Sometimes, PDPs (Programmable Providers) make incorrect decisions, allowing unauthorized parties to gain access. An attacker might have gained control of the PDP, thus influencing its decisions. Alternatively, the PDP's visibility might be limited; for example, it might lack access to information that could be crucial to the decision-making process. For instance, a simple electronic door lock in an end-user's home might not be able to authenticate who unlocks it, relying instead on proof of ownership of the token (key) (e.g., a signature on a random challenge). Meanwhile, one or more intrusion detection sensors in the home network might have detected that the person holding the key is actually a thief who has successfully stolen the key from the homeowner. Therefore, when suitable device or software entities are available, involving multiple PDPs in decision-making to improve security makes sense. With the continued rapid growth in the number of deployed Internet of Things (IoT) devices, an increasing number of potential PDPs are becoming available.

[0004] The latest access control methods are based on common access control or authorization frameworks, such as OAuth, XACML, SAML, and OpenID. Specifically, OAuth refers to the authorization framework defined in RFC 6749. One problem with all these frameworks is that they only support a single PDP. XACML is an Extensible Access Control Markup Language, a policy language and access control architecture. SAML is a Security Assertion Markup Language, an open standard for exchanging authentication and authorization data between parties. OpenID is a standard for decentralized authentication. To support multiple PDPs, existing single PDP decision and execution processes can be executed multiple times, once per PDP. However, scalability is poor; that is, the computational complexity and communication requirements of the decision and execution processes are high. Many potential PDPs are small devices, such as sensors, which can only perform the required cryptographic operations slowly. Furthermore, network latency is high in many scenarios. Therefore, an improved distributed decision-making method is needed. Summary of the Invention

[0005] In view of the above limitations, embodiments of the present invention aim to introduce an improved technical solution for distributed decision-making in an efficient and flexible manner. Specifically, one objective is to provide a technical solution that reduces computational complexity and communication requirements. Another objective is to reduce network latency during the decision-making process. The present invention also aims to enable the PEP to reside in different networks from one or more PDPs.

[0006] The above objectives are achieved by the embodiments provided in the appended independent claims. Advantageous implementations of these embodiments are further defined in the dependent claims.

[0007] A first aspect of the present invention provides a PEP for distributed decision-making. The PEP is configured to: receive a request from an entity; generate a first message including a challenge to the request and metadata, wherein the metadata represents the request and a plurality of PDPs; encrypt the first message using the public key of the entity and the public keys of the respective PDPs; transmit the encrypted first message via multi-hop unidirectional communication, wherein the multi-hop unidirectional communication begins at the PEP including the plurality of PDPs and ends at the entity; receive a signature on a second message from the entity, wherein the signature on the second message represents one or more decisions regarding the challenge proposed by the plurality of PDPs; and make a final decision based on the validity of the signature on the second message.

[0008] This invention provides a technical solution that requires only a single, mutually authenticated connection between the client (i.e., the entity) and the PEP, with public-key encryption used for the remainder of the communication. This avoids significant overhead. Furthermore, this invention proposes using a unidirectional chained communication. This means that there is no interaction between the previous and next hops in the unidirectional communication chain.

[0009] In one implementation of the first aspect, sending the encrypted first message via multi-hop unidirectional communication includes: sending the encrypted first message to the first hop PDP of the multi-hop unidirectional communication.

[0010] In one implementation of the first aspect, sending the encrypted first message to the first hop PDP of the multi-hop unidirectional communication includes: sending the encrypted first message together with an indication of the first hop PDP of the multi-hop unidirectional communication to the entity; causing the entity to forward the encrypted first message to the first hop PDP through the multi-hop unidirectional communication.

[0011] Alternatively, the PEP can first send an encrypted message to the client (i.e., the entity), and the client then forwards the encrypted first message to the first-hop PDP. The advantage of this is that the PEP does not need to be able to communicate directly with the PDP. It is worth noting that this can significantly improve the security of the PEP.

[0012] In one implementation of the first aspect, the request is received from the entity via a secure channel.

[0013] In one implementation of the first aspect, the secure channel between the PEP and the entity includes a transport layer security (TLS) connection, wherein the request is received from the entity and the encrypted first message is sent to the entity via a TLS handshake message.

[0014] Alternatively, the present invention can be integrated into the earliest possible stage of the TLS 1.3 handshake.

[0015] In one implementation of the first aspect, encrypting the first message includes: using the entity's public key, and then sequentially using the public keys of the plurality of PDPs, recursively wrapping the challenge and the metadata.

[0016] It's worth noting that such a process can create an "onion-like" recursive wrapper, similar to the wrapper used in onion routing. Therefore, each PDP is able to remove a layer of protection from the message and inspect the metadata. If the PDP approves the request, it sends the message to the next PDP (removing a layer of protection).

[0017] In one implementation of the first aspect, the number of PDPs in the plurality of PDPs is k, where k is a positive integer greater than 1; the recursive packaging includes (k+1) layers of packaging, and the recursive packaging of the challenge and the metadata includes: encrypting the challenge and the metadata using the entity's public key to obtain a first packaging layer; encrypting the nth layer of packaging using the public key of PDP(k+1–n) to obtain the (n+1)th layer of packaging, where n is a positive integer, 1≤n≤k, and PDP(k+1–n) represents the (k+1–n)th PDP in the plurality of PDPs of the multi-hop unidirectional communication.

[0018] Specifically, PEP first uses the entity's public key, then the public key of PDP k, and finally the public key of PDP(k–1), etc., to encrypt the challenge and metadata. The final layer of wrapping is added using the public key of the first-hop PDP.

[0019] In one implementation of the first aspect, the recursive wrapper uses one of the following encryption schemes: elliptic curve integrated encryption scheme (ECIES); Rivest–Shamir–Adleman (RSA) encryption; pre-shared key (PSK) encryption; or identity-based hybrid encryption.

[0020] ECIES stands for Public Key Certified Encryption Scheme. It uses a key-derivation function (KDF) to derive individual MAC and symmetric encryption keys from an Elliptic-curve Diffie-Hellman (ECDH) shared key. ECIES operations can be divided into two stages. In the first stage, a new ECDH key pair is generated locally, and a shared key is computed using its private ECDH key and a remote public ECDH key. The symmetric encryption or decryption key is then derived locally from this shared key. In the second stage, the actual encryption or decryption operation is performed using the symmetric key derived in the first stage. Standard ECIES operations always consist of two stages.

[0021] PSK stands for Shared Key, which is shared in advance by both parties using a secure channel before being used. Identity-based encryption is a type of public-key encryption where a user generates a public key from a known unique identifier, and a trusted third-party server calculates the corresponding private key based on that public key. Therefore, identity-based encryption does not require a prior secure bootstrapping phase.

[0022] In one implementation of the first aspect, the ECIES is used for recursive wrapping, and the PEP is further used for: obtaining the public key of the entity and the public keys of the plurality of PDPs, wherein the public key of the entity and the public keys of the plurality of PDPs are predetermined.

[0023] In the static ECIES variant used in this embodiment of the invention, the first phase of the ECIES operation is performed in advance, for example, during the bootstrapping phase. Therefore, at the start of the run phase, the PEP and each PDP already have a separate pair of symmetric public keys. This significantly reduces the time required to perform each ECIES operation. Furthermore, static ECIES provides implicit sender and receiver authentication for each message. The advantage of using static ECIES instead of pre-shared keys (i.e., pre-distributed symmetric keys) is that a confidential channel is not required during the bootstrapping process; that is, a physical channel is sufficient. This makes the bootstrapping phase much simpler than PSK encryption.

[0024] In one implementation of the first aspect, the metadata further represents the order of the plurality of PDPs, which are hops in the multi-hop unidirectional communication.

[0025] In one implementation of the first aspect, encrypting the first message includes: encrypting the challenge using the entity's public key; dividing the encrypted challenge into k parts, where k is the number of PDPs among the plurality of PDPs, k is a positive integer greater than 1, and each part in the k parts corresponds to one of the k PDPs; and encrypting each of the k parts and the metadata using the public key of the corresponding PDP.

[0026] This invention proposes an alternative method in which PEP does not use recursive wrapping, but instead divides the challenge into k parts and encrypts each part separately using the PDP public key. Each plaintext includes a copy of the metadata. Therefore, each PDP receives a copy of the metadata and can remove the wrapping from a part of the challenge. The advantage of this variant is that it enables dynamic routing, improving network performance.

[0027] In one implementation of the first aspect, making a final decision based on the validity of the signature on the second message includes: approving the request if the signature on the second message is determined to be valid; or rejecting the request if the signature on the second message is determined to be invalid.

[0028] In one implementation of the first aspect, the PEP is used to: determine that the signature on the second message is valid if the signature of the second message matches the challenge; or determine that the signature on the second message is invalid if the signature on the second message does not match the challenge.

[0029] In one implementation of the first aspect, the number of PDPs in the plurality of PDPs is k, where k is a positive integer greater than 1, the challenge includes k PDP-specific challenges, each PDP-specific challenge corresponds to one of the k PDPs, and generating the first message includes: generating PDP-specific challenges for each of the k PDPs.

[0030] PEP may also create k challenges instead of a single challenge.

[0031] In one implementation of the first aspect, encrypting the first message includes: first using the entity's public key, and then using the corresponding PDP's public key to encrypt each PDP-specific challenge and the metadata to obtain an encrypted PDP-specific message, wherein the encrypted first message includes k encrypted PDP-specific messages.

[0032] PEP can first use the client's public key, and then encrypt each challenge using the corresponding PDP's public key. Therefore, it may require the client to sign each challenge individually.

[0033] In one implementation of the first aspect, the PEP is used to: determine the decision of at least n PDPs among the k PDPs; if at least n of the k PDPs approve the request, determine that the signature on the second message is valid; or, if less than n of the plurality of PDPs approve the request, determine that the signature on the second message is invalid, where n is a positive integer less than k.

[0034] It is worth noting that by creating separate challenges that are independently coded for each challenge, the present invention also enables the PEP to approve a request if at least n of the k signatures are valid.

[0035] In one implementation of the first aspect, the signature on the second message includes k signatures on k PDP-specific messages, each signature on the PDP-specific messages corresponding to one of the k PDPs, and the decision to determine at least n PDPs among the k PDPs includes: if the signature on the PDP-specific message corresponding to a PDP matches the PDP-specific challenge corresponding to the PDP, determining that the PDP approves the request; or if the signature on the PDP-specific message corresponding to a PDP does not match the PDP-specific challenge corresponding to the PDP, determining that the PDP rejects the request.

[0036] In one implementation of the first aspect, the metadata represents the identifier of each of the plurality of PDPs.

[0037] In one implementation of the first aspect, the PEP and the plurality of PDPs are located in different networks.

[0038] As mentioned earlier, if the PEP uses an entity as a relay for forwarding encrypted messages, the PEP does not need to be on the same network as the PDP. This can be a very useful feature in practice. For example, to prevent attacks, a security lock (e.g., the PEP) may not have internet access, and the only way to communicate with the security lock is using near-field communication (NFC) or Bluetooth. For example, the security lock should be opened by placing a specific smartphone on it.

[0039] A second aspect of the present invention provides a PDP. The PDP is configured to: receive a first encrypted message via multi-hop unidirectional communication, wherein the multi-hop unidirectional communication originates from a PEP comprising multiple PDPs and terminates at an entity, the first encrypted message including an encrypted challenge to a request from the entity and encrypted metadata, the metadata representing the request and the multiple PDPs; decrypt the first encrypted message using the private key of the PDP to generate a first decrypted message; obtain the metadata from the first decrypted message; make a decision on whether to approve the request; and further provide a third message representing the decision to the next hop via the multi-hop unidirectional communication.

[0040] The present invention also proposes a PDP that can operate accordingly, as described in the first aspect and its implementation.

[0041] In one implementation of the second aspect, receiving the first encrypted message via multi-hop unidirectional communication includes: receiving the first encrypted message from the entity, wherein the first encrypted message is forwarded by the entity from the PEP.

[0042] In one implementation of the second aspect, if the request is granted, the third message includes the first decryption message; or if the request is denied, the third message includes a spam message, wherein the spam message is generated by the PDP and is predicted to have the same length as the first decryption message.

[0043] In one implementation of the second aspect, the metadata further represents the order of the plurality of PDPs, which are hops in the multi-hop unidirectional communication.

[0044] In one implementation of the second aspect, the first encrypted message includes a first part dedicated to the PDP and a second part for other PDPs among the plurality of PDPs; the decryption of the first encrypted message includes: decrypting the first part of the first encrypted message to obtain a first part of the first decrypted message, wherein the first decrypted message includes the first part of the first decrypted message and the second part of the first encrypted message.

[0045] In one implementation of the second aspect, providing a third message representing the decision to the next hop via the multi-hop unidirectional communication includes: sending the first decryption message and a decision indicator representing whether the request is approved by the PDP to the next hop via the multi-hop unidirectional communication.

[0046] A third aspect of the invention provides an entity. The entity is configured to: send a request to a PEP; receive an encrypted message from a PDP via multi-hop unidirectional communication, wherein the multi-hop unidirectional communication originates in a PEP comprising multiple PDPs and terminates at the entity; decrypt the encrypted message to obtain a decrypted message; sign the decrypted message using the entity's private key; send the signature on the decrypted message to the PEP; and, if the signature is verified by the PEP, receive approval for the request.

[0047] This invention also proposes an entity, namely, a client that makes a request. This entity can operate accordingly, as described in the first aspect and its implementation.

[0048] In one implementation of the third aspect, the number of PDPs in the plurality of PDPs is k, where k is a positive integer greater than 1, the encrypted message includes k parts, each part corresponding to one of the k PDPs, and the decryption of the encrypted message to obtain the decrypted message includes: combining the k parts of the encrypted message; and decrypting the combined k parts to obtain the decrypted message.

[0049] In one implementation of the third aspect, the number of PDPs in the plurality of PDPs is k, where k is a positive integer greater than 1, the encrypted message includes k parts, each part corresponding to one of the k PDPs, and the decryption of the encrypted message to obtain the decrypted message includes: decrypting each of the k parts to obtain a PDP-specific decryption message.

[0050] In one implementation of the third aspect, signing the decrypted message includes: signing each PDP-specific decrypted message using the entity's private key, wherein the signatures on the decrypted message include k signatures on k PDP-specific decrypted messages.

[0051] A fourth aspect of the invention provides a method for distributed decision-making performed by a PEP (Programmable Execution Platform). The method includes: receiving a request from an entity; generating a first message including a challenge and metadata of the request, wherein the metadata represents the request and a plurality of PDPs; encrypting the first message using the public key of the entity and the public keys of the respective PDPs; transmitting the encrypted first message via multi-hop unidirectional communication, wherein the multi-hop unidirectional communication originates at the PEP including the plurality of PDPs and terminates at the entity; receiving a signature on a second message from the entity, wherein the signature on the second message represents one or more decisions regarding the challenge proposed by the plurality of PDPs; and making a final decision based on the validity of the signature on the second message.

[0052] The implementation of the method provided in the fourth aspect can correspond to the implementation of the PEP provided in the first aspect above. The method provided in the fourth aspect and its implementation achieves the same advantages and effects as the PEP provided in the first aspect and its implementation above.

[0053] A fifth aspect of the invention provides a method performed by a PDP. The method includes: receiving a first encrypted message via multi-hop unidirectional communication, wherein the multi-hop unidirectional communication originates in a PEP comprising a plurality of PDPs and terminates at an entity, the first encrypted message including an encrypted challenge to a request from the entity and encrypted metadata, the metadata representing the request and the plurality of PDPs; decrypting the first encrypted message using the private key of the PDPs to generate a first decrypted message; obtaining the metadata from the first decrypted message; making a decision on whether to approve the request; and further providing a third message representing the decision to the next hop via the multi-hop unidirectional communication.

[0054] The method provided in the fifth aspect can be implemented in a manner corresponding to the PDP implementation provided in the second aspect above. The method provided in the fifth aspect and its implementation achieves the same advantages and effects as the PDP provided in the second aspect and its implementation above.

[0055] A sixth aspect of the invention provides a method performed by an entity. The method includes: sending a request to a PEP; receiving an encrypted message from a PDP via multi-hop unidirectional communication, wherein the multi-hop unidirectional communication originates in a PEP comprising multiple PDPs and terminates at the entity; decrypting the encrypted message to obtain a decrypted message; signing the decrypted message using the entity's private key; sending the signature on the decrypted message to the PEP; and receiving approval of the request if the signature is verified by the PEP.

[0056] A seventh aspect of the present invention provides a computer program. The computer program includes program code, which, when implemented on a processor, is used to execute the methods provided by the fourth aspect and any implementation thereof, the fifth aspect and any implementation thereof, and the sixth aspect and any implementation thereof.

[0057] It should be noted that all devices, elements, units, and modules described in this application can be implemented in software or hardware elements or any combination thereof. All steps performed by the various entities described in this application, and the functions to be performed by the various entities described, are intended to refer to the respective entities performing the respective steps and functions. Although the specific functions or steps to be performed by external entities are not reflected in the detailed description of the specific elements of the entities performing the specific steps or functions in the following description of specific embodiments, those skilled in the art will understand that these methods and functions can be implemented by the corresponding hardware or software elements or any combination thereof. Attached Figure Description

[0058] The following detailed description of specific embodiments, taken in conjunction with the accompanying drawings, explains various aspects and implementations of the present invention.

[0059] Figure 1 The signaling between the PEP and multiple PDPs provided by conventional technical solution 1 is shown.

[0060] Figure 2 The signaling between the PEP and multiple PDPs provided by conventional technical solution 2 is shown.

[0061] Figure 3 A PEP provided in one embodiment of the present invention is shown.

[0062] Figure 4The signaling between a PEP and multiple PDPs provided in one embodiment of the present invention is illustrated.

[0063] Figure 5 A PEP provided in one embodiment of the present invention is shown.

[0064] Figure 6 The signaling between a PEP and multiple PDPs provided in one embodiment of the present invention is illustrated.

[0065] Figure 7 The signaling between a PEP and multiple PDPs provided in one embodiment of the present invention is illustrated.

[0066] Figure 8 This illustrates a standard ECIES hybrid encryption provided by an embodiment of the present invention.

[0067] Figure 9 This illustrates a static ECIES hybrid encryption provided by an embodiment of the present invention.

[0068] Figure 10 This illustrates static ECIES decryption provided by an embodiment of the present invention.

[0069] Figure 11 The signaling between a PEP and multiple PDPs provided in one embodiment of the present invention is illustrated.

[0070] Figure 12 The signaling between a PEP and multiple PDPs provided in one embodiment of the present invention is illustrated.

[0071] Figure 13 A PDP provided in one embodiment of the present invention is shown.

[0072] Figure 14 An entity provided by one embodiment of the present invention is shown.

[0073] Figure 15 The present invention provides a method according to one embodiment.

[0074] Figure 16 The present invention provides a method according to one embodiment.

[0075] Figure 17 The present invention provides a method according to one embodiment.

[0076] Figure 18 The number of public key operations provided in one embodiment of the present invention is shown.

[0077] Figure 19 The number of public key operations provided by conventional technical solution 1 is shown.

[0078] Figure 20The number of public key operations provided by conventional technical solution 2 is shown. Detailed Implementation

[0079] Illustrative embodiments of methods and apparatus for distributed decision-making in communication systems are described with reference to the accompanying drawings. While detailed examples of possible implementations are provided herein, it should be noted that these details are exemplary and in no way limit the scope of this application.

[0080] Furthermore, one embodiment / example may refer to multiple other embodiments / examples. For example, any descriptions mentioned in one embodiment / example, including but not limited to terms, elements, processes, explanations, and / or technical advantages, are applicable to multiple other embodiments / examples.

[0081] Before disclosing specific embodiments in detail, some relevant requirements and assumptions are first described here.

[0082] The security protocol needs to explicitly specify the type of security provided. Each distributed access control method can consider the following basic security requirements (SR):

[0083] •SR1. Confidentiality: Unauthorized parties should not be able to see the requested content, decisions, and resources themselves.

[0084] •SR2. Integrity: No third party can modify the request or decision.

[0085] • SR3. Access Control Security: Only the PEP and the PDP selected by the PEP can influence decisions. A true copy of the relevant portion of the request needs to be provided to the PDP so that the PDP can make the correct decision based on its policy.

[0086] •SR4. Authentication: It is impossible for an attacker to impersonate a legitimate PDP or PEP; the PEP must be able to authenticate each PDP and client, and the PDP must be able to authenticate the PEP.

[0087] The final requirement is typically met by distributing the public key in an X.509 certificate. The certificate includes the public key and an identifier of the key owner, and is signed by a trusted third party (i.e., a Certificate Authority (CA)). Therefore, a valid certificate represents a genuine binding between the public key and its owner. Certificates can be distributed during protocol execution (such as in TLS) or prior to the secure bootstrap phase. The bootstrap phase requires a real communication channel but not confidentiality.

[0088] In this invention, it is assumed that the PEP is trusted, but both the PDP and the client may be under the control of an attacker. Furthermore, it is assumed that the previous bootstrapping phase has been completed.

[0089] The fields of consensus protocols and Byzantine fault tolerance also consider distributed, multi-agent decision-making problems. In these cases, agents (PDPs) must make collective decisions autonomously under the constraint that some agents may be unreliable. A key difference lies in the multi-PDP access control / authorization problem considered in this document: in the current case, there exists a trusted party, the PEP, which makes the final decision based on the inputs of the PDPs. Therefore, simpler technical solutions can be used, and the technical solutions for consensus or Byzantine fault tolerance are neither efficient nor directly applicable to the problems discussed in this application.

[0090] In blockchain-based decision-making, there is no trusted party (PEP) that makes the final decision. Furthermore, blockchain computations are often very complex and require a large amount of network traffic.

[0091] To introduce this invention, a simple extension of the traditional single PDP access control method (e.g., implemented under the OAuth framework) is first described here:

[0092] 1. The client (requester) sends a request to the PEP through a mutually authenticated TLS 1.3 connection.

[0093] 2. For each PDP:

[0094] • PEP protection request and send to PDP;

[0095] • PDP cancels protection and makes a decision;

[0096] • The PDP protects its response and sends it to the PEP;

[0097] • PEP removes protection and verifies the response.

[0098] 3. If each PDP approves the request, the PEP sends the resource to the client via a TLS connection; otherwise, the PEP may send an error message.

[0099] In this technical solution, the participants (i.e., the client, PEP, and PDP) communicate with each other through separate, mutually authenticated TLS 1.3 connections.

[0100] First, the client (requester) establishes a TLS connection with the PEP to securely send its request. Next, the PEP contacts each PDP in turn via separate TLS connections, providing the request and receiving a confirmation decision. Finally, the PEP sends the requested resource or an error message to the client. This process (referred to as the first traditional technical approach) is as follows: Figure 1 As stated above.

[0101] Figure 1The diagram illustrates the signaling between the PEP and multiple PDPs. Paired, mutually authenticated TLS connections exist between the PEP and the multiple PDPs, directly extending the traditional single-PDP access control method. In this diagram, three PDPs (k=3) are used as an example. A1, A2, and A3 represent the three PDPs, and C represents the client.

[0102] In this example, client C requests access to a protected resource. Client C first establishes a TLS session with the PEP and sends the request to the PEP via a secure channel. The PEP then queries each PDP in turn to approve or deny the request. The PEP does this by establishing paired, mutually authenticated TLS sessions with each PDP. After receiving all decisions, the PEP verifies these decisions and makes a final decision. If the final decision is "approve," the PEP sends the requested resource to the client via the existing TLS connection between the client and the PEP.

[0103] It's easy to see how this approach meets the aforementioned security requirements, as the mutual TLS connection provides endpoint authentication as well as data confidentiality and integrity. For example, implementing the first traditional technical solution within the OAuth framework is quite straightforward.

[0104] The computational cost of this method can be estimated as follows. Assuming each participant has a certificate chain of length 3 (i.e., the subject (e.g., device) certificate, intermediate CA certificate, and root CA certificate), each TLS 1.3 connection requires two signature generation steps (each party must generate and sign a certificate verification message) and four signature verification steps (each party must verify the other party's certificate verification message and certificate chain). This chain is very typical in many cases, especially for IoT devices. To verify this chain, two signature verifications are required (subject certificate and intermediate certificate). Verification of the root CA certificate's signature is not required because it is a self-signed certificate.

[0105] If the number of PDPs is k, then there are a total of 6k signature generation and verification operations, which is the most time-consuming cryptographic operation in almost all protocols. In particular, each PDP requires three such operations. For simplicity, the complexities introduced by the ECDHE key protocol, HKDF, HMAC, and symmetric encryption are ignored. This overhead is considerable, but not as significant as the signature operations themselves.

[0106] It is worth noting that, Figure 1 The technical solution illustrated has very high communication requirements. In addition to the round trip required for the TCP handshake, each TLS 1.3 handshake requires another network round trip before actual data transmission. The amount of data transmitted is also substantial. A typical TLS handshake has an average overhead of approximately 6500 bytes, with client authentication and long certificate chains adding even more overhead.

[0107] Because paired TLS connections are costly, other methods, such as using public-key encryption instead of a secure TLS channel, can significantly reduce encryption operations and network transmissions. Similarly, this approach can be easily implemented as part of any single PDP framework (e.g., OAuth). This approach (referred to as the second traditional technical solution) is as follows: Figure 2 As stated above.

[0108] Figure 2 An example of signaling between a PEP and multiple PDPs encrypted using pairwise public-key cryptography is shown. Figure 1 Similarly, here we take three PDPs (k=3) as an example.

[0109] In the second traditional technical approach, only one mutually authenticated TLS connection exists between the client and the PEP. Communication between the PEP and PDP uses only public-key encryption. The public-key encryption scheme used here can be RSA Optimal Asymmetric Encryption Padding (RSA-OAEP), where RSA refers to public-key cryptography based on integer modular prime multiplication group arithmetic, and RSA-OAEP is a public-key encryption scheme based on RSA (defined in RFC 8017). This significantly reduces computational complexity and the number of transmissions. Each message must be encrypted and decrypted. Therefore, each PDP performs two public-key operations and two private-key operations, or a total of 4k operations, where k is the number of PDPs. Each transmission includes the actual message (request or decision), meaning there are no messages considered as overhead, as in the TLS handshake.

[0110] However, a problem with this approach is that anyone can access the PEP and PDP public keys. Therefore, anyone can create valid messages. This doesn't necessarily mean an attacker can break access controls, but forcing each participant to decrypt the message and send a response significantly increases the attacker's chances of launching denial-of-service attacks and chosen-ciphertext attacks. Essentially, what's missing is the requirement for SR4 (authentication). This requirement can be met by adding a sender's signature to the transmitted message, but this effectively doubles the computational cost.

[0111] It is worth noting that, as mentioned above, traditional multi-PDP access control methods suffer from significant computational complexity and multiple transmissions per PDP. For security reasons, it is beneficial to involve as many PDPs as possible in decision-making. In many scenarios, such as sensor networks, data centers, or homes with a large number of IoT devices, this could potentially mean dozens or hundreds of PDPs. Having a lightweight distributed access control method specifically designed for multiple PDPs and scalability would be extremely useful. A technique that minimizes the number of cryptographic operations and transmissions required per PDP would be particularly valuable.

[0112] Figure 3 This is a schematic diagram of an example of the novel PEP 300. The PEP 300 may include a processing circuitry system (not shown) for performing, conducting, or initiating various operations of the PEP 300 described herein. This processing circuitry system may include hardware and software. The hardware may include analog circuitry systems or digital circuitry systems, or both. The digital circuitry system may include components such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The PEP 300 may also include a storage circuitry system that stores instructions executable by the processor or the processing circuitry system. For example, the storage circuitry system may include a non-transitory storage medium storing executable code. When the executable code is executed by the processor or the processing circuitry system, it causes various operations of the PEP 300 to be performed. In one embodiment, the processing circuitry system includes one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code. When the executable program code is executed by one or more processors, it causes the PEP 300 to perform, conduct, or initiate the operations or methods described herein.

[0113] More specifically, PEP 300 performs the following operations in response to request 301 from receiving entity 310.

[0114] Entity 310 can be Figure 1 and Figure 2 Client C is shown in the diagram, etc. Entity 310 can request PEP 300 to make a decision. For example, entity 310 can request access to a protected resource. Although a method for distributed access control or authorization is discussed herein, the invention is not limited to these fields. In fact, the invention can be used for any distributed decision-making.

[0115] Upon receiving request 301, PEP 300 generates a first message 302 that includes the challenge to request 301 and metadata. The metadata represents request 301 and multiple PDPs 302, 302'. Notably, multiple PDPs 302, 302' can independently identify the request 301 of entity 310.

[0116] PEP 300 encrypts the first message 302 using the public key of entity 310 and the public keys of multiple PDPs 320, 320'. Then, the PEP sends the encrypted first message 303 via multi-hop unidirectional communication. The multi-hop unidirectional communication begins at PEP 300, which includes multiple PDPs 320, 320', and ends at entity 310.

[0117] It should be noted that this multi-hop unidirectional communication differs from traditionally used bidirectional ("paired") communication (such as...). Figure 2 This differs significantly from the second traditional technical solution discussed earlier. It means that there is no interaction between the previous and next hops in a unidirectional communication chain. This can be particularly advantageous in certain scenarios. For example, broadcast communication utilizing the User Datagram Protocol (UDP) can be used instead of connection-based communication to transmit messages in such a multi-hop unidirectional chain.

[0118] Furthermore, PEP 300 is used to receive a signature 304 on a second message from entity 310. The signature 304 on the second message represents one or more decisions regarding challenges raised by multiple PDPs 320, 320'. PEP 300 then makes a final decision based on the validity of the signature 304.

[0119] Optionally, PEP 300 can receive request 301 from entity 310 via a secure channel (e.g., a TLS connection). Therefore, request 301 and encrypted first message 303 can be sent via a TLS handshake message.

[0120] Please note that only one mutually authenticated TLS connection is required between the client (i.e., entity 310) and PEP 300. Public-key encryption can be used for the rest of the communication. Therefore, the significant overhead caused by the (k+1) TLS handshakes in the first conventional computing scheme described above can be avoided, where k is the number of PDPs. This scheme uses unidirectional chained communication, unlike the second conventional scheme which uses bidirectional (“paired”) communication.

[0121] Specifically, PEP 300 can be used to send the encrypted first message 303 to the first-hop PDP 320 in multi-hop unidirectional communication. The first-hop PDP 320 can also process the encrypted first message 303 and forward it to the next-hop PDP 320'. This unidirectional chained communication can be based on the challenge of recursive wrapping.

[0122] Figure 4 The signaling between PEP 300, entity 310, and multiple PDPs 320, 320' provided in a basic variant of the present invention (Example 1) is illustrated. Example 1 is implemented according to a one-way communication and recursive packaging method. It should be noted that client C refers to entity 310, and A1, A2, and A3 all represent PDPs 320 or 320' among the multiple PDPs. In this embodiment, A1 refers to the first-hop PDP 320. These definitions also apply to the following figures.

[0123] like Figure 4 As shown, entity 310 first establishes a mutually authenticated TLS connection with PEP 300, and sends its own request (i.e., ...) through a secure channel. Figure 3 (See Request 301 shown in the diagram). Next, PEP 300 selects the PDPs that wish to participate in the decision-making process. PEP 300 creates a sufficiently long random challenge (i.e., denoted as "c" in the diagram) (in the illustrated example, the challenge is 32 random octets) and metadata describing the request and including identifiers of the participating PDPs. The identifier of PDP 300 can be included so that if each PDP 320 or 320' deems some other PDP untrustworthy, the request can be rejected. PEP 300 first encrypts the challenge and metadata using the public key of entity 310 (i.e., denoted as "C(c)"), then using the public key of PDP k, and finally using the public key of PDP (k–1), etc. The final layer of wrapping is added using the public key of PDP 1 (i.e., the first-hop PDP 320, or A1).

[0124] This process creates an "onion-like" recursive wrapping, similar to the wrapping used in onion routing. In Example 1, the ciphertext is first sent to PDP 1 (i.e., A1), which decrypts the message, checks the metadata, and makes its own decision. If PDP 1 approves the request, it forwards the decrypted message to PDP 2 (i.e., A2), and so on. Finally, the decrypted message is sent to entity 310. If each PDP approves request 301 (i.e., agrees to remove one layer of wrapping and continue sending decrypted messages), only one layer of wrapping remains, which entity 310 can remove using its private key. Therefore, entity 310 can only decrypt the challenge if each PDP 320 or 320' approves the request. Entity 310 then signs the challenge using its private key and sends the signature to PEP 300 using an existing TLS connection. If the signature ( Figure 3 If the signature 304 shown in the diagram is verified to be correct, then PEP 300 approves request 301 and sends the resource to entity 310.

[0125] Optionally, PEP 300 can also first send an encrypted message 303 to the client (i.e., entity 310), and the client then forwards the encrypted first message 303 to the first-hop PDP 320, such as... Figure 5 As shown. That is, according to one embodiment of the present invention, sending the encrypted first message 303 via multi-hop unidirectional communication may include: sending the encrypted first message 303 together with an indication from the first-hop PDP 320 of the multi-hop unidirectional communication to entity 310; causing entity 310 to forward the encrypted first message 303 to the first-hop PDP 320 via multi-hop unidirectional communication. It is worth noting that... Figure 5 Based on Figure 3 A variant of .

[0126] This approach can be called... Figure 6 Example 2 is shown. Figure 6 It shows the relationship with Figure 4 A similar signaling process is used, except that entity 310 forwards the encrypted first message 303 received from PEP 300 to the first-hop PDP 320 (i.e., A1). The advantage of this is that PEP 300 does not need to be able to communicate directly with PDPs 320 and 320'. One scenario where this benefits is when PEP 300 is located in a separate network, not accessing the rest of the local network or the internet, but entity 310 can communicate with PEP 300 via near-field communication or Bluetooth. In other words, PEP 300 and multiple PDPs 320 and 320' can reside in different networks. It is worth noting that this can significantly improve the security of PEP 300.

[0127] Based on Embodiment 1 or Embodiment 2, it can be seen that the number of cryptographic operations performed by each PDP is reduced to a minimum. It may only require one (authenticated) decryption operation (e.g., a single AES-GCM decryption). Compared to the embodiments of the present invention, the second conventional technical solution requires each PDP to perform one public-key (e.g., RSA-OAEP) encryption and one decryption. It should be noted that symmetric operations such as AES-GCM decryption are typically an order of magnitude faster than public-key encryption or decryption.

[0128] To prevent timed oracles, the time required for a successful protocol should be the same as the time required for a failed protocol. The existence of timed oracles indicates that the protocol leaks information about the plaintext through a timed side channel. For example, many well-known attacks against TLS exploit the fact that some implementations abort the TLS handshake once they detect an error in the format of the pre-master key after RSA decryption. If the format is correct, the server's response time is much longer, thus the timed side channel leaks information about whether the decrypted message is formatted correctly. The countermeasures used in this invention are as follows: Figure 7 As stated above.

[0129] Figure 7 The signaling between PEP 300, entity 310, and multiple PDPs 320, 320' provided in Embodiment 1 of the present invention is illustrated. However, in this example, the second-hop PDP 320' rejects entity 310's request 301. According to this embodiment, if metadata verification fails, PDP 320 or 320' needs to send garbage of the same length as the plaintext. The correct length can be predicted heuristically. Furthermore, each PDP 320 or 320' should attempt to use the same amount of time in the failure case as in the success case. When PDP 320 or 320' sends garbage, this naturally leads to a chain reaction, and all other decryptions fail. Finally, the client (i.e., entity 310) is able to decrypt only meaningless octets and therefore cannot generate a valid signature for the challenge. Assuming the underlying encryption algorithm is secure, an attacker cannot distinguish between valid ciphertext and arbitrary octets. Since the time required in the failure case is the same as in the success case, an attacker cannot learn the outcome of the individual PDP decisions or the final decision of the PEP by observing protocol messages on the network.

[0130] according to Figure 4 , Figure 6 and Figure 7 As can be seen from the embodiment shown, PEP 300 can encrypt the first message 302 by recursively wrapping the challenge and metadata, first using the public key of entity 310, and then sequentially using the public keys of multiple PDPs 320 and 320'.

[0131] Specifically, considering that the number of PDPs 320 and 320' in multiple PDPs 320 and 320' is k, where k is a positive integer greater than 1, the recursive packaging includes (k+1) layers of packaging. This means that PEP 300 can use the public key of entity 310 to encrypt the challenge and metadata to obtain the first layer of packaging, and then use the public key of PDP(k+1–n) to encrypt the nth layer of packaging to obtain the (n+1)th layer of packaging, where n is a positive integer, 1≤n≤k, and PDP(k+1–n) represents the (k+1–n)th PDP in multiple PDPs 320 and 320' for multi-hop unidirectional communication. Figure 4 , Figure 6 and Figure 7 In the example shown, the encrypted first message 303 can be represented as A1(d,A2(d,A3(d,C(c)))).

[0132] When recursive wrapping is used for encryption, metadata can also represent the order of multiple PDP 320, 320' (i.e., hops in multi-hop unidirectional communication).

[0133] The general description above leaves one question: which cryptographic primitives are used for recursive wrapping? Several alternatives exist, resulting in different embodiments of the invention. The basic variant of the invention uses static ECIES to minimize the number of cryptographic operations per PDP and achieves an optimal number of operations (1) per PDP. As previously stated, it is assumed that a previous bootstrapping phase has already occurred, in which PDPs 320, 320', and PEP 300 have exchanged real copies of their respective public keys. Note that prior bootstrapping is not necessary for applying the invention, as PEP 300 can also embed its own certificate into each metadata, but this speeds up subsequent processing. In particular, this allows us to obtain an efficient "static" variant of the ECIES hybrid encryption scheme.

[0134] First, the standard ECIES operation is as follows: Figure 8 As described above, in standard ECIES, the sender first generates a new ECDH key pair. Then, the sender uses the generated private key and the receiver's public key to derive an ECDH shared key. The shared key is passed to a key derivation function, such as KDF1, to generate a symmetric encryption key. This key, along with a random initial value, is then used.

[0135] In the static ECIES variant used in this embodiment of the invention, the shared key and symmetric encryption key are pre-derived by the PEP300 during the bootstrap phase. Therefore, the PEP300 has a separate symmetric encryption key for each PDP, which the PEP300 can use to add a layer of wrapping during the runtime phase. This is as follows: Figure 9 As shown.

[0136] According to one embodiment of the present invention, when static ECIES are used for recursive packaging, PEP 300 can also be used to obtain the public key of entity 310 and the public keys of each of the multiple PDPs 320, 320', wherein the public key of entity 310 and the public keys of each of the multiple PDPs 320, 320' are predetermined.

[0137] Figure 10 This illustrates how each PDP 320 or 320' decrypts its messages. Each PDP 320 or 320' has a separate symmetric key shared with the PEP 300 and can be used to decrypt messages. Note that the initial value vector (IV) is sent in plaintext.

[0138] A key feature of static ECIES is that, because only PEP 300 knows the PEP private key, attackers cannot use it as they would in a second, traditional technical approach. Figure 2 By creating valid ciphertext as described in [previous protocol], this scheme becomes more secure against denial-of-service attacks and known-ciphertext attacks. Furthermore, attackers cannot decrypt the ciphertext without access to the PDP private key. Therefore, static ECIES provides implicit sender and receiver authentication for each message. The advantage of using static ECIES instead of a pre-shared key (i.e., a pre-distributed symmetric key) is that a confidential channel is not required during bootstrapping; that is, a real channel suffices. This makes the bootstrapping phase much simpler than PSK encryption.

[0139] By using static ECIES, this invention only requires one symmetric key operation per PDP 320, 320'. This is likely optimal: if the PDP does not perform any cryptographic operations, deriving a secure scheme is impossible. Furthermore, the only cryptographic primitive faster than symmetric key decryption is keyless operation, such as hash calculation, which does not provide much security in this case.

[0140] Based on Embodiments 1 and 2, other embodiments can be derived from these basic variations of the present invention.

[0141] TLS integration example:

[0142] This embodiment provides a faster failure scenario by integrating the invention into the earliest possible phase of the TLS 1.3 handshake. PEP 300 uses a HelloRetryRequest message to send a recursively wrapped challenge to the client. The client must include a valid signature of the challenge in a second ClientHello message. This embodiment, for example... Figure 11 As stated above.

[0143] Non-recursive implementation:

[0144] In an embodiment of the invention, PEP 300 does not use recursive wrapping, but instead divides the challenge into k parts and encrypts each part separately using the PDP public key. Each plaintext includes a copy of the metadata. Therefore, each PDP 320, 320' receives a copy of the metadata and can be removed from the challenge portion. The advantage of this embodiment is that it enables dynamic routing, improving network performance. This contrasts sharply with the basic variant, in which the order of PDPs 320, 320' in the chain is fixed by PEP 300 during wrapping. This embodiment, for example... Figure 12 As shown.

[0145] Specifically, according to this embodiment, encrypting the first message 302 may include: encrypting the challenge using the public key of entity 310; dividing the encrypted challenge into k parts, where k is the number of PDPs 320 and 320' among the multiple PDPs 320 and 320', k is a positive integer greater than 1, and each of the k parts corresponds to one of the k PDPs 320 and 320'; and encrypting each of the k parts and metadata using the public key of the corresponding PDP.

[0146] According to an embodiment of the present invention, when making a final decision based on the validity of the signature 304 on the second message, if the signature 304 on the second message is determined to be valid, then PEP 300 may approve request 301. Specifically, if the signature 304 on the second message matches the challenge, then PEP 300 may determine that the signature 304 is valid. If the signature 304 on the second message is determined to be invalid, then PEP 300 may reject request 301. Specifically, if the signature 304 on the second message does not match the challenge, then PEP 300 may determine that the signature 304 is invalid.

[0147] It is worth mentioning that, in the above embodiment, if one of the multiple PDPs 320, 320' rejects request 301, then the signature 304 on the second message is invalid, and therefore PEP 300 will reject request 301.

[0148] Example of “n in k”:

[0149] Conversely, if n out of k PDPs agree, this embodiment causes entity 310 to decrypt the challenge. This embodiment can be created from a non-recursive variant, as described below.

[0150] PEP 300 creates k challenges c1, c2...ck instead of a single challenge, and encrypts each challenge first using the client's public key, then using the public key of the corresponding PDP: A1(C(c1)), A2(C(c2))...Ak(C(ck)). Each PDP 320, 320' decrypts its own challenge and sends the decrypted message forward, as described above. Entity 310 is required to sign each challenge individually. If at least n of the k signatures are valid, PEP 300 approves request 301.

[0151] According to this embodiment, considering that the number of PDPs in the multiple PDPs 320, 320' is k, where k is a positive integer greater than 1, the above challenge includes k PDP-specific challenges, each PDP-specific challenge corresponding to one of the k PDPs 320, 320'. PEP 300 is used to generate PDP-specific challenges for each of the k PDPs 320, 320'.

[0152] Specifically, encrypting the first message 302 may include: first using the public key of entity 310, and then using the public key of the corresponding PDP to encrypt each PDP-specific challenge and metadata to obtain an encrypted PDP-specific message. Therefore, the encrypted first message 303 includes k encrypted PDP-specific messages.

[0153] In the “n in k” embodiment, since each PDP 320 or 320' can independently make a decision on whether to approve request 301, PEP 300 can make a final decision based on the individual decisions of multiple PDPs 320, 320'.

[0154] Optionally, PEP 300 can be used to determine the decision of at least n PDPs among k PDPs 320, 320'. If at least n PDPs among the k PDPs approve request 301, then PEP 300 can determine that the signature 304 on the second message is valid; or, if less than n PDPs among the plurality of PDPs approve request 301, then the signature 304 on the second message is determined to be invalid, where n is a positive integer less than k.

[0155] Specifically, the signature 304 on the second message may include k signatures on k PDP-specific messages, each signature on the PDP-specific messages corresponding to one of the k PDPs 320, 320'. Therefore, if the signature on the PDP-specific message corresponding to PDP 320 matches the PDP-specific challenge corresponding to PDP 320, then PEP 300 determines that the PDP 320 approval request 301 is granted; or, if the signature on the PDP-specific message corresponding to PDP 320 does not match the PDP-specific challenge corresponding to PDP 320, then PEP 300 determines that the PDP 320 rejection request 301 is granted.

[0156] Optionally, it can also be designed such that one of the PDP 320s is more important than the others, and if a particular PDP 320 rejects request 301, then PEP 300 needs to reject request 301.

[0157] According to embodiments of the present invention, metadata can also represent the identifiers of multiple PDP 320, 320'.

[0158] Furthermore, other embodiments can be derived from the previously discussed embodiments and the basic version of the invention by using other cryptographic primitives instead of static ECIES. Alternatives here include RSA encryption, such as RSA Deterministic Optimal Asymmetric Encryption Padding (RSA-DOAEP) (i.e., a length-preserving variant of RSA encryption), PSK encryption, or identity-based hybrid encryption, such as Sakai-Kasahara key encryption (SAKKE).

[0159] It's worth noting that the last alternative, identity-based hybrid encryption, does not require a prior secure bootstrapping phase. This is because there's no need to exchange public keys, as the public key in any identity-based scheme is simply the public identifier (or name) of the participants, and the private key generator (PKG), a crucial component of any identity-based scheme, ensures that only the correct participants know the corresponding private key. Identity-based encryption also eliminates the need for cryptographically binding public keys to identifiers via X.509 certificates or similar methods.

[0160] The present invention also proposes the PDP 320 and entity 310 provided in the previous embodiments.

[0161] Figure 13A PDP 320 according to an embodiment of the present invention is shown. The PDP shown herein may be... Figure 3 or Figure 5 One of the PDPs shown herein is an example. PDP 320 may include a processing circuitry (not shown) for performing, conducting, or initiating various operations of the PDP 320 described herein. This processing circuitry may include hardware and software. The hardware may include analog circuitry or digital circuitry, or both. The digital circuitry may include components such as an ASIC, FPGA, DSP, or a multi-purpose processor. PDP 320 may also include a storage circuitry that stores one or more instructions executable by a processor or processing circuitry (specifically, under software control). For example, the storage circuitry may include a non-transitory storage medium storing executable software code. When the executable software code is executed by the processor or processing circuitry, it causes various operations of the PDP 320 to be performed. In one embodiment, the aforementioned processing circuitry includes one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code. When the executable program code is executed by one or more processors, it causes the PDP 320 to perform, conduct, or initiate the operations or methods described herein.

[0162] Specifically, PDP 320 is used to receive a first encrypted message 321 via multi-hop unidirectional communication. Specifically, the multi-hop unidirectional communication begins at PEP 300, which includes multiple PDPs 320, 320', and ends at entity 310, as previously described. The first encrypted message 321 includes an encryption challenge for request 301 from entity 310 and encryption metadata, wherein the metadata represents request 301 and the multiple PDPs 320, 320'. PEP 300 may be... Figure 3 or Figure 5 PEP 300 is shown in the diagram. Entity 310 can be... Figure 3 or Figure 5 Entity 310 is shown in the figure.

[0163] PDP 320 is also used to decode the first encrypted message 321 using the private key of PDP 320 to generate a first decrypted message 322. In addition, PDP 320 is used to obtain metadata from the first decrypted message 322, make a decision on whether to approve request 301, and further provide a third message 323 representing the decision to the next hop via multi-hop unidirectional communication.

[0164] According to one embodiment of the present invention, the first encrypted message 321 can be received from entity 310. That is, the first encrypted message is forwarded by entity 310 from PEP 300.

[0165] Optionally, if PDP 320 rejects request 301, PDP 320 may generate a junk message with the same predicted length as the first decryption message 322 and send the junk message to the next hop.

[0166] It is worth noting that the metadata obtained after encryption by the PDP 320 can also represent the order of multiple PDP 320s, 320' (i.e., hops in multi-hop unidirectional communication).

[0167] As mentioned earlier, the next hop can be the next PDP 320' on the unidirectional chain, or if PDP 320 here is the last PDP on the chain, the next hop can be entity 310.

[0168] For example, according to a previous embodiment, specifically a non-recursive embodiment, the encrypted message received by PDP 320 may include k encrypted PDP-specific messages. This means that the first encrypted message 321 may include a first part dedicated to PDP 320 and a second part for other PDPs 320'. In this case, PDP 320 can decrypt the first part of the first encrypted message 321 to obtain the first part of the first decrypted message 322. Therefore, the first decrypted message 322 includes the first part of the first decrypted message 322 and the second part of the first encrypted message 321. Therefore, PDP 320 can also send a decision indicator indicating whether PDP 320 approves request 301 to the next hop via multi-hop unidirectional communication.

[0169] The PDP 320 provided in this embodiment of the invention operates accordingly, such as in combination with Figures 2 to 12 As described in the embodiments. Other details will not be repeated here.

[0170] Figure 14 The illustration shows an entity 310 provided in one embodiment of the present invention. The entity 310 shown herein can be... Figure 3 or Figure 5Entity 310 is shown in the diagram. Specifically, entity 310 may refer to a client requesting a decision. Entity 310 may include a processing circuitry (not shown) for performing, conducting, or initiating various operations of entity 310 described herein. The processing circuitry may include hardware and software. The hardware may include analog circuitry or digital circuitry, or both. The digital circuitry may include components such as ASICs, FPGAs, DSPs, or multi-purpose processors. Entity 310 may also include a storage circuitry storing one or more instructions that can be executed by a processor or processing circuitry (specifically, under software control). For example, the storage circuitry may include a non-transitory storage medium storing executable software code. When the executable software code is executed by the processor or processing circuitry, it causes various operations of entity 310 to be performed. In one embodiment, the processing circuitry includes one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code. When the executable program code is executed by one or more processors, it causes entity 310 to perform, conduct, or initiate the operations or methods described herein.

[0171] Specifically, entity 310 is used to send request 301 to PEP 300. Entity 310 is also used to receive encrypted message 311 from PDP 320 via multi-hop unidirectional communication. Specifically, the multi-hop unidirectional communication starts at PEP 300, which includes multiple PDPs 320, 320', and ends at entity 310. Furthermore, entity 310 is used to decrypt encrypted message 311 to obtain decrypted message; sign the decrypted message using entity 310's private key; and send the signature 304 on the decrypted message to PEP 300. Accordingly, entity 310 is used to: receive approval for request 301 if signature 304 is verified by PEP 300.

[0172] It is possible that the number of PDPs in the multiple PDPs 320, 320' can be k, where k is a positive integer greater than 1, and the encrypted message 311 can include k parts, each part corresponding to one of the k PDPs.

[0173] According to one embodiment of the present invention, specifically the non-recursive embodiment described above, entity 310 can be used to combine k parts of the encrypted message 311 and decrypt the combined k parts to obtain a decrypted message.

[0174] According to another embodiment of the present invention, specifically the "n in k" embodiment as described above, entity 310 can be used to decrypt k parts separately to obtain PDP-specific decrypted messages. In this case, entity 310 can be used to sign each PDP-specific decrypted message using its private key. Therefore, the signature 304 on the decrypted message can include k signatures on the k PDP-specific decrypted messages.

[0175] It should be noted that entity 310 provided in the embodiments of the present invention operates accordingly, as in conjunction with... Figures 2 to 12 Other details described in the embodiments will not be repeated here.

[0176] Figure 15 A method 1500 provided according to an embodiment of the present invention is illustrated. In a particular embodiment of the present invention, method 1500 is performed by… Figure 3 , Figure 5 or Figure 14 The PEP 300 shown is executed. Method 1500 includes the following steps: Step 1501: Receive a request 301 from entity 310; Step 1502: Generate a first message 302 including a challenge to request 301 and metadata, wherein the metadata represents request 301 and multiple PDPs; Step 1503: Encrypt the first message 302 using the public key of entity 310 and the public keys of the multiple PDPs 320, 320'; Step 1504: Send the encrypted first message 302 via multi-hop unidirectional communication. Specifically, the multi-hop unidirectional communication begins at PEP 300 including multiple PDPs 320, 320' and ends at entity 310. Method 1500 also includes the following steps: Step 1505: Receive a signature 304 on a second message from entity 310, wherein the signature 304 on the second message represents one or more decisions regarding the challenge proposed by the multiple PDPs; Step 1506: Make a final decision based on the validity of the signature 304 on the second message. It is possible that multiple PDP 320 and 320' could be... Figure 3 , Figure 5 , Figure 13 or Figure 14 A PDP is shown in the figure. Entity 310 can be... Figure 3 , Figure 5 or Figure 14 The entity shown in the image.

[0177] Figure 16 A method 1600 provided in one embodiment of the present invention is illustrated. In a particular embodiment of the present invention, method 1600 is performed by… Figure 3 , Figure 5 , Figure 13 or Figure 14The method 1600 is executed by the PDP 320 shown in the figure. Method 1600 includes step 1601: receiving a first encrypted message 321 via multi-hop unidirectional communication. The multi-hop unidirectional communication begins at PEP 300, which includes multiple PDPs 320, 320', and ends at entity 310. Specifically, the first encrypted message 321 includes an encryption challenge for request 301 from entity 310 and encrypted metadata, wherein the metadata represents request 301 and the multiple PDPs 320, 320'. Method 1600 also includes the following steps: step 1602: decrypting the first encrypted message 321 using the private key of the PDP to generate a first decrypted message 322; step 1603: obtaining metadata from the first decrypted message 322; step 1604: making a decision on whether to approve request 301; step 1605: further providing a third message 323 representing the decision to the next hop via multi-hop unidirectional communication. It is possible that PEP 300 could be... Figure 3 , Figure 5 or Figure 14 PEP 300 is shown in the diagram. Entity 310 can be... Figure 3 , Figure 5 or Figure 14 The entity shown in the image.

[0178] Figure 17 A method 1700 provided according to an embodiment of the present invention is illustrated. In a particular embodiment of the present invention, method 1700 is performed by… Figure 3 , Figure 5 or Figure 14 The entity 310 shown in the diagram performs the following steps. Method 1700 includes the following steps: Step 1701: Sending a request 301 to PEP 300; Step 1702: Receiving an encrypted message 311 from PDP 320 via multi-hop unidirectional communication. Specifically, the multi-hop unidirectional communication begins at PEP 300, which includes multiple PDPs 320, 320', and ends at entity 310. Method 1700 also includes the following steps: Step 1703: Decrypting the encrypted message 311 to obtain a decrypted message; Step 1704: Signing the decrypted message using the private key of entity 310; Step 1705: Sending the signature 304 on the decrypted message to PEP 300. Furthermore, method 1700 includes step 1706: If the signature is verified by PEP 300, receiving approval for request 301. It is possible that PEP 300 could be... Figure 3 , Figure 5 or Figure 14 The PEP 300 is shown in the image. The PDP 320 can be... Figure 3 , Figure 5 , Figure 13 or Figure 14 A PDP is shown in the image.

[0179] The summary is as follows:

[0180] • Each PDP can help make overall decisions (access control, authorization) through a one-way (non-interactive) communication chain, which starts at the PEP and ends at the client, sending messages including protection challenges and protection metadata.

[0181] Each PDP can remove a layer of protection from a message and check the metadata. If the PDP approves the request, it sends the message (with a layer of protection removed) to the next PDP.

[0182] The client receives the message, and if each PDP approves the request, the message is left with only one layer of protection. Only in this case can the client remove the last layer of protection, generate a valid signature for the embedded challenge, and send the signature to the PEP for verification.

[0183] • Recursive encryption can be used to protect challenges and metadata in the basic variants (specifically, Examples 1 and 2).

[0184] The above methods can be integrated into the early stages of the TLS 1.3 handshake using the ClientHello and HelloRetryRequest extensions, etc.

[0185] • A custom ECIES variant with a static sender key pair can be used.

[0186] Parallel (cascaded) encryption can be used in both non-recursive variants and "n in k" variants of the method proposed in this paper.

[0187] The main advantages of the technology described in this paper are higher computational efficiency, better scalability, and fewer transmissions compared to traditional methods. The table below summarizes some of the potential advantages of this invention. Note that k represents the number of PDPs.

[0188]

[0189]

[0190] Referring to "#Public-key cryptography", the number "2k+4" is actually a symmetric key operation. If static ECIES is used, the efficiency can be further improved. Figure 18 The diagram illustrates the number of public key computation operations provided in one embodiment of the present invention. It can be seen that in the example with 3 PDPs, a total of 10 computations are required.

[0191] In comparison, Figure 19 and Figure 20 The number of public key operations is shown for traditional technical solution 1 and traditional technical solution 2, respectively.

[0192] Referring to "#transmission", in conventional technical solution 1, each PDP sends 3 handshake messages, plus 2 application data transmissions. Conventional technical solution 2 does not provide PEP authentication. To solve this problem, the PEP signature needs to be added to each plaintext, which effectively doubles the number of public-key cryptographic operations for each PDP. Regarding this invention, when using static ECIES, only the PEP can create valid ciphertext.

[0193] In addition to performance, this device offers two other advantages, as described below.

[0194] One advantage is that if the PEP sends the first message to the client instead of the PDP k, as described in Embodiment 2 of the present invention, the PEP does not need to be on the same network as the PDP. This can be a very useful feature in practice. For example, to prevent attacks, the security lock (PEP) may not have internet access, and the only way to communicate with the security lock is using NFC or Bluetooth. For example, the security lock should be opened by placing a specific smartphone on the security lock. The smartphone is naturally fully connected to the home network or the internet. The present invention allows the PEP and PDP to be on different networks.

[0195] A key distinguishing feature of this invention is unidirectional communication. This means, for example, that broadcast communication utilizing UDP can be used instead of connection-based communication to send messages. This is particularly advantageous in certain scenarios. In short, this invention has fewer communication requirements than conventional solutions.

[0196] Various embodiments of the invention have been described above. Based on this invention, those skilled in the art can implement other embodiments. In the claims and description, the word "comprising" does not exclude other elements or steps, and the quantifier "a" does not exclude a plurality. A single element or other unit can fulfill the functions of several entities or items described in the claims. Listing certain measures in dissimilar dependent claims does not imply that combinations of these measures cannot be used in advantageous implementations.

[0197] Furthermore, any method provided in the embodiments of the present invention can be implemented in a computer program having code modules, which, when run by a processing module, causes the processing module to perform the method steps. The computer program can be stored in a non-transitory computer-readable medium. The computer-readable medium may include read-only memory (ROM), programmable read-only memory (PROM), erasable PROM (EPROM), flash memory, electrically erasable PROM (EEPROM), or a hard disk drive, or a combination of these storage methods, etc.

[0198] Furthermore, those skilled in the art will recognize that embodiments of PEP 300, PDP 320, and Entity 310 respectively include the necessary communication capabilities in the form of functions, modules, units, elements, etc., for performing the technical solution. Other examples of such modules, units, elements, and functions include: processors, memories, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selection units, switches, interleavers, deinterleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiving units, transmitting units, DSPs, trellis-coded modulation (TCM) encoders, TCM decoders, power supply units, power feeders, communication interfaces, communication protocols, etc., which are appropriately arranged together to perform the technical solution.

[0199] The processors of PEP 300, PDP 320, and Entity 310 may each include one or more instances of a Central Processing Unit (CPU), processing unit, processing circuitry, processor, ASIC, microprocessor, or other processing logic capable of interpreting and executing instructions, etc. Therefore, the term "processor" can refer to a processing circuitry system comprising multiple processing circuits, such as any, some, or all of the aforementioned processing circuitry systems. The processing circuitry system can also perform data processing functions for inputting, outputting, and processing data, including data buffering and device control functions, such as call processing control, user interface control, etc.

Claims

1. A policy enforcement point (PEP) for distributed decision-making (300), characterized in that, The PEP includes: A receiving module is used to receive a request (301) from an entity (310). The processing module is used to generate a first message (302) including the challenge and metadata of the request (301), wherein the metadata represents the request (301) and multiple policy decision points (PDPs) (320, 320'). The processing module is further configured to encrypt the first message (302) using the public key of the entity (310) and the public keys of the plurality of PDPs (320, 320'); The sending module is used to send the encrypted first message (303) via multi-hop one-way communication, wherein the multi-hop one-way communication starts at the PEP (300) including the plurality of PDPs (320, 320') and ends at the entity (310). The receiving module is further configured to receive a signature (304) on a second message from the entity (310), wherein the signature (304) on the second message represents one or more decisions regarding the challenges posed by the plurality of PDPs (320, 320'); The decision module is used to make a final decision based on the validity of the signature (304) on the second message.

2. The PEP (300) according to claim 1, characterized in that, The step of sending the encrypted first message (303) via multi-hop one-way communication includes: The encrypted first message (303) is sent to the first hop PDP (320) of the multi-hop unidirectional communication.

3. The PEP (300) according to claim 2, characterized in that, Sending the encrypted first message (303) to the first hop PDP of the multi-hop unidirectional communication includes: The encrypted first message (303) is sent to the entity (310) together with the indication of the first hop PDP (320) of the multi-hop one-way communication. This enables the entity (310) to forward the encrypted first message (303) to the first hop PDP (320) through the multi-hop one-way communication.

4. The PEP (300) according to any one of claims 1 to 3, characterized in that, The request (301) is received from the entity (310) via a secure channel.

5. The PEP (300) according to claim 4, characterized in that, The secure channel between the PEP (300) and the entity (310) includes a transport layer security (TLS) connection. The request (301) is received from the entity (310) and the encrypted first message (303) is sent to the entity (310) via a TLS handshake message.

6. The PEP (300) according to any one of claims 1 to 3, characterized in that, The encryption of the first message (302) includes: Using the public key of the entity (310), and then using the public keys of the plurality of PDPs (320, 320') in turn, the challenge and the metadata are recursively packaged.

7. The PEP (300) according to claim 6, characterized in that, The number of PDPs (320, 320') in the plurality of PDPs (320, 320') is k, where k is a positive integer greater than 1; The recursive wrapping includes k+1 levels of wrapping, and the challenge and metadata included in the recursive wrapping are: The challenge and the metadata are encrypted using the public key of the entity (310) to obtain the first wrapping layer; Using PDP k+1–n The public key is used to encrypt the nth layer package to obtain the (n+1)th layer package, where n is a positive integer, 1 ≤ n ≤ k, and PDP k+1–n This refers to the (k+1)th–nth PDP among the plurality of PDPs (320, 320') in the multi-hop unidirectional communication.

8. The PEP (300) according to claim 6, characterized in that, The recursive wrapping uses one of the following encryption schemes: Elliptic curve integrated encryption scheme (ECIES); Rivest–Shamir–Adleman (RSA) encryption; Pre-shared key encryption; Identity-based hybrid encryption.

9. The PEP (300) according to claim 8, characterized in that, Static ECIES are used for recursive packaging, and the PEP (300) is also used for: Obtain the public key of the entity (310) and the public keys of the plurality of PDPs (320, 320'), wherein the public key of the entity (310) and the public keys of the plurality of PDPs (320, 320') are predetermined.

10. The PEP (300) according to claim 6, characterized in that, The metadata also indicates the order of the plurality of PDPs (320, 320'), which are hops in the multi-hop unidirectional communication.

11. The PEP (300) according to any one of claims 1 to 3, characterized in that, The encryption of the first message (302) includes: The challenge is encrypted using the public key of the entity (310); The encrypted challenge is divided into k parts, where k is the number of PDPs (320, 320') among the plurality of PDPs (320, 320'), k is a positive integer greater than 1, and each of the k parts corresponds to one of the k PDPs (320, 320'). Each of the k parts and the metadata is encrypted using the public key of the corresponding PDP.

12. The PEP (300) according to any one of claims 1 to 3, characterized in that, The final decision based on the validity of the signature (304) on the second message includes: If the signature (304) on the second message is determined to be valid, the request (301) is approved; or If it is determined that the signature (304) on the second message is invalid, the request (301) is rejected.

13. The PEP (300) according to claim 12, characterized in that, The PEP (300) is used for: If the signature (304) of the second message matches the challenge, the signature (304) on the second message is determined to be valid; or If the signature (304) on the second message does not match the challenge, the signature (304) on the second message is determined to be invalid.

14. The PEP (300) according to any one of claims 1 to 3, characterized in that, The number of PDPs in the plurality of PDPs (320, 320') is k, where k is a positive integer greater than 1. The challenge includes k PDP-specific challenges, each PDP-specific challenge corresponding to one of the k PDPs (320, 320'). The generation of the first message (302) includes: Generate PDP-specific challenges for each of the k PDPs (320, 320').

15. The PEP (300) according to claim 14, characterized in that, The encryption of the first message (302) includes: First, the public key of the entity (310) is used, and then the public key of the corresponding PDP is used to encrypt each PDP-specific challenge and the metadata to obtain the encrypted PDP-specific message. The encrypted first message (303) includes k encrypted PDP-specific messages.

16. The PEP (300) according to claim 12, characterized in that, The number of PDPs (320, 320') among the plurality of PDPs (320, 320') is k, and the PEP (300) is used for: Decisions to determine at least n PDPs from the k PDPs (320, 320'); If at least n of the k PDPs approve the request (301), the signature (304) on the second message is determined to be valid; or If fewer than n of the plurality of PDPs approve the request (301), then the signature (304) on the second message is determined to be invalid. Where n is a positive integer less than k.

17. The PEP (300) according to claim 16, characterized in that, The signature (304) on the second message includes k signatures on k PDP-specific messages, each signature on the PDP-specific message corresponding to one of the k PDPs (320, 320'), and the decision to determine at least n PDPs among the k PDPs (320, 320') includes: If the signature on a PDP-specific message corresponding to a PDP (320) matches the PDP-specific challenge corresponding to the PDP (320), it is determined that the PDP (320) approves the request (301); or If the signature on the PDP-specific message corresponding to a PDP (320) does not match the PDP-specific challenge corresponding to the PDP (320), it is determined that the PDP (320) rejects the request (301).

18. The PEP (300) according to any one of claims 1 to 3, characterized in that, The metadata represents the identifier of each of the plurality of PDPs (320, 320').

19. The PEP (300) according to claim 3, characterized in that, The PEP (300) and the plurality of PDPs (320, 320') are located in different networks.

20. A policy decision point (PDP) (320), characterized in that, The PDP includes: A receiving module is configured to receive a first encrypted message (321) via multi-hop unidirectional communication, wherein the multi-hop unidirectional communication begins at a policy enforcement point (PEP) (300) comprising multiple PDPs (320, 320') and ends at an entity (310), and the first encrypted message (321) includes an encrypted challenge and encrypted metadata of a request (301) from the entity (310), wherein the metadata represents the request (301) and the multiple PDPs (320, 320'). The processing module is used to decrypt the first encrypted message (321) using the private key of the PDP (320) to generate a first decrypted message (322). The processing module is further configured to obtain the metadata from the first decryption message (322); A decision module is used to decide whether to approve the request (301); The sending module is used to further provide a third message (323) representing the decision to the next hop via the multi-hop unidirectional communication.

21. The PDP (320) according to claim 20, characterized in that, The step of receiving the first encrypted message (321) via multi-hop one-way communication includes: The first encrypted message (321) is received from the entity (310), wherein the first encrypted message is forwarded by the entity (310) from the PEP (300).

22. The PDP (320) according to claim 20 or 21, characterized in that, If the request (301) is approved, the third message (323) includes the first decryption message (322); or If the request (301) is rejected, the third message (323) includes a spam message, wherein the spam message is generated by the PDP (320) and is predicted to have the same length as the first decryption message (322).

23. The PDP (320) according to claim 20 or 21, characterized in that, The metadata also indicates the order of the plurality of PDPs (320, 320'), which are hops in the multi-hop unidirectional communication.

24. The PDP (320) according to claim 20, characterized in that, The first encrypted message (321) includes a first part dedicated to the PDP (320) and a second part for the other PDPs (320') among the plurality of PDPs (320, 320'); The decryption of the first encrypted message (321) includes: decrypting a first part of the first encrypted message (321) to obtain a first part of the first decrypted message (322), wherein, The first decryption message (322) includes a first part of the first decryption message (322) and a second part of the first encryption message (321).

25. The PDP (320) according to claim 24, characterized in that, The provision of a third message (323) representing the decision to the next hop via the multi-hop unidirectional communication includes: The first decryption message (322) and a decision indicator indicating whether the request (301) is approved by the PDP (320) are sent to the next hop via the multi-hop one-way communication.

26. The PDP (320) according to claim 24 or 25, characterized in that, The PDP (320) is used for: Generate an indicator for the next hop, wherein the indicator indicates that the PDP (320) has made the decision; The indicator is provided to the next hop.

27. An entity (310), characterized in that, The entity (310) includes: The sending module is used to send a request (301) to the policy enforcement point (PEP) (300); The receiving module is configured to receive encrypted messages (311) from the policy decision point (PDP) (320) via multi-hop unidirectional communication, wherein the multi-hop unidirectional communication begins at a PEP (300) comprising multiple PDPs (320, 320') and ends at the entity (310). The processing module is used to decrypt the encrypted message (311) to obtain a decrypted message; The processing module is also used to sign the decrypted message using the private key of the entity (310); The sending module is also used to send the signature (304) on the decryption message to the PEP (300). The receiving module is also configured to receive approval for the request (301) if the signature (304) is verified by the PEP (300).

28. The entity (310) according to claim 27, characterized in that, The number of PDPs in the plurality of PDPs (320, 320') is k, where k is a positive integer greater than 1. The encrypted message (311) includes k parts, each part corresponding to one of the k PDPs. The decryption of the encrypted message (311) to obtain the decrypted message includes: Combine the k parts of the encrypted message (311); The k combined parts are decrypted to obtain the decrypted message.

29. The entity (310) according to claim 27, characterized in that, The number of PDPs (320, 320') among the plurality of PDPs (320, 320') is k, where k is a positive integer greater than 1. The encrypted message (311) includes k parts, each part corresponding to one of the k PDPs (320, 320'). The decryption of the encrypted message (311) to obtain the decrypted message includes: Each of the k parts is decrypted to obtain the PDP-specific decryption message.

30. The entity (310) according to claim 29, characterized in that, The signing of the decrypted message includes: Each PDP-specific decryption message is signed using the private key of the entity (310). The signature (304) on the decryption message includes k signatures on k PDP-specific decryption messages.

31. A method (1500) for distributed decision-making executed by a policy enforcement point (PEP) (300), characterized in that, The method includes: Receive (1501) request (301) from entity (310); Generate (1502) a first message (302) including the challenge and metadata of the request (301), wherein the metadata represents the request (301) and multiple policy decision points (PDPs) (320, 320'). The first message (302) is encrypted (1503) using the public key of the entity (310) and the public keys of the plurality of PDPs respectively. The encrypted first message (302) is sent (1504) via multi-hop one-way communication, wherein the multi-hop one-way communication begins at the PEP (300) which includes the plurality of PDPs (320, 320') and ends at the entity (310). Receive (1505) a signature (304) on a second message from the entity (310), wherein the signature (304) on the second message represents one or more decisions regarding the challenges posed by the plurality of PDPs (320, 320'); Make a final decision (1506) based on the validity of the signature (304) on the second message.

32. A method (1600) executed by a policy decision point (PDP) (320), characterized in that, The method includes: A first encrypted message (321) is received (1601) via multi-hop one-way communication, wherein the multi-hop one-way communication begins at a policy enforcement point (PEP) (300) comprising multiple PDPs (320, 320') and ends at an entity (310), and the first encrypted message (321) includes an encrypted challenge and encrypted metadata of a request (301) from the entity (310), wherein the metadata represents the request (301) and the multiple PDPs; The first encrypted message (321) is decrypted using the private key of the PDP to generate (1602) the first decrypted message (322). Obtain the metadata (1603) from the first decryption message (322); Make a decision (1604) on whether to approve the request (301); The decision is further represented by a third message (323) provided to the next hop via the multi-hop one-way communication (1605).

33. A method (1700) performed by an entity (310), characterized in that, The method (1700) includes: Send (1701) request (301) to the policy enforcement point (PEP) (300); Encrypted messages (311) are received (1702) from the policy decision point (PDP) (320) via multi-hop one-way communication, wherein the multi-hop one-way communication begins at the PEP (300) comprising multiple PDPs (320, 320') and ends at the entity (310). The encrypted message (311) is decrypted (1703) to obtain the decrypted message; The decrypted message is signed (1704) using the private key of the entity (310). Send (1705) the signature (304) on the decryption message to the PEP (300); If the signature is verified by the PEP (300), the recipient (1706) approves the request (301).

34. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method (1500, 1600, 1700) according to any one of claims 31 to 33.

Images