WO2022218544A1

WO2022218544A1 - Device and method for decision-making

Info

Publication number: WO2022218544A1
Application number: PCT/EP2021/059933
Authority: WO
Inventors: Arto NIEMI; Philip Ginzboorg; Pekka Laitinen; Sampo Sovio; Sandeep TAMRAKAR; Jan-Erik Ekberg
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-04-16
Filing date: 2021-04-16
Publication date: 2022-10-20
Also published as: CN117280651A

Abstract

The present disclosure relates to decision-making procedures. To provide an improved decision-making procedure with reduced computational complexity, the disclosure proposes a PEP being configured to: receive a request from 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 the plurality of PDPs; send the encrypted first message using a multi-hop unidirectional communication starting at the PEP, comprising the plurality of PDPs, and ending at the entity; receive a signature over a second message from the entity, wherein the signature over the second message is indicative of one or more decisions regarding the challenge made by the plurality of PDPs; and make a final decision based on a validity of the signature over the second message. The disclosure also proposes a PDP and an entity.

Description

DEVICE AND METHOD FOR DECISION-MAKING

TECHNICAL FIELD The present disclosure relates generally to a decision-making procedure, particularly to decision-making in a distributed system, i.e. a distributed decision-making procedure. The disclosure proposes devices and methods for an improved distributed decision-making procedure. BACKGROUND

A decision-making procedure generally can be divided into three phases: making a request for a decision, making the decision and enforcing the decision. In a distributed decision making system, these phases are performed by separate entities. Especially, the decision making can be performed by a policy decision point (PDP), while the decision enforcement can be performed by a policy enforcement point (PEP). An access control decision is one of the most common decisions for which a decision-making procedure is used. The access control can be defined as “a security function that protects shared resources against unauthorized access”. A shared resource is data for which some form of access control is implemented. Important issues in distributed access control design include how to express and protect requests and decisions, and how the decisions are to be validated. Cryptographic methods, such as encryption and digital signatures, are commonly used to protect the request, the decisions, and to validate the decisions. Sometimes, a PDP can make the wrong decision, causing access to be granted to an unauthorized party. An attacker may have gained control of the PDP, giving him the capability to influence its decisions. Or the PDP may have a limited visibility, e.g. has no access to some piece of information that may be critical for the decision-making process. For example, a simple electronic door lock in an end user’s home may have no way of authenticating an operator of the key to the lock, but may rely only on a proof-of-possession

(e.g. a signature over a random challenge) of the bearer token (the key). At the same time, one or more intrusion detection sensors in the home network may have detected that the person holding the key is actually a burglar, who has managed to steal the key from its owner. Thus, it makes sense to involve multiple PDPs in the decision-making, when suitable devices or software entities are available, to improve security. As the amount of deployed Internet-of-things (IOT) devices continues to grow rapidly, ever more potential PDPs become available.

The most current access control methods are based on a general access control or authorization frameworks, such as OAuth, XACML, SAML and OpenID. In particular, OAuth refers to an authorization framework defined in RFC 6749. An issue with all of these frameworks is that they only support a single PDP. XACML refers to an extensible access control markup language, which is a policy language and access control architecture. SAML refers to a security assertion markup language, which is an open standard for exchanging authentication and authorization data between parties. OpenID refers to a standard for decentralized authentication. To add support for multiple PDPs, it is possible to simply perform the existing single-PDP decision-making and enforcement process multiple times, once per each PDP. However, it does not scale well - the computational complexity and communication requirements for decision-making and enforcement process are high. Many potential PDPs are small devices such as sensors, which may be able to perform the required cryptographic operations only slowly. Further, network latency can be high in many use cases. Therefore, an improved distributed decision-making method is desired.

SUMMARY

In view of the above-mentioned limitations, embodiments of the present disclosure aim to introduce an improved solution for distributed decision-making in an effective and flexible manner. In particular, an objective is to provide a solution with reduced computational complexity and communication requirements, respectively. Another objective is to also reduce a network latency during the decision-making procedure. This disclosure further aims to allow a PEP to be in a different network than one or more PDPs.

The objective is achieved by embodiments as provided in the enclosed independent claims. Advantageous implementations of the embodiments are further defined in the dependent claims. A first aspect of the disclosure provides a PEP for distributed decision-making, configured to receive a request from an entity; generate a first message comprising a challenge and metadata of the request, wherein the metadata is indicative of the request and of a plurality of PDPs; encrypt the first message using a public key of the entity and a public key of each of the plurality of PDPs; send the encrypted first message using a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at the PEP, comprises the plurality of PDPs, and ends at the entity; receive a signature over a second message from the entity, wherein the signature over the second message is indicative of one or more decisions regarding the challenge made by the plurality of PDPs; and make a final decision based on a validity of the signature over the second message.

Embodiments of this disclosure enable a solution that may require only one mutually authenticated connection between a client, i.e., the entity, and the PEP, and uses public key encryption for the rest of the communication. Substantial overhead can thus be avoided. Further, this disclosure proposes to use a unidirectional, chained communication. That means, there is no interaction between a previous hop and a next hop in the unidirectional chain of communication.

In an implementation form of the first aspect, sending the encrypted first message using the multi-hop unidirectional communication comprises: sending the encrypted first message to a first-hop PDP of the multi-hop unidirectional communication.

In an implementation form of the first aspect, sending the encrypted first message to the first PDP of the multi-hop unidirectional communication comprises: sending the encrypted first message, along with an indication of the first-hop PDP of the multi-hop unidirectional communication, to the entity; and causing the entity to forward the encrypted first message to the first-hop PDP using the multi-hop unidirectional communication.

Optionally, it would also be possible for the PEP to first send the encrypted message to the client, i.e., the entity, which will then relay the encrypted first message to the first-hop PDP. The benefit of this may be that the PEP does not have to be able to communicate with the PDPs directly. It is worth mentioning that this can significantly improve the security of the PEP. In an implementation form of the first aspect, the request is received from the entity over a secured channel.

In an implementation form of the first aspect, the secured channel between the PEP and the entity comprises a transport layer security (TLS) connection, wherein the request is received from the entity, and the encrypted first message is sent to the entity, using TLS handshake messages.

Optionally, it is possible to integrate this disclosure into the earliest possible stage of a TLS 1.3 handshake.

In an implementation form of the first aspect, encrypting the first message comprises: recursively wrapping the challenge and the metadata using the public key of the entity and then using the public keys of the plurality of PDPs one after the other.

Notably, such a procedure may create an “onion-like” recursive wrapping, similar to the one used in onion routing. Accordingly, each PDP may be able to remove one layer of protection from the message and examines the metadata. If the PDP approves the request, it will send the message (with one layer of protection removed) to the next PDP.

In an implementation form of the first aspect, a quantity of the PDPs of the plurality of PDPs is k, k being a positive integer greater than 1, wherein the recursive wrapping comprises k + 1 layers of wrapping, wherein recursively wrapping the challenge and the metadata comprises: encrypting the challenge and the metadata using the public key of the entity to obtain a first layer of wrapping; and encrypting an nth layer of wrapping using the public key of PDP k + 1 - n to obtain an (n + l)th layer of wrapping, n being a positive integer and 1 ^ n ^ k, wherein PDP k + 1 - n represents the (k + 1 - n)th PDP of the plurality of PDPs of the multi-hop unidirectional communication.

In particular, the PEP first encrypts the challenge and the metadata first with the public key of the entity, then with the public key of PDP k, then with the public key of PDP k-1, etc. The final layer of wrapping is added using the public key of the first-hop PDP. In an implementation form of the first aspect, one of the following encryption schemes is used for the recursive warping: elliptic curve integrated encryption scheme (ECIES); Rivest-Shamir-Adleman (RSA) encryption; pre-shared key (PSK) encryption; identity- based hybrid encryption.

ECIES refers to a public-key authenticated encryption scheme, which uses a key-derivation function (KDF) for deriving separate MAC key and symmetric encryption key from the Elliptic-curve Diffie-Hellman (ECDH) shared secret. An ECIES operation can be divided into two stages. In the first stage, a local party generates a new ECDH key pair, and uses its private ECDH key together with the public ECDH key of the remote peer, to compute a shared secret, from which the local party then derives the symmetric encryption or decryption key. In the second stage, the actual encryption or decryption operation is performed using the symmetric key derived in the first stage. A standard ECIES operation always includes both stages.

PSK refers to a shared secret which was previously shared between the two parties using some secure channel before it needs to be used. Identity-based encryption is a type of public-key encryption in which a user can generate a public key from a known unique identifier, and a trusted third-party server calculates the corresponding private key from the public key. It can thus remove the need for a prior secure bootstrapping phase.

In an implementation form of the first aspect, the ECIES is used for the recursive warping, wherein the PEP is further configured to: obtain the public key of the entity and the public key of each of the plurality of PDPs, wherein the public key of the entity and the public key of each of the plurality of PDPs are predetermined.

In the static ECIES variant used in embodiments of this disclosure, the first phase of the ECIES operation is performed in advance, for instance during a bootstrapping phase. As a result, at the start of the operational phase, the PEP and each PDP already have a separate, pairwise symmetric key in common. This significantly reduces the time it takes to perform each ECIES operation. Further, static ECIES provides implicit sender and receiver authentication for each message. The benefit of using static ECIES instead of pre-shared keys (i.e. symmetric keys that are distributed in advance) is that there is no need for a confidential channel during bootstrapping — it is enough to use authentic channels. This makes the bootstrapping phase much simpler than with PSK encryptions.

In an implementation form of the first aspect, the metadata is further indicative of an order of the plurality of PDPs, which are hops of the multi-hop unidirectional communication.

In an implementation form of the first aspect, encrypting the first message comprises: encrypting the challenge using the public key of the entity; splitting the encrypted challenge into k parts, k being a quantity of the PDPs of the plurality of PDPs, k being a positive integer greater than 1, wherein each part of k parts corresponds to one PDP of the k PDPs; encrypting each part of the k parts and the metadata using the public key of the corresponding PDP.

Instead of using recursive wrapping, this disclosure proposes another approach in which the PEP splits the challenge into k parts and encrypts each separately using the PDP public keys. One copy of the metadata is included in each plaintext. Thus, each PDP gets one copy of metadata and can remove the wrapping from one part of the challenge. The benefit of this variant is that it allows dynamic routing, which improves network performance.

In an implementation form of the first aspect, making the final decision based on the validity of the signature over the second message comprises: granting the request if it is determined that the signature over the second message is valid; or denying the request if it is determined that the signature over the second message is not valid.

In an implementation form of the first aspect, the PEP is configured to: determine that the signature over the second message is valid if it matches the challenge; or determine that the signature over the second message is not valid if it does not matches the challenge.

In an implementation form of the first aspect, a quantity of the PDPs of the plurality of PDPs is k, k being a positive integer greater than 1, wherein the challenge comprises k PDP-dedicated challenges, each PDP-dedicated challenge corresponding to one of the k PDPs, wherein generating the first message comprises generating a PDP-dedicated challenge for each of the k PDPs. Instead of a single challenge, the PEP may also create k challenges.

In an implementation form of the first aspect, encrypting the first message comprises encrypting each PDP-dedicated challenge and the metadata using first the public key of the entity, and then the public key of the corresponding PDP, to obtain an encrypted PDP- dedicated message, wherein the encrypted first message comprises k encrypted PDP- dedicated messages.

The PEP may encrypt each with the client’s public key and then with the corresponding PDP’s public key. Accordingly, the client may be required to sign each challenge separately.

In an implementation form of the first aspect, the PEP is configured to: determine the decisions of at least n of the k PDPs; determine that the signature over the second message is valid if the at least n of the k PDPs permit the request; or determine that the signature over the second message is not valid if less than n of the plurality of PDPs permit the request, wherein n is a positive integer less than k.

Notably, by creating separated challenges encrypting each challenge independently, this disclosure further allows the PEP approves the request if at least n of the k signatures are valid.

In an implementation form of the first aspect, the signature over the second message comprises k signatures over k PDP-dedicated messages, each signature over the PDP- dedicated message corresponding to one of the k PDPs, wherein determining the decision of at least n of the k PDPs comprises: determining that a PDP permits the request if the signature over the PDP-dedicated message corresponding to that PDP matches the PDP- dedicated challenge corresponding to that PDP; or determining that a PDP denies the request if the signature over the PDP-dedicated message corresponding to that PDP does not match the PDP-dedicated challenge corresponding to that PDP.

In an implementation form of the first aspect, the metadata is indicative of an identifier of each of the plurality of PDPs. In an implementation form of the first aspect, the PEP and the plurality of PDPs are located in different networks

As previously mentioned, if the PEP uses the entity as a relay for forwarding encrypted messages, the PEP need not be in the same network as the PDPs. This can be a very useful feature in practice. For example, to prevent attacks, a secure door lock (e.g., PEP) may have no access to the Internet and the only way to communicate with the lock is to use near-field communication (NFC) or Bluetooth - e.g. the lock is supposed to be opened by placing a specific smartphone on the lock.

A second aspect of the disclosure provides a PDP, wherein the PDP is configured to: receive a first encrypted message via a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at a PEP, comprises a plurality of PDP, and ends at an entity, wherein the first encrypted message comprises an encrypted challenge and encrypted metadata of a request from the entity, and wherein the metadata is indicative of the request and the plurality of PDPs; generate a first decrypted message by decrypting the first encrypted message using a private key of the PDP; obtain the metadata from the first decrypted message; make a decision on whether to permit the request; and provide a third message indicative of the decision further using the multi-hop unidirectional communication to the next hop.

Embodiments of this disclosure further propose a PDP, which can operate accordingly as described in first aspect and its implementation forms.

In an implementation form of the second aspect, receiving the first encrypted message via the multi-hop unidirectional communication comprises: receiving the first encrypted message from the entity, wherein the first encrypted message is forwarded by the entity from the PEP.

In an implementation form of the second aspect, the third message comprises the first decrypted message, if the request is permitted; or the third message comprises a garbage message, if the request is denied, wherein the garbage message is generated by the PDP, and has a length that is predicted to be the same as a length of the first decrypted message. In an implementation form of the second aspect, the metadata is further indicative of an order of the plurality of PDPs, which are hops of the multi-hop unidirectional communication.

In an implementation form of the second aspect, the first encrypted message comprises a first part that is dedicated to the PDP, and a second part that is for other PDPs of the plurality of PDPs, wherein decrypting the first encrypted message comprises decrypting the first part of the first encrypted message to obtain a first part of the first decrypted message, wherein the first decrypted message comprises the first part of the first decrypted message, and the second part of the first encrypted message.

In an implementation form of the second aspect, providing the third message indicative of the decision using the multi-hop unidirectional communication to the next hop comprises: sending the first decrypted message and a decision indicator indicative of whether the request is permitted by the PDP using the multi-hop unidirectional communication to the next hop.

A third aspect of the disclosure provides an entity, wherein the entity is configured to: send a request to a PEP; receive an encrypted message from a PDP, via a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at the PEP, comprises a plurality of PDP, and ends at the entity; decrypt the encrypted message to obtain a decrypted message; sign the decrypted message using a private key of the entity; send a signature over the decrypted message to the PEP; and receive a grant on the request if the signature is verified by the PEP.

Embodiments of this disclosure further propose an entity, i.e., the client who makes the request, which can operate accordingly as described in first aspect and its implementation forms.

In an implementation form of the third aspect, a quantity of the PDPs of the plurality of PDPs is k, k being a positive integer greater than 1, wherein the encrypted message comprises k parts, each part corresponding to one PDP of the k PDPs, wherein decrypting the encrypted message to obtain the decrypted message comprises: combining the k parts of the encrypted message; and decrypting the combined k parts to obtain the decrypted message.

In an implementation form of the third aspect, a quantity of the PDPs of the plurality of PDPs is k, k being a positive integer greater than 1, wherein the encrypted message comprises k parts, each part corresponding to one PDP of the k PDPs, wherein decrypting the encrypted message to obtain the decrypted message comprises decrypting each of the k parts to obtain a PDP-dedicated decrypted message.

In an implementation form of the third aspect, signing the decrypted message comprises signing each PDP-dedicated decrypted message using the private key of the entity, wherein the signature over the decrypted message comprises k signatures over k PDP-dedicated decrypted messages.

A fourth aspect of the disclosure provides a method performed by a PEP for distributed decision-making, the method comprising: receiving a request from an entity; generating a first message comprising a challenge and metadata of the request, wherein the metadata is indicative of the request and of a plurality of PDPs; encrypting the first message using a public key of the entity and a public key of each of the plurality of PDPs; sending the encrypted first message using a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at the PEP, comprises the plurality of PDPs, and ends at the entity; receiving a signature over a second message from the entity, wherein the signature over the second message is indicative of one or more decisions regarding the challenge made by the plurality of PDPs; and making a final decision based on a validity of the signature over the second message.

Implementation forms of the method of the fourth aspect may correspond to the implementation forms of the PEP of the first aspect described above. The method of the fourth aspect and its implementation forms achieve the same advantages and effects as described above for the PEP of the first aspect and its implementation forms.

A fifth aspect of the disclosure provides a method performed by a PDP, the method comprising: receiving a first encrypted message via a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at a PEP, comprises a plurality of PDP, and ends at an entity, wherein the first encrypted message comprises an encrypted challenge and encrypted metadata of a request from the entity, and wherein the metadata is indicative of the request and the plurality of PDPs; generating a first decrypted message by decrypting the first encrypted message using a private key of the PDP; obtaining the metadata from the first decrypted message; making a decision on whether to permit the request; and providing a third message indicative of the decision further using the multi-hop unidirectional communication to the next hop.

Implementation forms of the method of the fifth aspect may correspond to the implementation forms of the PDP of the second aspect described above. The method of the fifth aspect and its implementation forms achieve the same advantages and effects as described above for the PDP of the second aspect and its implementation forms.

A sixth aspect of the disclosure provides a method performed by an entity, the method comprising: sending a request to a PEP; receiving an encrypted message from a PDP, via a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at the PEP, comprises a plurality of PDP, and ends at the entity; decrypting the encrypted message to obtain a decrypted message; signing the decrypted message using a private key of the entity; sending a signature over the decrypted message to the PEP; and receiving a grant on the request if the signature is verified by the PEP.

A seventh aspect of the disclosure provides a computer program comprising a program code for carrying out, when implemented on a processor, the method according to the fourth aspect and any implementation forms of the fourth aspect, the fifth aspect and any implementation forms of the fifth aspect, or the sixth aspect and any implementation forms of the sixth aspect.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms of the present disclosure will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a signaling among PEP and multiple PDPs according to

Conventional solution 1. FIG. 2 shows a signaling among PEP and multiple PDPs according to Conventional solution 2.

FIG. 3 shows a PEP according to an embodiment of the disclosure. FIG. 4 shows a signaling among PEP and multiple PDPs according to an embodiment of the disclosure.

FIG. 5 shows a PEP according to an embodiment of the disclosure. FIG. 6 shows a signaling among PEP and multiple PDPs according to an embodiment of the disclosure.

FIG. 7 shows a signaling among PEP and multiple PDPs according to an embodiment of the disclosure. FIG. 8 shows a standard ECIES hybrid encryption according to an embodiment of the disclosure.

FIG. 9 shows a static ECIES hybrid encryption according to an embodiment of the disclosure. FIG. 10 shows a static ECIES decryption according to an embodiment of the disclosure. FIG. 11 shows a signaling among PEP and multiple PDPs according to an embodiment of the disclosure.

FIG. 12 shows a signaling among PEP and multiple PDPs according to an embodiment of the disclosure.

FIG. 13 shows a PDP according to an embodiment of the disclosure.

FIG. 14 shows an entity according to an embodiment of the disclosure. FIG. 15 shows a method according to an embodiment of the disclosure.

FIG. 16 shows a method according to an embodiment of the disclosure.

FIG. 17 shows a method according to an embodiment of the disclosure.

FIG. 18 shows a number of public-key operations according to an embodiment of the disclosure.

FIG. 19 shows a number of public-key operations according to Conventional solution 1.

FIG. 20 shows a number of public-key operations according to Conventional solution 2. DETAILED DESCRIPTION OF EMBODIMENTS

Illustrative embodiments of methods and devices for distributed decision-making in a communication system are described with reference to the figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

Moreover, an embodiment/example may refer to other embodiments/examples. For example, any description including but not limited to terminology, element, process, explanation and/or technical advantage mentioned in one embodiment/example is applicative to the other embodiments/examples.

Before specific embodiments are disclosed in detail, some relevant requirements and assumptions are first described here.

A security protocol should be explicit about what kind of security it provides. The following basic security requirements (SR) may be considered for every distributed access control method:

• SRI. Confidentiality: the contents of the request, the decisions and the resource itself should not be visible to unauthorized parties.

• SR2. Integrity: it should not be possible for any third party to modify the request or the decisions.

• SR3. Security of access control: only the PEP and the PDPs chosen by the PEP should be able to influence the decision. The PDPs should be presented with an authentic copies of the relevant parts of the request, so that they can make the correct decision based on their policies.

• SR4. Authentication: it should not be possible for an attacker to masquerade as a valid PDP or PEP; the PEP must be able to authenticate each PDP and the client, and the PDPs must be able to authenticate the PEP.

The last requirement is typically fulfilled by distributing public keys in X.509 certificates. A certificate contains a public key and the key owner’s identifier, and is signed by a trusted third party (i.e., certificate authority (CA)). Thus, a valid certificate represents an authentic binding of the public key to its owner’s identity. Certificates can be either distributed during the protocol execution (as in e.g., TLS) or beforehand in a secure bootstrapping phase. The bootstrapping phase requires an authentic communication channel, but no confidentiality. In this disclosure, it is assumed that the PEP is trusted, but any of the PDPs and the client may be under the control of an attacker. Further, it is assumed that a prior bootstrapping phase has been completed.

The problem of distributed, multi-agent decision-making is also considered in the field of consensus protocols and Byzantine fault tolerance. In these cases, the agents (“PDPs”) must, by themselves, make a common decision under the constraint that some of the agents may be unreliable. There is one critical difference to the multi-PDP access control / authorization problem considered in the current document: in our case, there is a trusted party, the PEP, which makes the final decision based on inputs from the PDPs. Thus, much simpler solutions can be used, and the solutions to the consensus or Byzantine fault tolerance problems are neither efficient, nor directly applicable to the problem discussed in the present application.

In blockchain-based decision-making, there is also no trusted party (a “PEP”) that makes the final decision. Also, blockchains tend to be computationally very complex and require a large amount of network traffic.

To introduce this disclosure, a straightforward extension of a conventional single-PDP access control method (such as implemented under the OAuth framework) is first described here:

1. Client (requestor) sends a request to PEP over a mutually authenticated TLS 1.3 connection.

2. For each PDP:

• PEP protects the request and sends it to PDP;

• PDP removes the protection and makes the decision;

• PDP protects its response and sends it to PEP;

• PEP removes the protection and verifies the response.

3. If each PDP approved the request, the PEP sends the resource to the client over the TLS connection, otherwise, the PEP may send an error message.

In this solution, the participants (i.e., Client, PEP, and PDPs) communicate with each other over separate, mutually authenticated TLS 1.3 connections. First, the client (the requestor) establishes a TLS connection to the PEP in order to send its request securely. Next, the PEP contacts each PDP, in turn, over separate TLS connections, presenting them the request and receiving back the decisions for verification. Finally, the PEP either sends the requested resource or an error message to the client. This procedure (referred to as the first conventional solution) is depicted in FIG. 1.

FIG. 1 shows a signaling among a PEP and multiple PDPs with pairwise mutually authenticated TLS connections, for the straightforward extension of the conventional single-PDP access control method. In this figure, three PDPs (k=3) are used as an example. Al, A2 and A3 represent the three PDPs, and C represents the client.

In the example, the client C requests access to a protected resource. It first establishes a TLS session with the PEP and sends a request to the PEP over a secure channel. The PEP then asks each PDP in turn whether it approves or denies the request. The PEP does this by establishing a pairwise, mutually authenticated TLS session with each PDP. After the PEP has received all decisions, it verifies them and makes a final decision. If the final decision is “approve”, the PEP sends the requested resource to the client over the already existing TLS connection between the client and PEP.

It is easy to see how this method fulfills the security requirements set out earlier, as the mutual TLS connections provide both end point authentication and data confidentiality and integrity. It would be straightforward to implement the first conventional solution under the OAuth framework, for example.

The computational costs of this method can be estimated as follows. Assuming each participant has a certificate chain of length three (i.e., subject (e.g. device) certificate, intermediate CA certificate, root CA certificate), each TLS 1.3 connection requires two signature generations (each party must generate and sign the Certificate Verify message) and four signature verifications (the parties must verify each other’s Certificate Verify messages and certificate chains). Such a chain is quite typical in many cases, especially for IOT devices. In order to verify such a chain, two signature verifications are required (subject certificate, intermediate certificate). There is no need to verify the signature of the root CA certificate, as it is self-signed. If the number ofPDPs is k, then there are in total 6k signature generations and verifications, which are the most time-consuming cryptographic operations in almost any protocol. Especially, each PDP needs to perform three such operations. For simplicity, the complexity caused by ECDHE key agreement, HKDF, HMAC and symmetric encryption is ignored. This overhead is rather substantial, but less important than signature operations.

Notably, the communication requirements of a solution as shown in FIG. 1 are rather high. Each TLS 1.3 handshake requires one network round trip before actual data transmission, in addition to the one round trip required by the TCP handshake. The amount of data transmitted is also significant. A typical TLS handshake has an average overhead of around 6500 bytes, with client authentication and long certificate chains adding even more overhead.

Since pairwise TLS connections are costly, in another approach, it may be possible to substantially reduce the amount of cryptographic operations and network transmissions by using public-key encryption instead of secure TLS channels. Again, this approach can be easily implemented as part of any single-PDP framework such as OAuth. This approach (referred to as the second conventional solution) is illustrated in FIG. 2.

FIG. 2 shows an example of signaling among PEP and multiple PDPs with pairwise public- key encryption. Similar as in FIG. 1, three PDPs (k=3) are used here as an example.

In the second conventional solution, there is only one mutually authenticated TLS connection, between the client and the PEP. For communication between the PEP and the PDPs, only public-key encryption is used. The public-key encryption scheme used here may be RSA Optimal Asymmetric Encryption Padding (RSA-OAEP), wherein RSA refers to a public-key cryptographic primitive based on arithmetic in the multiplicative group of integers modulo a prime, and RSA-OAEP is a public-key encryption scheme based on RSA (defined in RFC 8017). This substantially reduces computational complexity and the number of transmissions. Each message must be encrypted and decrypted. Thus, there are two public and two private-key operations per PDP, or 4k operations in total, where k is the number of PDPs. Every transmission contains the actual message (a request or a decision) - there are no messages that could be considered overhead, as in the TLS handshake.

However, an issue of this approach is that anyone can have access to the PEP and PDP public keys. Thus, anyone can create valid messages. This does not necessarily mean that an attacker can break access control, but it forces every participant to decrypt the message and send a response, providing the attacker a substantial opportunity for denial-of-service attacks and chosen ciphertext attacks. Basically, what is missing is requirement SR4 (authentication). This requirement may be fulfilled by adding a sender signature to the transmitted messages, but this essentially doubles the computational costs.

Notably, as described above, the conventional multiple PDPs access control methods have issues of significant computational complexity and the number of transmissions per PDP. For security, it would be useful to involve the maximum amount of PDPs in the decision making. In many use cases, such as sensor networks, data centers, or homes with a large amount of IOT devices, this could well mean tens or hundreds of PDPs. It would be very useful to have a lightweight distributed access control method specifically designed for multiple PDPs and scalability. A solution that minimizes the amount of cryptographic work and transmissions required by each PDP would be especially valuable.

FIG. 3 schematically shows an example of a novel PEP 300. The PEP 300 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the PEP 300 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The PEP 300 may further comprise memory circuitry which stores instructions that can be executed by the processor or by the processing circuitry. For instance, the memory circuitry may comprise a non- transitory storage medium storing executable code which, when executed by the processor or the processing circuitry, causes the various operations of the PEP 300 to be performed. In one embodiment, the processing circuitry comprises 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 which, when executed by the one or more processors, causes the PEP 300 to perform, conduct or initiate the operations or methods described herein.

More particularly, the PEP 300 is configured to perform the following operations in response to receiving a request 301 from an entity 310.

The entity 310 may for example be client C shown in FIG. 1 and FIG.2. The entity 310 may request the PEP 300 to make a decision. For instance, the entity 310 may request access to a protected resource. Even though a method for distributed access control or authorization is discussed here, this disclosure is not limited only to those areas. In fact, the disclosure can be used for any distributed decision-making.

Upon receiving the request 301, the PEP 300 generates a first message 302 comprising a challenge and metadata of the request 301. The metadata is indicative of the request 301 and of a plurality of PDPs 302, 302’. Notably, each of the plurality of PDPs 302, 302’ may decide independently on the request 301 of the entity 310.

The PEP 300 encrypts the first message 302 using a public key of the entity 310 and a public key of each of the plurality of PDPs 320, 320’. The PEP then sends the encrypted first message 303 using a multi-hop unidirectional communication. The multi-hop unidirectional communication starts at the PEP 300, comprises the plurality of PDPs 320, 320’, and ends at the entity 310.

It should be noted that such multi-hop unidirectional communication is particularly distinguished from the bidirectional (“pairwise”) communication that is conventionally used (as the second conventional solution discussed in FIG. 2). That means, there is no interaction between a previous hop and a next hop in the unidirectional chain of communication. This may be particularly beneficial in some use cases. For instance, a broadcast communication with user datagram protocol (UDP) can be used instead of connection-based communication to transmit messages in such multi-hop unidirectional chain.

Further, the PEP 300 is configured to receive a signature 304 over a second message from the entity 310. The signature 304 over the second message is indicative of one or more decisions regarding the challenge made by the plurality of PDPs 320, 320’. Then, the PEP 300 makes a final decision based on a validity of the signature 304.

Optionally, the PEP 300 may receive the request 301 from the entity 310 over a secured channel, such as a TLS connection. Therefore, the request 301 and the encrypted first message 303 may be transmitted using TLS handshake messages.

Note that only one mutually authenticated TLS connection between the client, i.e., the entity 310, and the PEP 300 is required. Public key encryption can be used for the rest of the communication. Thus, the substantial overhead caused by the k+1 TLS handshakes of the first conventional solution as above discussed can be avoided, where k is the number of PDPs. In contrast to the second conventional solution, which uses bidirectional (“pairwise”) communication, to the present solution uses unidirectional, chained communication.

In particular, the PEP 300 may be configured to send the encrypted first message 303 to a first-hop PDP 320 of the multi-hop unidirectional communication. The first-hop PDP 320 may further process and forward the encrypted first message 303 to a next hop PDP 320’. This unidirectional, chained communication may be based on recursively wrapped challenges.

FIG. 4 shows a signaling among the PEP 300, the entity 310 and multiple PDPs 320, 320’ according to a basic variant (Embodiment 1) of this disclosure. Embodiment 1 is implemented based on the unidirectional communication and a recursive wrapping method. It should be noted that the client C refers to the entity 310, and each of Al, A2 and A3 represents a PDP 320 or 320’ of the plurality of PDPs. In this embodiment, Al refers to the first-hop PDP 320. Such definitions also apply for the following figures.

As shown in FIG. 4, the entity 310 first establishes a mutually authenticated TLS connection with the PEP 300 and sends its request (i.e., the request 301 as shown in FIG. 3) over the secure channel. Next, the PEP 300 selects the PDPs that it wants to involve in the decision. The PEP 300 creates a random challenge (i.e., represented as “c” in the figure) of sufficient length (in the example of the illustration, the challenge is 32 random octets) and a metadata that describes the request and contains identifiers of the participating PDPs. The PDP 300 identifiers may be included so that each PDP 320 or 320’ can reject the request if it deems that some of the other PDPs should not be trusted. The PEP 300 encrypts the challenge and the metadata first with the public key of the entity 310 (i.e., represented as “C(c)”), then with the public key of PDP k, then with the public key of PDP k-1, etc. The final layer of wrapping is added using the public key of PDP 1 (namely, the first-hop PDP 320, i.e., Al).

Such procedure creates an “onion-like” recursive wrapping, similar to the one used in onion routing. In Embodiment 1, the ciphertext is sent first to PDP 1 (i.e., Al), which decrypts the message, examines the metadata and makes its decision. If PDP 1 approves the request, it forwards the decrypted message to PDP 2 (i.e., A2), which does the same, etc. The final decrypted message is sent to the entity 310. If each PDP approved the request 301 (i.e. agreed to remove its layer of wrapping and to send the decrypted message onwards), there is only one layer of wrapping left, which the entity 310 can remove using its private key. Thus, the entity 310 can decrypt the challenge only with the approval of each PDP 320 or 320’. The entity 310 then signs the challenge using its private key, and sends it over to the PEP 300 using the existing TLS connection. If the signature (the signature 304 as shown in FIG. 3) verifies correctly, the PEP 300 grants the request 301 and sends the resource to the entity 310.

Optionally, it would also be possible for the PEP 300 to first send the encrypted message 303 to the client, i.e., the entity 310, which will then relay the encrypted first message 303 to the first-hop PDP 320, as shown in FIG. 5. That is, according to an embodiment of this disclosure, sending the encrypted first message 303 using the multi-hop unidirectional communication may comprise: sending the encrypted first message 303, along with an indication of the first-hop PDP 320 of the multi-hop unidirectional communication, to the entity 310; and causing the entity 310 to forward the encrypted first message 303 to the first-hop PDP 320 using the multi-hop unidirectional communication. Notably, FIG. 5 is a variant based on FIG. 3.

Such scheme can be named as Embodiment 2 as shown in FIG. 6. FIG. 6 shows a signaling procedure similar as FIG. 4, and the difference lies in that the entity 310 forwards the encrypted first message 303 that is received from the PEP 300, to the first-hop PDP 320 (i.e., Al). The benefit of this may be that the PEP 300 need not be able to communicate with the PDPs 320, 320’ directly. One use case where this is beneficial is when the PEP 300 is in a separate network, with no access to the rest of the local network or to the Internet, but the entity 310 is able to communicate with the PEP 300, e.g., over near field communication or Bluetooth. That is, the PEP 300 and the plurality of PDPs 320, 320’ may be located in different networks. It is worth mentioning that this can significantly improve the security of the PEP 300.

Based on Embodiment 1 or Embodiment 2, it can be seen that the number of cryptographic operations to be performed by each PDP is minimized. Only one (authenticated) decryption operation may be required (such as a single AES-GCM decryption). In contrast to embodiments of this disclosure, the second conventional solution requires one public-key (e.g. RSA-OAEP) encryption and one decryption by each PDP. It should be noted that a symmetric operation such as AES-GCM decryption is typically an order of magnitude faster than public-key encryption or decryption.

To prevent timing oracles, the protocol should take the same amount of time in the success case as in the failure case. The presence of a timing oracle means that the protocol leaks information about the plaintext via a timing side channel. For example, there have been many well-known attacks against TLS that exploit the fact that some implementations broke off the TLS handshake as soon as they noticed that the RSA-decrypted premaster secret had the wrong format. If the format was correct, the response from server took much longer, thus the timing side channel leaked the information whether the format of the decrypted message was correct or not. The countermeasure used in this disclosure is described in FIG. 7.

FIG. 7 shows a signaling among the PEP 300, the entity 310 and multiple PDPs 320, 320’ according to Embodiment 1 of this disclosure. However, in this example, a second hop PDP 320’ denies the request 301 of the entity 310. According to this embodiment, in case the verification of the metadata fails, a PDP 320 or 320’ should send garbage of around the same length as the plaintext would have been. The correct length can be predicted via heuristic methods. Also, each PDP 320 or 320’ should attempt to use as much time in the failure case as it would have in a successful case. When a PDP 320 or 320’ sends garbage, this will naturally cause a chain reaction, with all further decryptions failing. Finally, the client, the entity 310, is able to decrypt only meaningless octets and cannot thus produce a valid signature for the challenge. Assuming that the underlying encryption algorithm is secure, the attacker cannot distinguish between valid ciphertexts and arbitrary octets. Since the failure case now takes the same amount of time as the success case, the attacker should not be able to learn the outcome of individual PDP decisions or the PEP’s final decision by observing protocol messages on the wire.

According to embodiments illustrated in FIG. 4, FIG. 6 and FIG. 7, it can be seen that the PEP 300 may encrypt the first message 302 by recursively wrapping the challenge and the metadata using the public key of the entity 310 and then using the public keys of the plurality of PDPs 320, 320’ one after the other.

In particular, considering a quantity of the PDPs 320, 320’ of the plurality of PDPs 320, 320’ is k, k being a positive integer greater than 1, the recursive wrapping comprises k + 1 layers of wrapping. That means, the PEP 300 may encrypt the challenge and the metadata using the public key of the entity 310 to obtain a first layer of wrapping, and then encrypt an nth layer of wrapping using the public key of PDP k + 1 - n to obtain an (n + l)th layer of wrapping, n being a positive integer and 1 < n < k, wherein PDP k + 1 - n represents the (k + 1 - n)th PDP of the plurality of PDPs 320, 320’ of the multi-hop unidirectional communication. As the examples shown in FIG. 4, FIG. 6 and FIG. 7, the encrypted first message 303 may be represented as Al(d, A2(d, A3(d, C(c)))).

When the recursive wrapping is used for encryption, the metadata may be further indicative of an order of the plurality of PDPs 320, 320’, which are hops of the multi-hop unidirectional communication.

The above general description left open the question of which cryptographic primitive to use for the recursive wrapping. There are several alternatives, leading to different embodiments of the disclosure. The basic variant of this disclosure uses static ECIES to minimize the number of cryptographic operations per PDP and to achieve the optimum number of operations (one) by each PDP. As previously described, it is assumed that a prior bootstrapping phase has taken place, where the PDPs 320, 320’ and the PEP 300 have exchanged authentic copies of their public keys with each other. Note that the prior bootstrapping is not necessary in order to apply this disclosure, as it would also be possible for the PEP 300 to embed its certificate in each metadata, but makes the subsequent processing faster. Especially it allows us to an efficient “static” variant of the ECIES hybrid encryption scheme.

First, the operation of a standard ECIES is described in FIG. 8. In standard ECIES, the sender first generates a new ECDH key pair. Then it uses the generated private key and the recipient’s public key to derive an ECDH shared secret. The shared secret is passed to a key derivation function such as KDF1 to produce a symmetric encryption key. This key is then used, together with a random initial value.

In the static ECIES variant used in embodiments of this disclosure, the shared secret and the symmetric encryption key are derived in advance, during the bootstrapping phase, by the PEP 300. As a result, the PEP 300 has a separate symmetric encryption key for each PDP that it can use to add a layer of wrapping during the operational phase. This is shown in FIG. 9.

According to an embodiment of this disclosure, when static ECIES is used for the recursive warping, the PEP 300 may be further configured to obtain the public key of the entity 310 and the public key of each of the plurality of PDPs 320, 320’, wherein the public key of the entity 310 and the public key of each of the plurality of PDPs 320, 320’ are predetermined.

FIG. 10 illustrates how each PDP 320 or 320’ decrypts its message. Each PDP 320 or 320’ has a separate symmetric key that is shared with the PEP 300 and can use it to decrypt messages. Note that initial value vectors (IVs) are transmitted in plaintext.

An important feature of static ECIES is that, since the PEP private key is known only to the PEP 300, attackers cannot create valid ciphertexts as in the second conventional solution (FIG. 2), making the scheme more secure against denial-of-service and known ciphertext attacks. Also, the attackers cannot decrypt ciphertexts without access to the PDP private keys. Thus, static ECIES provides implicit sender and receiver authentication for each message. The benefit of using static ECIES instead of pre-shared keys (i.e. symmetric keys that are distributed in advance) is that there is no need for a confidential channel during bootstrapping — it is enough to use authentic channels. This makes the bootstrapping phase much simpler than with PSK encryptions. With static ECIES, this disclosure requires only one symmetric-key operation from each PDP 320, 320’. This can be considered optimal: it is not possible to device secure schemes without any cryptographic operations by the PDPs. Also, the only cryptographic primitive faster than a symmetric-key decryption would be a keyless operation, such as a hash computation, which would not provide much security in this case.

Based on Embodiment 1 and Embodiment 2, further embodiments can derived from these basic variant of this disclosure.

TLS -integrated embodiment:

This embodiment provides a faster failure case by integrating this disclosure into the earliest possible stage of a TLS 1.3 handshake. The HelloRetryRequest message is used by the PEP 300 to send the recursively wrapped challenge to the client. The client must include a valid signature of the challenge in the second ClientHello message. This embodiment is as described in FIG. 11.

Non-recursive embodiment:

Instead of using recursive wrapping, in this embodiment of the disclosure the PEP 300 splits the challenge into k parts and encrypts each separately using the PDP public keys. One copy of the metadata is included in each plaintext. Thus, each PDP 320, 320’ gets one copy of metadata and can remove the wrapping from one part of the challenge. The benefit of this embodiment is that it allows dynamic routing, which improves network performance. This is in contrast to the basic variant, where the order of the PDPs 320, 320’ in the chain is fixed by the PEP 300 at the time of wrapping. This embodiment is shown as in FIG. 12.

In particular, according to this embodiment, the encrypting the first message 302 may comprise: encrypting the challenge using the public key of the entity 310; splitting the encrypted challenge into k parts, k being a quantity of the PDPs 320, 320’ of the plurality of PDPs 320, 320’, k being a positive integer greater than 1, wherein each part of k parts corresponds to one PDP of the k PDPs 320, 320’; and encrypting each part of the k parts and the metadata using the public key of the corresponding PDP. According to embodiments of the disclosure, when making the final decision based on the validity of the signature 304 over the second message, the PEP 300 may grant the request 301 if it is determined that the signature 304 over the second message is valid. In particular, the PEP 300 may determine that the signature 304 over the second message is valid if it matches the challenge. The PEP 300 may deny the request 301 if it is determined that the signature 304 over the second message is not valid. In particular, the PEP 300 may determine that the signature 304 over the second message is not valid if it does not matches the challenge.

It is worth mentioning that for the above described embodiments, if one of the plurality of PDPs 320, 320’ denies the request 301, the signature 304 over the second message will not be valid, and accordingly the PEP 300 will deny the request 301.

“n out of k” embodiment:

This embodiment allows the entity 310 to decrypt the challenge if n out of k PDPs agreed, in contrast to all PDPs agreeing. This embodiment can be created from the non-recursive variant as follows.

Instead of a single challenge, the PEP 300 creates k challenges cl , c2 , ..., ck , and encrypts each with the client’s public key and then with the corresponding PDP’s public key: Al(C(cl)), A2(C(c2)), ..., Ak(C(ck)). Each PDP 320, 320’ decrypts its challenge and sends the decrypted message onwards, as before. The entity 310 is required to sign each challenge separately. The PEP 300 approves the request 301 if at least n of the k signatures are valid.

According to this embodiment, considering a quantity of the PDPs of the plurality of PDPs 320, 320’ is k, k being a positive integer greater than 1, the challenge comprises k PDP- dedicated challenges, each PDP-dedicated challenge corresponding to one of the k PDPs 320, 320’. The PEP 300 is configured to generate a PDP-dedicated challenge for each of the k PDPs 320, 320’.

In particular, the encrypting the first message 302 may comprise: encrypting each PDP- dedicated challenge and the metadata using first the public key of the entity 310, and then the public key of the corresponding PDP, to obtain an encrypted PDP-dedicated message. The encrypted first message 303 thus comprises k encrypted PDP-dedicated messages. For the “n out of k” embodiment, since each PDP 320 or 320’ may make the decision of whether to permit the request 301 independently, it is possible for the PEP 300 to make the final decision based on the individual decisions of the plurality of PDP 320, 320’.

Optionally, the PEP 300 may be configured to determine the decisions of at least n of the k PDPs 320, 320’. The PEP 300 can determine that the signature 304 over the second message is valid if the at least n of the k PDPs permit the request 301; or determine that the signature 304 over the second message is not valid if less than n of the plurality of PDPs permit the request 301, wherein n is a positive integer less than k.

In particular, the signature 304 over the second message may comprise k signatures over k PDP-dedicated messages, each signature over the PDP-dedicated message corresponding to one of the k PDPs 320, 320’. Accordingly, the PEP 300 determines that a PDP 320 permits the request 301 if the signature over the PDP-dedicated message corresponding to that PDP 320 matches the PDP-dedicated challenge corresponding to that PDP 320; or the PEP 300 determines that that a PDP 320 denies the request 301 if the signature over the PDP-dedicated message corresponding to that PDP 320 does not match the PDP-dedicated challenge corresponding to that PDP 320.

Optionally, it can also be designed as one of the PDP 320 has a higher importance than others, if this particular PDP 320 denies the request 301, the PEP 300 should deny the request 301.

According to embodiments of this disclosure, the metadata may be further indicative of an identifier of each of the plurality of PDPs 320, 320’.

In addition, further embodiments can derived from the previously discussed embodiments and from the basic version of this disclosure by using another cryptographic primitive in place of static ECIES. Alternatives here include RSA encryptions such as RSA Deterministic Optimal Asymmetric Encryption Padding (RSA-DOAEP, a length preserving variant of RSA encryption), PSK encryptions or identity-based hybrid encryptions such as Sakai-Kasahara key encryption (SAKKE). It may be worth mentioning that the last alternative, i.e., the identity-based hybrid encryption, removes the need for a prior secure bootstrapping phase. This is because there is no need to exchange public keys, as the public keys in any identity-based scheme are simply the public identifiers (or names) of the participants, and the private key generator (PKG), that is an essential part of any identity-based scheme, ensures that the corresponding private key is only known to the correct participant. An identity based encryption scheme also makes cryptographic binding of public keys to identifiers via e.g. X.509 certificates unnecessary.

This disclosure further proposes a PDP 320 and an entity 310 according to the previously embodiments.

FIG. 13 shows a PDP 320 according to an embodiment of the disclosure. The PDP shown here may be one of PDPs as shown in FIG. 3 or FIG. 5. The PDP 320 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the PDP 320 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as ASICs, FPGAs, DSPs, or multi-purpose processors. The PDP 320 may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the PDP 320 to be performed. In one embodiment, the processing circuitry comprises 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 which, when executed by the one or more processors, causes the PDP 320 to perform, conduct or initiate the operations or methods described herein.

In particular, the PDP 320 is configured to receive a first encrypted message 321 via a multi-hop unidirectional communication. In particular, the multi-hop unidirectional communication starts at a PEP 300, comprises a plurality of PDP 320, 320’, and ends at an entity 310, as previously discussed. The first encrypted message 321 comprises an encrypted challenge and encrypted metadata of a request 301 from the entity 310, and wherein the metadata is indicative of the request 301 and the plurality of PDPs 320, 320’. The PEP 300 may be the PEP 300 shown in FIG. 3 or FIG. 5. The entity 310 may be the entity 310 shown in FIG. 3 or FIG. 5.

The PDP 320 is further configured to generate a first decrypted message 322 by decrypting the first encrypted message 321 using a private key of the PDP 320. Further, the PDP 320 is configured to obtain the metadata from the first decrypted message 322, make a decision on whether to permit the request 301, and provide a third message 323 indicative of the decision further using the multi-hop unidirectional communication to the next hop.

According to an embodiment of this disclosure, the first encrypted message 321 may be received from the entity 310. That is, the first encrypted message is forwarded by the entity 310 from the PEP 300.

Optionally, if the PDP 320 denies the request 301, it may generate a garbage message, which has a length that is predicted to be the same as a length of the first decrypted message 322, and send this garbage message to the next hop.

Notably, the metadata obtained by the PDP 320 after encryption may be further indicative of an order of the plurality of PDPs 320, 320’, which are hops of the multi-hop unidirectional communication.

As previously discussed, the next hop may be a next PDP 320’ on the unidirectional chain, or may be the entity 310 if the PDP 320 here is the last PDP on the chain.

For instance, according to a previous embodiment, particularly the non-recursive embodiment, the encrypted message received by the PDP 320 may comprises k encrypted PDP-dedicated messages. That means, the first encrypted message 321 may comprise a first part that is dedicated to the PDP 320, and a second part that is for other PDPs 320’. In this case, the PDP 320 may decrypt the first part of the first encrypted message 321 to obtain a first part of the first decrypted message 322. Accordingly, the first decrypted message 322 comprises the first part of the first decrypted message 322, and the second part of the first encrypted message 321. Accordingly, the PDP 320 may also send a decision indicator indicative of whether the request 301 is permitted by it, using the multi-hop unidirectional communication to the next hop.

The PDP 320 according to embodiments of this disclosure operates accordingly as described in the embodiments with respect to FIG. 2 to FIG. 12. Other details are not repeated here.

FIG. 14 shows an entity 310 according to an embodiment of the disclosure. The entity 310 shown here may be the entity 310 as shown in FIG. 3 or FIG. 5. In particular, the entity 310 may refer to the client who requests for a decision. The entity 310 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the entity 310 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as ASICs, FPGAs, DSPs, or multi-purpose processors. The entity 310 may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the entity 310 to be performed. In one embodiment, the processing circuitry comprises 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 which, when executed by the one or more processors, causes the entity 310 to perform, conduct or initiate the operations or methods described herein.

In particular, the entity 310 is configured to send a request 301 to a PEP 300. The entity 310 is further configured to receive an encrypted message 311 from a PDP 320 via a multi-hop unidirectional communication. In particular, the multi-hop unidirectional communication starts at the PEP 300, comprises a plurality of PDP 320, 320’, and ends at the entity 310. Further, the entity 310 is configured to decrypt the encrypted message 311 to obtain a decrypted message; sign the decrypted message using a private key of the entity 310; and send a signature 304 over the decrypted message to the PEP 300. Accordingly, the entity 310 is configured to receive a grant on the request 301 if the signature 304 is verified by the PEP 300.

Possibly, a quantity of the PDPs of the plurality of PDPs 320, 320’ may be k, k being a positive integer greater than 1, the encrypted message 311 may comprise k parts, each part corresponding to one PDP of the k PDPs.

According to an embodiment of this disclosure, particularly the non-recursive embodiment as previously described, the entity 310 may be configured to combine the k parts of the encrypted message 311, and decrypt the combined k parts to obtain the decrypted message.

According to another embodiment of this disclosure, particularly the “n out of k” embodiment as previously described, the entity 310 may be configured to decrypt each of the k parts to obtain a PDP-dedicated decrypted message. In such case, the entity 310 may be configured to sign each PDP-dedicated decrypted message using the private key of the entity 310. The signature 304 over the decrypted message thus may comprise k signatures over k PDP-dedicated decrypted messages.

It should be noted that the entity 310 according to embodiments of this disclosure operates accordingly as described in the embodiments with respect to FIG. 2 to FIG. 12. Other details are not repeated here.

FIG. 15 shows a method 1500 according to an embodiment of the disclosure. In a particular embodiment of the disclosure, the method 1500 is performed by a PEP 300 shown in FIG. 3, FIG. 5 or FIG. 14. The method 1500 comprises: a step 1501 of receiving a request 301 from an entity 310; a step 1502 of generating a first message 302 comprising a challenge and metadata of the request 301, wherein the metadata is indicative of the request 301 and of a plurality of PDPs; a step 1503 of encrypting the first message 302 using a public key of the entity 310 and a public key of each of the plurality of PDPs 320, 320’; a step 1504 of sending the encrypted first message 302 using a multi-hop unidirectional communication. In particular, the multi-hop unidirectional communication starts at the PEP 300, comprises the plurality of PDPs 320, 320’, and ends at the entity 310. The method 1500 further comprises a step 1505 of receiving a signature 304 over a second message from the entity 310, wherein the signature 304 over the second message is indicative of one or more decisions regarding the challenge made by the plurality of PDPs; and a step 1506 of making a final decision based on a validity of the signature 304 over the second message. Possibly, each of the plurality of PDPs 320, 320’ may be one of the PDP shown in FIG. 3, FIG. 5, FIG. 13 or FIG. 14. The entity 310 may be the entity shown in FIG. 3, FIG. 5, or FIG. 14.

FIG. 16 shows a method 1600 according to an embodiment of the disclosure. In a particular embodiment of the disclosure, the method 1600 is performed by a PDP 320 shown in FIG. 3, FIG. 5, FIG. 13 or FIG. 14. The method 1600 comprises a step 1601 of receiving a first encrypted message 321 via a multi-hop unidirectional communication. The multi-hop unidirectional communication starts at a PEP 300, comprises a plurality of PDP 320, 320’, and ends at an entity 310. In particular, the first encrypted message 321 comprises an encrypted challenge and encrypted metadata of a request 301 from the entity 310, and the metadata is indicative of the request 301 and the plurality of PDPs 320, 320’. The method 1600 further comprises a step 1602 of generating a first decrypted message 322 by decrypting the first encrypted message 321 using a private key of the PDP; a step 1603 of obtaining the metadata from the first decrypted message 322; a step 1604 of making a decision on whether to permit the request 301; and a step 1605 of providing a third message 323 indicative of the decision further using the multi-hop unidirectional communication to the next hop. Possibly, the PEP 300 may be the PEP 300 shown in FIG. 3, FIG. 5 or FIG. 14. The entity 310 may be the entity shown in FIG. 3, FIG. 5, or FIG. 14.

FIG. 17 shows a method 1700 according to an embodiment of the disclosure. In a particular embodiment of the disclosure, the method 1700 is performed by an entity 310 shown in FIG. 3, FIG. 5 or FIG. 14. The method 1700 comprises: a step 1701 of sending a request 301 to a PEP 300; a step 1702 of receiving an encrypted message 311 from a PDP 320, via a multi-hop unidirectional communication. In particular, the multi-hop unidirectional communication starts at the PEP 300, comprises the plurality of PDPs 320, 320’, and ends at the entity 310. The method 1700 further comprises a step 1703 of decrypting the encrypted message 311 to obtain a decrypted message; and a step 1704 of signing the decrypted message using a private key of the entity 310; a step 1705 of sending a signature 304 over the decrypted message to the PEP 300. Further, the method 1700 comprises a step 1706 of receiving a grant on the request 301 if the signature is verified by the PEP 300. Possibly, the PEP 300 may be the PEP 300 shown in FIG. 3, FIG. 5 or FIG. 14. The PDP 320 may be one of the PDP shown in FIG. 3, FIG. 5, FIG. 13 or FIG. 14. To summarize,

• Each PDP may contribute to the overall decision (access control, authorization) via a unidirectional (non-interactive) chain of communication, originating from the PEP and ending at the client, with the transmitted message including a protected challenge and protected metadata.

• Each PDP may remove one layer of protection from the message and examines the metadata. If the PDP approves the request, it will send the message (with one layer of protection removed) to the next PDP.

• The client may receive the message, which has only one layer of protection left if each PDP approved the request. Only in this case can the client remove the final layer of protection and produce a valid signature of the embedded challenge, which it will send to the PEP for verification.

• Recursive encryption can be used to protect the challenge and metadata in the basic variant (particularly Embodiments 1 and 2).

• The the above described methods may be integrated, for example, in an early phase of a TLS 1.3 handshake using ClientHello and HelloRetryRequest extensions.

• A customized ECIES variant with a static sender key pair may be used.

• Parallel (concatenated) encryption may be used in the non-recursive and in the “n out of k” variants of the methods proposed herein.

A main benefit of the techniques described herein is a better computational efficiency, allowing better scaling and a reduced number of transmissions compared to conventional solutions. The following table summarizes some potential benefits of this disclosure. Note that k denotes the number of PDPs.

Referring to “#Public-key crypto ops”, the number “2k+4” are actually symmetric-key operations, if static ECIES is used, further efficiency boost can be provided. FIG. 18 shows a calculation of number of public-key operations according to this disclosure. It can be seen that in the example that there are 3 PDPs, 10 operations in total is needed.

By contrast, FIG. 19 and FIG. 20 show number of public-key operations according to Conventional solution 1 and Conventional solution 2, respectively.

Referring to “//Transmissions”, in Conventional solution 1, 3 handshake messages flight per PDP, plus 2 application data transmissions. Conventional solution 2 does not provide PEP authentication, to rectify this, it would need to add the PEP’s signature to each plaintext, essentially doubling the number of public-key cryptographic operations per PDP. With respect to this disclosure, when using static ECIES, only the PEP can create valid ciphertexts.

In addition to performance, this disclosure provides two further advantages. These are described below.

One advantage is that, if the PEP sends the first message to the client instead of PDP k, as in Embodiment 2 of this disclosure, the PEP need not be in the same network as the PDPs. This can be a very useful feature in practice. For example, to prevent attacks, a secure door lock (PEP) may have no access to the Internet and the only way to communicate with the lock is to use NFC or Bluetooth - e.g. the lock is supposed to be opened by placing a specific smartphone on the lock. The smartphone naturally has full connection with the home network or the Internet. This disclosure allows the PEP to be in a different network than the PDPs.

An important distinguishing feature of this disclosure is unidirectional communication. This means that e.g. broadcast communication with UDP can be used instead of connection-based communication to transmit messages. This can also be very beneficial in some use cases. In short, this disclosure has fewer communication requirements than conventional solutions. Various embodiments of the invention have been described above. Other embodiments can be effected by persons skilled in the art based on the present disclosure. In the claims and in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Furthermore, any method according to embodiments of the disclosure may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program may be stored in a non-transitory computer readable medium. The computer readable medium may comprise e.g. a ROM (Read-Only Memory), a PROM (Programmable Read-Only Memory), an EPROM (Erasable PROM), a Flash memory, an EEPROM (Electrically Erasable PROM), or a hard disk drive, or a combination of such memories.

Moreover, the skilled person will realize that embodiments of the PEP 300, PDP 320 and the entity 310, respectively, comprise the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, trellis-coded modulation (TCM) encoders, TCM decoders, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

Processors in each of the PEP 300, PDP 320 and the entity 310, respectively, may comprise, e.g., one or more instances of a Central Processing Unit (CPU), a processing unit, a processing circuit, a processor, an ASIC, a microprocessor, or other processing logic that may interpret and execute instructions. The expression “processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

Claims

1. A policy enforcement point, PEP (300), for distributed decision-making, configured to: receive a request (301) from an entity (310); generate a first message (302) comprising a challenge and metadata of the request (301), wherein the metadata is indicative of the request (301) and of a plurality of policy decision points, PDPs (320, 320’); encrypt the first message (302) using a public key of the entity (310) and a public key of each of the plurality of PDPs (320, 320’); send the encrypted first message (303) using a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at the PEP (300), comprises the plurality of PDPs (320, 320’), and ends at the entity (310); receive a signature (304) over a second message from the entity (310), wherein the signature (304) over the second message is indicative of one or more decisions regarding the challenge made by the plurality of PDPs (320, 320’); and make a final decision based on a validity of the signature (304) over the second message.

2. The PEP (300) according to claim 1, wherein sending the encrypted first message (303) using the multi-hop unidirectional communication comprises: sending the encrypted first message (303) to a first-hop PDP (320) of the multi-hop unidirectional communication.

3. The PEP (300) according to claim 2, wherein sending the encrypted first message (303) to the first PDP of the multi-hop unidirectional communication comprises: sending the encrypted first message (303), along with an indication of the first-hop PDP (320) of the multi-hop unidirectional communication, to the entity (310); and causing the entity (310) to forward the encrypted first message (303) to the first-hop PDP (320) using the multi-hop unidirectional communication.

4. The PEP (300) according to one of the claims 1 to 3, wherein the request (301) is received from the entity (310) over a secured channel.

5. The PEP (300) according to claim 4, wherein the secured channel between the PEP (300) and the entity (310) comprises a transport layer security, TLS, connection, wherein the request (301) is received from the entity (310), and the encrypted first message (303) is sent to the entity (310), using TLS handshake messages.

6. The PEP (300) according to one of the claims 1 to 5, wherein encrypting the first message (302) comprises: recursively wrapping the challenge and the metadata using the public key of the entity (310) and then using the public keys of the plurality of PDPs (320, 320’) one after the other.

7. The PEP (300) according to claim 6, wherein a quantity of the PDPs (320, 320’) of the plurality of PDPs (320, 320’) is k, k being a positive integer greater than 1, wherein the recursive wrapping comprises k + 1 layers of wrapping, wherein recursively wrapping the challenge and the metadata comprises: encrypting the challenge and the metadata using the public key of the entity (310) to obtain a first layer of wrapping; and encrypting an nth layer of wrapping using the public key of PDP k + 1 - n to obtain an (n + l)th layer of wrapping, n being a positive integer and 1 < n < k, wherein PDP k + 1 - n represents the (k + 1 - n)th PDP of the plurality of PDPs (320, 320’) of the multi-hop unidirectional communication.

8. The PEP (300) according to claim 6 or 7, wherein one of the following encryption schemes is used for the recursive warping: 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, wherein static ECIES is used for the recursive warping, wherein the PEP (300) is further configured to: obtain the public key of the entity (310) and the public key of each of the plurality of PDPs (320, 320’), wherein the public key of the entity (310) and the public key of each of the plurality of PDPs (320, 320’) are predetermined.

10. The PEP (300) according to one of the claims 6 to 9, wherein the metadata is further indicative of an order of the plurality of PDPs (320, 320’), which are hops of the multi-hop unidirectional communication.

11. The PEP (300) according to one of the claims 1 to 5, wherein encrypting the first message (302) comprises: encrypting the challenge using the public key of the entity (310); splitting the encrypted challenge into k parts, k being a quantity of the PDPs (320, 320’) of the plurality of PDPs (320, 320’), k being a positive integer greater than 1, wherein each part of k parts corresponds to one PDP of the k PDPs (320, 320’); and encrypting each part of the k parts and the metadata using the public key of the corresponding PDP.

12. The PEP (300) according to one of the claims 1 to 11, wherein making the final decision based on the validity of the signature (304) over the second message comprises: granting the request (301) if it is determined that the signature (304) over the second message is valid; or denying the request (301) if it is determined that the signature (304) over the second message is not valid.

13. The PEP (300) according to claim 12, configured to: determine that the signature (304) over the second message is valid if it matches the challenge; or determine that the signature (304) over the second message is not valid if it does not matches the challenge.

14. The PEP (300) according to one of the claims 1 to 5, wherein a quantity of the PDPs of the plurality of PDPs (320, 320’) is k, k being a positive integer greater than 1, wherein the challenge comprises k PDP-dedicated challenges, each PDP-dedicated challenge corresponding to one of the k PDPs (320, 320’), wherein generating the first message (302) comprises: generating a PDP-dedicated challenge for each of the k PDPs (320, 320’).

15. The PEP (300) according to claim 14, wherein encrypting the first message (302) comprises: encrypting each PDP-dedicated challenge and the metadata using first the public key of the entity (310), and then the public key of the corresponding PDP, to obtain an encrypted PDP-dedicated message, wherein the encrypted first message (303) comprises k encrypted PDP-dedicated messages.

16. The PEP (300) according to claims 12 and 15, configured to: determine the decisions of at least n of the k PDPs (320, 320’); determine that the signature (304) over the second message is valid if the at least n of the k PDPs permit the request (301); or determine that the signature (304) over the second message is not valid if less than n of the plurality of PDPs permit the request (301), wherein n is a positive integer less than k.

17. The PEP (300) according to claim 16, wherein the signature (304) over the second message comprises k signatures over k PDP-dedicated messages, each signature over the PDP-dedicated message corresponding to one of the k PDPs (320, 320’), wherein determining the decision of at least n of the k PDPs (320, 320’) comprises: determining that a PDP (320) permits the request (301) if the signature over the PDP- dedicated message corresponding to that PDP (320) matches the PDP-dedicated challenge corresponding to that PDP (320); or determining that a PDP (320) denies the request (301) if the signature over the PDP- dedicated message corresponding to that PDP (320) does not match the PDP-dedicated challenge corresponding to that PDP (320).

18. The PEP (300) according to one of the claims 1 to 17, wherein the metadata is indicative of an identifier of each of the plurality of PDPs (320, 320’).

19. The PEP (300) according to one of the claims 3 to 18, wherein the PEP (300) and the plurality of PDPs (320, 320’) are located in different networks.

20. A policy decision point, PDP (320), configured to: receive a first encrypted message (321) via a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at a policy enforcement point, PEP (300), comprises a plurality of PDP (320, 320’), and ends at an entity (310), wherein the first encrypted message (321) comprises an encrypted challenge and encrypted metadata of a request (301) from the entity (310), and wherein the metadata is indicative of the request (301) and the plurality of PDPs (320, 320’); generate a first decrypted message (322) by decrypting the first encrypted message (321) using a private key of the PDP (320); obtain the metadata from the first decrypted message (322); make a decision on whether to permit the request (301); and provide a third message (323) indicative of the decision further using the multi-hop unidirectional communication to the next hop.

21. The PDP (320) according to claim 20, wherein receiving the first encrypted message (321) via the multi-hop unidirectional communication comprises: receiving the first encrypted message (321) 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, wherein the third message (323) comprises the first decrypted message (322), if the request (301) is permitted; or the third message (323) comprises a garbage message, if the request (301) is denied, wherein the garbage message is generated by the PDP (320), and has a length that is predicted to be the same as a length of the first decrypted message (322).

23. The PDP (320) according to one of the claims 20 to 22, wherein the metadata is further indicative of an order of the plurality of PDPs (320, 320’), which are hops of the multi-hop unidirectional communication.

24. The PDP (320) according to claim 20, wherein the first encrypted message (321) comprises a first part that is dedicated to the PDP (320), and a second part that is for other PDPs (320’) of the plurality of PDPs (320, 320’), wherein decrypting the first encrypted message (321) comprises decrypting the first part of the first encrypted message (321) to obtain a first part of the first decrypted message (322), wherein the first decrypted message (322) comprises the first part of the first decrypted message (322), and the second part of the first encrypted message (321).

25. The PDP (320) according to claim 24, wherein providing the third message (323) indicative of the decision using the multi-hop unidirectional communication to the next hop comprises: sending the first decrypted message (322) and a decision indicator indicative of whether the request (301) is permitted by the PDP (320) using the multi-hop unidirectional communication to the next hop.

26. The PDP (320) according to claim 24 or 25, configured to: generate an indicator for the next hop, wherein the indicator indicates that the PDP (320) has made the decision; and provide the indicator to the next hop.

27. An entity (310), configured to: send a request (301) to a policy enforcement point, PEP (300); receive an encrypted message (311) from a policy decision point, PDP (320), via a multi hop unidirectional communication, wherein the multi-hop unidirectional communication starts at the PEP (300), comprises a plurality of PDP (320, 320’), and ends at the entity (310); decrypt the encrypted message (311) to obtain a decrypted message; sign the decrypted message using a private key of the entity (310); send a signature (304) over the decrypted message to the PEP (300); and receive a grant on the request (301) if the signature (304) is verified by the PEP (300).

28. The entity (310) according to claim 27, wherein a quantity of the PDPs of the plurality of PDPs (320, 320’) is k, k being a positive integer greater than 1, wherein the encrypted message (311) comprises k parts, each part corresponding to one PDP of the k PDPs, wherein decrypting the encrypted message (311) to obtain the decrypted message comprises: combining the k parts of the encrypted message (311); and decrypting the combined k parts to obtain the decrypted message.

29. The entity (310) according to claim 27, wherein a quantity of the PDPs (320,

320’) of the plurality of PDPs (320, 320’) is k, k being a positive integer greater than 1, wherein the encrypted message (311) comprises k parts, each part corresponding to one PDP of the k PDPs (320, 320’), wherein decrypting the encrypted message (311) to obtain the decrypted message comprises: decrypting each of the k parts to obtain a PDP-dedicated decrypted message.

30. The entity (310) according to claim 29, wherein signing the decrypted message comprises: signing each PDP-dedicated decrypted message using the private key of the entity

(310), wherein the signature (304) over the decrypted message comprises k signatures over k PDP-dedicated decrypted messages.

31. A method (1500) performed by a policy enforcement point, PEP (300), for distributed decision-making, comprising: receiving (1501) a request (301) from an entity (310); generating (1502) a first message (302) comprising a challenge and metadata of the request (301), wherein the metadata is indicative of the request (301) and of a plurality of policy decision points, PDPs (320, 320’); encrypting (1503) the first message (302) using a public key of the entity (310) and a public key of each of the plurality of PDPs; sending (1504) the encrypted first message (302) using a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at the PEP (300), comprises the plurality of PDPs (320, 320’), and ends at the entity (310); receiving (1505) a signature (304) over a second message from the entity (310), wherein the signature (304) over the second message is indicative of one or more decisions regarding the challenge made by the plurality of PDPs (320, 320’); and making (1506) a final decision based on a validity of the signature (304) over the second message.

32. A method (1600) performed by a policy decision point, PDP (320), comprising: receiving (1601) a first encrypted message (321) via a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at a policy enforcement point, PEP (300), comprises a plurality of PDP (320, 320’), and ends at an entity (310), wherein the first encrypted message (321) comprises an encrypted challenge and encrypted metadata of a request (301) from the entity (310), and wherein the metadata is indicative of the request (301) and the plurality of PDPs; generating (1602) a first decrypted message (322) by decrypting the first encrypted message (321) using a private key of the PDP; obtaining (1603) the metadata from the first decrypted message (322); making (1604) a decision on whether to permit the request (301); and providing (1605) a third message (323) indicative of the decision further using the multi hop unidirectional communication to the next hop.

33. A method (1700) performed by an entity (310), comprising: sending (1701) a request (301) to a policy enforcement point, PEP (300); receiving (1702) an encrypted message (311) from a policy decision point, PDP (320), via a multi-hop unidirectional communication, wherein the multi-hop unidirectional communication starts at the PEP (300), comprises a plurality of PDPs (320, 320’), and ends at the entity (310); decrypting (1703) the encrypted message (311) to obtain a decrypted message; signing (1704) the decrypted message using a private key of the entity (310); sending (1705) a signature (304) over the decrypted message to the PEP (300); and receiving (1706) a grant on the request (301) if the signature is verified by the PEP (300).

34. A computer program comprising a program code for carrying out, when implemented on a processor, the method (1500, 1600, 1700) according to one of the claims 31 to 33.