Avoidance of DID collisions?


#1

Is there any inherent mechanism on the Ledger or the consensus protocol in order to avoid DID collisions? Or does it merely rely on the improbability of such events? For example, what happens if an entity tries to register a DID that is already existing on the ledger?


#2

It’s actually a requirement of the DID spec (see Implementer’s Draft 01, section 5.2) that all DIDs are globally unique. Therefore the target distributed ledger for a DID MUST ensure that that DID is unique on that ledger.

It is fascinating to consider how different ledgers will handle this requirement. The DID methods proposed for Bitcoin and Ethereum are based on the transaction address (Bitcoin) or the smart contract address (Ethereum). That’s how those methods can guarantee uniqueness—every transaction (inside every block) has a unique address on Bitcoin and every smart contract has a unique address on Ethereum.

But it also means that the identity owner must first obtain the address (which becomes the DID), and then, in a second step, to another transaction to post a DDO that references that DID.

On Sovrin, this is reversed: first, the identity owner generates an Ed25519 key pair (which happens entirely locally, without involving the ledger). The first half (16 bytes) of the public key (the verification key) as the owner’s DID. So the identity owner can then register the DID and the DDO in a single Sovrin transaction. And the Sovrin validator nodes will verify that the DID is unique on Sovrin before accepting the transaction.

See the Sovrin DID Method Specification for more details.


#3

If the creation of a new DID is attempted by a given entity (via the generation of a “unique” keypair) and the validators reject the transaction because such DID is already found on the ledger, isn’t that a possible attack vector since now the entity owns a private key for which there is a registered DID for another (possibly unknown) owner?.. So the attacker would just need to lookup for the corresponding public key and then attempt to hijack the identity?

I’m truly no expert in cryptography or security, but this seems like a feasible attack: brute-force the creation of “new” DIDs until I find one that actually exists… How does Sovrin currently protect itself from such attacks?


#4

I’m not a crypto expert either, however the attack you talk about is essentially the same as trying to brute force guess an elliptic curve key. It’s very hard to do. But we should get a crypto expert to confirm.


#5

Using the full 32 bytes is secure. Using the first half (16 bytes) will result in identifiers vulnerable to collisions. Please see the recent PGP fingerprint attacks.

Please excuse me if I’m missing something here.

In Bitcoin, addresses are derived by taking the RIPEMD160 of the public key, which results in a 20 byte identifier. This should be considered secure whereas taking the first 20 bytes of the public key should not be considered secure.


#6

@ryan: by “secure” do you mean:

  1. The risk of collision is minimized, or
  2. The cost of brute-forcing a clone of an existing DID (as described in the attack above) is infeasible?

#7

I only consider a cryptographic identifier to be secure if it cannot feasibly be brute-forced.

If there’s any reasonable chance that a collision can be found, then compute power can be focused on it and the person can be impersonated.

I’d also like to highlight that if a single collision has been found for a given hashing algorithm, then all documents being hashed with that algorithm are vulnerable. As an example, the existence of a single SHA1 collision means that one cannot be certain about the integrity of any SHA1 documents.


#8

@ryan Good points. I am not a member of the Sovrin Technical Governance Board, but I attend most of their meetings and will make sure they have reviewed this input.

I think we should also reflect this as at least best practice if not a normative requirement in the DID spec.