Abstract:
The invention relates to information security technologies, provides a content security transmission device and a content security transmission system which separate data transmission function of a digital interface from data management and processing function thereof, and provides a content security transmission method based on the device and the system. The content security transmission protection device comprises digital interfaces and a management/processing unit, the management/processing unit is configured in a specific chip in the device, used for updating a revocation list stored therein and collecting information from downstream devices. A transmitting device and a forwarding device in the content security transmission protection system comprise digital interfaces and management/processing units. The invention employs software in the specific chip CPU to implement data management and processing function without increasing cost, thus being capable of increasing any functions, improving flexibility and expansibility of the system, and greatly reducing size and cost of digital interface chips, namely reducing the development difficulty. The digital interfaces only implement simple data transmission function at fast processing speed.

Description:
FIELD OF THE INVENTION 
       [0001]    The invention relates to information security technology, in particular to technologies for content security transmission between devices via high speed digital interfaces. 
       DESCRIPTION OF THE RELATED ART 
       [0002]    A content security transmission protection system between terminals comprises a transmitting device, a forwarding device and a receiving device. Each device in the system generally has a digital interface (input interface or output interface) and a presentation/use unit module. The transmitting device refers to a device with network device management function and digital contents transmitted; the receiving device refers to a device capable of receiving and decrypting the digital contents via one or more digital interfaces; and the forwarding device has input and output functions, receives digital contents via one or more digital interfaces, and transmits the digital contents via one or more transmitting interfaces. Audio data, video data, etc. to be protected are transmitted between devices via the digital interfaces. With regard to a bilateral network, the digital interface has input function and output function. With regard to the digital interfaces of the transmitting device and the forwarding device, they need manage output network, functions, sizes, etc. of devices, control the behaviors of downstream output devices or behaviors of terminals in the network, and are responsible for implementation of some protocols and algorithms and data encryption/decryption processing. A same device can have various input interfaces and output interfaces. The presentation/use unit module is a possible use part of the digital contents, and mainly for user operations. 
         [0003]    At present, two international standards HDCP and DTCP are mainly for protection of digital interface contents. The HDCP standard includes interfaces authentication, data encryption, information collection part and revocation list update etc. A public key of the HDCP is referred to as a KSV, and a private key is referred to as a Key. The KSV is a 40 bit digit including 20 0s and 20 1s. Suppose device A and device B are to be authenticated, the principle of authentication between HDCP interfaces is that the following equation is true: 
         [0000]    
       
         
           
             
               
                 ∑ 
                 
                   
                     A 
                     KSV 
                   
                   ≠ 
                   0 
                 
               
                
               
                   
               
                
               
                 B 
                 Keys 
               
             
             = 
             
               
                 ∑ 
                 
                   
                     B 
                     KSV 
                   
                   ≠ 
                   0 
                 
               
                
               
                   
               
                
               
                 A 
                 Keys 
               
             
           
         
       
     
         [0004]    The authentication method has the advantage of simple algorithm and disadvantage of small cracking operation amount. A variety of attacks on the authentication algorithm have emerged in the network. The algorithm proposed by the solution greatly improves the cracking operation volume. Stream ciphers are employed for data encryption of HDCP, and the method has the advantage of strong data processing capacity, and is especially suitable for encryption of data without high security requirements and encryption of high throughput data. 
         [0005]    In terms of revocation list update, the HDCP employs RSA signatures. As the revocation list update is carried out in a digital interface, the RSA is implemented in a digital interface chip according to standard regulations, resulting in increased development difficulty and size of the chip. 
         [0006]    The information collection part of the HDCP is to collect link count and link depth, and collect ID and public keys linking all downstream devices to the transmitting device. The protocol is complex, the volume of data to be transmitted is larger, the collection is time-consuming, occupies data bandwidth and affects performance when the size of a linking network is relatively large. 
         [0007]    The DTCP is another digital interface content protection standard widely used in current data transmission. The DTCP mainly includes interface authentication, key exchange, data encryption, copy information control, revocation list update, etc. The interface authentication of the DTCP employs a general ECC-based authentication algorithm, and has the advantage of high security and disadvantages of complex development and large size of chips. Algorithms of the HDCP are also compatible in DTCP. In terms of the copy control information (CCI), the DTCP can only process the CCI stipulated specific to MPEG with a maximum of 6 authorities. 
         [0008]    The interface authentication, the key exchange and the data encryption belong to data transmission function, and the revocation list update, the information collection, the copy control information, etc. belong to data management and processing function. The data management and processing function is carried out in digital interfaces, as the algorithm is very complex, resulting in increased development difficulty and size of chips, thus the cost of interface chips is very high. Meanwhile, the management function may need regular expansion, if chips are employed for the expansion, the management function can not be updated in case that production, thus the management function is inflexible. As the digital interfaces have to implement such two major functions as the data transmission function and the data management and processing function, requirements for performance and size of the digital interface chips are relatively high. For example, approximate 50 k logic gate may be consumed if the revocation list signature is implemented in the chips in an ECC way, which is more than the sum of all other functions of the digital interfaces. 
       SUMMARY OF THE INVENTION 
       [0009]    A technical problem to be solved by the invention is to provide a content security transmission device and a content security transmission system which separate data transmission function of a digital interface from data management and processing function thereof, and provides a content security transmission method based on the device and the system. 
         [0010]    A technical solution for solving the technical problem in the invention is a content security transmission protection device which comprises digital interfaces and a management/processing unit, and the management/processing unit is configured in a specific chip in the device; 
         [0011]    the digital interface is used for performing an authentication between the management/processing unit and the digital interface at the request of the management/processing unit in the device; performing an authentication between the digital interface and a digital interface of another device; and performing key activation between two devices to obtain an encryption key, and using the encryption key as an initial key to encrypt contents of data and transmit the data; and 
         [0012]    the management/processing unit is used for initiating an authentication between the management/processing unit and the digital interface in the device; performing an authentication between the management/processing unit and a management/processing unit of another device; and updating a revocation list stored therein, and collecting information from downstream devices. 
         [0013]    The specific chip in the device can be a master device chip or other separate specific chips except digital interface chips in the device. Software is employed in the specific chip CPU to implement data management and processing function, that is, the part with complex algorithm and the part needing regular update are separated, and a separate logic module is employed. Software is employed in the CPU to implement data management and processing function without increasing cost, thus being capable of increasing any function, improving flexibility and expansibility of the system, and greatly reducing size and cost of the digital interface chips, namely reducing the development difficulty. The digital interfaces only implement simple data transmission function at a fast processing speed without consuming resources for other complex operations, thus reducing development difficulty and development cost of the digital interfaces, and improving the processing performance thereof. 
         [0014]    The content security transmission protection system comprises transmitting devices, forwarding devices and receiving devices, the transmitting device comprises digital interfaces and a management/processing unit, the forwarding device comprises digital interfaces and a management/processing unit, and the receiving device comprises digital interfaces and a presentation/use unit; 
         [0015]    the digital interface is used for performing an authentication between the management/processing unit and the digital interface at the request of the management/processing unit in the device; performing an authentication between the digital interface and a digital interface of another device; and performing key activation between two devices to obtain an encryption key, and using the encryption key as an initial key to encrypt contents of data and transmit the data; 
         [0016]    the management/processing unit is used for initiating an authentication between the management/processing unit and the digital interface in the device; performing an authentication between the management/processing unit and a management/processing unit of another device; and updating a revocation list stored therein, and collecting information from downstream devices; and 
         [0017]    the presentation/use unit is used for possible use of digital contents and accepting user operations. 
         [0018]    Devices supported by the system functionally include three categories, i.e. transmitting devices, forwarding devices and receiving devices. The transmitting devices refer to devices with network device management function and digital contents transmitted, and generally include digital interfaces (input interfaces and output interfaces), management/processing units and some other modules (e.g. presentation/use unit); the receiving devices refer to devices capable of receiving and decrypting encrypted digital contents via one or more input interfaces, and include input interfaces or inactivated output interfaces, presentation/use units and optionally management/processing units; and the forwarding devices refer to devices having input and output functions, receive digital contents via one or more input interfaces, and then transmit the digital contents via one or more output interfaces, and are required to have management/processing units. That is, the management/processing unit is essential for the transmitting devices and the forwarding devices, and optional for the receiving devices which only have presentation function, such as computer monitors. 
         [0019]    The content security transmission method comprises the following steps: 
         [0020]    a. initiating, by the management/processing unit, of transmitter, an authentication between the management/processing unit of transmitter and the digital interface of transmitter; and initiating, by the management/processing unit, of receiver, an authentication between the management/processing unit of receiver and digital interface of receiver; 
         [0021]    b. performing, an authentication between the digital interface of transmitter and the digital interface of receiver; 
         [0022]    c. performing, an authentication between the management/processing unit of transmitter and the management/processing unit of receiver; 
         [0023]    d. performing key activation between the digital interface of transmitter and the digital interface of receiver to obtain an encryption key; 
         [0024]    e. transmitting, the digital interface of transmitter uses the encryption key as an initial key to encrypt contents of data and transmits the data to the digital interface of receiver; and 
         [0025]    judging, by the management/processing unit of transmitter, whether information collection is completed after the step c and before the step d, and collecting information if the information collection is not completed; judging whether revocation lists stored in the management/processing unit of transmitter and the management/processing unit of receiver are consistent, and updating the revocation list if the revocation lists stored in the management/processing unit of transmitter and the management/processing unit of receiver are not consistent; and proceeding to the step d if the information collection is completed and the revocation lists are consistent. 
         [0026]    The revocation list stores public keys of devices, including public keys held by the digital interfaces of the devices and public keys held by the management/processing units of the devices. The authentications in the steps a, b and c are performed by judging legality of the public keys, that is, the authentication between the digital interface and the management/processing unit in a same device in the step a is implemented by judging the legality of a public key held by the digital interface and a public key held by the management/processing unit; the authentication between the digital interface of transmitter and the digital interface of receiver in the step b is implemented by judging the legality of a public key held by the digital interface of transmitter and a public key held by the digital interface of receiver; and the authentication between the management/processing unit of transmitter and the management/processing unit of receiver in the step c is implemented by judging the legality of a public key held by the management/processing unit of transmitter and a public key held by the management/processing unit, of receiver Types of public key revocation records stored in a revocation list correspond to revocation of an individual public key, revocation of a batch of public keys and revocation of a segmental public keys respectively, in which the revocation of a batch of public keys can be revocation of public keys of a batch or of a manufacturer, and the revocation is implemented by nonzero positions of the public keys. The revocation of a specific individual public key is implemented using the value of the public key. In terms of system-based legality authentication, an ID of a certificate is generally revoked. As contents of a certificate are numerous and the volume of data is large, the volume of data to be transmitted is large. In digital interface applications, two-way transmission capability is generally very weak. For example, HDMI only has an I2C low speed channel, and a two-way AUX channel of DisplayPort has the speed below 1% of the speed of a data channel. In the invention, the volume of data exchanged can be reduced to 10% of the volume implemented by the revocation of the ID of the certificate by directly revoking a public key. 
         [0027]    In the step a, the authentication between the management/processing unit of transmitter and the digital interface of transmitter and the authentication between the management/processing unit of receiver and the digital interface of receiver are automatically performed when the transmitting device or the receiving device is electrified. 
         [0028]    In the step a, the authentication between the management/processing unit of transmitter and the digital interface of transmitter and the authentication between the management/processing unit of receiver and the digital interface of receiver are authentication between the management/processing unit and the digital interface in the same device, and the authentication comprises: 
         [0029]    a1. transmitting, by the digital interface of the device, the public key of the digital interface and a random number of the digital interface to the management/process unit of the same device; 
         [0030]    a2. judging, by the management/processing unit, whether the public key of the digital interface exists in the revocation list stored in the management/processing unit, and the authentication failing if the public key of the digital interface exists in the revocation list stored in the management/processing unit; and transmitting, by the management/processing unit, the public key of the management/processing unit and a random number of the management/processing unit to the digital interface; 
         [0031]    a3. judging, by the digital interface, whether the received public key of the management/processing unit exists in the revocation list stored in the management/processing unit of receiver through the management/processing unit, and the authentication failing if the received public key of the management/processing unit exists in the revocation list stored in the management/processing unit of receiver; generating, by the management/processing unit, a master key of the management/processing unit according to a private key of the management/processing unit, the public key of the digital interface, the random number of the management/processing unit and the random number of the digital interface; and generating, by the digital interface, a master key of the digital interface according to the private key of the digital interface, the public key of the management/processing unit, the random number of the management/processing unit and the random number of the digital interface if the received public key of the management/processing unit does not exist in the revocation list stored in the management/processing unit of receiver; and 
         [0032]    a4. judging whether the master key of the management/processing unit is the same as that of the digital interface, the authentication succeeding if the master key of the management/processing unit is the same as that of the digital interface, and the authentication failing if the master key of the management/processing unit is different from that of the digital interface. 
         [0033]    In the step b, the revocation list of the public key of the digital interface is stored in the management/processing unit, the digital interface applies to the management/processing unit for verifying whether the public key of an object to be authenticated exists in the revocation list, the management/processing unit feeds back the results, and the authentication is not performed directly in the digital interface chip. The revocation list is not stored in the digital interface, which improves the flexibility without any restriction to the size of the revocation list, and the revocation list can be updated at any time. Meanwhile, no storage space is reserved in the chip, thus reducing the cost. 
         [0034]    The authentication in the step b comprises: 
         [0035]    b1. transmitting, by the digital interface of receiver, the public key of the digital interface of receiver and a random number of the digital interface of receiver to the digital interface of transmitter; 
         [0036]    b2. handing, by the digital interface of transmitter, the public key of the digital interface of receiver over to the management/processing unit of transmitter, then judging, by the management/processing unit of transmitter, whether the pubic key of the digital interface of receiver exists in the revocation list stored in the management/processing unit of transmitter, and the authentication failing if the public key of the digital interface of receiver exists in the revocation list stored in the management/processing unit of transmitter; and transmitting, by the digital interface of transmitter, the public key of the digital interface of transmitter and a random number of the digital interface of transmitter to the digital interface of receiver if the public key of the digital interface of receiver does not exist in the revocation list stored in the management/processing unit of transmitter; 
         [0037]    b3. handing, by the digital interface of receiver, the public key of the digital interface of transmitter over to the management/processing unit of receiver, and judging, by the management/processing unit of receiver, whether the public key of the digital interface of transmitter exists in the revocation list stored in the management/processing unit of receiver, and the authentication failing if the public key of the digital interface of transmitter exists in the revocation list stored in the management/processing unit of receiver; and generating, by the digital interface of transmitter, a master key of the digital interface of transmitter according to a private key of the digital interface of transmitter, the public key of the digital interface of receiver, the random number of the digital interface of transmitter and the random number of the digital interface of receiver; and generating, by the digital interface of receiver, a master key of the digital interface of receiver according to a private key of the digital interface of receiver, the public key of the digital interface of transmitter, the random number of the digital interface of transmitter and the random number of the digital interface of receiver if the public key of the digital interface of transmitter does not exist in the revocation list stored in the management/processing unit of receiver; and 
         [0038]    b4. judging whether the master key of the digital interface of transmitter is the same as that of the digital interface of receiver, the authentication succeeding if the master key of the digital interface of transmitter is the same as that of the digital interface of receiver, and the authentication failing if the master key of the digital interface of transmitter is different from that of the digital interface of receiver. 
         [0039]    Data transmission in the authentication between the management/processing unit of transmitter and the management/processing unit of receiver in the step c relies on a communication link established during the authentication between the digital interface of transmitter and the digital interface of receiver in the step b. For example, an HDMI interface can establish an I2C communication link, and a DisplayPort interface can establish a communication link via an auxiliary channel. 
         [0040]    The authentication in the step c comprises: 
         [0041]    c1. transmitting, by the management/processing unit of receiver, the public key of the management/processing unit of receiver and a random number of the management/processing unit of receiver to the management/processing unit of transmitter; 
         [0042]    c2. judging, by the management/processing unit of transmitter, whether the public key of the management/processing unit of receiver exists in the revocation list stored in the management/processing unit of transmitter, the authentication failing if the public key of the management/processing unit of receiver exists in the revocation list stored in the management/processing unit of transmitter; and transmitting, by the management/processing unit of transmitter, the public key of the management/processing unit of transmitter and a random number of the management/processing unit of transmitter to the management/processing unit of receiver if the public key of the management/processing unit of receiver does not exist in the revocation list stored in the management/processing unit of transmitter; 
         [0043]    c3. judging, by the management/processing unit of receiver, whether the public key of management/processing unit of transmitter exists in the revocation list stored in the management/processing unit of receiver, the authentication failing if the public key of the management/processing unit of transmitter exists in the revocation list stored in the management/processing unit of receiver; and generating, by the management/processing unit of transmitter, a master key of the management/processing unit of transmitter according to a private key of the management/processing unit of transmitter, the public key of the management/processing unit of receiver, the random number of the management/processing unit of transmitter and the random number of the management/processing unit of receiver; and generating, by the management/processing unit of receiver, a master key of the management/processing unit of receiver according to the private key transmitted to the management/processing unit of receiver, the public key of the management/processing unit of transmitter, the random number of the management/processing unit of transmitter and the random number of the management/processing unit of receiver if the public key of the management/processing unit of transmitter does not exist in the revocation list stored in the management/processing unit of receiver; and 
         [0044]    c4. Judging whether the master key of the management/processing unit of transmitter is the same as that of the management/processing unit of receiver, the authentication succeeding if the master key of the management/processing unit of transmitter is the same as that of the management/processing unit of receiver, and the authentication failing if the master key of the management/processing unit of transmitter is different from that of the management/processing unit of receiver. 
         [0045]    Compared to the authentication methods of the prior art, such authentication methods can help effectively improve authentication security while reducing the complexity and size of the digital interface chips. 
         [0046]    Information collection is carried out by the management/processing unit instead of the digital interface. Information to be collected includes device capacity, link depth and link hierarchy. At present, the device capacity can not be collected by the HDCP and the DTCP, function lists of all devices can be collected in the invention, enhancing system functions. Meanwhile, the public keys are not uploaded to the transmitter, and controlled by the management/processing unit of each device, thus reducing the volume of data while implementing the same functions. And complex information collection protocol is transferred from the interface chips to the CPU for implementation, reducing development difficulty and size of the interface chips. The device capacity is represented by several bytes, the capacity is represented by a bit, 1 represents that the device has the capacity, and 0 represents that the device does not have the capacity. The information collection is carried out in the following ways: the management/processing unit judges whether a downstream device has a management/processing unit (if the downstream device does not exist, correspondingly downstream management/processing unit also does not exist), if the downstream device does not have a management/process unit, capacity of the device at this level only has presentation function, with the bit of 1. If the downstream device has a management/process unit, the capacity information of devices below this level and the capacity information of the device is subject to an OR operation according to the bit, and the result is used as the capacity information of all devices at and below this level. The capacity of the device is written in during production. Record types in the revocation list are divided into revocation of an individual public key, revocation of public keys of a batch or a manufacturer and revocation of a segmental public key. The revocation of a specific individual public key is implemented using the value of the public key. 
         [0047]    Key activation is implemented by a common digit formed after the authentication in the step b (e.g. the master key of the digital interface (the master key of the transmitting end digital interface is the same as that of the receiving end digital interface)) or operation with the digit. 
         [0048]    Synchronous key check and key update are carried out regularly in the step e, and the data content encryption and the key update are carried out in a parity key manner. Two keys are employed in the parity key manner, one key is updated when the other key is used. The two keys switch according to an appointed period, and the keys are switched while updating. 
         [0049]    The advantages of the invention are as follows: the characteristics of implementation by chip hardware and software are fully used, the unification of low development difficulty, low size and cost, high performance and multifunction is implemented in the content security transmission technology, further, the authentication method of the invention ensures high security during the content security transmission process. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0050]      FIG. 1  is a tree topological structure; 
           [0051]      FIG. 2  is a network or bus topological structure; and 
           [0052]      FIG. 3  is a schematic diagram of content flow of the system in an example. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0053]    I. System Structure 
         [0054]    1. Topological Structure of the System 
         [0055]    Devices conforming to the system include the following several parts: 
         [0056]    (1) Multiple Digital Interfaces (Output Interfaces or Input/Output Interface Modules) 
         [0057]    The multiple digital interfaces are mainly for outputting digital contents to other devices or network. With regard to a two-way network, etc., the same interface has input function and output function. The module can be responsible for encryption/decryption processing of data at the same time, and establishment of a communication link between management units. The same device can have various input interfaces. 
         [0058]    (2) Management/Processing Unit 
         [0059]    The management/processing unit mainly manages output network, functions and sizes of devices, etc., controls output behaviors or behaviors of terminals in the network, is responsible for implementation of some protocols and algorithms and some encryption processing, and is also responsible for management of own interfaces in the device. The functions of the management/processing unit are implemented outside the digital interfaces using software, for example, the CPU of a master chip is used, thus being capable of greatly reducing cost of the system. 
         [0060]    (3) Presentation/Use Unit 
         [0061]    The presentation/use unit is mainly a possible use part of digital contents, and mainly for user operations. 
         [0062]    The management/processing unit is essential for transmitting devices and forwarding devices, and optional for receiving devices which only have presentation function, the transmitting devices and the forwarding devices may not have presentation or use unit module. 
         [0063]    The system supports two topological structures, i.e. the tree topological structure as shown in  FIG. 1  and the network or bus topological structure as shown in  FIG. 2 . 
         [0064]    In the tree topological structure, data is output from a transmitting device, can be directly output to a receiving device or a repeater, and output to other repeaters or receiving devices by the repeater. Among others, the transmitting device can control output scale, such as the quantity of terminals linked to the network and number of output stages. Meanwhile, the transmitting device can also decide which type of devices is not allowed to be networked, and control behaviors of the terminals in the network. 
         [0065]    In the network or bus topological structure, data is output via a transmitting device, output to other devices via a network or a bus. Meanwhile, the network or the bus can have a forwarding device. The transmitting device can control the sizes of output terminals and the number of forwarding layers. The transmitting device has the same capacity as that of the tree topological structure. 
         [0066]    2. System Overview 
         [0067]    The system is mainly used for implementation of security transmission of digital contents via digital interfaces. A typical application of the system includes a transmitting device, one or more receiving devices, zero or more forwarding devices. The solution stipulates a group of operations to be completed by all parties participating in transmission of digital contents among the transmitting device, the forwarding device and the receiving device. 
         [0068]    First, the device implements authentication process before content transmission, the authentication process is generally performed between directly linked devices, directly linked interfaces, etc., including authentication between the management/processing unit of the transmitting device and the forwarding device and own digital interface of the devices, authentication between the digital interface of two directly linked devices, and authentication between the management/processing unit of transmitter and the management/processing unit of receiver. After the authentication, if clearly no protection is required for digital contents to be transmitted, the digital contents can be transmitted directly; if protection is required for the digital contents to be transmitted or content protection mark can not be found, the digital contents are encrypted and then transmitted. Meanwhile, the system must maintain the integrity of the system at any time by updating the revocation list, and exclude revoked devices and interfaces from the system. 
         [0069]    A basic workflow of the system is explained based on the example of transmitting digital contents by a device A and a device B via an interface A 2  and an interface B 1 . 
         [0070]      FIG. 3  is a schematic diagram of content flow of the system. The digital contents flow from a management/processing unit of the device A to the interface A 2  of the device A and the interface B 1  of the device B, and reach a management/processing unit B. 
         [0071]    After the device A and the device B are electrified, inter-authentication process of the devices is implemented, and the management/processing unit initiates an authentication between the management/processing unit and an interface thereof. If the device B does not have a management/processing unit, the inter-authentication process is not implemented. 
         [0072]    When the electrified devices A and B are linked via an interface or the devices A and B linked via an interface are electrified, the interface A 2  detects a hot plug detect signal (HPD signal) of the interface B 1  or a broadcast signal, the two linked devices successively implement corresponding operations according to different states, in which the following operations implemented between the devices must be implemented after interface or network communication link connection is completed, and the interfaces at both devices refer only to interfaces of the same physical connection: 
         [0073]    a) After the interface A 2  detects that the HPD signal or broadcast signal is connected: 
         [0074]    a1) if inter-authentication of the interface A 2  is not completed, the inter-authentication process continues; 
         [0075]    a2) if the inter-authentication of the interface A 2  succeeds, the interface A 2  initiates a two-way authentication between the interface A 2  and the interface B 1 , 
         [0076]    a3) if the inter-authentication of the interface A 2  is not completed successfully, and a content protection mark indicates that no protection is required for the contents, then the interface A 2  directly transmits the digital contents to the interface B 1 ; and 
         [0077]    a4) if the inter-authentication of the interface A 2  is not completed successfully, and protection is required for the contents or no content protection mark is found, then it is prohibited to transmit the digital contents to the interface B 1  via the interface A 2 . 
         [0078]    b) after a two-way authentication between the interface A 2  and the interface B 1  and a two-way authentication between a management/processing unit of the device A and a management/processing unit of the device B are completed: 
         [0079]    b1) if no protection is required for digital contents to be transmitted, the interface A 2  directly transmits the digital contents to the interface B 1 , 
         [0080]    b2) if the authentications pass, and protection is required for the digital contents to be transmitted or no content protection mark is found, the interface A 2  initiates a key activation between the interface A 2  and the interface B 1 ; 
         [0081]    b3) if the authentications pass, and the versions of revocation lists stored in management/processing units at both devices are inconsistent, a revocation list update between the devices is implemented; 
         [0082]    b4) if the authentications pass, and information collection process of the device A is not completed, then the device management unit A initiates a link information collection process; and 
         [0083]    b5) if the authentications do not pass, protection is required for the digital contents to be transmitted or no content protection mark is found, it is prohibited to transmit the digital contents to the interface B 1  via the interface A 2 ; 
         [0084]    c) after key activation transmission between the interface A 2  and the interface B 1  is completed: 
         [0085]    c1) if key activation succeeds, content encryption transmission process proceeds, the interface A 2  encrypts and transmits the digital contents, and the interface B 1  receives and decrypts the digital contents; 
         [0086]    c2) if the key activation fails, and the frequency of failures is less than a specified frequency (e.g. three times), the interface A 2  reinitiates a key activation between the interface A 2  and the interface B 1 ; and 
         [0087]    c3) if the key activation fails and the frequency of failures is more than the specified frequency, the interface A 2  reinitiates a two-way authentication between the interface A 2  and the interface B 1 . 
         [0088]    d) when information collection is carried out between management/processing units: 
         [0089]    d1) if information collection fails, and the frequency of failures is less than the specified frequency, a management/processing unit A reinitiates information collection between the management/processing unit A and a management/processing unit B; and 
         [0090]    d2) if information collection fails, and the frequency of failures is more than the specified frequency, then information collection process is terminated, and an information collection failure flag bit is set. 
         [0091]    e) during content encryption transmission process: 
         [0092]    e1) synchronous key check process is implemented in each line blanking period; and 
         [0093]    e2) if a key update period expires, the interface A 2  implements a key update between the interface A 2  and the interface B 1 . 
         [0094]    f) during synchronous key check process: 
         [0095]    f1) if synchronization is correct, content encryption transmission process continues; and 
         [0096]    f2) if synchronization is wrong, the interface A 2  reinitiates key activation between the interface A 2  and the interface B 1 . 
         [0097]    II Specific Procedures 
         [0098]    In the system, two communication participants identify legality of the identity each other, and a new shared key is established between the participants after identification passes. 
         [0099]    In the following description, state bits of different registers are shown in the table below: 
         [0100]    Definition of each state bit of a register R MU  in the management/processing unit is as shown in Table 1, and the register R MU  is used for storing identifications in the authentication process: 
         [0000]    
       
         
               
               
               
             
           
               
                 TABLE 1 
               
               
                   
               
               
                 Name of state 
                 Mark 
                 Full name in English 
               
               
                   
               
             
             
               
                 Hot Plug Detect Flag 
                 HPD 
                 Hot Plug Detect Flag 
               
               
                 Inter-Authentication Completed 
                 IAC 
                 Inter-Authentication 
               
               
                   
                   
                 Completed 
               
               
                 Inter-Authentication Succeed 
                 IAS 
                 Inter-Authentication 
               
               
                   
                   
                 Succeed 
               
               
                 IUM Update Completed 
                 IUC 
                 IUM Update Completed 
               
               
                 IUM Update Succeed 
                 IUS 
                 IUM Update Succeed 
               
               
                 Content Encryption Request 
                 CER 
                 Content Encryption 
               
               
                   
                   
                 Request 
               
               
                 Information Collection 
                 ICC 
                 Information Collection 
               
               
                 Completed 
                   
                 Completed 
               
               
                 MU Authentication Completed 
                 MAC 
                 MU Authentication Completed 
               
               
                 MU Authentication Succeed 
                 MAS 
                 MU Authentication Succeed 
               
               
                   
               
             
          
         
       
     
         [0101]    Definition of each state bit of a register R STAT  in the management/processing unit is as shown in Table 2, and the register R STAT  is used for storing identifications in the information collection process: 
         [0000]    
       
         
               
               
               
             
           
               
                 TABLE 2 
               
               
                   
               
               
                 Name of state 
                 English mark 
                 Full name in English 
               
               
                   
               
             
             
               
                 All IUM Update Completed 
                 AIUC 
                 All IUM Update Completed 
               
               
                 All Information Collection 
                 AICC 
                 All Information Collection 
               
               
                 Completed 
                   
                 Completed 
               
               
                 All Inter-Authentication 
                 AIAC 
                 All Inter-Authentication 
               
               
                 Completed 
                   
                 Completed 
               
               
                 All Inter-Authentication 
                 AIAS 
                 All Inter-Authentication 
               
               
                 Succeed 
                   
                 Succeed 
               
               
                 Link Depth 
                 LD 
                 Link Depth 
               
               
                 Link Count 
                 LC 
                 Link Count 
               
               
                 Max Cascade Exceeded 
                 MCE 
                 Max Cascade Exceeded 
               
               
                 Max Devs Exceeded 
                 MDE 
                 Max Devs Exceeded 
               
               
                   
               
             
          
         
       
     
         [0102]    Definition of each state bit of a register R IN  in the digital interface is as shown in Table 3: 
         [0000]    
       
         
               
               
               
             
           
               
                 TABLE 3 
               
               
                   
               
               
                 Name of state 
                 English mark 
                 Full name in English 
               
               
                   
               
             
             
               
                 Hot Plug Detect Flag 
                 HPD 
                 Hot Plug Detect Flag 
               
               
                 Inter-Authentication Succeed 
                 IAS 
                 Inter-Authentication 
               
               
                   
                   
                 Succeed 
               
               
                 Inter-Authentication Completed 
                 IAC 
                 Inter-Authentication 
               
               
                   
                   
                 Completed 
               
               
                 Content Encryption Request 
                 CER 
                 Content Encryption 
               
               
                   
                   
                 Request 
               
               
                 Outer-Authentication Completed 
                 OAC 
                 Outer-Authentication 
               
               
                   
                   
                 Completed 
               
               
                 Outer-Authentication Succeed 
                 OAS 
                 Outer-Authentication 
               
               
                   
                   
                 Succeed 
               
               
                 Key Activation Succeed 
                 KAS 
                 Key Activation 
               
               
                   
                   
                 Succeed 
               
               
                 Stream Cipher Synchronization 
                 SCS 
                 Stream Cipher 
               
               
                   
                   
                 Synchronization 
               
               
                 Having MU 
                 HMU 
                 Having MU 
               
               
                 Public-key Is Legal 
                 PIS 
                 Public-key Is Legal 
               
               
                   
               
             
          
         
       
     
         [0103]    1.1 Inter-Authentication and Outer-Authentication 
         [0104]    Authentications of the system include inter-authentication and outer-authentication. The inter-authentication completes an authentication between the management/processing unit and the interface thereof in the device, and the inter-authentication process is initiated by the management/processing unit; and the outer-authentication includes an authentication between interfaces linked between two devices and an authentication between two management/processing units, and the interface authentication is initiated by a transmitting interface, and the authentication between management/processing units is initiated by a transmitting management/processing unit. 
         [0105]    The procedures for implementation of the inter-authentication and the outer-authentication are similar, the distinction is that prerequisites for triggering implementation of the inter-authentication and the outer-authentication and updated state bits after implementation are different: 
         [0106]    The inter-authentication: the management/processing unit of the device checks an IAC bit of the R MU  corresponding to a specific interface. If the IAC bit is 0, the management/processing unit initiates a two-way authentication between the management/processing unit and the specific interface. If the authentication succeeds, the management/processing unit sets the IAS bit and the IAC bit of the R MU  corresponding to the interface as 1, and the corresponding interface sets flag bits in an R IN  as IAS=1 and IAC=1. If the authentication fails, the management/processing unit sets the IAS bit of the R MU  corresponding to the interface as 0, and IAC bit as 1, and the corresponding interface sets flag bits in the R IN  as IAS=0 and IAC=1. 
         [0107]    Authentication between interfaces: after a transmitting interface of the transmitting device completes the inter-authentication (in the corresponding R IN , IAS=1 and OAC=0), a two-way authentication between the transmitting interface and a receiving interface linked thereto is initiated. If the authentication succeeds, the transmitting interface and the receiving interface respectively set flag bits in respective R IN  as OAC=1 and OAS=1. If the authentication fails, the transmitting interface and the receiving interface respectively set the flag bits in respective R IN  as OAC=1 and OAS=0. 
         [0108]    Authentication between management/processing units: after the authentication between interfaces is completed or during content security transmission, if information collection and/or revocation list (IUM) update need to be implemented, a two-way authentication between management/processing units needs to be implemented. If the authentication succeeds, the management/processing units respectively set flag bits in respective R MU  as MAC=1 and MAS=1. If the authentication fails, the management/processing units respectively set the flag bits in respective R MU  as MAC=1 and MAS=0. 
         [0109]    1.1 Implementation Process of the Inter-Authentication 
         [0110]    In the implementation process of inter-authentication, suppose A is a management/processing unit (i.e. an authentication initiator) in the device, and B is a digital interface (i.e. an authentication responder) in the same device. Suppose a public key of the A is {right arrow over (p A1 )} and a private key thereof is {right arrow over (s A1 )}, a public key of the B is {right arrow over (p B1 )} and a private key thereof is {right arrow over (s B1 )}, and the A and the B keep a storage correlation coefficient k 1 , an offset vector {right arrow over (e)} 1 , a regression coefficient a 1  and a modulus m 1  secret. 
         [0111]    The specific authentication process is as follows: 
         [0112]    a) Implementing, by the initiator A, the following processes successively during the authentication process: 
         [0113]    a1) reading, by the A, an ID of a local system and a system version number to form a message Mes 1 , transmitting the message Mes 1  to the B, and implementing the next step after completion of transmission; 
         [0114]    Contents of a protocol message contained in the message Mes 1  are as follows:
       Message ID∥system ID∥system version number       
 
         [0116]    The symbol “∥” herein represents a bound symbol; 
         [0117]    a2) waiting for a message Mes 2  from B, after the A transmits the message Mes 1 , setting the maximum wait time T, and beginning timing, if the message Mes 2  from B is received within the maximum wait time T, implementing the next step; otherwise implementing step a 11 ); 
         [0118]    a3) verifying whether the public key in the message Mes 2  is legal: judging, by the A, whether the {right arrow over (p B1 )} is in the IUM stored in the A, setting, by the management/processing unit, the flag bit IAS in the R MU  as 0 if the {right arrow over (p B1 )} is in the IUM, the authentication failing, and implementing step a11); otherwise implementing the next step; 
         [0119]    a4) generating a random number R A1 , reading the public key {right arrow over (p A1 )}, forming a message Mes 3  after cascading, transmitting the message Mes 3  to the B, and implementing the next step after completion of transmission; 
         [0120]    contents of a protocol message Mes 3  are as follows:
       Message ID∥{right arrow over (p A1 )}∥R A1          
 
         [0122]    a5) reading, by the A, authentication parameters, successively performing the following computations, and implementing the next step after completion of the computations; 
         [0123]    a5-1) computing a vector product M 1 ; 
         [0000]        M 1= k   1 ×({right arrow over ( p   B1 )}×{right arrow over ( s   A1   Γ )}+{right arrow over ( p   B1 )}×{right arrow over ( e   1   Γ )}+ a   1 )   (mod m 1 )
 
         [0124]    a5-2) computing a master key K_M 1 ; 
         [0000]        K   —   M 1= M   —   A ( M 1μ R   A1   ∥R   B1 ):
       M_A herein represents an HASH algorithm, e.g. SHA-1 and HMAC;       
 
         [0126]    a5-3) computing authentication codes R 11  and R 21 : 
         [0000]        R   11   =M   —   A ( K   —   M 1∥ R   A1 )
 
         [0000]        R   21   =M   —   A ( K   —   M 1∥ R   B1 )
 
         [0127]    a6) transmitting a message Mes 4  containing the authentication code R 21  to the B, and implementing the next step after completion of transmission; 
         [0128]    Contents of a protocol message Mes 4  are as follows:
       Message ID∥R 21          
 
         [0130]    a7) waiting for a message Mes 5 , After the A completes the computations, setting a maximum wait time T, and beginning timing, if the message Mes 5  returned from B is received within the maximum wait time T, implementing the next step; otherwise implementing the step a11); 
         [0131]    a8) comparing whether the authentication code R 11  obtained in local computation is equal to the received R 11 ′, and transmitting a message MesS to the B if the authentication code R 11  obtained in the local computation is equal to the received R 11 ′, otherwise implementing the step a11); 
         [0132]    Contents of a protocol message MesS are as follows:
       Message ID∥SUCCEED       
 
         [0134]    The value of SUCCEED flags contained in all SUCCEED messages and FAIL messages defined in the specification is 0, and the value of FAIL flags is 1, occupying one byte respectively. 
         [0135]    a9) waiting for a message MesD, after the A completes the computations, setting the maximum wait time T, and beginning timing, if the message MesD from B is received within the maximum wait time T, implementing the next step; otherwise implementing the step a11); 
         [0136]    a10) storing the master key K_M 1 , setting flag bits in the R MU  as IAS=1 and IAC=1, and implementing no subsequent step in case that the authentication protocol is successfully implemented; 
         [0137]    a11) checking whether frequency of continuous local authentication failures is less than a specified frequency: adding 1 to the frequency of authentication failures, and reinitiating a two-way authentication between the A and the B if the frequency of the continuous local authentication failures is less than the specified frequency; otherwise setting flag bits in the R MU  as IAC=1 and IAS=0, and terminating the two-way authentication process in case that implementation failure of a two-way authentication protocol. 
         [0138]    b) Implementing, by the responder B, the following processes successively during the authentication process: 
         [0139]    b1) Reading the message Mes1, and then successively performing the next step; 
         [0140]    b2) verifying whether an authentication protocol version is compatible, checking, by the B, whether the authentication protocol version is compatible with the locally supported protocol version according to the system ID and the system version number in the message Mes 1 , and implementing the next step if the authentication protocol version is compatible with the locally supported protocol version, otherwise implementing step b12); 
         [0141]    b3) generating a random number R B1 , reading the locally stored public key {right arrow over (p B1 )}, forming a message Mes 2  after cascading, transmitting the message Mes 2  to the A, and implementing the next step after completion of transmission; 
         [0142]    Contents of the protocol message Mes 2  are as follows:
       Message ID∥{right arrow over (p B1 )}∥R B1          
 
         [0144]    b4) Waiting to read a message Mes 3  from A, after the B transmits the message Mes 2 , setting a maximum wait time T, and beginning timing, if the message Mes 3  from A is received within the maximum wait time T, implementing the next step; otherwise implementing the step b12); 
         [0145]    b5) verifying whether the public key in the message Mes 3  is legal: judging, by B, whether the {right arrow over (p A1 )} is in the IUM by accessing the IUM stored in the A, setting, by MU, the flag bit IAS in the R IN  corresponding to the B as 0 if the {right arrow over (p A1 )} is in the IUM, the authentication failing, and implementing the step b12), otherwise implementing the next step; 
         [0146]    b6) Reading, by the B, authentication parameters, successively performing the following computations, and implementing the next step after completion of the computations; 
         [0147]    b6-1) computing a vector product M 1 ′: 
         [0000]        M 1′= k   1 ×({right arrow over ( p   A1 )}×{right arrow over ( s   B1   Γ )}+{right arrow over ( p   A1 )}×{right arrow over ( e   1   Γ )}+ a   1 )   (mod m 1 )
 
         [0148]    b6-2) computing a master key K_M 1 ; 
         [0000]        K   —   M 1′= M   —   A ( M   1′, R   A1   ∥R   B1 )
 
         [0149]    b6-3) computing authentication codes R 11 ′ and R 21 ′: 
         [0000]        R   11   ′=M   —   A ( K   —   M 1′∥ R   A1 )
 
         [0000]        R   21   ′=M   —   A ( K   —   M 1′∥ R   B1 )
 
         [0150]    b7) transmitting a message Mes 5  containing the authentication code R 11 ′ to a corresponding storage area in the A, and implementing the next step after completion of transmission; 
         [0151]    Contents of a protocol message Mes 5  are as follows:
       Message ID∥R 11 ′       
 
         [0153]    b8) waiting to read a message Mes 4 , setting, by the B, the maximum wait time T, and beginning timing, if the message Mes 4  returned from A is read within the maximum wait time T, performing the next step; otherwise performing the step b12); 
         [0154]    b9) comparing whether the authentication code R 21 ′ is equal to the received R 21 , transmitting a message MesD to the A if the authentication code R 21  is equal to the received R 21 , and implementing the next step after completion of transmission, otherwise implementing the step b12); 
         [0155]    Contents of a protocol message are as follows:
       Message ID∥SUCCEED       
 
         [0157]    b10) waiting to read a message MesS, setting, by the B, the maximum wait time T, and beginning timing, if the message MesS returned from A is received within the maximum wait time T, performing the next step; otherwise performing the step b12); 
         [0158]    b11) Storing the master key K_M1′, setting flag bits in a local register R IN  as IAS=1 and IAC=1, and implementing no subsequent step in case that the authentication protocol is successfully implemented; 
         [0159]    b12) checking whether frequency of continuous local authentication failures is less than a specified frequency: adding 1 to the frequency of authentication failures, and waiting for the A to reinitiate a two-way authentication process if the frequency of the continuous local authentication failures is less than the specified frequency; otherwise setting flag bits in a corresponding state register R IN  in the device B as IAC=1 and IAS=0, and terminating the two-way authentication process in case that implementation failure of a two-way authentication protocol. 
         [0160]    1.2 Implementation Process of the Authentication Between Interfaces 
         [0161]    In the implementation process of the authentication between interfaces, suppose A is a digital interface of transmitter(i.e. an authentication initiator), and B is a digital interface of receiver (i.e. an authentication responder). Suppose a public key of the A is {right arrow over (p A2 )} and a private key thereof is {right arrow over (s A2 )}, a public key of B is {right arrow over (p B2 )} and a private key thereof is {right arrow over (s B2 )}, and the A and the B storage correlation coefficient k 2 , an offset vector {right arrow over (e)} 2 , a regression coefficient a 2  and a modulus m 2  secret. 
         [0162]    The specific authentication process is as follows: 
         [0163]    a) Implementing, by the initiator A, the following processes successively during authentication process: 
         [0164]    a1) reading, by the A, the ID of a local system and a cascade of a system version number to form a message Mes 1 _INBiAuth, transmitting a message Mes 1 _INBiAuth to the B, and implementing the next step after completion of transmission; 
         [0165]    Contents of a protocol message Mes 1 _INBiAuth are as follows:
       Message ID∥system ID∥system version number       
 
         [0167]    a2) waiting for a message Mes 2 _INBiAuth returned from the B, after the A transmits the message Mes 1 _INBiAuth, setting a maximum wait time T_INBiAuthDelay, and beginning timing, if the message Mes 2 _INBiAuth returned from the B is received within the maximum wait time T_INBiAuthDelay, implementing the next step; otherwise implementing the step a11); 
         [0168]    a3) verifying whether the public key in the message Mes 2 _INBiAuth is legal, judging, by the management/processing unit MU A  in the device A, whether the {right arrow over (p B2 )} is in the IUM A : setting, by the MU A , the flag bit PIS in the R IN  corresponding to the A as 0 if the {right arrow over (p B2 )} is in the IUM A , otherwise setting the PIS as 1; inquiring, by the A, the value of a flag bit PIS within the T_INBiAuthDelay, considering the B as an illegal interface if the value of the PIS is inquired to be 0 within the T_INBiAuthDelay, the authentication failing, and implementing the step a11), otherwise implementing the next step; 
         [0169]    Where, the management/processing unit of the device can obtain the {right arrow over (P B2 )} by inquiry, or can be informed after an interface receives the {right arrow over (P B2 )}. 
         [0170]    a4) generating a random number R A2 , reading the locally stored public key {right arrow over (p A2 )}, forming a message Mes 3 _INBiAuth after cascading, transmitting a message Mes 3 _INBiAuth to the B, and implementing the next step after completion of transmission; 
         [0171]    Contents of a protocol message Mes 3 _INBiAuth are as follows:
       Message ID∥{right arrow over (p A2 )}∥R A2          
 
         [0173]    a5) reading, by the A, locally stored authentication parameters, successively performing the following computations, and implementing the next step after completion of the computations; 
         [0174]    a5-1) computing a vector product M 2 : 
         [0000]        M 2 =k   2 ×({right arrow over ( p   B2 )}×{right arrow over ( s   A2   Γ )}+{right arrow over (p B2 )}×{right arrow over ( e   2   Γ )}+ a   2 )   (mod m 2 )
 
         [0175]    a5-2) computing a master key K_M 2 ; 
         [0000]        K   —   M 2 =M   —   A ( M 2∥ R   A2   ∥R   B2 ):
 
         [0176]    a5-3) computing authentication codes R 12  and R 22 : 
         [0000]        R   12   =M   —   A ( K   —   M 2∥ R   A2 )
 
         [0000]        R   22   =M   —   A ( K   —   M 2∥ R   B2 )
 
         [0177]    a6) transmitting a message Mes 4 _INBiAuth containing the authentication code R 22  to the B, and implementing the next step after completion of transmission; 
         [0178]    Contents of a protocol message Mes 4 _INBiAuth are as follows:
       Message ID∥R 22          
 
         [0180]    a7) waiting for a message Mes 5 _INBiAuth, after the A completes the above computations, setting the maximum wait time T_INBiAuthDelay, and beginning timing, if a message Mes 5 _INBiAuth returned from the B is received within the T_INBiAuthDelay, implementing the next step; otherwise implementing the step a11), 
         [0181]    a8) comparing whether the authentication code R 12  obtained in local computation is equal to the received R 12 , and transmitting a message MesS_INBiAuth_Succeed to the B if the authentication code R 12  obtained in local computation is equal to the received R 12 , otherwise implementing the step a11); 
         [0182]    Contents of a protocol message MesS_INBiAuth_Succeed are as follows:
       Message ID∥SUCCEED       
 
         [0184]    The value of SUCCEED flags contained in all SUCCEED messages and FAIL messages defined in the specification is 0, and the value of FAIL flags is 1, occupying one byte respectively. 
         [0185]    a9) waiting for a message MesD_INBiAuth_Succeed, after the A completes the computations, setting the maximum wait time T_INBiAuthDelay, and beginning timing, if the message MesD_INBiAuth_Succeed from the B is received within the T_INBiAuthDelay, implementing the next step; otherwise implementing the step a11); 
         [0186]    a10) storing the master key K_M2, setting flag bits in a local register R IN  as OAC=1 and OAS=1, and implementing no subsequent step in case that the authentication protocol is successfully implemented; 
         [0187]    a11) checking whether frequency of continuous local authentication failures is less than a specified frequency: adding 1 to the frequency of authentication failures, and reinitiating a two-way authentication between the A and the B if the frequency of the continuous local authentication failures is less than specified frequency; otherwise setting flag bits in a corresponding state register R IN  in the device A as OAC=1 and OAS=0, and terminating the two-way authentication process in case that implementation failure of a two-way authentication protocol. 
         [0188]    b) Implementing, by the responder B, the following processes successively during the authentication process: 
         [0189]    b1) Reading the Mes 1 _INBiAuth, and then successively implementing the next step; 
         [0190]    b2) verifying whether the authentication protocol version is compatible, checking, by B, whether the authentication protocol version is compatible with the locally supported protocol version according to the system ID and the system version number in the message Mes 1 _INBiAuth, and implementing the next step if the authentication protocol version is compatible with the locally supported protocol version, otherwise implementing the step b12); 
         [0191]    b3) generating a random number R B2 , reading the locally stored public key {right arrow over (p B2 )}, forming a message Mes 2 _INBiAuth after cascaded, transmitting the message Mes 2 _INBiAuth to the A, and implementing the next step after completion of transmission; 
         [0192]    Contents of a protocol message Mes 2 _INBiAuth are as follows:
       Message ID∥{right arrow over (p B2 )}∥R B2          
 
         [0194]    b4) Waiting to read a message Mes 3 _INBiAuth returned from the A, after B transmits the message Mes 2 _INBiAuth, setting, by the B, a maximum wait time T_INBiAuthDelay, and beginning timing, if the message Mes 3 _INBiAuth from the A is received within the T_INBiAuthDelay, implementing the next step; otherwise implementing the step b12); 
         [0195]    b5) verifying whether the public key in the message Mes 3 _INBiAuth is legal, judging, by the management/processing unit MU B  in the device B, whether the {right arrow over (p A2 )} is in the IUM B : setting, by the management/processing unit MU B , the flag bit PIS in R IN  corresponding to the B as 0 if {right arrow over (p A2 )} is in the IUM B , otherwise setting the PIS as 1; inquiring, by the B, the value of the flag bit PIS within T_INBiAuthDelay/2, considering the A as an illegal interface if the value of the PIS is inquired to be 0 within the T_INBiAuthDelay/2, the authentication failing, and implementing the step b12), otherwise implementing the next step; 
         [0196]    b6) reading, by the B, locally stored authentication parameters, successively performing the following computations, and implementing the next step after completion of the computations; 
         [0197]    b6-1) computing a vector product M2′: 
         [0000]        M 2′= k   2 ×({right arrow over ( p   A2 )}×{right arrow over ( s   B2   Γ )}+{right arrow over ( p   A2 )}×{right arrow over ( e   2   Γ )}+ a   2 )   (mod m 2 )
 
         [0198]    b6-2) computing a master key K_M2′; 
         [0000]        K   —   M 2′= M   —   A ( M 2′,  R   A2   ∥R   B2 )
 
         [0199]    b6.-3) computing authentication codes R 12 ′ and R 22 ′: 
         [0000]        R   12   ′=M   —   A ( K   —   M 2′∥ R   A2 )
 
         [0000]        R   22   ′=M   —   A ( K   —   M 2′∥ R   B2 )
 
         [0200]    b7) transmitting a message Mes 5 _INBiAuth containing the authentication code R 12 ′ to a corresponding storage area of the A, and implementing the next step after completion of transmission; 
         [0201]    Contents of a protocol message Mes 5 _INBiAuth are as follows:
       Message ID∥R 12 ′       
 
         [0203]    b8) waiting to read a message Mes 4 _INBiAuth, setting, by the B, the maximum wait time T_INBiAuthDelay, and beginning timing, if the message Mes 4 _INBiAuth returned from the A is read within the T_INBiAuthDelay, implementing the next step; otherwise implementing the step b12); 
         [0204]    b9) comparing whether the authentication code R 22 ′ obtained in local computation is equal to the received R 22 , transmitting a message MesD_INBiAuth_Succeed to the A if the authentication code R 22 ′ obtained in local computation is equal to the received R 22 , and implementing the next step after completion of transmission, otherwise implementing the step 12); 
         [0205]    Contents of a protocol message are as follows:
       Message ID∥SUCCEED       
 
         [0207]    b10) Waiting to read the message MesS_INBiAuth_Succeed, setting, by the B, the maximum wait time T_INBiAuthDelay, and beginning timing, if the message MesS_INBiAuth Succeed returned from the A is received within the T_INBiAuthDelay, implementing the next step; otherwise implementing the step b12); 
         [0208]    b11) storing the master key K_M 2 , setting flag bits in a local register R IN  as OAC=1 and OAS=1, and implementing no subsequent step in case that the authentication protocol is successfully implemented; 
         [0209]    b12) checking whether frequency of continuous local authentication failures is less than a specified frequency: adding 1 to the frequency of authentication failures, and waiting for the A to reinitiate a two-way authentication process if the frequency of the continuous local authentication failures is less than the specified frequency; otherwise setting flag bits in a corresponding state register R IN  in the device B as OAC=1 and OAS=0, and terminating the two-way authentication process in case that implementation failure of a two-way authentication protocol. 
         [0210]    1.3 Implementation Process of the Authentication Between Management/Processing Units 
         [0211]    After the authentication between interfaces is completed, a one-way data channel or a two-way data channel of the interfaces is employed to provide a data channel for the management/processing units. For example, an I2C channel can be used for data transmission in case that HDMI, and a AUX channel can be used for transmission in case that DisplayPort. The management/processing unit inquires the value of a flag bit HMU in the transmitting interface register R IN  on the link. If HMU=1, the authentication between management/processing units is implemented. 
         [0212]    In the system, the implementation process of the two-way authentication between management/processing units is basically the same as that of the two-way authentication between interfaces, and differences include legality check of public keys, settings of flag bits and name of protocol messages. In the implementation process of the authentication between management/processing units, suppose A is a management/processing unit of transmitter (i.e. an authentication initiator), and B is a management/processing unit of receiver (i.e. an authentication responder). Suppose a public key of the A is {right arrow over (p A3 )} and a private key thereof is {right arrow over (s A3 )}, a public key of the B is {right arrow over (p B3 )} and a private key thereof is {right arrow over (s B3 )}, and the A and the B storage correlation coefficient k 3 , an offset vector {right arrow over (e)} 3 , a regression coefficient a 3  and a modulus m 3  secret. 
         [0213]    The specific authentication process is as follows: 
         [0214]    a) Implementing, by the initiator A, the following processes successively during the authentication process: 
         [0215]    a1) reading, by A, the ID of a local system and a cascade of an MU system version number to form a message Mes 1 _MUBiAuth, transmitting the message Mes 1 _MUBiAuth to the B, and implementing the next step after completion of transmission; 
         [0216]    Contents of a protocol message Mes 1 _MUBiAuth are as follows:
       Message ID∥system ID∥system version number       
 
         [0218]    a2) waiting for a message Mes 2 _MUBiAuth transmitted from the B, after the A transmits the message Mes 1 _MUBiAuth, setting a maximum wait time T_MUBiAuthDelay, and beginning timing, if the message Mes 2 _MUBiAuth returned from the B is received within the T_MUBiAuthDelay, implementing the next step; otherwise implementing the step 11); 
         [0219]    a3) verifying whether the public key in the message Mes 2 _MUBiAuth is legal, and judging, by the A, whether {right arrow over (p B3 )} is in the IUM A , considering the B illegal if {right arrow over (p B3 )} is in the IUM A , the authentication failing, and implementing the step a11), otherwise implementing the next step; 
         [0220]    a4) generating a random number R A3 , reading the locally stored public key {right arrow over (p A3 )}, forming a message Mes 3 _MUBiAuth after cascading, transmitting the message Mes 3 _MUBiAuth to the B, and implementing the next step after completion of transmission; 
         [0221]    Contents of a protocol message Mes 3 _MUBiAuth are as follows:
       Message ID∥{right arrow over (p A3 )}∥R A3          
 
         [0223]    a5) reading, by the A, locally stored authentication parameters, successively performing the following computations, and implementing the next step after completion of the computations; 
         [0224]    a5-1) Computing a vector product M 3 : 
         [0000]        M 3= k   3 ×({right arrow over ( p   B3 )}×{right arrow over (s A3   Γ )}+{right arrow over (p B3 )}×{right arrow over ( e   3   Γ )}+a 3 )   (mod m 3 )
 
         [0225]    a5-2) computing a master key K_M 3 , 
         [0000]        K   —   M 3= M   —   A ( M 3∥ R   A3   ∥R   B3 ):
 
         [0226]    a5-3) computing authentication codes R 13  and R 23    
         [0000]        R   13   =M   —   A ( K   —   M 3∥ R   A3 )
 
         [0000]        R   23   =M   —   A ( K   —   M 3 ∥R   B3 ) 
         [0227]    a6) Transmitting a message Mes 4 _MUBiAuth containing the authentication code R 23  to the B, and implementing the next step after completion of transmission; 
         [0228]    Contents of a protocol message Mes 4 _MUBiAuth are as follows:
       Message ID∥R 23          
 
         [0230]    a7) waiting for a message Mes 5 _MUBiAuth, after the A completes the computations, setting the maximum wait time T_MUBiAuthDelay, and beginning timing, if the message Mes 5 _MUBiAuth returned from the B is received within the T_MUBiAuthDelay, implementing the next step; otherwise implementing the step a11); 
         [0231]    a8) Comparing whether the authentication code R 13  obtained in local computation is equal to the received R 13 ′, and transmitting a message MesS_MUBiAuth_Succeed to the B if the authentication code R 13  obtained in the local computation is equal to the received R 13 ′, otherwise implementing the step a11); 
         [0232]    Contents of a protocol message MesS_MUBiAuth_Succeed are as follows:
       Message ID∥SUCCEED       
 
         [0234]    The value of SUCCEED flags contained in all SUCCEED messages and FAIL messages defined in the specification is 0, and the value of FAIL flags is 1, occupying one byte respectively. 
         [0235]    a9) Waiting for a message MesD_MUBiAuth_Succeed, after the A completes the computations, setting the maximum wait time T_MUBiAuthDelay, and beginning timing, if the message MesD_MUBiAuth_Succeed from the B is received within the T_MUBiAuthDelay, implementing the next step; otherwise implementing the step a11); 
         [0236]    a10) setting flag bits in a local register R MU  as MAC=1 and MAS=1, and implementing no subsequent step in case that the authentication protocol is successfully implemented; 
         [0237]    a11) verifying whether the frequency of continuous local authentication failures is less than specified frequency: adding 1 to the frequency of authentication failures, and reinitiating a two-way authentication between the A and the B if the frequency of continuous local authentication failures is less than 3; otherwise setting flag bits in a corresponding state register R MU  in the device A as MAC=1 and MAS=0, and terminating the two-way authentication process in case that implementation failure of a two-way authentication protocol. 
         [0238]    b) Implementing, by the responder B, the following processes successively during the authentication process: 
         [0239]    b1) Reading the message Mes 1 _MUBiAuth, and then successively implementing the next step; 
         [0240]    b2) verifying whether the authentication protocol version is compatible, checking, by B, whether the authentication protocol version is compatible with the locally supported protocol version according to the system ID and the system version number of the management/processing unit in the message Mes 1 _MUBiAuth, and implementing the next step if the authentication protocol version is compatible with the locally supported protocol version, otherwise implementing the step b12); 
         [0241]    b3) Generating a random number R B3 , reading the locally stored public key {right arrow over (p B3 )}, forming a message Mes 2 _MUBiAuth after cascading, transmitting the message Mes 2 _MUBiAuth to the A, and implementing the next step after completion of transmission; 
         [0242]    Contents of protocol message Mes 2 _MUBiAuth are as follows:
       Message ID∥{right arrow over (p B3 )}∥R B3          
 
         [0244]    b4) waiting to read the message Mes 3 _MUBiAuth returned from the A, after B transmits the message Mes 2 _MUBiAuth, setting the maximum wait time T_MUBiAuthDelay, and beginning timing, if the message Mes 3 _MUBiAuth of the A is received within the T_MUBiAuthDelay, implementing the next step; otherwise implementing the step b12); 
         [0245]    b5) verifying whether the public key in the message Mes 3 _MUBiAuth is legal, and judging, by the B, whether the {right arrow over (p A3 )} is in IUM B , considering the A illegal if {right arrow over (p A3 )} is in the IUM B , the authentication failing, and implementing the step b12), otherwise implementing the next step; 
         [0246]    b6) reading, by the B, locally stored authentication parameters, successively performing the following computations, and implementing the next step after completion of the computations; 
         [0247]    b6-1) computing a vector product M 3 ′: 
         [0000]        M 3= k   3 ×({right arrow over ( p   A3 )}×{right arrow over ( s   B3   Γ )}+{right arrow over ( p   A3 )}×{right arrow over ( e   3   Γ )}+a 3 )   (mod m 3 )
 
         [0248]    b6-2) computing a master key K_M 3 ′; 
         [0000]        K   —   M 3′= M   —   A ( M 3′,  R   A3   ∥R   B3 )
 
         [0249]    b6-3) computing authentication codes R 13 ′ and R 23 ′: 
         [0000]        R   13   ′=M   —   A ( K   —   M 3′∥ R   A3 )
 
         [0000]        R   23   ′=M   —   A ( K   —   M 3′∥ R   B3 )
 
         [0250]    b7) transmitting a message Mes 5 _MUBiAuth containing the authentication code R 13 ′ to a corresponding storage area of the A, and implementing the next step after completion of transmission; 
         [0251]    Contents of a protocol message Mes 5 _MUBiAuth are as follows:
       Message ID∥R 13 ′       
 
         [0253]    b8) waiting to read the message Mes 4 _INBiAuth, setting, by the B, the maximum wait time T_MUBiAuthDelay, and beginning timing, if the message Mes 4 _MUBiAuth returned from the A is read within the T_MUBiAuthDelay, implementing the next step; otherwise implementing the step b12); 
         [0254]    b9) comparing whether the authentication code R 23 ′ obtained in the local computation is equal to the received R 22 , transmitting the message MesD_MUBiAuth_Succeed to the A if the authentication code R 23 ′ obtained in local computation is equal to the received R 22 , and implementing the next step after completion of transmission, otherwise implementing the step b12); 
         [0255]    Contents of a protocol message are as follows:
       Message ID∥SUCCEED       
 
         [0257]    b10) waiting to read the message MesS_MUBiAuth_Succeed, setting, by the B, the maximum wait time T_MUBiAuthDelay, and beginning timing, if the message MesS_MUBiAuth_Succeed returned from the A is received within the T_MUBiAuthDelay, implementing the next step; otherwise implementing the step b12); 
         [0258]    b11) setting flag bits in a local register R MU  as MAC=1 and MAS=1, and implementing no subsequent step in case that the authentication protocol is successfully implemented; 
         [0259]    b12) checking whether frequency of continuous local authentication failures is less than a specified frequency: adding 1 to the frequency of authentication failures, and waiting for the A to reinitiate a two-way authentication process if the frequency of the continuous local authentication failures is less than the specified frequency; otherwise setting flag bits in a corresponding state register R MU  in the device B as MAC=1 and MAS=0, and terminating the two-way authentication process in case that implementation failure of a two-way authentication protocol. 
         [0260]    2 Information Collection 
         [0261]    The information collection defined in the system is carried out by the management/processing unit instead of the interface, and the interface only establishes a communication link to cooperate with the management/processing unit to complete the information collection. Contents to be collected include functions of all downstream devices besides the quantity of terminals, link hierarchy, etc. Meanwhile, the ID or the public key of each device is not uploaded so as to reduce the volume of data, and the revocation list of the management/processing unit directly judges legality and validity of the interface. An information collection mechanism of the DTCP is similar to that of the HDCP, the signature uses the ECC algrithom, and the implementation of the ECC signature is very complex in the digital interface, with a very large size. The signature of the solution can receive any public keys signature, and is implemented in the CPU via software, thus effectively reducing complexity and difficulty. 
         [0262]    After completion of all authentications in the device (AIAC=1, AIAS=1), the management/processing unit of transmitter checks the value of the flag bit AICC of R STAT . If AICC=0, the management/processing unit in the device alternately checks the values of flag bits OAC, OAS of R IN  in each activated transmitting interface and the value of ICC in the corresponding local R MU  at a certain time interval T INTER . If OAC=1, OAS=1 and ICC=0, the management/processing unit of transmitter initiates the information collection between the management/processing unit of transmitter and a receiving device on the transmitting interface link to collect link topology information and device capacity information of all activated downstream devices of the link. After the information collection is successfully completed on all activated transmitting interface links, the flag bit AICC in the R STAT  is set as 1, and the information collection process of the device is completed. 
         [0263]    The link topology information includes link count (LC) and link depth (LD), and the device capacity information is fields for characterizing the capacity of a device. 
         [0264]    2.1 Information Collection Protocol 
         [0265]    During the implementation of an information collection protocol, the management/processing unit inquires the value of the flag bit HMU in a transmitting interface register R IN  on the link. If HMU=0, the LC and the LD obtained on the link are set as LC=0 and LD=1, and device capacity information is not collected. If HMU=1, the information collection between management/processing units is implemented. 
         [0266]    If a device having the management/processing unit does not have linked downstream device, capacity information of the device is directly collected, the LC and the LD are set as LC=1 and LD=1, and the flag bit AICC in the R STAT  is set as AICC=1, and the information collection process of the device is completed. 
         [0267]    In the information collection between management/processing units, the topmost device is defined as layer  0 , the layers of linked downstream devices are progressively increased in sequence, the collection process of the LC, the LD and the device capacity is as follows: 
         [0268]    a) LC(n) is defined as the link count stored in the management/processing unit in a device A at layer n, the numerical value thereof is equal to the sum of the LC stored in management/processing units of all directly linked downstream devices plus the number of all directly linked devices, and the computing formula is as follows: 
         [0000]    
       
         
           
             
               
                 
                   
                     LC 
                      
                     
                       ( 
                       n 
                       ) 
                     
                   
                   = 
                   
                     
                       
                         ∑ 
                         
                           i 
                           = 
                           0 
                         
                         
                           k 
                           - 
                           1 
                         
                       
                        
                       
                           
                       
                        
                       
                         
                           LC 
                            
                           
                             ( 
                             
                               n 
                               + 
                               1 
                             
                             ) 
                           
                         
                         i 
                       
                     
                     + 
                     k 
                   
                 
               
               
                 
                   ( 
                   1 
                   ) 
                 
               
             
           
         
       
     
         [0269]    Where, n is the layer at which the device is located, 1≦n≦6, LC(n+1), is the LC stored in the management/processing unit of an i th  device at layer n+1, and k is the number of the directly linked downstream devices of the device A. The LC value of the bottom device (without linked downstream device) is set as 0. 
         [0270]    b) LD(n) is defined as the link depth stored in the management/processing unit of a device A at layer n, the numerical value thereof is equal to the maximum value of the LD stored in management/processing units of all the directly linked downstream devices plus 1, and the computing formula is as follows: 
         [0000]        LD ( n )=MAX( LD ( n+ 1) i )+1   (2)
 
         [0271]    Where, n is the layer at which the device is located, 1≦n≦6, LD(n+1), is the LD stored in the management/processing unit of an i th  device at layer n+1, 0&lt;i≦k, and k is the number of directly linked downstream devices of the device A. The LD value of the bottom device is set as 1. 
         [0272]    c) Downstream device capacity fields stored in the management/processing unit of a device A at layer n are obtained through bit or operation of capacity fields of local devices and capacity fields stored in management/processing units of all directly linked downstream devices. Device capacity fields stored in the management/processing unit of the bottom device is the capacity field of the device. 
         [0273]    In the system, after the device collects all information of a link on which a downstream transmitting interface is arranged, the flag bit ICC in the R MU  corresponding to the link is set as 1, and the flag bit AICC in the R STAT  is set as 1 after collecting information of all downstream links. 
         [0274]    After a device collects all link information of downstream devices thereof, the management/processing unit judges whether the downstream LC and LD exceed limits, MCE and MDE in the R STAT  are set as MCE=0 and MDE=0 if the downstream LC and LD do not exceed limits, and encryption transmission is allowed to continue; otherwise the MCE and/or the MDE in the R STAT  are set as MCE=1 and/or MDE=1, and it is prohibited to continue transmission of digital contents to the downstream devices; and the value of LDF (LDF defines allowable device functions) of collected device capacity is judged. If any unallowed receiving device (determined by the LDF value) is found, it is prohibited to continue transmission of the digital contents to the downstream devices. The LDF is a function field of a linked device, and defined herein as 3 or more than 3 bytes, each bit defines a function of the device, and 3 bytes have 24 functions. In terms of the copy control information (CCI defines device functions allowed or not) of the prior art, the DTCP can only process the CCI control stipulated specific to MPEG, with a maximum of 6 authorities. The solution defines 24 basic authorities, meanwhile, as the authorities are controlled by software, the authorities can be expanded as required. 
         [0275]    2.1 Information Transmission 
         [0276]    After the management/processing unit of transmitter starts the information collection, the value of the flag bit AICC in the register R STAT  of the management/processing unit in a directly linked downstream device is alternately inquired at a certain time interval. If AICC=1, the information transmission process is initiated. Suppose A is a management/processing unit of transmitter and B is a management/processing unit of receiver, and the A and the B implement the process as follows: 
         [0277]    a) Implementing, by the A, the following processes successively during the information transmission: 
         [0278]    a1) transmitting a message Mes 1 _INUdICCol to the B; 
         [0279]    Contents of a protocol message Mes 1 _INUdICCol are as follows:
       Message ID∥Rand_Source_Info∥P A          
 
         [0281]    Where, Rand_Source_Info is obtained by computing a random number generation algorithm Rand( ). 
         [0282]    a2) reading Mes 2 _INUdICCol; after the A transmits the message Mes 1 _INUdICCol, setting, by the A, a maximum wait time T_INUdICColDelay, and beginning timing, if the message Mes 2 _INUdICCol returned from the B is received within the T_INUdICColDelay, implementing the next step; otherwise implementing the step a4). 
         [0283]    a3) verifying an M_A hash value contained in the message Mes 2 _INUdICCol: if the verification passes, updating the locally stored LC and LD and capacity field LDF of the downstream devices, and setting the flag bit in the corresponding local R MU  as ICC=1; and implementing the step a4) if the verification fails. 
         [0284]    Computations to be carried out in the verification of the M_A hash value are as follows:
       a3-1) computing 256-bit key K_M_Info;
           Computing formula of the K_M_Info is as follow:   
               
 
         [0000]        K   —   M _Info= K   —   G ( K   —   M   MU , fixed string)       a3-2) computing M_A(K_M_Info∥Rand_Source_Info∥LC∥LD∥LDF) hash value.         
         [0288]    a4) if the frequency of continuous failures is less than the specified frequency, re-initiating the information collection between the A and the B, otherwise considering the implementation of information transmission between the A and the B to be failed, and setting the flag bit in the corresponding local R MU  as ICC=0. 
         [0289]    a5) Implementing, by the B, the following processes successively during the information transmission: 
         [0290]    a5-1) waiting, by the B, to read a message Mes 1 _INUdICCol, and implementing the next step after receiving the message Mes 1 _INUdICCol; and 
         [0291]    a5-2) transmitting the message Mes 2 _INUdICCol to the A. 
         [0292]    Contents of a protocol message Mes 2 _INUdICCol are as follows:
       Message ID∥LC∥LD∥LDF∥M_A(K_M_Info∥Rand_Source_Info∥LC∥LD∥LDF)       
 
         [0294]    3 Key Activation 
         [0295]    The key activation process is typical of the solution. Once encryption and decryption are not synchronous, reauthentication is required, consuming more time. In the solution, the key activation is separated. When keys are not synchronized and the encryption needs to be interrupted temporally or begins, the key activation is performed directly, and authentication is not needed, saving processing time and achieving better user experience. 
         [0296]    The key activation is performed by input and output interfaces. 
         [0297]    After successfully completing the interface authentication between interfaces (OAC=1 and OAS=1), a transmitting interface checks values of flag bits CER and KAS of a local interface state register R IN , and the key activation between corresponding receiving interfaces is initiated if CER=1 and KAS=0. For the key activation process, the master key K_M 2  established after the successful authentication between interfaces is used to generate an encryption key K_E. After the key activation, the K_E can be used as an initial value of a subsequent communication encryption key, and when a parity key is used, the K_E is taken as an initial value of an odd key or even key. 
         [0298]    Suppose an interface A is a key activation initiator, and an interface B is a key activation responder. The specific activation process is as follows: 
         [0299]    a) performing, by the initiator A, the following processes successively during the key activation process: 
         [0300]    a1) generating a random number Rand_Act_Source=Rand( ), and transmitting a message Mes 1 _INSiKAct to the B; 
         [0301]    Contents of a protocol message Mes 1 _INSiKAct are as follows:
       Message ID∥Rand_Act_Source       
 
         [0303]    a2) receiving a message Mes 2 _INSiKAct; after the A transmits the message Mes 1 _INSiKAct, setting a max wait time T_INSiKActDelay, and beginning timing, if the message Mes 2 _INSiKAct returned from the B is read within the time T_INSiKActDelay, implementing the next step; otherwise implementing step a7); 
         [0304]    a3) computing the master key K_E: according to the received message Mes 2 _INSiKAct, computing the K_E, and implementing the next step after the computation; and computing formula of the K_E is as follows: 
         [0000]        K   —   E=M   —   A ( K   —   M 2∥Rand_Act_Sink∥Rand_Act_Source)
 
         [0305]    where, K_M 2  is the master key generated after the authentication between interfaces, and kept by both authentication parties. 
         [0306]    a4) verifying an M_A hash value contained in the message Mes 2 _INSiKAct; recomputing the M_A(K_E∥Rand_Act_Sink) according to the content transmitted in the message Mes 2 _INSiKAc and the computed K_E, and comparing the read M_A hash value to the computed M_A hash value; if such two values are identical, implementing the next step; otherwise implementing the step a7). 
         [0307]    a5) transmitting a message MesS_INSiKAct_Succeed to a corresponding storage area of the B, and implementing the next step after completion; 
         [0308]    Contents of a protocol message MesS_INSiKAct_Succeed are as follows:
       Message ID|SUCCEED       
 
         [0310]    a6) keeping the K_E, setting a flag bit KAS of a state bit register R IN  of the interface A as 1, and completing the key activation protocol successfully; 
         [0311]    a7) if frequency of continuous key activation failures is less than a specified frequency, re-initiating the key activation process, or setting the flag bits of the state bit register R IN  of the interface as OAC=0, OAS=0 and KAS=0, terminating the key activation process and re-initiating the two-way authentication between the A and the interface B. 
         [0312]    b) Performing, by the responder B, the following processes successively during the key activation process: 
         [0313]    b1) receiving the message Mes 1 _INSiKAct, and then implementing the next step; 
         [0314]    b2) generating a new random number Rand_Act_Sink=Rand( ), computing a key K_E′, and implementing the next step after the computation; 
         [0315]    Computing formula of the K_E′ is as follows: 
         [0000]        K   —   E′=M   —   A ( K   —   M 2∥Rand_Act_Sink∥Rand_Act_Source)
 
         [0316]    Where, K_M 2  is the master key generated after the authentication between interfaces, and kept by both authentication parties; 
         [0317]    b3) transmitting the message Mes 2 _INSiKAct to a corresponding storage area of the A, and implementing the next step after completion; 
         [0318]    Contents of a protocol message Mes 2 _INSiKAct are as follows:
       Message ID∥Rand_Act_Sink∥M_A(K_E′∥Rand_Act_Sink)       
 
         [0320]    b4) setting, by the B, the max wait time T_INSiKActDelay, and beginning timing, if the message MesS_INSiKAct_Succeed is read within the time T_INSiKActDelay, implementing the next step; otherwise implementing the step b6); 
         [0321]    b5) keeping the K_E, setting the flag bit KAS of the state bit register R IN  of the interface B as 1, and completing the key activation protocol successfully; 
         [0322]    b6) if the frequency of the continuous key activation failures is less than the specified frequency, waiting the interface A to re-initiate the key activation process, or setting the flag bits of the state bit register R IN  of the local interface as OAC=0, OAS=0 and KAS=0, terminating the key activation process and waiting the interface A to reinitiate the authentication process. 
         [0323]    4 Security Transmission 
         [0324]    For authentication algorithm of the solution, security is several magnitudes higher than the HDCP, and has simpler development and significantly decreased chip size compared with the DTCP. For content encryption, the DTCP employs the block encryption algorithm which consumes great resources, and is applicable to the cases with high security requirements and low data throughput. In the solution, the block encryption and stream cipher are compatible, and different algorithms are employed for different cases, meeting different needs. 
         [0325]    After successful inter-interface key activation of both transmission parties (KAS=1), an encryption module is initiated for encryption transmission of digital contents. The K_E generated by the key activation is used as an initial value of the encryption key. 
         [0326]    When the interfaces of both transmission parties detect local ISI 0 , ISI 1  and ISI 2  are 0 simultaneously, the security transmission is implemented according to an agreed encryption algorithm. 
         [0327]    During the security transmission, the encryption key and an integrity key are employed to complete the secrecy transmission of the digital contents requiring protection, and complete transmission of protective flags and control information related to the digital contents. Meanwhile, the encryption key and the integrity key are regularly updated simultaneously. 
         [0328]    Usually two keys are used for the encryption, that is, an odd key and an even key. When the odd key is in use, the even key is updated; and when the even key is in use, the odd key is updated. The time shifting of the key is performed at a certain time interval. 
         [0329]    The block encryption algorithm and the stream cipher algorithm used herein are taken as examples below respectively to explain the security transmission process of the system. 
         [0330]    4.1 Block Encryption Algorithm 
         [0331]    4.1.1 Encryption 
         [0332]    Encryption process in which an interface of transmitter uses the block encryption algorithm is as follows: 
         [0333]    a) detecting several registers of ISI (Interface State Information), and only when the ISI0, the ISI1 and the ISI2 are 0, calling the following algorithm to complete data encryption processing: 
         [0000]      B_E(K_Ei,[IV],data) 
         [0334]    Description of parameters of the encryption algorithm: K_Ei: the encryption key, where i=[Key_Counter]lsb 0 ; IV: an initialization vector (optional); data: data to be encrypted; 
         [0335]    b) after completion of each encryption, setting, by the transmitting end interface, Cipher_Counter or Channel_Cipher_Counter as follows: 
         [0000]      Cipher_Counter=Cipher_Counter+Length(data) 
         [0000]      Channel_Cipher_Counter=Channel_Cipher_Counter+Length(data) 
         [0336]    c) after completing the setting, computing Key_Counter++ if the Cipher_Counter or the Channel_Cipher_Counter overflows; 
         [0337]    d) if the Cipher_Counter or Channel_Cipher_Counter are more than a specified value (e.g. 220), computing a backup key as follows: 
         [0000]        K   —   Ej=B   —   E ( K   —   M   lsb128˜255   ,K   —   E ∥Key_Counter)
 
         [0338]    Where j=[K_Counter]lsb 0 ⊕ 1 , with j as a bit variable of 1, ⊕ representing bit specific OR operation, and K_M lsb128˜255  representing low 128-255 bits of the K_M; 
         [0339]    e) if the value of Key_Counter is more than ReAuthenticationMaxTime, for unicast encryption, setting authentication state of the interface as no authentication; for broadcast encryption or network encryption, generating a broadcast key again to perform the key activation. 
         [0340]    4.1.2 Decryption 
         [0341]    Decryption process in which the receiving end interface uses the block decryption algorithm is as follows: 
         [0342]    a) detecting the ISI, and only when the ISI 0 , the ISI 1  and the ISI 2  are 0 simultaneously, calling the following algorithm to complete data decryption processing: 
         [0000]      B_D(K_Ei,[IV],data) 
         [0343]    Description of parameters of the decryption algorithm: K_Ei: a decryption key, where i=[Key_Counter]lsb 0 ; IV: an initialization vector (optional); data: data to be decrypted; 
         [0344]    b) after completion of each decryption, setting, by the interface of receiver, a cipher text counter Cipher_Counter or Channel_Cipher_Counter according to type of the source interface (4.1.1b)); 
         [0345]    c) after completing the setting, computing the Key_Counter++ if the Cipher_Counter or Channel_Cipher_Counter overflows; 
         [0346]    d) if the Cipher_Counter or Channel_Cipher_Counter is more than the specified value (e.g. 220), computing a backup key according to type of the transmitting end interface (4.1.1d)), and placing new backup keys K_E and K_MAC in a storage area with j=[K_Counter]lsb 0 ⊕ 1  as an index; 
         [0347]    e) if the value of the Key_Counter is more than ReAuthenticationMaxTime, processing according to (4.1.1e) of the transmitting interface; 
         [0348]    f) if the decryption fails, recording, by the counter D_W_Counter, the frequency of the failing decryptions, if the frequency is more than the D_W_Max, considering that an attack occurs to the current security transmission, or the keys of the both parties are unmatched, then performing the key activation process again. 
         [0349]    4.2 Stream Cipher Algorithm 
         [0350]    4.2.1 Encryption 
         [0351]    Encryption process in which the interface of transmitter uses the stream cipher algorithm is as follows: 
         [0352]    a) detecting the ISI, and only when the ISI 0 , the ISI 1  and the ISI 2  are 0 simultaneously, applying a key data recognition algorithm to generate key data location information of the frame data; 
         [0353]    b) applying the stream cipher algorithm to encrypt a frame data; 
         [0000]      S_E(K_E,[IV],Data) 
         [0354]    Description of parameters of the encryption algorithm: K_E: an encryption key; IV: an optional initialization vector; data: data to be encrypted. 
         [0355]    c) modifying the key data location information according to the stream cipher algorithm, and then extracting cipher text of each key location to form KDI_Record, if the KDI_Record is not null, setting a 1 bit integrity flag S_A=1, or setting S_A=0, 
         [0356]    d) computing the hash value: 
         [0000]      [M_A(K_MAC, S_A∥KDI_Record)] lsb0-127  
 
         [0357]    the [M_A(K_MAC, S_A∥KDI_Record)] lsb0-127  represents low 0-127 bits of the M_A; 
         [0358]    e) packaging the received bit hash value, and transmitting the value to the interface of receiver after connecting the value with the S_A in series in the data frame cipher text; 
         [0359]    f) after the transmission, processing the Cipher_Counter, the Channel_Cipher_Counter and the Key_Counter according to the processing mode of the encryption steps b)-e) in 4.1.1. 
         [0360]    4.2.2 Decryption 
         [0361]    Decryption process in which the interface of receiver uses the stream cipher algorithm is as follows: 
         [0362]    a) detecting the ISI, and only when the ISI 0 , the ISI 1  and the ISI 2  are 0 simultaneously, calling the following algorithm to complete the data decryption: 
         [0000]      S_D(K_E,[IV],Data) 
         [0363]    Description of parameters of the decryption algorithm: K_E: a decryption key; IV: an optional initialization vector; data: data to be decrypted; 
         [0364]    b) detecting the value of the S_A, if 
         [0365]    b1) S_A=1, applying the key data recognition algorithm to obtain key data location information, modifying the key data location information according to the stream cipher algorithm, and extracting the cipher text of the key location to form the KDI_Record; then computing the hash value according to the encryption process d) of the interface of transmitter in 4.2.1; 
         [0366]    b2) S_A=0, computing the hash value according to the encryption process d) of the interface of transmitter in 4.2.1; 
         [0367]    c) comparing the computed hash value with the received hash value; if such two values are identical, considering the decryption is a success, or considering the decryption is a failure; 
         [0368]    d) after the successful decryption, processing the Cipher_Counter, the Channel_Cipher_Counter and the Key_Counter according to the processing mode of the decryption steps b)-e) in 4.1.2; 
         [0369]    e) after the failing decryption, processing the D_W_Counter according to the decryption process f) by the AES-CCM algorithm in 4.1.2. 
         [0370]    Usually, the stream cipher algorithm is used for obtaining a high encryption processing speed, and is applicable for data frame transmission with strict synchronizing signals. Concurrent operation of the key data location recognition, the hash value computation and the encryption can be implemented in a hardware. Concurrent processing of the decryption operation, the key data location recognition and the hash value computation can be implemented by caching the cipher text with a certain length. 
         [0371]    4.3 Ciphertext package 
         [0372]    The cipher packaging format herein is as follows: 
         [0373]    System flag∥encryption flag∥[integrity flag]∥cipher text 
         [0374]    Where, the integrity flag is optional, and is essential when using the stream cipher algorithm in 4.1.2 and providing data integrity. 
         [0375]    For application to a specific interface, the packaging can be encoded again according to transmission bandwidth of the interface, and then the packaging mode is capable of presenting all information before encoding. 
         [0376]    4.4 Stream Cipher Update 
         [0377]    During the data security transmission, the stream cipher must be updated in the transmitter and the receiver in real-time to ensure randomness of output key flow. 
         [0378]    Firstly, the value of the K_E is used as an odd key or even key, and then at a certain agreed moment (e.g. the beginning of a vertical blanking interval), a number is used in both the transmitter and the receiving receiver to update another key which serves as the encryption and decryption key in the next time period. After the decryption key is used for a certain time period, the transmitter and the receiver simultaneously use another key for encryption and decryption, and update the key again at the same time, and this is repeated again and again. 
         [0379]    5 System Integrity 
         [0380]    An integrated security system ensures all devices and interfaces therein are legal. An issuing entity places public keys held by the illegal devices in a revocation list (the legality of the devices is identified by the legality of the public keys held by the management/processing unit in the devices), and places the public keys held by the illegal interfaces in the revocation list, and organizes to sign and issue the revocation list regularly. 
         [0381]    Herein, any device with the management/processing unit and can be accessed to the system must support the storing and updating functions of the revocation list. Each management/processing unit has an independent and large enough storage area for storing the revocation list, the update thereof is performed between the management/processing units of two devices linked directly, and the update process is initiated by the management/processing units of a pair of linked transmitter. 
         [0382]    5.1 Format and Verification of the Revocation List in the System 
         [0383]    The revocation list format specified for the system is as shown in Table 12, all data in the revocation list are stored in the format of Big-Endian, and format and discription of the revocation list are as shown in Table 4. 
         [0000]    
       
         
               
               
               
             
               
               
               
             
           
               
                 TABLE 4 
               
               
                   
               
               
                   
                 Data 
                   
               
               
                   
                 length 
               
               
                 Name 
                 (bit) 
                 Description 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 System 
                 8 
                 Identification of the message for the system 
               
               
                 identifier 
               
               
                 Type 
                 3 
                 Types of messages updated, now only the IUM of 
               
               
                   
                   
                 type 0 is defined, and other values are reserved 
               
               
                 Reserve 
                 5 
                 Bytes reserved, undefined and all set to 0 
               
               
                 Version 
                 16 
                 A successively increasing integer representing 
               
               
                 number 
                   
                 time sequence of issuing the revocation list, 
               
               
                   
                   
                 which is increased from 1 successively, so the 
               
               
                   
                   
                 later the issue time is, the larger the version 
               
               
                   
                   
                 number is 
               
               
                 Issuer ID 
                 24 
                 ID of issuer of the revocation list 
               
               
                 Revocation 
                 32 
                 An integer representing the whole revocation 
               
               
                 list length 
                   
                 list length, in byte 
               
               
                 Public key 
                 Vari- 
                 One or more revocation records, with each 
               
               
                 revocation 
                 able 
                 revocation record format shown in Table 5 
               
               
                 record list 
               
               
                 Signature 
                 384 
                 The valid signature of the revocation list 
               
               
                   
                   
                 issuer for all above the information 
               
               
                   
               
             
          
         
       
     
         [0384]    The public key revocation record list includes one or more revocation records with variable length. The format and implication of the revocation list are as shown in Table 5: 
         [0000]    
       
         
               
               
               
               
             
           
               
                 TABLE 5 
               
               
                   
               
               
                 Public 
                   
                   
                   
               
               
                 key 
               
               
                 revocation 
               
               
                 record 
               
               
                 type 
                 Revocation 
                 Actually revoked 
               
               
                 (PRRT) 
                 record format 
                 public key 
                 Remarks 
               
               
                   
               
             
             
               
                 0x00 
                 0x00∥revoked 
                 Public key of an 
                 The revoked 
               
               
                   
                 public key 
                 individual 
                 public key 
               
               
                   
                   
                 device/interface with 
                 is 128 bits. 
               
               
                   
                   
                 the public key as the 
               
               
                   
                   
                 “revoked public key” 
               
               
                 0x01 
                 0x01∥revoked 
                 All public keys 
                 One record can 
               
               
                   
                 public key 
                 corresponding to all 
                 revoke all 
               
               
                   
                 batch No. or 
                 public keys with batch 
                 public keys in 
               
               
                   
                 manufacturer 
                 No. or “manufacturer 
                 one batch of 
               
               
                   
                 ID. 
                 ID” as the “revoked 
                 a manufacturer 
               
               
                   
                   
                 public key” 
               
               
                 0x02 
                 0x02∥revoked 
                 All public keys with the 
                 One record can 
               
               
                   
                 public key 
                 public keys in the 
                 revoke all public 
               
               
                   
                 start No., 
                 interval [revoked public 
                 keys in one area 
               
               
                   
                 revoked public 
                 key start No., revoked 
               
               
                   
                 key end No. 
                 public key end No.] 
               
               
                 Other 
                 PRRT∥ 
                 Undefined, reserved 
                 All revoked 
               
               
                 types 
                 revoked 
                   
                 contents are 
               
               
                   
                 content 
                   
                 set to zero 
               
               
                   
               
             
          
         
       
     
         [0385]    In which the length of the “public key revocation record type” is 8 bits. The public key revocation record types in the system are the 0x00, the 0x01 and the 0x02, corresponding to revocation of an individual public key, revocation of a batch of public keys and revocation of a segmental public keys respectively, and the formats of other types are not defined temporarily. For revocation of public keys of a batch or of a manufacturer, nonzero location of the public keys are employed for implementation. For revocation of the specific public keys, values of the public keys are employed. The revocation of the public keys of a batch or a manufacturer using nonzero locations of the public keys is: suppose the revocation list type is the 0x01, and one revocation batch No. therein is 0130201020 (suppose the public key length is 10 digits herein), all public keys characterized by the 0XX0X0X0X0 are revoked (herein X represents an arbitrary value). 
         [0386]    In the system, before storage and update of any revocation list, the validity of the revocation list is verified firstly. For any revocation list during transmission, a CA public key certificate of the revocation list must be carried. The CA public certificate can be a root certificate, or a public key certificate held by one corresponding authorized second CA. 
         [0387]    5.2 Two-Way Update of Revocation List 
         [0388]    After completion of all inter-authentications of the device (AIAC=1, AIAS=1), the management/processing unit of transmitter checks the value of the flag bit AIUC of the R STAT . If AIUC=0, the management/processing unit of transmitter checks the values of flag bits OAC, OAS of R IN  in each activated transmitting interface and the value of IUC of the corresponding R MU . If OAC=1, OAS=1 and IUC=0, the management/processing unit of transmitter initiates the revocation list update process between the management/processing unit of transmitter and the management/processing unit of receiver in the link corresponding to the transmitter. When the revocation list update process is completed successfully in all activated transmitting end links, the flag bit AIUC of the R STAT  as AIUC=1, and the update process of the IUM (revocation list) of the device is completed. 
         [0389]    A revocation list update protocol for two-way communication is employed for the revocation list update process between the management/processing units. During the specific process, suppose A is the management/processing unit of transmitter, and B is the management/processing unit of receiver. 
         [0390]    Both the A and the B use the master key K_M MU  generated after the authentication to compute the common revocation list transmission authentication key K_IUM (256 bits) as follows: 
         [0000]        K   —   IUM=K   —   G ( K   —   M   MU ,“Key for  DICP -IN- IUM -Update-Message”)
 
         [0391]    Where, the parameter “Key for DICP-IN-IUM-Update-Message” in the K_IUM computation is a fixed character string constants, or can be instead of other fixed strings. 
         [0392]    The A and the B set continuous update failures counter in the local storage area for counting frequency of the failing revocation list update, and a initialized value is 0. The implementation process of the two-way IUM update specified herein is as follows: 
         [0393]    a) performing, by the initiator A, the following processes successively during the two-way revocation list update process: 
         [0394]    a1) transmitting a message Mes 1 _INBiIUMUp to the B, and then implementing the next step; 
         [0395]    Contents of a protocol message Mes 1 _INBiIUMUp are as follows:
       Message ID∥Version_IUM A ∥RA_IUM∥AUA|       
 
         [0397]    Description of contents of the protocol message: Version_IUM A : IUM A  version number stored in the A; RA_IUM: a random number, output by Rand(128); AUA 1 : a message authentication code.
       AUA 1 =M_A(K_IUM∥(Version_IUM A ∥RA_IUM))       
 
         [0399]    a2) waiting a response message (MesD_INBiIUMUp_Fail, Mes 2 _INBiIUMUp or MesD_INBiIUMUp_Request) returned from the B; setting, by the A, a max wait time T_INBiIUMUpDelay, and beginning timing: 
         [0400]    if the message MesD_INBiIUMUp_Request returned from the B is read within the time T_INBiIUMUpDelay, implementing the next step; 
         [0401]    if the message Mes 2 _INBiIUMUp returned from the B is read within the time T_INBiIUMUpDelay, implementing step a5); 
         [0402]    if the message MesD_INBiIUMUp_Fail returned from the B is read within or T_INBiIUMUpDelay over the time, implementing step a9); 
         [0403]    a3) transmitting a message Mes 3 _INBiIUMUp to a corresponding storage area of the B, and then implementing the next step; 
         [0404]    Contents of a protocol message Mes 3 _INBiIUMUp are as follows:
       Message ID∥IUM A ∥Cert_IUM A     —   Adm∥RA_IUM∥AUA 3         
 
         [0406]    Description of contents of the protocol message: IUM A : IUM version stored in the A with variable length; Cert_IUM A     —   Adm: a CA certificate issuing the IUM A ; RA_IUM: a random number, output by Rand(128); AUA 3 : a message authentication code; 
         [0407]    a4) waiting to receive a verification success message MesD_INBiIUMUp_Succeed returned from the B; setting, by the A, a max wait time T_INBiIUMUpDelay, and beginning timing, if the message MesD_INBiIUMUp_Succeed is received within the time T_INBiIUMUpDelay, implementing step a8), otherwise, implementing the step a9); 
         [0408]    a5) verifying signatures of message authentication codes AUA 2  and IUM B  in the message Mes 2 _INBiIUMUp; if both verifications {circle around (1)} and {circle around (2)} pass, implementing the next step; otherwise implementing the step a9); 
         [0409]    The verification processes {circle around (1)} and {circle around (2)} are as follows: 
         [0410]    Implementing the verification {circle around (1)}: verifying whether the relation 
         [0000]        AUA 2== M   —   A ( K   —   IUM ∥( IUM   B ∥Cert —   IUM   B     —   Adm∥ RB   —   IUM )) is valid;
 
         [0411]    implementing the verification {circle around (2)}: calling a revocation list verification module to verify validity of the newly received signature in the revocation list of the device B; 
         [0412]    a6) replacing the original IUM A ∥Cert_IUM A     —   Adm with the IUM B ∥Cert_IUM B     —   Adm, and implementing the next step after the replacement; 
         [0413]    a7) transmitting a message MesS_INBiIUMUp_Succeed to the B, and then implementing the step a8); 
         [0414]    Contents of a protocol message contained in the message MesS_INBiIUMUp_Succeed are as follows:
       Message ID∥SUCCEED       
 
         [0416]    a8) setting the flag bits in a corresponding state register R MU  in the A as IUC=1 and IUS=1, and implementing the corresponding link revocation list update protocol successfully; 
         [0417]    a9) checking whether frequency of the continuous local update failures is less than a specified frequency: adding 1 to the frequency of update failures, and re-initiating the IUM update process with the B if the frequency of the continuous local update failures is less than the specified frequency; otherwise setting flag bits in a corresponding state register R IN  in the A as IUC=1 and IUS=0, and failing to implement the corresponding link IUM update protocol. 
         [0418]    b) Performing, by the responder B, the following processes successively during the two-way IUM update process: 
         [0419]    b1) Reading the Mes 1 _INBiIUMUp, and then successively implementing the next step; 
         [0420]    b2) verifying whether the message authorization code AUA 1  in the massage Mes 1 _INBiIUMUp is correct; re-computing the M_A hash value according to the contents of the message Mes 1 _INBiIUMUp, and comparing the computation result with the read AUA 1 : if the verification passes, implementing the next step; otherwise implementing step b12). 
         [0421]    b3) comparing version number of the IUM A  with that of the IUM B : if the version number of the IUM A  is greater, implementing the next step, otherwise implementing step b9); 
         [0422]    b4) transmitting the message MesD_INBiIUMUp_Request to a corresponding storage area of the A, and then implementing the next step; 
         [0423]    Contents of a protocol message MesD_INBiIUMUp_Request are as follows:
       Message ID∥REQUEST       
 
         [0425]    Where, the value of a defined request flag REQUEST in the system is 1, with the length of 1 bit. 
         [0426]    b5) waiting to read the message Mes 3 _INBiIUMUp returned from the A; setting, by the B, the maximum wait time T, and beginning timing, if the message Mes 3 _INBiIUMUp returned by the A is read within the time T_INBiIUMUpDelay, performing the next step; otherwise performing step b13); 
         [0427]    b6) verifying signatures of the message authentication codes AUA 3  and IUM A  in the message Mes 3 _INBiIUMUp; if both verifications {circle around (3)} and {circle around (4)} pass, implementing the next step; otherwise implementing the step b13); 
         [0428]    The verification processes {circle around (3)} and {circle around (4)} are as follows: 
         [0429]    implementing the verification {circle around (3)}: verifying whether the relation 
         [0000]        AUA 3== M   —   A ( K   —   IUM∥IUM   A ∥Cert —   IUM   A     —   Adm∥ RA   —   IUM ) is valid;
 
         [0430]    implementing the verification {circle around (4)}: calling the revocation list verification module to verify validity of the newly received signature in the revocation list of the device A. 
         [0431]    b7) replacing the original IUM B ∥Cert_IUM B     —   Adm with the IUM A ∥Cert_IUM A     —   Adm, and implementing the next step after the replacement; 
         [0432]    b8) transmitting the message MesD_INBiIUMUp_Succeed to the A, and then implementing step b11); 
         [0433]    Contents of a protocol message MesD_INBiIUMUp_Succeed are as follows:
       Message ID∥SUCCEED       
 
         [0435]    b9) transmitting the message Mes 2 _INBiIUMUp to the A, and then implementing the next step; 
         [0436]    Contents of a protocol message Mes 2 _INBiIUMUp are as follows:
       Message ID∥IUM B ∥Cert_IUM B     —   Adm∥RB_IUM∥AUA 2         
 
         [0438]    Description of contents of the protocol message: IUM B : IUM version stored in the B; Cert_IUM B     —   Adm: a CA certificate issuing the IUM B ; RB_IUM: a random number, output by Rand(128); AUA 2 : a message authentication code;
       AUA 2 =M_A(K_IUM∥IUMB∥Cert_IUMB_Adm∥RB_IUM)       
 
         [0440]    b10) waiting to read the verification success message MesS_INBiIUMUp_Succeed returned by the A; setting, by the B, the max wait time T_INBiIUMUpDelay, and beginning timing, if the message MesS_INBiIUMUp_Succeed is read within the time T_INBiIUMUpDelay, implementing the next step; otherwise implementing the step 13); 
         [0441]    b11) setting the flag bits IUC and IUS in a corresponding state register R MU  in the B as 1, and implementing the corresponding link IUM update protocol successfully; 
         [0442]    b12) transmitting the message MesD_INBiIUMUp_Fail to the corresponding storage area of the A, and then implementing the next step; 
         [0443]    Contents of a protocol message MesD_INBiIUMUp_Fail are as follows:
       Message ID∥FAIL       
 
         [0445]    checking whether frequency of continuous local update failures is less than a specified frequency: adding 1 to the frequency of the update failures, and waiting the A to re-initiate the IUM update process, if the frequency of the continuous local update failures is less than the specified frequency; otherwise setting flag bits in a corresponding state register R IN  of the B as IUC=1 and IUS=0, and implementing the corresponding link IUM update protocol unsuccessfully. 
         [0446]    The invention provides a content security transmission system, a device and a content security transmission method based on the system, which can implement the digital content security transmission between digital interfaces of home network and home terminal devices. In the case of transmission by the digital interface, the system can make full use of the characteristics of the terminal device digital interface chip and device master chip (or other special chips) to implement of the content transmission protection, decreasing the terminal cost effectively, and reducing the size of chip interfaces. The invention is suitable for content protection in high-speed digital interfaces, content protection in home network, other cases for content protection, and especially for chip development and software implementation.