SYSTEM FOR ENCRYPTING AND AUTHENTICATING COMMUNICATIONS WITH MUTUAL AUTHENTICATION OF THE COMMUNICATORS

Abstract

SYSTEM FOR ENCRYPTING AND AUTHENTICATING COMMUNICATIONS WITH MUTUAL AUTHENTICATION OF THE COMMUNICATORS which can be used between two parties who exchange messages supported by a communication network in which the parties are unequivocally identified. The system includes processes supported by respective authentication applications available to each party on a hardware/software device, the applications comprising at least: an identifier (Id) of the authentication application (AA); an encryption key (CC) of each party; a random number generator for encrypting and authenticating messages Mx; and an encryption algorithm that is shared with the rest of the parties of the system, allowing them to encrypt and decrypt the sent/received messages.

Claims

1.-9. (canceled)

10. A method for the encryption and authentication of communications, with mutual authentication of the communicating parties, the method comprising: each of the communicating Parties, Party A and Party B, having an Authentication Application (AA), in a device, which allows them to exchange messages between them, where each Authentication Application has: its Identifier, which identifies it unequivocally from the rest of the Authentication Applications integrated in the Authentication System; the Identifiers of each of the Authentication Applications of other Parties that are defined as their potential interlocutors within the Authentication System; a value, different for each interlocution pair, to be used as the Encryption Key, CC, for messages; one or more communication channels with between the Parties, through which authentication applications exchange messages; a generator of Pseudorandom Values; an encryption algorithm, shared with the rest of the System Parts, which allows encrypting and decrypting the messages sent/received; a summary function, shared with the rest of the System Parts, which provides summary values; wherein the Application of Party A: generates and stores two Pseudorandom Values, VAM2 and VAM3 to be used as Authentication Values (VAMx) in M2 and M3 messages respectively; prepares the information to be sent containing, at least, the values IdA, IdB, VAM2, VAM3 and DATA1, where DATA1 will contain information to be communicated to Party B; applies to this information a summary function, shared by Party A and Party B, obtaining a Summary Value of the information to be transmitted in the message M1, VRM1; encrypts, applying the encryption algorithm shared by Party A and Party B, with CC, obtaining CC(VAM2, VAM3, DATA1, VRM1); sends to the Application of Party B an M1 message containing, inter alia, the data: IdB; IdA; CC(VAM2, VAM3, DATA1, VRM1). wherein the Application of Party B: receives message M1, verifies Party A's Identifier, decrypts with CC the CC (VAM2, VAM3, DATA1, VRM1); applies the same summary function to the same received values (IdB, IdA, VAM2, VAM3, DATA1), and obtains the Summary Value that the received VRM1 must have; in that, in the case that if the calculated VRM1 coincides with the received one, it means that the decryption has been performed correctly then the one who created the message and performed the encryption has been Party A, and then: saves the values VAM2, VAM3; composes the message IdA, IdB, DATA2, VAM2, with the DATA2 to be sent, and calculates its summary value VRM2 by applying the same summary function; sends to Party A (IdA) an M2 message containing, among other possible values, the values of: IdA, IdB, DATA2, VRM2; wherein the Application of Party A: receives from the Party B Application the M2 message; verifies Party B's Identifier; recalculates the value of VRM2 on the data IdA, IdB, DATA2, VAM2M1, where the value VAM2M1 is the VAM2 sent in the message M1 and verifies its coincidence with the received VRM2; where, in the case that it does coincide, it is Party B who calculated the received VRM2, since only Party B has the value VAM2, so that both parties already know with whom they are dialoguing, and then; composes the message IdB, IdA, DATA3, VAM3, with the DATA3 to be sent, and calculates its summary function VRM3; sends to Party B (IdB) an M3 message containing, among other possible values, the values of: IdB, IdA, DATA3, VRM3; and wherein the Application of Party B: receives message M3 with IdB, IdA, DATA3, VRM3; verifies Party A's Identifier; recalculates the value of VRM3 on the data IdA, IdB, DATA3, VAM3M1 where the value VAM3M1 is the VAM3 received in the message M1 and verifies its coincidence with the received VRM3; where, in the case that it does coincide is that the one who calculated the received VRM3 is Party B, since only it has the value VAM3, and then the message M3 is the authenticated response to M2.

11. A method for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 10, wherein when it is necessary for party A to know that its message M3 has reached party B, a VAM4 value is sent in message M1 and the application of party B proceeds to compose a message M4 to be sent to the application of party A.

12. A method for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 10, wherein the application of Party A: generates and stores four Pseudorandom Values, CCM2, VAM2 and CCM3, VAM3 to be used as message Encryption Keys (CCMx) and Authentication Values (VAMx) in a M2 and M3 message respectively; applies a summary function to calculate the Summary Value, VRM1, of the Party A and Party B Application identifiers, the generated values and other data to be reported; sends to the Party B application an M1 message containing, among other possible values, the Party A and Party B Application identifiers together with the encrypted value, with the encryption key CCAB, of the generated values, the data to be communicated and the VRM1 value; wherein the application of Party B: receives the message M1, checks the Party A Application Identifier and decrypts with CCAB the encrypted part obtaining, inter alia, the value VRM1; applies, as did Party A, the same summary function to the same received values and obtains its Summary Value which must match the received VRM1; in the case where the VRMs do match, the message was sent by Party A's application, and then: stores the values CCM2, VAM2, CCM3, VAM3; sends to the Party A application an M2 message containing, among other possible values, the Party A and Party B Application identifiers together with the encrypted value, with the CCM2 encryption key, of the VAM2 value and the data to be communicated; wherein the application of Party A: receives from the application of Party B the M2 message, verifies the Party B application's Identifier and decrypts with CCM2 the M2 information to obtain the VAM2 and verify its coincidence with the one sent in the M1, in which, in the case that the VAMs do coincide, it means that the message was sent by the application of Party B, with which the two parties already know with whom they are dialoguing; sends to the application of Party B (IdB) an M3 message containing, among other possible values, the Party A and Party B Application identifiers together with the encrypted value, with the CCM3 encryption key, of the VAM3 value and the data to be communicated; and wherein the application of Party B: receives from the application of Party A the message M3, checks the Party A application's Identifier and decrypts with CCM3 the encrypted information to obtain the VAM3 and verify its coincidence with the one received in the M1; where, in the case where the VAMs do match, the message M3 was sent by the application of Party A in response to its M2.

13. A method for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 10, wherein the value of the encryption key CCAB, which is used in the encryption and decryption of message M1, is different for each dialogue in which Party A and Party B exchange messages M1 and M2, wherein the application of Party A: generates and stores four Pseudorandom Values, CCM2, VAM2 and CCM3, VAM3 to be used as message Encryption Keys (CCMx) and Authentication Values (VAMx) in a M2 and M3 message respectively; applies a summary function to calculate the Summary Value, VRM1, of Party A's and Party B's Application identifiers, the values generated, data to be communicated and the value of data ReceivedM2AB, where ReceivedM2AB shall contain the value Yes or NO to indicate to Party B's Application whether in the last dialogue initiated by Party A, Party A received Party B's M2 message so that Party B can act accordingly; sends to the application of Party B a message M1 containing, among other possible values, the Party A and Party B Application identifiers, the value of ReceivedM2AB and the encrypted value, with the encryption key CCAB, of the four generated values, the data to be communicated and the value VRM1; once M1 has been sent, it stores the value NO in the ReceivedM2AB data to indicate that Party A has initiated a dialogue with Party B but has not yet received the M2 message from this dialogue; wherein the application of Party B: receives the message M1, checks the Party A Application Identifier and decrypts with CCAB the encrypted part obtaining, inter alia, the value VRM1; applies, as Party A did, the same summary function to the same received values and obtains its Summary Value which must match the received VRM1 and: in the case where the VRMs do match, then the message was sent by the Party A application, and so; stores the values CCM2, VAM2, CCM3, VAM3; generates a CCSIG value to be used as the encryption key for the M1 message of the next dialogue Party B will have with Party A and stores it in the CCSIGAB data; sends to the Party A Application (IdA) an M2 message containing, among other possible values, the Party A Application and Party B Application identifiers together with the encrypted value, with the CCM2 encryption key, of the VAM2 value, the data to be communicated, and the CCSIGAB value; the value of CCAB is stored in the CCUUAB data in case in a next dialogue it is necessary to reuse the value of CCAB to decrypt the received M1; the value of CCSIGAB is stored in the CCAB data which, initially, shall be used to decrypt the next incoming M1; in the case where the VRMs do not match, then: checks if the data ReceivedM2AB has the value NO and if it does not, there has been an error or attempted attack on the system; in the case where ReceivedM2AB has the value NO then: saves the value of CCUUAB in CCAB, so that the same key used to decrypt the previous M1 received is used as the decryption key for the M1; This happens as long as Party A has not received the M2 from the previous dialogue with the new encryption key to be used in the CCSIGAB variable; decrypts again with CCAB; applies, as Party A did, the same summary function to the same received values and obtains its Summary Value VRM1R and checks if it matches the received VRM1; if it does not match, there has been an error or attempted attack on the system; in the case where they do agree is that Party A is the issuer of the M1 and so: stores the values CCM2, VAM2, CCM3, VAM3 and generates a CCSIG value which stores it in CCSIGAB; sends to the Party A application (IdA) an M2 message containing, among other possible values: the Party A and Party B Application identifiers together with the encrypted value, with the CCM2 encryption key, of the VAM2 value, the data to be communicated, and the CCSIGAB value: once M2 is sent, the value of CCAB is stored in the CCUUAB data and the value of CCSIGAB is stored in the CCAB data; wherein the application of Party A: receives from the Party B application the M2 message, verifies the Party B application's Identifier and decrypts with CCM2 the M2 information to obtain the VAM2 and verify its match with the one sent in the M1, in which it in the case where the VAMs do agree, is that the message was sent by party B's application, so both parties already know who they are talking to, and then; stores in CCAB the value of the CCSIGAB received; saves the value SI in ReceivedM2AB; and wherein the application of Party B: receives from the Party A application the message M3, checks the Party A application's Identifier and decrypts with CCM3 the encrypted information to obtain the VAM3 and verify its coincidence with the one received in the M1; where, in the case where the VAMs do match, the message M3 was sent by the Party A application in response to its M2.

14. A method for encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 12, wherein when it is necessary for party A to know that its message M3 arrived at party B, then in message M1 a CCM4 and VAM4 value is sent and the application of party B proceeds to compose a message M4 to be sent to the application of party A.

15. A method for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 10, wherein the dialoguIne is automatically initiated between the two Authentication Applications AAA and AAB, of Parties A and B, when an expected event arrives to AAA, being that the Authentication Applications are previously active and have the CCAB encryption key that they share.

16. A method for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 10, wherein the activation of an AA application is carried out by providing the Party, the person using the application, with an activation code CA which will be the second authentication factor for said Party, the natural person within the dialogue.

17. A method for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 16, wherein for an AA application to validate a message M sent by the other application involved in the dialogue, the Party, the person using the application, needs to provide a value that will be the third authentication factor of said Party, the natural person within the dialogue.

18. System for the encryption and authentication of communications, with mutual authentication of the communicating parties, each of the communicating Parties, Party A and Party B, has an Authentication Application (AA), in a device, which allows them to exchange messages between them, with Authentication Application, the system comprising the Authentication Application having: its Identifier, which identifies it unequivocally from the rest of the Authentication Applications integrated in the Authentication System; the Identifiers of each of the Authentication Applications of other Parties that are defined as their potential interlocutors within the Authentication System; a value, different for each interlocution pair, to be used as the Encryption Key, CC, for messages; one or more communication channels with between the Parties, through which authentication applications exchange messages; a generator of Pseudorandom Values; an encryption algorithm, shared with the rest of the System Parts, which allows encrypting and decrypting the messages sent/received; a summary function, shared with the rest of the System Parts, which provides summary values; wherein the Application of Party A: generates and stores two Pseudorandom Values, VAM2 and VAM3 to be used as Authentication Values (VAMx) in M2 and M3 messages respectively; prepares the information to be sent containing, at least, the values IdA, IdB, VAM2, VAM3 and DATA1, where DATA1 will contain information to be communicated to Party B; applies to this information a summary function, shared by Party A and Party B, obtaining a Summary Value of the information to be transmitted in the message M1, VRM1; encrypts, applying the encryption algorithm shared by Party A and Party B, with CC, obtaining CC(VAM2, VAM3, DATA1, VRM1); sends to the Application of Party B an M1 message containing, inter alia, the data: IdB; IdA; CC(VAM2, VAM3, DATA1, VRM1); wherein the Application of Party B: receives message M1, verifies Party A's Identifier, decrypts with CC the CC (VAM2, VAM3, DATA1, VRM1); applies the same summary function to the same received values (IdB, IdA, VAM2, VAM3, DATA1), and obtains the Summary Value that the received VRM1 must have; in that, in the case that if the calculated VRM1 coincides with the received one, it means that the decryption has been performed correctly then the one who created the message and performed the encryption has been Party A, and then: saves the values VAM2, VAM3; composes the message IdA, IdB, DATA2, VAM2, with the DATA2 to be sent, and calculates its summary value VRM2 by applying the same summary function; sends to Party A (IdA) an M2 message containing, among other possible values, the values of: IdA, IdB, DATA2, VRM2; wherein the Application of Party A: receives from the Party B Application the M2 message; verifies Party B's Identifier; recalculates the value of VRM2 on the data IdA, IdB, DATA2, VAM2M1, where the value VAM2M1 is the VAM2 sent in the message M1 and verifies its coincidence with the received VRM2; where, in the case that it does coincide, it is Party B who calculated the received VRM2, since only Party B has the value VAM2, so that both parties already know with whom they are dialoguing, and then; composes the message IdB, IdA, DATA3, VAM3, with the DATA3 to be sent, and calculates its summary function VRM3; sends to Party B (IdB) an M3 message containing, among other possible values, the values of: IdB, IdA, DATA3, VRM3; and wherein the Application of Party B: receives message M3 with IdB, IdA, DATA3, VRM3; verifies Party A's Identifier; recalculates the value of VRM3 on the data IdA, IdB, DATA3, VAM3M1 where the value VAM3M1 is the VAM3 received in the message M1 and verifies its coincidence with the received VRM3; where, in the case that it does coincide is that the one who calculated the received VRM3 is Party B, since only it has the value VAM3, and then the message M3 is the authenticated response to M2.

19. System for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 18, wherein when it is necessary for party A to know that its message M3 has reached party B, a VAM4 value is sent in message M1 and the application of party B proceeds to compose a message M4 to be sent to the application of party A.

20. System for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 18, wherein the application of Party A: generates and stores four Pseudorandom Values, CCM2, VAM2 and CCM3, VAM3 to be used as message Encryption Keys (CCMx) and Authentication Values (VAMx) in a M2 and M3 message respectively; applies a summary function to calculate the Summary Value, VRM1, of the Party A and Party B Application identifiers, the generated values and other data to be reported; sends to the Party B application an M1 message containing, among other possible values, the Party A and Party B Application identifiers together with the encrypted value, with the encryption key CCAB, of the generated values, the data to be communicated and the VRM1 value; wherein the application of Party B: receives the message M1, checks the Party A Application Identifier and decrypts with CCAB the encrypted part obtaining, inter alia, the value VRM1; applies, as did Party A, the same summary function to the same received values and obtains its Summary Value which must match the received VRM1; in the case where the VRMs do match, the message was sent by Party A's application, and then: stores the values CCM2, VAM2, CCM3, VAM3; sends to the Party A application an M2 message containing, among other possible values, the Party A and Party B Application identifiers together with the encrypted value, with the CCM2 encryption key, of the VAM2 value and the data to be communicated; wherein the application of Party A: receives from the application of Party B the M2 message, verifies the Party B application's Identifier and decrypts with CCM2 the M2 information to obtain the VAM2 and verify its coincidence with the one sent in the M1, in which, in the case that the VAMs do coincide, it means that the message was sent by the application of Party B, with which the two parties already know with whom they are dialoguing; sends to the application of Party B (IdB) an M3 message containing, among other possible values, the Party A and Party B Application identifiers together with the encrypted value, with the CCM3 encryption key, of the VAM3 value and the data to be communicated; and wherein the application of Party B: receives from the application of Party A the message M3, checks the Party A application's Identifier and decrypts with CCM3 the encrypted information to obtain the VAM3 and verify its coincidence with the one received in the M1; where, in the case where the VAMs do match, the message M3 was sent by the application of Party A in response to its M2.

21. System for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 18, wherein the value of the encryption key CCAB, which is used in the encryption and decryption of message M1, is different for each dialogue in which Party A and Party B exchange messages M1 and M2, wherein the application of Party A: generates and stores four Pseudorandom Values, CCM2, VAM2 and CCM3, VAM3 to be used as message Encryption Keys (CCMx) and Authentication Values (VAMx) in a M2 and M3 message respectively; applies a summary function to calculate the Summary Value, VRM1, of Party A's and Party B's Application identifiers, the values generated, data to be communicated and the value of data ReceivedM2AB, where ReceivedM2AB shall contain the value Yes or NO to indicate to Party B's Application whether in the last dialogue initiated by Party A, Party A received Party B's M2 message so that Party B can act accordingly; sends to the application of Party B a message M1 containing, among other possible values, the Party A and Party B Application identifiers, the value of ReceivedM2AB and the encrypted value, with the encryption key CCAB, of the four generated values, the data to be communicated and the value VRM1; once M1 has been sent, it stores the value NO in the ReceivedM2AB data to indicate that Party A has initiated a dialogue with Party B but has not yet received the M2 message from this dialogue; wherein the application of Party B: receives the message M1, checks the Party A Application Identifier and decrypts with CCAB the encrypted part obtaining, inter alia, the value VRM1; applies, as Party A did, the same summary function to the same received values and obtains its Summary Value which must match the received VRM1 and: in the case where the VRMs do match, then the message was sent by the Party A application, and so; stores the values CCM2, VAM2, CCM3, VAM3; generates a CCSIG value to be used as the encryption key for the M1 message of the next dialogue Party B will have with Party A and stores it in the CCSIGAB data; sends to the Party A Application (IdA) an M2 message containing, among other possible values, the Party A Application and Party B Application identifiers together with the encrypted value, with the CCM2 encryption key, of the VAM2 value, the data to be communicated, and the CCSIGAB value; the value of CCAB is stored in the CCUUAB data in case in a next dialogue it is necessary to reuse the value of CCAB to decrypt the received M1; the value of CCSIGAB is stored in the CCAB data which, initially, shall be used to decrypt the next incoming M1; in the case where the VRMs do not match, then: checks if the data ReceivedM2AB has the value NO and if it does not, there has been an error or attempted attack on the system; in the case where ReceivedM2AB has the value NO then: saves the value of CCUUAB in CCAB, so that the same key used to decrypt the previous M1 received is used as the decryption key for the M1; this happens as long as Party A has not received the M2 from the previous dialogue with the new encryption key to be used in the CCSIGAB variable; decrypts again with CCAB; applies, as Party A did, the same summary function to the same received values and obtains its Summary Value VRM1R and checks if it matches the received VRM1; if it does not match, there has been an error or attempted attack on the system; in the case where they do agree is that Party A is the issuer of the M1 and so: stores the values CCM2, VAM2, CCM3, VAM3 and generates a CCSIG value which stores it in CCSIGAB; sends to the Party A application (IdA) an M2 message containing, among other possible values: the Party A and Party B Application identifiers together with the encrypted value, with the CCM2 encryption key, of the VAM2 value, the data to be communicated, and the CCSIGAB value: once M2 is sent, the value of CCAB is stored in the CCUUAB data and the value of CCSIGAB is stored in the CCAB data; wherein the application of Party A: receives from the Party B application the M2 message, verifies the Party B application's Identifier and decrypts with CCM2 the M2 information to obtain the VAM2 and verify its match with the one sent in the M1, in which it in the case where the VAMs do agree, is that the message was sent by party B's application, so both parties already know who they are talking to, and then; stores in CCAB the value of the CCSIGAB received; saves the value SI in ReceivedM2AB; and wherein the application of Party B: receives from the Party A application the message M3, checks the Party A application's Identifier and decrypts with CCM3 the encrypted information to obtain the VAM3 and verify its coincidence with the one received in the M1; where, in the case where the VAMs do match, the message M3 was sent by the Party A application in response to its M2.

22. System for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 20, wherein when it is necessary for party A to know that its message M3 arrived at party B, then in message M1 a CCM4 and VAM4 value is sent and the application of party B proceeds to compose a message M4 to be sent to the application of party A.

23. System for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 18, wherein the dialogue is automatically initiated between the two Authentication Applications AAA and AAB, of Parties A and B, when an expected event arrives to AAA, being that the Authentication Applications are previously active and have the CCAB encryption key that they share.

24. System for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 18, wherein the activation of an AA application is carried out by providing the Party, the person using the application, with an activation code CA which will be the second authentication factor for said Party, the natural person within the dialogue.

25. System for the encryption and authentication of communications, with mutual authentication of the communicating parties, according to claim 24, wherein for an AA application to validate a message M sent by the other application involved in the dialogue, the Party, the person using the application, needs to provide a value that will be the third authentication factor of said Party, the natural person within the dialogue.

Description

DESCRIPTION OF DRAWINGS

[0220] In order to complement the description given and to assist in a better understanding of the features of the invention, this description is accompanied, as an integral part thereof, by a set of drawings in which the following has been illustrated in an illustrative and non-limiting manner:

[0221] FIG. 1 shows a schematic representation of the main elements involved in the authentication system covered by the invention and the relationship of how the authentication system interacts with the company's computer system that manages the operational applications to carry it out.

[0222] FIG. 2.—Shows a diagram of the steps comprising the operational scheme and flow messages authentication system when the data of the operation performed by Party A from a D1A device are captured by AA1 automatically (with a QR, via NFC, or any other possible means of communication) coming from D1A.

[0223] FIG. 3.—Shows a diagram of the steps comprising the operational scheme and message flow of the authentication system when AA1 initiates the authentication of a transaction that Party A requested to an Operational Application AO from its device D1A.

[0224] FIG. 4 shows a diagram of the steps comprising the operational scheme and message flow of an authentication system for a mutual authentication between two Parties that authenticates a message sent by Party A to Party B and Party B confirms its receipt.

[0225] FIG. 5.—Shows a diagram of the steps comprising the message flow authentication system for a mutually confirmed authentication between two Parties.

PREFERRED EMBODIMENT OF THE INVENTION

[0226] In view of the aforementioned figures, and in accordance with the numbering adopted, it is possible to observe in them a representation and various non-limiting schemes of realization of the system of the invention and which, therefore, do not exclude any other that may be given, of similar characteristics in which AA1 and AA2 exchange messages according to the authentication system described, which allows completing their mutual authentication and a possible confirmation of an operation carried out between them.

[0227] It is worth mentioning that, in order to simplify the explanation of the diagrams of the figures, in addition to the acronyms already mentioned in previous paragraphs, the following abbreviations will be used from now on: [0228] D1A Operating device from which a user is operating [0229] DO Transaction Data [0230] AA1 Authentication Application of the First Party [0231] AA2 Authentication Application of the Second Party [0232] AO Application of Party B that supports the operation being performed by the user or Party A.

[0233] Thus, FIG. 1 shows, schematically, a representation of the main elements comprising the authentication system (1) with which the procedure of the invention is carried out, where on the one hand, referenced as (2), are shown the devices and IT tools used by the users requesting operations or party A, namely at least a D1A and AO, as well as a D2A and AA1, and on the other hand, referenced as (3), are shown the tools of the company's IT system, party B, namely D1B and AA2 and the operating applications AP1, AP2, AP3. Looking at FIG. 2, it can be seen how the operational scheme and message flow of the authentication system, when the operation data requested by Party A from a device D1A is captured by AA1 automatically (with a QR, via NFC, or any other possible means of communication) coming from D1A, comprises the following steps: [0234] a) The D1A provides the AO with the DOs to be authenticated and confirmed. And the AO prepares the DOs to be sent to D1A and AA2. [0235] b) The AO sends to D1A the DOs in the appropriate format to be captured by AA1. [0236] c) The AO sends the DOs to AA2. AA2 stores the DOs pending authentication. [0237] d) The AA1 captures the DOs from D1A. AA1 presents the DOs to the user and waits for confirmation. If confirmed, it creates, according to the simplified authentication procedure, the M1 message and sends it to AA2. [0238] e) The AA2 decrypts, according to the simplified authentication procedure, the M1 and verifies the DOs with those it has on hold. If they are correct, it creates, according to the simplified authentication procedure, and sends to AA1 the M2 message. [0239] f) The AA2 communicates the result to the AO. [0240] g) The AA1 processes the M2 according to the simplified authentication procedure, and presents the data to the User, confirming that the authentication was successful. [0241] h) The AO communicates the result to D1A.

[0242] Looking at FIG. 3, the operational scheme and message flow of the authentication system, when AA1 initiates the authentication of an operation that Party A requested to an Operational Application AO from its device D1A, comprises the following steps: [0243] a′) The D1A provides the AO with the DOs to authenticate and confirm. The AO prepares the DOs and sends them to AA2. [0244] b′) The AA2 stores the DOs, waiting for the authentication request to arrive from AA1. [0245] c′) The AA1 sends an encrypted message M1 to AA2 to initiate the authentication of an operation that has been requested by the user from D1A. [0246] d′) The AA2 verifies that it comes from AA1 and that for that user there is an operation waiting for authentication. It creates the M2 message with the DOs and sends it to AA1. [0247] e′) The AA1 decrypts the M2, verifies that it comes from AA2 and presents it to the user for authorization. It creates the M3 message with the DOs and the result of the authorisation and sends it to AA2. [0248] f′) The AA2 decrypts the M3, verifies that it comes from AA1, checks that the DOs it has match the DOs received and communicates the result to the AO and creates an M4 message which it sends to AA1 to communicate the result. [0249] g′) The AA1 processes the M4 and presents the result of the operation to the user. [0250] h′) The AA2 communicates the result to AO. [0251] i′) The AO communicates the result to D1A.

[0252] Looking at FIG. 4, it can be seen that the operational scheme and message flow of the authentication system for a mutual authentication between two Parties that authenticates a message sent by Party A to Party B and Party B acknowledges its receipt comprises: [0253] a″) The AA1 sends an encrypted message M1 to AA2 and initiates the mutual authentication operation. [0254] b″) The AA2 verifies, with the decryption procedure, that the M1 comes from AA1, thus AA1 is authenticated against AA2 as the sender of the message and also the content of the message. AA2 creates the M2 message and sends it to AA1 to complete the mutual authentication process and confirm that the M1 has reached AA1. [0255] c″) The AA1 decrypts the M2 and verifies that it is the response provided by AA2 to the M1 message, which authenticates AA2 to AA1 and closes the mutual authentication process for the performed dialogue. AA1 also knows that AA2 received the M1.

[0256] And, looking at FIG. 5 which shows that the steps comprising the message flow of the authentication system for a mutually confirmed authentication between two Parties are: [0257] a′″) The AA1 sends an encrypted message M1 to AA2 and initiates the mutual authentication operation. [0258] b′″) The AA2 verifies, according to the procedure, that the M1 comes from AA1, thus AA1 is authenticated against AA2 as the sender of the message. AA2 creates the M2 message and sends it to AA1 to complete the mutual authentication process and confirm that the M1 arrived. [0259] c′″) The AA1 handles the M2 and checks that it is the response provided by AA2 to the M1 message, thus AA2 is now authenticated against AA1 and the mutual authentication process for the performed dialogue is closed. AA1 also knows that AA2 received the M1. To let Party B know that the mutual authentication has been successfully completed, Party A sends it an M3 message. [0260] d′″) The AA2 verifies, according to the procedure, that the M3 comes from AA1 and thus knows that the mutual authentication process has been successfully completed and that the M2 has reached AA1.

[0261] In the following, different examples of the mode of use of the authentication system according to the invention are described.

[0262] Thus, as a first example of Mode of use of the authentication and encryption system, object of the invention, we will see how it is applied to the case in which a user of the authentication system, Party A, wants to transmit an encrypted message to another user of the authentication system, Party B, making sure that said message has certainly reached the recipient user.

[0263] Characteristics:

[0264] Party A and Party B: [0265] are unequivocally identified, by their IdA and IbB, within the message authentication system supported by the communication network that allows them to exchange such messages, the parties being connected by one or more communication channels that allow them to exchange such messages; [0266] have their Authentication Application, with all its components, in a device that ensures that: the CC encryption key can only be known and used by it; and that encryption and decryption operations are also performed securely. For this purpose, Hardware Security Module (HSM) type means can be used.

[0267] For dialogues between A and B they need, in their authentication applications: [0268] that the parties activate their authentication applications by providing their activation codes using the means provided; [0269] share the CC value; [0270] a generator of Pseudo-Random Values, to be used in the Mx messages; [0271] an encryption algorithm, which it shares with the rest of the System Parties, that allows them to encrypt and decrypt the messages that are sent/received.

[0272] Operation:

[0273] Party A

[0274] It initiates the procedure for a dialogue with Party B, in which two messages are to be exchanged, using its Device and its AAA Authentication Application: [0275] It generates and saves two Pseudorandom Values, CCM2, VAM2 to be used as Encryption Key and Authentication Value in the M2 message. These generated values shall have a certain validity time which shall be controlled in the process of their use; [0276] It obtains the Timestamp of the time TS; it prepares the information to be sent containing, at least, the values IdB, IdA, TS, CCM2, VAM2, and DATA, where DATA will contain the information to be communicated to Party B; it applies to this information a hash function (Secure Hash Algorithm hash function or any other similar algorithm) obtaining a Summary Value of the information to be transmitted in the message M1, VRM1; its encrypts with CC, obtaining CC(TS, CCM2, VAM2, DATA, VRM1). [0277] It sends to Party B an M1 message containing, among other possible data: IdB; IdA; CC(TS, CCM2, VAM2, DATA, VRM1).

[0278] Optionally, for operational and control purposes, the identifier of the sender of the message in the communication network supporting the dialogue may also travel encrypted by CC.

[0279] Party B

[0280] It continues with the procedure for a dialogue with Party A, and for this, making use of his Device and his AAB Authentication Application: [0281] It receives the message M1 and continues with the authentication procedure of the initiated dialogue. To do so: [0282] It verifies Party A's Identifier. [0283] It decrypts, with CC that it shares with Party A, the CC (TS, CCM2, VAM2, DATA, VRM1); applying the same summary function to the same received values, it obtains the Summary Value that the received VRM1 must have and if it coincides with the received one, it means that the decryption has been carried out correctly. This means that the CC value is the one that was used to encrypt and therefore the one who created the message and performed the encryption has been Party A, since only Party A knows this value. In addition, the integrity and confidentiality of the information received is guaranteed. Also, optionally, it will be checked that the received Timestamp TS is equal to or greater than that of the last message processed and that it is within an agreed range of values. [0284] Party B, having received the M1 and verified that it comes from Party A, prepares and sends, to Party A, an M2 message to inform Party A that it has received the M1. For this purpose: [0285] It composes the message (TS2, VAM2, DATA), with the current TS2 and the confirmation DATA to be sent, and encrypts it with CCM2. [0286] It sends to Party A (IdA) an M2 message containing, among other possible values, the values of: IdA; IdB; CCM2(TS2, VAM2, DATA).

[0287] Party A

[0288] It receives from Party B the message M2: IdA; IdB; CCM2(TS2, VAM2 DATA) and continues with the authentication procedure of the already started dialogue. To do so: [0289] It verifies Party B's Identifier. [0290] It decrypts, with CCM2 sent to Party B in message M1, the information of M2 to obtain the VAM2 and verify its coincidence with that sent in M1, thus ensuring that the decryption has been correct and that M2 is the response to the M1 sent, since it contains the VAM2 value, which authenticates the message. As only Party B knows the CCM2 value with which the M2 message arrived encrypted, the authenticity of Party B as the originator of the M2 message is assured and, in this way, Party A knows that it is indeed in dialogue with Party B, thus completing the mutual authentication process and confirming that the M1 message was received by Party B and that it cannot subsequently claim ignorance of it. As the message travels encrypted, its integrity and confidentiality is also guaranteed.

[0291] By operating in this way, the Parties have transmitted encrypted information to each other, which is known only to them, with the sender ensuring that it has reached the correct recipient (only Party B can have generated the M2 received) and the recipient ensuring who the actual sender was (only Party A can have generated the M1 received).

[0292] A schematic of this operation and message flow is shown in FIG. 4.

[0293] An actual application of the above case would be where an e-mail server of party A sends a certified message with acknowledgement of receipt to another e-mail server of party B. By operating in this way, party A is assured that the information in the e-mail has reached party B only. By operating in this way, party A is assured that the information in the mail has reached party B only, and party B in turn is assured that the information has come from party A. In this way, it is possible to avoid receiving mails whose real sender is impersonating a party and is taking advantage of it to transmit false information in order to commit fraud. An example of this type of fraud is the Business Email Compromise (BEC) or MAN-IN-THE-EMAIL scams.

[0294] As a second example of Mode of use of the authentication and encryption system, object of the invention, it is now applied to the execution of an operation requested by Party A to Party B, operation in which the mutual authentication of the Parties and the confirmation of the request by the requesting Party is necessary prior to the execution of such operation. A peculiarity of the operation is the fact that the data of the operation to be executed are received by the authentication application AA1 by means of a communication between the devices D1A and D2A (supported by AA1) of Party A.

[0295] Characteristics

[0296] The embodiment makes use of the described simplified authentication procedure. Therefore, only the Central Party (Party B) can dialogue with all other Parties (Party A), which are integrated in the authentication system supporting the authentication procedure, while they can only dialogue with the Central Party.

[0297] The authentication procedure will only work correctly in a Party A specific AA authentication application and with a given CA activation code. Thus, even if someone copies the AA, he/she encounters the problem of not knowing the CA.

[0298] If the Central Party is called Party B and the rest of the Parties are generically called Party A, the characteristics to be highlighted in this authenticated dialogue according to the authentication system are: [0299] the parties, Party A and Party B, are unequivocally identified to each other within the authentication system by a first and second identifier; [0300] Party A has at least a first physical or logical device (D1A) and a second physical or logical device (D2A) in which a first authentication application (AA1) resides; [0301] the first device of the first part D1A is most often a PC, (although it can also be a mobile phone, ATM, physical or logical Point-of-Sale Terminal, or any other device, physical or logical, with equivalent capabilities), which can request transactions from a computer system and assist in their execution on behalf of Party A. [0302] the second device of the first part D2A will normally be a smart mobile phone but can also be any other device, physical or logical, with equivalent capabilities, on which the AA1 authentication application software can run; [0303] to activate such first authentication application AA1 Party A will have to key in a CA Activation Code or make use of a means (Party A's fingerprint, an Access Card NFC-type or with a QR code, a microcontroller, or any other similar means) which will provide AA1 with the CA Activation Code; [0304] Party B has a physical or logical device (D1B) on which resides a second authentication application (AA2), unequivocally related, within the authentication system, to the first authentication application AA1. This AA2 is active and running in a secure environment with the necessary security measures to be able to believe that only Party B can have access to the AA2 application and its data. [0305] said AA2 is part of Party B's computer system and can interact with the operational applications (AO) supported by said computer system, with which Party A, from its first device (D1A), can perform operations relating to the operational activity of Party B's computer system. An illustrative representation can be seen in FIG. 1; [0306] such AA2 may relate to as many Party A authentication applications as there are users in the Party B computer system; [0307] these first and second applications, AA1 and AA2, each have a unique identifier within the authentication system, IdA and IdB respectively; [0308] The first and the second application share the same CC encryption key which they will use throughout the mutual authentication procedure; [0309] This first AA1 application has a pseudo-random value generator algorithm; [0310] the said first and second applications, AA1 and AA2, each have the same AES 128 encryption algorithm, or any other with similar characteristics, for their encryption/decryption operations; [0311] the AA2 shall have as many different CC Encryption key values as there are Party A authentication applications related to it; [0312] the devices of such Party A and Party B are communicating over one or more different physical or logical communication channels; [0313] optionally, all messages exchanged between Parties A and B are stored by the authentication system in a file for later use as a system activity log (LOG) file.

[0314] Operation [0315] Party A through its first device D1A requests the execution of an operation from one of operational applications (AO) of Party B; [0316] the AO operating application receives from the device of Party A, D1A, the transaction request with the DO transaction data. This request with its DO data shall be authenticated and authorized by Party A from its Authentication Application due to the lack of security of the channel through which the request has been received and the need for authentication/confirmation required for the execution of the operation; [0317] the operational application AO prepares the received OD transaction data and sends it to the authentication application of Party B, AA2, which receives it and leaves it waiting to be authenticated by Party A; [0318] the AO application takes the received DO operation data and formats it by adapting it to the medium in which it will later be read by the AA1 from the D1A (reading a QR, transmitting via NFC, . . . ) and forwards it to the D1A device. [0319] optionally, it can be AA2 itself that is in charge of this formatting of the data that through the AO sends it to D1A. [0320] Party A activates its AA1 authentication application by providing the CA activation code; [0321] Party A making use of a possible communication between D1A and D2A (e.g. by scanning with its AA1, supported by the D2A, a QR code that the AO presents on its web page in the D1A, or by communicating via NFC the AA1 with the D1A, or any other possible form of communication between the AA1 and the D1A). The AA1 receives in its AA1 the OD data of the operation to be authenticated and confirmed, and presents them on screen to the user (Party A) for confirmation as data of the operation to be carried out. If Party A confirms the data, its authentication application AA1 sends to Party B's authentication application a first encrypted message M1, according to the simplified authentication procedure, in which the data of the transaction, requested and confirmed by Party A, which Party B has yet to authenticate, are already encrypted; [0322] the authentication application of Party B, AA2, receives this first message M1 encrypted according to the authentication procedure and accesses the pending operations to be authenticated to check that Party A has a pending operation to be authenticated and, if correct, decrypts the message according to the authentication procedure, and if among the decrypted data is the correct VRM1, checked against its recalculated value, it will be because the message comes from the authentication application of Party A as it is the only one that can have encrypted it as received, thus Party A is authenticated as the originator of the message against Party B, as well as the message and its content. The AA2 verifies that the transaction data received coincide with those of the transaction pending authentication and, if so, authenticates and confirms the transaction by communicating it to the AO. The AO, via device D1A, shall inform Party A of this confirmation. [0323] Party B sends an M2 message to AA1 informing it of the result of the authentication operation it requested in its M1 message. For this purpose, the authentication application of Party B constructs a second M2 encrypted message, according to the simplified authentication procedure, containing the operation data together with the result of the confirmation and sends it to authentication application AA1 of Party A; [0324] the authentication application of Party A receives the M2 encrypted message, processes it according to the simplified authentication procedure, and verifies that VAM2 is the value used for the calculation of VRM2, thus authenticating Party B as the originator of the message vis-à-vis Party A, as it is the only one together with Party A that knows this VAM2 value, and the fact that this M2 is the response to the sent M1, thus ensuring that its authentication request has been received by Party B and has been correctly processed.

[0325] A schematic of this operation and message flow is shown in FIG. 2.

[0326] An actual application of this way of operating is the case of a payment made with a mobile phone at an NFC terminal. Here the D1A is the NFC payment terminal; the AO is the bank's application that processes the payments made on that payment terminal; the DOs are the payment transaction data; AA2 is the central authentication server that is part of the bank's computer system; AA1 is the NFC payment application supported by the user's mobile phone, D2A. In this case, operating as described, the bank, through its central authentication server (party B), knows that the message M1 with the payment details to be made was sent by the user's application (party A) and the user, on receiving the message M2, knows that the information that arrives comes from the bank's central authentication server (party B) as only they know the decryption key CC used to encrypt the message M1. In addition, the central authentication server knows that the payment data that arrived encrypted in message M1 are those that the user has validated with the application on his mobile phone so that they are the correct payment data, and if they do not match those that the SCA received from the operational application of the AO payment, there has been an interception and manipulation of the data sent from the D1A to the AO (possible Man In The Middle type fraud attempt) and they must be rejected, thus avoiding fraud.

[0327] Finally, a preferred embodiment is described. Mode in which Party A requests the execution of an operation to Party B and, applying the authentication system subject of the invention, performs a mutual authentication of the two Parties and authenticates and confirms the operation to be executed.

[0328] Characteristics

[0329] The preferred embodiment makes use of the described simplified authentication procedure in which simplifications 2 and 3 are applied. Thus: only the Central Party can dialogue with all Parties A, generic name for each of the Parties that can dialogue with the Central Party (Party B), and the Parties A can only dialogue with the Central Party; and the encryption algorithm to be used will be AES.

[0330] The authentication system will only work correctly in a specific AA application of each Party A and with a specific CA activation code, since the generation of the CC encryption key will make use of the CA of specific variables of the AA. Thus, even if someone copies the AA, he/she is faced with the problem of not knowing the CA and, therefore, the lack of the CC value necessary to be able to operate with it.

[0331] If the Central Party is called Party B and the rest of the Parties are generically called Party A, the characteristics to be highlighted in this authenticated dialogue according to the authentication system are: [0332] the parties, Party A and Party B, are unequivocally identified to each other, and to the authentication system, by means of a first and second identifier; [0333] Party A has at least a first physical or logical device (D1A) and a second physical or logical device (D2A) in which a first authentication application (AA1) resides; [0334] the first device of the first part D1A is most often a PC, (although it can also be a mobile phone, ATM, physical or logical Point-of-Sale Terminal, IoT control panel, or any other device, physical or logical, with equivalent capabilities), which can request transactions from a computer system and assist in their execution on behalf of Party A. [0335] the second device of the first part D2A will normally be a smart phone, but can also be any other device, physical or logical, with equivalent capabilities, on which the AA1 authentication application software can run; [0336] to activate such first authentication application AA1 Party A will have to key in a CA Activation Code or make use of a means (Party A's fingerprint, an NFC or QR Code Access Card, or any other similar means) which will provide AA1 with the CA Activation Code; [0337] Party B has a physical or logical device (D1B) on which resides a second authentication application (AA2), unequivocally related, within the authentication system, to the first authentication application AA1. This AA2 is active and running in a secure environment with the necessary security measures to be able to assume that only Party B can have access to the AA2 application and its data; [0338] Party B has operational applications (AO), supported by its computer system, with which Party A, from its first device (D1A), can perform operations relating to the operational activity of Party B's computer system; [0339] said second authentication application AA2, of Party B, is part of the computer system and is related to its operational applications AO (FIG. 1); [0340] said second authentication application of Party B can relate to as many Party A authentication applications as there are users in the Party B computer system; [0341] said first and second application, AA1 and AA2, each have a unique identifier within the authentication system, IdA and IdB respectively; [0342] said first and the second application share the same CC encryption key which they will use throughout the mutual authentication procedure; [0343] said first application, AA1, has a pseudo-random number generator algorithm; [0344] said first and second application, AA1 and AA2, each have the same AES 128 encryption algorithm, or any other with similar characteristics, for their encryption/decryption operations; [0345] the AA2 will have as many different CC Encryption key values as there are Party A authentication applications related to it; [0346] the devices of said Party A and Party B are communicating over one or more different physical or logical communication channels; [0347] optionally, all the messages exchanged between Parties A and B are stored by the authentication system in a file for later use as a system activity log (LOG) file.

[0348] Operation [0349] Party A through its first device D1A requests the execution of an operation from one of Party B's operational applications (AO); [0350] the operational application AO receives from the device of Party A, D1A, the transaction request with the transaction data DO which shall be authenticated and authorized by Party A from its Authentication Application AA1 due to the lack of security of the channel through which the request has been received and the need for confirmation required for the execution of the transaction; [0351] the operational application AO prepares the received OD transaction data and sends it to the authentication application of Party B, AA2, which receives it and waits for it to be authenticated by Party A; [0352] Party A activates in its D2A its authentication application AA1 by providing the activation code CA; [0353] Party A with its authentication application AA1 is the one sending a first encrypted message M1, according to the authentication procedure, to authentication application of Party B indicating that it wants to authenticate a transaction that Party A has requested from its first device D1A, and that Party B must have pending to authenticate. Among the transaction data travelling encrypted will be the address of the Sender of the message within the network over which it communicates; [0354] the authentication application of Party B, AA2, receives this first message M1 encrypted according to the authentication procedure and accesses the pending operations to be authenticated to check that Party A has a pending operation to be authenticated and, if it is correct, decrypts the message according to the authentication procedure, and if among the decrypted data is the correct VRM1, checked against its recalculated value, it will be because the message comes from authentication application of Party A as it is the only one that can have encrypted it in the received form, thus Party A is authenticated as the originator of the message against Party B as well as the message and its content. In the event that it does not find a transaction waiting to be authenticated, AA2 will store the message, for a pre-defined short time, waiting for a Party A transaction to arrive from the AO that needs to be authenticated (logically at a given time for the same Party A there cannot be more than one transaction waiting for the other data it needs to initiate its processing); [0355] after verifying that the data of the waiting transaction is compatible with the information received by AA2, AA2 constructs a second M2 encrypted message, according to the authentication procedure, containing the data of the transaction pending authentication and sends it to the Party A authentication application; [0356] the authentication application of Party A receives the encrypted message M2, decrypts it according to the authentication procedure and checks the validity of the VAM2, thus authenticating Party B as the originator of the message against Party A, as well as the message and its content, and the fact that this M2 is the response to the M1 sent. AA1 then presents the transaction data to Party A on its device D2A for it to verify that it corresponds to the transaction data that it has requested from its device D1A and, if so, to authorize, or not, the transaction. To communicate its decision, it creates the M3 message, according to the encryption and authentication procedure, with the transaction data and the result of the authorization to send it to authentication application of Party B; [0357] the authentication application of Party B receives the encrypted message M3 and processes it according to the authentication procedure, and if among the decrypted data is the VAM3 that corresponds to it, it will be because the message comes from Party A's authentication application, as it is the only one that can have encrypted it in the form received, so Party A is authenticated as the creator of the message against Party B, as well as the message and its content, and the fact that this M3 is the response to the M2 sent. It verifies that the data of the operation to be authorized match with those pending to be authenticated/confirmed and communicates to the Operational Application, AO, of Party B the result of the authentication and authorization of the operation performed by Party A. Optionally, it sends an M4 message to Party A's authentication application, AA1, to inform Party A of the completion of the operation; [0358] the operational application of Party B shall send a message to the Party A device D1A informing it of the result of the operation;

[0359] A schematic of this operation and message flow is shown in FIG. 3.

[0360] An actual application of this way of operating is the case of making a transfer in online banking. Here the D1A is the PC from which online banking is operated; the AO is the bank's application that handles the transfer operations; the DOs are the transfer data; AA2 is the central authentication server that is part of the bank's computer system; AA1 is the authentication application supported by the user's mobile phone, D2A.

[0361] In this case, operating in the manner described, the bank, through its central SCA authentication server, knows that message M1 was sent by the application of user Party A, and said user, on receiving message M2, knows that the transfer data received comes from the bank's central SCA authentication server, as only they are the ones who know the decryption key CC used to encrypt message M1. In addition, the SCA knows that the data of the transfer to be carried out that arrived encrypted in message M3 are those that the user has validated with the application on his mobile phone, so that they are the correct ones. If the user had rejected the operation because the transfer data received in M2 do not match those requested from D1A, it will be because there has been an interception and manipulation of the data sent from D1A to the AO (possible man-in-the-middle fraud attempt) since it is the only communication that did not travel encrypted and, therefore, it is susceptible to manipulation.

[0362] The nature of the present invention having been sufficiently described, as well as the manner of putting it into practice, it is not considered necessary to explain it further so that any person skilled in the art may understand its scope and the advantages deriving therefrom, it being noted that, within its essential nature, it may be put into practice in other forms of realization which differ in detail from the one indicated by way of example, and to which the protection claimed will also apply provided that the fundamental principle thereof is not altered, changed or modified.