Security: BFT PRE-PREPARE messages bypass signature and freshness checks

[createkr]

Summary

The BFT consensus receive path validates HMAC signatures for PREPARE and COMMIT messages, but _handle_pre_prepare() processes PRE-PREPARE messages without verifying the message signature or timestamp freshness. This creates an authentication gap on the message type that carries the proposal itself.

Affected component

• node/rustchain_bft_consensus.py
• _handle_pre_prepare()

Impact

A network peer that can reach the BFT message endpoint can send a forged or stale PRE-PREPARE message that passes leader/view/proposal checks and triggers downstream consensus state changes even though the PRE-PREPARE was never authenticated at the receive path.

Why this happens

• handle_prepare() and handle_commit() verify signatures before processing
• _handle_pre_prepare() did not perform the same verification
• CONSENSUS_MESSAGE_TTL exists but was not enforced for received PRE-PREPARE messages

Suggested fix

• Verify the PRE-PREPARE signature before accepting the message
• Reject stale PRE-PREPARE messages using the existing TTL window
• Keep validation behavior consistent across PRE-PREPARE / PREPARE / COMMIT handlers

I have a minimal fix prepared.

Wallet: RTC1d48d848a5aa5ecf2c5f01aa5fb64837daaf2f35

[createkr]

I opened a fix PR for this issue: #2062 Wallet: RTC1d48d848a5aa5ecf2c5f01aa5fb64837daaf2f35