Content transmission protection method and related equipment thereof

Abstract

The invention discloses a content transmission protection method and related equipment thereof, which can avoid audio and video stream leakage when a sending end and a receiving end are authenticated. The method comprises the following steps: in the process of establishing a transmission link between a sending end and a receiving end, the sending end and the receiving end exchange an authentication key to obtain an authentication key; the sending end carries out session key negotiation on the receiving end based on the authentication key to obtain a session key; after the transmission link between the sending end and the receiving end is established, the sending end performs authorization control on the receiving end; and after the sending end completes authorization control on the receiving end, the sending end sends the encrypted audio and video stream to the receiving end, and the encrypted audio and video stream is encrypted based on the session key.

Description

[0001] This application is a divisional application. The original application has the application number 202080104985.6 and the original application date is September 16, 2020. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This application relates to the field of multimedia technology, and in particular to a method and related equipment for content transmission protection. Background Technology

[0003] With the development of high-definition television (HDTV), lossless transmission of audio and video signals can be achieved through High Definition Multimedia Interface (HDMI) technology to accommodate its high bandwidth. To prevent audio and video signal leakage during HDMI transmission, High-bandwidth Digital Content Protection (HDCP) technology can be used to limit this leakage, thus ensuring that the audio and video signals transmitted via HDMI are not illegally copied.

[0004] Currently, most high-definition digital devices (such as high-definition digital TVs, set-top boxes, DVD players, Blu-ray players, personal computers, or game consoles) have HDMI ports and support HDCP. When two devices (including the sender and receiver) need to transmit audio and video streams via HDMI, HDCP certification is required. Specifically, after the two devices are connected, the sender can begin sending encrypted audio and video streams to the receiver. During the transmission of the audio and video streams, both the sender and receiver can simultaneously perform HDCP certification based on the information from the audio and video streams.

[0005] However, during the HDCP certification process, the transmission of audio and video streams may lead to audio and video stream leakage. Summary of the Invention

[0006] This application provides a method and related equipment for content transmission protection, which can prevent audio and video stream leakage during authentication between the sending end and the receiving end.

[0007] A first aspect of this application provides a method for content transmission protection, the method comprising:

[0008] During the establishment of the transmission link between the sending and receiving ends, the sending and receiving ends exchange authentication keys to obtain an authentication key; based on the authentication key, the sending end negotiates a session key with the receiving end to obtain a session key; after the transmission link between the sending and receiving ends is established, the sending end performs authorization control on the receiving end; after the sending end completes the authorization control on the receiving end, the sending end sends an encrypted audio and video stream to the receiving end, and the encrypted audio and video stream is encrypted based on the session key.

[0009] As can be seen from the above method, the authentication key exchange process and session key negotiation process between the sending and receiving ends are implemented during the establishment of the transmission link between them, while the authorization control process and audio / video stream transmission process are implemented after the transmission link between them is established. Therefore, in this application, the authentication process and the audio / video stream transmission process between the sending and receiving ends can be implemented at different time periods, and are two independent processes. Thus, the authentication process between the sending and receiving ends is not accompanied by the transmission of audio / video streams, which can avoid audio / video stream leakage.

[0010] In one possible implementation, the sender and receiver exchange authentication keys. Obtaining the authentication key involves: the sender sending a first message to the receiver, which requests authentication; and the sender receiving a second message from the receiver, which includes a signature and a hash-based message authentication code calculated by the receiver. The signature (code, HMAC) is used to indicate the identity of the receiving end; the sending end calculates the authentication key and the authentication HMAC based on the authentication key calculated by the sending end; if the sending end determines that the authentication HMAC calculated by the sending end is equal to the authentication HMAC calculated by the receiving end, it verifies the signature; if the sending end successfully verifies the signature, it calculates the authentication key authentication code based on the authentication key calculated by the sending end; the sending end sends a third message to the receiving end, since the third message includes the authentication key authentication code calculated by the sending end; after receiving the third message, the receiving end can calculate the authentication key authentication code, thereby determining whether the authentication key authentication code calculated by the sending end is equal to the authentication key authentication code calculated by the receiving end. If they are equal, the receiving end can determine that the authentication is successful. After that, the receiving end can send a fourth message to the sending end or not send a message. The fourth message is used to indicate that the authentication is successful; after receiving the fourth message, the sending end can determine that the authentication is successful and cache the authentication key calculated by the sending end, or, if the sending end does not receive any message within a preset time, it defaults to successful authentication and caches the authentication key calculated by the sending end.

[0011] As can be seen from the above implementation, when the sending and receiving ends authenticate, they can complete the authentication by comparing whether their calculated authentication HMAC and authentication key codes are equal. Since the authentication process considers authentication parameters such as authentication HMAC and authentication key codes, the reliability of the authentication can be improved.

[0012] In one possible implementation, the first message includes a list of version numbers, and the second message also includes the version number of the receiving end and the update time of the revocation list of the receiving end. The version number of the receiving end is located in the version number list. Calculating the authentication HMAC based on the authentication key calculated by the sending end includes: calculating the authentication HMAC based on the version number of the receiving end, the update time of the revocation list of the receiving end, and the authentication key calculated by the sending end; calculating the authentication key authentication code based on the authentication key calculated by the sending end includes: calculating the authentication key authentication code based on the version number of the receiving end and the authentication key calculated by the sending end.

[0013] As can be seen from the above implementation, in the HDCP architecture, when the sender and receiver authenticate, they need to collect relevant information from other devices along the entire content transmission link to complete the authentication. However, in this application, when the sender and receiver authenticate, the authentication HMAC can be calculated based on the receiver's version number, the update time of the receiver's revocation list, and the authentication key, and the authentication key code can be calculated based on the receiver's version number and the authentication key. Therefore, the information required to calculate the authentication HMAC and the authentication key code is only the information of the sender and receiver devices themselves, without needing to obtain information from other devices along the entire content transmission link, thus enabling independent authentication.

[0014] In one possible implementation, after the authentication key exchange between the sender and the receiver is successful, the method further includes: when the sender determines that the update time of the sender's revocation list is different from the update time of the receiver's revocation list, the sender sends a revocation list update message to the receiver, the revocation list update message including the sender's revocation list.

[0015] As can be seen from the above implementation, after the sender and receiver complete authentication, if the sender determines that the update time of the sender's revocation list is different from that of the receiver's revocation list, it sends a revocation list update message including the sender's revocation list to the receiver. This allows the receiver to replace the locally stored revocation list with the sender's revocation list, thereby completing the revocation list update. This ensures that the revocation lists of all devices at all levels of the content transmission link are in the same version, improving the trustworthiness of the transmission link.

[0016] In one possible implementation, the first message further includes: a current session identifier, a sender identifier, a public key list, and a fast authentication identifier, which instructs the receiver to enter either a fast authentication process or a normal authentication process. For example, the format of the first message is as follows:

[0017]

[0018] In one possible implementation, the second message further includes: the current session identifier, the receiver's public key, the receiver's certificate authority (CA) certificate, and the receiver's device certificate. For example, the format of the second message is as follows:

[0019]

[0020] In one possible implementation, the session key includes a content encryption odd key and a content encryption even key, wherein the content encryption odd key or the content encryption even key is used to encrypt the audio and video streams.

[0021] In one possible implementation, the sending end performs authorization control on the receiving end by: the sending end obtaining authorization control information corresponding to the audio and video streams; and the sending end performing authorization control on the receiving end on a per-audio-video-stream basis based on the authorization control information corresponding to the audio and video streams. The authorization control information includes security level, copying restrictions, retention time, maximum cascading depth, and the maximum number of connected devices supported by each level of device.

[0022] As can be seen from the above implementation, when the sending end needs to send different audio and video streams to the receiving end, it can complete the authorization control of each audio and video stream to the receiving end one by one. Therefore, even if the receiving end fails to pass the authorization control of a certain audio and video stream, it will not affect the transmission of the other audio and video streams that have completed the authorization control, thereby improving the fault tolerance of the solution.

[0023] In one possible implementation, the session key also includes an authorization information HMAC key. After the sending end performs authorization control on the audio and video streams to the receiving end, the method further includes: the sending end generating a tenth message based on the authorization information HMAC key; the sending end sending the tenth message to the receiving end, the tenth message including the identifier of the audio and video stream transmission channel corresponding to the audio and video stream and the authorization control information corresponding to the audio and video stream. The identifier of the audio and video stream transmission channel is used to indicate the audio and video stream transmission channel corresponding to the audio and video stream. The tenth message is used to instruct the receiving end to perform authorization control on the next-level device of the receiving end based on the audio and video stream transmission channel corresponding to the audio and video stream and the authorization control information corresponding to the audio and video stream. For example, the tenth message is as follows:

[0024]

[0025] As can be seen from the above implementation, after receiving the tenth message from the sending end, the receiving end can determine the audio / video stream transmission channel corresponding to the audio / video stream based on the identifier of the audio / video stream transmission channel in the tenth message. Based on the corresponding audio / video stream transmission channel and the authorization control information, the receiving end can perform authorization control on the next-level device of the audio / video stream. After completing the authorization control, the receiving end can transmit the audio / video stream to the next-level device. This is equivalent to the sending end transmitting the audio / video stream to the next-level device of the receiving end through the receiving end, thereby ensuring the transmission of audio and video throughout the entire content transmission link.

[0026] In one possible implementation, the sending end sends encrypted audio and video streams to the receiving end, which includes: the sending end sending encrypted data to the receiving end, the encrypted data including an encrypted header and at least one encrypted audio and video stream, and the at least one encrypted audio and video stream is set on a per-audio and video stream transmission channel basis, the encrypted header including the version of the encrypted header, encryption method indicator value, encryption algorithm indicator value, encryption mode, reserved fields and counter.

[0027] As can be seen from the above implementation, the encrypted data sent from the sending end to the receiving end includes an encrypted header and at least one encrypted audio / video stream. The receiving end can determine the encryption information of the audio stream based on the encrypted header. Since the at least one encrypted audio / video stream is set on a per-audio / video stream transmission channel basis, the encryption process considers more dimensions of encryption information, such as the audio / video stream transmission channel, thereby improving the security of content transmission.

[0028] In one possible implementation, the sender and receiver exchange authentication keys to obtain the authentication key, which includes: the sender sending a first message to the receiver, the first message including the current session identifier, the sender's identifier, a version number list, a public key list, and a fast authentication identifier; the sender receiving a second message from the receiver, the second message including the current session identifier, the receiver's version number, the update time of the receiver's revocation list, the receiver's public key, a signature, and the authentication HMAC calculated by the receiver, the receiver's version number being located in the version number list; the sender calculating the authentication key based on the sender's private key and the receiver's public key, and based on the receiver's public key, the sender's public key, and the sender's identifier... The sender calculates the authentication HMAC based on the sender's identifier, receiver version number, current session identifier, update time of the receiver's revocation list, and authentication key. The sender's public key is determined based on the public key list. If the sender determines that the authentication HMAC calculated by the sender is equal to the authentication HMAC calculated by the receiver, it verifies the signature. If the sender successfully verifies the signature, it calculates the authentication key / authentication code based on the sender's identifier, receiver version number, current session identifier, and authentication key calculated by the sender. The sender sends a third message to the receiver, which includes the current session identifier and the authentication key / authentication code calculated by the sender. The sender caches the current session identifier and the authentication key calculated by the sender.

[0029] In one possible implementation, before the sender calculates the authentication key based on its private key and the receiver's public key, the method further includes: the sender verifying the receiver's device CA certificate and device certificate based on a pre-set root CA certificate to obtain the identifier of the receiver's device certificate; if the sender successfully verifies the receiver's device CA certificate and device certificate, it checks whether the identifier of the receiver's device certificate is in the revocation list; the sender calculating the authentication key based on its private key and the receiver's public key includes: if the sender determines that the identifier of the receiver's device certificate is in the revocation list, the sender calculates the authentication key based on its private key and the receiver's public key.

[0030] In one possible implementation, the method further includes: the sender caching the receiver's version, the receiver's CA certificate, the receiver's device certificate, and the identifier of the receiver's device certificate.

[0031] In one possible implementation, signature verification includes: verifying the signature based on the public key corresponding to the receiving device certificate.

[0032] In one possible implementation, after the sender sends the first message to the receiver, the method further includes: the sender receiving a fifth message from itself, the fifth message including the current session identifier, the receiver's version number, the receiver's device CA certificate, the receiver's device certificate, and a fast authentication HMAC calculated by the receiver; if the sender determines that it has cached the receiver's device CA certificate and the receiver's device certificate, it checks whether the identifier of the receiver's device certificate is in the revocation list; if the sender determines whether the identifier of the receiver's device certificate is in the revocation list, it calculates the fast authentication HMAC based on the sender's identifier, the receiver's version number, the current session identifier, the receiver's device certificate, and the cached authentication key; if the sender determines that the fast authentication HMAC calculated by the sender is equal to the fast authentication HMAC calculated by the receiver, it determines that the receiver's authentication status is successful.

[0033] In one possible implementation, after the sender caches the current session identifier, the authentication key calculated by the sender, or after the sender determines that the authentication status of the receiver is successful, the method further includes: the sender randomly generating a content encryption odd key, a content encryption even key, an authorization information HMAC key, and initialization variables; the sender calculating a first authentication code based on the current session identifier, the content encryption odd key, the content encryption even key, the authorization information HMAC key, the initialization variables, and the HMAC key, wherein the HMAC key is generated based on the cached authentication key; and the sender calculating the first authentication code based on the current session identifier, the content encryption odd key, the content encryption even key, the authorization information HMAC key, the initialization variables, and the first authentication key calculated by the sender. The sender calculates the session key ciphertext using the encryption key and the cached authentication key. The encryption key is generated based on the cached authentication key. The sender sends a seventh message to the receiver, which includes the current session identifier, initialization variables, and the session key ciphertext. The sender receives an eighth message from the receiver, which includes the current session identifier and the second authentication code calculated by the receiver. The sender calculates the second authentication code based on the current session identifier, the content encryption odd key, the content encryption even key, the authorization information HMAC key, and the HMAC key. If the sender determines that the second authentication code calculated by the sender is equal to the second authentication code calculated by the receiver, the content encryption odd key, the content encryption even key, and the authorization information HMAC key are determined as the session key.

[0034] In one possible implementation, after the sending end determines the content encryption odd key, the content encryption even key, and the authorization information HMAC key as the session key, the method further includes: if the sending end has authorized the receiving end for the target audio / video stream, then a third authentication code is calculated based on the current session identifier, the audio / video stream transmission channel corresponding to the target audio / video stream, the authorization control information, the current concatenation depth, the sequence number of the current request, and the cached authorization information HMAC key; the sending end sends a tenth message to the receiving end, the tenth message including the current session identifier, the audio / video stream transmission channel corresponding to the target audio / video stream, and the authorization control information. The sender receives the eleventh message from the receiver, which includes the current session identifier and the fourth authentication code calculated by the receiver. The sender calculates the fourth authentication code based on the current session identifier, the audio / video stream transmission channel corresponding to the target audio / video stream, authorization control information, the current concatenation depth, the current request sequence number incremented by one, and the cached authorization information HMAC key. If the sender determines that the fourth authentication code calculated by the sender and the fourth authentication code calculated by the receiver are the same, it caches the current session identifier and the current request sequence number.

[0035] In one possible implementation, after the sending end determines the content encryption odd key, the content encryption even key, and the authorization information HMAC key as the session key, the method further includes: if the sending end completes the authorization of the target audio and video stream to the receiving end, then sending an encrypted data frame to the receiving end, wherein the encrypted data frame includes the target audio and video stream encrypted based on the content encryption odd key or the content encryption even key.

[0036] In one possible implementation, the method further includes: the sender sending a thirteenth message to the receiver, the thirteenth message including the sender's revocation list; the sender receiving a fourteenth message from the receiver, the fourteenth message indicating that the receiver's revocation list has been successfully updated.

[0037] A second aspect of this application provides a method for content transmission protection, the method comprising: during the establishment of a transmission link between a sending end and a receiving end, the receiving end and the sending end exchange authentication keys to obtain an authentication key; the receiving end negotiates a session key with the sending end based on the authentication key to obtain a session key; after the transmission link between the sending end and the receiving end is established, the receiving end responds to the authorization control of the sending end; after the sending end completes the authorization control of the receiving end, the receiving end receives an encrypted audio and video stream from the sending end, the encrypted audio and video stream being encrypted based on the session key.

[0038] As can be seen from the above method, the authentication key exchange process and session key negotiation process between the sending and receiving ends are implemented during the establishment of the transmission link between them, while the authorization control process and audio / video stream transmission process are implemented after the transmission link between them is established. Therefore, in this application, the authentication process and the audio / video stream transmission process between the sending and receiving ends can be implemented at different time periods, and are two independent processes. Thus, the authentication process between the sending and receiving ends is not accompanied by the transmission of audio / video streams, which can avoid audio / video stream leakage.

[0039] In one possible implementation, the receiving end and the sending end exchange authentication keys to obtain the authentication key, which includes: the receiving end receiving a first message from the sending end, the first message being used to request authentication; the receiving end calculating a signature and an authentication key, and calculating an authentication HMAC based on the authentication key calculated by the receiving end; the receiving end sending a second message to the sending end, the second message including a signature and the authentication HMAC calculated by the receiving end, the signature being used to indicate the identity of the receiving end; the receiving end receiving a third message from the sending end, the third message including an authentication key authentication code calculated by the sending end; the receiving end calculating an authentication key authentication code based on the authentication key calculated by the receiving end; if the receiving end determines that the authentication key authentication code calculated by the sending end and the authentication key authentication code calculated by the receiving end are equal, then the authentication key calculated by the receiving end is cached.

[0040] As can be seen from the above implementation, when the sending and receiving ends authenticate, they can complete the authentication by comparing whether their calculated authentication HMAC and authentication key codes are equal. Since the authentication process considers authentication parameters such as authentication HMAC and authentication key codes, the reliability of the authentication can be improved.

[0041] In one possible implementation, the first message includes a list of version numbers, and the signature calculation by the receiving end includes: if the receiving end determines that its version number is in the list of version numbers, then the signature is calculated based on the receiving end's version number and the update time of the receiving end's revocation list.

[0042] In one possible implementation, calculating the authentication HMAC based on the authentication key calculated by the receiver includes: calculating the authentication HMAC based on the receiver's version number, the update time of the receiver's revocation list, and the authentication key calculated by the receiver; calculating the authentication key authentication code based on the authentication key calculated by the receiver includes: calculating the authentication key authentication code based on the receiver's version number and the authentication key calculated by the receiver.

[0043] As can be seen from the above implementation, in the HDCP architecture, when the sender and receiver authenticate, they need to collect relevant information from other devices along the entire content transmission link to complete the authentication. However, in this application, when the sender and receiver authenticate, the authentication HMAC can be calculated based on the receiver's version number, the update time of the receiver's revocation list, and the authentication key, and the authentication key code can be calculated based on the receiver's version number and the authentication key. Therefore, the information required to calculate the authentication HMAC and the authentication key code is only the information of the sender and receiver devices themselves, without needing to obtain information from other devices along the entire content transmission link, thus enabling independent authentication.

[0044] In one possible implementation, after the authentication key exchange between the sender and receiver is successful, the method further includes: the receiver receiving a revocation list update message from the sender, the revocation list update message including the sender's revocation list; the receiver replacing its own revocation list with the sender's revocation list; and the receiver using the sender's revocation list to verify the certificate of the receiver's next-level device.

[0045] As can be seen from the above implementation, after the sender and receiver complete authentication, if the sender determines that the update time of the sender's revocation list is different from that of the receiver's revocation list, it sends a revocation list update message including the sender's revocation list to the receiver. This allows the receiver to replace the locally stored revocation list with the sender's revocation list, thereby completing the revocation list update. This ensures that the revocation lists of all devices at all levels of the content transmission link are in the same version, improving the trustworthiness of the transmission link.

[0046] In one possible implementation, the first message also includes: the current session identifier, the sender's identifier, a list of public keys, and a fast authentication identifier, which is used to instruct the receiver to enter the fast authentication process or the normal authentication process.

[0047] In one possible implementation, the second message also includes: the current session identifier, the receiver's public key, the receiver's device certification authority (CA) certificate, and the receiver's device certificate.

[0048] In one possible implementation, the session key includes a content encryption odd key and a content encryption even key, wherein the content encryption odd key or the content encryption even key is used to decrypt the encrypted audio and video streams.

[0049] In one possible implementation, the receiver's response to the sender's authorization control includes: the receiver responding to the sender with authorization control information based on the audio and video streams, and authorization control on a per-stream basis, including security level, copying restrictions, retention time, maximum cascading depth, and the maximum number of connected devices supported by each level of device.

[0050] As can be seen from the above implementation, when the sending end needs to send different audio and video streams to the receiving end, it can complete the authorization control of each audio and video stream to the receiving end one by one. Therefore, even if the receiving end fails to pass the authorization control of a certain audio and video stream, it will not affect the transmission of the other audio and video streams that have completed the authorization control, thereby improving the fault tolerance of the solution.

[0051] In one possible implementation, after the receiving end responds to the authorization control from the sending end, the method further includes: the receiving end receiving a tenth message from the sending end, the tenth message including the identifier of the audio / video stream transmission channel corresponding to the audio / video stream and the authorization control information corresponding to the audio / video stream, the identifier of the audio / video stream transmission channel being used to indicate the audio / video stream transmission channel corresponding to the audio / video stream; the receiving end performing authorization control on the next-level device of the receiving end on a per-audio / video stream basis, based on the audio / video stream transmission channel corresponding to the audio / video stream and the authorization control information corresponding to the audio / video stream.

[0052] As can be seen from the above implementation, after receiving the tenth message from the sending end, the receiving end can determine the audio / video stream transmission channel corresponding to the audio / video stream based on the identifier of the audio / video stream transmission channel in the tenth message. Based on the corresponding audio / video stream transmission channel and the authorization control information, the receiving end can perform authorization control on the next-level device of the audio / video stream. After completing the authorization control, the receiving end can transmit the audio / video stream to the next-level device. This is equivalent to the sending end transmitting the audio / video stream to the next-level device of the receiving end through the receiving end, thereby ensuring the transmission of audio and video throughout the entire content transmission link.

[0053] In one possible implementation, the receiving end receives the encrypted audio and video stream from the sending end, including:

[0054] The receiving end receives encrypted data from the sending end. The encrypted data includes an encrypted header and at least one encrypted audio / video stream. The encrypted audio / video stream is set on a per-audio / video stream transmission channel basis. The encrypted header includes the encryption header version, encryption method indicator value, encryption algorithm indicator value, encryption mode, reserved fields, and counter.

[0055] As can be seen from the above implementation, the encrypted data sent from the sending end to the receiving end includes an encrypted header and at least one encrypted audio / video stream. The receiving end can determine the encryption information of the audio stream based on the encrypted header. Since the at least one encrypted audio / video stream is set on a per-audio / video stream transmission channel basis, the encryption process considers more dimensions of encryption information, such as the audio / video stream transmission channel, thereby improving the security of content transmission.

[0056] In one possible implementation, the receiving end and the sending end exchange authentication keys to obtain the authentication key. This includes: the receiving end receiving a first message from the sending end, which includes the current session identifier, the sending end identifier, a version number list, a public key list, and a fast authentication identifier; if the receiving end determines that its version number is in the version number list, it checks whether the authentication key is cached based on the fast authentication identifier; if the receiving end determines that the authentication key is not cached, it calculates a signature and calculates the authentication key based on the receiving end's private key and the sending end's public key, where the sending end's public key is determined based on the version number list; the receiving end then calculates the authentication key based on its public key, the sending end's public key, the sending end identifier, the receiving end's version number, the current session identifier, the update time of the receiving end's revocation list, and the... The receiving end calculates the authentication key and the authentication HMAC; the receiving end sends a second message to the sending end, which includes the current session identifier, the receiving end's version number, the revocation list update time, the receiving end's public key, signature, and the authentication HMAC calculated by the receiving end; the receiving end receives a third message from the sending end, which includes the current session identifier and the authentication key and authentication code calculated by the sending end; the receiving end calculates the authentication key and authentication code based on the sending end's identifier, the receiving end's version number, the current session identifier, and the authentication key calculated by the receiving end; if the receiving end determines that the authentication key and authentication code calculated by the sending end and the authentication key and authentication code calculated by the receiving end are equal, then it caches the current session identifier, the authentication key calculated by the receiving end, the sending end's identifier, and the receiving end's version.

[0057] In one possible implementation, signature calculation includes: calculating the signature based on the receiver's public key, the sender's public key, the sender's identifier, the receiver's version number, the current session identifier, the update time of the receiver's revocation list, and the private key corresponding to the receiver's device certificate.

[0058] In one possible implementation, if the receiver determines that its version number is in the version number list, before detecting whether an authentication key is cached based on the fast authentication identifier, the method further includes: if the receiver determines that the cached session identifier is different from the current session identifier, then detecting whether the receiver's version number is in the version number list.

[0059] In one possible implementation, if the receiving end determines that its version number is in the version number list, after detecting whether an authentication key is cached based on the fast authentication identifier, the method further includes: if the receiving end determines that an authentication key is cached, calculating the fast authentication HMAC based on the sender's identifier, the receiving end's version number, the current session identifier, the receiving end's device certificate, and the cached authentication key; the receiving end sends a fifth message to the sender, the fifth message including the current session identifier, the receiving end's version number, the receiving end's device CA certificate, the receiving end's device certificate, and the fast authentication HMAC calculated by the receiving end.

[0060] In one possible implementation, after the receiving end caches the current session identifier, the authentication key calculated by the receiving end, the identifier of the sending end, and the version of the receiving end, or after the receiving end sends a fifth message to the sending end, the method further includes: the receiving end receiving a seventh message from the sending end, the seventh message including the current session identifier, initialization variables, and ciphertext of the session key; the receiving end decrypting the ciphertext of the session key based on the initialization variables and the encryption cipher to obtain a content encryption odd key, a content encryption even key, an authorization information HMAC key, and a first authentication code calculated by the sending end, the encryption cipher being generated based on the cached authentication key; the receiving end calculating the first authentication code based on the current session identifier, the content encryption odd key, the content encryption even key, the authorization information HMAC key, the initialization variables, and the HMAC key, the HMAC key being generated based on the cached authentication key; if the receiving end determines that the first authentication code calculated by the receiving end is equal to the first authentication code calculated by the sending end, then calculating a second authentication code based on the current session identifier, the content encryption odd key, the content encryption even key, the authorization information HMAC key, and the HMAC key; the receiving end sending an eighth message to the sending end, the eighth message including the current session identifier and the second authentication code calculated by the receiving end.

[0061] In one possible implementation, after the receiving end sends the eighth message to the sending end, the method further includes: the receiving end receiving a tenth message from the sending end, the tenth message including the current session identifier, the corresponding audio / video stream transmission channel of the target audio / video stream, authorization control information, the current concatenation depth, the sequence number of the current request, and the third authentication code calculated by the sending end; the receiving end calculating the third authentication code based on the current session identifier, the corresponding audio / video stream transmission channel of the target audio / video stream, authorization control information, the current concatenation depth, the sequence number of the current request, and the cached authorization information HMAC key; if the receiving end determines that the third authentication code calculated by the sending end is the same as the third authentication code calculated by the receiving end, then calculating the fourth authentication code based on the current session identifier, the corresponding audio / video stream transmission channel of the target audio / video stream, authorization control information, the current concatenation depth, the current request sequence number incremented by one, and the cached authorization information HMAC key; the receiving end sending an eleventh message to the sending end, the eleventh message including the current session identifier and the fourth authentication code calculated by the receiving end; and receiving the cached current session identifier, the corresponding audio / video stream transmission channel of the target audio / video stream, authorization control information, and the updated current concatenation depth.

[0062] In one possible implementation, after the receiving end sends the eighth message to the sending end, the method further includes: the receiving end receiving an encrypted data frame from the sending end, the encrypted data frame including a target audio and video stream encrypted based on a content encryption odd key or a content encryption even key.

[0063] In one possible implementation, the method further includes: the receiving end receiving a thirteenth message from the sending end, the thirteenth message including the sending end's revocation list; if the receiving end determines that the update time of the sending end's revocation list is greater than the update time of the receiving end's revocation list, then the receiving end replaces the receiving end's revocation list with the sending end's revocation list; the receiving end sending a fourteenth message to the sending end, the fourteenth message indicating that the receiving end's revocation list has been successfully updated.

[0064] A third aspect of this application provides a content transmission protection apparatus, comprising: an authentication module, configured to exchange authentication keys with the receiving end during the establishment of a transmission link between the sending end and the receiving end to obtain an authentication key; the authentication module is further configured to negotiate a session key with the receiving end based on the authentication key to obtain a session key; an authorization module, configured to perform authorization control on the receiving end after the transmission link between the sending end and the receiving end is established; and an encryption module, further configured to send an encrypted audio / video stream to the receiving end after the sending end completes the authorization control on the receiving end, wherein the encrypted audio / video stream is encrypted based on the session key.

[0065] In one possible implementation, the authentication module is specifically configured to: send a first message to the receiving end, the first message being used to request authentication; receive a second message from the receiving end, the second message including a signature and an authentication hash message authentication code (hmac) calculated by the receiving end, the signature being used to indicate the identity of the receiving end; calculate an authentication key, and calculate an authentication hmac based on the authentication key calculated by the sending end; if it is determined that the authentication hmac calculated by the sending end is equal to the authentication hmac calculated by the receiving end, then verify the signature; if the signature verification is successful, then calculate an authentication key authentication code based on the authentication key calculated by the sending end; and send a third message to the receiving end, the third message including the authentication key authentication code calculated by the sending end.

[0066] In one possible implementation, the first message includes a list of version numbers, and the second message includes the version number of the receiving end and the update time of the revocation list of the receiving end. The version number of the receiving end is located in the version number list. The authentication module is specifically used to: calculate the authentication HMAC based on the version number of the receiving end, the update time of the revocation list of the receiving end, and the authentication key calculated by the sending end; and calculate the authentication key authentication code based on the version number of the receiving end and the authentication key calculated by the sending end.

[0067] In one possible implementation, the authentication module is further configured to determine that the update time of the revocation list at the sending end is different from the update time of the revocation list at the receiving end, and send a revocation list update message to the receiving end, the revocation list update message including the revocation list of the sending end.

[0068] In one possible implementation, the authorization module is specifically used to: obtain authorization control information corresponding to the audio and video streams;

[0069] Based on the authorization control information corresponding to the audio and video streams, authorization control is performed on the receiving end on a per-stream basis. The authorization control information includes security level, copying restrictions, retention time, maximum cascading depth, and the maximum number of connected devices supported by each level of device.

[0070] In one possible implementation, the authorization module is further configured to send a tenth message to the receiving end. The tenth message includes an audio / video stream transmission channel identifier corresponding to the audio / video stream and authorization control information corresponding to the audio / video stream. The audio / video stream transmission channel identifier is used to indicate the audio / video stream transmission channel corresponding to the audio / video stream. The tenth message is used to instruct the receiving end to perform authorization control on the next-level device of the receiving end based on the audio / video stream transmission channel corresponding to the audio / video stream and the authorization control information corresponding to the audio / video stream.

[0071] In one possible implementation, the encryption module is specifically used to send encrypted data to the receiving end. The encrypted data includes an encryption header and at least one encrypted audio / video stream. The at least one encrypted audio / video stream is set on a per-audio / video stream transmission channel basis. The encryption header includes the encryption header version, encryption method indicator value, encryption algorithm indicator value, encryption mode, reserved fields, and counter.

[0072] In one possible implementation, the first message also includes: the current session identifier, the sender's identifier, a list of public keys, and a fast authentication identifier, which is used to instruct the receiver to enter the fast authentication process or the normal authentication process.

[0073] In one possible implementation, the second message also includes: the current session identifier, the receiver's public key, the receiver's device certification authority (CA) certificate, and the receiver's device certificate.

[0074] In one possible implementation, the session key includes a content encryption odd key and a content encryption even key, wherein the content encryption odd key or the content encryption even key is used to encrypt the audio and video streams.

[0075] A fourth aspect of this application provides a content transmission protection apparatus, comprising: an authentication module, configured to exchange authentication keys with the sending end during the establishment of a transmission link between the sending end and the receiving end to obtain an authentication key; the authentication module is further configured to negotiate a session key with the sending end based on the authentication key to obtain a session key; an authorization module, configured to respond to the authorization control of the sending end after the transmission link between the sending end and the receiving end is established; and a decryption module, configured to receive an encrypted audio / video stream from the sending end after the sending end completes the authorization control of the receiving end, wherein the encrypted audio / video stream is encrypted based on the session key.

[0076] In one possible implementation, the authentication module is specifically configured to: receive a first message from the sender, the first message being used to request authentication; calculate a signature and an authentication key, and calculate an authentication HMAC based on the authentication key calculated by the receiver; send a second message to the sender, the second message including a signature and the authentication HMAC calculated by the receiver, the signature being used to indicate the identity of the receiver; receive a third message from the sender, the third message including an authentication key / authentication code calculated by the sender; calculate an authentication key / authentication code based on the authentication key calculated by the receiver; and if it is determined that the authentication key / authentication code calculated by the sender and the authentication key / authentication code calculated by the receiver are equal, then cache the authentication key calculated by the receiver.

[0077] In one possible implementation, the first message includes a list of version numbers, and the authentication module is specifically used to calculate a signature based on the version number of the receiver and the update time of the receiver's revocation list if it is determined that the version number of the receiver is in the list of version numbers.

[0078] In one possible implementation, the authentication module is specifically used to: calculate the authentication HMAC based on the receiver's version number, the update time of the receiver's revocation list, and the authentication key calculated by the receiver; and calculate the authentication key authentication code based on the receiver's version number and the authentication key calculated by the receiver.

[0079] In one possible implementation, the authentication module is further configured to: receive a revocation list update message from the sender, the revocation list update message including the sender's revocation list; and replace the receiver's revocation list with the sender's revocation list.

[0080] The sender's revocation list is used to verify the certificates of the next-level devices at the receiving end.

[0081] In one possible implementation, the authorization module is specifically used to respond to the authorization control information corresponding to the audio and video streams from the sending end. The authorization control is based on the audio and video streams and includes security level, copying limit, retention time, maximum cascading depth, and the maximum number of connected devices supported by each level of the device.

[0082] In one possible implementation, the authorization module is further configured to: receive a tenth message from the sender, the tenth message including an audio / video stream transmission channel identifier corresponding to the audio / video stream and authorization control information corresponding to the audio / video stream, the audio / video stream transmission channel identifier being used to indicate the audio / video stream transmission channel corresponding to the audio / video stream; and, based on the audio / video stream transmission channel corresponding to the audio / video stream and the authorization control information corresponding to the audio / video stream, perform authorization control on the next-level device of the receiver on a per-audio / video stream basis.

[0083] In one possible implementation, the decryption module is specifically used to receive encrypted data from the sender. The encrypted data includes an encrypted header and at least one encrypted audio / video stream. The encrypted audio / video stream is set on a per-audio / video stream transmission channel basis. The encrypted header includes the version of the encrypted header, encryption method indicator value, encryption algorithm indicator value, encryption mode, reserved fields, and counter.

[0084] In one possible implementation, the first message also includes: the current session identifier, the sender's identifier, a list of public keys, and a fast authentication identifier, which is used to instruct the receiver to enter the fast authentication process or the normal authentication process.

[0085] In one possible implementation, the second message also includes: the current session identifier, the receiver's public key, the receiver's device certification authority (CA) certificate, and the receiver's device certificate.

[0086] In one possible implementation, the session key includes a content encryption odd key and a content encryption even key, wherein the content encryption odd key or the content encryption even key is used to encrypt the audio and video streams.

[0087] A fifth aspect of this application provides a content transfer protection apparatus, the apparatus comprising: a processor and a transfer interface, the processor being configured to invoke program instructions stored in a memory to perform the method described in the first aspect, any possible implementation of the first aspect, the second aspect, or any possible implementation of the second aspect.

[0088] A sixth aspect of this application provides a computer-readable storage medium including instructions that, when executed on a computer or processor, cause the computer or processor to perform the method described in the first aspect, any possible implementation of the first aspect, the second aspect, or any possible implementation of the second aspect.

[0089] A seventh aspect of this application provides a computer program product including instructions, the computer program product including program instructions that, when executed on a computer or processor, cause the computer or processor to perform the method described in the first aspect, any possible implementation of the first aspect, the second aspect, or any possible implementation of the second aspect.

[0090] In this embodiment, the authentication key exchange process and session key negotiation process between the sending end and the receiving end are implemented during the establishment of the transmission link between them. The authorization control process and audio / video stream transmission process between them are implemented after the transmission link is established. Therefore, the authentication process and the audio / video stream transmission process between the sending end and the receiving end can be implemented at different times, and are two independent processes. Thus, the authentication process between the sending end and the receiving end is not accompanied by the transmission of audio / video streams, which avoids audio / video stream leakage. Attached Figure Description

[0091] Figure 1 A schematic diagram of the structure of the HTCP system provided in this application embodiment;

[0092] Figure 2 This is another schematic diagram of the HTCP system provided in the embodiments of this application;

[0093] Figure 3 A schematic diagram of device connection provided in an embodiment of this application;

[0094] Figure 4 A schematic diagram of the HTCP workflow provided in this application embodiment;

[0095] Figure 5 A hardware architecture diagram of the content transmission protection apparatus provided in the embodiments of this application;

[0096] Figure 6 A flowchart illustrating the content transmission protection method provided in this application embodiment;

[0097] Figure 7 Another flowchart illustrating the content transmission protection method provided in this application embodiment;

[0098] Figure 8 Another flowchart illustrating the content transmission protection method provided in this application embodiment;

[0099] Figure 9 Another flowchart illustrating the content transmission protection method provided in this application embodiment;

[0100] Figure 10 A schematic diagram of the structure of a data frame provided in an embodiment of this application;

[0101] Figure 11 Another flowchart illustrating the content transmission protection method provided in this application embodiment;

[0102] Figure 12 A schematic diagram of the structure of the content transmission protection device provided in the embodiments of this application;

[0103] Figure 13 Another schematic diagram of the device for content transmission protection provided in the embodiments of this application. Detailed Implementation

[0104] The technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0105] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0106] The embodiments of this application can be applied to home network transmission content protection (HTCP) systems. Figure 1 A schematic diagram of the structure of the HTCP system provided in the embodiments of this application is shown below. Figure 1 As shown, an HTCP system includes three types of devices: transmitters, repeaters, and receivers. Generally, the transmitter serves as the starting point for audio / video stream transmission, the receiver as the ending point, and the repeater acts as a bridging device (relay device) between the transmitter and receiver, extending the secure transmission distance between them. Based on this, by using the transmitter as a first-level device and the repeater or receiver as a next-level device, and by increasing the number of devices and cascading multiple levels, a system like this can be constructed. Figure 1 The system shown is a distributed system. In this distributed system, there are hierarchical relationships between transmitters and receivers, transmitters and repeaters, repeaters and repeaters, and repeaters and receivers, and all can transmit audio and video streams. In the embodiments of this application, the transmitter is the hierarchical device and the receiver is the subordinate device.

[0107] In addition, the HTCP system is also connected to the content licensing system. The content licensing system can interact with various devices within the HTCP system, and each device is equipped with at least one interface to receive information sent by the content licensing system. For example, the content licensing system can send licensing information to the sender through the sender's licensing interface, or it can update the sender's revocation list through the sender's revocation list update interface, and so on.

[0108] To further understand, the following text will combine... Figure 2 A further introduction to the HTCP system will follow. Figure 2 This is another schematic diagram of the HTCP system provided in the embodiments of this application, as shown below. Figure 2 As shown:

[0109] (1) The transmitter includes an authentication module, an authorization module, and an encryption module. The authentication module can authenticate the identity of the downstream device and negotiate the key. The authorization module can control the authorization of the downstream device according to the authorization information of the audio and video stream. The encryption module can encrypt the audio and video stream data using the negotiated session key and send the encrypted audio and video stream data to the downstream device. If the downstream device of the transmitter is a repeater, the authentication module can also update the revocation list of the downstream device.

[0110] (2) The receiver includes an authentication module, an authorization module, and a decryption module. The authentication module supports the upper-level device to complete identity authentication and key negotiation, the authorization module supports the upper-level device to complete authorization control, and the decryption module uses the negotiated session key to decrypt the audio and video stream data from the upper-level device.

[0111] (3) The repeater includes an authentication module, an authorization module, an encryption module, and a decryption module. When the repeater acts as a downstream device of the transmitter (the transmitter is the upstream device), the authentication module supports identity authentication and key negotiation; the authorization module supports authorization control by the upstream device; the decryption module uses the negotiated session key to decrypt audio and video stream data from the upstream device; and the authentication module supports revocation list updates by the upstream device. When the repeater acts as a upstream device of the receiver (the receiver or repeater is the downstream device), the authentication module performs identity authentication and key negotiation for the downstream device; the authorization module controls authorization for the downstream device based on the authorization information of the audio and video stream; and the encryption module re-encrypts the audio and video stream data using the negotiated session key and sends the encrypted audio and video stream data to the downstream device.

[0112] exist Figure 2In a network, after the transmitter, repeater, and receiver establish a connection, an audio / video stream transmission link is formed, supporting unidirectional transmission of audio and video streams. For example, a home network might include a set-top box, a television, and a relay device. The set-top box can serve as the starting point for audio / video stream transmission, the television as the ending point, and the relay device can be positioned between them. When the set-top box and television form a hierarchical relationship, after jointly completing the interaction based on the HTCP protocol (hereinafter referred to as protocol interaction, including the aforementioned authentication, key negotiation, and authorization control), the set-top box can securely send the encrypted audio / video stream to the television. When the set-top box and relay device form a hierarchical relationship, and the relay device and television form a hierarchical relationship, after the set-top box and relay device jointly complete the protocol interaction, and after the relay device and television jointly complete the protocol interaction, the set-top box can securely send the encrypted audio / video stream to the television through the relay device.

[0113] Furthermore, devices in an HTCP system can be divided into senders and receivers. The sender is responsible for initiating protocol interaction requests and encrypting the audio and video streams. The receiver is responsible for responding to the sender's requests and decrypting the audio and video streams. It should be noted that the sender is typically the sender, the receiver is typically the receiver, and a repeater can be either a sender or a receiver.

[0114] like Figure 3 As shown ( Figure 3 This diagram illustrates a device connection provided in an embodiment of this application. A command channel and an audio / video stream transmission channel can be established between the sending and receiving ends. The command channel is used for protocol interaction between the sending and receiving ends, specifically for authentication, key negotiation, and authorization control. Generally, multiple command channels exist between the sending and receiving ends. For example, an authentication module on the sending end and an authentication module on the receiving end can form a command channel used for authentication, key negotiation, and revocation list updates, etc. An authorization module on the sending end and an authorization module on the receiving end can also form a command channel used to send authorization information for different audio / video streams. The audio / video stream transmission channel is used for audio / video stream transmission between the sending and receiving ends. Cascaded audio / video stream transmission channels between multiple devices can form the entire audio / video stream transmission path. Generally, multiple audio / video stream transmission channels exist between the encryption module on the sending end and the decryption module on the receiving end. One audio / video stream transmission channel can be used to transmit one audio / video stream, and different audio / video stream transmission channels are used to transmit different audio / video streams.

[0115] Both the command channel and the audio / video stream transmission channel are logical channels, and both are provided by the device's transmission interface, allowing the reuse of the physical transmission link formed between the transmission interfaces. It is worth noting that the transmission interface can call the encryption module on the sending end to encrypt the audio / video streams transmitted in the physical link, and the transmission interface can also call the decryption module on the receiving end to decrypt the transmitted audio / video streams.

[0116] Along the entire audio and video stream transmission path, a primary device can initiate authentication and authorization for lower-level devices, and subsequent devices at each level similarly initiate authentication and authorization for their lower-level counterparts, thereby establishing a trust chain throughout the entire audio and video stream transmission path and achieving secure transmission of audio and video streams. If the sending end fails to authenticate or authorize the receiving end, the sending end stops sending audio and video streams to the receiving end.

[0117] To understand the complete HTCP workflow, the following section combines... Figure 4 This section provides a preliminary introduction to the HTCP workflow. Figure 4 A schematic diagram of the HTCP workflow provided in the embodiments of this application is shown below. Figure 4 As shown, the HTCP workflow includes authentication, key negotiation, revocation list update, authorization control, and content encryption. Authentication, key negotiation, and revocation list update are completed during the inter-device link establishment process, while authorization control and content encryption are completed before audio / video stream transmission. For example, after the sending and receiving ends' transmission interfaces are connected, they need to confirm each other's information (e.g., transmission interface parameters, device parameters, etc.). At this time, both send their own information and confirm the information sent by the other; this process is equivalent to the sending and receiving ends being in the process of establishing the transmission link. During the transmission link establishment process, the sending and receiving ends can complete authentication, key negotiation, and revocation list update. Once both the sending and receiving ends confirm that the other's information is correct, they can stop confirming information, which is equivalent to the transmission link being established. After the transmission link is established, the sending and receiving ends can perform authorization control, content encryption, and other operations. The following will provide a brief introduction to each process:

[0118] (1) Authentication and Key Negotiation: This process includes an authentication key exchange (AKE) process and a session key agreement (SKA) process. During the device connection establishment process (i.e., during the device transmission link establishment process), the authentication key exchange process realizes the authentication and authentication key exchange between connected devices, and the session key agreement process is used to negotiate the session key for encrypted audio and video streams. This process is initiated by the sending end and responded by the receiving end.

[0119] (2) Revocation List Update: After the authentication key exchange process is successful, the sending end checks whether the revocation list stored locally is updated compared to the version of the revocation list of the downstream device. If so, it must send a revocation list update message to the downstream device to update the downstream device's revocation list. The content authorization system can call the sending end's revocation list update interface to update the revocation list. After receiving the new revocation list from the sending end, the receiving end needs to use the new revocation list to verify the downstream device's certificate.

[0120] (3) Authorization Control: After the transmission link between devices is established, authorization between devices is based on the control of the transmitted audio and video streams. Each audio and video stream channel is bound to a unique audio and video stream, and each audio and video stream uses a corresponding audio and video stream channel for transmission. The audio and video stream transmission channel has a unique channel identifier (streamChannelId). Before the audio and video stream is transmitted, the content authorization system calls the sender's authorization interface to send authorization information. The sender receives the authorization information from the content authorization system through the authorization interface, performs authorization control on the lower-level devices according to the authorization information, and sends the authorization information to the lower-level devices. During the audio and video stream transmission process, before content encryption, after receiving the authorization information, the sending end judges the authentication and authorization status of the current receiving end. If authentication and authorization are both successful, the audio and video stream is encrypted and sent to the lower-level devices. If authorization fails, encryption and sending the stream to the lower-level devices are stopped. The receiving end performs authorization control on the use of local content according to the authorization information.

[0121] (4) Content Encryption: During audio and video stream transmission, the sending end encrypts the transmitted audio and video stream using a negotiated session key, and the receiving end decrypts the transmitted audio and video stream using the negotiated session key. During encryption, the session key can be updated through a session key negotiation process. In the HTCP system, different device groups (each device group contains one sending end and one receiving end) operate independently and asynchronously when executing the above workflow to ensure the performance of the interaction.

[0122] To further understand the HTCP workflow described above, the following section will introduce each step of the HTCP process separately. First, let's explain the relevant terms mentioned below:

[0123] Key management defines the requirements for HTCP trust system, key system, and secure storage.

[0124] (1) Trust System

[0125] The HTCP trust system is built on the public key infrastructure (PKI) certificate system. Devices in the system have built-in HTCP device certificates and their trust chains, and device authentication is achieved through the authentication of the device certificate chain.

[0126] (1.1) Certificate System

[0127] HTCP's PKI consists of the HTCP Root CA and the HTCP Device CA.

[0128] The HTCP root CA generates a root CA public-private key pair and self-signs the root CA public key to generate a root CA certificate; the root CA is also responsible for managing the HTCP device CAs and signing the device CA public key to generate a device CA certificate.

[0129] The HTCP device CA generates a device CA public-private key pair and submits the public key to the HTCP root CA to request a signature to obtain a device CA certificate. The HTCP device CA is also responsible for generating a device public-private key pair and signing the public key to generate a device certificate.

[0130] The certificate format adopts the X.509 v3 standard, supports the SM3SM2 national cryptographic signature algorithm, and optionally supports the SHA256X25519 international algorithm. See Appendix B for certificate format definitions, which includes the HTCP root CA certificate, device CA certificate, and device certificate format. The device CA certificate carries information such as device type (receiver, repeater; transmitters do not require a device certificate), security level, and version.

[0131] Before the devices leave the factory, the transmitter stores the HTCP national cryptographic algorithm and the international algorithm root CA certificate in secure storage; the receiver stores the device CA certificate, the device private key and its corresponding device certificate in secure storage; and the repeater stores the HTCP national cryptographic algorithm and the international algorithm root CA certificate, the device CA certificate, the device private key and its corresponding device certificate in secure storage.

[0132] In identity authentication and key negotiation, the receiving end sends the device CA certificate and device certificate to the authenticator. The authenticating device uses the built-in HTCP root CA certificate to verify the certificate of the authenticated device based on the certificate chain.

[0133] (1.2) Cancellation List

[0134] During the authentication key exchange process, the authentication device uses a revocation list to check whether the authenticated device has been revoked. The revocation list adopts the X.509v2 CRL standard, and its format is shown in Appendix C, Revocation List Format. The latest revocation list must be added before the device leaves the factory.

[0135] (1.3) Global authentication constants

[0136] The global authentication constant is used for the hmac key (hmacKey) used in the derived protocol interaction and the encryption key (encKey) used in the session key negotiation process, and its value is 0x85AC702793BD614F.

[0137] (2) Key system

[0138] HTCP employs a three-level key system, including:

[0139] Device public / private key pair: The sending end uses the device public key to encrypt the authentication key, and the receiving end uses the device private key to decrypt it to obtain the authentication key. The algorithm is determined by whether the receiving end's device certificate uses the Chinese national cryptographic algorithm or the international algorithm. The Chinese national cryptographic algorithm uses the SM2 encryption algorithm, and the international algorithm uses the curve25519 encryption algorithm.

[0140] Authentication Key: The sending and receiving ends use the authentication key to negotiate the session key. The session key encryption method, SessionKeyEncrypt, and the HMAC algorithm are determined by whether the receiving end's device certificate uses the Chinese national cryptographic algorithm or the international algorithm. The Chinese national cryptographic algorithm is SM4-CTR, the international cryptographic algorithm is AES-128-CTR, the Chinese national HMAC algorithm is HMAC-SM3, and the international HMAC algorithm is HMAC-SHA256.

[0141] Session key: The sending end uses the session key to encrypt the content, and the receiving end uses the session key to decrypt the content. The national cryptographic algorithm used is SM4, and the international cryptographic algorithm used is AES-128. CTR or GCM mode.

[0142] (3) Secure storage

[0143] (3.1) Data storage

[0144] The device private key should be stored in secure storage, which cannot be modified or replaced, and cannot be read by any other software or hardware outside the HTCP system;

[0145] Device certificates and device CA certificates should be stored in secure storage that cannot be modified or replaced.

[0146] Root CA certificates can be hardcoded or stored in secure storage, making them impossible to modify or replace.

[0147] The revocation list can be stored in secure storage or external non-volatile storage. If stored in external non-volatile storage, the integrity check value of the revocation list must be stored in secure storage, and the integrity check value in secure storage must be updated after an update. When reading the revocation list, the integrity check value must be used to verify the revocation list data.

[0148] (3.2) Storage space

[0149] The device's secure storage space can store the device's private key and device certificate, device CA certificate and root CA certificate, revocation list or its integrity check value, with a minimum of 20KB.

[0150] (3.3) Secure storage requirements

[0151] For secure storage requirements, please refer to the security levels shown in Table 8.

[0152] In addition, the following sections will provide formatting instructions for certificates and revocation lists, as shown in Tables 1 through 4.

[0153] Table 1 Format of HTCP Root Certificate

[0154]

[0155] Table 2 Format of HTCP Device CA Certificate

[0156]

[0157] Table 3 HTCP Device Certificate Format

[0158]

[0159]

[0160] Table 4 Format of the Cancellation List

[0161]

[0162] Furthermore, the following section will provide further explanation regarding key derivation:

[0163] The key derivation algorithm is the PDKDF2 algorithm, and the formula is derivedKey = PDKDF2(HASH algorithm, password, salt, count, keyLen), where:

[0164] 1) The HASH algorithm is determined by the signature algorithm of the receiving device certificate. If the signature algorithm is a Chinese cryptographic algorithm, SM3 is used; if the signature algorithm is an international algorithm, SHA256 is used.

[0165] 2) Password derived parameters;

[0166] 3) Salt value;

[0167] 4) count is the number of iterations;

[0168] 5) keyLen is the length of the derived key.

[0169] hmacKey is the HMAC key used in the protocol interaction. The derivation method is hmacKey = PDKDF2(HASH algorithm, authKey||global authentication constant||"mac key", sessionId, 1, 16).

[0170] `encKey` is the encryption key used in the session key negotiation process. The derivation method is `encKey = PDKDF2(HASH algorithm, authKey||global authentication constant)|| "enc key", sessionId, 1, 16)`.

[0171] Figure 5 This is a hardware architecture diagram of a content transmission protection device 500 provided in an embodiment of this application. The content transmission protection device 500 can be, for example, a processor chip. Figure 5 The hardware architecture diagram shown may be Figure 1 An exemplary architecture diagram of a processor for a transmitter, repeater, or receiver is provided in the present application, and the content transmission protection method provided in this application embodiment can be applied to this processor chip.

[0172] refer to Figure 5 The device 500 includes: at least one CPU, memory, a microcontroller unit (MCU), a GPU, an NPU, a memory bus, a receive interface, and a transmit interface, etc. Although Figure 5 As not shown in the diagram, the device 500 may also include an application processor (AP), a decoder, and a dedicated video or image processor.

[0173] The various parts of the device 500 are coupled together by connectors. For example, the connectors include various interfaces, transmission lines or buses, etc. These interfaces are usually electrical communication interfaces, but may also be mechanical interfaces or other forms of interfaces. This embodiment does not limit them.

[0174] Optionally, the CPU can be a single-core or multi-core processor; alternatively, the CPU can be a processor group consisting of multiple processors, which are coupled to each other through one or more buses. The receiving interface can be a data input interface for the processor chip. In one optional case, the receiving and transmitting interfaces can be High Definition Multimedia Interface (HDMI), V-By-One interface, Embedded Display Port (eDP), Mobile Industry Processor Interface (MIPI), or DisplayPort (DP), etc.

[0175] In one optional scenario, the aforementioned components are integrated onto the same chip; in another optional scenario, the CPU, GPU, decoder, receiving interface, and transmitting interface are integrated onto a single chip, with each component within the chip accessing external memory via a bus. A dedicated video / graphics processor can be integrated onto the same chip as the CPU, or it can exist as a separate processor chip; for example, a dedicated video / graphics processor can be a dedicated ISP. In one optional scenario, the NPU can also be a separate processor chip. This NPU is used to implement various neural network or deep learning related operations. Optionally, the image processing method and image processing framework provided in this application embodiment can be implemented by a GPU or NPU, or by a dedicated graphics processor.

[0176] The chip involved in this application embodiment is a system manufactured on the same semiconductor substrate using integrated circuit technology, also called a semiconductor chip. It can be a collection of integrated circuits formed on a substrate (usually a semiconductor material such as silicon) using integrated circuit technology, and its outer layer is typically encapsulated by semiconductor packaging materials. The integrated circuit can include various functional devices, each including logic gates, metal-oxide-semiconductor (MOS) transistors, bipolar transistors, or diodes, and may also include other components such as capacitors, resistors, or inductors. Each functional device can operate independently or under the action of necessary driving software, and can realize various functions such as communication, computation, or storage.

[0177] To facilitate further understanding, each process will be described separately below. Figure 6This is a flowchart illustrating a content transmission protection method provided in an embodiment of this application. It should be noted that the aforementioned authentication key exchange process includes a normal authentication process and a fast authentication process. Figure 6 The method shown is the standard authentication process. For example... Figure 6 As shown, the method includes:

[0178] 601. The sending end sends the first message to the receiving end. The first message includes the current session identifier, the sending end identifier, the version number list, the public key list, and the fast authentication identifier.

[0179] When the sender needs to initiate authentication with the receiver, it can first generate two random numbers, namely the sender's private key (x) and the current session identifier (sessionId), which is used to indicate the current session between the sender and the receiver.

[0180] Then, the sending end can obtain the sending end identifier (txId), the version number list (supportedVersions), the public key list (xG0||xG1), and the fast authentication identifier (enableFastAuth). The sending end identifier indicates the sending end's identity. The version number list contains at least one version number of the HCTP protocol supported by the sending end. The public key list contains public keys from two elliptic curve difficulty-Hellman (ECDH) protocols: the public key calculated by the sending end based on the Chinese national cryptographic algorithm (xG0) and the public key calculated by the sending end based on the international algorithm (xG1). The initial value of the fast authentication identifier is 1. The receiving end can use the fast authentication identifier to determine whether to execute the normal authentication process or the fast authentication process. Specifically, when the receiving end determines that the fast authentication identifier is 1, it can attempt to execute the fast authentication process (i.e., check if the authentication key is cached). If the receiving end fails to execute the fast authentication process, the sending end sets the fast authentication identifier to 0; if the receiving end succeeds in executing either the normal authentication process or the fast authentication process, the sending end sets the fast authentication identifier to 1. When the receiving end determines that the fast authentication identifier is 0, it directly executes the normal authentication process.

[0181] Next, the sender generates the first message (AKE_AUTHKEY_EXCHANGE) based on the current session identifier, sender identifier, version number list, public key list, and fast authentication identifier. The following describes the fields of the first message in conjunction with Table 5, as shown in Table 5:

[0182] Table 5 AKE_AUTHKEY_EXCHANGE

[0183]

[0184] After receiving the first message, the sending end sends the first message to the receiving end.

[0185] 602. If the receiving end determines that the cached session identifier is different from the current session identifier, it checks whether the version number of the receiving end is in the version number list.

[0186] After receiving the first message, the receiving end can parse it to obtain the various parameters within the message and then perform parameter checks. Specifically, if the receiving end determines that it has a locally cached session identifier, it retrieves the locally cached session identifier and compares it with the session identifier sent by the sending end (i.e., the current session identifier). If they are different, it checks whether the receiving end's version number is in the version number list. If they are the same, it sends an error message to the sending end to inform it of the session identifier error and stops the authentication process. If the receiving end determines that it does not have a locally cached session identifier, it checks whether the receiving end's version number is in the version number list.

[0187] 603. If the receiving end determines that the version number of the receiving end is in the version number list, then check whether the authentication key is cached.

[0188] When the receiving end checks whether the version number it supports is in the version number list, it can first obtain the highest version number it can support, and then determine whether the highest version number is in the version number list.

[0189] If the version number of the receiving end is determined to be in the version number list, since the fast authentication flag is set to 1, it checks whether the authentication key is cached locally. If it is, the fast authentication process is entered; otherwise, the next step is executed.

[0190] If it is determined that the receiver's version number is not in the version number list, an error message is sent to the sender to inform the sender that the version number is not supported and to stop the authentication process.

[0191] 604. If the receiving end determines that the authentication key is not cached, then calculate the signature, authentication key, and authentication HMAC.

[0192] After confirming that no authentication key is cached, the receiver generates a random number as its private key (y) and generates its public key (yG) according to an algorithm supported by the receiver. Furthermore, the receiver can select one of the two public keys from the sender in the first message as the sender's (final) public key (xG).

[0193] Then, the receiving end can calculate a signature (signAuth = S(yG||xG||txId||version||sessionId||crlThisUpdate, rxPriKey)) based on the receiving end's public key (yG), the sending end's final public key (xG), the sending end's identifier (txId), the receiving end's version number (version), the current session identifier (sessionId), the receiving end's revocation list update time (crlThisUpdate), and the private key corresponding to the receiving end's device certificate (rxPriKey). It should be noted that when the receiving end supports multiple version numbers, one of them can be selected as the receiving end's (final) version number.

[0194] Furthermore, the receiving end can also calculate the authentication key (authKey = y(xG)) based on the receiving end's private key and the public key finally determined by the sending end.

[0195] Furthermore, the receiving end can also calculate the hash-based message authentication code (hmac) based on the receiving end's public key (yG), the sending end's final determined public key (xG), the sending end's identifier (txId), the receiving end's version number (version), the current session identifier (sessionId), the revocation list update time (crlThisUpdate), and the authentication key (authKey) calculated by the receiving end (hmacAuth = HAMC(yG||xG|| txId||version||sessionId||crlThisUpdate, authKey)).

[0196] 605. The receiving end sends a second message to the sending end. The second message includes the current session identifier, the receiving end's version number, the receiving end's Certificate Authority (CA) certificate, the receiving end's device certificate, the revocation list update time, the receiving end's public key, signature, and the authentication HMAC calculated by the receiving end.

[0197] After obtaining the signature, authentication key, and authentication HMAC, the receiving end can generate a second message (AKE_AUTHKEY_EXCHANGE_ACK) based on the current session identifier, the receiving end's version number, the receiving end's device CA certificate (caCert), the receiving end's device certificate (rxCert), the revocation list update time (crlThisUpdate), the receiving end's public key, signature, and authentication HMAC. The following describes the fields of the second message in conjunction with Table 6, as shown in Table 6:

[0198] Table 6 AKE_AUTHKEY_EXCHANGE_ACK

[0199]

[0200] After receiving the second message, the receiving end sends the second message back to the sending end.

[0201] 606. The sending end verifies the certificate chain of the receiving end to obtain the algorithm used by the receiving end's device certificate and the identifier of the receiving end's device certificate.

[0202] After receiving the second message, the sending end can first check the session identifier in the second message. If it is inconsistent with the session identifier previously sent by the sending end, the authentication status is recorded as session identifier error and the authentication process is stopped. If it is consistent with the session identifier previously sent by the sending end, then it is determined whether the version number of the receiving end in the second message is supported.

[0203] If the sender does not support the receiver's version number, the authentication status is recorded as protocol version number error, and the authentication process is stopped. If the sender supports the receiver's version number, the receiver's certificate chain is verified based on the receiver's device CA certificate and device certificate to obtain the algorithm used by the receiver's device certificate (international algorithm or national cryptographic algorithm, which can be used for subsequent encryption content) and the identifier (serial number) of the receiver's device certificate.

[0204] Specifically, the process of the sending end verifying the certificate chain of the receiving end is as follows: After the receiving end sends the device CA certificate and device certificate to the sending end, the sending end uses the built-in HTCP root CA certificate to verify the receiving end's device CA certificate and device certificate based on the certificate chain.

[0205] 607. If the sending end successfully verifies the certificate chain of the receiving end, then check whether the identifier of the receiving end's device certificate is in the revocation list.

[0206] If the sending end successfully verifies the receiving end's certificate chain, it checks whether the identifier of the receiving end's device certificate is in the revocation list. If it fails, the sending end records the authentication status as certificate verification failed and stops the authentication process.

[0207] 608. If the sending end determines that the identifier of the receiving end's device certificate is in the revocation list, it calculates the authentication HMAC and checks whether the authentication HMAC calculated by the sending end is equal to the authentication HMAC calculated by the receiving end.

[0208] If the sending end determines that the receiver's device certificate identifier is on the revocation list, it calculates the authentication key (authKey = x(yG)) based on the sending end's private key (x) and the receiver's public key (yG). Then, it calculates the authentication HMAC based on the receiver's public key (yG), the sending end's final determined public key (xG), the sending end's identifier (txId), the receiver's version number (version), the current session identifier (sessionId), the revocation list update time (crlThisUpdate), and the authentication key (authKey) calculated by the sending end. Finally, it checks whether the authentication HMAC calculated by the sending end is equal to the authentication HMAC calculated by the receiver.

[0209] If the sending end determines that the identifier of the receiving end's device certificate is not in the revocation list, it records the authentication status as certificate revocation and stops the authentication process.

[0210] 609. If the sender determines that the authentication HMAC calculated by the sender is equal to the authentication HMAC calculated by the receiver, then verify the signature.

[0211] If the sending end determines that the authentication HMAC calculated by the sending end is equal to the authentication HMAC calculated by the receiving end, then it uses the public key (rxPubKey) corresponding to the receiving end's device certificate to verify the signature (signAuth). It should be noted that after the sending end parses the second message to obtain the receiving end's device certificate, it can obtain the public key corresponding to the receiving end's device certificate.

[0212] If the sending end determines that the authentication HMAC calculated by the sending end is not equal to the authentication HMAC calculated by the receiving end, it records the authentication status as HAMC verification failure and stops the authentication process.

[0213] 610. If the sender successfully verifies the signature, then calculate the authentication key / authentication code.

[0214] If the sender successfully verifies the signature, it calculates the authentication key and authentication code (hmacAuthConfirm = HMAC(txId||version||sessionId, authKey) based on the sender's identifier (txId), the receiver's version number (version), the current session identifier (sessionId), and the authentication key (authKey) calculated by the sender.

[0215] If the sender fails to verify the signature, it records the authentication status as "signature verification failed" and stops the authentication process.

[0216] 611. The sending end sends a third message to the receiving end. The third message includes the current session identifier and the authentication key / authentication code calculated by the sending end.

[0217] After obtaining the authentication key / authentication code, the sending end generates a third message (AKE_AUTHKEY_CONFIRM) based on the current session identifier and the authentication key / authentication code. The following describes the various fields of the third message in conjunction with Table 7:

[0218] Table 7 AKE_AUTHKEY_CONFIRM

[0219]

[0220] Subsequently, the sending end sends the third message to the receiving end.

[0221] 612. The receiving end calculates the authentication key and authentication code, and checks whether the authentication key and authentication code calculated by the sending end and the authentication key and authentication code calculated by the receiving end are equal.

[0222] After receiving the third message, the receiving end verifies the session identifier in the third message. Then, based on the sender's identifier (txId), the receiver's version number (version), the current session identifier (sessionId), and the authentication key (authKey) calculated by the receiver, it calculates the authentication key (hmacAuthConfirm = HMAC(txId||version||sessionId, authKey)). Next, the receiving end checks whether the authentication key calculated by the sender and the authentication key calculated by the receiver are equal.

[0223] 613. If the receiving end determines that the authentication key and authentication code calculated by the sending end are equal to the authentication key and authentication code calculated by the receiving end, then cache the current session identifier, authentication key, sending end identifier, and receiving end version.

[0224] If the receiving end determines that the authentication key / authentication code calculated by the sending end and the authentication key / authentication code calculated by the receiving end are equal, then it caches the current session identifier, the authentication key calculated by the receiving end, the sender's identifier, and the receiving end's version. Furthermore, the receiving end can send a fourth message to the sending end to inform it that the authentication key verification was successful.

[0225] If the receiving end determines that the authentication key and authentication code calculated by the sending end are not equal, it sends an error message to the sending end to inform it that the authentication key verification has failed and stops the authentication process.

[0226] 614. The sending end caches the current session identifier, authentication key, receiver version number, receiver CA certificate, receiver device certificate, and receiver device certificate identifier.

[0227] After receiving the fourth message, the sending end can set the authentication status of the receiving end to successful and cache the current session identifier, authentication key, receiving end version, receiving end CA certificate, receiving end device certificate and receiving end device certificate identifier. Alternatively, the sending end can directly cache (i.e., without needing the received fourth message) the current session identifier, authentication key, receiving end version, receiving end CA certificate, receiving end device certificate and receiving end device certificate identifier.

[0228] After completing a normal authentication process, both the sender and receiver cache the authentication key. Therefore, they can achieve fast authentication during the next re-authentication. The following will combine... Figure 7 The process of fast authentication will be introduced. Figure 7 Another flowchart illustrating the content transmission protection method provided in this application embodiment is shown below. Figure 7 As shown, the method includes:

[0229] 701. The sender sends the first message to the receiver. The first message includes the current session identifier, the sender identifier, the version number list, the public key list, and the fast authentication identifier.

[0230] 702. If the receiving end determines that the cached session identifier is different from the current session identifier, it checks whether the version number of the receiving end is in the version number list.

[0231] 703. If the receiving end determines that the version number of the receiving end is in the version number list, then check whether the authentication key is cached.

[0232] It should be noted that the explanations of steps 701 to 703 can be found in the relevant explanations of steps 601 to 603 mentioned above, and will not be repeated here.

[0233] 704. If the receiving end determines that the authentication key is cached, calculate the fast authentication HMAC;

[0234] If the receiving end determines that it has cached the authentication key (authKey), it calculates the fast authentication HMAC (hmacFastAuth = HMAC(sessionId||txId||version||rxCert, authKey) based on the sender's identifier (txId), the receiver's version number (version), the current session identifier (sessionId), the receiver's device certificate (rxCert), and the cached authentication key (authKey).

[0235] 705. The receiving end sends the fifth message to the sending end. The fifth message includes the current session identifier, the receiving end's version number, the receiving end's device CA certificate, the receiving end's device certificate, and the fast authentication HMAC calculated by the receiving end.

[0236] After receiving the fast authentication HMAC, the receiving end can generate a fifth message (AKE_FAST_AUTH) based on the current session identifier, the receiving end's version number, the receiving end's device CA certificate, the receiving end's device certificate, and the fast authentication HMAC calculated by the receiving end. The following describes the fields of the fifth message in conjunction with Table 8, as shown in Table 8:

[0237] Table 8 AKE_FAST_AUTH

[0238]

[0239] After receiving the fifth message, the receiving end sends the fifth message back to the sending end.

[0240] 706. The sending end compares the cached device CA certificate and the cached device certificate with the device CA certificate and the device certificate in the fifth message.

[0241] After receiving the fifth message, the sending end can first check the session identifier in the fifth message. If it is inconsistent with the session identifier previously sent by the sending end, the authentication status is recorded as session identifier error and the authentication process is stopped. If it is consistent with the session identifier previously sent by the sending end, then it is determined whether the version number of the receiving end in the fifth message is supported.

[0242] If the sender does not support the receiver's version number, the authentication status is recorded as protocol version number error, and the authentication process is stopped. If the sender supports the receiver's version number, the cached device CA certificate and the cached device certificate are compared with the device CA certificate and the device certificate in the fifth message.

[0243] 707. If the sending end determines that the certificates are consistent, then check whether the identifier of the receiving end's device certificate is in the revocation list.

[0244] If the sending end determines that the certificates are consistent (i.e., the cached device CA certificate, the cached device certificate, the device CA certificate in the fifth message, and the device certificate in the fifth message are the same), then it checks whether the identifier of the receiving end's device certificate is in the revocation list.

[0245] If the sender determines that the certificates are inconsistent (i.e., the cached device CA certificate and the cached device certificate are different from the device CA certificate and the device certificate in the fifth message), then the authentication status is recorded as certificate verification failed, and the authentication process is stopped.

[0246] 708. If the sending end determines whether the identifier of the receiving end's device certificate is in the revocation list, then calculate the fast authentication HMAC.

[0247] If the sender determines that the receiver's device certificate identifier is in the revocation list, it calculates the fast authentication HMAC (hmacFastAuth = HMAC(sessionId||txId||version||rxCert, authKey) based on the sender's identifier (txId), the receiver's version number (version), the current session identifier (sessionId), the receiver's device certificate (rxCert), and the cached authentication key (authKey).

[0248] If the sending end determines that the identifier of the receiving end's device certificate is not in the revocation list, it records the authentication status as certificate revocation and stops the authentication process.

[0249] 709. If the sending end determines that the fast authentication HMAC calculated by the sending end is equal to the fast authentication HMAC calculated by the receiving end, then the fast authentication is considered successful.

[0250] If the sending end determines that the fast authentication HMAC calculated by the sending end is equal to the fast authentication HMAC calculated by the receiving end, then the fast authentication is considered successful, and the authentication status of the receiving end can be set to successful. If they are not equal, then the fast authentication is considered to have failed, and the authentication process is stopped. It should be noted that once the sending end stops the authentication process, it sets the fast authentication flag to 0, disables the fast authentication mode, and restarts the normal authentication process. Furthermore, after determining that the fast authentication is successful, the sending end can also send a sixth message to the receiving end to inform the receiving end of the successful authentication.

[0251] In addition, HTCP provides an authentication status interface, which supports querying the authentication status of the sending end.

[0252] After authentication is completed between the sender and receiver, the sender updates the receiver's revocation list as needed and then initiates a session key negotiation process to determine the keys used for content encryption, such as the content encryption odd key (oddSessionKey), the content encryption even key (evenSessionKey), and the authorization information HMAC key (rcMacKey). This process can be restarted if the content encryption key or the authorization HMAC key needs to be changed. To ensure the continuity of content encryption, it is necessary to ensure that when switching between the content encryption odd and even keys, only keys that are not currently being used to encrypt content are changed. Figure 8 Another flowchart illustrating the content transmission protection method provided in this application embodiment is shown below. Figure 8 As shown, the method includes:

[0253] 801. The sending end calculates the first authentication code and calculates the session key ciphertext based on the first authentication code calculated by the sending end;

[0254] When session key negotiation is required, the sender can first generate a 128-bit random number, which consists of the content encryption odd key (oddSessionKey), the content encryption even key (evenSessionKey), the authorization information hmac key (rcMacKey), and the initialization variable (iv).

[0255] Then, the sender calculates the first authentication key (m = HMAC(sessionId||oddSessionKey||evenSessionKey||rcMacKey||iv, hmacKey)) based on the current session identifier, the content encryption odd key, the content encryption even key, the authorization information HMAC key, the initialization variables, and the HMAC key (hmacKey). The HMAC key is derived from the authentication key (authKey) cached by the sender.

[0256] Furthermore, the sender calculates the session key ciphertext (sessionEncData = SessionKeyEncrypt(sessionId||oddSessionKey||evenSessionKey||rcMacKey||m, encKey, iv)) based on the current session identifier, content encryption odd key, content encryption even key, authorization information HMAC key, initialization variables, the first authentication code calculated by the sender, and the encryption key (encKey), where SessionKeyEncrypt is the session key encryption method, and the encryption key is derived from the authentication key (authKey).

[0257] 802. The sending end sends the seventh message to the receiving end. The seventh message includes the current session identifier, initialization variables, and session key ciphertext.

[0258] After receiving the ciphertext of the session key, the sending end can generate the seventh message (SKA_SESSION_KEYS) based on the current session identifier, initialization variables, and the ciphertext of the session key. The following describes the fields of the seventh message in conjunction with Table 9:

[0259] Table 9 SKA_SESSION_KEYS

[0260]

[0261] Upon receiving the seventh message, the sending end will send the seventh message to the receiving end.

[0262] 803. The receiving end decrypts the session key ciphertext to obtain the content encryption odd key, the content encryption even key, the authorization information HMAC key, and the first authentication code calculated by the sending end.

[0263] After receiving the seventh message, the receiving end can verify the session identifier in the seventh message. After verification, it can derive the encryption key based on the cached authentication key. Then, the receiving end decrypts the ciphertext of the session key based on the initialization variables and the encryption key to obtain the content encryption odd key (oddSessionKey), the content encryption even key (evenSessionKey), the authorization information hmac key (rcMacKey), and the first authentication code (m) calculated by the sending end.

[0264] 804. The receiving end calculates the first authentication code and checks whether the first authentication code calculated by the receiving end is equal to the first authentication code calculated by the sending end.

[0265] After decrypting the ciphertext of the session key to obtain the content encryption odd key, content encryption even key, authorization information HMAC key, and the first authentication code calculated by the sender, the receiving end can calculate the first authentication code (m = HMAC(sessionId||oddSessionKey||evenSessionKey||rcMacKey||iv, hmacKey)) based on the current session identifier, the content encryption odd key, the content encryption even key, the authorization information HMAC key, the initialization variables, and the HMAC key (hmacKey). The HMAC key (hmacKey) is derived from the authentication key (authKey) cached by the receiving end.

[0266] Then, the receiving end checks whether the first authentication code calculated by the receiving end is equal to the first authentication code calculated by the sending end.

[0267] 805. If the receiving end determines that the first authentication code calculated by the receiving end is equal to the first authentication code calculated by the sending end, then the second authentication code is calculated.

[0268] If the receiving end determines that the first authentication code calculated by the receiving end is equal to the first authentication code calculated by the sending end, it can calculate the second authentication code based on the current session identifier, the content encryption odd key, the content encryption even key, the authorization information hmac key, and the hmac key (h = HMAC(sessionId||oddSessionKey||evenSessionKey||rcMacKey,hmacKey)).

[0269] 806. The receiving end sends the eighth message to the sending end. The eighth message includes the current session identifier and the second authentication code calculated by the receiving end.

[0270] After calculating the second authentication code, the receiving end can generate the eighth message (SKA_SESSION_KEYS_ACK) based on the current session identifier and the second authentication code calculated by the receiving end. The following describes the fields of the eighth message in conjunction with Table 10:

[0271] Table 10 Eighth Message

[0272]

[0273] After receiving the eighth message, the receiving end sends the eighth message to the sending end.

[0274] 807. The sending end calculates the second authentication code and checks whether the second authentication code calculated by the sending end is equal to the second authentication code calculated by the receiving end.

[0275] After receiving the eighth message, the sending end can verify the session identifier in the eighth message. After verification, the second authentication code can be calculated based on the current session identifier, the content encryption odd key, the content encryption even key, the authorization information hmac key, and the hmac key (h = HMAC(sessionId||oddSessionKey||evenSessionKey||rcMacKey,hmacKey)).

[0276] Then, the sending end checks whether the second authentication code calculated by the sending end is equal to the second authentication code calculated by the receiving end.

[0277] 808. If the sending end determines that the second authentication code calculated by the sending end is equal to the second authentication code calculated by the receiving end, then the session key negotiation is considered successful.

[0278] If the sending end determines that the second authentication code calculated by the sending end is equal to the second authentication code calculated by the receiving end, then the session key negotiation is considered successful, and the content encryption odd key, content encryption even key, and authorization information HMAC key can be used as the session key. Subsequently, the sending end can also send a ninth message to the receiving end to inform the receiving end that the content encryption odd key and content encryption even key can be used to decrypt the content, that is, to use the content encryption odd key, content encryption even key, and authorization information HMAC key as the session key.

[0279] If the sending end determines that the second authentication code calculated by the sending end is not equal to the second authentication code calculated by the receiving end, step 801 is executed again. The sending end can execute this step 8 times. If it still fails, the authentication status of the receiving end is recorded as session key negotiation failure, the session key negotiation is terminated, and the authentication key exchange process is restarted.

[0280] After completing the session key negotiation process, the sending end needs to complete authorization control before sending the audio and video streams to the receiving end. After completing authorization control, the sending end can also send authorization information to the receiving end, enabling the receiving end to complete authorization control over the next-level device. The following will combine... Figure 9 The aforementioned authorization control process will be explained. Figure 9 For another flowchart illustrating the content transmission protection method provided in this application embodiment, please refer to [link / reference]. Figure 9 The method includes:

[0281] 901. If the sending end and the receiving end have completed the authorization of a certain audio or video stream, then calculate the third authentication code;

[0282] After completing the session key negotiation process, the sending end can exercise authorization control over a specific audio / video stream on the receiving end. Specifically, when the sending end needs to transmit an audio / video stream to the receiving end, it can first verify the receiving end's permissions based on the authorization control information of that audio / video stream. The receiving end's permissions include: the receiving end's security level, the number of copies allowed, the retention time for the content, the concatenation depth, and the number of devices connected to the receiving end. Specifically, if the sending end determines that the receiving end's security level is greater than or equal to its own security level, the number of copies allowed (i.e., the number of times the receiving end can copy the audio / video stream) is less than or equal to the copy limit, the retention time for the audio / video stream is less than or equal to a preset retention time, the concatenation depth is less than or equal to the maximum concatenation depth, and the number of devices connected to the receiving end is less than or equal to the maximum number supported by the receiving end's current level, then the sending end's permissions are successfully verified.

[0283] After the sending end successfully verifies the receiving end's permissions, it is equivalent to authorizing the receiving end regarding the audio and video stream (i.e., authorization control). At this point, the sending end can transmit the audio and video stream to the receiving end. It should be noted that since the audio and video stream transmission channel is uniquely bound to the audio and video stream, the sending end must transmit the audio and video stream on the corresponding audio and video stream transmission channel.

[0284] If the sending end fails to verify the receiving end's permissions, it is equivalent to the receiving end not having completed the authorization for the audio and video stream, and therefore the audio and video stream will not be transmitted to the receiving end.

[0285] It should be understood that if the sending end needs to transmit additional audio and video streams to the receiving end, the above operation can be repeated, which will not be elaborated here.

[0286] After the sending end completes the authorization control of a certain audio or video stream to the receiving end, it can also send the authorization information of the audio or video stream to the receiving end, so that the receiving end can complete the authorization control of the audio or video stream to the next level device, and thus the receiving end can transmit the audio or video stream to the next level device.

[0287] Specifically, after the sending end successfully verifies the receiving end's permissions, it can first obtain the authorization information of the audio and video stream: the corresponding audio and video stream transmission channel (streamChannelId), rights control information (RCI), current concatenation depth, current request sequence number (seqNum), and the authorization information HMAC key (rcMacKey) cached by the sending end. The rights control information is shown in Table 11.

[0288] Table 11 Authorization Control Information

[0289]

[0290] The definitions of security levels are shown in Table 12:

[0291] Table 12 Security Levels

[0292]

[0293] In the authorization information of this audio / video stream, the corresponding audio / video stream transmission channel is used to indicate the audio / video stream (because the audio / video stream transmission channel is uniquely bound to the audio / video stream). Therefore, after receiving the authorization control information, the receiving end can determine the correspondence between the authorization control information and the audio / video stream based on the corresponding audio / video stream transmission channel, and thus perform authorization control on the next-level device based on the authorization control information corresponding to the audio / video stream. The current concatenation depth refers to the concatenation depth of the sending end. Generally, the current concatenation depth of the sending end can be set to 1, and the concatenation depth of each subsequent device can be incremented by 1. For the first authorization control after authentication and key negotiation (i.e., the authorization control of the first audio / video stream), the sequence number of the current request is initialized to 1. In subsequent new authorization controls (i.e., the authorization control of other audio / video streams), the sequence number of the current request can be incremented by 1 from the sequence number cached locally at the sending end.

[0294] Then, the sender can calculate the third authentication code (k=HMAC(sessionId || streamChannelId ||RCI||depth||seqNum, rcMacKey)) based on the current session identifier, the authorization information of the audio and video stream (i.e. the channel of the audio and video stream transmission, authorization control information, current concatenation depth, and current request sequence number) and the authorization information HMAC key cached by the sender.

[0295] 902. The sending end sends the tenth message to the receiving end. The tenth message includes the current session identifier, the authorization information of the audio and video stream, and the third authentication code calculated by the sending end.

[0296] After calculating the third authentication code, the sending end can generate the tenth message (RC_POLICY) based on the current session identifier, the authorization information of the audio / video stream (the channel for audio / video stream transmission, authorization control information, current concatenation depth, and current request sequence number), and the third authentication code calculated by the sending end. The following describes the fields of the tenth message in conjunction with Table 13, as shown in Table 13:

[0297] Table 13 RC_POLICY

[0298]

[0299] Upon receiving the tenth message, the sending end will send the tenth message to the receiving end.

[0300] It is worth noting that if the sending end needs the receiving end to perform authorization control on multiple audio and video streams at the next level of the receiving end, it needs to send authorization information for these audio and video streams to the receiving end. That is, the sending end needs to execute steps 901 to 908 multiple times. In other words, the sending end may send multiple tenth information messages to the receiving end simultaneously. For example, the sending end sends two tenth information messages to the receiving end simultaneously. The first tenth information message contains the audio and video stream transmission channel and authorization control information corresponding to audio and video stream A, and the second tenth information message contains the audio and video stream transmission channel and authorization control information corresponding to audio and video stream B. Then, the receiving end can determine that the authorization control information in the first tenth information message corresponds to audio and video stream A based on the audio and video stream transmission channel corresponding to audio and video stream A, and can determine that the authorization control information in the second tenth information message corresponds to audio and video stream B based on the audio and video stream transmission channel corresponding to audio and video stream B.

[0301] 903. The receiving end calculates the third authentication code and checks whether the third authentication code calculated by the sending end and the third authentication code calculated by the receiving end are the same.

[0302] After receiving the tenth message, the receiving end can verify the session identifier in the tenth message. After verification, it can check whether the sequence number of the current request is greater than or equal to the sequence number cached by the receiving end. If so, it calculates the third authentication code (k=HMAC(sessionId || streamChannelId ||RCI||depth||seqNum, rcMacKey) based on the current session identifier, the authorization information of the audio and video stream (i.e., the channel of the audio and video stream transmission, authorization control information, current concatenation depth, and sequence number of the current request) and the authorization information HMAC key cached by the receiving end.

[0303] Then, the receiving end checks whether the third authentication code calculated by the sending end and the third authentication code calculated by the receiving end are the same.

[0304] If the sequence number requested by the receiver is less than the sequence number already cached by the receiver, an error message is returned to the sender to inform the sender that the authorized sequence number is incorrect.

[0305] 904. If the receiving end determines that the third authentication code calculated by the sending end is the same as the third authentication code calculated by the receiving end, then the fourth authentication code is calculated.

[0306] If the receiving end determines that the third authentication code calculated by the sending end is the same as the third authentication code calculated by the receiving end, then it calculates the fourth authentication code based on the current session identifier, the authorization information of the audio / video stream (i.e., the channel for audio / video stream transmission, authorization control information, current concatenation depth, and sequence number of the current request), and the cached authorization information HMAC key (p=HMAC(sessionId|| streamChannelId ||RCI||depth||(seqNum+1), rcMacKey)). It should be understood that (seqNum+1) is the sequence number of the current request after incrementing by one.

[0307] If the receiving end determines that the third authentication code calculated by the sending end is different from the third authentication code calculated by the receiving end, it returns an error message to the sending end to inform the sending end of the authorization error.

[0308] 905. The receiving end sends the eleventh message to the sending end. The eleventh message includes the current session identifier and the fourth verification code calculated by the receiving end.

[0309] After calculating the fourth authentication code, the sending end can generate the eleventh message (RC_POLICY_ACK) based on the current session identifier, the authorization information of the audio / video stream (the transmission channel of the audio / video stream, authorization control information, current concatenation depth, and current request sequence number), and the fourth authentication code calculated by the sending end. The following describes the fields of the eleventh message in conjunction with Table 14, as shown in Table 14:

[0310] Table 14 RC_POLICY_ACK

[0311]

[0312] Upon receiving the eleventh message, the receiving end sends the eleventh message back to the sending end.

[0313] 906. The sending end calculates the fourth authentication code and checks whether the fourth authentication code calculated by the sending end and the fourth authentication code calculated by the receiving end are the same.

[0314] After receiving the eleventh message, the sending end can verify the session identifier in the eleventh message. After verification, it can calculate the fourth authentication code (p=HMAC(sessionId|| streamChannelId ||RCI||depth||(seqNum+1),rcMacKey)) based on the current session identifier, the authorization information of the audio and video stream (i.e., the channel of the audio and video stream transmission, authorization control information, current concatenation depth, and current request sequence number) and the cached authorization information HMAC key.

[0315] Then, the sending end checks whether the fourth authentication code calculated by the sending end and the fourth authentication code calculated by the receiving end are the same.

[0316] 907. If the sending end determines that the fourth authentication code calculated by the sending end and the fourth authentication code calculated by the receiving end are the same, then cache the current session identifier and the sequence number of the current request.

[0317] If the sending end determines that the fourth authentication code calculated by the sending end and the fourth authentication code calculated by the receiving end are the same, then it confirms that the transmission of authorization information is complete and caches the current session identifier (sessionId) and the sequence number of the current request (seqNum). In addition, the sending end can also send a twelfth message to the receiving end to inform the receiving end that the transmission of authorization information is complete.

[0318] If the sending end determines that the fourth authentication code calculated by the sending end and the fourth authentication code calculated by the receiving end are different, then the current status is determined to be an authorization error, and the process is stopped.

[0319] 908. The receiving end caches the current session identifier, the audio / video stream transmission channel corresponding to the audio / video stream, the authorization control information, and the updated current concatenation depth.

[0320] After receiving the twelfth message, the receiving end can increment the current concatenation depth by 1 to obtain the updated current concatenation depth (depth+1), which is the receiving end's concatenation depth. Then, the receiving end can cache the current session identifier, the audio / video stream transmission channel corresponding to the audio / video stream, the authorization control information, and the updated current concatenation depth.

[0321] Since the receiving end has successfully obtained the authorization information of the audio and video stream, if the receiving end is connected to a next-level device, it can verify the permissions of the next-level device based on the authorization control information (refer to step 901, which will not be repeated here). After successful verification, it is equivalent to completing the authorization of the audio and video stream, and then the audio and video stream can be transmitted to the next-level device through the audio and video stream transmission channel corresponding to the audio and video stream.

[0322] Furthermore, if the sending end is a transmitter (i.e., a primary device), the content licensing system calls the transmitter's licensing interface to send the audio and video stream licensing control information to the transmitter. The transmitter receives the audio and video stream licensing control information from the content licensing system through the licensing interface, performs licensing control on the audio and video stream at the receiving end based on this information, and sends the licensing information to the receiving end's downstream devices. If the sending end is a repeater (i.e., a non-primary device), the audio and video stream licensing control information comes from the sending end's upstream device.

[0323] Furthermore, to prevent the receiving end from receiving audio and video streams from the sending end beyond its range, the sending end needs to check the legitimacy of the receiving end's location. Figure 9 In the embodiment shown, the time from the sending end sending the tenth message (RC_POLICY) to receiving the eleventh message (RC_POLICY_ACK) does not exceed the minimum authorized sending time allowed by the interface (this time needs to be set according to the specific interface performance). That is, the location check of the receiving end passes. Otherwise, it needs to be retried, with a maximum of 8 retries. If it still fails, the current status is recorded as location check error, and the encryption and sending of audio and video streams are stopped, that is, the process is stopped.

[0324] Furthermore, the version of the authorization control message can be continuously upgraded according to business needs, but higher versions need to be backward compatible and compatible with lower versions.

[0325] After the authorization control process is completed, the sending end can initiate the content encryption process. Specifically, the sending end can use the content encryption key negotiated during the session key negotiation process to encrypt the audio and video streams transmitted in the link, and the receiving end can use the content encryption key to decrypt the audio and video streams.

[0326] In the content encryption process, the sending end can first generate an encrypted information header (HTCP header) and send it to the receiving end together with the encrypted data frame. The encrypted data frame contains data from at least one audio or video stream. Figure 10 A schematic diagram of the structure of a data frame provided in an embodiment of this application, as shown below. Figure 10 As shown, when the sending end sends encrypted data to the receiving end, assume that the sending end needs to send N audio and video streams (e.g., ...) to the receiving end. Figure 10 In this context, streamChannelId1 corresponds to audio / video stream 1, streamChannelId2 corresponds to audio / video stream 2, ..., streamChannelIdN corresponds to audio / video stream N. Data from N audio / video streams can be set in the same data frame and sent together to the receiving end.

[0327] The field definitions of the encrypted header are shown in Table 15:

[0328] Table 15 Encrypted Header

[0329]

[0330] After determining the encryption header, the encryption method, encryption algorithm, encryption mode, and Counter in the encryption header can be used to encrypt the audio and video stream data.

[0331] It is worth noting that after successfully authenticating the receiver, the sender can check whether the update time (thisUpdate) field of the locally stored revocation list is greater than the update time (crlThisUpdate) field of the receiver's revocation list obtained during the authentication process. In other words, it can determine whether a version update is needed. If so, the sender needs to send a revocation list update message to the receiver to update the receiver's revocation list.

[0332] The content authorization system can call the sender's revocation list update interface to update the revocation list, and can send it at any time.

[0333] The cancellation list update process can be implemented asynchronously during the hierarchical update process to ensure the performance of the transmission.

[0334] During the process of distributing the revocation list level by level, if the revocation list stored locally at the receiving end is newer than the received revocation list, the local revocation list is not updated, but it needs to be sent to the next-level device. After the revocation list is updated, it needs to be stored in local non-volatile storage.

[0335] After the revocation list is updated, the receiving end needs to re-verify whether the certificate of the lower-level device has been revoked using the revocation list. If the authentication of the lower-level device's certificate fails, it needs to stop sending audio and video streams to the lower level.

[0336] Before leaving the factory, the equipment should be added to the latest cancellation list.

[0337] The following will combine Figure 11 The process of updating the cancellation list is introduced. Figure 11 Another flowchart illustrating the content transmission protection method provided in this application embodiment is shown below. Figure 11 As shown, the method includes:

[0338] 1101. The sending end sends the thirteenth message to the receiving end. The thirteenth message includes the latest cancellation list.

[0339] After authentication is complete, the sender can send a thirteenth message (CRL_UPDATE, i.e., the aforementioned revocation list update message) to the receiver. This message includes the latest revocation list (i.e., the sender's revocation list). The thirteenth message is described below with reference to Table 16, as shown in Table 16:

[0340] Table 16 CRL_UPDATE

[0341]

[0342] 1102. The receiving end checks whether the update time of the latest cancellation list is greater than the update time of the local cancellation list.

[0343] After receiving the latest revocation list, the receiving end can use the certificate chain to verify the signature of the revocation list and check whether the update time of the latest revocation list is greater than the update time of the local revocation list.

[0344] 1103. If the receiving end determines that the update time of the latest cancellation list is greater than the update time of the local cancellation list, then the latest cancellation list will replace the local cancellation list.

[0345] If the receiving end determines that the update time of the latest revocation list is greater than the update time of the local revocation list, it replaces the local revocation list with the latest one, i.e., it updates the revocation list. If the receiving end is also connected to a downstream device, it can also use the revocation list to verify whether the downstream device's certificate has been revoked after updating the revocation list.

[0346] If the receiving end determines that the update time of the latest revocation list is not greater than the update time of the local revocation list, it returns an error message to the sending end to inform it of the revocation list error. The sending end can then re-execute step 1101, attempting a maximum of 8 times. If it still fails, the process stops.

[0347] 1104. The receiving end sends the fourteenth message to the sending end. The fourteenth message is used to indicate that the revocation list of the receiving end has been updated successfully.

[0348] The following section describes the fourteenth message (CRL_UPDATE_ACK) in conjunction with Table 17, as shown in Table 17:

[0349] Table 17 CRL_UPDATE_ACK

[0350]

[0351] In addition, Figures 6 to 11 In the illustrated embodiment, the fields of the error message (ERROR_ACK) are shown in Table 18:

[0352] Table 18 ERROR_ACK

[0353]

[0354] The states corresponding to each value of the error code are shown in Table 19:

[0355] Table 19 Error Codes

[0356]

[0357] In this embodiment, the authentication key exchange process and session key negotiation process between the sending end and the receiving end are implemented during the establishment of the transmission link between the sending end and the receiving end, while the authorization control process and audio / video stream transmission process between the sending end and the receiving end are implemented after the transmission link between the sending end and the receiving end is established. Therefore, in this application, the authentication process and the audio / video stream transmission process between the sending end and the receiving end can be implemented at different time periods, and are two independent processes. Thus, the authentication process between the sending end and the receiving end is not accompanied by the transmission of audio / video streams, which can avoid audio / video stream leakage.

[0358] Furthermore, this embodiment also has the following advantages: (1) Distributed authentication, each device group can complete independent authentication, and each device can independently authorize the next level device, and supports authorization control for local content usage, making the model simpler and easier to implement and promote; (2) Supports authorization based on transmitted audio and video streams and content encryption based on links, which can ensure authorization granularity while supporting encryption after multiplexing of multiple streams; (3) Authentication and key negotiation are implemented when the device connection is established, and no re-authentication is required before content transmission, resulting in better performance; (4) Identity authentication and key negotiation, revocation list update, and authorization control between upstream and downstream devices are independent and asynchronous operations, resulting in better performance; 5) More flexible authorization: In addition to supporting authorization controls such as location check, version, copy limit, retention time, maximum cascading depth, and the maximum number of connected devices supported per level, it also supports security level control, which makes it easy to restrict receiving devices according to the security level of the content, effectively improving system security; (5) Authorization sending and confirmation mechanism to ensure that the receiving end receives the authorization correctly and improve authorization security; (6) Content encryption supports independent encryption of data frames, solves the problem of frame synchronous decryption, and provides a better user experience; supports key transformation, which provides higher security; supports CTR model encryption and supports parallel encryption and decryption by hardware algorithm engine, which provides better performance; (7) Supports adaptive algorithm system based on the certificate type of the receiving end.

[0359] The above is a detailed description of the content transmission protection method provided in the embodiments of this application. The following will introduce the content transmission protection apparatus provided in the embodiments of this application. Figure 12 A schematic diagram of the structure of the content transmission protection device provided in the embodiments of this application is shown below. Figure 12 As shown, the device includes:

[0360] The authentication module 1201 is used to exchange authentication keys with the receiving end during the establishment of the transmission link between the sending end and the receiving end, and obtain the authentication key.

[0361] The authentication module 1201 is also used to negotiate a session key with the receiving end based on the authentication key to obtain the session key;

[0362] The authorization module 1202 is used to perform authorization control on the receiving end after the transmission link between the sending end and the receiving end is established;

[0363] The encryption module 1203 is also used to send an encrypted audio and video stream to the receiving end after the sending end completes the authorization control of the receiving end. The encrypted audio and video stream is encrypted based on the session key.

[0364] In one possible implementation, the authentication module 1201 is specifically used for:

[0365] Send the first message to the receiving end; the first message is used to request authentication.

[0366] Receive a second message from the receiving end. The second message includes a signature and an authentication hash message authentication code (hmac) calculated by the receiving end. The signature is used to indicate the identity of the receiving end.

[0367] Calculate the authentication key, and calculate the authentication HMAC based on the authentication key calculated by the sender;

[0368] If it is determined that the authentication HMAC calculated by the sender is equal to the authentication HMAC calculated by the receiver, then verify the signature;

[0369] If the signature verification is successful, the authentication key authentication code is calculated based on the authentication key calculated by the sender.

[0370] A third message is sent to the receiving end, which includes the authentication key and authentication code calculated by the sending end.

[0371] In one possible implementation, the first message includes a list of version numbers, and the second message also includes the receiver's version number and the update time of the receiver's revocation list. The receiver's version number is located in the version number list. The authentication module 1201 is specifically used for:

[0372] The authentication HMAC is calculated based on the receiver's version number, the update time of the receiver's revocation list, and the authentication key calculated by the sender.

[0373] The authentication key and authentication code are calculated based on the version number of the receiving end and the authentication key calculated by the sending end.

[0374] In one possible implementation, the authentication module 1201 is further configured to send a revocation list update message to the receiving end when it determines that the update time of the revocation list at the sending end is different from the update time of the revocation list at the receiving end. The revocation list update message includes the revocation list of the sending end.

[0375] In one possible implementation, the authorization module 1202 is specifically used for:

[0376] Obtain the authorization control information corresponding to the audio and video streams;

[0377] Based on the authorization control information corresponding to the audio and video streams, authorization control is performed on the receiving end on a per-stream basis. The authorization control information includes security level, copying restrictions, retention time, maximum cascading depth, and the maximum number of connected devices supported by each level of device.

[0378] In one possible implementation, the authorization module 1202 is further configured to send a tenth message to the receiving end. The tenth message includes an audio / video stream transmission channel identifier corresponding to the audio / video stream and authorization control information corresponding to the audio / video stream. The audio / video stream transmission channel identifier is used to indicate the audio / video stream transmission channel corresponding to the audio / video stream. The tenth message is used to instruct the receiving end to perform authorization control on the next-level device of the receiving end based on the audio / video stream transmission channel corresponding to the audio / video stream and the authorization control information corresponding to the audio / video stream.

[0379] In one possible implementation, the encryption module 1203 is specifically used to send encrypted data to the receiving end. The encrypted data includes an encryption header and at least one encrypted audio / video stream. The at least one encrypted audio / video stream is set on a per-audio / video stream transmission channel basis. The encryption header includes an encryption header version, encryption method indicator value, encryption algorithm indicator value, encryption mode, reserved fields, and a counter.

[0380] In one possible implementation, the first message also includes: the current session identifier, the sender's identifier, a list of public keys, and a fast authentication identifier, which is used to instruct the receiver to enter the fast authentication process or the normal authentication process.

[0381] In one possible implementation, the second message also includes: the current session identifier, the receiver's public key, the receiver's device certification authority (CA) certificate, and the receiver's device certificate.

[0382] In one possible implementation, the session key includes a content encryption odd key and a content encryption even key, wherein the content encryption odd key or the content encryption even key is used to encrypt the audio and video streams.

[0383] Figure 13 Another structural schematic diagram of the content transmission protection device provided in the embodiments of this application is shown below. Figure 13 As shown, the device includes:

[0384] The authentication module 1301 is used to exchange authentication keys with the sending end during the establishment of the transmission link between the sending end and the receiving end, and obtain the authentication key.

[0385] The authentication module 1301 is also used to negotiate a session key with the sender based on the authentication key to obtain the session key;

[0386] The authorization module 1302 is used to respond to the authorization control of the sending end after the transmission link between the sending end and the receiving end is established;

[0387] The decryption module 1303 is used to receive the encrypted audio and video stream from the sending end after the sending end completes the authorization control of the receiving end. The encrypted audio and video stream is encrypted based on the session key.

[0388] In one possible implementation, the authentication module 1301 is specifically used for:

[0389] Receive the first message from the sender; the first message is used to request authentication.

[0390] Calculate the signature and authentication key, and calculate the authentication HMAC based on the authentication key calculated by the receiving end;

[0391] A second message is sent to the sender. The second message includes a signature and an authentication HMAC calculated by the receiver. The signature is used to indicate the identity of the receiver.

[0392] Receive a third message from the sender, the third message including the authentication key / authentication code calculated by the sender;

[0393] Calculate the authentication key and authentication code based on the authentication key calculated by the receiver;

[0394] If it is determined that the authentication key / authentication code calculated by the sender and the authentication key / authentication code calculated by the receiver are equal, then the authentication key calculated by the receiver is cached.

[0395] In one possible implementation, the first message includes a list of version numbers, and the authentication module 1301 is specifically used to calculate a signature based on the version number of the receiver and the update time of the receiver's revocation list if it is determined that the version number of the receiver is in the list of version numbers.

[0396] In one possible implementation, the authentication module 1301 is specifically used for:

[0397] The authentication HMAC is calculated based on the receiver's version number, the update time of the receiver's revocation list, and the authentication key calculated by the receiver.

[0398] The authentication key and authentication code are calculated based on the version number of the receiving end and the authentication key calculated by the receiving end.

[0399] In one possible implementation, the authentication module 1301 is further used for:

[0400] Receive a cancellation list update message from the sender, which includes the sender's cancellation list;

[0401] Replace the sender's cancellation list with the receiver's cancellation list;

[0402] The sender's revocation list is used to verify the certificates of the next-level devices at the receiving end.

[0403] In one possible implementation, the authorization module 1302 is specifically used to respond to the authorization control information corresponding to the audio and video streams from the sending end. The authorization control is based on the audio and video streams and includes security level, copying limit, retention time, maximum cascading depth, and the maximum number of connected devices supported by each level of the device.

[0404] In one possible implementation, the authorization module 1302 is further configured to:

[0405] Receive the tenth message from the sender. The tenth message includes the audio and video stream transmission channel identifier corresponding to the audio and video stream and the authorization control information corresponding to the audio and video stream. The audio and video stream transmission channel identifier is used to indicate the audio and video stream transmission channel corresponding to the audio and video stream.

[0406] Based on the audio and video stream transmission channels corresponding to the audio and video streams and the corresponding authorization control information, authorization control is performed on the next-level devices of the receiving end on a per-audio and video stream basis.

[0407] In one possible implementation, the decryption module 1303 is specifically used to receive encrypted data from the sending end. The encrypted data includes an encrypted header and at least one encrypted audio / video stream. The encrypted audio / video stream is set on a per-audio / video stream transmission channel basis. The encrypted header includes an encrypted header version, an encryption method indicator value, an encryption algorithm indicator value, an encryption mode, a reserved field, and a counter.

[0408] In one possible implementation, the first message also includes: the current session identifier, the sender's identifier, a list of public keys, and a fast authentication identifier, which is used to instruct the receiver to enter the fast authentication process or the normal authentication process.

[0409] In one possible implementation, the second message also includes: the current session identifier, the receiver's public key, the receiver's device certification authority (CA) certificate, and the receiver's device certificate.

[0410] In one possible implementation, the session key includes a content encryption odd key and a content encryption even key, wherein the content encryption odd key or the content encryption even key is used to encrypt the audio and video streams.

[0411] It should be noted that the information interaction and execution process between the modules / units of the above-mentioned device are based on the same concept as the method embodiments of this application, and the resulting technical effects are the same as those of the method embodiments of this application. For details, please refer to the description in the method embodiments shown above in this application, and will not be repeated here.

[0412] This application also relates to a computer-readable storage medium, including instructions that, when executed on a computer, cause the computer to perform actions such as... Figure 6 , Figure 7 , Figure 8 , Figure 9 as well as Figure 11 The method shown.

[0413] This application also relates to a computer program product containing instructions that, when run on a computer, cause the computer to perform actions such as... Figure 6 , Figure 7 , Figure 8 , Figure 9 as well as Figure 11 The method shown.

[0414] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0415] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0416] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0417] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0418] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for content transmission protection, characterized in that, The method includes: During the establishment of the transmission link between the sending end and the receiving end, the sending end and the receiving end exchange authentication keys to obtain the authentication key; The sending end negotiates a session key with the receiving end based on the authentication key to obtain a session key; After the transmission link between the sending end and the receiving end is established, the sending end performs authorization control on the receiving end; After the sending end completes the authorization control of the receiving end, the sending end sends an encrypted audio and video stream to the receiving end, and the encrypted audio and video stream is encrypted based on the session key.

2. The method according to claim 1, characterized in that, The sending end and the receiving end exchange authentication keys to obtain authentication keys, including: The sending end sends a first message to the receiving end, the first message being used to request authentication; The sending end receives a second message from the receiving end, the second message including a signature and an authentication hash message authentication code (hmac) calculated by the receiving end, the signature being used to indicate the identity of the receiving end; The sending end calculates the authentication key and calculates the authentication HMAC based on the authentication key calculated by the sending end; If the sending end determines that the authentication HMAC calculated by the sending end is equal to the authentication HMAC calculated by the receiving end, then the signature is verified; If the sending end successfully verifies the signature, then the authentication key authentication code is calculated based on the authentication key calculated by the sending end. The sending end sends a third message to the receiving end, the third message including the authentication key and authentication code calculated by the sending end.

3. The method according to claim 2, characterized in that, The first message includes a list of version numbers, and the second message also includes the version number of the receiving end and the update time of the revocation list of the receiving end, wherein the version number of the receiving end is located in the list of version numbers, and the calculation of the authentication HMAC based on the authentication key calculated by the sending end includes: The authentication HMAC is calculated based on the version number of the receiving end, the update time of the revocation list of the receiving end, and the authentication key calculated by the sending end. The process of calculating the authentication key and authentication code based on the authentication key calculated by the sending end includes: The authentication key authentication code is calculated based on the version number of the receiving end and the authentication key calculated by the sending end.

4. The method according to claim 3, characterized in that, After the authentication key exchange between the sending end and the receiving end is successful, the method further includes: When the sending end determines that the update time of the sending end's revocation list is different from the update time of the receiving end's revocation list, it sends a revocation list update message to the receiving end, and the revocation list update message includes the revocation list of the sending end.

5. The method according to any one of claims 1 to 4, characterized in that, The first message also includes: the current session identifier, the sender's identifier, a public key list, and a fast authentication identifier, wherein the fast authentication identifier is used to instruct the receiver to enter the fast authentication process or the normal authentication process.

6. The method according to any one of claims 1 to 5, characterized in that, The second message also includes: the current session identifier, the public key of the receiving end, the CA certificate of the receiving end, and the device certificate of the receiving end.

7. The method according to any one of claims 1 to 6, characterized in that, The session key includes a content encryption odd key and a content encryption even key, wherein the content encryption odd key or the content encryption even key is used to encrypt the audio and video streams.

8. The method according to claims 1 to 7, characterized in that, The authorization control of the receiving end by the sending end includes: The sending end obtains the authorization control information corresponding to the audio and video streams; The sending end performs authorization control on the receiving end based on the authorization control information corresponding to the audio and video streams, with each audio and video stream as a unit. The authorization control information includes security level, copying restrictions, retention time, maximum cascading depth, and the maximum number of connected devices supported by each level of device.

9. The method according to claim 8, characterized in that, After the sending end performs authorization control on the audio and video streams to the receiving end, the method further includes: The sending end sends a tenth message to the receiving end. The tenth message includes the identifier of the audio and video stream transmission channel corresponding to the audio and video stream and the authorization control information corresponding to the audio and video stream. The identifier of the audio and video stream transmission channel is used to indicate the audio and video stream transmission channel corresponding to the audio and video stream. The tenth message is used to instruct the receiving end to perform authorization control on the next-level device of the receiving end based on the audio and video stream transmission channel corresponding to the audio and video stream and the authorization control information corresponding to the audio and video stream.

10. The method according to claim 9, characterized in that, The sending end sends the encrypted audio and video stream to the receiving end, including: The sending end sends encrypted data to the receiving end. The encrypted data includes an encrypted header and at least one encrypted audio / video stream. The encrypted audio / video stream is set on a per-audio / video stream transmission channel basis. The encrypted header includes an encrypted header version, an encryption method indicator value, an encryption algorithm indicator value, an encryption mode, a reserved field, and a counter.

11. A method for content transmission protection, characterized in that, The method includes: During the establishment of the transmission link between the sending end and the receiving end, the receiving end and the sending end exchange authentication keys to obtain the authentication key; The receiving end negotiates a session key with the sending end based on the authentication key to obtain a session key; After the transmission link between the sending end and the receiving end is established, the receiving end responds to the authorization control of the sending end; After the sending end completes the authorization control of the receiving end, the receiving end receives the encrypted audio and video stream from the sending end, and the encrypted audio and video stream is encrypted based on the session key.

12. The method according to claim 11, characterized in that, The receiving end and the sending end exchange authentication keys to obtain authentication keys, including: The receiving end receives a first message from the sending end, the first message being used to request authentication; The receiving end calculates the signature and authentication key, and calculates the authentication HMAC based on the authentication key calculated by the receiving end; The receiving end sends a second message to the sending end, the second message including the signature and the authentication HMAC calculated by the receiving end, the signature being used to indicate the identity of the receiving end; The receiving end receives a third message from the sending end, the third message including the authentication key and authentication code calculated by the sending end; The receiving end calculates the authentication key authentication code based on the authentication key calculated by the receiving end; If the receiving end determines that the authentication key / authentication code calculated by the sending end and the authentication key / authentication code calculated by the receiving end are equal, then the authentication key calculated by the receiving end is cached.

13. The method according to claim 12, characterized in that, The first message includes a list of version numbers, and the receiving end calculates the signature including: If the receiving end determines that its version number is in the version number list, then it calculates a signature based on the version number of the receiving end and the update time of the revocation list of the receiving end.

14. The method according to claim 13, characterized in that, The calculation of the authentication HMAC based on the authentication key calculated by the receiving end includes: The authentication HMAC is calculated based on the version number of the receiving end, the update time of the revocation list of the receiving end, and the authentication key calculated by the receiving end. The process of calculating the authentication key and authentication code based on the authentication key calculated by the receiving end includes: The authentication key authentication code is calculated based on the version number of the receiving end and the authentication key calculated by the receiving end.

15. The method according to claim 13 or 14, characterized in that, After the authentication key exchange between the sending end and the receiving end is successful, the method further includes: The receiving end receives a cancellation list update message from the sending end, the cancellation list update message including the cancellation list of the sending end; The receiving end replaces the sending end's cancellation list with the receiving end's cancellation list; The receiving end uses the revocation list of the sending end to verify the certificate of the next-level device of the receiving end.

16. The method according to any one of claims 11 to 15, characterized in that, The first message also includes: the current session identifier, the sender's identifier, a public key list, and a fast authentication identifier, wherein the fast authentication identifier is used to instruct the receiver to enter the fast authentication process or the normal authentication process.

17. The method according to any one of claims 11 to 16, characterized in that, The second message also includes: the current session identifier, the public key of the receiving end, the CA certificate of the receiving end, and the device certificate of the receiving end.

18. The method according to any one of claims 11 to 17, characterized in that, The session key includes a content encryption odd key and a content encryption even key, wherein the content encryption odd key or the content encryption even key is used to decrypt the encrypted audio and video streams.

19. The method according to any one of claims 11 to 18, characterized in that, The authorization control response from the receiving end to the sending end includes: The receiving end responds to the sending end with authorization control information based on the audio and video streams, and the authorization control is based on the audio and video streams. The authorization control information includes security level, copying limit, retention time, maximum cascading depth, and the maximum number of connected devices supported by each level device.

20. The method according to claim 19, characterized in that, After the receiving end responds to the authorization control of the sending end, the method further includes: The receiving end receives a tenth message from the sending end. The tenth message includes the identifier of the audio and video stream transmission channel corresponding to the audio and video stream and the authorization control information corresponding to the audio and video stream. The identifier of the audio and video stream transmission channel is used to indicate the audio and video stream transmission channel corresponding to the audio and video stream. The receiving end performs authorization control on the next-level device of the receiving end based on the audio and video stream transmission channel corresponding to the audio and video stream and the authorization control information corresponding to the audio and video stream, on a per-audio and video stream basis.

21. The method according to claim 20, characterized in that, The receiving end receives the encrypted audio and video stream from the sending end, including: The receiving end receives encrypted data from the sending end. The encrypted data includes an encrypted header and at least one encrypted audio / video stream. The encrypted audio / video stream is configured on a per-audio / video stream transmission channel basis. The encrypted header includes an encrypted header version, an encryption method indicator value, an encryption algorithm indicator value, an encryption mode, a reserved field, and a counter.

22. A device for content transmission protection, characterized in that, The device includes: The authentication module is used to exchange authentication keys with the receiving end during the establishment of the transmission link between the sending end and the receiving end, and obtain the authentication key. The authentication module is further configured to negotiate a session key with the receiving end based on the authentication key to obtain a session key; The authorization module is used to perform authorization control on the receiving end after the transmission link between the sending end and the receiving end is established; The encryption module is further configured to send an encrypted audio and video stream to the receiving end after the sending end completes the authorization control of the receiving end, wherein the encrypted audio and video stream is encrypted based on the session key.

23. The apparatus according to claim 22, characterized in that, The authentication module is specifically used for: Send a first message to the receiving end, the first message being used to request authentication; Receive a second message from the receiving end, the second message including a signature and an authentication hash message authentication code (hmac) calculated by the receiving end, the signature being used to indicate the identity of the receiving end; Calculate the authentication key, and calculate the authentication HMAC based on the authentication key calculated by the sending end; If it is determined that the authentication HMAC calculated by the sending end is equal to the authentication HMAC calculated by the receiving end, then the signature is verified; If the signature is successfully verified, the authentication key authentication code is calculated based on the authentication key calculated by the sending end. A third message is sent to the receiving end, the third message including the authentication key / authentication code calculated by the sending end.

24. The apparatus according to claim 23, characterized in that, The first message includes a list of version numbers, and the second message also includes the version number of the receiving end and the update time of the revocation list of the receiving end. The version number of the receiving end is located in the list of version numbers. The authentication module is specifically used for: The authentication HMAC is calculated based on the version number of the receiving end, the update time of the revocation list of the receiving end, and the authentication key calculated by the sending end. The authentication key authentication code is calculated based on the version number of the receiving end and the authentication key calculated by the sending end.

25. The apparatus according to claim 24, characterized in that, The authentication module is further configured to send a revocation list update message to the receiving end when it determines that the update time of the revocation list at the sending end is different from the update time of the revocation list at the receiving end. The revocation list update message includes the revocation list of the sending end.

26. The apparatus according to claims 22 to 25, characterized in that, The authorization module is specifically used for: Obtain the authorization control information corresponding to the audio and video streams; Based on the authorization control information corresponding to the audio and video streams, authorization control is performed on the receiving end on a per-audio-video-stream basis. The authorization control information includes security level, copying restrictions, retention time, maximum cascading depth, and the maximum number of connected devices supported by each level of device.

27. The apparatus according to claim 26, characterized in that, The authorization module is further configured to send a tenth message to the receiving end. The tenth message includes an audio / video stream transmission channel identifier corresponding to the audio / video stream and authorization control information corresponding to the audio / video stream. The identifier of the audio / video stream transmission channel is used to indicate the audio / video stream transmission channel corresponding to the audio / video stream. The tenth message is used to instruct the receiving end to perform authorization control on the next-level device of the receiving end based on the audio / video stream transmission channel corresponding to the audio / video stream and the authorization control information corresponding to the audio / video stream, on a per-audio / video stream basis.

28. The apparatus according to claim 27, characterized in that, The encryption module is specifically used to send encrypted data to the receiving end. The encrypted data includes an encryption header and at least one encrypted audio / video stream. The at least one encrypted audio / video stream is set on a per-audio / video stream transmission channel basis. The encryption header includes an encryption header version, encryption method indicator value, encryption algorithm indicator value, encryption mode, reserved fields, and a counter.

29. A device for content transmission protection, characterized in that, The device includes: The authentication module is used to exchange authentication keys with the sending end during the establishment of the transmission link between the sending end and the receiving end, and obtain the authentication key. The authentication module is further configured to negotiate a session key with the sending end based on the authentication key to obtain a session key; The authorization module is used to respond to the authorization control of the sending end after the transmission link between the sending end and the receiving end is established; The decryption module is used to receive an encrypted audio and video stream from the sending end after the sending end completes the authorization control of the receiving end. The encrypted audio and video stream is encrypted based on the session key.

30. The apparatus according to claim 29, characterized in that, The authentication module is specifically used for: Receive a first message from the sending end, the first message being used to request authentication; Calculate the signature and authentication key, and calculate the authentication HMAC based on the authentication key calculated by the receiving end; A second message is sent to the sending end, the second message including the signature and the authentication HMAC calculated by the receiving end, the signature being used to indicate the identity of the receiving end; Receive a third message from the sending end, the third message including the authentication key / authentication code calculated by the sending end; Calculate the authentication key and authentication code based on the authentication key calculated by the receiving end; If it is determined that the authentication key calculated by the sending end and the authentication key calculated by the receiving end are equal, then the authentication key calculated by the receiving end is cached.

31. The apparatus according to claim 30, characterized in that, The first message includes a list of version numbers. Specifically, the authentication module is used to calculate a signature based on the version number of the receiving end and the update time of the revocation list of the receiving end if it is determined that the version number of the receiving end is in the list of version numbers.

32. The apparatus according to claim 31, characterized in that, The authentication module is specifically used for: The authentication HMAC is calculated based on the version number of the receiving end, the update time of the revocation list of the receiving end, and the authentication key calculated by the receiving end. The authentication key authentication code is calculated based on the version number of the receiving end and the authentication key calculated by the receiving end.

33. The apparatus according to claim 31 or 32, characterized in that, The authentication module is also used for: Receive a cancellation list update message from the sender, the cancellation list update message including the cancellation list of the sender; Replace the revocation list of the receiving end with the revocation list of the sending end; The certificate of the next-level device at the receiving end is verified using the revocation list of the sending end.

34. The apparatus according to any one of claims 29 to 33, characterized in that, The authorization module is specifically used to respond to the authorization control information corresponding to the audio and video streams from the sending end. The authorization control is based on the audio and video streams. The authorization control information includes the security level, copying limit, retention time, maximum cascading depth, and the maximum number of connected devices supported by each level device.

35. The apparatus according to claim 34, characterized in that, The authorization module is also used for: The tenth message is received from the sending end. The tenth message includes the audio and video stream transmission channel identifier corresponding to the audio and video stream and the authorization control information corresponding to the audio and video stream. The identifier of the audio and video stream transmission channel is used to indicate the audio and video stream transmission channel corresponding to the audio and video stream. Based on the audio and video stream transmission channel corresponding to the audio and video stream and the authorization control information corresponding to the audio and video stream, authorization control is performed on the next-level device of the receiving end on a per-audio and video stream basis.

36. The apparatus according to claim 35, characterized in that, The decryption module is specifically used to receive encrypted data from the sending end. The encrypted data includes an encrypted header and at least one encrypted audio / video stream. The at least one encrypted audio / video stream is set on a per-audio / video stream transmission channel basis. The encrypted header includes an encrypted header version, an encryption method indicator value, an encryption algorithm indicator value, an encryption mode, a reserved field, and a counter.

37. A device for content transmission protection, characterized in that, include: A processor and a transmission interface, the processor being configured to invoke program instructions stored in memory to perform the method according to any one of claims 1 to 10 or 11 to 21.

38. A computer-readable storage medium, characterized in that, Includes instructions that, when executed on a computer or processor, cause the computer or processor to perform the method as described in any one of claims 1 to 10 or 11 to 21.

39. A computer program product containing instructions, characterized in that, The computer program product includes program instructions that, when executed on a computer or processor, cause the computer or processor to perform the method as described in any one of claims 1 to 10 or 11 to 21.

Images