This in-depth explanation covers the available options to revoke members in the Intel® EPID scheme. It also provides details on how and why each type of revocation is used.
The verifier only checks the revocation lists if the message was signed with a member private key that corresponds with the correct group public key.
After concluding that the signer is a member of a group, the verifier proceeds to check for group based revocation, then member private key based revocation, then signature based revocation, then verifier blacklist revocation.
If the group is revoked, the verifier stops and reports it.
If the member private key is revoked, the verifier does not check the signature based revocation list.
The verifier should periodically download the revocation lists (GroupRL, PrivRL, and SigRL) from the issuer and should use the latest revocation list during signature verification. The verifier should make sure that it gets the newest version of the revocation list during the update by checking RLver, the revocation list version number.
The group based revocation list, also called the GroupRL, has a list of revoked groups.
The issuer revokes the entire Intel® EPID group by revoking the group public key. This results in the revocation of all members of a group.
Group revocation is expected to be a rare event and would only happen under limited criteria.
Reasons to revoke a group might include:
Private key based revocation is used to revoke a compromised member. For example, the issuer can revoke a member if the member private key is exposed. When a compromised member private key is identified, it needs to be communicated to the issuer so that the issuer can revoke the member private key.
The issuer manages and publishes the member private key revocation list, also called the PrivRL, which contains member private keys that can no longer be used.
Depending on the use case, these member private keys could belong to members whose identity was compromised. For example, if a member private key is exposed online, allowing group members to be impersonated, then the compromised member private key is known, and the issuer revokes the member private key.
In signature based revocation, the issuer revokes a member based on the signature generated by the member. This revocation method is used when a member becomes subject to revocation criteria, but the issuer does not know the member's member private key.
The issuer manages and publishes the signature based revocation list, also called SigRL.
Entries in the SigRL cause signing to take longer for all members of the group. Therefore, when an issuer receives a signature revocation request, it first checks the signature against all entries in the private key based revocation list. If the signature was generated by a revoked private key, then it is not placed in the SigRL.
For the same reason, if the issuer were requested to revoke a private key, and the current SigRL had entries that corresponded to that private key, then the issuer would remove those entries from the SigRL.
The verifier and the member both use the SigRL managed by the issuer (the method of obtaining the SigRL is outside the scope of the SDK). The member sends the verifier an Intel® EPID signature that includes a number of non-revoked proofs that correspond to each revoked member in the SigRL.
In other words, the member mathematically proves that it is not any of the members who created the entries on the SigRL. One proof of non-revocation is generated by the member per entry in the SigRL. A single proof indicates the member in question cannot be the one who generated that signature in the SigRL.
For privacy, Intel® EPID signatures that are generated by the same member are unlinkable by default. This means that the verifier cannot recognize if two Intel® EPID signatures are from the same device. Therefore, multiple Intel® EPID signatures on the SigRL could be from the same member.
Reasons for revoking a signature might include the following:
Verifier blacklist revocation is similar to signature based revocation in that it can be used to revoke a member using only a signature from a compromised member. Unlike the procedure for the signature based revocation list, members do not have to create non-revoked proofs for each entry on the verifier blacklist. Instead, the verifier relies on the member to use a basename when creating the signature (in other words, to use a name based signature) in order to determine if the same member created any of the signatures on the verifier blacklist.
For the verifier to determine that a member created an entry on the verifier blacklist, the member and verifier must use the same basename. The mechanism that allows them to agree on a basename is outside the scope of the SDK.
For more information on basenames, refer to Name Based Signatures.
The verifier adds a signature to a blacklist when the verifier does not want to trust the signer, but the verifier does not have enough reason to send a request to the issuer to revoke the member's signature.
When the verifier tracks a member using a basename, and decides the member is not trustworthy, the verifier can add the member's signature to the verifier blacklist.
Reasons a verifier might revoke a member based on its tracked signatures include the following: