HMAC-Signed Threat Broadcast Authentication

1. Definition

HMAC-Signed Threat Broadcast Authentication governs the cryptographic authentication of threat level broadcasts exchanged between federated autonomous agent platforms. While AG-788 defines the propagation mechanism and message format, AG-789 ensures that every broadcast message is cryptographically authenticated using Hash-based Message Authentication Codes (HMAC), preventing message forgery, tampering, and replay attacks. The protocol establishes the end-to-end lifecycle of broadcast authentication: key provisioning, HMAC computation, signature attachment, verification on reception, and key rotation.

HMAC authentication provides a distinct security layer from transport-level encryption (TLS). While TLS protects the communication channel, it does not provide message-level authentication that persists beyond the transport session. An HMAC signature, computed over the broadcast message content using a shared secret key, accompanies the message and can be verified at any point — during reception, during audit, or during forensic investigation. This message-level authentication is essential because threat broadcasts may traverse intermediary systems (message brokers, federation hubs) where transport-level security terminates and re-establishes, creating gaps that an adversary could exploit.

The protocol specifies HMAC-SHA256 as the minimum acceptable algorithm, with HMAC-SHA384 and HMAC-SHA512 supported for environments requiring stronger assurance. Key management follows a bilateral shared-secret model where each pair of federated platforms maintains a unique HMAC key, ensuring that compromise of one bilateral relationship does not affect others. Key rotation is mandatory at configurable intervals, with overlap periods that allow both old and new keys to be accepted during rotation windows, preventing message loss during key transitions.

2. Scope

This protocol applies to all threat level broadcasts transmitted or received within federated governance deployments. Specifically:

• Broadcasting Platforms: Every platform that sends threat level broadcasts under AG-788 must compute and attach HMAC signatures before transmission.
• Receiving Platforms: Every platform that receives threat level broadcasts must verify HMAC signatures before processing the message content.
• Federation Key Management: The key management infrastructure that provisions, distributes, stores, rotates, and revokes HMAC keys for bilateral federation relationships.
• Intermediary Systems: Message brokers, federation hubs, and relay systems that forward broadcasts between platforms. These systems must preserve HMAC signatures intact during forwarding and must not have access to HMAC keys.
• Audit Systems: Systems that verify HMAC signatures on historical broadcasts during compliance reviews or forensic investigations.
• Exclusions: This protocol does not govern the broadcast format, delivery semantics, or propagation policies (see AG-788) nor the broader cryptographic key lifecycle (see AG-016).

3. Why This Matters

Federated threat propagation creates a trusted communication channel between autonomous agent platforms. If this channel is compromised, an adversary gains a powerful attack vector: they can inject false threat intelligence to trigger unnecessary escalations (causing operational disruption) or suppress genuine threat signals (leaving platforms exposed). HMAC authentication is the primary defence against these attacks, ensuring that every broadcast is provably from the claimed sender and has not been modified in transit.

Concrete Failure Scenario: An adversary performs a man-in-the-middle attack on the network path between a clearing house and a member bank in a financial federation. The adversary intercepts a genuine Level 2 broadcast from the clearing house and modifies it to Level 5 before forwarding it to the bank. The bank processes the forged Level 5 signal, which triggers mandatory human oversight (AG-019) and halts all autonomous transaction processing. During the resulting 4-hour disruption, the bank fails to process settlement transactions worth GBP 340 million, breaching contractual obligations and facing potential regulatory action from the FCA for failure to maintain orderly markets. With AG-789 in place, the bank's HMAC verification detects the tampered message, discards it, logs the incident, and continues normal operations based on its own local threat assessment.

The EU AI Act (Article 15(3)) requires that high-risk AI systems be resilient against attempts by unauthorised third parties to alter their behaviour through manipulation of inputs. SOX Section 302 requires that controls over information used in decision-making maintain their integrity. The FCA's SYSC 13.7.5 requires firms to ensure the security of communications with third parties. AG-789 operationalises these requirements for federated threat intelligence channels.

4. Requirements

• R1: The system MUST compute an HMAC signature over the complete broadcast message content (including all metadata fields defined in AG-788 R1) using HMAC-SHA256 or stronger (HMAC-SHA384, HMAC-SHA512).
• R2: The system MUST attach the HMAC signature, the algorithm identifier, and a key identifier to each outbound broadcast message before transmission.
• R3: Receiving platforms MUST verify the HMAC signature on every inbound broadcast before processing the message content. Messages with invalid or missing signatures MUST be discarded.
• R4: The system MUST maintain unique bilateral HMAC keys for each federated peer relationship. Compromise of one bilateral key MUST NOT affect the security of other federation relationships.
• R5: HMAC keys MUST be rotated at configurable intervals (default maximum: 90 days). During rotation, the system MUST accept signatures from both the old and new key for a configurable overlap period (default: 24 hours).
• R6: The system MUST log all HMAC verification results (success and failure) in the tamper-evident record (AG-006), including the message identifier, sender identity, verification result, and timestamp.
• R7: The system MUST implement replay protection by including a monotonically increasing sequence number or timestamp-based nonce in the HMAC-signed content, and rejecting messages with sequence numbers or nonces that have already been processed or that fall outside an acceptable window.
• R8: The system SHOULD store HMAC keys in a hardware security module (HSM) or equivalent secure key store, preventing extraction of key material by software processes.
• R9: The system SHOULD support algorithm agility, allowing the HMAC algorithm to be upgraded (e.g., from SHA-256 to SHA-384) without disrupting federation operations.
• R10: The system MAY support key distribution through an automated key exchange protocol, reducing the operational burden of manual key provisioning for large federations.

5. Maturity Model

Basic

At the Basic level, HMAC signatures are computed and verified on threat broadcasts using HMAC-SHA256. Bilateral keys exist for each federation relationship. Key rotation is manual and may not be performed at regular intervals. Replay protection is limited to timestamp-based checks without sequence numbers. HMAC keys are stored in software key stores with file-system-level access controls. Verification results are logged but may lack full metadata. Algorithm agility is not supported; changing the algorithm requires coordinated manual reconfiguration.

Intermediate

At the Intermediate level, key rotation is automated at configurable intervals with overlap periods for seamless transitions. Replay protection includes monotonic sequence numbers with sliding window validation. HMAC keys are stored in HSMs or equivalent hardware-backed key stores. Full verification metadata is logged in tamper-evident records. Algorithm agility is supported, allowing upgrades without federation disruption. All HMAC failures trigger automated security alerts. Key management is integrated with AG-016 for lifecycle governance.

Advanced

At the Advanced level, automated key exchange protocols reduce manual provisioning overhead for large federations. The HMAC authentication system has been validated through independent adversarial testing, including key extraction attempts, replay attacks, timing attacks on HMAC verification, and algorithm downgrade attacks. Key compromise recovery procedures have been tested and documented, including emergency revocation and re-keying workflows. Post-quantum HMAC algorithms are evaluated and roadmapped. End-to-end authentication latency overhead is measured and optimised to less than 1ms per message.

6. Test Criteria

• TC1: Generate a threat broadcast, compute its HMAC-SHA256 signature, transmit it to a peer, and verify that the peer successfully validates the signature. (Maps to R1, R2, R3)
• TC2: Modify a single byte of a signed broadcast in transit and verify that the receiving platform rejects the message due to HMAC verification failure. (Maps to R3)
• TC3: Verify that each bilateral federation relationship uses a unique HMAC key by confirming that a key used for Peer A cannot validate messages from Peer B. (Maps to R4)
• TC4: Initiate a key rotation, verify that during the overlap period both old and new keys are accepted, and verify that after the overlap period only the new key is accepted. (Maps to R5)
• TC5: Verify that all HMAC verification results (success and failure) appear in the tamper-evident record with complete metadata. (Maps to R6)
• TC6: Replay a previously valid broadcast message and verify that the receiving platform rejects it due to replay protection (duplicate sequence number or expired nonce). (Maps to R7)
• TC7: Attempt to extract HMAC key material from the key store through software-level access and verify that extraction is prevented. (Maps to R8)
• TC8: Upgrade the HMAC algorithm from SHA-256 to SHA-384 for one bilateral relationship and verify that message authentication continues without disruption during the transition. (Maps to R9)

7. Scoring

8. Failure Scenarios

F1: Message Tampering Undetected Due to Weak Algorithm (Maps to R1)

Scenario: A federation deploys HMAC-MD5 (a non-compliant, weak algorithm) for threat broadcast authentication. An adversary with significant computational resources computes an HMAC collision, allowing them to create a forged message with a valid HMAC signature. The forged message is accepted by the receiving platform.

Impact: CRITICAL. The entire authentication mechanism is defeated. The adversary can inject arbitrary threat intelligence into the federation.

Mitigation: R1 mandates HMAC-SHA256 as the minimum algorithm. MD5 and SHA-1 are explicitly excluded. Compliance testing (TC1) must verify the algorithm used. R9 recommends algorithm agility to facilitate future upgrades as cryptographic standards evolve.

F2: Bilateral Key Compromise Affecting Entire Federation (Maps to R4)

Scenario: A bilateral HMAC key between Platform A and Platform B is compromised through a phishing attack on an administrator. The adversary discovers that the same key is used for all federation relationships (a key reuse violation). The adversary can now forge messages from any platform to any other platform, effectively controlling the entire federation's threat intelligence.

Impact: CRITICAL. A single key compromise cascades to the entire federation, allowing the adversary to orchestrate coordinated false escalations or suppress genuine threats across all platforms.

Mitigation: R4 mandates unique bilateral keys for each relationship. TC3 verifies key uniqueness. R8 recommends HSM storage to prevent key extraction. Even if one bilateral key is compromised, it only affects that specific relationship.

F3: Replay Attack During Key Rotation Window (Maps to R5, R7)

Scenario: During a key rotation overlap period, an adversary captures a legitimate broadcast signed with the old key. After the overlap period ends, the adversary replays the captured message. If the receiving platform's replay protection only checks sequence numbers within the current key context (resetting the sequence with each new key), the replayed message may be accepted.

Impact: HIGH. The adversary can inject stale threat intelligence into the federation, potentially causing the receiving platform to escalate or decay its threat level based on outdated information.

Mitigation: R7 mandates replay protection that operates independently of key rotation. Sequence numbers must be monotonically increasing across key boundaries, not reset on rotation. Timestamp-based nonces with maximum age windows provide a secondary protection layer.

F4: HMAC Verification Bypass Through Missing Signature (Maps to R2, R3)

Scenario: A software bug in the broadcasting platform causes it to occasionally send messages without HMAC signatures when under high load. The receiving platform, designed to be resilient, processes unsigned messages rather than discarding them, reasoning that the transport-level TLS provides sufficient security.

Impact: HIGH. Messages without HMAC signatures cannot be authenticated at the message level. An adversary who can inject messages at the transport layer (e.g., through a compromised message broker) can send unauthenticated messages that are accepted.

Mitigation: R3 mandates that messages with missing signatures MUST be discarded. The verification engine must treat a missing signature as equivalent to an invalid signature. TC2 should be extended to test both tampered signatures and absent signatures.

9. Regulatory Mapping

10. Related Protocols

Document generated under Patent 7 governance framework. Classification: INTERNAL. Review cycle: Quarterly.