IPsec implementation flaw attacks¶
Attack pattern¶
Strong algorithms do not save a weak implementation. The library that runs the crypto, the code that gathers randomness, the daemon that parses IKE packets, each is software, and software has bugs the mathematics cannot fix. A non-constant-time operation leaks a key through timing, a starved random-number generator repeats a value it should never repeat, a parser mishandles a crafted packet, and one bug is enough to hand over everything the tunnel was protecting.
1.1.1 Implementation Flaws [OR]
1.1.3.1 Non-constant-time crypto operations
• Timing attacks on RSA-CRT implementation (Brumley and Boneh)
• Cache-timing attacks on AES T-table implementations
• Branch prediction attacks on elliptic curve point multiplication
• Memory access pattern leaks in modular exponentiation
1.1.3.2 Random number generator weaknesses
• Predictable seeding from a crippled entropy pool (CVE-2008-0166)
• Entropy starvation in virtualised environments
• RNG backdoors or predictable seeding
• Fork() process duplication causing RNG state duplication
1.1.3.3 Side-channel attacks (timing, power analysis)
• Power analysis attacks on hardware crypto accelerators
• Electromagnetic emanation analysis from network devices
• Acoustic cryptanalysis of hardware security modules
• Thermal imaging attacks on cryptographic operations
1.1.3.4 Memory corruption in crypto libraries
• Integer overflows in message processing
• Use-after-free in IKE SA state handling
• Heap corruption in certificate validation
Past the maths, not through it¶
Constant-time code is often traded away for speed, and the timing that remains leaks key material.
Virtual and cloud hosts struggle for entropy, so their random-number generators produce values an attacker can predict or catch repeating.
Side-channel attacks (timing, cache, power) need proximity, not a network breach, and read secrets a firewall never sees.
Cryptographic libraries run to millions of lines, and at that size memory-corruption bugs are a question of when, not if.
Optimisations lean on specific hardware behaviour that can itself be manipulated.
Old code paths kept for compatibility carry old, exploitable flaws.