CA2886849A1 - 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 a dynamic distributed key server - Google Patents

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.

Description

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.

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.

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.

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.

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 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.

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.

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.

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 , -.' 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, 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.

115 FIG. 2 SENDER BUYS A WESTERN
UNION MONEY TRANSFER AT
BANK CHANNEL
ROUTES TO
mom WESTERN UNION
= .=== Western Union API

\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.

444,4 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.

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.

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..

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.

Using a single, private, master key system can allow the bank (institution or party), without risk, to assume the role of a guarantor can guarantee the transaction and take the role that a credit card network is doing in the Western Union example. Furthermore, they can cover themselves with 169 traditional banking insurances like FDIC.

In the following embodiment, the bank or money transferring institution know assures the value of the transaction because it emanates from their bank or institution which is the only party with a key and from one of their clients for which they have knowledge of available funds for the 173 transaction.

The system stays the same in overall framework structure but the bank retains their first in line 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.

Instead of changing the bank system, adding a Whitenoise offset (preferable) or any other offset for a single, private key system, or adding a unique one-time token to the traditional routing numbers enables a secure crypto payment process. Each transaction and every Whitenoise key (token) and offset is unique and secure. Everything moves the same way it always has. But, since the offset or token is appended to traditional routing numbers the bank processing system can 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.

Each bank can have their own branded mobile payment because the each have their own unique, private master key and the ability to generate tokens and offsets. Any bank can receive such a 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 The initial and only master key distribution to bank happens only one time in a secure fashion.

The bank or institution also is securely provided a key or token generator for the distributed, unique, private, exponential master key. These can be distributed physically or securely electronically with technologies such as Dynamic Identity Verification and Authentication 194 (DIVA).

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 202 own unique, private, distributed key to provide a link at the server level of networks.) Note, in this part of the description we are authenticating the transaction.

Additionally layers can be added to authenticate the receiver, the receiving bank or any other parties in different configurations and are obvious and well-known to persons knowledgeable in cryptographic processes. Additional networks security controls like intrusion detection and automatic revocation are inherent with this technique. Additional security controls like signature and non-repudiation can be enable with this same key or by additional technologies. We will subsequently look at two distributed key handshakes if additional layers of authentication and 212 security are used.)

2. The transfer request goes to batik authentication server via a device with communication 214 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, 218 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 222 transaction and/or assure the authenticity and authorization for any kind of data transfer.

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 key and appends this value to the traditional banking routing numbers as can be found on a check and is illustrated in Fig. 3.

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:

6. 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 236 accepted authentication and identification protocols.

7. Once the receiving party is authenticated the transaction is authorized and authenticated 239 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 243 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. The offsets on the bank master key 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.

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 256 sent with a transaction receipt.

It is important to note in this scenario which is the least burdensome to a receiving party that the overall transaction likely will be further protected by another existing encryption scheme like Secure Socket Layer (SSL) that is already part of the existing framework.

However, even if the transaction was conducted in an unencrypted state, using Whitenoise superkeys, means that a token is random and is so small relative to the sender's secret, distributed, private, exponential master key that it is of no use cyrptanalytically to break the master key (and the receiver has been authenticated and 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.

Similarly, if an index is used for the funds transfer there is no information to the receiving party (or hackers) of the number of subkeys (at the bank) used to create the Whitenoise master key, the length and order of the subkeys used to create a Whitenoise 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.

8. Another scenario with an additional layer of security is one where the final receiver is "in the system" and has their own, unique, distributed, private, exponential key.
In this configuration that receiver can be authenticated by additional techniques, handshakes and 275 processes described below.

9. Another scenario is one where a transfer is made directly to an end user device (i.e. a person receiving their paycheck) and then that person and device can be identified with whatever level of identity proofing or anonymity that the institution "cashing" the 280 instrument requires by an additional separate process.

Secure distributed key handshakes are a preferred embodiment to be used in conjunction with this invention. The payment and funds transfer process described above is a single key, one way 283 authentication system.

It is anticipated to those familiar with cryptographic arts that there will be contexts where additional security layers, tiers, and key functions will be used. All contexts and key based security controls can easily be provide.:-I, from a dedicated authentication server that can perform two-way stateful authentication, encryption, signatures, inherent intrusion detection (the keys in 288 a dynamic distributed key system must be synchronized.) In symmetric, dynamic, distributed key systems the server has copies of all the keys on a system.

The keys are stored in an encrypted state. The keys are always kept separate from the last current 291 dynamic offsets.

Each endpoint has only its unique, distributed, private/secret key. Secret keys are NEVER shared 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:

1. A method of creating an authentication and key management server for dynamic distributed symmetric key systems (dynamic distributed key infrastructures) wherein there are no public key 298 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 300 number of keys;

ii) the server has copies of unique "link keys" between itself and other servers for 302 secure communications between networks;

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;

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;

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.

326 A simple distributed key handshake 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 -, _ , =
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 -- _....

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 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 communications with a new endpoint without first having to copy a key physically to that endpoint as has been traditional in distributed key systems. This allows simple scaling of the network. It facilitates authentication and secure, one-time key distribution.
It facilitates the 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 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.

pkA requests link ;
with "Er r 6- 'Er decrypts i / session key with pk6 /
, and then decrypts /
348 ,-----.'"/ 6 message, ,-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.

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 D_ Signater*
8 $. Mont and Som., imehaftipt 8 Cl ?triremes* as Seth seed 9 *filahrbeir rneeescees 9 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.

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.

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 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 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 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 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 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..

i . 41.111 I 1 .
'the streirth of a Whitenoise L.
key Ls calc',:,i=tAl by adding ..............
the lenspr, (-4 the subkeys in 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 ........,.,õ

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.

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.

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.

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:

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.

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.

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.

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.

=
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.

Claims (15)

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.