Security in CRC
Overview
CRC (Cyclic Redundancy Check) is extremely effective at detecting accidental data corruption — bit flips, noise, EMI, and random transmission faults. However, in a security context, CRC becomes insufficient and potentially dangerous.
Because CRC is:
- linear
- predictable
- fully reversible
- based on public polynomials
…an attacker can deliberately craft payloads that produce a valid CRC, bypassing integrity checks entirely.
Security analysis focuses on understanding CRC’s limitations and reinforcing it with cryptographic integrity mechanisms such as MAC/HMAC.
Why CRC Fails in Security
CRC was designed for random errors, not malicious manipulation. Its mathematical properties make it easy to exploit:
- The polynomial is public → attacker can compute valid CRCs.
- CRC is linear → bit flips can be compensated.
- CRC is reversible → attacker can derive the required correction.
- CRC has no secret → no authentication, no tamper resistance.
In short: CRC detects noise, not attackers.
Main Security Threats
CRC Forgery
Attackers modify payloads and recompute a valid CRC, bypassing integrity checks.
Replay Attacks
Previously valid frames with correct CRC values can be resent to trigger unintended actions.
Polynomial Predictability
CRC polynomials are public and allow controlled manipulation of bits.
Linearity Exploitation
Attackers can flip specific bits while preserving the final CRC value.
Weak Integrity Boundaries
If CRC covers only the payload, metadata can be altered without detection.
Header Manipulation
Length, type, priority, or routing fields can be modified and re‑CRC’d.
Collision Crafting
Small CRC sizes (CRC‑8, CRC‑16) allow feasible collision generation.
Figures
Figure 1 — CRC Linearity Exploitation
Because CRC is linear, an attacker can flip bits in the payload and apply a compensating correction to maintain the same CRC value.
Figure 2 — CRC vs MAC Integrity Boundary
CRC protects against random errors; MAC protects against intentional tampering. CRC alone cannot authenticate the sender.
Figure 3 — CRC Forgery Attack Flow
An attacker captures a valid frame, modifies the payload, recomputes the CRC, and injects a forged but “valid-looking” message.
Mitigation Techniques
Cryptographic Integrity (MAC/HMAC)
Replace CRC with a keyed integrity mechanism for security‑critical data.
- Prevents tampering
- Prevents forgery
- Authenticates sender
Combined CRC + MAC
Use CRC for fast error detection and MAC for tamper detection.
- CRC detects random corruption
- MAC detects intentional manipulation
Freshness Mechanisms
Sequence counters, timestamps, and nonces prevent replay of valid CRC frames.
Payload Plausibility Checks
Validate that data patterns match expected physical or logical behavior.
Protocol Hardening
Ensure CRC covers:
- headers
- metadata
- control fields
Not just the payload.
Polynomial Strengthening
Use larger CRCs (CRC‑32/64) to reduce collision feasibility — but note: even CRC‑64 is not secure against attackers.
End‑to‑End Protection
Integrity must be applied across all layers, not only at PHY or link layer.
Relationship with Safety
CRC plays different roles in Safety and Security:
Safety
- Detects random bit errors
- Ensures reliable communication
- Works with parity, Hamming codes, timeouts
Security
- CRC alone is insufficient
- Cannot detect intentional manipulation
- Must be combined with MAC/HMAC
Where They Converge
- Fault injection attacks can mimic random corruption
- CRC detects errors but cannot guarantee authenticity
- Combining CRC + MAC provides both error detection and tamper resistance
