Diameter end-to-end security with a multiway handshake

• US 10,277,576 B1
• Filed: 06/28/2018
• Issued: 04/30/2019
• Est. Priority Date: 06/29/2017
• Status: Active Grant

• Current Assignee: Syniverse Technologies LLC (Syniverse Corp.)
• Original Assignee: Syniverse Technologies LLC (Syniverse Corp.)
• Inventors: Yau, Edward
• Primary Examiner(s): Moorthy, Aravind K
• Application Number:
  US16/021,763
• Time in Patent Office: 306 Days
• Field of Search: 726 4, 726 5, 726 26, 713168, 713170, 713176, 380262
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/0892 by using authentication-authorization-accounting [AAA] servers or protocols
• CPC Class Codes: H04L 63/10 for controlling access to devices or network resources
• CPC Class Codes: H04L 63/123 received data contents, e.g. message integrity
• CPC Class Codes: H04L 67/01 Protocols
• CPC Class Codes: H04L 67/55 Push-based network services
• CPC Class Codes: H04L 9/3236 using cryptographic hash functions
• CPC Class Codes: H04L 9/3247 involving digital signatures
• CPC Class Codes: H04L 9/3271 using challenge-response

Abstract

A method of enhancing end-to-end security of the Diameter protocol. A client transmits a Request message to the server. The request message has a signature, which is generated by encrypting a hash result calculated by the client using predefined AVPs of the Request message. The server validates the signature by independently calculating the hash result and determining whether the hash result within the signature matches the calculated result. Upon successful validation of the signature, the server transmits an Answer message to the client. The Answer message contains a nonce value and a request for Authenticator message from the client. The client transmits an Authenticator message having a second signature based on the hash result calculated using the nonce. The server compares the received hash result with the calculated hash result. If there is a match, the server updates the information requested in the Request message.

Claims

1. A method of validating a message transmitted from a client to a server via a Diameter protocol comprising the steps of:

receiving a Request message from the client, the Request message having a digital signature and an Attribute Value Pair (AVP);

responsive to the Request message requesting an update of information at the server, classifying the Request message as a Push message;

validating, by the server, the digital signature of the Request message transmitted by the client;

responsive to successful validation of the digital signature and classifying the Request message as the Push message, proceeding with second and third stages of a three-way handshake between the client and the server, the second and third stages of the three-way handshake comprising the steps of;

generating a nonce value by the server;

transmitting an Answer message to the client, the Answer message carrying the nonce value and containing an indicator requesting an Authenticator message from the client;

receiving, from the client, an Authenticator message carrying a first hash result calculated by the client using the nonce value and the AVP of the Request message as inputs;

comparing the first hash result received in the Authenticator message with a second hash result calculated by the server using the nonce value and the AVP of the Request message as inputs; and

responsive to the first hash result matching the second hash result, updating, at the server, the information requested in the Request message.

2. The method of claim 1, wherein the digital signature is generated by encrypting a third hash result calculated using an input selected from the group consisting of an Origin-Host AVP, an Origin-Realm AVP, and a Session-ID AVP of the Request message.

3. The method of claim 2, wherein the first and the third hash results are calculated using the same AVPs of the Request message as inputs into a hash algorithm.

4. The method of claim 1, wherein the digital signature is generated using a private key and is decrypted using a pre-shared public key.

5. The method of claim 1, wherein the step of validating the digital signature further comprises the steps of:

decrypting the digital signature to obtain a third hash result calculated by the client;

calculating a fourth hash result based on AVPs of the Request message used by the client to calculate the third hash result;

comparing the third and fourth hash results; and

validating the digital signature responsive to a match between the third and fourth hash results.

6. The method of claim 1, wherein the AVP of the Answer message used to calculate the first hash is selected from the group consisting of an Origin-Host AVP, an Origin-Realm AVP, and a Session-ID AVP.

7. The method of claim 1, wherein the first hash result received at the server is encrypted, by the client, using a private key and is decrypted, by the server, using a pre-shared public key.

8. The method of claim 1, wherein the indicator within the Answer message requesting the Authenticator message is established by setting a Diameter Header Request bit (bit-0) to 1 and an authenticator bit (bit-4) to 1.

9. The method of claim 1, wherein the indicator for the Authenticator message and the nonce are transmitted in a grouped AVP within the Answer message.

10. The method of claim 1, wherein the first hash result is encrypted within the Authenticator message.

11. A non-transitory computer-readable medium storing a program including instructions that, when executed by a processor, causes a Diameter server to perform the steps comprising:

responsive to receiving a Request message from the client, the Request message having a first digital signature and an Attribute Value Pair (AVP), classifying the Request message as a Push message if the Request message is a request to update information at the server;

validating the first digital signature of the Request message transmitted by the client;

responsive to successful validation of the first digital signature and classifying the Request message as the Push message, generating a nonce value and transmitting an Answer message to the client, the Answer message carrying the nonce value and containing an indicator requesting an Authenticator message from the client;

responsive to receiving, from the client, an Authenticator message having a second digital signature, validating the second digital signature by comparing a first hash result calculated by the client with a second hash result calculated by the server, wherein both the first and the second hash results are calculated using the nonce value and the AVP of the Request message as inputs; and

responsive to the first hash result matching the second hash result, updating the information requested in the Request message.

12. The method of claim 11, wherein the first digital signature is generated by encrypting a third hash result calculated using an input selected from the group consisting of an Origin-Host AVP, an Origin-Realm AVP, and a Session-ID AVP of the Request message.

13. The method of claim 12, wherein the first and the third hash results are calculated using the same AVPs of the Request message as inputs into a hash algorithm.

14. The method of claim 11, wherein the first digital signature is generated using a private key and is decrypted using a pre-shared public key.

15. The method of claim 11, wherein the step of validating the first digital signature further comprises the steps of:

decrypting the first digital signature to obtain a third hash result calculated by the client;

calculating a fourth hash result based on AVPs of the Request message used by the client to calculate the third hash result;

comparing the third and fourth hash results; and

validating the first digital signature responsive to a match between the third and fourth hash results.

16. The method of claim 11, wherein the AVP of the Answer message used to calculate the first hash is selected from the group consisting of an Origin-Host AVP, an Origin-Realm AVP, and a Session-ID AVP.

17. The method of claim 11, wherein the first hash result received at the server is encrypted, by the client, using a private key and is decrypted, by the server, using a pre-shared public key.

18. The method of claim 11, wherein the indicator within the Answer message requesting the Authenticator message is established by setting a Diameter Header Request bit (bit-0) to 1 and an authenticator bit (bit-4) to 1.

19. The method of claim 11, wherein the indicator for the Authenticator message and the nonce are transmitted in a grouped AVP within the Answer message.

20. The method of claim 11, wherein the first hash result is encrypted within the Authenticator message.