[FR] - Expose a function in the API/CLI to sign arbitrary data with KES keys

[iquerejeta]

What - The user facing feature being implemented

Command to sign arbitrary data using pool's KES keys.

Why

In the Mithril project (fast bootstrapping of Cardano node) is relying on KES signatures to link Mithril keys with PoolID and, by consequence, their stakes. More information can be found in this discussion. In a nutshell, we want to create the following link:

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

For this, we need a way to interact with the KES keys, and the best and safest way we can think of, is to expose a function in the cardano-cli to sign arbitrary data using the current evolution of the KES key. In particular, this function could be as simple as:

cardano-cli node kes-sign \
--msg-to-sign msg.bin \
--out-file msg.signed

Describe alternatives you've considered
Other options that we have considered are: 1) to use the VRF key to sign the Mithril key, or 2) to use the KES key available in the file kes.skey, which is generated when creating the OpCert.

1. VRF keys We consider that using KES keys, instead of VRF keys, is more appropriate to certify an SPO for a given epoch.
2. Use kes.skey While this would be a viable option, it means that yet another piece of software (mithril-node) needs to safely handle a security critical piece of data. We are actively working on secure forgetting of KES keys, which could be made useless if other software (i.e. mithril-node) somehow stores the key in disk.

Personas - Who will this affect?

• SPO
• Dapp Devs --> Mithril
• Exchanges

Acceptance Criteria

• Read KES_0 from kes.skey (secret key file) and evolve it to the corresponding period.
• Data is signed with the corresponding evolved key

Both nodes run on the same machine.
Mithril will handle signature verification on their side.

Definition of done

• Code review
• Builds successfully on CI
• Includes documentation and/or examples for the functionality
• Log/record changes on Vnext (or similar depending on what we adopt)
• Ticket number included in PR description
• The new functionality is covered by dev/unit/property tests
• Acceptance Criteria met
• Test Engineering Sign-off + E2E automated tests

Sign-off

• Dev
• Test Engineering

Related PR

1. PR # here

[dcoutts]

Note that as-described this does not require any new on-chain functionality. It's just about making it easier to do something that is already in principle possible: sign messages using a KES key.

@iquerejeta could you clarify the request here. Are you thinking that:

1. the CLI should read the KES key from disk, or
2. that the CLI should ask the node (requires a new query in the node) to sign, or
3. perhaps thinking that the future KES agent should support doing such ad-hoc signing?

I should say that I'd prefer to start with 1, and then transition to 3, but not do 2. I think that gives a better separation of concerns.

[iquerejeta]

I was actually thinking of 2 as a first step, ask the node directly to sign with the current key evolution, available in memory. The problem I see from 1 is that we are handling the KES key with a different piece of software, which is undesirable IMO. If I understand correctly, your option 1 is a variant of the option 2 we've already considered (mentioned above).

Why are you concerned of having the CLI ask the node directly to sign data?

[dcoutts]

Long term, I think it's 3 that is probably the best solution. It gives a better separation of concerns: the agent will be where the key is at rest, and so is also the appropriate place to do other ad-hoc operations. Yes, the node will have a copy, but it's preferable not to give the node additional responsibilities.

As a general architecture principle we try to avoid giving the node responsibilities beyond its core task of participation in consensus, and providing all the blockchain data to clients.

Obviously 3 can only be done once we have the KES agent. In the meantime, the equivalent that does not use the agent would be 1. It's no worse than what we have now for key handling. The CLI already handles KES keys: it creates them, and opcerts. Again, all those creation and opcert operations would later move to the KES agent, and we'd move signing at the same time.

Option 2 is neither the best long term, because it goes against our architecture principle, and also as a practical matter requires more work in the node to add a new query. Option 1 is just an extra CLI command that can be done directly.

[iquerejeta]

I agree that option 3 is the best solution in the long term.

I understand your concerns for going forward with 2, and I don't think it is worth breaking the architecture principle for this matter. We can work with option 1 currently while we wait for option 3 to be ready.

[CarlosLopezDeLara]

How far are we from the KES agent?

The question is do we add the signing feature to the backlog (option 1: read from disk and evolve it) or is the agent close enough to wait for it?

[iquerejeta]

is the agent close enough to wait for it?

No, the agent is not close enough unfortunately, so we'll need an alternative solution.

[CarlosLopezDeLara]

So as an intermediate step until we have KES agent working, we can use option 1. Where we use read KES_0 from kes.skey and evolve it to the right period.

[CarlosLopezDeLara]

@disassembler @iquerejeta @abailly-iohk Do we need tooling to verify the signatures o will it be handled by mithril node?

Also, is it safe to assume that cardano and mithril nodes are running on the same machine?

[ghost]

Given the requirement to have access to the KES key in the cli to sign, it seems like necessary to have mithril-node and cardano-node being run in the same machine/context. The mithril-node will handle the verification as the verification key is attached to the signed data IIRC. And we already do it when verifying key registration and mithril certificates.

[iquerejeta]

@CarlosLopezDeLara For the use case described in this issue, we don't need tooling to verify the signatures. The mithril node takes care of this, using the verification key which is present in the OpCert. As Arnaud said, the current design is that both nodes run on the same machine.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[iquerejeta]

Commenting so that the bot does not close this issue.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[CarlosLopezDeLara]

@Jimbo4350 Can we prioritize this feature?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[iquerejeta]

@CarlosLopezDeLara, I saw that this was added in #4779 . Do you happen to know in which node release it will be included?