You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The x/avs module is vulnerable to rogue key attacks. An attacker can combine fake keys or signatures to bypass security checks, which could weaken the system.
Proposed Solution
Require users to prove they own their keys before using them. This can be done by asking them to submit a small extra signature when registering their key. Typically such a message should contain the protocol name (exocore) to prevent replay attacks on other chains and the operator's own address to prevent usage by another operator upon the first operator's withdrawal from the system.
The text was updated successfully, but these errors were encountered:
Upon reviewing the related PR, it seems that a check of key ownership was already present. However, it was vulnerable to replay attacks since any arbitrary message could be signed by the operator and then verified. The PR instead changes it to a constant message containing the chain-id and the operator's account address to prevent even these kinds of attacks.
Separately, it should be noted that registering another BLS key by the same operator for another AVS is not permitted. This appears to be an intentional design choice to discourage operators from reusing the same BLS key across multiple AVSs. The same choice has not been applied to operator consensus keys.
The x/avs module is vulnerable to rogue key attacks. An attacker can combine fake keys or signatures to bypass security checks, which could weaken the system.
Proposed Solution
Require users to prove they own their keys before using them. This can be done by asking them to submit a small extra signature when registering their key. Typically such a message should contain the protocol name (
exocore
) to prevent replay attacks on other chains and the operator's own address to prevent usage by another operator upon the first operator's withdrawal from the system.The text was updated successfully, but these errors were encountered: