October 17, 2012

A note to the Joint Committee regarding retrospective traffic decryption

In the corrected transcripts from the privately held evidence sessions of the Joint Committee for the draft Communications Bill there are several questions that suggest retrospective decryption of stored network traffic. We have sent a brief note to the committee to bring "forward secrecy" to their attention.

A note on storage of third-party encrypted data by CSPs and "Perfect Forward Secrecy"

For the Joint Committee on the draft Communications Data Bill

Author: Lee Maguire, Technical Officer, Open Rights Group

Questioning in the closed sessions has suggested a scenario under which a network CSP (i.e. ISP, such as BT) would be requested to store encrypted data-streams between their customers and third-party CSPs (such as Google). The implication that, under RIPA or equivalent, third-party CSPs would be requested to retrospectively decrypt this captured data.

(Q435-440, Q464-467, Q505-507, Q589-Q597. Q595 in particular)


We believe this scenario will be found to be unworkable for technical reasons. (With particular reference to point 5.)

  1. Requirement that the entire stream be captured will influence the way in which this data can be captured. The determination to capture a communication must be made at the very beginning of the connection. This would have implications in terms of cost and technical architecture.
  2. Requirement that the third-party CSP still has the key in question. It must be possible to identify and retrieve appropriate private key to decrypt. CSPs may have a large number of keys (e.g. some certificate signing authorities require a different certificate for each server, and hence a different key for each server.) Keys may only be kept during the lifetime of a specific server - hardware turnover rates may be quite high on larger sites. Indeed key certificates may expire and be replaced within the time period between capture and the request to decrypt.
  3. Retrospective decryption of TLS-encrypted streams is not a standard business function. If the appropriate procedure to do so is not available, time would need to be spent developing it. Regardless, it is likely an additional expense to the third-party CSP
  4. Security policies may require any key used for this purpose be retired from active use.  This would incur additional expenses in replacing them, and additionally the change in key would be publicly observable (potentially signalling that an order to decrypt has taken place).
  5. Even with access to the key, it may be possible that the stream cannot be decoded. Current technical implementations of the technology can use Diffie–Hellman key exchange to establish the use of a cipher which cannot be retrospectively decoded. Sessions that use a cipher-suite that provide Perfect Forward Secrecy (PFS) are not believed possible to decrypt since the key used to encrypt the session is not derived from the key held on the server. This technology exists precisely to protect encrypted streams from being decrypted in the event of the private key being compromised.

As an example: any encrypted stream between Google and a browser with PFS capacity (which now includes all widely used browsers), if stored, could then not be retrospectively decrypted by Google.  We anticipate wider adoption of PFS, especially by sites motivated to provide better privacy of their user's communications.  At best, any order for CSPs to store encrypted streams at public expense would accelerate adoption. 


There are companies offering retrospective decryption tools for TLS (only where Diffie-Hellman exchange is not used) which might be why it is imagined feasible.  For example Wireshark and Network Instruments Observer offer this facility.