CL-Signatures Revocation Scheme in Ursa has flaws that allow a holder to demonstrate non-revocation of a revoked credential
Date: 2024-01
Affected: rust/anoncreds-clsignatures, rust/ursa
Attack vector: other
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2024-21670
CWE: CWE-327
CVSS: 6.5 (CVSS:3.1/AV:P/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:N)

### Summary The revocation schema that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, allowing a malicious holder of a revoked credential to generate a valid Non-Revocation Proof for that credential as part of an AnonCreds presentation. ### Details The revocation schema that is part of the Ursa CL-Signatures implementation has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, allowing a malicious holder of a revoked credential to generate a valid Non-Revocation Proof for that credential as part of an AnonCreds presentation. The flaw exists in all CL-Signature versions published from the [Hyperledger Ursa] repository to the [Ursa Rust Crate], and are fixed in all versions published from the [Hyperledger AnonCreds CL-Signatures] repository to the [AnonCreds CL-Signatures Rust Crate]. To exploit the flaw, a holder must update their wallet (agent) software, replacing the Hyperledger Ursa or AnonCreds CL-Signatures library that generates the proof of non-revocation. This may involve, for example, altering an iOS or Android application published in the respective app stores. A mitigation for this flaw is to use the application attestation capabilities (such as the Android "[SafetyNet Attestation API]") offered by the app store vendors to (for example) "help determine whether your servers are interacting with your genui


Mitigations:

Architectural layers (MAESTRO):