[FOLLOW-UP] [ALIGNMENT]: Authenticated plaintext traffic in licensed/ham mode

[RCGV1]

[FOLLOW-UP] [ALIGNMENT]: Authenticated plaintext traffic in licensed/ham mode

Goal

Allow licensed/ham-mode Meshtastic nodes to publish an identity public key and XEdDSA-sign plaintext mesh traffic, including direct messages, without enabling payload encryption.

This is a follow-up to design#121, not part of its initial packet-policy PR stack. The current stack should retain its existing ham behavior and compatibility warning until this follow-up is reviewed and hardware-tested.

Why signatures fit the use case

Digital signatures provide origin authentication and data-integrity protection; they do not provide confidentiality. NIST describes signatures as detecting unauthorized modification and authenticating the signatory, while separately noting that signatures do not provide confidentiality or replay protection. See FIPS 186-5 and the NIST digital-signature glossary.

That distinction matters for amateur operation. In the United States, 47 CFR §97.113(a)(4) prohibits messages encoded for the purpose of obscuring their meaning; the FCC repeats that rule in Enforcement Advisory DA-24-1122. UK Ofcom guidance likewise says amateur messages generally shall not be encrypted and requires station identification; see sections 3.6.3.3 and 3.6.3.5 of Ofcom's amateur-radio guidance.

The proposed packets remain readable on air: only an identity public key and detached signature are added. This design does not make a universal legal determination. Operators remain responsible for their licence, jurisdiction, permitted modes, and callsign-identification requirements.

Current firmware behavior

Licensed mode currently:

• removes channel PSKs and disables the admin channel;
• prevents PKI encryption;
• prevents key generation in CryptoEngine::ensurePkiKeys() and NodeDB::generateCryptoKeyPair();
• strips User.public_key from outgoing NodeInfo;
• uses local-only rebroadcast behavior for encrypted traffic.

Because peers cannot obtain a key, licensed packets cannot be verified by XEdDSA and Strict receivers reject them.

Proposed behavior

1. Continue removing channel PSKs and prohibiting PKI/AES-CCM encryption in licensed mode.
2. Generate or restore the existing 32-byte identity keypair even when owner.is_licensed is true.
3. Publish the 32-byte public key in licensed NodeInfo.
4. Derive NodeNum = crc32(public_key), using the same identity binding as ordinary signed nodes.
5. XEdDSA-sign every locally originated, non-PKI Data packet that fits, including broadcasts and channel-plaintext unicast/direct messages.
6. Verify licensed traffic through the same Compatible/Balanced/Strict receive policy from design#121.
7. Never select the PKI encryption path for licensed traffic, even when both peers have keys.
8. Preserve normal callsign display/identification. A signed NodeInfo self-binds a callsign label to a key, but it is not a certificate authority and does not independently prove licence ownership.

Identity migration

Existing licensed nodes generally use a non-key-derived node number. Enabling keys therefore causes a one-time identity change so the public-key CRC binding can be verified.

The implementation must:

• preserve an existing valid private key across licensed-mode toggles and factory-reset flows that request key preservation;
• generate a key only when none exists or the stored key is known-compromised/low-entropy;
• reuse the normal identity migration path rather than maintaining two incompatible NodeNum constructions;
• warn clients before enabling licensed mode when the migration will change NodeNum;
• document that favorites, message history, remote-admin references, and peer caches may initially see a new node;
• send signed NodeInfo promptly after migration.

Direct-message semantics

“Authenticated ham direct message” means:

• the payload remains plaintext/no-PSK on air;
• the directed MeshPacket.to value is preserved;
• the inner Data carries a verifiable XEdDSA signature;
• Strict receivers accept it after signature verification;
• the UI uses the verified-signature shield meaning, not the encrypted-PKI lock meaning.

Signatures do not prevent an observer from reading the message and do not by themselves provide permanent replay protection.

Acceptance criteria

• Licensed NodeInfo includes a 32-byte public key and a valid signature.
• Licensed text, position, telemetry, routing, and NodeInfo broadcasts are signed when they fit.
• Licensed plaintext unicast/direct messages are signed when they fit and remain unencrypted on the wire.
• PKI encryption remains unreachable for licensed senders and receivers.
• A first-contact licensed NodeInfo passes the same crc32(public_key) == from bootstrap verification.
• Strict accepts verified licensed broadcasts and directed messages; invalid, unsigned, oversized, and unverifiable licensed traffic is rejected.
• Compatible/Balanced behavior remains as defined by design#121.
• Tests cover mode transitions, identity migration, key preservation/regeneration, wire readability, signature verification, and the no-PKI invariant.
• Client shield/lock semantics remain accurate and licensed-mode warnings/docs are updated.
• Firmware/client PRs remain draft until RF hardware capture confirms payload readability and signature interoperability.

Suggested sub-tasks

• Firmware implementation and migration tests.
• Android/Desktop, Apple, and Web licensed-mode warning/copy updates.
• On-device UI documentation/copy updates where licensed mode is configurable.
• Operator documentation with jurisdiction disclaimer and packet-capture evidence.

[RCGV1]

Firmware implementation draft: meshtastic/firmware#10969 reuses the existing XEdDSA tuple to sign fitting plaintext licensed broadcasts and directed packets, publishes the identity key, preserves the no-PKI/no-PSK/admin invariants across boot and restore, and adds migration warnings. It remains draft pending RF plaintext capture, cross-device interoperability, and integration with the Strict receive-policy work in firmware#10967.