Virtual Private Key Systems and Methods

Abstract

SUMMARY OF THE DISCLOSURE A system for generating a virtual private key using personal credentials to establish trust relationships between multiple entities, the credentials being stored in a remote secure repository, using information and data consisting of personal knowledge and a set of algorithms and methodologies integrated without the use of third party information to enable secure generation of the private key without exposing the credential entities.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Application No. 63 / 216,842, filed June 30, 2021.

[0002] STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT This invention was not researched or developed using any federal funding.

[0003] Names of parties in the joint research agreement Not applicable.

[0004] SEQUENCE LISTING INCORPORATED HEREIN BY REFERENCE Not applicable.

[0005] background [Background technology]

[0006] This disclosure relates to the use of virtual private and public keys in commercial activities.

[0007] Cloud computing and storage provide users with the ability to store and process data in third-party data centers. In data communications between users and service providers, providers must mask or encrypt all sensitive data (e.g., credit card numbers) and ensure that only authorized users can access the data in its entirety. Furthermore, digital identities and credentials must be protected, as must any data providers collect or create about customer activities in the cloud.

[0008] There are numerous security threats associated with cloud data services, including traditional and non-traditional threats. Traditional threats include network eavesdropping, unauthorized intrusions, and denial of service attacks. Threats specific to cloud computing include side channel attacks, virtualization vulnerabilities, and misuse of cloud services. To mitigate these threats, security controls often require monitoring three areas: confidentiality, integrity, and access control. This disclosure is related to access control.

[0009] Access control means that data owners can selectively restrict access to the data they have entrusted to the cloud. Legitimate users are granted access to the data by the owner, but no other users can access the data without authorization. Access control is sometimes called availability. Unauthorized access must be strictly prohibited, while administrative and even consumer access must be permitted and monitored. Availability and access control ensure that the right people have the right level of privileges.

[0010] Virtual security keys have been recognized in the commercial market as giving individual users virtual access to cloud-based data or data stored by or on behalf of a service provider. Security keys may be used to exchange information in a secure manner. Users often want to be able to exchange data securely, such that a third party cannot intercept and recover the information.

[0011] An example of such a situation is when an accounting firm needs to transmit financial information to a client: the accounting firm must first establish a trust relationship with the client and then transmit the information securely based on this trust relationship.

[0012] Currently, two types of keys are used to encrypt and decrypt data shared between users and service providers: asymmetric and symmetric. Each key is a variation of a known algorithm, but they are significantly different in that an asymmetric key is embodied as a private / public key pair, whereas a symmetric key is identical for both encryption and decryption. A private key must always be kept secret. A private key is not typically shared between the sender and receiver of encrypted sensitive information. Currently, systems that use public and private keys derived from large prime numbers, such as Public Key Infrastructure (PKI) type keys, use a shared symmetric key to encrypt and decrypt data.

[0013] In such a PKI system, one key is used to encrypt data and the other is used to decrypt it. Traditionally, a public key is shared and used to encrypt data, while a private key is kept secret and used to decrypt data. The problem is that the amount of data that can be encrypted is limited by the size of the modulus of the two keys. A public key with a modulus of 1024 bits can only encrypt a string that is 16 bytes long. For this reason, PKI systems are used to share symmetric keys that can be used to encrypt any amount of data. It is therefore clear that the strength of the system is proportional to the length of the symmetric key that can be shared, and it is desirable to introduce a system that generates larger symmetric keys. When using a symmetric key, the key must be the same for both encryption and decryption. Therefore, to use a symmetric key effectively, the shared key must be securely transferred to the other party. Loss of a PKI private key causes many problems, most of which are related to the need to revoke the public key. To mitigate this problem in web transactions, a symmetric key is shared between two parties using a public key and a private key. An example of a symmetric key sharing is Secure Sockets Layer (SSL).

[0014] Using shared symmetric keys removes this limitation, but requires a trust relationship between the two parties to share the key. In principle, symmetric keys are shared using a PKI-related system.

[0015] This virtual key methodology solves two problems. First, there is a need for a system that can exchange data without establishing trust relationships, and second, a system that generates public and private keys that are persistent and easily regenerated. This methodology provides a level of security at least equivalent to traditional cryptographic capabilities while removing many of the barriers associated with traditional security, such as the need for certificate authorities and revocation lists. This methodology provides the system with the ability to protect stored business data so that only authorized users can access it, eliminating traditional attempts at compromise. In some cases, information used by the system is derived from cryptographic data stored on the device instead of being stored on the device for use. BRIEF DESCRIPTION OF THE PRESENT DISCLOSURE

[0016] In a preferred embodiment, a system for generating virtual secret keys used to establish trust relationships between a user and one or more entities comprises the following elements:

[0017] A user device with a processor and memory A credential factory consisting of a private key miner Credentials Generator A credential factory obtains the user's credentials via a credit generator, which generates a virtual private key on request from the user. The virtual private key is optionally stored by the user, and the credit factory separately generates a public key that is associated with the virtual private key.

[0018] In another preferred embodiment, the system for generating virtual secret keys described herein includes a credential generator that transmits anonymized user credentials to a secure escrow server that includes a secure escrow database.

[0019] In another preferred embodiment, in the system for generating virtual secret keys described herein, the user authentication information consists of private, non-public information about the user.

[0020] In another preferred embodiment, the virtual private key generation system described herein uses user credentials and a set of algorithms and methodologies to generate a secure private key without exposing the user credentials and therefore without requiring third party information.

[0021] In another preferred embodiment, the system for generating a virtual private key described herein derives a mnemonic word for the virtual private key and further configures a digital wallet on the user device for storing encrypted random information on the RAM of the user device, the system uses the encrypted random information to derive and make available the virtual private key and mnemonic word only when the user is actively using an algorithm associated with the system.

[0022] In another preferred embodiment, the system for generating virtual private keys described herein does not store the private key in any database, but keeps it only in a virtual state. Whenever the private key is needed, it can be regenerated from the user's knowledge by first generating anonymized credentials and passing the credentials to a private key miner. And all other system components that do not require confidentiality can be stored normally.

[0023] In another preferred embodiment, a method of using the system for generating virtual private keys described herein comprises the following steps:

[0024] 1. Download the credential factory to the user device's memory 2. Provide the user with a credential generator interface to allow the user to enter personal credentials 3. Request a credential factory to create a virtual secret key 4. Transferring credentials from the credential generator to the credential factory 5. Generate a Virtual Secret in the Credentials Factory using the anonymized credentials 6. Use a credential factory to generate a public key to map to the virtual private key 7. Save the public key to the user device storage 8. Optionally, store anonymized personal credentials associated with the virtual private key in a secure escrow server and secure escrow database. [Brief description of the drawings]

[0025] [Figure 1] FIG. 1 is a schematic diagram outlining an example of the virtual private key systems and techniques disclosed herein. [Diagram 2] FIG. 2 is a flow chart illustrating the steps of the method of the present invention using the system of FIG. [Diagram 3] FIG. 3 is a flow chart showing the steps of the private key miner function of the system of FIG.

[0026] Detailed Description of the Invention The generation of the virtual private key of the present invention is used, as an example, to share data between multiple entities. At the same time, the virtual private key can be used for commercial purposes such as cryptocurrency. The private key of the present invention is set by personal authentication information, but can also be salted with other personal information.

[0027] This methodology allows for secure storage of credentials in a remote secure repository using the inventive methodology described herein. An example of the disclosed system uses information and data consisting of an individual user's knowledge and a set of algorithms and methodologies integrated to securely generate a private key without revealing credential entities such as a user name and password selected by the user. In some embodiments, no third party information is required for key generation. User credentials are passed through a non-reversible methodology that makes them anonymous. Current systems use hashing and randomization algorithms in the process of generating and regenerating virtual keys.

[0028] An example of this embodiment is a user registering with a system where the user must provide an acceptable username and password. These user credentials are used to generate a pseudo-random string, which is then used to generate a private key. The generated private key has the properties of being regenerable and being a virtual key. Furthermore, the username and password do not need to be stored in any system since it is based on the user's knowledge. In this embodiment, the private key is generated so that it can be used in a commercial transaction, to be compatible with existing systems. More specifically, the private key can be used to generate a valid sequence of 24 words selected from a list of 2048 words that are valid for the crypto wallet. Although there are other methodologies for generating this list, the approach of the present invention is based on the user credentials. The user credentials cannot be obtained by reverse engineering the process.

[0029] The present invention utilizes the properties of elliptic curves to generate appropriate private and public keys. While the use of such elliptic curves is well known, the methodology described herein is unique and innovative. It utilizes a "mining" process inside CF to generate a string of 32 bytes (8 bits each) and generate a sequence of 24 words from a list of 2048 commonly known words. These 24 words can also be the basis for forming a private key in a cryptocurrency, for example. Note that there are two mutually exclusive public keys that can be generated by this methodology (i.e., a public key derived from a virtual private key and a public key derived from a key derived from a string). One of these public keys is suitable for cryptocurrency and the other is suitable for data sharing.

[0030] In the main embodiment, the system of the present invention is not limited to sharing data with a single other entity. Rather, it allows multiple entities to securely share information. The public key can be derived from this private key, and thus the present embodiment is related to the formation and use of the private key. The design of the system does not require the use of current public key infrastructure. The system is unique and original in that the owner's authentication information is never provided to any other party, the private key is never stored or exposed to the underlying system, and is a virtual key that can be easily regenerated. For convenience, the private key can also be stored encrypted with a strong cryptographic key.

[0031] One main embodiment of the present system and methodology is shown in Figure 1 and described in more detail below. In this embodiment, the public and private keys cannot be tampered with or forged without ceasing access to the data. If either key is tampered with or forged, decryption of the information will fail since there is no one-to-one relationship between the keys. If the key is tampered with, the system will detect the tampering immediately as user authentication will immediately fail before access to the encrypted data begins. In this system, data encrypted with authentication information is inherently protected until the required authentication information is entered and verified. This methodology utilizes the ingenious step that authentication can be achieved by encryption and decryption success or failure rather than by comparing authentication information.

[0032] The advantage of this type of system is that it provides an effective and reliable system without exposing the critical private key. If the user's device is lost or stolen, a new private key and associated data can be regenerated using the user's personal credentials. The credentials can be strong, but must be easy to remember.

[0033] In another main embodiment, the system for generating virtual private keys described herein uses personal information of the user and a set of algorithms and methodologies to securely generate private keys without exposing the credential entity and thus without requiring third party information. An example of a practical use of this mechanism is a cryptocurrency wallet, which is required to protect data and not reveal it to anyone. Once registered, information stored in the wallet is mathematically calculated to create a private key, which is then used to derive a mnemonic word. Most wallets store private keys, mnemonics, and passwords on the device for authentication, providing a minimum level of protection, but data can be exposed if the device is lost or stolen. The mechanism does not store any such information, nor does it store any credential information associated with the user on the device. The wallet private key and mnemonic are derived on an as-needed basis from cryptographically random information stored in the wallet and held in RAM for the duration of the session. This protects sensitive information, since it is only available in RAM during the active session and only when needed by the user. Once the session is over, the sensitive information is removed from RAM, and cannot be retrieved from the device even if it is lost or stolen. This mechanism protects the wallet from intrusion whenever the session is inactive.

[0034] Detailed Drawing Description Figure 1 outlines an example of the virtual private key system and methodology disclosed herein, beginning with a client / user setting up a secure transaction using a user device 2, which may be a personal mobile device, tablet or personal computer. In this diagram, the client has installed a credential factory 3 (hereafter "CF") on his / her local device. Each CF consists of a "miner" embodied as software that operates according to the process of Figure 3 described below. In this diagram, the system components are numbered and each step is labeled with a letter.

[0035] In step A, the user sends a request to the locally installed CF3 to generate a virtual key using user-specific credentials, which may be done automatically as part of the transaction configuration interface. Step A begins with a Credential Generator 4 (hereafter "CG").

[0036] In step B, the CF3 server obtains credentials from the user via CG4 by first collecting user credentials from the user device 2 and then creating anonymized credentials from the credentials provided by the user. CG4 is configured to select the appropriate credentials for the user. The credentials may consist of a username, a password, answers to questions, or even reproducible biometrics or information obtained from a wearable device or hardware token. CF3 takes the anonymized credentials and generates a reproducible private key. Note that CG4 is a component of CF3, but in other embodiments, CG4 and CF3 may be separate components. The components of CF3 may be located locally or remotely, and CG4 and CF3 may have a client-server relationship. The private key may have a strength proportional to the user credentials used to generate it.

[0037] In step C, the CF3 makes the generated private key available to the user, either virtually on the device's RAM or by transmitting it over the Internet or the like. In this embodiment, the key does not need to be displayed or stored. do not have .

[0038] In step D, the CF 3 generates an associated public key and sends it together with other data to a storage device 8 consisting of a storage container / memory of the user device 2. This storage device 8 can be embodied as a local disk storage device such as a hard drive and associated devices, or remote storage on the cloud. The stored data does not need to be secure and is in fact intended for public use.

[0039] In step E, the user's anonymized private credentials may be sent to an associated secure escrow server 5 as a backup so that user 2 can retrieve the credentials if the user is no longer able to generate the credentials. It is not possible to revert the anonymized credentials back to user credentials, and anonymized credentials in escrow are useless without the associated personal information. The secure escrow server 5 may then, in optional step F, store the anonymized credentials in an associated secure escrow database 6.

[0040] FIG. 2 is a flow chart showing the steps of the method of the present invention using the virtual key system 1 shown in FIG.

[0041] 1. Download the credential factory to the user device's memory 2. Provide the user with a credential generator interface to allow the user to enter personal credentials 3. Request a credential factory to create a virtual secret key 4. Transfer the credentials from the credential generator 4 to the credential factory 5 5. Generate a Virtual Secret Key in Credentials Factory 3 using the anonymized credentials 6. Use a credential factory3 to generate a public key that maps to the virtual private key. 7. Save the public key to the user device's storage 8 8. Optionally, store anonymized personal credentials associated with the virtual private key in a secure escrow server 5 and secure escrow database 6. FIG. 3 is a flowchart illustrating a private key miner 3A and associated technique for returning to a user a virtual private key (hereinafter, “VPK”) derived from the user-specific anonymized authentication information (hereinafter, “AC”) received by the system.

[0042] Step A is to receive the AC from the registered device. The AC contains a two-byte enterprise code (hereinafter referred to as "EC").

[0043] EC is used to distinguish the registration system.

[0044] In step B, the AC is received and passed to a process that generates a pseudorandom string (hereinafter "PB").

[0045] PB can be reproduced by giving the generator the same AC and EC.

[0046] In step C, the PB is hashed and matched with the EC.

[0047] If the hashes match, go to step F-5.

[0048] If the hashes do not match, go to step D, then go to 4.

[0049] Increment a random string.

[0050] Increase your PB by one, go back to 3 and check again.

[0051] Continue this process until a valid hash is matched.

[0052] In step F, the VPK is returned to the system.

[0053] Parts Index: 1 Virtual Key System 2. User Devices 3 Credential Factory (CF) 3A Private Key Miner 4 Credential Generator Server (CG) 5. Secure Escrow Server 6. Secure Escrow Database 7 Virtual Keys User device storage The entirety of the references cited herein are incorporated herein because they contain any disclosures that are relevant to the level of teaching of a person skilled in the art and necessary for a layperson to understand the subject matter of the claimed invention. It is clear to those skilled in the art that the above-mentioned embodiments can be modified or slight changes can be made without departing from the scope of the present invention. Therefore, the scope of the present invention is determined by the scope of the following claims and their fair equivalents.

Claims

1. A system for generating virtual secret keys used to establish a trust relationship between a user and one or more entities, comprising the following elements: A user device with a processor and memory A credential factory consisting of a private key miner Credentials Generator A credential factory obtains the user's credentials via a credit generator, which generates a virtual private key on request from the user. The virtual private key is optionally stored by the user, and the credit factory separately generates a public key that is associated with the virtual private key.

2. 2. The system for generating a virtual private key of claim 1, wherein the credential generator transmits anonymized user credentials to a secure escrow server having a secure escrow database.

3. In the system for generating a virtual private key of claim 1, the user authentication information comprises non-public personal information of the user.

4. The system for generating a virtual private key of claim 3 uses user authentication information and a set of algorithms and methodologies to generate a secure private key without disclosing the user authentication information and therefore without requiring third party information.

5. The system for generating a virtual private key of claim 4, wherein the virtual private key derives a mnemonic word and further comprises configuring a digital wallet on the user device for storing encrypted random information on the RAM of the user device. The system uses cryptographically random information to derive and make available virtual secret keys and mnemonic words only when a user is actively using an algorithm associated with the system.

6. The system for generating a virtual private key according to claim 1, Private keys are not stored in any database, but are kept only in a virtual state Whenever the private key is needed, it can be regenerated from the user's knowledge by first generating anonymized credentials and then passing these credentials to a private key miner. Additionally, all other system components that do not require confidentiality can be stored normally.

7. A method of using the system for generating a virtual private key of claim 1, comprising the steps of:

1. Download the credential factory to the user device's memory 2. Provide the user with a credential generator interface to allow the user to enter personal credentials 3. Request a credential factory to create a virtual secret key 4. Transferring credentials from the credential generator to the credential factory 5. Generate a Virtual Secret in the Credentials Factory using the anonymized credentials 6. Use a credential factory to generate a public key to map to the virtual private key.

7. Save the public key to the user device storage 8. Optionally, store anonymized personal credentials associated with the virtual private key in a secure escrow server and secure escrow database.

Images