Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

frame-session: Introduce a proper proof of key ownership #1739

Open
wants to merge 31 commits into
base: master
Choose a base branch
from

Conversation

bkchr
Copy link
Member

@bkchr bkchr commented Sep 28, 2023

frame_session::set_keys supports providing a proof as second parameter. This proof was not yet checked. This pull request introduces a verification of this proof and also a way of generating this proof. The proof in FRAME are concatenated Signatures. These Signatures are in the same order as the public keys in the SessionKeys struct. Each signature is signing the owner, proofing that the generating party has access over the private key associated to the public session key. The owner in FRAME is the account id of the account that will call set_keys, aka the account of the validator.

This pull request is changing the SessionKeys runtime api. This still requires a RFC, as this is a public interface of the Polkadot runtime.

@jacogr polkadot-js should provide a way to use the runtime api directly to generate the sessions keys.
@paritytech/docs-audit this will require updates of the validator documentation to tell them what to pass for owner and that they need to pass proof to set_keys.

@bkchr bkchr requested review from a team September 28, 2023 11:09
@bkchr bkchr added T1-FRAME This PR/Issue is related to core FRAME, the framework. T8-polkadot This PR/Issue is related to/affects the Polkadot network. labels Sep 28, 2023
@paritytech-ci paritytech-ci requested a review from a team September 28, 2023 11:10
@bkchr
Copy link
Member Author

bkchr commented Sep 28, 2023

bot fmt

@command-bot
Copy link

command-bot bot commented Sep 28, 2023

@bkchr https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/3833889 was started for your command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh". Check out https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/pipelines?page=1&scope=all&username=group_605_bot to know what else is being executed currently.

Comment bot cancel 21-2be17067-a4d6-4111-9ee5-f00880c1886f to cancel this command or bot cancel to cancel all commands in this pull request.

@command-bot
Copy link

command-bot bot commented Sep 28, 2023

@bkchr Command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh" has finished. Result: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/3833889 has finished. If any artifacts were generated, you can download them from https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/3833889/artifacts/download.

substrate/frame/staking/src/tests.rs Outdated Show resolved Hide resolved
substrate/client/rpc/src/author/mod.rs Outdated Show resolved Hide resolved
@bkchr
Copy link
Member Author

bkchr commented Sep 29, 2023

@jacogr polkadot-js should provide a way to use the runtime api directly to generate the sessions keys.

Scrape that, we need a new RPC for this.

@kianenigma
Copy link
Contributor

https://github.com/orgs/paritytech/teams/docs-audit this will require updates of the validator documentation to tell them what to pass for owner and that they need to pass proof to set_keys.

This is mostly in the Polkadot wiki, I will ping the w3f folks and also setup a system where they can listen to mentioned of this docs-audit team. But all in all, you should do your best to update the docs around this in the rust docs of pallet session at first.

serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 8, 2024
serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 8, 2024
serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 8, 2024
serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 8, 2024
serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 9, 2024
serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 9, 2024
serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 9, 2024
serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 9, 2024
serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 9, 2024
serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 9, 2024
serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 10, 2024
serban300 added a commit to serban300/polkadot-sdk that referenced this pull request Apr 10, 2024
bkchr pushed a commit that referenced this pull request Apr 10, 2024
@bkchr bkchr requested a review from a team as a code owner July 30, 2024 15:19
Copy link
Member

@davxy davxy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

}

impl_opaque_keys! {
/// Some comment
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment?

/// The `owner` should be something that can be used on chain for verifying the ownership of the
/// generated keys using the returned `proof`. For example `owner` could be set to the account
/// id of the account registering the returned public session keys. The actual data to pass for
/// `owner` depends on the runtime logic verifying the `proof`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can add an example here?

Something like: "For example, "session pallet" set_keys requires owner to be the account used to sign the extrinsic."

fn generate_session_keys(seed: Option<Vec<u8>>) -> Vec<u8> {
SessionKeys::generate(seed)
fn generate_session_keys(_: Vec<u8>, _: Option<Vec<u8>>) -> sp_session::OpaqueGeneratedSessionKeys {
sp_session::OpaqueGeneratedSessionKeys {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick. Makes sense to implement Default for OpaqueGeneratedSessionKeys? I see a couple of use cases around

@davxy davxy requested a review from a team August 15, 2024 10:30
@paritytech-cicd-pr
Copy link

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable 1/3
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7035748

Copy link
Contributor

@lexnv lexnv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logic looks good to me! 👍

@ordian
Copy link
Member

ordian commented Aug 19, 2024

cc @drskalman @AlistairStewart

@drskalman
Copy link
Contributor

This is a very important work and I'm not sure if my comment should be considered after its merger for future improvement or not.

  1. Proof of possession with BLS signature is secure only if it is done with different signature scheme than the one is used by the signer to sign other messages (using different hash function for example). The attack is described on page 15 of [1].
  • [1] Ristenpart, T., & Yilek, S. (2007). The power of
    proofs-of-possession: Securing multiparty signatures against
    rogue-key attacks. In , Annual {{International Conference}} on the
    {{Theory}} and {{Applications}} of {{Cryptographic Techniques} (pp.
    228–245). : Springer.
  1. In our flavor of BLS signature, The verification of proof of possession function not only the verifies that the signature is correct but also verifies that the signer has used the same private key to generate the public keys in $G1$ and $G2$:
    https://github.com/w3f/bls/blob/master/src/double_pop.rs#L67. This is not being tested by calling normal verify on the signature.

In that regard, it seems that the correct way of implementing the macro is perhaps to implement the proof of possession generation and verification inside each crypto module and then call that function instead of generic sign and verify and perhaps call generic sign and verify inside that function for all key types except for BLS.

  1. @AlistairStewart is of opinion that everybody in the world calls this "Proof of Possession" and not "Ownership proof". Calling it "ownership proof" make it very hard for any outsider to spot and find the code. I'm not sure what is cost of renaming these functions though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T1-FRAME This PR/Issue is related to core FRAME, the framework. T8-polkadot This PR/Issue is related to/affects the Polkadot network.
Projects
Status: Audited
Development

Successfully merging this pull request may close these issues.

7 participants