Perfect Forward Secrecy: Not So Perfect, Not So Forward

[Peter Fairbrother]

On 11/12/12 07:20, Ian Batten wrote:
> Communication Data scrutiny report [1], paragraph 92 implies that Google
> are in a position to retrospectively decrypt SSL sessions.


Well, I expect that that is because in most cases they are are in a 
position to retrospectively decrypt SSL sessions.

They know the private certificate key. I assume that that's the key 
Sarah Hunter is talking about [1].

SSL sessions do not, per se, offer forward secrecy of any kind unless a 
DHE suite is used (and despite the frequent abuse of the term by 
so-called "cryptographers", only OTP's offer any kind of "perfect" 
forward secrecy of a communication channel).

If a DHE cipher suite is not used then the session-master and session 
keys can be derived from the handshaking, if you know the private 
certificate key.

It's been a while since I checked, but I think Google do offer a DHE 
suite - but the client must ask for one, they are not used as default. 
By far, most sessions do not use DHE suites.


When a non-DHE cipher suite is used, as part of the handshake the client 
sends a random number encrypted with the public certificate key, which 
is decrypted by the server (which knows the private certificate key - 
but an observer who doesn't know the private key cannot decrypt this 
part of the intercepted handshake).

After that the server knows the secret random data, and the client 
obviously knows it as well, as the client generated it - and this shared 
secret random data is used to derive the session-master and session keys.



If a DHE suite is used then Google would have to retain their 
Diffie-Hellman Ephemeral secret - something they should not do - in 
order to retrospectively decrypt a session.



Afaik, SSL-everywhere and the like do not distinguish between DHE and 
non-DHE suites. They should.


[1] While Google, if it was entirely a UK company, could undoubtedly be 
required to hand over the private certificate key under RIPA - it is a 
dual-use key after all, it is used for key exchange as well as for 
authentication - they would understandably be very reluctant to hand it 
over to anyone under any circumstances whatsoever.

I think they would rather enforce all-DHE suites, so their private 
certificate key was only used for authentication (and therefore could 
not be demanded under RIPA) than have the key they use for 
authentication in someone else's possession - and I think that's what 
Sarah was actually saying.

-- Peter Fairbrother

>
> ian
>>
>> 92. Many internet services are encrypted; this includes many of the
>> major overseas based communications services such as Gmail. Encryption
>> is the basis of internet security and companies encrypt their services
>> to protect their customers. If these companies are asked directly for
>> communications data and agree to supply it, whether under RIPA or
>> following a request under a Mutual Legal Assistance Treaty (MLAT),
>> then they will decrypt the information, extract the relevant
>> communications data and provide it to the requesting authority in an
>> accessible format. They told us however that if information about
>> their service was collected by another CSP they would not cooperate in
>> helping decrypt it. Sarah Hunter from Google explained:
>>
>> “From a Google Inc perspective, we are very confident about the
>> security of our encryption. If a valid RIPA request comes in or UK law
>> enforcement goes through the MLAT, receives a court order and in turn
>> gets Gmail user data, we will obviously provide that data decrypted.
>> If it was to use a third-party provider to gather the encrypted data,
>> I think it very unlikely that Google Inc would provide anyone outside
>> Google Inc with that key. That is simply because, as everyone said
>> earlier, security is our most important asset. Our relationship with
>> our users is predicated on trust. Without that, we have no business”.65
>>
>
>
>
> [1]
> http://www.publications.parliament.uk/pa/jt201213/jtselect/jtdraftcomuni/79/79.pdf