EP4481609A2 - Cloud-speicher unter verwendung eines verschlüsselungsgateways mit zertifikatautoritätsprüfung - Google Patents

Cloud-speicher unter verwendung eines verschlüsselungsgateways mit zertifikatautoritätsprüfung Download PDF

Info

Publication number
EP4481609A2
EP4481609A2 EP24198745.2A EP24198745A EP4481609A2 EP 4481609 A2 EP4481609 A2 EP 4481609A2 EP 24198745 A EP24198745 A EP 24198745A EP 4481609 A2 EP4481609 A2 EP 4481609A2
Authority
EP
European Patent Office
Prior art keywords
key
client
data
encryption
gateway
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24198745.2A
Other languages
English (en)
French (fr)
Other versions
EP4481609A3 (de
Inventor
Jordan ANDERSON
Richard J. Takahashi
Sean LITTLE
Lee Noehring
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Secturion Systems Inc
Original Assignee
Secturion Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/688,743 external-priority patent/US11283774B2/en
Application filed by Secturion Systems Inc filed Critical Secturion Systems Inc
Publication of EP4481609A2 publication Critical patent/EP4481609A2/de
Publication of EP4481609A3 publication Critical patent/EP4481609A3/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0471—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload applying encryption by an intermediary, e.g. receiving clear information at the intermediary and encrypting the received information at the intermediary before forwarding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing

Definitions

  • At least some embodiments disclosed herein relate to security processing or storage in general.
  • remote cloud and server systems are protected by distributed software based encryption in which each client generates and handles cryptographic keys and encrypts its data before transmission.
  • Distributed encryption local client to remote server adds extensive CPU overhead-computing to clients and allows a very wide attack vector.
  • adversaries can penetrate several clients at one time because each individual client uses a software-based encryption that insecurely stores the keys. The adversary illegally accesses (hacks) the client's machine and copies the cryptographic keys undetected.
  • the user of the client machine and the information technology network personnel are potential threats that can copy the cryptographic keys and sell/give to an adversary.
  • a distributed encryption system with hundreds of clients increases the burden of support network personnel to protect the network from both external and internal attackers or threats.
  • software encryption is susceptible to malicious hacking and covert modifications.
  • One embodiment replaces a distributed encryption solution for data object storage with a centralized encryption solution, which is more reliable, secure, and manageable and in many cases provides much higher performance.
  • a centralized encryption system and centralized key manager is significantly easier to manage and protect than a distributed encryption/key manager system.
  • a payload encryption method uses symmetric encryption algorithms with authentication to encrypt or decrypt a payload file object or data.
  • the gateway encrypts the payload (file object or data) using a specific key associated to the client and/or object.
  • the gateway then encrypts the payload to a remote-side transport encryption protocol and sends the encrypted payload to a remote server or cloud server.
  • a system includes: a first computing device configured as an encryption gateway, the first computing device comprising at least one processor (e.g., for data path and/or cryptographic processing) and at least one memory, the encryption gateway configured to receive data in a payload from a client application (e.g., the client application can be implemented in either hardware or software), to encrypt the data, and to send or write the encrypted data to a remote cloud storage or a data server; a router or switch, configured to provide, via local-side transport, the payload from the client application to the encryption gateway; and a key manager, the key manager configured to provide at least one key to the encryption gateway for encryption of the data in the payload, wherein at least one key is associated to the client application (or the corresponding client) or the payload, and the encryption of the data uses a remote-side transport protocol associated with the remote cloud storage or server.
  • a client application e.g., the client application can be implemented in either hardware or software
  • a router or switch configured to provide, via local-side transport
  • a method includes: receiving, by an encryption gateway from a hardware or software client application, a request to read data from a remote cloud storage or server; receiving the data in a first payload from the remote cloud storage or server, wherein the data has been encrypted using a remote-side transport protocol associated with the remote cloud storage or data server; decrypting, by at least one processor of the encryption gateway, the received data in the first payload using the remote-side transport protocol, wherein the decrypting uses a key of the client application and the key is retrieved from a memory; encrypting, by the encryption gateway, the first payload using a client-side transport protocol; and sending, from the encryption gateway to the client application, the encrypted first payload (for a nonlimiting example, see Figure 1 ).
  • an encryption gateway includes at least one processor; and memory storing instructions configured to instruct at least one processor to: receive, via local-side transport, data in a payload from a client application; receive, from a key manager, at least one key for encryption of the data in the payload, wherein at least one key is associated to the client application or the payload; encrypt the data in the payload, the encryption using a remote-side transport protocol associated with a remote cloud storage or server; and send or write the encrypted data to the remote cloud storage or server.
  • the disclosure includes methods and apparatuses which perform these methods, including data processing systems which perform these methods, and computer readable media containing instructions which when executed on data processing systems cause the systems to perform these methods.
  • the encryption gateway when connecting to the cloud or remote server, uses a trusted third party to verify the identity of the cloud or remote server.
  • a trusted third party may be a certificate authority (CA) (e.g., a computing device of the CA communicates over a network with the encryption gateway).
  • CA certificate authority
  • the TLS processors e.g., the TLS blocks illustrated in Figure 2
  • TLS functions contact the CA (e.g., over the internet or a network connected to the CA) that signed a TLS peer certificate to verify that the certificate is valid. More than one certificate can be used. Once the one or more certificates are verified, the TLS connection to the client and to the cloud is established, and the client session key and cloud session key are generated per the TLS protocols. In the case that the certificate is deemed invalid, the connection is aborted and client or cloud session keys are not generated.
  • the CA cryptographically signs a certificate that establishes the identity of the cloud or remote server.
  • the certificate is sent over the network from the computing device of the CA to the encryption gateway.
  • the encryption gateway verifies this signature and communicates with the CA to ensure that the certificate is valid and has not been compromised.
  • a client(s) to cloud or remote server secure communication system that connects from the clients to the gateway to the cloud and/or any remote servers.
  • the data is double encrypted in transit at 10 Gigabits to 100 Gigabits/second or higher data rates.
  • HTTPS is equivalent to HTTP over TLS or SSL (or another equivalent security).
  • Figures 1-4 show example embodiments of the communication system.
  • Figure 1 illustrates an example of the communication system in situ.
  • Figure 2 illustrates an embodiment of the system with TLS transport security on both local and remote sides of the system.
  • Figure 3 illustrates an embodiment of the system with TLS transport security on local side and MACSEC transport security on the remote side of the system.
  • Figure 4 illustrates an embodiment of the system with MACSEC transport security on both local and remote sides of the system.
  • MACSEC security is used.
  • MACSEC is described by the IEEE 802.1AE-2006 standard (currently with 3 amendments, IEEE 802.1AEbn-2011, IEEE 802.1AEbw-2013, IEEE 802.1AEcg-2017).
  • the MAC security standard also known as "MACsec" defines connectionless data confidentiality and integrity for media access independent protocols over an OSI layer two network.
  • the MACsec Key Agreement (“MKA”) protocol is responsible for maintaining MACsec connections by generating and providing cryptographic keys to be used for each MACSEC connection.
  • MKA MACsec Key Agreement
  • the optional addition of MACSEC adds another layer of transport encryption for cloud-based encryption to completely hide all information being transmitted.
  • MACSEC can be used to provide transport encryption instead of TLS.
  • a local client sends or writes data to the cloud or remote server flow.
  • the client uses any transport encryption method on the file object or data to the gateway.
  • the gateway decrypts the local-side transport to yield the plain text file object or data.
  • the gateway encrypts the payload (file object or data) using a specific key associated to the client and/or object.
  • the gateway then encrypts the payload to the remote-side transport encryption protocol and sends to the remote server or cloud server.
  • the remote server or cloud server decrypts the transport protocol. At this time, the payload is still encrypted by the client's key.
  • the encrypted payload data is then stored.
  • the aggregated gateway terminates local side communication (e.g., MACSEC, IPSEC, TLS), performs encryption as required on the TCP stream of data (e.g., encrypt a file object in a file transfer stream), and then performs new independent transport encryption (e.g., TCP and TLS sessions) on the remote side.
  • local side communication e.g., MACSEC, IPSEC, TLS
  • encryption as required on the TCP stream of data (e.g., encrypt a file object in a file transfer stream)
  • new independent transport encryption e.g., TCP and TLS sessions
  • data is read or the local client receives data from the cloud or remote server.
  • the client requests that the remote server or cloud server reads the encrypted stored data.
  • the remote server or cloud server encrypts the data using remote-side transport protocol.
  • the gateway receives the data and decrypts the remote-side transport protocol. Next, using the client's key, the gateway decrypts the payload file object or data and then encrypts the file object or data using the client-side transport protocol.
  • the client receives the transport data and decrypts.
  • the aggregated gateway terminates remote side communication (e.g., TCP and TLS sessions), performs decryption as required on the TCP stream of data (e.g., encrypt a file object in a file transfer stream), and then performs new independent transport encryption (e.g., MACSEC, IPSEC, TLS) on the local side.
  • remote side communication e.g., TCP and TLS sessions
  • decryption as required on the TCP stream of data
  • IPSEC e.g., IPSEC, TLS
  • the transport encryption method is used to protect the data during transmission between physical sites or buildings (i.e., point-to-point encryption).
  • the transport encryption method can be, for example, an industry standard such as, for example, TLS (Transport Security Layer), IPSec (Internet Protocol Security), MACSEC (IEEE MAC Security standard), or any custom transport protocol.
  • TLS, MACSEC, and IPSec each have authentication information that will be used to associate the client's payload keys.
  • a Transport Layer Security (TLS) or equivalent network or transport security protocol may communicate to a third party certificate authority (CA) for certificate(s) set-ups and to verify the identity of the cloud or remote server or users.
  • CA certificate authority
  • the payload encryption method uses symmetric encryption algorithms with authentication (e.g., AES-GCM) to encrypt or decrypt the payload file object or data.
  • AES-GCM symmetric encryption algorithms with authentication
  • other encryption algorithms can be used, such as an asymmetric algorithm.
  • Payload encryption protects the file or object data while it is stored in cloud storage or at the cloud or remote server. Adding authentication ensures that the data has not been manipulated in any way while it has been stored.
  • the payload encryption provides additional security above and beyond the transport encryption while the data is in transport. Encryption while the data is stored ensures that only the client can access the data. Other entities, such as the storage provider, cannot access, for example, the plaintext data because they do not have keys for that data.
  • the symmetric encryption algorithm with authentication is required to associate the proper client's payload key to the file object or data.
  • the payload key manager facilitates the loading of client payload keys into the gateway.
  • the client keys can be either loaded via a secure port or over the network using a secure method. Once the keys are loaded into the gateway, the keys are pre-associated to the clients that are connected to the gateway. The client's key is associated to the client based on the information provided by the transport encryption method. Once the client keys are loaded into the gateway, the client's keys cannot be read or exposed.
  • the payload key manager (e.g., illustrated in Figure 2 ) communicates with a payload encryption protocol to determine who the client is and what client payload key to associate with the file object or data for payload encryption or decryption.
  • a payload encryption protocol to determine who the client is and what client payload key to associate with the file object or data for payload encryption or decryption.
  • One of the features is the ability to encrypt the payload data at the file object level and associate the client's payload key to the file object.
  • a first computing device is configured as an encryption gateway, and the first computing device comprises at least one processor (e.g., for data path and/or cryptographic processing) and at least one memory.
  • the encryption gateway is configured to authenticate a client using one or multiple authentication factors, and further configured to receive TLS (or other transport encryption) data from a client application.
  • the encryption gateway will terminate the client TLS connection and extract the payload and encrypt the payload with authentication.
  • Authentication is used in addition to the encryption algorithm to authenticate the data.
  • the authentication process verifies the data originated from the intended source.
  • AES-GCM is an encryption algorithm that includes authentication performed prior to and after an encryption process. This authentication verifies the data that was encrypted or decrypted did originate to/from an authorized source or user.
  • the payload is encrypted using the object/file key (e.g., see "File object derived key” in Figure 6 ). This encryption protects the data while it is stored.
  • the payload is also authenticated so that when the object/file is read from the data store, the gateway can determine if the data was modified in any way including, for example, being tampered with.
  • the encryption gateway inserts the encrypted-authenticated payload into the cloud or data server TLS data packet/format.
  • the encryption gateway establishes a cloud or data server TLS connection.
  • the cloud or data server terminates the TLS connection, which includes TCP termination, and stores the encrypted-authenticated payload in the cloud or data server memory.
  • an approach terminates a client TLS connection which also includes TCP termination, extracts data from a payload and encrypts the extracted data with authentication (using an encryption key from a key manager).
  • a TLS connection is set-up to a cloud or data server, and the encrypted authenticated data is inserted into a TLS cloud payload with key association information.
  • the cloud or data server terminates the TLS connection and the encrypted authenticated payload data is stored on the cloud or data server memory/storage.
  • TLS algorithm can be implemented using a systolic matrix architecture as referred to below.
  • TLS background (used in this example) and other transport encryption methods are, for example, IPSEC, MACSEC, or a custom method.
  • transport and packet processing can be implemented using a systolic matrix architecture as referred to below.
  • Transport Layer Security or Secure Socket Layer (SSL) is used to secure data in flight at Layer 6 of the OSI model. It provides both certificate authentication and transport encryption for all application layer data. Certificate authentication is achieved by verifying the CA's cryptographic signature covering the certificate, and/or contacting the CA to ensure that the certificate in question is currently valid. In the context of remote cloud storage, TLS gives the client confidence that its data is only connected to the cloud service provider.
  • TLS operates by negotiating a session key per TLS or Secure Socket Layer (SSL) connection.
  • SSL Secure Socket Layer
  • the hardware encryption gateway acts as a TLS proxy between client applications and cloud storage as shown in Figure 5 .
  • Figure 6 shows a flow chart describing the process of decrypting and re-encrypting the TLS connections.
  • the encryption gateway negotiates a TLS connection to the client and a TLS connection to the cloud server.
  • part of this negotiation includes exchange of signed certificates.
  • the gateway provides a certificate to the client, verifying the gateway's identity (but the client does not need to prove its identity to the gateway or the remote server). So, a certificate is not necessarily received by the gateway from the client.
  • the TLS exchange may start by or include the gateway receiving a certificate from the client.
  • TLS exchanges can implement (and TLS allows for) clients to provide the gateway with a certificate.
  • the TLS endpoint contacts the CA to verify that the received certificate is valid.
  • the negotiation is aborted. If the CA indicates the certificate is valid, the TLS protocol will establish the session key and encrypt the data with the session key and transmit the encrypted data to the client and/or cloud server, thus establishing a secure connection.
  • the HTTP data of Figure 6 contains a file header, which contains information that is used to create the payload encryption key, which is derived using a key encryption key (KEK).
  • KEK key encryption key
  • the "Derived key” shown in Figure 6 is the payload encryption key.
  • the file header information stays with the file/object while it is stored and will be available when the file/object is read. When the file/object is read, the file header information is then used to derive the same key (using the KEK) to decrypt the data.
  • the file header information is prepended to the file/object. It is not encrypted and provides information which allows the gateway to derive the payload encryption key.
  • the file object will be encrypted using a key derived from the file object metadata (e.g., an Object ID).
  • the HTTP stream will be TLS encrypted for transport to the cloud server using the cloud session key.
  • the proxy Hardware Encryption Gateway
  • the cloud server provides the gateway with a signed certificate.
  • the gateway must present a separate certificate, optionally signed by a different signing authority.
  • the proxy cloud certificate is signed by a CA that is trusted by the client so that the client trusts the proxy certificate that is present in place of the original cloud server certificate.
  • CA Compute resource
  • the clients would need to accept the proxy certificate as a security exception.
  • the cost of Hardware Encryption Gateway using TLS for both the client and the cloud server is that the number of TLS negotiations required has doubled compared to not using a proxy. This can reduce throughput performance for clients due to added TLS negotiation time, especially for small-sized files. This also puts a heavy burden on the proxy (Hardware Encryption Gateway) because it must deal with the aggregate client TLS sessions.
  • TLS proxy Hardware Encryption Gateway
  • One way of doing this is to modify the client connection to use an unencrypted HTTP connection. Because all client-to-proxy connections are contained within the customer site, this is a low risk change to the internal network security as shown in Figure 7 .
  • Hardware Encryption Gateway would act as a client-only TLS proxy. Hardware Encryption Gateway will modify the client HTTP packets to the HTTPS. This will reduce the number of TLS negotiations in half from the full HTTPS option, and will remove a level of decryption in client-to-proxy traffic and a level of encryption in the proxy-to-client traffic, relieving both client and proxy of that computational burden. Note that this solution may require a change to the client side software.
  • Option 3 outlines potential performance optimizations that could reduce the number of TLS negotiations that are needed between cloud server and proxy from the direct-connect HTTPS network used in both Options 1 and 2.
  • the TLS proxy Hard Encryption Gateway
  • Hardware Encryption Gateway would set up TLS sessions with a cloud server before clients initiate any data transfer. As clients move data to/from the cloud servers, Hardware Encryption Gateway would use a pre-opened TLS session for the client, modifying the client IP address and port number to that of the active TLS session.
  • Hardware Encryption Gateway would insert a TLS header, modify the server TCP port number to HTTPS, and perform all the necessary TLS encryption and authentication.
  • Hardware Encryption Gateway would reverse the process described above. In one embodiment, there is a need to determine the duration the TLS sessions can be kept alive before the link would need to be renegotiated, as well as on potential impact on the cloud Load Balancers.
  • This option can be used in combination with either Option 1 or Option 2. In either case, it would reduce the number of proxy-to-server TLS sessions required especially in the case of many short-lived client connections. This option also disassociates the lag of proxy-to-server connections from the client-to-proxy connections so that the client does not see additional latency in individual client connections.
  • a general hardware aggregated encryption gateway (as discussed above) enables centralized encryption of communications leaving a corporate or other site.
  • the above Hardware Encryption Gateway can negotiate hundreds of TLS connections per second and maintain thousands of TCP connections simultaneously.
  • the Hardware Encryption Gateway is programmable for real-time HTTP 100 Gbps full duplex TLS and data at rest encryption that is transparent to clients and the cloud.
  • the encryption gateway may be implemented by or use encryption/decryption and/or communication methods and systems as described in U.S. Patent Application Serial No. 14/177,392, filed February 11, 2014, entitled “SECURITY DEVICE WITH PROGRAMMABLE SYSTOLIC-MATRIX CRYPTOGRAPHIC MODULE AND PROGRAMMABLE INPUT/OUTPUT INTERFACE,” by Richard J. Takahashi, and/or as described in U.S. Patent Application Serial No. 14/219,651, filed March 19, 2014, entitled “SECURE END-TO-END COMMUNICATION SYSTEM,” by Richard J. Takahashi .
  • the encryption gateway may use systolic matrix packet engines and multiplexers to process and route packets or other data, as described in the foregoing applications.
  • data transmitted from a client to a remote cloud storage or server for storage is encrypted using three different keys, described in more detail as follows.
  • the first key (key-1) is set-up with, for example, TLS encryption from the client application to the encryption gateway.
  • the second key is the payload encryption key (key-2) used to encrypt the payload data (e.g., a file, or one or more file objects).
  • the third key (key-3) is used for the TLS encryption from the encryption gateway to the remote cloud storage or server.
  • key-1 is used to decrypt data from the client that is received at the gateway
  • key-3 is used to encrypt data that is sent to the cloud.
  • key-1 is used as the TLS client session key. Data is only protected by key-1 for the duration of the transport between the client and the gateway. Key-3 is used similarly for the duration of the transport between the gateway and the remote cloud storage or server.
  • data is encrypted by the encryption gateway at a file or file object level, and at least one key is associated to a file object.
  • an executable file include a complete program that can be run directly by an operating system (e.g., in conjunction with shared libraries and system calls).
  • the file generally contains a table of contents, a number of code blocks and data blocks, ancillary data such as the memory addresses at which different blocks should be loaded, which shared libraries are needed, the entry point address, and sometimes a symbol table for debugging.
  • An operating system can run an executable file by loading blocks of code and data into memory at the indicated addresses and jumping to it.
  • Examples of a file object include code that is logically divided into multiple source files. Each source file is compiled independently into a corresponding object file of partially-formed machine code known as object code. At a later time these object files are linked together to form an executable file.
  • Object files have several features in common with executable files (table of contents, blocks of machine instructions and data, and debugging information). However, the code is not ready to run. For example, it has incomplete references to subroutines outside itself, and as such, many of the machine instructions have only placeholder addresses.
  • the encryption gateway sets up a transport session with the remote cloud storage or server prior to receiving the payload from the client (e.g., from an application executing on the client), and the encryption gateway uses the transport session for sending or writing data from a plurality of client applications, including the client application, to the remote cloud storage or server.
  • the encryption gateway modifies or inserts a header in a transport connection to associate the client application on a remote connection, or the encryption gateway modifies or inserts a header in a file object to associate the client application on a remote connection.
  • the client application can be software that transfers the file or file object to the gateway.
  • the header is an HTTP packet header that contains the information related to the packet, where the gateway can modify or insert information without disturbing or disrupting the original function of the HTTP packet.
  • the data received from the client comprises a payload having a plurality of file objects, and the payload key is associated to each of the file objects.
  • the payload key can be derived using metadata or file header information, as was described above.
  • the metadata or file header contains information that is used to derive the payload cipher key with a KEK.
  • the metadata or file header is maintained with the file/object for the life of the file/object so that it can be used at any time to derive the payload cipher key to decrypt the file/object (e.g., when it is read from remote cloud storage).
  • the data received from the client comprises packets including a first packet, and a header is inserted into one or more of the packets (e.g., the first packet), wherein the header associates each packet to the client.
  • the file object may be split among multiple packets.
  • identifying information is stored that is used to extract the correct key for decryption when the file is later read (this provides key association with the data). This identifying information can be in the form of an additional header prepended to the file, or by modifying existing metadata.
  • the inserted file header is a new header. If metadata is modified, new metadata is inserted in an existing header. In this embodiment, there is no association between the file header or metadata with the remote connection.
  • the contents of the header/metadata of the first packet of the file creates a context that associates subsequent packets with the first packet.
  • the payload key is associated to the client or an object in the data received from the client.
  • the payload key association is made through an identifying feature of the cloud server protocol associated with the cloud or remote server.
  • AWS Amazon Web Services
  • a specific "bucket" e.g., like a folder
  • the key to use is identified based on that information and uses that association.
  • the gateway receives authentication information from the client to request the local side TLS key using the TLS protocol.
  • the gateway communicates with the remote-side transport protocol to determine the remote side TLS key for use in encryption.
  • the TLS protocol is used to determine the key.
  • the client session key is an ephemeral key generated after receiving, by the gateway, a request from the client to establish a connection.
  • the cloud session key is an ephemeral key generated after receiving a request from the gateway to the cloud server to establish a connection. Both the client session and cloud session keys are generated in response to a request to the gateway for connection from the client.
  • the gateway modifies or inserts a header in at least one of a plurality of packets received from the client to associate the client to a file object (e.g., the header is only inserted in a first packet of a multi-packet file/object).
  • At least some aspects disclosed can be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system or other data processing system in response to its processor(s), such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device.
  • processor(s) such as a microprocessor
  • a memory such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device.
  • hardwired circuitry e.g., one or more hardware processors or other computing devices
  • software instructions e.g., the communication system may be implemented using one or more computing devices.
  • the techniques are neither limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system.
  • a computing device may be used that comprises an inter-connect (e.g., bus and system core logic), which interconnects a microprocessor(s) and a memory.
  • the microprocessor is coupled to cache memory in one example.
  • the inter-connect interconnects the microprocessor(s) and the memory together and also interconnects them to a display controller and display device and to peripheral devices such as input/output (I/O) devices through an input/output controller(s).
  • I/O devices include mice, keyboards, modems, network interfaces, printers, scanners, video cameras and other devices which are well known in the art.
  • the inter-connect may include one or more buses connected to one another through various bridges, controllers and/or adapters.
  • the I/O controller includes a USB (Universal Serial Bus) adapter for controlling USB peripherals, and/or an IEEE-1394 bus adapter for controlling IEEE-1394 peripherals.
  • USB Universal Serial Bus
  • IEEE-1394 IEEE-1394
  • the memory may include ROM (Read Only Memory), and volatile RAM (Random Access Memory) and non-volatile memory, such as hard drive, flash memory, etc.
  • ROM Read Only Memory
  • RAM Random Access Memory
  • non-volatile memory such as hard drive, flash memory, etc.
  • Volatile RAM is typically implemented as dynamic RAM (DRAM) which requires power continually in order to refresh or maintain the data in the memory.
  • Non-volatile memory is typically a magnetic hard drive, a magnetic optical drive, or an optical drive (e.g., a DVD RAM), or other type of memory system which maintains data even after power is removed from the system.
  • the non-volatile memory may also be a random access memory.
  • the non-volatile memory can be a local device coupled directly to the rest of the components in the data processing system.
  • a non-volatile memory that is remote from the system such as a network storage device coupled to the data processing system through a network interface such as a modem or Ethernet interface, can also be used.
  • a data processing system such as the computing device above is used to implement one or more of the following: an encryption gateway, a router, a switch, a key manager, a client application, cloud storage, a load balancer, and a firewall.
  • a data processing system such as the computing device above is used to implement a user terminal, which may provide a user interface for control of a computing device.
  • a user interface may permit configuration of the encryption gateway.
  • a user terminal may be in the form of a personal digital assistant (PDA), a cellular phone or other mobile device, a notebook computer or a personal desktop computer.
  • PDA personal digital assistant
  • one or more servers of the data processing system can be replaced with the service of a peer to peer network of a plurality of data processing systems, or a network of distributed computing systems.
  • the peer to peer network, or a distributed computing system can be collectively viewed as a server data processing system.
  • Embodiments of the disclosure can be implemented via the microprocessor(s) and/or the memory above.
  • the functionalities described can be partially implemented via hardware logic in the microprocessor(s) and partially using the instructions stored in the memory.
  • Some embodiments are implemented using the microprocessor(s) without additional instructions stored in the memory.
  • Some embodiments are implemented using the instructions stored in the memory for execution by one or more general purpose microprocessor(s).
  • the disclosure is not limited to a specific configuration of hardware and/or software.
  • various functions and operations may be described as being performed by or caused by software code to simplify description. However, those skilled in the art will recognize what is meant by such expressions is that the functions result from execution of the code by a processor, such as a microprocessor.
  • the functions and operations can be implemented using special purpose circuitry, with or without software instructions, such as using an Application-Specific Integrated Circuit (ASIC) or a Field-Programmable Gate Array (FPGA).
  • ASIC Application-Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • Embodiments can be implemented using hardwired circuitry without software instructions, or in combination with software instructions. Thus, the techniques are limited neither to any specific combination of hardware circuitry and software, nor to any particular source for the instructions executed by the data processing system.
  • At least some aspects disclosed can be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device.
  • processor such as a microprocessor
  • a memory such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device.
  • Hardware and/or software may be used to implement the embodiments above.
  • the software may be a sequence of instructions referred to as "computer programs.”
  • the computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects.
  • Software used in an embodiment may be stored in a machine readable medium.
  • the executable software when executed by a data processing system, causes the system to perform various methods.
  • the executable software and data may be stored in various places including for example ROM, volatile RAM, non-volatile memory and/or cache. Portions of this software and/or data may be stored in any one of these storage devices.
  • the data and instructions can be obtained from centralized servers or peer to peer networks. Different portions of the data and instructions can be obtained from different centralized servers and/or peer to peer networks at different times and in different communication sessions or in a same communication session.
  • the data and instructions can be obtained in entirety prior to the execution of the applications. Alternatively, portions of the data and instructions can be obtained dynamically, just in time, when needed for execution. Thus, it is not required that the data and instructions be on a machine readable medium in entirety at a particular instance of time.
  • Examples of computer-readable media include but are not limited to recordable and non-recordable type media such as volatile and non-volatile memory devices, read only memory (ROM), random access memory (RAM), flash memory devices, floppy and other removable disks, magnetic disk storage media, optical storage media (e.g., Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks (DVDs), etc.), among others.
  • the computer-readable media may store the instructions.
  • a tangible machine readable medium includes any mechanism that provides (e.g., stores) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.).
  • a machine e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)
EP24198745.2A 2017-06-12 2018-05-30 Cloud-speicher mit verschlüsselungsgateway mit zertifikatautoritätsidentifizierung Pending EP4481609A3 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201762518117P 2017-06-12 2017-06-12
US15/688,743 US11283774B2 (en) 2015-09-17 2017-08-28 Cloud storage using encryption gateway with certificate authority identification
PCT/US2018/035052 WO2018231519A1 (en) 2017-06-12 2018-05-30 Cloud storage using encryption gateway with certificate authority identification
EP18816604.5A EP3613195B1 (de) 2017-06-12 2018-05-30 Cloud-speicher unter verwendung eines verschlüsselungsgateways mit zertifikatautoritätsprüfung

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
EP18816604.5A Division EP3613195B1 (de) 2017-06-12 2018-05-30 Cloud-speicher unter verwendung eines verschlüsselungsgateways mit zertifikatautoritätsprüfung

Publications (2)

Publication Number Publication Date
EP4481609A2 true EP4481609A2 (de) 2024-12-25
EP4481609A3 EP4481609A3 (de) 2025-03-26

Family

ID=64659403

Family Applications (2)

Application Number Title Priority Date Filing Date
EP24198745.2A Pending EP4481609A3 (de) 2017-06-12 2018-05-30 Cloud-speicher mit verschlüsselungsgateway mit zertifikatautoritätsidentifizierung
EP18816604.5A Active EP3613195B1 (de) 2017-06-12 2018-05-30 Cloud-speicher unter verwendung eines verschlüsselungsgateways mit zertifikatautoritätsprüfung

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP18816604.5A Active EP3613195B1 (de) 2017-06-12 2018-05-30 Cloud-speicher unter verwendung eines verschlüsselungsgateways mit zertifikatautoritätsprüfung

Country Status (3)

Country Link
EP (2) EP4481609A3 (de)
CA (1) CA3066728A1 (de)
WO (1) WO2018231519A1 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9317718B1 (en) 2013-03-29 2016-04-19 Secturion Systems, Inc. Security device with programmable systolic-matrix cryptographic module and programmable input/output interface
US9355279B1 (en) 2013-03-29 2016-05-31 Secturion Systems, Inc. Multi-tenancy architecture
US9374344B1 (en) 2013-03-29 2016-06-21 Secturion Systems, Inc. Secure end-to-end communication system
US9524399B1 (en) 2013-04-01 2016-12-20 Secturion Systems, Inc. Multi-level independent security architecture
US11283774B2 (en) 2015-09-17 2022-03-22 Secturion Systems, Inc. Cloud storage using encryption gateway with certificate authority identification
US10708236B2 (en) 2015-10-26 2020-07-07 Secturion Systems, Inc. Multi-independent level secure (MILS) storage encryption
EP4052414B1 (de) * 2019-12-06 2024-02-07 Samsung Electronics Co., Ltd. Verfahren und elektronische vorrichtung zur verwaltung von digitalen schlüsseln
CN116483252A (zh) * 2022-01-14 2023-07-25 华为云计算技术有限公司 云存储设备的数据读取和写入方法及系统
US12561075B2 (en) 2024-07-01 2026-02-24 T-Mobile Usa, Inc. Secure storing and retrieval of sensitive data from a server system
US12563020B2 (en) 2024-07-01 2026-02-24 T-Mobile Usa, Inc. Secure collection of sensitive data on computer devices

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8595814B2 (en) * 2005-12-13 2013-11-26 Google Inc. TLS encryption in a managed e-mail service environment
US8356177B2 (en) * 2008-12-30 2013-01-15 Cisco Technology, Inc. Key transport in authentication or cryptography
US9380048B2 (en) * 2012-10-15 2016-06-28 Saife, Inc. Certificate authority server protection
GB2509709A (en) * 2013-01-09 2014-07-16 Ibm Transparent encryption/decryption gateway for cloud storage services
US9280678B2 (en) * 2013-12-02 2016-03-08 Fortinet, Inc. Secure cloud storage distribution and aggregation
US9794064B2 (en) * 2015-09-17 2017-10-17 Secturion Systems, Inc. Client(s) to cloud or remote server secure data or file object encryption gateway
US9871662B2 (en) * 2015-09-25 2018-01-16 Netflix, Inc. Systems and methods for digital certificate and encryption key management

Also Published As

Publication number Publication date
CA3066728A1 (en) 2018-12-20
EP4481609A3 (de) 2025-03-26
WO2018231519A1 (en) 2018-12-20
EP3613195A1 (de) 2020-02-26
EP3613195A4 (de) 2020-04-15
EP3613195B1 (de) 2024-09-18

Similar Documents

Publication Publication Date Title
US11792169B2 (en) Cloud storage using encryption gateway with certificate authority identification
AU2021201714B2 (en) Client(s) to cloud or remote server secure data or file object encryption gateway
EP3613195B1 (de) Cloud-speicher unter verwendung eines verschlüsselungsgateways mit zertifikatautoritätsprüfung
CN110870277B (zh) 将中间盒引入到客户端与服务器之间的安全通信中
US8438628B2 (en) Method and apparatus for split-terminating a secure network connection, with client authentication
US8788805B2 (en) Application-level service access to encrypted data streams
CN114788225B (zh) 用于进行互联网密钥交换重认证优化的方法和系统
CN114008976B (zh) 用于双壳加密的混合密钥交换
CN102349264A (zh) 卸载密码保护处理
US9961055B1 (en) Inaccessibility of data to server involved in secure communication
US10218682B1 (en) Secure network protocol cryptographic processing
WO2009018510A1 (en) Systems and methods for implementing a mutating internet protocol security
CN105591748B (zh) 一种认证方法和装置
CN116260580A (zh) 基于量子密钥的IPSec VPN连接方法及系统
CA2997125C (en) Client(s) to cloud or remote server secure data or file object encryption gateway
US20080059788A1 (en) Secure electronic communications pathway
Cornett et al. NETWORK SECURITY: CHALLENGES AND SOLUTIONS.
CN115941228A (zh) 处理报文、获取sa信息的方法、装置、系统及介质
de Moura MULTITLS: Secure communication channel with diversity
Manangi et al. Analysis of Security Features in 5 Layer Internet Model
Chakkour Secure Socket Layer (SSL)/TLS in Transport Layer Security

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AC Divisional application: reference to earlier application

Ref document number: 3613195

Country of ref document: EP

Kind code of ref document: P

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 67/1097 20220101ALI20250217BHEP

Ipc: H04L 67/02 20220101ALI20250217BHEP

Ipc: G06F 21/60 20130101ALI20250217BHEP

Ipc: H04L 9/40 20220101ALI20250217BHEP

Ipc: G06F 21/62 20130101AFI20250217BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250926

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20260330