 Hello everyone, I am Olivier Sanders and this is my presentation of the paper Improving Revocation for Group Signature with Redactable Signature. In this paper, we will consider the notion of group signature, which is probably one of the main privacy preserving primitives. A group signature scheme allows users to join a group managed by a group manager by interacting with this entity. At the end of the interaction, the user receives a signing key, which essentially consists in some certificate that attests that the user has indeed joined the group. And the interest of group signature is that users, once they have joined the group, can sign on behalf of the group. And in particular, the point is that the signatures are anonymous, except for an appointed entity, which can be the group manager or some other entity depending on the model. The interest of group signature is that, in particular, it allows anonymous access to a service, meaning that the verifier will be able to check that the user is a valid user, but he won't be able to identify him. Group signatures are now standardized at ESO and many variants, such as direct anonymous attestation or EPID, are now embedded in billions of devices. The main problem with group signature is that adding users is very easy for most systems. But once the users have joined the group, it becomes very difficult to revoke them. It's actually normal for a signature scheme, which is anonymous because it's very difficult for the verifier to decide if a user has produced a group signature using a revoke key or not. This explains why most group signature schemes do not consider revocation. But the problem is that you cannot simply rule out this event, because it is actually quite common for most systems. For example, revocation may be necessary when the subscription of a user ends. Moreover, this can happen when the user loses his credentials or simply when a user does not comply with the rules of the services. So there are many reasons that may lead to revocation, and it is necessary to provide a way to do it efficiently. Actually, for existing group signatures, there are essentially three families of revocation systems. The first strategy is the one where the group manager will generate a new public key and then run the join algorithms with every unrevoked users. The interest of this revocation strategy is that it does not impact the signature of the verification process, and moreover it works with any group signature scheme. But it is highly unpractical for the group manager. We will have to run these join algorithms with every unrevoked users. Moreover, this means that the users, the legitimate users, won't be able to perform, to produce valid group signature until they have joined the group again. So it's a revocation strategy that should be used only in exceptional cases. In particular, you don't want to do that each time a user unsubscribes to the service. The second revocation strategy is the one where the group manager publishes so-called update information at the beginning of each time period of the system. So using this update information, the user will be able to prove that he is indeed a group member, but also that he is still active at this time period. So another problem is that this means that the user must retrieve this information at the beginning of each time period when he wants to generate a signature, which is obviously a problem if his credentials are embedded in a non-connected device. Moreover, this means that the signature process will be more complex for him because he will not only prove that he is a member of the group, he will also have to prove that he has not been revoked. So it might be tempting at first sight to consider a large time period to avoid too often retrieval of update information. But the problem is that with this system, the revocation is only possible to the next time period. So if you consider large time period, you will have to wait for a long time before revoking a user, which can be a problem. So it's necessary to find a trade-off for the time period, but none of them is very satisfying. The last revocation strategy is called Verifier Revocation List. With such systems, the group managers can add some specific tokens to a so-called revocation list, and this token can be used by the verifier to check if a given signature has been generated by one of the revoked user. The main interest of this solution is that the revoked user are immediately added to the revocation list, so you can revoke user immediately. And for the users, it's very interesting because it does not change anything for them. They do not have to retrieve some specific information. They actually produce their signature as usual. The main drawback of this solution is that it's very complex for the verifier when the revocation lists are large, because for each revoked user, they will have to perform some complex operations, such as pairings, to check if the group signature were indeed issued by one of the revoked users. So there is actually no fully satisfying solution to revoke group signature. This may explain why several variants have been proposed and are widely used today. One of these variants is direct anonymous statistician, where it is possible to force users to use the same pseudonym. Since users can be forced to use the same pseudonyms, it means that you can revoke them. But the problem is that by doing that, you lose anonymity for all signers. You only retain a weaker notion of pseudonymity. Another solution has been proposed under the name of EPID. With EPID system, it's possible to revoke a user by adding one of their signatures on a so-called revocation list. And user to produce a new group signature will now have to prove that they did not generate one of the revoked signatures. So regarding anonymity, it's much better. But the problem is that complexity increases with the number of revoked signatures, because if you have a large revocation list, then the user will have to prove for any of the signatures that he has not generated this signature. So here again, none of these variants are fully satisfying. That's why true et al. have proposed a new variant of group signature, which is called group signature with time-bound keys. Here the main idea of group signature with time-bound keys is that there are two kinds of revocations. The first one is called natural revocation. And this is the kind of revocation that is predictable at the joining time. So typically, for example, this is the case of end of subscription. Because for example, if you join the group, if you subscribe to a group for one month, then you know that the signing rights might be deactivated, must be revoked in one month. And there is also premature revocation that is due to unpredictable events. So here, natural revocation will be ended by assigning an expiry period to each user key. This means that group signature can't be generated with this key after this time period. And premature revocation will be dealt with revocation list as in the strategy tree of group signature. So at first sight, it seems that we still have revocation list. So it seems that we do not improve anything with this primitive. But here's the idea that in cases where natural revocation will represent the largest part of revocation, it's very interesting as a solution. Because this means that you will have much shorter revocation list. So you will have a much more efficient verification process. And the state of the art today is a scheme by Emura et al. that use the revocation strategy two that I mentioned earlier to instantiate natural revocation. So what are the contributions of this paper? Our first contribution of this paper is a better granularity for group signature, for natural revocation of group signature. Indeed, the previous model proposed by Shwet Al only considers the notion of expiry time, meaning that the signing keys are useless after this expiry time. In particular, the users are active members of the group at once they have joined the group. So you cannot postpone the subscription of a user to the group. So in our case, we can deal with any set of time periods. For example, we can consider the case of a subscription that would start at a later period. For example, if you want to join a group, start in next month for a duration of one month. You can also consider much more complex situations where, for example, there will be a periodic access to a service. For example, a user that would use a public transport system but only during weekends and so on. You can actually consider any set of time periods. This has some important consequences on the security properties of the system. In particular, it means that revocation is no longer definitive or we will not speak of revoc user but rather active user or inactive user or active keys or inactive keys. That's roughly the same. And in particular, we now need to deal with the notion of both backwards and forward unlink abilities. And in particular, the fact that we consider any set of time periods rule out many solutions such as binary tree to represent the set of time periods because it won't be very efficient with this high granularity that we want. So to construct such kind of system, we will use a very different tool. We will use unlinkable, redactable signature scheme that was proposed by Kamini Chetal a few years ago. The idea of unlinkable, redactable signature is that you can issue one signature on a set of messages. And the idea is that given this signature sigma, you are able to derive a new signature, sigma prime, on the subset of these messages. For example, in my slide, sigma prime is valid, is derived only for the message M2. And by derived on M2, I mean that you only need to know M2 to verify this new signature sigma prime. And in particular, the interest of this solution is that the new derived signature are unlinkable. So given several sigma prime, you cannot decide if they were generated using the same sigma or not. So what is the basic idea of our system? In our system, we will essentially associate with each time period a message. And the properties, the following one, is that the message will be zero if the user is inactive at this time period. So during the joint process, the user will simply interact with the group manager to receive a redactable signature on this set of messages. And now to produce a group signature, it will simply derive a signature on the current set, on the current time period. And the group signature will be valid if the redactable signature is valid and if the associated message is not zero. In particular, this means that we do not have to publish update information. The user does not have to do anything once he has joined the group. It's very important, as I explained in particular, when we need to store the credentials in non-connective devices. Regarding security, we can prove that the trustability of the group signature directly relies on the unforgeability of the redactable signature scheme. In particular, this means that if a user managed to produce a valid group signature without joining the group, or if he managed to illegally extents his signing rights by publishing a signature generated for a time period where his signing keys are deactivated, then he necessarily have broken the unforgeability of the redactable signature scheme. Regarding non-forgeability, we need to define the set of non-zero messages as the user's secret key. This will have an important consequence. It means that the non-zero message cannot be revealed. This will prevent us from using some specific unincurable redactable signatures. And for premature revocation, we will use the standard strategy which consists in generating tokens that can be used to revoke user at a given time period. Here, we must be very careful because we want this token to revoke the user for this time period, but they must be useless for signature issues before this time period and after this time period. This means that we aim at both backward and forward unlinkability. And the consequence here is that anonymity will need more than simple unlinkability of the redactable signature scheme. And in particular, this means that we need some specific redactable signature schemes. And moreover, this means that the basic idea that I have described in my previous slide does not exactly work as it is. We need something more complex. We need to address some subtleties, but if you have understood the basic idea, I think it will be very easy to understand the more complex scheme described in the paper. So, we need some specific redactable signature schemes. And actually, one of them was recently proposed in the PICAC 2020. And it fulfills all the necessary requirements, but it requires quadratic, it suffers from a limitation regarding the size of the public key because the public key are of quadratic size, which is obviously a problem for large number of time periods. For example, in our system, if we consider time period of one day for the next three months, we will have the next three years, we will have a thousand of time periods, which means that we need a millions of elements in the public key if we use this specific signature scheme. That's why we propose a new variant with a much shorter public key. So, the variant works with billionaire groups and it consists, it consider a secret key for the group manager, which only contains two elements. And a signature generated on a set of messages only consists of two elements where each message is associated with a different power of I, of Y. So, to generate a derived signature on some specific subset, there are several steps. The first one is quite classical for PS signature. It's the one where we will re-randomize the original signature. So, we will essentially rise each element to a random power and aggregate a signature on some random message. Once we have done that, we can simply aggregate all redacted messages to generate this new element, sigma prime. And the novelty of this variant is that we will now commit to these three elements by simply hashing them with some additional information. This step is particularly important to ensure unforgeability of our system. It is reminiscent of the techniques that are used to prevent raw key attacks for aggregate signatures. Once we have this new element, we can generate the last element of our signature that will be used to prove that the other elements were well formed. We essentially prove that the signature is valid. And it means that our derived signature only consists of four elements, four group elements, and that they can be verified with essentially two pairing equations. Actually, in our system, this will be very, very efficient because we are in a very favorable case. The first one is that we will only, as I said, a group signature will be produced by deriving the signature on only one message. So it means that the set of non-redacted message only consists of one element which will allow us to greatly simplify the generation process. Moreover, we will only consider two types of messages. Either the message will be zero, either the signing key must be deactivated at this time period, or the message will be the user's secret key if it is active at this time period. So concretely, this means that the first step of our protocols will only require three exponentiation in the first pairing group. The generation of the element aggregating non-redacted messages will be, will only require two exponentiation in the second pairing group. There will be some hash computation, but only one hash computation actually, but the computational cost is negligible compared to the exponentiation. And finally, the last element of our signature can be generated with only three exponentiation in G1, thanks to the element provided in the public key. Finally, to complete our group signature, we only need to produce a proof of knowledge of the user's secret key. But again, this can be done quite efficiently because it will essentially require one exponentiation and one pairing. And actually, we can replace the pairing by one exponentiation in G1 if we simply add one element to our signature. So regarding the size, if we implement our scheme with BLS 381 curve, as we can see, this leads to the signing key, which is very, very short. That's because it only consists of 128 bytes. Moreover, one of the main advantage of our system is that there is no update information. Again, the users do not have to retrieve anything when a new time period begins. And another very important feature of our scheme is that the group signature are very short because they only consist of roughly 300 bytes. Finally, regarding the complexity, as I explained, the signature's complexity is constant. We essentially require a few exponentiation and verification can be performed quite efficiently as long as the number of premature revocation is not too large. So to conclude, we have explained in the paper why group signature with time-bound keys is a very efficient solution for user revocation. We, as explained, the user can be revoked immediately using revocation lists. So we keep, we retain the flexibility of group signature with the revocation list. And thanks to the idea of natural revocation, we can retain short revocation lists, which means that verification can remain efficient with such kind of system, despite the revocation. Moreover, in this system, we have improved the granularity of natural revocation by allowing the group member to associate a sign-in keys with any set of time periods, which can be useful in many scenarios. We have also shown how to construct it very efficiently with unlinkable redactable signature scheme. In particular, in our system, we have a very simple joint procedure where the group manager essentially generates a signature, a redactable signature on the set of messages. We have a very efficient signature process where the user simply derives a signature and proves knowledge of it secretly. And finally, the verification is very simple because it essentially consists in verifying the redactable signature. In particular, an important feature is that we do not need to publish or retrieve update information at the beginning of each time period. Finally, we have proposed a new unlinkable redactable signature with short public keys that can be of independent interest. In particular, if we use this URS scheme to implement our construction, this lead to very short and constant size group signature and the fast signature generation. Thank you for your attention and do not hesitate to send me an email if you have any question. Thank you.