search

decentralized-identity / peer-did-method-spec

A rich DID method that has no blockchain dependencies. The verifiable data registry is a synchronization protocol between peers.
https://decentralized-identity.github.io/peer-did-method-spec/index.html
Apache License 2.0
27 stars 17 forks source link

Attacker re-using a peer DID in a different context: Problematic or not? #17

Open dhh1128 opened 4 years ago

dhh1128 commented 4 years ago

Moved from https://github.com/openssi/peer-did-method-spec/issues/119. Tagging @SvenHammann90 , who was following it there.

dhh1128 commented 4 years ago

I believe this risk is substantially mitigated by the design decision we've recently made to align peer DIDs with KERI. KERI requires a pre-rotation of the inception key, which means the attacker would have to know 2 keys, not 1, to carry off the attack. @SmithSamuelM , can you confirm?

If I am correct, then I propose that we close this ticket as soon as we complete work on #4.

SmithSamuelM commented 4 years ago

A KERI rotation requires knowledge of the pre-rotated key. That pre-rotated key is not disclosed in the inception event. Merely the hash of the key is disclosed. An attacker must first invert the hash to discover the public key. This is post-quantum secure. When using only a basic self-certifying identifier, the vulnerability is the creation of an alternative inception event for the same identifier. This alternate event could use a different pre-rotated key's hash. This is detectable as duplicity so any verifier would detect it given a copy of the original inception event. Alternatively, using a self-addressing self-certifying identifier, the hash of the pre-rotated key becomes part of the derivation material used to create the identifier. Thus there is no possibility of creating an alternate inception event for the same identifier but with a different pre-rotated key hash. This this means that the only exploit is to invert the hash or a side channel attack that captures the key pair used to create the pre-rotated hash. This is about as secure as you can make anything. The only vulnerability (pre-and post quantum), besides a brute force attack, is to side channel attack the key creation infrastructure. And every PKI based cryptographic method has that vulnerability.

KERI 1 used a double signature (both current and perorated keys) for rotations but KERI 2 commits to the the hash of the pre-rotation so there is no longer a need for the double signature. It doesn't provide any meaningfully additional degree of security. Only the pre-rotated key is needed to sign the rotation.

SmithSamuelM commented 4 years ago

See the KERI white paper and this for the post-quantum analysis: https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/final-documents/quantum-secure-dids.pdf

SvenHammann90 commented 4 years ago

I have almost forgotten I had opened this issue, thanks for following up. @SmithSamuelM : I have listened to your webinar about KERI and if peer DIDs are to follow the principles you explained there, then issues such as the one I described should be prevented. I remember from the webinar that I was convinced, at least :-)

So from my side, this issue can be closed.

P.S: I'm happy to see that the different community efforts are converging in this way. This is an important prerequisite to perform meaningful formal analysis on these kinds of topics.

SmithSamuelM commented 4 years ago

@SvenHammann90 The KERI principle for a did:uni method and its associated DID doc is that the control authority over the did doc must be established as part of any verifier seeking verification. So following KERI principles in DID:peer should fix the problem. I don't know exactly yet what that fix looks like for did:peer. In KERI the did:doc is not the root of trust, the KERL is. The did:doc may provide a snapshot of the KERL or a reference to the KERL by which the did:doc authenticity may be established. Thus moving did:peer to a KERI approach changes how one looks at a did:peer DID Doc. One could use a sequence of did:peer DID DOCs as the equivalent of a KERL but the control establishment for each new DID Doc would have follow KERI principles. Each version of a DID Doc would function either as an establishment event or a non-establishment event in the KERI parlance. Those versions that function as establishment events would have to be signed appropriately in order to establish the transfer of control authority (rotate) keys. So a did:doc could not be used in an inconsistent sequence of events without being detectable.