Secure Human Identification Protocol with Human-Computable Passwords

Abstract

In this paper we present a new method of secure human-computer identification, which remains safe also in untrusted systems and environments. This method allows the elimination of any supplementary gadgets/devices or theft-sensitive biometric data used by the Multi-Factor Authentication (MFA), and using only one secret as a universal private key for all obtainable online accounts. However, the features of this solution make it best suited for use by an mobile authenticator or by Authentication Authority with the Single-Sign-On (SSO) method of identity and access management, rather than for individual services. Such a key is used by our innovative challenge-response protocol to generate One-Time-Password, e.g., 6-digit OTP, could be calculated by a human in only 15 s, also offline on paper documents with an acceptable level of security required for post-quantum symmetric cyphers, thanks to the hard lattice problem with noise introduced by our new method, which we call Learning with Options (LWO). The secret has the form of an outline like a kind of handwritten autograph, designed in invisible ink on the map** grid. The password generation process requires following such an invisible contour on the challenge matrix created randomly by the verifier and reading values from secret fields to calculate the OTP.

1 Introduction

Despite the use of different identification factors by multi-factor authentication (MFA) methods, the basic condition for a reliable authentication is the use of the intelligence of the human brain, in the form of a static password. For security reasons, it is recommended to use different passwords for each online account. As a result, users often adopt insecure password practices (e.g., reuse or weak password) or they have to frequently reset their passwords. To solve this problem, several solutions have been found, most of which use a secret shared by user and verifier, or such that the user reconstructs each of their passwords by calculating the response to a public challenge, by performing simple mathematical operations i.e. addition modulo 10. For each internet account, such a challenge must be stored on the server with the correct response as a hashed password, but only the user needs to know the secret (only one for all these accounts).

A similar approach to the password calculation idea is used by our iChip protocol (patent pending), inspired by microchip topography and handwriting (Fig. 1). As we showed in Sect. 7, it ensures the secure generation of several thousand of these passwords. In the following, it can also be used as an OTP generator.

Fig. 1.

Topography of microchip, iChip’s secret patern, and handwriting.

The MFA method often requires an additional electronic device, because using the same device or communication channel both to enter a static password and to verify another MFA-factor, may not be secure. Such a device uses a built-in OTP generator or biometrics. Then, the OTP is automatically entered into the verification system, for example from a smart card or IoT device, or by the user after being read from the token screen or smartphone via SMS or a special application. Unfortunately, this solution does not guarantee that the device is used by its owner; it must be available at all times and can be stolen, lost, damaged or duplicated. Biometric methods are an alternative, but they can be tricked relatively easily by a replay attack using intercepted biometric data and, if necessary, with the help of machine learning or AI algorithms [19].

The MFA obviously requires more time than entering a regular static password. Therefore, a human-generated OTP protocol that maintains the expected balance between security and usability, eliminating the long list of drawbacks mentioned above, has a high chance of being accepted by users.

More than 30 years have passed since Matsumoto and Imai presented the first Human-Generated Password protocol (HGP) in 1981 [1], and during that time, many attempts were made to achieve this above-mentioned balance, but only two protocols were implemented commercially: strong and very slow HB, presented by Hopper and Blum in 2000 [2], and fast and easy but very weak grIDsure (GS), presented by Brostoff et al. in 2010 [20]; both described briefly also in Sect. 2. We will show further that our iChip scheme has security properties better than HB and usability close to GS, while eliminating their drawbacks.

The contributions of this work are: the challenge-response cryptographic protocol, based on lattice problem with noise, introduced by our Learning with Options (LWO) method as a more effective new variant of the LPN/LWE method of easy OTP computation by a human; a graphical interface for the implementation of that protocol, which allows the user to create his secret in the form of an easy-to-remember image, and a special wizard to compose it; both well-proven in usability and security study discussed after the presentation of mathematical rules, illustrated by examples of the iChip core and its TurboChip overlay; and finally, a further protocol enhancement against active attacks.

The completed implementation can be tested in an interactive demo or viewed in a short film, either as a professional tutorial or an alternative version made by children participating in the research process; both available online [25]. It is much more effective to understand than a mathematical description.

2 Related Works

We do not wish to duplicate the overview of the HGP protocols compiled and presented in [5, 12]. The most relevant for our work were three schemes, two of which (HB and GS) were commercially implemented, and Human Computable Passwords (HCP) presented by Blocki et al. in 2017 [7], which were close to achieving this goal.

• The HB is based on the Learning Parity with Noise (LPN) method, which ensures a high level of security, but the time of over 10 min needed for a 20-bit authentication by a human is too long to be acceptable. Nevertheless, the properties of this protocol or later improved variants (HB$^+$, HB#, NLHB) are well suited to apply in resource-constrained devices. The protocol runs as follows: Both sides of the protocol (User U and Verifier V) shared the secret x. V set a random challenge $a \in \{0, 1\}^k$ and sends it to U. If the LPN method would be not used in this protocol, then U computes the binary inner-product $a \bullet x$, then sends the result back to V. V computes $a \bullet x$, and accepts if U parity bit is correct. By repeating it for r rounds, U can lower the probability of random guessing the correct parity bits for all r rounds to $2^{-r}$. An eavesdropper capturing O(k) valid challenge-response pairs between U and V can quickly calculate the value of x through Gaussian Elimination. To prevent revealing x to passive attacks, U has to inject noise into his response. U intentionally sends the wrong response with constant probability $\eta \in (0, 0.5)$. V then authenticates U identity if fewer than $\eta r$ of responses are incorrect.

• The grIDsure scheme has exactly the opposite properties confirmed in [20]: the high usability level and very low level of safety, as only 3 samples of challenge-response pairs are sufficient to reveal the secret. In addition, the entropy of this scheme is also low, as detailed research has shown, that users choose secret patterns that are easy to remember and frequently reused, so its scheme is highly vulnerable to dictionary attacks, as the choice is very limited due to the small grid $25\times 25$ and the small number of 4 secret objects. The user reads the 4 digits of the OTP password from 4 secret places in a grid filled with random numbers.

• The HCP has the best balance between safety and usability of any HGP protocols developed so far. The disadvantage of their scheme is the need to memorize dozens of pictures, map** to numbers with the help of associated mnemonics. The verifier shows a challenge of $k_1+k_2+10 = 14$ randomly selected pictures from n prepared and memorized by the user. The user has to mentally replace the pictures in the challenge with the corresponding numbers, and then compute each digit of the password using the following function:

  $$\begin{aligned} f_{k1, k2}(x_0,...,x_{9+k1+k2})=x_j+\sum _{i=10+k_1}^{9+k_1+k_2} x_i \mod 10, \text { where } j=(\sum _{i=10}^{9+k_1} x_i) \mod 10 \end{aligned}$$

The iChip has similar usability properties to grIDsure as the secret pattern of cells in the grid is employed by both schemes. However, the similarity is noticeable only in the so-called generator block. The most significant difference lies in the extraordinary rules used in iChip, which makes a huge difference in the key space (3e + 5 vs 3e + 154), and provides many thousands of times greater resistance against pee** attacks than GS. The conclusions about low practical entropy of GS do not apply to the iChip as getting all the easy-to-remember keys from such a huge key space is a task with a difficulty near to brute-force, which is not feasible for current supercomputers. In Sect. 7 we will show, that the iChip protocol inherits the abovementioned properties of HB, HB$^+$ and HCP, which protect it triply against passive attacks.

3 Introducing Noise to the iChip Protocol

An important feature of the iChip protocol is the implementation of the Learning with Rounding (LWR) method, which is an LPN variant of the worst-case hard lattice problem inherent in lattice cryptography. The implementation of core LPN or Learning with Errors (LWE) methods increases the security of any protocol; however, the degree of usability is reduced, and authentication requires much more time, as the user has to perform additional protocol rounds to compensate for rounds lost to incorrect responses due to reduced resistance to random attacks. In contrast, the LWR and described below LWO methods requires only correct responses. The iChip uses Eq. 1 introduced in Sect. 4.1, as its base function which satisfies the criteria of the LWR method of deterministic rounding by $x \mod p$, where $p = 10$ is admittedly too small to effectively introduce noise, but convenient for human computation. This function is a node for the various protocol variants and for our proposed LWO method of introducing noise, which is far more efficient. To further strengthen the iChip protocol it is beneficial to increase the entropy of the random option selection in the LWO case. The simplest way to get this entropy is to read the seconds from the system clock or user’s watch, and then calculate for example, $seconds \mod 2$, to addressing two output elements of any block in the secret.

4 Interface Design and Protocol Implementation

The iChip is a challenge-response protocol to authenticate the user to the verifier using the shared secret, where the user has to answer the challenge generated by the verifier (server). The way the iChip scheme worked was inspired by the image of the photolithographic mask used to create conductive paths on the PCB (Printed Circuit Board) or PLA (Programmable Logic Array) surface, like shown in Fig. 1. The user composes his secret by designing such a layout in a special wizard by drawing a map of blocks B of masking elements as paths conducting the digital signal from input to output; provided from the generator block. These paths will determine the change in value from $V_{inp}$ at the input to $V_{out}$ at the output and define their properties and mutual logical relations. This layer consists of $n\times n$ fields and is represented by the C matrix, containing $n\times n$ cells.

The user specifies his secret key S by specifying a list of b blocks that occupy the fields selected by him from the C matrix, and specifies the block elements that act as input or output. For a short and easy explanation, we will use the example of the secret key illustrated in Fig. 2 or Fig. 4 as an iChip layout and the matrix coordinates of the input and output elements encoded hexadecimal in the associated table, while for the description of the protocol, we will use the Python convention. The C matrix is a set of $n^2$ random values generated by verifier as $C = [[V_{1,1}, V_{1,2}, ..., V_{1,n}],... [V_{n,1}, V_{n,2}, ..., V_{n,n}]]$. Each i-th element of block $B[i] = [y_i, x_i, z_i]$ is defined by 3 parameters: row y and column x as field coordinates (y, x) in matrix C, and parameter z defining its state: $z = \left\{ I, O \right\}$, where: $I=Input, O=Output$.

We use also an alternative compact notation of block elements as: $B^z_j[i] = B^z_j[(y_i, x_i)]$. Each block $B_j$ is a list of such elements, divided into two segments for inputs and outputs: $B = [B^I, B^O ] = [B[1], B[2], ..., B[k]]$. A list of b blocks $B_j$ is included in the secret $S = [B_0, B_1, ... B_{b-1}]$, where $0 \leqslant j < b$.

The algorithm parameters are denoted by four positive integers $N,L,b,k\in \mathbb {N}$, where:

• chip size (the size of C matrix), $N = n\times n$;

• parameter describing OTP length, $L\leqslant 10$;

• maximal number of blocks, $1\leqslant b \leqslant 10$;

• maximal block length, $k\leqslant 10$;

4.1 Generating One-Time Passwords

$G=B_0$ is the first of these blocks in key S, and it is called a generator because it does not contain inputs and the values $V_G=C[G]$ from all its $L=|B_0|$ output elements are mapped by the remaining blocks. The user has to remember the position of all blocks and their order in the S. The verifier generates a challenge matrix C of N random digits. To generate the OTP, the user has to collate the C matrix with the secret key S and calculate all OTP digits, one at each i-th of $L=|$OTP| rounds of the protocol in the following 3 steps:

• 1. Read the $V^i_{inp}$ value of the G[i] element in C at position $(y_i, x_i)$: $V^i_{inp} = C[ G[(y_i, x_i)] ]$

• 2. Starting from j-th block (where $j=1$ in the 1st round), search input elements ($z=Input$) of j-th block for the coordinates $(y_i,x_i)$ such that $V^i_{inp}=C[B_j^I[(y_i, x_i)]]$. If no such coordinates are found in the j-th block, move to the subsequent block. By $j=\phi$ denote the index of the current block ($\phi$) in which the searched so-called target input ($\psi$) has been found first and let

  $V^i_{out} = C[ B_\phi [y, x, z=Output] ]$.

  If the search fails for all $j < b$ then let $V^i_{out} = V^i_{inp}$.

• 3. The i-th digit of the OTP you will get as

  $$\begin{aligned} OTP[i] = (V^i_{inp} + V^i_{out}) \mod 10 \end{aligned}$$

  (1)

To avoid overloading the first blocks, it is recommended to resume the search for $V^i_{inp}$ from the block next to the last searched. For additional security, the authentication protocol should follow at least one of the two exceptions/rules (*I, *O), which have been added to the 2nd step of the algorithm; these significantly increase the resistance of the iChip protocol against passive attacks with a statistical algorithm or Gaussian Elimination.

For their consideration let $(y_i, x_i)$ be the coordinates on which the target input $\psi$ in B such that $C[B_\phi [\psi ]]= V_{inp}^i$ was found first in the challenge matrix.

However, first, we will present a simple example illustrated in Fig. 2 to explain the principle of calculating the OTP without the exceptions mentioned above. Alternatively, it is recommended to watch the short video tutorial [25].

Fig. 2.

An example of a secret: block input elements given as black fields and output as blue or light blue fields. The positions of all input and output elements are hexadecimal encoded in the associated table. The first column ( &) contains the index of each block. On the right: The challenge matrix. (Color figure online)

There are generator block 0 containing 4 light blue cells in the matrix corners and two map** blocks labeled by their index (1 or 2) in the example above (Fig. 2). In the 1st round, we read the value $V^1_{inp} = 3$ from the 1st element of generator block at position (0, 0).

We look for this value sequentially in all map** blocks from 1 to 2. The first occurrence of this value is in the last element of block 2, i.e. $B_2^I[5]$ in cell (6, 6), which is the target input $\psi = 5$ in the current block $\phi = 2$. Now, we read a value of the output element of this block, which is in cell (8, 4), hence $V^1_{out} = C[8, 4] = 5$. The 1st round ends with a calculation of the 1st OTP digit according to Eq. 1 as: OTP[1] = $(V^1_{inp} + V^1_{out}) \mod 10$ =

$= (C[G[1]] + C[B_2^O[1]]) \mod 10 =$

$= (C[0, 0]+C[8, 4]) \mod 10 =$

$= (3 + 5) \mod 10 = 8$.

$$\text {EXTRA RULES / EXCEPTIONS}$$

*I) Let $V^i_{inp}$ be the sum of all input elements of the current block $B_\phi$, from $\psi$ to $\psi$+n, where $\psi$+$n \leqslant |B_{\phi }^I|$ and $n \leqslant 2$:

$$\begin{aligned} V^i_{inp}=(\sum _{k=0}^{k\leqslant n}C[B_{\phi }[\psi +k]] ) \mod q \end{aligned}$$

(2)

This introduces non-linearity to cryptanalysis and protection against Gaussian Elimination, as the number of arguments in Eq. 2 varies randomly in each challenge. Depending on the variant of *I, the q modulus can be 10 or omitted as default.

*O) If the current block $B_{\phi }$ contains more than one output element $|B_{\phi }^O|>1$, then randomly choose one of them as $V^i_{out}=C[B_{\phi }^O[randrange(1, |B_{\phi }^O|)]]$. This is the case of using the LWO method illustrated by Fig. 3: Block 2 with fields labeled by 2 has two outputs/options at positions (3, 1) and (3, 3). If the value searched for is found in this block, then the user has to choose one of these two options at random.

Fig. 3.

An example of secret with exception *O.

*$\varTheta$) If the current block $B_\phi$ has no output $|B_{\phi }^O|=0$, then we use the next input instead: $V^i_{out}=C[B_{\phi }[(\psi +1) \mod |B_\phi | ]]$. This exception is a logical complement to the exception *O and it has great importance for increasing the key space, because cryptanalysis must take into account the order of all block elements in the C matrix.

Fig. 4.

An example of a secret defined by the user and challenge matrix with a schema for determining the 1st digit of OTP.

4.2 Advanced Example

Based on Fig. 4 we will compute the 6-digit OTP using the variant of double protection against passive attacks, i.e., with the rules *I and *O, as follows:

The generator block contains $V_G = C[G] = C[B_0] = {[3, 7, 8, 8, 6, 3]}$.

The 1st element $V_G$[1] at position (0, 4) has a value of 3.

When looking for it sequentially in blocks 1 to 6, it can be found in the 3th input element of the 1st block $B_1^I[3]$ at position (6, 4), (marked in the red ring as a target input $\psi$); the output element $B_1^O[1]$ of this block is in cell (3, 3) with a value of 9. The 1st digit of OTP is calculated according to Eq. 1 as

OTP[1] = (3 + 9) mod 10 = 2.

The next element $V_G$[2] at position (1, 5) has a value of 7, which is also in $B^I_4[2]$ at position (5, a) and the output element $B^O_4[1]$ has a value of 9. Since $\psi =2 < |B_4^I| = 3$, then due to rule *I:

$V_{inp}^2 = C[B_4^I[2]] + C[B_4^I[3]] = 7 + 1 = 8$. Now, according to Eq. 1 we can calculate: OTP$[2] = (8 + 9) \mod 10 = 7$.

$V_G$[3] = 8 appears in $B^I_5[3]$ at position (c, 6), but this block has 2 output elements $B_5^O[1]$ in cell (d, 7) and $B_5^O[2]$ in cell (e, 7). Therefore due to exception *O, we can choose any of them; assuming we choose the first with value of 4, OTP[3] = (8 + 4) mod 10 = 2.

$V_G$[4] = 8, hence this round is similar to the previous one, but now, we use the second output $B_5^O[2]$ in cell (e, 7) for our calculations:

OTP$[4] = (8 + 0) \mod 10 = 8$.

$V_G[5] = 6$ appears in $B^2_I[1]$, but this block has 4 inputs, therefore we add three of them to $V_{out}^5 = 1$, hence: OTP$[5]= 6+3+4+0 \mod 10 = 3$.

OTP[6]$\, = \,$OTP[1]. The entire OTP = [ 2, 7, 2, 8, 3, 2].

4.3 TurboChip Overlay for the iChip Protocol

Since the most time in the iChip protocol is to look for the target input, we have introduced the TurboChip acceleration overlay. Now, only one iChip round and one element in the generator block are needed. Based on Fig. 4, we use the OTP$[1]=2$ a secrete and use it as offset V to calculate each i-th OTP number:

OTP$[i] = V+C[B^I_\phi [\psi +2i]] \mod 10$.

If the component index is outside the block range, then we continue from the 1-st element in the subsequent block. In this example: $\phi =1, \psi =3$, $|B^I_1|<\psi +2i$. Therefore, we go to the block $\phi =2$ to compute the next OTP digit:

OTP$[1]= V + C[B^I_2[1]] \mod 10= 2 + 6 \mod 10 = 8$,

OTP$[2]=V+C[B^I_2[3]]\mod 10 = 2 + 4\mod 10 = 6$, e.t.c.

5 Protection Against Active Attacks

5.1 Preliminary Stage in iChip Protocol with TurboChip Overlay

In this stage, which we denote as a rule *A, the user has to indicate (e.g., by the mouse pointer), a random field in the challenge grid shown by verifier.

The closest block to this field is taken as current $B_\phi$, and the user reads the value on its k-th output $B_\phi ^O[k]$ to change the offset value V calculated as in Sect. 4.3.

The user computes a new offset value by adding $V'=C[B_\phi ^O[k]] + V \mod 10$.

Now, the user calculates the entire OTP using $V'$ just like for the TurboChip overlay. The adversary does not know the secret, so the response to the challenge prepared by him will not give them any useful information, as it would be disturbed by an additional random component introduced by the user.

5.2 Hash-Based Signature

To ensure that the user authorizes a correct message M (e.g. transaction conditions), and not a falsified one by an active adversary, we propose an innovative Human-Hashed variant of (hash-based) Message Authentication Code (MAC). In this concept, the previously computed hash function (e.g., SHA-256) for message M and random matrix C, written here as $H = h (M, C)$, is finally hashed by iChip’s OTP. It is optimal that the number of grid fields N in challenge C is equal to the number of bits in digest $N=|C|=|H_2|$, because the randomly generated challenge matrix C is modified by adding one bit of the hash H to each value in matrix C, according to the formula $C_{10}'[i] = (C_{10}[i] + H_2[i]) \mod 10$, where $0 \leqslant i \leqslant 255$ when using SHA-256. The user performs the signature by entering the OTP on the keyboard or writing OTP digits on the document containing as in Fig. 5: a blank iChip grid for the global UID (optional), the challenge matrix C’, a QR code specifying the document identifier in the repository for automatic scanning and the HHMAC verification.

Fig. 5.

Global UID, Transaction ID, HHMAC, Challenge C’.

6 Brief Analysis of Usability

• Intelligibility

  Our time-limited study only focused on a small group of children aged 8–10, assuming that the adult performance should be better, because modular addition and abstract thinking is required, which develops with age [16]. For this group, the iChip protocol was compared with that of a board game, more especially the well-known Monopoly or Jumanji, where the throws of the dice symbolize the operation of the generator block, and all the fields on the board forming the track constitute the iChip blocks, which user have to go to achieve the target field/input and finally make a decision according to the rules of the game protocol The children took 1 standard lesson unit (45’) to learn the protocol and the special wizard to design their own microchip and remember it.

• Memorizing and Rehearsing

  The appropriate distribution of block elements is of major importance for entropy level and easy memorization of the entire structure of the secret. The numerous symmetries offered by the background are very helpful. It is profitable to draw the secret contours in a single sequence like a short piece of text (e.g., Fig. 1) or a simple shape (e.g., Fig. 4). Additionally, since all key elements are used each time, the whole secret image can be easily remembered after 30–45 minutes of repeated authentication training attempts and frequently refreshed at the use stage.

• Authentication Time

  The authentication time is proportional to the user’s cognitive workload - ranges from 4 to 8 s ($\thickapprox$ 6) in each round of response, depending on the composition of secret and the user’s skill. After several searches, visual perception adopts a parallel analysis approach, i.e. the search for an $\psi$ element with $V_{inp}$ is not performed element-by-element, but in blocks, just like reading a text, with whole words being interpreted, rather than individual letters. Each modular addition and block search requires ca. 1 sec. For the user who has to look at the keyboard to enter OTP, it will be easier, and faster, to use voice input, which is also a good source of biometric data and a 3-rd authentication factor. After the introducion of the TurboChip overlay, the authentication time is significantly reduced to an average of $\thickapprox$15 s for a 6-digit password.

7 Brief Analysis of Security

The resistance to a random attacks depends on the number of OTP digits calculated by the user. Their number L is arbitrary and depends on the needs of the authentication system, e.g., $L=6$ like OTP in most e-banking systems.

The iChip’s resistance to active attacks is ensured in the preliminary stage (see Sect. 5.1) or by the hashing and signing the authenticated message, as the HHMAC is valid only for the signed message (see Sect. 5.2).

As the challenge in the iChip protocol is generated full at random, it is fully immune to frequency analysis.

The iChip’s entropy is of course lower in practical use than its key size of 512 bits, but much higher than a text password due to large number of possible fonts and their positioning on the large grid. A good example is the word iCHIP used in Fig. 1. The number of possible patterns for designing this word is enormous, despite the use of many symmetries compared to the number of possible text entries offered only by upper and lower case letters. More on that in Appendix.

The resistance to brute-force and Grover’s quantum algorithm is provided by NP-hard lattice problem and huge key space (see Table 1), estimated as follows:

$$\begin{aligned} \begin{aligned} \frac{N!}{(N-L)!} \cdot \sum _{i=B}^{B+b_0} (\sum _{d=1}^{k} \left( {\begin{array}{c}N-L\\ d\end{array}}\right) \cdot \sum _{j=E}^{E+e_0}\left( {\begin{array}{c}N-L\\ j\end{array}}\right) +\\+\sum _{j=E}^{E+e_0}\frac{(N-L)!}{(N-j-L)!})^i \end{aligned} \end{aligned}$$

(3)

where:

$N = n \times n$ is the size of Chip’s matrix, default 16$\,\times \,$16

L is the number of OTP digits, default 6

$[B, B+b_0] =$ number of blocks, in the range 3 to 7

$[E, E+e_0] =$ number of input elements in block: 3 to 9

$[0, k] =$ number of output elements in block: 0 to 2 or max. 3

The iChip is triply protected against passive attacks by introducing: a non-linear function in the *I rule, LWO method in the *O rule, and preliminary stage against active attacks as the rule *A; relevant to the results of related works and protocols: HCP [7], HB [2], HB$^+$ [4].

• As shown in [7], relevant to *I: The k number of arguments used in the function $f(x_1, x_2, ..., x_k) = x_1 + x_2 + ... + x_k \mod p$ depends on the safety function for the statistical algorithm $r(f) = k/2$, however, f cannot be linear, because then the security for Gaussian Elimination is $g(f) = 1$ and the Equation 1 takes only 2 arguments (k = 2). Therefore, in this case the secret could be recovered even from O(n) challenge-response samples: $m=n^s, s=min(g, r)$. The introducion of *I rule gives up to 2 additional arguments by Eq. 2 to this base function, hence $2 \leqslant k \leqslant 4$. The number of these arguments is not constant but varies randomly in each challenge and $V_{out}$ is the result of a previously used map**, so the Eq. 1 becomes non-linear, and $g(f)=k+1$.

• As shown in [2], relevant to *O: Introducing noise by the LPN method does not allow the simple use of Gaussian Elimination, and the adversary needs to see $O(n^2)$ samples to reveal the secret, also in the case of secret’s low entropy as shown in [14].

• As shown in [4], relevant to *A: The introduction of an additional shared secret, which the prover uses to generate a random k-bit “blinding” vector and send it to the verifier before receiving the underlying challenge from them, is beneficial for protecting against both active and passive attacks.

If both rules (*I and *O) and the optimal key size for iChip $n=512$ are used then estimated safety function is limited by $s=min(r, g)=min(2, 5)=2$, hence $m \approx 262,144$ samples challenge-response are needed to reveal the secret.

Table 1. Comparison of the most important and optimal parameters.

We tested the resistance of the protocol against finding the secret key with an advanced Genetic Algorithm, which ran for m = 1,000, m = 10,000 and m = 20,000 samples over several days on a computer with 18-core CPU (Intel i9). The secret as a pattern of $k=36$ cells created in the default grid size of $N=256$ cells but without *I and *O rules was found after approx. 2 h of operation. After introducing the LWO, the cracker found a secret key only for weak parameters i.e., $k=13, N = 25$ (Fig. 3). With the simultaneous inclusion of *I and *O rules, the 2-day search did not give a correct result even for $k=25, N=49$.

The tests conditions and results are available online [25].

8 Comparison of the Best HGP Protocols

Referring to the data in Table 1 of the article from 13th NDSS [12] and the latest publications until today, we have compiled in Table 1, the parameters of the best Human Generated Passwords protocols, that were created in the years 1991–2017 (there is no significant contribution after 2017), as a comparison with iChip. As we can see, the iChip’s parameters have a significant advantage over all others, both in terms of security (key size, key space, s(f)) and usability (secret’s memorizing and authentication time closest to grIDsure). Only NLHB, HCP, and iChip are protected from linearization studied in [10], where $m=O(n^s)$ strongly depends on the key size n. The enhanced versions of HB$^+$ also offer protection from active attacks, but only iChip with *A rule or HHMAC are suitable for the user due to the required authentication time.

9 Conclusions

The result of our work is the iChip protocol and TurboChip overlay, which significantly accelerate the OTP generation process. This overlay allow flexibility in generating passwords of any length L from 1 to $k=|S|$. The protection against active adversary attacks is provided by introduction of an additional random factor controled by the user, not by the verifier, as well by the human-hashed signature HHMAC with the use of standard hash algorithm, preferably SHA-256. Such a signature can be also performed by the user offline on paper documents without any gadgets, and automatically scanned and loaded into the system for verification. The iChip is applicable as one universal secret key to the creation of multiple original static passwords for each online account. However, it would be redundant and it can be ommitted in this case as it relates to the same secret as the OTP generator. Thanks to this, we save time wasted on entering a static password. The preferred solution is an Authenticator realized by smartphone with embeded cryptochip which ran the iChip protocol and owns the user’s secret; or replacing the 2FA with iChip identification in the Single Sign-On (SSO) authentication method based on the OAuth2.0 protocol [23] under the control of the authentication server (as an Authentication Authority) that owns the user’s identities and credentials, including the iChip secret key or container with multiple pairs of challenges and responses as hashed OTPs.

The iChip protocol parameters and features (triply protected against passive attacks and double against active attacks) are well suited to apply in resource-constrained devices such as IoT or RFID. Noteworthy is the discovery of LWO as a new hard lattice problem, whose empirically tested properties confirm greater efficiency than LWE/LWR/LPN at least when applied to human computing. However, it requires an in-depth cryptographic analysis in the reduction to LWE.

A Increasing the iChip Entropy

In the sample of 920 students of our university, no secret pattern was repeated. However, the entropy of iChip can be effectively increased by using a suitable background image as shown in subsection A.1, or by further increasing the key size as shown in subsection A.2.

1.1 A.1 Individual Background Composition

A suitable background image, can be built individually by the user or proposed by the wizard as a random structure. The visual structure of such a background (e.g., Fig. 6) provides reference points for easy remembering the image of the secret and thus allows building a secret key with much higher practical entropy.

Fig. 6.

An example of a secret key pattern depicting the word ADMIN on an individually designed background.

1.2 A.2 The iChip as Multi-Layout Interface with 3D Key

The iChip interface allows the user to expand the secret not only in 2 dimensions (row x and column y), but also use the 3rd dimension, i.e., the z parameter is used here as a layout index ($z=1$ as default), marked in colour of the secret elements and is indicated in the i-th round by $z=V_G[i+1]$. In this simple way, the key size can even exceed a thousand bits, without increasing the C size, where $N_{|z|=1} = x \cdot y =|C|\approx 256$.

On the other hand, in the iChip protocol, the z parameter specifies the state of each secret element as Input or Output, marked in the graphical interface with two colours (black and blue). So, it can be considered as two layouts, hence $z = 2$ and $N_2 = 512$. This concept can be extended by introducting additional features of the secret elements, e.g. additional trigger, bridge, tunnel, e.t.c., or simply by their different colour, assigned to a specific layer. In this case, the process of computing the next digit of the password starts with the 1st block of the z layer.