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

Abstract

This disclosure provides a method, apparatus, device, and medium for verifying digital content playback devices. The specific implementation scheme is as follows: In response to determining that the operating system's kernel layer has started, a driver for managing digital video interfaces of the operating system is loaded to call the kernel layer to generate a target node; In response to the operating system's application layer starting, first pre-stored data is obtained from the disk of the digital content playback device through the application layer, and the first pre-stored data is transmitted to the driver via the target node; 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; Based on the first pre-stored data transmitted to the driver, data is stored in memory space by the driver; In response to receiving a verification request from a digital content source device, the verification key data is determined based on the data stored in memory space to perform digital content protection verification on the digital content playback device.

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] In related technologies, various verification techniques exist for digital content playback devices to verify their reliability. For example, High-bandwidth Digital Content Protection (HDCP) is a technology that protects digital content by verifying device reliability and preventing unauthorized copying during transmission. Digital content can include, for example, digitized video and audio data. Therefore, effectively verifying digital content playback devices using technologies such as HDCP has become a key challenge in this field. 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: in response to determining that the kernel layer of an operating system has started, loading a driver of the operating system for managing digital video interfaces to invoke the kernel layer to generate a target node; in response to the application layer of the operating system starting, obtaining first pre-stored data from the disk of the digital content playback device through the application layer, and transmitting the first pre-stored data to the driver via the target node; 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; based on the first pre-stored data transmitted to the driver, storing data in memory space through the driver; wherein the memory space is the space in the internal memory of the digital content playback device corresponding to the driver; in response to receiving a verification request from a digital content source device, determining verification key data based on the data stored in the memory space to perform digital content protection verification on the digital content playback device.

[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 generation module, configured to, in response to determining that the kernel layer of an operating system has started, load a driver of the operating system for managing digital video interfaces to call the kernel layer to generate a target node; a processing module, configured to, in response to the application layer of the operating system starting, obtain first pre-stored data from the disk of the digital content playback device through the application layer, and transmit the first pre-stored data to the driver via the target node; 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 storage module, configured to, based on the first pre-stored data transmitted to the driver, store data in a memory space through the driver; wherein the memory space is the space in the internal memory of the digital content playback device corresponding to the driver; and a verification module, configured to, in response to receiving a verification request from a digital content source device, determine verification key data based on the data stored in the memory space to perform digital content protection verification on the digital content playback 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 invoking the kernel layer to generate a target node in the first region, provided by some exemplary embodiments of this disclosure.

[0011] Figure 4 This is a flowchart illustrating a method for obtaining first pre-stored data from the disk of a digital content playback device through an application layer, provided by some exemplary embodiments of this disclosure.

[0012] Figure 5 This is a flowchart illustrating a method for obtaining first pre-stored data from the disk of a digital content playback device through an application layer, 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 based on data stored in memory space, provided by some exemplary embodiments of this disclosure.

[0015] Figure 8 This is a flowchart illustrating a method for storing data in memory space by a driver based on first pre-stored data transmitted to the driver, provided by some exemplary embodiments of this disclosure.

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

[0017] Figure 10 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.

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

[0019] Figure 12 This is a schematic diagram of the structure of a storage module in some exemplary embodiments of this disclosure.

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

[0021] Figure 14-1 This is a schematic diagram of the structure of the processing module in some exemplary embodiments of this disclosure.

[0022] Figure 14-2 This is a schematic diagram of the structure of the processing module in some other exemplary embodiments of this disclosure.

[0023] Figure 14-3 This is a schematic diagram of a module used to assist in updating the default region in some exemplary embodiments of this disclosure.

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

[0025] 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.

[0026] 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.

[0027] Exemplary Overview

[0028] This section uses High Bandwidth Digital Content Protection (HBP) technology as an example to explain the verification methods for digital content playback devices. HBP technology can prevent unauthorized copying of digital content during transmission through a transmission interface. Transmission interfaces can include, but are 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.

[0029] 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.

[0030] Understandably, it is necessary to verify digital content playback devices before transmitting digital content between them. 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.

[0031] Exemplary System

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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 case of a Linux operating system as an example.

[0036] 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.

[0037] In the embodiments of this disclosure, during the startup process of the operating system running on the SOC, data can be stored in the internal memory (also known as memory space) corresponding to the driver managing the digital video interface, through the collaborative work of the operating system kernel layer, the driver for managing the digital video interface, and the application layer. Furthermore, the data stored in the internal memory is closely associated with 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. Thus, if the digital content playback device receives a verification request from the digital content source device, it can quickly determine the verification key data based on the data stored in the memory space to perform digital content protection verification on the digital content playback device. 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.

[0038] Exemplary methods

[0039] 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.

[0040] Step 210: In response to determining that the operating system's kernel layer has started, load the operating system's driver for managing the digital video interface to invoke the kernel layer to generate the target node.

[0041] In some optional embodiments of this disclosure, after the digital content playback device is powered on, the operating system can be started using a fastboot mode to boot the device. 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 through the SPL to boot the operating system. Alternatively, the digital content playback device can be started using a conventional boot mode. This involves first running the ROM, then the SPL, then the bootloader (U-Boot), and finally booting the operating system.

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

[0043] Understandably, a driver can call the kernel layer to cause the kernel layer to generate a target node. The target node can serve as a bridge for communication between the application layer and the driver. For example, either the application layer or 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.

[0044] Step 220: In response to the application layer startup of the operating system, the first pre-stored data is obtained from the disk of the digital content playback device through the application layer, and the first pre-stored data is transmitted to the driver via the target node; 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.

[0045] 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 includes both public key data and private key data. Optionally, at least a portion of the verification key data can be pre-written to a disk. Alternatively, at least a portion of the verification key data can be processed according to a predetermined processing method, and the processed data can be pre-written to a disk. This processing method may include, but is not limited to, reordering, calculation according to a certain computational logic, etc. The data pre-written to the disk here may be referred to as target data in the following text.

[0046] In some optional embodiments of this disclosure, if the application layer starts successfully, it can read pre-written data from the disk. This read data can serve as first pre-stored data, comprising at least a portion of the verification key data. Since the target node can act as a bridge for communication between the application layer and the driver, the application layer can transmit the first pre-stored data to the driver via the target node.

[0047] Step 230: Based on the first pre-stored data transmitted to the driver, the driver stores the data in the memory space; wherein, the memory space is the space in the internal memory of the digital content playback device corresponding to the driver.

[0048] In some optional embodiments of this disclosure, the internal memory may include space for use by the driver, which can be considered as the space in the internal memory corresponding to the driver, i.e., the memory space in step 230.

[0049] In some optional embodiments of this disclosure, after the application layer transmits the first pre-stored data to the driver via the target node, the driver can store the first pre-stored data or related data in memory space based on the transmitted first pre-stored data. For example, if the first pre-stored data is at least a portion of the verification key data itself, the driver can store the first pre-stored data in memory space. If the first pre-stored data is data obtained by processing at least a portion of 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 at least a portion of the verification key data, and store at least a portion of the restored verification key data in memory space.

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

[0051] In some optional embodiments of this disclosure, if digital content needs to be transmitted between a digital content source device and a 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. Therefore, when the digital content playback device receives the verification request, it can determine the verification key data based on the data stored in the memory space. For example, if the data stored in the memory space includes all components of the verification key data, the verification key data can be extracted from the data stored in the memory space for use in digital content protection verification of the digital content playback device. If the data stored in the memory space only includes a portion of the verification key data, this portion can be extracted from the data stored in the memory space, and the remaining portion can be obtained using a certain acquisition method to obtain the complete composition of the verification key data, which can then be used for digital content protection verification of the digital content playback device. Optionally, the specific method for performing digital content protection verification of 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, in response to kernel layer startup, a driver can be loaded to generate a target node by calling the kernel layer through the driver. The target node can serve as a bridge for communication between the application layer and the driver. In response to application layer startup, the application layer can obtain first pre-stored data from the disk and transmit the first pre-stored data to the driver through the bridge function of the target node. The driver can store data in memory space based on the transmitted first pre-stored data. 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, and the data stored in memory space is based on the first pre-stored data, it can be considered that the data stored in memory space is closely related to the verification key data. That is, during the operating system startup process, through the collaborative work of the kernel layer, driver, and application layer, data closely related to the verification key data can be stored in memory space. If digital content needs to be transmitted between the digital content source device and the digital content playback device, the verification key data can be determined efficiently and quickly based on the data stored in memory space to perform digital content protection verification on the digital content playback device. This allows for efficient and quick verification of digital content playback devices, enabling them to play digital content safely and quickly, thus improving the user experience.

[0053] It is understood that the scheme disclosed in the above embodiments can verify the key data of the digital content playback device through the application layer, rather than during the operating system startup process, thereby reducing the requirements for operating system permissions, facilitating the implementation of the technical solution, and improving the flexibility of the device key verification disclosed in this embodiment.

[0054] In some optional examples, invoking the kernel layer to generate the target node may include: invoking the kernel layer to generate the target node in the first region. Therefore, retrieving the first pre-stored data from the disk of the digital content playback device via the application layer may include:

[0055] The first pre-stored data is obtained from the second area of ​​the disk through the application layer.

[0056] The first region can belong to either the disk or the internal storage. The first region can be a region that stores data according to the file system storage format, while the second region can be a region that stores data according to a non-file system storage format.

[0057] 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 first area for storing data according to the file system storage format can be a region on a disk or in internal memory that can be found according to a preset path.

[0058] 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.

[0059] In the embodiments of this disclosure, the data in the second region can be stored in a raw data storage format, which helps improve the security of the data in the second region. Since reading the second region yields the first pre-stored data, which is used to determine the verification key data, this further enhances the security of the verification key data and minimizes the risk of leakage. Additionally, the target node can be stored in the first region in a file system storage format, which facilitates its use and allows it to fulfill its bridging function.

[0060] Figure 3 This is a flowchart illustrating a method for invoking the kernel layer to generate a target node in the first region, provided by some exemplary embodiments of this disclosure. Figure 3 The method shown may include steps 310 and 320.

[0061] Step 310: Call the predefined module in the kernel layer to search for verification key data in the first region.

[0062] Step 320: In response to the failure to find verification key data in the first region, a target node is generated in the first region through a predetermined module.

[0063] 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.

[0064] 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 a first region.

[0065] It should be noted that since the first region stores data according to a file system storage format, only data stored in a file system storage format can be found in the first region; data stored in a non-file system storage format cannot be found. Because the first pre-stored data is used to obtain at least a portion of the verification key data, and this first pre-stored data is obtained by reading from the second region, 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 first region. In response to the lack of verification key data in the first region, the pre-defined module can generate a target node in the first region. In this way, by calling the pre-defined module, the target node can be generated efficiently and reliably, so that its bridging function can be used subsequently.

[0066] Figure 4 This is a flowchart illustrating a method for obtaining first pre-stored data from the disk of a digital content playback device through an application layer, provided by some exemplary embodiments of this disclosure. Figure 4 The method shown may include steps 410, 420, 430 and 440.

[0067] Step 410: Obtain the pre-stored data and the first checksum from the default area of ​​the disk through the application layer.

[0068] In some optional embodiments of this disclosure, a partition (hereinafter referred to as the cert partition) may be pre-allocated on the disk to store the pre-written data. The cert partition may serve as the default region. Alternatively, the default region may be a portion of the second region mentioned above.

[0069] In some optional embodiments of this disclosure, at least a portion of the verification key data can be pre-stored as pre-data in the default area. Alternatively, a preset verification operation can be performed on at least a portion of the verification key data, and the resulting verification code can be written into the default area. Or, the verification key data can be pre-processed according to a certain method, and the processed data can be pre-stored as pre-data in the default area. A preset verification operation can also be performed on the processed data, and the resulting verification code can be written into the default area. The preset verification operation may include, but is not limited to, Cyclic Redundancy Check (CRC) operations, parity check operations, etc. It should be noted that the amount of pre-stored data written into the default area in this paragraph may be referred to as the target data amount in the following text.

[0070] In step 410, the application layer can read the default area to obtain pre-stored data and a verification code from the default area, and the obtained verification code can be used as the first verification code.

[0071] Step 420: Determine the first amount of pre-stored data to be obtained from the default area.

[0072] In some optional embodiments of this disclosure, the pre-stored data obtained from the default area can be statistically analyzed to obtain a first data volume.

[0073] Step 430: Based on the first check code and the first data volume, verify the pre-stored data obtained from the default area to obtain the first verification result.

[0074] In some optional embodiments of this disclosure, a preset verification operation can be performed on the pre-stored data obtained from the default area to obtain the current verification code. Next, it can be determined whether the first verification code is the same as the current verification code, and whether the first data volume is the same as the target data volume. If the first verification code is the same as the current verification code, and the first data volume is the same as the target data volume, then the first verification result indicates that the verification of the pre-stored data obtained from the default area has passed. If the first verification code is different from the current verification code, and / or the first data volume is different from the target data volume, then the first verification result indicates that the verification of the pre-stored data obtained from the default area has failed.

[0075] Step 440: In response to the first verification result indicating that the verification of the pre-stored data obtained from the default area has passed, the pre-stored data obtained from the default area is determined as the first pre-stored data.

[0076] It should be noted that if the first verification result indicates that the verification of the pre-stored data obtained from the default area has passed, this means that the pre-stored data obtained from the default area is accurate and reliable. In this case, the pre-stored data read from the default area can be identified as the first pre-stored data. This improves the accuracy and reliability of the first pre-stored data obtained from the disk, which helps ensure the accuracy and reliability of the verification key data used for subsequent digital content protection verification, thus improving the accuracy of device verification.

[0077] Figure 5 This is a flowchart illustrating a method for obtaining first pre-stored data from the disk of a digital content playback device through an application layer, provided by some other exemplary embodiments of this disclosure. Figure 5 The method shown may include steps 510, 520, 530, and 540. Optionally, Figure 5 The method shown can be performed after step 430 of this disclosure.

[0078] Step 510: In response to the first verification result indicating that the verification of the pre-stored data obtained from the default area fails, the application layer obtains the pre-stored data and the second verification code from the backup area of ​​the disk.

[0079] As described above, at least a portion of the verification key data can be pre-stored as pre-data in the default area, along with the corresponding verification code. Alternatively, the verification key data can be pre-processed according to a specific method, and the processed data can be pre-stored as pre-data in the default area, along with the corresponding verification code. Optionally, the second area can include not only the default area but also a backup area. The aforementioned data and verification code can be pre-stored in both the default and backup areas. If a problem occurs in the default area, the data stored in the backup area can be automatically copied to the default area. This allows for data recovery from the default area via the backup area.

[0080] In step 510, if the first verification result indicates that the verification of the pre-stored data obtained from the default area fails, the application layer can read the backup area to obtain the pre-stored data and verification code from the backup area, and the obtained verification code can be used as the second verification code.

[0081] Step 520: Determine the second data volume of the pre-stored data obtained from the backup area.

[0082] Step 530: Based on the second check code and the second data volume, verify the pre-stored data obtained from the backup area to obtain the second verification result.

[0083] Step 540: In response to the second verification result indicating that the verification of the pre-stored data obtained from the backup area has passed, the pre-stored data obtained from the backup area is determined as the first pre-stored data.

[0084] Optionally, the specific implementation of steps 520 to 540 can refer to the relevant description of steps 420 to 440 above, and will not be repeated here.

[0085] It should be noted that if the second verification result indicates that the pre-stored data obtained from the backup area has passed verification, this means that the pre-stored data obtained from the backup area is accurate and reliable. In this case, the pre-stored data obtained from the backup area can be identified as the first pre-stored data. In this scheme, when there are problems with the pre-stored data in the default area, the backup area is verified. If the data in the backup area is correct, the data in the backup area is used to verify the device reliability, thereby further improving the accuracy and reliability of the device verification.

[0086] Figure 6This 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 530 of this disclosure.

[0087] Step 610: In response to the second verification result indicating that the verification of the pre-stored data obtained from the backup area has passed, update the pre-stored data in the default area using the pre-stored data obtained from the backup area.

[0088] In some optional embodiments of this disclosure, if the second verification result indicates that the verification of the pre-stored data obtained from the backup area has passed, this means that the pre-stored data obtained from the backup area is accurate and reliable. In this case, the pre-stored data in the default area can be updated using the pre-stored data obtained from the backup area. For example, the pre-stored data in the default area can be replaced with the pre-stored data obtained from the backup area. In this way, after the data update, the pre-stored data in the default area is accurate and reliable. Then, when the digital content playback device is powered on again, accurate and reliable pre-stored data can be obtained from the default area as the first pre-stored data, ensuring the efficiency of obtaining the first pre-stored data and improving the efficiency of device verification.

[0089] Optionally, when updating the default area, not only can the pre-stored data in the default area be replaced with pre-stored data obtained from the backup area, but the checksum in the default area can also be replaced with a second checksum obtained from the backup area.

[0090] Figure 7 This is a flowchart illustrating a method for determining verification key data based on data stored in memory space, provided by some exemplary embodiments of this disclosure. Figure 7 The method shown may include steps 710 and 720.

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

[0092] 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 serve as first pre-stored data. 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 serve as second 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.

[0093] 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, the IP core allows the retrieval of second pre-stored data from the one-time programmable memory.

[0094] Step 720: Determine the verification key data based on the data stored in the memory space and the second pre-stored data obtained from the one-time programmable memory.

[0095] In some optional embodiments of this disclosure, the first set of data mentioned above can be obtained based on the data stored in the memory space. For example, if the first set of data is pre-written to the disk, it can be extracted from the data stored in the memory space. If the data pre-written to the disk is data obtained by processing the first set of data according to a certain processing method, it can be processed in the reverse manner to restore the first set of data. Similarly, the second set of data mentioned above can be obtained based on the second 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.

[0096] 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.

[0097] Figure 8 This is a flowchart illustrating a method for storing data in memory space by a driver based on first pre-stored data transmitted to the driver, provided by some exemplary embodiments of this disclosure. Figure 8 The method shown may include steps 810 and 820.

[0098] Figure 8 In the method shown, the first pre-stored data can be data obtained by reordering at least a portion of the verification key data according to a preset rule. Optionally, the first pre-stored data can be data obtained by reordering the first group of data mentioned above according to a preset rule. As an example, the preset rule can be used to instruct the data to be divided into four parts, the first and second parts to be swapped, and the third and fourth parts to be swapped. Alternatively, the preset rule can be used to instruct the data to be divided into four parts, the first and fourth parts to be swapped, and the second and third parts to be swapped. Or, the preset rule can be used to instruct the overall order of all binary characters in the data to be reversed. Of course, the preset rule can also be other more complex reordering rules, which will not be listed here.

[0099] Step 810: Reorder the first pre-stored data transmitted to the driver according to the sorting and restoration rules adapted to the preset rules.

[0100] Step 820: The driver stores the reordered first pre-stored data in the memory space.

[0101] In some optional embodiments of this disclosure, the matching of sorting restoration rules with preset rules can be understood as follows: after reordering certain data according to preset rules, reordering the reordered results again according to sorting restoration rules can restore the data. If the preset rules are used to indicate dividing the data into four parts, swapping the positions of the first and second parts, and swapping the positions of the third and fourth parts, or if the preset rules are used to indicate dividing the data into four parts, swapping the positions of the first and fourth parts, and swapping the positions of the second and third parts, then the sorting restoration rules and the preset rules can be the same rules.

[0102] In some optional embodiments of this disclosure, after the first pre-stored data transmitted to the driver is reordered according to a sorting and restoration rule adapted to preset rules, the reordered first pre-stored data can be the restored first set of data, and the driver can store the first set of data in memory space. Additionally, as described above, second pre-stored data can be obtained from a one-time programmable memory, and based on the second pre-stored data, the second set of data mentioned above can be obtained. The first set of data and the second set of data can form complete verification key data for digital content protection verification of the digital content playback device.

[0103] In the embodiments of this disclosure, the first pre-stored data can be data obtained by processing at least a portion of the verification key data using a reordering method. This makes it difficult to obtain the verification key data based on the illegally obtained first pre-stored data, thus ensuring the security of the verification key data. Furthermore, if digital content transmission is required between the digital content source device and the digital content playback device, restoring the first pre-stored data yields the first set of data, which can then be used to determine the verification key data, ensuring the proper verification of the digital content playback device.

[0104] 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 booting of the embedded system. Figure 9 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.

[0105] After the DP driver is loaded, it can use the kernel-level firmware module to notify the application layer to retrieve pre-stored data. Optionally, the DP driver can call the kernel-level firmware module to perform a search operation according to a preset path to search for verification key data in the first region of the disk. Since the first region stores data according to the file system storage format, while the verification key data is stored in raw data format, the firmware module cannot find the verification key data. In this case, the firmware module can generate a target node in the first region. Optionally, the target node can be called an HDCP key node.

[0106] 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 the target node exists in the first region. If the application layer does not find the target node, it indicates that the application layer has not received a notification, and it can remain dormant. If the application layer finds the target node, it indicates that it has received a notification. The application layer can then retrieve pre-stored data and a checksum from the default region in the second region. Based on the amount of pre-stored data and the checksum, it can verify the pre-stored data to obtain the first verification result mentioned above. Optionally, the default region can also be called the cert partition.

[0107] If the first verification result indicates that the verification of the pre-stored data has passed, then the pre-stored data can be used as the first pre-stored data mentioned above.

[0108] If the first verification result indicates that the verification of the pre-stored data fails, the pre-stored data and verification code can be obtained from the backup area in the second area. Based on the data volume of the pre-stored data and the verification code, the pre-stored data can be verified to obtain the second verification result mentioned above. If the second verification result indicates that the verification of the pre-stored data passes, the pre-stored data can be used as the first pre-stored data mentioned above. Optionally, the pre-stored data can also be used to update the pre-stored data in the default area.

[0109] The application layer can transmit the first pre-stored data to the DP driver via the target node. The DP driver can sort and restore the transmitted first pre-stored data according to a sorting and restoration rule adapted to preset rules to obtain the first set of data mentioned above. The DP driver can store the first set of data in memory. Optionally, it can also obtain the second pre-stored data from Efuse to determine the second set of data. In this way, complete verification key data can be obtained. 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.

[0110] This allows for the rapid acquisition of verification key data through application-layer assistance without modifying the Linux operating system's boot parameters. Furthermore, the pre-stored data in the second disk area can be out-of-order, and this area can also contain a checksum for data integrity verification. The second area includes not only the default area but also a backup area. If the pre-stored data obtained from the default area becomes unavailable, the backup area ensures data availability, and the default area can be updated with available data. This effectively prevents verification key data from being tampered with or cracked, and allows for timely data recovery in case of corruption.

[0111] In some optional examples, after SPL starts running, SPL can read and move pre-stored data from the cert partition to a fixed space in main memory (hereinafter referred to as the target space). SPL can pass the address information of the target space to the kernel layer as a parameter. The DP driver can obtain the address information passed to the kernel layer by SPL during loading. Based on the address information, the DP driver can obtain pre-stored data from the target space, and the DP driver can also verify the pre-stored data obtained from the target space. If the DP driver verifies the pre-stored data obtained from the target space, it can obtain the first set of data mentioned above based on the pre-stored data obtained from the target space, and determine the verification key data based on this. If the DP driver fails to verify the pre-stored data obtained from the target space, the DP driver can call the kernel layer to generate a target node. The application layer can obtain pre-stored data from the cert partition and transmit the obtained pre-stored data to the DP driver via the target node. The DP driver can then store the first set of data in the memory space, and determine the verification key data based on this. In this way, if the content in the cert partition is normal and the SPL read is error-free, the verification key data can be obtained very quickly for HDCP verification of the smart glasses. This allows the smart glasses to play digital content safely and quickly, which helps to improve the user experience.

[0112] Exemplary device

[0113] Figure 10 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 10 The method shown can be applied to digital content playback devices. Figure 10 The apparatus shown may include:

[0114] The generation module 1010 is used to load the operating system's driver for managing the digital video interface in response to determining the kernel layer startup of the operating system, so as to call the kernel layer to generate the target node.

[0115] The processing module 1020 is used to respond to the application layer startup of the operating system, obtain first pre-stored data from the disk of the digital content playback device through the application layer, and transmit the first pre-stored data to the driver via the target node; 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.

[0116] The storage module 1030 is used to store data in the memory space by the driver based on the first pre-stored data transmitted to the driver; wherein, the memory space is the space in the internal memory of the digital content playback device corresponding to the driver;

[0117] The verification module 1040 is used to respond to a verification request received from a digital content source device, and determine verification key data based on the data stored in the memory space to perform digital content protection verification on the digital content playback device.

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

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

[0120] The verification module 1040 is used to determine the verification key data based on the data stored in the memory space and the second pre-stored data obtained from the one-time programmable memory.

[0121] In some optional examples, the first pre-stored data is data obtained by reordering at least a portion of the components of the verification key data according to preset rules;

[0122] like Figure 12 As shown, the storage module 1030 includes:

[0123] The reordering submodule 1210 is used to reorder the first pre-stored data transmitted to the driver according to the sorting restoration rules adapted to the preset rules.

[0124] Storage submodule 1220 is used to store the reordered first pre-stored data in memory space via a driver.

[0125] In some optional examples, generation module 1010 is used to call the kernel layer to generate target nodes in the first region;

[0126] Processing module 1030 is used to obtain first pre-stored data from the second area of ​​the disk through the application layer;

[0127] The first region belongs to either the disk or the internal storage. The first region is the region that stores data according to the file system storage format, while the second region is the region that stores data according to the non-file system storage format.

[0128] In some optional examples, such as Figure 13 As shown, the generation module 1010 includes:

[0129] Search submodule 1310 is used to call a predefined module in the kernel layer to search for the first pre-stored data in the first region;

[0130] The generation submodule 1320 is used to generate a target node in the first region in response to the failure to find the first pre-stored data in the first region through a predetermined module.

[0131] In some optional examples, such as Figure 14-1 As shown, the processing module 1020 includes:

[0132] The first acquisition submodule 1410 is used to acquire pre-stored data and the first verification code from the default area of ​​the disk through the application layer;

[0133] The first determining submodule 1420 is used to determine the first data volume of pre-stored data obtained from the default area;

[0134] The first verification submodule 1430 is used to verify the pre-stored data obtained from the default area based on the first verification code and the first data volume, and obtain the first verification result;

[0135] The second determining submodule 1440 is used to determine the pre-stored data obtained from the default area as the first pre-stored data in response to the first verification result indicating that the verification of the pre-stored data obtained from the default area has passed.

[0136] In some optional examples, such as Figure 14-2 As shown, the processing module 1020 also includes:

[0137] The second acquisition submodule 1450 is used to acquire the pre-stored data and the second verification code from the backup area of ​​the disk through the application layer in response to the first verification result indicating that the verification of the pre-stored data obtained from the default area has failed.

[0138] The third determining submodule 1460 is used to determine the second data volume of pre-stored data obtained from the backup area;

[0139] The second verification submodule 1470 is used to verify the pre-stored data obtained from the backup area based on the second verification code and the second data volume, and obtain the second verification result.

[0140] The fourth determination submodule 1480 is used to determine the pre-stored data obtained from the backup area as the first pre-stored data in response to the second verification result indicating that the verification of the pre-stored data obtained from the backup area has passed.

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

[0142] The update module 1490 is used to update the pre-stored data in the default area in response to the second verification result obtained by the second verification submodule 1470 indicating that the verification of the pre-stored data obtained from the backup area has passed.

[0143] 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.

[0144] Exemplary electronic devices

[0145] Figure 15 The illustration shows a block diagram of an electronic device according to an embodiment of the present disclosure. The electronic device 1500 includes one or more processors 1510 and memory 1520.

[0146] The processor 1510 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 1500 to perform desired functions.

[0147] The memory 1520 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 1510 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.

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

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

[0150] The output device 1540 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.

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

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

[0153] 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.

[0154] 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.

[0155] 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.

[0156] 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.

[0157] 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.

[0158] 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: In response to determining that the operating system's kernel layer has started, the driver for managing the digital video interface of the operating system is loaded to invoke the kernel layer to generate the target node; In response to the application layer startup of the operating system, the first pre-stored data is obtained from the disk of the digital content playback device through the application layer, and the first pre-stored data is transmitted to the driver via the target node; 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. Based on the first pre-stored data transmitted to the driver, data is stored in the memory space by the driver; wherein, the memory space is the space in the internal memory of the digital content playback device corresponding to the driver; In response to receiving a verification request from a digital content source device, the verification key data is determined based on the data stored in the memory space to perform digital content protection verification on the digital content playback device.

2. The method according to claim 1, wherein, The method further includes: The second pre-stored data is obtained from the one-time programmable memory of the digital content playback device; wherein the second pre-stored data is used to obtain a portion of the verification key data; The determination of the verification key data based on the data stored in the memory space includes: The verification key data is determined based on the data stored in the memory space and the second pre-stored data obtained from the one-time programmable memory.

3. The method according to claim 1, wherein, The first pre-stored data includes data obtained by reordering at least a portion of the verification key data according to a preset rule; The step of storing data in memory space by the driver based on the first pre-stored data transmitted to the driver includes: The first pre-stored data transmitted to the driver is reordered according to the sorting and restoration rules adapted to the preset rules. The driver stores the first pre-stored data, after reordering, in the memory space.

4. The method according to any one of claims 1-3, wherein, The process of calling the kernel layer to generate the target node includes: The kernel layer is invoked to generate the target node in the first region; The step of obtaining the first pre-stored data from the disk of the digital content playback device through the application layer includes: The first pre-stored data is obtained from the second region of the disk through the application layer; The first region belongs to either the disk or the internal memory. The first region is a region that stores data according to the file system storage format, while the second region is a region that stores data according to the non-file system storage format.

5. The method according to claim 4, wherein, The invocation of the kernel layer to generate the target node in the first region includes: The predetermined module of the kernel layer is invoked to search for the verification key data in the first region; In response to the failure to find the verification key data in the first region, the target node is generated in the first region by the predetermined module.

6. The method according to any one of claims 1-3, wherein, The step of obtaining the first pre-stored data from the disk of the digital content playback device through the application layer includes: The application layer obtains pre-stored data and a first checksum from the default area of ​​the disk. Determine the first data volume of the pre-stored data obtained from the default area; Based on the first verification code and the first data volume, the pre-stored data obtained from the default area is verified to obtain the first verification result; In response to the first verification result indicating that the verification of the pre-stored data obtained from the default region has passed, the pre-stored data obtained from the default region is determined as the first pre-stored data.

7. The method according to claim 6, wherein, The step of obtaining the first pre-stored data from the disk of the digital content playback device through the application layer further includes: In response to the first verification result indicating that the verification of the pre-stored data obtained from the default area fails, the application layer obtains the pre-stored data and the second verification code from the backup area of ​​the disk. Determine the second data volume of pre-stored data obtained from the backup area; Based on the second verification code and the second data volume, the pre-stored data obtained from the backup area is verified to obtain a second verification result; In response to the second verification result indicating that the verification of the pre-stored data obtained from the backup area has passed, the pre-stored data obtained from the backup area is determined as the first pre-stored data.

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

9. An apparatus for verifying a digital content playback device, applied to a digital content playback device, comprising: A generation module is used to load the operating system's driver for managing digital video interfaces in response to determining that the operating system's kernel layer has started, so as to call the kernel layer to generate the target node; The processing module is configured to, in response to the application layer startup of the operating system, obtain first pre-stored data from the disk of the digital content playback device through the application layer, and transmit the first pre-stored data to the driver via the target node; 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 storage module is used to store data in a memory space via the driver based on the first pre-stored data transmitted to the driver; wherein the memory space is the space in the internal memory of the digital content playback device corresponding to the driver; The verification module is used to respond to a verification request received from a digital content source device, and determine the verification key data based on the data stored in the memory space to perform digital content protection verification on the digital content playback device.

10. 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 8.

11. 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 8.

Images