Security amendment to 0048 ownership proof

text/xxxx-improve-the-security-of-proof-of-possession.md

@@ -0,0 +1,95 @@
+# RFC-XXXX: Adding customized mandatory context to proof of possession statement
+
+|  |  |
+|--|--|
+| **Start Date** | 20 May 2025 2025 |
+| **Description** | Change `SessionKeys` runtime API to generate a customized ownership proof for each crypto type |
+| **Authors** | Andrew Berger - Syed Hosseini |
+
+## Summary
+
+This RFC is an amendment to RFC-0048. It proposes changing the OpaqueKeysInner:create_ownership_proof and OpaqueKeys:: ownership_proof_is_valid to invoke generation and validation procedures specific to each crypto type. This enables different crypto schemes to implement proof of possession that fits their security needs. In short, this RFC delegates the procedure of generating and validating proof of possession to the crypto schemes rather than dictating a uniform generation and verification.
+
+## Motivation
+
+Following RFC-0048, all submitted keys accompany a signature of the account_id by the same key, proving that the submitter knows the private key corresponding to the submitted key. However, a scheme should mandate a context-specific approach for generating proof of possession and a different context for signing anything else to prevent rogue key attacks \[3\]. While this is critical for schemes with aggregatable public keys, the other (non-aggregatable) crypto schemes opt for backward compatibility and accept signatures not prepended with mandatory context.
+
+
+However, the current RFC does not allow using different API calls and procedures to generate proof of possession for different crypto schemes.
+
+After this RFC, the procedure for generating and verifying proof of possession would be at the discretion of the crypto scheme itself, not deterministically tied to the way they sign other messages. Stakeholders
+
+* Polkadot runtime implementors
+* Polkadot node implementors
+* Validator operators
+
+## Explanation
+
+The RFC does not change the structure introduced by RFC-0048. The proof is a sequence of signatures:
+
+```rust
+type Proof = (Signature, Signature, ..);
+```
+
+However, each signature is generated by the crypto scheme instead of each private session key signing the `account_id`. By default, the following statement is signed by the crypto scheme:
+
+```
+rust
+"POP_"|account_id
+```
+
+The prefix could alert signers if they are misled into signing false proof of possession statements. More importantly, a new crypto scheme could specify a different structure for its proof of possession.
+
+Because RFC-0048 has not been deployed, the version of the `SessionKeys` could still be set to `1` as requested by RFC-0048.
+
+## Drawbacks
+
+Crypto scheme needs to implement an explicit `generate_proof_of_possession` and `verify_proof_of_possession` runtime API in addition to old capabilities (`sigen`, `verify`, etc).
+
+## Testing, Security, and Privacy
+
+The proof of possession for current crypto schemes is virtually identical to the one defined in RFC-0048. On the other hand, the changes proposed by this RFC allow the generation of secure proof of possession for BLS keys.
+
+## Performance, Ergonomics, and Compatibility
+
+### Performance
+
+The performance is the same as the one discussed in RFC-0048.
+
+### Ergonomics
+
+Separating the generation of proof of possession from signing allows a crypto scheme more freedom to implement proof of possession that is fitted to its needs.
+
+### Compatibility
+
+The significant difference is that proof of possession suggested by  RFC-0048 is signed:
+
+```
+rust
+account_id
+```
+
+vs the current proposal suggests changing the statement to:
+
+```
+rust
+"POP_"|account_id
+```
+
+for the current crypto scheme. However, future crypto schemes such as BLS, which are not bound to backward compatibility, could produce more sophisticated proof of possession.
+
+## Prior Art and References
+
+This is a minor amendment to RFC-0048.
+
+## Unresolved Questions
+
+None.
+
+## Future Directions and Related Material
+
+\- \[1\] Substrate implementation of the generation of proof of possession for all crypto schemes (current and experimental ones) is implemented in Pull 6010.
+
+\- \[2\] Substrate implementation of [RFC-0048](https://github.com/paritytech/polkadot-sdk/pull/1739), in which the implementation of `OpaqueKeysInner:create_ownership_proof` and `OpaqueKeys:: ownership_proof_is_valid` should be modified to call `generate_proof_of_possion` and `verify_proof_of_possession` runtime APIs instead of directly calling the sign.
+
+\- \[3\] 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).