HMAC Signature

HMAC relies on a single shared secret key known to both the client and the server. The sender computes the HMAC using this key and the message payload. The receiver independently computes the HMAC on the received payload with the same key. If the two digests match, it proves the sender possesses the shared secret and the message was not altered.

• Key Exchange Requirement: The secret must be exchanged securely out-of-band before communication begins.
• No Third-Party Trust: Unlike digital signatures, there is no reliance on a Public Key Infrastructure (PKI).

The algorithm is defined in RFC 2104 and combines a cryptographic hash function with a secret key. The process involves two passes of the hash function.

• Formula: HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))
• Inner Padding (ipad): The key is XORed with a block of 0x36 bytes and prepended to the message for the first hash.
• Outer Padding (opad): The key is XORed with a block of 0x5c bytes and prepended to the result of the first hash for the second, final hash. This nested structure protects against length extension attacks that affect simple H(key || message) constructions.

HMAC is not tied to a single hash function. It can be paired with any iterative cryptographic hash, such as those in the SHA-2 or SHA-3 families. The strength of the HMAC is directly proportional to the strength of the underlying hash function and the entropy of the secret key.

• Common Algorithms: HMAC-SHA256 and HMAC-SHA512 are the current best practices.
• Deprecated Algorithms: HMAC-MD5 and HMAC-SHA1 should be avoided due to collision vulnerabilities in the underlying hashes, even though they do not immediately break HMAC.

A critical distinction is that HMAC provides message authentication, not encryption. It proves the message came from a trusted source and was not modified, but the message itself remains in plaintext.

• Tamper Detection: Even a single bit flip in the payload will result in a completely different HMAC digest, causing verification failure.
• Replay Attack Vulnerability: A valid HMAC does not prevent an attacker from capturing a request and resending it. Mitigation requires combining HMAC with a nonce or timestamp check to ensure request freshness.

Computing an HMAC is a fast, symmetric operation with low computational overhead, making it suitable for high-throughput API endpoints. It adds minimal latency compared to asymmetric digital signatures like RSA.

• CPU Efficiency: Modern CPUs with hardware acceleration for SHA-256 can compute HMACs in microseconds.
• Compact Size: The output size is fixed to the length of the hash function's digest (e.g., 32 bytes for SHA-256), adding minimal overhead to HTTP headers.

In a typical API request, the HMAC is transmitted in a custom HTTP header, such as X-Signature or the standard Authorization header with a custom scheme. The server reconstructs the signing string from specific request components to verify the signature.

• Signing String Components: Often includes the HTTP method, request path, timestamp, and a hash of the request body.
• Example Header: Authorization: HMAC-SHA256 Credential=api_key/20240601, Signature=4d2a8c...
• Body Inclusion: Hashing the request body and including it in the signing string prevents body tampering independently of the headers.

The practice of encrypting request and response bodies at the application layer, providing defense-in-depth beyond transport-level TLS. While HMAC ensures integrity and authenticity, payload encryption ensures confidentiality of the inference data itself.

• Protects sensitive model inputs and outputs
• Works with JWE (JSON Web Encryption) standards
• Essential when serving models with PII or proprietary data

A defensive technique restricting the number of API requests a client can make within a timeframe. While HMAC verifies who is calling, rate limiting controls how often they can call. Together they prevent brute-force attacks and model extraction attempts.

• Uses sliding window or token bucket algorithms
• Prevents denial-of-service on inference endpoints
• Often keyed on the HMAC client identifier

A tamper-proof, chronological record of all access and query events stored in WORM-compliant storage. Each HMAC-signed request creates a verifiable audit entry proving which client made which inference call and when, ensuring non-repudiation for compliance.

• Stores HMAC signature metadata per request
• Enables forensic analysis of API usage
• Required for SOC 2 and HIPAA compliance