P2P key and consensus key should not be the same key #26
Description
Separate P2P Node Key from Consensus Validator Key
Summary
This proposal separates the P2P network identity key from the consensus validator signing key by introducing a dedicated p2p_key.json file alongside the existing priv_validator_key.json.
Motivation
Currently, the same private key is used for both:
- P2P network identity - Establishing and authenticating peer connections
- Consensus operations - Signing proposals, votes, and other consensus messages
This coupling creates operational challenges and security limitations that prevent best practices for key management in production environments.
Benefits
1. Improved Operational Security
Problem: Using the same key for both P2P and consensus means:
- The signing key must be directly accessible by the node process
- Any compromise of the P2P layer exposes the consensus signing key
- No separation of concerns between network identity and validator authority
Solution: With separate keys:
- The P2P key can be stored on the node with standard file permissions
- The consensus key can be isolated with stricter access controls
- Network-level attacks don't directly threaten consensus signing capabilities
- Reduced blast radius in case of compromise
- This allow remote signing software to be used.
2. Flexible P2P Key Rotation
Problem: Rotating keys currently requires:
- Changing both network identity and validator identity simultaneously
- Coordination across the entire network
- Potential disruption to both P2P connectivity and consensus participation
Solution: With separate keys, operators can:
- Rotate P2P keys independently without affecting validator identity
- Change network identity if a node is being DDoS'd
- Migrate to new infrastructure without validator downtime
- Rotate P2P keys on a regular schedule as a security best practice
- Rotate consensus keys independently without changing network identity
- Update validator signing keys per security policy
- Maintain stable P2P connections during key rotation
Example scenarios:
# Rotate only the P2P key (no consensus impact) and extract just the p2p key file for use.
$ emerald init Remote Signer Integration (Critical Path)
Problem: The current architecture blocks integration with remote signing solutions like:
- Hardware Security Modules (HSMs)
- https://github.com/iqlusioninc/tmkms (Tendermint KMS)
- Cloud KMS services (AWS KMS, GCP KMS, Azure Key Vault)
- Air-gapped signing infrastructure
Solution: Separating keys enables the path to remote signing:
┌─────────────────────────────────────────────────────────────┐
│ Validator Node │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ │ │ │ │
│ │ P2P Layer │◄───────────────────┤ p2p_key.json│ │
│ │ │ (local access) │ │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ │
│ │ │ Network/IPC │
│ │ Consensus │◄──────────────────────────────────────────┼─────► Remote Signer
│ │ │ (gRPC/Unix socket) │ (HSM/KMS/tmkms)
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
This separation is a prerequisite for implementing remote signing because:
- The P2P key must remain on the node for real-time network operations
- The consensus key can be moved to secure remote infrastructure
- The node can operate without direct access to consensus signing material
- Supports compliance requirements for key isolation
- Operational Flexibility
Additional operational benefits:
- Infrastructure Migration: Move a validator to new hardware without changing its network identity
- Multi-Region Deployment: Run backup nodes with the same P2P identity but different consensus keys
- Testing: Use production P2P keys in staging environments with test consensus keys
- Audit Trail: Separate key materials make it easier to track and audit key usage patterns
Implementation
File Structure
~/.malachite/config/
├── config.toml
├── genesis.json
├── priv_validator_key.json # Consensus signing key
└── p2p_key.json # P2P network identity key (NEW)