Abstract:
The present invention provides a solution of automatically distributing PIP keys, and on that basis, provides a new encryption method. A domain control device is proposed to verify whether a network node is an eligible node in the domain; if the network node is an eligible node in the domain, then a key for the PTP protocol is sent to the network node. The methods and apparatuses according to the present invention enable access authentication of various forms of PTP network nodes, as well as the automatic configuration and dynamic sending of PTP keys, such that the security of the keys are significantly increased. Additionally, by means of SignCryption encryption algorithm, it is enabled that for each PTP message, not only message source authentication, message integrity authentication, message confidentiality, and replay protection can be provided, but also its sending network node can be tracked. Thus, the security is significantly increased.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates to the PTP protocol, and in particular, to encryption in the PTP protocol. 
       DESCRIPTION OF THE RELATED ART 
       [0002]    In a distributed system, clock synchronization is an essential technology for many applications. One of the most representative clock synchronization protocols is IEEE 1588 protocol, also referred as PTP protocol (Precision Timing Protocol). A major principle of the PTP protocol is to periodically perform correction synchronization to the clocks of all nodes in a network through a synchronization signal, such that the distributed system may arrive at a precise synchronization. Although the master-slave clock model-based PTP protocol has advantages of simplicity and ease for implementation, more and more studies show that the PTP protocol is vulnerary to malicious attacks or failure. As a typical example, the PTP protocol cannot deal with a malicious master clock, for example, Byzantine or Babbling idiot, that tampers time. 
         [0003]    The PTP protocol provides an experimental security extension in Annex K, i.e., offering a “native” security support for clock synchronization in open environments where attackers can get direct access. It uses symmetric message authentication code functions to provide group source authentication, message integrity, and replay protection. The participants in the protocol share symmetric keys that can be shared within a whole domain or within subsets of the domain. Currently, the distribution of symmetric keys are manually configured, thus the flexibility is rather poor. The number of keys that need to be configured in each network node is directly proportional to the number of nodes in the domain and the send/receive relationship among these nodes. It is not so easy for a network administrator to configure refresh such huge number of keys. With the current solution, static keys are stored in each network node, which has a drawback of poor confidentiality. From the perspective of security, dynamic keys are better than static keys. 
         [0004]    The security extension in Annex K of the PTP protocol does not support tracking. The Annex K uses symmetric message authentication code functions, i.e., any arbitrary node knows the encryption key of its communication peer, such that a malicious node can send out a PTP message in the name of the peer node without being tracked. It would be even worse if the malicious node sends a multicast or broadcast PTP message. 
         [0005]    The key distribution may be either manually configured or done through an automatic key management protocol. The Annex K in the PTP protocol supports manual configuration of keys and automatic generation of keys based on a configuration password in accordance with the specification of Annex K. Native security support provides possibility for other future message authentication. 
         [0006]    Additionally, the Annex K in the PTP protocol merely supports the fixed challenge-response authentication method, not supporting other authentication method. Thus, its flexibility is rather poor. 
       SUMMARY OF THE INVENTION 
       [0007]    In the PTP protocol, the key distribution may be either manually configured or done through an automatic key management protocol. The Annex K in the PTP protocol supports manual configuration of keys and automatic generation of keys based on a configuration password. The present invention provides a technical solution of automatically distributing PTP keys, and on that basis, provides a new encryption method. 
         [0008]    According to an embodiment of the present invention, there is provided a method for use in a domain control device of a communication network for distributing a key for the PTP protocol to a network node within a domain, comprising steps of: verifying whether the network node is an eligible node in the domain; sending a key for the PTP protocol to the network node if the network node is an eligible node in the domain. 
         [0009]    According to another embodiment of the present invention, there is provided a method for use in a network node of a communication network for encrypting the PTP protocol data packet, comprising steps of: receiving a key for the PTP protocol from a domain control device within a domain to which the network node belongs; performing encrypted communication following the PTP protocol with another network node in the domain with the key. 
         [0010]    According to a further embodiment of the present invention, there is provided an apparatus for use in a domain control device of a communication network for distributing the PTP protocol key to a network node within a domain, comprising: first verifying means configured to verify whether the network node is an eligible node in the domain; first sending means configured to send a key for the PTP protocol to the network node if the network node is an eligible node in the domain. 
         [0011]    According to yet another embodiment of the present invention, there is provided an apparatus for use in a network node of a communication network for encrypting the PTP protocol data packet, comprising: first receiving means configured to receive a key for the PTP protocol from a domain control device in a domain to which the network node belongs; encrypted communication means configured to perform encrypted communication following the PTP protocol with other network node in the domain utilizing the key. 
         [0012]    The methods and apparatuses according to the present invention enable access authentication of various forms of PTP network nodes, and automatic configuration and dynamic sending of PTP keys, such that the security of the keys are greatly enhanced. Additionally, by adopting a SignCryption encryption algorithm, it is enabled that for each PTP message, not only message source authentication, message integrity authentication, message confidentiality, and replay protection can be provided, but also its sending network node can be tracked. Thus, the security is significantly enhanced. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0013]    Through the following detailed depiction on the non-limiting embodiments with reference to the accompanying drawings, the other features, objectives, and advantages of the present invention will become more apparent. 
           [0014]      FIG. 1  is a diagram of an application scenario according to an embodiment of the present invention; 
           [0015]      FIG. 2  is a flow chart of a method of distributing a key for the PTP protocol to a network node within a domain in a domain control device of a communication network according to an embodiment of the present invention; 
           [0016]      FIG. 3  is a flow chart of a sub-step of step S 201  in  FIG. 2  according to an embodiment of the present invention; 
           [0017]      FIG. 4  is a flow chart of a method based on RADIUS authentication; 
           [0018]      FIG. 5  is a diagram of protocol architecture of EAP running on the PTP; 
           [0019]      FIG. 6  is a diagram of a format of an EAP message for authenticating network node  21  by employing an EAP authentication method; 
           [0020]      FIG. 7  is a diagram of a format of an EAP message for authenticating network node  21  by employing a new EAP authentication method; 
           [0021]      FIG. 8  is a flow chart of a method of encrypting the PTP protocol data packet within a network node of a communication network according to an embodiment of the present invention; 
           [0022]      FIG. 9  is a structural diagram of an apparatus  900  for distributing a key for the PTP protocol to a network node within a domain in a domain control device of a communication network according to an embodiment of the present invention; and 
           [0023]      FIG. 10  is a structural diagram of an apparatus  100  of encrypting the PTP protocol data packet within a network node of a communication network according to an embodiment of the present invention. 
       
    
    
       [0024]    Throughout the figures, same or similar reference numerals indicate same or corresponding step features or means (modules). 
       DETAILED DESCRIPTION OF THE INVENTION 
       [0025]    Hereinafter, the embodiments of the present invention will be described in detail with reference to the accompanying drawings. 
         [0026]      FIG. 1  is a diagram of an application scenario according to an embodiment of the present invention.  FIG. 1  illustrates a domain  10  and a plurality of network nodes  21 ,  22 ,  23 , etc., in the domain. There is a domain control device serving as an automatic distribution device for the PTP protocol key. A domain is generally an application scope in a network. An entity within this scope has an allowed access rights, while an entity beyond this scope will be subjected to the control of domain rights and cannot access. Domain is a relatively strict management mode. Usually, domain and domain control device are employed to perform central management and security control, which is very essential to network security. 
         [0027]      FIG. 2  is a flow chart of a method of distributing a key for the PTP protocol to a network node within a domain in a domain control device of a communication network according to an embodiment of the present invention.  FIG. 3  is a flow chart of a sub-step of step S 201  in  FIG. 2  according to an embodiment of the present invention. 
         [0028]    Hereinafter, a process of distributing the PTP protocol key for a domain control device in  FIG. 1  will be described in detail. 
         [0029]    With reference to  FIG. 2 , initially at step S 201 , a domain control device  11  verifies whether a network node  21  is an eligible node in the domain. 
         [0030]    If the network node  21  is the eligible node in the domain, then at step S 202 , a key for the PTP protocol is sent to the network node  21 . 
         [0031]    Specifically, there are numbers of manners for the domain control device to verify whether the network node  21  is an eligible node in the domain. One embodiment is shown in  FIG. 3 . 
         [0032]    Initially, at step S 301 , the domain control device  11  sends to the network node  21  a request message for querying an identity. 
         [0033]    Next, at step S 302 , the domain control device  11  receives from the network node  21  a response message for querying the identity, the response message comprising identity information of the network node  21 . 
         [0034]    At step S 303 , the domain control device  11  verifies whether the identity of the network node  21  is eligible. 
         [0035]    At step  304 , if the identity of the network node  21  is eligible, then a request message for querying authentication information is sent to the network node  21 . 
         [0036]    At step S 305 , the domain control device  11  receives from the network node  21  a response message for querying the authentication information. 
         [0037]    At step S 306 , the domain control device  11  verifies whether the authentication information of the network node  21  is eligible. 
         [0038]    If the authentication information of the network node  21  is eligible, then at step S 307 , the domain control device  11  sends the key for the PTP protocol to the network node  21 . 
         [0039]    There are numbers of manners for the domain control device  11  to verify whether the identity of the network node  21  is eligible and to verify whether the authentication information of the network node  21  is eligible. For example, RADIUS-based authentication (RFC2869) or DIAMETER-based authentication (RFC3588) may be used.  FIG. 4  is a flow chart of a method of RADIUS-based authentication, wherein steps S 301 , S 302 , S 304 , S 305 , and S 307  are the same as above mentioned, which will not be detailed here. After step S 302 , the domain control device  11  performs step S 401  to send a first access query request message to a remote server  31 , wherein the first access query request message comprises identity information of the network node  21 . After receiving the first access query request message, the remote server  31  queries stored identity information of the network node, to determine whether the identify information of the network node exists; if so, then it is deemed that the identity of the network node  21  is eligible; then, at step S 402 , an access challenge request message is sent to the domain control device  21 , the access challenge request message being used for requesting for the authentication information of the network node  21 . 
         [0040]    After receiving the access challenge request message, the domain control device  11  performs steps S 304  and S 305 , and then at step S 403 , a second access query request message is sent to the remote server  31 , the second access query request message comprising authentication information of the network node  21 . The remote server  31  verifies whether the authentication information from the network node  21  is eligible; if so, then at step S 404 , an access reception response message is sent to the domain control device  11 . Hereafter, the domain control device  11  performs step S 307 . 
         [0041]    An example of access challenge request and authentication information is Challenge (RN), wherein RN is a random number; Response=H(RN∥Key) where Key denotes the pre-configured key for the network node  21 , and H may be the hash function specified by the authentication protocol, for example, MD5. The remote server  31  receives the authentication information Response, and compares it with the H(RN∥Key) value calculated by itself. If consistent, then the authentication information is eligible. It should be noted that the access challenge request and the authentication information are not limited thereto, and any arbitrary other forms of authentication mechanisms are allowed, for example, One Time Password (OTP), Transport Layer Security (TLS), etc. 
         [0042]    Of course, if the domain control device  1  pre-stores the identity information and authentication information of the network node  21 , then it is unnecessary to perform RADIUS authentication or other authentication as illustrated in  FIG. 4 . 
         [0043]    The processes of the domain control device  11  to authenticate the network node  21  and send a key for the PTP protocol have been described in detail in terms of function. Specifically, in one embodiment, the domain control device  11  may verify whether the network node  21  is an eligible node in the domain  10  by means of EAP authentication. It will be described in detail in the following. 
         [0044]    EAP is a well known and commonly used security authentication protocol defined in RFC3748. It may run on various kinds of lower transport protocols. Because the present invention is directed to the PTP protocol, it is preferable to use the EAP that runs on the PTP. Of course, the present invention is not limited thereto. Using the EAP running on another protocol may also realize the authentication whether the network node  21  is an eligible node in domain  10 . For example, the EAP runs on the UDP or the EAP runs on the Ethernet may be used. 
         [0045]      FIG. 5  is a diagram of the protocol architecture of EAP running on the PIP.  FIG. 6  is a diagram of a format of an EAP message for authenticating network node  21  by means of an EAP authentication process. In  FIG. 6 , an existing EAP authentication process is shown to be used. According to the definition of RFC3748, when “Code” is 1, it is an EAP Request message; when “Code” is 2, it is an EAP Response message. “Identifier” is a one-bit-length integer for matching the EAP Request message and the EAP Response message. A new EAP Request message must modify the value of this field. “Length” indicates the length of the whole EAP message. “Type” is a type of EAP Request or EAP Response. The content of Type-data is determined by the type. For example, when the “Type” value=1, it represents “Identity” for querying the identity of the network node  21 ; when “Type” value=4, it represents “MD5-Challenge”, which is similar to a PPP CHAP protocol and comprises an interrogation message for querying the authentication information of the network node  21 . In other words, with reference to  FIG. 3 , at step S 301 , “Code” value is 1, and “Type” value is 1. At step S 302 , “Code” value is 2, “Type” value is 1, and “Type-Data” is the identity information of the network node  21 . Since steps S 304  and S 305  are described with EAP MD5 Challenge authentication manner as an example, “Type” value is 4; at step S 304 , “Code” value is 1; at step S 305 , “Code” value is 2, and “Type-Data” is authentication information of the network node  21 . Delivery of the key for the PTP protocol in step S 307  may be performed by extending the EAP protocol to define a new “Code” and/or a new “Type” and to define a new field in the “Type-Data”, or by extending an existing message of the EAP protocol to define a new “Type” and to define a new field in the “Type-Data”. Still taking the EAP MD5-Challenge authentication manner as an example to extend a SUCCESS message, a newly defined “Type-Data” is added in the SUCCESS message to transmit the key for the PTP protocol. In this case, the “Code” value is 3, and the type of “Type” may be a new type of extended definition. This type indicates a key field of the PTP protocol in “Type-Data”, for transmitting the key for the PIP protocol. 
         [0046]      FIG. 6  illustrates a scenario of authenticating the network node  21  by means of an existing EAP authentication process.  FIG. 7  illustrates a message format of defining a new EAP authentication according to an embodiment of the present invention. Transmission of the authentication message in steps S 301 , S 302 , S 304 , and S 305  and the key for PTP protocol in step S 307  are performed utilizing an extended EAP message with “Type” being 254, where the message format is shown in  FIG. 7 . The message content is transmitted in the “Vendor Data” field, and the key for the PIP protocol may be transmitted by adding one or more fields in the “Vendor Data”. 
         [0047]    At step S 301 , “Code” value is 1, “Type” value is 254, and “Vendor-ID” may extend the definition, for example, reserving a particular type value for the IEEE1588 PIP, and distributing a particular “Vendor-ID” for each supported authentication protocol. At step S 302 , “Code” value is 2, “Type” value is 254, and “Vendor-Data” is the identity information of the network node  21 . At step S 304 , “Code” value is 1, “Type” value is 254. At step S 305 , “Code” value is 2, “Type” value is 2544, and “Vendor-Data” is the authentication information of the network node  21 . The transmission of the key for the PTP protocol at step S 307  may be performed by defining a new field in the “Vendor-Data”. In this case, “Code” value is 2, “Type” value is 254, and in the “Vendor-Data”, the key field of the PTP protocol is added in addition to the field defined by the original authentication protocol, as illustrated in  FIG. 6 . 
         [0048]    It should be noted that the transmission of the key for the PTP protocol in step S 202  may be performed in plain text or in encryption. The encryption may be done through the key that has been agreed upon during the authentication stage at step S 201 . For example, in  FIG. 6  or  FIG. 7 , the network node  21  is authenticated at the domain control device  11  through a TLS protocol. A data encryption key for the TLS may be agreed upon while the authentication is completed. Thus, the data encryption key may be employed to perform encrypting transmission to the key for the PTP protocol. 
         [0049]    Based on different encryption manners as employed, there may be multiple forms of keys for the PTP protocol, for example, Hash function encryption manner (IEEE 1588-2008) defined in Annex K of the PTP protocol, and then the keys for the PTP protocol comprise shared symmetrical keys defined in the Annex K of the PIP protocol. For example, encryption and digital signature may be performed by adopting the identity-based SignCryption algorithm (Identity-Based Signcryption, John Malone-Lee, Cryptology ePrint Archive, Report 2002/098, 2002. http://eprint.iacr.org/), then the keys for the PIP protocol comprise parameters and private keys defined in the SignCryption algorithm. Hereinafter, the two algorithms will be described in detail. 
         [0050]      FIG. 8  is a flow chart of a method of encrypting the PTP protocol data packet within a network node of a communication network according to an embodiment of the present invention. Hereinafter, with reference to the application scenario as illustrated in  FIG. 1 , a method of encrypting the PTP protocol data packet in network node  21  will be described in detail. 
         [0051]    Initially, at step S 801 , the network node  21  receives a key for the PTP protocol from a domain control device  11  in a domain to which the present network node belongs. 
         [0052]    Next, at step S 802 , the network node  21  performs encrypted communication following the PTP protocol with another network node in the domain  10  with the key received at step S 801 . 
         [0053]    As stated above, in one embodiment, the key for the PTP protocol comprises parameters defined in the SignCryption algorithm and a first key, wherein the first key is generated by the domain control device based on the identity information of the network node  21 . Specifically, step S 802  comprises the following sub-steps: when sending a unicast PTP data packet, generating a digital signature for the unicast PTP data packet based on the first key and the identity information of the receiving node; and encrypting the text body of the unicast PTP data packet; and performing encryption and digital signature authentication for the received unicast PIP data packet based on the first key and the identity information of the sending node. 
         [0054]    Hereinafter, with reference to Identity-Based SignCryption by John, it will be described briefly how to generate a digital signature, encryption, decryption, and digital signature authentication in a unicast scenario. Without loss of generality, detailed description will be made with an example of communication between network node  21  and network node  22 . Let the identity information of the network node  21  be ID a , and the identity information of the network node  22  be ID b . 
         [0055]    P, ê, H 1 , H 2 , H 3 , and Q TA  are system confutation parameters defined for the SignCryption algorithm. They are specifically defined as follows: (G, +) and (V, •) are cyclic groups having a prime order of q. P is a generating element of the cyclic group G. In view of the protocol implementation performance requirements and the protocol datagram overhead, it is recommended to use a cyclic group that is generated by an elliptic curve. ê: GXG→V is a bilinear transformation that satisfies the requirements of identity-based SignCryption algorithm. H 1 , H 2 , and H 3  are pre-defined hash functions, wherein H 1 : {0,1}-→G*, H 2 :{0,1}*→Z* q , H 3 : Z* q →{0,1} n , where n denotes the length of the message processed by the SignCryption algorithm, and G*=G\{0}. 
         [0056]    In the following depiction, the symbol ∥ denotes bit string connection, ⊕ denotes that the bit string is XOR by bit, + denotes an add operation defined on the selected cyclic group, and t         Z* q  denotes randomly selecting a value from Z* q  and imparting the value to t. 
         [0057]    Upon the initialization of the system, the domain control device first selects system parameters P, e, H 1 , H 2 , and H 3  of the identity-based SignCryption algorithm. Then, t         Z* q  is randomly selected and Q TA  is calculated as tP, till the system configuration parameters of the SignCryption algorithm of the whole domain are completely determined. The domain control device may disclose P, ê, H 1 , H 2 , H 3 , and Q TA , namely notifying respective network nodes in the domain  10  of these parameters. As a random number only known by the domain control device  11 , t is the master key of the whole domain. 
         [0058]    For the network node  21 , when it is added into the domain  10 , it needs to be registered with the domain control device  11 . The domain control device  11  verifies the network node  21 . Only if the network node  21  is successfully authenticated, the domain control device  11  allows the network node  21  to be added into the domain  10 . The domain control device  11  obtains the identity ID of the network node  21  during the authentication process. After the network node  21  is successfully authenticated, a private key S ID =tQ ID  is calculated for the network node  21  based on its ID, wherein Q ID =H 1 (ID). The private key is distributed to the network node  21  with the system configuration parameters P, ê, H 1 , H 2 , H 3 , and Q TA . In order to guarantee security, these parameters may be encrypted and protected as required during the distribution process. After the network node  21  completes registration and obtains the system configuration parameters of the SignCryption as well as its private key, it may communicate securely with other nodes in the domain by utilizing the SignCryption algorithm. 
         [0059]    When sending a message, the network node  21  processes the message in accordance with the following provisions: 
         [0060]    Signcrypt(S Ida , ID b , m) 
         [0061]    Q IDb =H 1 (ID b ) 
         [0062]    x         Z* q    
         [0063]    U=xP 
         [0064]    r=H 2 (U∥m) 
         [0065]    W=xQ TA    
         [0066]    V=rS IDa +W 
         [0067]    y=ê(W, Q IDb ) 
         [0068]    k=H 3 (y) 
         [0069]    c=k⊕m 
         [0070]    σ=(c, U, V) 
         [0000]    wherein m is the PTP protocol message to be sent by the network node  21  to the network node  22 , c is the encrypted message, U and V are digital signatures generated based on m, and σ is the PTP protocol message encrypted and attached with a digital signature. 
         [0071]    After receiving the message with encrypted signature, the network node  22  performs decryption and digital signature authentication for the received unicast PTP data packet based on its private key and the identity information of the sending node (i.e., network node  21 ) with the following process: 
         [0072]    Unsigncrypt(IDa, S IDb , σ) 
         [0073]    Q IDa =H 1 (ID a ) 
         [0074]    Parse σ as (c, U V) 
         [0075]    y=ê(S IDb , U) 
         [0076]    k=y 
         [0077]    m=k⊕c 
         [0078]    r=H 2 (U∥m) 
         [0079]    If ê(V,P)≠ê(Q IDa , Q TA ) r ·ê(U, Q TA ) 
         [0080]    Return ⊥ (indicating that the message is invalid and should be discarded) 
         [0081]    Return m 
         [0082]    If ê(V, P) is not equal to ê(Q IDa , Q TA ) r ·ê(U, Q TA ), then the network node  22  determines that this signature is not correct, and then discards or neglects the message m. 
         [0083]    Of course, the process of how the network node  21  performs decryption and digital signature verification on the received unicast message is similar to the above mentioned. 
         [0084]    For transmission and reception of multicast or broadcast data packets, the domain control device  11  defines identity information for each multicast (or broadcast), generates a second private key based on the identity, and sends the second private key to the network node that requests for receiving the multicast (or broadcast) data packet, for example, network node  21 . When sending a multicast or broadcast PTP data packet, the network node  21  generates a digital signature to the multicast or broadcast PTP data packet based on its own first private key, identity information of its multicast group or broadcast group, and encrypts the text body of the multicast or broadcast PTP data packet; and performs decryption and digital signature authentication for the received multicast or broadcast PTP data packet based on the second private key of the multicast (or broadcast) group and the identity information of the sending node. 
         [0085]    As mentioned above, in one embodiment, a key for the PTP protocol comprises shared symmetrical keys defined by Annex K of the PIP protocol. Specifically, the number of shared symmetrical keys depends on the number of network nodes with which the network node  21  needs to communicate. Specifically, step S 802  comprises the following sub-steps: the network node  21  performs security protection for the PTP data packet utilizing the encryption key according to Annex K of the PTP protocol; and performs security verification for the PIP data packet utilizing the encryption key according to the Annex K of the PTP protocol. 
         [0086]    Hereinafter, it will be described in detail, with reference to the Annex K of the PTP protocol, how the network node  21  performs security protection and verification for the transmitted and received data packets with the shared symmetrical keys. 
         [0087]    When the PTP protocol supports the Annex K, all PTP messages must carry the field AUTHENTICATION TLV, and sets the security flag for the flag filed (flagField.Secure). The “Integrity Check Value” field in the AUTHENTICATION TLV is for guaranteeing the integrity of the whole message. The ICV is the obtained by applying the message authentication code function (for example, HMAC-SHA1-96 or HMAC-SHA256-128 functions defined in the Annex K of the PTP protocol) identified by the algorithm ID in the AUTHENTICATION TLV and the key identified by key ID to the whole PIP message. 
         [0088]    Without loss of generality, taking the communication between the network node  21  and the network node  22  as an example, their shared symmetrical key is K, and m is the PTP protocol data packet to be transmitted by the network node  21  to the network node  22 . The network node  21  fills in relevant fields in the AUTHENTICATION TLV as required, for example, algorithm ID, key ID, etc., wherein ICV value is zero, and the initial AUTHENTICATION TLV is attached to the message m. The network node  21  calculates the integrity check value field=H (attached with the PTP message of the initial AUTHENTICATION TLV, K) based on the algorithm ID in the AUTHENTICATION TLV, key ID, and the PTP message attached with the initial AUTHENTICATION TLV, wherein H is the HMAC-SHA1-96 or HMAC-SHA256-128 function defined in Annex K of the PTP protocol. The network node  21  uses this result to modify the ICV field in the initial AUTHENTICATION TLV and sends the message with the ICV-modified AUTHENTICATION TLV field to the network node  22 . After receiving the message in carrying the AUTHENTICATION TLV, the network node  22  calculates, using the same method as above mentioned, the algorithm ID in the AUTHENTICATION TLV, the key ID, and the received in, and compares it with the ICV value carried in the AUTHENTICATION TLV in the received message; if they are not consistent, then discards or neglects the message m. The network node  21  also performs such check to the PTP protocol message received from the network node  22 . 
         [0089]      FIG. 9  is a structural diagram of an apparatus  900  for distributing a key for the PTP protocol to a network node within a domain in a domain control device of a communication network according to an embodiment of the present invention, wherein the apparatus  900  comprises first verifying means  901  and first sending means  902 . In one embodiment, the first verifying means  901  comprises second sending means  9011 , second receiving means  9012 , second verifying means  9013 , third sending means  9014 , third receiving means  9015 , and third verifying means  9016 . 
         [0090]    Hereinafter, detailed description will be made with respect to the working procedure of the apparatus  900  in the domain control device  11 . 
         [0091]    Initially, the first verifying means  901  verifies whether the network node  21  is an eligible node in the domain. 
         [0092]    If the network node is an eligible node in the domain, then the first sending means  902  sends to the network node a key for the PTP protocol. 
         [0093]    Specifically, there are numbers of manners for the first verifying means  901  to verify whether the network node  21  is an eligible node in the domain. One embodiment will be illustrated below. 
         [0094]    Initially, the second sending means  9011  sends to the network node  21  a request message for querying an identity. 
         [0095]    Next, the second receiving means  9012  receives a response message for querying the identity from the network node  21 , the response message comprising identity information of the network node  21 . 
         [0096]    The second verifying means  9013  verifies whether the identity of the network node  21  is eligible. 
         [0097]    If the identity of the network node  21  is eligible, then the third sending means  9014  sends to the network node  21  a request message for querying authentication information. 
         [0098]    The third receiving means  9015  receives a response message for querying the authentication information from the network node  21 . 
         [0099]    The third verifying means  9016  verifies whether the authentication information of the network node  21  is eligible. 
         [0100]    If the authentication information of the network node  21  is eligible, then the first sending means  902  sends the key for the PTP protocol to the network node  21 . 
         [0101]    There are a plurality of manners for the second verifying means  9013  to verify whether the identity of the network node  21  is eligible and for the third verifying means  9016  to verify whether the authentication information of the network node  21  is eligible, for example, RADIUS-based authentication (RFC2869) or DIAMETER-based authentication (RFC3588). 
         [0102]    In one embodiment, the first verifying means  901  may verify whether the network node  21  is an eligible node in the domain  10  by means of EAP authentication. The first sending means  902  implements sending the key for the PTP protocol through extending the definition “Type-Data” in the message that is defined in the EAP authentication process. In another embodiment, the first sending means  902  implements sending the key for the PTP protocol by defining “Expanded Type” in the EAP message to thereby define a new EAP authentication manner The key for the PTP protocol may be sent in a form of encrypted text or in a form of plain text. In one embodiment, the key for the PTP protocol comprises shared symmetrical keys defined in Annex K of the PTP protocol. In another embodiment, the key for the PTP protocol comprises parameters and private keys that are defined in the SignCryption algorithm. 
         [0103]      FIG. 10  is a structural block diagram of an apparatus  100  for encrypting PTP protocol data packets in a network node of a communication network according to one embodiment of the present invention. Hereinafter, the process of encrypting the PTP protocol data packets for the apparatus  100  in the network node  21  will be described in detail. 
         [0104]    Initially, the first receiving means  101  receives a key for the PTP protocol from a domain control device  11  in a domain to which the present network node belongs. 
         [0105]    Next, the encrypted communication means  102  performs the encrypted communication following the PTP protocol with another network node in the domain utilizing the key. 
         [0106]    As stated above, in one embodiment, the key for the PTP protocol comprises parameters defined in the SignCryption algorithm and a first key, wherein the first key is generated by the domain control device  10  based on the identity information of the network node  21 . Specifically, the encrypted communication means  102  performs the following functions: when sending a unicast PTP data packet, generating a digital signature to the unicast PTP data packet based on the first key and the identity information of the receiving node, and encrypting the text body of the unicast PIP data packet; and performing encryption and digital signature authentication for the received unicast PTP data packet based on the first key and the identity information of the sending node. 
         [0107]    For transmission and reception of multicast or broadcast data packets, the domain control device  11  defines identity information for each multicast (or broadcast), generates a second private key based on the identity, and sends the second private key to the network node that requests for receiving the multicast (or broadcast) data packet, for example, network node  21 . When the network node  21  sends a multicast or broadcast PTP data packet, the encrypted communication means  102  generates a digital signature to the multicast or broadcast PIP data packet based on its own first private key, identity information of its multicast group or broadcast group, and encrypts the text body of the multicast or broadcast PTP data packet; and performs decryption and digital signature authentication for the received multicast or broadcast PTP data packet based on the second private key of the multicast (or broadcast) group and the identity information of the sending node. 
         [0108]    As stated above, in one embodiment, the key for the PTP protocol comprises shared symmetrical keys defined in Annex K of the PTP protocol. Specifically, the number of shared symmetrical keys depends on the number of network nodes with which the network node  21  needs to communicate. Specifically, the encrypted communication means  102  performs the following functions: the network node  21  performs security protection for the PTP data packet utilizing the encryption key according to Annex K of the PTP protocol; and performs security verification for the PTP data packet utilizing the encryption key according to the Annex K of the PTP protocol. 
         [0109]    Any arbitrary technical solution that does not deviate from the spirit of the present invention should fall into the protection scope of the present invention. Additionally, any reference numerals in the claims should not be regarded as limiting the claims; the term “comprise” does not exclude other means or steps that are not specified in the claims or description; “a” before a means does not exclude existence of more like means; in an apparatus that comprise a plurality of means, one or more functions of the plurality of means may be implemented by a same hardware or software module; phrases such as “first,” “second,” and “third” merely denote the names, without indicating any particular sequence. 
         [0110]    The specific embodiments of the present invention have been described above. It should be noted that the present invention is not limited to the above particular embodiment. Those skilled in the art may make various alterations or amendments within the scope of appended claims.