11.3 Digital Signatures, HMAC, Algorithm Strength, and Cryptanalysis

Non-repudiation: signatures, HMAC, and audit trails

The remainder of knowledge area 5.2 is non-repudiation (digital signatures and certificates, Hash-based Message Authentication Code (HMAC), audit trails), strength of encryption algorithms and keys (AES, RSA), and cryptographic attacks and cryptanalysis. Domain 1.2 defined non-repudiation as the inability to deny having performed an action. Here you apply cryptographic evidence so a vendor, an administrator, or an API client cannot credibly say "that was not me" after the fact.

Three tools appear together on the outline because operations mix them up.

Digital signatures: hash, then sign, then verify

You almost never "encrypt the whole firmware file with the private key." The operational sequence is:

1. Hash the message or image with SHA-256 (or SHA-384) — the 11.2 primitive.
2. Sign the digest with the sender's private key (RSA-PSS, ECDSA, Ed25519, or a PQC signature such as ML-DSA when the platform has it).
3. Ship the message plus the signature. Optionally ship a certificate that binds the public key to the vendor name.
4. The receiver hashes the received bits independently and verifies the signature with the public key. If the digest matches and the certificate chains to a trust anchor that has not expired or been revoked, accept.

Signing is not confidentiality. A signed firmware image is often downloaded in the clear (or over TLS for transport privacy). Anyone can read it; they cannot forge a valid vendor signature without the private key.

Scenario: signing a firmware update. You run a fleet of perimeter firewalls. The vendor publishes fw-12.4.bin and fw-12.4.bin.sig. Each firewall has the vendor's code-signing certificate (or a pinned public key) in ROM. On update, the box hashes the bin, verifies the signature, and only then flashes. If an attacker replaces the bin on the web server, verification fails. If the attacker also replaces the vendor public key in firmware — they cannot, unless they already broke secure boot. If you instead HMAC the image with a key printed in the customer portal HTML, every customer can forge "vendor" updates. That is why the outline lists signatures and HMAC as non-repudiation examples: one of them actually scales to a one-to-many vendor relationship.

Certificates are the identity layer. Knowledge area 5.4 covers issuance, revocation, and key management in depth. For 5.2, know that a signature over a hash is only as strong as the binding "this public key belongs to Vendor X" and as the protection of the private key (HSM, offline CA, dual control).

HMAC in operations

HMAC combines a cryptographic hash with a secret key (FIPS 198 family; HMAC-SHA256 is the default you should expect). Without the key, an attacker cannot produce a tag that verifies. With the key, production is easy — on every node that has the key.

Where HMAC is the right SSCP tool:

• REST APIs between two services that already share a secret in a vault.
• Routing protocol authentication, some VPN authenticators, cookie integrity.
• Older TLS record integrity (modern TLS 1.3 prefers AEAD; the idea is the same: a keyed integrity check).
• Syslog or backup manifests when both the sender and the SIEM hold the MAC key.

Where HMAC is the wrong tool for non-repudiation:

• A vendor authenticating firmware to 4,000 customers who all received the same HMAC key.
• A dispute over which of two API partners issued a refund, when both hosts load HMAC_KEY from the same secret store.
• Any design that publishes the HMAC key in JavaScript, a mobile app, or a wiki.

Scenario continued. Two payment APIs share HMAC-SHA256 over the canonical request string (timestamp + method + path + body). That stops a random internet client from forging refunds. It does not settle a court fight between the two operators. For that you want each party to sign with its own private key, plus audit trails: HSM key-use logs, application logs shipped to a write-once store, and change tickets that show who could mint signatures. The outline's grouping — signatures/certificates, HMAC, audit trails — is the complete non-repudiation stack, not three synonyms.

Strength of encryption algorithms and keys: AES and RSA

The outline's examples are AES and RSA. Strength is not a single integer the SSCP secretly publishes. It is the combination of algorithm, key length, mode, protocol version, randomness, and implementation.

Practitioner facts you may use; do not memorize unpublished "exam-only" sizes:

• AES key sizes are 128, 192, and 256 bits. AES-128 remains a 128-bit classical security strength cipher when used correctly. AES-256 is the usual choice for long-lived archives and quantum-aware bulk data. There is no AES-512 in FIPS 197.
• RSA moduli for new protection are 2048 bits or larger. 1024-bit RSA is legacy. 3072-bit RSA is the common 128-bit-strength comparison; 4096-bit appears in some CA and SSH deployments. Bigger RSA is not linearly "twice as strong" in the way doubling an AES key is, and it is a poor substitute for AES on bulk data (11.2).
• Equivalent-strength mappings (NIST SP 800-57 style) are why ECC P-256 is discussed next to AES-128 and RSA-3072. The SSCP will not require you to reproduce every cell of that table, but it will punish treating RSA-1024 as equivalent to AES-256.
• Deprecated does not become strong because the key is long: 3DES with a 168-bit advertised key, RC4, MD5, SHA-1 signatures, export-grade 40-bit ciphers.

Implementation can destroy strength: constant keys in source code, AES-ECB, reused GCM nonces, private keys on a jumphost home directory, a hardware module that leaks via timing. An HSM or TPM storing the RSA private key is part of strength. So is disabling SSLv3 on the load balancer.

Cryptographic attacks and cryptanalysis

Cryptanalysis is the study of how to defeat cryptographic protection. SSCP items stay at conceptual level: which attack class matches the stem, and which operational control answers it. You will not be asked to write a padding-oracle exploit.

Other names you should recognize as cousins, not extra outline bullets: chosen plaintext / chosen ciphertext, replay (fix with timestamps, nonces, or sequence numbers inside the MAC), man-in-the-middle against unauthenticated key exchange (fix with signatures and certificates), rainbow tables against unsalted hashes (fix with unique salts — 11.2).

Scenario. A tester finds an old load balancer that still offers TLS 1.2 and SSLv3. When the client offers SSLv3, the server takes it. Error pages differ for invalid CBC padding versus a bad MAC. That is downgrade plus a padding-oracle-style leak. The remediation is not "AES-256 is 256 bits so brute force is impossible, ignore the finding." Disable SSLv3 and CBC suites, prefer TLS 1.2 AEAD or TLS 1.3, and retest. Brute-forcing AES-256 is not the realistic first attack; protocol downgrade is.

A second operations picture: a custom appliance compares HMAC tags with a byte-by-byte == that returns on the first mismatch. Remote timing recovers the tag. That is a side channel, not a birthday attack on SHA-256. Fix the compare (constant time), not the hash family.

Exam traps for 11.3

• Calling HMAC non-repudiation in a two-party dispute.
• Treating AES encryption of firmware as a vendor signature.
• Claiming SHA-256 is birthday-broken the way MD5 is.
• Claiming the SSCP requires one unpublished RSA bit length (use 2048+ as the practitioner minimum, AES 128/192/256 as the FIPS set).
• Answering every cryptanalysis stem with "brute force AES."
• Ignoring side channels because the algorithm is on a standards list.

When you sit the CAT item, name the property (non-repudiation versus authenticity), then the primitive (signature versus HMAC), then the attack class if the stem described one. The math is in service of the change ticket: pin a vendor public key, put the API HMAC in a vault, disable SSLv3, and log HSM sign operations.