SECURE NODE ADMISSION IN A COMMUNICATION NETWORK
20180295117 ยท 2018-10-11
Inventors
Cpc classification
H04L2463/061
ELECTRICITY
H04L63/062
ELECTRICITY
H04L9/0861
ELECTRICITY
H04L12/2838
ELECTRICITY
H04L9/0891
ELECTRICITY
International classification
H04L12/28
ELECTRICITY
H04L9/08
ELECTRICITY
H04L9/32
ELECTRICITY
Abstract
System and methods are provided for admission to networks that include at least one node providing network coordinator functions. A network coordinator may have a random number generator, with the network coordinator distributing a random number within a network that include at least a first node and a second node. The network coordinator may receive a request for a dynamic encryption key from the first node, with the request being encrypted using a static encryption key unique to the first node, and with the static encryption key being determined based on the distributed random number. The network coordinator may then send a dynamic encryption key to the first node, with the dynamic encryption key being encrypted using the static encryption key. The second node may then admit the first node into the network. The network may be a Multimedia over Coax Alliance (MoCA) network.
Claims
1. (canceled)
2. A system comprising: a network coordinator that comprises a random number generator, wherein the network coordinator is operable to: distribute a random number within a network comprising at least a first node and a second node; receive a request for a dynamic encryption key from the first node, wherein the request is encrypted using a static encryption key unique to the first node, and wherein the static encryption key is determined based on the random number; and send a dynamic encryption key to the first node, wherein the dynamic encryption key is encrypted using the static encryption key.
3. The system of claim 2, wherein the random number is distributed within a data link layer.
4. The system of claim 2, wherein the request for the dynamic encryption key is received within a data link layer.
5. The system of claim 2, wherein the request for the dynamic encryption key is received within a Layer-2 Management Entity (L2ME) response.
6. The system of claim 2, wherein the static encryption key is used in a media access control (MAC) sublayer.
7. The system of claim 2, wherein the static encryption key comprises an AES MAC Management Key (AMMK).
8. The system of claim 2, wherein the static encryption key is generated according to a network password for the first node.
9. The system of claim 2, wherein the network is a Multimedia over Coax Alliance (MoCA) network.
10. The system of claim 2, wherein the random number is distributed according to a Multimedia over Coax Alliance (MoCA) key.
11. The system of claim 2, wherein the second node is operable to admit the first node into the network.
12. A method comprising: in a network coordinator that comprises a random number generator: distributing a random number to at least a first node and a second node; receiving a request for a dynamic encryption key from the first node, wherein the request is encrypted using a static encryption key unique to the first node, and wherein the static encryption key is determined based on the random number; and sending a dynamic encryption key to the first node, wherein the dynamic encryption key is encrypted using the static encryption key.
13. The method of claim 12, wherein the random number is distributed within a data link layer.
14. The method of claim 12, wherein the request for the dynamic encryption key is received within a data link layer.
15. The method of claim 12, wherein the request for the dynamic encryption key is received within a Layer-2 Management Entity (L2ME) response.
16. The method of claim 12, wherein the static encryption key is used in a media access control (MAC) sublayer.
17. The system of claim 12, wherein the static encryption key comprises an AES MAC Management Key (AMMK).
18. The method of claim 12, wherein the static encryption key is generated according to a network password for the first node.
19. The method of claim 12, wherein the network coordinator is operable in a Multimedia over Coax Alliance (MoCA) network.
20. The method of claim 12, wherein the random number is distributed according to a Multimedia over Coax Alliance (MoCA) key.
21. The method of claim 12, wherein the first node was previously admitted by the second node.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0031] One or more embodiments of the disclosed method and apparatus are described in detail with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict either typical embodiments or examples of particular embodiments of the disclosed method and apparatus. These drawings are provided to facilitate the reader's understanding of the disclosed method and apparatus and shall not be considered limiting of the breadth, scope, or applicability of the claimed invention. It should be noted that for clarity and ease of illustration these drawings are not necessarily made to scale.
[0032]
[0033]
[0034]
[0035]
[0036]
[0037]
[0038]
[0039]
DETAILED DESCRIPTION
[0040] In one embodiment of the disclosed method and apparatus, similar to networks that operate in accordance with MoCA 1.x and MoCA 2.0, a total of four encryption keys are used to gain admission and to communicate once a node (also referred to as a network device) is admitted. These four keys are specified in Table 1. There are two static keys and two dynamic keys.
TABLE-US-00001 TABLE 1 Encryption Keys Key Type Key Usage Static Keys AES MAC Encryption of MAC Control except Management Key for Link Privacy Messages. (AMMK) Initial AES Privacy Encryption of Link Privacy messages management Key when the current APMK being used (APMKInitial) by the rest of the network is not available (e.g., prior to admission). Dynamic AES Privacy Encryption of Link Privacy messages Keys Management Key when the current APMK being used (APMK) by the rest of the network is available. AES Traffic Encryption of MAC Data Encryption Transmissions Key (ATEK)
[0041] In one embodiment, the two static keys are used as admission keys. They are called static keys because they are based on a network password and a permanent SALT, and do not change unless the password or SALT are changed. The first of the static keys is an AES MAC Management Key (AMMK) and second is an Initial AES Privacy Management Key (APMKInitial).
[0042] In one such embodiment, the two dynamic keys change periodically in order to enhance the security of the network. The first of the dynamic keys is referred to as AES Privacy Management Key (APMK). The second of the dynamic keys is referred to as AES Traffic Encryption Key (ATEK).
[0043] The AMMK is used for encryption of MAC Control Messages with the exception of any Link Privacy Messages. The Link Privacy Messages during the admission process are encrypted using the APMKInitial. Link Privacy Messages include messages used to transfer the dynamic keys to an NN during admission. For the purposes of this disclosure, the definition of the NN is a node that is requesting admission to a network.
[0044] The admission process may be performed at initialization (e.g. initial application of power, reset or after the power has been cycled) or when a node within the network loses synchronization with the NC. In accordance with one embodiment, if, for any reason, a node gets out of sync with the dynamic keys maintained by the NC, then the NC drops the node from the network. The node must then be re-admitted to the network using the static keys.
[0045] After admission and during normal network operations, ATEK is used to encrypt data messages. Furthermore, in normal network operations, APMK is used to encrypt Link Privacy messages after a node has been admitted.
[0046] According to various embodiments of the disclosed method and apparatus, a node that is seeking admission to a network initiates the admission process by sending a request for a SALT. In accordance with one such embodiment, the request for the SALT is made by sending a discovery request. That is, the SALT is sent to the NN in response to the NN sending a discovery request. In one embodiment, the SALT is a 96 bit long random value generated by the NC, although other bit lengths can be chosen. This random string is used as the SALT for all network admissions. The random string can be generated by one or more commonly known mechanisms. For example, a pseudorandom number generator module can be used to generate a sequence of numbers determined by a small set of initial values.
[0047] The SALT preferably does not change except when the network is re-formed, such as, for example if all nodes of the network suffer a power outage at the same time. When the network is re-formed, a new permanent SALT can be generated. Use of a permanent SALT means the NC does not need to recalculate static keys each time a node requests access. In one embodiment, the SALT is generated before the network is formed. Alternatively, the NC can generate the SALT once when the network is initially formed and then maintain that SALT value in memory for further use later as additional nodes request admission to the network. In some cases, the network is considered to have been initially formed when the second node is put onto the communication medium (for example, connected to the coaxial cable that is used as the communication medium). Accordingly, a request from the second node to join the network (the first node to request admission after an NC is established) starts a process for obtaining a SALT for the network.
[0048] In one embodiment, the request for the SALT may be made in the form of a discovery request sent from the NN. In one such embodiment, the request is sent to a Network Coordinator node (NC). The NC provides the SALT to a requesting node in a discovery response message sent by the NC to the requesting node. Alternatively, the NC may distribute the SALT during mixed mode operation, as described in more detail below. Alternatively, the SALT can be distributed to the nodes of the network by any messaging available between the nodes and the NC.
[0049] Once obtained, the SALT is combined with the requesting node's password to create the static keys. In one embodiment, an ASCII string is also used in the generation of the static keys. Details regarding the generation of the static keys is provide further below. Once generated, the static key is used to encrypt messages communicated between the NN and the NC during the admission process. In addition, the AMMK is used to encrypt MAC control messages (except for privacy messages) after the admission process is complete. The admission process results in obtaining the dynamic keys necessary for ongoing secure communications. It will be understood that other processes and functions may occur during the admission process that are not relevant to the disclosed method and apparatus for generating a static key. Once the dynamic keys are obtained, all network communications are encrypted by either the dynamic keys or the AMMK.
[0050] As noted above, it is important to provide as secure a network as possible. Ensuring that the static key is strong helps to ensure that the network remains secure. Accordingly, in one embodiment, a solution is provided that increases the strength of the key without increasing the length of the password. In one embodiment, the password length is 10 to 17 decimal digits, which is equivalent to 40 to 56 bits. As noted above, in one embodiment the SALT is 96 random bits, although other bit lengths can be chosen. Thus, the key space for the static keys, which are derived from both password and the SALT, has a nominal length of at least 136 (40+96) bits. This is greater than the AES key length of 128 bits. The initial values calculated for the static keys are then truncated to fit within the 128 bit AES key space. It will be understood that the length of the password can be increased as well to further enhance the strength of the key, depending on the security goals of the system.
[0051]
[0052] In the embodiment illustrated in
[0053] The NC 305 sends a discovery response 314 at the time indicated in the beacon message 312. The discovery response 314 includes the SALT. In addition, if the NN 303 requested information about the network, that information would be included in the discovery response 314 as well. It should be noted that in one embodiment of the disclosed method and apparatus, the SALT is sent to the NN 303 whether the NN 303 requests an admission slot or not.
[0054] The NN 303 receives the discovery response 314 at the time indicated in the beacon message 312 and attains the value of the network SALT from the discovery response 314 (STEP 170). If the NN 303 included a request for an admission slot in the discovery request 311, a subsequent beacon message 317 will indicate when the NC 305 has scheduled the NN 303 to send an admission request 318.
[0055] The principle reason for requesting an admission slot within the discovery request 311 is to have the NC 305 schedule a time during which the NN 303 can send the admission request 318. The NN 303 generates one or more static keys using a combination of at least the network password and the SALT received in STEP 170. In one embodiment, the NN 303 uses an ASCII string in addition to the SALT and password to generate the static keys (STEP 172).
[0056]
[0057] If the NN 303 does not include a request for an admission slot in the discovery request 311, the NC 305 will wait until receiving such a request before scheduling a time for the NN 303 to send an admission request 318.
[0058] Upon receipt of the admission request 318, the NC 305 schedules a slot in which an admission response 324 will be transmitted by the NC 305. The NC 305 then transmits the schedule in the next beacon message 322. The NN 303 receives the beacon message with the schedule for sending the admission response 324 (STEP 328) alerting the NN 303 to be ready to receive the admission response 324. Next, the NC 305 sends the admission response 324 at the time indicated by the beacon message 322. The NN 303 receives the admission response 324 encrypted by the AMMK (i.e., one of the two static keys) (STEP 250).
[0059] The NN 303 then receives the next beacon message 326 indicating when the NN 303 is to send an acknowledgement 328 that the NN 303 has successfully received the admission response (STEP 252). The NN 303 sends an acknowledgement 328 to the NC 305 encrypted by the AMMK indicating that the NN 303 has received the admission response (STEP 254). In one embodiment of the disclosed method and apparatus, the admission response 324 is the first a several admission process messages that are sent between the NC 305 and the NN 303. Each of the messages exchanged during this admission process are encrypted with the AMMK key. With the completion of these operations, the NN 303 is admitted to the network. At that point, the NN 303 can send a request for the dynamic keys to the NC 305. In one embodiment, the dynamic key request is encrypted by the APMKInitial key. The NC 350 will respond to the NN 303 by sending the dynamic keys. The response is also encrypted by the APMKInitial key (STEP 256). As noted above, the dynamic keys include two pairs of dynamic keys. The first pair includes the odd and even APMK. The second pair includes the odd and even ATEK.
[0060] Accordingly, all further messages to and from the NN 303 will be encrypted using the dynamic keys or the AMMK (STEP 258). From time to time, the NC 305 sends updated keys to the network nodes 303, 307 using the APMK. In this manner, keys are updated to provide an extra measure of security to the network.
[0061] The above example describes the generation of two static keys: AMMK and APMKInitial. An AES key generation function is used in one embodiment to generate the two static keys. The function accepts three arguments and returns a 128 bit static key. The key generation function applies a process known as RFC 2898/PKCS#5, which is defined by RSA labs. The process derives a static key from: an ASCII encoded password, P; a SALT value, S; and an ASCII encoded string, N.
[0062] In one embodiment, the static keys are calculated as follows:
1. T1=HMAC-SHA-256(P, SNINT(1))
2. T2=HMAC-SHA-256 (P, T1)
[0063] n. Tn=HMAC-SHA-256 (P, Tn1)
n+1. static key=(T1 XOR T2 XOR . . . XOR Tn)<0:127>
Where:
[0064] INT(1) is a four-byte long value encoding of the integer 1, most significant byte first (i.e., 0000 0000 0000 0001);
n is the iteration count of the function HMAC-SHA-256 and has a value 1000 as suggested by PKCS#5;
<0:127> indicates truncating the preceding value at the 128.sup.th bit (i.e., the AESKey is the first 128 bits of the string T1 XOR T2 XOR . . . XOR Tn in step n+1);
SNINT(1) indicates that the value of S, N and INT(1) are concatenated to form a single argument;
HMAC-SHA-256(P, X)=SHA-256(P XOR opadSHA-256 (P XOR ipadX));
SHA-256 is a SHA-2 hashing function as defined in FIPS 180-2;
ipad is the binary value of 36 (hexadecimal) repeated 64 times (i.e., 0011 0110 0011 0110 0011 0110 0011 0110 0011 0110 0011 0110); and
opad is binary value of the 5C (hexadecimal) repeated 64 times.
[0065] As can be seen from the application of the above notation, HMAC-SHA-256(P, X) as defined in RFC 2104 and FIPS 180-2 is calculated by the following steps:
(1) Append zeros to the end of P to create a 64 byte string;
(2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with ipad;
(3) Append the stream of data X to the 64 byte string resulting from step (2);
(4) Apply SHA-256 to the stream generated in step (3);
(5) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with opad;
(6) Append the SHA-256 result from step (4) to the 64 byte string resulting from step (5);
(7) Apply SHA-256 to the stream generated in step (6) and output the result;
[0066] When generating the static key, increasing the iteration count n increases the cost of producing keys from a password, but also has the benefit of increasing the difficulty of attack. Setting n to be 1000, for example, increases the cost of an exhaustive search (brute force attack) for passwords significantly, without a noticeable impact in the cost of deriving individual keys. In one embodiment, each network node implements a hardware key lockout time of at least 1 ms to prevent successive key updates. Alternatively, there is no lockout time. Given the minimum password space of 40 bits, it takes at least 2 raised to the 40.sup.th power times 1 ms to exhaust searching through the entire password space in a brute force attack. That is equal to 35.2 years.
[0067] The manner in which the dynamic keys are generated is left up to the implementation and is not important to the disclosed method and apparatus. However, it should be noted that the SALT could be used in the generation of the dynamic keys as well.
[0068] The systems and methods described herein can also be used in a mixed mode MoCA network. A mixed mode MoCA network is a MoCA network that includes both MoCA 1.x (i.e., MoCA 1.0 and MoCA 1.1) and MoCA 2.0 nodes. Since MoCA 1.x does not use AES keys and does not use a SALT value, it is advantageous to upgrade the network operation as much as possible to conform with MoCA 2.0. Therefore, in a mixed mode MoCA network, when an NC handoff occurs and a MoCA 2.0 node accepts the NC role from a MoCA 1.x node, the MoCA 2.0 NC needs to distribute its permanent SALT to other existing MoCA 2.0 nodes to allow them to derive static keys using the SALT and the password without requiring the node to go through the admission procedure. In a mixed mode network that is already established, the MoCA 2.0 NC distributes dynamic keys (e.g. the ATEKs and APMKs) after an admission process initiated by new MoCA 2.0 nodes. However, before a new MoCA 2.0 node is admitted to such a mixed network, the NC must distribute the permanent SALT to the node in a network discovery message exchange.
[0069]
[0070] In a Wave 0, the NC 365 specifies which of the MoCA 2.0 nodes are requested to participate. The MoCA 2.0 nodes are indicated using a WAVE0_NODEMASK. In one embodiment, each bit of the WAVE0_NODEMASK represents one of the MoCA 2.0 nodes. Each of the requested nodes sends a response frame 344. The following constraints are observed on various fields of the request frame 344.
[0071] VENDOR_ID=0x0 (MoCA)
[0072] TRANS_TYPE=0x2 (AES Key Distribution)
[0073] TRANS_SUBTYPE=0x0 for Permanent SALT distribution
[0074] WAVED_NODEMASK=Set to indicate selected MoCA 2.0 nodes in the MoCA Network
[0075] MSG_PRIORITY=0xF0
[0076] TXN_LAST_WAVE_NUM=2
[0077] L2ME_PAYLOAD=as shown in Table 2
TABLE-US-00002 TABLE 2 L2ME_PAYLOAD of Request L2ME Frame for Wave 0 Field Length Value L2ME Request payload PEMANENT_SALT 96 bits A random number.
[0078] Each node responds to the NC with a response frame with the following constraints:
RESP_STATUS=Bit 0 set to 1
[0079] L2ME_PAYLOAD=as defined in Table 3.
TABLE-US-00003 TABLE 3 L2ME_PAYLOAD for Response L2ME Frame for Permanent SALT Distribution Field Length Usage Response to L2ME Payload for Create Flow/Update Flow RESPONSE-CODE 8 bits RESPONSE_CODE_TRUE (0x01) if successful and RESPONSE_CODE_FALSE (0x00) otherwise. RESERVED 24 Type III bits
[0080] After successfully distributing the dynamic keys, the NC may then turn on the AES encryption flags in the MAPs that follow.
[0081] Referring now to
[0082] Computing module 400 might include, for example, one or more processors, controllers, control modules, or other processing devices, such as a processor 404. Processor 404 might be implemented using a general-purpose or special-purpose processing engine such as, for example, a microprocessor, controller, or other control logic. In the illustrated example, processor 404 is connected to a bus 402, although any communication medium can be used to facilitate interaction with other components of computing module 400 or to communicate externally.
[0083] Computing module 400 might also include one or more memory modules, simply referred to herein as main memory 408. For example, preferably random access memory (RAM) or other dynamic memory, might be used for storing information and instructions to be executed by processor 404. Main memory 408 might also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 404. Computing module 400 might likewise include a read only memory (ROM) or other static storage device coupled to bus 402 for storing static information and instructions for processor 404.
[0084] The computing module 400 might also include one or more various forms of information storage mechanism 410, which might include, for example, a media drive 412 and a storage unit interface 420. The media drive 412 might include a drive or other mechanism to support fixed or removable storage media 414. For example, a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a CD or DVD drive (R or RW), or other removable or fixed media drive might be provided. Accordingly, storage media 414 might include, for example, a hard disk, a floppy disk, magnetic tape, cartridge, optical disk, a CD or DVD, or other fixed or removable medium that is read by, written to or accessed by media drive 412. As these examples illustrate, the storage media 414 can include a computer usable storage medium having stored therein computer software or data.
[0085] In alternative embodiments, information storage mechanism 410 might include other similar instrumentalities for allowing computer programs or other instructions or data to be loaded into computing module 400. Such instrumentalities might include, for example, a fixed or removable storage unit 422 and an interface 420. Examples of such storage units 422 and interfaces 420 can include a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, a PCMCIA slot and card, and other fixed or removable storage units 422 and interfaces 420 that allow software and data to be transferred from the storage unit 422 to computing module 400.
[0086] Computing module 400 might also include a communications interface 424. Communications interface 424 might be used to allow software and data to be transferred between computing module 400 and external devices. Examples of communications interface 424 might include a modem or softmodem, a network interface (such as an Ethernet, network interface card, WiMedia, IEEE 802.XX or other interface), a communications port (such as for example, a USB port, IR port, RS232 port Bluetooth interface, or other port), or other communications interface. Software and data transferred via communications interface 424 might typically be carried on signals, which can be electronic, electromagnetic (which includes optical) or other signals capable of being exchanged by a given communications interface 424. These signals might be provided to communications interface 424 via a channel 428. This channel 428 might carry signals and might be implemented using a wired or wireless communication medium. Some examples of a channel might include a MoCA channel over coaxial cable, phone line, a cellular link, an RF link, an optical link, a network interface, a local or wide area network, and other wired or wireless communications channels.
[0087] In this document, the terms computer program medium and computer usable medium are used to generally refer to physical storage media such as, for example, memory 408, storage unit 420, and media 414. These and other various forms of computer program storage media or computer usable storage media may be involved in storing and providing one or more sequences of one or more instructions to a processing device for execution. Such instructions embodied on the medium, are generally referred to as computer program code or a computer program product (which may be grouped in the form of computer programs or other groupings). When executed, such instructions might enable the computing module 400 to perform features or functions of the disclosed method and apparatus as discussed herein.
[0088] While various embodiments of the disclosed method and apparatus have been described above and shown in various figures, it should be understood that they have been presented by way of example only, and not of limitation. It should be understood that the various features, aspects and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described, but instead can be applied, alone or in various combinations, to one or more of the other embodiments of the disclosed method and apparatus, whether or not such embodiments are described and whether or not such features are presented as being a part of a described embodiment. Also, a multitude of different constituent module names other than those depicted herein can be applied to the various partitions. Additionally, with regard to flow diagrams, operational descriptions and method claims, the order in which the blocks are presented herein shall not mandate that various embodiments be implemented to perform the recited functionality in the same order unless the context dictates otherwise. Thus, the breadth and scope of the claimed invention should not be limited by any of the above-described embodiments which are presented as mere examples for illustration only.
[0089] Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term including should be read as meaning including, without limitation or the like; the term example is used to provide some of the many instances of the item in discussion, not an exhaustive or limiting list thereof; and the terms a or an should be read as meaning at least one, one or more or the like. Likewise, where this document refers to technologies that would be apparent or known to one of ordinary skill in the art, such technologies encompass those apparent or known to the skilled artisan now or at any time in the future.
[0090] As used herein, the term module might describe a given unit of functionality that can be performed in accordance with one or more embodiments of the disclosed method and apparatus. As used herein, a module might be implemented using any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logical components, software routines or other mechanisms might be implemented to make up a module. In implementation, the various modules described herein might be implemented as discrete modules or the functions and features described can be shared in part or in total among one or more modules. In other words, as would be apparent to one of ordinary skill in the art after reading this description, the various features and functionality described herein may be implemented in any given application and can be implemented in one or more separate or shared modules in various combinations and permutations.
[0091] Where components or modules of the disclosed method and apparatus are implemented in whole or in part using software, in one embodiment, these software elements can be implemented to operate with a computing or processing module capable of carrying out the functionality described with respect thereto. One such example a computing module is shown in