Issuer Key Rotation in the Event of compromised Issuer private key.

[SmithSamuelM]

The Indy AnonCreds Design here Anoncreds Design included provisions for key rotation leveraging the Indy/Sovrin Ledger. I see no mention of key rotation in this specification. How do you plan on providing for key rotation in the event the private key of the Issuer becomes compromised?

[swcurran]

Currently, the only method I'm aware of in AnonCreds for dealing with a Cred Def (which is the object that contains the public keys for a issuing a credential) is to create a new one, stop using the old one when issuing and only issue with the new Cred Def. Any existing credentials issued with the old Cred Def would reference the old Cred Def, any new credentials, the old Cred Def.

In theory, an issuer could do more. An Issuer with an Aries agent that retains a persistent DIDComm connection to the holders, would have a way to proactively issue a new credential to replace all of the old ones. If revocation is active for the credential type, the issuer could revoke all of the credentials associated with the old Cred Def.

[SmithSamuelM]

So if the the private key of the public keys is compromised what stops the compromiser from issuing fraudulent credentials under the old cred def? How does a verifier know that credentials should be using the new cred def not that old one. The Indy AnonCreds design used time-stamps of the key state on the ledger for the cred defs to signal that old public keys in the cred defs were no longer valid and a verifier had to check the time stamp provided by a majority BLS sig of the ledger nodes. Simply issuing a new cred def doesn't invadate credentials issued under the old cred def, unless the policty is to auto-revoke all credentials issued under the old cred def the instant the new cred def is published.

How does the legitimate issuer know that their key has been compromised and that they need to issue a new cred def? Given that the purpose of using Anoncreds is to prevent issuer linkability at presentation, a verifier would have to volunteer to the Issuer that they suspected a fraudulent issuance using a given cred def in spite of it being verifiable.

In theory, an issuer could do more. An Issuer with an Aries agent that retains a persistent DIDComm connection to the holders, would have a way to proactively issue a new credential to replace all of the old ones. If revocation is active for the credential type, the issuer could revoke all of the credentials associated with the old Cred Def.

Seems heavy weight to require a persistent didcom connection from issuers to holders. Not to mention that survelliance/privacy issues such a persistent connection would engender third party surveillors to correlate holders to the credentials they hold. (routing tables are highly stable and endpoints are highly stable) so a persistent connection, even did-com with mixed routing and asymmetric channels, is still correlatable to likely endpoints (the issuer is known), especially when used in a bulk reissuance of all credentials for a given cred def. So now the bulk reissuance would enable statistical correlation of holders to their held credentials by surveillors.

In theory, the revocation private key could also be compromised, so this is not a solution because a malicious attacker could revoke credentials that should not be revoked. So dependence on revocation as a mechanism to protect against key compromise exposes the system to a different attack, that of malicious revocation.

These (malicious issuance forcing bulk revocation or malicous revocation) are wholesale attacks that expose the full set of issued credentials of a given type (cred def) not just a single issuee's credentials. There is no forward security. A compromise of a private key some time in the future (issuance key or revocation) key can be used to wholesale invalidate all credentials issuable or revocable under that key. Thereby forcing new issuances.

But there is no guarantee that a given Issuer would know that such an attack has been successful because there is no mechanism to force its detection. So successful attacks could lay latent for some time before discovery. An attacker could compromise a key and then wait for an opportune time to take advantage of it. And subsequent reissuance would only happen too late (after the fact)

Typically prophylactic key rotation is used to minimize the time window for latent opportune attacks. But the mechanism you describe is equivalent to periodically revoking and reissuing credentials. One might as well use short expiration dates as use a dynamic revocation mechanism.

As we have seen with the DNS/CA system the lack of a normative key rotation mechanism has resulted in shorter and shorter expiration times in order to mitigate latent opportune attacks. Although the mechanisms for attack for DNS/CA are much easier to succeed (not even requiring a key compromise), the fundamental security weakness of not having a normative secure key rotation mechanism is still the same. At some point in the future, any key already used for signing (issuance or revocation) may be compromised through a side channel attack or a newly discovered exploit on the key creation algorithm. A code supply chain attack or a surprise quantum attack, for example.

The hard problem of PKI security is key rotation. It is perilous to ignore it or hand wave it.

Without either a normative key rotation mechanism or a requirement that it be used with one, the specter of key compromise makes anoncreds by itself fundamentally insecure.

[SmithSamuelM]

All that said. AnonCreds may choose not to have a normative key rotation mechanism, but then the spec should be caveated that it should/must be used with some key rotation mechanism and some thought should go into providing normative hooks in AnonCreds for such mechanisms.

[swcurran]

Is this part of the "all roads must lead to KERI?" tour, Sam?

I've quoted a few of your questions and responded as per the AnonCreds model.

So if the the private key of the public keys is compromised what stops the compromiser from issuing fraudulent credentials under the old cred def?

• Assuming the malicious actor replicates the environment of the Issuer and can attract holders interested in receiving a credential from the malicious actor, nothing stops them. It depends on how much control/information they have over the Issuer as to how effective it would be. How does a verifier know that credentials should be using the new cred def not that old one?
• Either the verifier does not know to ask for credentials from the new CredDef (and so never gets them -- holder can't satisfy the presentation request with the new credential) or the verifier gets a presentation that uses the new credential, with the Id of the new CredDef and they must decide if they trust it or not. As such, your definition of "how Indy did it" remains the same. Simply issuing a new cred def...
• Correct. And as noted, revocation is an option if the credential type supports revocation. Batch revocation is possible, although there is not "automation tied to publishing the new cred def", unless the issuer implements that. That is a policy issue supported by, but well above AnonCreds. How does the legitimate issuer know that their key has been compromised and that they need to issue a new cred def?
• There is no specified way to handle this as by definition. it is unknown. The issuer might detect the compromise. Verifiers could contact the Issuer (perhaps using the IssuerId in the credential) or perhaps a Trust Registry that supports reporting abuse could be used. This issue is well-above the AnonCreds protocol and part of governance. Seems heavy weight to require a persistent didcom connection from issuers to holders. Not to mention that survelliance/privacy issues such a persistent connection would engender third party surveillors to correlate holders to the credentials they hold...
• There is no requirement to have a DIDComm connection. An issuer unilaterally revokes credentials -- the DIDComm connection can help them with notifications of the revocation and optionally, re-issuance. I merely offered that as a policy that an issuer might want to use, a deployment model they might choose. There is no surveillance about keeping a persistent connection. An issuer supporting revocation MUST track the holder and credential issued in order to revoke the credential. Again, no surveillance, just a technical requirement.

Rest of your response are statements.

There is a security section in the specification and in that, we'll include the issue of compromised keys and the options an issuer has, mostly outlined in this issue.

Thank you for raising this issue.

[SmithSamuelM]

Very much appreciate your thoughtful responses.

Is this part of the "all roads must lead to KERI?" tour, Sam?

Actually i was trying to see what it would take to use AnonCreds as an optional proof type for ACDCs and ran into the inherent trade-off between stronger authenticiy and weaker privacy or weaker authenticity and stronger privacy that is a fundamental property of the limited crypto options at our disposal. I raised this issue primarly becasue I wanted see if this new spec for AnonCreds sans Indy had any new thinking on the key rotation problem.

We have a very limited set of properties we can play with, and as expressed by the PAC theorem, we have a trilemma when doing systems design. We can have all of Privacy, Authenticity, and Confidentiality at some level of security but not all three at the highest level. We must pick two and reduce the third. Usually, the conflict is between Authenticity and Privacy. Key rotation is one of the sticky points that force the trade. PKI can only do so much, and ZKPs can only do so much. So when you want absolute unlinkability, you must give up some other property to some degree.

KERI is opinionated in that it makes the choice to always have authenticity as the strongest of the three which necessarily means some compromise on privacy. It may not be a big compromise but the one that is most problematic is un-permissioned correlation between Issuer and Issuee made by a verifier. All the other correlations can be dealt with without sacrificing authenticity. It is the trade-off induced by key rotation vis a vis linking key state to revocation state that is the problem. If I want cryptographically strong linkage of key state to issuance/revocation state then I must sacrifice some degree of Issuer/Issuee unlinkability. If I want strong Issuer/Issuee unlinkability then I must sacrifice some degree of strength of the linkage of key state to issuance/revocation state.

I have yet to see a satisfying approach to key rotation that doesn't make some trade-off between unpermissioned Issuer/Issuee linkability and authenticity (secure attribution) via linkage of key state to Issuance/revocation state.

[rodolfomiranda]

Interesting discussion! Is that something we can tag as next version?

[swcurran]

Closing this issue. The “solution” for key rotation is “cred def rotation” — a new cred def is used.