A SECURE MOBILE ELECTRONIC PAYMENT SYSTEM WHERE ONLY THE BANK HAS THE KEY, DISTRIBUTED KEY HANDSHAKES, ONE WAY AND TWO WAY AUTHENTICATION DISTRIBUTED KEY PROCESSES AND SETTING UP ADYNAMIC DISTRIBUTED KEY SERVER

UN SYSTEME DE PAIEMENT ELECTRONIQUE MOBILE SECURISE DANS LEQUEL SEULE LA BANQUE DETIENT LA CLE, CODES DE CLE DISTRIBUEE, PROCESSUS DE CLE DISTRIBUEE D'AUTHENTIFICATION UNIDIRECTIONNELLE ET BIDIRECTIONNELLE ET PARAMETRAGE D'UN SERVEUR DYNAMIQUE DE CLE DISTRIBUEE

English Abstract

A single, unique, distributed, private, master key crypto-currency mobile
payment and financial
transaction process whereby an index, offset, or pointer into that unshared
private master key or
a token from that master key is appended to existing banking routing
information for payments
and funds transfer.
Need
There is a particular need for a secure mobile, electronic, secure payment and
money transfer
system where only the bank has the master key, that doesn't change the
existing banking routing
system to any significant degree, and that is easily adaptable to any
framework or financial
transfer systems and can be readily adapted to any other digital context that
requires secrecy like
medical records transfers, id cards, credit card transactions etc.

Claims

Claims
1. A single, private, distributed, exponential master key mobile payment,
funds transfer and
financial transaction system where only the bank or funds issuing entity has a
private, master
key. A token from the Master Key or a cryptographic offset or index value
representing this
token on a Master Key is appended to existing routing information. No key/key
structure
information used to secure and identify a unique transaction representing
value is ever
transmitted or shared between the sender (issuer) and receiver. No key offset
is transmitted in
an unencrypted state, and no key, key structure or pertinent offset
information is stored on a
server in an unencrypted state. The steps attendant in this transaction
entails:
a. Process
1. A transaction is initiated by a computerized or communications enabled
device, or a
mobile device and connects through an interface to an authentication and
encryption financial technology server to initiate a funds transfer. The
amount of
the funds transfer or the quantity and value of a financial instrument, the
sender's
account number and the intended receiver account number is entered or noted at
this time. The receiving account number can be associated with a bank or other
qualified and enabled receiver in any tiered, hierarchical distributed system.
(For
example, a receiving bank may have their own unique, private, distributed key
to
provide a link at the server level of networks.)
2. The transfer request goes to bank authentication server via a device
with
communication and connectivity capabilities.
3. The server identifies whether the requester is one of their own clients
and
authenticates this client using their existing processes and additionally
using unique
identifiers, application keys, or any other authentication factors.
4. The server identifies the client account and determines whether the
initiator has
requisite funds (or credit) or any other additional authorizations to
guarantee the
value of the transaction and/or assure the authenticity and authorization for
any
kind of data transfer.
5. The server creates a unique one-time token or an offset corresponding to
a specific
token of arbitrary length from the unique, private, distributed, exponential
Master
key and appends this value to the traditional banking routing numbers as can
be
found on a check and is illustrated in Fig. 3.
6. The transaction is sent to the receiving party. We will now look at three
scenarios:

7. One scenario is where the receiving party is a bank or financial enabled
institution.
In this case, if the intended recipient is a person or another party, they
will have to
go in, or connect to the receiving bank, and be authenticated by whatever
means
that institution uses for identity proofing whether it is by physical
identification like
showing a driver's license or passport or an electronic means whereby that
institution is using their own accepted authentication and identification
protocols.
8. Once the receiving party is authenticated the transaction is authorized and
authenticated in the following manner (likely during the same connection):
a. An acknowledgement of the funds transfer request is sent to the back to
the sender along with the token or offset provided by the sender and
which was appended to the routing numbers.
b. The bank receives the authorization knowing that the receiver has been
authenticated by other means at the receiving end and compares the offset
and the token it represents, or the token itself, and insures that this
transaction has not occurred yet. If the comparison is valid, this token or
offset is flagged as having been used and is never used again. If the
comparison is not identical or the transaction is redundant then the
transaction is terminated and any forensic information like IP addresses,
purported account, actual comprised account or any other available forensic
information is logged.
c. Final authorization for funds transfer is sent by the bank to the
receiving
party and the transaction is concluded or reason for rejection or transaction
termination is sent with a transaction receipt.
2. A crypto currency scheme whereby the value of the transaction is assured
under
sovereign laws and by the good faith of the issuing institution.
3. A crypto currency scheme whereby each institution, bank or institution
authorized for
funds transfer has their own unique master, private keys and hence has their
own
unique, secure, customizable crypto-currency.
4. A method of creating an authentication and key management server for
dynamic
distributed symmetric key systems (dynamic distributed key infrastructures)
for crypto
currency, funds transfers and banking transactions wherein there are no public
key
asymmetric components and where the server has the following functionalities:
i) the server has a unique, pre-distributed master key that can create an
unlimited
number of keys and tokens and their corresponding current, dynamic starting
offsets;

ii) the server has copies of unique "link keys" between itself and other
servers for secure
communications between networks if any;
iii) the server has copies of all the unique, private secret keys of all the
endpoints, nodes,
and components on the network, if any;
iv) end points never share private secret keys, if any, with any other
endpoints;
v) the server provides continual, dynamic, third party authentication of all
endpoints,
nodes and components on a network and imposes provenance on all data;
vi) the server manages accounts, keys, dynamic offsets, dynamic tokens,
authorizations
and all other network security controls;
vii) the server can transencrypt transmitted data from being encrypted in the
key of the
sender to being encrypted in the key of the receiver;
viii) the server can create an unlimited number of unique, secret, private
keys from its
master key to enable secure, encrypted and authenticated communications
between
endpoints for point-to-point communications and assignation of value and
imposition of
provenance on financial transactions;
ix) the server can create session keys and securely distribute session keys to
new
endpoints without their own, unique, secret, private key in order to
distributed new,
unique, private secret key to new endpoints without first having to physically
copy a
distributed key to an endpoint before being able to enroll the new endpoints
into the
network;
x) the server can perform all key based security controls from a single,
distributed, private
exponential master key for the transaction including secure network access,
continuous
dynamic one-time-pad autilentication and encryption, authorizations,
signature, non-
repudiation, inherent intrusion detection, and automatic revocation;
xi) the server enables secure one-to-one and one-to-many communications.
5. A method in a dynamic distributed symmetric key system called
"transencryption" FIG.
4 where data or a stream from a source (sender) computer that is encrypted in
its own,
unique, secret private key is changed (transcribed, converted, translated)
from being
encrypted in the secret, private key of the sender, to being encrypted in the
unique,
secret private key of the destination (receiver) computer by its
authentication and key
management server and forwarded to the destination computer. See Fig. 16. This
can be

done in a store and forward manner or in a streaming, real-time manner. The
conversion
is bit by bit and the preferred key for this process is a Whitenoise key or
equivalent
symmetric, exponential, stream cipher; but not restricted to that kind of
cipher. This
ensures paradigms where there is never a common key used between endpoints on
a
network.
6. The method of claim 5 wherein said secure encrypted, authenticated
communications
between different independent, secure networks are conducted utilizing pre-
distributed
and pre-authenticated network "link keys" (at a higher tier network level)
comprised of the
following steps:
i) the source and destination computers each have a unique, pre-distributed,
private, secret key and a first valid offset, that is never shared with one
another or another endpoint or node. Only the authentication server has
copies of all the endpoint private keys, its master key, and link keys to
communicate with other networks;
ii) the Sender encrypts data/file to send to a user in an outside network;
iii) the file goes is uploaded to its network server where it is trans-
encrypted from
the Sender's private key to the network link key. The link keys between
networks
are pre-distributed and pre-authenticated and are secret themselves;
iv) the server sends the encrypted data/file to an external network server
which
confirms that it shares a link key with the sending network and that the
intended
receiver is on its network and is authorized to receive the communication. The
receiving server transencrypts the file data from the shared server link key
into
the private key of the intended receiver on that network. If the intended
receiver is not present or authorized the transmission is stopped at the
server;
v) the destination (receiver) computer decrypts the transmission with its
unique
private, secret key There has never been sharing of private keys between
endpoints.
7. A method in a dynamic, distributed, symmetric key systems where session
keys are
generated from a server's unique, private secret master key FIG. 6 in order to
communicate with endpoints that do not yet have their own private/secret key.
The
purpose is to be able to establish secure communications with a new endpoint
or node
without first having to copy a key physically to that endpoint or node as has
been
traditional in distributed key systems. This allows simple scaling of the
network that
facilitates authentication and secure, one-time private, secret key
distribution. It facilitates
the establishment of a secure point-to-point connection between endpoints
without
intercession (transencryption) by the server. The server continues to
dynamically and

continually authenticate the endpoints but no encrypted traffic is passing
through it for
potential capture and is comprised of the following steps:
i) the source computer (sender) sends a request to the authentication and key
management server for a session key;
ii) the key storage server identifying the source computer and locating its
associated private distributed key;
iii) the key storage server generating a unique session key from its unique,
distributed master key for the session in question, and identifying this
session
key by a unique session identifier,
iv) the key storage server encrypting the session key with the source
computer's
private distributed key and sending it, with a session identifier, to the
source
(sender) computer,
v) the source computer (sender) using the source computer private distributed
key to decrypt the session key and using the session key to encrypt the
communication, which is sent to the destination computer (receiver) directly
along with the session identifier;
vi) the destination computer (receiver) receives the encrypted communication
and session identifier and sending a request to the key storage server for the
session key associated with the session identifier session offset,
vii) the key storage server determining from the session identifier or offset
whether it has or can create the corresponding session key, and whether it has
the destination computer's (receiver's) private distributed key;
viii) if the key storage server determines from the session identifier that it
has the
corresponding session key (or offset from which to recreate the session key
from
the master key), and has the destination computer's private distributed key,
the
key storage server encrypting the session key with said destination computer's
private distributed key and communicating it to the destination computer;
ix) the destination computer (receiver) then decrypting the session key using
as
private distributed key and decrypting the communication using the decrypted
session key.
8. A method of claim 1 where the same technique of using a dynamic offset to
be a vector,
pointer or index into a single distributed key stream indicating an unused
portion of a

bank master key ahead in the key stream to authenticate a crypto currency
provenance
and value in a funds transfer or financial transaction.
9. A method of claim 5 creating a current dynamic offset after the conclusion
of a previous
session where the offset is a pointer, vector or index into a specific place
in a key stream
from a single, distributed private, secret key that indicates a unique, unused
portion
ahead in a key stream that has never been created or used before so that it
maintains
one-time-pad characteristics for key based security controls.
10. A method of claim 1 where the next current dynamic offset on the only bank-
held secret,
private, distributed, exponential master key is set for the next crypto
currency transaction
by updating the current dynamic offset on the master key by the length of the
last used
token plus one (or some other mathematical operation) without any key or
offset
exchange.
11. A method of claim 1 where there is stateful two-way authentication where
the server as
well as the endpoint can request and send authenticating segments of data or
offsets.
This means that the endpoint has their own unique, private, secret,
distributed,
exponential key and key generation capability as well as the server.
12. A method of claim 1 where either the server or an enabled endpoint can
perform one way
authentication. One-way authentication means that either the server or the
endpoint
(server/site) has key generation capacity.
13. A method of claim 1 where there is stateful intrusion detection because
both the server
and the offset or token representing authorization and authentication of a
crypto currency
transaction appended to bank routing numbers must be synchronized and never
before
used.
14. A method of claim 13 where there is stateful and automatic revocation when
an
authentication call is not successful because the dynamic offsets or the token
it
represents and is used for the crypto currency transaction are not
synchronized or
equivalent upon comparison. When they are not synchronized or identical or if
it is a
redundant transaction then the transaction is terminated and network access is
blocked.
15. A method of claim 1 where the assignment and monitoring of permissions and
usage
rights for authorization of a crypto currency transaction are accomplished by
using
different indexes and tokens of the single, distributed, private, secret
master key stream
are constructed in the same fashion as authentication.

Any topology or technologies created to provide the highest level of network
security must
address issues of secure key management, key creation, key exchange,
authentication, intrusion
detection, revocation and authorizations. Secure networks must also be able to
assure continual
authentication of all persons, components, and devices on a network as well as
impose
provenance on all data.
There is a need for a key based network security control, protocol, process
and framework where
there is never any transfer of key or offset information during sessions,
after one-time pre-
distribution and pre-authentication of users and endpoints following accepted
identity proofing
techniques for person and non-person entities. There is a need for a system
where there is never a
shared secret transmitted in session, where there is never a public key which
can be factored or
broken because of improved factoring techniques or quantum computing, and
where there is no
reliance on asymmetric key exchange or negotiation which always has security
flaws if used in
isolation. There is a need for large scale, distributed authentication systems
where there is only
partial sharing of credentials.
There is a need to prevent credit card, debit card, and financial online,
electronic fraud as well as
preventing the theft or transmission key and PIN information. There is a need
for security
controls, protocols, and frameworks that overcome the fatal security flaws
attendant with
asymmetric and public key infrastructure key exchange and topology. There is a
need for key
based identity management for person and non-person devices (communication
backbone and
endpoint devices) that comprise our communication networks, smart grids and
critical
infrastructures. There is a need for protocols and network configurations that
eliminate threats
such as man-in-the-middle attacks, side channel attacks, botnet attacks, and
the unlimited
accessible life of data residing in the "cloud" or on the internet.
This particular embodiment provides a system where only the bank or the Sender
party making a
funds transfer has a copy of the private, unique, exponential Master key and
the client or
receiving endpoint never has access to the master key beyond a one-time offset
into an
exponential key to which they have no knowledge or access, or a token from an
exponential key
which is used only one time for the unique transaction and which is of no
cyrptanalytical use in
trying to break the key. Cryptanalysis requires capturing 50% of a key or key
stream. When
using a deterministic random number key generator like the preferred
embodiment using
Whitenoise even using tokens (in configurations using tokens as opposed to
offsets) thousands of
bytes long is insignificant when the master key streams can easily be
quadrillions of bytes long.
The foregoing examples of the related art and limitations related thereto are
intended to be
illustrative and not exclusive. Other limitations of the related art will
become apparent to those of
skill in the art upon a reading of the specification and a study of the
drawings.

Description

CA 02886849 2015-04-07
36 TECHNICAL FIELD
37 The invention relates to the field of security for electronic
communications and in particular
38 mobile, electronic, payment transfer, money transfer, and guaranteed
banking transactions.
39 BACKGROUND
40 The most widely used method for providing security online for
authentication and encryption is
41 using asymmetrical encryption systems of the public key design where
authentication relies on
42 certificates issued by certificate servers. Public Key Infrastructure
(PKI) systems have known
43 security vulnerabilities such as being susceptible to Man-in-the-Middle
[MiM] attacks, because
44 they are often implemented improperly and because public keys are always
available for
45 factoring and because there is always key transfer to initiate a
session.
46 The overhead of the PKI system is high, not just because of all the
steps involved in the
47 architecture, but also their choice of cryptography. The key strengths
used by the PKI have been
48 called into question recently. Public keys are compound primes and they
are always available for
49 attack. There have been significant strides in prime numbers and
factoring theory. New
50 techniques exist to factor compound primes. Fast computers factor compound
primes by
51 simplified techniques like the "sieve" method, so what used to take
years now can be done in
52 hours. Using progressively stronger keys with public key systems becomes
progressively more
53 difficult because of the additional computational overhead introduced as
keys get stronger
54 (longer). Additionally, with the advent of quantum computing all public
keys will be easily
55 factored and broken because of fixed key sizes.
56 SUMMARY
57
58 The security of all crypto systems, whether asymmetric or symmetric, is
determined by key
59 management, key distribution and exchAnge, key storage, and the nature
of the keys, and how the
60 keys are used.
61
62 In this summary, we will look at a unique and inventive key management,
key distribution and
63 exchange, and key storage process. In the description section of this
patent, we will examine an
64 embodiment of this invention using a single, unique, distributed,
private master key where a
65 bank (institution, issuer etc.) initiates a transaction and is the only
party that has a copy of the
66 key in a Sender-Receiver paradigm.
67
68 Additionally, this distributed key can generate session keys, encrypt
and authenticate data,
69 authenticate endpoints and users, and do so without any asymmetric key
exchange or
70 negotiation. Although the preferred embodiment uses Whitenoise Super keys
(patent: Boren

CA 02886849 2015-04-07
71 Brisson 10/299847 granted) or other exponential, one-time-pad keys for
additional key
72 generation (and for all security functions including encryption), the
encryption function may be
73 accomplished with any deterministic random (pseudo random) data source
and any encryption
74 algorithms. Adoption of secure network topologies also relies in some
contexts on its ability to
75 leverage existing technologies. As such, a hybrid approach is disclosed
that utilizes the banking
76 routing system that has been traditionally used.
77
78 An additional preferred embodiment, but not restricted to this, is using
a cloud or hybrid cloud
79 operating system or platform as described in a patents pending by
Timothy S. Vasko
80 Application number: 20130297371 and Application number: 20130132860 as
deployed with
81 a platform such as 1tolReal.
82
83 The following embodiments and aspects thereof are described and
illustrated in conjunction with
84 systems, tools and methods which are meant to be exemplary and
illustrative, not limiting in
85 scope. In various embodiments, one or more of the above-described
problems have been reduced
86 or eliminated, while other embodiments are directed to other
improvements.
87 A dynamic distributed key, identity management, payment and money-
transferring system is
88 provided in which an authentication and key management server manages the
only pre-
89 distributed and pre-authenticated unique, private, master key and
compares dynamic offsets or
90 tokens from the master key without ever transferring that key or key
structure or without ever
91 transmitting a token from an unbreakable key or offset in a secure
encrypted state.
92 In distributed key systems the server has a unique master key and has
copies of all the unique,
93 private, endpoint keys and key structures of network endpoints that are
pre-authenticated and
94 pre-distributed and link keys that are pre-authenticated and pre-
distributed to any other server at
95 a higher network tier to create a "network of secure networks".
96 In this particular single, distributed Master Key system the only party
with a key is the party
97 conducting a financial transaction and guaranteeing the value of such
transactions.
98 Initial key distribution to the financial institution can be conducted
in traditional physical
99 manners. One time key distribution and provisioning can be done
electronically because any key
100 theft, if possible, cannot happen without being detected by dynamic
identity verification and
101 authentication. Furthermore, system keys are inherent and compiled
within any client and server
102 software to further protect this initial, one-time key distribution by
sending them in an encrypted
103 state.

CA 02886849 2015-04-07
104 BRIEF DESCRIPTION OF DRAWINGS
105 Exemplary embodiments are illustrated in referenced figures of the
drawings. It is intended that
106 the embodiments and figures disclosed herein are to be considered
illustrative rather than
107 restrictive.
108 FIG. I illustrates how a Bitcoin transaction works and its dependency
on public key
109 cryptography. ==
110 FIG. 1
.
,
...........
, 4,
1 Nrolito.r. oott
..
- 1 N.A.........
tO 'Or' I or, .
1 t 1' 'µ ' ,1 ' , ', I ='.= r , I . I ,' ' , ( '
'', I r ' ' I..,
Itet +"'"). .,,,, ! .461.0'let dolaroroo
1
, -.' q 1, '' .t. ,f ' ,, L t=( , .
, r r , t ii i g . = I : + '
=
4.
vimitts NI :L."- 4 111;4'4 =.4".=*=*
AND 04 0' _,
-
,1/4.v.p.
ADDRESSES ¨1 ''',:::.õ' A,' si
.= =
ii, onmemawg 'mow
r 04.1,1e., Mit10,41,41
I. rf1011.l. In
.o.o. ant" 4 otgoninoon*c ,. 4Ø4.-
r, 11111* IIIII
/*two se
fkontonn o*niotnn* VAN Inn, inn
On., on
Awl,. xl n I 1 on wag* ...v. ....
, ....0a0ralitwootah.ati
...,1. oo Ma." - -- =-,--- lia Ooro.b. to.
frot000" to to. Atdowootoo., ortut lot WI.. Yeleoo.ott.
(IMAM ' 2' 'le' ft".. So ter,
tor.' ...MOM. ....root ...........
-.
u...........to t tr.
.. 1.,, '24....4 r eigopess ,_ ,
e I 'As- 40,1. ,ont onnialltifinP*410 OW*
nno lonnonno no
*on \ -. - -- -.....- =
Eall /'''
rOnrrrwes
r- Ea , othrooKralo
t1....1.0 ..
toido elo
...if
111DIDERID6 ...--,.. :,...: \ .0-
.004.
&FAME ...coo
..... = = 411h 1 '
- III I ....olk ..1C.Olettmotoy 101
o
..y..õ.....
\--&----)4-- 1.---
..,. .,) lit e oil õ...õ,....
_ ill,id..-- k --I
61001tIA i __
Jr" % ...
I = -
. OP OPronnt
- $ _
VERIFYIN6 Moo., .
INT 11.0 lame oft V.," /
TRANSACTION .olliwOor. $00.14.
,
,,to a".
P00101411...a show.,
-7..,..'..Z.:'
At ""*"' ,,r iRviAnaSAL401011
',..,
.....o.
110 1 , "02..10 tollittl MM.,*
V/AtApttl"..01"... It. m r,
.........twot e= ore.....swv1.-4,..
sin
00,,..4k.400........04,4.1.. 400..mhtm......-.0 le = op = -Ø--4,-
..1111416aTaMwoor lmortirs
MI
4101,1.146414101NNott.4.111.10Z ittrostAVIo...2µ2.42t140.4., r.
Ø1tralatoolit..........o-....to = di, ...
varko, it Ittollev000tet." 5to O.1 o mrtolTlvoolt
" 411""" I ll 11011 I,
111
112 Fig. 2 illustrates typical money transferring process flow. In this
case the process flow of
113 Western Union which has a core business of transferring funds is
illustrated. The guarantee that
114 the transfer has immediate cashable value is provided by a credit card
processing construct.

CA 02886849 2015-04-07
115 FIG. 2
SENDER BUYS A WESTERN
UNION MONEY TRANSFER AT
BANK CHANNEL
ROUTES TO
mom
WESTERN UNION
= .=== Western Union API
05 4 M WESTERN SUBMITS
1
\ID/ UNION AGE TRANSACTION
111 ...
I MasterCard
"Pk. 1-451
CD "ran I
NETWORK
SENDER App. ARID PROCESS
- ratio. lain.1.1.3 BANK TRANSACTION
ONLINE ,
P.IRANCH
0 Bank authenticates Sender. 3 Bank moves funds from 0 Personal
Payments API (;) MasterCard settlement
Sender provides instructions, Senders account to the submits a Send
transaction .,!, moves funds from the Bank
pays for transfer at Bank. Bank's settlement account, to the Western
Union NW to Western Union and
Western Union sets fees and Bank submits transfer to Gateway to
provide payout distributes the commission
FX rate. Personal Payments API
instructions. using modified settlement
process
116 -Product availability and channels vary by country
117 FIG. 3 shows a typical check utilizing a traditional banking routing
scheme. This is illustrated by
118 the series of numbers at the bottom of a traditional check. The last
set of numbers represented at
119 Seraem# represents a token from a single, private, master exponential
key like Whitenoise or an
120 index, pointer or transaction dynamic offset into a single, private,
master exponential key. Both
121 configurations retain critical one-time-pad characteristics because
they are only used once.

CA 02886849 2015-04-07
122 FIG 3
444,4
0401 1
t Jett row. 414'. 0.-41( 31 20 / 4
I
=
N,v04. tte.4 0,0t, d *.x.*40
Owe 1 ;.4õ Aet,õi
1 4111,04,' t:=444 I 441 5
:#11= ). .t 6: It.
2100021 0001 I 234367t0 Seraem# 947857567600505857474739303
I
Same RBC routing numbers that have been RBC brand Seraem-coin token
used for a hundred years.
123
124
125 In addition to the exemplary aspects and embodiments described above,
further aspects and
126 embodiments will become apparent by reference to the drawings and by
study of the following
127 detailed descriptions.
128 Throughout the following description specific details are set forth in
order to provide a more
129 thorough understanding to persons skilled in the art. However, well
known elements may not
130 have been shown or described in detail to avoid unnecessarily obscuring
the disclosure.
131 Accordingly, the description and drawings are to be regarded in an
illustrative, rather than a
132 restrictive, sense.
133 FIG. 1 illustrates the Bitcoin process.
134 FIG. 2 illustrates the traditional Western Union-type funds transfer.
135 FIG. 3 illustrates a traditional check used by banks and the bank
routing system with our
136 invention.

CA 02886849 2015-04-07
137 FIG. 4 illustrates the simplest kind of secure distributed key
infrastructure handshake.
138 FIG. 5 illustrates a secure distributed key handshake that creates one-
time session keys.
139 FIG. 6 illustrates a typical public key handshake
140 FIG. 7 illustrates a typical mathematical function used in public key
handshakes.
141 FIG. 8 illustrates how a Whitenoise key in the preferred embodiment is
created and its one-way
142 functions.
143 FIG. 9 illustrates how the length and Arength of the preferred
embodiment Whitenoise key is
144 calculated,
145 FIG. 10, 11, 12, 13 and 14 illustrate how the preferred embodiment of
Dynamic Identity
146 Verification and Authetication is used for identity proofing,
authentication, intrusion detection
147 and automatic revocation as described in (BRISSON Patent #13/764,586)
148 Description
149 Bitcoin is a cryptographic, crypto currency process. Because it
requires public key, asymmetric
150 processes it is by definition vulnerable and breakable.
151 The Bitcoin crypto currency process does not address the issue that
currency is a sovereign value
152 proposition where the value of funds is guaranteed by the ability of a
government to tax. It is at
153 odds with the entire global financial system and tries to circumvent
it.
154 In what follows key management, key distribution and exchange, key
storage, and how the keys
155 are used will be examined..
156
157 This invention can be used in any tier of network "architectures
traveling from IF to JP, whether
158 from computer to computer, or alternatively, from network to network,
or computer to network,
159 and wired-to-wired, wireless-to-wired, and wireless-to-wireless. The
system is able to plug
160 anywhere into a network.
161 Note is that traditional Western Union-type funds transfers are
underpinned by a credit card
162 network. This is the tie to the existing (milking system and it is a
step where additional costs are
163 incurred. However, it works within the existing Financial Tech
infrastructures and frameworks.
164 In this case, it is the credit card network that is assuring the value
of the transaction.
165

CA 02886849 2015-04-07
166
Using a single, private, master key system can allow the bank (institution or
party), without risk,
167
to assume the role of a guarantor can guarantee the transaction and take the
role that a credit card
168
network is doing in the Western Union example. Furthermore, they can cover
themselves with
169 traditional banking insurances like FDIC.
170
In the following embodiment, the bank or money transferring institution know
assures the value
171
of the transaction because it emanates from their bank or institution which is
the only party with
172
a key and from one of their clients for which they have knowledge of available
funds for the
173 transaction.
174
The system stays the same in overall framework structure but the bank retains
their first in line
175
place with their banking client and gain arm's reach potential clients in the
persons that are
176 having money transferred to them regardless of where they are banking.
177
Instead of changing the bank system, adding a Whitenoise offset (preferable)
or any other offset
178
for a single, private key system, or adding a unique one-time token to the
traditional routing
179
numbers enables a secure crypto payment process. Each transaction and every
Whitenoise key
180
(token) and offset is unique and secure. Everything moves the same way it
always has. But, since
181
the offset or token is appended to traditional routing numbers the bank
processing system can
182
immediately recognize it as a unique electronic transfer that is valid. The
current offset value
183 and/or token is just another field(s) in their databases for their
clients.
184
Each bank can have their own branded mobile payment because the each have
their own unique,
185
private master key and the ability to generate tokens and offsets. Any bank
can receive such a
186
transfer and there is no waiting ¨ it can be cashed on the spot because it is
guaranteed by the
187 bank originating the transaction and they can determine it hasn't been
compromised.
188 Process
189
190
The initial and only master key distribution to bank happens only one time in
a secure fashion.
191
The bank or institution also is securely provided a key or token generator for
the distributed,
192
unique, private, exponential master key. These can be distributed physically
or securely
193
electronically with technologies such as Dynamic Identity Verification and
Authentication
194 (DIVA).
195
1. A transaction is initiated by a computerized or communications enabled
device, or a
196
mobile device and connects through an interface to an authentication and
encryption
197
financial technology server to initiate a funds transfer. The amount of the
funds transfer
198
or the quantity and value of a financial instrument, the sender's account
number and the
199
intended receiver account number is entered or noted at this time. The
receiving account
200
number can be associated with a bank or other qualified and enabled receiver
in any

CA 02886849 2015-04-07
201
tiered, hierarchical distributed system. (For example, a receiving bank may
have their
202 own unique, private, distributed key to provide a link at the server
level of networks.)
203
204
Note, in this part of the description we are authenticating the transaction.
205
Additionally layers can be added to authenticate the receiver, the receiving
bank
206
or any other parties in different configurations and are obvious and well-
known to
207
persons knowledgeable in cryptographic processes. Additional networks security
208
controls like intrusion detection and automatic revocation are inherent with
this
209
technique. Additional security controls like signature and non-repudiation can
be
210
enable with this same key or by additional technologies. We will subsequently
211
look at two distributed key handshakes if additional layers of authentication
and
212 security are used.)
213
2. The transfer request goes to batik authentication server via a device with
communication
214 and connectivity capabilities.
215
216
3. The server identifies whether the requester is one of their own clients and
authenticates
217
this client using their existing processes and additionally using unique
identifiers,
218 application keys, or any other authentication factors.
219
220
4. The server identifies the client account and determines whether the
initiator has requisite
221
funds (or credit) or any other additional authorizations to guarantee the
value of the
222 transaction and/or assure the authenticity and authorization for any
kind of data transfer.
223
224
The server creates a unique one-time token or an offset corresponding to a
specific token of
225
arbitrary length from the unique, private, distributed, exponential key and
appends this value to
226
the traditional banking routing numbers as can be found on a check and is
illustrated in Fig. 3.
227
Appending a offset value to a routing number has no negative affect at routing
with existing
228 system.
229 5. The transaction is sent to the receiving party. We will now look at
three scenarios:
230
231
6. One scenario is where the receiving party is a bank or financial enabled
institution. In this
232
case, if the intended recipient is a person or another party, they will have
to go in, or
233
connect to the receiving bank, and be authenticated by whatever means that
institution
234
uses for identity proofing whether it is by physical identification like
showing a driver's
235
license or passport or an electronic means whereby that institution is using
their own
236 accepted authentication and identification protocols.
237

CA 02886849 2015-04-07
238
7. Once the receiving party is authenticated the transaction is authorized and
authenticated
239 in the following manner (likely during the same connection):
240
241
a. An acknowledgement of the funds transfer request is sent to the back to the
242
sender along with the token or offset provided by the sender and which was
243 appended to the routing numbers.
244
b. The bank receives the authorization knowing that the receiver has been
245
authenticated by other means at the receiving end and compares the offset and
the
246
token it represents, or the token itself, and insures that this transaction
has not
247
occurred yet. If the comparison is valid, this token or offset is flagged as
having
248
been used and is never used again. If the comparison is not identical or the
249
transaction is redundant then the transaction is terminated and any forensic
250
information like IP addresses, purported account, actual comprised account or
any
251
other available forensic information is logged. The offsets on the bank master
key
252
can be updated to a new, unused section of its key stream but the length of
the
253 token used plus one or an alternate arithmetic technique.
254
c. Final authorization for funds transfer is sent by the bank to the receiving
party and
255
the transaction is concluded or reason for rejection or transaction
termination is
256 sent with a transaction receipt.
257
It is important to note in this scenario which is the least burdensome to a
receiving party
258
that the overall transaction likely will be further protected by another
existing encryption
259
scheme like Secure Socket Layer (SSL) that is already part of the existing
framework.
260
However, even if the transaction was conducted in an unencrypted state, using
261
Whitenoise superkeys, means that a token is random and is so small relative to
the
262
sender's secret, distributed, private, exponential master key that it is of no
use
263
cyrptanalytically to break the master key (and the receiver has been
authenticated and
264
identity proofed at the other end.) It is further secure because it is a one-
time-pad process
265 which is the only mathematically provable unbreakable key based
system.
266
Similarly, if an index is used for the funds transfer there is no information
to the
267
receiving party (or hackers) of the number of subkeys (at the bank) used to
create the
268
Whitenoise master key, the length and order of the subkeys used to create a
Whitenoise
269
master key, or of the random data (it is not a counter or line feed shift
register) that is
270 used to populate those subkeys of the master key structure.
271
272
8. Another scenario with an additional layer of security is one where the
final receiver is "in
273
the system" and has their own, unique, distributed, private, exponential key.
In this
274
configuration that receiver can be authenticated by additional techniques,
handshakes and
275 processes described below.
276

CA 02886849 2015-04-07
277
9. Another scenario is one where a transfer is made directly to an end user
device (i.e. a
278
person receiving their paycheck) and then that person and device can be
identified with
279
whatever level of identity proofing or anonymity that the institution
"cashing" the
280 instrument requires by an additional separate process.
281
Secure distributed key handshakes are a preferred embodiment to be used in
conjunction with
282
this invention. The payment and funds transfer process described above is a
single key, one way
283 authentication system.
284
It is anticipated to those familiar with cryptographic arts that there will be
contexts where
285
additional security layers, tiers, and key functions will be used. All
contexts and key based
286
security controls can easily be provide.:-I, from a dedicated authentication
server that can perform
287
two-way stateful authentication, encryption, signatures, inherent intrusion
detection (the keys in
288 a dynamic distributed key system must be synchronized.)
289
In symmetric, dynamic, distributed key systems the server has copies of all
the keys on a system.
290
The keys are stored in an encrypted state. The keys are always kept separate
from the last current
291 dynamic offsets.
292
Each endpoint has only its unique, distributed, private/secret key. Secret
keys are NEVER shared
293
between endpoints. There is never key or offset exchange after setup. The
following illustration
294 shows a system in its simplest configuration.
295 These authentication and network security servers would have the
following characteristics:
296
1. A method of creating an authentication and key management server for
dynamic distributed
297
symmetric key systems (dynamic distributed key infrastructures) wherein there
are no public key
298 asymmetric components and where the server has the following
functionalities:
299
i) the server has a unique, pre-distributed master key that can create an
unlimited
300 number of keys;
301
ii) the server has copies of unique "link keys" between itself and other
servers for
302 secure communications between networks;
303
iii) the server has copies of all the unique, private secret keys of all the
endpoints,
304 nodes, and components on the network;
305 iv) end points never share private secret keys with any other
endpoints;
306
v) the server provides continual, dynamic, third party authentication of all
endpoints,
307 nodes and components on a network and imposes provenance on all
data;

CA 02886849 2015-04-07
308 vi) the server manages accounts, keys, dynamic offsets, dynamic
tokens,
309 authorizations and all other network security controls;
310 vii) the server can transencrypt transmitted data from being
encrypted in the key of
311 the sender to being encrypted in the key of the receiver;
312 viii) the server can create an unlimited number of unique,
secret, private keys from its
313 master key to enable secure, encrypted and authenticated
communications between
314 endpoints for point-to-point communications;
315 ix) the server can create session keys and securely distribute
session keys to new
316 endpoints without their own, unique, secret, private key in order
to distributed new,
317 unique, private secret key tc new endpoints without first having
to physically copy a
318 distributed key to an endpoint before being able to enroll the
new endpoints into the
319 network;
320 x) the server performs all key based security controls from a
single pre-distributed
321 key for each endpoint including secure network access, continuous
dynamic one-
322 time-pad authentication and encryption, authorizations,
signature, non-repudiation,
323 inherent intrusion detection, and automatic revocation;
324 xi) the server enables secure one-to-one and one-to-many
communications.
325

CA 02886849 2015-04-07
326 A simple distributed key handshake
327
328 FIG 4
Direct point-to-point process in symmetric, distributed key systems.
õ,----
Whitenoise DIVA Dynamic Distributed Key Authentication
Server
______________ ,
Server has 1
copies of all
keys on
I nisel
:kke
r ver
ha ys
system- )1\ E, ___, _______ ,_
l
PpkAks 7
,4 2
' The server transencrypts
Etc (translates)the ,
' message in real-time from being encrypted in
f / pkA to beir.ig encrypted in pkB and passes rt
/ through to 'Er. ,1/4 servers at
higher levet
_____________________ 1 ___________________________________________
I + = ,
i
-,
1 3
_
,
=
Source "A' with ,' Destination "Ir
,
unique private key
i decrypts the
pkA encrypts file message with its
and sends to , private key Privew
server for delivery keys have never
to "S" been shared
329 -- _....
330
331 In this invention, only the bank has the unique, private, distributed,
exponential master key.
332 Links 1 and 3 can be secured with this technique as an additional layer
of security or the entire
333 transaction can be conducted using additional security controls like
Secure Socket Layer.
334 A simple distributed key handshake would be comprised of the following
steps illustrated in
335 FIG. 4.
336 A distributed key session key creation handshake
337
338 It may be desirable to be able to generate session keys in order to
communicate with endpoints
339 that do not yet have their own private/secret key. The purpose is to be
able to establish secure

CA 02886849 2015-04-07
340
communications with a new endpoint without first having to copy a key
physically to that
341
endpoint as has been traditional in distributed key systems. This allows
simple scaling of the
342
network. It facilitates authentication and secure, one-time key distribution.
It facilitates the
343
establishment of a secure point-to-point connection between endpoints without
intercession
344 (trans-encryption) by the server. The server continues to dynamically and
continually
345 authenticate the endpoints but no encrypted traffic is passing through
it for potential capture.
346 FIG. 5
347
Session Key creation and handshake for symmetric, distributed key systems.
Whitenoise DIVA Dynamic Distributed Key Authentication .
Server I
....
Server has,.1 , Server has unique
copies quit 4 2 -The server creates a session key with its master
key and gives it a .; master key to
keys on '',' session key identifier. It locates A's unique,
private key and identify itself and
,
system: authenticates A. "The se rver e nc rypts the session
key with A's private ,' make keYsJt hos
t link keys to other
I- ' key and sends the encrypted session key and the
identifier backto A.
PkA The private secret key is n eve rshared with another
endpoint.The servers fer secure !
pkB ..
;,õ communications :
,.1 only arit hmetic function used is X-Or, the fastest fu nction on a
at the server level.
Etc.
II computer. ,v, .
...... ','
\\, ' . i ' 5. The session
key is encrypted with pke. and sent back to "13". ., .
Imo 2 5
\7,-'r,,
4N\ \\:\
./
\ \, \
N. ,õ .,.,
/ /' \ \
.1. , \ \ \ '1
/ with unique
private
( key pkB
requests
Source "A with \ session key
end sends \
unique private key \ 3 itlfa rthfier.
1
pkA requests link ;
with "Er r 6- 'Er decrypts
i
/ session key with pk6 /
,
and then decrypts /
348 ,-----.'"/ 6
message, ,-
349
3

CA 02886849 2015-04-07
350 This provides a method of sending a secure encrypted communication
between a first source
351 computer through an authentication and key management server to a
second destination
352 computer, comprising the following steps when the server has already
provided the source and
353 destination computers each with a unique, private, secret distributed
key and a first valid
354 offset.
355 i) the source computer (sender) sends a request to the authentication
and key management server
356 for a session key;
357 ii) the key storage server identifying the source computer and locating
its associated private
358 distributed key;
359 iii) the key storage server generating a unique session key from its
unique, distributed master key
360 for the session in question, and identifying this session key by a
unique session identifier;
361 iv) the key storage server encrypting the session key with the source
computer's private
362 distributed key and sending it, with a session identifier, to the
source (sender) computer;
363 v) the source computer (sender) using the source computer private
distributed key to decrypt the
364 session key and using the session key to encrypt the communication,
which is sent to the
365 destination computer (receiver) directly along with the session
identifier;
366 vi) the destination computer (receiver) receives the encrypted
communication and session
367 identifier and sending a request to the key storage server for the
session key associated with the
368 session identifier session offset;
369 vii) the key storage server determining from the session identifier or
offset whether it has or can
370 create the corresponding session key, and whether it has the
destination computer's (receiver's)
371 private distributed key;
372 viii) if the key storage server determines from the session identifier
that it has the corresponding
373 session key (or offset from which to recreate the session key from the
master key), and has the
374 destination computer's private distributed key, the key storage server
encrypting the session key
375 with said destination computer's private distributed key and
communicating it to the destination
376 computer;
377 ix) the destination computer (receiver) then decrypting the session key
using its private
378 distributed key and decrypting the communication using the decrypted
session key.
379 For comparison, let's look at the complexity of a typical asymmetric,
public key process and key
380 exchange handshake.

CA 02886849 2015-04-07
381 FIG. 6
1. akkid sends Kryptotrif
ocliontowie message
traltrastruc ter*
-
lierver asrads
e
olletvstrisett* reessilee 0
3.1terver seeds Its certificate
Server request* s
6 caret** eratilicate
=
CiTent's 5 S. Ciiset tristiesifts terrine***
Server** Certificate located
Certificate
Weide Kryptetel's intra%fructure
- S. Client wet*
SessionN marstOwyuctorintas tomes,
Key s
Servers
Server's Private My
Public Key 'l\\..õ
DieltsI
Ermines*
elfteuel".11"6"."1"4"******orsoss.,,
COaret sands w "Ma Session Key
VertnteateVerter ittessase
OS 7
D_ Signater*
8 $. Mont and Som., imehaftipt 8
Cl ?triremes* as
Seth seed
9 *filahrbeir rneeescees 9
382
383
384 The complexity of public key systems is further aggravated by the very
intensive mathematics
385 required. It requires so much overhead in power, space and
computational resources that it is
386 literally unusable in many environments including the Internet of
Everything where the majority
387 of networked components operate under restrictive environments.
388
389 This is one mathematical technique for creating an asymmetric, public
key session key. By
390 comparison, after key load, the only operation used by DIVA and DDKI is
X-Or. The either-or
391 function is the fastest function available on a computing device.
392
393

CA 02886849 2015-04-07
394 FIG. 7
Diffie Heilman Key Exchange
Alice Evil Eve i Bob
AM.*d 114:4. sachem; (on n,p,,:,:norateri3 annr Mixt,
ty, Ev. woe = moo and Ike *atm:1,174.Z1070itlerpirl kat
43.7,P411
.7 P.. II G.7.0* If
swot = Alice geneinles'a'random number: XA Bob generates' irandom
number Xe
XA=6.LSecret) 1 . Xe=9 (SecreiL
YA=GxA(niod P) YB=Gx(mod P)
Sudo YA = (jj,r I Y. r (mod
11)
t si,1 Eve
SW3 Alic'e receives 8rr-:1;;;:text Bob
receiv-s Y, 4 in dear text
B
Secret Key =Y8x4(mod P) Secret Key =YA;(mod P)
1*d 4 Secret Key fr (mod 11) Secret Key e (mod 11)
r Secret Key = 3 4rSecret
Key = 3
395
396 The security of public key systems has always been fatally flawed. They
can never prevent Man-
397 in-the-Middle attacks and a host of other attack classes. In the past,
computers were so slow that
398 none of the attacks were considered feasible. Now computers are so fast
it is simple to ravage our
399 networks because of lack of sustainable identity and data provenance
and easily compromised
400 security processes.
401 Whitenoise superkeys are the preferred technologies to be used with
this invention but the
402 process is not restricted to their use. We will first review how a
Whitenoise key is constructed
403 and its one-way functions (Whitenoise Super keys (patent: Boren Brisson
10/299847
404 granted).
405 Whitenoise superkey creation
406 One distributed Whitenoise key creates an infinite number of one-time-
pads and handles all
407 network security controls.
408 Whitenoise is a deterministic random number generator creating
deterministic key streams of
409 unlimited length that are orders of magnitude more random then radio-
active decay.
410 A Whitenoise key is built from a variable number of prime number length
sub-keys which roll
411 out horizontally to create the data source. Each bit from the data
source is XOr'd with the

CA 02886849 2015-04-07
412 corresponding bit of the next subkey in a vertical fashion to create
the first key stream. This
413 ensures that it is not operating like a line feed shift register or a
counter and makes it bit
414 independent.
415 FIG. 8
Whitcnoise Architecture =
. 1 . .1 = variable number of
prime
. ' Subkeyk loop infinitely number
length subkeys
= each bit is XOr'd with the
vok bftha indepen4kuu and EAST corresponding bit of the
next subkey
supvrEty tk larger thah the data * two bytes worth are
appended together and
hatatuta !Stets! testhlealtures
run through an S-box
1.4
. . = it becomes first byte
of
. , 1 lq.,ert1 P.t - 1/4stafec, 4,t ram .1111 co.1
de4inearized key stream
break stream up- process and ransoltil shnuttanthasty th channels - tetett
416
417 To delinearize this stream, two bytes worth from the initial key stream
are appended together and
418 run through an S-box. Only one byte emerges. That becomes first byte of
the delinearized key
419 stream which can then be used for any cryptographic purpose.
420 This creates several one-way functions. A hacker cannot go backwards
and guess two bytes of
421 key stream from one byte of captured information. The hacker has no
knowledge of the number
422 of subkeys in the data source, their lengths or the random data they
are populated with. Further, it
423 is used as a one-time pad in the DIVA protocol and a one-time pad is
the only mathematically
424 proven unbreakable key technology.
425 FIG. 9
= two bytes are taken from the
Whitenoise Delinearization initial key stream, appended
together and pushed through
an S-Box
Path Sat schemata* byte
= only one byte emerges
P est byte al likasso oasr psint(she firs byte ii. thia
(ç,)
V The iddrest P-3 is s whim theme dame byes mayhem t. a hacker cannot go
backwards and guess two
sf Misdates, PAO!, aiWimst co-Firsle ammo sit sots bytes insy he P3 bytes
of key stream from one
byte of captured information
=
the Nolter has no
r=-ka, irair knowledge (lithe number of
ikecoefoi-
2. sub keys. thew lengths or the
random data they are
.; populated with
pow".
= it is a one-time pad
426

CA 02886849 2015-04-07
427
428 One-time-pads have three characteristics:
429 1. The keys are larger then the data to be encrypted or monitored.
430 2. The keys are random.
431 3. The keys are never used more than one time.
432 David Wagner of the University of California, Berkeley did a security
analysis of a deployment
433 of Whitenoise and wrote:
434 "With the recommended parameters, Whitenoise uses keys with at least
1600 bits randomness.
435 Exhaustive search of 1600 bit keys is completely and absolutely
infeasible. Even if we
436 hypothesized the existence of some magic computer that could test a
trillion-trillion key trials per
437 second (very unlikely!), and even if we could place a trillion-trillion
of these computers
438 somewhere throughout the universe (even more unlikely!), and even if we
were to wait a trillion
439 trillion years (not a chance!), then the probability that we would
discuss the correct key would be
440 negligible (about 1/2 to the 1340 power which is unimaginably small).
Hence, if keys are chosen
441 appropriately and Whitenoise is implemented correctly, exhaustive key
search is not a threat."
442 "After careful security analysis, I was unable to find any security
weaknesses in the Whitenoise
443 stream cipher. Whitenoise resists all of the attack methods I was able
to think of. This provides
444 evidence for the security of Whitenoise."
445 How do we calculate the length and strength of a Whitenoise key?
446 FIG. 10
A quick look at the multiplicity
= the length of a Whitenoise
key I by
length of the
subkeys in bytes..
7
i . 41.111
I 1 .
'the streirth of a Whitenoise
L.
key Ls calc',:,i=tAl by adding
..............
the lenspr, (-4 the subkeys in
17
If +ft reweeqely the he*, of else ve.steleey., ,64, too lbw win 10 bytes
and multiplying by 8 bits
õ.. . aggey...4 lb* embliesi mimeo, *void mos& ie. = key
Per bYre-
õõõ.
LI 9 = 1 sitorkuumooptas kw* 0/0 001, 00010. S. *Ws
¨ ......,..
ol'i01goud ergy meleememediele fleece iscekoteeeme armee.) en ardor le
r 2 3 egeonmille 4i. ey to create a key> 100
bilhon
bytes long, we only have to
The tell lelettisele of the . rwAeldoied try mieivra Awe key
27 fere Smythe gad 1.10444)011.0
by II bees pee lay* store 158 bytes of information
........,.,õ
29
447

CA 02886849 2015-04-07
448 The length of a Whitenoise key is calculated by multiplying the length
of the subkeys in bytes.
449 Multiplying the 10 smallest prime numbers together to form the smallest
Whitenoise key
450 possible would create a key stream greater than 100 billion bytes long.
And, we only have to
451 store 158 bytes of key stream information (like DNA) to exactly
recreate this key.
452 The strength of a Whitenoise key is calculated by adding the lengths of
the subkeys in bytes and
453 multiplying by 8 bits per byte.
454 How does diva work?
455 The fundamental characteristic of Dynamic Identity Verification and
Authorization and the
456 different functions it serves is the ability to generate and compare
tokens ahead in the key stream
457 that have never yet been created or used.
458 These and other similar DIVA techniques are ideal for identity
verification, secure network
459 access, continuous dynamic authentication, authorization, signature,
inherent intrusion detection
460 and automatic revocation.
461 Both server and endpoint have a copy of the account identity management
key. The server sends
462 a request to the endpoint for an identification token of a specific
length. It is not sending across
463 either an offset or a key with this request.
464 FIG. 11
Both server and endpoint have a copy of the account identity management key.
The server sends a request to the
endpoint for an identification token of a specific length, in this case twenty-
five bytes. It is not sending across
either an offset or a key with this request.
Last valid offscL? Device state la
22 IF CD FE FA 17 F2 BE A5 FO 8A El 55 D6 DD 36 13 73 E2 9A65 2F F6 EA71 FE F7
D7 88 26, 5D 26 0B93 64 1603
The key stream is a minimum of 106 bytes in length. We are continuously and
dynamically comparing tokens to
insure the correct identity of the network user. A token is an unused segment
of key stream of an arbitrary length.
It is random and has the equivalency of being encrypted ¨ it cannot be guessed
or broken and it is only used once.
The endpoint replies by sending a 26-byte token beginning at its last valid
offset.
Last valid offset plus token
Device state lb
22 1F CZ FE FA17 F2 BEA5 FOI3AE1 55 D6 DD 36 13 7.3 E2 9A 65 2F F6 EA 71 FE F7
D7 80 26 5D 26 Ilf3 93 64 16 03
length =Mbytes This 4 arbitrary and scalable depending on security
requirements.
465
466 We are continuously and dynamically comparing tokens to insure the
correct identity of the
467 network user. A token is an unused segment of key stream of an
arbitrary length. It is random
468 and has the equivalency of being encrypted ¨ it cannot be guessed or
broken and it is only used
469 once.

CA 02886849 2015-04-07
470 The endpoint replies by sending a token beginning at its last valid
offset. Server authenticates the
471 user/device by comparing the received token bit-by-bit to the token
generated at the server for
472 this account/person/device beginning at its last current dynamic offset
for this key. If they are
473 identical then the Server acknowledges by sending authorization without
sending either key or
474 offset information. Both server and endpoint update dynamic offset
independently. The system is
475 synchronized for the next continuous authentication query. The account
is automatically locked
476 if the comparison of tokens fails.
477 FIG. 12
DIVA dynamic update of Offset
Server authenticates user/device by comparing the received token bit-by-bit to
the token
generated at the server for this account/person/device. If they are identical
then the
Server acknowledges by sending authorization
Both server and endpoint update dynamic offset independently
Last offset New offset = last offset + token
+ 1
22 1F Ca FE FA 17 F2 flEA5 FO BA El 55 D6 DD 36 13 73 E2 9A 65 2F F6 EA71 FE
FT D7 Be 28 5D 26 BB 93 64 16 03
k \length 25 bytes This is arbitrary end scalable depending on securfty
requirements}
-
The system is synchronized for the next continuous authentication query.
The account is automatically locked if the comparison of tokens fails. This
would
happen if someone has copied a key and the offsets are not synchronous.
478
479 DIVA encompasses the following abilities: stateful two-way and one-way
authentication. Two-
480 way authentication means that each endpoint can request and send
authenticating segments of
481 data or offsets. This means that each endpoint has key generation
capability. One-way
482 authentication means that only one endpoint (server/site) has key
generation capacity. The server
483 then writes back to the endpoint subsequent segments of key stream data
that have not yet been
484 used (and delivers this data chunk securely or otherwise)*. On the next
session, the server/site
485 compares the actual data at the endpoint to the data they can generate
using the endpoint's key
486 structure and current offset.
487 With DIVA, the key stream is polled throughout the session to
continually identify and verify
488 that the correct user is on the network. It is possible to incorporate
transmission of session keys,
489 use of time stamps, biometrics etc. to increase the security of initial
network access (login).
490 DIVA has stateful detection. The offsets of the key streams must remain
in sync between the
491 endpoint and the server. If an interloper manages to steal a key, or
gain network access, then the
492 offsets between the server, the legitimate endpoint, and the interloper
become out of sync.
493 There are only two outcomes:
494

CA 02886849 2015-04-07
495 The legitimate owner uses his key/card/device first and the segment of
random key data (or
496 offset) is updated on the legitimate card. The thief then uses the
stolen key /card and it won't
497 process because the data segment (or offset) does not match between the
stolen key /credit card
498 and the server. The account is immediately disabled.
499
500 FIG. 13
100% accurate ¨ only two DIVA outcomes
Someone tries to steal a key.
44.
The legitimate user logs back onto the network first 4.
" = The legitimate key and server offset
dynamically updates
with this use independently.
Rai' U,/' = The pirated or spoofed key (if possible)
is no longer
synchronized with the server and the legitimate key.
= The pirate will be detected if he makes a login attempt
taw mow 13msso
= The pirate can't access network. Stolen copy is useless.
=11 = No theft has occurred.
This is the only outcome we have ever seen.
501
502

CA 02886849 2015-04-07
503 2) The thief uses the stolen key/card first successfully. The next time
the legitimate key owner
504 tries to access the network they are refused because the stolen
card/device has been updated with
505 a new offset or segment of data, the offset on the server database has
been updated, but not
506 segment of data or offset on the legitimate card/device. Theft has been
identified. The account is
507 immediately disabled. Where the theft occurred is known because of the
previous transaction.
508 FIG. 14
2. The pirate somehow steals a key and logs on first
= The offset at the server and pirated key updates with this use.
= The legitimate key is no longer synchronized with the server.
= The next time the legitimate owner logs onto the secure network, the
server
recognizes that the offset is no longer synchronized because of the pirated
Gotcha Hacker!
key.
= The account is automatically locked.
= System Administrator and client know that their account has been
accessed.
= The logs know the exact duration of the event and the exact transactions
within that time beginning at the last time the server and client were
synchronized and ending at the point in time when the account was locked.
= The pirate I P address is known for law enforcement use.
509
510 DIVA has automatic revocation. The inherent intrusion detection is
simply continuing to monitor
511 that offsets and key segments (tokens) always remain in sync. This is a
simple comparison of
512 offset numbers or sections of random data. Without any human
intervention, the instant out of
513 sync offsets are detected then the account is frozen and that key is
denied network access. It does
514 not require going to outside parties, revocation lists etc. A system
administrator can remediate or
515 deal with any situation without worry of continued or ongoing
malfeasance
516 DIVA/Whitenoise can perform authorization and DRM. The assignment and
monitoring of
517 permissions and usage rights are accomplished by using different
portions of the key stream in
518 the same fashion as authentication.
519 DIVA prevents all known cyber attack classes
520 = Man-in-the-Middle attacks are prevented because there is no key
exchange.
521 = Side Channel attacks are prevented because all operations are order
1 after key load and
522 because there is no access to the key.
523 = Mathematical and factoring attacks are prevented because keys are
created by a binary
524 mechanical process as opposed to arithmetic ones requiring
multiplication and mods.
525 = Botnet attacks are prevented by configuration with server so the
botnet never has access
526 to all the key material to authenticate data being sent OUT of a
network or computer.

CA 02886849 2015-04-07
=
527 = Brute force attacks are not feasible with the continually changing
dynamic offsets.
528 = Denial of service attacks can be prevented by exploiting unbreakable
identity and a proxy
529 for secure network access so that hackers could never get on a
network.
530 = Quantum computing attacks are prevented because every variable can be
variable.
531 Dynamic Distributed Key Infrastructures (DDKI) and Dynamic Identity
Verification and
532 Authentication (DIVA) are very flexible while remaining secure and
allow for context and goal
533 specific configuration.
534 This invention is a Dynamic Distributed Key system.
535 There are no public key elements.

Representative Drawing