Method, apparatus, device and medium for verifying a digital content playback device

Abstract

This disclosure provides a method, apparatus, device, and medium for verifying a digital content playback device. The specific implementation scheme is as follows: During the operating system startup process of the digital content playback device, first pre-stored data obtained from the disk of the digital content playback device is stored in a target space of the internal memory; wherein, the first pre-stored data is used to obtain at least a portion of the verification key data corresponding to the digital content playback device, and the verification key data is used for digital content protection verification; the operating system's driver for managing the digital video interface is loaded to obtain the first pre-stored data from the target space; based on the obtained first pre-stored data, the verification key data is determined; in response to receiving a verification request from a digital content source device, digital content protection verification is performed on the digital content playback device based on the verification key data.

Description

Technical Field

[0001] This disclosure relates to the field of digital content transmission technology, and in particular to a method, apparatus, device, and medium for verifying digital content playback devices. Background Technology

[0002] High-bandwidth Digital Content Protection (HDCP) is a technology that protects digital content from unauthorized copying during transmission. Digital content can include, for example, digitized video and audio data. Therefore, how to effectively protect data content by verifying digital content playback devices using HDCP technology is a concern for those skilled in the art. Summary of the Invention

[0003] Embodiments of this disclosure provide a method, apparatus, device, and medium for verifying digital content playback devices.

[0004] According to one aspect of this disclosure, a method for verifying a digital content playback device is provided, applied to the digital content playback device, comprising: during the startup process of the operating system of the digital content playback device, storing first pre-stored data obtained from the disk of the digital content playback device into a target space of internal memory; wherein the first pre-stored data is used to obtain at least a portion of verification key data corresponding to the digital content playback device, the verification key data being used for digital content protection verification; loading a driver of the operating system for managing a digital video interface to obtain the first pre-stored data from the target space; determining verification key data based on the obtained first pre-stored data; and, in response to receiving a verification request from a digital content source device, performing digital content protection verification on the digital content playback device based on the verification key data.

[0005] According to another aspect of this disclosure, an apparatus for verifying a digital content playback device is provided, applied to the digital content playback device, comprising: a storage module, configured to store first pre-stored data obtained from the disk of the digital content playback device into a target space of internal memory during the startup process of the operating system of the digital content playback device; wherein the first pre-stored data is used to obtain at least a portion of verification key data corresponding to the digital content playback device, and the verification key data is used for digital content protection verification; a loading module, configured to load a driver of the operating system for managing digital video interfaces to obtain the first pre-stored data from the target space; a determining module, configured to determine the verification key data based on the obtained first pre-stored data; and a verification module, configured to perform digital content protection verification on the digital content playback device based on the verification key data in response to receiving a verification request from a digital content source device.

[0006] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores a computer program for performing the above-described method for verifying a digital content playback device.

[0007] According to another aspect of this disclosure, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; and a processor for reading executable instructions from the memory and executing the instructions to implement the method described above for verifying a digital content playback device. Attached Figure Description

[0008] Figure 1 This is a schematic diagram of the structure of a digital content playback device in some exemplary embodiments of this disclosure.

[0009] Figure 2 This is a flowchart illustrating a method for verifying a digital content playback device provided by some exemplary embodiments of this disclosure.

[0010] Figure 3 This is a flowchart illustrating a method for obtaining first pre-stored data from a target space, provided by some exemplary embodiments of this disclosure.

[0011] Figure 4 This is a flowchart illustrating a method for determining verification key data provided by some exemplary embodiments of this disclosure.

[0012] Figure 5 This is a flowchart illustrating a method for determining verification key data provided by some other exemplary embodiments of this disclosure.

[0013] Figure 6 This is a flowchart illustrating a data update method provided by some exemplary embodiments of this disclosure.

[0014] Figure 7 This is a flowchart illustrating a method for determining verification key data provided in some exemplary embodiments of this disclosure.

[0015] Figure 8 This is a flowchart illustrating a method for generating a target node in a target region by a driver calling the kernel layer, as provided in some exemplary embodiments of this disclosure.

[0016] Figure 9 This is a flowchart illustrating a method for determining verification key data provided by some exemplary embodiments of this disclosure.

[0017] Figure 10 This is a flowchart illustrating a method for verifying a digital content playback device provided by some other exemplary embodiments of this disclosure.

[0018] Figure 11This is a schematic diagram of the structure of an apparatus for verifying a digital content playback device provided by some exemplary embodiments of this disclosure.

[0019] Figure 12 This is a schematic diagram of a module used to assist in obtaining first pre-stored data from a target space in some exemplary embodiments of this disclosure.

[0020] Figure 13 This is a schematic diagram of the structure of a module defined in some exemplary embodiments of this disclosure.

[0021] Figure 14 This is a schematic diagram of a module used to assist in determining verification key data in some exemplary embodiments of this disclosure.

[0022] Figure 15 This is a schematic diagram of the structure of the generation module in some exemplary embodiments of this disclosure.

[0023] Figure 16 This is a schematic diagram of the structure of a submodule defined in some exemplary embodiments of this disclosure.

[0024] Figure 17 This is a schematic diagram of the structure of an apparatus for verifying a digital content playback device provided by some other exemplary embodiments of this disclosure.

[0025] Figure 18 This is a structural diagram of an electronic device provided by some exemplary embodiments of this disclosure. Detailed Implementation

[0026] To explain this disclosure, exemplary embodiments of the disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the disclosure, and not all of them. It should be understood that the disclosure is not limited to exemplary embodiments.

[0027] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0028] Exemplary Overview

[0029] High-bandwidth digital content protection technology can be used to prevent unauthorized copying of digital content during transmission through a transmission interface. This transmission interface can include, but is not limited to, DisplayPort (DP) and High Definition Multimedia Interface (HDMI). It is understood that both DP and HDMI are high-speed video transmission interfaces.

[0030] In the application of digital content protection technology, digital content can be transmitted between two devices through a transmission interface. The device used to send the digital content can be called the sending end or digital content source device. The device used to receive and play the digital content can be called the receiving end or digital content playback device. For ease of understanding, the device used to send the digital content will be referred to as the digital content source device, and the device used to receive and play the digital content will be referred to as the digital content playback device.

[0031] It should be noted that before transmitting digital content between a digital content source device and a digital content playback device, it is necessary to verify the digital content playback device. How to efficiently and quickly verify digital content playback devices to ensure they can safely and quickly play digital content is a problem worthy of attention for those skilled in the art.

[0032] Exemplary Overview

[0033] To facilitate understanding of the exemplary methods section below, a brief introduction is given first to the types and components of digital content playback devices, the components of the operating system of digital content playback devices, and the types of digital content source devices.

[0034] In some optional embodiments of this disclosure, the digital content playback device may be a head-mounted display device. A head-mounted display device may also be referred to as a head-mounted display (HMD) or head-mounted device. The head-mounted display device may take the form of glasses, a helmet, or the like. The head-mounted display device may include, but is not limited to, augmented reality (AR) glasses, virtual reality (VR) glasses, etc. Optionally, AR glasses and VR glasses may be collectively referred to as smart glasses.

[0035] In some alternative embodiments of this disclosure, such as Figure 1 As shown, a digital content playback device may include a system-on-a-chip (SOC) and a hard disk. The SOC may integrate a video chip and an ephemeral programmable memory (Efuse). The SOC may also encapsulate internal memory. Internal memory may, for example, include Double Data Rate Synchronous Dynamic Random Access Memory (DDR). The hard disk may, for example, include Nand Flash (a type of non-volatile memory). Optionally, in addition to including Nand Flash with storage capabilities, the hard disk may also include a controller with bad block management capabilities.

[0036] In some optional embodiments of this disclosure, the operating system of the digital content playback device may include a kernel layer, drivers, and an application layer. The operating system may be, for example, a Linux operating system. The operating system drivers may include drivers for managing digital video interfaces, and may also include other types of drivers. The digital video interface may be, for example, a DP (Digital Video Interface), and correspondingly, the driver for managing the digital video interface may be called a DP driver. Generally, during the boot process of the operating system on a System-on-a-Chip (SoC), the kernel layer of the operating system may be started first, followed by the drivers, and finally the application layer. For ease of understanding, the following description uses the Linux operating system as an example.

[0037] In some optional embodiments of this disclosure, the digital content source device may include, but is not limited to, mobile phones, tablets, desktop computers, etc. The digital content source device may also be referred to as a host or host terminal.

[0038] In the embodiments of this disclosure, during the operating system startup process on the SOC, first pre-stored data acquired from the disk can be stored in the internal memory. This first pre-stored data can be used to obtain at least a portion of the verification key data corresponding to the digital content playback device. The verification key data can be a set of device keys used for digital content protection verification. Next, the first pre-stored data can be retrieved from the internal memory to determine the verification key data, thus effectively preparing the device key set required for digital content protection verification. If the digital content playback device receives a verification request from the digital content source device, it can perform digital content protection verification based on the prepared device key set. This allows for efficient and rapid verification of the digital content playback device, enabling it to play digital content securely and quickly, thereby improving the user experience.

[0039] Exemplary methods

[0040] Figure 2 This is a flowchart illustrating a method for verifying a digital content playback device provided by some exemplary embodiments of this disclosure. Figure 2 The method shown can be applied to digital content playback devices. Figure 2 The method shown may include steps 210, 220, 230 and 240.

[0041] Step 210: During the startup process of the operating system of the digital content playback device, the first pre-stored data obtained from the disk of the digital content playback device is stored in the target space of the internal memory; wherein, the first pre-stored data is used to obtain at least a portion of the verification key data corresponding to the digital content playback device, and the verification key data is used for digital content protection verification.

[0042] In some optional embodiments of this disclosure, the verification key data corresponding to the digital content playback device can be a set of device keys used for digital content protection verification, which may include both public key data and private key data. Optionally, at least a portion of the verification key data can be pre-written to the disk. Alternatively, at least a portion of the verification key data can be processed according to a certain processing method, and the processed data can be pre-written to the disk. The processing method here may include, but is not limited to, reordering, calculation according to a certain calculation logic, etc. The amount of data pre-written to the disk here may be referred to as the target data amount in the following text.

[0043] It should be noted that whether at least a portion of the verification key data is pre-written to the disk or the processed data is pre-written to the disk, the pre-written data can be retrieved from the disk by reading the disk. The retrieved data can be used as the first pre-stored data for obtaining at least a portion of the verification key data.

[0044] In some alternative embodiments of this disclosure, after the digital content playback device is powered on, it can be started using a fastboot mode. This involves first running the ROM (code that runs immediately after reset or power-on), then running the Secondary Program Loader (SPL), and finally loading the operating system via the SPL to start the operating system. Alternatively, the digital content playback device can be started using a regular boot mode. This involves first running the ROM, then the SPL, then the bootloader (U-Boot), and finally starting the operating system.

[0045] In some alternative embodiments of this disclosure, the target space may be a space in internal memory that is not typically used and is sufficient to hold the first pre-stored data. The startup and subsequent operation of the operating system will not corrupt the target space. During the operating system startup process, the pre-stored data can be read from the disk to retrieve the first pre-stored data and store it in the target space.

[0046] Step 220: Load the operating system's driver for managing the digital video interface to obtain the first pre-stored data from the target space.

[0047] In some optional embodiments of this disclosure, the kernel layer of the operating system may be started first during the operating system startup process. If the kernel layer of the operating system starts successfully, it can load the driver of the operating system for managing the digital video interface. The driver for managing the digital video interface can read the target space to obtain first pre-stored data from the target space. For ease of explanation, the driver for managing the digital video interface may be simply referred to as the driver below. Generally, the internal memory may include space for use by the kernel layer, which may be called kernel space. The driver may be a program running in kernel space.

[0048] Step 230: Based on the acquired first pre-stored data (i.e., the first pre-stored data acquired from the target space), determine the verification key data.

[0049] In some optional embodiments of this disclosure, if the first pre-stored data is the verification key data itself, the driver obtains the first pre-stored data from the target space, which is equivalent to obtaining the verification key data. If the first pre-stored data is data obtained by processing the verification key data according to a certain processing method, the driver can process the first pre-stored data in the reverse manner of the processing method to restore the verification key data. Of course, the method of determining the verification key data based on the first pre-stored data obtained from the target space is not limited to this, and examples will be introduced later.

[0050] Step 240: In response to receiving a verification request from the digital content source device, perform digital content protection verification on the digital content playback device based on the verification key data.

[0051] In some optional embodiments of this disclosure, if digital content needs to be transmitted between the digital content source device and the digital content playback device, the digital content source device can initiate a verification request, and the digital content playback device can receive the verification request from the digital content source device. Based on the verification key data determined in step 230, digital content protection verification can be performed on the digital content playback device. Optionally, the specific method for performing digital content protection verification on the digital content playback device based on the verification key data can refer to the HDCP verification principle in related technologies, and will not be elaborated here.

[0052] In the embodiments of this disclosure, during the operating system startup process of the digital content playback device, the first pre-stored data obtained from the disk can be stored in the target space of the internal memory. Additionally, a driver can be loaded to retrieve the first pre-stored data from the target space. Since the first pre-stored data is used to obtain at least a portion of the verification key data corresponding to the digital content playback device, the verification key data can be determined efficiently and quickly based on the first pre-stored data obtained from the target space. This is equivalent to preparing the device key set required for digital content protection verification. If digital content needs to be transmitted between the digital content source device and the digital content playback device, digital content protection verification can be performed on the digital content playback device based on the prepared device key set. This solution performs HDCP verification during the operating system startup process, which can efficiently and quickly verify the digital content playback device, enabling the digital content playback device to play digital content securely and quickly, thus improving the user experience.

[0053] It is understood that the scheme disclosed in the above embodiments can obtain the verification key data from the disk during the startup process of the operating system of the digital content playback device, instead of configuring the verification key data or related key data in the operating system. This ensures that different digital content playback devices use different key data for verification, thus guaranteeing the reliability of the digital content playback device.

[0054] In some optional examples, the initial pre-stored data to the target space can be retrieved from the disk by a secondary program loader used to load the operating system.

[0055] As described above, at least a portion of the verification key data can be pre-written to disk. Alternatively, at least a portion of the verification key data can be processed according to a certain method, and the processed data can be pre-written to disk. Optionally, a partition (hereinafter referred to as the cert partition) can be pre-allocated on the disk to store the pre-written data. The secondary program loader can read the cert partition to obtain the pre-written data, which can be used as the first pre-stored data. This first pre-stored data can then be stored in the target space. The target space can correspond to an address range, and the first pre-stored data can be stored starting from the first address of this address range.

[0056] Figure 3 This is a flowchart illustrating a method for obtaining first pre-stored data from a target space, provided by some exemplary embodiments of this disclosure. Figure 3 The method shown may include steps 310, 320, and 330. Optionally, a combination of steps 320 and 330 may be used as an alternative implementation of step 220 of this disclosure.

[0057] Step 310: The address information of the target space is transmitted to the kernel layer of the operating system through the secondary program loader.

[0058] In some optional embodiments of this disclosure, the secondary program loader can determine the address information of the target space. As an example, the address information of the target space can be the starting address of the address range corresponding to the target space. Alternatively, the address information of the target space can be the address range corresponding to the target space. The secondary program loader can pass the address information of the target space to the kernel layer of the operating system as a parameter.

[0059] Step 320: Load the operating system's driver for managing the digital video interface.

[0060] Step 330: Based on the address information transmitted to the kernel layer, the driver obtains the first pre-stored data from the target space.

[0061] In some optional embodiments of this disclosure, the driver can be loaded by the kernel layer. Since the driver can run in kernel space (i.e., the space in internal memory used by the kernel layer), the driver can easily obtain the address information transferred to the kernel layer by the secondary program loader. Based on the address information, the driver can obtain the first pre-stored data from the target space. For example, if the address information is an address range corresponding to the target space, the first pre-stored data can be read according to the address range. If the address information is the starting address of the address range corresponding to the target space, reading can start from the starting address until the target amount of data is read, thus obtaining the first pre-stored data.

[0062] In the embodiments of this disclosure, the secondary program loader can not only obtain the first pre-stored data from the disk and store it in the target space, but also determine the address information of the target space and transmit it to the kernel layer. Thus, based on the address information transmitted to the kernel layer, the first pre-stored data can be obtained efficiently and quickly, thereby enabling the verification key data to be applied to the DP driver efficiently and quickly, improving the digital content protection verification efficiency of the digital content playback device.

[0063] Figure 4 This is a flowchart illustrating a method for determining verification key data provided by some exemplary embodiments of this disclosure. Figure 4 The method shown may include steps 410, 420, and 430. Optionally, a combination of steps 410 to 430 may be used as an alternative implementation of step 230 of this disclosure.

[0064] Step 410: Verify the first pre-stored data obtained from the target space to obtain the first verification result.

[0065] In some optional embodiments of this disclosure, the first pre-stored data obtained from the target space can be statistically analyzed to obtain the current data volume. Next, it can be determined whether the current data volume is the same as the target data volume mentioned above. If the current data volume is the same as the target data volume, the first verification result indicates that the verification of the first pre-stored data obtained from the target space has passed. If the current data volume is different from the target data volume, the first verification result indicates that the verification of the first pre-stored data obtained from the target space has failed.

[0066] Of course, the method of obtaining the first verification result is not limited to this. For example, when the secondary program loader retrieves the first pre-stored data from the disk, it can also retrieve the checksum corresponding to the first pre-stored data. This checksum can be obtained by performing a preset verification operation on the first pre-stored data, and this checksum can be referred to as the target checksum below. The preset verification operation can include, but is not limited to, Cyclic Redundancy Check (CRC) operation, parity check operation, etc. Accordingly, what is stored in the target space can be not only the first pre-stored data retrieved from the disk, but also the target checksum retrieved from the disk. Then, a preset verification operation can be performed on the first pre-stored data retrieved from the target space to obtain the current checksum. If the current checksum is the same as the target checksum, and the current data volume is the same as the target data volume, the first verification result can indicate that the verification of the first pre-stored data retrieved from the target space has passed. If the current checksum is different from the target checksum, and / or, the current data volume is different from the target data volume, the first verification result can indicate that the verification of the first pre-stored data retrieved from the target space has failed.

[0067] Step 420: In response to the first verification result indicating that the verification of the first pre-stored data obtained from the target space has passed, the first pre-stored data obtained from the target space is transformed to obtain verification key data.

[0068] In some optional embodiments of this disclosure, if the first verification result indicates that the verification of the first pre-stored data obtained from the target space has passed, this indicates that the first pre-stored data obtained from the target space is accurate and reliable. In this case, the first pre-stored data obtained from the target space can be transformed to obtain the verification key data. For example, if the first pre-stored data is data obtained by reordering the verification key data, the first pre-stored data can be sorted and restored to obtain the verification key data. As another example, if the first pre-stored data is data obtained by calculating the verification key data according to a certain computational logic, the verification key data can be deduced by following the reverse computational logic.

[0069] Step 430: In response to the first verification result indicating that the verification of obtaining the first pre-stored data from the target space fails, the second pre-stored data is obtained from the disk through the application layer of the operating system, and the verification key data is determined based on the second pre-stored data.

[0070] In some optional embodiments of this disclosure, if the first verification result indicates that the verification of the first pre-stored data obtained from the target space fails, this indicates that the first pre-stored data obtained from the target space is not accurate or reliable enough. In this case, the data pre-written to the cert partition mentioned above can be read by the application layer, and the read data can be used as the second pre-stored data. Next, the verification key data can be determined based on the second pre-stored data. For example, the specific transformation method of the first pre-stored data was described above, and a similar method can be used to transform the second pre-stored data to obtain the verification key data. Of course, the method of determining the verification key data based on the second pre-stored data is not limited to this, and examples will be given later.

[0071] Optionally, the first and second pre-stored data can be the results of reading the same data pre-written to the disk. It is understood that the first and second pre-stored data can be different or the same. For example, if the pre-stored data in the disk's cert partition is corrupted, the first pre-stored data read by SPL and the second pre-stored data read by the application layer may be the same, and both the first and second pre-stored data will fail verification. As another example, if the pre-stored data in the disk's cert partition is normal, SPL may have a read error, causing the first pre-stored data verification to fail, but the second pre-stored data obtained by the application layer when reading the same data may pass verification. In this implementation, if the operating system's SPL reads the wrong data, the operating system's application layer rereads and verifies the same data stored in the cert partition, thus enabling two verifications of the verification key data during the operating system startup process, further improving the probability and accuracy of successful verification by the digital content playback device.

[0072] In the embodiments of this disclosure, the first pre-stored data obtained from the target space can be verified. If the verification of the first pre-stored data obtained from the target space passes, accurate and reliable verification key data can be obtained based on the first pre-stored data obtained from the target space. If the verification of the first pre-stored data obtained from the target space fails, the first pre-stored data obtained from the target space can be discarded, and second pre-stored data can be obtained from the disk through the application layer to determine the verification key data. This helps to improve the accuracy and reliability of the verification key data subsequently used for digital content protection verification.

[0073] It is understood that the scheme disclosed in this embodiment uses a combination of verifying key data during the operating system loading process and verifying key data at the application layer to verify digital content playback devices. Under the premise of ensuring that the key data verification is accurate, efficient and reliable, the application layer of the operating system can support key data verification, which improves the flexibility of device key verification disclosed in this embodiment.

[0074] Figure 5 This is a flowchart illustrating a method for determining verification key data provided by some other exemplary embodiments of this disclosure. Figure 5 The method shown may include steps 510, 520, 530, 540, and 550. Optionally, Figure 5 In the method shown, the application layer can read the stored data from the default area of ​​the disk, and the read result is the second pre-stored data. Here, the default area can be the cert partition mentioned above. The combination of steps 510 to 550 can be used as an optional implementation to determine the verification key data based on the second pre-stored data.

[0075] Step 510: Verify the second pre-stored data to obtain the second verification result.

[0076] Step 520: In response to the second verification result indicating that the verification of the second pre-stored data has passed, the second pre-stored data is transformed to obtain the verification key data.

[0077] Optionally, the specific implementation of steps 510 to 520 can be referred to the relevant description of steps 410 to 420 above, and will not be repeated here.

[0078] Step 530: In response to the second verification result indicating that the verification of the second pre-stored data failed, the backup data is obtained from the backup area of ​​the disk through the application layer.

[0079] As described above, at least a portion of the verification key data can be pre-written into the default area. Alternatively, at least a portion of the verification key data can be processed according to a certain method, and the processed data can be pre-written into the default area. Optionally, the disk can include not only the default area but also a backup area, and the aforementioned data can be pre-written into both the default and backup areas. If a problem occurs in the default area, the data already stored in the backup area can be automatically copied to the default area. In this way, data recovery from the default area can be achieved through the backup area.

[0080] Step 540: Verify the backup data obtained from the backup area to obtain the third verification result.

[0081] Step 550: In response to the third verification result indicating that the verification of the backup data has passed, the backup data is transformed to obtain the verification key data.

[0082] Optionally, the specific implementation of steps 540 to 550 can be referred to the relevant description of steps 410 to 420 above, and will not be repeated here.

[0083] It should be noted that if the second verification result indicates that the verification of the second pre-stored data passes, it means that the obtained second pre-stored data is accurate and reliable. In this case, accurate and reliable verification key data can be obtained based on the second pre-stored data. If the second verification result indicates that the verification of the second pre-stored data fails, it means that the obtained second pre-stored data is not accurate and reliable enough. In this case, backup data can be obtained from the backup area. If the third verification result indicates that the verification of the backup data passes, it means that the backup data is accurate and reliable. In this case, accurate and reliable verification key data can be obtained based on the backup data. This helps to ensure the accuracy and reliability of the verification key data used for subsequent digital content protection verification.

[0084] Figure 6 This is a flowchart illustrating a data update method provided by some exemplary embodiments of this disclosure. Figure 6 The method shown may include step 610. Optionally, Figure 6 The method shown can be performed after step 540 of this disclosure.

[0085] Step 610: In response to the third verification result indicating that the verification of the backup data has passed, update the data in the default area using the backup data.

[0086] In some optional embodiments of this disclosure, if the third verification result indicates that the verification of the backup data has passed, this indicates that the backup data is accurate and reliable. In this case, the backup data can be used to update the data in the default area. For example, the data in the default area can be replaced with the backup data. Thus, after the data update, the data in the default area is accurate and reliable. Then, when the digital content playback device powers on again, the secondary program loader can obtain accurate and reliable first pre-stored data from the default area to determine the verification key data. Alternatively, when the digital content playback device powers on again, the application layer can obtain accurate and reliable second pre-stored data from the default area to determine the verification key data. In this way, the verification key data can be determined without reading the backup area, which helps ensure the verification efficiency of the verification key data.

[0087] Figure 7 This is a flowchart illustrating a method for determining verification key data provided in some exemplary embodiments of this disclosure. Figure 7 The method shown may include steps 710, 720, and 730. Optionally, a combination of steps 720 and 730 may be used as an alternative implementation to determine the verification key data based on the second pre-stored data.

[0088] Step 710: Generate the target node by calling the kernel layer of the operating system through the driver.

[0089] In some alternative implementations of this disclosure, the driver may call the kernel layer to cause the kernel layer to generate a target node. The target node can serve as a bridge between the application layer and the driver for data transfer between them. For example, one of the application layer and the driver can use this bridge to transfer data to the other. Optionally, the target node can be understood as a file in the Linux operating system.

[0090] Step 720: The second pre-stored data is transmitted to the driver via the target node.

[0091] Step 730: Transform the second pre-stored data transmitted to the driver to obtain verification key data.

[0092] In some optional embodiments of this disclosure, since the target node can serve as a bridge between the application layer and the driver, the application layer can transmit the second pre-stored data to the driver via the target node. The driver can transform the transmitted second pre-stored data in various ways to obtain verification key data. For example, the specific transformation methods for the first pre-stored data have been described above; here, the driver can use a similar method to transform the second pre-stored data to obtain verification key data. The internal memory may include storage space for use by the driver, in which the driver can store the transformed verification key data.

[0093] In the embodiments disclosed herein, by calling the kernel layer to generate a target node, and utilizing the bridging function of the target node, the second pre-stored data can be provided to the driver efficiently and reliably, so that the driver can determine the verification key data efficiently and reliably through data transformation, thereby further improving the speed and accuracy of reliability verification of digital content playback devices.

[0094] In some optional examples, the target node is generated by the driver calling the operating system's kernel layer, including:

[0095] The target node is generated in the target region by calling the kernel layer through the driver.

[0096] The second pre-stored data is retrieved from the disk through the operating system's application layer, including:

[0097] The second pre-stored data is obtained from the default area of ​​the disk through the application layer;

[0098] The target area belongs to either the disk or the internal storage. The target area can be a region that stores data according to the file system storage format, while the default area can be a region that stores data according to a non-file system storage format.

[0099] In some optional embodiments of this disclosure, storing data according to a file system storage format can be understood as organizing the data to be stored into a file system format and then storing it on a storage medium. The characteristics of storing data according to a file system storage format are: it is convenient for the operating system to read, the file system is easily recognized when it is hacked, allowing the files within to be found, and the file system is visible after being mounted. The target area for storing data according to a file system storage format can be a region on a disk or in internal memory that can be found according to a preset path.

[0100] In some optional embodiments of this disclosure, storing data in a non-file system storage format can be equivalent to storing data in a raw data storage format. Here, storing data in a raw data storage format can be understood as storing the data to be stored in its original form on the storage medium (without needing to be organized into a file system format). The characteristic of storing data in a raw data storage format is that it can only be cracked if the data structure and storage location are known, thus offering higher security compared to storing data in a file system storage format. In the embodiments of this disclosure, data in the default area can be stored in a raw data storage format, which helps improve the security of the data in the default area. Since reading the default area can yield either the first pre-stored data or the second pre-stored data mentioned above, and both the first and second pre-stored data can be used to determine the verification key data, this helps improve the security of the verification key data and minimizes the possibility of leakage. Furthermore, the target node can be stored in the target area in a file system storage format, which facilitates the use of the target node and allows it to fulfill its bridging function.

[0101] Figure 8 This is a flowchart illustrating a method for generating a target node in a target region by a driver calling the kernel layer, as provided in some exemplary embodiments of this disclosure. Figure 8 The method shown may include steps 810 and 820.

[0102] Step 810: Search for verification key data in the target region by calling a predefined module in the kernel layer through the driver.

[0103] Step 820: In response to the failure to find verification key data in the target area, a target node is generated in the target area through a predefined module.

[0104] In some alternative embodiments of this disclosure, the predefined module at the kernel layer may be a firmware module. It is understood that a firmware module is the firmware within the Linux operating system that provides communication between the operating system and the hardware, implementing the functions in the driver.

[0105] In some optional embodiments of this disclosure, the driver can invoke a predetermined module, which can perform a search operation according to a preset path to search for verification key data in the target area.

[0106] It should be noted that since the target area stores data according to a file system storage format, only data stored in this format can be found; data stored in a non-file system format cannot be found. Because the second pre-stored data is used to determine the verification key data, and this second pre-stored data is obtained by reading from the default area, which stores data in a raw data storage format, the verification key data can be considered to also be in a raw data storage format. Therefore, the pre-defined module obviously cannot find the verification key data in the target area. In response to the lack of verification key data in the target area, the pre-defined module can generate a target node in the target area. In this way, by calling the pre-defined module, the target node can be generated efficiently and reliably for subsequent use as a bridge.

[0107] Figure 9 This is a flowchart illustrating a method for determining verification key data provided by some exemplary embodiments of this disclosure. Figure 9 The method shown may include steps 910 and 920. Optionally, step 920 may be an alternative implementation of step 230 of this disclosure.

[0108] Step 910: Obtain third pre-stored data from the one-time programmable memory of the digital content playback device; wherein the third pre-stored data is used to obtain a portion of the verification key data.

[0109] In some optional embodiments of this disclosure, the verification key data corresponding to the digital content playback device can be pre-divided into two parts: a first set of data and a second set of data. As an example, the first set of data may include a portion of the public key data and a portion of the private key data in the verification key data, and the second set of data may include the remaining data in the verification key data. Optionally, the first set of data can be pre-written to a disk, or the first set of data can be processed according to a certain processing method, and the processed data can be pre-written to a disk. The data pre-written to the disk can later be used as the first pre-stored data mentioned above. Alternatively, the second set of data can be pre-written to a one-time programmable memory, or the second set of data can be processed according to a certain processing method, and the processed data can be pre-written to a one-time programmable memory. The data pre-written to the one-time programmable memory can be used as the third pre-stored data. Thus, the first and second pre-stored data can be used to obtain partial components of the verification key data, and based on the first and second pre-stored data, the complete components of the verification key data can be obtained.

[0110] In some alternative embodiments of this disclosure, the digital content playback device may include a System-on-Chip (SOC), which may integrate an intellectual property (IP) core capable of reading data from a one-time programmable memory. Thus, third-party pre-stored data can be retrieved from the one-time programmable memory via the IP core.

[0111] Step 920: Based on the first pre-stored data obtained from the target space and the third pre-stored data obtained from the one-time programmable memory, perform digital content protection verification on the digital content playback device.

[0112] In some optional embodiments of this disclosure, the first set of data mentioned above can be obtained based on the first pre-stored data obtained from the target space. For example, if the first set of data is pre-written to the disk, then the first pre-stored data obtained from the target space can be the first set of data. If the data pre-written to the disk is data obtained by processing the first set of data according to a certain processing method, then the first pre-stored data obtained from the target space can be processed in the reverse manner of the processing method to restore the first set of data. Similarly, the second set of data mentioned above can be obtained based on the third pre-stored data obtained from the one-time programmable memory, thus obtaining the complete composition of the verification key data. Based on this, digital content protection verification can be performed on the digital content playback device.

[0113] In the embodiments of this disclosure, the verification key data can be divided into a first group of data and a second group of data. Based on the first group of data, corresponding data can be pre-stored on a disk, and based on the second group of data, corresponding data can be pre-stored in a one-time programmable memory. Thus, based on the data stored on the disk and the one-time programmable memory respectively, the complete composition of the verification key data can be obtained for verification by the digital content playback device. It should be noted that the data stored in the one-time programmable memory can only be read by specific hardware (such as the IP core mentioned above). Even if the disk is disassembled and read, the complete verification key data cannot be obtained, thereby improving the security of the verification key data.

[0114] In some optional examples, the digital content playback device can be smart glasses. If the smart glasses are plugged into the host and powered on, they can boot into fastboot mode, which allows for rapid boot loading of the embedded system. Figure 10 As shown, you can first run the ROM, then run the SPL, and then load an operating system such as Linux through the SPL. Optionally, you can first start the Linux operating system kernel layer, and then load the Linux operating system drivers and application layer. The Linux operating system drivers may include DP drivers.

[0115] SPL can read data from the cert partition and move it to a fixed space in internal memory (equivalent to storing the first pre-stored data retrieved from the disk into the target space as described above). Here, when reading data from the cert partition, there may be some redundancy. For example, if the amount of data used to determine the verification key in the cert partition is less than 2KB, then 2KB of data can be read from the cert partition, ensuring that the read 2KB of data covers all the data used to determine the verification key. SPL can pass the starting address of the target space to the kernel layer as a parameter.

[0116] During loading, the DP driver can obtain the starting address passed to the kernel layer by the SPL. Based on the obtained starting address, the DP driver can retrieve the first pre-stored data from the target space. The DP driver can then verify the first pre-stored data retrieved from the target space.

[0117] If the verification of the first pre-stored data obtained from the target space passes, the first set of data mentioned above can be obtained based on the first pre-stored data obtained from the target space. Optionally, third pre-stored data can also be obtained from Efuse to obtain the second set of data mentioned above, thus obtaining complete verification key data. The smart glasses can wait for the host's verification request. If a verification request is received from the host, HDCP verification can be performed on the smart glasses based on the verification key data.

[0118] If the verification of the first pre-stored data obtained from the target space fails, the firmware module can notify the application layer to retrieve the pre-stored data. Optionally, the DP driver can call the firmware module to perform a search operation according to a preset path to search for verification key data in the target area of ​​the disk. Since the target area stores data according to the file system storage format, while the verification key data is stored according to the raw data storage format, the firmware module cannot find the verification key data. In this case, the firmware module can generate a target node in the target area. Optionally, the target node can be called an HDCP key node.

[0119] After the application layer begins execution, it can check if a node generated by the DP driver through the firmware module exists in a certain directory. For example, it can check if a target node exists in the target region. If the application layer does not find the target node, it indicates that the application layer has not received a notification, and the application layer can remain dormant. If the application layer finds the target node, it indicates that the application layer has received a notification. The application layer can then retrieve the second pre-stored data mentioned above from the cert partition, verify the second pre-stored data, and obtain the second verification result mentioned above.

[0120] If the second verification result indicates that the verification of the second pre-stored data has passed, the second pre-stored data can be transmitted to the DP driver through the target node so that the DP driver can store the data in the memory space. The data stored in the memory space and the third pre-stored data can be used to obtain complete verification key data for HDCP verification of the smart glasses.

[0121] If the second verification result indicates that the verification of the second pre-stored data fails, backup data can be obtained from the backup area and verified to obtain the third verification result mentioned above. If the third verification result indicates that the verification of the backup data passes, complete verification key data can be obtained based on the backup data and the third pre-stored data, which can be used for HDCP verification of the smart glasses.

[0122] In summary, in the embodiments of this disclosure, when the content in the cert partition is normal and the SPL read is error-free, verification key data can be obtained very quickly for HDCP verification of smart glasses. This allows digital content playback devices to play digital content securely and quickly, improving the user experience. Furthermore, the disk can also have a backup area. If data from the default area becomes unavailable, the backup area can ensure data availability, and available data can be used to update the data in the default area. This effectively prevents verification key data from being tampered with or cracked, and allows for timely data recovery in case of data corruption.

[0123] Exemplary device

[0124] Figure 11 This is a schematic diagram of the structure of an apparatus for verifying a digital content playback device provided by some exemplary embodiments of this disclosure. Figure 11 The method shown can be applied to digital content playback devices. Figure 10 The apparatus shown may include:

[0125] Storage module 1110 is used to store first pre-stored data obtained from the disk of the digital content playback device into the target space of the internal memory during the startup process of the operating system of the digital content playback device; wherein, the first pre-stored data is used to obtain at least a portion of the verification key data corresponding to the digital content playback device, and the verification key data is used for digital content protection verification.

[0126] Loading module 1120 is used to load the operating system's driver for managing the digital video interface in order to obtain the first pre-stored data from the target space;

[0127] The determining module 1130 is used to determine the verification key data based on the acquired first pre-stored data;

[0128] The verification module 1140 is used to perform digital content protection verification on the digital content playback device based on the verification key data in response to receiving a verification request from the digital content source device.

[0129] In some optional examples, the first pre-stored data to the target space is retrieved from the disk by a secondary program loader used to load the operating system;

[0130] like Figure 12 As shown, the apparatus provided in the embodiments of this disclosure further includes:

[0131] The transmission module 1210 is used to transmit the address information of the target space to the kernel layer of the operating system through the secondary program loader;

[0132] Load module 1120, including:

[0133] Load submodule 1220, which is used to load the operating system's driver for managing the digital video interface;

[0134] The acquisition submodule 1230 is used to obtain the first pre-stored data from the target space through the driver based on the address information transmitted to the kernel layer.

[0135] In some optional examples, such as Figure 13 As shown, module 1130 includes:

[0136] The verification submodule 1310 is used to verify the acquired first pre-stored data and obtain the first verification result;

[0137] The transformation submodule 1320 is used to transform the acquired first pre-stored data to obtain verification key data in response to the first verification result indicating that the verification of the acquired first pre-stored data has passed.

[0138] The determination submodule 1330 is used to, in response to the first verification result indicating that the verification of the acquired first pre-stored data has failed, obtain the second pre-stored data from the disk through the application layer of the operating system, and determine the verification key data based on the second pre-stored data.

[0139] In some optional examples, such as Figure 14 As shown, the apparatus provided in the embodiments of this disclosure further includes:

[0140] The generation module 1410 is used to generate target nodes by calling the kernel layer of the operating system through the driver;

[0141] Submodule 1330 is defined, including:

[0142] Transmission unit 1420 is used to transmit the second pre-stored data to the driver via the target node;

[0143] The first transformation unit 1430 is used to transform the second pre-stored data transmitted to the driver to obtain verification key data.

[0144] In some optional examples, generation module 1410 is used to generate target nodes in the target region by calling the kernel layer via driver;

[0145] Determine submodule 1330, which is used to obtain second pre-stored data from the default area of ​​the disk through the application layer;

[0146] The target area belongs to either the disk or the internal storage. The target area is the area where data is stored according to the file system storage format, while the default area is the area where data is stored according to a non-file system storage format.

[0147] In some optional examples, such as Figure 15 As shown, the generation module 1310 includes:

[0148] Search submodule 1510 is used to search for verification key data in the target area by calling a predefined module in the kernel layer through the driver;

[0149] The generation submodule 1520 is used to generate a target node in the target area by means of a predefined module in response to the failure to find verification key data in the target area.

[0150] In some optional examples, the application layer is used to retrieve a second pre-stored data from a default area of ​​the disk, such as Figure 16 As shown, submodule 1330 is defined, including:

[0151] The first verification unit 1610 is used to verify the second pre-stored data and obtain the second verification result;

[0152] The second transformation unit 1620 is used to transform the second pre-stored data to obtain verification key data in response to the second verification result indicating that the verification of the second pre-stored data has passed.

[0153] The acquisition unit 1630 is used to acquire backup data from the backup area of ​​the disk through the application layer in response to the second verification result indicating that the verification of the second pre-stored data has failed.

[0154] The second verification unit 1640 is used to verify the backup data and obtain the third verification result;

[0155] The third transformation unit 1650 is used to transform the backup data to obtain the verification key data in response to the third verification result indicating that the verification of the backup data has passed.

[0156] In some optional examples, such as Figure 16 As shown, the apparatus provided in the embodiments of this disclosure further includes:

[0157] Update module 1660, in response to the third verification result indicating that the verification of the backup data has passed, uses the backup data to update the data in the default area.

[0158] In some optional examples, such as Figure 17 As shown, the apparatus provided in the embodiments of this disclosure further includes:

[0159] The acquisition module 1710 is used to acquire third pre-stored data from the one-time programmable memory of the digital content playback device; wherein the third pre-stored data is used to obtain a portion of the verification key data;

[0160] The determination module 1130 is used to perform digital content protection verification on the digital content playback device based on the acquired first pre-stored data and the third pre-stored data acquired from the one-time programmable memory.

[0161] In the apparatus disclosed herein, the various optional embodiments, optional implementation methods and optional examples disclosed above can be flexibly selected and combined as needed to achieve the corresponding functions and effects, and this disclosure does not list them all.

[0162] Exemplary electronic devices

[0163] Figure 18 The illustration shows a block diagram of an electronic device according to an embodiment of the present disclosure. The electronic device 1800 includes one or more processors 1810 and memory 1820.

[0164] The processor 1810 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 1800 to perform desired functions.

[0165] The memory 1820 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 1810 may execute one or more computer program instructions to implement the methods of the various embodiments of this disclosure described above and / or other desired functions.

[0166] In one example, the electronic device 1800 may also include an input device 1830 and an output device 1840, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0167] The input device 1830 may also include, for example, a keyboard, a mouse, etc.

[0168] The output device 1840 can output various information to the outside, including, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0169] Of course, for the sake of simplicity, Figure 18Only some of the components of the electronic device 1800 relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device 1800 may include any other suitable components depending on the specific application.

[0170] Exemplary computer program products and computer-readable storage media

[0171] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps in the methods according to various embodiments of this disclosure as described in the "Exemplary Methods" section of this specification.

[0172] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of embodiments of this disclosure. These programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0173] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps in the methods according to various embodiments of this disclosure described in the "Exemplary Methods" section above.

[0174] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0175] The basic principles of this disclosure have been described above with reference to specific embodiments. However, the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. The specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the specific details described above.

[0176] Various modifications and variations can be made to this disclosure without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this disclosure and their equivalents, this disclosure is also intended to include such modifications and variations.

Claims

1. A method for verifying a digital content playback device, applied to a digital content playback device, comprising: During the operating system startup process of the digital content playback device, a first pre-stored data obtained from the disk of the digital content playback device is stored in the target space of the internal memory; wherein, the first pre-stored data is used to obtain at least a portion of the verification key data corresponding to the digital content playback device, and the verification key data is used for digital content protection verification. Load the operating system's driver for managing the digital video interface to obtain the first pre-stored data from the target space; Based on the acquired first pre-stored data, the verification key data is determined; In response to receiving a verification request from a digital content source device, the digital content playback device performs digital content protection verification based on the verification key data.

2. The method according to claim 1, wherein, The first pre-stored data stored in the target space is obtained from the disk by a secondary program loader used to load the operating system; The method further includes: The address information of the target space is transmitted to the kernel layer of the operating system through the secondary program loader; The step of loading the operating system's driver for managing the digital video interface to obtain the first pre-stored data from the target space includes: Load the operating system's driver for managing the digital video interface; Based on the address information transmitted to the kernel layer, the driver obtains the first pre-stored data from the target space.

3. The method according to claim 1, wherein, The step of determining the verification key data based on the acquired first pre-stored data includes: The acquired first pre-stored data is verified to obtain the first verification result; In response to the first verification result indicating that the verification of the acquired first pre-stored data has passed, the acquired first pre-stored data is transformed to obtain the verification key data; In response to the first verification result indicating that the verification of the acquired first pre-stored data fails, the second pre-stored data is obtained from the disk through the application layer of the operating system, and the verification key data is determined based on the second pre-stored data.

4. The method according to claim 3, wherein, The method further includes: The target node is generated by calling the kernel layer of the operating system through the driver. The step of determining the verification key data based on the second pre-stored data includes: The second pre-stored data is transmitted to the driver via the target node; The verification key data is obtained by transforming the second pre-stored data transmitted to the driver.

5. The method according to claim 4, wherein, The step of generating the target node by calling the kernel layer of the operating system through the driver includes: The driver invokes the kernel layer to generate the target node in the target region. The step of obtaining the second pre-stored data from the disk through the application layer of the operating system includes: The second pre-stored data is obtained from the default area of ​​the disk through the application layer; The target area belongs to either the disk or the internal memory. The target area is a region that stores data according to the file system storage format, while the default area is a region that stores data according to a non-file system storage format.

6. The method according to claim 5, wherein, The step of generating a target node in the target region by calling the kernel layer through the driver includes: The driver invokes a predetermined module in the kernel layer to search for the verification key data in the target region. In response to the failure to find the verification key data in the target area, a target node is generated in the target area by the predetermined module.

7. The method according to claim 3, wherein, The application layer is used to obtain the second pre-stored data from the default area of ​​the disk; The step of determining the verification key data based on the second pre-stored data includes: The second pre-stored data is verified to obtain a second verification result; In response to the second verification result indicating that the verification of the second pre-stored data has passed, the second pre-stored data is transformed to obtain the verification key data; In response to the second verification result indicating that the verification of the second pre-stored data failed, backup data is obtained from the backup area of ​​the disk through the application layer; The backup data is verified to obtain a third verification result; In response to the third verification result indicating that the verification of the backup data has passed, the backup data is transformed to obtain the verification key data.

8. The method according to claim 7, wherein, The method further includes: In response to the third verification result indicating that the verification of the backup data has passed, the data in the default area is updated using the backup data.

9. The method according to claim 1, wherein, The method further includes: The third pre-stored data is obtained from the one-time programmable memory of the digital content playback device; wherein the third pre-stored data is used to obtain a portion of the verification key data; The step of determining the verification key data based on the acquired first pre-stored data includes: Based on the first pre-stored data and the third pre-stored data obtained from the one-time programmable memory, the digital content playback device is subjected to digital content protection verification.

10. An apparatus for verifying a digital content playback device, applied to a digital content playback device, comprising: A storage module is configured to store first pre-stored data obtained from the disk of the digital content playback device into a target space of the internal memory during the operating system startup process of the digital content playback device; wherein, the first pre-stored data is used to obtain at least a portion of the verification key data corresponding to the digital content playback device, and the verification key data is used for digital content protection verification. A loading module is used to load the operating system's driver for managing the digital video interface in order to obtain the first pre-stored data from the target space; The determining module is used to determine the verification key data based on the acquired first pre-stored data; The verification module is used to respond to a verification request received from a digital content source device and perform digital content protection verification on the digital content playback device based on the verification key data.

11. An electronic device, comprising: Memory, used to store computer program products; A processor is configured to execute a computer program product stored in the memory, wherein, when the computer program product is executed, it implements the method for verifying a digital content playback device as described in any one of claims 1 to 9.

12. A computer-readable storage medium having stored thereon computer program instructions, which, when executed by a processor, implement the method for verifying a digital content playback device according to any one of claims 1 to 9.

Images