Sidetree and the Late Publish Attack

At Transmute, we are enjoying working with some of the smartest engineers at Microsoft on a decentralized public key infrastructure protocol called Sidetree. The Transmute team on the Ethereum version; we call it Element. You can read more about it here and see the code here.

Transmute views Sidetree as an architecture for layer 2 scaling solutions for distributed ledgers. This means there are applications other than Decentralized Public Key Infrastructure (DPKI) and identity for people and devices.

We’re particularly excited about two of these other applications:

1. Assets
2. Attestations

Or more generally, verifiable credentials / verifiable presentations.

As you read about Sidetree and start to get excited, the moment inevitably comes when you ask the question: what about transferability can Sidetree entities be transferred from one controller to another.

In this post we’ll explore the challenges associated with decentralized asset / identity / credential control transfer, and explain why its not supported out of the box in Sidetree.

Introducing the Late Publish Attack

Let’s cut to the chase. You can’t transfer Sidetree DIDs because of the “Late Publish Attack”. Here’s how it works:

Step 1: Alice mines a fancy DID, did:elem:facebook-0c2361vAdfhFD… She thinks because its fancy, it must be worth something, so she offers to sell it.

Step 2: Bob sees the offer, and agrees to buy. Ignoring a number of timing attacks, Bob proves he controls a public key to Alice, and she issues a recovery operation making Bob’s key the new controller.

Step 3: Bob observes the recovery operation, performs another update, and recover operation, which both succeed. He believes he controls the DID.

Except Bob does not control the DID.

What happened?

A few additional steps took place behind the scenes:

Step 0: As soon as Alice realized she had something valuable, she created a recovery operation, calculated an anchor and batch file for it, and submitted the ledger transaction without making the anchor file or batch file available to decentralized storage. This transaction just looks like a mistake, and is ignored by everyone, including Bob.

Step 4. After receiving payment, Alice publishes the anchor and batch files, and suddenly the history of the DID is reverted. Since the ledger controls the order of Sidetree transactions, every operations that occurred after Alice’s sneaky recover operation is no longer valid, and whichever keys Alice choose in that recover operation are in control of the DID.

Why does the late publish attack always succeed?

• There is no way to know if a Sidetree transaction is invalid or unpublished… So there will always be the potential for late publish attacks.
• The ledger controls the order, so any non resolving transaction might later turn out to revert the history of a DID.

But I still want to transfer my DIDs… what are my options?

• If Alice and Bob sign a legal contract, Bob can take Alice to court if she ever does this, and the ledger will provide an immutable audit log of the activity.
• The Sidetree protocol could be extended to support multisig operations, and then transfers could occur when a threshold of trusted party signatures was reached.
• A smarter anchor contract might be able to resolve such disputes; but that would undoubtedly be more expensive, and must be coupled to ledger that supports complicated smart contracts.

Alternative constructions and mitigation strategies:

• DIDs are inexpensive to create in Sidetree. This opens the opportunity to create a new DID (rather than transferring) and link to the old DID.
• Before create, there is no history to revert. After create, there is only the history after create to revert. If create contains a cryptographic link to a previous DID, the transaction history will always preserve at least this record. It might get overwritten (service or publicKeys might change), but at this point, we are talking about processing transactions slightly differently for a certain case of DID, its essentially a protocol update.
• Implementing protocol changes like cryptographic accumulators, aggregate signatures, zero-knowledge schemes would support the addition of transferability as a special ledger operation.
• Unlike token transfers on a ledger like Ethereum, you cannot transfer a Sidetree DID in a trustless setting. However, you can transfer a Sidetree DID if you trust the creator, and plan to continue trusting them and anyone they have received the DID from forever. As the chain gets longer, these trust assumptions become less reasonable, but for corporate or government issued DIDs with a single [or very limited number of] transfer[s], it is likely acceptable.