Proposal: Preventing Forged Keygen/Sign result

[anhthii]

Executive Summary

This proposal suggests implementing cryptographic authentication for MPC result events as a security improvement to strengthen the overall authentication model in the mpcium system. While the current system has robust input authentication, adding result authentication would provide end-to-end verification and improve the security posture.

Current State Analysis

The mpcium system currently has strong authentication for input messages but lacks authentication for result events:

Input Authentication (Well-Protected): All incoming MPC requests use the InitiatorMessage interface with Ed25519 signature verification client.go:224-241 .

Output Events (Improvement Opportunity): Result events are published without cryptographic signatures:

Key generation results are composed and published directly event_consumer.go:218-237
Signing results follow the same pattern `sign.go:11-25

Security Enhancement Opportunity

While not a critical vulnerability, adding result authentication would provide:

• Enhanced Integrity: Cryptographic proof that results originated from legitimate nodes
• Improved Traceability: Clear attribution of results to specific nodes
• Defense in Depth: Additional security layer complementing existing protections
• Consistency: Uniform authentication model across all message types

Proposed implementation

type KeygenResultEvent struct {
	WalletID    string `json:"wallet_id"`
	ECDSAPubKey []byte `json:"ecdsa_pub_key"`
	EDDSAPubKey []byte `json:"eddsa_pub_key"`

	ResultType  ResultType `json:"result_type"`
	ErrorReason string     `json:"error_reason"`
	ErrorCode   string     `json:"error_code"`

       	NodeID       string     `json:"node_id"`       // Unique ID of the node (e.g., pubkey hash)
	Signature      []byte     `json:"signature"`       // Signature over canonical serialized event
	SignatureAlgo  string     `json:"signature_algo"`  // e.g., "ed25519"
}

Potential Timestamp + Expiry Check (Optional) to avoid replay protection

Timestamp int64 `json:"timestamp"` // Unix epoch seconds

[nann-cheng]

Sounds interesting to me

[nann-cheng]

To proceed with the actual implementation, could you answer following questions to accelerate my operations:

• Currently, which nodes delivers the reply (PublicKey) to client wallet with his request? In standard threshold model, assuming potential malicious nodes, the client should always verify the consistency of the PublicKey from enough 'honest' nodes.
• Do you isolate request from different wallets? I see currently the topic are not yet associated with wallet-ID?
• Do you intend to have the client learn the public key of each MPC node?

Thank you in advance for your reply.

[anhthii]

hi @nann-cheng

1. If the cluster has 3 nodes then could be one of three node. Currently there is no fixed node that do this.the client should always verify the consistency of the PublicKey from enough 'honest' nodes -> this might introduce significant delay as I think might need to use bls signature to prove that majority of the nodes agree on the public key output
2. Can you elaborate this as currently I think the topic is associated with the wallet

3. Yes, we might need to let the clients import the import public key of all nodes

Btw, thanks for asking the question. I think we need to finalize the ECDH pull request first before implementing this.

[nann-cheng]

hi @anhthii

1. We have to have enough 'honest' nodes give their replies, as this random node could be a malicious one as per our assumed security model. A simple solution could be having all nodes delivering the result, in case of any inconsistency, just abort, no additional communication rounds required.
2. Thanks, so far I think it's good, I was missing this line.
3. This is necessary, because you cannot simply believe the temporary public key within the message, the client/wallet should have the correct MPC nodes public keys in the set up. This will be helpful to achieve point 1, verify consistency of message send from MPC nodes.

Please let me know when you find issues in your integration. Thanks!

[anhthii]

For :

1. Currently ther is a feature idemptotent key of NATs queue that drop message that is duplicate even though all nodes deliver the same result. We might remove the idempotent check, let the client get all the results and check.

3. Agree

[tuananhk13bk]

hi @nann-cheng are you working on this issue yet?

[nann-cheng]

@tuananhk13bk No, feel free to take it as yours, if you find it interesting. Will be back adding stuff after two weeks.

[anhthii]

feel free to suggest solution first before you take htis one @tuananhk13bk

[tuananhk13bk]

Thanks both @anhthii @nann-cheng will read through and suggest a solution first.

[tuananhk13bk]

Btw, in the worst-case scenario, if 2/3 nodes are compromised, the attacker can either reconstruct the whole private key to sign any transactions or bypass event result validation? Am I correct? Which situation does this proposal prepare for?

[nann-cheng]

I think we assume at most t-1 corrupted nodes, this proposal is simply to add the missing scheme to have the client validate the received result are indeed issued by the MPC nodes, not from any adversary manipulating the communication layer.

As for the existence of potential maximum t-1 malicious MPC nodes, the following discussion suggests checking results sent from at least t nodes, only when consistency check passed, the client accepts the final result.

[anhthii]

There might be a performance impact if we wait for results from t nodes so we are thinking if there are any better solution without impacting the performance too much