"ELECTRONIC SYSTEM FOR SECURE AUTHENTICATION OF A USER'S IDENTITY"

DESCRIPTION

Field of the invention

The present invention relates to a mode of secure authentication of a user's identity which is alternative or additional to those currently in use, and which is useful to increase security in network transactions, and can be adopted on a wide variety of user terminals with a very high level of security and with a specific guarantee on network transactions. In particular, the present invention relates to an electronic system for secure authentication of a user's identity.

Background art

Nowadays it has become increasingly common to use and access remote services over networks; therefore, prior to granting access it is necessary that the user be identified and authenticated. Many authentication techniques are known which are useful to gain access to computer systems or services using network connections (mobile network, the Internet, and the like).

Some known techniques provide session-based authentication among devices such as apparatuses connected to the Internet, i.e. laptop computers, smartphones, tablets and systems such as Internet-based web services, servers, or other network-connected apparatuses.

Network authentication systems typically utilize public-key encryption systems, also called asymmetric-key systems, which are considered to be very robust from a mathematical viewpoint, but complex from a computational viewpoint, so much so that they are often used for exchanging symmetric encryption keys, so that the system can, after a first authentication, use simpler systems for subsequent secure communications. Asymmetric-key encryption is based on the use of two keys, a private one and a public one. The private key must be held confidential and must never be communicated. After having obtained the authorization from a Registration Authority (RA), which verifies and records the applicant's identity, the user creates both keys and deliver the public one to a Certificate Authority (or Certification Authority, CA, a body that declares that the public key is actually associated with that user), which generates the certificate, saves it into a certificate directory, and sends it to the same user. Upon receiving the certificate with the public key, the user has the possibility of using the keys also for authentication or electronic signature of messages. Therefore, if the user wants to send a "certified or authenticated" message to an interlocutor, he will have to use his own private key in order to decrypt the message and then send it, and the receiver, by using the public key, will be able to decrypt and read the message, the origin of which will have been thus certified. Public-key systems are dependent on the security of the private key: should the latter be stolen or copied, then the system will no longer be secure. Most network-based authentication systems utilize a third party, typically the Certification Authority, to guarantee authentication between two interlocutors in the network, who will generally be referred to herein as a and β.

Furthermore, many authentication techniques are based on a single authentication factor that may cause exposure to potential attacks, as is the case when a password is stolen. Many systems adopt, therefore, an authentication method with two authentication factors, resulting in the adverse effect of overloading the processor of the apparatus, which will be slower (in the best of cases) in providing the services. As an alternative, the methods with two authentication factors require an additional hardware apparatus which is uncomfortable for the user to handle.

Other authentication systems send, over a channel that is alternative to the one used for accessing the service, some information to be used for the second authentication factor. A system is known wherein a temporary password (generally called OTP, One Time Password) is sent to the user's phone, to be used as a second authentication level.

As is known, every algorithm for generating random numbers is subject to theoretical vulnerabilities, and this is why random numbers are not widely used in the Internet unless encrypted. For this very reason, in patent US2007/0172041 random numbers are only used for a physical proximity check, not for authentication in the Internet network. In patent US2007/0172041, a generic random number and the associated sequence number from which it has been generated are sent encrypted for possible authentications. The encryption employed in patent US2007/0172041 is a public-key encryption, and therefore requires certificates, containing the public keys, to be released by a Certification Authority. As will be explained below, the present invention does not require such public-key encryption, because it implements a method that will not allow determining, by using a theoretically known method, how the random numbers have been generated, so that it will be computationally costly for an attacker to determine even past random numbers.

Summary of the invention

It is therefore an object of the present invention to propose an electronic system for secure authentication of a user's identity, which can overcome the above-mentioned drawbacks.

The present invention relates to an electronic system for secure authentication of a user's identity, said system comprising at least one first user apparatus subject to said secure authentication, and one or more further apparatuses bidirectionally communicating with each other and with said first apparatus, characterized in that:

- said first apparatus (a) and a second apparatus (β), belonging to said one or more further apparatuses, comprise an equal system generating a random number (Ml) composed of any number of digits, said random number (Ml) being divided into a first part (SGN) and, respectively, a second part (CSGN), which are complementary and subsets of said random number (Ml);

- said first apparatus (a) comprises means for generating, through said generating system, said first part (SGN), and for sending it to said second apparatus (β);

- said second apparatus (β) comprises means for generating, through said generating system, said second part (CSGN) via generation of one or more of said random number

(Ml), each one characterized by a corresponding first part (SGN'), and means for comparing said corresponding first part (SGN') thus generated with said first part (SGN) received from said first apparatus (a), determining said second part (CSGN) associated with the corresponding first part (SGN') equal to the first part (SGN) received, and means for sending said second part (CSGN) to said first apparatus (a), thereby attaining said secure authentication of the identity of a user associated with said first apparatus.

It is another object of the present invention to provide a user terminal adapted to carry out the functions of said first apparatus.

The system of the invention is a system wherein, advantageously, the two parts authenticate each other, without requiring a third party and without the need for a Certification Authority, unlike public-key algorithms. Moreover, the system can be added to existing ones, because it has an extremely low processor load and therefore can be implemented by means of low-power processors or coexist with more complex processings, such as those of public-key algorithms.

It is a particular object of the present invention to provide an electronic system for secure authentication of a user's identity and an associated user terminal as set out in the claims, which are an integral part of the present description.

Brief description of the drawings

Further objects and advantages of the present invention will become apparent from the following detailed description of a preferred embodiment (and variants) thereof referring to the annexed drawings, which are only supplied by way of non- limiting example, wherein:

Figures 1 to 4 show some variants of sequences of steps carried out by the system for secure authentication of a user's identity according to the present invention;

Figures 5 to 11 show some variants of application of said sequences of steps on generic terminals.

In the drawings, the same reference numerals and letters identify the same items or components.

Description of some embodiments

The present invention relates to an electronic system for secure authentication of a user's identity, which utilizes a series of high-security procedures (or algorithms) which can be used by portable and fixed devices, such as smartphones, smart cards, personal computers and the like.

The advantage offered by the present invention is that it guarantees network transactions and provides increased security for connected systems because it can be added to existing systems.

The present invention describes procedures that can be carried out by processors, computer systems and information technologies for implementing application programming interfaces (API) automated and distributed among different main apparatuses.

The networks useful for connecting said processor systems may be of any kind: local connections through radio-frequency apparatuses, such as those used by RFIDs (Radio Frequency Identification), LAN (Local Area Network), optical data transport by video camera, WiFi connections, 3G or LTE (Long Term Evolution ) or 4.5G or 5G mobile connections, the Internet network, or anyway connections over the Internet Protocol (IP) or over optical fiber or the like, and future evolutions of such technologies. The connections can also be effected via messaging over chat systems (such as, for example, Whatsapp, Facebook Messenger, Wechat, Telegram, Short Message Services (SMS), MMS, e-mail, or the like. A potential use of the described functionalities can be effected in the so-called chatterbots. A chatterbot or chatbot is software designed for simulating an intelligent conversation with human beings through the use of voice or text, and is mostly used for implementing services by using the natural language in messages or conversations.

The present method and the associated system can be implemented and used in different ways.

In accordance with some basic aspects of the present invention, it is provided for generating a random number Ml; such number Ml is divided into two parts: SGN and CSGN. The two parts SGN and CSGN are complementary and subsets of Ml, and therefore the methods that can be used by those skilled in the art in order to derive SGN and CSGN from Ml are numerous.

Let it suffice to say, by way of example, that SGN may be the number obtained by extracting the digits of Ml in the even positions and CSGN the number obtained from the digits of Ml in the odd positions, as shown in 1003 of Figure 1.

The component subset SGN can be derived from Ml in many ways: still by way of example, we can say that the subset digits, extracted from Ml, can be arranged in SGN (or in CSGN) in any manner, just because a and β share the same means for generating SGN and CSGN starting from Ml .

SGN, for example, may contain two thirds of the digits of Ml, so that on the a side it could be possible to extract from Ml two digits, skip one, and then extract the two next digits and skip one again, then iterating this sequence up to the last digit contained in Ml : actually, however, the methods for extracting two thirds of the digits contained in Ml may be numerous, and depend on how this function is implemented in a and β. The number of all possible subsets of Ml is equal to 2 ^A (number of digits of Ml), from which one is subtracted in order to not count the empty subset (two raised to an exponent equal to the number of digits of Ml minus one). The subset of digits extracted from Ml can then be arranged in SGN (or in CSGN) in any order.

The following will provide a general description of the use of SGN and CSGN.

Two entities or apparatuses a and β share the same algorithm for generating Ml and the same initialization, and therefore will use SGN and CSGN for authenticating or setting a seal on a given message.

Therefore, a can send SGN to β and wait for β to reply with CSGN, as shown in Figure 5. In order to reply with CSGN, the entity β, which has received the "challenge" consisting of SGN, will have to calculate one or more Mis until the received SGN matches one of the calculated ones, β will reply by sending a CSGN corresponding to and associated with the received and calculated SGN.

For the purpose of making false matches less probable, it is useful to introduce some overlaps between the digits of SGN and those of CSGN, as shown in 1003 of Figure 1. The number of overlapped digits between SGN and CSGN may be different: the more the overlapped digits, the less likely will a false match occur. The number of overlapped digits is a feature that can be configured by the system in such a way as to increase the overlapped digits if the system cannot handle a false match. Conversely, the system may have less overlapped digits if, when a false match occurs, the system can detect it and make a second attempt.

The possibility of having two numbers with a configurable partial overlap constitutes one possible implementation of the present invention. In a primary embodiment, a few bytes constituting the checksum of the digits of SGN and CSGN are added at the beginning or at the end of the message in which SGN and CSGN are being sent. A checksum, as is known, is a sequence of bits that, being associated with the packet being transmitted, is used for verifying the integrity of a datum or a message that may undergo alterations during the transmission over a communication channel.

Every time SGN or CSGN is received, therefore, the system will, prior to checking that the received digits match those generated locally, start a checksum-based integrity check on the received data.

The option of calculating many Mis, rather than just one Ml, before obtaining the correspondence, is called "proof of work". The "proof of work" is the machine time that the processor must use in order to calculate different Mis (e.g. more than one thousand) before it finds the one corresponding to the received SGN "challenge". SGN matching may occur, therefore, either with or without "proof of work", depending on the level of security required. The "proof of work" is therefore an optional feature of the present invention, useful for increasing the security level. An interceptor of the messages between a and β will not be able to reconstruct CSGN by reading SGN, and therefore CSGN can be used in a very general way, e.g. for:

a) validating the reception of messages,

b) validating transactions of any kind,

c) authenticating an identity in communications. In this case, the interlocutor can be authenticated without requiring any mediation by a third party; therefore, if a and β want to rely on an additional mode of authentication in network communications, they can implement the system and method proposed herein.

This system does not require a third-party certification body and has the advantage that is can be superimposed on other authentication systems: if a and β have been authenticated with a first authentication factor and have started the communication, they can then start the second authentication procedure, one sending SGN and the other replying with CSGN.

The code Ml can be generated by a known algorithm (pseudo random generators such as, for example Yarrow, Rule 30, Xorshift, FreeBSD, AIX, OS X, NetBSD, and the like).

In order to generate Ml it is possible to use, in addition to the above-mentioned known algorithms, a specific solution that constitutes an alternative embodiment of the present invention. For this purpose, let us consider the logistic map equation given by: Xn+1= K*Xn*(l-Xn). The initial values of Xn are comprised between 0 and 1. K is a positive number smaller than 4. For values of K greater than 3.6 (exactly starting from K equal to 3.56995), chaos arises: any minimal variation of the initial value of the Xn population will give different results, which is a primary characteristic of chaos. Let us then consider a K variable from 3.6 to 4 as indicated in 1004 in Figure 1, i.e.:

Each user (Ul ....Un) may have a specific K:

User l= kl, Ul with 3.6< kl <4

User 2= k2, U2 with 3.6< k2 <4 User n= kn , Un with 3.6< kn <4

In an alternative embodiment, K may be changed, for example, by using a pseudorandom generator such as, for example, those based on the Yarrow algorithm or the Fortuna algorithm or other algorithms, some of which have already been mentioned above. Once the pseudo-random number has been generated, which will be called A - 1001 -, it must be normalized to values smaller than 0.2 and greater than zero prior to be added to the previously stored K; the value may also be different from 0.2, so long as it is comprised between zero and 0.4.

Each user may, in fact, have a specific initial K - 1004 - different from that of the other users. The sum of A and K, as shown in Figure 1, must be less than 4. If the value is greater, then that value will be set by convention - 1001 - to a value close to 3.6 as proposed herein, although this value may also be different, so long as it is comprised between 3.6 and 4. Once used, the new K is stored and will be used again for the next calculation.

Also the initial value of X may be different among the various users. Once Xn+1 has been calculated as shown in 1001, on the basis of the variable K, it is inputted to one or more cryptographic non-invertible transformation functions, e.g. ashing functions (hereafter defined as ashing function for brevity), such as Blake-256, SHA-1, SHA-2, or the like. Xn+i is stored and will constitute Xn in the next iteration. The ashing algorithm that will be used herein merely by way of example is SHA-1 or SHA-2. The output of the ashing function is Ml .

In Figure 1 one can see how to generate Ml or Nl through a specific method:

Initial value of X: 0<X<1

Xn+l= k*Xn*(l-Xn)

With 3.6<k<4

Each k for each specific user may be variable; one random number A is generated at each step t.

For example, for the user U2 at step 0: Xl= k2,t0 *Xinitial*(l-Xinitial). Considering that XI has values comprised between 0 and 1, it is used as input to an ashing function to obtain Ml or Nl . Uln is a secret number specific for the user n.

From Ml, the two subsets that may have some elements in common are extracted as said SGN and CSGN, as shown in the example 1003 of Figure 1. In an alternative embodiment, Ml could be obtained as shown in 1002 of Figure 1, by using one or more cryptographic non-invertible transformation functions, e.g. ashing functions, Ash*, such as, by way of non-limiting example, Blake-256, SHA-1, SHA-2, to which a random number Nl is inputted, which is originated from the sum of Ul, the secret number specific for each user, and A, the random number generated by a commercial pseudo-random generator among those mentioned above. In this mode as well, SGN and CSGN are then extracted from Ml.

The cryptographic ashing function known as SHA-256 produces a 32-bit output. Another typical ashing function, RJPEMD160, produces a 20-byte ash. Should Ml be required to have more than 32 bytes, the same input of SHA-256 can be inputted to a second ashing function, which in the example illustrated herein is RJPEMD160, and both outputs can then be logically concatenated or combined to form Ml . Many are the methods through which Ml can be made sufficiently extended to enhance the security of the system. When Ml consists of a concatenation of multiple ashing functions, the digit overlap between SGN and CSGN must be constructed in such a way that there will be a part of the overlapped digits in each one of the outputs of the ashing functions in use.

In an alternative embodiment (see Figure 2), a further modification is introduced for better security when generating SGN and CSGN. To this end, a code entered by the user, or anyway entered into the system, is first used. The code is arbitrary and can be modified at every transaction by inventing a new one; therefore, the user will not have to remember any secret code. This code, which will be called PON (personal obfuscation number), is combined with Ml as defined above into various alternatives that will be described below, and is used by the central payment management system and/or by the user's device to generate the random code Ml in an unpredictable manner. The technique for generating random numbers is heterogeneous, and those skilled in the art will appreciate that a really random component is used, which is entered into the system by the user so as to make Ml actually unpredictable.

Many are the technologic methods, available to those skilled in the art and accustomed to using different algorithms for generating random numbers, which can be adopted when using the PON in order to increase the random component of Ml, thus making it completely unpredictable. By way of example, we will only mention the method that provides for the execution of a logic function, such as XOR or XNOR (or another logic function) between the PON and the random number A and/or the number Ul calculated as shown in Figure 1 at 1002. The output of this operation becomes the input of the ashing function, also shown in Figure 1 at 1002.

On a general level, using the PON in order to modify a parameter used by any commercial algorithm for generating a random number A or the random number Ml, from which SGN and CSGN are then extracted, constitutes a primary embodiment of the present invention. For example, the PON can be logically combined with A, a random number, by executing a logic function such as XOR or XNOR (or another logic function) in order to cause it to change. The same also applies to Ml .

In general, the PON can be used for determining a change in a parameter of any known algorithm used for generating random numbers. For example, the PON, suitably normalized, may cause the clock of the system used by the algorithm generating A to be incremented (or decremented) in a random manner, so that A will "jump" among the random values allowed by the algorithm. The general process according to which the PON is used, after appropriate normalization, in order to change the parameters or the configuration of any random number generator includes, for example, the following steps:

- the PON is first normalized;

- the normalized PON then modifies, in an unpredictable manner, one or more parameters of the random number generator;

- the random number A is then outputted.

In an alternative embodiment, a system can be used for generating Ml which depends on a particular parameter, and the PON can be used for changing such parameter, possibly after normalizing the PON to the utilization values of said parameter.

For example, after the PON has been normalized to decimal values in such a way that it is greater than zero and smaller than 0.4, it can be added to K _n as indicated by way of example in 4001 in Figure 4.

A further example of PON use is the following: the number X _n +i in 2001 (Figure 2), which is the output of the above-described logistic equation, can be added to the PON, possibly after the numerical value of the PON has been normalized to values between 0 and 1. The output of this sum is the input of the ashing function - 2001 - and such input, after having been normalized to values between 0 and 1, is stored and will represent X _n in the next iteration. The output of the ashing function constitutes Ml . Many are the parameters of commercial random number generators that can be modified by using the PON. The following will describe some implementation examples.

In the following, the symbol ^A in the drawings will indicate optional functional blocks. One example that may be used is the following: for each specific user, the PON, possibly suitably normalized, can be added to the last X _n +i generated. From this sum (Xn+i +PON - 2001 of Figure 2) one obtains the input to a cryptographic ashing algorithm, such as Blake-256, SHA-1, SHA-2 or the like, the output of which is the new Ml . The result of the sum X _n +i +PON - normalized between 0 and 1 - is stored and will constitute X _n in the next iteration. Another example that may be used is the following: for each specific user, the PON can be added to a secret number specific for the user Ul . From the sum Ul+PON - 2002 of Figure 2 - (or A+PON+U1 - 2002 of Figure 2 - ), one obtains the input to a cryptographic ashing algorithm, such as Blake-256, SHA-1, SHA-2 or the like, the output of which is Ml . There are also other combinations, such as Xn+i +PON+U1 - 3001 of Figure 3 - from which one can obtain the input to a cryptographic ashing algorithm, the output of which is still Ml . The output of the sum Xn+i +PON+U1 is normalized to a value between 0 and 1 and then stored, so as to constitute Xn in the next iteration.

Should the security requirements be less restrictive, it is conceivable to not use a cryptographic ashing algorithm like Blake-256, SHA-1, SHA-2 or the like, and to use directly the output of the sum A+PON+U1 as described in 3002 of Figure 3.

In general, the ashing function can be eliminated also from 3001 (Figure 3) and from 2001 (Figure 2). Also in these cases (and in these embodiments), CSGN is a subset of Ml and may have some digits overlapping those of SGN, which is the other subset of Ml .

With the introduction of the PON, CSGN and SGN are made even more unpredictable and some sort of transaction signature is created: CSGN and/or SGN represent the signature of the service provider as a guarantee for the vendor and/or the supplier of a service. The correspondence of CSGN warrants that the message has been sent from the only subject that could generate the same Ml starting from the PON.

There are many possible PON scenarios and applications. Before describing some application examples, the following will describe the methodology in a very general way.

In Figure 8 it can be seen that, after the user a has entered the PON, the APIs of the user apparatus generate Ml, SGN and CSGN. The PON is sent to the entity β, which, based on the initial conditions and the profile of the user who has sent the PON, calculates Ml, SGN and CSGN. The entity β sends CSGN to a, certifying its identity or certifying a given operation. If on the contrary it is the user a that has to be authenticated, then the messages will be exchanged in a different manner: the PON entered by the user a is sent to β, which calculates Ml and SGN. β sends SGN to a, which, on the basis of the PON, calculates the Ml corresponding to the received SGN. a sends CSGN to β to confirm the user's identity.

Actually, the PON can be sent or received in many alternative ways. In fact, the communication channel used for sending the PON to a device may be a simple message over IP (Internet Protocol) travelling over a WiFi network or a 3G, 4G or 5G mobile network, or via Bluetooth or the Internet or RFID, or by any other means, such as SMS, a visual QR code take, or messages over chatterbots or other messaging systems, e.g. Whatsapp, Messenger, Telegram, Wechat or the like, to mention just a few.

The PON can also be used among three different entities, two of which, δ and β, while they are secure parties, play different roles and have different responsibilities. Let us consider, for example, Figure 9, wherein, upon an input from user a, based on such input δ generates a PON (or modifies the PON received from a) and sends it to β and to a. The PON sent to a will be encrypted or unavailable to a until the latter receives a message from β with the key for reading that PON. After having received the PON, β will generate many Mis, and from the last Ml selected will extract SGN and CSGN. β will send SGN to a (in addition to the keys for reading the PON) and CSGN to δ. Based on the PON now available, a will generate many Mis until it finds the one corresponding to the SGN received from β. It will then send the corresponding CSGN to δ. If CSGN received from a is equal to that received from β over another secure communication channel, then δ will be able to supply a service to a because the latter will be authorized.

Numerous alternative embodiments can be implemented by modifying the position of the database and some message exchanges. The modes of use of the present invention with or without PON are manifold, and only some of them have been described herein merely by way of example. This is, therefore, a general mode of signing an operation, which adds to the current techniques or even replaces them, if allowed by security requirements. The advantage over current electronic signature systems is that it requires less processing capacity. When used as an input to a system for generating encryption keys, the PON may also be used for generating new encryption keys for two systems that must communicate in encrypted mode. The PON transmission channel must be, in this case, a secure channel. Ml or concatenations of Mis, generated as shown in 1001, 1002, 2001, 2002, 3001, 4001, may constitute the symmetrical encryption key between two systems a and β exchanging the PON over a secure communication channel. 4002 shows an example of two encryption systems called "Cipher" utilizing Ml or multiple Ml numbers as encryption keys.

It can be inferred from the above description that, when subscribing to network services, a typical problem lies in the manner in which the identity of the user, defined above as a or β, is used.

In these cases there are conflicting needs: on the one hand, the user data must not be fraudulently reused, while on the other hand there is a risk, for economical users, that someone might cancel the operations or not take due responsibility for them.

For example, some solutions available on the market replace the user's identity with tokens, which cannot be reused but, on the other hand, have no connection with the personal data of the user accessing the network service.

The personal data of the user may consist of his tax data, personal healthcare data, payment card numbers, or personal bank account number, such as the IBAN (International Bank Account Number), or other data. The user's identity in the network will be referred to herein as User ID and generally corresponds to the name used for accessing the network services. The user's User ID is typically defined when subscribing to the service of interest.

To exemplify, we will use a set of personal data. The set of such data will be called PAN (Personal Account Number). The functions of the service under examination, which will have received such data, will store the data and translate them into a univocal numerical datum through one or more cryptographic ashing functions, such as, for example, SHA-256, Blake-256, HEFTY1, in combination with the authentication data: SGN or CSGN and/or the PON.

Optionally, the simple ashing datum may be complemented by the system with a "proof of work" variable from time to time.

The "proof of work" consists of the ashing datum plus a processing effort from the system. In this case the system, in addition to encoding the user fields by applying the selected ashing function or combination of ashing functions, may also generate a univocal datum with certain characteristics, which requires some processing effort from the processor: by way of example, to the IBAN number and the holder data (name, surname, tax code...) a number is added at the end, which is then incremented (IBAN+data+01, IBAN+data+02, IBAN+data+03); then the ashing functions are applied to each data block and the associated increment until an output is determined which begins, for example, with three digits 1 in cascade (e.g. 1110d98b388e77eec46660de9c6f042ac67134cbb497ce).

The system must therefore apply the ashing functions until it finds the output that begins with three digits 1.

Generalizing the above concept, the system is able to iteratively generate a new user identity as a combination of the first and/or second parts (SGN, CSGN) of the number Ml, and/or of the random code (PON), with clear and/or confidential data of the user's identity, and to iteratively apply to this combination a non-invertible transformation function (e.g. Ashing function) at every transaction, connected to the preceding transaction.

The system could periodically update such cryptogram or, at any rate, use different proofs of work for different users: instead of beginning with three digits of number 1, it may begin with four digits of number 0.

In order to generate such an improbable cryptogram beginning, it is necessary to spend resources of the processor, which will have to reiterate the operations until it finds the output with the cryptogram beginning (or end) required as a proof of work. All this hinders many frauds and allows some ongoing verifications, and, most importantly, the user's identity is univocal.

As we will see also below, the set of user data (user ID and associated data) will be referred to as PAN (Personal Account Number). A procedure, illustrated in Figure 6, allows changing the data of the PAN field and/or those of the User Id field at each transaction. The procedure recalculates the PAN or the User Id (or the like) by using the data of the last transaction (e.g. the last calculated CSGN), so as to make it variable. In the example shown in Figure 6, the new User Id, which will be called User ID#2, is equal to the output of an ashing function having as input the old User ID combined with (e.g. added to) the last used CSGN and a number Un, which may be specific for each user.

The same procedure described for the User Id can be repeated for any other user identification datum (e.g. the PAN). In the procedure of Figure 6, if one wants to generate some sort of proof of work, it is possible to apply the ashing function repeatedly: for example, to the data block User ID#1+CSGN+U _n +01, then to the block User ID#1+CSGN+Un +02 ... User ID#1+CSGN+Un+In, and continuing in this way until the increment In produces the desired proof of work. Un is a user-specific secret number and is optional. Without Un the data block will become: User ID#1+CSGN +01, User ID#l+CSGN+02 ... User ID#1+CSGN +I _n . Once the required proof of work has been found, the new User Id will be obtained, which will be called User ID#2. The newly calculated User Id#2 will be sent to the user's device, where it will be stored in the place of the previous User Id (User ID#1 in our example).

The advantage of the procedure of Figure 6 is not only related to the improved security of a User Id not changing at every transaction, but also to the fact that it makes it difficult to cancel operations carried out by a given User Id. Figure 7 illustrates a variant wherein the stored User Id is modified before being used. In the example of Figure 7, the stored userID#2 is modified before use as follows: some user's personal data are added to userID#2, including biometric data and/or PINs stored and shared with the system (typically it will be a service-specific PIN), and possibly other shared data may also be added (i.e. device numbers). To all these data added (e.g. summed) to userID#2 an ashing function is applied, and the modified userID*#2 is obtained. The system of Figure 7 expects to receive a userID*#2 modified from the one sent, as a confirmation of the fact that the user knows the PIN and has a given biometric characteristic (e.g. fingerprint).

A proof of work can be implemented also in the case described in Figure 7, as in the case described in Figure 6.

The proof of work described in the various cases also allows for easy intermediate verifications of the veracity of the subject that will receive the message, e.g. by verifying if the data begin with three ones or four zeroes. In most cases, a cryptogram may simply be generated without proof of work.

In general, the PAN (personal account number) may consist of, according to the case:

1) the identifier of the user A or user ID - whether a number and/or biometric data of A - and possibly one or more characteristic numbers of the terminal of the user A, both encrypted.

2) alternatively, the PAN may contain the identifier of the user A - whether a number and/or biometric data of A - encrypted by using a sequence of ashing functions, as previously provided for Crypto 1, with the production of a proof of work and possibly one or more characteristic numbers of the terminal of the user A.

3) alternatively, the PAN may contain a combination of data identifying A, such as user ID, tax code and other confidential data of the user (such as IBAN and/or other identification numbers and/or biometric data of A) and possibly one or more characteristic numbers of the terminal of the user A, everything optionally encrypted by means of an ashing function, as done for userID*#2.

The three above cases indicate different contents in the field that will hereafter be synthetically referred to as PAN.

The detailed description of the present invention allows using an authentication between a and β as described in Figures 5, 8 and 9, wherein the respective identities of α, β and δ are User Id#2 and/or a userID*#2 that, as aforesaid, is modified prior to transmission. Figures 6 and 7 illustrate the operation with authentication without a PON. Such schemes, when PON input by the user is included, will change as shown in Figures 10 and 11, respectively.

The following will provide some further explanatory details about Figures 5 to 11.

With reference to Figure 5 :

- a generates the random number Ml and extracts SGN

- a sends SGN to β

- β receives SGN from a after various other possible receptions in the network, β generates many Mis by using the same method as used by a until it finds a match with the received SGN. - β extracts CSGN and sends CSGN to a

- If CSGN corresponds, then the counterpart β will be authenticated,

β can manage different users as a

With reference to Figures 6 and 10:

User ID # 2 is stored by a and is not modified by a

User ID #2 = =ashing [(User ID #1)+CSGN+Un]

β* is a third party that may receive CSGN, and is optional

Un is a code specific for the n-th final user, and may be optional.

With reference to Figures 7 and 11 :

- User ID #2 = ashing [(User ID # 1 )+C SGN+Un]

- Ash (User JD # 2 + PIN + biometric data + other)= =User ID* # 2

User ID # 2 is stored by a, but it is modified by a with the inclusion of the PIN and/or biometric data of the user and/or other data, such as the serial number of the terminal and/or the telephone number. APIS

β* is a third party that may receive CSGN, and is optional.

When it receives User ID* # 2, different from User ID # 2 sent, APIS will calculate User ID* # 2 by using the same procedure as used by a and will verify the correspondence.

Un is a code specific for the n-th final user, and may be optional.

With reference to Figure 8:

- PON input (entered by the user of the terminal a)

- a sends PON to β

- β receives SGN from a after other possible receptions in the network, β generates Ml, SGN and CSGN on the basis of the PON obtained through the same system available on a

- β sends CSGN to a

- If CSGN matches the one generated by a, then the counterpart β will be authenticated, β can manage different users as a

With reference to Figure 9:

- PON input (provided by user a), PON is modified by δ

- The modified PON is sent to β and a

- β generates Ml, SGN and CSGN on the basis of the received PON - β sends SGN to a

- β sends C SGN to δ

- a receives SGN and generates many Mis until it finds the one that matches the received SGN

a sends CSGN to δ

- δ will carry out a specific action, if the CSGN received from a matches the CSGN received from β

The present invention can advantageously be implemented by means of a computer program comprising coding means for carrying out one or more steps of the method, when this program is executed on a computer. It is therefore understood that the protection scope extends to said computer program and also to computer-readable means comprising a recorded message, said computer-readable means comprising program coding means for carrying out one or more steps of the method, when said program is executed on a computer.

The above-described non-limiting example of embodiment may be subject to variations without departing from the protection scope of the present invention, including all equivalent designs known to a man skilled in the art.

The elements and features shown in the various preferred embodiments may be combined together without however departing from the protection scope of the present invention.

From the above description, those skilled in the art will be able to produce the object of the invention without introducing any further construction details.