Note: Descriptions are shown in the official language in which they were submitted.
WO 2021/229410
PCT/1B2021/053964
1
GENERATING KEYS USING CONTROLLED CORRUPTION IN COMPUTER
NETWORKS
Field of Invention
This invention 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.
Background of the Invention
All organizations are challenged with securing their data from potential
security
breaches. Only through data security can an organization ensure that their
communications are secure and that only authorized persons are granted access
to
their systems across multiple technologies. Thus, data security and authorized
system
access are two of the major challenges that organization must wrestle with
today.
Presently there are many systems and methods that effect various types of
authentication of users of systems and networks. These various types of
authentication
have differing levels of security and reliability. The following are examples
of types
of prior art authentication methods for systems and networks.
U.S. Patent No. 6,962,530 issued to IGT on November 8, 2005, discloses an
architecture and method for a gaming-specific platform that features secure
storage
and verification of game code and other data. The method further provides a
user with
the ability to securely exchange data with a computerized wagering game
system.
This invention does not involve spreading out login information amongst
multiple
devices.
U.S. Patent No. 9,053,306 issued to NEC Solution Innovators, Ltd. on June 9,
2015,
discloses an authentication system operable to calculate a first and a second
hash
value from the login information inputted by a user. A session will be
established
between a server and a terminal if the first and second hash values match each
other.
This invention does not involve holding back portions of the encrypted
details.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
2
U.S. Patent No. 8,989,706 issued to Microsoft Corporation on March 24, 2015,
discloses systems, method and/or techniques that relate to automated secure
pairing
for devices, relating to parallel downloads of content using devices. The
tools for
pairing the devices may perform authentication protocols based on addresses
and on
keys. This invention does not involve holding back portions of the encrypted
details.
U.S. Patent No. 8,356,180 issued to Koninklijke Philips Electronics N.V. on
January
15, 2013, discloses a method for multi-dimensional identification,
authentication,
authorization and key distribution relation to secure communications at a deep
common security domain. This invention cannot authenticate a transaction
without the
user revealing the user's key to the system.
U.S. Patent No. 6,847.995 issued to United Devices, Inc. on August 25, 2000,
discloses a security architecture and an associated method for providing
secure
transmissions within distributed processing systems. This invention does not
involve
multi-layer encryption or holding back portions of the encrypted details.
U.S. Patent Application Publication No. 2017/0149796 filed by Yaron Gvili on
November 23, 2016, discloses a system and technique for allowing a third party
verifier to verify aspects of secured data, or the successful communication
thereof.
This invention does not involve multi-layer encryption or holding back
portions of the
encrypted details.
U.S. Patent Application Publication No. 2011/0246779 filed by Isamu Teranishi
on
June 6, 2011, discloses a zero-knowledge proof system that allows a discrete-
logarithm zero-knowledge proof. This invention does not involve multi-layer
encryption or holding back portions of the encrypted details.
The prior art encryption methods and systems are particularly vulnerable to
the
intervention of third parties into the transfer of data and information
between a user
and a user and a system or network. If the third party can access data in
transit, it can
extrapolate login details from such information. If all of the login details
are available
from data transferred between the user and the system then the third party may
be able
to login to the system using the user's login details. This creates a security
hazard for
present day systems if known authentication methods and systems are utilized.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/IB2021/053964
3
What is needed is an authentication method and system that will protect a
user's login
details from being obtained through third party interference with transmitted
data.
Summary of the Invention
According to some embodiments, a method of processing keys generated using
controlled corruption may comprise registering a first computing device at one
or
more servers, the one or more servers comprising a security engine and an
action
engine; receiving, at the one or more servers, a first privacy code and one or
more
parameters associated with first data from the first computing device, the
first privacy
code being based on first user input at the first computing device and the
first data
being based on second user input at the first computing device; generating, at
the one
or more servers, a chunk count and a public key, wherein the chunk count is
based on
the one or more parameters associated with first data, and the public key is
part of an
asymmetric cryptographic key pair; transmitting the chunk count and the public
key
from the one or more servers to the first computing device; receiving, at the
one or
more servers, data associated with a quantity of privacy keys and a second
privacy
code from the first computing device, wherein: the privacy keys are based on
the first
data, the chunk count, and one or more corruptors, the second privacy code is
based
on the first privacy code, and the quantity of the privacy keys is equal to
the chunk
count; generating, at the one or more servers, second data based on the
privacy keys,
the generating the second data comprising steps of: concatenating the privacy
keys to
generate a concatenated key, and removing the one or more corruptors from the
concatenated key to generate the second data.
According to some embodiments, a method of processing keys generated using
controlled corruption may comprise generating, at the one or more servers, two
or
more chunk names; and transmitting the two or more chunk names to thc first
computing device.
According to some embodiments, the privacy keys are further based on the two
or
more chunk names.
According to some embodiments, concatenating the privacy keys to generate the
concatenated key is based on the two or more chunk names.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
4
According to some embodiments, the one or more corruptors comprises three
corruptors.
According to some embodiments, at least one of the corruptors is based on the
first
privacy code.
According to some embodiments, removing the one or more corruptors to generate
the second data comprises removing one or more first corruptors from the
concatenated key to generate first cleaned data; removing one or more second
corruptors from the first cleaned data to generate second cleaned data;
removing one
or more third corruptors from the second cleaned data to generate a base 64 of
compressed data; decoding the base of the compressed second data to generate
the
compressed data; and decompressing the compressed data to generate the second
data,
wherein the privacy code is used to remove at least one of the one or more
first
corruptors, the one or more second corruptors, and the one or more third
corruptors.
According to some embodiments, the first privacy code is used to remove at
least one
of the corruptors.
According to some embodiments, the second privacy code is used to remove at
least
one of the corruptors.
According to some embodiments, the first data comprises a targeted
communication.
According to some embodiments, the second user input comprises at least one of
an
alphanumeric string of characters, biometric data, a password, an eye scan, a
photograph, and a fingerprint.
According to some embodiments, a method of generating keys using controlled
corruption may comprise the steps of: generating a first privacy code and one
or more
parameters associated with first data at a first computing device, the first
privacy code
based on first user input and the first data based on second user input;
transmitting the
first privacy code and the one or more parameters associated with the first
data from
the first computing device to one or more servers; receiving, at the first
computing
device, a chunk count and a public key from the one or more servers, wherein
the
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
chunk count is based on the one or more parameters associated with the first
data and
the public key is part of an asymmetric cryptographic key pair; compressing,
at the
first computing device, the first data to generate compressed first data;
generating, at
the first computing device, a first pre-key based on the compressed first data
and one
5 or more first corruptors; generating, at the first computing device, the
second pre-key
based on the first pre-key and one or more second corruptors; generating, at
the first
computing device, two or more chunks based on the second pre-key and the chunk
count; generating, at the first computing device, two or more privacy keys
based on
the two or more chunks; and transmitting the two or more privacy keys to the
one or
more servers.
According to some embodiments, the generating the two or more chunks based on
the
second pre-key and the chunk count comprises: corrupting the second pre-key
using a
salt to generate a third pre-key, corrupting the third pre-key using one or
more third
corruptors; and dividing the corrupted third pre-key into the two or more
chunks
based on the chunk count.
According to some embodiments, a method of generating keys using controlled
corruption may comprise receiving, at the first computing device, two or more
chunk
names.
According to some embodiments, the two or more privacy keys are additionally
based
on the two or more chunk names.
According to some embodiments, a method of generating and distributing keys
using
controlled corruption may comprise registering a first computing device at one
or
more servers; receiving, at the one or more servers, a first privacy code and
one or
more parameters associated with first data from the first computing device,
the first
privacy code being based on first user input at the first computing device and
the first
data being based on second user input at the first computing device;
generating, at the
one or more servers, a chunk count and a public key, wherein the chunk count
is
based on the one or more parameters associated with first data, and the public
key is
part of an asymmetric cryptographic key pair; transmitting the chunk count and
the
public key from the one or more servers to the first computing device;
receiving, at
the one or more servers, data associated with a quantity of first privacy keys
and a
second privacy code from the first computing device, wherein the first privacy
keys
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
6
are based on the first data, the chunk count, and one or more corruptors; the
second
privacy code is based on the first privacy code; and the quantity of the first
privacy
keys is equal to the chunk count; generating, at the one or more servers,
second data
based on the first privacy keys, the generating the second data comprising the
steps
of: concatenating the privacy keys to generate a concatenated key; removing
the one
or more corruptors from the concatenated key to generate the second data;
generating,
at the one or more servers, a result based on the second data; generating, at
the one or
more servers and based on the result, a receiver identifier and a privacy code
identifier, wherein the receiver identifier is associated with one or more
nodes and the
privacy code identifier is based on the second privacy code; and distributing
the first
privacy keys. the receiver identifier, and the privacy code identifier to the
one or more
nodes.
According to some embodiments, a method of generating keys using controlled
corruption may comprise the steps of receiving, at the one or more servers,
two or
more privacy keys based on third data from the first computing device; and
generating
sign-in data, wherein the sign-in data is based on the two or more privacy
keys based
on the third data.
According to some embodiments, a method of generating keys using controlled
corruption may comprise the steps of retrieving, based on at least one of the
receiver
identifier and the privacy code identifier, the privacy keys stored at the one
or more
nodes; and generating enrollment data, wherein the enrollment data is based on
the
privacy keys retrieved from the one or more nodes.
According to some embodiments, a method of generating keys using controlled
corruption may comprise the steps of comparing the sign-in data to the
enrollment
data; and generating a result.
According to some embodiments, a system may comprise a server, the server
comprising: a memory comprising server instructions; and a processing device
configured for executing the server instructions, wherein the server
instructions cause
the processing device to perform operations of: registering a first computing
device at
one or more servers, the one or more servers comprising a security engine, an
action
engine, a library, and one or more nodes associated with the one or more
servers;
receiving, at the one or more servers, a first privacy code and one or more
parameters
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
7
associated with first data from the first computing device, the first privacy
code being
based on first user input at the first computing device and the first data
being based on
second user input at the first computing device; generating, at the one or
more servers,
a chunk count and a public key, wherein the chunk count is based on the one or
more
parameters associated with first data, and the public key is part of an
asymmetric
cryptographic key pair; transmitting the chunk count and the public key from
the one
or more servers to thc first computing device; receiving, at the one or more
servers, a
quantity of privacy keys and a second privacy code from the first computing
device,
wherein: the privacy keys are based on the first data, the chunk count, and
one or
more corruptors; the second privacy code is based on the first privacy code;
and a
number of the privacy keys is equal to the chunk count; generating, at the one
or more
servers, second data based on the privacy keys, the generating the second data
comprising the steps of: concatenating the privacy keys to generate a
concatenated
key; and removing the one or more corruptors from the concatenated key to
generate
the second data.
In this respect, before explaining at least one embodiment of the invention in
detail, it
is to be understood that the invention is not limited in its application to
the details of
construction and to the arrangements of the components set forth in the
following
description or illustrated in the drawings. The invention is capable of other
embodiments and of being practiced and carried out in various ways. Also, it
is to be
understood that the phraseology and terminology employed herein are for the
purpose
of description and should not be regarded as limiting.
Brief Description of the Drawings
The invention will be better understood and objects of the invention will
become
apparent when consideration is given to the following detailed description
thereof.
Such description makes reference to the annexed drawings wherein:
FTG. 1 is a system drawing showing an embodiment of the authentication system
of
the present invention.
FTG. 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 invention.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
8
FIG. 3 is a system drawing showing a configuration of elements operable to
undertake
a registration process of an embodiment of the present invention.
FIG. 4 is a system drawing showing a configuration of elements operable to
undertake
an access process of an embodiment of the present invention.
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
invention.
FIG. 6 is a system drawing showing a configuration of elements operable to
undertake
a decoding process of an embodiment of the present invention.
FIG. 7 is a system drawing showing elements of a user device of an embodiment
of
the present invention.
FIG. 8 is a system drawing showing elements of a client system of an
embodiment of
the present invention.
FIG. 9 is a system drawing showing elements of a client display unit of an
embodiment of the present invention.
FIG. 10 is a system drawing showing elements of an verification system of an
embodiment of the present invention.
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 invention.
FIG. 12 is a system drawing showing a configuration of elements operable to
undertake the generation and processing of noise and keys for authentication
of a user
in accordance with an embodiment of the present invention.
FIG. 13 is a system drawing showing a configuration of elements operable to
undertake the verification of keys for authentication of a user in accordance
with an
embodiment of the present invention.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
9
FIG. 14 is a system drawing showing a configuration of elements operable to
undertake the verification of tokens for authentication of a user in
accordance with an
embodiment of the present invention.
FIG. 15 is a system drawing showing a configuration of elements operable to
undertake the verification of a challenge via a client display system for
authentication
of a user in accordance with an embodiment of the present invention.
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 invention.
FIGURE 17 illustrates a registration method, according to one embodiment of
the
present invention.
FIGURE 18 illustrates a method of creating one or more keys, according to one
embodiment of the present invention.
FIGURE 19 illustrates a method of distributing one or more keys, according to
one
embodiment of the present invention.
FIGURE 20 illustrates a login method, according to one embodiment of the
present
invention.
FIGURE 21 illustrates a method of creating one or more keys, according to one
embodiment of the present invention.
FIGURE 22 illustrates a method of distributing one or more verification keys,
according to one embodiment of the present invention.
FIGURE 23 illustrates a method of verifying a verification key in a local
database,
according to one embodiment of the present invention.
FIGURE 24 illustrates a method of validating a verification process, according
to one
embodiment of the present invention.
FIGURE 25 illustrates a method of generating one or more bar codes, according
to
one embodiment of the present invention.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
FIGURE 26 illustrates a method of generating one or more keys, according to
one
embodiment of the present invention.
FIGURE 27 illustrates a method of generating one or more keys, according to
one
embodiment of the present invention.
5 FIGURE 28 illustrates a method of generating one or more keys, according
to one
embodiment of the present invention.
FIGURE 29 illustrates a method of establishing a web session, according to one
embodiment of the present invention.
FIGURE 30 illustrates a system for generating keys using controlled
corruption,
10 according to some embodiments.
FIGURE 31 illustrates a method of generating keys using controlled corruption,
according to some embodiments.
FIGURE 32 illustrates a method of generating keys using controlled corruption,
according to some embodiments.
FIGURE 33 illustrates a method of generating keys using controlled corruption,
according to some embodiments.
FIGURE 34 illustrates a method of generating keys using controlled corruption,
according to some embodiments.
FIGURE 35 illustrates a method of using keys generated using controlled
corruption
for authentication, according to some embodiments.
In the drawings, embodiments of the invention are illustrated by way of
example. It is
to be expressly understood that the description and drawings are only for the
purpose
of illustration and as an aid to understanding, and are not intended as a
definition of
the limits of the invention.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/TB2021/053964
11
Detailed Description of the Preferred Embodiment
The present invention is an authentication method and system operable to
authenticate
users, data, documents, devices and transactions. Embodiments of the present
invention may be operable with any system or network of any organization or
individual. The authentication method and system arc operable to disburse
unique
portions of login related information amongst multiple devices. The disbursed
portions of login related information arc 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.
Any reference herein to "client system" means either the network or system of
an
organization or individual. Any reference herein to a "user 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. Any
reference to the "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.
For clarity, when reference is made to any unit or element of the
authentication
system "accessing" another unit or element, this may involve any of the
following: (i)
the unit or element accessing the other unit or element to obtain information
therefrom; or (ii) the unit or element sending a request to the other unit or
element for
information to be retrieved or generated, and once such information is
retrieved or
generated in response to the request, such information can be sent to the unit
or
element that sent the request.
When a user logs into a client system using a user device, the creation,
transfer,
storage or authentication of login related information between the user device
and th.e
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
12
client system can be vulnerable to attack by a third party. As a result of the
third
party's attack on user device or client system, during the creation, transfer,
storage
and/or authentication of login related information between, the third party
may obtain
and/or use such information for nefarious purposes. For example, the third
party may
login to the client system using the login details they have obtained and
thereby
achieve unauthorized access to the client system or move laterally to systems
connected to the client system by obtaining more login related information
from the
client system or otherwise. As another example, the -third party may utilize
the data,
documents or transaction information obtained due to the attack for a variety
of
unauthorized purposes (i.e., dissemination of the information to other
parties, use of
the information to obtain a market advantage, holding the information hostage
for a
ransom, espionage, subversion etc.). The present invention decreases the
vulnerability
of a client system to such unauthorized usage of the client system or data,
documents
or transaction information created, transferred. and/or stored between such
client
system and a user device.
The method of the present invention involves a user utilizing a user device to
login to
the client system of an organization or person. The login related information
will be
hashed and/or encrypted through a single or multi-layer hashing and/or
encryption
process(es). In particular at least a portion of the encrypted and/or hashed
key may be
generated and stored in the user's device. Other unique portions of the login
related
information will be stored in other devices in the environment. The
disbursement of
unique portions of the login related information amongst multiple devices
means a
third party who accesses information transferring between the client system
and the
user's device will not be able to obtain any or all of the information
required for a
successful login to the client system.
Moreover, in one aspect of the current system, to authenticate data documents,
devices, transactions and/or a user, 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 invention without the user device having
to
reveal a key or keys to the client system. Thus, 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.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
13
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.
As most prior art authentication systems involve the creating, storing,
transfer and
single point authentication of login related information between a user's
device and a
client system, the prior art systems are vulnerable to such information being
compromised by third parties. Once such information is obtained by a third
party, the
information can be used to login at a single authentication point to the
system
network without authorization, or unauthorized use of the data, documents or
transaction information. The present invention offers a benefit over the prior
art
systems in that it is not vulnerable to such third party access to information
that would
allow unauthorized access to a client system, or to data, documents or
transaction
information. The authentication system of the present invention addresses the
problem
of prior art authentications that can be compromised at creation, storage,
transit and
authentication point.
As an example of another benefit of the present invention over the prior art
system is
that prior art systems are not generally operable with any type of client
system, or
with any type of user device. The present invention 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 invention can be implemented by any organization for use with any type
of
client system, and with any user device on any platform.
Yet another example of a benefit of the present invention over the prior art
is that the
present invention is operable to undertake hive authorization of devices
within an
environment. For example, multiple mobile and/or storage devices across geo-
temporal zones can be authorized in the course of hive authorization. Prior
art systems
are not operable to undertake hive authorization across geo-temporal zones.
Embodiments of the present invention may incorporate multiple components
operable
to authenticate a user for the purpose of a user login to a client system
having secure
portions therein, or for the purpose of the user accessing the secure portions
of such
system. For example, one embodiment of the present invention may incorporate
three
main components as follows: (1) Synchronized Multi-Faceted Authentication
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
14
(SMFA); (2) Interactive Semi-Manual Authentication (ISMA); (3) Transaction
Authentication. To provide an example of such an embodiment of the present
invention these three components of an embodiment of the present invention all
described below. A skilled reader will recognize that other configurations of
the
present invention are possible, including configurations that only include one
or two
of the three components described below, or configurations that incorporate
other
components.
Synchronized Multi-Faceted Authentication (SMFA)
The authentication process for a user of the present invention authentication
method
and system operates so that the encrypted and or hashed portions of random
multi-unit
login related information are disbursed amongst devices (e.g., user and/or
system
devices and storage units) and all of such or more of such devices must be
utilized to
authenticate the user.
Therefore, if login data is compromised at creation, transit, storage or at
authentication, such as by unauthorized access by a third party, only an
encrypted and
or hashed partial portion of the time sensitive random login related
information of the
unknown user(s) will be obtained this data will be unusable to authenticate
the user.
More specifically; the present invention is operable to require a user to
engage in a
challenge, such as, a static challenge that may be a pin andlor pattern
challenge, an
animated and/or non-animated challenge, a graphical and/or non-graphical
challenge,
a two dimensional and/or -three dimensional challenge, a moving and/or static
gamified challenge, and/or a non-garnified interface challenge, in order to
login to the
client system. The system may choose a series of units and may use these to
generate
a challenge. Each unit is randomly assigned multiple divits, that may change
at each
login event. A user may select multiple challenges in the same authentication
event
and in any subsequent authentication events.
The series of units chosen during the challenge are divided by the
authentication
system into multiple unique system portions. The units in each unit portion
may be
hashed or encrypted individually to venerate unit results, and then the units
in each
system portion are hashed and/or encrypted collectively to generate system
portion
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
results. The number of hashes and/or en.cryptions applied to each unit in a
system
portion and to each system portion can vary.
Portions of the hashed and/or encrypted results are stored in different
devices of the
distributed architecture of the client or other system and a portion is stored
in the
5 user's device. For example, portions of the hashed and/or encrypted
results may be
stored in multiple user and system devices.
All of the client system devices containing hashed and/or encrypted partial
data, as
well as the user device, must validate themselves. Once devices are
authenticated they
might then co-authenticate the user.
10 The present authentication system invention is platform agnostic, so it
can be used
with any client system.
Interactive Semi-Manual Authentication (1SMA)
The authentication process for a user of the present invention operates so
that the
login information is encrypted and/or hashed using multi-layer encryption
and/or
15 hashing functions. The portions of random encryption and/or hashing
details that are
held back and manually transmitted and are not stored in the client system, or
in the
user device, thereby decreasing the possibility of compromise during
transmission,
storage or authentication.
The system of the present invention provides a key (i.e., key 4 1) to the
mobile device.
All keys in the present invention are encrypted and/or hashed using multi-
layer
encryption and/or hashing functions.
The encrypted key is required to be used in the authentication process of the
present
invention, and therefore the user must first authenticate using the SMFA
process
described herein, and thereby validate the key and authenticate the user's
device.
The system will generate a challenge based on random encrypted keys that will
change at each login event. The authenticated user will use their
authenticated device
to scan the challenge. At the end of this process part or whole portions of
the random
encrypted key will be sent to the user device.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/TB2021/053964
16
In some embodiments of the present invention there may be another set of
encrypted
random keys that may be generated by the user device that will also change at
each
login event. Multiple keys that can be combined to form an encrypted shared
secret
key; portions of or the entire encrypted shared secret key will be sent to the
client
system of the organization that is requesting authentication of the user.
Multiple layers of encryption may be generated by the user device. Such
encryption
may be applied to elements individually or collectively. For example, 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..
Multiple random characters will be removed from the package that results from
the
multiple layers of encryption. For example, six random n characters may be
removed
from the package. The multiple random digits and characters will be provided
to the
user and the encrypted details are sent to the client system requesting
authentication
of the user device.
The client system requesting authentication of the user device will challenge
the user
to provide the information given to the user device. Only upon the user
providing
such information will the client system be able to authenticate the user. This
process
reduces the possibility of a third party intercepting, guessing or knowing the
user's
login information.
When the user is authenticated the session will be authenticated through time
and geo-
based access code. For example, the geo-based access code may be a token or
any
other type of geo-based access code. The geo-based access code may be
invalidated if
the time expires or the geo aspect is invalidated. For example, the geo aspect
may be
invalidated if the user is not located within the geo-location relating to the
geo-based
access code.
Transaction Authentication
The authentication process for a user of the present invention authentication
system
operates so that the transactions arc authenticated without the user having to
reveal his
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/TB2021/053964
17
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. Once
the
user device is authenticated, 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.
As an example, one embodiment of the present invention may be operable such
that
the system will generate multiple random digit alpha numeric codes with one or
more
digits being blank, the corresponding alphabet or numeral to be filled-in to
the blank
will be also sent to the user with the challenge in the 1SMA process. For
example, the
system. may generate six or more multiple random digit alpha numeric codes, or
any
other number of random digit alpha numeric codes.
'The system will generate and encrypt the six or more random digit
alphanumeric code
as well as other elements. For example, die 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.
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
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
18
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
When
the user device is authenticated 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.
A skilled reader will recognize that the method and system for authentication
of the
present invention may be implemented in a variety of manners. FIGs 1-17
provide
some examples of embodiments of the present invention, and these are described
herein.
As shown in FIG. I. the authentication system incorporates many elements
including
a client system, a user system, a verification system, and multiple storage
units. The
authentication system is operable to achieve many functions including proving
and
verifying a user's login.
The user system 102 is used by the user to login to the client system 902. The
user
system is operable to engage in verifying the user's identity as well as other
activities,
as described herein. The user's identity must be verified by the client system
in order
for the user to gain access to the secured area of the client system. The
verification
system 202 is operable to engage in verifying the identity of the user to the
client
system.
When the user, through the user device 90, wants to access a secured area of
the client
system, the user will have to first prove the user's identity to the client
system. Once
the client system receives verification of the identity of the user, the
system can then
permit the user to access the secure contents of the client system.
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
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
19
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. In one embodiment of the
present invention 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 invention 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. In one
embodiment
of the present invention 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
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
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.).
A skilled reader will recognize that in embodiments of the present invention
some or
5 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 invention 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
10 generally incorporated in the authentication system.
The synchronization system 300 may incorporate one or more synchronization
elements 302A...302N, and each synchronization element may incorporate
multiple
units. In one embodiment of the present invention at least two synchronization
elements may incorporate a proving unit 304A...304N, a storage unit
308A...308N, a
15 processing unit 306A...306N, an approval unit 312A...312N, and a
communications
unit 310A...310N. The proving unit 304A is operable to prove the initial
identity of
the synchronization system 300 to the verification system 202.
Communication between the user system, the verification system and the
synchronization elements is received by and transferred from the communication
unit
20 of such system and/or elements. All such communication between the
systems and/or
elements may be secured by the use of one or more masking functions., the one
or
more masking functions may include, hashing and/or encryption.
As shown in FIG. 2, data may be transferred between the client system 902 and
a
masker unit 204 of the verification system via the communication unit 216 of
the
verification system. During the initial communication between the client
system and
the verification system relating to the set-up of a new user who wants to use
the client
system, the client system may communicate with the masker unit of the
verification
system to request credentials required for the new user to establish a secure
connection with the client system. The masker unit generates unique secured
credentials the client system can use to establish a link between the client
system and
the verification system. These unique credentials may include for example a
client ID,
or other forms of credentials.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
21
When the trusted connection is established between the client system and the
verification system, the masker unit performs a process, such as, a
calculation, an
algorithm or another type of process that will generate a unique non-
identifying
identifier that is a secret for the user. The unique non-identifying
identifier may be
stored in one of the storage units 214A (or any of storage units 214A...214N)
incorporated in the verification system.
The masker unit may use a masking function such as hashing, encryption, and or
some other masking function to render the non-identifying identifier secure.
The
client system may also provide the verification system with a list of all
available
synchronization elements. In embodiments of the present invention, one or more
of
the synchronization elements may be stored in one or more of the storage units
214A...214N of the verification system.
As shown in FIG. 3, the registration process of the present invention may
involve the
operation of elements of the authentication system as required during the
initial
interaction of the user with the authentication system, in order for the user
to register
with the client system. All communications between the client system, elements
of the
user system, elements of the verification system and elements of the
synchronization
system are via the communication units of the user system, the verification
system
and the synchronization system, as shown in FIG. 3. The user must register
with the
client system to be authorized to access the secure portions of the client
system.
During the initial registration the proving unit 104 accesses one or more
storage units
110 of the client system to retrieve proving information. The proving
information
may include a non-identifying identifier generated by the masker unit, a
secret that
has also been generated by the masker unit, and may also include information
that
may identify the user device, a unique application number, and or other
information
relating to the user, for example biometric information (e.g., the user's
fingerprint,
the user's retina scan, or other biometric information of the user), usage
information
etc. Once the proving unit obtains all of the proving information, the proving
information may be stored in one or more of the storage units of the user
system.
The proving information that has been obtained by the proving unit 104 is
securely
sent via the communication unit 114 of the user system to the processing unit
210 of
the verification system. The processing unit 210 retrieves information for the
user, via
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
22
the communications unit 216 of the verification system, from one or more of
the
storage units 214A...214N of the verification system. The processing unit 210
combines the information it receives from the client system with the
information it
retrieves from the one or more storage units of the verification system to
create a
package of information. The processing unit sends such package of information
to the
approval unit 212.
The approval unit 212 compares the values of the package of information it
receives
from the processing unit with information stored in the one or more storage
units
214A...214N of the verification system, that was previously received from the
client
system. If the comparison is successful the approval unit will accept the
connection
with the user system. If the comparison is not successful the approval unit
212 will
deny the connection with the user system. The results of the approval system
are sent
to the N-packet generator 206.
If the connection with the user system is not approved, the operation of the
authentication system to attempt to register the user will end. In one
embodiment of
the current invention, if the connection with the user system is approved,
then the N-
packet generator will generate a random challenge. The random challenge may
include multiple packets (N-packets). Each N-packet contains multiple random
numeric or alphanumeric/other characters (N-RANC).
The N-packets are securely sent to the display unit 106 of the user system.
Embodiments of the present invention may apply multi-layer of protection,
including,
but not limited to encryption, hashing and /or digital signature to provide
security to
the N-packets in transit between the N-packet generator and the display unit,
for
example, the multi-layer protection of both the N-RNAC and the N-packets prior
to
transit. In other embodiment of the present invention N packets could be
generated
by an element of the user system or a different system with or without N-RNAC.
The
user interacts with this element to generate an OY packet.
The display unit 106 receives the N-packets and displays the information
incorporated
in the N-packets to the user. From the N-packets displayed the user enters one
or more
N-packets, and thereby selects the N-RANC associated with the chosen N-
packets.
For ease of reference the N-packets chosen by the user are the Y-packets
herein. The
order in which the Y-packets are chosen by the user is retained to become
Ordered Y-
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
23
packet (OY-Packet) The OY-Packets are sent by the display unit 106 to the
processing unit 108 of the user system. The processing unit of the user system
splits
the OY-Packet into two or more portions. Each portion may contain two or more
N-
Packets.
The processing unit of the user system may mask the 0Y-Packet information by
applying a masking function to each portion of the OY-Packet. For example, the
processing unit of the user system may apply masking to one or more of the
following: each of N-RNAC incorporated in the OY-Packet and/or to each Y-
Packet
incorporated in the OY-Packet and/or to each OY-Packet,. The results of one or
more
masking may be stored in one or more of the storage units 110 of the user
system. The
results that are not stored are sent to the processing unit of the
verification system.
The challenge generated by the N-packet generator that is sent to the display
unit of
the user system may incorporate nmltiple N-packets and each N-packet may
incorporate three or more N-RANC. The user may select multiple Y-packets that
form
the OY-packet. The OY-packet may be split into 2 portions (i.e., an OYA-
portion and
an OYB-portion).
The processing unit of the verification system may apply hashing and/or
encryption
and then select two or more random synchronization elements of the
synchronization
system from a list stored in the one or more storage units of the verification
system.
The selected random synchronization elements form a sync registry. The
processing
unit of the verification system may add a secret to the OY-packet portions,
individually or collectively, and may perform a multi-layer hashing and/or
encryption
function on the OY-packet portions, individually and/or collectively. The
hashed
and/or encrypted unique OY-packet portions may then be distributed among one
or
more synchronization elements, and be stored in one or more of the storage
units in
one or more of the synchronization elements to which the OY-packet portion is
distributed. The result is that the unique OY-packet portions are stored in
different
synchronization elements. The distribution information portions may be stored
in a
sync registry of the synchronization elements.
As shown in FIG. 4, the authentication system may be operable to perform an
access
process, whereby the registered user tries to authenticate itself through the
operation
of the verification system, in order for the user to gain access to secure
portions of the
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
24
client system. All communications between elements of the user system,
elements of
the verification system and elements of the synchronization system are via the
communication units of the user system, the verification system and the
synchronization elements of the synchronization elements of the
synchronization
system, as shown in FIG. 4. The proving unit 104 of the user system accesses
one or
more of the storage units 110 of the user system to retrieve proving
information. The
proving information may include a non-identifying identifier and a secret.
Some or all of the proving information that has been obtained by the proving
unit is
securely sent via the communication unit 114 of the user system to the
processing unit
210 of the verification system, via the communication unit 216 of the
verification
system. The processing unit 210 retrieves information for the user from one or
more
of the storage units 214A.. .214N of the verification system. The processing
unit 210
combines information received from the client system with the information
retrieved
from one or more storage units of the verification system to create a package
of
information. The processing unit sends this package of information to the
approval
unit 212 of the verification system.
The approval unit 212 compares the values of the package of information it
receives
from the processing unit 210 with information stored in the verification
system that
was previously received from the client system. If the comparison is
successful (i.e.,
the comparison results in a match between the compared information) the
approval
unit will accept the connection with the user system. if the comparison is not
successful the approval unit will deny the connection with the user system.
The results
of the approval system are sent to the N-packet generator 206.
If the connection with the user system is not approved, the operation of the
authentication system to attempt to register the user will end. If the
connection with
the user system is approved, the N -packet generator will generate a random
challenge.
The random challenge may include two or more packets (N-packets). Each N-
packet
contains two more random numbers or alphanumeric characters (N-RANC). A multi-
layer hashing and/or encryption may be applied to the challenge sent to the
display
unit. The hashing and/or encryption is applied by the random number generator
The N-packets are securely sent to the display unit 106 of the user system.
Embodiments of the present invention may apply multi-layer hashing and/or
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
encryption to provide security to the N-packets in transit between the N-
packet
generator and the display unit. For example, the multi-layer hashing and/or
encryption
may incorporate hashing and/or encrypting the N-RNAC and/or the N-packets
prior
to transit. The display unit 106 receives the N-packets and displays the
corresponding
5 information to the user. From corresponding information displayed the
user selects
two or more corresponding information and there by selecting N-packets, and N-
RANC associated with the chosen N-packets. For case of reference the N-packets
chosen by the user are the Y-packets herein these Y packets are ordered and
are called
OY Packets.
10 In another embodiment of the present invention, the N-packet generator
maybe
present in the user system and or other systems which may generate Y and/or OY
packets by interaction with a user through any element from the user system or
other
systems, such as, cameras, scanners, etc.
The 0Y-Packets arc sent by the display unit 106 to the processing unit 108 of
the user
15 system. The processing unit of the user system splits the OY-Packet into
multiple
portions. Each portion contains multiple N-Packets.
The processing unit 108 of the user system retrieves previously stored OY-
packet
portions from one or more storage units of the user system where such
previously
stored OY-packet portions are stored. The processing unit sends the previously
stored
20 OY-packet portions and more recently created OY-packet portions to the
approval
unit 110 of the user system. The approval unit of the user system compares the
information it receives from the processing unit of the user system with the
previously
stored OY-packet portion and generates either an approval result or a denial
result.
The result generated by the approval unit of the user system (that is either
an approval
25 result or a denial result) is transferred to the processing unit of the
user system. If the
result from the approval unit of the user system is a denial result the
authentication
process is halted.
If the result of the approval unit of the user system is an approval result,
the
processing unit of the user system may store one or more of the OY-packet
portions
recently generated in one or more storage units of the user system, and will
send the
rest of the OY-packet portions to the processing unit of the verification
system. The
processing unit of the verification system retrieves the synchronization
system
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
26
information for the user from the sync registry. The processing unit of the
verification system may add a secret to the OY-packet portions it receives and
perform a multi-layer hashing and/or encryption function on these OY-packet
portions. After hashing and/or encryption the processing unit of the
verification
system may send the hashed and/or encrypted unique OY-packet portions to one
or
more of the processing units 302A...320N of the synchronization elements of
the
synchronization system. Each processing unit of a synchronization clement that
receives a hashed and/or encrypted unique OY-packet portion from the
processing
unit 210 of the verification system,. Each synchronization element of the
synchronization unit that receives a hashed and/or encrypted OY-packet portion
may
undertake a process, as shown in FIG. 5. The processing unit 306A...306N of
the
synchronization element may decode the hash and/or encryption to determine and
identify one or more N-Packets and N-RANCs. The processing unit of the
synchronization element may send the N-packets and N-RANCs to the approval
unit
312A ... 312N of the same synchronization element.
The proving unit 304A...304N of the synchronization unit retrieves the
previously
stored hashed and/or encrypted OY-packet portions from the storage unit
308A...308N of the synchronization element. The proving unit of the
synchronization
unit may decode the hash and/or encryption to determine and identify one or
more N-
packets and N-RANCs and these are sent to the approval unit of the
synchronization
element. The approval unit of the synchronization element compares the N-
packets
and N-RANCs it received that were recently generated to those that were
previously
stored. Based upon this comparison either a pass value or a fail value is
generated.
The generated pass value or fail value is transferred to the proving unit of
the
synchronization element.
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 receives the hashed and/or
encrypted
results and proving information from each of the proving units of each of the
synchronization elements that generated such information. For clarity,
multiple
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
27
synchronization elements may have received unique OY-packet portions and each
such synchronization element will have processed the OY-packet portions in
accordance with the method discussed herein. All communications between
elements
of the user system, verification system and the client system are via the
communication units of the user system, client system and the verification
system, as
shown in FIG. 6. Also as shown in FIG. 6, the processing unit 210 of the
verification
system 202 will decode the proving information it received from each
synchronization
element 302A...302N and send the decoded information to the approval unit 212
of
the verification system. The processing unit 210 of the verification system
retrieves
proving information from one or more of the storage units 214A...214N of the
verification system. The processing unit of the verification system sends the
retrieved
proving information to the approval unit of the verification system. The
approval unit
of the verification system utilizes the information it receives to approve the
synchronization elements.
The processing unit of the verification system decodes each of the pass and/or
fail
values it receives from the synchronization elements. The decoded values are
saved in
one or more of the storage units of the verification system as verification
results. A
verification results report may be generated by the processing unit of the
verification
system or a report generator 208, and this report may contain a variety of
information,
for example the total synchronization elements requested, the number of pass
values
received, the number of fail values received, synchronization system trust
scores and
other information.
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
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
28
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.
After a user is authenticated and is granted access to the secure portions of
the client
system, the user may access information (i.e., data, documents, transaction
information, etc.) and/or provide user information (i.e., text, data, etc.) to
the client
system. As an example, the user may access the client system to send messages,
to
undertake purchases that involve credit card payments, to attach an c-
signature to a
document, or for a variety of other purposes. In the course of the interaction
of the
user with the client system, via the user system, user information will be
transmitted
between the client system and the user system. The present invention is
operable to
protect the security of such user and authentication related information
during
creation, transit, storage and authentication.
To achieve such security an embodiment of the present invention may
incorporate a
user system, a client system, a client display unit and a verification system.
The user
system may be incorporated wholly or partially in the client device utilized
by the
user to communicate with and access the client system. A skilled reader will
recognize that embodiments of the present invention that achieve security for
user and
authentication related information in transit between the user device and the
client
system may incorporate other elements.
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.
As an
example, the user will only be able to approve certain transactions through
the client
system if the user and the user system arc 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
invention 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.
As shown in FIG. 7, a user system 101 utilized to transmit user information to
and
from the client system may incorporate multiple elements. For example, an
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
29
embodiment of the present invention 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.
As shown in FIG. 8, the client system 130 of an embodiment of the present
invention
may incorporate multiple elements. For example, an embodiment of the present
invention may include a client system that incorporates a CSAP generator 131,
a
storage unit 133, a processing unit 135, a challenge generator 137, and an
approval
unit 139.
As shown in FIG. 9, the client display unit 150 of an embodiment of the
present
invention may incorporate multiple elements. For example, an embodiment of the
present invention 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.
As shown in FIG. 10, the verification system 140 of an embodiment of the
present
invention may incorporate multiple elements. For example, an embodiment of the
present invention 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.
When the user wants to login to a secure portion of the client system, the
user will
declare his/her intention through interaction with client display unit, and
use of the
interaction unit of the client display unit to input a request. As shown in
FIG. 11, the
interaction unit 151 will communicate the request to the processing unit 153
of the
client display unit, and the processing unit of the client display unit will
then
communicates the request to the processing unit 147 of the verification
system. The
processing unit 109 of the user system will generate a request to generate an
Alpha
Key (ak) combo consisting of a akl and ak2 Keys that it sends to the key
generator
157 of the client display unit via the processing unit 147 of the verification
system.
The key generator of the client display unit transmits both ak 1 & ak2 to the
processing unit 147 of the verification system.
The processing unit 147 of the verification system then requests random text
from the
random text generator 143 of the verification system, and requests a unique
system &
event identifier (USID) from the USID generator 145 of the verification
system. The
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
random text generator generates the random text and sends the random text to
the
processing unit 147 of the verification system. The USID generator generates
the
USID and sends the USID to the processing unit of the verification system. The
USID
generator is operable to identify to the verification system, the user device
and event
5 that is trying to connect to the secure area in the client system. The
USID may be
unique to each tab in a browser or in multiple browsers to identify and
control the
number of browsers or tabs that arc open for usc by a user.
The processing unit 147 of the verification system combines the USID and
random
text that it receives with ctk2 into a data string and converts the data
string into a
10 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.
As shown in FIG. 12, after the process of FIG. 11 is completed the information
is
made available to the user system through the reader unit 113. The reader unit
113
15 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.
20 The reader unit 113 then sends the information that it obtained to the
processing unit
109 of the user system. The processing unit of the user system may separate
the
information it receives from the reader unit and may hold that information.
The
processing unit 109 of the user system will request noise from the noise
generator 107
of the user system. The noise generator will generate noise and will send the
noise to
25 the processing unit of the user system. The noise is used to mask the
identity of the
information in transit.
If the user has previously been authenticated by the client system, the user
system
may have a random Delta 1 Key (6k1).
The processing unit of the user system will send (x1(2. and 6k1 to the
verifier generator
30 105 of the user system. The processing unit will also send a request to
the verifier
generator of the user system requesting that a new Beta Key be generated. In
response
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
31
to this request the verifier generator will generate Beta Keyl (13K1) and Beta
Key2
(13K2) using ak2 and 6k1. The verifier generator 105 will send I3K1 and j3K2
to the
processing unit 109 of the user system.
The processing unit of the user system will also access the storage unit 111
of the user
system and request 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. For example, 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 6k1 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.
When the MIC is generated residual data will exist (the "post-MIC data"). The
processing unit of the user system may conduct a symmetric or asymmetric
encryption on the post-MIC Data. The processing unit of the user system may
send
the post-MIC data and the hash value to the processing unit 135 of the client
system.
As shown in FIG. 13, once the MIC, the post-MIC data and the hash value are
created
by the user system, 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.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
32
The user is now required to interact with the interaction unit 151 of the
client display
unit. The user must manually enter the MIC. Once entered, the MIC is then sent
by
the 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
6k1
to be available. The processing unit of the client display unit calculates the
hash value
for SC or 6k1 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 6k1, 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.
If the hash values match then the approval unit 139 confirms the match to the
processing unit 135 of the client system.
As shown in FIG. 14, upon receiving this match confirmation, the processing
unit 135
of the client system requests a Client Session Access Pass (CSAP) from the
CSAP
generator 131. The CSAP generator 131 generates 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.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
33
If the approval unit 139 of the client system determines that the values do
not match,
then the user, the user system and the client display unit are not
authenticated.
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. In any instance that 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.
CSAP conditions for authentication applied in embodiments of the present
invention
may include conditions relating to any of the following: dimensions, geo-
temporal,
machine learnt artificial intelligence, behavioral, or any other conditions.
Another embodiment of the present invention 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. Upon
such a request the processing unit 135 of the client system sends a request to
the
challenge generator 137 of the client system to generate a challenge. Upon
such a
request the 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
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
34
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. In one
embodiment of
the present invention, the user may be required to interact with the
interaction unit
151 of the client display unit to find the solution to the challenge. In
another
embodiment of the present invention, the processing unit 153 of the client
display unit
may solve the decrypted challenge.
Once the user using the client display unit finds a solution to the challenge,
the user
solution is sent to the processing unit 153 of the client display unit. The
processing
unit 153 of the client display unit may generate a hash value based 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) may
be sent
to the processing unit 135 of the client system. The processing unit 135 of
the client
system may send a request to the storage unit 133 of the client system to
retrieve the
stored solution and/or the stored hash value. Upon such a request the storage
unit 133
of the client system will retrieve the stored solution and/or the stored hash
value and
send the stored solution and/or 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.
If the received solution and/or hash values matches with the stored solution
and/or the
hash values, 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
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
system to confirm that the authentication of the transaction has completed
successfully and the client system will thereby authorize the transaction.
If the received solution and/or hash values does not match with the stored
solution
and/or the hash values, the approval unit 139 will send notice to the
processing unit
5 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.
In another embodiment of the present invention, the processing unit of the
verification
system can perform the functions described for the processing unit of the
client
10 system in accordance with FIG. 14. In such an embodiment of the present
invention 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.
15 Another embodiment of the present invention whereby the user uses the
user system
to attempt to validate a transaction is shown in FIG. 16. In such an
embodiment of
the present invention the processing unit 109 of the user system sends a
request of the
processing unit 135 of the client system to validate a transaction. Upon such
a request,
the processing unit 135 of the client system sends a request to the challenge
generator
20 137 to generate a challenge. Upon such a request 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
25 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. In one
embodiment of the present invention, the user may be required to interact with
the
30 interaction unit 103 of the user system to find the solution to the
challenge. In another
embodiment of the present invention, the processing unit 109 of the user
system may
solve the decrypted challenge.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
36
Once the user finds a solution to the challenge, the user solution is sent to
the
processing unit 109 of the user system. The processing unit 109 of the user
system
may generate a hash value based 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) may be sent to the processing unit 135 of thc client
system.
The processing unit 135 of the client system may send a request to the storage
unit
133 of the client system to retrieve the stored solution and/or the stored
hash value.
Upon such a request the storage unit 133 of the client system will retrieve
the stored
solution and/or the stored hash value and send the stored solution and/or
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.
If the received solution matches with the stored solution and/or the received
hash
value matches with the stored hash value, then 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.
If the received solution matches with the stored solution and/or the received
hash
value matches with the stored hash value, then 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.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
37
In another embodiment of the present invention, 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. In such an embodiment of the present
invention 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. In some embodiments, 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. In
some
embodiments, 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, and 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. By way of example, and not
limitation, 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.
By way
of example, and not limitation, a data manipulator of a first peer may be
configured to
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
38
separate a one or more strings of characters into a first portion and a second
portion,
or 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. In some embodiments, a data converter may be configured to apply
hash
algorithms to a first string of characters. In other embodiments, a data
converter may
be configured to apply encryption protocols to a first string of characters.
In yet other
embodiments, a data converter may be configured to apply decryption protocols
to a
first string of characters. In other embodiments still, 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. In some embodiments,
data may comprise a one or more strings of characters of any length and may
comprise bar codes and the like. In some embodiments, 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. In some embodiments, 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. In some embodiments, 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
Figure 17, a registration method 1700 may additionally comprise communication
between a first peer 1701, a server 1750, and at least one second peer 1775.
In some embodiments of a registration method 1700, 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
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
39
for a registration method 1700. In some embodiments, 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. In other
embodiments,
registration data comprises user selection objects. In yet other embodiments,
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. In some embodiments, a server key 1705
and a
client key 1706 are used to generate a registration key 1707. In other
embodiments, 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. Further, a registration method 1700 may comprise transferring
information
from a first peer 1701 to a server 1750. In some embodiments, a registration
key 1707
and a server key 1705 are transferred to a server 1750.
A registration method 1700 may comprise receiving information from a first
peer
1701 at a server 1750. In some embodiments, information received at a server
1750
may comprise a registration key 1707 and a server key 1705. A server 1750 may
generate a recipient code 1752. Further, a server 1750 may generate a sender
code
1754. Even further, a server 1750 may generate a distribution code 1756. A
server key
1705, recipient code 1752, and sender code 1754 may be used to generate a
distribution key 1753. In some embodiments, a distribution key 1753 may be
generated from any one or more of server keys 1705, recipient codes 1752, or
sender
codes 1754, or any combination therein. Some information, e.g. a recipient
code 1752,
a distribution key 1753, may be stored in the database 1757 of a server 1750.
A
registration method 1700 may further comprise transferring information from a
server
1750 to at least one second peer 1775. In some embodiments, a distribution key
1753
and a distribution code 1756 are transferred to at least one second peer 1775.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
A registration method 1700 may further comprise storing one or more keys on a
local
database. Illustrated in Figure 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
5 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. Some
information, e.g.
a distribution key 1753, a deposit key 1777, a distribution code 1756 may be
stored in
10 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.
In some embodiments, 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
15 1775 and storing that information in a local database. In some
embodiments, 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.
20 Referring now to Figure 18, creating one or more keys 1800, according to
some
embodiments, may occur in a first peer 1801. A first peer 1801 may be any IoT
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
25 from a server 1850. According to some embodiments, 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. In some embodiments,
registration data may comprise a client registration code 1803. In other
embodiments,
30 registration data may comprise a client registration code 1803 and
additional data
which may serve as a precursor to user input 1804. A client registration code
1803
may comprise a one or more strings of characters of any length.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
41
User input 1804 may comprise any form of user-generated data which comprises
discreet units of information. In some embodiments, user input 1804 comprises
biometric data, e.g. fingerprint, iris, etc. In those embodiments, biometric
data may be
split into discreet units of information comprising identifiers. Identifiers
may be
converted into unique selection codes 1809. In other embodiments, user input
1804
may comprise any number of spatial and/or temporal data. Spatial and/or
temporal
data may be split into discreet units of information comprising identifiers.
Identifiers
may be converted into unique selection codes 1809. In yet other embodiments,
user
input 1804 may comprise a combination of biometric data and spatial and/or
temporal
data, each of which may be used to generate unique selection codes 1809.
hi other embodiments, 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. In some embodiments, selection objects may be received at a
transmitter/receiver 1841 and a processing migrator 1842 may migrate selection
objects to a visual display 1843. Upon selection by a user on 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. In a specific
embodiment,
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 objects produces a user input 1804 comprising a combination of
selection
codes 1809 that is unique to the user's selection of selection objects. In
some
embodiments, any combination of biometric data, spatial and/or temporal data,
and
selection objects may comprise user input 1804.
According to some embodiments, 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. In some embodiments, 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
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
42
converter 1845, resulting in a first group of converted selection codes 1813
and a
second group of converted selection codes 1815. In some embodiments,
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
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. In some
embodiments,
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. In some embodiments, 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 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. In some
embodiments, 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 1805 by a data converter 1845. In some embodiments, 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.
According to some embodiments, a registration key 1807 may be generated. Each
of a
client key 1806 and a server key 1805 may be separated by a data manipulator
1844
into a client key first part 1817, a client key second part 1818, a server key
first part
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
43
1819, and a server key second part 1820. In some embodiments, a client key
1806
may be separated into three or more parts. Likewise, a server key 1805 may be
separated into three or more parts. A client key first part 1817 and a client
key second
part 1818 may comprise different portions of the characters that comprise a
client key
1806. In a specific embodiment, each of a client key first part 1817 and a
client key
second part 1818 may be one half of a client key 1806. 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. In a specific embodiment, 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-kcy 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. 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 second pre-key 1822 may be used to generate a
registration pre-key 1823. According to some embodiments, 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. In some embodiments, conversion 1812 may
comprise using hash algorithms. In other embodiments, conversion 1812 may
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
44
comprise using encryption methods. Yet other embodiments may comprise
conversion 1812 using a combination of hash algorithms and encryption methods.
A first peer 1801 may transmit information to a server 1850. According to some
embodiments, a processing migrator 1842 of a first peer 1801 may migrate a
registration key 1807 and a server key 1805 to a transmitter/receiver 1841 of
a first
peer 1801, which may transmit a registration key 1807 and a server key 1805 to
a
server 1850. In other embodiments, a transmitter/receiver 1841 of a first peer
1801
may transmit a registration key 1807, a server key 1805, and other information
necessary for a registration method to a server 1850.
A registration method may further comprise distributing one or more keys 1900.
Illustrated in Figure 19, a transmitter/receiver 1941 of a server 1950 may
receive
information from a first peer 1901. According to some embodiments, a
transmitter/receiver 1941 of a server 1950 may receive a registration key 1907
from a
first peer 1901. A transmitter/receiver 1941 of a server 1950 may receive a
server key
1905 from a first peer 1901. A transmitter/receiver 1941 of a server 1950 may
receive
both a registration key 1907 and a server key 1905 from a first peer 1901. A
processing migrator 1942 may migrate a registration key 1907 and a server key
1905
to a processor of a server 1950. A registration key 1907 may be stored in a
database
1957 of a server 1950 by a processing migrator 1942. A processing generator
1946 of
a server 1950 may generate a peer list 1958. A peer list 1958 may comprise a
list of
peer devices, e.g. a first peer 1901, a second peer 1975, on the network. A
peer list
may also comprise recipient codes 1952 and distribution codes 1956, which may
comprise a one or more strings of characters of any length. Additionally, a
processing
generator 1946 of a server 1950 may generate a sender code 1954, which may
also
comprise a one or more strings of characters of any length.
According to some embodiments, a server 1950 may receive a registration key
1907
from a first peer 1901. A registration key 1907 may be used to generate any
number
of registration key subparts. A data manipulator may generate registration key
subparts from a registration key 1907. In these embodiments, a registration
key 1907
may comprise any number of characters equal to n. Each registration key
subpart may
comprise any number or combination of characters equal to n-1. A server 1950
may
generate one or more random strings of characters. Each of a registration
subpart may
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
be concatenated with one or more random strings of characters by a data
manipulator
1944. In some embodiments, concatenated strings may be converted 1912. Each
generated concatenated string or converted concatenated string may be
transmitted to
one or more second peers 1975.
5 A server 1950 may receive a server key 1908 from a first peer 1901. A
server key
1908 may be used to generate any number of server key subparts. A data
manipulator
may generate server key subparts from a server key 1908. In these embodiments,
server key 1908 may comprise any number of characters equal to n. Each server
key
subpart may comprise any number or combination of characters equal to n-1. A
server
10 1950 may generate one or more random strings of characters. Each of a
server key
subpart may be concatenated with one or more random strings of characters by a
data
manipulator 1944. In some embodiments, concatenated strings may be converted
1912. Each generated concatenated string or converted concatenated string may
be
transmitted to one or more second peers 1975.
15 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. In some
embodiments, 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
20 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 distribution pre-key 1959 may be converted 1912 by a
data
converter 1945 into a one or more strings of characters comprising a
distribution key
25 1953. In some embodiments, conversion 1912 may comprise using hash
algorithms.
In other embodiments, conversion 1912 may comprise using encryption methods.
Yet
other embodiments may comprise conversion 1912 using a combination of hash
algorithms and encryption methods. A distribution key 1953 may be stored in a
database 1957 of a server 1950 by a processing migrator 1942. A server 1950
may be
30 configured to transmit information to a second peer 1975. In some
embodiments, a
processing migrator 1942 of a server 1950 may migrate a distribution key 1953
and a
distribution code 1956 to a transmitter/receiver 1941 of a server 1950. In
other
embodiments, a transmitter/receiver 1941 of a server 1950 may transmit a
distribution
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
46
key 1953, a distribution code 1956, and other information necessary for a
registration
method to a second peer 1975. In some embodiments, a server 1950 may store any
combination of a registration key 1907, a server key 1905, and a distribution
key 1953
at a database 1957 of a server 1950.
A server 1950 may generate more than one distribution keys 1953 and transmit
data to
more than one second peer 1975. In some embodiments, a peer list 1958 may
comprise a list of more than one second peers 1975 on the network. A second
peer
may comprise any IoT 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. In these embodiments,
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.
According to some embodiments, a registration key 1907 may be used to generate
a
distribution pre-key 1959. In these embodiments_ 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.
Referring now back to Figure 17, a registration method 1700 may comprise
storing
one or more keys on a local database. According to some embodiments, 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. In some embodiments, 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 generate a deposit code 1776. 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 1776 may be generated by a server 1750
and
received by a second peer 1775. A deposit code 1776 and a distribution key
1753 may
be combined through concatenation of units to form one or more strings of
characters
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
47
comprising a deposit pre-key 1779. Concatenation may comprise using each of a
deposit code 1776 and a distribution key 1753 as a unit or may comprise using
pieces
of deposit code 1776 and a distribution key 1753 as a unit. A deposit pre-key
1779
may be converted 1712 into a one or more strings of characters comprising a
deposit
key 1777. In some embodiments, conversion 1712 may comprise using hash
algorithms. In other embodiments, conversion 1712 may comprise using
encryption
methods. Yet other embodiments may comprise conversion 1712 using a
combination
of hash algorithms and encryption methods. A deposit key 1777 may be stored in
a
memory 1778 of a second peer 1775. In some embodiments, a second peer 1775 may
transmit a deposit key 1777 and a distribution code 1756 to a server 1750. In
other
embodiments, a second peer 1775 may transmit a deposit key 1777, a
distribution
code 1756, and any other information necessary for a registration method 1700
to a
server 1750.
A registration method 1700 may further comprise storing one or more keys on a
server database. Shown in Figure 19, a transmitter/receiver 1941 of a server
1950 may
receive information from a second peer 1975. In some embodiments, a
transmitter/receiver 1941 of a server 1950 may receive a distribution code
1956. In
some embodiments, a transmitter/receiver 1941 of a server 1950 may receive a
deposit key 1977. In other embodiments, a transmitter/receiver 1941 of a
server 1950
may receive a distribution code 1956 and a deposit key 1977. In yet other
embodiments, a transmitter/receiver 1941 of a server 1950 may receive a
distribution
code 1956, a deposit key 1977, and any other information necessary for a
registration
method. A distribution code 1956 and a deposit key 1977 may be stored in a
database
1957 of a server 1950 by a processing migralor 1942.
In a specific embodiment, 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
Figure 17, a
registration method 1700 may begin with a request for registration 1702 from a
first
peer 1701. A request for registration 1702 may be transmitted to and received
by one
or more servers 1750. One or more servers may transmit registration data 1751
to a
first peer 1701. Referring now to Figure 18, a specific embodiment may
comprise a
first peer 1801 receiving registration data from a server 1850. Registration
data may
comprise a client registration code 1803 and one or more selection objects. A
client
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
48
registration code 1803 may comprise a single, eight-digit string of
characters.
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.
User input 1804 may be separated into a first group 1810 and a second group
1811. In
a specific embodiment, each of a first group 1810 and a second group 1811
comprises
three different selection codes 1809. Each selection code 1809 comprising a
first
group 1810 and a second group 1811 may be converted 1812 into one or more
strings
of characters. In a specific embodiment, each selection code 1809 may be
converted
using a hash algorithm and may collectively comprise a first group of
converted
selection codes 1813 and a second group of converted selection codes 1815,
respectively. Each of a first group of converted selection codes 1813 and a
second
group of converted selection codes 1815 may be combined to generate each of a
client
pre-key 1814 and a server pre-key 1816, respectively. In a specific
embodiment, three
converted selection codes comprising a first group of converted selection
codes 1813
may be concatenated to produce one or more strings of characters comprising a
client
pre-key 1814. Likewise, three converted selection codes comprising a second
group
of converted selection codes 1815 may be concatenated to produce one or more
strings of characters comprising a server pre-key 1816. A client pre-key 1814
and a
server pre-key 1816 may be converted 1812 to a client key 1806 and a server
key
1805, respectively. Inn specific embodiment, conversion 1812 comprises using a
hash
algorithm.
A registration key 1807 may be generated using a combination of client key
1806,
server key 1805, and client registration code 1803. In a specific embodiment,
a client
key 1806 and server key 1805 are separated into a first part 1817 and 1819,
and a
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
49
second part 1818 and 1820, respectively. A first pre-key 1821 may be generated
by
combining any part of a client key 1806 and any part of a server key 1805 by
concatenation to form one or more strings of characters. A first pre-key 1821
may be
converted 1812 into one or more strings of characters comprising a second pre-
key
1822. In a specific embodiment, conversion 1812 comprises using a hash
algorithm.
A registration pre-key 1823 may be generated by combining a client
registration code
1803 and a second prc-kcy 1822 by concatenation to form one or more strings of
characters. A registration pre-key 1823 may be converted 1812 to a
registration key
1807, where conversion 1812 comprises using a hash algorithm. In a specific
embodiment, a client key 1806 and a client registration code 1803 may be
stored in a
memory 1808 of a first peer 1801. Further, a server key 1805 and a
registration key
1807 may be transmitted to one or more servers 1850.
A registration method may comprise distributing one or more keys. In a
specific
embodiment, shown in Figure 19, a server 1950 may receive a registration key
1907
and a server key 1905 from a first peer 1901. A registration key may be stored
in a
database 1957 of a server 1950. A server 1950 may generate a peer list 1958,
which
may comprise a list of second peers 1975 on the network. For each of the
second
peers 1975, a server 1950 may generate a recipient code 1952 and a
distribution code
1956. In a specific embodiment, a recipient code 1952 and a distribution code
1956
may be unique to both a specific second peer 1975 and a specific transaction.
Additionally, a server 1950 may generate a sender code 1954 that may be unique
to a
particular server 1950. In a specific embodiment, a recipient code 1952, a
sender code
1954, and a server key 1905 may be combined through concatenation to produce
one
or more strings of chara.clers comprising a distribution pre-key 1959. A
distribution
pre-key 1959 may be converted 1912 into a distribution key 1953. In a specific
embodiment, conversion 1912 may comprise using a hash algorithm. In some
embodiments, multiple unique distribution keys 1953 may be generated, each
comprising a different recipient code 1952 and having a different associated
distribution code 1956 from a peer list 1958, wherein each unique distribution
key
1953 may be ultimately transmitted to a different second peer 1975. In a
specific
embodiment, multiple unique distribution keys 1953 arc generated from an
identical
server key 1905 and each of the unique distribution keys 1953 is transmitted
to a
separate second peer 1975 on a network.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
A registration method may further comprise storing one or more keys on a local
database, illustrated in Figure 17. In a specific embodiment, a second peer
1775 may
receive a distribution key 1753 and a distribution code 1756 from a server
1750. In
this embodiment, a second peer 1775 may be one of several second peers 1775 in
a
5 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
sccond pccr 1775 may store a distribution key 1753 and a distribution code
1756 in a
memory 1778 of a second peer 1775. Further, a second peer 1775 may generate a
deposit code 1776. In a specific embodiment, a deposit code 1776 comprises a
single
10 string of eight characters. A deposit code 1776 and a distribution key
1753 may be
combined through concatenation to produce one or more strings of characters
comprising a deposit pre-key 1779. A deposit pre-key 1779 may be converted
1712 to
a deposit key 1777. In a specific embodiment, conversion 1712 comprises using
a
hash algorithm. A second peer 1775 may transmit information to one or more
servers
15 1750. In a specific embodiment, several second peers 1775 may transmit
information
to a server 1750. Information may comprise a distribution code 1756, a deposit
key
1777, and any other information necessary to perform a registration process
1700.
A registration method 1700 may comprise storing one or more keys on a server
database. In some embodiments, a server 1750 may be configured to receive
20 information from one or more second peers 1775. In a specific
embodiment, a server
1750 may receive information from several second peers 1775, information
comprising distribution codes 1756 and deposit keys 1777. A server 1750 may
store
distribution codes 1756 and deposit keys 1777 in a database 1757. Referring
now to
Figure 19, distribution codes 1956 and deposit keys 1977 may be stored on a
peer list
25 1958 stored inside a database 1957. In a specific embodiment,
distribution codes 1956
and deposit keys 1977 are paired with stored distribution keys 1953 and
recipient
codes 1952 which may be specific to a transaction conducted between a first
peer
1901, a server 1950, and a specific second peer 1975.
An authentication method may comprise a login method, illustrated in Figure
20. A
30 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
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
51
communication between one or more first peers 2001, one or more servers 2050,
and
one or more second peers 2075.
A login method 2000 may comprise a first peer 2001, wherein the first peer may
be
configured to interact with a user. A first peer 2001 may request login 2002
and a
login request 2002 may be transmitted to one or more servers 2050. A server
2050
may receive a login request 2002 and generate login data 2051. In sonic
embodiments, login data 2051 may comprise a login salt 2024. A login salt may
be
made up of one or more characters comprising letters, numbers, symbols, or any
combination thereof. In some embodiments, login data 2051 may comprise user
selection objects. In other embodiments, login data 2051 may comprise one or
more
login salts 2024 and user selection objects, and any other data required for a
login
method 2000.
Creating one or more login keys may further comprise generating a server key
2005
and a client key 2006 from user input 2004. In some embodiments, a server key
2005
and a client key 2006 may be used to generate a login key 2099. In other
embodiments, 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. Further, creating
one or
more login keys may comprise transferring information from a first peer 2001
to a
server 2050. In some embodiments, a login key 2099 and a server key 2005 are
transferred to a server 2050.
Also shown in Figure 20, distributing one or more verification keys may
comprise
receiving information from a first peer 2001 at a server 2050. In some
embodiments,
information received at a server 2050 may comprise a login key 2099 and a
server key
2005. A server 2050 may generate a recipient code 2052. Further, a server 2050
may
generate a sender code 2054. Even further, a server 2050 may generate a
distribution
code 2056. A server key 2005, recipient code 2052, and sender code 2054 may be
used to generate a verification key 2062. In some embodiments, a verification
key
2062 may be generated from one or more server keys 2005, recipient codes 2052,
verification salts 2024 or sender codes 2054, or any combination therein. Some
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
52
information, e.g. a recipient code 2052, a verification key 2062, may be
stored in the
database 2057 of a server 2050. In some embodiments, a verification key 2062
may
not be stored in the database 2057 of a server 2050. Distributing one or more
verification keys may further comprise transferring information from a server
2050 to
at least one second peer 2075. In some embodiments, a verification key 2062
and a
distribution code 2056 are transferred to at least one second peer 2075.
A login method 2000 may further comprise verifying one or more verification
keys on
a local database. Illustrated in Figure 20, at least one second peer 2075 may
receive
information from a server 2050. In some embodiments, information may comprise
a
verification key 2062 and a distribution code 2056. In other embodiments,
information may comprise a verification key 2062, a distribution code 2056,
and a
verification salt 2063. A second peer 2075 may use any combination of a
distribution
code 2056 and a verification key 2062 to locate and confirm that a
corresponding
distribution key may be stored in a memory 2078 of a second peer 2075. A
stored
distribution key may be used to generate confirmation key 2081. In some
embodiments, 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.
Validating a verification process may comprise receiving information from a
second
peer 2075 and comparing received information against information stored in a
database 2057 of a server 2050. In some embodiments, a server 2050 receives
information from a second peer 2075. Information received may comprise a
confirmation key 2081, a result, a distribution code 2056 and other
information
needed for storage or comparison of information by the server 2050 or for
identification of the second peer 2075.
Shown in Figure 21, creating one or more login keys 2100, according to some
embodiments, may occur in a first peer 2101. A first peer 2101 may be any IoT
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 2101 may request
login from a
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
53
server 2150. According to some embodiments, a transmitter/receiver of a server
2150
may transmit login data to a first peer 2101. Login data may be received by a
transmitter/receiver 2141 of a first peer 2101 and may comprise any data
necessary to
initiate a login method at a first peer 2101. In some embodiments, login data
may
comprise a login salt 2124. In other embodiments, login data may comprise a
login
salt 2124 and additional data which may serve as a precursor to user input
2104. A
login salt 2124 may comprise a one or more strings of characters of any
length.
Also shown in Figure 21, user input 2104 may comprise any form of user-
generated
data which comprises discreet units of information. In some embodiments, user
input
2104 comprises biometric data, e.g. fingerprint, iris, etc. In those
embodiments,
biometric data may be split into discreet units of information comprising
identifiers.
Identifiers may be converted into unique selection codes 2109.
In other embodiments, user input 2104 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 displayed on a visual display 2143
of a
first peer 2101 and may be converted into selection codes 2109 which may
comprise
any number of characters, e.g. letters, numbers, symbols. In a specific
embodiment,
selection objects are images that may be received from a server 2150. Each
image is
assigned a unique selection code 2109, wherein user selection of a combination
of
selection objects produces a user input 2104 comprising a combination of
selection
codes 2109 that is unique to the user's selection of selection objects.
According to some embodiments, a user may generate user input 2104 comprising
two or more selection codes 2109, wherein the number of selection codes is
equal to
n. Selection codes 2109 may be separated by a data manipulator 2144 into a
first
group 2110 and a second group 2111, wherein a first group 2110 comprises
between
one and n-1 selection codes 2109 and a second group 2111 comprises between one
and n-1 selection codes 2109. Each selection code 2109 in a first group 2110
and a
second group 2111 may be individually converted 2112 by a data converter 2145
into
a one or more strings of characters, resulting in a first group of converted
selection
codes 2113 and a second group of converted selection codes 2115. In some
embodiments, conversion 2112 may comprise using hash algorithms. In other
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
54
embodiments, conversion 2112 may comprise using encryption methods. Yet other
embodiments may comprise conversion 2112 using a combination of hash
algorithms
and encryption methods. A first group of converted selection codes 2113 may be
used
to generate a client pre-key 2114. Individual converted selection codes
comprising a
first group of converted selection codes 2113 may be combined by a data
manipulator
2144 to form one or more strings of characters comprising a client pre-key
2114. In
some embodiments, 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 client pre-key 2114 may be converted
2112 by a
data converter 2145 to a client key 2106. In some embodiments, conversion 2112
may
comprise using hash algorithms. In other embodiments, conversion 2112 may
comprise using encryption methods. Yet other cmbodimcnts may comprise
conversion 2112 using a combination of hash algorithms and encryption methods.
A
client key 2106 may be stored by a processing migrator 2147 in a memory unit
2108
of a first peer 2101. A client key 2106 generated by a login method may be
compared
by a processing verifier 2147 to a client key 2106 stored in a memory 2108 of
a first
peer 2101 during a registration process for identity.
A second group of converted selection codes 2115 may be used to generate a
server
pre-key 2116. Individual converted selection codes comprising a second group
of
converted selection codes 2115 may be combined by a data manipulator 2144 to
form
one or more strings of characters comprising a server pre-key 2116. In some
embodiments, 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 2116 may be converted
2112 by a
data converter 2145 to a server key 2105. In some embodiments, conversion 2112
may comprise using hash algorithms. In other embodiments, conversion 2112 may
comprise using encryption methods. Yet other embodiments may comprise
conversion 2112 using a combination of hash algorithms and encryption methods.
According to some embodiments, a login key 2199 may be generated. Each of a
client
key 2106 and a server key 2105 may be separated by a data manipulator 2144
into a
client key first part 2117, a client key second part 2118, a server key first
part 2119,
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
and a server key second part 2120. A client key first part 2117 and a client
key second
part 2118 may comprise different portions of the characters that comprise a
client key
2106. In a specific embodiment, each of a client key first part 2117 and a
client key
second part 2118 may be one half of a client key 2106. A server key first part
2119
5 and a server key second part 2120 may comprise different portions of the
characters
that comprise a server key 2105. In a specific embodiment, each of a server
key first
part 2119 and a server key second part 2120 may be one half of a server key
2105. A
client key first part 2117, a client key second part 2118, a server key first
part 2119,
and a server key second part 2120 may be combined by a data manipulator 2144
10 through concatenation of units to form one or more strings of characters
comprising a
first pre-key 2121. Concatenation may comprise using each of a client key
first part
2117, a client key second part 2118, a server key first part 2119, and a
server key
second part 2120 as a unit or may comprise using pieces of a client key first
part
2117, a client key second part 2118, a server key first part 2119, and a
server key
15 second part 2120 as a unit.
A first pre-key 2121 may be converted 2112 by a data converter 2145 into a one
or
more strings of characters comprising a second pre-key 2122. In some
embodiments,
conversion 2112 may comprise using hash algorithms. In other embodiments,
conversion 2112 may comprise using encryption methods. Yet other embodiments
20 may comprise conversion 2112 using a combination of hash algorithms and
encryption methods. A second pre-key 2122 may be used to generate a
registration
pre-key 2123. According to some embodiments, a second pre-key 2122 and a
client
registration code 2103 may be concatenated by a data manipulator 2144 to form
one
or more strings of characters comprising a registration pre-key 2123.
Concatenation
25 may comprise using each of a second pre-key 2122 and a client
registration code 2103
as a unit or may comprise using pieces of a second pre-key 2122 and a client
registration code 2103 as a unit. A client registration code 2103 may be
stored in a
memory 2108 of a first peer 2101 by a processing migrator 2142 during a
registration
process. A registration pre-key 2123 may be converted 2112 by a data converter
2144
30 into a one or more strings of characters comprising a registration key
2107. In some
embodiments, conversion 2112 may comprise using hash algorithms. In other
embodiments, conversion 2112 may comprise using encryption methods. Yet other
embodiments may comprise conversion 2112 using a combination of hash
algorithms
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
56
and encryption methods. In some embodiments, a registration key 2107 may be
identical to a registration key 1707 generated by a first peer 1701 during a
registration
method 1700, shown in Figure 17. Referring back to Figure 21, a registration
key
2107 may be used to generate a login key 2199. In some embodiments, a
registration
key 2107 and a login salt 2124 are used to generate a login key 2199. A
registration
key 2107 and a login salt 2024 may be concatenated by a data manipulator 2144
to
form one or more strings of characters comprising a login pre-key 2198.
Concatenation may comprise using each of a registration key 2107 and a login
salt
2024 as a unit or may comprise using pieces of a registration key 2107 and a
login salt
2024 as a unit. A login pre-key 2198 may be used to generate a login key 2199.
In
some embodiments, a login pre-key 2198 may be converted 2112 by a data
converter
2145 to a login key 2199. In some embodiments, conversion 2112 may comprise
using hash algorithms. In other embodiments, conversion 2112 may comprise
using
encryption methods. Yet other embodiments may comprise conversion 2112 using a
combination of hash algorithms and encryption methods.
A first peer 2101 may transmit information to a server 2150. According to some
embodiments, a transmitter/receiver 2141 of a first peer 2101 may transmit a
login
key 2199 and a server key 2105 to a server 2150. In other embodiments, a
transmitter/receiver 2141 of a first peer 2101 may transmit a login key 2199,
a server
key 2105, and other information necessary for a login method to a server 2150.
A login method may further comprise distributing one or more verification
keys.
Illustrated in Figure 22, a server 2250 may receive information from a first
peer 2201.
According to some embodiments, a transmitter/receiver 2241 of a server 2250
may
receive a login key 2299 from a first peer 2201. A transmitter/receiver 2241
of a
server 2250 may receive a server key 2205 from a first peer 2201. A
transmitter/receiver 2241 of a server 2250 may receive both a login key 2299
and a
server key 2205 from a first peer 2201. In some embodiments, a server 2250 may
generate a comparison login key 2260. A comparison login key 2260 may be
generated using a registration key 2207 that has been stored in a database
2257 of a
server 2250 during a registration method. A processing migrator 2242 of a
server
2250 may migrate a registration key 2207 and a login salt 2224 from a database
2257.
A data manipulator 2244 of a server 2250 may combine a registration key 2207
and a
login salt 2224 by concatenation to generate a comparison login pre-key. A
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
57
comparison login pre-key may be converted 2212 by a data converter 2245 to a
comparison login key 2260. In some embodiments, conversion 2212 may comprise
using hash algorithms. In other embodiments, conversion 2212 may comprise
using
encryption methods. Yet other embodiments may comprise conversion 2212 using a
combination of hash algorithms and encryption methods. A processing verifier
2247
of a server 2250 may compare a comparison login key 2260 to a login key 2299
sent
by a first peer 2201 to determine if a first peer 2201 may be communicated
with.
A login key 2299 may be stored in a database 2257 of a server 2250 by a
processing
migrator 2242. A server may access a previously stored peer list 2258 using a
data
migrator 2242. A stored peer list 2258 may comprise a list of peer devices,
e.g. a first
peer 2201, a second peer 2275, on the network. A peer list may also comprise
recipient codes 2252 and distribution codes 2256, which may comprise a one or
more
strings of characters of any length. Additionally, a processing generator 2246
of a
server 2250 may generate a sender code 2254, which may also comprise a one or
more strings of characters of any length.
A data manipulator 2244 of a server 2250 may generate a distribution pre-key
2259
by combining any combination of a server key 2205, a recipient code 2252. a
sender
code 2254, a distribution code 2256, or a login key 2299. In some embodiments,
a
distribution pre-key 2259 is comprised of a server key 2205, a sender code
2254, and
a recipient code 2252, 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 2205, a sender code 2254, and a recipient code 2252 as a unit or may
comprise
using pieces of a server key 2205, a sender code 2254, and a recipient code
2252 as a
unit. A distribution pre-key 2259 may be converted 2212 by a data converter
2245
into a one or more strings of characters comprising a distribution key 2253.
In some
embodiments, conversion 2212 may comprise using hash algorithms. In other
embodiments, conversion 2212 may comprise using encryption methods. Yet other
embodiments may comprise conversion 2212 using a combination of hash
algorithms
and encryption methods. A distribution key 2253 may be stored in a database
2257 of
a server 2250. A verification pre-key 2261 may be generated by a data
manipulator
2244 of a server 2250. In some embodiments, a distribution key 2253 and a
verification salt 2263, generated by a processing generator 2246 of a server
2250 and
comprising any number of characters, may be concatenated to generate a
verification
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
58
pre-key 2261. A verification pre-key 2261 may be converted 2212 by a data
converter
2245 into a verification key 2262. In some embodiments, conversion 2212 may
comprise using hash algorithms. In other embodiments, conversion 2212 may
comprise using encryption methods. Yet other embodiments may comprise
conversion 2212 using a combination of hash algorithms and encryption methods.
A server 2250 may be configured to transmit information to a second peer 2275.
In
some embodiments, a transmitter/receiver 2241 of a server 2250 may transmit a
verification key 2262 and a distribution code 2256 to a second peer 2275. In
other
embodiments, 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. In some embodiments,
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 server 2250 may generate more than one verification keys 2262 and transmit
data to
more than one second peer 2275. In some embodiments, a peer list 2258 may
comprise a list of more than one second peers 2275 on the network. A second
peer
may comprise any IoT device, server, or any device that is on a network and
capable
of transmitting and receiving data from a server 2250. A server 2250 may
generate a
unique distribution code 2256 for each second peer 2275. A server 2250 may
generate
a unique recipient code 2252 for each second peer 2275. In these embodiments,
a
verification key 2262 created for each second peer 2275 may be different from
verification keys 2262 created for other second peers 2275, although
underlying
server keys 2205 received from a first peer 2201 may be identical.
Verification keys
2262 may or may not be stored at a database 2257 of a server 2250.
Referring now to Figure 23, a login method may comprise verifying one or more
login keys on a local database. According to some embodiments, a second peer
2375
may be configured to receive and transmit information to a server 2350. A
transmitter/receiver 2341 of a second peer 2375 may receive a verification key
2362
from a server 2350. A transmitter/receiver 2341 of a second peer 2375 may
receive a
distribution code 2356 from a server 2350. In some embodiments, a
transmitter/receiver 2341 of a second peer 2375 may receive a verification key
2362,
a distribution code 2356, and verification salt 2363 from a server 2350. A
distribution
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
59
code 2356 may be compared by a processing verifier 2347 across all
distribution
codes 2356 stored in a memory 2378 of a second peer 2375. If a distribution
code
2356 received from a server 2350 is identical to a distribution code 2356
stored in a
memory 2378 of a second peer 2375, then a processing generator 2346 of a
second
peer 2375 may produce a result 2382 that is affirmative. If a distribution
code 2356
received by a second peer 2375 is not identical to a distribution code 2356
stored in a
memory 2378 of a second pccr 2375, then a processing generator 2346 of a
second
peer 2375 may produce a result 2382 that is negative. In some embodiments, a
verification key 2362 is also used to locate identical distribution codes
2356. If a
second peer 2375 determines that one or more distribution codes 2356 stored in
a
memory 2378 of a second peer 2375 is identical to a distribution code 2356
received
from a server 2350, then a processing migrator 2342 of a second peer 2375 may
remove a distribution key 2353 that is associated with a matching distribution
code
2356 from a memory 2378. A distribution key 2353 removed from a memory 2378 of
a second peer 2375 and a verification salt 2363 may be used by a data
manipulator
2344 to generate a confirmation pre-key 2380 by concatenation. A confirmation
pre-
key 2380 may be converted 2312 by a data converter 2345 to a confirmation key
2381. In some embodiments, conversion 2312 may comprise using hash algorithms.
In other embodiments, conversion 2312 may comprise using encryption methods.
Yet
other embodiments may comprise conversion 2312 using a combination of hash
algorithms and encryption methods.
In some embodiments, a second peer 2375 may receive a distribution key and a
verification salt 2363 from a server 2350. A second peer 2375 may generate a
verification key 2362 at a second peer 2375 by concatenation of a distribution
key and
a verification salt 2363 to generate a verification pre-key. A verification
pre-key may
be converted 2312 to a verification kay 2362.
In some embodiments, a second peer 2375 may generate a comparison verification
key 2383. A second peer 2375 may generate a comparison verification key 2383
by
concatenation of a stored distribution key 2353 and a verification salt 2363
received
from a server 2350 to generate a comparison verification pre-key. A comparison
verification pre-key may be converted 2312 to a comparison verification key.
In some
embodiments, a comparison verification key 2383 may be compared by a
processing
verifier 2347 to a received verification key 2362 and a result 2382 may be
generated.
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
In some embodiments, a result 2382 may comprise a result generated from
comparing
a verification key 2362 to a comparison verification key 2383 and a result
generated
from comparing a received distribution code 2356 to a stored distribution code
2356.
A confirmation key 2381 may be generated from a verification salt 2363 and a
deposit
5 key 2377 retrieved from a memory 2378 of a second peer 2375. A deposit
key 2377
and a verification salt 2363 may be concatenated by a data manipulator 2344 to
generate a confirmation pre-key 2380. A confirmation pre-key 2380 may be
converted
2312 to a confirmation key 2381. Any combination of a confirmation key 2381, a
distribution code 2356, and a result 2382 may be transmitted from a second
peer 2375
10 to a server 2350.
A second peer 2375 may be configured to transmit data to a server 2350. In
some
embodiments, a transmitter/receiver 2341 of a second peer 2375 may transmit
any
combination of a result 2382, a distribution code 2356, and a confirmation key
2381
to a server 2350. In some embodiments, a second peer 2375 may be configured to
15 delete all data associated with a transaction. In a specific embodiment,
a second peer
2375 may delete any combination of a distribution code 2356, a deposit key
2377, a
distribution key 2353, a verification key 2362, a verification salt 2326, a
confirmation
pre-key 2380, and a confirmation key 2381 from a memory 2378 of a second peer
2375 or from a processor of a second peer 2375. In some embodiments, deletion
of
20 data may occur contemporaneously with transmitting data to a server
2350. In other
embodiments, deletion of data may occur after transmitting data to a server
2350.
Referring now to Figure 24, a login method may further comprise validating a
verification process 2400. A server 2450 may be configured to receive data
from a
one or more second peers 2475. In some embodiments, a transmitter/receiver
2441 of
25 a server 2450 may receive any combination of a confirmation key 2481, a
result 2482,
and a distribution code 2456. A server 2450 may acknowledge a result 2482
received
from a second peer 2475. In the event that a result is affirmative, a
processing verifier
2447 of a server 2450 may compare a distribution code 2456 received from a
second
peer 2475 to all or some distribution codes 2456 stored in a database 2457 of
a server
30 2450. If a distribution code 2456 stored in a database 2457 of a server
2450 is
identical to a distribution code 2456 received from a second peer 2475, then 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
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
61
distribution code 2456 and stored in a database 2457 of a server 2450. In some
embodiments, 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. In some embodiments, conversion
2412
may comprise using hash algorithms. In other embodiments, conversion 2412 may
comprise using encryption methods. Yet other embodiments may comprise
conversion 2412 using a combination of hash algorithms and encryption methods.
A processing verifier 2447 of a server 2450 may compare a generated
verification key
2462 to a confirmation key 2481 received from a second peer 2475 and a
processing
generator 2246 may produce an authentication result 2464. If a verification
key 2462
is identical to a confirmation key 2481 received from a second peer 2475, a
result
might be affirmative, e.g. authentication success. If a verification key 2462
is not
identical to a confirmation key 2481 received from a second peer 2475, then an
authentication result 2464 may be negative, e.g. authentication failure or
threat. A
processing migrator 2442 of a server 2450 may store an authentication result
2464 in
a database 2457. In some embodiments, an authentication result 2464 is stored
with
an associated distribution key 2453 generated during a registration method.
A server 2450 may send new distribution keys 2453 to one or more second peers
2475. Referring now to Figure 19, a server 1950 may generate a new peer list
1958 in
a database 1957 of a server 1950. In some embodiments, a server 1950 may
assign
any combination of a new recipient code 1952 and a new distribution code 1956
and
use any combination of a new recipient code 1952 and a new distribution code
1956
to generate a new distribution key 1953, in a method which may be identical to
distributing one or more distribution keys 1900. A server 1950 may transmit
newly
generated distribution keys 1953 to second peers 1975 which may be different
from
second peers 1975 which previously stored distribution keys 1953.
A web authentication method may comprise generating a bar code, generating one
or
more keys, and establishing a web session. Further, a web authentication
system may
comprise communication between one or more first devices, second devices,
first
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
62
servers, second servers, and internet applications. One or more first devices,
second
devices, first servers, and second servers may comprise at least a processor
and a
transmitter/receiver. One or more first devices and one or more second devices
may
additionally comprise a respective memory. In some embodiments, each of one or
more first devices and one or second devices may comprise a visual display.
Each of
one or more first devices and one or second devices may comprise a means to
scan a
bar code. One or more first servers and second servers may additionally
comprise a
database.
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. In
some
embodiments, 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. By way of example, and not limitation, 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 data manipulator may be configured to manipulate data, e.g. combine,
separate, separate and recombine, reorder, etc. By way of example, and not
limitation,
a data manipulator of a first device may be configured to separate a one or
more
strings of characters into a first portion and a second portion, or a data
manipulator of
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
63
a server may be configured to combine a first portion of data with a second
portion of
data to produce one or more strings of characters.
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. In some embodiments, a data converter may be configured to apply
hash
algorithms to a first string of characters. In other embodiments, a data
converter may
be configured to apply encryption protocols to a first string of characters.
In yet other
embodiments, a data converter may be configured to apply decryption protocols
to a
first string of characters. In other embodiments still, 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. In some embodiments,
data may comprise a one or more strings of characters of any length and may
comprise bar codes and the like. In some embodiments, 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. In
some embodiments, 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.
A web authentication method may comprise generating a bar code, illustrated in
Figure 25. Generating a bar code 2500 may be initiated at an internet
application
2590. In some embodiments, a user may initiate generating a bar code 2500 at
an
internet application 2590 with a login request. A first agreement protocol
pair 2646
may be generated by a processing generator 2646. In some embodiments, a first
agreement protocol pair 2646 may be generated by a processing generator 2646
at an
internet application 2590. A first key agreement protocol pair 2526 may
comprise any
key agreement protocol pair that is readily known to a person having ordinary
skill in
the art. In some embodiments, a first key agreement protocol pair 2526 may
comprise
an Elliptic-curve Diffie¨Hellman (ECDH) pair. According to some embodiments,
an
internet application 2590 may be configured to transmit information to a first
server
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
64
2525. A processing migrator 2642 may transfer information to a
transmitter/receiver
2541 of an intemet application 2590. An intemet 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.
In some embodiments, a first server 2525 may be configured to receive
information
from an intemet 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 intemet
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. In some embodiments, 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. In some embodiments, 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. In a specific embodiment, 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 intemet application 2590. In some embodiments, a
transmitter/receiver 2541 of a first server 2525 may transmit information to
an
intemet application 2590. In a specific embodiment, a first server 2525 may
transmit a
bar code 2505 to an intemet application 2590. An intemet application 2590 may
receive a bar code 2505 at a transmitter/receiver 2541 and may display a bar
code
2505 at a visual display 2590 of an intemet application 2590.
A web authentication method may comprise generating one or more keys,
illustrated
in Figures 26, 27, and 28. Referring now to Figure 26, generating one or more
keys
2600 may comprise a first device 2650 scanning a bar code 2605. A data
manipulator
2644 of a first device 2650 may generate a random key 2627, a first public key
2603,
or a random key 2627 and a first public key 2603 from information contained
within a
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
bar code 2605. A data manipulator 2644 may extrapolate any information
contained
within a bar code 2605 for the purpose of generating one or more keys 2600.
Further,
a processing generator 2646 of a first device 2650 may generate a second key
agreement protocol pair 2651. A second key agreement protocol pair 2651 may
5 comprise any key agreement protocol pair that is readily known to a
person having
ordinary skill in the art. In some embodiments, a second key agreement
protocol pair
2651 may comprise an Elliptic-curve Diffie¨Hellman (ECDH) pair. In some
embodiments, 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
10 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. In a specific embodiment, a processing
generator
2646 of a first device 2650 may generate each of a salt 2655, an initializing
vector
15 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
20 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
25 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. According to some embodiments, 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
30 2663, a masked IV first part 2664, and a masked IN first part 2665,
respectively. In
some embodiments, an initializing vector 2656 may be converted 2612 by a data
converter 2645 to a masked IV first part 2664. Likewise, an iteration number
2657
may be converted 2612 by a data converter 2645 to a masked IN first part 2665.
In
some embodiments, conversion 2612 may comprise using hash algorithms. In other
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
66
embodiments, conversion 2612 may comprise using encryption methods. Yet other
embodiments may comprise conversion 2612 using a combination of hash
algorithms
and encryption methods. In some embodiments, 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.
According
to some embodiments, a client key 2666 may be converted 2612 by a data
converter
2645 to a first masked client key 2667. In other embodiments, a client key
2667 may
be converted 2612 by a data converter 2645 to a second masked client key 2668.
In
yet other embodiments, 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. Additionally,
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. In some embodiments, 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. In some
embodiments, 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. In a specific
embodiment, an
iteration number 2657 may be displayed in its entirety on a visual display
2669 of a
first device 2650.
Referring now to Figure 27, generating one or more keys may comprise a first
server
2725 receiving information from a first device 2750. In some embodiments, 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. In some embodiments, a processing migrator 2742
of a
first server 2725 may store one or more of a masked secret key 2762, a second
masked client key 2768, a masked salt 2763, a masked IV first part 2764, a
masked
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
67
IN first part 2765, and a first masked client key 2767 received from a first
device
2750 in a database 2729 of a first server 2725. According to a specific
embodiment, a
processing migrator 2742 of a first server 2725 may store a first masked
client key
2767 in a database 2729 of a first server 2729.
A first server 2725 may be configured to transmit information to an intemet
application 2790. In some embodiments, 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. In a
specific
embodiment, 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. In
other
embodiments, 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 intemet application 2790
(collectively
referred to as "received data 2728- from this point forward).
Illustrated in Figure 28, generating one or more keys 2800 may comprise a
transmitter/receiver 2841 of an intemet application 2890 receiving received
data 2828
from a first server 2825. A first device 2850 may contain user input 2869,
which may
comprise an IV second part 2659 and an IN second part 2661 (see Figure 26),
which
may respectively comprise strings of characters. User input 2869 may comprise
an IV
first part and an iteration number. In some embodiments, user input 2869 may
be
displayed on a graphical display 2869 of a first device 2850. Generating one
or more
keys may comprise user input 2869 being entered into an intemet application
2890. A
data converter 2844 of an intemet application 2890 may convert 2812 received
data
2828 into one or more of a secret key 2854, an IN first part 2860, a salt
2855, an IV
first part 2858, and a client key 2866. Conversion 2812 may comprise using
hash
algorithms. Additionally, conversion 2812 may comprise using encryption
methods.
Conversion may comprise using decryption methods. In some embodiments,
conversion 2812 may comprise any combination of hash algorithms, encryption
methods, or decryption methods. According to some embodiments, a data
converter
2844 of an internet application 2890 may use both user input 2869 and received
data
2828 to convert 2812 received data 2828 into one or more of a secret key 2854,
an IN
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
68
first part 2860, a salt 2855, an IV first part 2858, and a client key 2866. A
processing
migrator 2842 may store a client key 2866 in a storage 2891 of an interact
application
2890. A data converter 2845 of an intemet application 2890 may convert 2812 a
client
key 2866 into a third masked client key 2892. In some embodiments, a third
masked
client key 2892 may be migrated by a processing migrator 2842 to a
transmitter/receiver 2841 of an intemet application 2890. A
transmitter/receiver 2841
of an internct application 2890 may transmit a third masked client key 2892 to
a first
server 2825.
A web authentication method may comprise establishing a web session.
Illustrated in
Figure 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 intemet 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. A transmitter/receiver 2941 of a
first server
2825 may transmit a result 2930 to a second server 2980. A
transmitter/receiver 2941
of a second server 2980 may receive a result 2930 from a first server 2825 and
generate a web token 2931. A web token 2931 may be generated by a processing
generator 2946. In some embodiments, a web token 2931 may be any means known
in
the art for authorizing the establishment of a web session. A second server
2980 may
transmit a generated web token 2931 to first server 2825. A
transmitter/receiver 2941
of a first server 2825 may receive a web token 2931 from a second server 2980
and
may transmit a received web token 2931 to an intemet application 2990. A
transmitter/receiver 2941 of an intemet application 2990 may receive a web
token
2931 from a first server 2825.
In some embodiments, an intemet application may transmit a received web token
to a
second server. A second server may receive a web token from a web browser and
may
establish a web session. Further, a second server may be configured to
transmit
information to a first server. In some embodiments, a second server may
transmit
information regarding receipt of a web token from an intemet application.
Information
regarding receipt of a web token from an intemet application may comprise
without
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
69
limitation any information about the intemet application, information about a
user of
an internet application, information about access to a web session, spatial
and/or
temporal information about any component of a system described herein. A first
server may receive information regarding receipt of a web token from a second
server.
In some embodiments, a first server may be configured to transmit information
to a
first device, including without limitation, information regarding receipt of a
web
token.
Generating Keys to Protect Sensitive Data
It will be appreciated that any method, system, component, and/or embodiment
disclosed appearing in any part of this disclosure may be combined with any
other
method, system, component and/or embodiment appearing in any other part of
this
disclosure. Biometrics may be incorporated into any embodiments described
herein as
codes, information, data, etc.
In some embodiments, keys (e.g., privacy keys) may be generated in order to
protect
the contents of sensitive data transmissions. For example, where a first data
comprises sensitive information such as biometric data, sensitive
communications,
etc., using controlled corruption to generate keys may provide an elegant
means by
which the sensitive data (e.g., first data), may be protected against a third-
party
interception. Sensitive data (e.g., first data) may comprise any number of
data types,
for example and without limitation, biometric data, documents, text messages,
email
messages, or other types of sensitive communications.
According to some embodiments, 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. In some embodiments, 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.) may be any server or any IoT device, i.e. any
device
that may connect to a network and have the ability to transmit data, including
but not
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
limited to cell phones, personal assistants, buttons, home security systems,
appliances,
and the like.
FIGURE 30 is an example system, according to a specific embodiment, for
generating
keys using controlled corruption 3000. The system may include a web layer 3010
5 comprising a first computing device 3012, an administrative layer 3020
comprising
one or more servers 3022, and a client layer 3030 comprising one or more
servers
3022. A system 3000 may additionally include one or more communications
channels (e.g., intemet gateways and one or more virtual private network (VPN)
tunnels), shown in dotted lines.
10 The web layer 3010 may further comprise an administrative mobile
platform (AMP)
3014 comprising an administrative mobile library (AML) and a partner mobile
library
(PML) and an administrative web platform (AWP) 3016 comprising an
administrative
web library (AWL) and a partner web library (PWL). As used herein, any library
may mean, without limitation, any application, application database, database,
and/or
15 data.
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
20 (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. In some embodiments,
the
client layer 3030 and the administrative layer 3020 may be in communication
with
25 one another using a VPN tunnel.
FIGURE 31 is an example server-side (e.g., comprised in the administrative
layer
3020) method of generating keys using controlled corruption 3100, according to
a
specific embodiment, which may comprise registering a first computing device
at one
or more servers 3140; receiving, at the one or more servers, a first privacy
code and
30 one or more parameters associated with first data from the first computing
device
3142; generating, at the one or more servers, a chunk count and a public key
3143;
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
71
transmitting the chunk count and public key to the first computing device
3144;
receiving, at the one or more servers, a quantity of first privacy keys and a
second
privacy code 3146; and generating, at the one or more servers, second data
based on
the privacy keys 3148.
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. In some
embodiments, 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. A detailed discussion of different methods
of
communication may be found in the preceding sections of this specification.
According to some embodiments, registration of a computing device comprised in
the
web layer may include initiating communications and transmission of
information
between the administrative layer (e.g., an ASE), the client layer (e.g., a
CSA), and the
web layer (e.g., an AML and/or AWL comprised in a computing device).
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. As discussed above, 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. In some embodiments, 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). In some embodiments, 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. In a
specific embodiment, a privacy code is a first user input comprising a
personal
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
72
identification number (e.g., PIN) selected by a user of the computing device.
A
privacy code may be based on user input, for example, an encrypted version, a
hashed
version, a truncated version, or a rearranged version of a user input. In some
embodiments, a privacy code may be generated automatically by a component of
the
system (e.g., server, first computing device, etc.). In some embodiments, a
privacy
code may comprise and/or may be based on a digital footprint of a user. In
these
embodiments, a user's digital footprint may comprise information about a
user's
digital habits including, but not limited to, browsing history, browsing
times/duration/frequency, usage habits, application usage, purchasing habits,
geolocation data, etc.
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, according to some embodiments, 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. In some embodiments, 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.
According to some embodiments, a quantity of privacy keys (based on one or
more of
the first data, the chunk count, the chunk names, and the privacy code) may be
generated by a computing device comprised in the web layer of a system for
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
73
generating privacy keys. FIGURE 32 is a computing device-side illustration of
a
method of generating privacy keys 3200 according to come embodiments.
A computing device 3212 (e.g., a first computing device) comprised in the web
layer
of the system may receive a chunk count 3260, chunk names 3261, and a public
key
3262 from one or more servers comprised in the administrative layer of the
system.
As discussed above, a first data 3263 may comprise any data that a user may
consider
secure and desire to protect in transit. In some embodiments, a computing
device
3212 may condense (e.g., zip) a first data 3263 to generate a compressed first
data
3264. A computing device 3212 may generate a base 64 of the compressed first
data
3265 where the base 64 of the compressed first data 3265 comprises a base 64
version
of the compressed first data 3264. Using controlled corruption (e.g., a
controlled file
corruption), a computing device 3212 may generate a first pre-key 3267 by
adding a
corruptor (e.g., first corruptor 3266) to the base 64 of the compressed first
data 3265.
As discussed above, a corruptor 3266 may comprise a string of alphanumeric
and/or
symbolic characters. In a specific embodiment, a first corruptor 3266 may be
based
on a formula. For example, a first corruptor 3266 may be generated by a
computing
device 3212 by summing the first 30 characters comprised in the base 64 of the
compressed first data 3265. In another specific embodiment, a first corruptor
3266
may be generated by summing the first and third characters the comprised in
the base
64 of the compressed first data 3265, summing the second and fourth characters
comprised in the base 64 of the compressed first data 3265, summing the third
and
fifth characters comprised in the base 64 of the compressed first data 3265,
etc., and
concatenating the results to generate a string of numeric characters which may
then
comprise a first corruptor 3266. Any number of formulas may be used to
generate a
corruptor (e.g., first corruptor 3266, second corruptor 3268, third corruptor
3273, etc.)
and the possibilities are not limited to the examples above.
A computing device 3212 may generate a second pre-key 3269 by adding a
corruptor
(e.g., second corruptor 3268) to the first pre-key 3267. In a specific
embodiment, a
corruptor (e.g., second corruptor 3268) may comprise one or more alphanumeric
and/or symbolic characters comprised in a privacy code entered by a user. In
some
embodiments, a corruptor (e.g., second corruptor 3268) may comprise one or
more
alphanumeric and/or symbolic characters comprised in a manipulated (e.g.,
hashed,
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
74
encrypted, rearranged, truncated, etc.) privacy code entered by a user. In a
specific
embodiment, a second corruptor 3268 may be based on a formula.
A computing device 3212 may generate a salt 3270 and an initializing vector
(IV)
3271. A detailed discussion of a salt 3270 and IV 3271 may be found in earlier
sections of this specification. A salt 3270 and IV 3271 may be added to a
second pre-
key 3269 to generate a third pre-key 3272. It should be appreciated that this
addition
(e.g., salt 3270 and IV 3271) is not always present when generating privacy
keys and
that, according to some embodiments, a second pre-key 3269 may be used to
generate
chunks 3274 based on the chunk count 3260 without the addition of a salt 3270,
IV
3271, or third corruptor 3273.
A third corruptor 3273 may be added to a third pre-key 3272. A third corruptor
3273
may be generated by a computing device 3212 in any manner described above for
a
corruptor (e.g., first corruptor 3266, second corruptor 3268). In a
specific
embodiment, a third corruptor 3273 may be based on a formula. In some
embodiments, a third corruptor 3273 is added to a third pre-key 3272 and the
resulting
string is then divided into chunks 3274 based on the chunk count 3260 received
from
the administrative layer. As discussed above, a chunk count 3260 is an integer
that
directs the number of chunks 3274 to be generated in a method of generating
keys
3200. For example, where the chunk count 3260 is equal to three, then a
computing
device 3212 will divide the pre-key (e.g., third pre-key 3272, second pre-key
3269,
third pre-key 3272 with a third corruptor 3273) into three chunks 3274.
In some embodiments, 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.
In some embodiments, 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 may be named according to chunk names 3261 to generate privacy
keys
3275. According to some embodiments, chunk names 3261 may be generated at an
administrative layer and received at a computing device 3212 comprised in the
web
layer. Chunk names 3261, as discussed above, may be based at least in part on
information received as part of parameters associated with a first data (e.g.,
an initial
package). In a specific embodiment, the number of chunk names 3261 received is
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
equal to the chunk count 3260. For example, where a chunk count 3260 is equal
to
three, three chunk names 3261 will be generated at the administrative layer
and
received at a computing device 3212. Accordingly, in this embodiment, three
chunks
3274 will be generated (based on the chunk count 3260) and each resulting
chunk
5 3274 will have an associated chunk name 3261. In some embodiments, 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, according to
these embodiments, 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.
10 To illustrate the above, the following example is provided. Where a
third pre-key
3272 comprises the string '123456789' and a third corruptor 3273 comprises the
string '543', a resulting string from controlled corruption may comprise the
string
'123455436789'. If the chunk count 3260 is equal to three and the chunk names
are
'One', 'Two', and 'Three', the resulting privacy keys may comprise the
following:
Chunk Name Privacy Key
String
'One' '123'
'Two' '4554'
'Three' '36789'
Chunk names 3261 may, according to some embodiments, facilitate downstream
ordering of the privacy keys 3275 to recreate the initial string. Here, by
ordering the
privacy keys 3275 according to 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,
according to
some embodiments, 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. According to
a
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
76
specific embodiment, 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.
Referring now back to FIGURE 31, 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.
FIGURE 33 illustrates a specific embodiment of generating second data based on
the
privacy keys 3300. A second data 3382, according to some embodiments, may
comprise a reconstructed version of a first data. For example, 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.
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.
According to some embodiments, 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. According to some embodiments, and as
discussed
above, 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 3322 may remove a third corruptor 3373 to generate a first
cleaned data 3377, remove a salt 3370 and IV 3371 to generate a second cleaned
data
3378, remove a second corruptor 3368 to generate a third cleaned data 3379,
and
remove a first corruptor 3366 to generate a base64 file of a compressed second
data
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
77
3380. According to some embodiments, removal of corruptors may require
recognition of the corruptors (e.g., first corruptor 3366, second corruptor
3368, third
corruptor 3373, etc.) which need to be removed. In these embodiments, the one
or
more servers may use different recognition tools to recognize corruptors. For
example, where a corruptor has been generated at a computing device using a
privacy
code (or a derivative of a privacy code such as a truncated privacy code), one
or more
servers may generate a privacy code from a received second privacy code 3377.
In a
specific embodiment, a second privacy code 3377 is used to remove one or more
coriuptors (e.g., first corruptor 3366, second corruptor 3368, third corruptor
3373,
etc.). In some embodiments, the one or more servers 3322 use a fon-nula to
generate a
corruptor (e.g., the same formula used to generate a corruptor at the
computing
device) and use the newly generated corruptor to recognize a corruptor
embedded in a
cleaned data (e.g., first cleaned data 3377, second cleaned data 3378, third
cleaned
data 3379, etc.) and remove it. Importantly, a characteristic of one or more
servers
3322 is the ability to recognize corruptors (e.g., first corruptor 3366,
second corruptor
3368, third corruptor 3373, etc.) in a concatenated key 3376 or in cleaned
data (e.g.,
first cleaned data 3377, second cleaned data 3378, third cleaned data 3379,
etc.) and
systematically remove them to generate a base 64 of a compressed second data
3380.
In some embodiments, a concatenated key 3376 may be decrypted to generate a
first
cleaned data 3377.
A base 64 file of a compressed second data 3380 may be converted (e.g.,
decoded) to
a compressed second data 3381. According to some embodiments, a compressed
second data 3381 may be converted (e.g., unzipped) to a second data 3382. As
discussed above, a second data 3382 may be a reconstructed version of a first
data.
For example, where 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.
Where 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. In
this
way, it will be appreciated by one of ordinary skill in the art that 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.
For
example, where 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
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
78
message) may be generated at a processor comprised in a second mobile device
(e.g.,
a second computing device).
Using Privacy Keys to Authenticate Identity
Privacy keys, according to some embodiments, may be used to authenticate
identity
from a first computing device (e.g., a mobile computing device). In some
embodiments, a first data may comprise a biometric scan, login password or
code, or
any other first data which may be based on a user input. A method for
generating
privacy keys using controlled corruption, and distributing, storing, and/or
retrieving
stored privacy keys to authenticate identity may include an enrollment module
and a
sign in module.
Enrollment Module. An enrollment module may comprise methods to generate keys
(e.g., privacy keys) using controlled corruption and distribute and store keys
for later
use. Using the methods and systems disclosed herein, 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. When 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.
By generating privacy keys using controlled corruption, a user's input, such
as
biometric data, may be protected.
FIGURE 34 is an example server-side (e.g., comprised in the administrative
layer
3020) method of generating and distributing keys using controlled corruption
3400,
according to a specific embodiment, which may comprise registering a first
computing device at one or more servers 3440; receiving, at the one or more
servers, a
first privacy code and one or more parameters associated with first data from
the first
computing device 3442; generating, at the one or more servers, a chunk count
and a
public key 3443; transmitting the chunk count and public key to the first
computing
device 3444; receiving, at the one or more servers, a quantity of first
privacy keys and
a second privacy code 3446; and generating, at the one or more servers, second
data
based on the privacy keys 3448. According to some embodiments, privacy keys
may
be stored at one or more nodes associated with the one or more servers for
later uses,
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
79
for example, authenticating identity. In these embodiments, a method for
generating
and distributing keys 3400 may further comprise generating a result 3450,
generating
a receiver identifier and a privacy code identifier 3452, and distributing
privacy keys,
the receiver identifier, and the privacy code identifier to one or more of the
nodes
associated with the one or more servers 3454.
When privacy keys are generated for uses such as authentication, the methods
of
generating onc or more privacy keys arc generally thc same as those
illustrated in
FIGURES 31, 32, and 33 and discussed above. In addition to those methods, a
method 3400 may include generating a result 3450. According to some
embodiments,
a base 64 file of compressed second data (such as 3380 of FIGURE 33) may be
compared to a base 64 of compressed first data which may be received as a
parameter
associated with first data (such as in 3142 of FIGURE 31). In these
embodiments, the
two base 64 files may be compared and a result may be generated 3450. Where
the
two base 64 files are identical, a result may be positive. Where the two base
64 files
are not identical, a result may be negative.
In some embodiments, a result 3450 may be generated by comparing a compressed
second data 3381 to a compressed first data. In some embodiments, a result
3450
may be generated by comparing a second data 3382 to a first data. In some
embodiments, a result may be generated by comparing multiple elements (e.g.,
first
and second data, compressed first and compressed second data, base64 of
compressed
first and base64 of compressed second data, etc.). Iterative learning may be
utilized
when generating a result 3450. For example, many second data 3382 may be
generated over time and these second data 3382 may be compared to one another,
over time, to generate a result 3450. Although second data 3382 is used as an
example, a result 3450 may be generated by comparing any of the elements
(e.g., first
data, compressed data, base64 compressed data, privacy codes, etc.) over time.
In some embodiments, a positive result may prompt the one or more servers
comprised in an administrative layer to generate a receiver identifier and a
privacy
code identifier 3452. A positive result may prompt one or more servers
comprised in
an administrative layer to generate two or more copies of each privacy key
received
from a computing device 3446. The privacy keys, receiver identifier, and
privacy
code identifier may be transmitted to one or more nodes associated with the
one or
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
more servers for storage 3454. In some embodiments, the privacy keys, receiver
identifier, and privacy code identifier may be manipulated before
transmission.
Distributing privacy keys to one or more nodes for storage 3454 may be done
using a
ledgerless non-descriptive distribution. This method of distribution may
comprise
5 using sender identifiers in conjunction with receiver identifiers,
privacy codes, and/or
other user specific codes (e.g., biometrics, etc.) to generate unique piece
descriptions
for each privacy key. A sender identifier, according to some embodiments, may
be a
string of alphanumeric and/or symbolic characters used to identify any
combination of
users, transactions, applications, and/or computing devices. In these
embodiments, a
10 system may manipulate one or more of privacy keys, privacy codes, receiver
identifiers, and sender identifiers to generate a unique piece description for
each
privacy key distributed. Piece descriptions, according to some embodiments,
may be
created on an "as-needed" basis, eliminating the need for keeping ledgers or
other
records of privacy keys destinations (e.g., nodes) at the server.
15 Even if a hacker/virus is able to penetrate the defenses (e.g., firewall
and other
security features) and enter the system, not having an endpoint address (of
where the
data is distributed) stored in a central location or a central ledger, ensures
that the
hacker will not know where the nodes are or which nodes have a particular
data.
Even if the nodes are compromised, this type of distribution ensures that the
hacker
20 will not be able to identify pieces that go together to form a data.
This also provides
protection against ransomware and has high fault tolerance. Furthermore, the
manipulation (e.g., encryption, hashing, corruption, chunking, concatenation,
etc.)
process ensures another level of security, even if the pieces from the nodes
are
obtained, it cannot be put together in its original form without the
authorized user's
25 consent.
The privacy keys, receiver identifier, and privacy code identifier may be
stored for
later uses, including identity authentication in the sign in module.
Sign In Module. When a user (e.g., system user at a computing device comprised
in
the web layer) wishes to use stored privacy keys to authenticate identity in a
sign in
30 module, a user enters a first user input (e.g., a privacy code) and a
second user input
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
81
(e.g., a biometric scan, a third data). A method for authenticating identity
using
privacy keys is illustrated in FIGURE 35.
Privacy keys based on third data 3590 are generated in the same manner as
described
above and as illustrated in FIGURES 31 and 32. The resulting privacy keys 3590
are
transmitted to one or more servers comprised in the administrative layer of
the
system. Using information comprised in one or more of a privacy key, a privacy
codc, a second privacy code, and parameters associated with a first data, the
one or
more servers locates and retrieves the stored privacy keys 3591 from the one
or more
nodes associated with the one or more servers. In some embodiments, retrieval
is
based at least partially on a receiver identifier and/or privacy code
identifier.
Each of the privacy keys based on third data 3590 (e.g., privacy keys received
from a
computing device during the sign in module) is used to generate a fourth data
in the
same manner illustrated in FIGURE 33. According to some embodiments, a fourth
data may be sign in data 3592. Each of the stored privacy keys 3591 retrieved
from
one or more nodes is used to generate a fifth data 3593 in the same manner
illustrated
in FIGURE 33. According to some embodiments, a fifth data may be enrollment
data
3593. A fourth data (e.g., sign in data 3592) may be compared to a fifth data
(e.g.,
enrollment data 3593) to generate a result 3594. According to some
embodiments, if
a fourth data 3592 is the same as a fifth data 3593, then the result 3594 is
positive. In
embodiments where a data (e.g., a first data, a second data, a third data, a
fourth data
3952, a fifth data 3593) is information about any one of a biometric scan, a
privacy
code, a login password, etc., then identity can be confirmed if the fourth
data 3952
(e.g., data entered during sign in) is the same as a fifth data (e.g., data
entered during
enrollment and stored as privacy keys). A positive result may allow a user to
access
one or more protected systems.
Using Privacy Keys for Secure Data Storage
In some embodiments, privacy keys may be used for secure data storage. For
example, in some embodiments, a first data may comprise a sensitive document.
The
first data may be used in the manner described above to generate privacy keys
which
may then be stored. In these embodiments, it may become necessary to edit the
secure data (e.g., first data, sensitive document). Privacy keys may be
retrieved in
these embodiments, and a second data generated in the manner described above.
The
CA 03178613 2022- 11- 11
WO 2021/229410
PCT/1B2021/053964
82
system allows for the temporary storage of the data (e.g., first data, second
data) at a
landing zone for editing. In some embodiments, a landing zone may be comprised
in
any one or more of the one or more servers, a temporary database, first
computing
devices, second computing devices, or application. In some embodiments, a
landing
zone may comprise an external application such as Google Docs, Microsoft Word,
or
other application. The edited data may then be used, in the manner described
above,
to generate a new set of privacy keys which may then be stored for later use.
It will be appreciated by those skilled in the art that other variations of
the
embodiments described herein may also be practiced without departing from the
scope of the invention. Other modifications are therefore possible.
CA 03178613 2022- 11- 11
