Real-time update methods, systems, and electronic devices for remote keys

Abstract

This application discloses a method, system, and electronic device for real-time updating of remote keys, applied to terminal devices, and relating to the field of information security technology. The method includes: acquiring certificate signing request data from the terminal device and saving the certificate signing request data to a secure storage area; monitoring the key configuration status between the target application and a remote configuration server; if the key configuration status indicates configuration failure, retrieving the certificate signing request data from the secure storage area; and sending the certificate signing request data to a vendor server, so that the vendor server uploads the certificate signing request data to the remote configuration server for verification and configuration. This solution can automatically remedy remote key configuration failures caused by missing certificate signing request data uploads, improving the reliability of key configuration on terminal devices.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a method, system and electronic device for real-time updating of remote keys. Background Technology

[0002] With the rapid development of mobile internet and smart terminal technologies, streaming media services have become an indispensable part of people's daily lives. To protect digital rights-protected content (such as premium streaming videos offered by platforms like Netflix and Prime Video) from illegal copying and distribution, the industry widely adopts Digital Rights Management (DRM) technology, with Widevine being one of the most widely used security solutions. Before playing copyrighted and secure videos, terminal devices must interact with a remote configuration server to obtain the corresponding security encryption and decryption permissions (such as Widevine L1 level authentication qualifications and certificates).

[0003] In existing device key configuration technologies, the early Provision2 method primarily relied on symmetric keys for interaction, requiring the secure encryption and decryption key data to be stored locally on the terminal device. This method depended on a unique device ID stored locally and a specific key derived from the device key to communicate with a remote server, and required factories to manually burn pre-set key files onto each machine supporting this function during the production phase, which not only increased manufacturing costs but also significantly slowed down the production process. To overcome this shortcoming, the industry gradually introduced Provision4 remote key technology. Provision4 technology abandons the old burning method and instead generates a unique asymmetric key pair for each device, uploading the public key to a remote database for storage.

[0004] However, existing Provision4 remote keying technology heavily relies on OEMs' manual execution of specifications on the production line. This requires production personnel to accurately extract the CSR file from each terminal device using specialized tools and upload it to a remote configuration server. In actual production environments, due to personnel turnover, unfamiliarity with production specifications, or simple operational negligence, it's highly likely that individual or even entire batches of devices' CSR files will be missed during extraction or uploading. Once these terminal devices with "missed uploads" enter the consumer market, when end users attempt to play protected video content using third-party applications while connected to the internet, the device will fail to configure itself due to the lack of a corresponding CSR record on the server. This directly prevents the terminal device from obtaining a valid DRM certificate from the remote configuration server, resulting in the loss of video encryption / decryption permissions. This functional deficiency caused by human error at the manufacturing stage not only prevents consumers from watching legitimate content but also triggers numerous customer complaints, widespread product returns, and device recalls, causing severe damage to the manufacturer's brand reputation and resulting in financial losses. Therefore, there is an urgent need for a method that can eliminate the reliance on manual factory operations and automatically detect and repair configuration failures in real time after the equipment is put into use. Summary of the Invention

[0005] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes a method, system, and electronic device for real-time updating of remote keys, which can automatically and in real-time remedy missing certificate signature request data after the terminal device leaves the production line and enters the consumer market.

[0006] In a first aspect, embodiments of this application provide a method for real-time updating of a remote key.

[0007] The method for real-time updating of a remote key according to embodiments of this application includes: The real-time remote key update method according to the embodiments of this application has at least the following beneficial effects: By acquiring the certificate signing request data of the terminal device and saving the certificate signing request data to a secure storage area in advance, the real-time remote key update method of the embodiment establishes a reliable security backup mechanism on the local terminal device. After the device is put into actual use, by monitoring the key configuration status between the target application and the remote configuration server, the terminal device can detect key interaction anomalies caused by reasons such as missing files from the factory; once it is determined that the key configuration status is a configuration failure, the real-time remote key update method of the embodiment can trigger an automatic repair process, directly extract the saved certificate signing request data from the secure storage area, and send the certificate signing request data to the vendor server, and then use the vendor server to upload the data to the remote configuration server to complete the final verification and configuration. The real-time remote key update method of the embodiment realizes automated and real-time remediation of missing certificate signing request data after the terminal device leaves the production line and enters the consumer market. This effectively breaks the absolute reliance on manual data uploads on the factory line in the existing Provision4 solution, solving the pain point that terminal devices cannot obtain DRM security certificates and thus cannot play copyrighted videos due to workers failing to extract or upload equipment data during the production stage. The real-time remote key update method in this embodiment not only compensates for human error in the factory production process, ensuring the normal flow of digital rights management video services on terminal devices and providing users with a seamless and smooth high-definition streaming media playback experience; but also reduces customer complaint rates and equipment refund / return rates caused by such factory defects without requiring users to perform cumbersome operations or return equipment to the factory, saving after-sales maintenance costs and improving product market reputation and overall yield.

[0008] According to some embodiments of this application, the step of obtaining the certificate signature request data of the terminal device further includes: In the trusted execution environment of the terminal device, an asymmetric key pair is generated based on the unique device key of the terminal device; Based on the private key in the asymmetric key pair, the device information and root certificate chain data of the terminal device are signed to generate the certificate signing request data.

[0009] According to some embodiments of this application, generating an asymmetric key pair based on the unique device key of the terminal device includes: Obtain the unique device key of the terminal device from the trusted execution environment; A private key is generated based on the unique device key using a key derivation function; Based on the private key, an elliptic curve signature algorithm is used to generate a public key, and the public key and the private key are combined to form the asymmetric key pair.

[0010] According to some embodiments of this application, the step of signing the device information and root certificate chain data of the terminal device based on the private key in the asymmetric key pair to generate the certificate signing request data includes: The device information of the terminal device is collected in a non-secure general environment, and the device information is transmitted to the trusted execution environment through serialization. Convert the device information and the public key in the asymmetric key pair into a data structure of a preset format; The private key in the asymmetric key pair is used to sign the data structure in the preset format to generate the certificate signing request data.

[0011] According to some embodiments of this application, obtaining the certificate signature request data of the terminal device includes: The certificate signing request data is transmitted from the trusted execution environment to the key service program in the insecure general environment through serialization and deserialization; The certificate signing request data is read from the key service program through the background service program.

[0012] According to some embodiments of this application, the key configuration status between the target application being monitored and the remote configuration server includes: When the terminal device is connected to the network and the target application is started, the target application initiates a key configuration request to the remote configuration server through the key service program of the terminal device; The background service program obtains the response result of the key configuration request and determines the key configuration status based on the response result.

[0013] According to some embodiments of this application, determining the key configuration status based on the response result includes: Obtain the system identifier value returned by the key service program and the configuration status code returned by the remote configuration server; When the system identifier value is a preset abnormal value and the configuration status code is a preset unauthorized status code, the key configuration status is determined to be configuration failure.

[0014] According to some embodiments of this application, the step of sending the certificate signing request data to the vendor server further includes: The certificate signing request data is encrypted to generate encrypted certificate signing request data.

[0015] Secondly, embodiments of this application provide a real-time update system for remote keys.

[0016] The real-time update system for remote keys in this embodiment includes: a data acquisition module for acquiring certificate signing request data from the terminal device and saving the certificate signing request data to a secure storage area; a status monitoring module for monitoring the key configuration status between the target application and the remote configuration server; a data extraction module for extracting the certificate signing request data from the secure storage area when the key configuration status is configuration failure; and a data sending module for sending the certificate signing request data to the vendor server, so that the vendor server uploads the certificate signing request data to the remote configuration server for verification and configuration.

[0017] Thirdly, embodiments of this application provide an electronic device.

[0018] The electronic device of the embodiment includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement a method for real-time updating of a remote key according to any embodiment of the first aspect. Attached Figure Description

[0019] The present application will be further described below with reference to the accompanying drawings and embodiments, wherein: Figure 1 A flowchart illustrating a method for real-time updating of a remote key provided in an embodiment of this application; Figure 2 A flowchart illustrating the certificate signature request data generation process provided in this application embodiment; Figure 3 A flowchart illustrating the asymmetric key pair generation process provided in this application embodiment; Figure 4 A flowchart illustrating the certificate signature request data generation process provided in this application embodiment; Figure 5 A flowchart illustrating the certificate signature request data transmission and reading process provided in this application embodiment; Figure 6 A flowchart illustrating the key configuration status monitoring process provided in this application embodiment; Figure 7 A flowchart illustrating the key configuration failure determination process provided in this application embodiment; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0021] In the description of this application, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0022] In the description of this application, "several" means one or more, "multiple" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0023] In the description of this application, unless otherwise expressly defined, terms such as "setup," "installation," and "connection" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this application in conjunction with the specific content of the technical solution.

[0024] In the description of this application, the terms "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0025] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0026] In a first aspect, embodiments of this application provide a method for real-time updating of a remote key.

[0027] The real-time update method for remote keys in this embodiment can be applied to terminal devices, such as mobile phones, tablets, and smart TVs, which have network connectivity and need to support playback of copyrighted content. Figure 1 As shown, the real-time update method for the remote key in this embodiment includes, but is not limited to, steps S100 to S400: S100: Obtain the certificate signing request data of the terminal device and save the certificate signing request data to the secure storage area; S200: Monitor the key configuration status between the target application and the remote configuration server; S300. If the key configuration status is "configuration failed", retrieve the certificate signing request data from the secure storage area. S400: Send the certificate signing request data to the vendor server so that the vendor server can upload the certificate signing request data to the remote configuration server for verification and configuration.

[0028] In step S100, the Certificate Signing Request (CSR) is credential data used to prove the legitimacy of the terminal device's identity to the remote configuration server. It is generated based on the terminal device's Boot Certificate Chain (BCC), and each terminal device's generated CSR uniquely corresponds to that device. The terminal device pre-generates the CSR, reads it from the device's key service program (e.g., Widevine Service) via a background service program (e.g., SoC RKPTool), and persistently writes it to the terminal device's secure storage area. The secure storage area is a protected storage space within the terminal device with access control, ensuring that the CSR is not read or tampered with by unauthorized programs, thereby ensuring the integrity and security of the data during subsequent use.

[0029] In step S200, the target application refers to an application that requires Digital Rights Management (DRM) authentication to function properly, such as copyright-protected content streaming platforms like Netflix and Prime Video. The remote configuration server is the server responsible for issuing DRM certificates and configuring keys for terminal devices, such as the Google Widevine provisioning server. When the target application is launched by the user while the terminal device is connected to the internet, the target application triggers a key configuration process (provision process) with the remote configuration server, attempting to obtain a DRM certificate for the terminal device to gain encryption and decryption permissions for secure video content. The background service program continuously monitors the interaction results of the above key configuration process, obtaining the key configuration status in real time so that subsequent remedial procedures can be triggered promptly in case of configuration anomalies.

[0030] In step S300, when the background service program determines, based on the monitoring result of step S200, that the key configuration status between the target application and the remote configuration server has failed, the background service program retrieves the certificate signing request data pre-saved in step S100 from the secure storage area to prepare data for the subsequent remedial upload process. Key configuration failure is usually caused by the factory production stage failing to extract and upload the certificate signing request data from the terminal device to the remote configuration server, resulting in the remote configuration server being unable to recognize the terminal device's identity and thus refusing to issue a DRM certificate. By automatically extracting the pre-stored certificate signing request data when configuration fails, an automated remediation process can be initiated without user intervention or the need for the terminal device to be returned to the factory.

[0031] In step S400, the background service program sends the certificate signing request data extracted in step S300 to the vendor server (i.e., the OEM server) via a network communication protocol (e.g., HTTP). Upon receiving the certificate signing request data, the vendor server verifies its validity. If the verification is successful, it uploads the data to the remote configuration server. After receiving and verifying the certificate signing request data, the remote configuration server issues an OEM certificate and a DRM certificate to the terminal device, completing the key configuration. At this point, the terminal device obtains Widevine L1 secure video encryption and decryption certification. When the user restarts the target application, the application can successfully complete provisioning interaction with the terminal device's key service program, enabling normal playback of secure video content.

[0032] The real-time update method for remote keys provided in this embodiment can automatically detect the configuration failure status and trigger a remedial upload process when the key configuration fails due to the omission of certificate signature request data upload during the factory production stage. This eliminates the need for manual user intervention and the need for the device to be returned to the factory. It effectively solves the problem of copyright protection content platforms being unusable, products being returned, or being recalled due to production errors, and has important practical significance for product delivery.

[0033] Understandably, before executing step S100 (obtaining certificate signing request data), the terminal device needs to pre-generate the certificate signing request data. Therefore, in some embodiments, such as Figure 2 As shown, before "obtaining the certificate signature request data of the terminal device" in step S100, there are further steps including but not limited to S110 to S120: S110. In the trusted execution environment of the terminal device, generate an asymmetric key pair based on the unique device key of the terminal device; S120. Based on the private key in the asymmetric key pair, sign the device information and root certificate chain data of the terminal device to generate certificate signing request data.

[0034] To facilitate understanding, the key terms involved in this embodiment will be explained first: Trusted Execution Environment (TEE): An independent and isolated runtime environment in which all resources such as memory and registers are opaque and inaccessible to the external runtime environment (including the general-purpose operating system kernel and user space). TEE only executes verified trusted code (such as OECrypto), thereby ensuring that the key data generated and processed within it will not be intercepted or tampered with by malicious programs.

[0035] Rich Execution Environment (REE): A general-purpose operating environment for mobile terminal devices, running a general-purpose operating system (such as Android), and hosting ordinary applications and system services, including key service programs such as WidevineService. In contrast to a TEE, applications in an REE environment do not have direct access to the data and operations within the TEE.

[0036] Trusted Application (TA): An application running in a TEE environment, responsible for performing operations that require high-security protection, such as key generation and data signing.

[0037] Client Application (CA): An application running in the REE environment. It can send service requests to the TA in the TEE through the TEE standard communication interface (such as the GlobalPlatform TEE Client API), but it cannot directly read sensitive data inside the TEE.

[0038] Boot Certificate Chain (BCC): This is the root certificate chain data generated by the terminal device during startup based on the DICE (Device Identity Composition Engine) mechanism. Its uniqueness is bound to the device hardware, and each device generates a unique and unforgeable BCC. BCC data is one of the core foundational materials for generating certificate signing request data.

[0039] Unique Device Secret (UDS): A unique key value stored in the terminal device's TEE security system and bound to the device hardware. It is not visible to the outside world and is the root of trust for the unique asymmetric key pair of the derived device.

[0040] In step S110, the Trusted Execution Environment (TEE) of the terminal device provides hardware-level isolation security. The generation process of the asymmetric key pair is entirely performed within the TEE. The unique device key (UDS) upon which the generation process depends, and the generated private key, are not exposed to the outside of the TEE in plaintext, thereby preventing the private key from being read or tampered with by external programs (including general-purpose operating systems), ensuring the uniqueness and security of the key. Since the unique device key is bound to the hardware of the terminal device, the asymmetric key pairs generated by different devices are different, thus achieving the security goal of each terminal device having a unique identity. The private key in this asymmetric key pair is used for subsequent data signing operations, and the public key is used to construct the root certificate chain data and is ultimately included in the certificate signing request data, where the remote configuration server verifies the device identity.

[0041] In step S120, after generating the asymmetric key pair in step S110, the trusted application (TA) in the TEE uses the private key from this asymmetric key pair as the signing key to digitally sign the device information and root certificate chain (BCC) data of the terminal device, generating certificate signing request (CSR) data. The device information describes the hardware and software attributes of the terminal device, including the device brand, model, product name, manufacturer, security level, and operating system version, used to prove the hardware and software compliance of the terminal device to the remote configuration server. The root certificate chain data is generated based on the terminal device's boot link, reflecting the complete trusted metric chain from the hardware root of trust to the software environment, and is the core credential for device authentication in the Widevineprovision4 remote key scheme. By signing the above data using the device's unique private key, an unforgeable binding relationship is formed between the certificate signing request data and the specific terminal device—even if the certificate signing request data is intercepted during transmission, an attacker cannot forge a legitimate certificate signing request from another device.

[0042] like Figure 3 As shown, in some embodiments, step S110 further includes, but is not limited to, steps S111 to S113: S111. Obtain the unique device key of the terminal device from the trusted execution environment; S112. Generate a private key based on the unique device key using a key derivation function; S113. Based on the private key, generate a public key using the elliptic curve signature algorithm, and combine the public key and the private key to form an asymmetric key pair.

[0043] In step S111, the unique device key (UDS) is stored in the TEE security system of the terminal device. For example, a data named "huk" (Hardware Unique Key) extracted from the TEE security system can be used as the unique device key value. This key value is a 16-byte (128-bit) hexadecimal data, written by the chip manufacturer during the chip manufacturing stage and protected by the TEE's access control. Each device's huk value is unique and invisible to the outside of the TEE, meaning it cannot be directly read by a general operating system or any application on the REE side, thus ensuring the security and trustworthiness of the key derivation process. In this step, the trusted application (TA) running in the TEE reads the aforementioned unique device key by calling the protected interface provided by the TEE security system, providing input material for subsequent key derivation operations. This operation is performed entirely within the TEE isolation environment; the value of the unique device key is not transmitted to the outside of the TEE in any form.

[0044] In step S112, after obtaining the unique device key (16 bytes), TA calls HKDF (HMAC-based Key Derivation Function) to perform key derivation operations on the unique device key, generating 32 bytes (256 bits) of hexadecimal data as the private key material for the ED25519 type asymmetric key pair. HKDF is a standard HMAC-based key derivation mechanism defined in RFC 5869. Its core advantage lies in the fact that even if the entropy value of the input material (i.e., the unique device key) is insufficient, HKDF can expand the input key material into a derived key with uniform distribution characteristics that meets cryptographic security requirements through a two-stage "extract-expand" operation.

[0045] For example, HKDF uses a unique device key as input key material, extracts and expands it using the SHA-256 hash function, and outputs 32 bytes of derived key data. This derivation process is deterministic—the same input unique device key always produces the same 32-byte derivation result, thus ensuring that the private key generated by the same device at different times remains consistent, providing a guarantee for the device's persistent identity. It is important to note that the entire key derivation process is completed within the TEE, and the derived private key is only used within the TEE and will not be transmitted to the REE or exposed externally in any form, effectively preventing the security risk of the private key being intercepted by malicious programs.

[0046] In step S113, after generating the 32-byte private key material in step S112, TA calls the ED25519 elliptic curve signature algorithm to generate the corresponding 32-byte (256-bit) public key data based on the aforementioned 32-byte private key data. ED25519 is an elliptic curve digital signature algorithm based on the Twisted Edwards Curve (Curve 25519), possessing the following characteristics: high security, providing 128-bit security strength, effectively resisting various known cryptographic attacks, including side-channel attacks; fast signing and verification speeds, low computational overhead, suitable for resource-constrained embedded device TEE environments; the signing process does not rely on random number generation, avoiding security vulnerabilities caused by poor random number quality (such as known ECDSA random number reuse attacks); both the public and private keys are 32 bytes, suitable for secure storage environments with limited storage resources.

[0047] In step S113, based on the 32-byte private key material generated in step S112, a 32-byte public key is derived using the ED25519 algorithm. This 32-byte public key is then appended to the end of the private key, forming a complete 64-byte private key data set (the first 32 bytes are the original private key material, and the last 32 bytes are the corresponding public key). The 32-byte public key and the 64-byte private key together constitute a unique ED25519 type asymmetric key pair for the device. In this asymmetric key pair, the public key is used to construct the root certificate chain (BCC) data and include it in the certificate signing request for remote configuration server authentication of the device. The private key remains within the TEE and is used to sign the certificate signing request data to prove the authenticity of the request and the uniqueness of the device. Because the private key never leaves the TEE security environment, the entire key pair usage process has extremely high security.

[0048] like Figure 4 As shown, in some embodiments, step S120 further includes, but is not limited to, steps S121 to S123: S121. Collect device information of terminal devices in a non-secure general environment, and transmit the device information to a trusted execution environment through serialization; S122. Convert the device information and the public key in the asymmetric key pair into a data structure of a preset format; S123. Use the private key in the asymmetric key pair to sign the data structure in the preset format and generate certificate signing request data.

[0049] In step S121, the device information reflects the hardware and software attributes of the terminal device. Its collection is performed by a key service program running in the REE (Remotely Secure Environment) through an interface provided by the Android system. For example, in one specific embodiment, the collected device information structure (DeviceInfoV3) includes, but is not limited to, the following fields: brand (device brand name), fused (device fusion status), model (device model), device identifier, product (product name), vb_state (Verified Boot status), os_version (operating system version number), manufacturer (device manufacturer name), vbmeta_digest (verified boot metadata digest), security_level (device security level), boot_patch_level (boot patch security level), bootloader_state (bootloader status), system_patch_level (system patch security level), and vendor_patch_level (vendor patch security level).

[0050] Because of the isolation boundary between the TEE security environment and the REE general environment, direct memory data sharing is not possible between the two. Therefore, device information data needs to be transmitted across the environment boundary through serialization and deserialization mechanisms. For example, the Widevine Service (CA) on the REE side serializes the structure containing the aforementioned device information, converting it into a continuous byte stream. This serialized byte stream is then transmitted to the Trusted Application (TA) on the TEE side via the TEE's general standard communication interface. Upon receiving the byte stream, the TA deserializes it, restoring the data and storing it in a custom structure within the TA for subsequent processing. Using serialization / deserialization mechanisms for cross-environment data transmission satisfies the data communication needs between the TEE and REE, ensures the consistency and integrity of the transmitted data format, and avoids direct exposure of the TEE's internal memory structure, thus maintaining the security boundary of the TEE environment.

[0051] In step S122, in some embodiments, after the TA completes the reception of device information and generates an ED25519 asymmetric key pair, the TA extracts the public key (32 bytes) from the asymmetric key pair and converts the device information structure and the public key data together into a CBOR (Concise Binary Object Representation) format data structure. CBOR is a lightweight binary data format designed based on the JSON data model. Compared to the text format of JSON, CBOR uses binary encoding, resulting in a smaller data size, making it suitable for network transmission between terminal devices and servers. CBOR is an IETF standard format, and the Widevine provision4 protocol specification explicitly requires the use of CBOR format to encode CSR data, ensuring protocol compatibility with Google Remote Configuration Server. CBOR supports multiple data types such as integers, byte strings, text strings, arrays, and mappings, and can completely and losslessly express complex device information structures. The TA can encode the data in each field of the device information structure and the ED25519 public key data into a binary data structure that conforms to the CBOR format specification, according to the Widevineprovision4 protocol specification and the predefined field order and data type mapping relationship, to form a data payload to be signed.

[0052] In step S123, in some embodiments, after the device information and public key are encapsulated in CBOR format, the TA calls the ED25519 private key (64 bytes) generated in steps S112 / S113 to perform a digital signature operation on the CBOR format data structure generated in step S122, generating an ED25519 digital signature. The ED25519 signature algorithm takes the private key and the message to be signed as input and outputs a 64-byte signature value. This signature process is deterministic; using the same private key for the same message always produces the same signature result, without relying on an external random number source, eliminating the risk of private key leakage due to random number generation quality issues. The signature value is combined with the CBOR format data structure generated in step S122 to finally form the complete Certificate Signing Request (CSR) data. For example, the CSR data includes: Device Information, structured data describing the hardware and software attributes of the terminal device; an ED25519 public key, serving as the raw data for the BCC (Root Certificate DICE Chain), used by the remote configuration server to verify the device's identity; and an ED25519 digital signature, generated by signing the above data with the device's unique private key, proving that the CSR data was generated by this specific device and possesses unforgeability and non-repudiation. Upon receiving the CSR data, the remote configuration server can verify the signature using the public key contained within, thereby confirming that the CSR data indeed originates from this specific terminal device, and subsequently issuing an OEM certificate and a DRM certificate. The entire CSR generation and signing process is completed within the TEE, and the private key never leaves the TEE's secure environment, ensuring the unforgeability and integrity of the CSR data.

[0053] Understandably, after generating the certificate signing request data, this data needs to be securely and completely transferred from the TEE (Trusted Execution Environment) to the key service program in the REE (Insecure General Environment), and read by the background service program for subsequent secure storage and monitoring processes. For example... Figure 5 As shown, in some embodiments, step S100 further includes, but is not limited to, steps S130 to S140: S130. Transmit the certificate signing request data from the trusted execution environment to the key service program in the insecure general environment through serialization and deserialization; S140. Read the certificate signing request data from the key service program through the background service program.

[0054] In step S130, the trusted application (TA) on the TEE side has completed the construction of the Certificate Signing Request (CSR) data and private key signing within a secure isolation environment, forming complete CSR data. Because there are strict physical and logical isolation boundaries between the TEE and REE, data generated within the TEE cannot be directly accessed by programs on the REE side. Therefore, a standardized cross-environment data transmission mechanism is needed to securely transmit the CSR data to the key service program on the REE side (such as the Widevine Service in the Android system). The cross-environment transmission process of CSR data is implemented through serialization and deserialization mechanisms. For example, the steps are as follows: (1) The TA serializes the CSR data (containing CBOR-encoded device information, ED25519 public key and private key signature data) held inside the TEE, converting it into a continuous, standardized byte stream. The serialization operation maps complex data structures in memory (including nested structures, byte arrays, etc.) into a linear byte sequence, enabling data to be transmitted between two isolated runtime environments in a unified binary form, avoiding data corruption or misinterpretation caused by differences in memory layout or inconsistent data type definitions between the two environments.

[0055] (2) The TA transmits the serialized CSR byte stream data to the client application (CA, i.e., the communication proxy module in the Widevine Service process) on the REE side through the standard communication interface between the TEE and REE. The TEE Client API is a set of standardized interface specifications that have been certified with security, providing a parameter passing channel (TEEC_Parameter) to support the transfer of data between the CA on the REE side and the TA on the TEE side in the form of shared memory or pass-by-value. In the specific implementation, the serialized CSR byte stream data is transmitted through shared memory. The TEE side writes to the shared memory area, and the REE side reads from the same shared memory area. The entire transmission process is managed by the TEE kernel driver (TEE driver), which ensures the security and data integrity of the transmission process and prevents the data from being tampered with or intercepted during the transmission process.

[0056] (3) Upon receiving the CSR byte stream data transmitted via shared memory, the Widevine Service (acting as the CA) on the REE side performs deserialization, restoring the byte stream into a structured CSR data object that can be called by the program on the REE side. The deserialization process is performed according to the format specification corresponding to the serialization on the TEE side, ensuring that the restored CSR data is completely consistent with the original data on the TEE side in content, without any missing fields or data truncation. After deserialization, the Widevine Service holds the complete CSR data and provides an interface for reading CSR data to other processes (such as background service programs) in the system through the Android BinderIPC (inter-process communication) mechanism for subsequent steps to call. Through the above serialization and deserialization mechanisms, the transmission of CSR data from the trusted application on the TEE side to the key service program on the REE side achieves secure and complete data transmission while meeting the TEE security isolation boundary constraints, laying the data foundation for the subsequent persistent storage of CSR data.

[0057] In step S140, the background service program (SoC RKP Tool) running on the terminal device detects that CSR data based on BCC (Root Certificate DICE Chain) has been generated in WidevineService, and then actively initiates a CSR data reading operation. For example, the SoC RKP Tool background service program runs as a background resident process on the REE side (Android system layer), continuously working during the normal operation of the terminal device. The SoC RKP Tool continuously monitors the status of Widevine Service through polling or event notification mechanisms to determine whether BCC-based CSR data is ready for reading in Widevine Service. When Widevine Service completes the deserialization of the CSR data and exposes the reading interface, the SoC RKP Tool background service program is triggered to execute the CSR data reading operation. The SoC RKP Tool background service program calls the CSR data reading interface exposed by Widevine Service through the inter-process communication (IPC) mechanism provided by the Android system (such as Android Binder) to completely read the deserialized and restored CSR data from Widevine Service. During the reading process, the background service program needs to perform a preliminary verification of the integrity of the read CSR data, such as checking the byte length of the CSR data and the header identifier field of the data structure, to confirm that the CSR data has not been damaged or truncated during transmission.

[0058] Understandably, when the terminal device is first started, the process of generating CSR on the TEE side (steps S110 to S123) and transmitting CSR data to the REE (step S130) is completed during the Widevine Service initialization phase. At this time, the target application has not yet started the provisioning process. The SoC RKP Tool background service program immediately performs reading (step S140) after the above CSR data is ready and writes it to the secure storage area (save operation in step S100). The completion of the above pre-storage operation is the data prerequisite for the subsequent monitoring step (S200) and remedial process (S300, S400), ensuring that when provisioning fails and CSR data needs to be extracted, complete and valid CSR data is pre-stored in the secure storage area and is available for use.

[0059] Through steps S130 and S140, the real-time update method for the remote key in this embodiment realizes a complete and secure transmission link of CSR data from the TEE secure generation environment to the REE backend service program. Without compromising the TEE security boundary, it completes the extraction and reception of CSR data, providing necessary data support for subsequent secure storage and real-time monitoring remediation processes.

[0060] like Figure 6 As shown, in some embodiments, step S200 further includes, but is not limited to, steps S210 to S220: S210. When the terminal device is connected to the network and the target application is started, the target application initiates a key configuration request to the remote configuration server through the key service program of the terminal device. S220. The background service program obtains the response result of the key configuration request and determines the key configuration status based on the response result.

[0061] In step S210, the initiation of a key configuration request (provision request) requires the following conditions to be met: the terminal device is connected to the network and the target application is launched. Playback of secure streaming content relies on real-time online verification of DRM certificates. The provision configuration process requires network communication between the terminal device and Google's remote configuration server. Therefore, the provision process will only be triggered if the terminal device successfully connects to an external network (Wi-Fi or mobile data network). If the terminal device is offline, the provision configuration process will not be initiated. The background service program (SoC RKPTool) will detect this status, pause listening, and wait for the network connection to be restored. The target application refers to a copyright-protected application that requires DRM (Digital Rights Management) authentication to play secure video content, including but not limited to streaming copyright-protected content platforms such as Netflix and Amazon Prime Video. When the terminal user launches the target application for the first time, or when the target application is installed but has not yet completed provision configuration, the target application will actively trigger the provision process to attempt to obtain the Widevine L1 secure video encryption / decryption OEM certificate and DRM certificate for the terminal device.

[0062] When both of the above conditions are met, the target application (such as Netflix) interacts with the Widevine Service on the REE side via the MediaDrm API provided by the Android system, triggering the provision configuration process. For example, the target application calls standard Android MediaDrm interfaces such as MediaDrm.KEY_TYPE_STREAMING or MediaDrm.provideProvisionResponse() to notify the Widevine Service to initiate a provision configuration request. After receiving the provision trigger instruction from the target application, the Widevine Service constructs a standard Widevine provision4 remote key configuration request message based on the generated CSR data (BCC certificate signing request), and through the system's appProcess, sends a key configuration request (HTTP Request) to the Google Remote Provisioning Server (Google Provisioning Server) via HTTP protocol. The request asks the server to verify the CSR data of the terminal device and issue an OEM certificate and DRM certificate for the device. Understandably, the Widevine Service is a core system service component in the Android system responsible for Widevine DRM key management and provisioning configuration processes. In the provisioning process, it plays the following roles: providing a provisioning status query interface to the target application, exposing provisioning status information such as the current device's systemID; and acting as a proxy intermediary layer for provisioning communication between the terminal device and the Google Remote Provisioning Server, responsible for constructing and sending provisioning request messages, and receiving and processing the server's response results.

[0063] In step S220, the SoC RKP Tool background service runs in the Android system as a persistent background process, continuously running during normal operation of the terminal device. After the target application initiates a provisioning request, the SoC RKP Tool background service continuously obtains the response results of the provisioning process through the following two parallel data channels: Data Channel 1: Widevine Service systemID Query Channel. The SoC RKP Tool background service program periodically polls the system identifier interface exposed by Widevine Service (DRPC) to obtain the systemID value currently maintained by Widevine Service. The systemID is an integer value used by Widevine Service to identify the provisioning status of the terminal device during the provisioning configuration process.

[0064] Data Channel Two: HTTP Response Listening Channel of the System's appProcess. After a provisioning request is sent, the Google Remote Provisioning Server returns an HTTP Status Code, which reflects the server's processing result for the provisioning request. The SoC RKP Tool background service listens to the system's appProcess to capture the HTTP WidevineRKP provisioning response status value (i.e., the HTTP response status code) returned from the Google Remote Provisioning Server, using it as one of the important bases for determining the provisioning status.

[0065] After obtaining the response results from the two data channels simultaneously, the SoC RKP Tool background service program combines the two results to make a comprehensive judgment and finally determine the key configuration status (configuration successful or configuration failed) of this provision process.

[0066] If the response results from both channels meet the expected criteria for successful provisioning, the key configuration status is determined to be successful, the background service program does not trigger the remediation process, the terminal device has obtained Widevine L1 secure video encryption and decryption permissions, and the target application can play secure video content normally; if the response results from both channels simultaneously meet the criteria for provisioning failure, the key configuration status is determined to be failed, and the background service program triggers the CSR data extraction and reporting remediation process described in steps S300 and S400.

[0067] Understandable, such as Figure 7 As shown, in some embodiments, step S220, "determining the key configuration status based on the response result," further includes, but is not limited to, steps S221 to S222: S221. Obtain the system identifier value returned by the key service program and the configuration status code returned by the remote configuration server; S222. When the system identifier value is a preset abnormal value and the configuration status code is a preset unauthorized status code, the key configuration status is determined to be configuration failure.

[0068] In step S221, the SoC RKP Tool background service program obtains two types of key data for provision status determination from two independent data sources: obtain the system identifier value (systemID) and obtain the configuration status code.

[0069] (1) Obtain the system identifier (systemID). The SoC RKP Tool background service program calls the provision status query interface exposed by WidevineService (DRPC) to read the systemID value maintained by Widevine Service. The systemID is a 32-bit signed integer (int32) value dynamically maintained by Widevine Service in the provision configuration process, used to identify the provision configuration status of the current terminal device: When provisioning is successful, Widevine Service obtains valid OEM and DRM certificates from Google's remote configuration server. The systemID is then updated to an integer identifier (usually a valid positive integer, with an absolute value much smaller than the maximum value of int32) assigned to the device by Google's server. If provisioning is incomplete or fails, Widevine Service cannot obtain valid certificate allocation results from Google's server. The systemID remains at the default placeholder value defined internally by Widevine Service, which is the maximum value of int32: 2,147,483,647 (this value applies to both 32-bit and 64-bit systems, and its hexadecimal representation is 0x7FFFFFFF). This value serves as a default exception value and is defined internally by Widevine Service as a marker of provisioning status anomalies.

[0070] (2) Obtaining the configuration status code. After the provision configuration request is sent to the Google remote configuration server through the system's appProcess process, the Google server returns an HTTP response status code via the HTTP protocol, reflecting the server's processing result for this provision request. The SoC RKP Tool background service program captures the above HTTP response status code by listening to the system's appProcess process, and uses it as the configuration status code. For example, in the Widevineprovision4 remote key configuration scenario, the configuration status codes that may be returned mainly include the following categories: 200 OK, the request was processed successfully; 400 Bad Request, the request format is incorrect; 401 Unauthorized; 403 Forbidden, access is denied; 500 Internal Server Error.

[0071] In the Widevine provisioning 4 scenario, the HTTP 401 (Unauthorized) status code has specific business semantics: this status code indicates that the Google Remote Provisioning Server cannot find a registration record in its database that matches the current end-device's CSR. In other words, the end-device's CSR file was never uploaded to the Google Provisioning Server, and the server therefore refuses to issue OEM and DRM certificates, notifying the end-device with an HTTP 401 response code. This is a direct result of the OEM factory failing to extract or upload the CSR file during the production phase, leading to a server-side error response.

[0072] In step S222, after the SoC RKP Tool background service program obtains the two types of judgment data from step S221, it can use dual-condition joint judgment logic to make a final judgment on the provision configuration status: Condition 1 (Preset anomaly detection): The systemID value obtained from Widevine Service (DRPC) is equal to the maximum value of int32 type, i.e., systemID == 2,147,483,647; Condition 2 (Preset Unauthorized Status Code Determination): The HTTP response status code captured from the system appProcess and returned by the Google Remote Configuration Server is equal to HTTP 401, i.e., HTTP Status Code == 401 Unauthorized.

[0073] Using a dual-condition approach of "Widevine systemID outlier value + HTTP 401 status code" for judgment, rather than a single-condition approach, improves accuracy and avoids false positives. Relying solely on a systemID that is at its maximum value is insufficient to accurately distinguish between situations like "CSR not registered" and "temporary provisioning failure due to network instability." For example, when the terminal device's network connection is unstable, the provisioning request may fail due to timeout, causing the systemID to remain at its maximum value. However, in this case, Google's server does not return an HTTP 401, but rather a timeout error or no response. If provisioning failure is judged solely based on an outlier systemID value and CSR uploads are triggered, unnecessary CSR data reporting requests will occur, placing an additional burden on the server.

[0074] It should be noted that the SoC RKP Tool background service program continuously and in real-time monitors the provisioning configuration status, rather than performing a one-time check. Each time the target application is started and the provisioning process is triggered, the background service program performs the aforementioned monitoring and judgment operations, ensuring that any provisioning configuration failure event can be detected and responded to promptly, thus guaranteeing the real-time nature and reliability of the remediation process.

[0075] In some embodiments, before "sending the certificate signing request data to the vendor server" in step S400, the method may include, but is not limited to, step S500: S500: Encrypt the certificate signing request data to generate encrypted certificate signing request data.

[0076] In step S500, the encryption algorithm used to encrypt the certificate signing request data is determined by mutual agreement between the SoC chip manufacturer (SoC) and the OEM manufacturer's server. Examples include, but are not limited to, the following two encryption methods.

[0077] Method 1: AES Symmetric Encryption Scheme. In this scheme, the SoC chip manufacturer and the OEM manufacturer's server pre-agree on a shared AES key (Pre-shared Key, PSK) during the system deployment phase. This shared key is stored in the secure storage area of ​​the terminal device and is only visible to the SoC RKP Tool background service program, not directly accessible to external programs. During step S500, the SoC RKP Tool background service program uses the aforementioned pre-shared AES key to perform AES encryption on the plaintext CSR data extracted from the secure storage area, generating encrypted CSR ciphertext data (i.e., encrypted certificate signature request data). After receiving the encrypted CSR ciphertext data, the OEM manufacturer's server uses the same AES key agreed upon with the terminal device to perform a decryption operation, restoring the plaintext CSR data, and then performs subsequent legitimacy verification and upload processing.

[0078] Method 2: RSA Asymmetric Encryption Scheme. In this scheme, the OEM manufacturer's server generates an RSA key pair and pre-distributes the RSA public key to the terminal device (this can be written to a secure storage area before the device leaves the factory, or distributed via a secure channel during the device initialization phase). During step S500, the SoC RKP Tool background service program uses the OEM manufacturer's server's RSA public key to encrypt the plaintext CSR data, generating RSA-encrypted ciphertext CSR data. Since only the OEM manufacturer's server holding the corresponding RSA private key can decrypt the ciphertext, even if the ciphertext is intercepted during network transmission, an attacker cannot recover the plaintext CSR data without the RSA private key, thus ensuring data confidentiality. After receiving the RSA-encrypted ciphertext CSR data, the OEM manufacturer's server uses its RSA private key to perform a decryption operation, recovering the plaintext CSR data, and then performs subsequent processing.

[0079] Understandably, regardless of whether AES or RSA is used, the key type and specific parameters used for encryption are jointly negotiated and agreed upon by the SoC chip manufacturer and the OEM manufacturer during the system deployment phase. This ensures that the encryption operations on the terminal device side and the decryption operations on the OEM manufacturer's server side completely correspond in terms of key, algorithm type, and parameters, guaranteeing the correctness of the encryption and decryption process. The specific key negotiation and distribution mechanism needs to be designed in conjunction with the security strategy of the actual production deployment environment to ensure that the key is not leaked during distribution and storage.

[0080] Before sending the CSR data to the OEM server via HTTP (step S400), the SoC RKP Tool background service program first performs the encryption processing described in step S500 on the plaintext CSR data, converting the plaintext CSR data into encrypted CSR ciphertext data (i.e., encrypted certificate signing request data). Then, step S400 sends this encrypted certificate signing request data (not the original plaintext CSR) to the OEM server via the HTTP protocol network communication module. Even if the HTTP communication process is intercepted by a man-in-the-middle attack, the attacker will only obtain the encrypted CSR ciphertext data and will not be able to reconstruct the valid plaintext CSR data, thus effectively preventing the risk of CSR data leakage during network transmission. After receiving the encrypted certificate signing request data, the OEM server decrypts it using the corresponding decryption key pre-agreed with the terminal device, restoring it to plaintext CSR data, then performs a validity check, and uploads the verified CSR data to the Google provisioning server to complete the subsequent provisioning process.

[0081] Secondly, embodiments of this application provide a real-time update system for remote keys.

[0082] The real-time update system for remote keys in this embodiment includes a data acquisition module, a status monitoring module, a data extraction module, and a data sending module.

[0083] The data acquisition module in this embodiment is used to acquire certificate signing request data from the terminal device and save the certificate signing request data to a secure storage area. In some embodiments, the function of the data acquisition module is mainly implemented by the CSR data reading subunit and CSR data writing subunit in the SoC RKP Tool background service program. The CSR data reading subunit is responsible for detecting the readiness status of CSR data in Widevine Service (DRPC), and after the CSR data is ready, it calls the standard CSR data reading interface exposed by Widevine Service (such as the generateCertificateRequest interface) through the Android Binder IPC inter-process communication mechanism to read the CSR data generated based on BCC (root certificate DICE chain) from Widevine Service. The read CSR data contains the terminal device's device information, ED25519 public key, and digital signature generated by the device's unique private key, which is the identity credential data uniquely bound to the hardware of that specific terminal device. After the CSR data reading subunit completes the CSR data reading, the CSR data writing subunit writes the CSR data to the secure storage area of ​​the terminal device for persistent storage, ensuring that the CSR data can be reliably retrieved in subsequent provisioning and remediation processes. The operation of writing CSR data to the secure storage area is protected by access control, guaranteeing the storage security and integrity of the CSR data.

[0084] The data acquisition module operates earlier than the provision process. During the normal operation of the terminal device (i.e., after Widevine Service completes the generation of CSR data and exposes the interface), it completes the reading and secure storage of CSR data. This prepares the data in advance for the automatic recovery process in case of subsequent provision failures, and is the data foundation for the entire system to achieve "real-time" recovery capabilities.

[0085] The implementation example's state monitoring module is used to monitor the key configuration status between the target application and the remote configuration server. In some embodiments, the state monitoring module includes a provision trigger awareness subunit, a systemID query subunit, and an HTTP response monitoring subunit in the SoC RKP Tool background service program. These three subunits work together to achieve real-time and accurate monitoring of the provision configuration status. The provision trigger awareness subunit is responsible for sensing the startup event of the target application (such as copyright protection content platforms like Netflix and Amazon Prime Video) and the network status of the terminal device. When the terminal device is connected to the network and the target application is launched by the user, the provision trigger awareness subunit detects that the above conditions have been met and then activates the systemID query subunit and the HTTP response monitoring subunit to actively monitor the status of this provision process. After the target application is launched, the target application triggers the Widevine Service to initiate a provision configuration request through the AndroidMediaDrm standard interface. The Widevine Service, through the system's appProcess process, initiates a key configuration request to the Google provision configuration server via HTTP protocol, attempting to obtain OEM and DRM certificates for the terminal device. The systemID query subunit periodically polls the provision status query interface exposed by Widevine Service (DRPC) via the Android Binder IPC mechanism to continuously obtain the systemID value currently maintained by Widevine Service. The systemID is a 32-bit signed integer (int32) value used internally by Widevine Service to identify the current device provision status: when provisioning succeeds, the systemID is updated to a valid integer identifier value assigned by the Google server; when provisioning fails or is not yet complete, for example, the systemID remains at the maximum value of int32, 2,147,483,647 (i.e., 0x7FFFFFFF), which is defined internally by Widevine Service as a preset flag value for provision status anomalies. The HTTP response monitoring subunit monitors the system's appProcess process to capture the response status code returned by the Google provisioning configuration server via the HTTP protocol in real time. This status code reflects the processing result of the current provisioning configuration request by the Google server.The HTTP response monitoring subunit passes the captured HTTP response status code to the status determination logic, which, together with the query result of the systemID query subunit, is used for a comprehensive determination of the provision configuration status.

[0086] The status monitoring module performs the above monitoring operation every time the target application starts and triggers the provision process. It is continuous and real-time, ensuring that any provision configuration failure event can be detected in a timely manner, providing a reliable guarantee for the accurate triggering of the data extraction module.

[0087] The data extraction module in this embodiment is used to extract certificate signing request data from the secure storage area when the key configuration status is configuration failure. In some embodiments, the function of the data extraction module is implemented collaboratively by the failure status response subunit and the CSR data extraction subunit in the SoC RKP Tool background service program. The failure status response subunit continuously receives the provision configuration status determination result from the status monitoring module. When the status monitoring module determines that the current provision configuration status is configuration failure (for example, simultaneously satisfying the dual conditions of systemID == 2,147,483,647 and HTTP response status code 401 Unauthorized), the failure status response subunit is activated and sends a CSR data extraction instruction to the CSR data extraction subunit, triggering the subsequent automated remediation process. The failure status response subunit triggers the extraction operation every time a provision configuration failure is determined, ensuring the real-time responsiveness of the remediation process. After receiving the extraction instruction, the CSR data extraction subunit accesses the secure storage area of ​​the terminal device, reads the CSR data pre-written by the data acquisition module, and loads it into memory for use by the data sending module. The CSR data extraction subunit performs a preliminary data integrity check during the extraction process to confirm that the extracted CSR data has not been damaged or truncated, thus ensuring the validity of the CSR data subsequently reported to the OEM manufacturer's server.

[0088] By retrieving pre-stored CSR data from a secure storage area on demand when provisioning fails, real-time response and automated processing of provisioning failure scenarios are achieved without manual user intervention or equipment return to the factory, reducing the risk of product returns or recalls due to production errors for OEM manufacturers.

[0089] The data sending module in this embodiment is used to send certificate signing request data to the vendor server, so that the vendor server uploads the certificate signing request data to a remote configuration server for verification and configuration. In some embodiments, the functionality of the data sending module is jointly implemented by the encryption processing subunit and the HTTP sending subunit in the SoC RKP Tool background service program. The encryption processing subunit is used to perform encryption processing on the CSR data before sending the CSR data to the OEM vendor server via the HTTP protocol, generating encrypted certificate signing request data to prevent CSR data leakage during HTTP network transmission. The encryption algorithm type (AES symmetric encryption or RSA asymmetric encryption) is jointly agreed upon and determined by the SoC chip manufacturer and the OEM vendor during the system deployment phase. The HTTP sending subunit is responsible for sending the CSR data (or encrypted CSR ciphertext data) to the OEM vendor server via the HTTP protocol. The HTTP sending subunit constructs a standard HTTP request message, encapsulates the CSR data in the request body, and initiates an HTTP POST request to the pre-configured OEM vendor server address (URL) to report the CSR data to the OEM vendor server. The HTTP sending subunit is also responsible for receiving the processing response result returned by the OEM vendor server to confirm that the CSR data reporting operation has been successfully completed.

[0090] After receiving the CSR data reported by the end device, the OEM manufacturer's server verifies its legitimacy. If the verification is successful, the CSR data is uploaded to the Google Provisioning Server. Upon receiving and verifying the CSR data, the Google Provisioning Server issues an OEM certificate and a DRM certificate to the end device, ultimately completing the configuration of Widevine L1 secure video encryption and decryption permissions. When the end user restarts the target application such as Netflix, the target application can successfully complete the provisioning interaction with the Widevine Service on the end device and play secure video content normally.

[0091] Thirdly, embodiments of this application provide an electronic device.

[0092] Reference Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 500 includes: a memory 501, a processor 502, and a computer program stored on the memory 501 and executable on the processor 502. When the computer program is executed, it is used to perform a real-time update method for a remote key according to any embodiment of the first aspect.

[0093] The processor 502 and the memory 501 can be connected via a bus or other means.

[0094] The memory 501, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs, such as the real-time update method for remote keys according to any embodiment of the first aspect of this application. The processor 502 implements the above-described method by running the non-transitory software program and instructions stored in the memory 501.

[0095] Memory 501 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and application programs required for at least one function; the data storage area may store the methods described above. Furthermore, memory 501 may include high-speed random access memory and may also include non-transitory memory, such as at least one storage device, flash memory, or other non-transitory solid-state storage device. In some embodiments, memory 501 may optionally include memory remotely located relative to processor 502, and these remote memories may be connected to the electronic device 500 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0096] The non-transient software program and instructions required to implement the above method are stored in memory 501. When executed by one or more processors 502, the real-time update method of the remote key of any embodiment of the first aspect is executed.

[0097] The embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of this application. Furthermore, unless otherwise specified, the embodiments and features described in the embodiments of this application can be combined with each other.

Claims

1. A method for real-time updating of a remote key, characterized in that, Applied to terminal devices, the real-time update method for the remote key includes: Obtain the certificate signing request data of the terminal device and save the certificate signing request data to a secure storage area; Monitor the key configuration status between the target application and the remote configuration server; If the key configuration status is configuration failure, the certificate signing request data is retrieved from the secure storage area; The certificate signing request data is sent to the vendor server, so that the vendor server uploads the certificate signing request data to the remote configuration server for verification and configuration.

2. The method for real-time updating of a remote key according to claim 1, characterized in that, The step of obtaining the certificate signing request data of the terminal device also includes: In the trusted execution environment of the terminal device, an asymmetric key pair is generated based on the unique device key of the terminal device; Based on the private key in the asymmetric key pair, the device information and root certificate chain data of the terminal device are signed to generate the certificate signing request data.

3. The method for real-time updating of a remote key according to claim 2, characterized in that, The generation of an asymmetric key pair based on the unique device key of the terminal device includes: Obtain the unique device key of the terminal device from the trusted execution environment; A private key is generated based on the unique device key using a key derivation function; Based on the private key, an elliptic curve signature algorithm is used to generate a public key, and the public key and the private key are combined to form the asymmetric key pair.

4. The method for real-time updating of a remote key according to claim 2, characterized in that, The step of signing the device information and root certificate chain data of the terminal device based on the private key in the asymmetric key pair to generate the certificate signing request data includes: The device information of the terminal device is collected in a non-secure general environment, and the device information is transmitted to the trusted execution environment through serialization. Convert the device information and the public key in the asymmetric key pair into a data structure of a preset format; The private key in the asymmetric key pair is used to sign the data structure in the preset format to generate the certificate signing request data.

5. The method for real-time updating of a remote key according to claim 4, characterized in that, The step of obtaining the certificate signing request data of the terminal device includes: The certificate signing request data is transmitted from the trusted execution environment to the key service program in the insecure general environment through serialization and deserialization; The certificate signing request data is read from the key service program through the background service program.

6. The method for real-time updating of a remote key according to claim 1, characterized in that, The key configuration status between the target application and the remote configuration server being monitored includes: When the terminal device is connected to the network and the target application is started, the target application initiates a key configuration request to the remote configuration server through the key service program of the terminal device; The background service program obtains the response result of the key configuration request and determines the key configuration status based on the response result.

7. The method for real-time updating of a remote key according to claim 6, characterized in that, Determining the key configuration status based on the response result includes: Obtain the system identifier value returned by the key service program and the configuration status code returned by the remote configuration server; When the system identifier value is a preset abnormal value and the configuration status code is a preset unauthorized status code, the key configuration status is determined to be configuration failure.

8. The method for real-time updating of a remote key according to claim 1, characterized in that, Before sending the certificate signing request data to the vendor server, the process also includes: The certificate signing request data is encrypted to generate encrypted certificate signing request data.

9. A real-time remote key update system, applied to a terminal device, characterized in that, include: The data acquisition module is used to acquire the certificate signing request data of the terminal device and save the certificate signing request data to a secure storage area; The status monitoring module is used to monitor the key configuration status between the target application and the remote configuration server; The data extraction module is used to extract the certificate signing request data from the secure storage area when the key configuration status is configuration failure. The data sending module is used to send the certificate signing request data to the vendor server, so that the vendor server uploads the certificate signing request data to the remote configuration server for verification and configuration.

10. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the real-time update method for the remote key according to any one of claims 1 to 8.

Images