[go: up one dir, main page]

WO2024147078A2 - Archive à extraction automatique à des fins de protection de données - Google Patents

Archive à extraction automatique à des fins de protection de données Download PDF

Info

Publication number
WO2024147078A2
WO2024147078A2 PCT/IB2024/000055 IB2024000055W WO2024147078A2 WO 2024147078 A2 WO2024147078 A2 WO 2024147078A2 IB 2024000055 W IB2024000055 W IB 2024000055W WO 2024147078 A2 WO2024147078 A2 WO 2024147078A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
file
user
key
servers
Prior art date
Application number
PCT/IB2024/000055
Other languages
English (en)
Other versions
WO2024147078A3 (fr
Inventor
Devi Selva Kumar VIJAYANARAYANAN
Original Assignee
Vijayanarayanan Devi Selva Kumar
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vijayanarayanan Devi Selva Kumar filed Critical Vijayanarayanan Devi Selva Kumar
Publication of WO2024147078A2 publication Critical patent/WO2024147078A2/fr
Publication of WO2024147078A3 publication Critical patent/WO2024147078A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2111—Location-sensitive, e.g. geographical location, GPS

Definitions

  • This disclosure relates in general to the field of data security and more particularly to security of targeted communications and authentication of a user of a network or system.
  • a method for generating an automatically-extractable archive of protected data comprises: determining, at one or more first servers, a file comprising protected content data stored on at least one of a computer system or the one or more first servers; and executing, at the one or more first servers, a data encapsulation operation on the file comprising protected content data.
  • the data encapsulation operation comprises: generating, at the one or more first servers, an archive file; determining, at the one or more first servers, a first executable command, wherein the first executable command is executable, by one or more of the first servers or one or more second servers, to recover the file comprising protected content data; determining, at the one or more first servers, a first security computing operation, wherein the first security computing operation comprises an access control computing operation, wherein the access control computing operation restricts access to the file comprising protected content data based on one or more parameters of the first security computing operation; and adding, at the one or more first servers, to the archive file, the file comprising protected content data, the first executable command, and the first security computing operation, wherein the file comprising protected content data is extractable from the archive file.
  • extracting the file comprising protected content data comprises: receiving, at the one or more first servers or the one or more second servers, a first indicia associated with the one or more parameters of the first security computing operation; determining, at the one or more first servers or the one or more second servers, based on the first indicia associated with the one or more parameters of the first security computing operation, whether a first user of a first computing device is permitted to access the file comprising protected content data; and executing, at the one or more first servers or the one or more second servers, the first executable command, wherein the first executable command comprises executable instructions for execution by one or more computer processors.
  • the executable instructions referenced above include instructions for: automatically removing, at the one or more first servers or the one or more second servers, from the archive file, the file comprising protected content data, wherein automatically removing the file comprising protected content data from the archive file comprises removing, from the archive file, the first executable command and the first security computing operation to recover the file comprising protected content data; and transmitting, from the one or more first servers or the one or more second servers, a second indicia associated with the determining, based on the first indicia associated with the one or more parameters of the first security computing operation, whether a first user of a first computing device is permitted to access the file comprising protected content data.
  • a system and a computer program can include or execute the method described above. These and other implementations may each optionally include one or more of the following features.
  • the disclosed method may further comprise protecting data to generate the protected content data.
  • protecting data can comprise: determining, using one or more computing device processors, a file comprising content data stored on the computing system; generating, using the one or more computing device processors, index information for the file comprising content data; and transmitting, using the one or more computing device processors, a corruption operation on the file comprising content data.
  • the index information comprises at least one of: a file path for a location of the file comprising content data on the computing system; a hash value associated with at least one of the file comprising content data or the content data comprised in the file comprising content data; and a time of creation or modification of the file comprising content data.
  • the disclosed method includes executing, using the one or more computing device processors, a dividing operation on the file comprising content data that divides the content data comprised in the file comprising content data in a plurality of data chunks, wherein a first data chunk comprised in the plurality of data chunks has a size that is different from a second data chunk comprised in the plurality of data chunks; adding, using the one or more computing device processors, a first corruptor to the first data chunk prior to executing a first encryption operation on the first data chunk, the first corruptor comprising one or more of a first alphanumeric character or a first symbolic character; and executing the first encryption operation, using the one or more computing device processors, on the first data chunk comprised in the plurality of data chunks based on an encryption protocol.
  • the disclosed method includes adding, using the one or more computing device processors, a second corruptor to the first data chunk after the first encryption operation, the second corruptor comprising one or more of a second alphanumeric character or a second symbolic character.
  • the disclosed method may further include determining, using the one or more computing device processors, a first identifier for the first data chunk comprised in the plurality of data chunks; and determining, using the one or more computing device processors, a second identifier for the second data chunk comprised in the plurality of data chunks.
  • the disclosed method includes determining, using the one or more computing device processors, an indicia associated with an order of the first data chunk and the second data chunk comprised in the plurality of data chunks.
  • the disclosed method includes determining, using the one or more computing device processors, an indicia associated with an order of the first data chunk and the second data chunk comprised in the plurality of data chunks.
  • the corruption operation referenced above comprises the steps of: determining, at the one or more first servers, a second security computing operation, wherein the second security computing operation comprises a second access control computing operation, wherein the second access control computing operation restricts access to the file comprising protected content data based on one or more parameters of the second security computing operation.
  • first security computing operation and the second security computing operation are the same security computing operation and wherein the access control computing operation and the second access control computing operation are the same access control computing operation.
  • receiving, at the one or more first servers or the one or more second servers, a first indicia associated with the one or more parameters of the first security computing operation further comprises receiving the first indicia from a first computing device, wherein the first indicia is a first user input from the first computing device.
  • the first user input from the first computing device for example, is a password associated with the first user.
  • determining, at the one or more first servers or the one or more second servers, based on the first indicia associated with the one or more parameters of the first security computing operation, whether the first user of a first computing device is permitted to access the file comprising protected content data further comprises determining whether the password associated with the first user is correct.
  • the archive file comprises one or more files including metadata associated with the file comprising protected content data.
  • one or more of the first security computing operation and the access control computing operation is a computing operation that executes to one or more of modify one or more application of a first computing device of a first user, replicate data of the first computing device of the first user, and block access to at least the file comprising content data and one or more files on the first computing device of the first user.
  • the executable command for example, further comprises an impact computing operation.
  • the executable command is executed such that the impact computing operation impacts electronic operations of a first computing device of a first user.
  • Impacting the electronic operations of the first computing device of the first user can comprise one or more impact computing operations that modify one or more application of a first computing device of a first user, replicate data of the first computing device of the first user, and block access to at least the file comprising content data and one or more files on the first computing device of the first user.
  • FIG. 1 is a system drawing showing an embodiment of the authentication system of the present disclosure.
  • FIG. 2 is a system drawing showing a configuration of elements operable to undertake a transfer of data between the client system and the verification system of an embodiment of the present disclosure.
  • FIG. 3 is a system drawing showing a configuration of elements operable to undertake a registration process of an embodiment of the present disclosure.
  • FIG. 4 is a system drawing showing a configuration of elements operable to undertake an access process of an embodiment of the present disclosure.
  • FIG. 5 is a system drawing showing a synchronization element operable to process a hashed OY- packet portion in accordance with an embodiment of the present disclosure.
  • FIG. 6 is a system drawing showing a configuration of elements operable to undertake a decoding process of an embodiment of the present disclosure.
  • FIG. 7 is a system drawing showing elements of a user device of an embodiment of the present disclosure.
  • FIG. 8 is a system drawing showing elements of a client system of an embodiment of the present disclosure.
  • FIG. 9 is a system drawing showing elements of a client display unit of an embodiment of the present disclosure.
  • FIG. 10 is a system drawing showing elements of a verification system of an embodiment of the present disclosure.
  • FIG. 11 is a system drawing showing a configuration of elements operable to undertake processing of a user authentication request to access the secure portion(s) of a client system in accordance with an embodiment of the present disclosure.
  • FIG. 16 is a system drawing showing a configuration of elements operable to undertake the verification of a challenge via a user device for authentication of a user in accordance with an embodiment of the present disclosure.
  • FIG. 17 illustrates a registration method, according to one embodiment of the present disclosure.
  • FIG. 18 illustrates a method of creating one or more keys, according to one embodiment of the present disclosure.
  • FIG. 19 illustrates a method of distributing one or more keys, according to one embodiment of the present disclosure.
  • FIG. 21 illustrates a method of creating one or more keys, according to one embodiment of the present disclosure.
  • FIG. 22 illustrates a method of distributing one or more verification keys, according to one embodiment of the present disclosure.
  • FIG. 27 illustrates a method of generating one or more keys, according to one embodiment of the present disclosure.
  • FIG. 28 illustrates a method of generating one or more keys, according to one embodiment of the present disclosure.
  • FIG. 29 illustrates a method of establishing a web session, according to one embodiment of the present disclosure.
  • FIG. 30 illustrates a system for generating keys using controlled corruption, according to some embodiments.
  • FIG. 31 illustrates a method of generating keys using controlled corruption, according to some embodiments.
  • FIG. 32 illustrates a method of generating keys using controlled corruption, according to some embodiments.
  • FIG. 33 illustrates a method of generating keys using controlled corruption, according to some embodiments.
  • FIG. 34 illustrates a method of generating keys using controlled corruption, according to some embodiments.
  • FIG. 35 illustrates a method of using keys generated using controlled corruption for authentication, according to some embodiments.
  • FIGS. 36, 37, 38, and 39 illustrate exemplary interfaces associated with setting up and using a Swarm (e.g., a software tool, program, plug-in, etc.) for data protection, according to some embodiments.
  • a Swarm e.g., a software tool, program, plug-in, etc.
  • FIGS. 40, 41A, and 41B illustrate exemplary flowcharts for executing Swarm data protection, according to some embodiments.
  • FIGS. 42 and 43 show an exemplary flowchart and workflow for computationally securing content data, respectively.
  • FIGS. 44 - 47 are respectively directed to: generating an automatically-extractable archive of protected data; executing a data encapsulation operation associated with the automatically- extractable archive; extracting a file associated with the automatically-extractable archive; and executing or activating executable instructions associated with the automatically-extractable archive.
  • the present disclosure is an authentication method and system operable to authenticate users, data, documents, devices and transactions.
  • Embodiments of the present disclosure may be operable with any system or network of any organization or individual.
  • the authentication method and system are operable to disburse unique portions of login related information amongst multiple devices.
  • the disbursed portions of login related information are utilized by the system to authenticate users, data, documents, devices and transactions without revealing the login related information to the system.
  • the login related information is encrypted and/or hashed through multi-layer encryption and/or hashing, and some of the encrypted and/or hashed details are held back.
  • the devices wherein login related information is stored will all be utilized in the authentication method and system.
  • Login related information provided to a user is not revealed to and/or stored in the system or any user device.
  • the authentication of data, documents, devices and transactions does not require a key to be revealed to the system.
  • client system means either the network or system of an organization or individual.
  • client device means a device utilized by a user to login to the client system, such as a laptop, a tablet, a cell phone, a smart phone, a desktop computer, smart watch, a computing device, whereby a user can login to the client system or any other device which requires a secure login.
  • transfer of information between a user and the client system can include any creation, transfer or storage of information occurring in relation to the system.
  • the user’ s device will need to prove to the client system that it has valid keys and/or that the device has been previously authenticated This will be achieved by the present disclosure without the user device having to reveal a key or keys to the client system.
  • the authentication of data, documents, devices, transaction and users can occur without the user having to reveal his or her key to the client system.
  • the login related information will be created uniquely and will not be stored and/or transmitted; this along with the user device assisted multipoint authentication prevents unauthorized third party access to the client system.
  • prior art systems are not generally operable with any type of client system, or with any type of user device.
  • the present disclosure provides an organization with a secure authentication system that will provide the necessary secure access to a user to access the organizations' data across any platform, solution or environment.
  • the present disclosure can be implemented by any organization for use with any type of client system, and with any user device on any platform.
  • ISMA Interactive Semi-Manual Authentication
  • Multiple layers of encryption may be generated by the user device. Such encryption may be applied to elements individually or collectively. For example, random three or more digits (that may change during each login event) along with salt and iv can be generated by the user device, or other types of encryption and/or hashing may be applied. Another layer of encryption may be added collectively to the prior encryption.
  • the authentication process for a user of the present disclosure authentication system operates so that the transactions are authenticated without the user having to reveal his or her key to the client system.
  • the client system does not know the user key or if the user has a key.
  • the user device has to prove to the system that it has valid keys and that the user and device have been authenticated, without revealing the key to the system. In order to achieve this the user device will have to authenticate using the SMFA process described herein and/or the ISMA process described herein.
  • the user device may use a random temporary key it has or that it has received.
  • the system will generate a security challenge. This challenge may be secured using features, such as, multi-layer encryption, digital signature and or hashing.
  • the secured package 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 solve the challenge.
  • the system will generate and encrypt the six or more random digit alphanumeric code as well as other elements. For example, the system may encrypt the six or more random digit alphanumeric code. Additional encryption and security features (which may include but not limited to salt, iv, secure keys etc.) may also be applied by the client system. The system will then add a digital signature to the results of the encryptions. This encrypted & signed package is then sent to the user device requesting to be authenticated.
  • Additional encryption and security features which may include but not limited to salt, iv, secure keys etc.
  • the user device will verify the digital signature and then use the decryption key provided to recreate the six or more digit alpha numeric code along with corresponding alphabets or numerals.
  • the user device then encrypts the recreated information. Along with the security features. The user device will then add a digital signature to the results of the encryption. This encrypted and signed package is then sent to the client system engaged in the authentication process.
  • the client system receives the message from the user device, and upon receipt will verify the digital signature, decrypt the message and compares the message with the sent message. If the comparison shows that the received message is the same as the sent message then the client system knows that the user has the required key
  • the session will be authenticated through time and geo-based access codes, these access codes will be invalidated if the time expires or the geo is invalidated, as previously discussed herein.
  • the user uses the user system to prove its identity and to gain access to the secured area of the client system.
  • the verification system 202 is operable to verify the authenticity of the user’s identity.
  • the synchronization system 300 is a collection of one or more synchronization elements 302A. . .302N, operable to function in a synchronized manner to approve the authenticity of user’s identity.
  • the user system may incorporate multiple elements.
  • the user system may incorporate a proving unit 104, a display unit 106, a processing unit 108, an approval unit 112, a storage unit 110 and a communications unit 114.
  • the proving unit is operable to prove the initial identity of the user system 102 to the verification system.
  • the display unit is operable to display information to a user, for example, such as a challenge or any other information transferred from the client system, the verification system or any other system or element of the present disclosure to the user system.
  • the display unit is further operable to display information generated by the client system to the user.
  • the display unit may further be connected to an input unit, or have a touch screen or other input operability, whereby a user can input information.
  • the information inputted by the user may be displayed on the display unit or may otherwise be collected by the user system and stored, transferred to the client system or another system or element of the authentication system, or processed by the user system.
  • the processing unit 108 will be responsible for all the processing capacity within the system.
  • the approval unit 112 will be responsible for accessing the challenge and response and providing a result and the storage unit will be responsible for storing both temporary and permanent data.
  • the communication unit 114 is responsible for all external communications.
  • the verification system 202 may incorporate multiple elements.
  • the verification system may incorporate a masker unit 204, a N-packet generator 206, a report generator 208, a processing unit 210, an approval unit 212, one or more storage units 214A. . .214N, and communications unit 216.
  • the masker unit is operable to generate one or more unique non-identifying identifiers for the client system and the user system.
  • the processing unit 210 is operable to processing of information and data as required by the authentication system.
  • the approval unit 212 is operable to access the responses received internally in the system and providing a result that can be sent to the processing unit or sent to a receiver that is external to the system via a communication unit.
  • the one or more storage units are operable to store both temporary and permanent data.
  • the N-packet generator 206 is operable to generate packets of authentication information.
  • the communication unit 216 is operable to receive and transfer all communications with all elements of the authentication system that are external to the verification system (i.e., the client system, the user system, etc.).
  • some or all of the units described as elements of the verification system in FIG. 1 may be incorporated within other systems or elements of the authentication system, such as the client system. In some embodiments of the present disclosure some or all of the units described as elements of the verification system in FIG. 1 may be standalone elements that are not incorporated in any system of the authentication system, but are generally incorporated in the authentication system.
  • the proving unit of the synchronization unit retrieves proving information from one or more of the storage units of the synchronization unit and both the proving information and the pass value or fail value that the proving unit has received may be hashed and/or encrypted and sent to the processing unit of the verification system.
  • the processing unit of the verification system may hash or encrypt the verification results and send the hashed and/or encrypted verification result to the processing unit 108 of the user system 102, via the communication unit 216 of the verification system.
  • the processing unit of the user system sends the hashed or encrypted verification result to the client system 902.
  • the client system submits a request for authentication to the processing unit 210 of the verification system, via the communication unit 216 of the verification system, based upon the verification results the client system receives.
  • the processing unit of the verification system retrieves the verification results saved in one or more of the storage units of the verification system and sends the retrieved results to the approval unit of the verification system.
  • the approval unit of the verification system reviews the retrieved results and may approve these and send the verification results to the client system which will then decide whether or not to authenticate the user based on the verification report results.
  • the user will use the user device to verify the user system and the user’s credentials to the client systems.
  • a user’s credentials and the user system must be verified in order to verify that the user is authorized to access the secure portions of the client system.
  • the user will only be able to perform certain functions or access certain information through the secure portions of the client system if the user is authenticated.
  • the user will only be able to approve certain transactions through the client system if the user and the user system are authenticated.
  • the client system is the system that the user is trying to gain access to and therefore requires the authentication to be performed.
  • the verification system of the present disclosure will verify the identity of the user and the user system and cause the client system to recognize the user and the user system as authenticated, as is described herein.
  • a user system 101 utilized to transmit user information to and from the client system may incorporate multiple elements.
  • an embodiment of the present disclosure may include a user system that incorporates 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.
  • the client display unit 150 of an embodiment of the present disclosure may incorporate multiple elements.
  • an embodiment of the present disclosure may include a client display unit that incorporates an interaction unit 151, a processing unit 153, a temporary storage unit 155 and a key generator 157.
  • the verification system 140 of an embodiment of the present disclosure may incorporate multiple elements.
  • an embodiment of the present disclosure may include a verification system that incorporates a random key generator 141, a random text generator 143, a USID generator 145 and a processing unit 147.
  • the processing unit 147 of the verification system combines the USID and random text that it receives with ak2 into a data string and converts the data string into a machine readable format, then sends this to the processing unit 153 of the client display unit.
  • the interaction unit 151 of the client display unit makes the information available to the reader unit 113 of the user system.
  • the reader unit 113 may include one or more sensors including any of the following auditory, visual, tactile, print, movement and other kind of sensors that may be incorporated in the client device or external to the client device but connected thereto either via a wired connection or a wireless connection.
  • the sensors may be utilized to obtain information relating to the user.
  • the processing unit of the user system will also access the storage unit 111 of the user system and request Delta 1 Key and/or session code and/or the generation of a session code.
  • the storage unit 111 will provide Delta 1 Key to the processing unit of the user system or will generate a session code and provide this to the processing unit of the user system.
  • the processing unit 109 of the user system may request that the random key generator 141 of the verification system generate a random Delta 1 keys and/ or a session code and provide this to the processing unit 109, that may generate a hash value for 5kl or SC that is provided.
  • the processing unit of the user system may generate a Manual Interaction Code (MIC) using the 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.
  • the processing unit 135 of the client system receives post-MIC data and the hash.
  • the processing unit 135 of the client system sends the hash value to be stored temporarily in the storage unit 133 of the client system.
  • the post-MIC data is sent to the processing unit 153 of the client display unit.
  • the processing unit 153 of the client display unit combines akl and post-MIC data as a package and sends this package to the key generator 157 of the client display unit.
  • the processing unit 153 requests that the key generator 157 of the client display unit generates a Gama key (yK).
  • the yK is sent by the key generator of the client display unit 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.
  • the MIC is then sent by the interaction unit of the client display unit to the processing unit 153 of the client display unit.
  • the processing unit 153 uses yK, MIC and package, to cause SC or 8kl to be available.
  • the processing unit of the client display unit calculates the hash value for SC or Ski and sends the hash value to the approval unit 139 of the client system for verification.
  • Any of the information received or generated by the processing unit of the client display unit can be temporarily stored in the temporary storage unit 155 of the client display unit at any point during the processing activities 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 either the hash value of SC or 8k 1, and the value retrieved from storage to the approval unit 139 of the client system.
  • the approval unit 139 compares the hash values to determine a match.
  • the approval unit 139 confirms the match to the processing unit 135 of the client system.
  • the processing unit 135 of the client system requests a Client Session Access Pass (CSAP) from the CSAP generator 131.
  • the CSAP generator 131 generates the CSAP which is sent to the storage unit 133 of the client system to be stored temporarily.
  • the CSAP generator 131 also sends the CSAP to the processing unit 147 of the verification system.
  • the processing unit 147 of the verification system sends the CSAP to the processing unit of the 153 client display unit.
  • the processing unit 153 of the client display unit sends CSAP to the processing unit 135 of the user system.
  • the processing unit 135 of the user system sends CSAP to the 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 notice of such confirmation and operates to permit the user to access secured portions of the client system.
  • the CSAP generator 131 of the client system may be utilized to test conditions relating to the authentication of the user; the user system and the client display unit periodically through the generation of CSAP, the processing thereof by the processing unit of the client system and the transfer of such CSAP to other processing units of the verification system, user system, client display unit and storage of such CSAP in the storage unit of the client system, user system and client display unit, in accordance with the method described herein.
  • the approval unit of the client system determines that authentication conditions are not met in relation to the CSAP, for example, such as a determination that the CSAP received by the processing unit of the client system and the stored CSAP do not match, then the authentication (i.e., CSAP authentication) of the user, the user device and the client display unit will be rescinded and access to the secure area terminated for the user, the user device and the client display unit.
  • the authentication i.e., CSAP authentication
  • CSAP conditions for authentication applied in embodiments of the present disclosure may include conditions relating to any of the following: dimensions, geo-temporal, machine learnt artificial intelligence, behavioral, or any other conditions.
  • FIG. 15 Another embodiment of the present disclosure whereby the user uses the client display unit to attempt to validate a transaction through access to a secure portion of the client system is shown in FIG. 15.
  • the processing unit 153 of the client display unit sends a request to the processing unit 135 of the client system to validate a transaction.
  • the processing unit 135 of the client system sends a request to the challenge generator 137 of the client system to generate a challenge.
  • the challenge generator 137 of the client system will generate a challenge and may further apply a hash value to the result of the challenge, and save the solution and/or the hash value in the storage unit 133 of the client system.
  • the challenge generator of the client system will send 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 challenge.
  • the processing unit 135 will send 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 to it, and will send the challenge to the interaction unit 151 of the client display unit.
  • the user may be required to interact with the interaction unit 151 of the client display unit to find the solution to the challenge.
  • the processing unit 153 of the client display unit may solve the decrypted 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 upon the user solution, and the processing unit of the client display unit may further add either symmetric or asymmetric encryption to this hash value and/or to the solution.
  • the results of the processing by the processing unit of the client display unit e.g., a hash value or an encrypted hash value, or a solution or an encrypted solution
  • 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 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 value or encrypted solution and/or non-encrypted hash values it receives from the processing unit 153 of the client display unit.
  • the processing unit 135 of the client system will send the hash value and/or solution it receives from the processing unit 153 of the client display unit (in an unencrypted form), and the stored solution and/or the stored has value, to the approval unit 139 of the client system for approval.
  • the approval unit 139 of the client system will compare the received solution to the stored solution, and/or the received hash value to the stored hash value.
  • the approval unit 139 will send confirmation to the processing unit 135 of the client system of a match. If the match is a positive, the processing unit 135 of the client system will transmit the confirmation of the positive match to the client system to confirm that the authentication of the transaction has completed successfully, and the client system will thereby authorize the transaction.
  • the approval unit 139 will send notice to the processing unit 135 of the client system that there is no match.
  • the processing unit of the client system will transmit the notice to the client system and advise the client system not to authenticate the transaction.
  • the processing unit of the verification system can perform the functions described for the processing unit of the client system in accordance with FIG. 14.
  • a challenge generator unit and an approval unit may be incorporated in either the client system or the verification system, and such challenge generator unit and approval unit will have the same functions as described in accordance with FIG. 14 of the challenge generator 137 and the approval unit 139.
  • FIG. 16 Another embodiment of the present disclosure whereby the user uses the user system to attempt to validate a transaction is shown in FIG. 16.
  • the processing unit 109 of the user system sends a request of the processing unit 135 of the client system to validate a transaction.
  • the processing unit 135 of the client system sends a request to the challenge generator 137 to generate a challenge.
  • the challenge generator 137 will generate a challenge, and will further apply hash value to the result of the challenge (the solution of the challenge), and save 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 challenge.
  • the processing unit 135 will send the challenge, which may be encrypted, to the processing unit 109 of the user system.
  • the processing unit 109 of the user system may decrypt the challenge, if the challenge is encrypted, and will send the challenge to the interaction unit 103 of the user system.
  • the user may be required to interact with the interaction unit 103 of the user system to find the solution to the challenge.
  • the processing unit 109 of the user system may solve the decrypted 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 upon the user solution, and the processing unit 109 of the user system may further add either symmetric or asymmetric encryption to this hash value and/or to the solution.
  • the results of the processing by the processing unit 109 of the user system e.g., a hash value or an encrypted hash value, and a solution or an encrypted solution
  • 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 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 value or encrypted solution it receives from the processing unit 109 of the user system.
  • the processing unit 135 of the client system will send the hash value and solution it receives from the processing unit 109 of the user system (in an unencrypted form), and the stored solution and/or the stored has value, to the approval unit 139 of the client system for approval.
  • the approval unit 139 of the client system will compare the received solution to the stored solution, and/or the received hash value to the stored hash value.
  • the approval unit 139 will send confirmation to the processing unit 135 of the client system of a match.
  • the processing unit 135 of the client system will transmit the confirmation of a match to the client system to confirm that the authentication of the transaction is completed and successful.
  • the approval unit 139 will send notice to the processing unit of the client system that there is no match.
  • the processing unit of the client system will transmit the notice to the client system and advise the client system not to authenticate the transaction.
  • the processing unit of the verification system can perform the functions described for the processing unit of the client system in accordance with FIG. 16.
  • a challenge generator unit and an approval unit may be incorporated in either the client system or the verification system, and such challenge generator unit and approval unit will have the same functions as described in accordance with FIG. 16 of the challenge generator 137 and the approval unit 139.
  • a system and network for authentication may comprise one or more first peers, one or more servers, and one or more second peers, each comprising at least a processor and a transmitter/receiver.
  • One or more first peers and one or more second peers may additionally comprise a respective memory.
  • each of one or more first peers and one or second peers may comprise a visual display.
  • One or more servers may additionally comprise a database.
  • a transmitter/receiver of each of a first peer, a second peer, and a server may be configured to transmit and receive information from an exogenous source.
  • a first peer may be configured to transmit and receive information from a server
  • a server may be configured to transmit and receive information from both a first peer and a second peer
  • a second peer may be configured to transmit and receive information from a server.
  • a memory of a first peer and a second peer and a database of a server may be configured to store information and to allow information to be retrieved.
  • a visual display may additionally comprise a means for a user to interact with a display, e.g., enter data, select characters, select objects, etc.
  • a processor of a first peer, a second peer, or a server may comprise a processing migrator, a data manipulator, a data converter, a processing generator, and a processing verifier.
  • a processing migrator may be configured to migrate data from one component within a first peer, a second peer, or a server to another component within a first peer, a second peer, or a server.
  • a processing migrator may be configured to move data from a memory of a first peer to a processor of a first peer, or from a processor of a second peer to a transmitter/receiver of a second peer.
  • a data manipulator may be configured to manipulate data, e.g., combine, separate, separate and recombine, reorder, etc.
  • a data manipulator of a first peer may be configured to separate a one or more strings of characters into a first portion and a second portion
  • a data manipulator of a server may be configured to combine a first portion of data with a second portion of data to produce a single packet of data.
  • a data converter may be configured to convert a first string of characters into a second string of characters, wherein each of a first string of characters and a second string of characters may be different in any one or more of length, composition, or arrangement.
  • a data converter may be configured to apply hash algorithms to a first string of characters.
  • a data converter may be configured to apply encryption protocols to a first string of characters.
  • a data converter may be configured to apply decryption protocols to a first string of characters.
  • a data converter may be configured to apply any combination of hash algorithms, encryption protocols, decryption protocols, or any other known method of data conversion to a first string of characters to produce a second string of characters.
  • a processing generator may be configured to produce data.
  • data may comprise a one or more strings of characters of any length and may comprise bar codes and the like.
  • data may be produced in either a random manner or in a directed manner.
  • a processing verifier may be configured to compare two or more data and determine if those data are identical or different.
  • a processing verifier and a processing generator may be paired to determine if a first string of characters and a second string of characters are identical and generate a response based on the identity of a first and second string of characters.
  • An authentication method may comprise a registration method 1700 and a user log-in method 2000.
  • a registration method 1700 may comprise creating one or more keys, distributing one or more keys, storing one or more keys on a local database, and storing one or more keys on a server database. Illustrated in FIG. 17, a registration method 1700 may additionally comprise communication between a first peer 1701, a server 1750, and at least one second peer 1775.
  • a server 1750 may receive a registration request 1702 from a first peer 1701.
  • a server 1750 may send registration data 1751 to a first peer 1701.
  • Registration data 1751 may comprise any data required for a registration method 1700.
  • registration data 1751 may comprise a client registration code 1703.
  • a client registration code 1703 may be made up of one or more characters comprising letters, numbers, symbols, or any combination thereof, and may be generated by a server 1750.
  • registration data comprises user selection objects.
  • registration data may comprise a combination of one or more of client registration codes 1703, user selection objects, and any other data required for registration.
  • a registration method 1700 may further comprise generating a server key 1705 and a client key 1706 from user input 1704.
  • a server key 1705 and a client key 1706 are used to generate a registration key 1707.
  • a server key 1705, a client key 1706, and at least one client registration code 1703 are used to generate a registration key 1707.
  • Other embodiments may comprise different combinations of client keys 1706, server keys 1705, and client registration codes 1703 being used to generate registration keys 1707.
  • Some information, e.g., a client key 1706, a client registration code 1703 may be stored in the memory 1708 of a first peer 1701.
  • a registration method 1700 may comprise transferring information from a first peer 1701 to a server 1750.
  • a registration key 1707 and a server key 1705 are transferred to a server 1750.
  • a registration method 1700 may further comprise transferring information from a server 1750 to at least one second peer 1775.
  • a distribution key 1753 and a distribution code 1756 are transferred to at least one second peer 1775.
  • a registration method 1700 may further comprise storing one or more keys on a local database. Illustrated in FIG. 17, at least one second peer 1775 may receive information from a server 1750. In some embodiments, information may comprise a distribution key 1753 and a distribution code 1756. A second peer may generate a deposit code 1776. Further, a distribution key 1753 and a deposit code 1776 may be used to generate a deposit key 1777. In some embodiments, a deposit key 1777 may be generated using only a distribution key 1753, only a deposit code 1776, or any combination of distribution keys 1753 and deposit codes 1776.
  • a distribution key 1753, a deposit key 1777, a distribution code 1756 may be stored in the memory 1758 of a second peer device 1775.
  • a registration method 1700 may further comprise transferring information from a second peer 1775 to a server 1750.
  • a deposit key 1777 and a distribution code 1756 are transferred to a server 1750.
  • a registration method 1700 may comprise receiving information from a second peer 1775 and storing that information in a local database.
  • a server 1750 receives information from a second peer 1775.
  • Information received may comprise a deposit key 1777, a distribution code 1756, and other information needed for storage of information by the server 1750 or for identification of the second peer 1775.
  • a first peer 1801 may be any loT device, i.e., any device that may connect to a network and have the ability to transmit data, including but not limited to cell phones, personal assistants, buttons, home security systems, appliances, and the like.
  • a first peer 1801 may request registration from a server 1850.
  • a server 1850 may transmit registration data to a first peer 1801.
  • Registration data may be received by a transmitter/receiver 1841 of a first peer 1801 and may comprise any data necessary to generate one or more keys 1800 at a first peer 1801.
  • registration data may comprise a client registration code 1803.
  • user input 1804 may comprise one or more selection objects.
  • One or more selection objects may be images, icons, tokens, buttons, or any other object that allows a user to select one or more selection objects from a group of selection objects.
  • selection objects may be received at a transmitter/receiver 1841 and a processing migrator 1842 may migrate selection objects to a visual display 1843.
  • selection objects may be converted into selection codes 1809 which may comprise any number of characters, e.g., letters, numbers, symbols.
  • selection objects are images that may be received from a server 1850.
  • Each image is assigned a unique selection code 1809, wherein user selection of a combination of selection obj ects produces a user input 1804 comprising a combination of selection codes 1809 that is unique to the user’s selection of selection objects.
  • any combination of biometric data, spatial and/or temporal data, and selection objects may comprise user input 1804.
  • a user may generate user input 1804 comprising two or more selection codes 1809, wherein the number of selection codes is equal to n.
  • a data manipulator 1844 may be configured to separate selection codes into two or more groups.
  • a data manipulator 1844 may be configured to separate selection codes 1809 into a first group 1810 and a second group 1811, wherein a first group 1810 comprises between one and n-1 selection codes 1809 and a second group 1811 comprises between one and n-1 selection codes 1809.
  • Each selection code 1809 in a first group 1810 and a second group 1811 may be individually converted 1812 into a one or more strings of characters, by a data converter 1845, resulting in a first group of converted selection codes 1813 and a second group of converted selection codes 1815.
  • conversion 1812 may comprise using hash algorithms.
  • conversion 1812 may comprise using encryption methods.
  • Yet other embodiments may comprise conversion 1812 using a combination of hash algorithms and encryption methods.
  • a first group of converted selection codes 1813 may be used to generate a client pre-key 1814. Individual converted selection codes comprising a first group of converted selection codes 1813 may be combined by a data manipulator 1844 to form one or more strings of characters comprising a client pre-key 1814.
  • individual converted selection codes are combined through concatenation of units. Concatenation may comprise using each of the individual converted selection codes as a unit or may comprise using pieces of each individual converted selection code as a unit.
  • a client pre-key 1814 may be converted 1812 to a client key 1806 by a data converter 1845.
  • conversion 1812 may comprise using hash algorithms.
  • conversion 1812 may comprise using encryption methods.
  • Yet other embodiments may comprise conversion 1812 using a combination of hash algorithms and encryption methods.
  • a client key 1812 may be stored in a memory 1808 of a first peer 1801 by a processing migrator 1842.
  • a second group of converted selection codes 1815 may be used to generate a server pre-key 1816.
  • Individual converted selection codes comprising a second group of converted selection codes 1815 may be combined by a data manipulator 1844 to form one or more strings of characters comprising a server pre-key 1816.
  • individual converted selection codes may be combined through concatenation of units. Concatenation may comprise using each of the individual converted selection codes as a unit or may comprise using pieces of each individual converted selection code as a unit.
  • a server pre-key 1816 may be converted 1812 to a server key
  • conversion 1812 may comprise using hash algorithms. In other embodiments, conversion 1812 may comprise using encryption methods. Yet other embodiments may comprise conversion 1812 using a combination of hash algorithms and encryption methods.
  • a registration key 1807 may be generated.
  • a server key first part 1819 and a server key second part 1820 may comprise different portions of the characters that comprise a server key 1805.
  • each of a server key first part 1819 and a server key second part 1820 may be one half of a server key 1805.
  • a client key first part 1817, a client key second part 1818, a server key first part 1819, and a server key second part 1820 may be combined by a data manipulator 1844 through concatenation of units to form one or more strings of characters comprising a first pre-key 1821.
  • Concatenation by a data manipulator 1844 may comprise using each of a client key first part 1817, a client key second part 1818, a server key first part 1819, and a server key second part 1820 as a unit or may comprise using pieces of a client key first part 1817, a client key second part 1818, a server key first part 1819, and a server key second part 1820 as a unit. Further, concatenation may comprise using any combination of parts generated by separation of a client key 1806 or a server key 1805.
  • a first pre-key 1821 may be converted 1812 by a data converter 1845 into a one or more strings of characters comprising a second pre-key 1822. In some embodiments, conversion 1812 may comprise using hash algorithms.
  • conversion 1812 may comprise using encryption methods. Yet other embodiments may comprise conversion 1812 using a combination of hash algorithms and encryption methods.
  • a second prekey 1822 may be used to generate a registration pre-key 1823.
  • a second pre-key 1822 and a client registration code 1803 may be concatenated by a data manipulator 1844 to form one or more strings of characters comprising a registration pre-key 1823. Concatenation may comprise using each of a second pre-key 1822 and a client registration code 1803 as a unit or may comprise using pieces of a second pre-key 1822 and a client registration code 1803 as a unit.
  • a registration pre-key 1823 may be converted 1812 by a data converter 1845 into a one or more strings of characters comprising a registration key 1807.
  • conversion 1812 may comprise using hash algorithms.
  • conversion 1812 may comprise using encryption methods.
  • Yet other embodiments may comprise conversion 1812 using a combination of hash algorithms and encryption methods.
  • a data manipulator 1944 of a server 1950 may generate a distribution pre-key 1959 by combining any combination of a server key 1905, a recipient code 1952, a sender code 1954, a distribution code 1956, or a registration key 1907.
  • a distribution pre-key is comprised of a server key 1905, a sender code 1954, and a recipient code 1952, which may be combined through concatenation of units to form one or more strings of characters. Concatenation may comprise using each of a server key 1905, a sender code 1954, and a recipient code 1952 as a unit or may comprise using pieces of a server key 1905, a sender code 1954, and a recipient code 1952 as a unit.
  • a server 1950 may generate more than one distribution keys 1953 and transmit data to more than one second peer 1975.
  • a peer list 1958 may comprise a list of more than one second peers 1975 on the network.
  • a second peer may comprise any loT device, server, or any device that is on a network and capable of transmitting and receiving data from a server 1950.
  • a server 1950 may generate a unique distribution code 1956 for each second peer 1975.
  • a server 1950 may generate a unique recipient code 1952 for each second peer 1975.
  • a distribution key 1953 created for each second peer 1975 may be different from distribution keys 1953 created for other second peers 1975, although underlying server keys 1905 received from a first peer 1901 may be identical.
  • a registration key 1907 may be used to generate a distribution pre-key 1959.
  • any combination of a registration key 1907, a sender code 1954, a recipient code 1952, and a server key 1905 may be used to generate a distribution pre-key 1959.
  • a registration method 1700 may comprise storing one or more keys on a local database.
  • a second peer 1775 may be configured to receive and transmit information to a server 1750 through a transmitter/receiver of a second peer 1775.
  • a second peer 1775 may receive a distribution key 1753 from a server 1750 through a transmitter/receiver of a second peer 1775.
  • a second peer 1775 may receive a distribution code 1756 from a server 1750.
  • a second peer 1775 may receive a distribution key 1753 and a distribution code 1756 from a server 1750.
  • a distribution key 1753 and a distribution code 1756 may be stored in a memory 1778 of a second peer 1775.
  • a second peer 1775 may be configured to receive and transmit information to a server 1750 through a transmitter/receiver of a second peer 1775.
  • a second peer 1775 may receive a distribution key 1753 from a server 1750 through a transmitter/receiver of a second peer 17
  • a deposit code 1776 may be a one or more strings of characters of any length and may be generated in a random fashion. Alternatively, a deposit code
  • Selection objects may comprise a number of images. In a specific embodiment, selection objects may comprise a number of selection objects equal to 60. Each selection object may contain a unique selection code 1809. A selection code 1809 may comprise a one or more strings of characters, and in a specific embodiment, each selection code may comprise a string of five characters. A user may select a number of selection objects from selection objects received by a server 1850. In a specific embodiment, a user may select six selection objects. A user’s selection of selection objects may generate user input 1804 comprising a collection of selection codes 1809 that may be chosen by selecting specific selection object associated with each selection code 1809. In a specific embodiment, user input 1804 comprises six, five-character selection codes 1809.
  • a registration method may further comprise storing one or more keys on a local database, illustrated in FIG. 17.
  • a second peer 1775 may receive a distribution key 1753 and a distribution code 1756 from a server 1750.
  • a second peer 1775 may be one of several second peers 1775 in a network to receive distribution keys 1753 and distribution codes 1756 arising from a same transaction between a first peer 1701 and a server 1750 discussed above.
  • a second peer 1775 may store a distribution key 1753 and a distribution code 1756 in a memory 1778 of a second peer 1775.
  • a second peer 1775 may generate a deposit code 1776.
  • a deposit code 1776 comprises a single string of eight characters.
  • An authentication method may comprise a login method, illustrated in FIG. 20.
  • a login method 2000 may comprise creating one or more login keys, distributing one or more verification keys, verifying a verification key in a local database, and validating a verification process. Additionally, a login method 2000 may comprise communication between one or more first peers 2001, one or more servers 2050, and one or more second peers 2075.
  • Creating one or more login keys may further comprise generating a server key 2005 and a client key 2006 from user input 2004.
  • a server key 2005 and a client key 2006 may be used to generate a login key 2099.
  • a server key 2005, a client key 2006, and at least login salt 2024 may be used to generate a login key 2099.
  • Other embodiments may comprise different combinations of client keys 2006, server keys 2005, and login salts 2024 being used to generate login keys 2099.
  • Some information, e.g., a client key 2006, a login salt 2024 may be stored in the memory 2008 of a first peer 2001.
  • creating one or more login keys may comprise transferring information from a first peer 2001 to a server 2050.
  • a login key 2099 and a server key 2005 are transferred to a server 2050.
  • a stored distribution key 2053 and a verification salt 2063 received from a server 2050 may be used to generate a confirmation key 2081.
  • a second peer 2075 may transmit information to a server 2050, which may comprise any combination of a confirmation key 2081, a distribution code 2056, and any other information that may be necessary for a login method 2000.
  • a server 2250 may be configured to transmit information to a second peer 2275.
  • a transmitter/receiver 2241 of a server 2250 may transmit a verification key 2262 and a distribution code 2256 to a second peer 2275.
  • a transmitter/receiver 2241 of a server 2250 may transmit a verification key 2262, a distribution code 2256, a verification salt 2263, and other information necessary for a login method 2000 to a second peer 2275.
  • a server 2250 may transmit any combination of a distribution key 2253, a verification salt 2263, and a distribution code 2256 to a second peer 2275.
  • a processing migrator 2442 of a server 2450 may retrieve any combination of a verification salt 2463 and a distribution key 2453 which may be associated with a distribution code 2456 and stored in a database 2457 of a server 2450.
  • a retrieved distribution key 2453 may be a distribution key 2453 which was stored during a registration process.
  • a retrieved verification salt 2463 and a retrieved distribution key 2453 may be used by a data manipulator 2444 to generate a verification pre-key 2461 through concatenation of a verification salt 2463 and a distribution key 2453.
  • a verification pre-key 2461 may be converted 2412 by a data converter 2445 to a verification key 2462.
  • conversion 2412 may comprise using hash algorithms.
  • conversion 2412 may comprise using encryption methods.
  • Yet other embodiments may comprise conversion 2412 using a combination of hash algorithms and encryption methods.
  • a transmitter of a first device, a second device, a first server, and a second server may be configured to transmit and receive information from an exogenous source.
  • a first device may be configured to transmit and receive information from any combination of a second device, a first server, and a second server.
  • a first server and a second server may be configured to transmit and receive information from both a first device and a second device, and a second device may be configured to transmit and receive information from a first server, a first device, and a second server.
  • a memory of a first device and a second device and a database of a server may be configured to store information and to allow information to be retrieved.
  • a visual display may additionally comprise a means for a user to interact with a display, e.g., enter data, select characters, select objects, etc.
  • An internet application may be configured to transmit or receive information from any combination of a first server, a second server, a first device, and a second device.
  • a processor of a first device, a second device, a first server, and a second server may comprise a processing migrator, a data manipulator, a data converter, a processing generator, and a processing verifier.
  • a processing migrator may be configured to migrate data from one component within a first device, a second device, or first or second server to another component within a first device, a second device, or a first or second server.
  • a processing migrator may be configured to move data from a memory of a first device to a processor of a first device, or from a processor of a second device to a transmitter/receiver of a second device.
  • a processing generator may be configured to produce data.
  • data may comprise a one or more strings of characters of any length and may comprise bar codes and the like.
  • data may be produced in a random manner or a directed manner.
  • a processing verifier may be configured to compare two or more data and determine if those data are identical or different.
  • a processing verifier and a processing generator may be paired to determine if a first string of characters and a second string of characters are identical and generate a response based on the identity of a first and second string of characters.
  • an internet application 2590 may be configured to transmit information to a first server 2525.
  • a processing migrator 2642 may transfer information to a transmitter/receiver 2541 of an internet application 2590.
  • An internet application 2590 may transmit any combination of a first public key 2503, a first private key 2504, and any other information necessary to generate a bar code 2505.
  • a first server 2525 may be configured to receive information from an internet application 2590.
  • a transmitter/receiver 2541 of a first server 2525 may receive any combination of a first public key 2503, a first private key 2504, and any other necessary information for generating a bar code 2500 from an internet application 2590.
  • a first server 2525 may generate a random key 2527 and a random key 2527 may be generated by a processing generator 2646 of a first server 2525.
  • a random key 2527 may comprise one or more strings of characters of any length and characters may comprise letters, numbers, and symbols.
  • a bar code 2505 may be generated.
  • a processing generator 2546 may use a bar code precursor to generate a bar code 2505.
  • a bar code 2505 may comprise any type of barcode 2505, including without limitation any linear barcode, 2-dimensional bar code, or any type of readable indicia readily known to a person having ordinary skill in the art.
  • a bar code 2505 may comprise a QR code.
  • a bar code 2505 may be generated from any combination of a first public key 2503, a first private key 2504, a random key 2527, and any other information necessary for generating a bar code 2500.
  • a bar code 2505 may be generated by a data manipulator 2544 of a first server 2525 and may be based on a first public key 2503 and a random key 2527.
  • a first server 2525 may be configured to transfer information to an internet application 2590.
  • a second key agreement protocol pair 2651 may comprise any key agreement protocol pair that is readily known to a person having ordinary skill in the art.
  • a second key agreement protocol pair 2651 may comprise an Elliptic-curve Diffie- Hellman (ECDH) pair.
  • ECDH Elliptic-curve Diffie- Hellman
  • a second key agreement protocol pair 2651 may comprise a second private key 2652 and a second public key 2653.
  • a second private key 2652 and a first public key 2603 extrapolated from a bar code 2605 may be combined by a data manipulator 2644 to generate a secret key 2654.
  • a processing generator 2646 of a first device 2650 may generate any combination of a salt 2655, an initializing vector 2656, and an iteration number 2657.
  • a processing generator 2646 of a first device 2650 may generate each of a salt 2655, an initializing vector 2656, and an iteration number 2657.
  • a salt 2655, an initializing vector 2656, and an iteration number 2657 may respectively comprise a one or more strings of characters of any length and characters may comprise any combination of letters, numbers, or symbols.
  • An initializing vector 2656 may comprise a number of characters equal to n, and may additionally comprise an IV first part 2658 and an IV second part 2659.
  • An IV first part 2658 and an IV second part 2659 may each comprise a number of characters between one and n-1.
  • An iteration number 2657 may comprise a number of characters equal to n, and additionally comprise an IN first part 2660 and an IN second part 2661.
  • An IN first part 2660 and an IN second part 2661 may each comprise a number of characters between one and n-1.
  • a data manipulator 2644 may produce an IV first part 2658 and an IV second part 2659 from an initializing vector 2656.
  • a data manipulator 2644 may produce an IN first part 2660 and an IN second part 2661 from an iteration number 2657.
  • a secret key 2654, a salt 2655, an IV first part 2658, and an IN first part 2660 may be converted 2612 by a data converter 2645 to a masked secret key 2662, a masked salt 2663, a masked IV first part 2664, and a masked IN first part 2665, respectively.
  • an initializing vector 2656 may be converted 2612 by a data converter 2645 to a masked IV first part 2664.
  • an iteration number 2657 may be converted 2612 by a data converter 2645 to a masked IN first part 2665.
  • conversion 2612 may comprise using hash algorithms. In other embodiments, conversion 2612 may comprise using encryption methods.
  • Yet other embodiments may comprise conversion 2612 using a combination of hash algorithms and encryption methods.
  • an iteration number 2657 may remain intact, not generating an IN first part 2660 and an IN second part 2661 and a resulting IN first part 2660 may not be converted 2612.
  • a processing generator 2646 of a first device 2650 may generate a client key 2666.
  • a client key 2666 may comprise a one or more strings of characters of any length and characters may comprise any combination of letters, numbers, or symbols.
  • a client key 2666 may be converted 2612 by a data converter 2645 to a first masked client key 2667.
  • a client key 2667 may be converted 2612 by a data converter 2645 to a second masked client key 2668.
  • a client key 2666 may be converted 2612 by a data converter 2645 into each of a first masked client key 2667 and a second masked client key 2668. Conversion 2612 may comprise using hash algorithms.
  • conversion 2612 may comprise using encryption methods. In some embodiments, conversion 2612 may comprise a combination of hash algorithms and encryption methods.
  • a first device 2650 may be configured to transmit information to a first server 2625.
  • a transmitter/receiver 2641 of a first device 2650 may transmit any combination of a first masked client key 2667, a second masked client key 2668, a masked secret key 2662, a masked salt 2663, a masked IV first part 2664, and a masked IN first part 2665 to a first server 2625.
  • a first device 2650 may display each of an IV second part 2659 and an IN second part 2661 on a visual display 2669 of a first device 2650.
  • an iteration number 2657 may be displayed in its entirety on a visual display 2669 of a first device 2650.
  • generating one or more keys may comprise a first server 2725 receiving information from a first device 2750.
  • a transmitter/receiver 2741 of a first server 2725 may receive any combination of a masked secret key 2762, a second masked client key 2768, a masked salt 2763, a masked IV first part 2764, a masked IN first part 2765, and a first masked client key 2767 from a first device 2750.
  • a first server 2725 may be configured to transmit information to an internet application 2790.
  • a transmitter/receiver 2741 of a first server 2725 may transmit any combination of a masked secret key 2762, a second masked client key 2768, a masked salt 2763, a masked IV first part 2764, a masked IN first part 2765, and a first masked client key 2767 to a first server 2725.
  • a transmitter/receiver 2741 of a first server 2725 may transmit a masked secret key 2762, a second masked client key 2768, a masked salt 2763, a masked IV first part 2764, and a masked IN first part 2765 to a first server 2725.
  • a transmitter/receiver 2741 of a first server 2725 may transmit any combination of a masked secret key 2762, a second masked client key 2768, a masked salt 2763, and a masked IV first part 2764 to an internet application 2790 (collectively referred to as “received data 2728” from this point forward).
  • a web authentication method may comprise establishing a web session. Illustrated in FIG. 29, a transmitter/receiver 2941 of a first server 2825 may receive a third masked client key 2992 from an internet application 2990. According to some embodiments, a processing migrator 2942 of a first server 2825 may retrieve a stored first masked client key 2967 from a database 2929 of a first server 2825. A processing verifier 2947 may compare a retrieved first masked client key 2967 to a third masked client key 2992 received from an internet application 2990. A processing generator 2946 may generate a result 2930 based on the identity of a first masked client key 2967 and a third masked client key 2992.
  • systems and methods of generating keys (e.g., privacy keys) using controlled corruption may include one or more computing devices (e.g., first computing device, second computing device, third computing device, etc.) and one or more servers.
  • the one or more servers may comprise security engine, an action engine, and one or more libraries.
  • one or more servers may further comprise a client layer comprising the one or more computing device (e.g., first computing device, second computing device, etc.) may comprise a mobile platform and one or more libraries.
  • a computing device e.g., first computing device, second computing device, etc.
  • the administrative layer 3020 may further comprise an administrative security engine (ASE), 3024 an action engine (AE) 3026, an administrative partner library (APL) 3028, and one or more nodes 3029 associated with the administrative layer.
  • the one or more nodes 3029 may comprise 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 additionally comprise an administrative client library (ACL) 3034 and a client server application (CSA) 3036.
  • ACL administrative client library
  • CSA client server application
  • the client layer 3030 and the administrative layer 3020 may be in communication with one another using a VPN tunnel.
  • Registering a computing device (e g., first computing device) 3140 may comprise installing one or more applications on the computing device, where the one or more applications may comprise a mobile platform and one or more libraries.
  • the computing device and one or more applications may comprise a web layer of a system for generating privacy keys.
  • a computing device may be in communication (e.g., network communication, internet communication, virtual private network (VPN communication)) with one or more servers which may comprise an administrative layer.
  • VPN communication virtual private network
  • One or more servers comprised in an administrative layer may receive, from a computing device (e.g., first computing device) a first privacy code and one or more parameters associated with first data 3142.
  • first data may comprise any data (e.g., biometric data, documents, messages, etc.) which a user may desire to protect in transmission.
  • One or more parameters associated with first data may include any information about the first data, including without limitation, device identifiers, camera identifiers, file size, data format, application identifiers, user identifiers, personal identifiers, metadata, etc.
  • one or more parameters associated with the first data may include a file size, a public key associated with an asymmetric cryptographic key pair (which may identify the origin of the first data), and a manipulated version of the first data (e.g., a compressed or “zipped” version of the data).
  • parameters associated with a first data may include a base 64 version of a compressed (e.g., zipped) first data.
  • a privacy code may comprise a string of alphanumeric and/or symbolic characters associated with a user of the computing device or with the origin of the first data.
  • a privacy code is a first user input comprising a personal identification number (e.g., PIN) selected by a user of the computing device.
  • One or more servers comprised in an administrative layer may generate a chunk count, chunk names, and a public key associated with an APL 3143.
  • the chunk count and chunk names may be based, at least in part, on the received parameters associated with a first data.
  • a chunk count may be an integer that informs a downstream process of generating privacy keys.
  • Chunk names may be alphanumeric and/or symbolic identifiers which may be associated with one or more privacy keys generated in a downstream process.
  • a chunk count is generated based on parameters associated with a first data, for example, one or more of the size of the first data, the size of a compressed first data, or the size of a compressed first data that has been converted to a base 64 file.
  • Chunk names may be generated based on the chunk count. For example, where a chunk count is an integer equal to three, then three chunk names will be generated, each designed to be associated with a downstream privacy key. As another example, where a generated chunk count is equal to seven, then seven chunk names will also be generated. In a downstream step, seven privacy keys will be generated and each of the seven privacy keys will be assigned one of the chunk names.
  • a public key may be associated with an asymmetric cryptographic key pair associated with an APL comprised in the administrative layer.
  • a chunk count, chunk names, and public key may be transmitted from one or more servers comprised in an administrative layer to a computing device comprised in the web layer.
  • a third pre-key 3272 may be divided into chunks 3274, which may then be used to generate privacy keys 3275 without using a third corruptor 3273.
  • a third pre-key 3272 may be divided into chunks 3274 and one or more third corruptors 3273 (or first corruptors, second corruptors, etc.) may be added to the chunks 3274 to generate the privacy keys.
  • chunks 3274 will be generated (based on the chunk count 3260) and each resulting chunk 3274 will have an associated chunk name 3261.
  • a chunk 3274 is associated with a single chunk name 3261 to generate a privacy key 3275 comprising a chunk 3274 with a chunk name 3261.
  • Chunk names 3261 are useful in downstream processes to organize privacy keys 3275 to recreate the first data 3263 (e.g., a second data) on the server side.
  • Chunk names 3261 may, according to some embodiments, facilitate downstream ordering of the privacy keys 3275 to recreate the initial string.
  • chunk names 3261 e.g., ‘One’, ‘Two’, ‘Three’
  • the initial string ‘ 123455436789’ can be recreated on the server (e.g., administrative layer) side.
  • a computing device 3212 comprised in a web layer may transmit a quantity (equal to the chunk count 3260) of privacy keys 3275 to one or more servers comprised in an administrative layer.
  • a computing device 3212 may generate a second privacy code 3277 based on the first privacy code 3276.
  • a second privacy code 3277 may be an alphanumeric and/or symbolic string of characters.
  • a second privacy code 3277 may be a manipulated (e.g., compressed, hashed, encrypted, rearranged, truncated, etc.) first privacy code 3276.
  • a second privacy code 3277 is a hashed first privacy code 3276.
  • a privacy code (e.g., first privacy code 3276, second privacy code 3277) may be transmitted from a computing device 3212 comprised in the web layer of the system to one or more servers comprised in an administrative layer of the system.
  • a method of generating keys using controlled corruption may comprise receiving a quantity of privacy keys and a second privacy code from a computing device 3146, and generating second data based on the privacy keys 3148.
  • FIG. 33 illustrates a specific embodiment of generating second data based on the privacy keys 3300.
  • a second data 3382 may comprise a reconstructed version of a first data.
  • a first data may originate at a computing device comprised in a web layer of the system.
  • the first data may be used to generate privacy keys 3375, which may be a corrupted version of the first data which may be then transmitted in corrupted chunks (e.g., privacy keys) to one or more servers comprised in the administrative layer.
  • the privacy keys 3375 may be concatenated and the corruptors (e.g., first corruptor 3366, second corruptor 3368, third corruptor 3373, etc.) removed in a systematic fashion such that the resulting second data 3382 is a reconstructed version of the original first data.
  • the corruptors e.g., first corruptor 3366, second corruptor 3368, third corruptor 3373, etc.
  • One or more servers 3322 comprised in the administrative layer of the system may receive a quantity (e.g., one or more, two or more, three or more) of privacy keys 3375 from a computing device comprised in the web layer of the system.
  • One or more servers 3322 may receive a second privacy code 3377 from a computing device.
  • the one or more servers 3322 may concatenate the quantity (e.g., one or more, two or more, three or more) of privacy keys 3375 to generate a concatenated key 3376.
  • chunk names 3361 may guide the process of concatenation, may determine the order in which the privacy keys 3375 should be joined, or may direct the arrangement of the privacy keys 3375 to generate a concatenated key 3376.
  • one or more servers may generate a privacy code from a received second privacy code 3377.
  • a second privacy code 3377 is used to remove one or more corruptors (e.g., first corruptor 3366, second corruptor 3368, third corruptor 3373, etc.).
  • a base 64 file of a compressed second data 3380 may be converted (e.g., decoded) to a compressed second data 3381.
  • a compressed second data 3381 may be converted (e.g., unzipped) to a second data 3382.
  • a second data 3382 may be a reconstructed version of a first data.
  • a first data is information about a biometric scan
  • the second data will be a reconstructed version of the original information about the biometric scan.
  • a first data is a sensitive email, text, or other communication
  • a second data is a reconstructed version of the sensitive email, text, or other communication.
  • any method or operation performed by the one or more servers comprised in an administrative layer may also be performed by a processor comprised in a second computing device.
  • the first data is a text message originating from a mobile device comprising a first computing device
  • the second data (e.g., the reconstructed text message) may be generated at a processor comprised in a second mobile device (e.g., a second computing device).
  • An enrollment module may comprise methods to generate keys (e.g., privacy keys) using controlled corruption and distribute and store keys for later use.
  • keys e.g., privacy keys
  • privacy keys may be generated from the first data using controlled corruption, transmitted to a server, and stored on multiple nodes associated with the server.
  • a user subsequently enters their user input (e.g., biometric scan, password, first data, third data, etc.) into a first computing device in a sign in module
  • the privacy keys generated by controlled corruption and based on the user input in that module can be compared to privacy keys generated using a first data in the enrollment module and a user’s identity can be authenticated.
  • a user’s input such as biometric data, may be protected.
  • the user may be directed to a login page.
  • the user may sign in using an email address and/or a phone number that has been registered with the Dashboard and/or an SSO and may further enter an OTP that could be sent to the said email address and/or to a phone number for verification purposes.
  • the PIN may be dynamically provided to the user, or may have been previously provided to the user who subsequently enters said PIN in order to initiate the un-buzzing protection operation.
  • the Bee may display information such as how many files are buzzed, how many files are backed up, how many files are buzzed but are not backed up, how many files are not buzzed, etc. ii. Buzzing Operation - When a file is buzzed, it is locked up, protected, and may be backed up. A logo of the file may change from an original file logo to a Bee buzzed logo after the buzzing.
  • a client may pick one or multiple storage locations anywhere in their devices and/or their computing infrastructure that needs to be protected. b. The client may select a location for an entire Swarm and also customize such location selections based on a given Bee. c. The client may also set “No Go” locations that would be inaccessible to the Swarm so that fdes in such locations may not buzzed.
  • B ackup Locati on a The client, according to some embodiments may setup backup location through a backup location registration form associated with the dashboard or may use custom locations provided by Swarm. b. In some cases, the client may disable this backup function as needed.
  • a Bee When activated, a Bee may search approved locations for one or more files that need to be protected. b. Once the Bee identifies the one or more files, the Bee indexes said files according to some implementations. c. Properties of the identified files that are indexed include file path, hash value of the content of an identified file or files, hash value of an entire identified file, creation date and/or time of the identified file, modification date and/or time of the identified file, author or authors of an identified file, modifiers of the identified file, risk content/data of an identified file, etc. In some embodiments, risk data may include health card information, credit card information, drivers license information, social security information, etc. d.
  • Each Bee may send an index to the cloud and/or store a local copy of the index.
  • e. each time a file is buzzed, if the file's contents are changed, then the new data may be collected and saved to the cloud.
  • a user's device may store the latest index, whereas the cloud storage may store all indices associated with an identified file in an index history.
  • the cloud storage may store all indices associated with an identified file in an index history.
  • the local index may also deleted. In such instances, the file that is moved or deleted may be flagged with a status like “Not Available in device (NAD)” in the cloud.
  • NAD Not Available in device
  • file movements may be identified by comparing a new index against a NAD file index. j . If a file movement is identified, then it may be reflected in the cloud index as well. Once identified as a moved file, a NAD file index may be appended to the new file index as history.
  • the properties, parameters, or variables may be associated with a sensitivity level (e.g., from a scale of 1-10) that ascribes a sensitivity level or security value (e.g., a value of 1 indicates the file in question has very little sensitive data while a value of 10 indicates that the file has extremely sensitive content) to the file and or a vulnerability level having varying degrees of vulnerability that can be ascribed to a file and/or device.
  • a sensitivity level e.g., from a scale of 1-10) that ascribes a sensitivity level or security value (e.g., a value of 1 indicates the file in question has very little sensitive data while a value of 10 indicates that the file has extremely sensitive content) to the file and or a vulnerability level having varying degrees of vulnerability that can be ascribed to a file and/or device.
  • the one or more flags may comprise a priority rating of a file on a given scale (e.g., a scale of 1-10 with 1 being a low priority rating and 10 being
  • a user may provide a custom flag (e.g., user-defined index information or user-specified index information) based on user preferences to further classify or otherwise characterize a file or contents of a file.
  • the custom flag may similarly be quantified on a user defined scale as done for the sensitivity level and/or the priority rating flags.
  • an Al and/or an ML tool may generate one or more flags (ALgenerated or ML-generated index information associated with the file) to characterize the file or multiple files.
  • the Al and/or ML tool may analyze a file and/or the contents of the file and automatically assign the file or its contents with one or more flags.
  • the Al and/or ML tool may analyze a file and/or the contents of the file and recommend one or more flags to a user who then selects one or more flags to characterize the file or the contents of the file.
  • the analysis by the Al and/or ML tool may be based on a parameterization of the Al and/or ML tool by an administrator, training data generated from using the Al and/or MIL tool to analyze and ascribe flags to similar and/or dissimilar files or file contents, etc.
  • index information associated with the file may be accordingly updated such that metadata associated with the file may also be updated.
  • the flags assigned to a file based on user-input and/or ML-inputs and/or Al inputs may be classified based on qualitative parameters such as high priority, medium priority, low priority, high sensitivity, medium sensitivity, low sensitivity, etc.
  • a client or organization associated with the dashboard may to control and/or govern the life cycle of the file that has been flagged.
  • the client or organization may use, store, and/or distribute the file as the case may require. In some cases, this may assist in Effective Restoration Planning (discussed below) by helping the Al and/or ML tool to select an order of files during restoration and thus avoid data dumping and thereby enable systematic restoration of data.
  • the indexing operations discussed above, in conjunction with the buzzing and/or unbuzzing operations discussed herein allow, in some cases, surgical restoration of data where the dashboard (e.g., Al and/or ML tool within the dashboard) determines the data restoration needs of a client or user, assesses the requirements (e.g., fde size, bandwidth, computing power of user device, storage capacity of user device, etc.) of the data restoration operation, and optimally restoring the data requiring restoration.
  • the dashboard e.g., Al and/or ML tool within the dashboard
  • the requirements e.g., fde size, bandwidth, computing power of user device, storage capacity of user device, etc.
  • a buzzing operation may comprise identifying one or more files to be buzzed using a buzzer.
  • one or more files may be identified and buzzed using an Autnhive Buzzer.
  • the one or more identified files may be encrypted using an advanced encryption standard (AES).
  • AES advanced encryption standard
  • the one or more identified files may be encrypted using an AES- 128, an AES- 192 encryption, or an AES-256 encryption, or an AES-512 encryption or an AES-1024 encryption.
  • AES advanced encryption standard
  • This disclosure contemplates other AES's other than those presented herein and/or other data obfuscation and/or other data encryption techniques other than those mentioned above.
  • a controlled corruption process may be combined with the encryption of the one or more identified files.
  • Such a controlled corruption process may include: i. breaking up a file or plurality of files comprised in the one or more identified files into a random number of data chunks with various random sizes, ii. encrypting each data chunk comprised in the random number of data chunks using one or more of the AES encryptions provided above, such that each data chunk includes corruptors before and after encryption of each data chunk.
  • a PIN may be incorporated into the buzzing operation such that the PIN may be required before one or more of the encrypted data chunks are decrypted. iii.
  • one or more of the data chunks may be randomly named with or without any particular ordering information such that the given order of the structure of the data chunks may be used to generate an order key which may be subsequently encrypted using one or more of the AES's provided above.
  • the data risk index may be calculated using contents of one or more identified files that have been searched for high-risk data such as those discussed above and/or other data that can cause substantial risk to a business if rendered unavailable (e.g., unavailable to the business in question or otherwise held hostage by hackers or the like) or rendered publicly available. Based on a sum of all data risk values associated with a given identified file or associated with a plurality of identified files, a data risk index may be calculated for the given file or the plurality of identified files as the case may be.
  • a subject matter expert e.g., administrator, etc.
  • SME subject matter expert
  • an authorized SME may record key data and/or a risk value data associated with buzzed and/or unbuzzed data to provide or revoke access to the buzzed and/or unbuzzed data.
  • a score may be given to the identified file.
  • Files created by an Architect e.g., role-based priority
  • files created on a CEO's e.g., rank-based device priority
  • computing device may be assigned a higher priority than files created on the computing device of a junior associate's computer.
  • effective restoration planning may be initiated based on the time a file is created and may extend through the life cycle of the file.
  • the intelligence-based tool e.g., Al, ML, DL, etc.
  • the intelligence-based tool used in association with a Swarm may calculate one or more scores indicative of at least a best case scenario and/or a worst case scenario and/or an intermediate case scenario.
  • the one or more scores may be used for effective restoration which includes: i. surgical file selection based on a data risk index, a file type, and an inner location of sensitive chunks, etc. ii. regressive performance assessment, iii. business continuity priority index, and i v . storage 1 ocati on b andwi dth .
  • one or more clients may be notified of the ERP, any issues identified during the ERP, etc.
  • Plans generated and/or associated with the ERP may be viewed, weighed and/or re-weighed by one or more clients. If re-weighed, the intelligence-based tool may leam from the weighed and/or re-weighed plan. b.
  • an inner location of a sensitive chunk of data (e.g., data chunk generated from breaking a file or a plurality of files into a random number of chunks) associated with a file or a plurality of files may be stored as index information because instead of buzzing/unbuzzing entire files, we can surgically buzz and/or unbuzz a file or given set of files based on computation power, storage capacities of storage devices, and latency considerations of a computing devices associated with the file or the given set of files. This may be achieved using the intelligent-based tools previously discussed along with one or more sensitivity flagging associated with the file or the set of files. Consequently, a surgical restoration in varying degrees of granularity associated with the file content or the content of the set of files may be achieved.
  • c. Regressive Performance Assessment of devices across an enterprise may be stored regularly when executing a buzzing operation and/or an unbuzzing operation and/or a backup operation and/or a restore operation occurs.
  • the following include data or telemetries that may be stored in the cloud for further analysis: i. average backup of devices vs. number of buzzed and/or unbuzzed files, ii. network latency relative to backup and/or restore operation vs. number of buzzed and/or unbuzzed files, iii. network latency to restore vs. number of sensitive files, iv. cloud network bandwidth speed vs. edge device network throughput during restoration of sensitive files at an edge device, v. daily restoration time vs.
  • files with data risk indices e.g., indices of 5, 6, 7, 8, 9 and 10 where the higher the value of the index, the higher the risk.
  • network latency to restore a high priority file of one or more IOT devices vs. network latency to restore data associated with, for example, CEO's device.
  • network latency of edge devices with specific device risk indices e.g., indices of 5, 6, 7, 8, 9 and 10.
  • comparison of elapsed time for full unbuzzing vs. surgical unbuzzing of sensitive data files e.g., a file or a number of files containing sensitive data).
  • effective restoration planning and mocking of restoration may be tested on a regular basis across multiple client devices. For example, all of client devices may be subject to effective restoration planning and mocking of restoration may be regularly tested. This may make data restoration more effective and efficient and allow a given business employing such mechanisms to be more resilient.
  • KMS 5 KEY MANAGEMENT SYSTEM
  • KMS Key Generation and Use i. In one Iteration:
  • the data keys may be generated by the cloud (e.g., cloud computing device) and shared to a given device.
  • the cloud e.g., cloud computing device
  • a Bee may generate device keys and share the public key with the cloud. ii. In another Iteration:
  • the data keys may be generated by computing device and shared to the cloud.
  • buzzed data keys may be stored in the cloud.
  • the data keys may be buzzed with the device key (in the cloud) when they are stored in the cloud.
  • each data key may have a unique cloud key.
  • device public keys may be stored in the cloud. ii. In another Iteration:
  • buzzed data keys may be stored in the device and backed-up in the cloud.
  • the bee may buzz the data key using the device's public key (from the cloud) and sends it to the cloud.
  • each data key may have a unique cloud key.
  • device public keys may be stored in the cloud.
  • a cloud buzzed data key(s) using the device public key may be generated
  • the Bee may use its private key to unbuzz the data key and/or buzz/unbuzz the data.
  • the data key(s) may be generated by the device and shared to the cloud
  • the data key backed up may be buzzed with a device key (from the cloud for example).
  • Table 1 provides a visual representation of the life cycle and phases of a device key and/or a data keys.
  • Crypto-Period - i both data key(s) and the device key(s) may have to be changed on a regular basis. The time between each key change may be called the crypto-period of the key in question. ii. In some cases, when the device keys are being changed, the following operations may be executed:
  • each Bee may generate the device key and store the private key associated with the device key while sharing the public key with the cloud.
  • each Bee may re-buzz its data key with the new device key.
  • the computing operation(s) of the at least one executable command may comprise one or more of computing operations that modify one or more applications on a first computing device of a first user; data replication operations that replicate data of the first computing device of the first user; data blockage operations that block access to at least the content data and one or more files on the first computing device of the first user; one or more security operation that is performed on the first computing device of the first user; or other operations on a computing device of a user.
  • the computing operations, data replication operations, data blockage operations, security operations, or other operations on a computing device of a user are not part of the executable command.
  • the content data comprises one or more of a file, a folder, a plurality of files, or a plurality of folders.
  • the corruptor may comprise one or more of an alphanumeric character or a symbolic character.
  • the first user is a hacker, a threat-actor, an adversary, a bad actor, or the like that seeks to intercept, decrypt, or otherwise gain access to the content data without authorization.
  • the plurality of data chunks comprise a random number of data chunks. It is appreciated that the key, name, or other indicia of some embodiments, discussed in conjunction with block 4202 of the flowchart of FIG. 42, may be encrypted based on an encryption protocol used to encrypt at least one data chunk comprised in the plurality of data chunks of the content data.
  • flowchart 4400 may include: adding, using the one or more computing device processors, a third corruptor to the second data chunk before a second encryption operation, the third corruptor comprising one or more of a third alphanumeric character or a third symbolic character; executing the second encryption operation, using the one or more computing device processors, on the second data chunk comprised in the plurality of data chunks based on the encryption protocol; and adding, using the one or more computing device processors, a fourth corruptor to the second data chunk after the second encryption operation, the fourth corruptor comprising one or more of a fourth alphanumeric character or a fourth symbolic character.
  • Flowchart 4400 may also include: determining, using the one or more computing device processors, a first identifier for the first data chunk comprised in the plurality of data chunks; and determining, using the one or more computing device processors, a second identifier for the second data chunk comprised in the plurality of data chunks.
  • the corruption operation referenced above comprises the steps of: determining, at the one or more first servers, a second security computing operation, wherein the second security computing operation comprises a second access control computing operation, wherein the second access control computing operation restricts access to the file comprising protected content data based on one or more parameters of the second security computing operation.
  • the disclosed method comprises receiving, at the one or more first servers or the one or more second servers, a first indicia associated with the one or more parameters of the first security computing operation further comprises receiving the first indicia from a first computing device, wherein the first indicia is a first user input from the first computing device.
  • determining, at the one or more first servers or the one or more second servers, based on the first indicia associated with the one or more parameters of the first security computing operation, whether the first user of a first computing device is permitted to access the file comprising protected content data further comprises determining whether the password associated with the first user is correct.
  • the archive file comprises one or more files including metadata associated with the file comprising protected content data.
  • receiving, at the one or more first servers or the one or more second servers, a first indicia associated with the one or more parameters of the first security computing operation further comprises receiving the first indicia from a first computing device, wherein the first indicia is a first user input from the first computing device.
  • the first user input from the first computing device may be a password associated with the first user.
  • determining, at the one or more first servers or the one or more second servers, based on the first indicia associated with the one or more parameters of the first security computing operation, whether the first user of a first computing device is permitted to access the file comprising protected content data further comprises determining whether the password associated with the first user is correct.
  • the archive file may comprise one or more files including metadata associated with the file comprising protected content data.
  • one or more of the first security computing operation and the access control computing operation is a computing operation that executes to one or more of modify one or more application of a first computing device of a first user, replicate data of the first computing device of the first user, and block access to at least the file comprising content data and one or more files on the first computing device of the first user.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Storage Device Security (AREA)

Abstract

La technologie divulguée comprend des systèmes et des procédés de protection informatique de données de contenu. Le procédé peut consister à recevoir des données de contenu stockées sur un système informatique et à exécuter une opération de corruption pour générer des données protégées et à ajouter au moins une première couche de sécurité aux données de contenu. Le procédé peut en outre consister à exécuter une opération d'archivage comprenant une opération d'encapsulation de données qui combine les données protégées avec une instruction exécutable pour générer des données sécurisées. L'opération d'encapsulation de données peut ajouter une ou plusieurs secondes couches de sécurité aux données de contenu de sorte que l'instruction exécutable est exécutée pour bloquer électroniquement l'accès aux données de contenu par un utilisateur non autorisé. De plus, les données sécurisées peuvent être automatiquement extraites pour distribuer les données de contenu à un utilisateur lorsque l'utilisateur est autorisé à accéder aux données de contenu ou lorsqu'un utilisateur non autorisé parvient à passer ou contourne une ou plusieurs couches de sécurité.
PCT/IB2024/000055 2023-01-04 2024-01-04 Archive à extraction automatique à des fins de protection de données WO2024147078A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202363437052P 2023-01-04 2023-01-04
US63/437,052 2023-01-04

Publications (2)

Publication Number Publication Date
WO2024147078A2 true WO2024147078A2 (fr) 2024-07-11
WO2024147078A3 WO2024147078A3 (fr) 2024-08-15

Family

ID=91803647

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2024/000055 WO2024147078A2 (fr) 2023-01-04 2024-01-04 Archive à extraction automatique à des fins de protection de données

Country Status (1)

Country Link
WO (1) WO2024147078A2 (fr)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11329817B2 (en) * 2017-10-19 2022-05-10 Devi Selva Kumar Vijayanarayanan Protecting data using controlled corruption in computer networks

Also Published As

Publication number Publication date
WO2024147078A3 (fr) 2024-08-15

Similar Documents

Publication Publication Date Title
US11329817B2 (en) Protecting data using controlled corruption in computer networks
JP6941146B2 (ja) データセキュリティサービス
US12058115B2 (en) Systems and methods for Smartkey information management
US10904014B2 (en) Encryption synchronization method
US20190311148A1 (en) System and method for secure storage of electronic material
US9740849B2 (en) Registration and authentication of computing devices using a digital skeleton key
US8966287B2 (en) Systems and methods for secure third-party data storage
US20170063827A1 (en) Data obfuscation method and service using unique seeds
JP6678457B2 (ja) データセキュリティサービス
WO2019199288A1 (fr) Système et procédé de stockage sécurisé du matériel électronique
US12047500B2 (en) Generating keys using controlled corruption in computer networks
US8667281B1 (en) Systems and methods for transferring authentication credentials
AU2018100503A4 (en) Split data/split storage
JP2018106026A (ja) アクセス管理システム、アクセス管理方法及びプログラム
US9882879B1 (en) Using steganography to protect cryptographic information on a mobile device
WO2024147078A2 (fr) Archive à extraction automatique à des fins de protection de données
WO2023052845A2 (fr) Protection de données à l'aide d'une altération contrôlée dans des réseaux informatiques
WO2024157087A1 (fr) Systèmes et procédés de gestion et de protection de données dans des réseaux informatiques
Nyamwaro Application for enhancing confidentiality and availability for sensitive user data using AES algorithm in smartphone devices
KR20230024279A (ko) 컴퓨터 네트워크에서 제어된 손상을 이용하여 키를 생성하는 방법
WO2024026428A1 (fr) Affectation, attribution et gestion d'identités numériques
RU2481632C1 (ru) Система и способ восстановления пароля и зашифрованных данных на мобильных устройствах

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24738595

Country of ref document: EP

Kind code of ref document: A2