System and method for secure messaging in a hybrid peer-to-peer network

• US 8,611,540 B2
• Filed: 06/23/2010
• Issued: 12/17/2013
• Est. Priority Date: 06/23/2010
• Status: Active Grant

• Current Assignee: Damaka, Inc.
• Original Assignee: Damaka, Inc.
• Inventors: Chaturvedi, Sivakumar, Gundabathula, Satish
• Primary Examiner(s): Moorthy, Aravind
• Assistant Examiner(s): PLOTKIN, JASON R
• Application Number:
  US12/821,939
• Publication Number:
  US 20110317834A1
• Time in Patent Office: 1,273 Days
• Field of Search: None
• US Class Current: 380/273
• CPC Class Codes: H04L 63/061 for key exchange, e.g. in peer-to-peer networks cryptographic mechanisms or cryptographic arrangements for key agreement H04L9/0838
• CPC Class Codes: H04L 63/068 using time-dependent keys, e.g. periodically changing keys cryptographic mechanisms or cryptographic arrangements for controlling usage of secret information H04L9/088
• CPC Class Codes: H04L 67/104 Peer-to-peer [P2P] networks

Abstract

An improved system and method are disclosed for peer-to-peer communications. In one example, the method enables endpoints to securely send and receive messages to one another within a hybrid peer-to-peer environment.

Claims

1. A method for changing an encryption key by a first endpoint operating in a hybrid peer-to-peer network comprising:

retrieving, by a first endpoint, a profile from an access server following an authentication process, wherein the profile identifies a plurality of endpoints that includes a second endpoint as endpoints that have each previously granted the first endpoint permission to communicate with that endpoint and contains a unique encryption key for each of the plurality of endpoints that is online but not for any of the plurality of endpoints that are offline, and wherein a key for any particular endpoint of the plurality of endpoints that was offline when the profile is retrieved will be received by the first endpoint directly from the particular endpoint when the particular endpoint logs into the hybrid peer-to-peer network;

receiving, by the first endpoint, an instruction to change from a first encryption key to a second encryption key;

sending, by the first endpoint, a first message to the second endpoint that the first endpoint is going to change to the second encryption key, wherein the first message is defined for use with a transactional state model and includes information representing the second encryption key, and wherein the first message is encrypted using the unique encryption key for the second endpoint contained in the profile;

receiving, by the first endpoint, in response to the first message, a second message from the second endpoint indicating that the second endpoint received the first message, wherein the second message is defined for use with the transactional state model;

sending, by the first endpoint, a third message to the second endpoint acknowledging receipt of the second message, wherein the third message is defined for use with the transactional state model;

changing, by the first endpoint, from the first encryption key to the second encryption key, wherein all incoming messages for the first endpoint are to be encrypted using the second encryption key;

receiving, by the first endpoint, a fourth message from the second endpoint, wherein the fourth message is encrypted using the second encryption key;

applying a first key iteration of the second encryption key to the fourth message to determine if the first key iteration will decrypt the fourth message, wherein the second encryption key is used by the first endpoint to form a plurality of key iterations, and wherein each of the plurality of key iterations is a valid encryption key for the first endpoint;

if the first key iteration will not decrypt the fourth message, rotating the second encryption key to form a next key iteration from the second encryption key;

applying the next key iteration to the fourth message to determine if the next key iteration will decrypt the fourth message;

as long as untried key iterations are available, continuing the steps of rotating and applying for each key iteration until the fourth message is decrypted; and

rejecting the fourth message if no untried key iterations exist and the fourth message is not decrypted.

2. The method of claim 1 further comprising:

determining whether the decrypted fourth message is a correct message type; and

rejecting the fourth message if it is not the correct message type.

3. The method of claim 2 wherein the correct message type is a Session Initiation Protocol message.

4. The method of claim 1 wherein the transactional state model is a Session Initiation Protocol model and the first, second, and third messages are carried via the User Datagram Protocol.

5. The method of claim 1 further comprising receiving, by the first endpoint, a fourth message from the second endpoint that the second endpoint is going to change from a third encryption key to a fourth encryption key.

6. The method of claim 5 further comprising ignoring, by the first endpoint, the fourth message if the first message was sent before the fourth message.

7. The method of claim 6 further comprising determining, by the first endpoint, whether the first message and fourth message were sent within a defined period of time relative to one another, wherein the first endpoint does not change to the second encryption key if the first message and fourth message were sent within the defined period of time relative to one another.

8. The method of claim 7 further comprising receiving, by the first endpoint, a time offset to avoid a future collision with the second endpoint during a next key change event.

9. The method of claim 5 further comprising:

sending, by the first endpoint, in response to the fourth message, a fifth message to the second endpoint indicating that the first endpoint received the fourth message, wherein the fifth message is defined for use with the transactional state model;

receiving, by the first endpoint, a sixth message from the second endpoint acknowledging receipt of the fifth message, wherein the sixth message is defined for use with the transactional state model; and

changing, by the first endpoint, from the third encryption key to the fourth encryption key, wherein all messages to be sent from the first endpoint to the second endpoint are to be encrypted using the fourth encryption key.

10. The method of claim 9 further comprising rotating through a plurality of key iterations based on the fourth encryption key, wherein each of the plurality of key iterations is a valid encryption key for the second endpoint, and wherein each message sent from the first endpoint to the second endpoint uses a different key iteration than the previous message.

11. The method of claim 1 further comprising obtaining, by the first endpoint, the second encryption key from an access server via a secure channel.

19. The method of claim 1 further comprising receiving, by the first endpoint, a notification message from a third endpoint that the third endpoint is online, wherein the notification message includes a unique encryption key of the third endpoint, and wherein the unique encryption key of the third endpoint was not in the profile because the third endpoint was not online during the authentication process.

12. A method for receiving a secure message by a first endpoint operating in a hybrid peer-to-peer network comprising:

obtaining, by the first endpoint, a second base encryption key associated with the first endpoint after receiving an order from an access server to change from a first base encryption key to a second base encryption key, wherein the second base encryption key is to be used by the first endpoint to form a plurality of known key iterations that match a plurality of identical known key iterations that are available for use by a second endpoint to encrypt a message for the first endpoint, wherein the second endpoint uses the second base encryption key for the plurality of identical known key iterations, and wherein the first and second endpoints both use an identical rotation process to form the known key iterations;

receiving, by the first endpoint, an encrypted message from the second endpoint, wherein the encrypted message was encrypted by the second endpoint using one of the plurality of known key iterations and wherein the first endpoint does not know which of the identical known key iterations was used to encrypt the encrypted message because the rotation process is not synchronized between the first and second endpoints;

applying, by the first endpoint, a first key iteration of the second base encryption key to the encrypted message to determine if the first key iteration will decrypt the encrypted message;

if the first key iteration will not decrypt the message, rotating, by the first endpoint, the encryption key to form a next key iteration from the second base encryption key using the rotation process;

applying, by the first endpoint, the next key iteration to the encrypted message to determine if the next key iteration will decrypt the encrypted message;

as long as untried key iterations are available, continuing the steps of rotating and applying by the first endpoint for each key iteration until the message is decrypted; and

rejecting, by the first endpoint, the encrypted message if no untried key iterations exist and the message is not decrypted.

13. The method of claim 12 further comprising:

determining, by the first endpoint after decrypting the encrypted message, whether the decrypted message is a correct message type; and

rejecting the decrypted message if it is not the correct message type.

14. The method of claim 13 wherein the correct message type is a Session Initiation Protocol message.

15. The method of claim 12 further comprising:

determining, by the first endpoint if the decrypted message is a correct message type, whether the decrypted message is associated with a current state of a state machine of the first endpoint; and

rejecting the decrypted message if it is not associated with a current state of the state machine.

16. A system comprising:

a network interface;

a processor coupled to the network interface; and

a memory coupled to the processor and containing a plurality of instructions for execution by the processor, the instructions including instructions for configuring a first endpoint stored at least partially in the memory for secure communications between the first endpoint and a second endpoint by;

obtaining, by the first endpoint, a second base encryption key associated with the first endpoint after receiving an order from an access server to change from a first base encryption key to a second base encryption key, wherein the second base encryption key is to be used by the first endpoint to form a plurality of known key iterations that match a plurality of identical known key iterations that are available for use by a second endpoint to encrypt a message for the first endpoint, wherein the second endpoint uses the second base encryption key for the plurality of identical known key iterations, and wherein the first and second endpoints both use an identical rotation process to form the known key iterations;

receiving, by the first endpoint, an encrypted message from the second endpoint, wherein the encrypted message was encrypted by the second endpoint using one of the plurality of known key iterations and wherein the first endpoint does not know which of the identical known key iterations was used to encrypt the encrypted message because the rotation process is not synchronized between the first and second endpoints;

receiving, by the first endpoint, an encrypted message from a second endpoint;

applying a first key iteration of the second base encryption key to the encrypted message to determine if the first key iteration will decrypt the encrypted message;

if the first key iteration will not decrypt the message, rotating the encryption key to form a next key iteration from the second base encryption key using the rotation process;

applying the next key iteration to the encrypted message to determine if the next key iteration will decrypt the encrypted message;

as long as untried key iterations are available, continuing the steps of rotating and applying for each key iteration until the message is decrypted; and

rejecting the encrypted message if no untried key iterations exist and the message is not decrypted.

17. The system of claim 16 wherein the system is configured for coupling to a resource meter.

18. The system of claim 16 wherein the system is a resource meter.