CN116018592A

CN116018592A - Generating keys using controlled corruption in a computer network

Info

Publication number: CN116018592A
Application number: CN202180049502.1A
Authority: CN
Inventors: D·S·K·维贾亚纳拉亚那
Original assignee: Althevik Corp
Current assignee: Althevik Corp
Priority date: 2020-05-11
Filing date: 2021-05-10
Publication date: 2023-04-25
Also published as: BR112022023105A2; AU2021272736A1; JP2023525774A; MX2022014179A; KR20230024279A; WO2021229410A1; CA3178613A1; EP4150858A1

Abstract

The present invention relates to a platform and/or cross-platform method and system operable to protect data, documents, devices, communications and transactions. Embodiments of the present invention are operable to authenticate a user and may be applicable to any client system. The method and system are operable to distribute unique pieces of anonymized relevant information among a plurality of devices. These devices allocate unique pieces of anonymous information for use by the present scheme to protect the transmission of sensitive information and to authenticate users, data, documents, devices, and transactions. When used for authentication, information related to login is not stored in any part of the scheme, and the user and device are subject to anonymous authentication. The present solution also allows a user to access a protected portion of a client system through a semi-automated process without displaying the user's key.

Description

Generating keys using controlled corruption in a computer network

Technical Field

The present invention relates generally to the field of data security, and more particularly to security of directional communications and authentication of network or system users.

Background

All organizations face the challenge of protecting their data from potential security vulnerabilities. Only data security, organizations can ensure that their communications are secure and that only authorized personnel can access their systems across a variety of technologies. Thus, data security and authorization system access are two major challenges that today's organizations must face.

There are many systems and methods available for various types of authentication of users of systems and networks. These various types of authentication have different security and reliability levels. The following are examples of the types of prior art authentication methods for systems and networks.

United states patent No. 6,962,530 to IGT, 11/8/2005 discloses an architecture and method for a game-specific platform with secure storage and validation of game code and other data. The method also provides the user with the ability to securely exchange data with a computer wagering gaming system. Said invention does not involve the transmission of login information between a plurality of devices.

U.S. patent No. 9,053,306 to NEC Solution Innovators, ltd. 6/9, 2015 discloses a verification system that can be used to calculate first and second hash values based on login information entered by a user. If the first and second hash values match each other, a session will be established between the server and the terminal. Said invention does not relate to hiding parts of the encryption details.

U.S. patent No. 8,989,706 to microsoft corporation, 24, 3, 2015, discloses systems, methods, and/or techniques related to automatic secure pairing of devices, involving the use of devices to download content in parallel. The means for pairing the devices may perform an authentication protocol based on the address and the key. Said invention does not relate to hiding parts of the encryption details.

U.S. patent No. 8,356,180, granted to philips electronics limited of royal netherlands (Koninklijke PhilipsElectronics n.v.), 1/15/2013 discloses a method of multidimensional identification, authentication, authorization and key distribution to enable secure communications in deep public security domains. If the user does not reveal the user key to the system, the invention does not enable transaction verification.

U.S. patent No. 6,847,995 to United states Devices, 25 th year 2000 discloses a security architecture and related methods for providing secure transmissions within a distributed processing system. Said invention does not relate to multi-layer encryption or to hiding parts of the encryption details.

U.S. patent application publication No. 2017/0149796, filed 11/23 in 2016, by yarn Gvili, discloses a system and technique that allows a third party verifier to verify secure data content or its successful communication. Said invention does not relate to multi-layer encryption or to hiding part of the encryption details.

U.S. patent application publication 2011/0246779 filed on 6 th month 6 of Isamu Teranishi discloses a zero knowledge proof system that allows zero knowledge proof of discrete logarithm problems. Said invention does not relate to multi-layer encryption or to hiding part of the encryption details.

The encryption methods and systems of the prior art are particularly vulnerable to third party intervention in the transmission of data and information from user to user and to the system or network. If a third party has access to the data being transmitted, it can infer login details from this information. If the data transferred between the user and the system provides all login details, the third party may login to the system using the login details of the user. This would constitute a security risk to the current system if known authentication methods and systems were used.

There is a need for an authentication method and system to protect the login details of a user from being obtained by interference from third parties with the transmitted data.

Disclosure of Invention

According to some embodiments, a method of processing a key generated using controlled corruption may include registering a first computing device at one or more servers, the one or more servers including a security engine and an action engine; at the one or more servers, receiving a first privacy code from the first computing device and one or more parameters associated with first data, the first privacy code generated based on a first user input at the first computing device, and the first data generated based on a second user input at the first computing device; generating, at the one or more servers, a block count and a public key, wherein the block count is generated based on one or more parameters associated with the first data, and the public key is part of an asymmetric key pair; transmitting the block count and the public key from the one or more servers to the first computing device; receiving, at the one or more servers, data from the first computing device associated with a plurality of private keys and a second privacy code, wherein the private keys are generated based on the first data, the block count, and one or more corrupt codes, the second privacy code is generated based on the first privacy code, and the number of private keys is equal to the block count; generating, at the one or more servers, second data based on the private key, the generating the second data including the steps of concatenating the private key to generate a keychain and removing the one or more corruptions from the keychain to generate the second data.

According to some embodiments, a method for processing keys generated using controlled corruption may include generating, at the one or more servers, two or more block names; and transmitting the two or more block names to the first computing device.

According to some embodiments, the private key is further generated based on the two or more block names.

According to some embodiments, the private key is concatenated based on the two or more block names to generate a keychain.

According to some embodiments, the one or more corruptions comprise three corruptions.

According to some embodiments, at least one of the corrupt codes is generated based on the first privacy code.

According to some embodiments, removing the one or more corruptions to generate the second data includes removing one or more first corruptions from the keychain to generate first clean data; removing one or more second corruptions from the first clean data to generate second clean data; removing one or more third corruptions from the second clean data to generate base 64 encoded compressed data; decoding the base encoding of the compressed second data to generate compressed data; and decompressing the compressed data to generate second data, wherein the privacy code is used to remove at least one of the one or more first corruptions, the one or more second corruptions, and the one or more third corruptions.

According to some embodiments, the first privacy code is used to remove at least one of the corrupt codes.

According to some embodiments, the second privacy code is used to remove at least one of the corrupt codes.

According to some embodiments, the first data comprises directional communications.

According to some embodiments, the second user input comprises at least one of an alphanumeric string, biometric data, a password, an eye scan, a photograph, and a fingerprint.

According to some embodiments, a method of generating a key using controlled corruption may comprise the steps of: generating, at a first computing device, a first privacy code and one or more parameters associated with first data, the first privacy code generated based on a first user input and the first data generated based on a second user input; transmitting the first privacy code and the one or more parameters associated with the first data from the first computing device to one or more servers; at the first computing device, receiving a block count and a public key from the one or more servers, wherein the block count is generated based on the one or more parameters associated with the first data, and the public key is part of an asymmetric key pair; at the first computing device, compressing the first data to generate compressed first data; generating, at the first computing device, a first pre-key based on the compressed first data and one or more corruptions codes; generating, at the first computing device, a second pre-key based on the first pre-key and one or more second corruptions; generating, at the first computing device, two or more blocks based on the second pre-key and a block count; generating, at the first computing device, two or more private keys based on the two or more blocks; and sending the two or more private keys to the one or more servers.

According to some embodiments, the generating two or more blocks based on the second pre-key and the block count includes corrupting the second pre-key with salt (salt) to generate a third pre-key; corrupting the third pre-key using one or more third corruptions codes; and dividing the corrupted third pre-key into two or more blocks based on the block count.

According to some embodiments, a method of generating a key using controlled corruption may include receiving, at the first computing device, two or more block names.

According to some embodiments, the two or more private keys are also generated based on the two or more block names.

According to some embodiments, a method of generating and distributing keys using controlled corruption may include registering, at one or more servers, a first computing device; at the one or more servers, receiving a first privacy code from the first computing device and one or more parameters associated with first data, the first privacy code generated based on a first user input at the first computing device, and the first data generated based on a second user input at the first computing device; generating, at the one or more servers, a block count and a public key, wherein the block count is generated based on the one or more parameters associated with the first data, and the public key is part of an asymmetric key pair; transmitting the block count and the public key from the one or more servers to the first computing device; at the one or more servers, receiving data from the first computing device associated with a plurality of first private keys and a second privacy code, wherein the first private keys are generated based on the first data, the block count, and one or more corruptions, the second privacy code is generated based on the first privacy code, and the number of first private keys is equal to the block count; generating, at the one or more servers, second data based on the first private key, the generating second data comprising the steps of concatenating the private key to generate a keychain; removing one or more corruptions from the keychain to generate the second data; generating, at the one or more servers, a result based on the second data; generating, at the one or more servers and based on the results, a recipient identifier and a privacy code identifier, wherein the recipient identifier is associated with one or more nodes, and the privacy code identifier is generated based on the second privacy code; and assigning the first private key, the recipient identifier, and the privacy code identifier to the one or more nodes.

According to some embodiments, a method of generating a key using controlled corruption may include the steps of receiving, at the one or more servers, two or more private keys from the first computing device based on third data; and generating login data, wherein the login data is generated based on the two or more private keys based on the third data.

According to some embodiments, a method of generating a key using controlled corruption may include the steps of retrieving the private key stored at one or more nodes based on at least one of a recipient identifier and a private code identifier; and generating registration data, wherein the registration data is generated based on the private key retrieved from the one or more nodes.

According to some embodiments, a method of generating a key using controlled corruption may include the steps of comparing login data with registration data; and generating a result.

According to some embodiments, a system may include a server including a memory containing server instructions; and a processing device configured to execute the server instructions, wherein the server instructions cause the processing device to register the first computing device at one or more servers including a security engine, an action engine, a library, and one or more nodes associated with the one or more servers; at the one or more servers, receiving a first privacy code from the first computing device and one or more parameters associated with first data, the first privacy code generated based on a first user input at the first computing device, and the first data generated based on a second user input at the first computing device; generating, at the one or more servers, a block count and a public key, wherein the block count is generated based on one or more parameters associated with the first data, and the public key is part of an asymmetric key pair; transmitting the block count and the public key from the one or more servers to the first computing device; receiving, at the one or more servers, a plurality of private keys and a second privacy code from the first computing device, wherein the private keys are generated based on the first data, the block count, and one or more corruptions codes; the second privacy code is generated based on the first privacy code; and the number of private keys is equal to the block count; generating, at one or more servers, second data based on the private key, the generating second data comprising the steps of concatenating the private key to generate a keychain; and removing one or more corruptions from the keychain to generate the second data.

For this reason, before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. 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 used herein is for the purpose of description and should not be regarded as limiting.

Drawings

The objects of the present invention will be better understood and will become apparent upon reading the following detailed description. The description makes reference to the accompanying drawings wherein:

fig. 1 is a system diagram illustrating an embodiment of a verification system of the present invention.

Fig. 2 is a system diagram showing a configuration of elements operable to transmit data between a client system and an authentication system of an embodiment of the present invention.

Fig. 3 is a system diagram showing the configuration of elements operable to perform registration processing of an embodiment of the present invention.

Fig. 4 is a system diagram showing a configuration of elements operable to perform an access process of an embodiment of the present invention.

Fig. 5 is a system diagram illustrating a synchronization element operable to process hashed OY packet portions according to an embodiment of the present invention.

Fig. 6 is a system diagram showing a configuration of elements operable to perform a decoding process of an embodiment of the present invention.

Fig. 7 is a system diagram illustrating elements of a user device in accordance with an embodiment of the present invention.

Fig. 8 is a system diagram illustrating elements of a client system of an embodiment of the present invention.

Fig. 9 is a system diagram showing elements of a client display unit of an embodiment of the present invention.

Fig. 10 is a system diagram showing elements of a verification system of an embodiment of the present invention.

Fig. 11 is a system diagram illustrating a configuration of elements operable to process a user authentication request to access a secure portion of a client system in accordance with one embodiment of the present invention.

Fig. 12 is a system diagram illustrating a configuration of elements operable to generate and process noise and keys for authenticating a user in accordance with one embodiment of the present invention.

Fig. 13 is a system diagram showing a configuration of elements operable to perform verification of a key for verifying a user according to one embodiment of the present invention.

Fig. 14 is a system diagram illustrating a configuration of elements operable to perform token authentication for authenticating a user in accordance with one embodiment of the present invention.

Fig. 15 is a system diagram illustrating a configuration of elements operable to challenge authentication through a client display system for authenticating a user in accordance with one embodiment of the present invention.

Fig. 16 is a system diagram illustrating a configuration of elements operable to challenge-verify through a user device for authenticating a user in accordance with one embodiment of the present invention.

Fig. 17 shows a registration method according to an embodiment of the present 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 assigning one or more keys according to one embodiment of the present 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 authentication keys according to one embodiment of the present invention.

Fig. 23 illustrates a method of verifying a verification key in a local database according to one embodiment of the invention.

FIG. 24 illustrates a method of validating a verification process in accordance with one embodiment of the invention.

FIG. 25 illustrates a method of generating one or more bar codes 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 network session according to one embodiment of the invention.

Fig. 30 illustrates a system for generating keys using controlled corruption in accordance with some embodiments.

Fig. 31 illustrates a method of generating a key using controlled corruption in accordance with some embodiments.

Fig. 32 illustrates a method of generating a key using controlled corruption in accordance with some embodiments.

Fig. 33 illustrates a method of generating a key using controlled corruption in accordance with some embodiments.

Fig. 34 illustrates a method of generating a key using controlled corruption in accordance with some embodiments.

Fig. 35 illustrates a method of authentication using a controlled corruption generated key in accordance with some embodiments.

In the drawings, embodiments of the invention are illustrated by way of example. It is to be expressly understood that the description and drawings are only for the purpose of illustration and for the purpose of facilitating understanding and are not intended as a definition of the limits of the invention.

Detailed Description

The present invention is an authentication method and system operable to authenticate users, data, documents, devices, and transactions. Embodiments of the invention may operate with any system or network of any organization or individual. The authentication method and system are operable to distribute unique portions of login-related information among a plurality of devices. The system uses the assigned portion of the login-related information to authenticate the user, data, documents, devices, and transactions without revealing the login-related information to the system. The login-related information is encrypted and/or hashed by means of multi-layer encryption and/or hashing, and some details of the encryption and/or hashing are hidden. The devices storing login-related information will all be used in the authentication method and system. The login-related information provided to the user is not revealed to and/or stored in the system or any user device. Verification of data, documents, devices, and transactions does not require that keys be revealed to the system.

As referred to herein, a "client system" refers to an organization or individual's network or system. Reference herein to "user device" refers to a device that a user uses to log into a client system, such as a notebook, tablet, cell phone, smart phone, desktop, smart watch, computing device, whereby the user can log into the client system or any other device that requires secure login. Any reference to "information transmission" between a user and a client system may include the creation, transmission, or storage of any information related to the system.

For clarity, when any unit or element of the authentication system is mentioned to "access" another unit or element, this may involve any of the following aspects: (i) A unit or element that accesses another unit or element to obtain information therefrom; or (ii) a unit or element that sends a request for information retrieval or generation to another unit or element, and once such information is retrieved or generated in response to the request, such information may be sent to the unit or element that sent the request.

When a user logs into a client system using a user device, creation, transmission, storage, or verification of login-related information between the user device and the client system may be vulnerable to attack by a third party. Due to the attack of the third parties on the user equipment or the client system, the third parties may obtain and/or use the login-related information between the third parties for malicious purposes during the creation, transmission, storage and/or verification of the information. For example, a third party may log into the client system using the login details it obtained to enable unauthorized access to the client system, or by obtaining more login-related information from the client system or otherwise moving laterally to a system connected to the client system. As another example, a third party may use data, files, or transaction information obtained from an attack for various unauthorized purposes (i.e., propagating information to other parties, taking advantage of the information acquisition market, taking advantage of information to personally make luxury, spying, corrupting, etc.). The present invention reduces the vulnerability of client systems to unauthorized use of client systems or data, documents or transaction information created, transmitted and/or stored between the client systems and user devices.

The method of the present invention involves a user logging into a client system of an organization or individual using a user device. The login-related information will be hashed and/or encrypted by a single-layer or multi-layer hashing and/or encryption process. In particular, at least a portion of the encryption and/or hash keys may be generated and stored in the user's device. Other unique portions of the login-related information will be stored in other devices in the environment. Paying for the unique portion of login-related information among the multiple devices means that a third party accessing the information transmission between the client system and the user device will not be able to obtain any or all of the information needed to successfully login to the client system.

Furthermore, in one aspect of the current system, in order to authenticate a data document, device, transaction, and/or user, the user's device will need to prove to the client system that it has a valid key and/or that the device has been authenticated. This is achieved by the present invention without the user device having to reveal one or more keys to the client system. Thus, verification of data, documents, devices, transactions, and users may be performed without the user having to reveal their keys to the client system.

The login-related information will be created in a unique way and will not be stored and/or transmitted; this, together with user device assisted multi-point authentication, prevents unauthorized third parties from accessing the client system.

Since most prior art authentication systems involve creating, storing, transmitting, and single-point authenticating login-related information between a user's device and a client system, prior art systems are vulnerable to third parties revealing such information. Once obtained by a third party, this information can be used to log onto the system network at a single point of authentication without the need for authorization, or unauthorized use of data, documents, or transaction information. The present invention provides an advantage over prior art systems in that it is not vulnerable to information attacks by third parties that would allow unauthorized access to client systems or data, documents or transaction information. The verification system of the present invention solves the problem of the prior art that verification may be compromised in creating, storing, transmitting and verifying points.

As an example of another advantage of the present invention over prior art systems, prior art systems are generally not operable with any type of client system or any type of user device. The present invention provides an organization with a security verification system that will provide the necessary security access to users to access the organization's data across any platform, solution or environment. The present invention may be implemented by any organization for any type of client system and any user device on any platform.

Another example of the benefits of the present invention over the prior art is that the present invention is operable to cellular authorize devices in an environment. For example, multiple mobile and/or storage devices across a geographic time region may be authorized during a cellular authorization process. Prior art systems are not capable of cellular authorization across geographical time regions.

Embodiments of the present invention may include a number of components operable to authenticate a user for logging into a client system having a secure portion therein, or for accessing a secure portion of such a system. For example, one embodiment of the present invention may include the following three main components: (1) synchronous multiple aspect verification (SMFA); (2) interactive semi-manual verification (ISMA); (3) transaction verification. To provide an example of such an embodiment of the invention, these three components of an embodiment of the invention are described below. The skilled reader will recognize that other configurations of the present invention are possible, including configurations that include only one or two of the three components described below, or configurations that include other components.

Synchronous multiple verification (SMFA)

The authentication processing operations of the user of the authentication method and system of the present invention cause the encrypted and/or hashed portions of the random multi-unit login-related information to be distributed among the devices (e.g., the user and/or the system devices and storage units) and all such or more such devices to be used to authenticate the user.

Thus, if login data is compromised (e.g., by unauthorized access by a third party) at the time of creation, transmission, storage, or authentication, only the encrypted and/or hashed portion of the unknown user's time-sensitive random login-related information is obtained, and this data will not be able to authenticate the user.

More specifically, the present invention is operable to require a user to participate in a challenge, e.g., a static challenge may be a needle and/or pattern challenge, an animated and/or non-animated challenge, a graphical and/or non-graphical challenge, a two-dimensional and/or three-dimensional challenge, a mobile and/or static gamification challenge, and/or a non-gamification interface challenge, in order to log into a client system. The system may select a series of units and use those units to generate challenges. Each cell is randomly assigned a plurality of digits. May change each time an event is logged in. The user may select multiple challenges in the same authentication event and any subsequent authentication events.

The series of units selected during the challenge is divided by the authentication system into a plurality of unique system parts. The cells in each cell portion may be separately hashed or encrypted to generate a cell result, and then the cells in each system portion may be hashed and/or collectively encrypted to generate a system portion result. The number of hashes and/or encryptions applied to each unit in a system portion and to each system portion may vary.

Some of the hash and/or encryption results are stored in a different device of the distributed architecture of the client or other system and some are stored in the user's device. For example, portions of the hash and/or encryption result may be stored in multiple users and system devices.

All client system devices and user devices that contain hashed and/or encrypted portions of data must authenticate themselves. Once the devices are authenticated, they can perform a joint authentication of the user.

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

Interactive semi-manual verification (ISMA)

The authentication processing operations of the user of the present invention enable the login information to be encrypted and/or hashed using a multi-layer encryption and/or hashing function. A portion of the random encryption and/or hash details are retained and manually transmitted, but not stored in the client system or user device, thereby reducing the likelihood of corruption during transmission, storage, or authentication.

The system of the present invention provides a key (i.e., key 1) to the mobile device. All keys in the present invention are encrypted and/or hashed using a multi-layer encryption and/or hash function.

The encryption key is required to be used in the authentication process of the present invention, so the user must first verify using the SMFA process described herein to authenticate the key and authenticate the user's device.

The system will generate challenges based on random encryption keys, which will be altered at each login event. The authenticated user will scan for challenges using his authenticated device. At the end of this process, a part or all of the random encryption key will be sent to the user equipment.

In some embodiments of the invention there may be another set of encrypted random keys generated by the user device, which will also change at each login event. Multiple keys that can be combined into an encrypted shared key; some or all of the encrypted shared key will be sent to the client system of the organization requesting user authentication.

The user device may generate a multi-layer encryption. Such encryption may be applied to the elements individually or collectively. For example, the user device may generate three or more digits at random (which may change during each login event) and salt and iv, or other types of encryption and/or hashing may be applied. Another layer of encryption may be added collectively to the previous encryption.

The plurality of random characters are deleted from a packet, which is generated by the plurality of encryption layers. For example, six random characters may be deleted from the packet. The user will be provided with a plurality of random numbers and characters and the encrypted detailed information will be sent to the client system requesting authentication of the user device.

A client system requesting authentication of a user device would require the user to provide information given to the user device. The client system can only authenticate the user if the user provides such information. This process reduces the likelihood that a third party intercepts, guesses, or knows the user login information.

When the user passes authentication, the session will pass authentication by the time and geography based access code. For example, the geographic-based access code may be a token or any other type of geographic-based access code. If the time expires or the geographic aspect is invalid, the geographic-based access code may be invalid. For example, if the user is not within a geographic location associated with a geographic-based access code, the geographic aspect may be invalid.

Transaction verification

The authentication processing operation of the user of the authentication system of the present invention enables the transaction to be authenticated without requiring the user to reveal his key to the client system. The client system does not know the user key or whether the user has a key. The user device must prove to the system that it has a valid key and that the user and device have been authenticated without revealing the key to the system. To achieve this, the user device will have to authenticate using the SMFA process described herein and/or the ISMA procedure described herein. Once the user device is authenticated, the user device may use the random temporary key it owns or receives.

The system will generate a security challenge. Features such as multi-layer encryption, digital signatures, and/or hashes may be used to protect this challenge. The security packet is sent to the user device requesting authentication. The user device will verify the package and may use the decryption key provided to the display or resolve the challenge.

As an example, one embodiment of the invention may be operable such that the system will generate a plurality of random number alphanumeric codes in which one or more digits are blank, the corresponding letters or numbers will be filled in the blank, and the corresponding letters or numbers will also be sent to the user by way of a challenge during the ISMA. For example, the system may generate six or more random number alphanumeric codes, or any number of random number alphanumeric codes.

The system will generate and encrypt 6 or more random alphanumeric codes and other elements. For example, the system may encrypt six or more random numbers of alphanumeric codes, additional encryption and security features (which may include, but are not limited to, salt, iv, security keys, etc.) may also be applied by the client system. The system will then add a digital signature to the encryption result. This encrypted and signed packet is then sent to the user device requesting authentication.

The user device will verify the digital signature and then recreate the six or more digit alphanumeric code and corresponding letters or numbers using the provided decryption key.

The user device then encrypts the recreated information as well as the security features. The user device will then add a digital signature to the encryption result. The encrypted and signed packets are then sent to the client systems that participate in the authentication process.

The client system receives the message from the user device, upon receipt will verify the digital signature, decrypt the message and compare the message with the transmitted message. If the comparison shows that the received message is the same as the transmitted message, then the client system knows that the user has the required key session to verify the user device will be verified by time and geographic location based access codes that will be invalidated if the time expires or the geographic location is invalidated, as previously described.

Readers of skill in the art will recognize that the methods and systems for verification of the present invention may be implemented in a variety of ways. Figures 1-17 provide some examples of embodiments of the invention, which are described herein.

As shown in fig. 1, the authentication system includes a number of elements including a client system, a user system, an authentication system, and a plurality of storage units. The verification system has the functions of proving and verifying user login and the like.

The user system 102 is used by a user to log into the client system 902. As described herein, a user system may be used to verify the identity of a user, as well as other activities. The identity of the user must be verified by the client system in order for the user to be able to access the secure area of the client system. The authentication system 202 is used to authenticate the identity of a user to a client system.

When a user wants to access a secure area of a client system through the user device 90, the user will have to first prove the user's identity to the client system. Once the client system receives verification of the user's identity, the system may allow the user to access the secure content of the client system.

The user uses the user system to prove his identity and access the secure area of the client system. The verification system 202 may be used to verify the authenticity of the user's identity. The synchronization system 300 is a collection of one or more synchronization elements 302a … 302N that operate in a synchronized manner to approve the authenticity of a user identity.

The user system may comprise a plurality of elements. In one embodiment of the invention, the user system may include a certification unit 104, a display unit 106, a processing unit 108, an approval unit 112, a storage unit 110, and a communication unit 114. The attestation unit is operable to attest to the authentication system to an initial identity of the user system 102. The display unit is operable to display information to the user, for example, a challenge or any other information sent to the user system from the client system, the authentication system or any other system or element of the present invention. The display unit is further operable to display information generated by the client system to a user. The display unit may also be connected to an input unit or have a touch screen or other input operability, whereby a user can input information. The information entered by the user may be displayed on a display unit or may be collected and stored by the user system, sent to another system or element of the client system or authentication system, or processed by the user system. The processing unit 108 will be responsible for all processing power within the system. The approving unit 112 will be responsible for accessing the challenges and responses and providing the results and the storage unit will be responsible for storing temporary and permanent data. The communication unit 114 is responsible for all external communications.

Verification system 202 may include a number of elements. In one embodiment of the invention, the verification system may include 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 a communication unit 216. The masker unit may be used to generate one or more unique non-identifying identifiers for the client system and the user system. The processing unit 210 is operable to process information and data in accordance with the requirements of the authentication system. The approval unit 212 is operable to access the response received inside the system and to provide results that can be sent to the processing unit or to a receiver outside the system via the communication unit. One or more storage units may be used to store temporary and permanent data. The N-data packet generator 206 may be used to generate packets of authentication information. The communication unit 216 is operable to receive and transmit all communications with all elements of the authentication system (i.e., client systems, user systems, etc.) external to the authentication system.

Readers of skill in the art will recognize that in embodiments of the present invention, some or all of the units described in FIG. 1 as elements of the authentication system may be incorporated into other systems or elements of the authentication system, such as a client system. In some embodiments of the invention, some or all of the units described in fig. 1 as elements of the authentication system may be stand-alone elements that are not included in any system of the authentication system, but are typically included in the authentication system.

The 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 may include a attestation unit 304A … 304N, a storage unit 308A … 308N, a processing unit 306A … 306N, an approval unit 312A … 312N, and a communication unit 310A … N. The attestation unit 304A is operable to attest to the verification system 202 to an initial identity of the synchronization system 300.

Communications between the user system, the authentication system and the synchronisation element are received and transmitted by a communications unit of said system and/or element. All such communications between systems and/or elements may be protected by using one or more masking functions, which may include hashing and/or encryption.

As shown in fig. 2, data may be sent between the client system 902 and the masker unit 204 of the authentication system via the communication unit 216 of the authentication system. During initial communication between the client system and the authentication system associated with the settings of the new user to use the client system, the client system may communicate with a masker unit of the authentication system to request credentials required by the new user to establish a secure connection with the client system. The masker unit generates unique security credentials that the client system can use to establish a link between the client system and the authentication system. These unique credentials may include, for example, a client ID or other form of credentials.

When a trusted connection is established between the client system and the authentication system, the masker unit performs such processes as calculations, algorithms, or other types of processing that will generate a unique non-identifying identifier that is secret to the user. The unique non-identifying identifier may be stored in the storage unit 214A (or any of the storage units 214A … 214N) incorporated into the authentication system.

The masker unit may use a masking function such as hashing, encryption, or some other masking function to secure the non-identification identifier. The client system may also provide a list of all available synchronization elements to the verification system. In an embodiment of the invention, one or more synchronization elements may be stored in one or more storage units 214a … N of the authentication system.

As shown in FIG. 3, the enrollment process of the present invention may include operating elements of the verification system as needed during initial interaction of the user with the verification system to enroll the user with the client system. As shown in fig. 3, all communications between the client system, the elements of the user system, the elements of the authentication system and the elements of the synchronization system are via the communication units of the user system, the authentication system and the synchronization system. The user must register with the client system that is authorized to access the secure portion of the client system. During initial enrollment, the attestation unit 104 accesses one or more storage units 110 of the client system to retrieve attestation information. The attestation information may include a non-identifying identifier generated by the masker unit, a secret also generated by the masker unit, and may also include information that may identify the user device, a unique application number, and or other information related to the user, such as biometric information (e.g., a user's fingerprint, a user's retinal scan, or other biometric information of the user), usage information, and so forth. Once the attestation unit obtains all attestation information, the attestation 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 transmitted to the processing unit 210 of the authentication system via the communication unit 114 of the user system. The processing unit 210 retrieves information for the user from one or more of the storage units 214a … 214N of the authentication system via the communication unit 216 of the authentication system. The processing unit 210 combines information received from the client system with information retrieved from one or more storage units of the authentication system to create an information package. The processing unit sends such a packet to the approving unit 212.

The approval unit 212 compares the value of the information packet it received from the processing unit with information previously received from the client system that is stored in one or more storage units 214a … 214N of the authentication system. If the comparison is successful, the approval unit will accept the connection with the user system. If the comparison is unsuccessful, approval unit 212 will reject the connection with the user system. The results of the approval system are sent to the N packet generator 206.

If the connection with the user system is not approved, the operation of the authentication system attempting to register the user will end. In one embodiment of the invention, the N-packet generator will generate a random challenge if the connection with the user system is approved. The random challenge may include a plurality of data packets (N-data packets). Each N-data packet contains a plurality of random numbers or alphanumeric/other characters (N-RANC).

The N-data packet is securely sent to the display unit 106 of the user system. Embodiments of the present invention may apply multi-layer protection including, but not limited to, encryption, hashing, and/or digital signing to provide security to the N-data packets sent between the N-data packet generator and the display unit, e.g., multi-layer protection to the N-RNAC and the N-data packets prior to transmission. In other embodiments of the invention, the N-data packet may be generated by an element of the user system or a different system with or without N-RNAC. The user interacts with this element to generate OY packets.

The display unit 106 receives the N-data packet and displays information contained in the N-data packet to the user. From the displayed N-data packets, the user enters one or more N-data packets, thereby selecting the N-RANC associated with the selected N-data packet. For ease of reference, the N-packets selected by the user are the Y-packets herein. The Y-packets selected by the user are kept as ordered Y-packets (OY packets). The OY packets are 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 two or more parts. Each section may contain two or more N-packets.

The processing unit of the user system may mask the OY packet information by applying a masking function to each portion of the OY packet. For example, the processing unit of the user system may apply masking to one or more of: each N-RNAC contained in an OY packet and/or each Y packet and/or each OY packet contained in an OY packet. The results of the one or more masks may be stored in one or more memory units 110 of the user system. The non-stored results are sent to the processing unit of the verification system.

The challenge generated by the N data packet generator sent to the display unit of the user system may contain a plurality of N packets, and each N packet may contain three or more N-RANCs. The user may select a plurality of Y packets that form an OY packet. The OY packet may be split into two parts (i.e., OYA part and OYB part).

The processing unit of the authentication system may apply hashing and/or encryption and then select two or more random synchronization elements of the synchronization system from a list stored in one or more memory units of the authentication system. The selected random synchronization elements form a synchronization registry. The processing unit of the authentication system may add secrets to the OY packet portion individually or collectively, and may perform multi-layer hashing and/or encryption functions on the OY packet portion individually and/or collectively. The hashed and/or encrypted unique OY packet portion may then be distributed among one or more synchronization elements and stored in one or more storage units in the one or more synchronization elements to which the OY packet portion is distributed. As a result, the unique OY packet portions are stored in different synchronization elements. The distribution information part may be stored in a synchronization registry of the synchronization element.

As shown in fig. 4, the authentication system may be used to perform an access process in which a registered user attempts to authenticate himself by operation of the authentication system so that the user gains access to a secure portion of the client system. As shown in fig. 4, all communications between the elements of the user system, the authentication system and the synchronization system are via the communication unit of the user system, the authentication system and the synchronization element of the synchronization system. The attestation unit 104 of the user system accesses one or more of the storage units 110 of the user system to retrieve attestation information. The attestation information may include a non-identifying identifier and a secret.

Some or all of the attestation information obtained by the attestation unit is securely sent to the processing unit 210 of the authentication system via the communication unit 114 of the user system via the communication unit 216 of the authentication system. The processing unit 210 retrieves the user's information from one or more storage units 214a … 214N of the authentication system. The processing unit 210 combines information received from the client system with information retrieved from one or more storage units of the authentication system to create an information package. The processing unit sends the information package to an approval unit 212 of the verification system.

Approval unit 212 compares the value of the information packet it received from processing unit 210 with information stored in the authentication system that was previously received from the client system. If the comparison is successful (i.e., the comparison result matches the comparison information), the approval unit will accept the connection with the user system. If the comparison is unsuccessful, the approval unit will refuse the connection with the user system. The results of the approval system are sent to the N packet generator 206.

If the connection with the user system is not approved, the operation of the authentication system attempting to register the user will end. If the connection with the user system is approved, the N packet generator will generate a random challenge. The random challenge may include two or more data packets (N-data packets). Each N data packet contains more than two random numbers or alphanumeric characters (N-RANC). A multi-layer hash and/or encryption may be applied to the challenge sent to the display unit. Hashing and/or encryption is applied by a random number generator.

The N-data packet is securely sent to the display unit 106 of the user system. Embodiments of the present invention may apply multi-layer hashing and/or encryption to provide security for the N-packets sent between the N-packet generator and the display unit. For example, multi-layer hashing and/or encryption may include hashing and/or encrypting the N-RNAC and/or N-data packet prior to transmission. The display unit 106 receives the N-data packet and displays corresponding information to the user. From the displayed correspondence information, the user selects two or more correspondence information and then selects by selecting an N-data packet and an N-RANC associated with the selected N-data packet. For ease of reference, the N-packets selected by the user are Y-packets herein, which are ordered and referred to as OY packets.

In another embodiment of the invention, the N-packet generator may reside in a user system and/or other system that may interact with the user through any element from the user system or other system (e.g., camera, scanner, etc.) to generate Y and/or OY packets.

The OY packets are 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 a plurality of parts. Each section contains a plurality of N packets.

The processing unit 108 of the user system retrieves the previously stored OY packet part from one or more memory units of the user system that store the previously stored OY packet part. The processing unit distributes the previously stored OY packet part and the recently created OY packet part to the approval unit 110 of the user system. The approval unit of the user system compares the information it receives from the processing unit of the user system with the previously stored OY packet portion and generates an approval result or a rejection result. The result generated by the approval unit of the user system, i.e. the approval result or the rejection result, is sent to the processing unit of the user system. If the result from the approval unit of the user system is a rejection result, the authentication process will be stopped.

If the result of the approval unit of the user system is an approval result, the processing unit of the user system may store one or more of the OY packet parts that were recently generated in the one or more memory units of the user system and dispatch the remaining OY packet parts to the processing unit of the verification system. The processing unit of the authentication system retrieves the synchronization system information of the user from the synchronization registry. The processing unit of the authentication system may add secrets to the OY packet portions it receives 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 may distribute the hashed and/or encrypted unique OY packet portion to one or more processing units 302a … 320N of the synchronization element of the synchronization system. Each processing unit of the synchronization element receives hashed and/or encrypted unique OY packet portions from the processing unit 210 of the authentication system. Each synchronization element of the synchronization unit that receives the hashed and/or encrypted OY packet portion may perform the processing as shown in fig. 5. The processing unit 306a … 306N of the synchronization element may decode the hash and/or encryption to determine and identify one or more N-data packets and N-RANC. The processing unit of the synchronization element may send the N-data packet and the N-RANC to the approval unit 312a … 312N of the same synchronization element.

The attestation unit 304a … N of the synchronization unit retrieves previously stored hashed and/or encrypted OY packet portions from the storage unit 308a … N of the synchronization unit. The attestation unit of the synchronization unit may decode the hash and/or encryption to determine and identify one or more N-data packets and N-RANC, and these are sent to the approval unit of the synchronization unit. The approval unit of the synchronization element compares the most recently generated N-data packet and N-RANC it received with the previously stored N-data packet and N-RANC. Based on this comparison, a pass or fail value is generated. The generated pass or fail value is sent to a certification unit of the synchronization element.

The attestation unit of the synchronization unit retrieves attestation information from one or more storage units of the synchronization unit, and both the attestation information and the pass or fail value received by the attestation unit may be hashed and/or encrypted and sent to a processing unit of the verification system.

The processing unit of the verification system receives the hashed and/or encrypted result and the attestation information from each attestation unit of each synchronization element generating the information. For clarity, multiple sync elements may receive a unique OY packet portion, and each such sync element will process the OY packet portion according to the methods discussed herein. As shown in fig. 6, all communications between the elements of the user system, the authentication system and the client system are via the communication units of the user system, the client system and the authentication system. As also shown in fig. 6, the processing unit 210 of the verification system 202 will decode the verification information it receives from each synchronization element 302a … 302N and send the decoded information to the approval unit 212 of the verification system. The processing unit 210 of the authentication system retrieves the attestation information from one or more storage units 214a … 214N of the authentication system. The processing unit of the verification system sends the retrieved attestation information to an approval unit of the verification system. The approval unit of the verification system approves the synchronization element using the information it receives.

The processing unit of the verification system decodes each pass and/or fail value it receives from the synchronization element. The decoded value is stored as a verification result in one or more memory cells of the verification system. The processing unit of the verification system or report generator 208 may generate a verification result report and the report may contain various information such as the total synchronization element requested, the number of pass values received, the number of fail values received, the synchronization system trust score, etc.

The processing unit of the authentication system may hash or encrypt the authentication result and send the hashed and/or encrypted authentication result to the processing unit 108 of the user system 102 via the communication unit 216 of the authentication system. The processing unit of the user system sends the hashed or encrypted authentication result to the client system 902. The client system submits a verification 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. The processing unit of the authentication system retrieves the authentication results stored in the one or more storage units of the authentication system and sends the retrieved results to the approval unit of the authentication system. The approval unit of the verification system approves the retrieved result and sends the approval result to the client system, and the client system decides whether to verify the user according to the result of the verification report.

After the user is 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 provide user information (i.e., text, data, etc.) to the client system. For example, a user may access a client system to send a message, make a purchase involving a credit card payment, attach an electronic signature to a document, or for various other purposes. During the interaction of the user with the client system, user information is sent between the client system and the user system via the user system. The present invention may be used to secure such user and authentication related information during creation, transmission, storage and authentication.

To achieve this security, embodiments of the present invention may include a user system, a client display unit, and an authentication system. The user system may be wholly or partially incorporated into a client device used by a user to communicate with and access the client system. Readers of skill in the art will recognize that embodiments of the present invention implementing the security of user and authentication related information sent between a user device and a client system may include other elements.

The user will verify the credentials of the user system and the user to the client system using the user device. The credentials of the user and the user system must be verified to verify whether the user has access to the secure portion of the client system. Only when the user is authenticated, the user can perform certain functions or access certain information through the secure portion of the client system. For example, a user may only be able to approve certain transactions through a client system if the user and the user system are authenticated. The client system is a system that the user attempts to access, and thus authentication needs to be performed. As described herein, the authentication system of the present invention will authenticate the identity of the user and the user system and cause the client system to identify the user and the user system as authenticated.

As shown in fig. 7, a user system 101 for transmitting user information to and from a client system may include a plurality of elements. For example, embodiments of the present invention may include a user system that includes an interaction unit 103, a verifier generator 105, a noise generator 107, a processing unit 109, a storage unit 111, and a reader unit 113.

As shown in fig. 8, the client system 130 of an embodiment of the present invention may include a plurality of elements. For example, embodiments of the present invention may include a client system including CSAP generator 131, storage unit 133, processing unit 135, challenge generator 137, and approval unit 139.

As shown in fig. 9, the client display unit 150 of the embodiment of the present invention may include a plurality of elements. For example, an embodiment of the present invention may include a client display unit including an interaction unit 151, a processing unit 153, a temporary storage unit 155, and a key generator 157.

As shown in fig. 10, the verification system 140 of an embodiment of the present invention may include a plurality of elements. For example, embodiments of the present invention may include a verification system that includes a random key generator 141, a random text generator 143, a USID generator 145, and a processing unit 147.

When a user wants to log into the secure portion of the client system, the user will declare his own intent through interaction with the client display unit and use the interaction unit of the client display unit to input a request. As shown in fig. 11, the interaction unit 151 transmits a request to the processing unit 153 of the client display unit, and then the processing unit of the client display unit transmits the request to the processing unit 147 of the authentication system. The processing unit 109 of the user system will generate a request for a combination of alpha keys (ak) consisting of the ak 1 and ak 2 keys and send to the key generator 157 of the client display unit via the processing unit 147 of the authentication system. The key generator of the client display unit sends αk1 and αk2 to the processing unit 147 of the authentication system.

Then, the processing unit 147 of the authentication system requests a random text from the random text generator 143 of the authentication system and requests a unique system and event identifier (USID) from the USID generator 145 of the authentication system. The random text generator generates and sends random text to the processing unit 147 of the authentication system. The USID generator generates a USID and sends the USID to the processing unit of the authentication system. The USID generator may be used to identify the authentication system, user devices attempting to connect to a secure area in the client system, and events. The USID is unique to the browser or each tab in the plurality of browsers and is used to identify and control the number of browsers or tabs that are opened for use by the user.

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

As shown in fig. 12, after the process of fig. 11 is completed, information is provided to the user system through the reader unit 113. The reader unit 113 may include one or more sensors including audible, visual, tactile, printed, motion, and other types of sensors that may be incorporated into or external to the client device, but connected to the sensors by wired or wireless connections. The sensor may be used to obtain information about the user.

The reader unit 113 then transmits the information it obtained to the processing unit 109 of the user system. The processing unit of the user system may separate the information it receives from the reader unit and may save the information. The processing unit 109 of the user system will request noise from the noise generator 107 of the user system. The noise generator will generate and send noise to the processing unit of the user system. Noise is used to mask the identity of the information in the transmission.

If the user has been previously authenticated by the client system, the user system may have a random Δ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 will also send a request to the verifier generator of the user system requesting the generation of a new beta key. Based on the request, the verifier generator will generate βkey1 (βk1) and βkey2 (βk2) using αk2 and δk1. The verifier generator 105 will send βk1 and βk2 to the processing unit 109 of the user system.

The processing unit of the user system will also access the storage unit 111 of the user system and request the generation of the Δ1 key and/or the session code. The storage unit 111 will provide the Δ1 key to the processing unit of the user system or will generate and provide the session code to the processing unit of the user system. For example, the processing unit 109 of the user system may request the random key generator 141 of the authentication system to generate a random Δ1 key and/or a session code and provide it to the processing unit 109, which processing unit 109 may generate a hash value for the provided δk1 or SC.

The processing unit of the user system may generate a human interaction code (MIC) using information obtained from each of the noise generator, the storage unit of the user system, and the verifier generator. The processing unit of the user system may send the MIC to the interaction unit 103 of the user system. The interaction unit 103 of the client display unit will display the MIC to the user.

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

As shown in fig. 13, once the user system creates the MIC, post-MIC data, and hash value, the processing unit 135 of the client system receives the post-MIC data and hash. The processing unit 135 of the client system transmits the hash value to be temporarily stored in the storage unit 133 of the client system. The post-MIC data is transmitted 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 one packet and transmits the packet 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 γ key (γk). The key generator of the client display unit sends γk to the processing unit 153 of the client display unit.

The user is now 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 interactive unit of the client display unit to the processing unit 153 of the client display unit. The processing unit 153 uses γ K, MIC and packets to make SC or δk1 available. The processing unit of the client display unit calculates a 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 processing unit of the client display unit may be temporarily stored in the temporary storage unit 155 of the client display unit at any time during the processing activity of the processing unit 153 of the client display unit.

The processing unit 135 of the client system retrieves the hash value temporarily stored in the storage unit 133 of the client system. The processing unit of the client system sends the hashed value of SC or δk1 and the value retrieved from memory 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, approval unit 139 confirms a match with processing unit 135 of the client system.

As shown in fig. 14, upon receiving the match confirmation, processing unit 135 of the client system requests a Client Session Access Pass (CSAP) from CSAP generator 131. CSAP generator 131 generates a CSAP that is sent to storage unit 133 of the client system to be temporarily stored. CSAP generator 131 also sends the CSAP to processing unit 147 of the authentication system. The processing unit 147 of the authentication system sends 153 the CSAP to the processing unit 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. Processing unit 135 of the user system sends the CSAP to approval unit 139 of the client system. The approval unit of the client system confirms the CSAP. The processing unit of the user system receives notification of such confirmation and operates to allow the user to access the secure portion of the client system.

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

CSAP generator 131 of the client system may be used to test conditions related to authentication of the user; by means of the generation of the CSAP, the user system and the client display unit process it periodically, and the CSAP is sent to the authentication system, the user system, the other processing units of the client display unit and stored in the storage units of the client system, the user system and the client display unit according to the method described herein. In any case where the approval unit of the client system determines that the authentication condition associated with the CSAP is not met, e.g., it is determined that the CSAP received by the processing unit of the client system does not match the stored CSAP, then the authentication of the user (i.e., CSAP authentication), the user device and the client display unit will be revoked, and access to the user, the user device, and the secure area of the client display unit will be terminated.

The CSAP conditions applied for authentication in embodiments of the present invention may include conditions related to any of the following conditions: dimension, geographic time, machine learning artificial intelligence, behavior, or any other condition.

Fig. 15 illustrates another embodiment of the invention in which a user uses a client display unit to attempt to validate a transaction by accessing a secure portion of a client system. The processing unit 153 of the client display unit sends a request to the processing unit 135 of the client system to verify the transaction. Based on such a request, the processing unit 135 of the client system sends a request to the challenge generator 137 of the client system to generate a challenge. Upon such a request, the client system's challenge generator 137 will generate a challenge, and may further apply a hash value to the result of the challenge, and store the solution and/or hash value in the client system's storage unit 133. The challenge generator of the client system sends the challenge to the processing unit 135 of the client system.

The processing unit 135 of the client system may apply symmetric and/or asymmetric encryption to the poll. 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 key provided thereto 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 a solution to the challenge. In another embodiment of the invention, the processing unit 153 of the client display unit may solve the decrypted challenge.

Once the user using the client display unit finds the solution of the challenge, the user solution 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 solution and the processing unit of the client display unit may further add a symmetric or asymmetric encryption to the hash value and/or solution. The processing results (e.g., hash values or encrypted hash values, or solutions or encrypted solutions) of the processing unit of the client display unit may be sent to the processing unit 135 of the client system. The processing unit 135 of the client system may send a request to the storage unit 133 of the client system to retrieve the stored solution and/or the stored hash value. Upon such a request, the storage unit 133 of the client system will retrieve the stored solution and/or the stored hash value and send the stored solution and/or the stored hash value to the processing unit 135 of the client system.

The processing unit 135 of the client system will decrypt any encrypted hash or encrypted de-and/or unencrypted hash that it received from the processing unit 153 of the client display unit. The processing unit 135 of the client system sends the hash value and/or solution (in unencrypted form) and the stored solution and/or stored has value it received from the processing unit 153 of the client display unit to the approval unit 139 of the client system for approval. The approval unit 139 of the client system compares the received solution with the stored solution and/or compares the received hash value with the stored hash value.

If the received solution and/or hash value matches the stored solution and/or hash value, approval unit 139 will send a confirmation of the match to processing unit 135 of the client system. If the match is positive, the processing unit 135 of the client system sends a confirmation of the positive match to the client system to confirm that the verification of the transaction has been successfully completed, and the client system will thereby authorize the transaction.

If the received solution and/or hash value does not match the stored solution and/or hash value, approval unit 139 will send a notification of the mismatch to processing unit 135 of the client system. The processing unit of the client system sends a notification to the client system and recommends that the client system not to verify the transaction.

In another embodiment of the invention, the processing unit of the authentication system may perform the functions described for the processing unit of the client system according to fig. 14. In such an embodiment of the invention, the challenge generator unit and the approving unit may be incorporated into the client system or the authentication system and will have the same functionality as described in relation to fig. 14 of the challenge generator unit 137 and the approving unit 139.

FIG. 16 illustrates another embodiment of the invention in which a user uses a user system to attempt to verify a transaction. In such an embodiment of the invention, the processing unit 109 of the user system sends a request from the processing unit 135 of the client system to verify the transaction. Based on such a request, the processing unit 135 of the client system sends a request to the challenge generator 137 to generate a challenge. Upon such a request, the challenge generator 137 will generate a challenge, and will further apply a hash value to the result of the challenge (solution of the challenge), and store the solution and/or hash value in the storage unit 133 of the client system.

The processing unit 135 of the client system may apply symmetric and/or asymmetric encryption to the poll. The processing unit 135 sends the challenge, which may be encrypted, to the processing unit 109 of the user system. If the challenge is encrypted, the processing unit 109 of the user system may decrypt the challenge and send 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 to find a solution to the challenge. In another embodiment of the invention, the processing unit 109 of the user system may solve the decrypted challenge.

Once the user finds the solution to the challenge, the user solution is sent to the processing unit 109 of the user system. The processing unit 109 of the user system may generate a hash value based on the user solution and the processing unit 109 of the user system may further add a symmetric or asymmetric encryption to the hash value and/or solution. The processing results (e.g., hash values or encrypted hash values and solutions or encrypted solutions) of the processing unit 109 of the user system may be sent to the processing unit 135 of the client system. The processing unit 135 of the client system may send a request to the storage unit 133 of the client system to retrieve the stored solution and/or the stored hash value. Upon such a request, the storage unit 133 of the client system will retrieve the stored solution and/or the stored hash value and send the stored solution and/or the stored hash value to the processing unit 135 of the client system.

The processing unit 135 of the client system will decrypt any cryptographic hashes or cryptographic solutions it receives from the processing unit 109 of the user system. The processing unit 135 of the client system sends the hash value and the solution it received from the processing unit 109 of the user system (in unencrypted form) and the stored solution and/or stored has value to the approval unit 139 of the client system for approval. The approval unit 139 of the client system compares the received solution with the stored solution and/or compares the received hash value with the stored hash value.

If the received solution matches the stored solution and/or the received hash value matches the stored hash value, then approval unit 139 will send a confirmation of the match to processing unit 135 of the client system. The processing unit 135 of the client system will send a confirmation of the match to the client system to confirm that the verification of the transaction has been completed and successful.

If the received solution matches the stored solution and/or the received hash value matches the stored hash value, the approval unit 139 will send a notification of the mismatch to the processing unit of the client system. The processing unit of the client system sends a notification to the client system and recommends that the client system not to verify the transaction.

In another embodiment of the invention, the processing unit of the authentication system may perform the functions described for the processing unit of the client system according to fig. 16. In such an embodiment of the invention, the challenge generator unit and the approving unit may be incorporated in the client system or the authentication system and will have the same functionality as described in relation to fig. 16 of the challenge generator 137 and the approving unit 139.

The system and network for authentication may include one or more first peers, one or more servers, and one or more second peers, each peer including at least one processor and a transmitter/receiver. The one or more first peers and the one or more second peers may additionally comprise respective memories. In some embodiments, each of the one or more first peers and the one or second peers may include a visual display. The one or more servers may also include a database.

The transmitter/receiver of each of the first peer, the second peer, and the server may be configured to transmit and receive information from an external source. In some embodiments, the first peer may be configured to send and receive information from the server, the server may be configured to send and receive information from the first peer and the second peer, and the second peer may be configured to send and receive information from the server. The memories of the first peer and the second peer and the database of the server may be configured to store information and allow retrieval of the information. The visual display may also include means for a user to interact with the display, such as entering data, selecting characters, selecting objects, and the like.

The processor of the first peer, the second peer, or the server may include a process mover, a data manipulator, a data converter, a process generator, and a process verifier. The process migration may be configured to migrate data from one component within the first peer, the second peer, or the server to another component within the first peer, the second peer, or the server. By way of example and not limitation, the process migration may be configured to move data from the memory of the first peer to the processor of the first peer or from the processor of the second peer to the transmitter/receiver of the second peer. The data manipulator may be configured to manipulate data, such as combine, separate and reassemble, reorder, etc. By way of example and not limitation, the data operator of the first peer may be configured to separate one or more strings into a first portion and a second portion, or the data operator of the server may be configured to combine the first portion of data with the second portion of data to produce a single data packet.

The data converter may be configured to convert the first string into a second string, wherein each of the first string and the second string may differ in any one or more of length, composition, or arrangement. In some embodiments, the data converter may be configured to apply a hashing algorithm to the first string. In other embodiments, the data converter may be configured to apply an encryption protocol to the first string character. In another embodiment, the data converter may be configured to apply a decryption protocol to the first string character. In other embodiments, the data converter may be configured to apply a hashing algorithm, an encryption protocol, a decryption protocol, or any other known data conversion method to the first string to produce the second string.

The process generator may be configured to generate data. In some embodiments, the data may include one or more strings of any length, and may include bar codes or the like. In some embodiments, the data may be generated in a random or directed manner. The process validator may be configured to compare two or more data and determine whether the data are the same or different. In some embodiments, the process verifier and the process generator may pair to determine whether the first string and the second string are identical and generate a response based on the identification of the first and second strings.

Verification methods may include a registration method 1700 and a user login method 2000. In some embodiments, the registration method 1700 may include creating one or more keys, assigning the one or more keys, storing the one or more keys on a local database, and storing the one or more keys on a server database. As shown in fig. 17, the registration method 1700 may also include communication between a first peer 1701, a server 1750, and at least one second peer 1775.

In some embodiments of the registration method 1700, the server 1750 may receive the registration request 1702 from the first peer 1701. The server 1750 may send registration data 1751 to the 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. The client registration code 1703 may be comprised of one or more characters, including letters, numbers, symbols, or any combination thereof, and may be generated by the server 1750. In other embodiments, the registration data includes a user selection object. In another embodiment, the registration data may include a combination of one or more client registration codes 1703, user selection objects, and any other data required for registration.

Registration method 1700 may also 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, the registration key 1707 is generated using the server key 1705, the client key 1706, and at least one client registration code 1703. Other embodiments may include different combinations of client key 1706, server key 1705, and client registration code 1703 for generating registration key 1707. Some information, such as the client key 1706, the client registration code 1703, may be stored in the memory 1708 of the first peer 1701. Further, the registration method 1700 may include sending information from the first peer 1701 to the server 1750. In some embodiments, registration key 1707 and server key 1705 are sent to server 1750.

Registration method 1700 may include receiving information from a first peer 1701 at server 1750. In some embodiments, the information received at server 1750 may include registration key 1707 and server key 1705. The server 1750 may generate the receiver code 1752. In addition, the server 1750 may generate the sender code 1754. Even further, server 1750 may generate allocation code 1756. Server key 1705, receiver code 1752, and sender code 1754 may be used to generate allocation key 1753. In some embodiments, allocation key 1753 may be generated by any one or more of server key 1705, receiver code 1752, or sender code 1754, or any combination thereof. Some information, such as receiver code 1752, distribution key 1753, may be stored in database 1757 of server 1750. Registration method 1700 may also include transmitting information from server 1750 to at least one second peer 1775. In some embodiments, allocation key 1753 and allocation code 1756 are transmitted to at least one second peer 1775.

Registration method 1700 may also include storing one or more keys on a local database. As shown in fig. 17, at least one second peer 1775 may receive information from a server 1750. In some embodiments, the information may include an allocation key 1753 and an allocation code 1756. The second peer may generate a registration code 1776. In addition, allocation key 1753 and registration code 1776 may be used to generate registration key 1777. In some embodiments, the registration key 1777 may be generated using only the allocation key 1753, only the registration code 1776, or any combination of the allocation key 1753 and the registration code 1776. Some information, such as allocation key 1753, deposit key 1777, allocation code 1756 may be stored in memory 1758 of second peer device 1775. Registration method 1700 may also include sending information from second peer 1775 to server 1750. In some embodiments, the registration key 1777 and allocation code 1756 are sent to server 1750.

Registration method 1700 may include receiving information from a second peer 1775 and storing the information in a local database. In some embodiments, server 1750 receives information from second peer 1775. The received information may include the registration key 1777, the allocation code 1756, and the server 1750 store information or other information needed to identify the second peer 1775.

Referring now to fig. 18, in accordance with some embodiments, creating one or more keys 1800 may occur in a first peer 1801. The first peer 1801 may be any IoT device, i.e., any device that may connect to a network and that is capable of transmitting data, including, but not limited to, a cell phone, a personal assistant, a button, a home security system, a device, etc. The first peer 1801 may request registration from the server 1850. According to some embodiments, the server 1850 may send registration data to the first peer 1801. The registration data may be received by the transmitter/receiver 1841 of the first peer 1801 and may include any data required to generate one or more keys 1800 at the first peer 1801. In some embodiments, the registration data may include a client registration code 1803. In other embodiments, the registration data may include the client registration code 1803 and additional data that may be a precursor to the user input 1804. The client registration code 1803 may include one or more strings of any length.

The user input 1804 may include any form of user-generated data including discrete units of information. In some embodiments, the user input 1804 includes biometric data, such as a fingerprint, iris, etc. In these embodiments, the biometric data may be partitioned into discrete units of information including identifiers. The identifier may be converted into a unique selection code 1809. In other embodiments, the user input 1804 may include any number of spatial and/or temporal data. The spatial and/or temporal data may be partitioned into discrete units of information containing identifiers. The identifier may be converted into a unique selection code 1809. In another embodiment, the user input 1804 may include a combination of biometric data and spatial and/or temporal data, each of which may be used to generate a unique selection code 1809.

In other embodiments, the user input 1804 may include one or more selection objects. The one or more selection objects may be images, icons, labels, buttons, or any other object that allows a user to select one or more selection objects from a set of selection objects. In some embodiments, the selection object may be received at the transmitter/receiver 1841, and the process shifter 1842 may shift the selection object to the visual display 1843. When a user makes a selection on the visual display 1843, the selection object may be converted into a selection code 1809, and the selection code 1809 may include any number of characters, such as letters, numbers, symbols. In a particular embodiment, the selection object is an image that may be received from the server 1850. Each image is assigned a unique selection code 1809, wherein user selection of a combination of selection objects results in user input 1804, said user input 1804 comprising a combination of selection codes 1809 unique to user selection of selection objects. In some embodiments, any combination of biometric data, spatial and/or temporal data, and selection objects may include user input 1804.

According to some embodiments, a user may generate a user input 1804 comprising two or more selection codes 1809, where the number of selection codes is equal to n. The data operator 1844 may be configured to divide the selection code into two or more groups. In some embodiments, the data manipulator 1844 may be configured to separate the selection codes 1809 into a first group 1810 and a second group 1811, wherein the first group 1810 is comprised between one and n-1 selection codes 1809 and the second group 1811 is comprised between one and n-1 selection codes 1809. Each of the selection codes 1809 in the first and

second groups

1810, 1811 may be individually converted to one or more strings by the data converter 1845, resulting in a first and second groups of converted

selection codes

1813, 1815. In some embodiments, converting 1812 may include using a hashing algorithm. In other embodiments, the conversion 1812 may include using an encryption method. However, other embodiments may include conversion 1812 using a combination of hashing algorithms and encryption methods. The first set of translated selection codes 1813 may be used to generate a client pre-key 1814. The individual transformed selection codes comprising the first set of transformed selection codes 1813 may be combined by a data operator 1844 to form one or more strings comprising the client pre-key 1814. In some embodiments, the selection codes of the individual translations are combined by a series of cells. The concatenation may include using each individually converted selection code as a unit, or may include using a segment of each individually converted selection code as a unit. Client pre-key 1814 may be converted 1812 to client key 1806 by data converter 1845. In some embodiments, converting 1812 may include using a hashing algorithm. In other embodiments, the conversion 1812 may include using an encryption method. However, other embodiments may include conversion 1812 using a combination of hashing algorithms and encryption methods. Client key 1812 may be stored by process migration 1842 in memory 1808 of first peer 1801.

A second set of transformed selection codes 1815 may be used to generate a server pre-key 1816. Individual conversion selection codes comprising second set of conversion selection codes 1815 may be combined by data operator 1844 to form one or more strings comprising server pre-key 1816. In some embodiments, the selection codes of the individual translations may be combined by a series of units. The concatenation may include using each individually converted selection code as a unit, or may include using a segment of each individually converted selection code as a unit. Server pre-key 1816 may be converted 1812 to server key 1805 by data converter 1845. In some embodiments, converting 1812 may include using a hashing algorithm. In other embodiments, the conversion 1812 may include using an encryption method. However, other embodiments may include conversion 1812 using a combination of hashing algorithms and encryption methods.

According to some embodiments, a registration key 1807 may be generated. The data manipulator 1844 may separate each of the client key 1806 and the server key 1805 into a client key first portion 1817, a client key second portion 1818, a server key first portion 1819, and a server key second portion 1820. In some embodiments, the client key 1806 may be divided into three or more portions. Also, the server key 1805 may be divided into three or more parts. The client key first portion 1817 and the client key second portion 1818 may include different portions of the characters that make up the client key 1806. In particular embodiments, each of client key first portion 1817 and client key second portion 1818 may be half of client key 1806. The server key first portion 1819 and the server key second portion 1820 may include different portions of the characters that make up the server key 1805. In particular embodiments, each of server key first portion 1819 and server key second portion 1820 may be half of server key 1805. The client key first portion 1817, the client key second portion 1818, the server key first portion 1819, and the server key second portion 1820 may be combined by the data operator 1844 in series through units to form one or more strings containing the first pre-key 1821. The connection of the data manipulator 1844 may include using each of the client key first portion 1817, the client key second portion 1818, the server key first portion 1819, and the server key second portion 1820 as a unit, or may include using the client key first portion 1817, the client key second portion 1818, the server key first portion 1819, and the server key second portion 1820 as a unit. Further, concatenation may include using any combination of parts generated by separating client key 1806 or server key 1805. First pre-key 1821 may be converted by data converter 1845 into one or more strings containing second pre-key 1822. In some embodiments, converting 1812 may include using a hashing algorithm. In other embodiments, the conversion 1812 may include using an encryption method. However, other embodiments may include conversion 1812 using a combination of hashing algorithms and encryption methods. The second pre-key 1822 may be used to generate a registration pre-key 1823. According to some embodiments, second pre-key 1822 and client registration code 1803 may be concatenated by data operator 1844 to form one or more strings containing registration pre-key 1823. Concatenating may include using each of the second pre-key 1822 and the client registration code 1803 as a unit, or may include using a fragment of the second pre-key 1822 and the client registration code 1803 as a unit. Registration pre-key 1823 may be converted 1812 by data converter 1845 to one or more strings containing registration key 1807. In some embodiments, converting 1812 may include using a hashing algorithm. In other embodiments, the conversion 1812 may include using an encryption method. However, other embodiments may include conversion 1812 using a combination of hashing algorithms and encryption methods.

The first peer 1801 may send information to a server 1850. According to some embodiments, the process migration 1842 of the first peer 1801 may migrate the registration key 1807 and the server key 1805 to the transmitter/receiver 1841 of the first peer 1801, and the first peer 1801 may send the registration key 1807 and the server key 1805 to the server 1850. In other embodiments, the transmitter/receiver 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 also include assigning one or more keys 1900. As shown in fig. 19, a transmitter/receiver 1941 of a server 1950 may receive information from a first peer 1901. According to some embodiments, the transmitter/receiver 1941 of the server 1950 may receive a registration key 1907 from the first peer 1901. The transmitter/receiver 1941 of the server 1950 may receive a server key 1905 from the first peer 1901. The transmitter/receiver 1941 of the server 1950 may receive a registration key 1907 and a server key 1905 from the first peer 1901. The process migration device 1942 may migrate the registration key 1907 and the server key 1905 to the processor of the server 1950. Registration key 1907 may be stored by process migration 1942 in database 1957 of server 1950. The processing generator 1946 of the server 1950 may generate a peer list 1958. Peer list 1958 may include a list of peers on the network, e.g., first peer 1901, second peer 1975. The peer list may also include a recipient code 1952 and an allocation code 1956, which may include one or more strings of any length. In addition, the processing generator 1946 of the server 1950 may generate a sender code 1954, which may also include one or more strings of arbitrary length.

According to some embodiments, the server 1950 may receive a registration key 1907 from the first peer 1901. Registration key 1907 may be used to generate any number of registration key subdivisions. The data manipulator may generate a registration key subsection from the registration key 1907. In these embodiments, registration key 1907 may contain any number of characters equal to n. Each registration key subsection may contain any number or combination of characters equal to n-1. Server 1950 may generate one or more random strings. Data operator 1944 may concatenate each registration subsection with one or more random strings. In some embodiments, the concatenated string may be converted 1912. Each generated or converted connection string may be sent to one or more second peers 1975.

The server 1950 may receive a server key 1908 from the first peer 1901. The server key 1908 may be used to generate any number of server key sub-portions. The data manipulator may generate a server key subsection from the server key 1908. In these embodiments, server key 1908 may contain any number of characters equal to n. Each server key subsection may contain any number or combination of characters equal to n-1. Server 1950 may generate one or more random strings. Each of the server key subsections may be connected by a data operator 1944 to one or more random strings. In some embodiments, the concatenated string may be converted 1912. Each generated or converted connection string may be sent to one or more second peers 1975.

The data operator 1944 of the server 1950 may generate a distribution pre-key 1959 by combining any combination of the server key 1905, the receiver code 1952, the sender code 1954, the distribution code 1956, or the registration key 1907. In some embodiments, the distribution pre-key consists of a server key 1905, a sender code 1954, and a receiver code 1952, which may be combined in series by units to form one or more strings. Concatenation may include using each of the server key 1905, the sender code 1954, and the receiver code 1952 as a unit, or may include using each of the server key 1905, the sender code 1954, and the receiver code 1952 as a unit. Distribution pre-key 1959 may be converted by data converter 1945 at 1912 into one or more strings containing distribution key 1953. In some embodiments, converting 1912 may include using a hashing algorithm. In other embodiments, the conversion 1912 may include using an encryption method. However, other embodiments may include conversion 1912 using a combination of hashing algorithms and encryption methods. The distribution key 1953 may be stored by the process migration device 1942 in a database 1957 of the server 1950. The server 1950 may be configured to send information to the second peer 1975. In some embodiments, the process migration 1942 of the server 1950 may migrate the distribution key 1953 and the distribution code 1956 to the transmitter/receiver 1941 of the server 1950. In other embodiments, the transmitter/receiver 1941 of the server 1950 may send the distribution key 1953, the distribution code 1956, and other information needed 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.

The server 1950 may generate more than one distribution key 1953 and send data to more than one second peer 1975. In some embodiments, peer list 1958 may include a list of more than one second peer 1975 on the network. The second peer may include any IoT device, server, or any device on the network capable of sending and receiving data from the server 1950. The server 1950 may generate a unique allocation code 1956 for the second peer 1975. The server 1950 may generate a unique recipient code 1952 for the second peer 1975. In these embodiments, the distribution key 1953 created for each second peer 1975 may be different from the distribution keys 1953 created for other second peers 1975, although the underlying server key 1905 received from the first peer 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, receiver code 1952, and server key 1905 may be used to generate pre-allocation key 1959.

Referring now to fig. 17, a registration method 1700 may include storing one or more keys on a local database. According to some embodiments, the second peer machine 1775 may be configured to receive and transmit information to the server 1750 via a transmitter/receiver of the second peer machine 1775. The second peer 1775 may receive the allocation key 1753 from the server 1750 via a transmitter/receiver of the second peer 1775. The second peer 1775 may receive the allocation code 1756 from the server 1750. In some embodiments, second peer 1775 may receive allocation key 1753 and allocation code 1756 from server 1750. The allocation key 1753 and allocation code 1756 may be stored in a memory 1778 of the second peer 1775. The second peer 1775 may generate a registered code 1776. The registration code 1776 may be one or more strings of any length and may be generated in a random manner. Alternatively, the check code 1776 may be generated by the server 1750 and received by the second peer 1775. The registration code 1776 and allocation key 1753 may be combined by concatenation of units to form one or more strings containing the registration pre-key 1779. Concatenation may include using each of the registered code 1776 and the allocation key 1753 as a unit, or may include using each of the registered code 1776 and the allocation key 1753 as a unit. The registration pre-key 1779 may be converted 1712 into one or more strings containing the registration key 1777. In some embodiments, the conversion 1712 may include using a hashing algorithm. In other embodiments, the conversion 1712 may include using an encryption method. However, other embodiments may include a transform 1712 that uses a combination of hashing algorithms and encryption methods. The registration key 1777 may be stored in the memory 1778 of the second peer 1775. In some embodiments, the second peer 1775 may send the registration key 1777 and the allocation code 1756 to the server 1750. In other embodiments, second peer 1775 may send registration key 1777, allocation code 1756, and any other information needed to register method 1700 to server 1750.

Registration method 1700 may also include storing one or more keys on a server database. As shown in fig. 19, a transmitter/receiver 1941 of the server 1950 may receive information from the second peer 1975. In some embodiments, the transmitter/receiver 1941 of the server 1950 can receive an allocation code 1956. In some embodiments, the transmitter/receiver 1941 of the server 1950 may receive the registration key 1977. In other embodiments, the transmitter/receiver 1941 of the server 1950 may receive an allocation code 1956 and a registration key 1977. In another embodiment, the transmitter/receiver 1941 of the server 1950 may receive the allocation code 1956, the registration key 1977, and any other information needed for the registration method. Distribution code 1956 and registration key 1977 may be stored by process migration 1942 in database 1957 of server 1950.

In particular embodiments, registration method 1700 may include creating one or more keys, assigning one or more keys, storing one or more keys on a local database, and storing one or more keys on a server database. As shown in fig. 17, the registration method 1700 may begin with a registration request 1702 from a first peer 1701. The registration request 1702 may be sent to and received by one or more servers 1750. One or more servers may send registration data 1751 to first peer 1701. Referring now to fig. 18, a particular embodiment may include a first peer 1801 receiving registration data from a server 1850. The registration data may include a client registration code 1803 and one or more selection objects. The client registration code 1803 may include a character string of 8-bit characters. The selection object may include a plurality of images. In particular embodiments, the selection object may include a plurality of selection objects equal to 60. Each selection object may contain a unique selection code 1809. The selection codes 1809 may include one or more strings, and in particular embodiments, each selection code may include a string of five characters. The user may select a plurality of selection objects from among the selection objects received from the server 1850. In a particular embodiment, the user may select six selection objects. User selection of a selection object may generate user input 1804 comprising a set of selection codes 1809, the selection codes 1809 may be selected by selecting a particular selection object associated with each selection code 1809. In a particular embodiment, the user input 1804 includes a six, five character selection code 1809.

The user inputs 1804 may be divided into a first group 1810 and a second group 1811. In particular embodiments, each of the first set 1810 and the second set 1811 includes three different selection codes 1809. Each selection code 1809 comprising a first set 1810 and a second set 1811 may be converted 1812 into one or more strings. In particular embodiments, each selection code 1809 may be transformed using a hashing algorithm, and may collectively include a first set of transformed selection codes 1813 and a second set of transformed selection codes 1815, respectively. Each of the first set of transformed selection codes 1813 and the second set of transformed selection codes 1815 may be combined to generate each of a client pre-key 1814 and a server pre-key 1816, respectively. In particular embodiments, three translated selection codes, including first set of translated selection codes 1813, may be concatenated to produce one or more strings containing client pre-key 1814. Likewise, three conversion selection codes comprising second set of conversion selection codes 1815 may be concatenated to produce one or more character strings containing server pre-key 1816. Client pre-key 1814 and server pre-key 1816 may convert 1812 to client key 1806 and server key 1805, respectively. In a particular embodiment, converting 1812 includes using a hashing algorithm.

The registration key 1807 may be generated using a combination of the client key 1806, the server key 1805, and the client registration code 1803. In particular embodiments, client key 1806 and server key 1805 are divided into

first portions

1817 and 1819 and second portions 1818 and 1820, respectively. The first pre-key 1821 may be formed by concatenating one or more strings, generated by combining any portion of the client key 1806 with any portion of the server key 1805. First pre-key 1821 may convert 1812 into one or more strings containing second pre-key 1822. In a particular embodiment, converting 1812 includes using a hashing algorithm. Registration pre-key 1823 may be generated by combining client registration code 1803 and second pre-key 1822 by concatenating to form one or more strings. Registration pre-key 1823 may be converted into registration key 1807, where converting 1812 includes using a hashing algorithm. In particular embodiments, the client key 1806 and client registration code 1803 may be stored in memory 1808 of the first peer 1801. Further, the server key 1805 and registration key 1807 may be transmitted to one or more servers 1850.

The registration method may include assigning one or more keys. In the particular embodiment shown in fig. 19, the server 1950 may receive a registration key 1907 and a server key 1905 from the first peer 1901. The registration key may be stored in a database 1957 of the server 1950. The server 1950 may generate a peer list 1958, which may include a second peer list 1975 on the network. For each of the second peers 1975, the server 1950 may generate a recipient code 1952 and an allocation code 1956. In particular embodiments, the recipient code 1952 and the distribution code 1956 are unique to a particular second peer 1975 and a particular transaction. In addition, the server 1950 may generate sender code 1954 unique to the particular server 1950. In particular embodiments, receiver code 1952, sender code 1954, and server key 1905 may be combined in series to produce one or more strings containing an assigned pre-key 1959. Distribution key 1959 may be converted to distribution key 1953 at 1912. In particular embodiments, converting 1912 may include using a hashing algorithm. In some embodiments, multiple unique distribution keys 1953 may be generated, each key including a different recipient code 1952, and having a different associated distribution code 1956 from the peer list 1958, where each unique distribution key 1953 may ultimately be sent to a different second peer 1975. In particular embodiments, multiple unique distribution keys 1953 are generated from the same server key 1905, and each unique distribution key 1953 is sent over the network to a separate second peer 1975.

The registration method may also include storing one or more keys on a local database, as shown in fig. 17. In particular embodiments, second peer 1775 may receive allocation key 1753 and allocation 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 to receive the allocation key 1753 and the allocation code 1756 from the same transaction between the first peer 1701 and the server 1750 described above. The second peer 1775 may store the allocation key 1753 and the allocation code 1756 in a memory 1778 of the second peer 1775. In addition, the second peer 1775 may generate a registered code 1776. In a particular embodiment, the register code 1776 includes a single string of 8 characters. The registration code 1776 and the allocation key 1753 may be combined in concatenation to produce one or more strings containing the registration pre-key 1779. Registered pre-key 1779 may be converted 1712 to registered pre-key 1777. In a particular embodiment, the conversion 1712 includes using a hashing algorithm. The second peer 1775 may send information to one or more servers 1750. In particular embodiments, a plurality of second peer machines 1775 may send information to server 1750. The information may include allocation code 1756, registration key 1777, and any other information needed to perform registration process 1700.

Registration method 1700 may include storing one or more keys on a server database. In some embodiments, the server 1750 may be configured to receive information from one or more second peer machines 1775. In particular embodiments, server 1750 may receive information from a plurality of second peer machines 1775, including allocation code 1756 and registration key 1777. Server 1750 may store allocation code 1756 and key 1777 in database 1757. Referring now to FIG. 19, the allocation code 1956 and the registration key 1977 may be stored in a peer list 1958 stored in a database 1957. In particular embodiments, distribution code 1956 and registration key 1977 are paired with stored distribution key 1953 and receiver code 1952, and stored distribution key 1953 and receiver code 1952 may be specific to transactions conducted between first peer 1901, server 1950, and specific second peer 1975.

The authentication method may include a login method as shown in fig. 20. The login method 2000 may include creating one or more login keys, assigning one or more authentication keys, authenticating authentication keys in a local database, and authenticating an authentication 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.

The login method 2000 may include a first peer 2001, where the first peer may be configured to interact with a user. The first peer 2001 may request a login 2002, and the login request 2002 may be sent to the one or more servers 2050. The server 2050 may receive the login request 2002 and generate login data 2051. In some embodiments, the login data 2051 may include a login salt 2024. The login salt may be comprised of one or more characters including letters, numbers, symbols, or any combination thereof. In some embodiments, login data 2051 may include a user-selected object. In other embodiments, the login data 2051 may include one or more login salt 2024 and user-selected objects, as well as any other data required by the login method 2000.

Creating one or more login keys may also 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, the server key 2005, the client key 2006, and at least the login salt 2024 may be used to generate the login key 2099. Other embodiments may include different combinations of client key 2006, server key 2005, and login salt 2024 for generating login key 2099. Some information, such as the client key 2006, login salt 2024, may be stored in the memory 2008 of the first peer 2001. Further, creating one or more login keys may include sending information from the first peer 2001 to the server 2050. In some embodiments, login key 2099 and server key 2005 are sent to server 2050.

As shown in fig. 20, assigning one or more authentication keys may include receiving information from a first peer 2001 at a server 2050. In some embodiments, the information received at server 2050 may include login key 2099 and server key 2005. The server 2050 may generate a recipient code 2052. In addition, the server 2050 may generate a sender code 2054. Even further, the server 2050 may generate an allocation code 2056. The server key 2005, the receiver code 2052, and the sender code 2054 may be used to generate the authentication key 2062. In some embodiments, the authentication key 2062 may be generated by one or more of the server key 2005, the recipient code 2052, the authentication salt 2024, or the sender code 2054, or any combination thereof. Some information, such as the recipient code 2052, the authentication key 2062, may be stored in a database 2057 of the server 2050. In some embodiments, the authentication key 2062 may not be stored in the database 2057 of the server 2050. Assigning one or more authentication keys may also include sending information from server 2050 to at least one second peer 2075. In some embodiments, the authentication key 2062 and the assignment code 2056 are transmitted to at least one second peer 2075.

The login method 2000 may also include verifying one or more verification keys on the local database. As shown in fig. 20, at least one second peer 2075 may receive information from the server 2050. In some embodiments, the information may include an authentication key 2062 and an allocation code 2056. In other embodiments, the information may include a verification key 2062, a distribution code 2056, and a verification salt 2063. The second peer 2075 may use any combination of the allocation code 2056 and the authentication key 2062 to locate and confirm that the corresponding allocation key may be stored in the memory 2078 of the second peer 2075. The stored distribution key may be used to generate a validation key 2081. In some embodiments, the storage allocation key 2053 and the validation salt 2063 received from the server 2050 may be used to generate the validation key 2081. The second peer 2075 may send information to the server 2050, which server 2050 may include any combination of an acknowledgement key 2081, an allocation code 2056, and any other information that may be needed to log in to the method 2000.

Validating the authentication process may include receiving information from the second peer 2075 and comparing the received information with information stored in the database 2057 of the server 2050. In some embodiments, server 2050 receives information from second peer 2075. The received information may include validation key 2081, results, assignment code 2056, and server 2050 to store or compare information or other information needed to identify second peer 2075.

As shown in fig. 21, according to some embodiments, creating one or more login keys 2100 may occur in the first peer 2101. The first peer 2101 may be any IoT device, i.e., any device that may connect to a network and that is capable of transmitting data, including but not limited to a cell phone, a personal assistant, a button, a home security system, a device, etc. The first peer 2101 may request login from the server 2150. According to some embodiments, the transmitter/receiver of the server 2150 may send login data to the first peer 2101. The login data may be received by the transmitter/receiver 2141 of the first peer 2101 and may include any data required to initiate a login method at the first peer 2101. In some embodiments, the login data may include login salt 2124. In other embodiments, the login data may include login salt 2124 and additional data that may be a precursor to user input 2104. The login salt 2124 may include one or more strings of any length.

As shown in fig. 21, the user input 2104 may include any form of user-generated data including discrete units of information. In some embodiments, the user input 2104 includes biometric data, such as a fingerprint, iris, or the like. In these embodiments, the biometric data may be partitioned into discrete units of information including identifiers. The identifier may be converted into a unique selection code 2109.

In other embodiments, the user input 2104 may include one or more selection objects. The one or more selection objects may be images, icons, labels, buttons, or any other object that allows a user to select one or more selection objects from a set of selection objects. The selection object may be displayed on the visual display 2143 of the first peer 2101 and may be converted into a selection code 2109, the selection code 2109 may include any number of characters, e.g., letters, numbers, symbols. In a particular embodiment, the selected object is an image that may be received from server 2150. Each image is assigned a unique selection code 2109, wherein a user selection of a combination of selection objects results in a user input 2104, the user input 2104 comprising a combination of selection codes 2109 unique to the user selection of a selection object.

According to some embodiments, a user may generate a user input 2104 comprising two or more selection codes 2109, wherein the number of selection codes is equal to n. The selection codes 2109 may be separated by the data manipulator 2144 into a first set 2110 and a second set 2111, where the first set 2110 includes between one and n-1 selection codes 2109 and the second set 2111 includes between one and n-1 selection codes 2109. Each of the selection codes 2109 of the first set 2110 and the second set 2111 may be individually converted into one or more character strings by the data converter 2145, thereby producing a first set of converted selection codes 2113 and a second set of converted selection codes 2115. In some embodiments, converting 2112 may include using a hashing algorithm. In other embodiments, the conversion 2112 may include using an encryption method. However, other embodiments may include a transformation 2112 using a combination of hashing algorithms and encryption methods. The first set of transformed selection codes 2113 may be used to generate a client pre-key 2114. The individual transformed selection codes comprising the first set of transformed selection codes 2113 may be combined by the data operator 2144 to form one or more character strings containing the client pre-key 2114. In some embodiments, the selection codes of the individual translations may be combined by a series of units. The concatenation may include using each individually converted selection code as a unit, or may include using a segment of each individually converted selection code as a unit. Client pre-key 2114 may be converted to client key 2106 by data converter 2145. In some embodiments, converting 2112 may include using a hashing algorithm. In other embodiments, the conversion 2112 may include using an encryption method. Other embodiments may include a transformation 2112 using a combination of hashing algorithms and encryption methods. The client key 2106 may be stored by the process migrate 2147 in the memory unit 2108 of the first peer 2101. 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 registration process of the identity.

The second set of transformed selection codes 2115 may be used to generate a server pre-key 2116. The individual transformed selection codes comprising the second set of transformed selection codes 2115 may be combined by the data operator 2144 to form one or more character strings containing the server pre-key 2116. In some embodiments, the selection codes of the individual translations may be combined by a series of units. The concatenation may include using each individually converted selection code as a unit, or may include using a segment of each individually converted selection code as a unit. Server pre-key 2116 may be converted 2112 to server key 2105 by data converter 2145. In some embodiments, converting 2112 may include using a hashing algorithm. In other embodiments, the conversion 2112 may include using an encryption method. However, other embodiments may include a transformation 2112 using a combination of hashing algorithms and encryption methods.

According to some embodiments, a login key 2199 may be generated. The data manipulator 2144 may separate each of the client key 2106 and the server key 2105 into a client key first portion 2117, a client key second portion 2118, a server key first portion 2119, and a server key second portion 2120. The client key first portion 2117 and the client key second portion 2118 may include different portions of characters that make up the client key 2106. In particular embodiments, each of client key first portion 2117 and client key second portion 2118 may be half of client key 2106. The server key first portion 2119 and the server key second portion 2120 may include different portions of the characters that make up the server key 2105. In particular embodiments, each of server key first portion 2119 and server key second portion 2120 may be half of server key 2105. The client key first portion 2117, the client key second portion 2118, the server key first portion 2119, and the server key second portion 2120 may be combined by the data operator 2144 through concatenation of units to form one or more strings containing the first pre-key 2121. Concatenating may include using each of the client key first portion 2117, the client key second portion 2118, the server key first portion 2119, and the server key second portion 2120 as a unit, or may include using each of the client key first portion 2117, the client key second portion 2118, the server key first portion 2119, and the server key second portion 2120 as a unit.

The first pre-key 2121 may be converted 2112 by the data converter 2145 into one or more strings containing the second pre-key 2122. In some embodiments, converting 2112 may include using a hashing algorithm. In other embodiments, the conversion 2112 may include using an encryption method. However, other embodiments may include a transformation 2112 using a combination of hashing algorithms and encryption methods. The second pre-key 2122 may be used to generate a registration pre-key 2123. According to some embodiments, the second pre-key 2122 and the client registration code 2103 may be concatenated by the data manipulator 2144 to form one or more strings containing the registration pre-key 2123. Concatenating may include using each of the second pre-key 2122 and the client registration code 2103 as a unit, or may include using a fragment of the second pre-key 2122 and the client registration code 2103 as a unit. During the registration process, the process migrate 2142 may store the client registration code 2103 in the memory 2108 of the first peer 2101. Registration pre-key 2123 may be converted 2112 by data converter 2144 into one or more strings containing registration key 2107. In some embodiments, converting 2112 may include using a hashing algorithm. In other embodiments, the conversion 2112 may include using an encryption method. However, other embodiments may include a transformation 2112 using a combination of hashing algorithms and encryption methods. In some embodiments, the registration key 2107 may be the same as the registration key 1707 generated by the first peer 1701 during the registration method 1700, as shown in fig. 17. Returning to fig. 21, registration key 2107 may be used to generate registration key 2199. In some embodiments, the registration key 2107 and the login salt 2124 are used to generate the login key 2199. The registration key 2107 and the login salt 2024 may be connected by the data manipulator 2144 to form one or more strings containing the login pre-key 2198. Concatenation may include using each of the registration key 2107 and the login salt 2024 as a unit, or may include using a fragment of the registration key 2107 and the login salt 2024 as a unit. The login pre-key 2198 may be used to generate a login key 2199. In some embodiments, the login pre-key 2198 may be converted to a login key 2199 by the data converter 2145. In some embodiments, converting 2112 may include using a hashing algorithm. In other embodiments, the conversion 2112 may include using an encryption method. However, other embodiments may include a transformation 2112 using a combination of hashing algorithms and encryption methods.

The first peer 2101 may send information to the server 2150. According to some embodiments, the transmitter/receiver 2141 of the first peer 2101 may send the login key 2199 and the server key 2105 to the server 2150. In other embodiments, the transmitter/receiver 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 comprise assigning one or more authentication keys. As shown in fig. 22, the server 2250 may receive information from the first peer 2201. According to some embodiments, the transmitter/receiver 2241 of the server 2250 may receive the login key 2299 from the first peer 2201. The transmitter/receiver 2241 of the server 2250 may receive the server key 2205 from the first peer 2201. The transmitter/receiver 2241 of the server 2250 may receive the login key 2299 and the server key 2205 from the first peer 2201. In some embodiments, server 2250 may generate comparison login key 2260. The comparison login key 2260 may be generated using the registration key 2207 stored in the database 2257 of the server 2250 during the registration method. The process migrate 2242 of the server 2250 may migrate the registration key 2207 and the login salt2224 from the database 2257. The data manipulator 2244 of server 2250 may combine the registration key 2207 and the login salt2224 in series to generate a comparison login pre-key. The data converter 2245 may convert the comparison login pre-key 2212 into a comparison login key 2260. In some embodiments, the conversion 2212 may include using a hashing algorithm. In other embodiments, the conversion 2212 may include using encryption methods. However, other embodiments may include a transformation 2212 using a combination of hashing algorithms and encryption methods. The process verifier 2247 of server 2250 may compare the comparison login key 2260 with the login key 2299 sent by the first peer 2201 to determine whether communication with the first peer 2201 is possible.

The process migration 2242 may store the login key 2299 in the database 2257 of the server 2250. The server may access a previously stored peer list 2258 using the data mover 2242. The stored peer list 2258 may include a list of peers on the network, e.g., first peer 2201, second peer 2275. The peer list may also include recipient code 2252 and allocation code 2256, which may include one or more strings of any length. In addition, the processing generator 2246 of the server 2250 may generate the sender code 2254, which may also include one or more character strings of arbitrary length.

The data manipulator 2244 of server 2250 may generate distribution pre-key 2259 by combining any combination of server key 2205, recipient code 2252, sender code 2254, distribution code 2256, or login key 2299. In some embodiments, distribution pre-key 2259 is made up of server key 2205, sender code 2254, and receiver code 2252, which keys may be combined by concatenation of units to form one or more strings. Concatenation may include using each of the server key 2205, the sender code 2254, and the receiver code 2252 as a unit, or may include using fragments of the server key 2205, the sender code 2254, and the receiver code 2252 as a unit. Distribution pre-key 2259 may be converted 2212 by data converter 2245 into one or more strings containing distribution key 2253. In some embodiments, the conversion 2212 may include using a hashing algorithm. In other embodiments, the conversion 2212 may include using encryption methods. However, other embodiments may include a transformation 2212 using a combination of hashing algorithms and encryption methods. Distribution key 2253 may be stored in database 2257 of server 2250. The authentication pre-key 2261 may be generated by the data operator 2244 of the server 2250. In some embodiments, an allocation key 2253 and authentication salt 2263 generated by the processing generator 2246 of server 2250 and containing any number of characters may be concatenated to generate authentication pre-key 2261. Authentication pre-key 2261 may be converted 2112 to authentication key 2262 by data converter 2245. In some embodiments, the conversion 2212 may include using a hashing algorithm. In other embodiments, the conversion 2212 may include using encryption methods. However, other embodiments may include a transformation 2212 using a combination of hashing algorithms and encryption methods.

The server 2250 may be configured to send information to the second peer 2275. In some embodiments, the transmitter/receiver 2241 of the server 2250 may send the authentication key 2262 and the allocation code 2256 to the second peer 2275. In other embodiments, the transmitter/receiver 2241 of the server 2250 may send the authentication key 2262, the allocation code 2256, the authentication salt 2263, and other information required for the login method 2000 to the second peer 2275. In some embodiments, server 2250 may send any combination of distribution key 2253, authentication salt 2263, and distribution code 2256 to second peer 2275.

The server 2250 may generate a plurality of authentication keys 2262 and send the data to a plurality of second peers 2275. In some embodiments, peer list 2258 may include a list of more than one second day peer 2275 on the network. The second peer may include any IoT device, server, or any device on the network capable of sending and receiving data from the server 2250. The server 2250 may generate a unique allocation code 2256 for each second peer 2275. The server 2250 may generate a unique recipient code 2252 for each second peer 2275. In these embodiments, the authentication key 2262 created for each second peer 2275 may be different from the authentication keys 2262 created for the other second peers 2275, although the underlying server key 2205 received from the first peer 2201 may be the same. The authentication key 2262 may or may not be stored in the database 2257 of the server 2250.

Referring now to fig. 23, a login method may include verifying one or more login keys on a local database. The second peer 2375 may be configured to receive information and send the information to the server 2350. The transmitter/receiver 2341 of the second peer 2375 may receive the authentication key 2362 from the server 2350. The transmitter/receiver 2341 of the second peer 2375 may receive the allocation code 2356 from the server 2350. In some embodiments, the transmitter/receiver 2341 of the second peer 2375 may receive the authentication key 2362, the allocation code 2356, and the authentication salt 2363 from the server 2350. The process verifier 2347 may compare the allocation code 2356 to all allocation codes 2356 stored in the memory 2378 of the second peer 2375. If the allocation code 2356 received from the server 2350 is the same as the allocation code 2356 stored in the memory 2378 of the second peer 2375, then the processing generator 2346 of the second peer 2375 may produce a positive result 2382. If the allocation code 2356 received by the second peer 2375 is not the same as the allocation code 2356 stored in the memory 2378 of the second peer 2375, then the processing generator 2346 of the second peer 2375 may produce a negative result 2382. In some embodiments, the verification key 2362 is also used to locate the same allocation code 2356. If the second peer 2375 determines that one or more allocation codes 2356 stored in the memory 2378 of the second peer 2375 are the same as the allocation codes 2356 received from the server 2350, then the process migration 2342 of the second peer 2375 may remove the allocation key 2353 associated with the matched allocation codes 2356 from the memory 2378. The distribution key 2353 and validation salt 2363 removed from the memory 2378 of the second peer 2375 may be used by the data operator 2344 to generate a validation pre-key 2380 by concatenating. Validation pre-key 2380 may be converted 2312 into validation key 2381 by data converter 2345. In some embodiments, the conversion 2312 may include the use of a hashing algorithm. In other embodiments, the conversion 2312 may include the use of encryption methods. However, other embodiments may include a conversion 2312 using a combination of hashing algorithms and encryption methods.

In some embodiments, the second peer 2375 may receive the distribution key and authentication salt2363 from the server 2350. The second peer 2375 may generate the authentication key 2362 at the second peer 2375 by concatenating the distribution key and the authentication salt2363 to generate an authentication pre-key. Authentication pre-key 2312 may be converted to authentication key 2362.

In some embodiments, the second peer 2375 may generate a comparison verification key 2383. The second peer 2375 may generate a comparison verification key 2383 by concatenating the stored allocation key 2353 and the verification salt2363 received from the server 2350 to generate a comparison verification pre-key. The comparison verification pre-key may be converted into comparison verification key 2312. In some embodiments, the process verifier 2347 may compare the comparison verification key 2383 to the received verification key 2362 and may generate a result 2382. In some embodiments, results 2382 may include results from comparing verification key 2362 to comparison verification key 2383, and results from comparing received allocation code 2356 to stored allocation code 2356. The validation key 2381 may be generated by the authentication salt2363 and the storage key 2377 retrieved from the memory 2378 of the second peer 2375. The registration key 2377 and validation salt2363 may be concatenated by the data operator 2344 to generate a validation pre-key 2380. Validation pre-key 2380 may be converted 2312 to validation key 2381. Any combination of acknowledgement key 2381, allocation code 2356 and result 2382 may be sent from second peer 2375 to server 2350.

The second peer 2375 may be configured to send data to the server 2350. In some embodiments, the transmitter/receiver 2341 of the second peer 2375 may send any combination of the result 2382, the allocation code 2356, and the validation key 2381 to the server 2350. In some embodiments, the second peer 2375 may be configured to delete all data associated with the transaction. In particular embodiments, second peer 2375 may delete allocation code 2356, registration key 2377, allocation key 2353, authentication key 2362, authentication salt 2326, validation pre-key 2380, and validation key 2381 from memory 2378 of second peer 2375 or from the processor of second peer 2375. In some embodiments, the deletion of data may occur simultaneously with the transmission of the data to the server 2350. In other embodiments, the data deletion may occur after the data is sent to the server 2350.

Referring now to fig. 24, the login method may further include validating the authentication process 2400. Server 2450 can be configured to receive data from one or more second peers 2475. In some embodiments, the transmitter/receiver 2441 of the server 2450 can receive any combination of the validation key 2481, the result 2482, and the allocation code 2456. Server 2450 can confirm the results 2482 received from second peer 2475. In the affirmative case, the process validator 2447 of the server 2450 can compare the allocation code 2456 received from the second peer 2475 with all or some of the allocation codes 2456 stored in the database 2457 of the server 2450. If the allocation code 2456 stored in the database 2457 of the server 2450 is the same as the allocation code 2456 received from the second peer 2475, the process migration 2442 of the server 2450 can retrieve any combination of the authentication salt 2463 and the allocation key 2453, which can be associated with the allocation code 2456 and stored in the database 2457 of the server 2450. In some embodiments, the retrieved distribution key 2453 may be the distribution key 2453 stored during the enrollment process. Data operator 2444 can generate authentication pre-key 2461 by concatenating authentication salt 2463 and distribution key 2453 using retrieved authentication salt 2463 and retrieved distribution key 2453. The authentication pre-key 2461 may be converted 2412 into an authentication key 2462 by the data converter 2445. In some embodiments, converting 2412 may include using a hashing algorithm. In other embodiments, the conversion 2412 may include using an encryption method. However, other embodiments may include the conversion 2412 using a combination of a hashing algorithm and an encryption method.

The process verifier 2447 of the server 2450 can compare the generated verification key 2462 with the validation key 2481 received from the second peer 2475 and the process generator 2246 can generate the verification result 2464. If the authentication key 2462 is the same as the validation key 2481 received from the second peer 2475, the result may be affirmative, e.g., the authentication was successful. If the authentication key 2462 is different from the validation key 2481 received from the second peer 2475, the authentication result 2464 may be negative, such as a failed authentication or threat. The process migration 2442 of the server 2450 can store the validation results 2464 in the database 2457. In some embodiments, the validation result 2464 is stored with the associated distribution key 2453 generated during the enrollment method.

Server 2450 can send new distribution key 2453 to one or more second peers 2475. Referring now to FIG. 19, the server 1950 can generate a new peer list 1958 in a database 1957 of the server 1950. In some embodiments, the server 1950 may allocate any combination of the new recipient code 1952 and the new allocation code 1956 and use any combination of the new recipient code 1952 and the new allocation code 1956 to generate a new allocation key 1953 in a manner similar to allocating one or more allocation keys 1900. The server 1950 may send the newly generated distribution key 1953 to a second peer 1975, the second peer 1975 being different from the second peer 1975 that previously stored the distribution key 1953.

The network authentication method may include generating a bar code, generating one or more keys, and establishing a network session. Further, the network authentication system may include one or more of a first device, a second device, a first server, a second server, and communication between the internet application. The one or more first devices, second devices, first server, and second server may include at least one processor and a transmitter/receiver. The one or more first devices and the one or more second devices may additionally include respective memories. In some embodiments, each of the one or more first devices and the one or second devices may include a visual display. Each of the one or more first devices and the one or more second devices may include means for scanning a bar code. The one or more first servers and the second server may additionally include a database.

The first device, the second device, the first server, and the transmitter of the second server may be configured to send and receive information from an external source. In some embodiments, the first device may be configured to send and receive information from any combination of the second device, the first server, and the second server. The first server and the second server may be configured to send and receive information from the first device and the second device, and the second device may be configured to send and receive information from the first server, the first device, and the second server. The memories of the first device and the second device and the database of the server may be configured to store information and allow retrieval of information. The visual display may also include means for a user to interact with the display, such as entering data, selecting characters, selecting objects, and the like. The internet application may be configured to send or receive information from any combination of the first server, the second server, the first device, and the second device.

The processors of the first device, the second device, the first server, and the second server may include a process migration device, a data operator, a data converter, a process generator, and a process verifier. The process migration may be configured to migrate data from one component within the first device, the second device, or the first or second server to another component within the first device, the second device, or the first or second server. By way of example and not limitation, the process migration may be configured to 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 transmitter/receiver of the second device. The data manipulator may be configured to manipulate the data, e.g., combine, separate, segregate and reassemble, reorder, etc. For example, and without limitation, the data operator of the first device may be configured to separate one or more strings into a first portion and a second portion, or the data operator of the server may be configured to combine the first portion of data with the second portion of data to produce one or more strings.

The data converter may be configured to convert the first string to a second string, wherein each of the first string and the second string may differ in any one or more of length, composition, or arrangement. In some embodiments, the data converter may be configured to apply a hashing algorithm to the first string. In other embodiments, the data converter may be configured to apply an encryption protocol to the first string character. In another embodiment, the data converter may be configured to apply a decryption protocol to the first string character. In other embodiments, the data converter may be configured to apply a hashing algorithm, an encryption protocol, a decryption protocol, or any other known data conversion method to the first string to produce the second string.

The process generator may be configured to generate data. In some embodiments, the data may include one or more strings of any length, and may include bar codes or the like. In some embodiments, the data may be generated in a random or directional manner. The process validator may be configured to compare two or more data and determine whether the data are the same or different. In some embodiments, the process validator and the process generator may pair to determine whether the first string and the second string are identical and generate a response based on the identification of the first and second strings.

The network authentication method may include generating a bar code, as shown in fig. 25. The bar code 2500 may be generated beginning at the internet application 2590. In some embodiments, the user may use the login request to begin generating bar code 2500 at internet application 2590. The first negotiation protocol pair 2646 may be generated by a process generator 2646. In some embodiments, the first negotiation protocol pair 2646 may be generated by a process generator 2646 at the internet application 2590. The first key agreement protocol pair 2526 may include any key agreement protocol pair readily known to one 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. The process migrate 2642 may send information to the transmitter/receiver 2541 of the internet application 2590. Internet application 2590 may send any combination of first public key 2503, first private key 2504, and any other information needed to generate barcode 2505.

In some embodiments, first server 2525 may be configured to receive information from internet application 2590. The transmitter/receiver 2541 of the first server 2525 may receive any combination of the first public key 2503, the first private key 2504, and any other necessary information for generating the bar code 2500 from the internet application 2590. The first server 2525 may generate a random key 2527, and the random key 2527 may be generated by a processing generator 2646 of the first server 2525. Random key 2527 may include one or more strings of any length, and characters may include letters, numbers, and symbols. In some embodiments, a bar code 2505 may be generated. The process generator 2546 can use the barcode precursors to generate the barcode 2505. The bar code 2505 may comprise any type of bar code 2505 including, but not limited to, any linear bar code, two-dimensional bar code, or any type of readable indication readily known to one of ordinary skill in the art. In some embodiments, the barcode 2505 may include a QR code. The bar code 2505 may be generated from any combination of the first public key 2503, the first private key 2504, the random key 2527, and any other information needed to generate the bar code 2500. In particular embodiments, bar code 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. The first server 2525 may be configured to send information to the internet application 2590. In some embodiments, the transmitter/receiver 2541 of the first server 2525 may send information to the internet application 2590. In particular embodiments, first server 2525 may send bar code 2505 to internet application 2590. The internet application 2590 may receive the bar code 2505 at the transmitter/receiver 2541 and the bar code 2505 may be displayed at the visual display 2590 of the internet application 2590.

The network authentication method may include generating one or more keys as shown in fig. 26, 27 and 28. Referring now to fig. 26, generating one or more keys 2600 can include scanning a first device 2650 of a barcode 2605. The data operator 2644 of the first device 2650 may generate a random key 2627, a first public key 2603, or both the random key 2627 and the first public key 2603 from information contained in the barcode 2605. To generate one or more keys 2600, the data operator 2644 may extrapolate any information contained in the barcode 2605. Further, the processing generator 2646 of the first device 2650 may generate a second key agreement protocol pair 2651. The second key agreement protocol pair 2651 may include any key agreement protocol pair readily known to one 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, the second key agreement protocol pair 2651 may include a second private key 2652 and a second public key 2653. The second private key 2652 and the first public key 2603 inferred from the barcode 2605 may be combined by the data manipulator 2644 to generate a key 2654. The processing generator 2646 of the first device 2650 may generate any combination of salt 2655, initialization vector 2656, and iteration number 2657. In particular embodiments, processing generator 2646 of first device 2650 may generate each of salt 2655, initialization vector 2656, and iteration number 2657. The salt 2655, initialization vector 2656, and iteration number 2657 may each include one or more strings of any length, and the characters may include any combination of letters, numbers, or symbols. Initialization vector 2656 may include a number of characters equal to n, and may additionally include IV first portion 2658 and IV second portion 2659. The IV first portion 2658 and the IV second portion 2659 may each contain a number of characters between one and n-1. The iteration number 2657 may include a number of characters equal to n, and further include an IN first portion 2660 and an IN second portion 2661. The IN first portion 2660n and the IN second portion 2661An may each contain a plurality of characters between 1 and n-1. The data manipulator 2644 may generate an IV first portion 2658 and an IV second portion 2659 from the 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, keys 2654, salt 2655, IV first portion 2658, and IN first portion 2660 may be converted 2612 by data converter 2645 into masking keys 2662, masking salt 2663, masking IV first portion 2664, and masking IN first portion 2665, respectively. In some embodiments, initialization vector 2656 may be converted 2612 to mask IV first portion 2664 by data converter 2645. Likewise, iteration number 2657 may be converted 2612 by data converter 2645 to mask IV first portion 2665. In some embodiments, converting 2612 may include using a hashing algorithm. In other embodiments, the conversion 2612 may include using an encryption method. However, other embodiments may include the conversion 2612 using a combination of a hashing algorithm and an encryption method. IN some embodiments, the iteration number 2657 may remain intact, the IN first portion 2660 is not generated, the IN second portion 2661 is generated, and the generated IN first portion 2660 may not be converted 2612.

The processing generator 2646 of the first device 2650 may generate a client key 2666. Client key 2666 may include one or more strings of any length, and the characters may include any combination of letters, numbers, or symbols. According to some embodiments, the client key 2666 may be converted 2612 by the data converter 2645 to a first masked client key 2667. In other embodiments, the client key 2667 may be converted 2612 by the data converter 2645 to a second masked client key 2668. In another embodiment, the client key 2666 may be converted 2612 into each of the first masking client key 2667 and the second masking client key 2668 by the data converter 2645. The conversion 2612 may include using a hashing algorithm. In addition, the conversion 2612 may include using an encryption method. In some embodiments, the conversion 2612 may include a combination of a hashing algorithm and an encryption method. The first device 2650 may be configured to send information to the first server 2625. IN some embodiments, the transmitter/receiver 2641 of the first device 2650 may send any combination of the first masking client key 2667, the second masking client key 2668, the masking key 2662, the masking salt 2663, the masking IV first portion 2664, and the masking IN first portion 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 visual display 2669 of the first device 2650. In a particular embodiment, the iteration number 2657 may be displayed entirely on the visual display 2669 of the first device 2650.

Referring now to fig. 27, generating one or more keys may include first server 2725 receiving information from first device 2750. IN some embodiments, the transmitter/receiver 2741 of the first server 2725 may receive any combination of the masking key 2762, the second masking client key 2768, the masking salt 2763, the masking IV first portion 2764, the masking IN first portion 2765, and the first masking client key 2767 from the first device 2750. IN some embodiments, the process migration 2742 of the first server 2725 may store one or more masking keys 2762, second masking client keys 2768, masking salt 2763, masking IV first portion 2764, masking IN first portion 2765, and first masking client keys 2767 received from the first device 2750 IN a database 2729 of the first server 2725. According to particular embodiments, the process migration 2742 of the first server 2725 may store the first masking client key 2767 in the database 2729 of the first server 2729.

The first server 2725 may be configured to send information to the internet application 2790. IN some embodiments, the transmitter/receiver 2741 of the first server 2725 may send any combination of the masking key 2762, the second masking client key 2768, the masking salt 2763, the masking IV first portion 2764, the masking IN first portion 2765, and the first masking client key 2767 to the first server 2725. IN a particular embodiment, the transmitter/receiver 2741 of the first server 2725 may send the masking key 2762, the second masking client key 2768, the masking salt 2763, the masking IV first portion 2764, and the masking IN first portion 2765 to the first server 2725. In other embodiments, the transmitter/receiver 2741 of the first server 2725 may send any combination of the masking key 2762, the second masking client key 2768, the masking salt 2763, and the masking IV first portion 2764 to the internet application 2790 (collectively referred to from this point forward as "receive data 2728").

As shown in fig. 28, generating one or more keys 2800 may include a transmitter/receiver 2841 of an internet application 2890 receiving received data 2828 from a first server 2825 transmitter. The first device 2850 may include a user input 2869, which may include an IV second portion 2659 and an IN second portion 2661 (see fig. 26), which may each include a string of characters. User input 2869 may include the IV first portion and the iteration number. In some embodiments, the user input 2869 may be displayed on the graphical display 2869 of the first device 2850. Generating one or more keys may include user input 2869 into internet application 2890. The data converter 2844 of the internet application 2890 may convert the data 2828 received by 2812 into one or more of a key 2854, an IN first portion 2860, a salt2855, an IV first portion 2858, and a client key 2866. Converting 2812 may include using a hashing algorithm. Additionally, the conversion 2812 may include the use of encryption methods. The conversion may include using a decryption method. In some embodiments, the transform 2812 may include any combination of a hashing algorithm, an encryption method, or a decryption method. According to some embodiments, the data converter 2844 of the internet application 2890 may use the user input 2869 and the received data 2828 to convert 2812 received data 2828 into one or more of a key 2854, an IN first portion 2860, a salt2855, an IV first portion 2858, and a client key 2866. The process migration 2842 may store the client key 2866 in memory 2891 of the internet application 2890. Data converter 2845 of internet application 2890 may convert 2812 client key 2866 into third masking client key 2892. In some embodiments, third masking client key 2892 may be migrated by process migration 2842 to transmitter/receiver 2841 of internet application 2890. The transmitter/receiver 2841 of the internet application 2890 may send the third masking client key 2892 to the first server 2825.

The network authentication method may include establishing a network session. As shown in fig. 29, the transmitter/receiver 2941 of the first server 2825 may receive the third masking client key 2992 from the internet application 2990. According to some embodiments, the process migration 2942 of the first server 2825 may retrieve the stored first masking client key 2967 from the database 2929 of the first server 2825. The process verifier 2947 may compare the retrieved first masking client key 2967 to a third masking client key 2992 received from the internet application 2990. The processing generator 2946 may generate a result 2930 based on the identification of the first masking client key 2967 and the third masking client key 2992. The transmitter/receiver 2941 of the first server 2825 may send the result 2930 to the second server 2980. The transmitter/receiver 2941 of the second server 2980 may receive the result 2930 from the first server 2825 and generate the network token 2931. The network token 2931 may be generated by the process generator 2946. In some embodiments, the network token 2931 may be any means known in the art for authorizing establishment of a network session. Second server 2980 may send generated network token 2931 to first server 2825. The transmitter/receiver 2941 of the first server 2825 may receive the network token 2931 from the second server 2980 and may send the received network token 2931 to the internet application 2990. The transmitter/receiver 2941 of the internet application 2990 may receive the network token 2931 from the first server 2825.

In some embodiments, the internet application may send the received network token to the second server. The second server may receive the network token from the web browser and may establish the web session. Further, the second server may be configured to send information to the first server. In some embodiments, the second server may send information regarding the receipt of the network token from the internet application. Information about receiving a network token from an internet application may include, but is not limited to, any information about the internet application, information about a user of the internet application, information about accessing a web session, spatial and/or temporal information about any component of the system described herein. The first server may receive information from the second server regarding the receipt of the network token. In some embodiments, the first server may be configured to send information to the first device, including, but not limited to, information about receiving the network token.

Generating keys to protect sensitive data

It should be understood that any of the methods, systems, components, and/or embodiments disclosed in any portion of this disclosure may be combined with any of the other methods, systems, components, and/or embodiments that occur in any other portion of this disclosure. The biometric features may be incorporated as code, information, data, or the like in any of the embodiments described herein.

In some embodiments, a key (e.g., a private key) may be generated to protect the content of the sensitive data transmission. For example, if the first data includes sensitive information such as biometric data, sensitive communications, etc., the use of the controlled corruption generation key may provide a smart way in which the sensitive data (e.g., the first data) may be protected from interception by a third party. The sensitive data (e.g., first data) may include a variety of data types such as, but not limited to, biometric characteristic data, documents, text messages, email messages, or other types of sensitive communications.

According to some embodiments, systems and methods of generating a key (e.g., a private key) using controlled corruption may include one or more computing devices (e.g., a first computing device, a second computing device, a third computing device, etc.) and one or more servers. The one or more servers may include a security engine, an action engine, and one or more libraries. In some embodiments, the one or more servers may further include a client tier that includes one or more computing devices (e.g., a first computing device, a second computing device, etc.) that may include a mobile platform and one or more libraries. The computing device (e.g., first computing device, second computing device, etc.) may be any server or any internet of things device, i.e., any device that is capable of connecting to a network and having data transmission capabilities, including but not limited to a cell phone, personal assistant, button, home security system, appliance, etc.

Fig. 30 is an exemplary system for generating keys using controlled corruption 3000 in accordance with a particular embodiment. The system may include a network layer 3010 having a first computing device 3012, a management layer 3020 having one or more servers 3022, and a client layer 3030 having one or more servers 3022. The system 3000 may also include one or more communication channels (e.g., an internet gateway and one or more Virtual Private Network (VPN) channels) shown in dashed lines.

The network layer 3010 may also include a management mobile platform (AMP) 3014 having a management mobile library (AML) and a Partner Mobile Library (PML) and a management network platform (AWP) 3016 having a management network library (AWL) and a partner network library (PWL). Any library may refer herein to, but is not limited to, any application, application database, and/or data.

The management layer 3020 may also include a management security engine (ASE) 3024, an Action Engine (AE) 3026, a management partner library (APL) 3028, and one or more nodes 3029 associated with the management layer. The one or more nodes 3029 may include one or more databases, one or more user devices (e.g., computing devices), or any combination of one or more databases and one or more user devices (e.g., computing devices).

The client layer 3030 may also include a management client library (ACL) 3034 and a Client Server Application (CSA) 3036. In some embodiments, the client layer 3030 and the management layer 3020 may communicate with each other via a VPN channel.

Fig. 31 is a method 3100 of generating keys (e.g., in a management layer 3020) using an example server side with controlled corruption, according to one particular embodiment, the method may include: registering, at the one or more servers, the first computing device (step 3140); at the one or more servers, receiving a first privacy code and one or more parameters associated with first data from the first computing device (step 3142); generating, at the one or more servers, a block count and a public key (step 3143); transmitting the block count and public key to the first computing device (step 3144); at the one or more servers, receiving a plurality of first private keys and second private codes (step 3146); and generating, at the one or more servers, second data based on the private key (step 3148).

The step 3140 of registering the computing device (e.g., the first computing device) may include installing one or more applications on the computing device, wherein the one or more applications may include a mobile platform and one or more libraries. In some embodiments, the computing device and one or more applications may include a network layer of a system for generating private keys. The computing device may be in communication (e.g., network communication, internet communication, virtual private network (VPN communication)) with one or more servers, which may include a management layer. A detailed discussion of the different communication methods can be found in the foregoing sections of this specification. According to some embodiments, registration of a computing device located in a network layer may include initiating communication and information transmission between a management layer (e.g., ASE), a client layer (e.g., CSA), and a network layer (e.g., AML and/or AWL located in the computing device).

One or more servers located in the management layer may receive a first privacy code and one or more parameters associated with the first data from a computing device (e.g., a first computing device) (step 3142). As described above, the first data may include any data (e.g., biometric data, documents, messages, etc.) that the user may wish to protect in the transmission. The one or more parameters associated with the first data may include any information about the first data including, but not limited to, a device identifier, a camera identifier, a file size, a data format, an application identifier, a user identifier, a personal identifier, metadata, and the like. In some embodiments, the one or more parameters associated with the first data may include a file size, a public key associated with the asymmetric key pair (which may identify the source of the first data), and a processed version of the first data (e.g., a compressed or "zipped" version of the data). In some embodiments, the parameters associated with the first data may include compressed (e.g., sized) first data of the base 64 version. The privacy code may include an alphanumeric and/or symbol string associated with a user of the computing device or a source of the first data. In a particular embodiment, the privacy code is a first user input containing a personal identifier (e.g., a PIN) selected by a user of the computing device. The privacy code may be generated based on user input, such as an encrypted version, a hashed version, a truncated version, or a rearranged version of the user input. In some embodiments, the privacy code may be automatically generated by a system component (e.g., a server, a first computing device, etc.). In some embodiments, the privacy code may include and/or may be generated based on a digital footprint of the user. In these embodiments, the user's digital footprint may include information about the user's digitized habits, including, but not limited to, browsing history, number of browses/duration/frequency, usage habits, application usage, purchasing habits, geographic location data, and the like.

One or more servers located in the management layer may generate a block count, a block name, and a public key 3143 associated with the APL. The block count and the block name may be generated based at least in part on the received parameters associated with the first data. According to some embodiments, the block count may be an integer indicating a downstream process of generating the private key. The block name may be an alphanumeric and/or symbolic identifier that may be associated with one or more private keys generated in a downstream process. In some embodiments, the block count is generated based on a parameter associated with the first data (e.g., one or more of a size of the first data, a size of the compressed first data, or a size of the compressed first data that has been converted to a base 64 file). The block name may be generated based on the block count. For example, in the case where the block count is an integer equal to three, three block names are generated, each designed to be associated with a downstream private key. As another example, in the case where the generated block count is equal to 7, 7 block names are also generated. In a downstream step, seven private keys are generated and each of the seven private keys is assigned a block name. The public key may be associated with an asymmetric key pair associated with an APL located in the management layer. The block count, block name, and public key may be sent from one or more servers located in the management layer to computing devices located in the network layer.

According to some embodiments, a quantity of private keys (based on one or more of the first data, the block count, the block name, and the privacy code) may be generated by a computing device included in a network layer of a system for generating the private keys. Fig. 32 illustrates a computing device-side method 3200 of generating a private key, in accordance with some embodiments.

A computing device 3212 (e.g., a first computing device) located in a network layer of the system may receive the block count 3260, the block name 3261, and the public key 3262 from one or more servers located in a management layer of the system. As described above, the first data 3263 may include any data that a user deems secure and wishes to protect in transmission. In some embodiments, the computing device 3212 may compress (e.g., zip) the first data 3263 to generate compressed first data 3264. The computing device 3212 may generate base64 encoded compressed first data 3265, wherein the base64 encoded compressed first data 3265 comprises a base64 version of the compressed first data 3264. Using controlled corruption (e.g., controlled file corruption), the computing device 3212 may generate a first pre-key 3267 by adding a corruption code (e.g., first corruption code 3266) to the base64 encoded compressed first data 3265. As described above, the corruption code 3266 may comprise a string of alphanumeric and/or symbolic characters. In a specific embodiment, the first corruption code 3266 may be generated based on a formula. For example, the first corruption code 3266 may be generated by the computing device 3212 by summing the first 30 characters contained in the base64 encoded compressed first data 3265. In another particular embodiment, the first corruption 3266 may be generated by summing first and third characters contained in the base64 encoded compressed first data 3265, summing second and fourth characters contained in the base64 encoded compressed first data 3265, summing third and fifth characters contained in the base64 encoded compressed first data 3265, and the like, and concatenating the results to generate a digital character string, such that the digital character string may include the first corruption 3266. Multiple formulas may be used to generate the corruptions (e.g., first corruption 3266, second corruption 3268, third corruption 3273, etc.), such that the possible options are not limited to the above examples.

The computing device 3212 may generate a second pre-key 3269 by adding a corruption code (e.g., a second corruption code 3268) to the first pre-key 3267. In particular embodiments, the corruption code (e.g., second corruption code 3268) may include one or more alphanumeric and/or symbolic characters contained in the user-entered privacy code. In some embodiments, the corruption code (e.g., the second corruption code 3268) may comprise one or more alphanumeric and/or symbol characters contained in the privacy code after processing (e.g., hashing, encrypting, rearranging, truncating, etc.) of the user input. In a specific embodiment, the second corruption code 3268 may be generated based on a formula.

The computing device 3212 may generate a salt (salt) 3270 and an Initialization Vector (IV) 3271. A detailed discussion of salts 3270 and IV 3271 can be found in the previous section of this specification. Salt 3270 and IV 3271 may be added to second pre-key 3269 to generate third pre-key 3272. It should be appreciated that such additions (e.g., salt 3270 and IV 3271) are not always present when generating the private key, and that according to some embodiments, second pre-key 3269 may be used to generate block 3274 based on block count 3260 without adding salt 3270, IV 3271, or third corruption 3273.

A third corruption code 3273 may be added to the third pre-key 3272. The third corruption code 3273 may be generated by the computing device 3212 in any manner for the above-described corruption codes (e.g., first corruption code 3266, second corruption code 3268). In a particular embodiment, the third corruption code 3273 may be generated based on a formula. In some embodiments, a third corruption code 3273 is added to the third pre-key 3272 and the resulting string is then divided into blocks 3274 based on a block count 3260 received from the management layer. As described above, block count 3260 is an integer indicating the number of blocks 3274 generated in the method of generating key 3200. For example, with a block count 3260 equal to 3, the computing device 3212 divides the pre-key (e.g., third pre-key 3272, second pre-key 3269, third pre-key 3272 with third corruption 3273) into three blocks 3274.

In some embodiments, third pre-key 3272 may be divided into blocks 3274, which blocks 3274 may then be used to generate private key 3275 without using third corruption code 3273. In some embodiments, the third pre-key 3272 may be divided into blocks 3274 and one or more third corruptions 3273 (or first corruptions, second corruptions, etc.) that may be added to the blocks 3274 to generate the private key.

Block 3274 may be named according to block name 3261 to generate private key 3275. According to some embodiments, the block name 3261 may be generated at the management layer and received at a computing device 3212 located in the network layer. As described above, the block name 3261 may be generated based at least in part on information received as part of a parameter associated with the first data (e.g., the initial packet). In a particular embodiment, the number of received block names 3261 is equal to block count 3260. For example, where the block count 3260 is equal to three, three block names 3261 may be generated at the management layer and received at the computing device 3212. Thus, in this embodiment, three blocks 3274 would be generated (based on block count 3260), and each resulting block 3274 would have an associated block name 3261. In some embodiments, block 3274 is associated with a single block name 3261 to generate a private key 3275 containing block 3274, which block 3274 has block name 3261. According to these embodiments, the block name 3261 is used to organize the private key 3275 in a downstream process to regenerate the first data 3263 (e.g., the second data) at the server side.

To illustrate the above, the following examples are provided. In the case where the third pre-key 3272 includes a string '123456789' and the third corruption 3273 includes a string '543', the string resulting from the controlled corruption may include a string '123455436789'. If block count 3260 is equal to 3, and the block names are "one", "two", and "three", the resulting private key may include the following:

Block name	Private key string
		' one ' of '	‘123’
'two'	‘4554’
		'three'	‘36789’

According to some embodiments, the block name 3261 may facilitate downstream ordering of the private key 3275 to regenerate the initial string. At this time, by sorting the private keys 3275 according to the block names 3261 (e.g., "one", "two", "three"), the initial character string "123455436789" can be newly generated at the server (e.g., management layer) side.

The computing device 3212 located in the network layer may send a plurality (equal to the block count 3260) of private keys 3275 to one or more servers located in the management layer. The computing device 3212 may generate a second privacy code 3277 based on the first privacy code 3276. According to some embodiments, the second privacy code 3277 may be an alphanumeric and/or symbol string. The second privacy code 3277 may be the first privacy code 3276 after processing (e.g., compressing, hashing, encrypting, rearranging, truncating, etc.). According to a particular embodiment, the second privacy code 3277 is a hashed first privacy code 3276. The privacy codes (e.g., first privacy code 3276, second privacy code 3277) may be sent from the computing device 3212 located in the network layer of the system to one or more servers located in the management layer of the system.

Referring back now to fig. 31, a method of generating a key using controlled corruption may include receiving a quantity of a private key and a second privacy code from a computing device (step 3146), and generating second data based on the private key (step 3148).

Fig. 33 illustrates a particular embodiment 3300 of generating second data based on a private key. According to some embodiments, the second data 3382 may include a reconstructed version of the first data. For example, the first data may originate from a computing device located in a network layer of the system. The first data may be used to generate a private key 3375, which private key 3375 may be a corrupted version of the first data that may then be sent to one or more servers located in the management layer in a corrupted block (e.g., private key). The private key 3375 may be concatenated and the corruptions (e.g., first corruption 3366, second corruption 3368, third corruption 3373, etc.) removed in sequence such that the resulting second data 3382 is a reconstructed version of the original first data.

One or more servers 3322 located in the management layer of the system may receive a plurality of (e.g., one or more, two or more, three or more) private keys 3375 from computing devices located in the network layer of the system. The one or more servers 3322 may receive the second privacy code 3377 from the computing device. According to some embodiments, the one or more servers 3322 may connect a plurality of (e.g., one or more, two or more, three or more) private keys 3375 to generate a keychain 3376. According to some embodiments, and as described above, the block name 3361 may direct the connection process, may determine the proper order of connecting the private keys 3375, or may direct the arrangement of the private keys 3375 to generate the keychain 3376.

The one or more servers 3322 may remove the third corruption 3373 to generate the first clean data 3377, remove the salt 3370 and the initialization vector 3371 to generate the second clean data 3378, remove the second corruption 3368 to generate the third clean data 3379, and remove the first corruption 3366 to generate the base64 encoded compressed second data 3380. According to some embodiments, removing the corruption code may require identifying the corruption code that needs to be removed (e.g., first corruption code 3366, second corruption code 3368, third corruption code 3373, etc.). In these embodiments, one or more servers may use different identification tools to identify corrupt codes. For example, if the corruption code is generated at the computing device using a privacy code (or a derivative of a privacy code, such as a truncated privacy code), the one or more servers may generate the privacy code 3377 based on the received second privacy code. In a particular embodiment, the second privacy code 3377 is used to remove one or more corruptions (e.g., first corruptions 3366, second corruptions 3368, third corruptions 3373, etc.). In some embodiments, the one or more servers 3322 use a formula to generate corruption (e.g., the same formula used to generate corruption at the computing device) and use the newly generated corruption to identify and remove corruptions embedded in the cleaning data (e.g., the first cleaning data 3377, the second cleaning data 3378, the third cleaning data 3379, etc.). Importantly, one feature of the one or more servers 3322 is the ability to identify corruptions (e.g., first corruptions 3366, second corruptions 3368, third corruptions 3373, etc.) in the keychain 3376 or cleaning data (e.g., first cleaning data 3377, second cleaning data 3378, third cleaning data 3379, etc.) and remove them in sequence to generate base64 encoded compressed second data 3380. In some embodiments, the keychain 3376 may be decrypted to generate the first cleaning data 3377.

The base 64 file of the compressed second data 3380 may be converted (e.g., decoded) to compressed second data 3381. According to some embodiments, the compressed second data 3381 may be converted (e.g., unipressed) into second data 3382. As described above, the second data 3382 may be a reconstructed version of the first data. For example, where the first data is information about a biometric scan, the second data will be a reconstructed version of the original information about the biometric scan. Where the first data is a sensitive email, text or other communication, the second data is a reconstructed version of the sensitive email, text or other communication. As such, one of ordinary skill in the art will appreciate that any method or operation performed by one or more servers located in the management layer may also be performed by a processor located in the second computing device. For example, if the first data is a text message originating from a mobile device that contains the first computing device, the second data (e.g., a reconstructed text message) may be generated at a processor located in a second mobile device (e.g., a second computing device).

Authentication using private key

According to some embodiments, the private key may be used to verify an identity from a first computing device (e.g., a mobile computing device). In some embodiments, the first data may include a biometric scan, a login password, or a login code, or any other first data that may be based on user input. A method of generating a private key using controlled corruption, and allocating, storing, and/or retrieving stored private keys to verify identity may involve a registration module and a login module.

Registration module. Methods of generating keys (e.g., private keys) using controlled corruption and assigning and storing keys for later use may involve a registration module. With the methods and systems disclosed herein, a private key may be generated based on first data using controlled corruption and sent to a server and stored on a plurality of nodes associated with the server. When the user subsequently types in his user input (e.g., biometric scan, password, first data, third data, etc.) to the first computing device in the login module, the use-controlled corruption and the private key generated based on the user input in the module may be compared to the private key generated using the first data in the login module so that the user identity may be verified. By generating a private key using controlled corruption, user input, such as biometric feature data, may be protected.

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

When the generated private key is used for a purpose such as authentication, the method of generating one or more private keys is generally the same as the method shown in fig. 31, 32, and 33 discussed above. In addition to the methods described above, the method 3400 may also include generating a result (step 3450). According to some embodiments, a base64 file of compressed second data (e.g., 3380 of FIG. 33) may be compared to a base64 file of compressed first data, where the base64 file of compressed first data may be received as parameters associated with first data ((e.g., 3142 of FIG. 31). In these embodiments, the two base64 files may be compared such that a result may be generated (step 3450). If the two base64 files are the same, the result may be yes. If the two base64 files are different, the result may be no.

In some embodiments, the compressed second data 3381 may be compared to the compressed first data to generate a result (step 3450). In some embodiments, the second data 3382 may be compared to the first data to generate a result (step 3450). In some embodiments, the result may be generated by comparing a plurality of elements (e.g., first and second data, compressed first data and compressed second data, base64 encoded compressed first data and base64 encoded compressed second data, etc.). Iterative learning may be utilized when generating the results (step 3450). For example, a plurality of second data 3382 may be generated over time, and then these second data 3382 may be compared with each other over time to generate a result (step 3450). Although second data 3382 is used as an example, the result may be generated by comparing any element (e.g., first data, compressed data, base64 encoded compressed data, privacy code, etc.) (step 3450).

In some embodiments, the result is that one or more servers located in the management layer may be prompted to generate a recipient identifier and a privacy code identifier (step 3452). The result is that one or more servers located in the management layer may be prompted to generate two or more copies of each private key received from the computing device 3446. The private key, recipient identifier, and privacy code identifier may be sent to one or more nodes associated with the one or more servers for storage (step 3454). In some embodiments, the private key, recipient identifier, and privacy code identifier may be processed prior to transmission.

The private key may be distributed to one or more storage nodes (step 3454) using a non-ledger-type non-descriptive distribution. Such an allocation method may include generating a unique segment description for each private key using the sender identifier as well as the receiver identifier, the privacy code, and/or other user-specific code (e.g., biometric features, etc.). According to some embodiments, the sender identifier may be an alphanumeric and/or symbol string used to identify any combination between users, transactions, applications, and/or computing devices. In these embodiments, the system may process one or more of the private key, the privacy code, the recipient identifier, and the sender identifier to generate a unique segment description for each private key assigned. According to some embodiments, the segment descriptions may be created "on demand" such that there is no need to keep a ledger or other record of private key distribution destinations (e.g., nodes) on the server.

Even if a hacker/virus can break through the guard (e.g., firewall and other security functions) and enter the system, the central location or account does not store the endpoint addresses (of the data allocation), thereby ensuring that the hacker cannot learn the location of the nodes or which nodes have specific data.

This way of distribution ensures that a hacker cannot identify the individual pieces that make up the data, even if the node is collapsed. This also provides protection against the lux software and has a high fault tolerance. In addition, the processing (e.g., encryption, hashing, corruption, chunking, connecting, etc.) process ensures another level of security such that even if segments are obtained from a node, the segments cannot be spliced together in their original form without the consent of an authorized user.

The private key, recipient identifier and privacy code identifier may be stored for later use, including authentication in the login module.

Login module. When a user (e.g., a system user at a computing device at the network layer) wishes to verify a login mode using a stored private keyUpon identity in the block, the user enters a first user input (e.g., a privacy code) and a second user input (e.g., biometric scan, third data). Fig. 35 illustrates a method of verifying identity using a private key.

A third data based private key 3590 is generated in the same manner as described above and shown in fig. 31 and 32. The resulting private key 3590 is sent to one or more servers located in the management layer of the system. The one or more servers locate and retrieve the stored private key 3591 from one or more nodes associated with the one or more servers by utilizing information contained in one or more of the private key, the private code, the second private code, and parameters associated with the first data. In some embodiments, the retrieval is based at least in part on the recipient identifier and/or the privacy code identifier.

Fourth data is generated in the same manner as shown in fig. 33 using each private key 3590 based on third data (e.g., a private key received from a computing device during a login module). According to some embodiments, the fourth data may be login data 3592. Each stored private key 3591 retrieved from one or more nodes is used to generate fifth data 3593 in the same manner as shown in fig. 33. According to some embodiments, the fifth data may be registration data 3593. The fourth data (e.g., login data 3592) may be compared to the fifth data (e.g., registration data 3593) to generate a result 3594. According to some embodiments, if fourth data 3592 is the same as fifth data 3593, then result 3594 is yes. In an embodiment in which the data (e.g., first data, second data, third data, fourth data 3952, fifth data 3593) is information about any of biometric feature scan, privacy code, login password, etc., if the fourth data 3952 (e.g., data entered during login) is the same as the fifth data (e.g., data entered during login and stored as a private key), the identity may be confirmed. The result is that a user may be allowed access to one or more protected systems.

Storing secure data using private keys

In some embodiments, the private key may be used to store secure data. For example, in some embodiments, the first data may include a sensitive document. The first data may be used in the manner described above to generate a private key, which may then be stored. In these embodiments, it may be necessary to edit the security data (e.g., first data, sensitive document). In these embodiments, the private key may be retrieved and the second data generated in the manner described above. The system allows temporary storage of data (e.g., first data, second data) in a landing zone (landing zone) for editing. In some embodiments, the landing zone may be located in 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 contain an external application, such as Google Docs, microsoft Word, or other applications. The edited data may then be used to generate a new set of private keys in the manner described above so that the set of private keys may be stored for later use.

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

Claims

1. A method of processing a key generated using controlled corruption, the method comprising:

registering, at one or more servers, the first computing device, the one or more servers including a security engine and an action engine;

at the one or more servers, receiving a first privacy code from the first computing device and one or more parameters associated with first data, the first privacy code generated based on a first user input at the first computing device, and the first data generated based on a second user input at the first computing device;

generating, at the one or more servers, a block count and a public key, wherein the block count is generated based on one or more parameters associated with the first data, and the public key is part of an asymmetric key pair;

transmitting the block count and the public key from the one or more servers to the first computing device;

receiving, at the one or more servers, data associated with a plurality of private keys and a second privacy code from the first computing device, wherein:

the private key is generated based on the first data, the block count and one or more corruptions,

The second privacy code is generated based on the first privacy code, and

the number of private keys is equal to the block count;

generating, at the one or more servers, second data based on the private key, the generating second data comprising the steps of:

concatenating the private key to generate a keychain

The one or more corruptions are removed from the keychain to generate the second data.

2. The method of claim 1, further comprising:

generating, at the one or more servers, two or more block names; and

the two or more block names are sent to the first computing device.

3. The method of claim 2, wherein the private key is generated further based on the two or more block names.

4. A method according to claim 3, wherein the private key is concatenated based on the two or more block names to generate a keychain.

5. The method of claim 1, wherein the one or more corruptions comprise three corruptions.

6. The method of claim 5, wherein at least one of the corrupt codes is generated based on the first privacy code.

7. The method of claim 6, wherein removing the one or more corruptions to generate the second data comprises:

removing one or more first corruptions from the keychain to generate first clean data;

removing one or more second corruptions from the first clean data to generate second clean data;

removing one or more third corruptions from the second clean data to generate base 64 encoded compressed data;

decoding base encoding of the compressed second data to generate compressed data; and

decompressing the compressed data to generate second data, wherein the privacy code is used to remove at least one of the one or more first corruptions, the one or more second corruptions, and the one or more third corruptions.

8. The method of claim 6, wherein the first privacy code is used to remove at least one of the corrupt codes.

9. The method of claim 1, wherein the second privacy code is used to remove at least one of the corrupt codes.

10. The method of claim 1, wherein the first data comprises directional communications.

11. The method of claim 1, wherein the second user input comprises at least one of an alphanumeric string, biometric feature data, a password, an eye scan, a photograph, and a fingerprint.

12. A method of generating a key using controlled corruption, the method comprising:

at a first computing device, generating a first privacy code and one or more parameters associated with first data, the first privacy code generated based on a first user input and the first data generated based on a second user input;

transmitting the first privacy code and the one or more parameters associated with the first data from the first computing device to one or more servers;

at the first computing device, receiving a block count and a public key from the one or more servers, wherein the block count is generated based on the one or more parameters associated with the first data, and the public key is part of an asymmetric key pair;

at the first computing device, compressing the first data to generate compressed first data;

generating, at the first computing device, a first pre-key based on the compressed first data and one or more corruptions codes;

generating, at the first computing device, a second pre-key based on the first pre-key and one or more second corruptions;

Generating, at the first computing device, two or more blocks based on the second pre-key and a block count;

generating, at the first computing device, two or more private keys based on the two or more blocks; and

the two or more private keys are sent to the one or more servers.

13. The method of claim 12, wherein the generating two or more blocks based on the second pre-key and the block count comprises:

corrupting the second pre-key with salt to generate a third pre-key;

corrupting the third pre-key using one or more third corruptions codes;

the corrupted third pre-key is divided into two or more blocks based on the block count.

14. The method of claim 12, further comprising receiving, at the first computing device, two or more block names.

15. The method of claim 14, wherein the two or more private keys are also generated based on the two or more block names.

16. A method of generating and distributing keys using controlled corruption, the method comprising:

registering, at one or more servers, a first computing device;

Generating, at the one or more servers, a block count and a public key, wherein the block count is generated based on the one or more parameters associated with the first data, and the public key is part of an asymmetric key pair;

receiving, at the one or more servers, data associated with a plurality of first private keys and a second privacy code from the first computing device, wherein:

the first private key is generated based on the first data, the block count and one or more corrupt codes,

the second privacy code is generated based on the first privacy code, and

the number of the first private keys is equal to a block count;

generating, at the one or more servers, second data based on the first private key, the generating second data comprising the steps of:

concatenating the private key to generate a keychain;

removing the one or more corruptions from the keychain to generate the second data;

generating, at the one or more servers, results based on the second data;

generating, at the one or more servers and based on the results, a recipient identifier and a privacy code identifier, wherein the recipient identifier is associated with one or more nodes, and the privacy code identifier is generated based on the second privacy code; and

The first private key, the recipient identifier, and the privacy code identifier are assigned to the one or more nodes.

17. The method of claim 16, further comprising:

receiving, at the one or more servers, two or more private keys from the first computing device based on third data; and

login data is generated, wherein the login data is generated based on the two or more private keys based on third data.

18. The method of claim 17, further comprising:

retrieving the private key stored at the one or more nodes based on at least one of the recipient identifier and the privacy code identifier; and

registration data is generated, wherein the registration data is generated based on the private key retrieved from the one or more nodes.

19. The method of claim 18, further comprising:

comparing the login data with the registration data; and

and generating a result.

20. A system comprising a server, the server comprising:

a memory containing server instructions;

and a processing device configured to execute the server instructions, wherein the server instructions cause the processing device to:

Registering, at one or more servers, the one or more servers including a security engine, an action engine, a library, and one or more nodes associated with the one or more servers, a first computing device;

receiving, at the one or more servers, a plurality of private keys and a second privacy code from the first computing device, wherein:

the private key is generated based on the first data, the block count, and one or more corruptions codes;

The second privacy code is generated based on the first privacy code; and the number of private keys is equal to the block count;

concatenating the private key to generate a keychain; and

one or more corruptions codes are removed from the keychain to generate the second data.