METHOD AND SYSTEM FOR STRONG AUTHENTICATION AND SECURE COMMUNICATION
TUPLEZZ is the Enigma Machine of the 21st century without Enigma's
major flaw (i.e., a letter could never be encoded as itself)
and up for licensing, sale or startup --
. White Paper .
Cybercrime is one of the biggest challenges that humanity is facing and cybersecurity innovation is paramount to our economy and national security so I thought of a method – which I called TUPLEZZ – that has the following strengths:
.1. . .TUPLEZZ is a Challenge-Response authentication method that makes it impossible for an attacker to replicate even when the hacker has the static ID and Pw of the User and he (the attacker) has recorded (screen capture and keylogging) all previous login sessions of the User.
.2. . . This method doesn’t require a third party or time synchronization.
.3. . .Due to the infinite number of possible formulas that can be used, a brute force attack to figure out the algorithm is impossible.
.4. . .The Client can log in even in the absence of the token with no need to contact the Server (or a third party) and no need for a cell phone.
.5.. .The AOTC (Authenticated One Time Challenge) makes phishing impossible. AOTC replaces the OTP (One Time Password) used by other methods.
.6. . .The use of a login counter means that TUPLEZZ is automatically updated after each login session. Therefore this method doesn’t need to be updated but if the Server’s policy requires periodic updates they can be done.
.7. . .The encryption it provides is unbreakable because TUPLEZZ can provide a key length as large as the message and only used once (because each new message will be associated with a new AOTC which will result in a new unique key), which is what Claude Shannon showed to achieve the so called perfect secrecy.
.8.. .This method requires that both parties (Server and Client) contribute with a random input every time the user logs in, which results in a unique authentication method which is superior to anything else tried so far.
* The Server’s authentication (the 6-characters-long 13th column in our example) for each login session could be the value of the login counter encoded using the Active elements for that specific login session so the two parties will make sure that their login counters are in sync.
Fig. 1:
When the Server receives a login request 102 it will ask for the static username and password of the Client 104 (Client and User are used here interchangeably).
If the Client enters the correct values in the first step -- 106 and 108-YES -- of this 2FA then the Server randomly generates a Challenge 110 and compares it with the previous Challenges that have been used and saved in the Server’s Challenges Database 114.
If/when the Challenge is new 112-YES the Server will authenticate it 116, add it to the Database 114 and display 118 for the User the Authenticated One Time Challenge (AOTC) for him/her to solve it .
The User enters the Response 120 and if the Response is correct 122-YES the access is granted 126. If the User enters the wrong Response then 124 the Server will take the appropriate action.
Fig. 2:
When the Server displays the Challenge the token optically reads 210 the Challenge.
The token compares the Challenge with the previous Challenges that have been used and saved in the Client’s Challenges Database 214.
If the Challenge is not an AOTC the token will take the appropriate action 216.
If the Challenge is new and correctly authenticated by the Server 212-YES the Client’s Challenges Database 214 is updated with this new Challenge.
The token randomly generates Rc 218.
The token computes the Response 220 using the set of formulas associated to Rc.
User enters Response 120.
The Challenge is a list containing only the characters that can be used in a password/Response for that specific server.
1b. Without token:
In situations where it is acceptable for the Client to skip checking if the Challenge is an AOTC (Authenticated One Time Challenge), the Response can be computed without a token. Even if an attacker tricked the Client into providing a Response that Response can’t be used again anyway.
When the token is unavailable (damaged, misplaced, dead battery, stolen and so on) the Client can still provide the Response by using only list_c_a and a set of formulas as simple as ax + b.
The User will save list_c_a, one particular listP_i which we call the User’s List (listP_8 in this example) with its specific 9 characters and the set of formulas associated with the User’s List in a safe place that can be as simple as a hardcopy.
When Rc is one of the 9 characters in listP_8 (User’s List) above that will notify the Server that the list_c_b (and the login counter, if any) is/(are) ignored. There is no way to know for an attacker (assuming that the attacker somehow knows the User’s List, which is highly improbable) or even the Server whether the Client can’t use the token (and thus computes manually) or the token just happened to randomly generate a character from the User’s List. Out of the 8 lists (listP_i) only one (in this example we chose listP_8 to be the User’s List) is ignoring list_c_b (and the login counter, if any) to make it easier and faster for the User to compute the Response. When computing the Response by himself the Client has to place any of the 9 characters of the User’s List on the predetermined position for Rc (the 3 rd position from the left in this presentation).
The User will ignore list_c_b and only use list_c_a for computations by replacing b(ActiveElement_i) with a(ActiveElement_i) in the first step of computations presented in Sample Formulas associated to listP_6 (of course that in this case the formulas associated with listP_8 will be used). Then he will complete the rest of the steps of the algorithm.
If the Client always (that is with or without token) manually enters the Response using the keyboard instead of providing the Response by other means when the token is available then even an attacker who managed to install a RAT (Remote Access Trojan / Remote Administration Tool) capable of performing keylogging and screen capture on the user’s computer will not be able to figure out whether the Client used a token or not to answer the Challenge.
The user’s set of formulas are so simple that he can easily do the computations himself (all PCs and smart phones have a calculator with all the needed operations including the MOD function). There is an infinite number of simple formulas of the form ax +b and no attacker can be successful trying to brute force attack the infinite.
[00xyz] In many situations it should be sufficient for a Client with no token to compute less than 7 characters (Ai’s) for the Response. For instance the Client can compute only 4 or 3 Ai’s, place them and the Rc on the predetermined places in the Response and fill the other positions with random characters -- it will be up to the Server to set up the details for this very convenient authentication method.
Of course that the Server can provide the Client with banks’ style Transaction Authentication Numbers (typically, there are 50 TANs printed on a list) or backup codes (Google provides a list of 10) for situations when the token is unavailable, but while the TANs and the backup codes have to be re-delivered again and again each time they expire, the ability of a TUPLEZZ User to compute a valid Response by himself is unlimited.
Part2: Secure communication and transaction signing.
The party who initiates the secure communication randomly generates a Challenge, encodes the plaintext with the key_final explained below and submits to the other party the Challenge and the ciphertext. For simplicity we consider that Response_k is provided by the set of formulas as- 11 sociated to listP_k (1 <= k <= 8).
All Responses concatenated (‘Response_1’ + ‘Response_2’ + ... + ‘Response_n’) create key_0. If the plaintext is longer than key_0 (len(plaintext) > len(key_0)) the next key (key_1) can be created from the original Responses each one multiplied by 2 and then concatenated and then the two keys are concatenated. If the plaintext is still longer than key_0 + key_1 the multiplying method is repeated (this time by 3) and so on until len(plaintext) <= len(key_0 + key_1 + ..) = len(key_final). Note: The series that will provide the numbers used to multiply the responses doesn’t have to be the set of natural numbers (1, 2, 3, 4, ..., n) but it can be any series (and there are an infinite number of them) the two parties agree upon. Because no two keys are identical (key_0 =/ key_1 =/key_2 and so on) statistical analysis (for instance the one proposed by Charles Babbage) to break the code is ineffective. A key length** as large as the message and only used once is what Claude Shannon showed to achieve the so called perfect secrecy
** Of course that the key can be of any length from a minimum acceptable length to len(key_final) = len(plaintext).
Because in this method the Challenge accepts multiple valid Responses there are an infinite number of ways to use these Responses to create a key_final of a desired length.
For transaction signing: The server sends an AOTC and a request for a signature. Any valid Response from the client can be used as a signature. If the signature is required to be longer than one Response then the algorithm will concatenate n valid responses to that specific AOTC such as len(Response_1 + .. + Response_n) >= len(signature) and the server will consider the first m characters as a valid signature, where m = len(signature). Or the client algorithm can do the job and return to the server the appropriate substring as the m-long signature. Of course that a more convenient understanding between the two parties (server-client) would be for the len(signature) to be a multiple of len(Response).
Some final notes:
- The method presented herein is designed to allow the User to provide a valid Response to the Challenge with or without a token. While for purposes of explanation we described a version with 8 possible Responses (7 ‘with token’ and 1 ‘with or without token’) the number of possible Responses can be anywhere from as little as 2 (1 ‘with token’ and 1 ‘with or without token’) to as many as 72 (71 ‘with token’ and 1 ‘with or without token’).
- The Server will provide the Client with the token or the software for the token in a safe manner.
- The token has a camera and a screen capable of displaying the required number of characters a Response has. If the token also contains a flash memory it will make it quite convenient for the tens of millions of people who already carry a flash memory with them -- so the token will not come as an inconvenience at all. If the token’s camera has 2 modes: OCR and a James Bond-style spy camera the device will appeal to even more people. Ideally a Client can use a token for multiple Servers which use this 2FA method. Depending on its complexity the token can have a different number of buttons.
- In any login session only 2 elements will be randomly generated: the Challenge by the Server and the Rc (Random character) by the token to identify which set of formulas to use. In the ‘no token’ situation the User will randomly pick up a character from the User’s List (listP_8 in this presentation).
- It is up to the Server to update the list_c_a and/or list_c_b and/or listP_i and/or the formulas and/or the position of Rc if and when that is considered necessary.
- While an OCR was used in this presentation, any other safe manner of reading the Challenge can be used.
- The len(Challenge) can be (1) smaller than len(list_c) in which case not all elements of list_c will show up but the Response can have any elements from list_c whether they are in the Challenge or not; or(2) larger than len(list_c) in which case some elements will be repeated.
- In many situations list _c_a will offer the desired level of security so list_c_b can be ignored and the computations will be done by the token using only list_c_a like the Client does when the token is not available.
- There are many people who love numbers (how popular Sudoku is worldwide doesn’t come close to saying the whole story) who might enjoy using for authentication a light version (only list_c_a, only one set of formulas and no Rc) of this method without any token and, eventually, having to compute only 3 or 4 Ai’s as explained in [00xyz] except that in this ‘no token’ situation there is no need for an Rc.
- Tokens/key fobs which utilize this method can also be used for authentication to objects such as doors or automobiles.
DRAWINGS
