System and process for TLS exceptionally verified eavesdropping

Abstract

Although TLS provides desirable end-to-end encryption, there are circumstances in which it is desirable or a regulatory requirement for a client to establish a TLS connection through an intermediary that is capable of creating an archival record. There is provided a modification to the TLS protocol that allows an aware client to provide a recovery record to such an intermediary. The recovery record permits the intermediary to verify that the encrypted recovery records can be decrypted by a party that holds the corresponding private key but does not enable decryption by the intermediary.

Claims

1. A process for Transport Layer Security (TLS) intercept comprising: negotiating a Transport Layer Security (TLS) tunnel to a server by a Transport Layer Security—Exceptionally Verified Eavesdropping (TLS-EVE) aware client through an intermediary, and performing an imperfect forward secrecy exchange by said client generating an ephemeral key pair {x, |e.sup.x|p} to perform a perfect forward secrecy exchange with said server by passing a value |e.sup.x|p to said server and said client passing a value d-x to said server en-clair; determining by said intermediary that communication can be decrypted by use of an offline key; decrypting said communications by a decryptor.

2. A process for encrypted communication intercept comprising: providing access to encrypted communications between a client and a server with an imperfect forward secrecy exchange by said client generating an ephemeral key pair {x, |e.sub.x|p} to perform a perfect forward secrecy exchange with said server by passing a value |e.sup.x|p to said server and said client passing a value d-x to said server en-clair; collecting said encrypted communications with a monitor, wherein said monitor is separate from a decryptor capable of decrypting said encrypted communications and said monitor is unable to decrypt said encrypted communications; receiving, by said monitor, an interception certificate; storing, by said monitor, said interception certificate in a memory location; accessing, by said monitor, said memory location to passively evaluate encrypted communication bits on the wire; collecting, by said monitor, encrypted communication compliant with said evaluation; and sending, by said monitor, said collected compliant encrypted communication to said decryptor, wherein said decryptor decrypts said encrypted communication.

3. The process according to claim 2 where said chosen encryption protocol is Transport Layer Security (TLS).

4. The process according to claim 2 of said monitor receiving said interception certificate comprising: passing a decryptor public key in-band from a key manager; and receiving said decryptor public key without requiring a response from said monitor; wherein said decryptor public key is in the form of an interpretation certificate.

5. The process according to claim 2 where said encrypted communication is saved within said monitor; and sending said encrypted communication to said decryptor for decryption.

6. The process according to claim 2 where said encrypted communication is not saved within said monitor; and routing said encrypted communication to said decryptor for decryption.

7. A system for Transport Layer Security (TLS) intercept comprising: a first network device which discloses key agreement material of said first network device; a second network device which does not disclose key agreement material of said second network device; a Transport Layer Security (TLS) tunnel established for communications between said first network device and said second network device; performing an imperfect forward secrecy exchange by said first network device generating an ephemeral key pair {x, |e.sup.x|p} to perform a perfect forward secrecy exchange with said second network device by passing a value |e.sup.x|p to said second network device and said first network device passing a value d-x to said second network device en-clair; a monitor for intercepting said communications between said first network device and said second network device and said monitor determining said communications can be decrypted but is incapable of decrypting said communications; and a decryptor for decrypting said communications.

8. The system according to claim 7 wherein said first network device is a client device.

9. The system according to claim 7 wherein said second network device is a server device.

10. The system according to claim 7 wherein said monitor observes communication packets and determines compliancy for security.

11. The system according to claim 7 wherein said first network device provides a recovery record to said monitor.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 is a schematic of the present invention.

(2) FIG. 2 is a schematic of the present invention with key distribution service.

DETAILED DESCRIPTION

(3) The TLS protocol provides a secure socket or tunnel between two network devices, a client (that initiates the communication) and a server (that responds to the communication request). The TLS protocol provides multiple key agreement schemes that provide Perfect Forward Secrecy. These schemes make use of either Diffie Hellman using the discrete log problem or Elliptic Curve Diffie Hellman. For simplicity, the protocol is described using the discrete log form, but the same approach may be applied in an Elliptic Curve Diffie Hellman as described later.

(4) In each case the general approach is as follows, let p be a prime and g be a primitive root modulo p.

(5) Client generates ephemeral Diffie Hellman key pair {x, |g.sup.x|p}, passes |g.sup.x|.sub.p to the server.

(6) Server generates ephemeral Diffie Hellman key pair {y, |g.sup.y|.sub.p}, passes, |g.sup.y|.sub.p to the client using some mechanism that provides authentication of the value under the Server certificate.

(7) The client and server both calculate the shared session key |g.sub.xy|.sub.p as follows:

(8) Client knows x (generated locally) and |g.sup.y|.sub.p (from the server), |(|g.sup.y|.sub.p).sup.x=|(g.sup.y).sup.x|.sub.p=|g.sup.xy|.sub.p

(9) Server knows y (generated locally) and |g.sup.x|.sub.p (from the server), |(|g.sup.x|.sub.p).sup.y=|(g.sup.y).sup.y|.sub.p=|g.sup.xy|.sub.p

(10) To achieve Imperfect Forward Secrecy, the protocol is modified as follows:

(11) First, there is an introduction of two additional parties, an interceptor and a decryptor. The interceptor has the ability to observe packets and determine that they are compliant with the protocol. Only the decryptor has the ability to decrypt packets.

(12) The same technique may be applied to other protocols that either make use of Perfect Forward Secrecy or may be modified to do so. Such protocols include IPSEC, SSH and QUIC.

(13) The same approach may also be applied to TLS but with disclosure of the ephemeral private key taking place at the client side.

(14) Unlike the previous approaches, a single modified TLS client may be used to establish TLS sessions that permit exceptional access with either internal or external hosts. In either case, the exceptional access approach is passive and does not rely on either forged credentials or knowledge of the server private key.

(15) The functions of interception and decryption are separated such that the interception device can determine that TLS communications can be decrypted but does not have the ability to decrypt them. Thus the interception device is not in itself a trusted device, compromise of the interception device does not compromise the network communications unless the decryption device is also compromised.

(16) Depending on the precise specification of TLS/1.3, the possibility exists to implement the protocol without the need to make use of either forged server credentials or knowledge of the server private key while maintaining compatibility with other TLS/1.3 implementations.

(17) EVE Imperfect Forward Secrecy

(18) The TLS-EVE protocol provides Imperfect Forward Secrecy. A passive monitor observing the network traffic can determine that TLS-EVE messages can be decrypted by an authorized party but is not necessarily capable of decrypting the traffic itself.

(19) Discloser The party that discloses its key agreement material, this may be either the client or the server.

(20) Counter-Party The party that does not disclose its key agreement material.

(21) Monitor A party that intercepts communications and determines that they can be decrypted but is not capable of decrypting them.

(22) Decryptor A party that has the ability to decrypt the communications.

(23) The Imperfect Forward Secrecy protocol may be implemented with disclosure occurring on the client side, the server side or both. This describes the case where disclosure takes place at the client.

(24) The Client, Server, Monitor and Decryptor are provisioned with cryptographic keys as follows:

(25) Client Has the decryptor private key D.sub.s=d

(26) Server Has the server private key S.sub.s and certificate C

(27) Monitor Has the server private key S.sub.s and decryptor public key D.sub.p=|e.sup.d|p

(28) Decryptor Has the decryptor private key D.sub.s=d

(29) The possible means by which these keys are established is described in the following section.

(30) The key S_s is only required if the key exchange is encrypted. This is the case for TLS/1.2 but not for TLS/1.3.

(31) The key pair {D.sub.s, D.sub.p} is a Diffie Hellman key pair, {d, |e.sup.d|p}

(32) To perform an Imperfect Forward Secrecy exchange, the client first generates an ephemeral key pair, {x, |e.sup.x|p}. This is used to perform a normal PFS exchange with the server, passing the value |e.sup.x|p to the server.

(33) In addition, the client passes the value d-x to the server en-clair. This allows the monitor and decryptor to verify that the communication can be decrypted and to decrypt the communication respectively, as follows:

(34) Monitor Has the decryptor public key |e.sup.d|p, obtains |e.sup.x|p and d−x from the channel. Calculates |e.sup.d-|p, verifies that |e.sup.x|p. |e.sup.d-x|p|=p|e.sup.d|p.

(35) Decryptor Has the decryptor private key d, obtains d-x from the channel. Calculates x=d−(d−x) and thus the means to perform the key exchange from the information provided by the server.
Protocol Mapping

(36) Cryptographic hygiene demands that each discloser party have a unique decryptor key pair. Otherwise the security gained from separating the monitor and decryptor functions is lost because the network master decryption key is known to discloser. Furthermore it is highly desirable that the disclosure keys be rotated frequently so that the decryption capabilities granted to an authorized party can be closely controlled.

(37) To implement the protocol in practice it is thus necessary to provision the necessary keying material to each party. The task of key distribution is assigned to a key distribution service.

(38) For reasons of efficiency and reliability, it is desirable that the number of parties required to communicate directly with the key manager is kept to a minimum. It is especially desirable that the Monitor be entirely passive and perform its function from the ‘bits on the wire’

(39) Passing the decryptor public key D.sub.p to the monitor in-band in the form of an interception certificate signed by the key distribution system eliminates the need for the monitor to communicate with the key distribution service.

(40) It is also possible to eliminate the need for the Decryptor to communicate with the key distribution service by encrypting the decryptor private key and including it in the interception certificate. This approach is less attractive however as it limits the degree to which the activities of the decryptor may be controlled and audited.

(41) Referring to FIG. 1, there is shown the present invention. A client device 100 of a network is in communication with a server 101 by an established TLS tunnel connection (secure socket). The client 100 initiated the communication and the server 101 responds to the communication request. An interceptor or monitor 102 is positioned between the client 100 and server 102 and has the ability to intercept the communications or communication packets of the traffic between client device 100 and server device 101 of the network. However, the monitor/interceptor does not have the ability to decrypt the traffic, only to observe and determine compliancy with security and protocols. A reader or decryptor 103 is in communication with the monitor 102 and has the ability to decrypt packets.

(42) FIG. 2 illustrates the invention shown in FIG. 1, with the added feature of a key distribution service 104 with public key information sent to the monitor 102 and private key information provided to the reader (decryptor) 103 and the client device 100.