JP2023525774A - Key Generation Method Using Controlled Corruption in Computer Networks - Google Patents

Abstract

Kind Code: A1 The present invention is a platform and/or agnostic method and system operable to protect data, documents, devices, communications, and transactions. Embodiments of the present invention may be operable to authenticate users and may be operable with any client system. The method and system operate to distribute unique pieces of anonymous related information among multiple devices. These devices distribute a unique piece of anonymous information and are utilized by the solutions to protect sensitive data transmissions and authenticate users, data, documents, devices and transactions. When used for authentication, login-related information is not stored anywhere in the solution, and users and devices are authenticated anonymously. This solution also allows the user to access protected portions of the client system through a semi-autonomous process without revealing the user's key. [Selection drawing] Fig. 31

Description

The present invention relates generally to the field of data security, and more specifically to security of intended communications and authentication of users of networks or systems.

Protecting data from possible security breaches is a challenge for all organizations. Data security enables organizations to ensure that communications are secure and that only authorized personnel are allowed access to organizational systems across multiple technologies. Thus, data security and authorized system access are two major issues that organizations must contend with today.

A number of systems and methods currently exist that provide various types of authentication for users of systems and networks. These various types of authentication differ in their level of security and trust. The following are examples of types of prior art authentication methods for systems and networks.

U.S. Pat. No. 6,962,530, issued Nov. 8, 2005 to IGT, discloses an architecture and method for a game-only platform, which architecture and method can process game code and other data. is securely stored and verified. The method further provides the user with the ability to securely exchange data with a computerized wagering gaming system. This invention does not involve disseminating login information among multiple devices.

U.S. Patent No. 9,053,306, granted to NEC Solution Innovators, Ltd. on June 9, 2015, discloses a method for calculating a first hash value and a second hash value from login information entered by a user. An authentication system that works is disclosed. A session is established between the server and the terminal if the first hash value and the second hash value match. The invention does not involve hiding some of the encrypted details.

U.S. Pat. No. 8,989,706, granted March 24, 2015 to Microsoft Corporation, discloses systems, methods and/or techniques for automated secure pairing for devices, Related to parallel download of content using . Tools for pairing devices may implement address-based authentication protocols and key-based authentication protocols. The invention does not involve hiding some of the encrypted details.

Koninklijke Philips Electronics N.V. V. U.S. Pat. No. 8,356,180 to , discloses a method for multi-dimensional identification, authentication, authorization, and key distribution for secure communications in deep common security domains. The present invention cannot authenticate transactions without the user revealing the user's key to the system.

United Devices, Inc. on August 25, 2000. U.S. Pat. No. 6,847,995 to , discloses a security architecture and method for providing secure transfers within a distributed processing system. The present invention does not involve multiple layers of encryption or hiding some of the encrypted details.

U.S. Patent Application Publication No. 2017/0149796, filed Nov. 23, 2016 by Yaron Gvili, describes systems and techniques for enabling third-party verifiers to verify features of secure data, or the success thereof. Disclosure of Communications The present invention does not involve multiple layers of encryption or hiding some of the encrypted details.

US Patent Application Publication No. 2011/0246779, filed June 6, 2011 by Isamu Teranishi, discloses a zero-knowledge proof system that enables discrete logarithmic zero-knowledge proofs. The present invention does not involve multiple layers of encryption or hiding some of the encrypted details.

Prior art encryption methods and systems are particularly vulnerable to third party intervention in data and information transfers between users and systems or networks. A third party can deduce login details from that information if they have access to the data in transit. A third party can use the user's login details to login to the system, provided that all of the login details are available from the data transferred between the user and the system. This poses a security risk to current systems when known authentication methods and systems are used.

What is needed is an authentication method and system that prevents a user's login information from being obtained by a third party interfering with the data sent.

In some embodiments, a method of generating and distributing keys using controlled corruption includes registering a first computing device with one or more servers comprising a security engine and an action engine. , receiving, at the one or more servers, from the first computing device a first privacy code and one or more parameters associated with first data; is based on a first user input at the first computing device, and the first data is based on a second user input at the first computing device; and the one or more generating a chunk count and a public key, at a server of sending the chunk count and the public key from the one or more servers to the first computing device; and at the one or more servers from the first computing device: receiving data relating to a number of privacy keys and a second privacy code, the number of privacy keys being based on the first data, the chunk count, and the one or more corruptors; the second privacy code is based on the first privacy code, the number of privacy keys equals the chunk count; and the amount of privacy at the one or more servers. Generating second data based on a key, wherein generating the second data comprises concatenating the certain number of privacy keys to generate a concatenated key; or removing a plurality of corruptors to generate the second data.

In some embodiments, the method of generating and distributing keys using controlled corruption includes generating two or more chunk names at the one or more servers; sending a chunk name to the first computing device.

In some embodiments, the number of privacy keys is further based on the two or more chunk names.

In some embodiments, concatenating the number of privacy keys to generate the concatenated key is based on the two or more chunk names.

In some embodiments, the one or more corruptors consist of three corruptors.

In some embodiments, at least one of said one or more corruptors is based on said first privacy code.

In some embodiments, removing the one or more corruptors to generate the second data includes removing one or more first corruptors from the concatenated key to create a first clean removing one or more second corruptors from the first clean data to generate second clean data; and removing one from the second clean data. or removing a plurality of third corruptors to produce a base of compressed data 64; decoding said compressed second base of data to produce said compressed data; and decompressing said compressed data. and generating the second data by
The privacy code is used to remove at least one of the one or more first corruptors, the one or more second corruptors, and the one or more third corruptors.

In some embodiments, the first privacy code is used to remove at least one of the one or more corruptors.

In some embodiments, said second privacy code is used to remove at least one of said one or more corruptors.

In some embodiments, the first data includes intended communications.

In some embodiments, the second user input includes at least one of an alphanumeric character string, biometric data, password, eye scan, photograph, and fingerprint.

In some embodiments, a method of generating a key using controlled corruption includes generating, at a first computing device, a first privacy code and one or more parameters associated with first data. wherein the first privacy code is based on a first user input and the first data is based on a second user input; and the first privacy code and one or more parameters associated with the first data from the first computing device to one or more servers; and at the first computing device, from the one or more servers receiving a chunk count and a public key, wherein the chunk count is based on one or more parameters associated with the first data and the public key is part of an asymmetric cryptographic key pair; compressing the first data to generate compressed first data at the first computing device; and generating compressed first data at the first computing device; or generating a first pre-key based on a plurality of first corruptors; and at said first computing device, based on said first pre-key and one or more second corruptors, said generating a second pre-key; generating, at the first computing device, two or more chunks based on the second pre-key and the chunk count; and at the first computing device , generating two or more privacy keys based on the two or more chunks, and sending the two or more privacy keys to the one or more servers.

In some embodiments, generating the two or more chunks based on the second pre-key and the chunk count includes corrupting the second pre-key with a salt to generate a third pre-key. corrupting the third pre-key using one or more third corruptors; and splitting the corrupted third pre-key into the two or more chunks based on the chunk count. and

In some embodiments, the method of generating keys using controlled corruption further comprises receiving two or more chunk names at the first computing device.

In some embodiments, the one or more privacy keys are further based on the two or more chunk names.

In some embodiments, a method of generating and distributing keys using controlled corruption includes registering a first computing device with one or more servers; receiving from the first computing device a first privacy code and one or more parameters associated with first data, wherein the first privacy code is at the first computing device; and the first data is based on a second user input at the first computing device; and at the one or more servers, chunk count and generating a public key, wherein the chunk count is based on one or more parameters associated with the first data, the public key being part of an asymmetric cryptographic key pair; sending a count and the public key from the one or more servers to the first computing device; and at the one or more servers from the first computing device for a number of first privacy keys. receiving data and a second privacy code, wherein the number of first privacy keys is based on the first data, the chunk count and one or more corruptors; the number of first privacy keys is based on the first privacy code, wherein the number of first privacy keys equals the chunk count; and at the one or more servers, the number of generating second data based on one privacy key, wherein generating the second data includes concatenating the certain number of first privacy keys to generate a concatenated key; , removing the one or more corruptors from the concatenated key to generate the second data; and at the one or more servers, based on the second data. generating a result; and generating, at the one or more servers, a recipient identifier and a privacy code identifier based on the result, wherein the recipient identifier is associated with one or more nodes. and wherein said privacy code identifier is based on said second privacy code; and said number of first privacy keys, said recipient identifiers, and said privacy code identifiers are provided to said one or more nodes. including distributing.

In some embodiments, the method of generating and distributing keys using controlled corruption comprises: at said one or more servers, from said first computing device, two keys based on third data; and generating sign-in data, wherein the sign-in data is based on two or more privacy keys based on the third data.

In some embodiments, the method of generating and distributing keys using controlled corruption includes: keys stored in the one or more nodes based on at least one of the recipient identifier and the privacy code identifier; and generating enrollment data, wherein the enrollment data is based on privacy keys obtained from the one or more nodes.

In some embodiments, a method of generating and distributing keys using controlled corruption includes comparing the sign-in data and the enrollment data and generating a result. OK.

In some embodiments, a system comprising a server, said server comprising a memory comprising server instructions, and a processing device configured to execute said server instructions, said server instructions comprising said registering a first computing device with a processing device at one or more servers, the one or more servers comprising a security engine, an action engine, a library, and one or more associated with the one or more servers; and receiving, at the one or more servers, from the first computing device a first privacy code and one or more parameters associated with first data. the first privacy code is based on a first user input at the first computing device and the first data is based on a second user input at the first computing device and generating, at the one or more servers, a chunk count and a public key, wherein the chunk count is based on one or more parameters associated with the first data; the key is part of an asymmetric cryptographic key pair; sending the chunk count and the public key from the one or more servers to the first computing device; and at the one or more servers, receiving a number of privacy keys and a second privacy code from a first computing device, the number of privacy keys comprising the first data, the chunk count, and one or more corruptors; and the second privacy code is based on the first privacy code, and the number of privacy keys in the certain number equals the chunk count; and at the one or more servers, generating second data based on the quantity of privacy keys, wherein generating the second data comprises concatenating the number of privacy keys to generate a concatenated key; and removing the one or more corruptors from the concatenated key to generate the second data.

In this regard, before describing at least one embodiment of the invention in detail, the invention is limited to the details of construction and arrangement of components set forth in the following description or illustrated in the drawings. It should be understood that the The invention is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein is for the purpose of description and should not be regarded as limiting.

The invention will be better understood and the objects of the invention will become apparent upon consideration of the following detailed description. The detailed description refers to the accompanying drawings.

FIG. 1 is a system diagram showing one embodiment of the authentication system of the present invention. FIG. 2 is a system diagram illustrating the configuration of elements operable to transfer data between a client system and a verification system in accordance with an embodiment of the present invention. FIG. 3 is a system diagram illustrating the organization of elements that operate to perform the registration process of an embodiment of the present invention. FIG. 4 is a system diagram illustrating the configuration of elements that operate to perform the access process of an embodiment of the present invention. FIG. 5 is a system diagram illustrating a synchronization element operating to process hashed OY-packet portions in accordance with an embodiment of the present invention. FIG. 6 is a system diagram illustrating the configuration of elements that operate to perform the decoding process according to one embodiment of the present invention. FIG. 7 is a system diagram illustrating elements of a user device in one embodiment of the invention. FIG. 8 is a system diagram illustrating elements of the client system of one embodiment of the present invention. FIG. 9 is a system diagram illustrating elements of the client display unit of one embodiment of the present invention. FIG. 10 is a system diagram illustrating elements of the verification system of one embodiment of the present invention. FIG. 11 is a system diagram illustrating the organization of elements operable to process user authentication requests to access secure portions of a client system, in accordance with one embodiment of the present invention. FIG. 12 is a system diagram illustrating the organization of elements operable to generate and process noise and keys for user authentication in accordance with one embodiment of the present invention. FIG. 13 is a system diagram illustrating the organization of elements that operate to validate keys for user authentication in accordance with an embodiment of the present invention. FIG. 14 is a system diagram illustrating the organization of elements operable to validate tokens for authentication of users in accordance with one embodiment of the present invention. FIG. 15 is a system diagram illustrating the composition of elements that operate to validate a challenge via a client presentation system for authenticating a user, according to one embodiment of the present invention. FIG. 16 is a system diagram illustrating a configuration of elements that operate to validate a challenge via a user device for user authentication, according to one embodiment of the invention. FIG. 17 illustrates a registration method according to one embodiment of the invention. FIG. 18 illustrates a method of creating one or more keys according to one embodiment of the invention. FIG. 19 illustrates a method of distributing one or more keys according to one embodiment of the invention. FIG. 20 illustrates a login method according to one embodiment of the invention. FIG. 21 illustrates a method of creating one or more keys according to one embodiment of the invention. FIG. 22 illustrates a method of distributing one or more verification keys according to one embodiment of the invention. FIG. 23 illustrates a method of validating a validation key with a local database according to one embodiment of the invention. FIG. 24 illustrates a method of enabling a verification process according to one embodiment of the invention. FIG. 25 illustrates a method of generating one or more barcodes according to one embodiment of the invention. FIG. 26 illustrates a method of generating one or more keys according to one embodiment of the invention. FIG. 27 illustrates a method of generating one or more keys according to one embodiment of the invention. FIG. 28 illustrates a method of generating one or more keys according to one embodiment of the invention. FIG. 29 illustrates a method of establishing a web session according to one embodiment of the invention. FIG. 30 illustrates a system for generating keys using controlled corruption, according to some embodiments. FIG. 31 illustrates a method of generating keys using controlled corruption, according to some embodiments. FIG. 32 illustrates a method of generating keys using controlled corruption, according to some embodiments. FIG. 33 illustrates a method of generating keys using controlled corruption, according to some embodiments. FIG. 34 illustrates a method of generating keys using controlled corruption, according to some embodiments. FIG. 35 illustrates a method of using keys generated with controlled corruption for authentication, according to some embodiments.

In the drawings, embodiments of the invention are illustrated by way of example. It is expressly understood that the specification and drawings are for the purpose of illustration only and as an aid to understanding and are not intended as a definition of the scope of the invention.

The present invention is an authentication method and system that operates to authenticate users, data, documents, devices, and transactions. Embodiments of the present invention can operate on any system or network at any organization or individual. The authentication method and system are operable to distribute unique pieces of login-related information among multiple devices. The distributed portion of the login-related information is utilized by the system to authenticate users, data, documents, devices, and transactions without revealing the login-related information to the system. The login-related information is multi-layered encrypted and/or hashed, and some of the encrypted and/or hashed details are hidden. Any device that stores login-related information is used in the authentication method and system. User-provided login-related information is not revealed and/or stored in the system or any user device. Authentication of data, documents, devices and transactions does not require keys published to the system.

As used herein, "client system" means any organizational or individual network or system. As used herein, "user device" means a device that a user uses to log into a client system, such as a laptop, tablet, mobile phone, smartphone, desktop computer, smartwatch, computing device. , thereby allowing a user to log into a client system or other device that requires a secure login. References to "transferring information" between a user and a client system may include creating, transferring, or storing information occurring in connection with the system.

For clarity, when referring to a unit or element of the authentication system that "accesses" another unit or element of the authentication system, this may include any of the following: (i) a unit or element accessing and obtaining information from another unit or element; or (ii) a unit or element making a request to another unit or element for information to be obtained or generated. sending, and when that information is obtained or generated in response to a request, that information is sent to the unit or element that sent the request.

When a user logs into a client system using a user device, the generation, transfer, storage, or authentication of login-related information between the user device and the client system may be vulnerable to attacks by third parties. . A third party's use of such information during the generation, transfer, storage, and/or authentication of login-related information between the User Device and the Client System as a result of an attack by a third party on the User Device or Client System; may be obtained and/or used for unauthorized purposes. For example, a third party may use obtained login information to log into the client system, thereby achieving unauthorized access to the client system, obtain more login-related information from the client system, or otherwise Depending on the method, there is the possibility of moving laterally to systems that are connected to the client system. As another example, a third party may use data, documents, or transaction information obtained from an attack for various illicit purposes (e.g., disseminating information to other parties, gaining an advantage in the market, etc.). information, holding information hostage for ransom, espionage, destruction, etc.). The present invention reduces the client system's vulnerability to unauthorized use of the client system and of data, documents, or transaction information generated, transferred, and/or stored between the client system and the user device.

The method of the present invention involves a user logging into an organizational or individual client system using a user device. Login-related information is hashed and/or encrypted through a single or multi-layered hashing and/or encryption process. In particular, at least a portion of the encrypted and/or hashed key may be generated and stored on the user's device. Other unique pieces of login-related information are stored on other devices in the environment. Distributing unique pieces of login-related information across multiple devices is necessary for a third party with access to information transferred between the client system and the user device to successfully log in to the client system. means that some or all of the relevant information cannot be obtained.

Further, in one aspect of current systems, in order to authenticate data, documents, devices, transactions, and/or users, the user device must have a valid key and/or the device has already been authenticated. to the client system. This is accomplished in the present invention without the user device revealing the key to the client system. Thus, data, documents, devices, transactions, and user authentication occur without the user revealing their keys to the client system.

Login-related information is uniquely created and not stored and/or sent. Together with user device assisted multi-point authentication, this prevents unauthorized access to the client system by third parties.

Because most prior art authentication systems involve creation, storage, transfer, and single point authentication of login-related information between a user device and a client system, prior art systems do not allow login-related information to be authenticated by a third party. Vulnerable to being compromised. Once login-related information has been obtained by a third party, that information may be used to log in without authentication at a single authentication point into the system network, or may be subject to unauthorized use of data, documents, or transactional information. may be used. The present invention differs from prior art systems in that it is not vulnerable to access to third party information that would allow unauthorized access to client systems or to data, documents or transaction information. provide a superior advantage. The authentication system of the present invention solves the problems of prior art authentication that can be compromised at the creation, storage, transfer, and authentication points.

An example of a further advantage of the present invention over prior art systems is that prior art systems generally cannot be operated with any type of client system or any type of user device. The present invention provides organizations with a secure authentication system that provides users with the secure access they need to access their data across any platform, solution, or environment. The present invention can be implemented by any organization for use with any type of client system and with any type of user device on any platform.

A further example of the advantages of the present invention over the prior art is that the present invention operates to perform hive authentication of devices within the environment. For example, multiple mobile devices and/or storage devices across geo-temporal zones may be authorized during the hive authentication process. Prior art systems are not operable to perform hive approvals across geo-temporal zones.

Embodiments of the present invention provide multiple authentication methods that operate to authenticate a user for the purpose of user login to a client system having a secure portion, or for the purpose of a user accessing a secure portion of such a system. may contain components. For example, one embodiment of the present invention may include three main components: (1) Synchronized Multi-Faceted Authentication (SMFA); (2) Interactive Semi-Automatic Authentication (SMFA); Manual Authentication (ISMA); and (3) Transaction Authentication. All three of these components of an embodiment of the invention are described below to provide an example of such an embodiment of the invention. A person skilled in the art will read that other configurations of the invention are possible, such as configurations that include only one or two of the three components described below, or that incorporate other components. would recognize

<Synchronized Multi-Faceted Authentication (SMFA)>
The authentication process for a user in the authentication methods and systems of the present invention operates such that an encrypted or hashed portion of random multi-unit login-related information is transferred to a device (e.g., user device and/or system device and storage units), and all or one or more of those devices are utilized to authenticate the user.

Therefore, encryption of time-sensitive random login-related information for unknown users should the login data be compromised during creation, transmission, storage, or authentication, such as unauthorized access by a third party. Or only a hashed portion is obtained and this data cannot be used to authenticate the user.

More specifically, the present invention is operable to require a user to perform a challenge to log into a client system, the challenge being, for example, a static challenge of pins and/or patterns, an animated and/or non-animated challenges, graphical and/or non-graphical challenges, two-dimensional and/or three-dimensional challenges, dynamic and/or static gamified challenges, and/or non-gamified interface challenges, etc. It is operable to require the user to make a challenge. The system may select a set of units and use them to generate a challenge. Each unit is randomly assigned multiple numbers, which may change with each login event. A user may select multiple challenges in the same authentication event and in any subsequent authentication event.

The sequence of units selected during the challenge is divided into multiple unique system parts by the authentication system. The units in each unit part may be individually hashed or encrypted to produce a unit result, and then the units in each system part are collectively hashed and/or encrypted to give the system part result. generated. The number of hashing and/or encryptions applied to each unit within a system portion and the number of hashing and/or encryptions applied to each system portion may vary.

Some of the hashed and/or encrypted results are stored on various devices in the client or other system's distributed architecture, and some are stored on the user's device. For example, some of the hashed and/or encrypted results may be stored on multiple user devices and system devices.

All client system devices and user devices that contain hashed and/or encrypted partial data must authorize themselves. Once the devices are authenticated, they may then co-authenticate the user.

The authentication system of the present invention is platform independent and can be used with any client system.

<Interactive Semi-Manual Authentication (ISMA)>
The authentication process for users of the present invention operates such that login information is encrypted and/or hashed using multiple layers of encryption and/or hash functions. Part of the random encryption and/or hashing details are hidden and manually transmitted and not stored within the client system or user device, thereby potentially compromising during transmission, storage, or authentication. Decrease.

The system of the present invention provides a key (ie, Key #1) to the mobile device. All keys of the present invention are encrypted and/or hashed using layered encryption and/or hash functions.

An encrypted key is required for use in the authentication process of the present invention, so the user first authenticates using the SMFA process described herein and thereby verifies the key. to authenticate the user's device.

The system generates challenges based on random encryption keys, which change with each login event. An authenticated user scans the challenge using an authenticated device. At the end of this process, some or all of the random encrypted keys are sent to the user device.

In some embodiments of the invention, there may be another set of encrypted random keys, which may be generated by the user device and changed for each login event. Multiple keys may be combined to form an encrypted shared secret. Part or all of the encrypted shared secret is sent to the client system of the organization requesting authentication of the user.

Multiple layers of encryption may be generated by the user device. Such encryption may be applied to elements individually or collectively. For example, a random 3 or more digit number (which may change during each login event) along with the salt and iv may be generated by the user device, or some other type of encryption and/or hashing may be applied. good. Another layer of encryption may be added en bloc to the previous encryption.

Multiple random characters are removed from the resulting package of multiple layers of encryption. For example, 6 random characters may be removed from the package. A plurality of random digits and characters are provided to the user and the encrypted details are sent to the client system requesting authentication of the user device.

A client system requesting authentication of a user device requests the user to provide information provided on the user device. Only when the user provides such information will the client system be able to authenticate the user. This process reduces the possibility of a third party intercepting, guessing, or learning a user's login information.

Once the user is authenticated, the session is authenticated with a temporal geobase access code. For example, the geo-based access code may be a token or any other type of geo-based access code. The geobase access code may be revoked if time has passed or if the geo aspect has been revoked. For example, a geoaspect may be disabled if the user is not located within the geolocation associated with the geobase access code.

<Transaction authentication>
The user authentication process of the authentication system of the present invention operates so that transactions are authenticated without the user revealing his key to the client system. The client system does not know the user's key, or the presence or absence of the user's key. The user device must prove to the system that it has a valid key and that the user and device are authenticated without exposing the key to the system. To accomplish this, the user device would need to authenticate using the SMFA process described herein and/or the ISMA process described herein. Once the user device is authenticated, the user device may use random temporary keys it has or has received.

The system will generate a security challenge. This challenge may be protected using features such as layered encryption, digital signatures, and/or hashing. The protected package is sent to the user device requesting authentication. The user device verifies the package and uses the decryption key provided to the display or resolves the challenge.

In one embodiment, an embodiment of the present invention may operate such that the system generates a plurality of random digit alphanumeric codes in which one or more digits are blank, and the correspondence to be filled in blanks. Alphabets or numbers are also sent to the user with the challenge in the ISMA process. For example, the system may generate multiple random digit alphanumeric codes of six digits or more, and may generate any other number of random digit alphanumeric codes.

The system generates and encrypts a six or more random digit alphanumeric code plus other elements. For example, the system may encrypt six or more random digit alphanumeric codes. Additional encryption and security features (including but not limited to salt, iv, secure key, etc.) may be applied by the client system. The system then adds a digital signature to the encryption result. This encrypted and signed package is sent to the user device requesting authentication.

The user device verifies the digital signature and uses the provided decryption key to recreate the six or more alphanumeric code along with the corresponding alphanumeric characters.

The user device then encrypts the reproduced information along with security features. The user device adds a digital signature to the encryption result. This encrypted and signed package is sent to the client system for authentication process.

A client system receives a message from a user device, and upon receiving the message, verifies the digital signature, decrypts the message, and compares it to the message sent. If the received message is the same as the sent message by comparison, the client system knows that the user has the required key. Once the user device is authenticated, the session is authenticated by temporal geo-based access codes, but these access codes may expire over time or when the geo expires, as previously described herein. become invalid.

A reader of ordinary skill in the art will appreciate that the method and system for authentication of the present invention can be implemented in a variety of ways. Figures 1-17 illustrate examples of some embodiments of the present invention and are described herein.

As shown in FIG. 1, the authentication system includes many elements including a client system, a user system, a verification system, and multiple storage units. An authentication system is operable to perform many functions such as proving and verifying a user's login.

User system 102 is used by a user to log into client system 902 . The user system is operable to verify the user's identity and participate in other actions as described herein. In order for a user to gain access to a protected area of the client system, the user's identity must be verified by the client system. Verification system 202 is operable to engage in verification of a user's identity to a client system.

When a user wishes to access the secure area of a client system via user device 90, the user must first prove his or her identity to the client system. Once the client system receives proof of the user's identity, the system can then authorize the user to access protected content on the client system.

A user uses the user system to prove his identity and gain access to the secure area of the client system. Verification system 202 is operable to verify the authenticity of a user's identity. Synchronization system 300 is a collection of one or more synchronization elements 302A...302N that operate to work synchronously to authenticate the authenticity of a user's identity.

A user system may include multiple elements. In one embodiment of the invention, the user system may include an authentication unit 104 , a display unit 106 , a processing unit 108 , an authorization unit 112 , a storage unit 110 and a communication unit 114 . The proving unit is operable to prove the initial identity of user system 102 to the verification system. The display unit is operable for displaying information to the user, for example challenges or other information transferred to the user system from the client system, the verification system or other systems or elements of the invention. The display unit is further operable to display information generated by the client system to the user. The display unit may also be connected to an input device, or may have a touch screen or other input operability, allowing the user to enter information. The information entered by the user may be displayed on the display unit, or otherwise collected and stored by the user system, transferred to the client system or another system or element of the authentication system, or may be processed by the system. Processing unit 108 is responsible for all of the processing power in the system. The approval unit 112 is responsible for accessing challenges and responses and providing results, and the storage unit is responsible for storing both temporary and permanent data. Communication unit 114 is responsible for all external communications.

Verification system 202 may include multiple elements. In one embodiment of the invention, the verification system includes a masker unit 204, an N-packet generator 206, a report generator 208, a processing unit 210, an approval unit 212, one or more storage units 214A...214N. , and communication unit 216 . The masker unit operates to generate one or more unique non-identifying identifiers for client systems and user systems. Processing unit 210 operates to process information and data as required by the authentication system. Approval unit 212 operates to access responses received within the system and provide results that are sent to a processing unit or via a communication unit to a recipient external to the system. One or more storage units operate to store both temporary and permanent data. The N-packet generator 206 operates to generate packets of authentication information. Communications unit 216 operates to receive and forward all communications with all elements of the authentication system external to the verification system (ie, client systems, user systems, etc.).

As one skilled in the art will read, in embodiments of the invention some or all of the units described as elements of the verification system of FIG. 1 may be included within other systems or elements of an authentication system, such as a client system. you will recognize that you may In some embodiments of the invention, some or all of the units described as elements of the verification system of FIG. 1 may be stand-alone elements and not included in any system of the authentication system. , may generally be included in the authentication system.

Synchronization system 300 may include one or more synchronization elements 302A...302N, and each synchronization element may include multiple units. In one embodiment of the invention, the at least two synchronization elements are certification units 304A...304N, storage units 308A...308N, processing units 306A...306N, authorization units 312A...312N, and communication units. 310A...310N. Proof unit 304 A operates to prove the initial identity of synchronization system 300 to verification system 202 .

Communications between user systems, verification systems and synchronization elements are received by and forwarded from communication units of such systems and/or elements. All such communications between systems and/or elements may be protected through the use of one or more masking functions, which may include hashing and/or encryption.

As shown in FIG. 2, data may be transferred between the client system 902 and the verification system's masker unit 204 via the verification system's communication unit 216 . During initial communication between a client system and a verification system associated with setting up a new user wishing to use the client system, the client system communicates with the verification system's masker unit to establish a secure connection with the client system. It may request the credentials required of the new user to establish. The masker unit generates a unique protected credential that the client system uses to establish a link between the client system and the verification system. These unique credentials may include, for example, client IDs, or other forms of credentials.

Once a trusted connection is established between the client system and the verification system, the masker unit performs a computation, algorithm, or other type of process to generate a unique non-identifying identifier that is secret to the user. do. The unique non-specific identifier may be stored in one of the storage units 214A (or any of the storage units 214A...214N) included in the verification system.

The masker unit may use hashing, encryption, or some other masking function to secure the non-identifying identifier. The client system may also provide the verification system with a list of all available synchronization elements. In embodiments of the present invention, one or more of the synchronization elements may be stored in one or more of the storage units 214A...214N of the verification system.

As shown in FIG. 3, the registration process of the present invention may include the operation of elements of the authentication system required during the initial interaction between the user and the authentication system in order for the user to register with the client system. All communication between the client system, the user system elements, the verification system elements, and the synchronization system elements is through the communication units of the user system, the verification system, and the synchronization system, as shown in FIG. A user must be registered with the client system in order to be granted access to the secure portion of the client system. During initial registration, the certification unit 104 accesses one or more storage units 110 of the client system to obtain certification information. Credentials may include a non-identifying identifier generated by the masker unit, a secret generated by the masker unit, and information that may identify the user device and/or a unique application number or, for example, biometric information (e.g., user's fingerprint, retinal scan of the user, or other biometric information of the user) and other information related to the user, such as usage information. Once the certification unit has obtained all of the certification information, the certification information may be stored in one or more storage units of the user system.

The certification information obtained by the certification unit 104 is securely sent to the processing unit 210 of the verification system via the communication unit 114 of the user system. The processing unit 210 obtains the user's information from one or more storage units 214A...214N of the verification system via the communication unit 216 of the verification system. The processing unit 210 combines information received from the client system with information obtained from one or more storage units of the verification system to create a package of information. The processing unit sends such information packages to approval unit 212 .

The approval unit 212 compares the value of the information package received from the processing unit with the information previously received from the client system and stored in one or more storage units 214A...214N of the verification system. If the comparison succeeds, the approval unit accepts the connection with the user system. If the comparison is unsuccessful, the approval unit 212 rejects the connection with the user system. The results of the approval system are sent to N-Packet Generator 206 .

If the connection with the user's system is not approved, the authentication system's attempts to enroll the user are terminated. In one embodiment of the invention, the N-packet generator generates a random challenge when a connection with the user system is approved. A random challenge may include multiple packets (N-packets). Each N packet contains multiple random numbers or alphanumeric/other characters (N-RANC).

The N-packets are sent securely to the display unit 106 of the user system. Embodiments of the present invention apply multiple layers of protection, including but not limited to N-encryption, hashing and/or digital signatures, to determine the N - Protection may be applied to the packet, eg multiple layers of protection for both N-RNAC and N-packets before forwarding. In other embodiments of the present invention, N-packets could be generated by the user system or another system element, with or without N-RNAC. The user interacts with this element to generate OY packets.

A display unit 106 receives the N-packets and displays the information contained in the N-packets to the user. From the displayed N-packets, the user enters one or more N-packets, thereby selecting the N-RANC associated with the selected N-packets. For ease of reference, the N-packets selected by the user are referred to herein as Y-packets. The order of Y-packets selected by the user is preserved to be Ordered Y-packets (OY-packets). OY-packets are sent by the display unit 106 to the processing unit 108 of the user system. A processing unit in the user system splits the OY-packet into two or more parts. Each portion may contain more than one N-packet.

The processing unit of the user system may mask the information of the OY-packet by applying a masking function to each portion of the OY-packet. For example, the processing unit of the user system may select one or more of each of the N-RNAC contained in the OY-packet and/or each of the Y-packets contained in the OY-packet and/or each of the OY-packets. masking may be applied to One or more masking results may be stored in one or more storage units 110 of the user system. Results that are not stored are sent to the processing device of the verification system.

The challenge generated by the N-packet generator is sent to the display unit of the user system and contains multiple N-packets, each N-packet may contain more than two N-RANCs. A user may select multiple Y-packets to form an OY-packet. An OY packet may be split into two parts: OYA-part and OYB-part.

A processing unit of the verification system applies hashing and/or encryption and selects two or more random synchronization elements of the synchronization system from a list stored in one or more storage units of the verification system. good too. The selected random synchronization elements form a synchronization registry. The processing units of the verification system may individually or collectively add secrets to the OY-packet portions and individually and/or collectively perform multi-layered hashing and/or encryption functions on the OY-packet portions. . The hashed and/or encrypted unique OY-packet part is then distributed among one or more synchronization elements, and one or more of the one or more synchronization elements to which the OY-packet part is distributed. storage unit. As a result, unique OY-packet parts are stored in various synchronization elements. The distributed pieces of information may be stored in the synchronization registry of the synchronization element.

As shown in FIG. 4, the authentication system may operate to perform an access process for a user to gain access to the secure portion of the client system, whereby registered users are Attempts to authenticate itself through behavior. All communications between the elements of the user system, the elements of the verification system, and the elements of the synchronization system are as shown in FIG. through the communication unit of the synchronous element. The user system's certification unit 104 accesses one or more of the user system's storage units 110 to obtain certification information. Credentials may include non-identifying identifiers and secrets.

Part or all of the certification information obtained by the certification unit is securely sent from the communication unit 114 of the user system to the processing unit 210 of the verification system via the communication unit 216 of the verification system. The processing unit 210 obtains information for the user from one or more of the storage units 214A...214N of the verification system. The processing unit 210 combines information received from the client system with information obtained from one or more storage units of the verification system to create a package of information. The processing unit sends this information package to the approval unit 212 of the verification system.

Approval unit 212 compares the value of the information package received from processing unit 210 with information previously received from the client system and stored in the verification system. If the comparison is successful (ie the comparison results in a match between the compared information), the approval unit accepts the connection with the user system. If the comparison is unsuccessful, the Approval Unit rejects the connection with the user system. The results of the approval system are sent to N-Packet Generator 206 .

If the connection with the user's system is not approved, the authentication system's attempts to enroll the user are terminated. If the connection with the user system is approved, the N-Packet Generator generates a random challenge. A random challenge may include two or more packets (N-packets). Each N-packet also contains two or more random numbers or alphanumeric characters (N-RANC). Multiple layers of hashing and/or encryption may be applied to the challenge sent to the display unit. Hashing and/or encryption may be applied using a random number generator.

The N-packets are sent securely to the display unit 106 of the user system. Embodiments of the present invention may apply multiple layers of hashing and/or encryption to protect N-packets in transit between the N-packet generator and the display unit. For example, multiple layers of hashing and/or encryption may include hashing and/or encrypting N-RNACs and/or N-packets prior to transmission. The display unit 106 receives the N-packets and displays corresponding information to the user. From the displayed correspondence information, the user selects two or more correspondence information, selects an N-packet, and the N-RANC is associated with the selected N-bracket. For ease of reference, the N-packets selected by the user are here Y-packets, and these Y-packets are ordered and referred to as OY-packets.

In another embodiment of the invention, the N-packet generator may reside in the user system or other system, which may include any element from the user system or other system, such as a camera, scanner, etc. A Y packet and/or an OY packet may be generated by interaction with the user via.

The OY-packet is sent by the display unit 106 to the processing unit 108 of the user system. The processing unit of the user system divides the OY-packet into parts. Each part contains multiple N-packets.

The processing unit 108 of the user system retrieves previously stored OY-packet portions from one or more storage units of the user system. The storage unit contains such previously stored OY-packet parts. The processing unit sends the previously stored OY-packet part and the more recently created OY-packet part to the approval unit 110 of the user system. The user system's approval unit compares the information received from the user system's processing unit with the previously stored OY-packet portion to generate either an approval or a denial result. The results generated by the approval unit of the user system (either approval or rejection results) are forwarded to the processing unit of the user system. If the result from the authorization unit of the user system is a rejection result, the authentication process is stopped.

If the result of the approval unit of the user system is the approval result, the processing unit of the user system stores one or more OY packet parts of the newly generated OY packet parts in one or more storage units of the user system. may be stored, and the remaining OY packet portions are sent to the processing unit of the verification system. A processing unit of the verification system obtains synchronization system information from the synchronization registry for the user. A processing unit of the verification system may add a secret to received OY packet portions and perform multi-layer hashing and/or encryption functions on these OY packet portions. After hashing and/or encryption, the processing unit of the verification system sends the hashed and/or encrypted unique OY packet portion to one or more of the synchronization element processing units 302A...320N of the synchronization system. You can send Each processing unit of the synchronization element receives a unique hashed and/or encrypted OY packet portion from the processing unit 210 of the verification system. Each processing unit of the synchronization element that receives the hashed and/or encrypted OY packet portion may perform processing as shown in FIG. Synchronization element processing units 306A...306N may decode hashing and/or encryption to determine and identify one or more N-packets and N-RANC. The processing unit of a synchronization element may send N-packets and N-RANC to the acknowledgment units 312A...312N of the same synchronization element.

The verification units 304A...304N of the synchronization units retrieve previously stored hashed and/or encrypted OY-packet portions from the storage units 308A...308N of the synchronization elements. The attestation unit of the synchronization unit may decrypt hashing and/or encryption to determine and identify one or more N-packets and N-RANC, the N-packets and N-RANC being the synchronization element to the Approval Unit of The acknowledgment unit of the synchronization element compares the received recently generated N-packet and N-RANC with those previously stored. A pass or fail value is generated based on this comparison. The generated pass or fail value is forwarded to the certification unit of the synchronization element.

A certification unit of the synchronization unit obtains certification information from one or more storage units of the synchronization unit, and hashes and/or encrypts both the certification information and the pass or fail values received by the certification unit. , may be sent to the processing unit of the verification system.

A processing unit of the verification system receives the hashed and/or encrypted result and proof information from the proof unit of each synchronization element that generated the information. To clarify, multiple synchronization elements may receive a unique OY-packet portion, and each of those synchronization elements will process the OY-packet portion according to the methods described herein. All communication between the user system elements, the verification system elements and the client system elements is through communication units in the user system, the client system and the verification system, as shown in FIG. 6, processing unit 210 of verification system 202 decrypts the certification information received from each synchronization element 302A . . . 302N and sends the decrypted information to approval unit 212 of verification system. The processing unit 210 of the verification system obtains the certification information from one or more storage units 214A...214N of the verification system. The processing unit of the verification system sends the obtained certification information to the approval unit of the verification system. An approval unit of the validation system approves the synchronization element using the received information.

A processing unit of the verification system decodes each pass and/or fail value received from the synchronization element. The decrypted values are stored as verification results in one or more storage units of the verification system. A verification results report may be generated by a processing unit or report generator 208 of the verification system, which reports various information such as total synchronization elements requested, number of pass values received, number of fail values received, and so on. number, confidence score of the synchronization system, and other information.

The processing unit of the verification system may hash or encrypt the verification result and send the hashed and/or encrypted verification result to the processing unit 108 of the user system 102 via the communication unit 216 of the verification system. . The user system's processing unit sends the hashed or encrypted verification result to the client system 902 . The client system sends an authentication request to the processing unit 210 of the verification system via the communication unit 216 of the verification system based on the verification result received by the client system. A processing unit of the verification system obtains verification results stored in one or more storage units of the verification system and sends the obtained verification results to an approval unit of the verification system. An approval unit of the verification system may review the obtained verification results, approve them and send the verification results to the client system. The client system decides whether to authenticate the user based on the results of the verification report.

After a user has been authenticated and granted access to the secure portion of the client system, the user may access information (i.e., data, documents, transaction information, etc.) and/or user information (i.e., text, data, etc.). etc.) can be provided to the client system. In one example, a user accesses a client system to send a message, make a purchase involving credit card payment, attach an electronic signature to a document, or for various other purposes. you can During the course of interaction between the user and the client system with the user system, user information is passed between the client system and the user system. The present invention operates to protect security during creation, transfer, storage and authentication of such user information and authentication related information.

To achieve such security, embodiments of the invention may include user systems, client systems, client display units, and verification systems. A user system may be included in whole or in part in a client device, which is utilized by a user to communicate with and access the client system. Those skilled in the art will read that embodiments of the present invention achieve security of user authentication related information transferred between a user device and a client system, and may include other factors. will recognize.

The user validates the user system and user credentials against the client system using the user device. User credentials and the user's system need to be verified to ensure that the user is authorized to access the secure portion of the client system. A user will only be able to perform certain functions or access certain information through the secure portion of the client system if the user is authenticated. For example, a user would only be able to approve certain transactions via the client system if the user and the user system are authenticated. The client system is the system that the user is trying to access and therefore requires authentication to be performed. The verification system of the present invention verifies the identity of users and user systems and allows client systems to recognize users and user systems as authenticated as described herein.

As shown in FIG. 7, the user system 101 is used to transfer user information to and from client systems, and may include multiple elements. For example, one embodiment of the present invention provides a user system that incorporates dialogue unit 103, verifier generator 105, noise generator 107, processing unit 109, storage unit 111, and reader unit 113. may contain.

As shown in FIG. 8, the client system 130 of one embodiment of the invention may include multiple elements. For example, one embodiment of the present invention may include a client system in which CSAP generator 131, storage unit 133, processing unit 135, challenge generator 137, and approval unit 139 are incorporated.

As shown in FIG. 9, the client display unit 150 of one embodiment of the invention may include multiple elements. For example, embodiments of the present invention may include a client display unit in which interaction unit 151, processing unit 153, temporary storage unit 155, and key generator 157 are incorporated.

As shown in FIG. 10, the verification system 140 of one embodiment of the invention may include multiple elements. For example, embodiments of the present invention may include a verification system incorporating random key generator 141 , random text generator 143 , USID generator 145 and processing unit 147 .

When a user wishes to log into the secure portion of the client system, the user declares his intention by interacting with the client display unit and enters a request using the interaction unit of the client display unit. As shown in FIG. 11, the interaction unit 151 communicates the request to the processing unit 153 of the client display unit, which in turn communicates the request to the processing unit 147 of the verification system. The user system's processing unit 109 generates a request to generate an alpha key (αk) combo. The alpha key (αk) combo consists of αk1 and αk2 and is sent to the client display unit's key generator 157 via the verification system's processing unit 147 . The client display unit's key generator 157 sends both αk1 and αk2 to the verification system's processing unit 147 .

The verification system's processing unit 147 then requests random text from the verification system's random text generator 143 and requests a unique system event identifier (USID) from the verification system's USID generator 145 . The random text generator generates random text and sends it to the processing unit 147 of the verification system. The USID generator generates and sends a USID to the processing unit of the verification system. The USID generator operates to identify to the verification system the user device and event attempting to connect to the secure realm within the client system. The USID may be unique to each tab within one or more browsers and identifies and controls the number of browsers or tabs open for use by the user.

The processing unit 147 of the verification system combines the USID and random text received with αk2 into a data string, converts the data string into machine-readable form, and then sends it to the processing unit 153 of the client display unit. The dialog unit 151 of the client display unit makes this information available to the reader unit 113 of the user system.

As shown in FIG. 12, after the process of FIG. 11 has been completed, the information is available to the user system via reader unit 113 . Reader unit 113 may include one or more sensors including any of auditory, visual, tactile, print, motion, and other types of sensors. The sensors may be embedded in the client device, or they may be embedded external to the client device and connected via either wired or wireless connections. These sensors may be used to obtain information relevant to the user.

The reader unit 113 then sends the obtained information to the processing unit 109 of the user system. The processing unit of the user system may split the information received from the reader unit and retain the information. The user system's processing unit 109 requests noise from the user system's noise generator 107 . The noise generator generates noise and sends the noise to the processing unit of the user system. This noise is used to mask the identity of information in transit.

If the user has previously authenticated with the client system, the user system may have a random delta 1 key (δk1).

The processing unit of the user system sends αk2 and δk1 to the verifier generator 105 of the user system. The processing unit also sends a request to the user system's verifier generator to generate a new beta key. In response to this request, the verifier generator generates beta key 1 (βk1) and beta key 2 (βk2) using αk2 and δk1. Verifier generator 105 sends βk1 and βk2 to processing unit 109 of the user system.

The processing unit of the user system further accesses the storage unit 111 of the user system to request generation of a delta 1 key and/or session code and/or session code. The storage unit 111 provides the delta 1 key to the processing unit of the user system or generates a session code and provides it to the processing unit of the user system. For example, the user system's processing unit 109 may request that the verification system's random key generator 141 generate a random delta 1 key and/or session code and provide it to the processing unit 109; The processing unit 109 may generate a hash value for the provided δk1 or SC.

The user system's processing unit may use information obtained from each of the noise generator, the user system's storage unit, and the verifier generator to generate a manual interaction code (MIC). The user system's processing unit may send the MIC to the user system's interaction unit 103 . The interaction unit 103 of the client display unit displays the MIC to the user.

When the MIC is generated, there is residual data ("post-MIC data"). A processing unit in the user system may perform symmetric or asymmetric encryption on post-MIC data. The user system's processing unit may send the post-MIC data and the hash value to the client system's processing unit 135 .

The user system's processing unit may send the post-MIC data and the hash value to the client system's processing unit 135 . The client system's processing unit 135 sends the hash value, which is temporarily stored in the client system's storage unit 133 . Post-MIC data is sent to the processing unit 153 of the client display unit.

The processing unit 153 of the client display unit combines αk1 and post-MIC data into a package and sends the package to the key generator 157 of the client display unit. The processing unit 153 requests the key generator 157 of the client display unit to generate a gamma key (γK). γK is sent to the client display unit's processing unit 153 by the client display unit's key generator 157 .

The user is then required to interact with the interaction unit 151 of the client display unit. The user must manually enter the MIC. Once entered, the MIC is then sent by the interaction unit of the client display unit to the processing unit 153 of the client display unit. Processing unit 153 uses γK, MIC, and packages to enable SC or δk1. The processing unit of the client display unit computes the hash value of SC or δk1 and sends the hash value to the approval unit 139 of the client system for verification.

Any information received or generated by the client display unit's processing unit may be temporarily stored in the client display unit's temporary storage unit 155 at any point during processing operations of the client display unit's processing unit 153 . good.

The processing unit 135 of the client system obtains the hash value temporarily stored in the storage unit 133 of the client system. The processing unit 135 of the client system sends either SC or the hash value of δk1 and the value retrieved from the storage unit to the approval unit 139 of the client system. Approval unit 139 compares the hash values to determine a match.

If the hash values match, the approval unit 139 communicates the match to the processing unit 135 of the client system.

As shown in FIG. 14, upon receiving this match confirmation, the processing unit 135 of the client system requests a Client Session Access Pass (CSAP) from the CSAP generator 131 . The CSAP generator 131 generates a CSAP, which is sent to the storage unit 133 of the client system for temporary storage. CSAP generator 131 also sends CSAPs to processing unit 147 of the verification system. Processing unit 147 of the verification system sends the CSAP to processing unit 153 of the client display unit. The processing unit 153 of the client display unit sends the CSAP to the processing unit 135 of the user system. The processing unit 135 of the user system sends the CSAP to the authorization unit 139 of the client system. The client system's approval unit verifies the CSAP. A processing unit of the user system receives notification of the confirmation and acts to authorize the user to access the secure portion of the client system.

If the client system authorization unit 139 determines that the values do not match, the user, user system and client display unit are not authenticated.

The client system's CSAP generator 131 may be used to periodically test conditions related to authentication of users, user systems, and client display units. This includes generating a CSAP, processing it by a processing unit of the client system, forwarding the CSAP to other processing units of the verification system, the user system, the client display unit, and the client according to the methods described herein. Storage of the CSAP in the storage unit of the system, the user system, and the client display unit. If the authorization unit of the client system determines that the authentication conditions are not satisfied for the CSAP, e.g., if the processing unit of the client system determines that the received CSAP and the stored CSAP do not match, the user, User device and client display unit authentication (ie, CSAP authentication) is revoked, and access to the secure area is terminated for the user, user device and client display unit.

CSAP conditions for authentication employed in embodiments of the present invention may include conditions related to any of dimensional, geo-temporal, machine learning artificial intelligence, behavioral, or other conditions.

In another embodiment of the invention, shown in FIG. 15, a user attempts to validate a transaction through access to the secure portion of the client system using the client display unit. The processing unit 153 of the client display unit sends a request to validate the transaction to the processing unit 135 of the client system. In response to the request, the client system's processing unit 135 sends a request to the client system's challenge generator 137 to generate a challenge. In response to this request, the client system's challenge generator 137 generates a challenge and also applies a hash value to the result of the challenge and stores the answer and/or hash value in the client system's storage unit 133 . you can The client system's challenge generator 137 sends a challenge to the client system's processing unit 135 .

Processing unit 135 of the client system may apply symmetric and/or asymmetric encryption to the challenge. The processing unit 135 sends the challenge to the processing unit 153 of the client display unit. The processing unit 153 of the client display unit may decrypt the challenge using the provided key and send the challenge to the interaction unit 151 of the client display unit. In one embodiment of the invention, the user may be required to interact with the interaction unit 151 of the client display unit to find the answer to the challenge. In another embodiment of the invention, the processing unit 153 of the client display unit may resolve the decrypted challenge.

When a user using the client display unit finds an answer to the challenge, the user's answer is sent to the processing unit 153 of the client display unit. The processing unit 153 of the client display unit may generate a hash value based on the user's answer, and the processing unit of the client display unit further applies either symmetric or asymmetric encryption to this hash value and/or answer. can be added. The result of processing by the processing unit of the client display unit (eg, hash value or encrypted hash value, or answer or encrypted answer) may be sent to the processing unit 135 of the client system. The client system's processing unit 135 may send a request to the client system's storage unit 133 to retrieve the stored answer and/or hash value. Upon this request, the storage unit 133 of the client system retrieves the stored answer and/or the stored hash value and sends the stored answer and/or the stored hash value to the client system. Send to processing unit 135 .

The processing unit 135 of the client system decrypts the encrypted hash value or answer and/or the unencrypted hash value received from the processing unit 153 of the client display unit. The processing unit 135 of the client system combines the hash value and/or answer (in unencrypted form) received from the processing unit 153 of the client display unit with the stored answer and/or hash value for authorization. to the approval unit 139 of the client system. The approval unit 139 of the client system compares the received answer with the stored answer and/or the received hash value with the stored hash value.

If the received answer and/or hash value matches the stored answer and/or hash value, the approval unit 139 sends confirmation of the match to the processing unit 135 of the client system. If the match is positive, the client system's processing unit 135 sends a match confirmation to the client system to confirm successful completion of the authentication of the transaction, and the client system thereby approves the transaction.

If the received answer and/or hash value do not match the stored answer and/or hash value, the approval unit 139 sends a notification of the mismatch to the processing unit 135 of the client system. The client system's processing unit sends the notification to the client system, notifying the client system not to authenticate the transaction.

In another embodiment of the invention, the processing unit of the verification system can perform the functions described for the processing unit of the client system with reference to FIG. In such embodiments of the invention, the challenge generator and approval unit may be included in either the client system or the verification system, the challenge generator and approval unit being the same as described according to FIG. It has the functions of a challenge generator 137 and an approval unit 139 .

Another embodiment of the invention in which a user attempts to validate a transaction using the user system is shown in FIG. In such an embodiment of the invention, the processing unit 109 of the user system sends a request to validate the transaction to the processing unit 135 of the client system. In response to the request, processing unit 135 of the client system sends a request to challenge generator 137 to generate a challenge. In response to this request, the challenge generator 137 generates a challenge and also applies a hash value to the challenge result (challenge answer) and stores the answer and/or hash value in the storage unit 133 of the client system. do.

Processing unit 135 of the client system may apply symmetric and/or asymmetric encryption to the challenge. Processing unit 135 sends the challenge, possibly encrypted, to processing unit 109 of the user system. The processing unit 109 of the user system decrypts the challenge if the challenge is encrypted and sends the challenge to the interaction unit 103 of the user system. In one embodiment of the invention, the user may be required to interact with the interaction unit 103 of the user system in order to find the answer to the challenge. In another embodiment of the invention, the processing unit 109 of the user system may resolve the decrypted challenge.

When the user finds an answer to the challenge, the user's answer is sent to the processing unit 109 of the user's system. The processing unit 109 of the user system may generate a hash value based on the user's answer, and the processing unit 109 of the user system further applies either symmetric or asymmetric encryption to this hash value and/or answer. good. The results of processing by processing unit 109 of the user system (eg, hash values or encrypted hash values and answers or encrypted answers) may be sent to processing unit 135 of the client system. The client system's processing unit 135 may send a request to the client system's storage unit 133 to retrieve the stored answer and/or hash value. Upon this request, the storage unit 133 of the client system retrieves the stored answer and/or the stored hash value and sends the stored answer and/or the stored hash value to the client system. Send to processing unit 135 .

The processing unit 135 of the client system decrypts the encrypted hash value or answer received from the processing unit 109 of the user system. The processing unit 135 of the client system passes the received hash value and answer (in unencrypted form) from the processing unit 109 of the user system and the stored answer and/or hash value to the client system for authorization. Send to approval unit 139 . The approval unit 139 of the client system compares the received answer with the stored answer and/or the received hash value with the stored hash value.

If the received answer matches the stored answer and/or the received hash value matches the stored hash value, the approval unit 139 sends confirmation of the match to the processing unit 135 of the client system. The client system's processing unit 135 sends a match confirmation to the client system to confirm that the transaction has been authenticated successfully.

If the received answer matches the stored answer and/or the received hash value matches the stored hash value, then approval unit 139 notifies the processing unit of the client system of the mismatch. send. The client system's processing unit sends the notification to the client system, notifying the client system not to authenticate the transaction.

In another embodiment of the invention, the processing unit of the verification system can perform the functions described for the processing unit of the client system with reference to FIG. In such embodiments of the invention, a challenge generator and approval unit may be included in either the client system or the verification system, the challenge generator and approval unit being the same as described according to FIG. It has the functions of a challenge generator 137 and an approval unit 139 .

A system and network for authentication comprises one or more first peers, one or more servers, and one or more second peers, each comprising at least a processor and a transceiver. you can Additionally, one or more of the first peers and one or more of the second peers may be individually equipped with memory. In some embodiments, each of the one or more first piers and the one or more second piers may comprise a display device. One or more servers may further comprise a database.

Each transceiver of the first peer, the second peer, and the server may be configured to send and receive information to and from an exogenous source. In some embodiments, the first peer may be configured to send and receive information to and from a server, and the server sends and receives information to and from both the first peer and the second peer. and the second peer may be configured to send and receive information to and from the server. The memory of the first and second peers and the database of the server may be configured to store information and enable retrieval of information. The display device may further comprise means for the user to interact with the display, eg for entering data, selecting characters, selecting objects.

The processor of the first peer, second peer or server may consist of a process migrator, a data manipulator, a data transformer, a process generator and a process verifier. The processing migrator is configured to migrate data from one component within the first peer, second peer, or server to another component within the first peer, second peer, or server. you can By way of example, and not limitation, the processing migrator may move data from a first peer's memory to a first peer's processor, or from a second peer's processor to a second peer's transceiver. may be configured. Data manipulators may be configured to manipulate data, for example, combine, split, split and recombine, reorder, and the like. By way of example, and not limitation, the first peer's data manipulator may or may be configured to split a plurality of character strings into a first part and a second part, and the server's data manipulator may divide the data into a first part and a second part. It may be configured to combine the one portion and the second portion of data to produce a single data packet.

The data converter may be configured to convert the first character string to a second character string, each of the first character string and the second character string having a length, configuration, or arrangement of any one or more of may be different. In some embodiments, the data converter may be configured to apply a hashing algorithm to the first character string. In other embodiments, the data converter may be configured to apply an encryption protocol to the first character string. In still other embodiments, the data converter may be configured to apply the decoding protocol to the first character string. Also in other embodiments, the data converter applies any combination of hashing algorithms, encryption protocols, decryption protocols, or other known methods of data conversion to the first character string to produce a second character string may be configured to generate

The process generator may be configured to generate data. In some embodiments, the data may consist of one or more character strings of any length and may consist of barcodes and the like. In some embodiments, data may be generated in either a random or systematic manner. The processing verifier may be configured to compare two or more pieces of data to determine if the pieces of data are the same or different. In some embodiments, the action verifier and the action generator are paired to determine if the first character string and the second character string are the same, and to determine whether the first character string and the second character string are identical. may be configured to generate a response based on the identity of the character strings of the .

Authentication methods may include a registration method 1700 and a user login method 2000 . In some embodiments, the registration method 1700 comprises: generating one or more keys; distributing the one or more keys; storing the one or more keys in a local database; and storing the plurality of keys in a server database. As illustrated in FIG. 17, registration method 1700 may further include communication between first peer 1701 , server 1750 and at least one second peer 1775 .

In some embodiments of registration method 1700 , server 1750 may receive registration request 1702 from first peer 1701 . Server 1750 may send data 1751 to first peer 1701 . Registration data 1751 may include any data required by registration method 1700 . In some embodiments, registration data 1751 may include client registration code 1703 . Client registration code 1703 may include one or more characters made up of letters, numbers, symbols, or any combination thereof, and may be generated by server 1750 . In another embodiment, the registration data includes user selection objects. In yet another embodiment, the registration data may consist of a combination of one or more of the client registration code 1703, user selection objects, and other data required for registration.

Registration method 1700 may further include generating server key 1705 and client key 1706 from user input 1704 . In some embodiments, server key 1705 and client key 1706 are used to generate registration key 1707 . In other embodiments, server key 1705 , client key 1706 and at least one client registration code 1703 are used to generate registration key 1707 . Other embodiments include various combinations of client key 1706 , server key 1705 and client registration code 1703 that are used to generate registration key 1707 . Some information, such as client key 1706 , client registration code 1703 , may be stored in memory 1708 of first peer 1701 . Additionally, the registration method 1700 may include transferring information from the first peer 1701 to the server 1750 . In some embodiments, registration key 1707 and server key 1705 are transferred to server 1750 .

Registration method 1700 may include receiving information from first peer 1701 at server 1750 . In some embodiments, information received at server 1750 may include registration key 1707 and server key 1705 . Server 1750 may generate recipient code 1752 . Additionally, server 1750 may generate sender code 1754 . Additionally, server 1750 may generate distribution code 1756 . Server key 1705 , recipient code 1752 and sender code 1754 may be used to generate distribution key 1753 . In some embodiments, distribution key 1753 may be generated from any one or more of server key 1705, recipient code 1752, sender code 1754, or any combination thereof. Some information, such as recipient code 1752 , distribution key 1753 , may be stored in database 1757 of server 1750 . Registration method 1700 may further include forwarding information from server 1750 to at least one second peer 1775 . In some embodiments, distribution key 1753 and distribution code 1756 are forwarded to at least one second peer 1775 .

Registration method 1700 may further include storing one or more keys in a local database. At least one second peer 1775 may receive information from the server 1750, as illustrated in FIG. In some embodiments, the information may include distribution key 1753 and distribution code 1756 . A second peer may generate a deposit code 1776 . Additionally, distribution key 1753 and escrow code 1776 may be used to generate escrow key 1777 . In some embodiments, escrow key 1777 may be generated using distribution key 1753 alone, escrow code 1776 alone, or any combination of distribution key 1753 and escrow code 1776 . For example, some information such as distribution key 1753 , escrow key 1777 , distribution code 1756 may be stored in memory 1758 of second peer device 1775 . Registration method 1700 may further include transferring information from second peer 1775 to server 1750 . In some embodiments, escrow key 1777 and distribution code 1756 are transferred to server 1750 .

Registration method 1700 may be configured to receive information from second peer 1775 and store the information in a local database. In some embodiments, server 1750 receives information from second peer 1775 . The received information may consist of a escrow key 1777 , a distribution code 1756 and other information necessary for storage of the information by server 1750 or for identification at second peer 1775 .

Referring now to FIG. 18, in some embodiments generating one or more keys 1800 may be performed at a first peer 1801 . The first peer 1801 can be any IoT device, i.e. any device that has the ability to connect to a network and send data, including mobile phones, personal assistants, buttons, home security systems, appliances, etc. are not limited to these. A first peer 1801 may request registration with a server 1850 . In some embodiments, server 1850 may send registration data to first peer 1801 . Registration data may be received by transceiver 1841 of first peer 1801 and may include any data necessary to generate one or more keys 1800 at first peer 1801 . In some embodiments, registration data may include client registration code 1803 . In other embodiments, registration data may include client registration code 1803 and additional data that serves as a precursor to user input 1804 . Client registration code 1803 may consist of one or more character strings of any length.

User input 1804 may include user-generated data, including discrete units of information, in any form. In some embodiments, user input 1804 includes biometric data, eg, fingerprint, iris, and the like. In those embodiments, the biometric data may be divided into discrete units of information containing identifiers. Identifiers may be converted to unique selection codes 1809 . In other embodiments, user input 1804 may include any number of spatial and/or temporal data. Spatial and/or temporal data may be divided into discrete units of information containing identifiers. Identifiers may be converted to unique selection codes 1809 . In yet another embodiment, user input 1804 may include a combination of biometric data and spatial and/or temporal data, each of which may be used to generate unique selection code 1809. .

In other embodiments, user input 1804 may include one or more selection objects. The one or more selection objects may be images, icons, tokens, buttons, or any other objects that allow the user to select one or more selection objects from a group of selection objects. In some embodiments, a selection object may be received at transceiver 1841 and processing migrator 1842 may migrate the selection object to display device 1843 . When selected by the user on display device 1843, the selection object may be converted to selection code 1809, which may consist of any number of characters, eg, letters, numbers, symbols. In particular embodiments, the selection object is an image and may be received from server 1850 . Each image is assigned a unique selection code 1809 . User selection of a combination of selection objects generates user input 1804 that includes a combination of selection codes 1809 that are unique to the selection of selection objects by the user. In some embodiments, any combination of biometric data, spatial and/or temporal data, and selection objects may constitute user input 1804 .

According to some embodiments, a user may generate user input 1804 that includes two or more selection codes 1809 . The number of selection codes is equal to n. Data manipulator 1844 may be configured to divide the selection code into two or more groups. In some embodiments, data manipulator 1844 may be configured to divide selected codes 1809 into first group 1810 and second group 1811 . The first group 1810 consists of 1 to n-1 selection codes 1809 and the second group 1811 consists of 1 to n-1 selection codes 1809 . Each selection code 1809 in the first group 1810 and the second group 1811 may be individually converted 1812 into one or more character strings by the data converter 1845, such that the first of the converted selection codes and a second group 1815 of transformed selection codes are obtained. In some embodiments, conversion 1812 may include using a hashing algorithm. In other embodiments, transformation 1812 may include using an encryption method. In still other embodiments, transformation 1812 may include using a combination of hashing algorithms and encryption methods. A first group 1813 of transformed selection codes may be used to generate a client pre-key 1814 . The individual transformed selection codes that make up first group 1813 of transformed selection codes may be combined by data manipulator 1844 to form one or more character strings that make up client prekey 1814 . In some embodiments, the individual transformed selection codes are combined through unit concatenation. Concatenation may involve using each of the individual transformed selection codes as one unit, or may involve using portions of the individual transformed selection codes as one unit. Client pre-key 1814 may be converted 1812 to client key 1806 by data converter 1845 . In some embodiments, conversion 1812 may include using a hashing algorithm. In other embodiments, transformation 1812 may include using an encryption method. In still other embodiments, transformation 1812 may include using a combination of hashing algorithms and encryption methods. Client key 1812 may be stored in memory 1808 of first peer 1801 by process migrator 1842 .

A second group 1815 of transformed selection codes may be used to generate a server prekey 1816 . The individual transformed selection codes that make up second group 1815 of transformed selection codes may be combined by data manipulator 1844 to form one or more character strings that make up server prekey 1816 . In some embodiments, individual transformed selection codes may be combined by concatenation of units. Concatenation may be using each of the individual transformed selection codes as a unit, or may be using portions of the individual transformed selection codes as units. Server pre-key 1816 may be converted 1812 to server key 1805 by data converter 1845 . In some embodiments, conversion 1812 may include using a hashing algorithm. In other embodiments, transformation 1812 may include using an encryption method. In still other embodiments, transformation 1812 may include using a combination of hashing algorithms and encryption methods.

In some embodiments, a registration key 1807 may be generated. Each of client key 1806 and server key 1805 is manipulated by data manipulator 1844 into client key first portion 1817, client key second portion 1818, server key first portion 1819, and server key second portion. It may be divided into portions 1820 . In some embodiments, client key 1806 may be split into more than two parts. Similarly, server key 1805 may be separated into more than two parts. Client key first portion 1817 and client key second portion 1818 may include different portions of the characters that make up client key 1806 . In particular embodiments, each of client key first portion 1817 and client key second portion 1818 may be half of the characters that make up client key 1806 . Server key first portion 1819 and server key second portion 1820 may include different portions of the characters that make up server key 1805 . In particular embodiments, each of server key first portion 1819 and server key second portion 1820 may be half of the characters that make up server key 1805 . Client key first portion 1817, client key second portion 1818, server key first portion 1819, and server key second portion 1820 are combined by data manipulator 1844 via a concatenation of units. may form one or more character strings that make up the first pre-key 1821 . The concatenation by data manipulator 1844 uses each of client key first part 1817, client key second part 1818, server key first part 1819, and server key second part 1820 as a unit. using pieces of client key first portion 1817, client key second portion 1818, server key first portion 1819, and server key second portion 1820 as a unit. may contain Further, concatenation may include using any combination of portions generated by splitting client key 1806 or server key 1805 . The first prekey 1821 may be converted 1812 by a data converter 1845 into one or more character strings that make up the second prekey 1822 . In some embodiments, conversion 1812 may include using a hashing algorithm. In other embodiments, transformation 1812 may include using an encryption method. In still other embodiments, transformation 1812 may include using a combination of hashing algorithms and encryption methods. A second pre-key 1822 may be used to generate a registration pre-key 1823 . In some embodiments, second prekey 1822 and client registration code 1803 may be concatenated by data manipulator 1844 to form one or more character strings that make up registration prekey 1823 . The concatenation may include using each of the second pre-key 1822 and the client registration code 1803 as a unit, and may include using pieces of the second pre-key 1822 and the client registration code 1803 as a unit. Registration prekey 1823 may be converted 1812 by data converter 1845 into one or more character strings that make up registration key 1807 . In some embodiments, conversion 1812 may include using a hashing algorithm. In other embodiments, transformation 1812 may include using an encryption method. In still other embodiments, transformation 1812 may include using a combination of hashing algorithms and encryption methods.

First peer 1801 may send information to server 1850 . In some embodiments, processing migrator 1842 of first peer 1801 may migrate registration key 1807 and server key 1805 to transceiver 1841 of first peer 1801 , where transceiver 1841 migrates registration key 1807 . and server key 1805 may be sent to server 1850 . In other embodiments, the transceiver 1841 of the first peer 1801 may send the registration key 1807, the server key 1805, and other information required for the registration method to the server 1850.

The registration method may further include distributing 1900 one or more keys. As illustrated in FIG. 19, transceiver 1941 of server 1950 may receive information from first peer 1901 . In some embodiments, transceiver 1941 of server 1950 may receive registration key 1907 from first peer 1901 . Transceiver 1941 of server 1950 may receive server key 1905 from first peer 1901 . Transceiver 1941 of server 1950 may receive both registration key 1907 and server key 1905 from first peer 1901 . Processing migrator 1942 may migrate registration key 1907 and server key 1905 to the processor of server 1950 . Registration key 1907 may be stored in database 1957 of server 1950 by process migrator 1942 . Process generator 1946 of server 1950 may generate a peer list 1958 . Peer list 1958 may include a list of peer devices on the network, eg, first peer 1901, second peer 1975, and so on. The peer list may also include recipient code 1952 and distribution code 1956, which may include one or more character strings of arbitrary length. Additionally, the processing generator 1946 of the server 1950 may generate a sender code 1954, which may also include one or more character strings of arbitrary length.

In some embodiments, server 1950 may receive registration key 1907 from first peer 1901 . Registration key 1907 may be used to generate any number of registration key subparts. A data manipulator may generate a registration key subpart from registration key 1907 . In these embodiments, registration key 1907 may contain any number of characters equal to n. Each registration key subpart may contain any number or combination of characters equal to n-1. Server 1950 may generate one or more random character strings. Each of the registration key subparts may be concatenated with one or more random character strings by data manipulator 1944 . In some embodiments, concatenated character strings may be transformed 1912 . Each of the generated concatenated character strings or converted concatenated character strings may be sent to one or more second peers 1975 .

Server 1950 may receive a server key 1908 from first peer 1901 . Server key 1908 may be used to generate any number of server key subparts. A data manipulator may generate a server key subpart from the server key 1908 . In these embodiments, server key 1908 may contain any number of characters equal to n. Each server key subpart may contain any combination of numbers or characters equal to n-1. Server 1950 may generate one or more random character strings. Each of the server key subparts may be concatenated with one or more random character strings by data manipulator 1944 . In some embodiments, concatenated character strings may be transformed 1912 . Each of the generated concatenated character strings or converted concatenated character strings may be sent to one or more second peers 1975 .

Data manipulator 1944 of server 1950 may combine any combination of server key 1905 , recipient code 1952 , sender code 1954 , distribution code 1956 , or registration key 1907 to generate distribution pre-key 1959 . In some embodiments, the distribution pre-key includes a server key 1905, a sender code 1954, and a recipient code 1952, which are combined by concatenation of units to form one or more character strings. good. The concatenation may include using each of the server key 1905, sender code 1954, and recipient code 1952 as a unit, using pieces of the server key 1905, sender code 1954, and recipient code 1952 as a unit. may include doing Distribution pre-key 1959 may be converted 1912 by a data converter into one or more character strings that make up distribution key 1953 . In some embodiments, conversion 1912 may include using a hashing algorithm. In other embodiments, transformation 1912 may include using an encryption method. In still other embodiments, transformation 1912 may include using a combination of hashing algorithms and encryption methods. Distribution key 1953 may be stored in database 1957 of server 1950 by process migrator 1942 . Server 1950 may be configured to send information to second peer 1975 . In some embodiments, processing migrator 1942 of server 1950 may migrate distribution key 1953 and distribution code 1956 to transceiver 1941 of server 1950 . In other embodiments, the transceiver 1941 of the server 1950 may send the distribution key 1953, the distribution code 1956, and other information required for the registration method to the second peer 1975. In some embodiments, server 1950 may store any combination of registration key 1907 , server key 1905 , and distribution key 1953 in database 1957 of server 1950 .

Server 1950 may generate two or more distribution keys 1953 and send data to two or more second peers 1975 . In some embodiments, peer list 1958 may include a list of two or more secondary peers 1975 on the network. A second peer may include any IoT device, server, or any device on the network that can send data to and receive data from server 1950 . Server 1950 may generate a unique distribution code 1956 for each second peer 1975 . Server 1950 may generate a unique recipient code 1952 for each second peer 1975 . In these embodiments, the distribution key 1953 generated for each second peer 1975 may be different than the distribution keys 1953 generated for other second peers 1975, but the first peer The underlying server key 1905 received from 1901 may be the same.

According to some embodiments, registration key 1907 may be used to generate distribution pre-key 1959 . In these embodiments, any combination of registration key 1907, sender code 1954, recipient code 1952, and server key 1905 may be used to generate distribution pre-key 1959.

Referring again to FIG. 17, registration method 1700 may include storing one or more keys in a local database. In some embodiments, the second peer 1775 may be configured to send and receive information with the server 1750 via the second peer's 1775 transceiver. Second peer 1775 may receive distribution key 1753 from server 1750 via second peer's 1775 transceiver. Second peer 1775 may receive distribution code 1756 from server 1750 . In some embodiments, second peer 1775 may receive distribution key 1753 and distribution code 1756 from server 1750 . Distribution key 1753 and distribution code 1756 may be stored in memory 1778 of second peer 1775 . A second peer 1775 may generate a escrow code 1776 . Escrow code 1776 may be a string of one or more characters of any length and may be randomly generated. Alternatively, escrow code 1776 may be generated by server 1750 and received by second peer 1775 . The escrow code 1776 and distribution key 1753 may be combined by concatenation of units to form one or more character strings that make up the escrow prekey 1779 . Concatenation may include using each of custody code 1776 and distribution key 1753 as a unit, and may include using pieces of custody code 1776 and distribution key 1753 as a unit. The escrow pre-key 1779 may be converted 1712 into one or more character strings that make up the escrow key 1777 . In some embodiments, conversion 1712 may include using a hashing algorithm. In other embodiments, transformation 1712 may include using an encryption method. In still other embodiments, transformation 1712 may involve using a combination of hashing algorithms and encryption methods. Escrow key 1777 may be stored in memory 1778 of second peer 1775 . In some embodiments, second peer 1775 may send escrow key 1777 and distribution code 1756 to server 1750 . In other embodiments, second peer 1775 may send escrow key 1777 , distribution code 1756 , and other information required for registration method 1700 to server 1750 .

Registration method 1700 may further include storing one or more keys in a server database. As shown in FIG. 19, transceiver 1941 of server 1950 may receive information from second peer 1975 . In some embodiments, transceiver 1941 of server 1950 may receive distribution code 1956 . In some embodiments, transceiver 1941 of server 1950 may receive escrow key 1977 . In other embodiments, transceiver 1941 of server 1950 may receive distribution code 1956 and escrow key 1977 . In yet another embodiment, transceiver 1941 of server 1950 may receive distribution code 1956, escrow key 1977, and other information necessary for the registration method. Distribution code 1956 and escrow key 1977 may be stored in database 1957 of server 1950 by process migrator 1942 .

In particular embodiments, the registration method 1700 comprises: creating one or more keys; distributing the one or more keys; storing the one or more keys in a local database; and storing the key of in a server database. As illustrated in FIG. 17, registration method 1700 may begin with registration request 1702 from first peer 1701 . Registration request 1702 may be sent to or received from one or more servers 1750 . One or more servers may send registration data 1751 to the first peer 1701 . Referring now to FIG. 18, in certain embodiments, first peer 1801 may receive registration data from server 1850 . Registration data may include a client registration code 1803 and one or more selection objects. Client registration code 1803 may include a single eight-digit character string. A selection object may include several images. In particular embodiments, the selection objects may include a number of selection objects equal to sixty. Each selection object may contain a unique selection code 1809 . Selection code 1809 may include one or more character strings, and in certain embodiments, each selection code may include a string of five characters. A user may select a number of selection objects from the selection objects received by server 1850 . In particular embodiments, a user may select six selection objects. Selection of selection objects by a user may generate user input 1804 consisting of a collection of selection codes 1809 that are selected by selecting the particular selection object associated with each selection code 1809. good. In particular embodiments, user input 1804 includes six five-character selection codes 1809 .

User inputs 1804 may be divided into first group 1810 and second group 1811 . In particular embodiments, first group 1810 and second group 1811 each include three different selection codes 1809 . Each selection code 1809 that makes up the first group 1810 and the second group 1811 may be converted 1812 into one or more character strings. In particular embodiments, each selection code 1809 may be transformed using a hashing algorithm to combine the first group 1813 of transformed selection codes and the second group 1815 of transformed selection codes. may contain. Each of the first group of transformed selection codes 1813 and the second group of transformed selection codes 1815 may be combined to generate a client pre-key 1814 and a server pre-key 1816, respectively. In certain embodiments, the three transformed selection codes that make up the first group of transformed selection codes 1813 may be concatenated to generate one or more character strings that make up the client prekey 1814. . Similarly, the three transformed selection codes that make up the second group of transformed selection codes 1815 may be concatenated to produce one or more character strings that make up the server's prekey 1816 . Client pre-key 1814 may be converted 1812 to client key 1806 and server pre-key 1816 to server key 1805 . In particular embodiments, conversion 1812 includes using a hashing algorithm.

Registration key 1807 may be generated using a combination of client key 1806 , server key 1805 and client registration code 1803 . In particular embodiments, client key 1806 is split into first portion 1817 and second portion 1818 and server key 1805 is split into first portion 1819 and second portion 1820 . First pre-key 1821 may be generated by concatenating any portion of client key 1806 and any portion of server key 1805 to form one or more character strings. The first prekey 1821 may be converted 1812 into one or more character strings that make up the second prekey 1822 . In particular embodiments, conversion 1812 includes using a hashing algorithm. Registration prekey 1823 may be generated by concatenating client registration code 1803 and second prekey 1822 to form one or more character strings. Registration pre-key 1823 may be converted to registration key 1807, and conversion 1812 may include using a hashing algorithm. In particular embodiments, client key 1806 and client registration code 1803 may be stored in memory 1808 of first peer 1801 . Additionally, server key 1805 and registration key 1807 may be sent to one or more servers 1850 .

Registration methods may include distributing one or more keys. In the particular embodiment shown in FIG. 19, server 1950 may receive registration key 1907 and server key 1905 from first peer 1901 . The registration key may be stored in database 1957 of server 1950 . Server 1950 may generate peer list 1958 containing a list of second peers 1975 on the network. For each second peer 1975 , server 1950 may generate recipient code 1952 and distribution code 1956 . In particular embodiments, recipient code 1952 and distribution code 1956 may be unique to both a particular second peer 1975 and a particular transaction. Additionally, the server 1950 may generate a sender code 1954 , and the sender code 1954 may be unique to a particular server 1950 . In certain embodiments, recipient code 1952 , sender code 1954 , and server key 1905 may be combined by concatenation to produce one or more character strings that make up distribution prekey 1959 . Distribution pre-key 1959 may be converted 1912 to distribution key 1953 . In particular embodiments, conversion 1912 may include using a hashing algorithm. In some embodiments, multiple unique distribution keys 1953 may be generated, each containing a different recipient code 1952 and having an associated different distribution code 1956 from peer list 1958 . Each unique distribution key 1953 may ultimately be sent to a different second peer 1975 . In certain embodiments, multiple unique distributed keys 1953 are generated from the same server key 1905 and each unique distributed key 1953 is sent to a separate second peer 1975 on the network.

The registration method may further include storing one or more keys in a local database, as illustrated in FIG. In particular embodiments, second peer 1775 may receive distribution key 1753 and distribution code 1756 from server 1750 . In this embodiment, the second peer 1775 may be one of a plurality of second peers 1775 in the network, and the same transaction between the first peer 1701 and the server 1750 as described above. receives a distribution key 1753 and a distribution code 1756 resulting from Second peer 1775 may store distribution key 1753 and distribution code 1756 in memory 1778 of second peer 1775 . Further, second peer 1775 may generate escrow code 1776 . In certain embodiments, escrow code 1776 includes a single string of eight characters. Escrow code 1776 and distribution key 1753 may be combined by concatenation to produce one or more character strings that make up escrow prekey 1779 . The escrow pre-key 1779 may be converted 1712 to a escrow key 1777 . In particular embodiments, conversion 1712 may include using a hashing algorithm. A second peer 1775 may send information to one or more servers 1750 . In certain embodiments, multiple second peers 1775 may send information to server 1750 . Information may include distribution code 1756 , escrow key 1777 , and any other information necessary to perform registration process 1700 .

Registration method 1700 may include storing one or more keys in a server database. In some embodiments, server 1750 may be configured to receive information from one or more secondary peers 1775 . In particular embodiments, server 1750 may receive information from a plurality of second peers 1775 including distribution code 1756 and escrow key 1777 . Server 1750 may store distribution code 1756 and escrow key 1777 in database 1757 . Referring to FIG. 19, distribution code 1956 and escrow key 1977 may be stored in peer list 1958 stored in database 1957 . In a particular embodiment, distribution code 1956 and escrow key 1977 are paired with stored distribution key 1953 and recipient code 1952, which includes first peer 1901, server 1950, and a particular second may be specific to transactions made with peers 1975 of

Authentication methods may include login methods, as shown in FIG. The login method 2000 may consist of creating one or more login keys, distributing one or more verification keys, verifying the verification keys in a local database, and activating the verification process. . Additionally, the login method 2000 may include communication between one or more first peers 2001 , one or more servers 2050 and one or more second peers 2075 .

Login method 2000 may include a first peer 2001, which may be configured to interact with a user. A first peer 2001 may make a login request 2002 and the login request 2002 may be sent to one or more servers 2050 . Server 2050 may receive login request 2002 and generate login data 2051 . In some embodiments, login data 2051 may constitute login salt 2024 . A login salt may include one or more characters consisting of letters, numbers, symbols, or any combination thereof. In some embodiments, login data 2051 may include user selection objects. In other embodiments, login data 2051 may include one or more login salts 2024 , user-selected objects, and any other data required by login method 2000 .

Generating one or more login keys may further include generating a server key 2005 and a client key 2006 from user input 2004 . In some embodiments, server key 2005 and client key 2006 may be used to generate login key 2099 . In other embodiments, server key 2005 , client key 2006 and at least login salt 2024 may be used to generate login key 2099 . In other embodiments, different combinations of client key 2006 , server key 2005 and login salt 2024 may be used to generate login key 2099 . Some information may be stored in the memory 2008 of the first peer 2001 , eg client key 2006 , login salt 2024 . Additionally, generating one or more login keys may include transferring information from first peer 2001 to server 2050 . In some embodiments, login key 2099 and server key 2005 are transferred to server 2050 .

Also, as shown in FIG. 20, distributing one or more verification keys may include receiving information from first peer 2001 at server 2050 . In some embodiments, information received at server 2050 may include login key 2099 and server key 2005 . Server 2050 may generate recipient code 2052 . Additionally, server 2050 may generate sender code 2054 . Additionally, server 2050 may generate distribution code 2056 . Server key 2005 , recipient code 2052 and sender code 2054 may be used to generate verification key 2062 . In some embodiments, verification key 2062 may be generated from one or more of server key 2005, recipient code 2052, verification salt 2024, or sender code 2054, or any combination thereof. Some information may be stored in database 2057 of server 2050, such as recipient code 2052, verification key 2062, and so on. In some embodiments, verification key 2062 may not be stored in database 2057 of server 2050 . Distributing multiple verification keys may further include forwarding information from server 2050 to at least one second peer 2075 . In some embodiments, verification key 2062 and distribution code 2056 are forwarded to at least one second peer 2075 .

Login method 2000 may further include verifying one or more verification keys on a local database. At least one second peer 2075 may receive information from the server 2050, as illustrated in FIG. In some embodiments, the information may include verification key 2062 and distribution code 2056 . In other embodiments, the information may include verification key 2062 , distribution code 2056 and verification salt 2063 . Second peer 2075 may use any combination of distribution code 2056 and verification key 2062 to locate and verify that the corresponding distribution key may be stored in memory 2078 of second peer 2075 . You can A stored distribution key may be used to generate a verification key 2081 . In some embodiments, stored distribution key 2053 and verification salt 2063 received from server 2050 may be used to generate verification key 2081 . Second peer 2075 may send information to server 2050 , which may include verification key 2081 , distribution code 2056 , and any combination of other information required by login method 2000 .

Enabling the verification process may include receiving information from second peer 2075 and comparing the received information to information stored in database 2057 of server 2050 . In some embodiments, server 2050 receives information from second peer 2075 . The information received may include verification keys 2081 , results, distribution codes 2056 and other information necessary for storage or comparison of information by server 2050 or for identifying second peer 2075 .

As shown in FIG. 21, generating 2100 one or more login keys may be performed at a first peer 2101 in some embodiments. The first peer 2101 can be any IoT device, i.e. any device that has the ability to connect to a network and send data, including mobile phones, personal assistants, buttons, home security systems, home appliances, etc. are not limited to these. First peer 2101 may request a login from server 2150 . In some embodiments, the transceiver of server 2150 may send login data to first peer 2101 . The login data may be received at the transceiver 2141 of the first peer 2101 and may include data necessary to initiate the login method at the first peer 2101 . In some embodiments, login data may constitute login salt 2124 . In other embodiments, login data may include login salt 2124 and additional data that serve as precursors to user input 2104 . Login salt 2124 may include one or more character strings of any length.

Also, as shown in FIG. 21, user input 2104 may include any form of user-generated data that constitutes discrete units of information. In some embodiments, user input 2104 includes biometric data, eg, fingerprint, iris, and the like. In those embodiments, the biometric data may be divided into discrete units of information containing identifiers. Identifiers may be converted to unique selection codes 2109 .

In other embodiments, user input 2104 may include one or more selection objects. The one or more selection objects may be images, icons, tokens, buttons, or any other objects that allow the user to select one or more selection objects from a group of selection objects. The selection object may be displayed on the display device 2143 of the first peer 2101 and may be converted to a selection code 2109 including any number of characters, eg, letters, numbers, symbols. In particular embodiments, the selection object is an image and may be received from server 2150 . Each image is assigned a unique selection code 2109, and user selection of a combination of selection objects generates user input 2104 that includes the combination of selection codes 2109, which combination corresponds to the user's selection of the selection object. Unique.

In some embodiments, a user may generate user input 2104 that includes two or more selection codes 2109 with the number of selection codes equal to n. Selection codes 2109 may be divided into first group 2110 and second group 2111 by data manipulator 2144 . Here, the first group 2110 includes 1 to n−1 selection codes 2109 and the second group 2111 includes 1 to n−1 selection codes 2109 . Each selection code 2109 of the first group 2110 and the second group 2111 may be individually converted 2112 into one or more character strings by the data converter 2145, such that the first of the converted selection codes A group 2113 and a second group 2115 of transformed selection codes are obtained. In some embodiments, conversion 2112 may include using a hashing algorithm. In other embodiments, conversion 2112 may include using cryptographic means. In still other embodiments, transformation 2112 may include using a combination of hashing algorithms and encryption methods. A first group 2113 of transformed selection codes may be used to generate a client pre-key 2114 . The individual transformed selection codes that make up the first group of transformed selection codes 2113 may be combined by data manipulator 2144 to form one or more character strings that make up client prekey 2114 . In some embodiments, individual transformed selection codes may be combined by concatenation of units. Concatenation may include using the transformed individual selection codes as units, and may include using portions of the transformed individual selection codes as units. Client pre-key 2114 may be converted 2112 to client key 2106 by data converter 2145 . In some embodiments, conversion 2112 may include using a hashing algorithm. In other embodiments, conversion 2112 may include using cryptographic means. In still other embodiments, transformation 2112 may include using a combination of hashing algorithms and encryption methods. Client key 2106 may be stored in memory unit 2108 of first peer 2101 by process migrator 2147 . The client key 2106 generated by the login method may be compared by the process verifier 2147 with the client key 2106 stored in the memory 2108 of the first peer 2101 during the identity registration process.

A second group 2115 of transformed selection codes may be used to generate a server pre-key 2116 . The individual transformed selection codes that make up the second group of transformed selection codes 2115 may be combined by data manipulator 2144 to form one or more character strings that make up server prekey 2116 . In some embodiments, individual transformed selection codes may be combined by concatenation of units. Concatenation may include using the transformed individual selection codes as units, and may include using portions of the transformed individual selection codes as units. Server pre-key 2116 may be converted 2112 to server key 2105 by data converter 2145 . In some embodiments, conversion 2112 may include using a hashing algorithm. In other embodiments, conversion 2112 may include using cryptographic means. In still other embodiments, transformation 2112 may include using a combination of hashing algorithms and encryption methods.

In some embodiments, a login key 2199 may be generated. Each of client key 2106 and server key 2105 is manipulated by data manipulator 2144 into client key first portion 2117, client key second portion 2118, server key first portion 2119, and server key second portion. It may be divided into portions 2120 . Client key first portion 2117 and client key second portion 2118 may include different portions of the characters that make up client key 2106 . In particular embodiments, each of client key first portion 2117 and client key second portion 2118 may be one half of client key 2106 . Server key first portion 2119 and server key second portion 2120 may include different portions of the characters that make up server key 2105 . In particular embodiments, each of server key first portion 2119 and server key second portion 2120 may be half of the characters that make up server key 2105 . Client key first portion 2117, client key second portion 2118, server key first portion 2119, and server key second portion 2120 are combined by data manipulator 2144 via concatenation of units. , one or more characters that make up the first pre-key 2121 may be formed. Concatenation may include using each of client key first portion 2117, client key second portion 2118, server key first portion 2119, and server key second portion 2120 as a unit. or, alternatively, using pieces of client key first portion 2117, client key second portion 2118, server key first portion 2119, and server key second portion 2120 as a unit. .

The first pre-key 2121 may be converted 2112 by a data converter 2145 into one or more character strings that make up the second pre-key 2122 . In some embodiments, conversion 2112 may include using a hashing algorithm. In other embodiments, conversion 2112 may include using cryptographic means. In still other embodiments, transformation 2112 may include using a combination of hashing algorithms and encryption methods. A second pre-key 2122 may be used to generate a registration pre-key 2123 . In some embodiments, second prekey 2122 and client registration code 2103 may be concatenated by data manipulator 2144 to form one or more character strings that make up registration prekey 2123 . The concatenation may include using each of the second pre-key 2122 and the client registration code 2103 as a unit, and may include using pieces of the second pre-key 2122 and the client registration code 2103 as a unit. Client registration code 2103 may be stored in memory 2108 of first peer 2101 during the registration process by process migrator 2142 . Registration pre-key 2123 may be converted 2112 by data converter 2144 into one or more character strings that make up registration key 2107 . In some embodiments, conversion 2112 may include using a hashing algorithm. In other embodiments, conversion 2112 may include using cryptographic means. In still other embodiments, transformation 2112 may include using a combination of hashing algorithms and encryption methods. In some embodiments, registration key 2107 may be the same registration key 1707 generated by first peer 1701 during registration method 1700 shown in FIG. Referring to FIG. 21, registration key 2107 may be used to generate login key 2199 . In some embodiments, registration key 2107 and login salt 2124 may be used to generate login key 2199 . Registration key 2107 and login salt 2024 may be concatenated by data manipulator 2144 to form one or more character strings that make up login prekey 2198 . Concatenation may include using each of the registration key 2107 and the login salt 2024 as a unit, and may include using pieces of the registration key 2107 and the login salt 2024 as a unit. A login pre-key 2198 may be used to generate a login key 2199 . In some embodiments, a login pre-key 2198 may be converted 2112 by a data converter 2145 into a login key 2199 . In some embodiments, conversion 2112 may include using a hashing algorithm. In other embodiments, conversion 2112 may include using cryptographic means. In still other embodiments, transformation 2112 may include using a combination of hashing algorithms and encryption methods.

First peer 2101 may send information to server 2150 . In some embodiments, transceiver 2141 of first peer 2101 may send login key 2199 and server key 2105 to server 2150 . According to other embodiments, the transceiver 2141 of the first peer 2101 may send the login key 2199, the server key 2105 and other information required for the login method to the server 2150.

The login method may further include distributing one or more verification keys. As illustrated in FIG. 22, server 2250 may receive information from first peer 2201 . In some embodiments, transceiver 2241 of server 2250 may receive login key 2299 from first peer 2201 . Transceiver 2241 of server 2250 may receive server key 2205 from first peer 2201 . Transceiver 2241 of server 2250 may receive both login key 2299 and server key 2205 from first peer 2201 . In some embodiments, server 2250 may generate comparison login key 2260 . Comparison login key 2260 may be generated by using registration key 2207 stored in database 2257 of server 2250 during the registration method. Processing migrator 2242 of server 2250 may migrate registration key 2207 and login salt 2224 from database 2257 . Data manipulator 2244 of server 2250 may combine registration key 2207 and login salt 2224 by concatenation to generate a comparison login pre-key. A comparison login pre-key may be converted 2112 by a data converter 2245 to a comparison login key 2260 . In some embodiments, conversion 2212 may include using a hashing algorithm. In other embodiments, transform 2212 may include using an encryption method. In still other embodiments, transformation 2212 may include using a combination of hashing algorithms and encryption methods. The transaction verifier 2247 of the server 2250 may compare the login key 2299 sent by the first peer 2201 with the comparison login key 2260 to determine whether communication with the first peer 2201 is allowed. .

Login key 2299 may be stored in database 2257 of server 2250 by process migrator 2242 . The server may use data migrator 2242 to access previously stored peer list 2258 . Stored peer list 2258 may include a list of peer devices on the network, eg, first peer 2201 , second peer 2275 . The peer list may also include recipient code 2252 and distribution code 2256, which may include one or more character strings of arbitrary length. Additionally, the processing generator 2246 of the server 2250 may generate a sender code 2254, which may also include one or more character strings of arbitrary length.

Data manipulator 2244 of server 2250 may combine any combination of server key 2205 , recipient code 2252 , sender code 2254 , distribution code 2256 , or login key 2299 to generate distribution pre-key 2259 . In some embodiments, distribution pre-key 2259 includes server key 2205, sender code 2254, and recipient code 2252, which are combined by concatenation of units to form one or more character strings. may be Concatenation may include using each of server key 2205, sender code 2254, and recipient code 2252 as a unit, including using parts of server key 2205, sender code 2254, and recipient code 2252 as a unit. OK. Distribution pre-key 2259 may be converted 2112 by data converter 2245 into one or more character strings that make up distribution key 2253 . In some embodiments, conversion 2212 may include using a hashing algorithm. In other embodiments, transform 2212 may include using an encryption method. In still other embodiments, transformation 2212 may include using a combination of hashing algorithms and encryption methods. Distribution key 2253 may be stored in database 2257 of server 2250 . Validation pre-key 2261 may be generated by data manipulator 2244 of server 2250 . In some embodiments, distribution key 2253 and verification salt 2263 generated by process generator 2246 of server 2250 and containing any number of characters may be concatenated to generate verification pre-key 2261 . A verification pre-key 2261 may be converted 2212 by a data converter 2245 into a verification key 2262 . In some embodiments, conversion 2212 may include using a hashing algorithm. In other embodiments, transform 2212 may include using an encryption method. In still other embodiments, transformation 2212 may include using a combination of hashing algorithms and encryption methods.

Server 2250 may be configured to send information to second peer 2275 . In some embodiments, transceiver 2241 of server 2250 may send verification key 2262 and distribution code 2256 to second peer 2275 . In other embodiments, transceiver 2241 of server 2250 may send verification key 2262 , distribution code 2256 , verification salt 2263 , and other information required for login method 2000 to second peer 2275 . In some embodiments, server 2250 may send any combination of distribution key 2253 , verification salt 2263 , and distribution code 2256 to second peer 2275 .

Server 2250 may generate one or more verification keys 2262 and send data to one or more second peers 2275 . In some embodiments, peer list 2258 may include a list of one or more secondary peers 2275 on the network. A second peer may include any IoT device, server, or any device on the network that can send and receive data from server 2250 . Server 2250 may generate a unique distribution code 2256 for each second peer 2275 . Server 2250 may generate a unique recipient code 2252 for each second peer 2275 . In these embodiments, the verification key 2262 generated for each second peer 2275 may be different than the verification keys 2262 generated for other second peers 2275, but the first peer The underlying server key 2205 received from 2201 may be the same. Verification key 2262 may or may not be stored in database 2257 of server 2250 .

Referring now to Figure 23, the login method may include verifying one or more login keys on a local database. In some embodiments, second peer 2375 may be configured to receive and send information to server 2350 . Transceiver 2341 of second peer 2375 may receive verification key 2362 from server 2350 . Transceiver 2341 of second peer 2375 may receive distribution code 2356 from server 2350 . In some embodiments, transceiver 2341 of second peer 2375 may receive verification key 2362 , distribution code 2356 , and verification salt 2363 from server 2350 . Distribution code 2356 may be compared by transaction verifier 2347 across all distribution codes 2356 stored in memory 2378 of second peer 2375 . If the distribution code 2356 received from the server 2350 is identical to the distribution code 2356 stored in the memory 2378 of the second peer 2375, the process generator 2346 of the second peer 2375 returns a positive result 2382 can be generated. If the distribution code 2356 received by the second peer 2375 is not identical to the distribution code 2356 stored in the memory 2378 of the second peer 2375, the processing generator 2346 of the second peer 2375 is negative. A result 2382 may be generated. In some embodiments, verification key 2362 is also used to verify the location of the same distribution code 2356 . If second peer 2375 determines that one or more distribution codes 2356 stored in memory 2378 of second peer 2375 are identical to distribution code 2356 received from server 2350, second peer 2375 Migrator 2342 may delete distribution key 2353 associated with matching distribution code 2356 from memory 2378 . The distribution key 2353 and verification salt 2363 deleted from the memory 2378 of the second peer 2375 may be used in the data manipulator 2344 to generate the verification pre-key 2380 by concatenation. The verification pre-key 2380 may be converted 2312 by a data converter 2345 into a verification key 2381 . In some embodiments, conversion 2312 may include using a hashing algorithm. In other embodiments, conversion 2312 may include using an encryption method. In still other embodiments, transformation 2312 may include using a combination of hashing algorithms and encryption methods.

In some embodiments, second peer 2375 may receive a distribution key and verification salt 2363 from server 2350 . Second peer 2375 may generate verification key 2362 at second peer 2375 by concatenating distribution key and verification salt 2363 to generate a verification pre-key. A verification pre-key may be converted 2312 to a verification key 2362 .

In some embodiments, second peer 2375 may generate comparison verification key 2383 . Second peer 2375 may generate comparison verification key 2383 by concatenating verification salt 2363 received from server 2350 and stored distribution key 2353 to generate a comparison verification pre-key. The comparison verification pre-key may be converted 2312 to a comparison verification key. In some embodiments, comparison verification key 2383 may be compared with received verification key 2362 by process verifier 2347 to produce result 2382 . In some embodiments, the result 2382 is generated by comparing the received distribution code 2356 with the stored distribution code 2356 with the result generated by comparing the verification key 2362 and the comparison verification key 2383 . and results obtained. Confirmation key 2381 may be generated from verification salt 2363 and escrow key 2377 obtained from memory 2378 of second peer 2375 . Escrow key 2377 and verification salt 2363 may be concatenated by data manipulator 2344 to generate verification pre-key 2380 . A confirmation pre-key 2380 may be converted 2312 to a confirmation key 2381 . Any combination of verification key 2381 , distribution code 2356 and result 2382 may be sent from second peer 2375 to server 2350 .

A second peer 2375 may be configured to send data to the server 2350 . In some embodiments, transceiver 2341 of second peer 2375 may send any combination of result 2382 , distribution code 2356 , and verification key 2381 to server 2350 . In some embodiments, second peer 2375 may be configured to delete all data associated with the transaction. In particular embodiments, second peer 2375 retrieves distribution code 2356, escrow key 2377, distribution key 2353, verification key 2362, verification salt 2326 from memory 2378 of second peer 2375 or processor of second peer 2375. , confirmation pre-key 2380, and confirmation key 2381 may be omitted. In some embodiments, deletion of data may occur concurrently with transmission of data to server 2350 . In other embodiments, deletion of data may occur after sending the data to server 2350 .

Referring now to FIG. 24, the login method may further include enabling verification process 2400 . Server 2450 may be configured to receive data from one or more secondary peers 2475 . In some embodiments, transceiver 2441 of server 2450 may receive any combination of verification key 2481 , result 2482 , and distribution code 2456 . Server 2450 may approve results 2482 received from second peer 2475 . If the result is positive, the processing verifier 2447 of the server 2450 compares the distribution code 2456 received from the second peer 2475 with all or part of the distribution code 2456 stored in the database 2457 of the server 2450. You can If the distribution code 2456 stored in the database 2457 of the server 2450 is identical to the distribution code 2456 received from the second peer 2475, then the processing migrator 2442 of the server 2450 converts the verification salt 2463 and the distribution code 2456 to Any combination with distribution key 2453 that may be associated and stored in database 2457 of server 2450 may be obtained. In some embodiments, the obtained distribution key 2453 may be the distribution key 2453 stored during the registration process. Obtained verification salt 2463 and obtained distribution key 2453 may be used by data manipulator 2444 to concatenate verification salt 2463 and distribution key 2453 to generate verification pre-key 2461 . Verification pre-key 2461 may be converted 2412 to verification key 2462 by data converter 2445 . In some embodiments, conversion 2412 may include using a hashing algorithm. In other embodiments, conversion 2412 may include using an encryption method. In still other embodiments, transformation 2412 may include using a combination of hashing algorithms and encryption methods.

Transaction verifier 2447 of server 2450 may compare generated verification key 2462 with verification key 2481 received from second peer 2475 , and transaction generator 2246 may generate authentication result 2464 . If verification key 2462 is identical to confirmation key 2481 received from second peer 2475, the result may be positive, eg, successful authentication. If verification key 2462 is not identical to verification key 2481 received from second peer 2475, authentication result 2464 may be negative, eg, authentication failure or threat. Processing migrator 2442 of server 2450 may store authentication result 2464 in database 2457 . In some embodiments, the authentication result 2464 is stored with the associated distribution key 2453 generated during the enrollment method.

Server 2450 may send new distribution key 2453 to one or more second peers 2475 . Referring to FIG. 19, server 1950 may create a new peer list 1958 in database 1957 of server 1950 . In some embodiments, server 1950 may assign any combination of new recipient code 1952 and new distribution code 1956, and use any combination of new recipient code 1952 and new distribution code 1956 to generate one Or a new distribution key 1953 may be generated in a manner that may be identical to distributing multiple distribution keys 1900 . The server 1950 may send the newly generated distribution key 1953 to a second peer 1975 that is different from the second peer 1975 that previously stored the distribution key 1953. good.

A web authentication method may include generating a barcode, generating one or more keys, and establishing a web session. Additionally, the web authentication system may include communication between one or more first devices, second devices, first servers, second servers, and Internet applications. One or more of the first device, second device, first server, and second server may include at least a processor and a transceiver. The one or more first devices and the one or more second devices may further include respective memories. In some embodiments, each of the one or more first devices and the one or more second devices may include a display. Each of the one or more first devices and the one or more second devices may include means for scanning barcodes. One or more of the first and second servers may further include a database.

The transmitters of the first device, the second device, the first server, and the second server may be configured to transmit information to and receive information from an external source. In some embodiments, a first device may be configured to send and receive information to and from any combination of a second device, a first server, and a second server. The first server and the second server may be configured to send and receive information to and from both the first device and the second device, the second device communicating with the first server, the first and any combination of the second server. The memory of the first and second devices and the database of the server may be configured to store information and enable retrieval of information. The display device may further include means for a user to interact with the display, eg, enter data, select characters, select objects, and the like. The Internet application may be configured to send or receive information from any combination of the first server, second server, first device and second device.

The processors of the first device, second device, first server, and second server may include process migrators, data manipulators, data transformers, process generators, and process verifiers. The process migrator migrates the first device, the second device, the first server, or the second device from a component in the first device, the second device, the first server, or the second server. It may be configured to migrate data to another component within the server. For example, without limitation, the processing migrator may move data from the memory of the first device to the processor of the first device, or from the processor of the second device to the transceiver of the second device. may be configured to move the The data manipulator may be configured to manipulate data, for example, to perform operations such as combining, separating, separating and recombining, reordering, and the like. For example, and without limitation, the data manipulator of the first device may be configured to divide the one or more character strings into a first portion and a second portion, and the data manipulator of the server may divide the data into a first portion and a second portion. It may be configured to combine the first portion and the second portion of data to produce one or more character strings.

The data converter may be configured to convert the first character string to a second character string, each of the first character string and the second character string having a length, configuration, or arrangement of any one or more of may be different. In some embodiments, the data converter may be configured to apply a hashing algorithm to the first character string. In other embodiments, the data converter may be configured to apply an encryption protocol to the first character string. In still other embodiments, the data converter may be configured to apply the decoding protocol to the first character string. In other embodiments, the data converter also applies any combination of hashing algorithms, encryption protocols, decryption protocols, or other known methods of data conversion to the first character string to convert the second character string. It may be configured to generate a string.

The process generator may be configured to generate data. In some embodiments, the data may consist of one or more character strings of any length and may consist of barcodes and the like. In some embodiments, data may be generated in a random or systematic manner. The processing verifier may be configured to compare two or more pieces of data to determine if the pieces of data are the same or different. In some embodiments, the action verifier and the action generator are paired to determine if the first character string and the second character string are the same, and to determine whether the first character string and the second character string are identical. may be configured to generate a response based on the identity of the character strings of the .

A web authentication method may include generating a barcode, as shown in FIG. Generation of barcode 2500 may be initiated at Internet application 2590 . In some embodiments, a user may initiate generation of barcode 2500 in Internet application 2590 with a login request. First agreed protocol pair 2646 may be generated by process generator 2646 . In some embodiments, first agreed protocol pair 2646 may be generated by process generator 2646 at internet application 2590 . First key agreement protocol pair 2526 may include any key agreement protocol pair commonly known to those of ordinary skill in the art. In some embodiments, the first key agreement protocol pair 2526 may include an Elliptic-curve Diffie-Hellman (ECDH) pair. According to some embodiments, Internet application 2590 may be configured to send information to first server 2525 . Processing migrator 2642 may transfer information to transceiver 2541 of Internet application 2590 . Internet application 2590 may send first public key 2503 , first private key 2504 , and any combination of other information necessary to generate barcode 2505 .

In some embodiments, first server 2525 may be configured to receive information from Internet application 2590 . Transceiver 2541 of first server 2525 receives first public key 2503, first private key 2504, and any combination of other necessary information for generating barcode 2500 from Internet application 2590. good. First server 2525 may generate random key 2527 , and random key 2527 may be generated by process generator 2646 of first server 2525 . Random key 2527 may include one or more character strings of any length, where characters may include letters, numbers, and symbols. In some embodiments, a barcode 2505 may be generated. Process generator 2546 may generate barcode 2505 using a barcode precursor. Barcode 2505 may comprise any type of barcode 2505, including without limitation, any linear barcode, two-dimensional barcode, or commonly known to those of ordinary skill in the art. Contains any type of readable indicia. In some embodiments, barcode 2505 may include a QR code®. Barcode 2505 may be generated from any combination of first public key 2503 , first private key 2504 , random key 2527 and other information necessary to generate barcode 2500 . In particular embodiments, barcode 2505 may be generated by data manipulator 2544 of first server 2525 and may be based on first public key 2503 and random key 2527 . First server 2525 may be configured to forward information to Internet application 2590 . In some embodiments, transceiver 2541 of first server 2525 may be configured to send information to Internet application 2590 . In certain embodiments, first server 2525 may send barcode 2505 to Internet application 2590 . Internet application 2590 may receive barcode 2505 at transceiver 2541 and may display barcode 2505 on display 2590 of Internet application 2590 .

A web authentication method may include generating one or more keys, as shown in FIGS. Referring to FIG. 26, generating one or more keys 2600 may include first device 2650 scanning barcode 2605 . Data manipulator 2644 of first device 2650 may generate random key 2627 , first public key 2603 , or random key 2627 and first public key 2603 from information contained within barcode 2605 . Data manipulator 2644 may extrapolate any information contained within barcode 2605 to generate one or more keys 2600 . Additionally, the process generator 2646 of the first device 2650 may generate a second key agreement protocol pair 2651 . Second key agreement protocol pair 2651 may include any key agreement protocol pair commonly known to those of ordinary skill in the art. In some embodiments, the second key agreement protocol pair 2651 may include an Elliptic Curve Diffie-Hellman (ECDH) pair. In some embodiments, second key agreement protocol pair 2651 may include second private key 2652 and second public key 2653 . Second private key 2652 and first public key 2603 extrapolated from barcode 2605 may be combined by data manipulator 2644 to generate private key 2654 . The process generator 2646 of the first device 2650 may generate any combination of salt 2655, initialization vector 2656, and number of iterations 2657. In particular embodiments, the process generator 2646 of the first device 2650 may generate each of the salt 2655, the initialization vector 2656, and the number of iterations 2657. Each of salt 2655, initialization vector 2656, and iteration number 2657 may include one or more character strings of any length, and characters may include any combination of letters, numbers, or symbols. The initialization vector 2656 may have a number of characters equal to n and may also include an IV first portion 2658 and an IV second portion 2659 . The first portion 2658 of the IV and the second portion 2659 of the IV may each be from 1 to n−1 characters. The number of repetitions 2657 may be a number of characters equal to n and may further include the first portion 2660 of IN and the second portion 2661 of IN. The IN first portion 2660 and the IN second portion 2661 may each be from 1 to n−1 characters. Data manipulator 2644 may generate IV first portion 2658 and IV second portion 2659 from initialization vector 2656 . Data manipulator 2644 may generate IN first portion 2660 and IN second portion 2661 from iteration number 2657 . According to some embodiments, private key 2654, salt 2655, IV first part 2658, and IN first part 2660 are converted by data transformer 2645 into masked private key 2662, masked The salt 2663, the masked IV first portion 2664, and the masked IN first portion 2665 may be converted respectively. In some embodiments, the initialization vector 2656 may be transformed into a masked IV first portion 2664 by a data transformer 2645 . Similarly, the iteration number 2657 may be converted 2612 by the data converter 2645 into the masked IN first portion 2665 . In some embodiments, conversion 2612 may include using a hashing algorithm. In other embodiments, conversion 2612 may include using an encryption method. In still other embodiments, transformation 2612 may include using a combination of hashing algorithms and encryption methods. In some embodiments, the number of iterations 2657 does not produce the first part of IN 2660 and the second part of IN 2661, but may be left as is, and the resulting first part of IN 2660 is transformed 2612 does not have to be done.

Process generator 2646 of first device 2650 may generate client key 2666 . Client key 2666 may include a string of one or more characters of any length, where characters may include any combination of letters, numbers, or symbols. In some embodiments, client key 2666 may be transformed 2612 by data transformer 2645 into first masked client key 2667 . In other embodiments, the client key 2667 may be transformed 2612 by a data transformer 2645 into a second masked client key 2668 . In yet another embodiment, the client key 2667 may be transformed 2612 by a data transformer 2645 into each of a first masked client key 2667 and a second masked client key 2668 . Transformation 2612 may include using a hashing algorithm. Additionally, transforming 2612 may include using cryptographic means. In some embodiments, conversion 2612 may include using a combination of hashing algorithms and encryption methods. First device 2650 may be configured to send information to first server 2625 . In some embodiments, transceiver 2641 of first device 2650 uses first masked client key 2667, second masked client key 2668, masked private key 2662, masked salt 2663. , masked IV first part 2664 , and masked IN first part 2665 , to the first server 2625 . In some embodiments, the first device 2650 may display each of the IV second portion 2659 and the IN second portion 2661 on the display 2669 of the first device 2650 . In certain embodiments, iteration number 2657 may be displayed in its entirety on display 2669 of first device 2650 .

Referring to FIG. 27, generating one or more keys may include first server 2725 receiving information from first device 2750 . In some embodiments, transceiver 2741 of first server 2725 uses masked private key 2762, second masked client key 2768, masked salt 2763, masked IV first part 2764 , the masked IN first portion 2765 , and the masked first masked client key 2767 may be received from the first device 2750 . In some embodiments, the processing migrator 2742 of the first server 2725 receives the masked private key 2762 from the first device 2750, the second masked client key 2768, the masked salt 2763, the masked one or more of masked IV first portion 2764, masked IN first portion 2765, and first masked client key 2767 are stored in database 2729 of first server 2725; good. According to particular embodiments, processing migrator 2742 of first server 2725 may store first masked client key 2767 in database 2729 of first server 2725 .

First server 2725 may be configured to send information to Internet application 2790 . In particular embodiments, the transceiver 2741 of the first server 2725 uses the masked private key 2762, the second masked client key 2768, the masked salt 2763, the masked IV first part 2764. , the masked IN first portion 2765 , and the first masked client key 2767 may be sent to the first server 2725 . In particular embodiments, the transceiver 2741 of the first server 2725 uses the masked private key 2762, the second masked client key 2768, the masked salt 2763, the masked IV first part 2764. , and the first portion 2765 of the masked IN may be sent to the first server 2725 . In another embodiment, the transceiver 2741 of the first server 2725 receives the masked private key 2762, the second masked client key 2768, the masked salt 2763, and the masked first part of the IV. 2764 (hereafter collectively referred to as “received data 2728”) may be sent to Internet application 2790 .

As illustrated in FIG. 28, generating one or more keys 2800 may include receiving data 2828 received by a transceiver 2841 of an Internet application 2890 from a first server 2825 . First device 2850 may include user input 2869 . This user input 2869 may include an IV second portion 2659 and an IN second portion 2661 (see FIG. 26), each of which may include a character string. User input 2869 may include the first portion of the IV and the number of iterations. In some embodiments, user input 2869 may be displayed on display 2869 of first device 2850 . Generating one or more keys may include user input 2869 being entered into Internet application 2890 . Data converter 2844 of internet application 2890 converts received data 2828 into one or more of private key 2854 , IN first part 2860 , salt 2855 , IV first part 2858 , and client key 2866 . 2812 may be converted. Transformation 2812 may include using a hashing algorithm. Additionally, transforming 2812 may include using an encryption method. Transforming may include using a decoding method. In some embodiments, transformation 2812 may include using any combination of hashing algorithms, encryption methods, or decryption methods. In some embodiments, data transformer 2844 of Internet application 2890 uses both user input 2869 and received data 2828 to convert private key 2854, first part of IN 2860, salt 2855, first part of IV. portion 2858 , and client key 2866 . Process migrator 2842 may store client key 2866 in storage 2891 of internet application 2890 . A data converter 2845 of the Internet application 2890 may convert 2812 the client key 2866 into a third masked client key 2892 . In some embodiments, third masked client key 2892 may be migrated to transceiver 2841 of internet application 2890 by process migrator 2842 . Transceiver 2841 of Internet application 2890 may send third masked client key 2892 to first server 2825 .

A web authentication method may include establishing a web session. As illustrated in FIG. 29, transceiver 2941 of first server 2825 may receive third masked client key 2992 from Internet application 2990 . In some embodiments, processing migrator 2942 of first server 2825 may retrieve stored first masked client key 2967 from database 2929 of first server 2825 . Processing verifier 2947 may compare obtained first masked client key 2967 with third masked client key 2992 received from internet application 2990 . Processing generator 2946 may generate result 2930 based on the identity of first masked client key 2967 and third masked client key 2992 . The transceiver 2941 of the first server 2825 may send the result 2930 to the second server 2980 . A transceiver 2941 of the second server 2980 may receive the result 2930 from the first server 2825 and generate a web token 2931 . Web token 2931 may be generated by transaction generator 2946 . In some embodiments, web token 2931 may be any means known in the art for authorizing the establishment of a web session. Second server 2980 may send generated web token 2931 to first server 2825 . The transceiver 2941 of the first server 2825 may receive the web token 2931 from the second server 2980 and send the received web token 2931 to the Internet application 2990 . Transceiver 2941 of Internet application 2990 may receive web token 2931 from first server 2825 .

In some embodiments, the Internet application may send the received web token to the second server. A second server may receive a web token from a web browser and establish a web session. Additionally, the second server may be configured to send information to the first server. In some embodiments, the second server may send information regarding receipt of web tokens from Internet applications. Information about receipt of web tokens from Internet applications may include any information about Internet applications, information about users of Internet applications, information about access to web sessions, location information about any component of the systems described herein. and/or temporal information. The first server may receive information from the second server regarding receipt of the web token. In some embodiments, the first server may be configured to send information to the first device, which may include, but is not limited to, information regarding receipt of the web token.

<Generate a key to protect confidential data>
Any method, system, component and/or embodiment disclosed appearing in any part of this specification may be applied to any other method, system, component and/or embodiment appearing in any other part of this specification. , components, and/or embodiments may be combined. Biometrics may be incorporated into any of the embodiments described herein as code, information, data, and the like.

In some embodiments, a key (eg, privacy key) may be generated to protect the content of sensitive data transmissions. For example, if the first data contains sensitive information, such as biometric data or confidential contact information, using controlled corruption to generate a key would allow the sensitive data (e.g., first data) to be exposed to a third party. can provide an elegant means that can protect against interception of Sensitive data (eg, first data) may include any number of data types, including, but not limited to, biometric data, documents, text messages, email messages, or other types of sensitive information. .

In some embodiments, systems and methods for generating keys (e.g., privacy keys) using controlled corruption are performed on one or more computing devices (e.g., first computing device, second computing device) , a third computing device, etc.) and one or more servers. One or more servers may comprise a security engine, an action engine, and one or more libraries. In some embodiments, one or more servers are client tiers in which one or more computing devices (e.g., first computing device, second computing device, etc.) include a mobile platform and one or more libraries. may be further provided. A computing device (e.g., first computing device, second computing device, etc.) may be any server or any IoT device, i.e., any device capable of connecting to a network and capable of transmitting data. , for example, without limitation, mobile phones, personal assistants, buttons, home security systems, appliances, and the like.

FIG. 30 is an exemplary system 3000 for generating keys using controlled corruption, according to certain embodiments. The system comprises a web tier 3010 comprising a first computing device 3012 , a management tier 3020 comprising one or more servers 3022 , and a client tier 3030 comprising one or more servers 3022 . System 3000 may additionally include one or more communication channels (eg, an Internet gateway, one or more virtual private network (VPN) tunnels) indicated by dashed lines.

The web tier 3010 includes the Managed Mobile Platform (AMP) 3014 comprising the Managed Mobile Libraries (AML) and the Partner Mobile Libraries (PML) and the Managed Web Platform (AWP) comprising the Managed Web Libraries (AWL) and the Partner Web Libraries (PWL). 3016 may further be included. Any library, as used herein, can mean, without limitation, any application, application database, database, and/or data.

The management layer 3020 may further comprise an administrative security engine (ASE) 3024, an action engine (AE) 3026, an administrative partner library (APL) 3028, and one or more nodes 3029 associated with the administrative layer. One or more nodes 3029 may be any of one or more databases, one or more user devices (eg, computing devices), or one or more databases and one or more user devices (eg, computing devices). Combinations may be provided.

The client tier 3030 may further comprise administrative client libraries (ACL) 3034 and client server applications (CSA) 3036 . In some embodiments, client tier 3030 and management tier 3020 may communicate with each other using a VPN tunnel.

FIG. 31 is an example of a server-side (eg, included in management layer 3020) method 3100 for generating keys using controlled corruption, according to certain embodiments, including one or more Registering 3140 a first computing device with a server; and receiving 3142 a first privacy code and one or more parameters associated with first data from the first computing device at one or more servers. generating 3143 the chunk count and public key at one or more servers; sending 3144 the chunk count and public key to a first computing device; Receiving 3146 a privacy key and a second privacy code, and generating 3148 second data based on the privacy keys at one or more servers.

Registering 3140 a computing device (eg, a first computing device) may include installing one or more applications on the computing device, where the one or more applications include the mobile platform and one or more libraries. and In some embodiments, a computing device and one or more applications may comprise a web layer of systems for generating privacy keys. A computing device may communicate (eg, network communication, Internet communication, virtual private network (VPN communication)) with one or more servers, which may constitute a management layer. A detailed description of various communication methods can be found in earlier sections of this specification. In some embodiments, registration of computing devices included in the web tier includes management tier (eg, ASE), client tier (eg, CSA), and web tier (eg, AML and/or AWL included in the computing device). ) to initiate communication and transmission of information.

One or more servers included in the management layer receive 3142 a first privacy code and one or more parameters associated with the first data from a computing device (eg, a first computing device). As noted above, the first data may include any data that the user wishes to protect during transmission (eg, biometric data, documents, messages, etc.). The one or more parameters associated with the first data may include any information about the first data, including, but not limited to, device identifier, camera identifier, file size, data format, application identifier, user identifier, personal May include identifiers, metadata, and the like. In some embodiments, the one or more parameters related to the first data are file size, a public key associated with an asymmetric cryptographic key pair (which may identify the origin of the first data), and a manipulation of the first data. zipped versions (eg, compressed or "zipped" versions of the data). In some embodiments, parameters associated with the first data may include a compressed (eg, zip-compressed) base 64 version of the first data. The privacy code may comprise an alphanumeric and/or symbolic character string associated with the user of the computing device or the source of the first data. In certain embodiments, the privacy code is the first user input including a personal identification number (eg, PIN) selected by the user of the computing device. The privacy code may be based on user input, such as an encrypted, hashed, chopped, or sorted version of the user input. In some embodiments, the privacy code may be automatically generated by a component of the system (eg, server, first computing device, etc.). In some embodiments, the privacy code may include and/or be based on the user's digital footprint. In these embodiments, the user's digital footprint may include information about the user's digital habits, including, but not limited to, browsing history, browsing time/duration/frequency, usage habits, application usage, purchase habits, geolocation Information data and the like may be included.

One or more servers included in the management layer may generate 3143 the chunk count, chunk name, and public key associated with the APL. The chunk count and chunk name may be based, at least in part, on the received parameters associated with the first data. The chunk count, in some embodiments, may be an integer that tells downstream processes to generate a privacy key. A chunk name is an alphanumeric and/or symbolic identifier that may be associated with one or more privacy keys generated in a downstream process. In some embodiments, the chunk count is based on parameters associated with the first data, such as the size of the first data, the size of the first data compressed, or converted to a base 64 file. based on one or more of the sizes of the first data compressed by the A chunk name may be generated based on the chunk count. For example, if the chunk count is an integer equal to 3, three chunk names will be generated, each designed to be associated with a downstream privacy key. In another example, if the generated chunk count equals 7, then 7 chunk names will be generated. In a downstream step, 7 privacy keys will be generated and each of the 7 privacy keys will be assigned a chunk name. A public key may be associated with an asymmetric cryptographic key pair associated with an APL contained in the management layer. The chunk count, chunk name, and public key may be sent from one or more servers included in the management tier to computing devices belonging to the web tier.

In some embodiments, a number of privacy keys (based on one or more of the first data, chunk count, chunk name, and privacy code) are sent to the web layer of the system for generating privacy keys. It may be generated by an included computing device. FIG. 32 is a computing device side illustration of a privacy key generation method 3200 according to some embodiments.

A computing device 3212 (e.g., a first computing device) included in the web tier of the system may receive chunk count 3260, chunk name 3261, and public key 3262 from one or more servers included in the management tier of the system. . As noted above, first data 3263 may include any data that the user has security in mind and wishes to protect during transfer. In some embodiments, computing device 3212 may compress (eg, zip) first data 3263 to generate compressed first data 3264 . The computing device 3212 may generate a compressed first data base 64 3265 , which may include a base 64 version of the compressed first data 3264 . Using controlled corruption (eg, controlled file corruption), the computing device 3212 adds a corruptor (eg, the first corruptor 3266) to the compressed first data base 64 3265. may generate a first prekey 3267 by . As noted above, corruptor 3266 may include alphanumeric and/or symbolic character strings. In certain embodiments, the first corruptor 3266 may be based on a formula. For example, the first corruptor 3266 may be generated by the computing device 3212 by combining the first 30 characters contained in the compressed first data base 64 3265 . In another particular embodiment, adding the first character and the third character contained in the compressed first data base 64 3265, the adding together the second and fourth characters, adding together the third and fifth characters contained in the compressed primary data base 64 3265, etc., and concatenating the results; A first corruptor 3266 may be generated by doing so to generate a string of characters contained in the first corruptor 3266 . Any number of formulas can be used to generate corruptors (eg, first corruptor 3266, second corruptor 3268, third corruptor 3273, etc.) and the possibilities are not limited to the examples above.

Computing device 3212 may generate second pre-key 3269 by attaching a corruptor (eg, second corruptor 3268 ) to first pre-key 3267 . In certain embodiments, the corruptor (eg, second corruptor 3268) may include one or more alphanumeric characters and/or symbols included in the privacy code entered by the user. In some embodiments, the corruptor (e.g., second corruptor 3268) includes one or more data included in the privacy code entered and manipulated (e.g., hashed, encrypted, reordered, truncated, etc.) by the user. alphanumeric characters and/or symbols. In certain embodiments, second corruptor 3268 may be based on a formula.

Computing device 3212 may generate salt 3270 and initialization vector (IV) 3271 . More information on salt 3270 and IV3271 can be found in earlier sections of this specification. Salt 3270 and IV 3271 may be added to second pre-key 3269 to generate third pre-key 3272 . Note that this addition (e.g., salt 3270 and IV 3271) is not always present when generating a privacy key, and in some embodiments, second pre-key 3269 is salt 3270, IV 3271, or third may be used to generate chunk 3274 based on chunk count 3260 without adding corruptor 3273 of .

A third corruptor 3273 may be attached to the third prekey 3272 . Third corruptor 3273 may be generated by computing device 3212 in any manner described above for corruptors (eg, first corruptor 3266, second corruptor 3268). In certain embodiments, the third corruptor 3273 may be based on a formula. In some embodiments, a third corruptor 3273 is added to the third prekey 3272 and then the resulting string is split into chunks 3274 based on the chunk count 3260 received from the management layer. good. As noted above, chunk count 3260 is an integer that indicates the number of chunks 3274 generated in key generation method 3200 . For example, if chunk count 3260 equals 3, then computing device 3212 divides the pre-key (eg, third pre-key 3272, second pre-key 3269, third pre-key 3272 with third corruptor 3273) into three It will be split into chunks 3274.

In some embodiments, third pre-key 3272 may be split into chunks 3274 , which may then be used to generate privacy key 3275 without using third corruptor 3273 . In some embodiments, the third prekey 3272 is split into chunks 3274 and one or more third corruptors 3273 (or first corruptors, second corruptors, etc.) are attached to the chunks 3274 to A privacy key may be generated.

Chunk 3274 may be named according to chunk name 3261 and privacy key 3275 may be generated. In some embodiments, the chunk name 3261 may be generated at the management tier and received at the computing device 3212 included in the web tier. Chunk name 3261 may be based, at least in part, on information received as part of the parameters associated with the first data (eg, initial package), as described above. In certain embodiments, the number of chunk names 3261 received is equal to chunk count 3260 . For example, if chunk count 3260 equals three, three chunk names 3261 will be generated at the management layer and received at computing device 3212 . Thus, in this embodiment, when three chunks 3274 are generated (based on chunk count 3260), each resulting chunk 3274 will have an associated chunk name 3261. In some embodiments, chunk 3274 is associated with a single chunk name 3261 to generate privacy key 3275 that includes chunk 3274 with chunk name 3261 . Chunk name 3261 is useful, according to these embodiments, in the downstream process of compiling privacy key 3275 for reproducing first data 3263 (eg, second data) on the server side.

To illustrate the above, the following example is provided. If the third prekey 3272 contains the string "123456789" and the third corruptor 3273 contains the string "543", the string resulting from the controlled corruption may contain the string "123455436789". If the chunk count 3260 equals 3 and the chunk names are "1", "2", and "3", the resulting privacy key contains:

Chunk name 3261 may facilitate downstream sequencing of privacy key 3275 to recreate the initial string in some embodiments. Here, the initial string "123455436789" can be reproduced on the server (eg, management layer) side by arranging the privacy keys 3275 according to the chunk names 3261 (eg, "one", "two", "three"). .

A computing device 3212 included in the web tier may send a number of privacy keys 3275 (equal to chunk count 3260) to one or more servers included in the management tier. Computing device 3212 may generate second privacy code 3277 based on first privacy code 3276 . Second privacy code 3277 may be an alphanumeric and/or symbolic character string in some embodiments. Second privacy code 3277 may be first privacy code 3276 that has been manipulated (eg, compressed, hashed, encrypted, reordered, truncated, etc.). In certain embodiments, second privacy code 3277 is hashed first privacy code 3276 . A privacy code (e.g., first privacy code 3276, second privacy code 3277) may be sent from a computing device 3212 included in the web tier of the system to one or more servers included in the administrative tier of the system. .

Returning to FIG. 31, the method of key generation using controlled corruption includes receiving 3146 a number of privacy keys and a second privacy code from a computing device, and generating second data based on the privacy keys. and performing 3148 .

FIG. 33 is a diagram illustrating a particular embodiment of generating second data based on privacy key 3300. As shown in FIG. The second data 3382 may include a reconstructed version of the first data in some embodiments. For example, the first data may originate from a computing device included in the web tier of the system. The first data may be used to generate a privacy key 3375, which may be a corrupted version of the first data, which version is then included in the management layer. It may be sent in corrupted chunks (eg, privacy keys) to multiple servers. Privacy key 3375 is concatenated to corruptors (e.g., first corruptor 3366, second corruptor 3368) such that resulting second data 3382 is a reconstructed version of the original first data. , third corruptor 3373, etc.) may be systematically removed.

One or more servers 3322 included in the administrative tier of the system receive a number (eg, one or more, two or more, three or more) of privacy keys 3375 from computing devices included in the web tier of the system. good. One or more servers 3322 may receive the second privacy code 3377 from the computing device. In some embodiments, one or more servers 3322 may concatenate a number (eg, one or more, two or more, three or more) of privacy keys 3375 to generate concatenated key 3376 . In some embodiments, chunk names 3361 may guide the process of concatenation, may determine the order in which privacy keys 3375 should be combined, or may be used to generate concatenated keys 3376, as described above. may indicate the arrangement of privacy keys 3375 in .

One or more servers 3322 remove the third corruptor 3373 to produce a first clean data 3377, remove the salt 3370 and IV 3371 to produce a second clean data 3378, and the second A corruptor 3368 may be removed to produce a third clean data 3379 and a first corruptor 3366 may be removed to produce a compressed second data base 64 file 3380 . In some embodiments, removal of corruptors may require recognition of the corruptor (eg, first corruptor 3366, second corruptor 3368, third corruptor 3373, etc.) that needs to be removed. In these embodiments, one or more servers may use various recognition tools to recognize corruptors. For example, if the corruptor was generated on a computing device using a privacy code (or a derivative of a privacy code, such as a truncated privacy code), one or more servers may use the received second privacy code A privacy code may be generated from 3377. In certain embodiments, a second privacy code 3377 is used to remove one or more corruptors (eg, first corruptor 3366, second corruptor 3368, third corruptor 3373, etc.). In some embodiments, one or more servers 3322 generate corruptors using a formula (e.g., the same formulas used to generate corruptors on computing devices) and generate newly generated corruptors is used to recognize and remove corruptors embedded in clean data (eg, first clean data 3377, second clean data 3378, third clean data 3379, etc.). A characteristic of one or more servers 3322 is the corruptor ( the ability to recognize and systematically remove first corruptor 3366, second corruptor 3368, third corruptor 3373, etc.) to produce compressed second data base 64 3380; is important. In some embodiments, concatenated key 3376 may be decrypted to produce first clean data 3377 .

The compressed second data base 64 3380 file may be converted (eg, decoded) into compressed second data 3381 . In some embodiments, compressed second data 3381 may be converted (eg, decompressed) to second data 3382 . As noted above, the second data 3382 may be a reconstructed version of the first data. For example, if the first data is information about a biometric scan, the second data would be a reconstructed version of the original information about the biometric scan. If the first data is confidential email, text, or other information, the second data is a reconstructed version of the confidential email, text, or other information. As such, those skilled in the art will appreciate that any method or operation performed by one or more servers included in the management tier may also be performed by a processor included in the second computing device. be. For example, if the first data is a text message originating on a mobile device comprising a first computing device, the second data (eg, reconstructed text message) is transmitted on a second mobile device (eg, a 2 computer device).

<Identity Authentication Using Privacy Keys>
A privacy key may be used in some embodiments to authenticate an identity from a first computing device (eg, a mobile computing device). In some embodiments, the first data may include a biometric scan, login password or code, or any other first data that may be based on user input. A method of generating privacy keys using controlled corruption and distributing, storing, and/or retrieving stored privacy keys to authenticate identities includes an enrollment module and a sign-in module. OK.

<Enrollment module>
The enrollment module may comprise a method of generating keys (eg, privacy keys) using controlled corruption, distributing the keys, and storing them for later use. Using the methods and systems disclosed herein, privacy keys are generated from first data using controlled corruption, sent to a server, and stored at a plurality of nodes associated with the server. you can Subsequently, when the user enters user input (e.g., biometric scan, password, first data, third data, etc.) into the first computing device of the sign-in module, the and a privacy key based on user input in that module is compared to a privacy key generated using the first data in the enrollment module to authenticate the user's identity. Using controlled corruption to generate a privacy key protects user input, such as biometric data.

FIG. 34 is an example of a server-side (e.g., included in management layer 3020) method 3400 for generating and distributing keys using controlled corruption, according to a particular embodiment. or registering 3440 the first computing device with a plurality of servers; and transmitting the first privacy code and one or more parameters associated with the first data to the one or more servers from the first computing device; receiving 3442; generating 3443 a chunk count and public key at one or more servers; transmitting 3444 the chunk count and public key to a first computing device; receiving 3446 a number of first privacy keys and second privacy codes; and generating 3448 second data based on the privacy keys at one or more servers. In some embodiments, privacy keys may be stored in one or more nodes associated with one or more servers for later use, such as identity authentication. In these embodiments, the method 3400 of generating and distributing keys comprises generating 3450 a result; generating 3452 a recipient identifier and a privacy code identifier; distributing 3454 to one of the nodes associated with the one or more servers.

When privacy keys are generated for uses such as authentication, the method of generating one or more privacy keys is generally the same as described above and illustrated in FIGS. In addition to those methods, method 3400 may include generating 3450 a result. In some embodiments, the compressed second data base 64 file (e.g., 3380 in FIG. 33) can be received as a parameter associated with the first data (e.g., 3142 in FIG. 31). may be compared with the base 64 of first data generated. In these embodiments, two Base64 files may be compared to generate a result 3450. If the two Base64 files are identical, the result may be positive. If the two base64 files are not identical, the result can be negative.

In some embodiments, result 3450 may be generated by comparing compressed second data 3381 with compressed first data. In some embodiments, results 3450 may be generated by comparing second data 3382 to first data. In some embodiments, the result is multiple elements (e.g., first data and second data, compressed first data and compressed second data, compressed first data by comparing the base 64 with the base 64 of the compressed second data, etc.). Iterative learning may be utilized in generating result 3450 . For example, a number of second data 3382 may be generated over time and these second data 3382 may be compared to each other over time to generate results 3450 . Note that although the second data 3382 was used as an example, the result 3450 is generated by comparing any element (first data, compressed data, base 64 compressed data, privacy code, etc.) over time. good too.

In some embodiments, a positive result may prompt 3452 one or more servers included in the management layer to generate recipient identifiers and privacy code identifiers. A positive result may prompt one or more servers that make up the management layer to generate 3446 two or more copies of each privacy key received from the computing device. The privacy key, recipient identifier, and privacy code identifier may be sent 3454 for storage to one or more nodes associated with one or more servers. In some embodiments, privacy keys, recipient identifiers, and privacy code identifiers may be manipulated prior to transmission.

Distributing 3454 the privacy key to one or more nodes for storage may be performed using ledgerless non-descriptive distribution. This distribution method uses a combination of sender identifiers, recipient identifiers, privacy codes, and/or other user-specific codes (e.g., biometrics, etc.) to create a unique piece description for each privacy key. may include generating In some embodiments, a sender identifier may be a string of alphanumeric and/or symbolic characters used to identify any combination of users, transactions, applications, and/or computing devices. In these embodiments, the system may manipulate one or more of privacy keys, privacy codes, recipient identifiers, and sender identifiers to generate a unique piece description for each distributed privacy key. . Piece descriptions may be created on an "as-needed" basis, according to some embodiments, eliminating the need to maintain a ledger or other record of privacy key destinations (eg, nodes) on the server.

Even if a hacker/virus manages to penetrate the system by bypassing defenses (e.g. firewalls or other security features), the endpoint addresses (where the data is distributed) cannot be stored in a central location or central ledger. Without storage, a hacker cannot know for sure where the nodes are or which nodes have particular data.

Even if a node is compromised, this type of distribution ensures that hackers cannot identify the pieces that together form the data. It also has ransomware protection and high fault tolerance. In addition, another level where the process of manipulation (encryption, hashing, corruption, chunking, concatenation, etc.) prevents pieces from being brought together in their original form without the consent of the authorized user. security is ensured.

The privacy key, recipient identifier, and privacy code identifier may be saved for later use, including authentication at the sign-in module.

<Sign-in module>
If a user (e.g., a system user of a computing device included in the web tier) wishes to use a stored privacy key to authenticate an identity with the sign-in module, the user inputs the first user input (eg, privacy code) and second user input (eg, biometric scan, third data). FIG. 35 shows a method of authenticating an identity using a privacy key.

A third data-based privacy key 3590 is generated as described above and shown in FIGS. The resulting privacy key 3590 is sent to one or more servers included in the administration layer of the system. The one or more servers are associated with the one or more servers using information contained in one or more of the privacy key, the privacy code, the second privacy code, and the parameters associated with the first data. Locate and obtain the stored privacy key 3591 from one or more nodes that In some embodiments, the search is based at least in part on the recipient identifier and/or the privacy code identifier.

Each third data-based privacy key 3590 (eg, the privacy key received from the computing device during the sign-in module) is used to generate fourth data in a manner similar to that shown in FIG. be. In some embodiments, the fourth data may be sign-in data 3592 . Each of the stored privacy keys 3591 retrieved from one or more nodes is used to generate fifth data 3593 in a manner similar to that shown in FIG. In some embodiments, the fifth data may be enrollment data 3593 . The fourth data (eg, sign-in data 3592) may be compared to the fifth data (eg, enrollment data 3593) to generate results 3594. FIG. In some embodiments, if fourth data 3592 is the same as fifth data 3593, result 3594 is positive. The data (e.g., first data, second data, third data, fourth data 3952, fifth data 3593) is information relating to any of biometric scans, privacy codes, login passwords, etc. In such embodiments, if the fourth data 3952 (eg, data entered during sign-in) is the same as the fifth data (eg, data entered during enrollment and stored as a privacy key). , the identity can be confirmed. A positive result may allow the user to access one or more protected systems.

<Secure data storage using privacy key>
In some embodiments, privacy keys may be used for secure data storage. For example, in some embodiments the first data may include confidential documents. The first data may be used in the above manner to generate a privacy key and then stored. In these embodiments, it may be necessary to edit secure data (eg, first data, sensitive documents). In these embodiments, a privacy key may be obtained to generate the second data in the manner described above. The system allows data (eg, first data, second data) to be temporarily stored in the landing zone for editing. In some embodiments, a landing zone may be contained on any one or more of one or more servers, temporary databases, first computing devices, second computing devices, or applications. In some embodiments, the landing zone may include external applications such as Google Docs, Microsoft Word, or other applications. The edited data may be used to generate new privacy keys in the manner described above and stored for later use.

Those skilled in the art will appreciate that other variations of the embodiments described herein may be practiced without departing from the scope of the invention. Other modifications are therefore possible.

Claims (20)

In a method of generating and distributing keys using controlled corruption,
registering a first computing device with one or more servers comprising a security engine and an action engine;
receiving, at the one or more servers, from the first computing device a first privacy code and one or more parameters associated with first data, wherein the first privacy code is based on a first user input at the first computing device, the first data being based on a second user input at the first computing device;
generating a chunk count and a public key at the one or more servers, the chunk count being based on one or more parameters associated with the first data, the public key being an asymmetric cryptography being part of a key pair;
sending the chunk count and the public key from the one or more servers to the first computing device;
receiving, at the one or more servers, data relating to a number of privacy keys and a second privacy code from the first computing device;
the number of privacy keys is based on the first data, the chunk count, and the one or more corruptors;
the second privacy code is based on the first privacy code;
the number of privacy keys equals the chunk count;
and
generating second data based on the quantity of privacy keys at the one or more servers, wherein generating the second data comprises:
concatenating the number of privacy keys to generate a concatenated key;
removing the one or more corruptors from the concatenated key to generate the second data;
including
A method, including A way to generate and distribute keys with controlled corruption is
generating two or more chunk names at the one or more servers;
sending the two or more chunk names to the first computing device;
2. The method of claim 1, further comprising: 3. The method of claim 2, wherein the certain number of privacy keys is further based on the two or more chunk names. 4. The method of claim 3, wherein concatenating the certain number of privacy keys to generate the concatenated key is based on the two or more chunk names. 2. The method of claim 1, wherein the one or more corruptors consist of three corruptors. 6. The method of claim 5, wherein at least one of said one or more corruptors is based on said first privacy code. Removing the one or more corruptors to generate the second data includes:
removing one or more first corruptors from the concatenated key to generate first clean data;
removing one or more second corruptors from the first clean data to generate second clean data;
removing one or more third corruptors from the second clean data to produce a compressed data base 64;
decoding a base of the compressed second data to produce the compressed data;
decompressing the compressed data to generate the second data;
contains
4. The privacy code is used to remove at least one of the one or more first corruptors, the one or more second corruptors, and the one or more third corruptors. 6. The method according to 6. 7. The method of claim 6, wherein said first privacy code is used to remove at least one of said one or more corruptors. 2. The method of claim 1, wherein said second privacy code is used to remove at least one of said one or more corruptors. 2. The method of claim 1, wherein the first data comprises intended communications. 2. The method of claim 1, wherein the second user input comprises at least one of an alphanumeric character string, biometric data, a password, an eye scan, a photograph, and a fingerprint. In a method of generating a key using controlled corruption,
generating, at a first computing device, a first privacy code and one or more parameters associated with first data, the first privacy code based on a first user input; and wherein the first data is based on a second user input;
sending the first privacy code and one or more parameters associated with the first data from the first computing device to one or more servers;
receiving, at the first computing device, a chunk count and a public key from the one or more servers, the chunk count being based on one or more parameters associated with the first data; said public key is part of an asymmetric cryptographic key pair;
compressing the first data to generate compressed first data at the first computing device;
generating, at the first computing device, a first prekey based on the compressed first data and one or more first corruptors;
generating, at the first computing device, the second pre-key based on the first pre-key and one or more second corruptors;
generating two or more chunks at the first computing device based on the second pre-key and the chunk count;
generating, at the first computing device, two or more privacy keys based on the two or more chunks;
sending the two or more privacy keys to the one or more servers;
method including. generating the two or more chunks based on the second pre-key and the chunk count;
corrupting the second pre-key with a salt to generate a third pre-key;
corrupting the third pre-key with one or more third corruptors;
splitting the corrupted third pre-key into the two or more chunks based on the chunk count;
13. The method of claim 12, comprising: 13. The method of claim 12, further comprising receiving two or more chunk names at the first computing device. 15. The method of claim 14, wherein the one or more privacy keys are further based on the two or more chunk names. In a method of generating and distributing keys using controlled corruption,
registering a first computing device with one or more servers;
receiving, at the one or more servers, from the first computing device a first privacy code and one or more parameters associated with first data, wherein the first privacy code is based on a first user input at the first computing device, the first data being based on a second user input at the first computing device;
generating a chunk count and a public key at the one or more servers, the chunk count being based on one or more parameters associated with the first data, the public key being an asymmetric cryptography being part of a key pair;
sending the chunk count and the public key from the one or more servers to the first computing device;
receiving, at the one or more servers, from the first computing device a number of data relating to a first privacy key and a second privacy code;
the number of first privacy keys is based on the first data, the chunk count, and one or more corruptors;
the second privacy code is based on the first privacy code;
the number of first privacy keys equals the chunk count;
and
generating second data at the one or more servers based on the number of first privacy keys, wherein generating the second data includes:
concatenating the number of first privacy keys to generate a concatenated key;
removing the one or more corruptors from the concatenated key to generate the second data;
contains a
and
generating results at the one or more servers based on the second data;
generating, at the one or more servers, a recipient identifier and a privacy code identifier based on the results, the recipient identifier being associated with one or more nodes; and the privacy code identifier is based on said second privacy code;
distributing the number of first privacy keys, the recipient identifiers, and the privacy code identifiers to the one or more nodes;
A method, including receiving, at the one or more servers, from the first computing device two or more privacy keys based on third data;
generating sign-in data, said sign-in data being based on two or more privacy keys based on said third data;
17. The method of claim 16, further comprising: obtaining a privacy key stored in the one or more nodes based on at least one of the recipient identifier and the privacy code identifier;
generating enrollment data, the enrollment data being based on privacy keys obtained from the one or more nodes;
18. The method of claim 17, further comprising: comparing the sign-in data and the enrollment data;
generating a result;
19. The method of claim 18, further comprising: In a system comprising a server, said server comprising:
a memory containing server instructions;
a processing device configured to execute the server instructions;
and
The server instructions instruct the processing device to:
registering a first computing device with one or more servers, wherein the one or more servers include a security engine, an action engine, a library, and one or more nodes associated with the one or more servers; be prepared and
receiving, at the one or more servers, from the first computing device a first privacy code and one or more parameters associated with first data, wherein the first privacy code is based on a first user input at the first computing device, the first data being based on a second user input at the first computing device;
generating a chunk count and a public key at the one or more servers, the chunk count being based on one or more parameters associated with the first data, the public key being an asymmetric cryptography being part of a key pair;
sending the chunk count and the public key from the one or more servers to the first computing device;
receiving a number of privacy keys and a second privacy code from the first computing device at the one or more servers;
the number of privacy keys is based on the first data, the chunk count, and one or more corruptors;
the second privacy code is based on the first privacy code;
the number of privacy keys equals the chunk count;
and
generating, at the one or more servers, second data based on the quantity of privacy keys, wherein generating the second data comprises:
concatenating the number of privacy keys to generate a concatenated key;
removing the one or more corruptors from the concatenated key to generate the second data;
including
the system to run.

Images