How should we link the Mithril identity with Cardano identity

[iquerejeta]

The mithril paper analyses security under the assumption that the stake distribution links a mithril key (pairing based) with a stake. However, that is not the case in Cardano. The stake distribution links a pool id (blake2b hash of a cold ed25519 verification key) with some stake. In order to link a mithril key with its corresponding pool id, the SPOs will sign the mithril key with their active KES key (up to discussion if we use the VRF key here), and submit it during registration. The registrar verifies this signature, and in case it is valid, includes the link of mithril-key <-> stake in its local hashmap (which contains all valid registrations).

The concern is that the explicit link mithril-key <-> poolId does not exist after registration, meaning that the client cannot validate this. @pyrros, what would be the best way to proceed here? Should we include the KES signature in the mithril certificate to allow clients to validate that explicitly? Is there a workaround to avoid appending all those signatures?

[iquerejeta]

Do we need to append the KES signatures to the Mithril certificate?

In a discussion with @pyrros, the following was mentioned:

We trust the genesis keys to check the link between SPOs and the SD keys for the first distribution, 
and past that, we trust the signers to check the SD they are signing is legitimate (this trust is the 
reason why we can't recover from forgeries btw).

This means that it is not necessary to include the KES signature and/or opcert to the Mithril certificate. The intuition here is that the guarantee that a given Mithril key really corresponds with its associated stake is implicit in the Mithril certificate by the fact that the signers have agreed on the AVK (and by consequence, on the committed [mithril-vk, stake] pairs). The security of Mithril relies on the assumption that a majority of the stake is honest, and the guarantee that a mithril vk really corresponds to its associated stake also falls back to that assumption.

Mithril keys validation

In order for a party to register as a Mithril signer, it needs to authenticate as the rightful owner of the SPO it is registering for. This is done in the same way an SPO authenticates to mint a block, i.e. by leveraging the OpCert and KES signatures. To fully understand how this works, we need to understand that the entity running the registration procedure has knowledge of the stake distribution of Cardano, i.e., it knows the relation PoolID <-> Stake for all registered pools. This information can be extracted by running the node (which can be achieved either via bootstrapping, or using Mithril). Assuming that the registrar knows this information, registration would proceed as follows:

• Registering party uses its current KES sk to sign its Mithril vk, and sends the OpCert, KES signature and Mithril vk to the registrar
• The registrar computes the PoolID out of the OpCert (by hashing the cold vk). If there is no entry for this PoolID, it does not accept the registration. Otherwise, it verifies the KES signature using the KES vk available in the OpCert. If the signature validates, it links Mithril vk with its corresponding stake.

This provides the following link:

PoolID <-------> ColdVK <----------> OpCert <------------> KES vk <--------> Mithril vk
        Blake2b          OpCert sig          Contained in           KES sig
                                                OpCert

The PoolID is sufficient for the registrar to authenticate the registering SPO due to the first two links.

Spoofing attacks

There has been a discussion in Discord that points to the direction that if an OpCert is not available on main-net, then any entity can spoof an OpCert. I believe it is better to keep this discussion here, to facilitate visibility and future reference.

My argument is that even if OpCerts have not been published on main-net, one cannot spoof them. Recall that the registrar knows the PoolID of existing pools. In order to spoof a certification, and adversary would need to create an OpCert which validates against the pre-image of the PoolID. In other words, the adversary needs to produce a valid signature with the cold sk. Under the security assumptions of Cardano, this can only be performed by the SPO itself.

Links of interest

This is being implemented in #433

[cardano-apexpool]

The discussion in Discord started because at this development stage, the stake pool ID is set when running the Mithril signer node. When I asked about how spoofing will be prevented, the answer was that the KES keys will be used for that. Is was not clear if the operational certificate would also be used or not, and even in case it was going to be used, if it will be registered or not.
Without registering the operational certificate, after a KES keys and operational certificate rotation, until the first block is minted using the new KES key and the new operational certificate, there would be not evidence that a certain KES key belongs to a certain stake pool.

If there is a registration of the operational certificate, like it is mentioned in the above comment, the stake pool ID will be taken from the operational certificate (which is signed with the stake pool cold key), and spoofing the stake pool ID is not possible.

I am not sure I understand who the registrar is. Is the registration process decentralized (like for the stake pools on Cardano), or is it a node (maybe the Aggregator Node)?

[iquerejeta]

I am not sure I understand who the registrar is

Right now the registrar is the Aggregator node, but it will eventually be decentralised, that is why I wanted to generalise a bit more.

Without registering the operational certificate, [...] there would be not evidence that a certain KES key belongs to a certain stake pool.

Indeed. This is why we require the opcert to be submitted during registration. Actually, there is a further check that needs to be performed by the registrar. It needs to check whether there exists an OpCert posted on-chain with a higher issue number, as this would overwrite the previous one.

[cardano-apexpool]

Actually, there is a further check that needs to be performed by the registrar. It needs to check whether there exists an OpCert posted on-chain with a higher issue number, as this would overwrite the previous one.

This extra check is welcome. But I assume this also means that once the new OpCert was used to mint a block, if the new KES key and the new OpCert are not updated in the Mithril signer node, the Mithril signer node should become invalid.

[ghost]

If you try to register a Mithril key with a stale OpCert your registration will be registered, I guess.

[iquerejeta]

What do you mean the registration will be registered? In this case the registration would not be accepted (if the OpCert used is stale).

[ghost]

This discussion supersedes #507 hence I locked the former.

[conraddit]

This would then mean that the 500 ADA, which is presently sufficient to prevent attacks on MainNet, would be the primary layer (i.e., to register multiple Mithril pools, one would first need to register multiple L1 pools, each one at a 500 ADA cost) of protection for Mithril, in addition to the corresponding stake for each of the Mithril-registered pools. Is this a valid understanding?

[ghost]

Not sure what you mean by primary protection 🤔

[conraddit]

One would need to spend 500 ADA on multiple pools in order to attempt an attack on Mithril.

[iquerejeta]

That would not be the case. This is due to the weighting function used. See the last paragraph of section 2.6 in the research paper

[reqlez]

Yea, the stake distribution is taken into account, correct? So a 1000 ada stake pool will not have a lot of weight.

[iquerejeta]

Yes, that is correct. The chance for each Mithril signer to produce valid signatures (they can produce more than one for a single aggregate) depends on the amount of stake they own.