Google engineers have enhanced the encryption offered in Gmail, Google Docs, and other services to protect users against retroactive attacks that allow hackers to decrypt communications months or years after they were sent.
The feature, a type of key-establishment protocol known as forward secrecy, ensures that each online session is encrypted with a different public key and that corresponding private keys are never kept in long-term storage. That, in essence, means there's no master key that unlocks multiple sessions that may span months or years. Attackers who recover a key will be able to decrypt communications exchanged only during a single session.
Google security guru Adam Langley said his team built the feature into Google's default SSL protection using a preferred cipher suite that's based on elliptic curve cryptography and the Diffie-Hellman key-exchange method. They have released their code as an addition to the OpenSSL library to reduce the work necessary for other websites to implement the protection.
“We would very much like to see forward secrecy become the norm and hope that our deployment serves as a demonstration of the practicality of that vision,” Langley wrote in a blog post published on Tuesday.
The move preserves Google as the uncontested leader in offering its users default protections. Last year, the web giant rolled out end-to-end SSL by default for users of its Gmail service. Last month, it introduced encrypted search. Competitors such as Twitter and Facebook – and to a much lesser extent – Microsoft frequently follow suit in the months that follow such releases.
Forward secrecy, which is also known as perfect forward secrecy, is important for protecting the continued confidentiality of encrypted communications over long periods of time. As computers grow faster and more powerful, it often becomes feasible to use brute-force attacks to crack encryption keys that only a decade earlier were considered unbreakable. Encrypted communications not protected by forward secrecy can be recorded and stored and only decrypted much later, once its single private key can be deduced.
The protection works by default with all versions of the Mozilla Firefox and Google Chrome browsers. Microsoft's Internet Explorer also supports the feature when the browser is running on Vista, and later versions of Windows, although not by default. That's because IE isn't compatible with some of the elements contained in the ECDHE-RSA-RC4-SHA cipher suite chosen by Langley's team.
As Langley explained in a deeper technical description, the Google implementation uses a single-session public key based on the elliptic curve, ephemeral Diffie-Hellman protocol that is then signed by a separate RSA private key belonging to Google. This makes the task of eavesdropping on someone over an extended period of time much harder, since each new session is protected by a different key.
The scheme also relies on TLS session tickets, which are cookie-like files that are stored on end-user machines and contain keys and other settings required by Google servers to resume a session. The use of session tickets is most likely intended to reduce the load on Google servers, but it also introduces potential security risks, particularly if an attacker could intercept or forge a valid file.
“This is actually a step backwards,” cryptographer Nate Lawson, who is principal of the Root Labs security consultancy, told The Register. “You're putting all your trust in the clients and hoping you don't make any mistakes on the server side.”
Of course, if Google does the cryptography right, there's little risk posed, and if the method significantly reduces the load on servers, it could bring forward secrecy to the computing masses. ®