Traditional IPSec VPN Security
Last Month, academic researchers have published a paper on “The Danger of Key Reuse: Practical Attacks on IPSec IKE”. IPsec has emerged as the most commonly used IP level VPN to provide confidentiality, integrity, peer authentication, replay protection, and access control. IPSec keys can be configured statically or dynamically generated using IKE protocol.
Internet Key Exchange (IKE) is used to negotiate, create, and manage keys for IPSec. IKE exists in two versions (IKEv1 and IKEv2) each with different modes and supports following authentication methods.
- Signature-based Authentication (IKEv1 and IKEv2)
- Public Key Encryption (PKE) based Authentication (IKEv1)
- Revised Public Key Encryption (RPKE) based Authentication (IKEv1)
- Pre-shared key (PSK) based Authentication (IKEv1 and IKEv2)
IKE consists of two phases.
Phase-1: To authenticate the peer and derive keys for IKE
Phase-2: To acquire keys for IPSec
In this research, authors have shown possible strikes on IKE Phase-1 based on Blechenbacher Oracle that exploits RSA encryption with PKCS#1 v1.5 padding. The RSA algorithm needs padding and PKCS #1 v1.5 is a widely used padding mode. There are more secure padding modes for RSA (PSS/OAEP), but they never gained widespread adoption.
Bleichenbacher’s oracle discovered fragilities in the implementation of the two RSA encryption based authentication in IKEv1 and signature-based authentication in IKEv1 and IKEv2. PSK based authentication also failed to stop dictionary based invasion if low entropy PSK is used.
Though Bleichenbacher dates back to 1998 and 20-year-old, vulnerabilities are being discovered even now. “Cisco, Huawei, Clavister, ZyXel have published fixes or workaround…” and “By repeating these attacks, all IKE implementations can be broken”, the paper has concluded.
To counter these aggressions, following suggestions has been proposed.
- Key Separation – Not only the sender but every receiver must also be informed about this key separation.
- PKE, RPKE authentication modes must be deactivated in ALL devices
- Use High-entropy PSK
However, numerous practical constraints prevail as above workarounds have to be applied on all the devices.
Lavelle SD-WAN
Lavelle SD-WAN does not rely on IKE to generate keys but built-on a cutting-edge platform that offers invincible end-to-end security architecture. Lavelle SD-WAN solution is built ground-up considering several aspects of security with the following key factors that nurture sure-enough security.
- Multi-layered Security Architecture
- Multiple levels of identification and authentication
- Mutual authentication with distinct identifiers and device fingerprints to defend the man in the middle
- Separate keys and certificates to different nodes and functions to assure key separation and bar key-reuse based intrusions
- Certificate pinning to distinguish MITM
- Multi-level encryption to secure data in transit and at rest
- Robust algorithms to sign, authenticate, conceal and integrity protect
- Strict version checks and policy enforcement
- Strong validation against configuration
- Continuous Authentication, Risk Assessment, and Frequent Key Refresh
Conclusion
What looks secure is not truly secure!! If a 20-year-old vulnerability is still present in your legacy VPN solutions, a good time to migrate to a revolutionary solution that not just protects but is Always ON – ScaleAOn
