Key Update of Multiple Nodes in a Secure Network

In a secure network, each node needs to maintain a temporary key to decrypt the packet information or to make a signature for the packet. Meanwhile, the temporary key needs to be updated periodically. A packet needs to go though the network hop by hop, and it will be handled by multiple nodes. When the keys are being updated, in the same node, some packets may need to be decrypted or signed by the old key, and some packets may need to be signed by the new key. The problem is caused by the fact that the communication is made by multiple elements along the path. In this case, not only the peer nodes join in the secure process, but also the middle nodes join into the secure process. It is different from the peer-to-peer scenario, for example the one described in . The main idea of the document is that we can add a flag in the packet to indicate whether the new key should be used by the node or the old key should be used. One assumption of the document is that the nodes will update the keys in the same time. However, it may take a while to finish all the key update, and the traffic should not be stopped while the updating.

A preliminary key updating mechanism is described in this section. The objective of the mechanism is to make sure the secure communication. Each node along the path should have a primary key to generate temporary keys, and we call them kti-j in this document, in which the "i" stands for the number of the node, and the "j" stands for the number of the temporary key. We have two cycles for the network, and they are called the odd cycle and the even cycle. At the first odd cycle, each node uses its temporary key, called ki-a in document, to do the decryption and signature. Also, each node will also have another temporary key, ki-b, and it will be used in the even cycle. In the first cycle, the ki-a is set to kti-1, and the ki-b is set to null. The ki-a is used as the active key of the Node i. The headend, which generates packets for a path, will use {kti-1} to encrypt the packet information, and the cycle flag is set to 1. In the second cycle, the kti-2 of each node is generated, and the ki-b is set to kti-2. At the front part of the cycle, all the packets are with the cycle flag 1. Within the cycle, the headend will use {kti-2} instead to encrypt the packet information, and the cycle flag is set to 0. At the end of the cycle, all packets with the cycle flag 1 should have finished and disappeared, and all packets are with the cycle flag 0. In the third cycle, the kti-3 of each node is generated, and the ki-a is set to kti-3. At the front part of the cycle, all the packets are with the cycle flag 0. Within the cycle, the headend will use {kti-3} instead to encrypt the packet information, and the cycle flag is set to 1. At the end of the cycle, all packets with the cycle flag 0 should have finished, and all packets are with the cycle flag 1. In the fourth cycle, the kti-4 of each node is generated, and the ki-b is set to kti-4. At the front part of the cycle, all the packets are with the cycle flag 1. Within the cycle, the headend will use {kti-4} instead to encrypt the packet information, and the cycle flag is set to 0. At the end of the cycle, all packets with the cycle flag 1 should have finished and disappeared, and all packets are with the cycle flag 0. Similar operation takes place afterwards. In the above mechanism, for a headend, all the paths will be encrypted by using the same {kti-j}. To improve the security, we can also generate another session key, {sti-j-p}, for a specific path "p". For example, they can be generated by using the a timestamp and the {kti-j}, and will be updated accordingly when the temporary key is updated. In this case, the packet header should also carry the timestamp. Hence, the node can generate the {sti-j-p} when the packet arrives. We assume that a controller exists for the key distribution. In each cycle, the kti-j of Node j will be sent to the controller. For each headend, if it want to generate a path by using the session key, it need to send a timestamp to the controller, and the controller will respond a session key for the path. Afterwards in each cycle, the session key will be updated and provide to the headend. Hence, the headend can use the {sti-j-p} to encrypt the packet.