 Hi everyone, I'm Hendrik Waldner and this talk is about policy-compliant signatures, which is joint work with Christian Vardetscher and Christian Mutt. Starting with some motivation, we consider the standard blockchain setting, where we have two parties, Alice and Bob, that are both in possession of a signature key pair. If Alice now wants to create a transaction for Bob, she uses her signing key to generate a signature over the transaction details M and the verification key of Bob. The generated transaction can then be checked for validity using the verification key of Alice. Furthermore, we require unfortability in this setting, which means that no one other than Alice should be able to create a valid signature in her name. In this talk, we consider the more restricted setting, where we require a valid transaction to also fulfill the global policy F evaluated over the attributes of the sender and the receiver. A blockchain that allows for these types of attribute checks can be very useful within corporate environments to only allow for transactions between employees of different departments. In this setting, the key pairs of Alice and Bob are additionally associated with an attribute set XA and XB. To generate a signature, Alice proceeds similarly to the previous case and uses her signing key together with the transaction details M and the public key of Bob. The generated signature is now deemed valid if the policy F applied on the attribute set XA of Alice and XB of Bob verifies. In this setting, we also require unfortability, which means, as in the previous case, that no one other than Alice should be able to create a valid signature in her name. And additionally, that Alice and Bob should not be able to create a valid signature if they do not fulfill the global policy. Furthermore, we require attribute hiding, which means that nothing about the attributes of the different parties is leaked by the public keys. And the generated signatures only reveal that the attributes of the participating parties fulfill the policy and nothing beyond that. Next we are going to see which existing cryptographic primitives we could use to achieve this goal. The first primitive that could be useful in this setting are digital signatures. In a digital signature scheme, there exists a party Carol that executes the setup procedure that outputs a verification key VK and a secret key SK. Carol then sends the verification key to Bob and the secret key to Alice. Alice can use the secret key to sign a message M and generate the corresponding signature Sigma. The verification key can then be used to check if the signature Sigma is valid with respect to the message M. Unfortunately, this primitive does not incorporate any attributes of the sender or the receiver and is therefore not useful in our setting. An extension of digital signatures that incorporates attributes is the notion of attribute-based signatures. In an attribute-based signature scheme, Carol executes the setup procedure to generate a master public key and a master secret key. The master secret key is then used by Carol together with an attribute set XA to generate the signing key SKA of Alice. Alice then uses her signing key SKA to generate a signature Sigma for a message M and a policy F. This signature can then be verified using the master public key and the policy F. The signature in this case is only valid if the attributes XA of Alice fulfill the policy F. The notion of attribute-based signatures incorporates attributes into the signature generation, but unfortunately only the attributes of the sender are incorporated, which is still insufficient for our setting. Another type of signature that handles attributes is the notion of policy-based signatures. Policy-based signatures work similarly to attribute-based signatures with the difference that signing keys are generated with respect to a policy F instead of an attribute set. Furthermore, during the signature generation, Alice needs to provide a witness W for a relation that involves the policy F associated with a signing key and the message that is being signed. A signature now is only deemed valid if the witness W that has been used in the signature generation is a valid witness for the relation involving the policy F of the signing key and the message M. One way to allow for the incorporation of Bob's attributes in this notion would be by including some public information of Bob in the message M that is being signed. The problem here is that for the signature generation, Alice needs to know Bob's attributes to prove that both of their attributes together fulfill the policy. Therefore, we cannot guarantee privacy for Bob in this setting, which makes this notion unsuitable for our motivational example. Since none of the previous primitives fit our motivational example, we now introduce the new notion of policy-compliant signatures. In a policy-compliant signature scheme, Carol executes the setup procedure which takes as an input a policy F and outputs a master public key and a master secret key. She then uses the master secret key together with an attribute set to generate a public key secret key pair. In more detail, she uses the attribute set XA to generate the keys for Alice and the attribute set XB to generate the keys for Bob. To generate a signature, Alice uses her secret key together with the public key of Bob and the message M in the signing procedure. The resulting message signature pair can then be verified using the master public key and the public keys of Alice and Bob. A signature only verifies if the global policy F is fulfilled when evaluated using the attributes XA of Alice and XB of Bob. We can directly see that the notion of policy-compliant signatures provides a good solution for our motivational example. To achieve unforgeability and attribute hiding in our motivational example, our policy-compliant signature scheme also needs to achieve these notions. Before we can talk about how to achieve these notions, we first need to formally define them. We begin with the notion of unforgeability. In the case of unforgeability, we have three different types of forgeries that we need to prevent. The first type of forgery is what we call a key generation forgery. In a key generation forgery, a malicious Alice is able to generate a valid signature for a public key that has not been generated by Carol. Since Carol did not assign any attributes to this maliciously generated public key, it cannot result in a valid policy evaluation. In a signature forgery, an adversary is able to create a signature corresponding to Alice's public key without knowing her secret key. This type of attack is similar to the standard notion of unforgeability for a digital signature scheme. In the third and last type of forgery, an attribute forgery, a malicious Alice and a malicious Bob are able to jointly create a valid signature even though their attributes do not fulfill the policy. After informally talking about the different types of attacks we need to prevent, we are now going to formally define unforgeability using a security game. In this security game, an adversary has access to different oracles that are run by a challenger and can be queried multiple times. The first oracle that the adversary can access is the key generation oracle. It queries it using an attribute set x and receives as a reply the corresponding public key pk. Additionally, the adversary can also query a corruption oracle using one of the public keys that have been previously output by the key generation oracle to obtain the corresponding secret key. The last oracle that the adversary has access to is the signing oracle. Inputting a sender public key pks, a receiver public key pkr and a message m, the adversary obtains a signature sigma for the message m. After the adversary has interacted with the different oracles, its goal is to output two public keys pk and pk star, a message m star and a signature sigma star such that the signature sigma star is a valid signature with respect to the public keys pk and pk star and the message m star. For the adversary to provide a valid signature forgery, it needs to provide one of the different types of attacks that we have previously described. This is the case if it either holds that the sender public key pk has not been query to the corruption oracle or if both of the public keys pk and pk star have been output by the key generation oracle and their corresponding attribute sets x and x star do not fulfill the policy f. We call a policy compliant signature scheme unfortable if it is impossible for any efficient adversary to produce a valid signature forgery. After talking about unforgeability, we now focus on attributiding where we distinguish between an indistinguishability based and a simulation based notion. We start by considering the indistinguishability based notion. As in the case of unforgeability, we define indistinguishability based attribute hiding using a security game. In this game, the adversary has access to the same oracles as before but with a different input output behavior. Also in this game, the adversary can query all of the oracles multiple times. The key generation oracle in this game can be queried using two attribute sets x0 and x1. The adversary then receives as a reply to this query a public key pk that has been generated with respect to the attribute set xb where b is a bit that is sampled in the beginning of the game. The goal of the adversary in this game after it has finished querying the different oracles is to correctly determine the bit b by outputting a bit b prime. A policy compliant signature scheme achieves indistinguishability based attribute hiding if the probability that the output bit b prime is equal to b is close to one half for all efficient adversaries. Besides the key generation oracle, the adversary also has access to a corruption oracle which it can query using a public key pk to obtain the corresponding secret key sk. To not make it trivial for the adversary to determine the bit b and therefore win the security game, it can only query the corruption oracle using public keys that have been the reply to a key generation query where the attribute sets x0 and x1 are equal. If we do not enforce this restriction, the adversary might be able to directly learn the bit b. The signing oracle in this game behaves exactly as in the unforgeability game but we also need to enforce an additional restriction on the queries of the adversary here. Namely, we require that the policy evaluated on the left challenge attributes of the sender key pkx and the receiver key pky used in the signing query are equal to the policy evaluated on the right challenge attributes of the sender and the receiver key. Otherwise, the adversary might again be able to directly learn the bit b. After defining unforgeability and indistinguishability-based attribute hiding, we can now consider some construction approaches for policy-compliant signatures. The first approach to realize policy-compliant signatures is by relying on Carol. In more detail, if Alice wants to generate a signature for Bob, she submits her message to Carol together with Bob's identifier and receives as a reply the signature sigma. Afterwards, Bob can send the signature together with a message and Alice identifier to Carol who outputs either 0 or 1. Unfortunately, this solution requires the involvement of Carol for every signature generation and verification but we would like to have a solution where Carol is only needed for the generation of the public parameters and the keys of the different parties such that Alice can generate the signatures on her own and everyone can verify them on their own. The second approach to realizing policy-compliant signatures is to let Carol issue signature keys together with a certificate that corresponds to the attributes of the corresponding party. For the generation of a signature, Alice would then use her signing key to generate a signature for her message and additionally prove using both of the verification keys and the certificates that her attributes together with the attributes of Bob fulfill the global policy. When Bob obtains the proof and the signature, he can verify the signature generated for the message as well as the proof that the attributes of Alice and Bob together fulfill the policy. This solution looks like a good solution at first sight but it has the drawback that it does not give us any guarantees in terms of privacy. This is due to the fact that for Alice to prove that her attributes together with Bob's attributes fulfill the global policy, she needs to know Bob's attributes which directly compromises privacy. After considering these first approaches for the realization of policy-compliant signatures, we now introduce the necessary tools for our final construction. The first tool that is needed for our construction is a digital signature scheme which we have already introduced. Additionally our construction also requires a non-interactive zero-knowledge proof system which is similar to the proof system that we have mentioned in the previous construction approach. The last primitive that we need for our construction is a predicate encryption scheme which allows for the oblivious evaluation of policies without revealing the underlying attributes. We now describe the different primitives in more detail where we begin with non-interactive zero-knowledge proofs. In the first step of a non-interactive zero-knowledge proof, a setup procedure is executed by Carol that outputs a common reference string which is then sent to Alice and to Bob. If Alice now wants to prove the validity of a statement x for which she knows a witness w, then she can generate a proof pi using the CRS, the statement x and the witness w. This proof is then sent to Bob who can verify it using the statement x and the common reference string. We require a zero-knowledge proof system to achieve soundness and zero-knowledge. Soundness ensures that it is not possible for malicious Alice to generate a valid proof for statements x for which no witness w exists and zero-knowledge in turn guarantees that when Bob obtains the proof pi, he does not learn anything about a witness w for the statement x. After introducing non-interactive zero-knowledge proofs we can now focus on predicate encryption. In a predicate encryption scheme, the setup procedure executed by Carol outputs a master public key and a master secret key. The master public key can then be used by Alice to generate a ciphertext ct encrypting an attribute set x. The master secret key in turn is used by Carol to generate a functional key skf that is associated with a policy f. When Bob uses this functional key to decrypt the ciphertext ct, he obtains as an output the policy associated with the functional key applied on the attribute set encrypted in the ciphertext which in this case is f of x. We require a predicate encryption scheme to be attribute hiding, which means that Bob, when decrypting a ciphertext, does not learn anything more about the encrypted attribute set than what is leaked by the evaluation of the policy f. In our construction of policy compliant signatures we only require the predicate encryption scheme to be secret key, which means that the setup procedure only outputs a master secret key that is used for encryption and key generation. After introducing the necessary tools for our construction we are now ready to give a high-level overview of how our construction works. The idea of our construction is to use a predicate encryption scheme to encrypt the attributes of the different parties in the public keys and use the corresponding functional key as part of the secret keys of the different parties for the policy evaluation. To generate a signature the sender decrypts the ciphertext contained in the public key of the receiver and proves in zero knowledge that the decryption output together with its functional key shows that the policy is fulfilled. It can then be verified that the global policy is fulfilled by checking the validity of the generated proof. In more detail the master public key of our scheme consists of a common reference string for non-interactive zero knowledge proof and two verification keys for a digital signature scheme vkp and vks. The corresponding master secret key consists of the master secret key for a predicate encryption scheme and the signing keys skp and sks that correspond to the verification keys vkp and vks. To generate a public key for a participating party a new digital signature key per is sampled where the verification key vk is included in the public key. Furthermore the attributes of the party are encrypted using the predicate encryption scheme and the resulting ciphertext is included in the public key. Finally a signature sigma p is generated using the signing key skp for the verification key vk and the ciphertext ct and is also included in the public key. The corresponding secret key for the public key consists of the signing key sk which has been generated together with the verification key vk and a functional key skf that is generated for the policy f evaluated on the first component using the attribute set x of the party. This half evaluated policy enables us to obliviously check if the sender and the receiver together fulfilled the policy without revealing anything about their attributes. In the last step another signature sigma s is generated using the signing key sks for the verification key vk of the public key and the functional key skf to bind the public key and the secret key together. To generate a signature the sender uses its functional key to decrypt the ciphertext contained in the public key of the receiver and produces the proof pi using the zero-knowledge proof system by proving that the output of the decryption is one and that the functional key that has been used to generate the decryption is part of the secret key that corresponds to the public key of the sender. The generated proof ensures that the policy is fulfilled by both of the parties and that the correct key of the sender has been used. In the final step the sender uses its signing key sk to generate a signature sigma prime over the message m and to prove pi. The resulting signature sigma prime can then be publicly verified by verifying the zero-knowledge proof pi and the signature sigma of the digital signature scheme. We highlighted all the primitives used in our construction can be based on standard assumptions which in turn results in the realization of policy compliant signatures from standard assumptions. After describing how our construction works we now discuss its security where we first focus on unforgeability. We can argue that our scheme is unforgeable by analyzing the different events in which an adversary construct a signature forgery and show that the occurrence probability of these events are bounded by the security of our underlying primitives. The first way for an adversary to produce a forgery is to generate a public key on its own for which it is able to produce a valid signature. The generation of a public key without carol's involvement would result in a signature forgery with respect to the verification key vkp and can therefore be bounded by the unforgeability of the digital signature scheme. Another possibility for an adversary to generate a forgery is by forging a signature for a public key in the system for which it does not know the secret key. In this case the adversary could use a proof pi from a previous signature generated for this key and try to forge a signature with respect to the verification key vk for a new message m prime. If the adversary is successful in this case it has created a signature forgery with respect to the verification key vk. Therefore the occurrence of this event can also be bounded by the unforgeability of the digital signature scheme. A third way for an adversary to produce a signature forgery is by generating a valid signature for public keys that do not fulfill the policy. It can achieve this by either forging a zero-knowledge proof or by creating a valid witness on its own. In the case that an adversary forges a zero-knowledge proof without knowing a witness it breaks the extractability property of the underlying non-interactive zero-knowledge protocol. Extractability requires that an adversary is not able to generate a valid proof for a statement if it is not in possession of a corresponding witness. This is a stronger property than soundness where it is only required that an adversary is not able to generate a valid proof for a false statement. One possibility for the adversary to generate a valid witness is by taking the secret key of a public key that fulfills the policy and forge a signature sigma prime with respect to the verification key of the public key that does not fulfill the policy. This forged key can then be used to generate a valid proof pi with respect to the public key that does not fulfill the policy. This attack results in a signature forgery with respect to the verification key vks and can therefore be again bounded by the unforgeability of the digital signature scheme. This concludes the analysis of the unforgeability of our construction and we can now take a more detailed look into the attribute hiding of our scheme. To achieve attribute hiding we need to ensure that nothing about the attributes of the participating parties is leaked from the public keys and that the generated signatures between different parties only reveal that the attributes fulfill the policy and nothing beyond that. Since the only part in the public key that contains information about the attributes of the party is the ciphertext ct it follows from the attribute hiding of the predicate encryption scheme that nothing about the attributes of the parties is leaked by the public keys. To ensure that no information beyond the policy evaluation is leaked by signature sigma prime we can rely on the zero-knowledge property of our proof system. The zero-knowledge property states that no information beyond the validity of the statement that is being proven is leaked which in our case is the fulfillment of the policy. This concludes our analysis of the indistinguishability-based attribute hiding. Besides standalone security we also analyze the security of policy-compliant signatures in the universal composability framework. Before doing so we give a high-level overview of the UC framework. In the UC framework we consider two different worlds the real world and the ideal world. In the real world we have a protocol that is executed by Alice and Bob and can further be influenced by an adversary. In the ideal world we have Alice and Bob that interact with an ideal functionality F which is also accessed by an ideal adversary called the simulator. The inputs of Alice Bob and the adversary are decided by an environment Z in both of these worlds. We say that a scheme is UC secure if there exists a simulator such that it is hard for any efficient environment Z to determine if it interacts with the real world or the ideal world. The job of the simulator here is to properly simulate the interaction in the ideal world such that the environment cannot see a difference with respect to the real world. The intuition behind this definition of security is that all the attacks that can be executed in the protocol execution in the real world can also be executed in the ideal world through the simulator. The same holds in terms of leakage. In more detail it follows that the information that is leaked in the protocol execution is the same as the information that is leaked by the ideal functionality. This security definition further allows that whenever the ideal functionality is used as a subroutine in the bigger protocol execution it can be replaced by the specific protocol for which your serialization has been proven. This is known as the composition theorem. Before presenting the ideal functionality that can be realized using policy-compliant signatures we focus on the ideal functionality that is realized by a digital signature scheme. The signature functionality has interfaces to interact with Alice and Bob. Alice can use her interface to send a key generation request to the ideal functionality which then forwards this request to the simulator. The simulator replies to this request with a key identifier V that is then sent back to Alice. Afterwards for the signature generation Alice sends M as a sign request to the ideal functionality as in the case of a key generation request the ideal functionality forwards the request to the simulator which replies with the signature sigma that is then sent to Alice by the ideal functionality. If Bob is in possession of a signature sigma for a message M of Alice he can send a verify request consisting of Alice identifier, the message and the signature to the ideal functionality. The ideal functionality then forwards the verification request to the simulator which replies to the ideal functionality if the signature is valid or not. This answer is then forwarded to Bob by the ideal functionality. The signature functionality also guarantees unforgability which means that no signature for a message that has never been used in a sign request by Alice will be deemed valid with respect to her identifier V. The described signature functionality can be realized using a protocol where Alice uses the setup procedure of a digital signature scheme to generate her key pair and uses the verification key as her identifier. To sign a message Alice executes the sign procedure using her signing key. Bob can then use the verification procedure together with Alice verification key to check a signature for its validity. The simulator in the ideal world for the signature functionality generates a key pair when a key generation query is forwarded to it by the signature functionality and replies with the verification key as the corresponding identifier. Whenever the simulator receives a sign query it uses the sign procedure of the signature scheme to generate a signature with the signing key that corresponds to the verification key contained in the sign query and whenever a verification query is asked the simulator locally executes the verify procedure using the corresponding verification key and sends the output as a reply to the ideal functionality. The unforgability of the signature scheme in this setting ensures that no one other than Alice is able to generate a valid signature for a new message with respect to her identifier which matches the unforgability guarantee of the ideal functionality. After focusing on the ideal functionality for a digital signature scheme we now consider the extended policy compliant signatures functionality. The policy compliant signature functionality consists of an additional interface to Carol. Carol can use this interface to submit a policy generation query for policy f to the ideal functionality which forwards it to the simulator. The simulator then replies to the ideal functionality with a master identifier vm. This master identifier is then forwarded to Carol. When Alice issues her key generation query she additionally submits her attribute zxa to the ideal functionality which then notifies the simulator that a key generation query has been asked for Alice without revealing the attribute zxa. The simulator then replies to the ideal functionality with an identifier va which is then forwarded to Alice. When Bob issues his key generation query using the attribute zxb the ideal functionality and the simulator interact in the same way as before to obtain the identifier vb. When Alice issues a sign query she submits Bob's identifier vb and the message m to the ideal functionality which forwards this query to the simulator together with the policy evaluation over the attributes of Alice and Bob. The simulator then replies with a signature sigma that is forwarded by the ideal functionality to Alice. For verification query Bob submits the signature together with the message and the identifier of the sender and the receiver to the ideal functionality which forwards this query to the simulator. The simulator then notifies the ideal functionality if the signature is valid or not which is forwarded to Bob. We highlight that it is also possible to submit a corrupt query for the different parties to the ideal functionality. If a corrupt query is submitted the simulator learns the attribute set for the party that is being corrupted as well as the evaluation with all the remaining public keys where the corrupted party acts as the sender. In the case that another key generation query is asked after a corruption query the simulator also learns the policy evaluation for this new key with all the corrupted parties acting as senders. The policy compliance signature functionality guarantees unforgeability and privacy. Unforgeability here means that first no one other than Alice is able to generate a valid signature for her identifier. Second that it is not possible to generate a valid signature for two identifiers where the corresponding parties do not fulfill the policy. And third that no valid signature can be generated with respect to identifiers that have not been output by the ideal functionality. Privacy in this setting means that nothing more about the attributes of the different parties can be learned than what is leaked by generated signatures and corrupted parties. The policy compliance signature functionality can be realized using a protocol where the setup and key generation procedure are executed by Carol to generate the master public key and the master secret key as well as the keys for Alice and Bob. For Alice to generate a signature she can execute the sign procedure using Bob's public key and her secret key to sign a message M and Bob can verify the signature using the verify procedure of the policy compliance signature scheme. In the ideal world the simulator needs to sample all the keys using the information it obtains from the ideal functionality as described on the previous slide. We observe that for the simulator to be able to accomplish this and to guarantee privacy it needs to be able to simulate public keys without knowing the underlying attribute sets and to be able to simulate signatures by only knowing the corresponding policy evaluation of the involved parties. Furthermore it needs to be able to generate a secret key for a previously generated public key in the case of a corruption query by learning the corresponding attribute set after the public key has been generated. The existence of such a simulator is not guaranteed by our current indistinguishability based attribute hiding definition. Contrary, unforgeability in the ideal world directly follows from the unforgeability of the policy compliance signature scheme which is due to the fact that the unforgeability requirements on the policy compliance signature scheme match the unforgeability requirements of the ideal functionality. To guarantee privacy in the ideal world we need to consider a stronger simulation based attribute hiding notion that guarantees the existence of a simulator that is able to simulate the different keys and signatures. In the simulation based security game the adversary has access to the same oracles as in the indistinguishability based one but instead of distinguishing between the left or right attribute set used for the generation of public keys the task of the adversary is to distinguish if the keys and signatures it receives are simulated or honestly generated. For the simulator to generate these keys it obtains some additional information. In the case of a key generation query the simulator learns all the policy evaluations of the requested key with all the corrupted keys where the corrupted keys act as sender keys. In the case of a corruption query the simulator learns the attributes of the key as well as all the policy evaluations of this key acting as the sender key with all the remaining keys. In the case of a sign query the simulator learns the policy evaluation of the attributes associated with the keys that are used in the query. This notion is sufficient for our UC realization and guarantees the existence of the simulator that is able to generate the different keys and signatures in a proper way. Additionally, we highlight that if the simulation-based secure predicate encryption scheme is used as an instantiation in our construction, then we also obtain a simulation-based secure policy-compliant signature scheme. Unfortunately, we are not aware of any predicate encryption that achieves the required notion of simulation-based security. Therefore, we leave it as an interesting open question to construct simulation-based secure policy-compliant signatures. To summarize, in this talk we have introduced the notion of policy-compliant signatures together with the corresponding notion of unforgibility and indistinguishability-based attribute hiding. Furthermore, we presented a policy-compliant signature scheme based on digital signatures, non-interactive zero-knowledge proofs, and predicate encryption that achieves unforgibility and indistinguishability-based attribute hiding. In the last step, we also gave a UC formulation of our notion and presented the corresponding simulation-based notion of attribute hiding that is needed to realize our UC formulation. Thank you very much for listening.