The present disclosure relates to authentication and/or encoding/decoding methods and systems and to parts thereof. The present disclosure relates particularly but not exclusively to Matrix Pattern Authentication or equivalents or derivatives thereof. Certain aspects of the disclosure described may be applied to any form of secret information other than Matrix Pattern Authentication, where safeguarding the secret information is important; including passwords, passcodes, and personal information, including biometric information. The disclosure has particular although not exclusive relevance to personal authentication as an alternative to passwords and Personal Identification Numbers for computerized systems, embedded systems (e.g. for authentication/unlocking to computers and mobile devices), online identification or credit card payment, or any other authentication/unlocking process to any other device or process, such as e.g. to launch, or control access to, any third party applications on a device as a non-limiting example. Authentication is a process by which a user validates that they are legitimate, and may access, e.g. a secure service or transaction, protected by an authentication scheme. Matrix Pattern Authentication (MPA) is a generic term describing a form of known authentication which is an alternative to passwords and Personal Identification Numbers (PIN). Figures 1A and 1 B show matrices 100 used in a MPA, and comprising elements 101 . In the case of Figure 1A, the matrix 100 is a square pattern of 25 elements 101 , and in the case of Figure 1 B, the matrix 100 is a line (i.e. a linear matrix) of 12 elements 101. Figures 2A and 2B show that each matrix 100 is a basic template which a human user employs in order to select a memorable identification pattern (MIP) shown as arrowed and colored. It should be understood that other sizes of matrices and other form factors are possible, depending on the level of security required, and how easy it needs to be for a human user to recall their MIP.

In the context of MPA, the term entropy refers to the degree of variability that a given MPA design will afford humans in their selection of their MIP. Thus a grid, say of 25 elements in a 5x5 matrix as in Figure 1A, may be used. If a user was to select a MIP of five elements from the matrix, one could theoretically calculate that there would be 25 ^L 5 = 9,765,625 unique possible combinations for any individual MIP.

Figures 3A and 3B show that, in an authentication operation, a challenge matrix 200 is generated by an authentication system and presented to the user. The challenge matrix 200 is populated with a randomized set of signs, such as numbers, letters, or other logos. In the case of Figure 3A, the matrix 200 is a square pattern of 25 elements 201 , with numbers 1 , 2, 3, 4 and 5, and in the case of Figure 3B, the matrix 200 is a linear matrix of 12 elements 201 , with letters A, B, C, D, E and F. The user then enters, in a dedicated space of an interface, separate from the matrix 200, the signs corresponding to their secret MIP and which appear in the matrix elements 201 , in the correct order in which the signs appear in their MIP. In the case of Figure 3A, the user would enter the code“1 , 2, 3, 4, 5”, and in the case of Figure 3B, the user would enter the code“BFCE”.

The MIP is only known to the user, and it is critical that the pattern is never divulged. For effective security, it is essential that the signs presented in a challenge matrix 200 for an authentication operation are in some way randomized at each authentication operation. Thus the code entered by the user has the desirable property that the code changes on each authentication operation - this is denoted by the term one-time code (OTC). Further, it is an essential feature of all matrix pattern authentication approaches that each sign in a matrix is repeated more than once, and preferably many times. This is to ensure that when a user enters their OTC, their secret MIP is not divulged. In the case of Figure 3A, with 25 elements, if each sign is repeated five times, each number entered by the user corresponds to five possible different positions in the matrix. Consequently, the code“1 , 2, 3, 4, 5” corresponds to 3125 possible different patterns. In the case of Figure 3B, with the 12 element matrix, each letter corresponds to two possible positions in the matrix. Consequently, a four element code could represent 16 possible patterns. It is clear that the 25 element matrix, with a five element code and five unique signs is much more secure than the 12 element case.

Furthermore, any authentication system based upon a MIP keeps the pattern secret, in order to prevent hackers from gaining valuable information. Security of MPA technology is essential for their use, e.g. in any online system, especially in the case of financial transactions, access to personal data, etc. Consequently a method of storing sensitive information, particularly the user’s MIP, must be employed.

The MIP is therefore usually encoded, in general by hashing. There are many public domain encoding algorithms available. The most appropriate algorithms employ a technique known as “one-way cryptographic hashing”. This means that the sensitive information, in this case the MIP, once passed through a one-way hashing function, cannot be reversed. The sensitive information is encoded, and it is highly unlikely that anyone can retrieve the sensitive information. This means that even if a database with the encoded information is stolen, it would still be difficult to retrieve the sensitive information. Standard hashing algorithms (e.g. from the family SHA-2, such as SHA-256) and inclusion of at least one long salt should be applied to maximize the effectiveness of any encoding approach by hashing, and represents standard known best practice. Typically, in MPA technology, each element 101 in the matrix 100 is given a unique symbol, in order to represent the position of the element 101 within the matrix 100. Figure 4 shows a numeric indexing approach which is often utilized. For example, in the case of the 25 element matrix 100 of Figure 1 A, the elements might be numbered. In the example of Figure 2A, the MIP would be represented by the code“e6, e22, e13, e4, e10”.

Figure 5 shows schematically that, in a known processing of the MIP, when a user U selects in S1 their MIP, once they have confirmed the selection, the code representing their pattern is usually encoded using a one-way hashing function, in S1 1 , prior to being stored in S13 on a secure database 1 1 , e.g. as a record. Preferably, the system will retain any non-coded record of the MIP in a volatile memory which will be immediately discarded after processing such as encoding. This has the desirable property that the only place where a not encoded record of the MIP is stored is in the user’s mind. The known MPA technology has however drawbacks or deficiencies.

Consider an example, with a six element MIP and a 36 element matrix 200 with six unique signs (i.e. 1 , 2, 3, 4, 5 and 6), each repeated six times. An OTC entered by the user only ambiguously describes the MIP, as each digit of the OTC entered by the user represents six possible element positions on a challenge matrix 200. Therefore, in fact, any single six digit OTC describes 6 ^L 6 = 46,656 possible MIPS.

Only one of these is correct, but an authentication engine has no a priori knowledge as to which of these is the right one, because of the one-way hashing. An authentication engine needs therefore to generate all of the potentially-valid MIP combinations represented by the entered OTC and, in a similar manner as is explained in reference to Figure 5, each of these potentially-valid MIP combinations needs to be passed through the same encoding using the cryptographic one-way hashing function (as in S1 1), as the original MIP, prior to comparison with the encoded representation of the user’s MIP stored in the database 1 1 . Such repeated generations by encoding and comparisons need to continue until a match is found. It is only at this point that a positive authentication could be confirmed. The number of iterations required is random, albeit with a flat distribution. As a minimum, one iteration is required, as a maximum 46,656 iterations are required, in our example. Therefore on average 23,328 such iterations, comprising generation and comparison, will be required for a positive authentication.

This means that in the case of an incorrect OTC being entered by the user, the authentication system always has to perform the maximum number of iterations, in order to ensure that all possible valid combinations are examined, before eventually actually rejecting the authentication request. It is estimated that using the strong encoding algorithms that are necessary to defend against hackers (e.g. SHA-2), each individual encoding on an OTC takes between 0.1 ms and 1 ms on state of the art computer servers. Using 0.2ms as a representative processing speed, and continuing with our example, an average authentication request would take between 5 to 10 seconds to approve, in the case of a valid one-time code being entered. In the case of an incorrect OTC being entered, the time taken to produce a rejection of an authentication request will always be approximately 10 seconds (i.e. 46,656 x 0.2ms). In addition some secure system require to hash the MIP and/or password multiple times, which will further increase the processing time.

This processing overhead is unacceptable in a multi-user, cloud server environment, and the length of the MIP must be reduced.

However, simply reducing the length of the MIP is not a solution because a significant issue arises. That is any single individual authentication event performed for example on an individual authentication device 3 of Figure 5 (such as a laptop, a personal computer, a Personal Digital Assistant, a phone, a smartphone, or a dedicated token, etc.) is now vulnerable under brute force attacks. Furthermore, not reducing the length of the MIP is also not a solution because the encoding algorithms used to defend against hackers (e.g. SHA-2) are not sufficient to protect an individual authentication event performed for example on an individual authentication device 3 from brute force attacks. Aspects of the disclosure address or at least ameliorate at least one of the above issues.

According to some aspects, the disclosure provides methods according to claims 1 and/or 12 and/or 14 and/or 24. According to another aspect, the disclosure provides a device according to claim 42.

Aspects of the disclosure extend to computer program products such as computer readable storage media having instructions stored thereon which are operable to program a programmable processor to carry out a method as described in the aspects and possibilities set out above or recited in the claims and/or to program a suitably adapted computer to provide the system recited in any of the claims.

The disclosure has advantages over the prior art. The processing overhead generated by the one way hashing is perfectly acceptable in any one individual authentication event for example performed on an authentication device (such as a laptop, a personal computer, a Personal Digital Assistant, a phone, a smartphone, or a dedicated token, etc.).

The device has numerous applications, and can be associated with any type of key code lock, the lock being either an electronic lock (for locking a transaction) or a mechanical lock (for locking a door or the opening of any device). The device may be used to lock or unlock access to sensitive data stored in the memory of the device and/or e.g. to launch, or control access to, any third party applications on a device as a non-limiting example. The sensitive data may be encrypted and the device may enable locking/unlocking of the encryption of the sensitive data. The locking and unlocking modes could be synchronized, respectively, with the device LOCKED / UNLOCKED states. In some examples, the user may override the LOCKED / UNLOCKED states of the device. The disclosure enables the use of large square matrices which possess significantly greater entropy compared to known 5x5 matrices. For example, a 36 element (6 x 6) array has 2.1 billion potential combinations with a choice of six elements to make up a MIP. The disclosure also enables the use of MIP having a length of at least 6 elements, and therefore ensures that the probability of randomly guessing a MIP from an OTC at authentication is lower than the probability of randomly guess a classic four digit PIN (10,000:1). For example, with a choice of six signs each repeated six times in a challenge matrix, the probability of guessing the MIP in the random is 1/46,656 (46,656 = 6 ^L 6). Consequently the disclosure provides a MPA technology which has superior and sufficient entropy compared to the prior art, and also has superior and sufficient resistance to guessing an MIP compared to the prior art.

The processing overhead thus enables the authentication process not to be vulnerable under brute force attacks.

Additionally or alternatively, the identification of the device on which the challenge code is entered can also be taken into account, providing a two-factor system. Further, a biometric data, such as the voice of the user, can also be taken into account in the authentication operation, providing a three-factor system.

The disclosure has advantages in an offline security context. ln the context of offline security, the disclosure has the advantage of a long hashing processing time, which means that even if a hacker tries to perform a brute force attack, the challenge code would still be hard and long to process. Embodiments of the disclosure will now be described, by way of example, with reference to the accompanying drawings in which:

Figures 1A and 1 B, already discussed, schematically illustrate MPA matrices;

Figures 2A and 2B, already discussed, schematically illustrate MIP in the MPA matrices of Figures 1A and 1 B, respectively;

Figures 3A and 3B, already discussed, schematically illustrate challenge matrices corresponding to the MPA matrices of Figures 1A and 1 B, respectively;

Figure 4, already discussed, schematically illustrates an exemplary indexing of the MPA matrix of Figure 1 A;

Figure 5, already discussed, schematically illustrates an exemplary encoding of a MIP;

Figure 6 schematically illustrates an example of a device implementing a method according to the disclosure,

Figure 7 is a diagram illustrating steps of an exemplary method performed by the device of Figure 6;

Figure 8 is a diagram illustrating an exemplary method of Figure 7;

Figure 9 is a diagram illustrating further steps of an exemplary method performed by the device of Figure 6;

Figure 10 is a diagram illustrating steps of an exemplary method performed by the device of Figure 6;

Figure 1 1 is a diagram illustrating an exemplary method of Figure 10;

Figure 12 is a diagram illustrating further steps of an exemplary method performed by the device of Figure 6; and

Figure 13 is a diagram illustrating an exemplary method of creating a blockchain of transactions. In all of the Figures, similar parts or steps are referred to by like numerical references.

An aspect of the disclosure will now be described with reference to Figures 6 to 9.

The disclosure provides a method of encoding data 5. The data 5 may be created and/or received by a device 3 and/or stored in a memory 30 of the device 3. The memory 30 may comprise a non-volatile memory 33 and a volatile memory 34. The data 5 may be of any type, and may be initially in a non-encoded format, i.e. accessible format, for example stored on the memory 30 of the device 3.

As illustrated in Figure 8, in some examples, the data 5 may comprise an authentication code 51 of a user U. The authentication code 51 may be of any type, such as a password. In some examples, the authentication code 51 of the user U may comprise elements e based on a memorable identification pattern, MIP, 6 associated with at least one authentication arrangement 100.

Alternatively or additionally, in some examples, the data 5 may comprise a data encryption key 52 configured to encrypt, e.g. at 12 in Figure 8, sensitive data 11 1 stored in the memory 30 of the device 3 and/or decrypt, e.g. at 14 in Figure 1 1 , encrypted sensitive data 1110 stored in the memory 30 of the device 3. In some examples, the encrypted sensitive data 1 110 (i.e. the sensitive data 1 11 in encrypted format) may be stored in a secure data store 1100 of the memory 30 of the device 3. Alternatively or additionally, in some examples, the secure data store 1100 may be a sensitive data store, SDS. The sensitive data may be any type of data, such as data comprising files corresponding to a text, a picture, an audio and/or a video.

As illustrated in Figure 7, in an example, the method of encoding the data 5 mainly comprises the steps of:

generating, at S30 (for example also referred to as S30(n) in Figure 7), a challenge code 7

(sometimes referred to as“one-time code” (OTC), for example also referred to as challenge code 7(n) in Figure 8);

encrypting, at S32 (for example also referred to as S32(n) in Figure 7), the challenge code OTC 7 using a one-way hashing function 9 to obtain a temporary encryption key (sometimes referred to as“Kt”, for example also referred to as Kt(n) in Figure 8); and

generating encoded data 50 by encoding, at S34 (for example also referred to as S34(n) in Figure 7), the data 5 using a two-way transcoding function 10 using the obtained temporary encryption key Kt. As will be apparent to the skilled in the art, in the following specification, the device 3 further comprises at least a processor 35 in order to perform at least partly the different steps of the method. As explained in further detail below, the device 3 may be any type of device such as a laptop, a personal computer, a Personal Digital Assistant, a phone, a smartphone, or a dedicated token, etc. In some examples, the device 3 may be linked to a network, and may preferably use wireless technology to communicate with the network. In that case, the device 3 may be configured to communicate with cellular base stations (using mobile technology) and/or other Wireless Access Points (using other wireless communications) such as WiFi, Bluetooth™ or near-field technology (also called sometimes“Near Field Communication” or“NFC”). The device 3 may also use wired access point (such as a wired modem) to communicate with the network. The communication between the device 3 and the network may preferably comply with Secure Socket Layer (SSL) or Transport Layer Security (TLS) protocols known by the skilled person in the art.

As will be apparent to the skilled person in the art, in the following specification, the device 3 also should not be understood as a limited natural entity, but may rather refer to physical devices comprising at least a processor and a memory, and the processor and the memory may be comprised in one or more apparatuses and/or servers which can be located in a single location or can be remote from each other to form a nebulous network (such as server farms). As already stated, the device 3 may therefore comprise for instance a laptop, a personal computer, a Personal Digital Assistant, a phone, a smartphone, etc., thus comprising a display 31 and an interface 32, for selecting the authentication code 51 and/or transmitting it to the network during a registration operation. In some examples, a single device 3 may perform the selecting of the authentication code 51 during the registration operation, and also the displaying of a challenge arrangement 200 to a user during an authentication operation. Alternatively or additionally, the device 3 may comprise a separate dedicated token comprising a display for displaying the challenge arrangement 200 to the user during the authentication operation.

It should be appreciated that Figure 6 shows functional block diagrams, and that in practice the individual blocks shown in Figure 6 may exist as discrete elements or their functionality may be distributed in different combinations or not individually discernable. In that respect, some of the functionality of the device 3 may be distributed in different combinations or may be at least partially merged.

The authentication code 51 has a length L of at least six elements e, and users U are encouraged to have codes 51 greater than six if possible. The code 51 may be allocated to the user U by an administrator. However as already mentioned the device 3 is preferably configured to enable the user U to select their authentication code 51. Optionally, the code 51 is modified at user-configurable or administrator-configurable times, as variable code lengths are a strong security feature, adding significantly to entropy.

As illustrated in Figure 8, the code 51 is associated with the memorable identification pattern MIP 6, based on an authentication arrangement 100, preferably but not exclusively used in a Matrix Pattern Authentication (MPA) 100 and the elements of the code 51 form a set of the elements of at least one authentication array or arrangement 100 comprising S symbols s, preferably unique symbols. In some aspects of the disclosure, once the authentication code 51 is confirmed by the user U, e.g. on the device 3, the device 3 may save the code 51 in the memory 30 of the device 3. In some examples, the data 5 may initially be stored in the volatile memory 34 of the device 3. This feature strengthens security because if the device 3 is switched off, the data 5 is lost and the encoding cannot be performed.

In some examples, the authentication code 51 may initially be stored in the volatile memory 34 of the device 3. Similarly, in some examples the data encryption key 52 may initially be stored in the volatile memory 34 of the device 3.

In some examples, the generated challenge code OTC 7 may be based on a pattern 206 associated with at least one challenge arrangement 200 comprising duplicated signs 201 (for example also referred to as challenge arrangement 200(n) in Figure 8).

In some examples, obtaining at S30 the challenge code OTC 7 may comprise generating a sequence 7 of signs 71 corresponding to the elements 201 , based on the MIP 6, and appearing in the challenge arrangement 200. The generating may be performed automatically by the processor 35 of the device 3.

Alternatively or additionally, the generating of the sequence 7 may comprise obtaining from the user U the sequence 7 of signs 71 in a dedicated space of an interface 32 of the device 3. In some examples, the device 3 may enable the user U to enter, during an authentication operation e.g. via any Human User interface mechanism, such as part of a logon process for a device 3 being a smartphone or an Internet browser, at least the one time code OTC 7, associated with the challenge array 200. As already stated, the OTC 7 comprises the signs 201 corresponding to the pattern 206 presented in the challenge matrix 200, as the user U enters, in the dedicated space of the interface 32, separate from the matrix 200, the signs corresponding to their secret MIP 6 and which appear in the matrix 200 of elements 201 , in the correct order in which the signs appear in their MIP 6.

Preferably the device 3 may enable the user U to enter also any type of user identification. In some examples the device 3 is configured to belong to the user U such that entering of user identification may not be needed. ln some examples, the one-way hashing function 9 used at S32 may comprise a PBKDF2 algorithm. The function 9 may thus be a slow hashing algorithm, intensive with respect to the computation and/or the memory required. The function 9 may enable to reinforce protection against brute force attacks. In some examples, the one-way hashing function 9 uses a salt 8. In some examples, the salt 8 may be stored in the memory 30 of the device 3. In some examples, the salt 8 may be stored in the nonvolatile memory 33 of the device 3. Alternatively or additionally, in order to further security, the salt 8 may be stored only in the volatile memory 34 of the device 3, such that if the device 3 is switched off, the salt is lost and the encoding cannot be performed.

In some examples, additionally or alternatively, the one-way hashing function 9 uses a User Device ID 13 and furthers security of the one-way hashing function 9.

In some examples, the two-way transcoding function 10 may comprise an AES256 algorithm. The AES256 algorithm is a strong two-way transcoding algorithm. The algorithm may enable to reinforce protection against brute force attacks.

At S34, the encoded data 50 is generated by encoding the data 5 using the two-way transcoding function 10 using the obtained temporary encryption key Kt. In some examples, the encoded data 50 (i.e. the data 5 in encoded format) may be stored in a secure data store 50 of the memory 30 of the device 3. Alternatively or additionally, in some examples, the secure data store 50 may be an authentication information store, AIS.

With reference to Figure 9, in some examples, the encoded data 50 may be stored, at S341 , in the memory 30 of the device 3, for example for use in an authentication of the user U as explained in further detail below. In some examples, the encoded data 50 may be stored in the non-volatile memory 33 of the device 3. The non-volatile memory 33 of the device 3 may thus comprise a dedicated store, such as an authentication information store where the encoded data 50 may be stored.

In some examples, alternatively or additionally, in order to further security, the data 5 may be deleted, at S342, from the memory 30 of the device 3 once the encoded data 50 is stored in the memory 30 of the device 3. In some examples, alternatively or additionally, in order to further security, the temporary encryption key Kt may be deleted, at S343, from the memory 30 of the device 3 once the encoded data 50 is stored in the memory 30 of the device 3. In some examples, alternatively or additionally, in order to further security, the temporary challenge code 7 (one time code OTC 7) may be deleted, at S344, from the memory 30 of the device 3 once the encoded data 50 is stored in the memory 30 of the device 3.

It is understood that, at the end of S34, access to the encoded data 50 is locked. In some examples, the encoded data 50 may comprise:

the encoded authentication code 510 (i.e. the authentication code in an encrypted format using e.g., an AES256 algorithm using the temporary encryption key Kt); and/or

the encoded data encryption key 520 (i.e. the data encryption key in an encrypted format using e.g., an AES256 algorithm using the temporary encryption key Kt).

At the end of S34, when the data 5 stored in the memory of the device 3 is configured to encrypt sensitive data 1 1 1 stored in the memory 30 of the device 3 (for example when the data comprises a data encryption key 52), access to the encrypted sensitive data 1 1 10 is locked, because access to the data 5 is locked - since the data 5 is stored in an encoded format as described above.

An aspect of the disclosure will now be described with reference to Figures 10 to 12 in connection with Figures 6 to 9 already discussed.

In some examples the disclosure provides a method of authentication of the user U of the device 3. As it will be appreciated below, in some examples, the authentication may result from a validation of an encoding of a challenge code. As illustrated in Figure 10, in some examples the method may mainly comprise the steps of:

obtaining, at S40 (for example also referred to as S40(n) in Figure 10), a challenge code OTC 7 (for example also referred to as challenge code 7(n) in Figure 1 1 ) from the user;

encrypting, at S42 (for example also referred to as S42(n) in Figure 10), the challenge code OTC 7 using a one-way hashing function 9 to obtain a temporary encryption key Kt (for example also referred to as Kt(n) in Figure 1 1 ); and

validating, at S44 (for example also referred to as S44(n) in Figure 10), the challenge code OTC 7 if the obtained temporary encryption key Kt(n) matches a temporary encryption key Kt(n) used to encode, for example at S34(n) already described in reference to Figure 7, data 5 using a two-way transcoding function 10.

The encoded data 50 may be created and/or received by the device 3. In some examples, the encoded data 50 may be stored in the memory 30 of the device 3, for example in the non-volatile memory 33 of the device 3. In some examples, the encoded data 50 (i.e. the data 5 in encoded format) may be stored in a secure data store 50 of the memory 30 of the device 3. Alternatively or additionally, in some examples, the secure data store 50 may be an authentication information store, AIS.

With reference to Fig. 11 , in some examples the challenge code 7 may be based on a pattern 206 associated with at least one challenge arrangement 200 comprising duplicated signs 201 (for example also referred to as 200(n) in Figure 11), as the user U enters, in the dedicated space of the interface 32, separate from the matrix 200, the signs 201 corresponding to their secret MIP 6 and which appear in the matrix 200 of elements 201 , in the correct order in which the signs appear in their MIP 6.

In some examples, the one-way hashing function 9 used at S42(n) may comprise a PBKDF2 algorithm. The function 9 may thus be a slow hashing algorithm, intensive with respect to the computation and/or the memory required. The function 9 may enable to reinforce protection against brute force attacks.

In some examples, the one-way hashing function 9 uses the salt 8. In some examples, the salt 8 may be stored in the memory 30 of the device 3. In some examples, the salt 8 may be stored in the nonvolatile memory 33 of the device 3. Alternatively or additionally, in order to further security, the salt 8 may be stored only in the volatile memory 34 of the device 3, such that if the device 3 is switched off, the salt is lost and the validating cannot be performed.

In some examples, additionally or alternatively, the one-way hashing function 9 uses the User Device ID 13 and furthers security of the one-way hashing function 9.

In some examples, at S44(n), the two-way transcoding function 10 may comprise an AES256 algorithm. The AES256 algorithm is a strong two-way transcoding algorithm. The algorithm may enable to reinforce protection against brute force attacks. At S42(n), if the obtained temporary encryption key Kt(n) matches the temporary encryption key Kt(n) used to encode, for example at S34(n) already described in reference to Figure 7, data 5 using the two-way transcoding function 10, it is understood that the OTC 7(n) matches the OTC 7(n). This is because, as explained in greater detail below, the challenge array 200(n) of Figure 7 matches the challenge array 200(n) of Figure 1 1. The OTC 7(n) is thus validated. In other words the user U has entered the correct OTC 7, which means that they know the MIP 6 and access should thus be unlocked. With reference to Figure 12, alternatively or additionally, at S44(n), if the OTC 7 is validated, the method may further comprise the decoding, at S4401 , of the encoded data 50, using the obtained temporary encryption key Kt(n), in order to obtain decoded data 5. The data 5 may comprise the authentication code 51 of the user U and/or the data encryption key 52 configured to decrypt, e.g. at 14 in Figure 1 1 , encrypted sensitive data 1 1 10 stored in the memory 30 of the device 3. In some examples, the encoded data 50 (i.e. the data 5 in encoded format) may be stored in a secure data store 50 of the memory 30 of the device 3. Alternatively or additionally, in some examples, the secure data store 50 may be an authentication information store, AIS. In some examples, at S4402, the decoded data 5 (e.g. the data encryption key 52) may be stored in the memory 30 of the device 3. In some examples, to further security, the decoded data 5 may be stored in the volatile memory 34 of the device 3.

In some examples, at S4403, the obtained temporary encryption key Kt(n) may be deleted from the memory 30 of the device 3, so it cannot be used in a further encoding of data 5 stored in the memory 30 of the device 3.

In some examples, the decoded data 5 may be configured to decrypt sensitive data 1 1 10 stored in the memory 30 of the device 3 (for example when the data 5 comprises a data encryption key 52). The validation may therefore unlock access to the decrypted sensitive data 1 1 1 , e.g. by allowing decryption 14 of the encrypted data in the store 1 100 as illustrated in Figure 1 1 . The user may therefore read and/or write sensitive data 1 1 1 from and/or into the sensitive data store of the device 3. Alternatively or additionally, the user may launch, or control access to, any third party applications on a device as a non-limiting example.

The user may access (e.g. read and/or write) the sensitive data 1 1 1 from and/or into the sensitive data store of the device 3 as long as the decoded data 5 (e.g. the data encryption key 52) is stored in the memory 30 of the device 3 (e.g. in the volatile memory 34 of the device 3). In some examples, alternatively or additionally, the method may comprise a new iteration of any of the methods shown in Figures 7, 8, 9, 10, 1 1 and/or 12.

In some examples, and as illustrated in Figure 7 with n set to (n+1) and Figure 1 1 , the method may further comprise generating a subsequent challenge code OTC 7 (n+1 ) for a subsequent encoding of the decoded data 5. In some examples the subsequent challenge code 7(n+1) may be based on a pattern 206 associated with at least one subsequent challenge arrangement 200(n+1) comprising duplicated signs 201 . As described with reference to Figures 7 and 8 with n being set to (n+1), the method may further comprise encrypting the subsequent challenge code 7(n+1) using the one-way hashing function 9 to obtain a subsequent temporary encryption key Kt(n+1). As described with reference to Figures 7 and 8 with n being set to (n+1), the method may further comprise generating subsequent encoded data 50 by encoding the data 5 (the data 5 may comprise the authentication code 51 of the user U and/or the data encryption key 52) using the two-way transcoding function 10 using the obtained subsequent temporary encryption key Kt(n+1). In some examples, the generating, the encrypting and the generating as shown in Figures 7 and 8 with n being set to (n+1) may occur concurrently or shortly after the validating, at S44, of the challenge code OTC 7(n). With reference to Figure 9, in some examples, the encoded data 50 (i.e. the data 5 in encoded format) may be stored in a secure data store 50 of the memory 30 of the device 3, e.g. at S341 , concurrently or shortly after the validating, at S44, of the challenge code OTC 7(n). Alternatively or additionally, in some examples, the secure data store 50 may be an authentication information store, AIS. However the user may access (e.g. read and/or write) the sensitive data 1 1 1 from and/or into the sensitive data store of the device 3 and/or launch an application as long as, e.g. a copy of, the decoded data 5 (e.g. a copy of the data encryption key 52) is stored in the memory 30 of the device 3 (e.g. in the volatile memory 34 of the device 3). In other words, and with reference to Figure 9, the data 5 may not be deleted straight away, at S342, from the memory 30 of the device 3 once the encoded data 50 is stored in the memory 30 of the device 3. In some example the data (e.g. a copy of the data) may be deleted after a period of time or after the device 3 is turned off, as non-limiting examples.

In some examples, alternatively or additionally, in order to further security, the temporary encryption key Kt may be deleted, at S343, from the memory 30 of the device 3 once the encoded data 50 is stored in the memory 30 of the device 3.

In some examples, alternatively or additionally, in order to further security, the temporary challenge code 7 (one time code OTC 7) may be deleted, at S344, from the memory 30 of the device 3 once the encoded data 50 is stored in the memory 30 of the device 3.

As shown in reference to Figures 8 and 1 1 with n set to (n+1), the subsequent challenge arrangement 200(n+1) may be, and preferably is, different from the current challenge arrangement 200(n). It is also understood that the challenge arrangement 200 used in a following decoding (i.e. of rank (n+1) with reference to Figure 1 1) matches the subsequent challenge arrangement 200(n+1). It is thus understood that the new iteration of the steps of the method corresponds, as shown in Figure 10, to a new iteration of the steps as described in reference to Figure 7, with n set to (n+1).

Similarly, it is thus understood, in reference to Figures 7, 8, 10 and 11 with rank (n) describing the current stage, that in another aspect of the present disclosure, it is described a method of sequentially encoding and decoding data, comprising the steps of:

generating a current challenge code 7(n) for a current encoding of the data 5, the current challenge code 7(n) being based on a pattern 206 associated with at least one current challenge arrangement 200(n) comprising duplicated signs 201 ;

encrypting the current challenge code 7(n) using a one-way hashing function 9 to obtain a current temporary encryption key Kt(n);

generating encoded data 50 by encoding the data 5 using a two-way transcoding function 10 using the obtained current temporary encryption key Kt(n);

obtaining a user challenge code 7(n) from the user, the user challenge code 7(n) being based on the pattern 206 associated with the at least one current challenge arrangement 200(n) comprising the duplicated signs 201 ,

encrypting the user challenge code 7(n) using the one-way hashing function 9 to obtain a user temporary encryption key Kt(n); and

decoding the encoded data 50 using the two-way transcoding function 10 and the user temporary encryption key Kt(n) if the user temporary encryption key Kt(n) matches the obtained current temporary encryption key Kt(n) used to encode the data 5.

Similarly, it is thus understood, in reference to Figures 7, 8, 10 and 11 with rank (n) describing the current stage, that in another aspect of the present disclosure, it is described a method of sequentially encoding and decoding data, comprising the steps of:

obtaining a current challenge code from the user for a current decoding of encoded data stored in the memory of the device, the current challenge code being based on a pattern associated with at least one current challenge arrangement comprising duplicated signs;

encrypting the current challenge code using a one-way hashing function to obtain a current temporary encryption key ;

validating the current challenge code if the current temporary encryption key matches a previous temporary encryption key used to encode the data using the two-way transcoding function; decoding the encoded data using the two-way transcoding function and the current temporary encryption key;

generating a subsequent challenge code for a subsequent encoding of the decoded data, the subsequent challenge code being based on a pattern associated with at least one subsequent challenge arrangement comprising duplicated signs; encrypting the subsequent challenge code using a one-way hashing function to obtain a subsequent temporary encryption key;

generating subsequent encoded data by encoding the data using a two-way transcoding function using the obtained subsequent temporary encryption key.

In some examples, the steps of generating a subsequent challenge code for a subsequent encoding of the decoded data; encrypting the subsequent challenge code using a one-way hashing function to obtain a subsequent temporary encryption key; and generating subsequent encoded data by encoding the data using a two-way transcoding function using the obtained subsequent temporary encryption key may be performed concurrently or shortly after the step of decoding the encoded data using the two-way transcoding function and the current temporary encryption key.

The user may access (e.g. read and/or write) the sensitive data 1 1 1 from and/or into the sensitive data store of the device 3 as long as the decoded data 5 or a copy of the decoded data 5 (e.g. the data encryption key 52) is stored in the memory 30 of the device 3 (e.g. in the volatile memory 34 of the device 3).

As illustrated in Figure 13, the method may further comprise a step 15 of creation of a blockchain of transactions (such as encoding data and/or decoding data). It should be understood that at each iteration n (e.g. authentication) a new temporary encryption key Kt(n) is generated, which itself may be optionally timestamped at 16, and hashed to create a blockchain history of authentication events. This may create a blockchain of transactions which may have strong authentication built into each transaction. In some examples, a local copy of the authentication history can be kept on the device 3, and/or a copy of the blockchain may be shared with any third party blockchain application.

In embodiments of the disclosure, all authentication steps may be performed on the (e.g. mobile) device 3 only. The method may be Operating System (OS) agnostic, such that no OS jailbreaking may be necessary. In some embodiments, the method may further comprise a step of either delete and/or make unreadable information in the secure data store, in the event of compromise.

In embodiments of the disclosure, work load of an operator may be minimized, and several authentication steps may be avoided. As already explained below, the disclosure applies to any authentication arrangement 100 of size S used in any MPA system, not only those of a square form factor. However in some examples the array may have a square form factor and:

L = 6

5 36

The disclosure provides therefore offline security, because the hashing processing time is sufficiently long. Table 1 below shows the processing time required to process the MIP, based on an indicative 0.2ms per hashing operation.

Table 1 The length of the authentication code enables achieving acceptable offline security. Therefore the disclosure enables the use of MPA of square form factors and with MIP of a length L with L>6.

In some aspects of the disclosure, each authentication arrangement 100 has a square form factor a, wherein

a ³ 6

with a being a linear dimension of the matrix, each matrix having a size S equal to a ² elements 101 .

The disclosure can be applied to an optimal family of matrices of length (or size) S, wherein a balance between the uniqueness of signs s (providing a high level of entropy) and non-reversability of the OTC (given by the duplication of the signs s) is given by the solution of equation (E2):

S

n = - (E2)

n where n is the number of times each different type of signs are replicated in each challenge arrangement 200, and

S/n is the number of different signs in each challenge arrangement 200 (also referred to as m below).

The solution of (E2) is:

n = V S

Therefore preferably each challenge arrangement 200 has a square form factor a, wherein

m = n = a

and

a ³ 6

with a being a linear dimension of the matrix, each matrix having a size S equal to a ² elements 201 ;

m (=S/n) being the number of different signs in each challenge arrangement 200; and n being the number of times each different type of signs are replicated in each challenge arrangement 200.

The MPA according to the disclosure has better practical entropy compared to a one dimensional linear array or arrangement.

As stated above, the disclosure enables the use of an ideal configuration which has a square pattern and is therefore advantageous compared to a rectangular array which tends to suppress entropy. Also as stated above, the disclosure enables the use of the ideal configuration where each symbol of the challenge matrix is repeated n=sqrt(S) times, where S is the number of elements (or the size) in the challenge matrix. Thus, it is desirable that a matrix has a number of elements that is a square number, i.e. 4, 9, 16, 25, 36, 49, 64, 81 etc. This is to ensure that signs in a matrix are repeated an integer number of times, with no bias in favour of any particular sign. Such a bias would compromise security effectiveness.

However the disclosure is not limited to n = s . The use of m unique signs, with m ¹ n ¹ a is also possible and sometimes advantageous. For example, in a matrix with a = 6 (36 elements), the case m = 9, with n = 4 (each of the nine signs is repeated four times) is also possible and sometimes advantageous. Other examples for a, m or n are possible. Preferably“a” is an integer number between six and ten, for example nine unique signs in a 9x9 matrix, and so on.

Therefore a 36 element array with 6 unique different signs with each sign being repeated six times (i.e. a 6 x 6 x 6 x 6 configuration) with a six element MIP is the minimum configuration that has sufficient entropy, having the further advantage of having the property that the probability of guessing a correct OTC (i.e. 1/46,656) is much better than guessing a conventional four-digit PIN number.

Modifications and Alternatives

As already described, the authentication operation performed on the device 3 may take into account device identification 13. It is therefore sometimes referred to as a two-factor device. Identification of the device 3 may comprise any unique identification, hereafter referred to as 13, such as a serial number of any part of the device and/or an International Mobile Equipment Identity (IMEI), etc. Preferably, both a type of device and/or a selected device and a type of authentication operation and/or a selected authentication operation are user-configurable or operator-configurable. The user U may therefore e.g. choose one of his registered devices 3 for authentication regarding bank transactions and another one of his registered devices 3 for online payments. The operator may also e.g. ban a type of devices for highly secure transactions. Alternatively or additionally, the salt and/or the data encryption key maybe user-configurable and/or operator-configurable and/or application- configurable.

The device 3 may be adapted to read and/or recognize biometric data from the user U. The device 3 may thus be a three-factor device. The biometric data maybe a voice and/or a shape of the face and/or the image of the iris, and/or a fingerprint of the user U.

The present disclosure may be applied to any form of secret information, and the authentication code described above may be any secret information, such as passwords, passcodes, and personal information, including biometric information.

It is understood that the authentication code described in the specification is not limited to an authentication code derived from a MPA. The authentication code of a user may further be any type of password, number, ID, etc. It is understood that the processing of the authentication codes and challenge codes, such as encoding, decoding and storing according to the disclosure may be performed on any type of such authentication code and challenge codes. Detailed embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiments whilst still benefiting from the disclosures embodied therein. In the embodiments described above, the processor is typically implemented as software run by a corresponding controller. However, in some embodiments, the processor may be formed, where appropriate, by hardware, software, firmware or any combination thereof. A software implementation may however be preferred to facilitate the updating of the functionality of the processor. Where software are provided, they may be provided, as appropriate, in compiled or un-compiled form and may be supplied to the processing module, the authentication engine or to the device, as the case may be, as a signal over a computer or telecommunications network, or on a computer storage medium such as for instance a disc, an optical disc or a CD ROM. It should of course be appreciated that, although not explicitly shown in Figure 6, the processor will have all of the functionality necessary to enable it to operate as the processor, in the particular device in which it is designed to function.

Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.