ABSTRACT
Abstract
Methods are described for a data creator to securely send a data payload to another device in a transient symmetric key technology (TSKT) system, and for the other device to securely receive the payload data. One method includes receiving a first seed and a formula from a command and control server. A second seed is generated, and the first seed and the second seed are combined using the formula to create a data seed. A first key is generated using the first seed, and the second seed is encrypted using the first key to form an encrypted second seed. A second key is generated using the data seed, and the data payload is encrypted using the second key to form an encrypted data payload. The encrypted data payload and the encrypted second seed are combined in a secure container, and subsequently all keys and seeds and the formula are destroyed.
Description
FIELD
This disclosure relates generally to data security, and more specifically to methods and systems for exchanging and maintaining data with high levels of security.
BACKGROUND
Recently, reports of data breaches and compromises, thefts, or âhacksâ of sensitive user information have become commonplace. Most of the vulnerabilities arise from exchange of user data over public networks, granting remote access to users whose security credentials or passwords can be guessed or automatically emulated, and storage and retrieval of data on systems that can be compromised. The industry has developed methods and algorithms for storing and transmitting data in encrypted format, such as the Advanced Encryption Standard (AES), which defines different block and key sizes and that provide higher levels of complexity for larger block and key sizes. A common AES standard, known as âAES-128â, can theoretically be discovered or hacked, although with a great amount of difficulty. While AES standards with higher computational complexity have been developed, many systems use legacy AES-128 encryption or even simpler encryption and are still vulnerable to attack.
A typical system using a public key encryption (PKI) algorithm uses public key/private key encryption, in which the public key is generally available and used to encrypt data, but the private key is kept confidential and can decrypt the data. Because the private key is stored on one or more devices, if the computer itself is breached or hacked and the private key is discovered, the computational complexity of deciphering PKI-encrypted data can be bypassed, and sensitive user data can be exposed.
In the PKI system, an entity known as a certificate authority (CA) has the ability to issue private keys to allow trusted users to gain access to data. However, the CAs themselves have been breached, hacked, or stolen from, leading to counterfeit certificates being issued and user's data being stolen.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates a flow diagram that may be used by a data creator according to the embodiments herein;
FIG. 2 shows a flow diagram that would be used by a data accessor according to the embodiments herein;
FIG. 3 illustrates a block diagram of a transient symmetric key technology (TSKT) system that can implement the TSKT flows of FIGS. 1 and 2 according to various embodiments described herein;
FIG. 4 illustrates a block diagram of the TSKT system of FIG. 3 when the data creator requests the creation of a secure container;
FIG. 5 illustrates a block diagram of the TSKT system of FIG. 3 showing the actions of the CCS in response to the request for the creation of the secure container.
FIG. 6 illustrates a block diagram of the TSKT system of FIG. 3 showing the creation of the secure container;
FIG. 7 illustrates a block diagram of the TSKT system of FIG. 3 showing of the retrieval of the secure container by an authorized data accessor;
FIG. 8 illustrates a block diagram of the TSKT system of FIG. 3 showing a request by the authorized data accessor to decrypt the secure container; and
FIG. 9 illustrates a block diagram of the TSKT system of FIG. 3 when the CCS responds to the request for the retrieval of the secure container by the authorized data accessor; and
FIG. 10 illustrates a block diagram of the TSKT system of FIG. 3 when the data accessor decrypts the secure container.
In the following description, the use of the same reference numerals in different drawings indicates similar or identical items. Unless otherwise noted, the word âcoupledâ and its associated verb forms include both direct connection and indirect electrical connection by means known in the art, and unless otherwise noted any description of direct connection implies alternate embodiments using suitable forms of indirect electrical connection as well.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
Encryption and/or decryption according to the techniques described herein vastly improve known public key/private key systems by making encryption and decryption keys transitory on the user's system, such that they are only in existence for a period of time too short to expose the keys with any significant risk of hacking. The system is symmetric in that the same process is used for both encrypting and decrypting. The system defines a secure âcontainerâ for data that practically cannot be hacked.
In general, the inventors have created a transient, symmetric key method that allows for keys to be generated on demand and be present only for short periods of time while needed for encryption and decryption. The approach utilizes a distributed, zero-trust, end-to-end encryption architecture which leverages a new transient symmetric key technology (TSKT). After the keys are no longer needed, they are digitally destroyed by overwriting the values.
There will normally be three unique participants in the enhanced key management process: a data creator, a data accessor, and a command and control server. The data creator creates and encrypts the data. The data accessor has access rights to the encrypted data. The command and control server authenticates, validates and authorizes all creators' and accessors' rights to encrypted data.
Moreover, there are two types of keys that can be used to encrypt data: asymmetric and symmetric. Asymmetric cryptography, also known as Public-Key Infrastructure (PKI), uses a pair of keys (public and private) to encrypt and decrypt data. Traditionally, a network user receives a public and private key pair from a certificate authority. Any other user who wants to send an encrypted message can get the intended recipient's public key directly from the recipient or from a public directory. They use this key to encrypt the data, and they send it to the recipient. When the recipient gets the message, they decrypt it with their private key, which no one else should have access to.
However, this is not the case for the distributed, zero-trust, end-to-end encryption architecture described herein. In the architecture described herein, certificate authorities are unnecessary. Furthermore, the TSKT eliminates the need for a server to use, store, and manage public/private keys for users. The client machines generate their own public/private keys locally as needed. The public key is sent to the server by the local client when making a request to create a secure container or access an existing secure container. That public key is not stored on the server.
Known symmetric cryptography utilizes only one key to encrypt and decrypt data. While symmetric-key systems are generally more simple and faster, their main drawback is that the two parties attempting to communicate must somehow exchange the key in a secure way. This is where the TSKT comes into play, and the TSKT steps are described below. A TKST system according to some embodiments will now be described with a concrete example.
Exemplary Tskt Flows
FIG. 1 shows a flow diagram 100 that may be used by a data creator according to the embodiments herein. In the example shown in FIG. 1 , the dashed lines indicate the flow of data over a link using a TLS based protocol. The solid lines represent a processing step that takes place inside a particular node. The black keys are keys encoded using AES. The gray keys are keys encoded using RSA or ECC. In other embodiments, other link protocols and key encryption and decryption standards can be used as well. Using the TKST method, the data creator/protector performs the following steps:
Data Creator/Protector
1. Creator ( e.g. Client 1 in FIG. 1 ) has credentials, and generates public and private keys (RSA or ECC);
2. Creator requests permission from a Command & Control Server (CCS) (hereinafter âServerâ) to create a secure container;
3. Server authenticates and validates the request;
4. Server generates Seed A via a Pseudo Random Number Generator (PRNG), and Server generates a randomly unique formula;
5. Server encrypts copy of Seed A and the formula with creator's public key, e.g., an ECC 521 public key;
6. Server encrypts and stores Seed A and the formula;
7. Server passes encrypted Seed A and the formula to client via SSL or, as shown in FIG. 1 , TLS;
8. Creator decrypts Seed A and the formula using private key;
9. Creator generates Seed B on local device via a PRNG;
10. Creator uses the formula to combine Seed A and B to create Seed C, also known as the Data Seed;
11. Creator generates the payload;
12. Creator uses Seed A to generate AES Key 1 ;
13. Data Seed (C) is used to generate AES Key 2 ;
14. Creator uses AES Key 2 to encrypt payload;
15. Creator uses AES Key 1 to encrypt Seed B;
16. AES keys and seeds are destroyed by Creator;
17. Creator combines payload, encrypted Seed B and other data into one container;
18. Creator finishes registering the new secure container with the CCS; and
19. Container is ready for transport or storage, e.g. a cloud storage server.
As shown in FIG. 1 , in flow 100 at process node 110 a data creator, also referred to as Client 1 , desires to protect sensitive data and to create a secure container for it so it can be accessed by others that Client 1 desires to grant access to. Client 1 has credentials and generates public and private keys using, in the example shown in FIG. 1 , ECC/521 cryptography. Alternatively, the public and private keys can be creased using RSA. Client 1 sends its public key to the Command and Control Server (CCS). Subsequently when Client 1 wishes to create a secure container, Client 1 establishes a secure session with the CCS and creates symmetric AES session keys using Client 1 's public key before requesting permission to create a secure container. Communication between Client 1 and the CCS uses a secure process such as TLS/2048 over an internet connection to authenticate the user, validate the request, and generate Seed A. At process node 120 , the CCS generates an encrypted Seed A that was encrypted with, e.g., the AES session key generated using the data creator's ECC 521 public key, and sends encrypted Seed A to Client 1 as shown at process node 122 .
At process node 130 , Client 1 receives Seed A and decrypts it using the AES session key. At process node 132 , Client 1 uses the AES Key 1 to encrypt Seed B. At process node 140 , Client 1 generates Seed B using a PRNG. At process node 142 , Client 1 uses Seeds
FIELD
This disclosure relates generally to data security, and more specifically to methods and systems for exchanging and maintaining data with high levels of security.
BACKGROUND
Recently, reports of data breaches and compromises, thefts, or âhacksâ of sensitive user information have become commonplace. Most of the vulnerabilities arise from exchange of user data over public networks, granting remote access to users whose security credentials or passwords can be guessed or automatically emulated, and storage and retrieval of data on systems that can be compromised. The industry has developed methods and algorithms for storing and transmitting data in encrypted format, such as the Advanced Encryption Standard (AES), which defines different block and key sizes and that provide higher levels of complexity for larger block and key sizes. A common AES standard, known as âAES-128â, can theoretically be discovered or hacked, although with a great amount of difficulty. While AES standards with higher computational complexity have been developed, many systems use legacy AES-128 encryption or even simpler encryption and are still vulnerable to attack.
A typical system using a public key encryption (PKI) algorithm uses public key/private key encryption, in which the public key is generally available and used to encrypt data, but the private key is kept confidential and can decrypt the data. Because the private key is stored on one or more devices, if the computer itself is breached or hacked and the private key is discovered, the computational complexity of deciphering PKI-encrypted data can be bypassed, and sensitive user data can be exposed.
In the PKI system, an entity known as a certificate authority (CA) has the ability to issue private keys to allow trusted users to gain access to data. However, the CAs themselves have been breached, hacked, or stolen from, leading to counterfeit certificates being issued and user's data being stolen.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates a flow diagram that may be used by a data creator according to the embodiments herein;
FIG. 2 shows a flow diagram that would be used by a data accessor according to the embodiments herein;
FIG. 3 illustrates a block diagram of a transient symmetric key technology (TSKT) system that can implement the TSKT flows of FIGS. 1 and 2 according to various embodiments described herein;
FIG. 4 illustrates a block diagram of the TSKT system of FIG. 3 when the data creator requests the creation of a secure container;
FIG. 5 illustrates a block diagram of the TSKT system of FIG. 3 showing the actions of the CCS in response to the request for the creation of the secure container.
FIG. 6 illustrates a block diagram of the TSKT system of FIG. 3 showing the creation of the secure container;
FIG. 7 illustrates a block diagram of the TSKT system of FIG. 3 showing of the retrieval of the secure container by an authorized data accessor;
FIG. 8 illustrates a block diagram of the TSKT system of FIG. 3 showing a request by the authorized data accessor to decrypt the secure container; and
FIG. 9 illustrates a block diagram of the TSKT system of FIG. 3 when the CCS responds to the request for the retrieval of the secure container by the authorized data accessor; and
FIG. 10 illustrates a block diagram of the TSKT system of FIG. 3 when the data accessor decrypts the secure container.
In the following description, the use of the same reference numerals in different drawings indicates similar or identical items. Unless otherwise noted, the word âcoupledâ and its associated verb forms include both direct connection and indirect electrical connection by means known in the art, and unless otherwise noted any description of direct connection implies alternate embodiments using suitable forms of indirect electrical connection as well.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
Encryption and/or decryption according to the techniques described herein vastly improve known public key/private key systems by making encryption and decryption keys transitory on the user's system, such that they are only in existence for a period of time too short to expose the keys with any significant risk of hacking. The system is symmetric in that the same process is used for both encrypting and decrypting. The system defines a secure âcontainerâ for data that practically cannot be hacked.
In general, the inventors have created a transient, symmetric key method that allows for keys to be generated on demand and be present only for short periods of time while needed for encryption and decryption. The approach utilizes a distributed, zero-trust, end-to-end encryption architecture which leverages a new transient symmetric key technology (TSKT). After the keys are no longer needed, they are digitally destroyed by overwriting the values.
There will normally be three unique participants in the enhanced key management process: a data creator, a data accessor, and a command and control server. The data creator creates and encrypts the data. The data accessor has access rights to the encrypted data. The command and control server authenticates, validates and authorizes all creators' and accessors' rights to encrypted data.
Moreover, there are two types of keys that can be used to encrypt data: asymmetric and symmetric. Asymmetric cryptography, also known as Public-Key Infrastructure (PKI), uses a pair of keys (public and private) to encrypt and decrypt data. Traditionally, a network user receives a public and private key pair from a certificate authority. Any other user who wants to send an encrypted message can get the intended recipient's public key directly from the recipient or from a public directory. They use this key to encrypt the data, and they send it to the recipient. When the recipient gets the message, they decrypt it with their private key, which no one else should have access to.
However, this is not the case for the distributed, zero-trust, end-to-end encryption architecture described herein. In the architecture described herein, certificate authorities are unnecessary. Furthermore, the TSKT eliminates the need for a server to use, store, and manage public/private keys for users. The client machines generate their own public/private keys locally as needed. The public key is sent to the server by the local client when making a request to create a secure container or access an existing secure container. That public key is not stored on the server.
Known symmetric cryptography utilizes only one key to encrypt and decrypt data. While symmetric-key systems are generally more simple and faster, their main drawback is that the two parties attempting to communicate must somehow exchange the key in a secure way. This is where the TSKT comes into play, and the TSKT steps are described below. A TKST system according to some embodiments will now be described with a concrete example.
Exemplary Tskt Flows
FIG. 1 shows a flow diagram 100 that may be used by a data creator according to the embodiments herein. In the example shown in FIG. 1 , the dashed lines indicate the flow of data over a link using a TLS based protocol. The solid lines represent a processing step that takes place inside a particular node. The black keys are keys encoded using AES. The gray keys are keys encoded using RSA or ECC. In other embodiments, other link protocols and key encryption and decryption standards can be used as well. Using the TKST method, the data creator/protector performs the following steps:
Data Creator/Protector
1. Creator ( e.g. Client 1 in FIG. 1 ) has credentials, and generates public and private keys (RSA or ECC);
2. Creator requests permission from a Command & Control Server (CCS) (hereinafter âServerâ) to create a secure container;
3. Server authenticates and validates the request;
4. Server generates Seed A via a Pseudo Random Number Generator (PRNG), and Server generates a randomly unique formula;
5. Server encrypts copy of Seed A and the formula with creator's public key, e.g., an ECC 521 public key;
6. Server encrypts and stores Seed A and the formula;
7. Server passes encrypted Seed A and the formula to client via SSL or, as shown in FIG. 1 , TLS;
8. Creator decrypts Seed A and the formula using private key;
9. Creator generates Seed B on local device via a PRNG;
10. Creator uses the formula to combine Seed A and B to create Seed C, also known as the Data Seed;
11. Creator generates the payload;
12. Creator uses Seed A to generate AES Key 1 ;
13. Data Seed (C) is used to generate AES Key 2 ;
14. Creator uses AES Key 2 to encrypt payload;
15. Creator uses AES Key 1 to encrypt Seed B;
16. AES keys and seeds are destroyed by Creator;
17. Creator combines payload, encrypted Seed B and other data into one container;
18. Creator finishes registering the new secure container with the CCS; and
19. Container is ready for transport or storage, e.g. a cloud storage server.
As shown in FIG. 1 , in flow 100 at process node 110 a data creator, also referred to as Client 1 , desires to protect sensitive data and to create a secure container for it so it can be accessed by others that Client 1 desires to grant access to. Client 1 has credentials and generates public and private keys using, in the example shown in FIG. 1 , ECC/521 cryptography. Alternatively, the public and private keys can be creased using RSA. Client 1 sends its public key to the Command and Control Server (CCS). Subsequently when Client 1 wishes to create a secure container, Client 1 establishes a secure session with the CCS and creates symmetric AES session keys using Client 1 's public key before requesting permission to create a secure container. Communication between Client 1 and the CCS uses a secure process such as TLS/2048 over an internet connection to authenticate the user, validate the request, and generate Seed A. At process node 120 , the CCS generates an encrypted Seed A that was encrypted with, e.g., the AES session key generated using the data creator's ECC 521 public key, and sends encrypted Seed A to Client 1 as shown at process node 122 .
At process node 130 , Client 1 receives Seed A and decrypts it using the AES session key. At process node 132 , Client 1 uses the AES Key 1 to encrypt Seed B. At process node 140 , Client 1 generates Seed B using a PRNG. At process node 142 , Client 1 uses Seeds A and B to make Seed C according to the formula. At process node 146 , Client 1 uses Seed C to generate a key, namely AES Key 2 , and at process node 148 , Client 1 uses AES Key 2 to encrypt the data payload, i.e. sensitive data it desires to protect.
At process node 150 , Client 1 combines encrypted Seed B and the encrypted data payload, along with various metadata, to create the secure container. At process node 160 , Client 1 destroys all AES keys and seeds and the formula after use, including all encrypted forms thereof. At process node 160 , Client 1 finishes registering the new secure container with the CCS by sending the metadata to the CCS, encrypted using the AES session key. Finally at process node 170 , Client 1 sends the secure container to a storage server, such as a cloud storage server as shown in FIG. 1 , securely using TLS/2048.
FIG. 2 shows a flow diagram 200 that would be used by a data accessor according to the embodiments herein. Using the TKST method, the data accessor, also referred to as Client 2 , performs the following steps:
Data Accessor
1. Data accessor (hereinafter âaccessorâ) has credentials, and generates public and private keys (RSA or ECC);
2. Accessor receives the secure container from the cloud or other media;
3. Accessor opens the secure container and begins the process of requesting access to encrypted data;
4. Accessor sends their public key and container metadata to CCS via an SSL or TLS connection;
5. Server authorizes the request, and retrieves Seed A and the formula for the container that needs to be opened;
6. Server encrypts Seed A and the formula using Accessor public key;
7. Server passes encrypted Seed A and the formula to Accessor via the SSL or TLS connection;
8. Accessor decrypts container using its private key;
9. Accessor uses Seed A to generate AES Key 1 ;
10. Accessor uses AES Key 1 to decrypt Seed B and the formula;
11. Accessor combines Seed A and B to create Seed C, using the formula provided by Server;
12. Accessor uses Seed C to generate AES key 2 ;
13. Accessor uses AES Key 2 to decrypt the payload, the payload being viewable, for example, by a local client secure viewer; and
14. Accessor destroys all Seeds and AES keys.
In flow diagram 200 , at process node 210 , a medium such as a cloud storage server as stores a secure container previously created and uploaded by a data creator as shown in FIG. 1 . A data accessor, also referred to as Client 2 , desires to access the data in the secure container. It establishes a secure session with the cloud storage server using TLS/2048 and the cloud storage server transfers the data securely using TLS session keys. At process node 220 , Client 2 receives the secure container but is not yet able to decrypt it. It creates or has already created a public key-private key pair, and Client 2 sends a request to access it to the CCS along with its public key and the metadata from the secure container, again securely using at least one AES session key such as a TLS/2048 session key. At process node 230 , the CCS authenticates the request, validates Client 2 as a user, and determines access rights. At process node 232 , the CCS retrieves the Seed A and formula associated with the secure container, and encrypts it using the AES session key. At process node 240 , Client 2 receives and decrypts Seed A and the formula using its corresponding AES session key. At process node 242 , Client 2 generates a first key known as AES Key 1 from Seed A, and at process node 244 uses AES Key 1 to decrypt Seed B from the encrypted Seed B in the secure container. At process node 246 , Client 1 combines Seeds A and B using the formula to create Seed C, the Data Seed. At process node 248 , Client 2 uses Seed C to generate a second key known as AES Key 2 . At process node 250 , Client 2 uses AES Key 2 to decrypt the payload, i.e. the sensitive data that Client 1 wishes to protect but also to allow Client 2 access to. At process node 260 , Client 2 has access to the sensitive data. In the example shown in FIG. 2 , Client 2 has viewing rights but not printing or saving rights, so a secure viewer available to Client 2 allows Client 2 to view the sensitive data. At process node 270 , Client 2 destroys all keys and seeds and the formula after use, including all encrypted forms thereof.
Using the TKST process, the CCS never receives a copy of Creator's sensitive data, only Seed A and the formula. When the CCS sends Seed A and the formula, it uses a secure communication protocol, such as one using symmetric AES session keys like TLS or SSL. Moreover, AES Key 1 and AES Key 2 only exist for a very short period of time, on the order of a few microseconds, and the clients at which they are created, either Client 1 or Client 2 , can securely destroy them after use.
Details of an Exemplary TSKT System
FIG. 3 illustrates a block diagram of a TSKT system 300 that can implement the TSKT flows of FIGS. 1 and 2 according to various embodiments described herein. As explained above, a TSKT system defines four roles: a data creator, a command and control server (CCS), a storage server, and a data accessor. In some embodiments, the same physical computer system can function as both the CCS and the storage server.
TSKT system 300 includes a client labeled â CLIENT 1 â that functions as a data creator 310 , a file server system that functions as a CCS 320 , a cloud storage server, enterprise server, other file server system, or other storage medium that functions as a storage server 330 , and a client labeled â CLIENT 2 â that functions as a data accessor 340 . Each of CLIENT 1 and CLIENT 2 can have associated with it, for example, a laptop computer, a desktop computer, a notebook computer, a personal digital assistant (PDA), a smartphone, and the like, and in general each of them can be any data processor or data processing system capable of creating digital file content that will be secured at a user's direction and perform the computations as described.
CLIENT 1 and CLIENT 2 communicate with other components including CCS 320 and storage server 330 using existing wired and/or wireless computer networks, and TSKT system 300 shows these communication paths as bidirectional arrows. Typically, these communications paths will be internet connections implementing secure forms of the TCP/IP protocol that use AES session keys (TLS or SSL) for security. In some embodiments, SSL session keys may be used in place of the TLS session keys.
Data creator 310 first creates a file 312 that he or she wishes to grant data accessor 340 access to. The file can be, for example, a word processing document, a plain text file, a spreadsheet file, a visual presentation file, an photograph, an audio recording, a video recording, and the like. The user associated with data creator 310 may wish to secure file 312 because it contains credit card credentials, user passwords, personal health information, confidential business information, company trade secrets, attorney work product or attorney-client privileged communications, or other sensitive data. File 312 is stored in memory of the computer associated with data accessor 310 , and would be vulnerable to hacking or theft if sent over a public network such as the internet to data accessor 340 , and may additionally be subject to hacking or theft if stored on either CCS 320 or storage server 330 . TSKT system 300 assumes zero trust from computer networks and from organizations that operate CCS 320 and storage server 330 .
FIG. 4 illustrates a block diagram 400 of TSKT system 300 of FIG. 3 when data creator 310 requests the creation of a secure container. In order to request the secure container according to various embodiments described herein, data creator 310 first creates a public key-private key pair, and sends the public key to CCS 320 , before requesting the creation of a secure container. For example, data creator 310 may send its public key to CCS 320 through an application running on the computer associated with it and at a time when client 310 registers the application with CCS 320 .
Subsequently, data creator 310 desires to store data securely on storage server 330 , or to send data to data accessor 340 using other means. At this point, data creator 310 sends a request to create a secure container to CCS 320 . In some embodiments, the user creates the request using software resident on client 310 's associated computer. In one example, the software can be a stand-alone program running under the associated computer's operating system. In another example, the software can be a plug-in, applet, or widget that is tightly coupled to another program, such as an EMAIL program. In an exemplary embodiment, the software displays a graphical user interface that allows the user to select options associated with the creation secure container. The software preferably interacts with CCS 320 in the background and in a way that is invisible to the user to create a better user experience.
FIG. 5 illustrates a block diagram 500 of TSKT system 300 of FIG. 3 showing the actions of CCS 320 in response to the request for the creation of the secure container. CCS 320 first creates a record in its database or file system associated with the secure container identifying the request as coming from data creator 310 , using a tag labelled âC 1 â. CCS 320 creates a Seed A (described above) and a randomly unique formula and associates them with the secure container request for the particular client in its database. CCS 320 then encrypts Seed A and the randomly unique formula using, e.g., an AES session key. Thus, the public-network communications containing the encrypted seed and the encrypted formula are themselves protected using conventional but very strong encryption techniques.
FIG. 6 illustrates a block diagram 600 of TSKT system 300 of FIG. 3 showing the creation of a secure container 314 by the data creator 310 , i.e. Client 1 . As described above, after communicating with CCS 320 using TLS session keys, data creator 310 decrypts Seed A and the formula using its corresponding session key. Data creator 310 generates Seed B locally using a pseudo random number generator (PRNG). Data creator 310 then combines Seed A and Seed B using the decrypted formula to create Seed C, the Data Seed.
Data creator 310 also uses Seed A to generate AES Key 1 , and encrypts Seed B using AES Key 1 . Data creator 310 uses the Data Seed (Seed C) to generate AES Key 2 , and encrypts the data payload, i.e. the file desired to be protected, using AES Key 2 . Data creator 310 then combines encrypted Key 2 and encrypted Seed B with various metadata to form secure container 314 , labelled âSCâ. The metadata includes various data rights management (DRM) indicators such as copy, printing, and/or saving privileges, biometrics that can uniquely identify the user of data creator 340 such as fingerprints, facial characteristics, and the like, geographic information of data creator 340 for geo-fencing access rights, a device identifier (Device ID), and access rights such as timelines that indicate when accesses are allowed or prohibited.
Shortly after use in creating secure container 314 , data creator 310 destroys all keys and seeds and the formula. In this system, data creator 310 destroys both AES Key 1 and AES Key 2 , as well as Seed A, Seed B, the Data Seed, and the formula, and any encrypted versions of them, using a digital shredder 316 . A conventional file erase process of a personal computer operating system does not destroy or overwrite the data when the file is moved to the ârecycle binâ or âtrashâ, but merely deletes the file entry in the directory. Data of a recently deleted file may actually persist in computer memory for some time, making it subject to hacking and discovery. In addition, data that has been stored in a solid-state virtual memory drive, such as one based on floating-gate memory, may still be discoverable even after its nominal erasure, due to incomplete erasure or remaining charge profiles on the floating gates. To prevent these possibilities, data creator 310 uses digital shredder 316 to securely remove the data not only by removing its identification in the file directory, but also by overwriting the physical memory that the data was stored in sufficiently to prevent later discovery.
By creating Seed B using the PRNG with an adequate size, data creator 310 makes it practically impossible for a hacker to reproduce Seed B using random number generation. Moreover by allowing the seeds and keys to exist for only a brief period of time before they are digitally shredded, data creator 310 makes it difficult for a hacker that surreptitiously is able to access data creator 310 's computer remotely, to understand the significance of the activity quickly enough to capture the necessary seeds, formula, and keys while they exist and therefore to decrypt secure container 314 .
FIG. 7 illustrates a block diagram 700 of TSKT system 300 of FIG. 3 showing of the retrieval of the secure container by an authorized data accessor. In this example, data accessor 340 is presumed to be an authorized data accessor. Data accessor 340 fetches the secure container from storage server 330 . For example, the secure container may become visible in a shared file folder on storage server 330 , and data accessor 340 accesses the file as it would access any other file under its operating system. For example, data accessor 340 accesses storage server 330 using the internet and the TLS protocol that creates secure session keys for the session. In another example, data creator 310 may send the secure container to data accessor 340 as an attachment to an electronic mail (EMAIL) message. In this case, the message is routed to data accessor 340 's EMAIL server, and the message appears in the EMAIL Inbox of data accessor 340 from which it can be fetched. In yet another example, a user associated with data creator 310 transfers the secure file to the user associated with data accessor 340 using a portable medium such as a flash memory âthumbâ drive that can be accessed by data accessor 340 's computer.
FIG. 8 illustrates a block diagram 800 of TSKT system 300 of FIG. 3 showing a request by the authorized data accessor 340 to decrypt the secure container. As with data creator 310 , data accessor 340 initially creates a public key/private key pair, and sends the public key to CCS 320 . Later after receiving a secure container, data accessor 340 opens a secure session with CCS 320 using an SSL or TLS connection, and sends a secure request to CCS 320
CLAIMS
Claims ( 27 )
What is claimed is:
1. A method that, in response to a user's direction, causes a data creator to securely send a data payload to another device in a transient symmetric key technology (TSKT) system, comprising:
receiving an encrypted first seed and an encrypted formula from a command and control server, in response to the command and control server authenticating the data creator to create a secure container;
generating a second seed;
decrypting said encrypted first seed and said encrypted formula in response to said receiving;
combining said first seed and said second seed using said formula to create a data seed;
generating a first key using said first seed to form an encrypted second seed;
encrypting said second seed using said first key;
generating a second key using said data seed;
encrypting the data payload using said second key to form an encrypted data payload; and
combining said encrypted data payload and said encrypted second seed in said secure container, and
subsequently destroying all keys and seeds and said formula.
2. The method of claim 1 , further comprising: sending a request to create said secure container to said command and control server prior to said receiving said encrypted first seed and said encrypted formula from said command and control server.
3. The method of claim 1 , further comprising:
communicating with said command and control server using a secure communication protocol.
4. The method of claim 3 , wherein said communicating comprises:
generating a public key and a private key;
sending said public key to said command and control server; and
communicating with said command and control server using symmetric key cryptography with at least one session key generated using said public key.
5. The method of claim 1 , wherein said formula is characterized as being randomly unique and wherein said generating said second seed comprises:
generating said second seed using a pseudo random number generator (PRNG).
6. The method of claim 1 , wherein said data creator generates said first and second keys using an Advanced Encryption Standard (AES) encryption algorithm.
7. The method of claim 1 , wherein said destroying said first seed, said second seed, said data seed, said first key, and said second key comprises:
overwriting values of said first seed, said second seed, said data seed, said first key, and said second key in memory associated with said data creator.
8. The method of claim 1 , wherein said combining said data payload and said second seed in said secure container comprises:
combining metadata with said encrypted data payload and said encrypted second seed in said secure container.
9. The method of claim 8 , wherein said metadata comprises data rights management information associated with said secure container.
10. The method of claim 8 , wherein said metadata comprises biometrics information about an individual that controls the data creator.
11. The method of claim 8 , wherein said metadata comprises geolocation data associated with the data creator.
12. A method that, in response to a user's direction, causes a data accessor to securely decrypt a data payload from another device in a transient symmetric key technology (TSKT) system, comprising:
receiving and opening a secure container from the other device;
extracting an encrypted second seed and an encrypted data payload from the secure container;
receiving an encrypted first seed and an encrypted formula from a command and control server in response to the command and control server authorizing the data accessor to decrypt the data payload;
decrypting said encrypted first seed and said encrypted formula to create a first seed and a formula;
using said first seed to generate a first key;
using said first key to decrypt said encrypted second seed to form a second seed;
combining said first seed and said second seed using said formula to create a data seed;
using said data seed to generate a second key; and
decrypting said encrypted data payload using said second key to obtain the data payload, and subsequently destroying all keys and seeds and said formula.
13. The method of claim 12 , further comprising:
generating a public key and a private key;
sending said public key to a command and control server; and
communicating between said data accessor and said command and control server using symmetric key cryptography with at least one session key generated using said public key.
14. The method of claim 12 , wherein the other device comprises a cloud storage server.
15. The method of claim 12 , wherein the other device comprises a portable storage medium.
16. A method for operating a command and control server to implement a transient symmetric key technology (TSKT) system, comprising:
in response to a first request to create a secure container from a data creator:
authenticating said first request;
generating a first seed and a formula in response to said authenticating;
first encrypting said first seed and said formula to provide a first encrypted first seed and a first encrypted formula; and
sending said first encrypted first seed and said first encrypted formula to said data creator,
wherein said data creator:
decrypts said first encrypted first seed and said first encrypted formula, generates a second seed not based on either said first seed or said formula, and combines an encrypted data payload encrypted based on said first seed, said second seed, and said formula, and an encrypted second seed encrypted based on said first seed, into said secure container; and
in response to a second request that is subsequent to the first request to access data in said secure container from a data accessor:
authorizing said second request;
retrieving said first seed and said formula in response to said authorizing;
second encrypting said first seed and said formula associated with said secure container to form a second encrypted first seed and a second encrypted formula; and
sending said second encrypted first seed and said second encrypted formula to said data accessor in response to said second encrypting,
wherein said data accessor: decrypts said second encrypted first seed and said second encrypted formula, decrypts said encrypted second seed from said secure container based on said first seed, and decrypts said encrypted data payload from said secure container based on said first seed, said second seed, and said formula.
17. The method of claim 16 , wherein said formula is characterized as being randomly unique, and said generating said seed comprises generating said seed using a pseudo random number generator (PRNG).
18. The method of claim 16 , further comprising:
receiving a first public key from said data creator; and
subsequently communicating between said command and control server and said data creator using symmetric key cryptography with at least one session key generated using said first public key.
19. The method of claim 18 , wherein said communicating comprises:
receiving a second public key from said data accessor; and
communicating between said command and control server and said data accessor using symmetric key cryptography with at least one session key generated using said second public key.
20. A transient symmetric key technology (TSKT) system, comprising: a data creator comprising a first computer; and a command and control server comprising a second computer and coupled to the data creator, wherein:
in response to user input, said data creator sends a request to said command and control server to create a secure container for secure transmission and storage of a data payload,
said command and control server is configured to:
authenticate said request,
generate a first seed and a formula in response to authenticating said request,
encrypt said first seed and said formula to provide an encrypted first seed and an encrypted formula, and
send said encrypted first seed and said encrypted formula to said data creator in response to the command and control server authenticating the data creator to create said secure container, and
said data creator is configured to:
decrypt said encrypted first seed and said encrypted formula, generate a second seed,
combine said first seed and said second seed using said formula to create a data seed,
generate a first key using said first seed,
encrypt said second seed using said first key to produce an encrypted second seed,
generate a second key using said data seed,
encrypt said data payload using said second key,
combine said data payload and said encrypted second seed in said secure container, and
subsequently destroy all keys and seeds and said formula.
21. The TSKT system of claim 20 , further comprising:
a storage server coupled to said data creator for receiving and storing said secure container.
22. The TSKT system of claim 21 , wherein:
said storage server comprises a cloud storage server.
23. The TSKT system of claim 21 , wherein said command and control server and said storage server are implemented using a common computer system.
24. The TSKT system of claim 21 , wherein said command and control server and said storage server are implemented using separate computer systems.
25. The TSKT system of claim 21 , further comprising: a data accessor comprising a third computer coupled to said storage server, wherein said data accessor generates a public key and a second private key, sends said public key to said command and control server, subsequently receives and opens said secure container from said storage server, sends a request to access said secure container and secure container metadata to said command and control server.
26. The TSKT system of claim 25 , wherein: said command and control server selectively authorizes said request from the data accessor to access said secure container based on said secure container metadata, retrieves said first seed and said formula for said secure container, encrypts said first seed and said formula using symmetric key cryptography with at least one session key generated with said public key, and sends an encrypted first seed and an encrypted formula to said data accessor.
27. The TSKT system of claim 26 , wherein:
said data accessor receives and decrypts said encrypted first seed and said encrypted formula using said at least one session key, uses said first seed to generate said first key, uses said first key to decrypt said encrypted second seed, combines said first seed and said second seed using said formula to provide said data seed, uses said data seed to decrypt a payload, and subsequently destroys all keys and seeds and said formula.
US16/935,941
2019-07-25
2020-07-22
Enhanced secure encryption and decryption system
Active
2041-03-03
US11570155B2
( en )
Priority Applications (11)
Application Number
Priority Date
Filing Date
Title
US16/935,941
US11570155B2
( en )
2019-07-25
2020-07-22
Enhanced secure encryption and decryption system
KR1020227006393A
KR20220039779A
( en )
2019-07-25
2020-07-23
Enhanced security encryption and decryption system
BR112022000995A
BR112022000995A2
( en )
2019-07-25
2020-07-23
Improved secure encryption and decryption system
MX2022000793A
MX2022000793A
( en )
2019-07-25
2020-07-23
Enhanced secure encryption and decryption system.
IL289876A
IL289876B2
( en )
2019-07-25
2020-07-23
Encryption and decryption system with improved security
JP2022504535A
JP2022542095A
( en )
2019-07-25
2020-07-23
Hardened secure encryption and decryption system
CA3145851A
CA3145851A1
( en )
2019-07-25
2020-07-23
Enhanced secure encryption and decryption system
AU2020316082A
AU2020316082A1
( en )
2019-07-25
2020-07-23
Enhanced secure encryption and decryption system
CN202080053784.8A
CN114175580B
( en )
2019-07-25
2020-07-23
Enhanced security encryption and decryption system
EP20844992.6A
EP3991351A4
( en )
2019-07-25
2020-07-23
ENHANCED SECURE ENCRYPTION AND DECRYPTION SYSTEM
PCT/US2020/043283
WO2021016459A1
( en )
2019-07-25
2020-07-23
Enhanced secure encryption and decryption system
Applications Claiming Priority (2)
Application Number
Priority Date
Filing Date
Title
US201962878637P
2019-07-25
2019-07-25
US16/935,941
US11570155B2
( en )
2019-07-25
2020-07-22
Enhanced secure encryption and decryption system
Publications (2)
Publication Number
Publication Date
US20210029096A1
US20210029096A1 ( en )
2021-01-28
US11570155B2
true
US11570155B2 ( en )
2023-01-31
Family
ID=74190371
Family Applications (1)
Application Number
Title
Priority Date
Filing Date
US16/935,941
Active
2041-03-03
US11570155B2
( en )
2019-07-25
2020-07-22
Enhanced secure encryption and decryption system
Country Status (11)
Country
Link
US
( 1 )
US11570155B2
( en )
EP
( 1 )
EP3991351A4
( en )
JP
( 1 )
JP2022542095A
( en )
KR
( 1 )
KR20220039779A
( en )
CN
( 1 )
CN114175580B
( en )
AU
( 1 )
AU2020316082A1
( en )
BR
( 1 )
BR112022000995A2
( en )
CA
( 1 )
CA3145851A1
( en )
IL
( 1 )
IL289876B2
( en )
MX
( 1 )
MX2022000793A
( en )
WO
( 1 )
WO2021016459A1
( en )
Cited By (2)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US20250133066A1
( en )
*
2023-10-20
2025-04-24
Capital One Services, Llc
Secure encryption using tokenized data
WO2026005397A1
( en )
*
2024-06-24
2026-01-02
ì¼ì±ì ì주ìíì¬
Electronic device, method, and non-transitory computer-readable storage medium for performing electronic signature
Families Citing this family (12)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US12010229B2
( en )
*
2021-05-25
2024-06-11
International Business Machines Corporation
Durability enforcement of cryptographic keys in a key management system
ES3065863T3
( en )
2021-08-27
2026-05-08
Qohash Inc
System and method for secure collection and display of sensitive data
TWI868416B
( en )
*
2021-12-29
2025-01-01
æ°åç§æè¡ä»½æéå ¬å¸
Method and device for protecting and managing key
EP4231583A1
( en )
*
2022-02-16
2023-08-23
Gurulogic Microsystems Oy
Methods and arrangements for establishing digital identity
CN116800539A
( en )
*
2022-02-25
2023-09-22
å½ç½å±±ä¸ççµåå ¬å¸ä¸´æ²ä¾çµå ¬å¸
A quantum secret key encryption method for communication networks
US12452044B2
( en )
*
2022-05-17
2025-10-21
Kidde Fire Protection, Llc
Securing network communications using dynamically and locally generated secret keys
CN115174136B
( en )
*
2022-05-23
2024-02-02
å京æ·è§ç§ææéå ¬å¸
Data acquisition and data transmission method, terminal, server and storage medium
KR102486888B1
( en )
*
2022-05-30
2023-01-11
주ìíì¬ ë² ì´ì¤ì¤í¤íë©ì¤
A method for generating a quantum random number encryption key
KR102865851B1
( en )
*
2022-11-15
2025-09-30
주ìíì¬ ë² ì´ì¤ì¤í¤
Improved method for generating a quantum random number encryption key
KR20240079841A
( en )
*
2022-11-29
2024-06-05
ì¼ì±ì ì주ìíì¬
Method and device for encrypting data
US20250192989A1
( en )
*
2023-12-11
2025-06-12
Wells Fargo Bank, N.A.
Extensible key management (xkm)
CN119814356B
( en )
*
2024-11-29
2025-12-02
éå²æµ·å°ç§ææéå ¬å¸
A data security access system, method and electronic device
Citations (22)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US6381696B1
( en )
1998-09-22
2002-04-30
Proofspace, Inc.
Method and system for transient key digital time stamps
US20050244001A1
( en )
*
2003-04-11
2005-11-03
Satoshi Kitani
Information recording medium drive device
US20060224793A1
( en )
*
2005-03-31
2006-10-05
John Purlia
Mechanism and method for managing data storage
US20100150351A1
( en )
2004-07-14
2010-06-17
Sutton Ii James A
Method of Delivering Direct Proof Private Keys to Devices Using an On-Line Service
US20120250863A1
( en )
*
2009-02-19
2012-10-04
Leonid Bukshpun
Chaotic cipher system and method for secure communication
US20130013931A1
( en )
2011-03-07
2013-01-10
Security First Corp.
Secure file sharing method and system
US20140351586A1
( en )
2012-02-20
2014-11-27
Lock Box Pty Ltd
Cryptographic method and system
US20150117640A1
( en )
*
2013-10-31
2015-04-30
Electronics And Telecommunications Research Institute
Apparatus and method for performing key derivation in closed domain
US20160267280A1
( en )
*
2015-03-12
2016-09-15
Rasta Mansour
Mutual authentication of software layers
US20170033934A1
( en )
*
2015-07-29
2017-02-02
International Business Machines Corporation
Privacy-preserving attribute-based credentials
US20170054555A1
( en )
*
2015-08-20
2017-02-23
Alibaba Group Holding Limited
Method, apparatus, terminal device and system for generating shared key
US20170244687A1
( en )
2016-02-24
2017-08-24
Whitewood Encryption Systems, Inc.
Techniques for confidential delivery of random data over a network
US20170264599A1
( en )
*
2015-02-11
2017-09-14
Visa International Service Association
Systems and methods for securely managing biometric data
US10298554B2
( en )
2015-04-24
2019-05-21
Encryptics, Llc
System and method for enhanced data protection
US20190392153A1
( en )
*
2017-02-02
2019-12-26
Blancco Technology Group IP Oy
Method and System for Verifying a Data Erasure Process
US20200004970A1
( en )
*
2018-06-27
2020-01-02
At&T Intellectual Property I, L.P.
Multi-phase digital content protection
US20200059703A1
( en )
*
2018-08-17
2020-02-20
Samsung Electronics Co., Ltd.
Method and device for generating content
US20200272580A1
( en )
*
2019-02-27
2020-08-27
Nxp Usa, Inc.
Read-once memory and method of operating same
US20200358712A1
( en )
*
2019-05-06
2020-11-12
Bank Of America Corporation
Systems and methods for providing self-referencing utilization calculation and dynamic resource allocation based thereon for digital transmissions
US10924482B1
( en )
*
2014-12-18
2021-02-16
Amazon Technologies, Inc.
Virtual service authorization
US20210281408A1
( en )
*
2019-01-04
2021-09-09
Baidu.Com Times Technology (Beijing) Co. Ltd.
A data processing accelerator having a security unit to provide root trust services
US11128452B2
( en )
*
2017-03-25
2021-09-21
AVAST Software s.r.o.
Encrypted data sharing with a hierarchical key structure
Family Cites Families (5)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
FR2824212A1
( en )
*
2001-04-25
2002-10-31
Thomson Licensing Sa
METHOD FOR MANAGING A SYMMETRIC KEY IN A COMMUNICATION NETWORK AND DEVICES FOR IMPLEMENTING IT
US8948395B2
( en )
*
2006-08-24
2015-02-03
Qualcomm Incorporated
Systems and methods for key management for wireless communications systems
US9503433B2
( en )
*
2014-03-27
2016-11-22
Intel Corporation
Method and apparatus for cloud-assisted cryptography
US9716716B2
( en )
*
2014-09-17
2017-07-25
Microsoft Technology Licensing, Llc
Establishing trust between two devices
US9942034B2
( en )
*
2015-02-13
2018-04-10
Visa International Service Association
Confidential communication management
2020
2020-07-22
US
US16/935,941
patent/US11570155B2/en
active
Active
2020-07-23
AU
AU2020316082A
patent/AU2020316082A1/en
not_active
Abandoned
2020-07-23
WO
PCT/US2020/043283
patent/WO2021016459A1/en
not_active
Ceased
2020-07-23
BR
BR112022000995A
patent/BR112022000995A2/en
not_active
IP Right Cessation
2020-07-23
CN
CN202080053784.8A
patent/CN114175580B/en
not_active
Expired - Fee Related
2020-07-23
MX
MX2022000793A
patent/MX2022000793A/en
unknown
2020-07-23
EP
EP20844992.6A
patent/EP3991351A4/en
not_active
Withdrawn
2020-07-23
IL
IL289876A
patent/IL289876B2/en
unknown
2020-07-23
JP
JP2022504535A
patent/JP2022542095A/en
active
Pending
2020-07-23
CA
CA3145851A
patent/CA3145851A1/en
active
Pending
2020-07-23
KR
KR1020227006393A
patent/KR20220039779A/en
active
Pending
Patent Citations (22)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US6381696B1
( en )
1998-09-22
2002-04-30
Proofspace, Inc.
Method and system for transient key digital time stamps
US20050244001A1
( en )
*
2003-04-11
2005-11-03
Satoshi Kitani
Information recording medium drive device
US20100150351A1
( en )
2004-07-14
2010-06-17
Sutton Ii James A
Method of Delivering Direct Proof Private Keys to Devices Using an On-Line Service
US20060224793A1
( en )
*
2005-03-31
2006-10-05
John Purlia
Mechanism and method for managing data storage
US20120250863A1
( en )
*
2009-02-19
2012-10-04
Leonid Bukshpun
Chaotic cipher system and method for secure communication
US20130013931A1
( en )
2011-03-07
2013-01-10
Security First Corp.
Secure file sharing method and system
US20140351586A1
( en )
2012-02-20
2014-11-27
Lock Box Pty Ltd
Cryptographic method and system
US20150117640A1
( en )
*
2013-10-31
2015-04-30
Electronics And Telecommunications Research Institute
Apparatus and method for performing key derivation in closed domain
US10924482B1
( en )
*
2014-12-18
2021-02-16
Amazon Technologies, Inc.
Virtual service authorization
US20170264599A1
( en )
*
2015-02-11
2017-09-14
Visa International Service Association
Systems and methods for securely managing biometric data
US20160267280A1
( en )
*
2015-03-12
2016-09-15
Rasta Mansour
Mutual authentication of software layers
US10298554B2
( en )
2015-04-24
2019-05-21
Encryptics, Llc
System and method for enhanced data protection
US20170033934A1
( en )
*
2015-07-29
2017-02-02
International Business Machines Corporation
Privacy-preserving attribute-based credentials
US20170054555A1
( en )
*
2015-08-20
2017-02-23
Alibaba Group Holding Limited
Method, apparatus, terminal device and system for generating shared key
US20170244687A1
( en )
2016-02-24
2017-08-24
Whitewood Encryption Systems, Inc.
Techniques for confidential delivery of random data over a network
US20190392153A1
( en )
*
2017-02-02
2019-12-26
Blancco Technology Group IP Oy
Method and System for Verifying a Data Erasure Process
US11128452B2
( en )
*
2017-03-25
2021-09-21
AVAST Software s.r.o.
Encrypted data sharing with a hierarchical key structure
US20200004970A1
( en )
*
2018-06-27
2020-01-02
At&T Intellectual Property I, L.P.
Multi-phase digital content protection
US20200059703A1
( en )
*
2018-08-17
2020-02-20
Samsung Electronics Co., Ltd.
Method and device for generating content
US20210281408A1
( en )
*
2019-01-04
2021-09-09
Baidu.Com Times Technology (Beijing) Co. Ltd.
A data processing accelerator having a security unit to provide root trust services
US20200272580A1
( en )
*
2019-02-27
2020-08-27
Nxp Usa, Inc.
Read-once memory and method of operating same
US20200358712A1
( en )
*
2019-05-06
2020-11-12
Bank Of America Corporation
Systems and methods for providing self-referencing utilization calculation and dynamic resource allocation based thereon for digital transmissions
Non-Patent Citations (2)
* Cited by examiner, â Cited by third party
Title
" ProofMarkTM System Technical Overview "; white paper; Rev. Jul. 2007; Proofspace, 900 Clancy Ave NE, Grand Rapids, MI. 49503; United States; 19 pages.
International Search Report and Written Opinion for International Application No. PCT/US2020/043283, dated Oct. 26, 2020, 7 pages.
Cited By (3)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US20250133066A1
( en )
*
2023-10-20
2025-04-24
Capital One Services, Llc
Secure encryption using tokenized data
US12621274B2
( en )
*
2023-10-20
2026-05-05
Capital One Services, Llc
Secure encryption using tokenized data
WO2026005397A1
( en )
*
2024-06-24
2026-01-02
ì¼ì±ì ì주ìíì¬
Electronic device, method, and non-transitory computer-readable storage medium for performing electronic signature
Also Published As
Publication number
Publication date
EP3991351A1
( en )
2022-05-04
AU2020316082A1
( en )
2022-02-24
KR20220039779A
( en )
2022-03-29
IL289876B2
( en )
2024-09-01
BR112022000995A2
( en )
2022-06-14
EP3991351A4
( en )
2023-07-05
IL289876A
( en )
2022-03-01
CA3145851A1
( en )
2021-01-28
MX2022000793A
( en )
2022-02-16
JP2022542095A
( en )
2022-09-29
IL289876B1
( en )
2024-05-01
CN114175580B
( en )
2023-02-17
CN114175580A
( en )
2022-03-11
WO2021016459A1
( en )
2021-01-28
US20210029096A1
( en )
2021-01-28
Similar Documents
Publication
Publication Date
Title
CN114175580B
( en )
2023-02-17
Enhanced security encryption and decryption system
US9070112B2
( en )
2015-06-30
Method and system for securing documents on a remote shared storage resource
US7688975B2
( en )
2010-03-30
Method and apparatus for dynamic generation of symmetric encryption keys and exchange of dynamic symmetric key infrastructure
US9124641B2
( en )
2015-09-01
System and method for securing the data and information transmitted as email attachments
US11233653B2
( en )
2022-01-25
Dongle for ciphering data
US20020046350A1
( en )
2002-04-18
Method and system for establishing an audit trail to protect objects distributed over a network
US20220158829A1
( en )
2022-05-19
Computer system, device, and method for securing sensitive data in the cloud
US20140019753A1
( en )
2014-01-16
Cloud key management
CN110519049A
( en )
2019-11-29
A kind of cloud data protection system based on credible performing environment
CN114091058B
( en )
2026-03-31
Methods and systems for secure data sharing between the first and second zones
US20030174842A1
( en )
2003-09-18
Managing private keys in a free seating environment
AU2011201188A1
( en )
2011-04-07
System and method for securing data
US20030237005A1
( en )