Patent Grant
11895153
Secure Electronic Transaction (SET) allocated certificates to cardholders, merchants, and payment gateways such that purchase data was encrypted between the cardholder and the merchant, but payment information was encrypted between the cardholder and the gateway. The merchant received an authorization from the gateway to complete the purchase so goods and services could be provided to the cardholder. However, the SET implementation ultimately disregarded cardholder certificates and large merchants received the payment information along with the authorization from the gateway for clearing and settlement. Thus, SET was equivocally reduced to Secure Sockets Layer (SSL) technology between the cardholder and merchant, and between the merchant and payment gateway. SET was deployed in 1997 but decommissioned in 2002. While SSL was new, easier, simpler, and supported by the browser community, it was later deprecated and replaced by Transport Layer Security (TLS). SSL and TLS have had their own problems.
Aspects of the present disclosure relate generally to secure electronic transactions using Transport Layer Security (TLS), and more particularly to systems and methods for extending data protection of one or more data elements within a data packet beyond a TLS tunnel termination point by using encryption keys established when the TLS tunnel was established.
One arrangement disclosed herein is directed to a method of extending data protection of one or more data elements within a data packet beyond a TLS tunnel termination point by using application-level encryption keys generated when the TLS tunnel was established. In some arrangements, the method includes decrypting, by one or more processors, a data packet using a session key to recover a decrypted data packet, the data packet including a data element encrypted with a first content-specific key associated with a shared secret, the data packet encrypted with the session key, and decrypting, by the one or more processors, the data element of the decrypted data packet using a second content-specific key corresponding to a data type of the data element, to recover a decrypted data element.
One arrangement disclosed herein is directed to a system of extending data protection of one or more data elements within a data packet beyond a TLS tunnel termination point by using application-level encryption keys generated when the TLS tunnel was established. In some arrangements, the system includes one or more processors, and one or more computer-readable storage mediums storing instructions which, when executed by the one or more processors, cause the one or more processors to decrypt a data packet using a session key to recover a decrypted data packet, the data packet including a data element encrypted with a first content-specific key associated with a shared secret, the data packet encrypted with the session key, and decrypt the data element of the decrypted data packet using a second content-specific key corresponding to a data type of the data element, to recover a decrypted data element.
One arrangement disclosed herein is directed to a non-transitory computer-readable storage medium storing instructions which, when executed by one or more processors, cause the one or more processors to perform operations including decrypting, by one or more processors, a data packet using a session key to recover a decrypted data packet, the data packet including a data element encrypted with a first content-specific key associated with a shared secret, the data packet encrypted with the session key, and decrypting, by the one or more processors, the data element of the decrypted data packet using a second content-specific key corresponding to a data type of the data element, to recover a decrypted data element.
These and other features, together with the organization and manner of operation thereof, will become apparent from the following detailed description when taken in conjunction with the accompanying drawings.
Like reference numbers and designations in the various drawings indicate like elements.
The TLS protocol is designed to provide three essential services to all applications running above it: authentication, encryption and data integrity. To establish a cryptographically secure data channel between peers (e.g., client device to/from server, client device to/from another client device, server to/from another server), the peers negotiate with one another to agree on a set of keys (e.g., encryption keys) that will be used to encrypt the data. The TLS protocol defines a TLS handshake protocol that negotiates cryptographic parameters between the peers for the purpose of establishing TLS session keys. Specifically, the peers negotiate a shared secret (or shared secret key) without having to establish any prior knowledge of each other, and to do so over an unencrypted channel. For example, when a peer (e.g., a client device) attempts to establish a connection with another peer (e.g., a server), the peers generate and exchange public keys, such as a Diffie-Hellman Key (also referred to herein as, “TLS_DH”) and an ephemeral Diffie-Hellman Key (also referred to herein as, “TLS_DHE”) to establish the shared secret (i.e., common secret, master secret) between the peers. The peers then pass the shared secret through a key derivation function (KDF) that uses a pseudorandom function to generate (e.g., compute, derive, calculate) a data encryption (DE) key and a hash message authentication code (HMAC) key to facilitate confidentiality and integrity of the data.
After negotiating (e.g., computing, calculating, generating, etc.) the shared secret and generating the DE keys and the HMAC keys, the peers may communicate with one another by transmitting a data packet. To ensure data integrity, a peer transmits a data packet with an integrity check value (ICV) generated from the data packet using an HMAC key. Thus, the entire contents of the data packet are treated equally, even in instances when the data packet contains sensitive data elements (e.g., debit card pin, a password, a social security tax ID, biometrics, etc.) or components. That is, the TLS protocol simply encrypts the sensitive data elements and non-sensitive data elements of a data packet using the same DE key (or session key).
However, encrypting sensitive and non-sensitive data with the same encryption key may, depending on where the TLS tunnel terminates, expose the sensitive data to risky, unprotected environments. For example, an enterprise network may have an application running on a server in its demilitarized zone (DMZ). The client device (also referred to herein as, “a client”) and the server could terminate the TLS tunnel outside the DMZ via a router, inside the DMZ via a load balancer, or inside the DMZ via a web server. Consequently, if the client device and the server exchange a data packet that includes sensitive data elements (e.g., debit card pin, tax identifier, a password, etc.), then those sensitive data elements could be exposed to the environment at the TLS tunnel termination point. Thus, there is a long-felt need in providing a mechanism for encrypting sensitive data elements of a data packet such that termination of a TLS tunnel does not expose the sensitive data elements to an unprotected environment.
Accordingly, the present disclosure is directed to systems and methods for extending data protection of one or more data elements (e.g., sensitive data, personal data, financial data, etc.) within a data packet beyond a TLS tunnel termination point by using cryptographic keys established when the TLS tunnel was established. Specifically, and discussed in greater detail below, this disclosure describes an extension to the TLS protocol for generating content-specific keys (also referred to herein as, “SET keys”) by inserting an object identifier (OID) into a TLS protocol extension field of a data packet. In some arrangements, the system and methods described herein extend the TLS protocol (e.g., version 1.3, as defined in Request for Comments (RFC) 8446, and later versions) for generating content-specific keys. By providing application-level encryption without application-level key management, the systems and methods allow client/server applications to communicate in a way that may prevent eavesdropping, tampering, or message forgery.
In general, the TLS protocol allows a client device (e.g., client device 102 in
Once the peers (e.g., the client device and server) set up the TLS session keys, they may generate content-specific keys (e.g., pin encryption key, password encryption key, a biometrics encryption key, etc.) that could be used to encrypt one or more sensitive data elements of the data packet. Every sensitive data element that is encrypted with this extra layer of encryption, via the content-specific keys, may include the content of the sensitive data element and/or the object identifier indicating a data type (e.g., a pin, a tax id, etc.) associated with the sensitive data element. Since both parties know the common shared secret that was used to establish the TLS handshake, each party can generate (e.g., derive, establish, calculate) the content-specific keys without having to transmit the content-specific keys to one another across a communication network. Thus, the client device encrypts the sensitive data element (e.g., password, pin, tax identifier, etc.) of the data packet using a content-specific key associated with the sensitive data element to generate an encrypted sensitive data element. The client device then encrypts the entire data packet (also referred to as, “an application data packet” and/or data packet 110 in
In response to receiving the content-specific key and the decrypted data packet, the application decrypts the encrypted sensitive data element of the decrypted data packet. In some arrangements, the TLS tunnel decrypts the data packet using the TLS session key at the TLS tunnel termination point, decrypts the encrypted sensitive data element using the content-specific keys at the TLS tunnel termination point, and pushes the decrypted data packet and/or the decrypted sensitive data element to an application executing on the server. In some arrangements, an application executing on the server encrypts one or more sensitive data elements using the content-specific key to generate encrypted sensitive data elements, and passes the encrypted sensitive data elements to the TLS tunnel to be encapsulated into an encrypted data packet (using the TLS session keys) and transmitted to the client device.
A client device 102 may be an electronic device that is under control of a user and may be capable of receiving and/or sending TLS messages (e.g. a ClientHello message, a ServerHello message, a data packet, application data, etc.) to/from one or more TLS servers 104 and/or one or more client devices 102 over communication network 120. The client device 102 may be any number of different types of user electronic devices adapted to communicate over a communication network 120, including without limitation, a personal computer, a laptop computer, a desktop computer, a mobile computer, a tablet computer, a smart phone, a digital video recorder, a set-top box for a television, a video game console, or any other type and form of computing device or combinations of devices. In some arrangements, the type of client device 102 may be categorized as a mobile device, a desktop device, a device intended to remain stationary, a device adapted to primarily access a network via a local area network (e.g., communication network 120), or another category of electronic devices such as a media consumption device. The client device 102 may include a user application (e.g., a web browser) to facilitate the sending and receiving of data over communication network 120.
The TLS server 104 may be an electronic device that is capable of receiving and/or sending TLS messages (e.g. a ClientHello message, a ServerHello message, a data packet, application data, etc.) to/from one or more TLS servers 104 and/or one or more client devices 102 over communication network 120. The client device 102 may be any number of different types of user electronic devices adapted to communicate over a communication network 120, including without limitation, an application server, a catalog server, a communications server, a computing server, a database server, a file server, a game server, a mail server, a media server, a proxy server, a virtual server, a web server, or any other type and form of computing device or combinations of devices.
The communication network 120, (e.g., a local area network (LAN), wide area network (WAN), the Internet, or a combination of these or other networks) connects any electronic device (e.g., client device 102, TLS server 104, etc.) with one or more electronic devices and/or databases (e.g., OID database 112, content-specific key database 114). The environment 100 may include many thousands of client devices 102 and TLS servers 104 interconnected in any arrangement to facilitate exchange of data between the electronic devices. Although not illustrated, in many arrangements, the communication network 120 may comprise one or more intermediary devices, including gateways, routers, firewalls, switches, network accelerators, Wi-Fi access points or hotspots, or other devices. Any of the electronic devices and/or the communication network 120 may be configured to support any application layer protocol, including without limitation, Transport Layer Security (TLS), Secure Socket Layer (SSL), Hypertext Transfer Protocol (HTTP), and Hypertext Transfer Protocol Secure (HTTPS).
Still referring to
The client device 102 and/or the TLS server 104 may generate one or more object identifiers (also referred to herein as, “OID key types”). In some arrangements, the client device 102 may generate one or more object identifier (OID) key types and send (e.g., transmit, deliver) the object identifiers to the TLS server 104. In some arrangements, the TLS server 104 may generate one or more object identifiers and send (e.g., transmit, deliver) the object identifier to the client device 102. In some arrangements, the client device 102 may store one or more object identifiers in a database (not shown). In some arrangements, the TLST server 104 may store one or more object identifiers in a database (e.g., OID database 112 in
Example object identifiers (OID) are as follows:
In some arrangements, an object identifier may be expressed as a string of numbers. For example, an object identifier may be expressed as ‘1.3.133.16.840.9’ or ‘1.3.133.17’. As another example, an object identifier may be expressed as ‘1.3.133.16.840.9.n.2.1’, where “n” is the number of a yet-to-be-written X9 standard (e.g. n=144) for X9.144.
Each SET key (e.g., content-specific keys) is uniquely identified using an object identifier. For example, the object identifier, “set-pin-encrypt-key OBJECT IDENTIFIER::={set-key-type 1}”, uniquely identifies the SET key, “pin-encrypt-key” (also referred to herein as, “PIN encryption key (PK)”).
A TLS handshake protocol messaging may include a ClientHello 106 message sent from a client device 102 to a TLS server 104 to initiate the negotiation, and a ServerHello 108 message from the TLS server 104 responding back to the client device 102 to establish the session keys. The TLS message format (e.g., version 1.3, and beyond) includes an Extension field that may be used to exchange additional parameters. The ClientHello 106 message may include one or more fields, such as a Protocol Version field, Random field, an Opaque legacy session ID field, a Cipher Suites field, an Opaque legacy compression methods field, and an Extension field. The ServerHello 108 message may include one or more fields, such as a Protocol Version field, a Random field, an Opaque legacy session ID field, a Cipher Suites field, a Uint8 legacy compression methods field, and an Extension field.
The TLS server 104 may be configured to send a request to client device 102 requesting one or more secure electronic transactions (SET) data elements (also referred to herein as “sensitive data elements”). The ServerHello 108 Extensions may include one or more SET object identifiers instructing the client device 102 to derive additional SET keys (also referred to herein as, “content-specific keys”) from a shared secret that the peers (e.g., client and server) previously established and pass (e.g., deliver, send, transmit) the additional SET keys to a calling application. Once the SET keys have been passed to the server and client applications, the TLS server 104 and client device 102 can then destroy their copies of the SET keys.
A client application (e.g., internet browser, etc.) executing on the client device 102 may display a command prompt and/or a pop-up window to the user that requests one or more data elements or sensitive data elements (e.g., pin, password, tax ID, etc.). In some arrangements, the client application may fetch (e.g., retrieve) the one or more data elements from a stored location (e.g., a database, a server, another client device, etc.). The client application determines a data type associated with the one or more data elements and encrypts the data element, using a SET key (also referred to herein as, “a content-specific key”) corresponding to the data type, to generate a SET ciphertext (e.g., encrypted information, encoded information). For example, a user could provide an alphanumeric string, such as “password 1234”, via a command prompt or application (e.g., a browser). The client application could determine that “password 1234” is in the form of a password data type, and in response, the client application could encrypt the password with a SET key corresponding to a password encryption key (WK). As another example, the client application could determine that “123-45-6789” is in the form of a social security tax identifier type, and in response, the client application could encrypt the social security tax identifier with a SET key corresponding to a social security tax identifier key (XK).
The SET ciphertext (also referred to herein as, “an encrypted data element” or “data element encrypted with a content-specific key”) is provided to the client device 102 for encapsulation within the encrypted TLS data packet 110 (shown in
Each SET ciphertext data element is uniquely identified using a SET OD (also referred to as, “an object identifier”) along with the SET ciphertext encapsulated within the normally encrypted TLS data packet (also referred to as, “a data packet 110”). The following sample code shows a SET ciphertext data element.
The TLS server 104 decrypts the data packet 110 using the TLS session keys, and passes the cleartext blob to a receiving server application executing on the TLS server 104. The server application recognizes the SET ciphertext and decrypts it for further processing. In some arrangements, the server application may destroy its copies of the SET keys.
In some arrangements, the calling client and server applications may not send or receive encrypted sensitive data. In some arrangements, the client and server applications may perform encryption and decryption. In some arrangements, the client and server applications may manage the keys.
The TLS server 104 includes a processing circuit 202A composed of one or more processors 203A and a memory device 204A. A processor 203A may be implemented as a general-purpose processor, a microprocessor, an Application Specific Integrated Circuit (ASIC), one or more Field Programmable Gate Arrays (FPGAs), a Digital Signal Processor (DSP), a group of processing components, or other suitable electronic processing components. In many arrangements, processor 203A may be a multi-core processor or an array (e.g., one or more) of processors.
The memory 204A (e.g., Random Access Memory (RAM), Read-Only Memory (ROM), Non-volatile RAM (NVRAM), Flash Memory, hard disk storage, optical media, etc.) of processing circuit 202A stores data and/or computer instructions/code for facilitating at least some of the various processes described herein. The memory 204A includes tangible, non-transient volatile memory, or non-volatile memory. The memory 204A stores programming logic (e.g., instructions/code) that, when executed by the processor 203A, controls the operations of the TLS server 104. In some arrangements, the processor 203A and the memory 204A form various processing circuits described with respect to the TLS server 104. The instructions include code from any suitable computer programming language such as, but not limited to, C, C++, C#, Java, JavaScript, VBScript, Perl, HTML, XML, Python, TCL, and Basic. In some arrangements, the TLS server 104 may include an input/output circuit (not shown) for receiving/providing user input from/to a computing device (e.g., client device 102 and/or another TLS server 104). In some arrangements (referred to as “headless servers”), the TLS server 104 may omit the input/output circuit, but may communicate with a computing device (e.g., client device 102 and/or another TLS server 104) via network interface 206A.
The TLS server 104 includes a network interface 206A configured to establish a communication session with a computing device (e.g., client device 102 and/or another TLS server 104) for sending and receiving data over the communication network 120 to the computing device. Accordingly, the network interface 206A includes a cellular transceiver (supporting cellular standards), a local wireless network transceiver (supporting 802.11X, ZigBee, Bluetooth, Wi-Fi, or the like), a wired network interface, a combination thereof (e.g., both a cellular transceiver and a Bluetooth transceiver), and/or the like. In many arrangements, the TLS server 104 may include a plurality of network interfaces 206A of different types, allowing for connections to a variety of networks, such as local area networks or wide area networks including the Internet, via different sub-networks.
The TLS server 104 includes an authenticator circuit 220A that may be configured to authenticate a client device 102 to establish a shared secret and/or a connection. That is, the authenticator circuit 220A receives a request message (e.g., a ClientHello message) from a client device 102 or TLS server 104 requesting to establish a secure connection with the TLS server 104. The request message may include one or more message parameters, such as a protocol version, a client random, an opaque legacy session identifier, one or more cipher suites, opaque legacy compression methods, and/or an extension. The authenticator circuit 220A generates a ServerHello message that includes SSL certificates, its selected cipher suite, the server random, and/or any other message parameters. The authenticator circuit 220A may also include, in the ServerHello message, a server digital signature message establishing that the TLS server 104 has the private key that matches with the public key from the SSL certificate. The authenticator circuit 220A generates the server digital signature message via its private key by encrypting the client random, the server random, and a Diffie-Hellman (TLS_DH) parameter associated with the TLS server 104.
The authenticator circuit 220A may be configured to send the ServerHello message to the client device 102, causing the client device 102 to decrypt the TLS server's 104 digital signature with the public key and verifying (e.g., authenticating) that the TLS server 104 controls the private key. In response to verifying the TLS server 104, the client device 102 sends a DH parameter associated with the client device 102 to the TLS server 104. The authenticator circuit 220A generates (e.g., derives, computes, calculates) the shared secret based on the DH parameter associated with the server and/or a DH parameter associated with the client device 102.
The authenticator circuit 220A may be configured to receive from the client device 102, and in response to the client device 102 verifying the TLS server 104, the DH parameters associated with the client device 102. In response to receiving the DH parameters associated with the client device 102, the authenticator circuit 220A calculates session keys from the shared secret, client random, and server random. For example, the authenticator circuit 220A may pass the shared secret through a key derivation function (KDF) that uses a pseudorandom function to generate (e.g., compute, derive) one or more data encryption (DE) keys and/or one or more hash message authentication (HMAC) keys to facilitate confidentiality and integrity of the data.
The authenticator circuit 220A may be configured to send a ServerHello message to the client device 102 causing the client device 102 to generate a content-specific key (e.g., a first content-specific key) based on the shared secret and sending the content-specific key to the TLS server 104. In some arrangements, another content-specific key (e.g., a second content-specific key) may be the same or substantially the same as the content-specific key (e.g., a first content-specific key). In some arrangements, another content-specific key (e.g., a second content-specific key) may be different than the content-specific key (e.g., a first content-specific key).
The TLS server 104 includes an encryption/decryption circuit 222A that may be configured to receive from the client device 102, via a communication channel, a data packet. In some arrangements, the data packet may include one or more data elements, one or more encrypted data elements (e.g., a decrypted first data element, a decrypted second data element, etc.), and/or one or more object identifiers associated with the one or more of encrypted data elements. In some arrangements, a data element of a data packet may be encrypted (also referred to herein as, “an encrypted data element”) with a content-specific key (e.g., a first content-specific key) that is associated with the shared secret. In some arrangements, the data packet may be encrypted with a session key. In some arrangements, a data element of the data packet may be double-encrypted. For example, a data element may initially be encrypted with a content-specific key (e.g., a first content-specific key) that is associated with the shared secret and then the data packet (and all data elements of the data packet) may be encrypted with a session key. In some arrangements, a data packet may include one or more double-encrypted data elements (e.g., a data element encrypted with a content-specific key and then encrypted with a session key) and one or more single-encrypted data elements (e.g., a data element only encrypted with a session key). In some arrangements, a data packet may include a first data element encrypted with a first content-specific key associated with the shared secret, and a second data element that is not encrypted with the first content-specific key.
The encryption/decryption circuit 222A may be configured to decrypt a data packet using the session key to recover a decrypted data packet. For example, in response to receiving a data packet, the encryption/decryption circuit 222A may retrieve the session key from a database (e.g., OID database 112, content-specific key database 114). The encryption/decryption circuit 222A may then decrypt the data packet using the session key to recover a decrypted data packet. In some arrangements, the encryption/decryption circuit 222A may store the data packet in a database. In some arrangements, the encryption/decryption circuit 222A may decrypt the data packet at a TLS tunnel termination point.
The encryption/decryption circuit 222A may be configured to generate one or more content-specific keys based on the shared secret. For example, in response to decrypting the data packet, the encryption/decryption circuit 222A may determine an existence of an object identifier in the decrypted data packet by scanning one or more portions (e.g., a header, a header field, a payload, a TCP/IP header, an extension) of the decrypted data packet for an object identifier. In some arrangements, the object identifier may exist in a TCP/IP header of a data packet. In some arrangements, the object identifier may exist in an extension or extension block of a TLS data packet. In some arrangements, the encryption/decryption circuit 222A may determine an existence of an object identifier in the decrypted data packet by comparing the scanned portions of the decrypted data packet to object identifiers stored in the OID database 112 in
In response to determining an existence of an object identifier in the decrypted data packet, the encryption/decryption circuit 222A may identify the data element of the decrypted data packet that is associated with (or identified by) the object identifier. For example, the encryption/decryption circuit 222A may determine that the decryptor circuit includes the object identifier, “set-pin-encrypt-key OBJECT IDENTIFIER::={set-key-type 1}” and that the object identifier uniquely identifies the content-specific key, “pin-encrypt-key”. The encryption/decryption circuit 222A may then extract the data element associated with the object identifier from the decrypted data packet by scanning one or more portions (e.g., a header, a header field, a payload, a TLS extension) of the decrypted data packet for a data element associated with the “pin-encrypt-key”. In some arrangements, the encryption/decryption circuit 222A copies (e.g., without extracting) the data element associated with the object identifier from the decrypted data packet. The encryption/decryption circuit 222A may determine that the object identifier identifies at least one of a pin key type, a password key type, a social security tax identifier key type, a tokenization key type, and a to-be-defined key type.
The encryption/decryption circuit 222A may generate a content-specific key (also referred to herein as, “second content-specific key”) associated with the data element based on the session key and the object identifier. For example, the encryption/decryption circuit 222A may determine that the object identifier, “set-pin-encrypt-key OBJECT IDENTIFIER::={set-key-type 1}”, uniquely identifies the content-specific key, “pin-encrypt-key”. In response, the encryption/decryption circuit 222A generates a content-specific key in the form of a pin encryption key (referred to herein as, “PIN encryption key (PK)”).
The encryption/decryption circuit 222A may decrypt the data element using the content-specific key to recover a decrypted data element. In some arrangements, the encryption/decryption circuit 222A may store the one or more content-specific keys that it generates in the content-specific key database 114 in
The encryption/decryption circuit 222A may grant (e.g., authorize, allow, approve), via the communication channel, permission for the client device 102 to access one or more resources (depicted in
The encryption/decryption circuit 222A may deliver, from a TLS tunnel termination point, the content-specific key (also referred to herein as, “second content-specific key”) that the encryption/decryption circuit 222A generated and the decrypted data packet to an application (e.g., TLS Server Resources 270A) executing on the TLS server 104. The encryption/decryption circuit 222A may decrypt, at the application executing on the TLS server 104, the data element of the decrypted data packet using the second content-specific key to recover the decrypted data element.
The TLS server 104 includes a bus (not shown), such as an address/data bus or other communication mechanism for communicating information, which interconnects subsystems and devices, such as the network interface 206A, the authenticator circuit 220A, and the encryption/decryption circuit 222A, or any other subsystem and device of the TLS server 104. In some arrangements, the TLS server 104 may include one or more of any such components.
In some arrangements, some or all of the circuits of the TLS server 104 may be implemented with the processing circuit 202A. For example, the network interface 206A, the authenticator circuit 220A, and the encryption/decryption circuit 222A may be implemented as a software application stored within the memory 204A and executed by the processor 203A. Accordingly, such arrangement can be implemented with minimal or no additional hardware costs. In some arrangements, any of these above-recited circuits rely on dedicated hardware specifically configured for performing operations of the circuit.
In some arrangements, the client device 102 includes a processing circuit 202B having a processor 203B and memory 204B. The processor 203B is implemented as a general-purpose processor, a microprocessor, an ASIC, one or more FPGAs, a DSP, a group of processing components that are distributed over various geographic locations or housed in a single location or device, or other suitable electronic processing components. In many arrangements, processor 203B may be a multi-core processor or an array (e.g., one or more) of processors.
The memory 204B (e.g., RAM, NVRAM, ROM, Flash Memory, hard disk storage, etc.) stores data and/or computer instructions/code for facilitating the various processes described herein. Moreover, the memory 204B is or includes tangible, non-transient volatile memory or non-volatile memory. Accordingly, the memory 204B includes database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein. The instructions include code from any suitable computer programming language such as, but not limited to, C, C++, C#, Java, JavaScript, VBScript, Perl, HTML, XML, Python, TCL, and Basic.
The client device 102 includes a network interface 206B configured to establish a communication session with a computing device (e.g., a TLS server 104 and/or another client device 102) for sending and receiving data over the communication network 120 to the computing device. Accordingly, the network interface 206B is an interface such as, but not limited to, the network interface 206A in
The client device 102 includes an input/output circuit 205B configured to receive user input from and provide information to a user. In this regard, the input/output circuit 205B is structured to exchange data, communications, instructions, etc. with an input/output component of the client device 102. Accordingly, input/output circuit 205B may be any electronic device that conveys data to a user by generating sensory information (e.g., a visualization on a display, one or more sounds, tactile feedback, etc.) and/or converts received sensory information from a user into electronic signals (e.g., a keyboard, a mouse, a pointing device, a touch screen display, a microphone, etc.). The one or more user interfaces may be internal to the housing of client device 102, such as a built-in display, touch screen, microphone, etc., or external to the housing of client device 102, such as a monitor connected to client device 102, a speaker connected to client device 102, etc., according to various arrangements. In some arrangements, the input/output circuit 205B includes communication circuitry for facilitating the exchange of data, values, messages, and the like between the input/output device and the components of the client device 102. In some arrangements, the input/output circuit 205B includes machine-readable media for facilitating the exchange of information between the input/output device and the components of the client device 102. In still another arrangement, the input/output circuit 205B includes any combination of hardware components (e.g., a touchscreen), communication circuitry, and machine-readable media.
The client device 102 includes a device identification circuit 207B (shown in
The client device 102 includes an authenticator circuit 220B that may be configured to authenticate a TLS server 104 or another client device 102 to establish a shared secret and/or a secure connection. That is, the authenticator circuit 220B sends a request message (e.g., a Client Hello message) to a TLS server 104 or another client device 102 requesting to establish a secure connection with the client device 102. The request message may include one or more message parameters, such as a protocol version, a client random, an opaque legacy session identifier, one or more cipher suites, opaque legacy compression methods, and/or an extension. The ClientHello may cause the TLS server 104 to generate a ServerHello message, as discussed herein, and send the ServerHello message to the client device 102.
The authenticator circuit 220B may be configured to receive and process a ServerHello message. In response to receiving the ServerHello message, the authenticator circuit 220B decrypts the TLS server's 104 digital signature from the ServerHello message using the public key and verifies (e.g., authenticates) that the TLS server 104 controls the private key. In response to verifying the TLS server 104, the authenticator circuit 220B generates and sends a DH parameter associated with the client device 102 to the TLS server 104, causing the TLS server 104 to generate a shared secret based on the DH parameter associated with the TLS server 104 and/or a DH parameter associated with the client device 102. The authenticator circuit 22B generates a shared secret based on the DH parameter associated with the TLS server 104 and/or a DH parameter associated with the client device 102. The shared secret generated by the TLS server 104 and the client device 102 may be the same, or substantially the same, shared secret.
The authenticator circuit 220B may be configured to send the DH parameters associated with the client device 102 to the TLS server 104, causing the TLS server 104 to calculate session keys from the shared secret, client random, and/or server random. The authenticator circuit 220B may be configured to generate session keys. For example, the client device 102 may pass the shared secret through a key derivation function (KDF) that uses a pseudorandom function to generate (e.g., compute, derive) one or more data encryption (DE) keys and/or one or more hash message authentication (HMAC) keys to facilitate confidentiality and integrity of the data.
The authenticator circuit 220B may be configured to generate content-specific keys. For example, the authenticator circuit 220B may receive a ServerHello message from the TLS server 104 and, in response, generate a content-specific key (e.g., a first content-specific key) based on the shared secret. In some arrangements, the client device 102 may send the content-specific key to the TLS server 104. In some arrangements, another content-specific key (e.g., a second content-specific key) may be the same or substantially the same as the content-specific key (e.g., a first content-specific key). In some arrangements, another content-specific key (e.g., a second content-specific key) may be different than the content-specific key (e.g., a first content-specific key).
The client device 102 includes an encryption/decryption circuit 222B that may be configured to encrypt one or more data elements (or portions) within application data. For example, the encryption/decryption circuit 222B may receive application data from a TLS client application (e.g., TLS client application 270B in
The encryption/decryption circuit 222B may be configured to generate a data packet to send to a TLS server 104 or another client 102 device. For example, the encryption/decryption circuit 222B may generate a data packet (e.g., data packet 110) that includes the one or more data elements within the application data. The encryption/decryption circuit 222B may include one or more object identifiers in a TCP/IP header of the data packet based whether the encryption/decryption circuit 222B encrypted any of the data elements. For example, the encryption/decryption circuit 222B may have encrypted a first data element containing a pin with a first content-specific key (e.g., “pin-encrypt-key”) and a second data element containing a social security number with a second content-specific key (e.g., “ssn-encrypt-key”). In response to the encryption, the encryption/decryption circuit 222B may insert a first object identifier (e.g., set-pin-encrypt-key OBJECT IDENTIFIER::={set-key-type 1}) into the TCP/IP header of the data packet that uniquely identifies the first content-specific key (e.g.,) and a second object identifier (set-ssn-encrypt-key OBJECT IDENTIFIER::={set-key-type 3}) into the TCP/IP header of the data packet that uniquely identifies the second content-specific key. The encryption/decryption circuit 222B may then encrypt the data packet (including the encrypted and/or non-encrypted data elements) with a session key. In some arrangements, the encryption/decryption circuit 222B generates a data packet based on the Transport Layer Security (TLS) protocol.
In some arrangements, the encryption/decryption circuit 222B may be configured to include some or all of the functionality of the encryption/decryption circuit 222A in
The client device 102 includes (or executes) a TLS client application 270B that is communicably coupled to the TLS server 104 via the communication network 120 and is configured to access one or more resources provided by the TLS server 104. In this regard, the TLS client application 270B is configured to send/receive data (e.g., data packet 110 in
The TLS client application 270B includes a collection agent 215B. Collection agent 215B may include an application plug-in, application extension, subroutine, browser toolbar, daemon, or other executable logic for collecting data processed by TLS client application 270B and/or monitoring interactions of user with the input/output circuit 205B. In other arrangements, collection agent 215B may be a separate application, service, daemon, routine, or other executable logic separate from TLS client application 270B but configured for intercepting and/or collecting data processed by TLS client application 270B, such as a screen scraper, packet interceptor, application programming interface (API) hooking process, or other such application. The collection agent 215B is configured for intercepting or receiving data input via input/output circuit 205B, including mouse clicks, scroll wheel movements, gestures such as swipes, pinches, or touches, or any other such interactions; as well as data received and processed by TLS client application 270B. The collection agent 215B, may begin intercepting/gathering/receiving data input via its respective input/output circuit based on any triggering event, including, e.g., a power-up of client device 102 or a launch of any software application executing on a processor of client device 102.
The client device 102 includes a bus (not shown), such as an address/data bus or other communication mechanism for communicating information, which interconnects subsystems and devices, such as processing circuit 202B, processor 203B, memory 204B, network interface 206B, input/output circuit 205B, device ID circuit 207B, TLS client application 270B, encryption/decryption circuit 222B, authenticator Circuit 220B, or any other subsystem and device of the client device 102. In some arrangements, the client device 102 may include one or more of any such components.
In some arrangements, some or all of the circuits of the client device 102 may be implemented with the processing circuit 202B. For example, the subsystems and devices of client device 102 may be implemented as a software application stored within the memory 204B and executed by the processor 203B. Accordingly, such arrangement can be implemented with minimal or no additional hardware costs. In some arrangements, any of these above-recited circuits rely on dedicated hardware specifically configured for performing operations of the circuit.
As shown in
As shown in
Once the TLS Client 502 and the TLS Server 504 establish (e.g., agree upon) session keys, then the TLS Client 502 and the TLS Server 504 each generate SET keys (e.g., SET keys 540 and SET keys 542) that may be used to encrypt/decrypt one or more data elements within the data packet. For example, the App Client 506 sends application data 524 to the TLS Client 502 that includes a first data element (e.g., a pin) and a second data element (e.g., a social security number). The TLS Client 502 encrypts the first data element using a SET key (e.g., a pin encryption key) associated with the first data element. The TLS Client 502 encrypts the second data element using a SET key (e.g., a social security number encryption key) associated with the second data element. After encrypting the data elements with its associated encryption key, the TLS Client 502 inserts into a TLS protocol extension field of the application data 524 an object identifier (MD) for each encrypted data element that uniquely identifies the SET key used to generate the respective data element. The TLS Client 502 then encrypts the application data 524 (including all the data elements) using the set of keys to generate encrypted application data 526. The TLS client 502 sends via a network (e.g., communication network 120 in
Using the set of keys, the TLS Server 504 decrypts the encrypted application data to recover a decrypted application data. The TLS Server 504 scans the TLS protocol extension field for any object identifiers. In response to determining an occurrence of one or more object identifiers, the TLS Server 504 decrypts each data element using a SET key that is uniquely identified by the object identifier associated with the respective data element. That is, the TLS Server 504 decrypts the first data element using a SET key 542 (e.g., a pin encryption key) associated with the first data element. The TLS Server 504 decrypts the second data element using a SET key 542 (e.g., a social security number encryption key) associated with the second data element. The TLS Server 504 sends the decrypted application data (including each of the decrypted data elements) to the App Server 508. The App Client 506 may send an end call 530 to the TLS Client 502. In response, the TLS Client 502 sends an end 532 to the TLS Server 504, causing the TLS Server 508 to end (e.g., terminate, halt) the secure connection. This process may be repeated in the opposite direction in instances when the App Server 508 sends application data 528 to the App Client 506. In some arrangements, the TLS Client 502 may send the SET keys 540 that it generates to the App Client 506, such that the App Client 506 may encrypt one or more data elements within the application data 524 using the SET keys 540 prior to delivering the application data 524 to the TLS Client 502. In some arrangements, the TLS Server 504 may send the SET keys 542 that it generates to the App Server 508, such that the App Server 508 may decrypt the one or more data elements within the application data 528 using the SET keys 542 upon receiving the application data 528 from the TLS Server 504.
As shown in
The arrangements described herein have been described with reference to drawings. The drawings illustrate certain details of specific arrangements that implement the systems, methods and programs described herein. However, describing the arrangements with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings.
It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”
As used herein, the term “circuit” may include hardware structured to execute the functions described herein. In some arrangements, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein. The circuit may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some arrangements, a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, etc.), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” may include any type of component for accomplishing or facilitating achievement of the operations described herein. For example, a circuit as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR, etc.), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on).
The “circuit” may also include one or more processors communicatively coupled to one or more memory or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. In some arrangements, the one or more processors may be embodied in various ways. The one or more processors may be constructed in a manner sufficient to perform at least the operations described herein. In some arrangements, the one or more processors may be shared by multiple circuits (e.g., circuit A and circuit B may comprise or otherwise share the same processor which, in some example arrangements, may execute instructions stored, or otherwise accessed, via different areas of memory). Alternatively or additionally, the one or more processors may be structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example arrangements, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. Each processor may be implemented as one or more general-purpose processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor, etc.), microprocessor, etc. In some arrangements, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor). Alternatively or additionally, the one or more processors may be internal and/or local to the apparatus. In this regard, a given circuit or components thereof may be disposed locally (e.g., as part of a local server, a local computing system, etc.) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, a “circuit” as described herein may include components that are distributed across one or more locations.
An exemplary system for implementing the overall system or portions of the arrangements might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. Each memory device may include non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some arrangements, the non-volatile media may take the form of ROM, flash memory (e.g., flash memory such as NAND, 3D NAND, NOR, 3D NOR, etc.), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other arrangements, the volatile storage media may take the form of RAM, TRAM, ZRAM, etc. Combinations of the above are also included within the scope of machine-readable media. In this regard, machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. Each respective memory device may be operable to maintain or otherwise store information relating to the operations performed by one or more associated circuits, including processor instructions and related data (e.g., database components, object code components, script components, etc.), in accordance with the example arrangements described herein.
It should also be noted that the term “input devices,” as described herein, may include any type of input device including, but not limited to, a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function. Comparatively, the term “output device,” as described herein, may include any type of output device including, but not limited to, a computer monitor, printer, facsimile machine, or other output devices performing a similar function.
Any foregoing references to currency or funds are intended to include fiat currencies, non-fiat currencies (e.g., precious metals), and math-based currencies (often referred to as cryptocurrencies). Examples of math-based currencies include Bitcoin, Litecoin, Dogecoin, and the like.
It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative arrangements. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.
It is also understood that any reference to an element herein using a designation such as “first,” “second,” and so forth does not generally limit the quantity or order of those elements. Rather, these designations can be used herein as a convenient means of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements can be employed, or that the first element must precede the second element in some manner.
The foregoing description of arrangements has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The arrangements were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various arrangements and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the arrangements without departing from the scope of the present disclosure as expressed in the appended claims.
This application is a continuation of U.S. patent application Ser. No. 16/539,726, filed Aug. 13, 2019, entitled “SECURE ELECTRONIC TRANSACTIONS USING TRANSPORT LAYER SECURITY (SETUTLS),” the content of which is incorporated by reference in its entirety and for all purposes.
| Number | Name | Date | Kind |
|---|---|---|---|
| 20080039209 | Chen | Feb 2008 | A1 |
| 20210297400 | Lehtovirta | Sep 2021 | A1 |
| 20220150227 | Selander | May 2022 | A1 |
| Entry |
|---|
| ETS Isn't TLS and You Shouldn't Use It by Jacob Hoffman-Andrews—Feb. 26, 2019 https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-use-it (Year: 2019). |
| Internet Engineering Task Force (IETF) Request for Comments: 8446, The Transport Layer Security (TLS) Protocol Version 1.3 E. Rescorla, Mozilla Aug. 2018 (Year: 2018). |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16539726 | Aug 2019 | US |
| Child | 17558565 | US |
