Message Authentication Code (MAC)

A MAC provides integrity verification, ensuring a message has not been altered in transit. The MAC algorithm uses a secret key shared between the sender and receiver to generate a short tag from the message. The receiver independently recomputes the tag; any mismatch indicates tampering or corruption.

• Mechanism: The tag is a function of the entire message content. A single-bit change produces a completely different tag with high probability.
• Example: In secure aggregation protocols, a client attaches a MAC to its model update before transmission. The aggregator verifies the MAC to ensure the update was not corrupted by network errors or malicious intermediaries.

A MAC provides authenticity assurance, confirming the message originated from a party possessing the shared secret key. This prevents impersonation and forgeries by unauthorized entities.

• Key Principle: Only entities with the secret key can generate a valid MAC for a given message. This binds the message to a specific sender (or group of senders).
• Application: In federated learning, the server can authenticate updates from legitimate, enrolled clients, rejecting contributions from unauthorized or spoofed devices.
• Limitation: Authenticity is symmetric; any party that can verify a MAC can also generate one. For non-repudiation, a digital signature is required.

The security of a MAC is fundamentally dependent on the secrecy of the symmetric key. The algorithm is public, but the output is unpredictable without the key.

• Design: Common MAC constructions like HMAC (Hash-based MAC) or CMAC (Cipher-based MAC) use cryptographic hash functions or block ciphers in a keyed mode.
• Requirement: The key must be established via a secure key agreement protocol (e.g., using TLS) and stored securely on both client and server.
• Threat Model: If the key is compromised, an adversary can forge valid MACs, breaking both integrity and authenticity guarantees.

For a given message and key, a MAC algorithm produces a deterministic, fixed-length output tag. This determinism enables efficient verification.

• Fixed Length: The tag is a short, constant-size string (e.g., 128 or 256 bits), regardless of input message size. This provides bandwidth efficiency.
• Verification Process: The receiver performs the same deterministic computation. No state or nonce is required for basic verification (unlike some authenticated encryption schemes).
• Caution: Determinism can be a weakness in certain contexts, as identical messages produce identical tags, potentially revealing message equality. This is addressed by including a nonce or message number in the MAC computation.

A secure MAC must be existentially unforgeable under chosen-message attacks (EUF-CMA). This means an adversary who can obtain MACs for arbitrary messages of their choice cannot forge a valid MAC for a new, previously unseen message.

• Security Definition: This is the formal gold standard for MAC security. It models an attacker with an oracle that generates MACs.
• Implication: Even learning MACs for many messages does not help an attacker produce a valid MAC for a different message. The probability of a successful forgery should be negligible.
• Relation to Aggregation: In secure aggregation, this property prevents a malicious client from forging a valid MAC on an aggregated sum they did not legitimately compute.

A critical limitation of MACs is the lack of non-repudiation. Because the secret key is shared, both the sender and receiver can generate identical MACs. The receiver cannot prove to a third party that a specific sender generated the message, as the receiver could have forged it themselves.

• Contrast with Digital Signatures: Digital signatures use asymmetric key pairs (private/public) to provide non-repudiation. The signer's private key is unique and not shared.
• Use Case Fit: MACs are ideal for point-to-point or closed-group communication where parties have mutual trust and a shared goal (e.g., server and clients in federated learning). They are faster and more efficient than signatures.
• Protocol Design: For audits requiring third-party verification, MACs must be complemented by additional logging or commitment schemes within a trusted execution environment.

In Federated Learning, MACs are critical for ensuring the integrity of model updates exchanged between clients and the aggregator.

• Integrity Assurance: Clients attach a MAC to their encrypted model update using a key shared with the server. This proves the update was not tampered with in transit.
• Preventing Poisoning: While MACs don't prevent malicious updates, they ensure the update received is exactly what the (potentially malicious) client sent, which is essential for audit trails and Byzantine detection.
• Protocol Integration: Used alongside Secure Aggregation and Homomorphic Encryption to provide a full confidentiality, integrity, and authenticity guarantee for the federated learning pipeline.

A cryptographic protocol in federated learning that allows a central server to compute the sum of client model updates without learning any individual client's contribution. It is the primary application context for MACs in federated edge learning.

• Purpose: Ensures the server only sees the aggregated result, not individual gradients or weights.
• Mechanism: Often uses cryptographic techniques like pairwise masking where clients add and subtract shared secrets that cancel out upon summation.
• Role of MACs: Used to authenticate each client's masked update, preventing malicious clients from corrupting the aggregation with invalid data.

A cryptographic system where the same secret key is used for both encryption and decryption. MACs are intrinsically linked to symmetric cryptography.

• Relationship to MACs: Most MAC algorithms (e.g., HMAC, CMAC) are built using symmetric cryptographic primitives like block ciphers (AES) or hash functions (SHA-256).
• Key Management: Both systems require secure, pre-shared key distribution between communicating parties.
• Contrast with Asymmetric: Faster and more efficient than public-key (asymmetric) encryption, making it suitable for authenticating high-volume data streams in distributed systems.

A specific, widely-used type of MAC calculated using a cryptographic hash function (like SHA-256) in combination with a secret key. It is a standard for data integrity and authenticity.

• Construction: HMAC(K, m) = H((K ⊕ opad) || H((K ⊕ ipad) || m)), where H is a hash function, K is the key, and m is the message.
• Security: Proven secure if the underlying hash function is collision-resistant.
• Usage: The default choice in many network security protocols (TLS, IPSec) and APIs for verifying message authenticity.

A cryptographic scheme that provides authentication, integrity, and non-repudiation using asymmetric (public-key) cryptography. It is a more powerful but computationally heavier alternative to a MAC.

• Key Difference: Uses a public/private key pair. The private key signs, the public key verifies. This provides non-repudiation—the signer cannot later deny signing.
• MAC vs. Signature: A MAC requires a shared secret and provides only authentication/integrity between parties who know the key. A signature provides publicly verifiable proof of origin.
• Application: Used in federated learning for authenticating server-to-client communications (e.g., model broadcasts) where the server's identity must be publicly verifiable by all clients.

An encryption mode that simultaneously provides confidentiality, integrity, and authenticity of the encrypted data. It often combines a symmetric cipher with a MAC.

• Schemes: Modern standards like AES-GCM (Galois/Counter Mode) perform encryption and authentication in a single, efficient operation.
• Composition: Can be built as Encrypt-then-MAC (encrypt plaintext, then MAC the ciphertext), which is generally the most secure method.
• Role in Secure Channels: Forms the basis for Transport Layer Security (TLS), securing all communication between federated learning clients and the central aggregator.

A standard security model (also called semi-honest) where participants follow the protocol correctly but may attempt to learn extra information from the messages they observe. MACs help enforce this model.

• Model Assumption: The server and clients execute the federated learning steps faithfully but are curious about individual data.
• MAC's Role: Prevents a curious server from accepting a forged update from a malicious client, which could bias the model or leak information about other clients' updates.
• Limitation: MACs do not protect against fully malicious adversaries who arbitrarily deviate from the protocol; stronger primitives like zero-knowledge proofs may be required.