Many of us are familiar with Secure Hypertext Transfer Protocol (HTTPS) that uses a cryptographic protocol commonly referred to as Transport Layer Security (TLS) to secure our communication on the Internet. In simple terms, there are two keys, one available to everyone via a certificate, called a public key and the other available to the recipient of the communication, called a private key. When you want to send encrypted communication to someone, you use the receiver’s public key to secure that communication channel. Once secured, this communication can only be decrypted by the recipient who has the private key.
The benefit of securing our communication to prevent snooping of sensitive data is obvious; however, encrypting the communication has its downside – it’s computationally expensive and requires a lot of CPU processing to enable, plus encrypted communication may be used in malicious ways to send proprietary information – see Is Your Data Secure From Hackers?
SSL/TLS Offload is a technique commonly used to secure applications while reducing the computational impact of enabling SSL/TLS. In SSL/TLS Offloading, devices such as Application Delivery Controllers (ADC), act as a SSL/TLS gateway for communication with external clients using strong ciphers, while proxying SSL/TLS sessions with internal clients (in a secure zone) at reduced cipher strength and may even reusing session keys. Traditionally, RSA cryptography has been used to secure these SSL/TLS sessions. To offer stronger security in keeping with higher computational power available to decrypt, the key size required to secure the communication has been increasing over time. The current standard is 2048-bit keys, which has doubled from the key size of 1024-bit just a few years back. The trend is toward a larger key size of 4096 or higher.
As we move to a larger key size, say from 1024-bit to 2048-bit, the processing requirement increases by a factor of four. The CPU processing for adopting higher key size directly affects the business services that are also sharing those CPU resources. As a rule of thumb, the number of client connections processed decreases by a factor of four by doubling the key size. The bottom line is that organizations require more hardware to process the same amount of traffic for a higher key size. Increasing key size and its associated processing requirements impact mobile devices disproportionately due to lower computational power available and the need to save on battery.
Enter ECC and PFS
The benefit of elliptic curve cryptography (ECC) is a smaller key size to provide the same level of security enabled by an RSA-based system with a large key size. As an example, a 256-bit ECC public key would provide security equivalent to a 3072-bit RSA public key. The smaller key size and lower processing requirements make elliptic curve cryptography a good fit for devices that are low on computational resources and memory such as mobile and IOT, enabling them to save on battery power.
Perfect Forward Secrecy (PFS) complements ECC. By generating a unique session key for each session a user initiates, PFS ensures that the encryption of a specific session is unique and specific to that session. The data to generate each session key is never actually sent over the wire. In the event that the private key is compromised, only one session (and not all the stored communication) can be decrypted and replayed. Prior to PFS, all recorded data transmissions could be decrypted if the server’s private key was ever compromised.
ECC and PFS adoption – let CVE-2014-0160 be your guide!
CVE-2014-0160, better known as Heartbleed, is a vulnerability in OpenSSL library that could allow a remote attacker to expose sensitive data, possibly including user authentication credentials and secret keys, through incorrect memory handling in the TLS heartbeat extension. You should care because a majority of commercial products use this library.
Once the private key has been compromised an attacker can impersonate the server and also decrypt any recorded encrypted traffic – ALL stored encrypted data is vulnerable. This is what PFS prevents.
The smaller key size and lower processing requirements make elliptic curve cryptography a clear winner for applications targeting mobile devices, enabling them to also dramatically save on battery power. With PFS, even though there is some overhead, securing data from replay in case of a key compromise, is a huge benefit.
For more details:
Read “Keep It Simple; Make It Scalable: 6 Characteristics of the Futureproof Load Balancer” to learn more.
Prakash Sinha, VP, ADC Solutions, Radware brings over 22 years of industry experience in strategy, product management and engineering.
Prior to Radware, Prakash led product management and ecosystem development for Citrix and was instrumental in introducing Citrix NetScaler VPX and SDX product lines to market. Prior to Citrix, Prakash held senior positions in architecture, engineering, and product management at leading technology companies such as Cisco, Informatica, and Tandem Computers.
Prakash holds a Bachelor in Electrical Engineering from India and an MBA from UC Berkeley.
*** This is a Security Bloggers Network syndicated blog from Radware Blog authored by Prakash Sinha. Read the original post at: https://blog.radware.com/applicationdelivery/2017/09/securing-applications-why-ecc-pfs-matter/