WO2019110000A1 - 一种设备数据处理方法及系统 - Google Patents

一种设备数据处理方法及系统 Download PDF

Info

Publication number
WO2019110000A1
WO2019110000A1 PCT/CN2018/119741 CN2018119741W WO2019110000A1 WO 2019110000 A1 WO2019110000 A1 WO 2019110000A1 CN 2018119741 W CN2018119741 W CN 2018119741W WO 2019110000 A1 WO2019110000 A1 WO 2019110000A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
execution environment
device data
trusted execution
data
Prior art date
Application number
PCT/CN2018/119741
Other languages
English (en)
French (fr)
Inventor
赵泳清
Original Assignee
阿里巴巴集团控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2019110000A1 publication Critical patent/WO2019110000A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/30—Computing systems specially adapted for manufacturing

Definitions

  • the present application relates to the field of communications technologies, and in particular, to a device data processing method and system.
  • the present application provides a device data processing method and system, which can prevent customized device data from being used by mobile terminals of other manufacturers.
  • a device data processing system comprising:
  • the host side is configured to determine a key for encrypting the device data, perform an encryption operation on the device data by using the key, and burn the encrypted device data to the device end;
  • the device is configured to determine a key for encrypting the device data, and save the key to a trusted storage area of the trusted execution environment, and receive and save the encryption of the host-side burning in the non-trusted execution environment.
  • Device data is configured to determine a key for encrypting the device data, and save the key to a trusted storage area of the trusted execution environment, and receive and save the encryption of the host-side burning in the non-trusted execution environment.
  • Device data is configured to determine a key for encrypting the device data, and save the key to a trusted storage area of the trusted execution environment, and receive and save the encryption of the host-side burning in the non-trusted execution environment.
  • the process of determining, by the host end, a key for encrypting device data specifically: generating a key for encrypting device data, and burning the key to the device end;
  • the process of determining, by the device end, the key for encrypting the device data includes: receiving the key that is burned by the host end in a non-trusted execution environment.
  • the device performs a process of determining a key for encrypting device data, where the device includes: generating, by the device, a key for encrypting device data in a trusted execution environment, and sending the key to the device Host side
  • the process of the host side performing a key for determining the encryption of the device data includes: receiving a key for encrypting the device data sent by the device end, and saving the key.
  • the process of the device performing the saving of the key to the trusted storage area of the trusted execution environment includes:
  • the trusted execution environment acquires a root key RKEK in the secure hardware device, and performs an encryption operation on the key by using the root key RKEK; wherein the root key RKEK of each secure hardware device is different;
  • the trusted execution environment stores the encrypted key to the trusted storage area.
  • the device is further configured to send the encrypted device data to the trusted execution environment when the non-trusted execution environment needs to use the device data, where the trusted execution environment utilizes The key decrypts the encrypted device data to obtain the device data, and sends the device data to the non-trusted execution environment.
  • the key comprises a symmetric key.
  • a device data processing method is applied to a device end including a non-trusted execution environment and a trusted execution environment, the method comprising:
  • the device data encrypted by the key is received and saved in the non-trusted execution environment.
  • the saving the key to the trusted execution environment includes:
  • the key burning client application in the non-trusted execution environment invokes an application interface of the trusted application environment, and the key burning security of transmitting the key to the trusted execution environment through the application program interface application;
  • the key burning security application of the trusted execution environment sends the key to an operating system of the trusted execution environment
  • the operating system of the trusted execution environment saves the key to a trusted storage area.
  • the operating system of the trusted execution environment saves the key to the trusted storage area, including:
  • the operating system of the trusted execution environment acquires a root key RKEK in the secure hardware device, and performs an encryption operation on the key by using the root key RKEK; wherein the root key RKEK of each secure hardware device different;
  • the operating system of the trusted execution environment stores the encrypted key to the trusted storage area.
  • the determining a key for encrypting device data includes:
  • a key for encrypting device data is generated in the trusted execution environment.
  • the key comprises a symmetric key.
  • a device data processing method is applied to a host end, and the method includes:
  • the encryption operation is performed on the device data by using the key, and the encrypted device data is burned to the device end.
  • the determining, by using the key for encrypting the device data includes:
  • multiple parts of the file or a specified part of the multiple parts are used as device data to be encrypted.
  • the key comprises a symmetric key.
  • a device data processing method is applied to a device end including a non-trusted execution environment and a trusted execution environment, the method comprising:
  • sending the encrypted device data to the trusted execution environment including:
  • the sending the encrypted device data to the trusted execution environment includes:
  • the device fingerprint client application in the non-trusted execution environment invokes an application program interface of the trusted application environment, and sends the encrypted device data to a device fingerprint security application of the trusted execution environment;
  • the sending the device data to the non-trusted execution environment includes: the device fingerprint security application of the trusted execution environment invokes the application program interface, and sends the device data to the non-trusted execution environment Device fingerprint client application.
  • the trusted execution environment decrypts the encrypted device data by using the key to obtain the device data, including:
  • the device fingerprint security application in the trusted execution environment sends the encrypted device data to an operating system of the trusted execution environment
  • the operating system of the trusted execution environment acquires a key from the trusted storage area, and decrypts the encrypted device data by using the key to obtain the device data.
  • the device fingerprint security application invokes an application interface of the non-trusted application environment, and sends the device data to a device fingerprint client application of the non-trusted execution environment.
  • the operating system of the trusted execution environment obtains a key from the trusted storage area, including:
  • the operating system of the trusted execution environment acquires an encrypted key from the trusted storage area, and obtains a root key RKEK from the secure hardware device; wherein the root key RKEK of each secure hardware device is different;
  • the operating system of the trusted execution environment performs a decryption operation on the encrypted key using the root key RKEK to obtain a decrypted key.
  • the key comprises a symmetric key.
  • a device data processing system comprising:
  • the host side is configured to determine a key for encrypting the device data, perform an encryption operation on the device data by using the key, and burn the encrypted device data and the data identifier indicating the device data to the device end. ;
  • the device is configured to determine a key for encrypting the device data, and save the key and the data identifier indicating the device data to a trusted storage area of the trusted execution environment, and receive and save in the non-trusted execution environment.
  • the encrypted device data and the data identifier that are programmed by the host.
  • the process of determining, by the host end, a key for encrypting device data specifically: generating a key for encrypting device data, and burning the key and the data identifier indicating the device data Recorded to the device side;
  • the process of determining, by the device end, the key for encrypting the device data includes: receiving, in the non-trusted execution environment, the key that is burned by the host and the data identifier that represents the device data.
  • the device performs a process of determining a key for encrypting device data, where the device includes: generating, by the device, a key for encrypting device data in a trusted execution environment, and sending the key and Data indicating the device data is identified to the host end;
  • the process of determining, by the host end, the key for encrypting the device data includes: receiving a key and a data identifier that are sent by the device end to encrypt the device data, and correspondingly saving the key and the data Logo.
  • the device performs a process corresponding to saving the key and the data identifier to a trusted storage area of the trusted execution environment, and specifically includes:
  • the trusted execution environment acquires a root key RKEK in the secure hardware device, and performs an encryption operation on the key by using the root key RKEK;
  • the trusted execution environment corresponds to storing the encrypted key and the data identifier to the trusted storage area.
  • the device is further configured to send the encrypted device data and the data identifier to the trusted execution environment if the device data is to be used in a non-trusted execution environment,
  • the trusted execution environment searches for a key corresponding to the data identifier, decrypts the encrypted device data with the key to obtain the device data, and sends the device data to the non-trusted execution environment.
  • the key comprises a symmetric key.
  • a device data processing method is applied to a device end including a non-trusted execution environment and a trusted execution environment, the method comprising:
  • the encrypted device data and the data identifier that are programmed by the host end are received and saved in a non-trusted execution environment.
  • a device data processing method is applied to a host end, and the method includes:
  • the encrypted device data and the data identifier representing the device data are burned to the device side.
  • a device data processing method is applied to a device end including a non-trusted execution environment and a trusted execution environment, the method comprising:
  • the trusted execution environment searches for a key corresponding to the data identifier, and uses the key to decrypt the encrypted device data to obtain device data;
  • the customized device data is encrypted by using the key, and then the encrypted device data is burned to the mobile terminal. Since the encrypted device data is stored by the mobile terminal, the encrypted device data cannot be used even if the encrypted device data is stolen by other manufacturers.
  • FIG. 1a is a schematic structural diagram of a device data processing system according to an embodiment of the present application.
  • FIG. 1b is a flowchart of a device data processing method according to an embodiment of the present application.
  • 3a-3b are schematic diagrams of an executable file disclosed in an embodiment of the present application.
  • FIG. 5 is a flowchart of still another method for processing device data according to an embodiment of the present application.
  • 6a-6b are flowcharts of still another device data processing method disclosed in an embodiment of the present application.
  • FIG. 7 is a flowchart of still another method for processing device data according to an embodiment of the present application.
  • Symmetric key encryption Also known as private key encryption, where the sender and receiver of the message use the same key to encrypt and decrypt the information.
  • Non-trusted execution environment English full name Rich Execution Environment, REE. Enriching the execution environment to provide powerful features and performance is the main design goal. Because the rich execution environment is open, it is also called the non-trusted execution environment.
  • Trusted Execution Environment English full name Trusted Execution Environment, TEE.
  • the trusted execution environment exists in parallel with the non-trusted execution environment, and the trusted execution environment can provide security services for applications in the non-trusted application environment.
  • Customer application English full name Client Application, CA.
  • An application running in a non-trusted execution environment REE is called a client application.
  • Security application English full name Trusted Application, TA.
  • the client application CA can invoke the TEE Client API to request security services from the TA, and the security application TA can provide security services for client applications running in the untrusted application environment REE.
  • ELF Executable and Linkable Format
  • Root key RKEK Stored in a secure hardware device at the factory.
  • the root key RKEK of each secure hardware device is different.
  • an asymmetric key may be used according to actual conditions. That is, an asymmetric key is also within the scope of the present application.
  • the manufacturer in the present application encrypts the customized device data with a symmetric key before burning the customized device data to the mobile terminal, and then The encrypted device data is burned to the non-trusted execution environment of the mobile terminal.
  • the non-trusted execution environment is open, it is possible for other manufacturers to steal encrypted device data. Since the device data is encrypted, the encrypted device data cannot be used by other manufacturers even after stealing the encrypted device data.
  • the symmetric key is saved in the trusted execution environment of the mobile terminal.
  • the encrypted device data can be decrypted by using the symmetric key in the trusted execution environment to obtain and use the device data.
  • the reason why the present application sets the symmetric key in the trusted execution environment is because the trusted execution environment is physically isolated from the non-trusted execution environment, so the trusted execution environment is very secure and can prevent other manufacturers from stealing from trusted execution. Stealing symmetric keys in the environment.
  • the present application can prevent other manufacturers from using customized device data.
  • the mobile terminal includes device data such as an application library and a function library, and the device data includes many executable files.
  • the application can include two aspects:
  • the first aspect multiple executable files share a symmetric key.
  • a common symmetric key can be set for a plurality of executable files.
  • the plurality of executable files perform the encryption operation or the decryption operation by using the symmetric key, the processing procedure is simple and convenient, and the symmetric key is conveniently managed.
  • the device data processing system includes a host end 100 and a device end 200.
  • a device data processing method applied to the above device processing system is provided. See Figure 1b, including the following steps:
  • Step S101 The host end 100 determines and saves a symmetric key for encrypting the device data, and the trusted execution environment of the device end 200 obtains a symmetric key for encrypting the device data.
  • This step has two implementation modes. The following two implementation modes are respectively described.
  • the first implementation manner the host end 100 generates a symmetric key.
  • the host end 100 generates a symmetric key that encrypts the device data and saves the symmetric key.
  • the host side 100 may randomly generate or generate a symmetric key for encrypting the device data according to a preset algorithm, or the host end 100 receives the manufacturer to construct a special symmetric key. This application does not limit the process of generating a symmetric key.
  • the host side 100 saves the symmetric key after determining the symmetric key for subsequent use in performing encryption operations on the device data.
  • Device end 200 includes a non-trusted execution environment and a trusted execution environment.
  • the non-trusted execution environment includes a key burning client application CA
  • the trusted execution environment includes a key burning security application TA.
  • the host terminal 100 burns the symmetric key to the key burning client application CA in the non-trusted execution environment of the device terminal 200 through the burning software.
  • the process transmits symmetric keys in an open environment
  • the process of transmitting symmetric keys is safe because the burning process is performed at the manufacturer's factory.
  • the device end 200 transmits the symmetric key to the trusted execution environment.
  • the key burning client application CA in the non-trusted execution environment invokes the application interface (TEE Client API) of the trusted application environment, and transmits the symmetric key to the key execution of the trusted execution environment through the application interface. Record the security application TA.
  • TEE Client API application interface
  • the key burning security application TA will transmit the symmetric key to the operating system (TEE OS) of the trusted execution environment.
  • TEE OS operating system
  • the second implementation manner the device end 100 generates a symmetric key.
  • Step S21 The host end 100 sends a request for obtaining a symmetric key to the device 200.
  • Device end 200 includes a non-trusted execution environment and a trusted execution environment.
  • the non-trusted execution environment includes a transfer request client application CA
  • the trusted execution environment includes a transfer request security application TA.
  • the host 100 sends a symmetric key acquisition request to the device 200 to trigger the device 200 to generate a symmetric key for encrypting the device data.
  • the device 200 transmits the symmetric request in the non-trusted execution environment. request.
  • Step S22 The device end 200 transmits the acquisition request of the symmetric key to the trusted execution environment of the device.
  • the transfer request client application CA in the non-trusted execution environment invokes the application interface (TEE Client API) of the trusted application environment, through which the transmission request of the symmetric key acquisition request to the trusted execution environment is transmitted.
  • Security application TA is the application interface of the trusted application environment, through which the transmission request of the symmetric key acquisition request to the trusted execution environment is transmitted.
  • Step S23 The device end 200 generates a symmetric key for encrypting the device data in the trusted execution environment, and sends the symmetric key to the host end 100.
  • the device 200 requests the security application TA in the transmission of the trusted execution environment, transmits the acquisition request of the symmetric key to the operating system (TEE OS) of the trusted execution environment, and the operating system of the trusted execution environment generates the symmetry for encrypting the device data. Key.
  • TEE OS operating system
  • the operating system of the trusted execution environment of the device 200 sends a symmetric key to the transmission request security application TA, and the transmission request security application TA sends a symmetric key to the transmission request client application CA, and then the transmission request client application CA sends the symmetric key to Host side 100.
  • Step S22 The host end 100 saves the symmetric key sent by the device end 200.
  • the host side 100 stores the symmetric key sent by the device end 200 and saves the symmetric key for subsequent use in performing an encryption process on the device data.
  • step S102 the device end 200 saves the symmetric key to the trusted storage area of the trusted execution environment.
  • the symmetric key in the first implementation, the symmetric key of the host-side programming is obtained, and in the second implementation, the symmetric key is generated
  • the symmetricity can be saved. Key to trusted storage area.
  • the trusted storage area can be a section of DDR (full name DDR SDRAM, Double Data Rate SDRAM, double rate SDRAM) in the trusted execution environment.
  • the controller of the DDR in the trusted execution environment can be used to ensure non-trusted The execution environment REE cannot access the DDR.
  • the trusted execution environment stores the symmetric key area more securely, the symmetric key can be protected and the symmetric key can be prevented from being stolen by other manufacturers.
  • the symmetric key in order to further protect the symmetric key, may be encrypted before the symmetric key is stored to the trusted storage area.
  • the operating system of the trusted execution environment may obtain the root key RKEK in the secure hardware device.
  • the root key RKEK is stored in the secure hardware device before leaving the factory to indicate the mobile terminal produced by the manufacturer, which is equivalent to the device fingerprint.
  • the root key RKEK of each security hardware device is different.
  • the operating system of the trusted execution environment performs an encryption operation on the symmetric key using the root key RKEK, and then stores the encrypted symmetric key to the trusted storage area. This will further protect the symmetric key.
  • Step S103 The host end 100 determines device data to be encrypted, and performs an encryption operation on the device data by using the symmetric key.
  • ELF file Take a file in ELF format that needs to be encrypted (hereinafter referred to as ELF file).
  • ELF file includes ELF header, .text, .data, .comment, .shstatab, and Sec header table.
  • This application can perform encryption operations on various parts of the ELF file, which is highly secure. It can be understood that the decryption operation needs to be performed on the entire ELF file at the time of decryption.
  • each part of the ELF file is not of high importance, it is possible to selectively perform encryption operations on multiple parts of the ELF file.
  • a state may be set for each portion. If a portion is encrypted, the portion is encrypted and needs to be decrypted before being used; if a portion is unencrypted , which means that the part is not encrypted and can be used directly.
  • Step S104 The host terminal 100 burns the encrypted device data to the device end 200.
  • the device end 200 includes a non-trusted execution environment and a trusted execution environment.
  • the non-trusted execution environment includes the device fingerprint client application CA
  • the trusted execution environment includes the device fingerprint security application TA.
  • the host device 100 burns the encrypted device data to the device end, and the device fingerprint client application CA in the non-trusted execution environment of the device end receives the encrypted device data.
  • the entire ELF file can be burned to the device.
  • the status of the .text and .data sections in the overall ELF file is encrypted, and the rest of the state is unencrypted.
  • Step S105 The device 200 receives and saves the encrypted device data that is programmed by the host in the non-trusted execution environment.
  • the encrypted device data is saved in the storage area of the non-trusted execution environment.
  • Step S106 The device end 200 sends the encrypted device data to the trusted execution environment if the device data is to be used by the non-trusted execution environment.
  • Non-trusted execution environments for example, banking clients, communication clients, calculators, calendars, clocks, etc.
  • the untrusted execution environment looks up the executables that the application needs to use in the storage area.
  • the state of the executable file has an encrypted state, and if there is an encrypted state, the encrypted device data is determined.
  • the states of the .text and .data are encrypted, and the .text and .data portions are determined to be encrypted device data.
  • the device fingerprint client application CA in the non-trusted execution environment of the device side invokes an application program interface (TEE Client API) of the trusted execution environment, and transmits the encrypted device data to the trusted execution environment through the application program interface.
  • TEE Client API application program interface
  • Step S107 The trusted execution environment decrypts the encrypted device data by using the symmetric key to obtain the device data.
  • the device fingerprint security application TA in the trusted execution environment sends the encrypted device data to the operating system of the trusted execution environment, and the operating system of the trusted execution environment obtains the symmetric key from the trusted storage area. .
  • the encrypted symmetric key is obtained from the trusted storage area, and then the encrypted symmetric key is decrypted by using the root key RKEK. Get a symmetric key.
  • the operating system of the trusted execution environment decrypts the encrypted device data using the symmetric key to obtain the device data.
  • Step S108 The trusted execution environment sends the device data to the non-trusted execution environment.
  • the operating system of the trusted execution environment sends the device data to the device fingerprint security application TA, the device fingerprint security application TA, and the device data to the device fingerprint client application CA of the non-trusted execution environment, thereby reaching the non- Trusted execution environment.
  • Step S109 The non-trusted execution environment normally runs the device data.
  • the untrusted execution environment can use the decrypted device data, and after the decrypted device data is used, delete the decrypted device data to prevent other manufacturers from stealing device data.
  • the device data is still kept as encrypted device data.
  • the original encryption state is maintained, that is, the .data and .text segments are encrypted.
  • each executable file has its own symmetric key.
  • the manufacturer can also set a symmetric key for each executable file, that is, each executable file uses its own symmetric key to perform an encryption operation or a decryption operation, so that the security is higher.
  • a device data processing method applied to the device processing system illustrated in FIG. 1a is provided. Referring to Figure 5, the following steps are included:
  • Step S501 The host end 100 determines and correspondingly stores a symmetric key for encrypting the device data and a data identifier for indicating the device data, and the trusted execution environment of the device end 200 obtains a symmetric key for encrypting the device data and is used for A data identifier that represents device data.
  • This step has two implementation modes. The following two implementation modes are respectively described.
  • the first implementation manner the host end 100 generates a symmetric key.
  • the host end 100 generates a symmetric key for encrypting device data, and correspondingly stores a symmetric key and a data identifier for indicating device data.
  • the host side 100 may randomly generate or generate a symmetric key for encrypting the device data according to a preset algorithm, or the host end 100 receives the manufacturer to construct a special symmetric key. This application does not limit the process of generating a symmetric key.
  • the host side 100 saves the symmetric key after determining the symmetric key for subsequent use in performing encryption operations on the device data.
  • S612 The host end 100 burns the symmetric key and the data identifier to the device end 200.
  • Device end 200 includes a non-trusted execution environment and a trusted execution environment.
  • the non-trusted execution environment includes a key burning client application CA
  • the trusted execution environment includes a key burning security application TA.
  • the host terminal 100 burns the symmetric key and the data identifier to the key burning client application CA in the non-trusted execution environment of the device terminal 200 through the burning software.
  • the process transmits symmetric keys in an open environment
  • the process of transmitting symmetric keys is safe because the burning process is performed at the manufacturer's factory.
  • the device end 200 transmits the symmetric key and the data identifier to the trusted execution environment.
  • the key burning client application CA in the non-trusted execution environment invokes the application interface (TEE Client API) of the trusted application environment, through which the symmetric key and the data identifier are transmitted to the trusted execution environment.
  • the key is burned to the security application TA.
  • the key burning security application TA transmits the symmetric key and data identification to the operating system (TEE OS) of the trusted execution environment.
  • TEE OS operating system
  • the second implementation manner the device end 100 generates a symmetric key.
  • Step S621 The host end 100 sends an acquisition request for indicating the data identifier of the device data and the symmetric key to the device end 200.
  • Device end 200 includes a non-trusted execution environment and a trusted execution environment.
  • the non-trusted execution environment includes a transfer request client application CA
  • the trusted execution environment includes a transfer request security application TA.
  • the host side 100 sends the acquisition request and the data identifier of the symmetric key to the device 200 to trigger the device 200 to generate a symmetric key for encrypting the device data.
  • the transmission request CA in the non-trusted execution environment of the device 200 receives the symmetric key. Key acquisition request and data identification.
  • Step S622 The device end 200 transmits the acquisition request and the data identifier of the symmetric key to the trusted execution environment of the device.
  • the transfer request client application CA in the non-trusted execution environment invokes the application interface (TEE Client API) of the trusted application environment, through which the symmetric key acquisition request and the data identifier are transmitted to the trusted execution environment.
  • the transfer request is secure to apply the TA.
  • Step S623 The device end 200 generates a symmetric key for encrypting the device data in the trusted execution environment, and sends the symmetric key and the data identifier to the host end 100.
  • the device 200 requests the security application TA in the transmission of the trusted execution environment, and transmits the acquisition request of the symmetric key and the data identifier to the operating system (TEE OS) of the trusted execution environment, and the operating system of the trusted execution environment generates the device data. Encrypted symmetric key.
  • TEE OS operating system
  • the operating system of the trusted execution environment of the device 200 sends a symmetric key and a data identifier to the transmission request security application TA, and the transmission request security application TA sends the symmetric key and the data identifier to the transmission request client application CA, and then the transmission request client application
  • the CA sends a symmetric key and data identification to the host side 100.
  • Step S622 The host end 100 corresponds to the symmetric key and the data identifier sent by the device end 200.
  • the host side 100 stores the symmetric key and the data identifier sent by the device 200, and stores the symmetric key and the data identifier correspondingly, so as to be used for performing the encryption process on the device data.
  • step S502 the device end 200 saves the symmetric key and the data identifier to the trusted storage area of the trusted execution environment.
  • the operating system of the trusted execution environment of the device 200 obtains the symmetric key and the data identifier (in the first implementation, the symmetric key of the host-side programming is obtained, and in the second implementation, the symmetric key is generated),
  • the symmetric key and data identifier can be saved to the trusted storage area.
  • the trusted storage area can be a section of DDR (full name DDR SDRAM, Double Data Rate SDRAM, double rate SDRAM) in the trusted execution environment.
  • the controller of the DDR in the trusted execution environment can be used to ensure non-trusted The execution environment REE cannot access the DDR.
  • the trusted execution environment stores the symmetric key area more securely, the symmetric key can be protected and the symmetric key can be prevented from being stolen by other manufacturers.
  • the symmetric key in order to further protect the symmetric key, may be encrypted before the symmetric key is stored to the trusted storage area.
  • the operating system of the trusted execution environment may obtain the root key RKEK in the secure hardware device.
  • the root key RKEK is stored in the secure hardware device before leaving the factory to indicate the mobile terminal produced by the manufacturer, which is equivalent to the device fingerprint. Different manufacturers' mobile terminals have different device fingerprints.
  • the operating system of the trusted execution environment performs an encryption operation on the symmetric key using the root key RKEK, and then stores the encrypted symmetric key and data identifier to the trusted storage area. This will further protect the symmetric key.
  • Step S503 The host end 100 determines device data to be encrypted, and finds a symmetric key according to the data identifier of the device data, and performs an encryption operation on the device data by using the symmetric key.
  • ELF file Take a file in ELF format that needs to be encrypted (hereinafter referred to as ELF file).
  • ELF file includes ELF header, .text, .data, .comment, .shstatab, and Sec header table.
  • This application can perform encryption operations on various parts of the ELF file, which is highly secure. It can be understood that the decryption operation needs to be performed on the entire ELF file at the time of decryption.
  • each part of the ELF file is not of high importance, it is possible to selectively perform encryption operations on multiple parts of the ELF file.
  • a state may be set for each portion. If a portion is encrypted, the portion is encrypted and needs to be decrypted before being used; if a portion is unencrypted , which means that the part is not encrypted and can be used directly.
  • the host side searches for the symmetric key corresponding to the device ID based on the data identifier of the device data. Since the process of performing encryption operations on device data by using a symmetric key is a mature technology, the specific execution process will not be described herein.
  • Step S504 The host terminal 100 burns the encrypted device data and the data identifier to the device end 200.
  • Device end 200 includes a non-trusted execution environment and a trusted execution environment.
  • the non-trusted execution environment includes the device fingerprint client application CA
  • the trusted execution environment includes the device fingerprint security application TA.
  • the host device 100 burns the encrypted device data and data identifiers to the device 200, and the device fingerprint client application CA in the device-side non-trusted execution environment receives the encrypted device data and data identifiers.
  • the entire ELF file can be burned to the device.
  • the status of the .text and .data sections in the overall ELF file is encrypted, and the rest of the state is unencrypted.
  • Step S505 The device end 200 receives and saves the encrypted device data and the data identifier that are programmed by the host end in the non-trusted execution environment.
  • the encrypted device data and the data identifier are stored in the storage area of the non-trusted execution environment.
  • Step S506 The device end 200 sends the encrypted device data and the data identifier to the trusted execution environment if the device data is to be used by the non-trusted execution environment.
  • Non-trusted execution environments for example, banking clients, communication clients, calculators, calendars, clocks, etc.
  • the untrusted execution environment looks up the executables that the application needs to use in the storage area.
  • the state of the executable file has an encrypted state, and if there is an encrypted state, the encrypted device data is determined.
  • the states of the .text and .data are encrypted, and the .text and .data portions are determined to be encrypted device data.
  • the device fingerprint client application CA in the non-trusted execution environment of the device side invokes an application program interface (TEE Client API) of the trusted execution environment, and transmits the encrypted device data and data identifier to the device interface through the application program interface.
  • Step S507 The trusted execution environment searches for a symmetric key corresponding to the data identifier, and decrypts the encrypted device data by using the symmetric key to obtain the device data.
  • the device fingerprint security application TA in the trusted execution environment sends the encrypted device data and data identifier to the operating system of the trusted execution environment, and the operating system of the trusted execution environment obtains from the trusted storage area.
  • a symmetric key corresponding to the data identifier is asymmetric key corresponding to the data identifier.
  • the encrypted symmetric key is obtained from the trusted storage area, and then the encrypted symmetric key is decrypted by using the root key RKEK. Get a symmetric key.
  • the operating system of the trusted execution environment decrypts the encrypted device data using the symmetric key to obtain the device data.
  • Step S508 The trusted execution environment sends the device data to the non-trusted execution environment.
  • the operating system of the trusted execution environment sends the device data to the device fingerprint security application TA, the device fingerprint security application TA, and the device data to the device fingerprint client application CA of the non-trusted execution environment, thereby reaching the non- Trusted execution environment.
  • Step S509 Non-trusted execution environment normal operation device data
  • the non-trusted execution environment may use the decrypted device data, and after the decrypted device data is used, delete the decrypted device data to prevent other manufacturers from stealing device data. .
  • the ELF file After the ELF file is used, it remains in its original state, ie the .data and .text sections are encrypted.
  • the customized device data is encrypted by using the key, and then the encrypted device data is burned to the mobile terminal. Since the mobile terminal stores the encrypted device data, the encrypted device data cannot be used even if the encrypted device data is stolen by other manufacturers.
  • the functions described in the method of the present embodiment can be stored in a readable storage medium of a computing device if implemented in the form of a software functional unit and sold or used as a standalone product. Based on such understanding, a portion of the embodiments of the present application that contributes to the prior art or a portion of the technical solution may be embodied in the form of a software product stored in a storage medium, including a plurality of instructions for causing a
  • the computing device (which may be a personal computer, server, mobile computing device, or network device, etc.) performs all or part of the steps of the methods described in various embodiments of the present application.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

本申请公开了一种设备数据处理方法及系统，其中一种方法应用于包括非可信执行环境和可信执行环境的设备端，所述方法包括：确定对设备数据进行加密的密钥；保存所述密钥至所述可信执行环境的可信存储区域；在所述非可信执行环境接收并保存经所述密钥加密后的设备数据。本申请生产厂家在烧录定制化的设备数据至移动终端之前，利用密钥对定制化的设备数据进行加密，然后再将加密后的设备数据烧录至移动终端。由于移动终端存储的加密后的设备数据，所以即便被其它生产厂家窃取加密后的设备数据，也无法使用的加密后的设备数据。

Description

一种设备数据处理方法及系统
本申请要求2017年12月08日递交的申请号为201711292563.2、发明名称为“一种设备数据处理方法及系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，尤其涉及一种设备数据处理方法及系统。
背景技术
随着移动终端市场的激烈竞争，为了提高自身竞争力，移动终端的生产厂家推出功能库、应用库等设备数据的定制化服务。
由于定制化的设备数据具有特殊优势，所以可能会出现定制化的设备数据被盗用的问题。比如，生产厂家A为移动终端A’定制化的设备数据，被盗用至厂家B生产的移动终端B’上。
因此，现在需要防止一个生产厂家定制化的设备数据，被其它生产厂家的移动终端所使用的方案。
发明内容
鉴于此，本申请提供一种设备数据处理方法及系统，可以防止定制化的设备数据被其它生产厂家的移动终端所使用。
为了实现上述目的，本申请提供了下述技术特征：
一种设备数据处理系统，包括：
主机端，用于确定对设备数据进行加密的密钥，利用所述密钥对设备数据执行加密操作，并将加密后的设备数据烧录至设备端；
设备端，用于确定对设备数据进行加密的密钥，并保存所述密钥至可信执行环境的可信存储区域，在非可信执行环境接收并保存所述主机端烧录的加密后的设备数据。
可选的，所述主机端执行确定对设备数据进行加密的密钥的过程，具体包括：生成对设备数据进行加密的密钥，并将所述密钥烧录至设备端；
所述设备端执行确定对设备数据进行加密的密钥的过程，具体包括：在非可信执行环境接收所述主机端烧录的所述密钥。
可选的，所述设备端执行确定对设备数据进行加密的密钥的过程，具体包括：所述设备端在可信执行环境生成对设备数据进行加密的密钥，发送所述密钥至所述主机端；
所述主机端执行确定对设备数据进行加密的密钥的过程，具体包括：接收所述设备端发送的对设备数据进行加密的密钥，并保存所述密钥。
可选的，所述设备端执行保存所述密钥至可信执行环境的可信存储区域的过程，具体包括：
所述可信执行环境在安全硬件设备中获取根密钥RKEK，并利用所述根密钥RKEK对所述密钥执行加密操作；其中，每个安全硬件设备的根密钥RKEK均不同；
所述可信执行环境存储加密后的密钥至所述可信存储区域。
可选的，所述设备端，还用于在非可信执行环境需使用所述设备数据情况下，发送所述加密后的设备数据至所述可信执行环境，所述可信执行环境利用所述密钥解密所述加密后的设备数据获得所述设备数据，发送所述设备数据至所述非可信执行环境。
可选的，所述密钥包括对称密钥。
一种设备数据处理方法，应用于包括非可信执行环境和可信执行环境的设备端，所述方法包括：
确定对设备数据进行加密的密钥；
保存所述密钥至所述可信执行环境的可信存储区域；
在所述非可信执行环境接收并保存经所述密钥加密后的设备数据。
可选的，所述保存所述密钥至所述可信执行环境，包括：
所述非可信执行环境中的密钥烧录客户应用调用所述可信应用环境的应用程序接口、通过该应用程序接口传输所述密钥至所述可信执行环境的密钥烧录安全应用；
所述可信执行环境的密钥烧录安全应用发送所述密钥至所述可信执行环境的操作系统；
所述可信执行环境的操作系统保存所述密钥至可信存储区域。
可选的，所述可信执行环境的操作系统保存所述密钥至可信存储区域，包括：
所述可信执行环境的操作系统在安全硬件设备中获取根密钥RKEK，并利用所述根密钥RKEK对所述密钥执行加密操作；其中，每个安全硬件设备的根密钥RKEK均不同；
所述可信执行环境的操作系统存储加密后的密钥至所述可信存储区域。
可选的，所述确定对设备数据进行加密的密钥，包括：
在所述非可信执行环境接收主机端烧录至设备端的密钥；或，
在所述可信执行环境生成对设备数据进行加密的密钥。
可选的，所述密钥包括对称密钥。
一种设备数据处理方法，应用于主机端，所述方法包括：
确定对设备数据进行加密的密钥；
利用所述密钥对设备数据执行加密操作，并将加密后的设备数据烧录至设备端。
可选的，所述确定对设备数据进行加密的密钥包括：
生成并保存对设备数据进行加密的密钥；或，
接收设备端发送的对设备数据进行加密的密钥，并保存所述密钥。
可选的，对于一个包含多个部分的文件而言，将所述文件的多个部分或者所述多个部分中的指定部分作为待加密的设备数据。
可选的，所述密钥包括对称密钥。
一种设备数据处理方法，应用于包括非可信执行环境和可信执行环境的设备端，所述方法包括：
在所述非可信执行环境需使用设备数据情况下，发送加密后的设备数据至所述可信执行环境；
所述可信执行环境利用所述密钥解密所述加密后的设备数据获得所述设备数据；
发送所述设备数据至所述非可信执行环境。
可选的，在所述非可信执行环境需使用设备数据情况下，发送加密后的设备数据至所述可信执行环境，包括：
在非可信执行环境需要使用文件的情况下，通过文件中各个部分的状态；
将具有加密状态的各个部分，确定为加密后的设备数据；
发送加密后的设备数据至可信执行环境。
可选的，所述发送所述加密后的设备数据至所述可信执行环境，包括：
所述非可信执行环境中的设备指纹客户应用调用所述可信应用环境的应用程序接口、发送所述加密后的设备数据至所述可信执行环境的设备指纹安全应用；
所述发送所述设备数据至所述非可信执行环境，包括：所述可信执行环境的设备指纹安全应用调用所述应用程序接口、发送所述设备数据至所述非可信执行环境的设备指纹客户应用。
可选的，所述可信执行环境利用所述密钥解密所述加密后的设备数据获得所述设备数据，包括：
所述可信执行环境中的设备指纹安全应用发送加密后的设备数据至所述可信执行环境的操作系统；
所述可信执行环境的操作系统从可信存储区域获取密钥，并利用所述密钥解密所述加密后的设备数据获得所述设备数据。
所述设备指纹安全应用调用所述非可信应用环境的应用程序接口、发送所述设备数据至所述非可信执行环境的设备指纹客户应用。
可选的，所述可信执行环境的操作系统从可信存储区域获取密钥，包括：
所述可信执行环境的操作系统从所述可信存储区域获取加密的密钥，并从所述安全硬件设备获取根密钥RKEK；其中，每个安全硬件设备的根密钥RKEK均不同；
所述可信执行环境的操作系统利用根密钥RKEK对所述加密的密钥执行解密操作，获得解密后的密钥。
可选的，所述密钥包括对称密钥。
一种设备数据处理系统，包括：
主机端，用于确定对设备数据进行加密的密钥，利用所述密钥对所述设备数据执行加密操作，并将加密后的设备数据和表示所述设备数据的数据标识烧录至设备端；
设备端，用于确定对设备数据进行加密的密钥，并保存所述密钥和表示所述设备数据的数据标识至可信执行环境的可信存储区域，在非可信执行环境接收并保存所述主机端烧录的加密后的设备数据和所述数据标识。
可选的，所述主机端执行确定对设备数据进行加密的密钥的过程，具体包括：生成对设备数据进行加密的密钥，并将所述密钥和表示所述设备数据的数据标识烧录至设备端；
所述设备端执行确定对设备数据进行加密的密钥的过程，具体包括：在非可信执行环境接收所述主机端烧录的所述密钥和表示所述设备数据的数据标识。
可选的，所述设备端执行确定对设备数据进行加密的密钥的过程，具体包括：所述设备端在可信执行环境生成对设备数据进行加密的密钥，发送所述密钥和用于表示所述设备数据的数据标识至所述主机端；
所述主机端执行确定对设备数据进行加密的密钥的过程，具体包括：接收所述设备端发送的对设备数据进行加密的密钥和数据标识，并对应保存所述密钥和所述数据标识。
可选的，所述设备端执行对应保存所述密钥和数据标识至可信执行环境的可信存储区域的过程，具体包括：
所述可信执行环境在安全硬件设备中获取根密钥RKEK，并利用所述根密钥RKEK对所述密钥执行加密操作；
所述可信执行环境对应存储加密后的密钥和所述数据标识至所述可信存储区域。
可选的，所述设备端，还用于在非可信执行环境需使用所述设备数据情况下，发送所述加密后的设备数据和所述数据标识至所述可信执行环境，所述可信执行环境查找与所述数据标识对应的密钥，利用该密钥解密所述加密后的设备数据获得所述设备数据，发送所述设备数据至所述非可信执行环境。
可选的，所述密钥包括对称密钥。
一种设备数据处理方法，应用于包括非可信执行环境和可信执行环境的设备端，所述方法包括：
确定对设备数据进行加密的密钥；
保存所述密钥和表示所述设备数据的数据标识至可信执行环境的可信存储区域；
在非可信执行环境接收并保存所述主机端烧录的加密后的设备数据和所述数据标识。
一种设备数据处理方法，应用于主机端，所述方法包括：
确定对设备数据进行加密的密钥；
利用所述密钥对所述设备数据执行加密操作；
将加密后的设备数据和表示所述设备数据的数据标识烧录至设备端。
一种设备数据处理方法，应用于包括非可信执行环境和可信执行环境的设备端，所述方法包括：
在非可信执行环境需使用所述设备数据情况下，发送所述加密后的设备数据和用于表示设备数据的数据标识至所述可信执行环境；
所述可信执行环境查找与所述数据标识对应的密钥，利用该密钥解密所述加密后的设备数据获得设备数据；
发送所述设备数据至所述非可信执行环境。
通过以上技术手段，可以实现以下有益效果：
本申请生产厂家在烧录定制化的设备数据至移动终端之前，利用密钥对定制化的设备数据进行加密，然后再将加密后的设备数据烧录至移动终端。由于移动终端存储的加密后的设备数据，所以即便被其它生产厂家窃取加密后的设备数据，也无法使用的加密后的设备数据。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1a为本申请实施例公开的一种设备数据处理系统的结构示意图；
图1b为本申请实施例公开的一种设备数据处理方法的流程图；
图2a-2b为本申请实施例公开的又一种设备数据处理方法的流程图；
图3a-3b为本申请实施例公开的一种可执行文件的示意图；
图4为本申请实施例公开的又一种设备数据处理方法的流程图；
图5为本申请实施例公开的又一种设备数据处理方法的流程图；
图6a-6b为本申请实施例公开的又一种设备数据处理方法的流程图；
图7为本申请实施例公开的又一种设备数据处理方法的流程图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
术语解释：
对称密钥加密：又称私钥加密，即信息的发送方和接收方使用相同密钥来加密和解密信息。
非可信执行环境：英文全称为Rich Execution Environment，REE。丰富执行环境以提供强大功能和性能为主要设计目标，由于丰富执行环境具有公开性所以又被称为非可信执行环境。
可信执行环境：英文全称Trusted Execution Environment，TEE。可信执行环境与非可信执行环境平行存在却又互相隔离，可信执行环境可以为非可信应用环境中的应用提供安全服务。
客户应用：英文全称Client Application，CA。运行在非可信执行环境REE中的应用 称为客户应用。
安全应用：英文全称Trusted Application，TA。运行在可信执行环境TEE中的应用。客户应用CA可以调用TEE Client API向TA请求安全服务，安全应用TA可以为运行在非可信应用环境REE中的客户应用提供安全服务。
ELF(Executable and Linkable Format)：一种用于二进制文件、可执行文件、目标代码、功能库的文件格式。
根密钥RKEK：在出厂前存储在安全硬件设备中。每个安全硬件设备的根密钥RKEK均不同。
为了便于说明，本实施例中的密钥采用对称密钥描述，可以理解的是，在具体实施时，可以根据实际情况采用非对称密钥也是可以的。即，非对称密钥也在本申请保护范围内。
为了防止定制化的设备数据被盗用至其它生产厂家的移动终端，本申请中生产厂家在烧录定制化的设备数据至移动终端之前，利用对称密钥对定制化的设备数据进行加密，然后再将加密后的设备数据烧录至移动终端的非可信执行环境。
由于非可信执行环境具有开放性，所以可能被其它生产厂家窃取加密后的设备数据。由于设备数据是被加密的，所以其它生产厂家即便盗用加密后的设备数据后，也无法使用的加密后的设备数据。
为了不影响移动终端本身使用定制化的设备数据，将对称密钥保存在移动终端的可信执行环境中。在移动终端需使用设备数据时，便可以利用可信执行环境中的对称密钥解密加密后的设备数据，从而获得并使用设备数据。
本申请之所以将对称密钥设置在可信执行环境，是因为可信执行环境与非可信执行环境具有物理隔离，所以可信执行环境很安全，可以防止其它生产厂家盗取从可信执行环境中盗取对称密钥。
在其它生产厂家无法获得对称密钥的基础上，其它生产厂家是无法解密并使用加密后的设备数据的。因此，本申请可以防止其它生产厂家使用定制化的设备数据。
移动终端包括应用库、功能库等设备数据，设备数据包括很多可执行文件。依据对称密钥与可执行文件的数量对应关系，本申请可以包括两个方面：
第一方面：多个可执行文件共用一个对称密钥。
生产厂家可以对可执行文件进行定制化，从而获得定制化的多个可执行文件。在第一方面中，可以为多个可执行文件设置一个共用的对称密钥。这样，多个可执行文件均采用该对称密钥执行加密操作或解密操作，处理过程简单方便，且便于管理对称密钥。
根据本申请的一个实施例，提供一种设备数据处理系统的实施例一。参见图1a，设备数据处理系统包括：主机端100和设备端200。
根据本申请的一个实施例，提供一种应用于上述设备处理系统的设备数据处理方法。参见图1b，包括以下步骤：
步骤S101：主机端100确定并保存对设备数据进行加密的对称密钥，设备端200的可信执行环境获得对设备数据进行加密的对称密钥。
本步骤具有两种实现方式，下面分别对两种实现方式进行说明。
第一种实现方式：主机端100生成对称密钥。
参见图2a，提供第一种实现方式的实现过程：
S11：主机端100生成对设备数据进行加密的对称密钥并保存对称密钥。
主机端100可以随机生成或者按照预设算法生成对设备数据进行加密的对称密钥，或者，主机端100接收生产厂家构建一个特殊对称密钥。本申请对于生成对称密钥的过程不做限定。
主机端100在确定对称密钥后保存对称密钥，以便后续用于对设备数据执行加密操作。
S12：主机端100将所述对称密钥烧录至设备端200。
设备端200包括非可信执行环境和可信执行环境。为了执行烧录过程，非可信执行环境包括密钥烧录客户应用CA，可信执行环境包括密钥烧录安全应用TA。
主机端100通过烧录软件将对称密钥烧录至设备端200的非可信执行环境中的密钥烧录客户应用CA。
虽然该过程会在开放环境中传输对称密钥，但是因为烧录过程在生产厂家的工厂执行，所以传输对称密钥的过程是安全的。
S13：设备端200将对称密钥传输至可信执行环境。
非可信执行环境中的密钥烧录客户应用CA会调用所述可信应用环境的应用程序接口(TEE Client API)，通过该应用程序接口传输对称密钥至可信执行环境的密钥烧录安全应用TA。
密钥烧录安全应用TA会传输对称密钥至可信执行环境的操作系统(TEE OS)。
第二种实现方式：设备端100生成对称密钥。
参见图2b，提供第二种实现方式的实现过程：
步骤S21：主机端100发送对称密钥的获取请求至设备端200。
设备端200包括非可信执行环境和可信执行环境。非可信执行环境包括传输请求客户应用CA，可信执行环境包括传输请求安全应用TA。
主机端100发送对称密钥的获取请求至设备端200，以触发设备端200生成对设备数据进行加密的对称密钥；设备端200非可信执行环境中的传输请求CA接收对称密钥的获取请求。
步骤S22：设备端200传输对称密钥的获取请求至设备端的可信执行环境。
非可信执行环境中的传输请求客户应用CA会调用所述可信应用环境的应用程序接口(TEE Client API)，通过该应用程序接口传输对称密钥的获取请求至可信执行环境的传输请求安全应用TA。
步骤S23：设备端200在可信执行环境生成对设备数据进行加密的对称密钥，发送所述对称密钥至所述主机端100。
设备端200在可信执行环境的传输请求安全应用TA，传输对称密钥的获取请求至可信执行环境的操作系统(TEE OS)，可信执行环境的操作系统生成对设备数据进行加密的对称密钥。
设备端200的可信执行环境的操作系统发送对称密钥至传输请求安全应用TA，传输请求安全应用TA发送对称密钥至传输请求客户应用CA，再由传输请求客户应用CA发送对称密钥至主机端100。
步骤S22：主机端100保存设备端200发送的对称密钥。
主机端100存储设备端200发送的对称密钥并保存对称密钥，以便后续用于对设备数据执行加密过程。
接着返回图1b，进入步骤S102：设备端200保存所述对称密钥至可信执行环境的可信存储区域。
设备端200的可信执行环境的操作系统获得对称密钥后(在第一种实现方式中获得主机端烧录的对称密钥，在第二种实现方式中生成对称密钥)，可以保存对称密钥至可信存储区域。
可信存储区域可以为可信执行环境中DDR(全称为DDR SDRAM，Double Data Rate SDRAM，双倍速率SDRAM)中的一段区域，可信执行环境中的DDR的控制器可以用来保证非可信执行环境REE不能访问DDR。
由于可信执行环境存储对称密钥的区域较为安全，所以可以保护对称密钥，防止对称密钥被其它生产厂家盗取。
本实施例中，为了更进一步保护对称密钥，在存储对称密钥至可信存储区域之前，还可以对对称密钥进行加密操作。
根据本申请提供的一个实施例，可信执行环境的操作系统可以在安全硬件设备中获取根密钥RKEK。根密钥RKEK在出厂前存储在安全硬件设备中，用于表示该生产厂家生产的移动终端，相当于设备指纹。其中，每个安全硬件设备的根密钥RKEK均不同。
可信执行环境的操作系统利用所述根密钥RKEK对所述对称密钥执行加密操作，然后再存储加密后的对称密钥至所述可信存储区域。这样可以更进一步保护对称密钥。
步骤S103：主机端100确定待加密的设备数据，利用所述对称密钥对设备数据执行加密操作。
以一个需要加密的ELF格式的文件为例(后续称为ELF文件)，参见图3a，ELF文件包括ELF header、.text、.data、.comment、.shstatab、Sec header table多个部分。
本申请可以对ELF文件的各个部分均执行加密操作，这样安全性较高。可以理解的是，在解密时便需要对整个ELF文件均执行解密操作。
由于ELF文件中各个部分并非均具有较高的重要性，所以，可以选择性的对ELF文件中多个部分执行加密操作。
例如，参见图3b，可以仅对重要性较高的.text、.data两个部分进行加密。后续解密时候仅对两个部分执行解密操作，由于两个部分的数据量少，所以解密时间缩短，从而提高响应速度。
可以理解的是，为了便于后续区分加密部分和未加密部分，可以为各个部分设置一个状态，若一个部分为加密状态则表示该部分已加密，需要解密后再使用；若一个部分为未加密状态，则表示该部分未加密，可以直接使用。
由于利用对称密钥对设备数据执行加密操作过程已为成熟技术，在此不再赘述具体执行过程。
步骤S104：主机端100将加密后的设备数据烧录至设备端200。
参见图4，设备端200包括非可信执行环境和可信执行环境。非可信执行环境包括 设备指纹客户应用CA，可信执行环境包括设备指纹安全应用TA。
主机端100在烧录加密后的设备数据至设备端，设备端的非可信执行环境中的设备指纹客户应用CA会接收加密后的设备数据。
延续上述举例，在对重要性较高的.text、.data两个部分进行加密后，可以烧录整体ELF文件至设备端。其中，整体ELF文件中.text、.data两个部分的状态为已加密状态，其余部分的状态为未加密状态。
步骤S105：设备端200在非可信执行环境接收并保存所述主机端烧录的加密后的设备数据。
设备端200的非可信执行环境中的设备指纹客户应用CA会接收加密后的设备数据后，保存加密后的设备数据在非可信执行环境的存储区域内。
步骤S106：设备端200在非可信执行环境需使用所述设备数据情况下，发送所述加密后的设备数据至所述可信执行环境。
在非可信执行环境中的应用(例如，银行客户端、通讯客户端、计算器、日历、时钟等应用)在执行过程中，会使用一些可执行文件。非可信执行环境会在存储区域查找应用所需使用的可执行文件。
然后，判断可执行文件的状态是否有加密状态，若有加密状态则确定加密的设备数据。延续上述举例，在对一个ELF文件的状态进行判断后，发现.text、.data两个部分的状态为已加密状态，则确定.text、.data两个部分为加密后的设备数据。
参见图4，设备端的非可信执行环境中的设备指纹客户应用CA，调用可信执行环境的应用程序接口(TEE Client API)，通过该应用程序接口传输加密后的设备数据至可信执行环境的设备指纹安全应用TA。
步骤S107：所述可信执行环境利用所述对称密钥解密所述加密后的设备数据获得所述设备数据。
参见图4，所述可信执行环境中的设备指纹安全应用TA发送加密后的设备数据至所述可信执行环境的操作系统，可信执行环境的操作系统从可信存储区域获取对称密钥。
若在可信存储区域存储对称密钥时进一步使用根密钥RKEK进行加密，则在从可信存储区域获取加密后的对称密钥，然后，利用根密钥RKEK解密加密后的对称密钥，获得对称密钥。
可信执行环境的操作系统利用所述对称密钥解密所述加密后的设备数据获得所述设备数据。
步骤S108：可信执行环境发送所述设备数据至所述非可信执行环境。
参见图4，可信执行环境的操作系统发送设备数据至设备指纹安全应用TA，设备指纹安全应用TA、发送所述设备数据至所述非可信执行环境的设备指纹客户应用CA，从而到达非可信执行环境。
步骤S109：非可信执行环境正常运行设备数据。
非可信执行环境可以使用解密后的设备数据，在解密后的设备数据使用完毕后，删除解密后的设备数据，以防止其它生产厂家盗用设备数据。
非可信执行环境使用完毕后，依旧保持设备数据为加密后的设备数据。例如，在ELF文件使用完毕后，依旧保持最初时的加密状态，即.data和.text段被加密的状态。
第二方面：各个可执行文件均有各自的对称密钥。
生产厂家还可以为各个可执行文件均设置一个对称密钥，即各个可执行文件分别均采用各自的对称密钥执行加密操作或解密操作，这样安全性更高。
根据本申请的一个实施例，提供一种应用于图1a所示的设备处理系统的设备数据处理方法。参见图5，包括以下步骤：
步骤S501：主机端100确定并对应保存对设备数据进行加密的对称密钥和用于表示设备数据的数据标识，设备端200的可信执行环境获得对设备数据进行加密的对称密钥和用于表示设备数据的数据标识。
本步骤具有两种实现方式，下面分别对两种实现方式进行说明。
第一种实现方式：主机端100生成对称密钥。
参见图6a，提供第一种实现方式的实现过程：
S611：主机端100生成对设备数据进行加密的对称密钥，并对应保存对称密钥和用于表示设备数据的数据标识。
主机端100可以随机生成或者按照预设算法生成对设备数据进行加密的对称密钥，或者，主机端100接收生产厂家构建一个特殊对称密钥。本申请对于生成对称密钥的过程不做限定。
主机端100在确定对称密钥后保存对称密钥，以便后续用于对设备数据执行加密操作。
S612：主机端100将所述对称密钥和数据标识烧录至设备端200。
设备端200包括非可信执行环境和可信执行环境。为了执行烧录过程，非可信执行 环境包括密钥烧录客户应用CA，可信执行环境包括密钥烧录安全应用TA。
主机端100通过烧录软件将对称密钥和数据标识烧录至设备端200的非可信执行环境中的密钥烧录客户应用CA。
虽然该过程会在开放环境中传输对称密钥，但是因为烧录过程在生产厂家的工厂执行，所以传输对称密钥的过程是安全的。
S613：设备端200将对称密钥和数据标识传输至可信执行环境。
非可信执行环境中的密钥烧录客户应用CA会调用所述可信应用环境的应用程序接口(TEE Client API)，通过该应用程序接口传输对称密钥和数据标识至可信执行环境的密钥烧录安全应用TA。
密钥烧录安全应用TA会传输对称密钥和数据标识至可信执行环境的操作系统(TEE OS)。
第二种实现方式：设备端100生成对称密钥。
参见图6b，提供第二种实现方式的实现过程：
步骤S621：主机端100发送用于表示设备数据的数据标识和对称密钥的获取请求至设备端200。
设备端200包括非可信执行环境和可信执行环境。非可信执行环境包括传输请求客户应用CA，可信执行环境包括传输请求安全应用TA。
主机端100发送对称密钥的获取请求和数据标识至设备端200，以触发设备端200生成对设备数据进行加密的对称密钥；设备端200非可信执行环境中的传输请求CA接收对称密钥的获取请求和数据标识。
步骤S622：设备端200传输对称密钥的获取请求和数据标识至设备端的可信执行环境。
非可信执行环境中的传输请求客户应用CA会调用所述可信应用环境的应用程序接口(TEE Client API)，通过该应用程序接口传输对称密钥的获取请求和数据标识至可信执行环境的传输请求安全应用TA。
步骤S623：设备端200在可信执行环境生成对设备数据进行加密的对称密钥，发送所述对称密钥和数据标识至所述主机端100。
设备端200在可信执行环境的传输请求安全应用TA，传输对称密钥和数据标识的获取请求至可信执行环境的操作系统(TEE OS)，可信执行环境的操作系统生成对设备数 据进行加密的对称密钥。
设备端200的可信执行环境的操作系统发送对称密钥和数据标识至传输请求安全应用TA，传输请求安全应用TA发送对称密钥和数据标识至传输请求客户应用CA，再由传输请求客户应用CA发送对称密钥和数据标识至主机端100。
步骤S622：主机端100对应保存设备端200发送的对称密钥和数据标识。
主机端100存储设备端200发送的对称密钥和数据标识，并对应保存对称密钥和数据标识，以便后续用于对设备数据执行加密过程。
接着返回图5，进入步骤S502：设备端200保存所述对称密钥和数据标识至可信执行环境的可信存储区域。
设备端200的可信执行环境的操作系统获得对称密钥和数据标识后(在第一种实现方式中获得主机端烧录的对称密钥，在第二种实现方式中生成对称密钥)，可以对应保存对称密钥和数据标识至可信存储区域。
可信存储区域可以为可信执行环境中DDR(全称为DDR SDRAM，Double Data Rate SDRAM，双倍速率SDRAM)中的一段区域，可信执行环境中的DDR的控制器可以用来保证非可信执行环境REE不能访问DDR。
由于可信执行环境存储对称密钥的区域较为安全，所以可以保护对称密钥，防止对称密钥被其它生产厂家盗取。
本实施例中，为了更进一步保护对称密钥，在存储对称密钥至可信存储区域之前，还可以对对称密钥进行加密操作。
根据本申请提供的一个实施例，可信执行环境的操作系统可以在安全硬件设备中获取根密钥RKEK。根密钥RKEK在出厂前存储在安全硬件设备中，用于表示该生产厂家生产的移动终端，相当于设备指纹。不同生产厂家的移动终端的设备指纹不同。
可信执行环境的操作系统利用所述根密钥RKEK对所述对称密钥执行加密操作，然后再存储加密后的对称密钥和数据标识至所述可信存储区域。这样可以更进一步保护对称密钥。
步骤S503：主机端100确定待加密的设备数据，根据设备数据的数据标识查找到对称密钥利用所述对称密钥对设备数据执行加密操作。
以一个需要加密的ELF格式的文件为例(后续称为ELF文件)，参见图3a，ELF文件包括ELF header、.text、.data、.comment、.shstatab、Sec header table多个部分。
本申请可以对ELF文件的各个部分均执行加密操作，这样安全性较高。可以理解的是，在解密时便需要对整个ELF文件均执行解密操作。
由于ELF文件中各个部分并非均具有较高的重要性，所以，可以选择性的对ELF文件中多个部分执行加密操作。
例如，参见图3b，可以仅对重要性较高的.text、.data两个部分进行加密。后续解密时候仅对两个部分执行解密操作，由于两个部分的数据量少，所以解密时间缩短，从而提高响应速度。
可以理解的是，为了便于后续区分加密部分和未加密部分，可以为各个部分设置一个状态，若一个部分为加密状态则表示该部分已加密，需要解密后再使用；若一个部分为未加密状态，则表示该部分未加密，可以直接使用。
主机端会根据设备数据的数据标识，查找与设备标识对应的对称密钥。由于利用对称密钥对设备数据执行加密操作过程已为成熟技术，在此不再赘述具体执行过程。
步骤S504：主机端100将加密后的设备数据和数据标识烧录至设备端200。
设备端200包括非可信执行环境和可信执行环境。非可信执行环境包括设备指纹客户应用CA，可信执行环境包括设备指纹安全应用TA。
参见图7，主机端100在烧录加密后的设备数据和数据标识至设备端200，设备端的非可信执行环境中的设备指纹客户应用CA会接收加密后的设备数据和数据标识。
延续上述举例，在对重要性较高的.text、.data两个部分进行加密后，可以烧录整体ELF文件至设备端。其中，整体ELF文件中.text、.data两个部分的状态为已加密状态，其余部分的状态为未加密状态。
步骤S505：设备端200在非可信执行环境接收并保存所述主机端烧录的加密后的设备数据和数据标识。
设备端200的非可信执行环境中的设备指纹客户应用CA会接收加密后的设备数据和数据标识后，对应保存加密后的设备数据和数据标识在非可信执行环境的存储区域内。
步骤S506：设备端200在非可信执行环境需使用所述设备数据情况下，发送所述加密后的设备数据和数据标识至所述可信执行环境。
在非可信执行环境中的应用(例如，银行客户端、通讯客户端、计算器、日历、时钟等应用)在执行过程中，会使用一些可执行文件。非可信执行环境会在存储区域查找应用所需使用的可执行文件。
然后，判断可执行文件的状态是否有加密状态，若有加密状态则确定加密的设备数 据。延续上述举例，在对一个ELF文件的状态进行判断后，发现.text、.data两个部分的状态为已加密状态，则确定.text、.data两个部分为加密后的设备数据。
参见图7，设备端的非可信执行环境中的设备指纹客户应用CA，调用可信执行环境的应用程序接口(TEE Client API)，通过该应用程序接口传输加密后的设备数据和数据标识至可信执行环境的设备指纹安全应用TA。
步骤S507：所述可信执行环境查找与数据标识对应的对称密钥，利用所述对称密钥解密所述加密后的设备数据获得所述设备数据。
参见图7，所述可信执行环境中的设备指纹安全应用TA发送加密后的设备数据和数据标识至所述可信执行环境的操作系统，可信执行环境的操作系统从可信存储区域获取与数据标识对应的对称密钥。
若在可信存储区域存储对称密钥时进一步使用根密钥RKEK进行加密，则在从可信存储区域获取加密后的对称密钥，然后，利用根密钥RKEK解密加密后的对称密钥，获得对称密钥。
可信执行环境的操作系统利用所述对称密钥解密所述加密后的设备数据获得所述设备数据。
步骤S508：可信执行环境发送所述设备数据至所述非可信执行环境。
参见图7，可信执行环境的操作系统发送设备数据至设备指纹安全应用TA，设备指纹安全应用TA、发送所述设备数据至所述非可信执行环境的设备指纹客户应用CA，从而到达非可信执行环境。
步骤S509：非可信执行环境正常运行设备数据非可信执行环境可以使用解密后的设备数据，在解密后的设备数据使用完毕后，删除解密后的设备数据，以防止其它生产厂家盗用设备数据。
在ELF文件使用完毕后，依旧保持最初时的状态，即.data和.text段被加密的状态。
通过以上实施例可以实现以下有益效果：
本申请生产厂家在烧录定制化的设备数据至移动终端之前，利用密钥对定制化的设备数据进行加密，然后再将加密后的设备数据烧录至移动终端。由于移动终端存储加密后的设备数据，所以即便被其它生产厂家窃取加密后的设备数据，也无法使用的加密后的设备数据。
本实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或 使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算设备(可以是个人计算机，服务器，移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (30)

  1. 一种设备数据处理系统，其特征在于，包括：
    主机端，用于确定对设备数据进行加密的密钥，利用所述密钥对设备数据执行加密操作，并将加密后的设备数据烧录至设备端；
    设备端，用于确定对设备数据进行加密的密钥，并保存所述密钥至可信执行环境的可信存储区域，在非可信执行环境接收并保存所述主机端烧录的加密后的设备数据。
  2. 如权利要求1所述的系统，其特征在于，
    所述主机端执行确定对设备数据进行加密的密钥的过程，具体包括：生成对设备数据进行加密的密钥，并将所述密钥烧录至设备端；
    所述设备端执行确定对设备数据进行加密的密钥的过程，具体包括：在非可信执行环境接收所述主机端烧录的所述密钥。
  3. 如权利要求1所述的系统，其特征在于，
    所述设备端执行确定对设备数据进行加密的密钥的过程，具体包括：所述设备端在可信执行环境生成对设备数据进行加密的密钥，发送所述密钥至所述主机端；
    所述主机端执行确定对设备数据进行加密的密钥的过程，具体包括：接收所述设备端发送的对设备数据进行加密的密钥，并保存所述密钥。
  4. 如权利要求2或3所述的系统，其特征在于，所述设备端执行保存所述密钥至可信执行环境的可信存储区域的过程，具体包括：
    所述可信执行环境在安全硬件设备中获取根密钥RKEK，并利用所述根密钥RKEK对所述密钥执行加密操作；其中，每个安全硬件设备的根密钥RKEK均不同；
    所述可信执行环境存储加密后的密钥至所述可信存储区域。
  5. 如权利要求1所述的系统，其特征在于，
    所述设备端，还用于在非可信执行环境需使用所述设备数据情况下，发送所述加密后的设备数据至所述可信执行环境，所述可信执行环境利用所述密钥解密所述加密后的设备数据获得所述设备数据，发送所述设备数据至所述非可信执行环境。
  6. 如权利要求1所述的系统，其特征在于，所述密钥包括对称密钥。
  7. 一种设备数据处理方法，其特征在于，应用于包括非可信执行环境和可信执行环境的设备端，所述方法包括：
    确定对设备数据进行加密的密钥；
    保存所述密钥至所述可信执行环境的可信存储区域；
    在所述非可信执行环境接收并保存经所述密钥加密后的设备数据。
  8. 如权利要求7所述的方法，其特征在于，所述保存所述密钥至所述可信执行环境，包括：
    所述非可信执行环境中的密钥烧录客户应用调用所述可信应用环境的应用程序接口、通过该应用程序接口传输所述密钥至所述可信执行环境的密钥烧录安全应用；
    所述可信执行环境的密钥烧录安全应用发送所述密钥至所述可信执行环境的操作系统；
    所述可信执行环境的操作系统保存所述密钥至可信存储区域。
  9. 如权利要求8所述的方法，其特征在于，所述可信执行环境的操作系统保存所述密钥至可信存储区域，包括：
    所述可信执行环境的操作系统在安全硬件设备中获取根密钥RKEK，并利用所述根密钥RKEK对所述密钥执行加密操作；其中，每个安全硬件设备的根密钥RKEK均不同；
    所述可信执行环境的操作系统存储加密后的密钥至所述可信存储区域。
  10. 如权利要求7所述的方法，其特征在于，所述确定对设备数据进行加密的密钥，包括：
    在所述非可信执行环境接收主机端烧录至设备端的密钥；或，
    在所述可信执行环境生成对设备数据进行加密的密钥。
  11. 如权利要求7-10任一项所述的方法，其特征在于，所述密钥包括对称密钥。
  12. 一种设备数据处理方法，其特征在于，应用于主机端，所述方法包括：
    确定对设备数据进行加密的密钥；
    利用所述密钥对设备数据执行加密操作，并将加密后的设备数据烧录至设备端。
  13. 如权利要求12所述的方法，其特征在于，所述确定对设备数据进行加密的密钥包括：
    生成并保存对设备数据进行加密的密钥；或，
    接收设备端发送的对设备数据进行加密的密钥，并保存所述密钥。
  14. 如权利要求12所述的方法，其特征在于，对于一个包含多个部分的文件而言，将所述文件的多个部分或者所述多个部分中的指定部分作为待加密的设备数据。
  15. 如权利要求12-14任一项所述的方法，其特征在于，所述密钥包括对称密钥。
  16. 一种设备数据处理方法，其特征在于，应用于包括非可信执行环境和可信执行 环境的设备端，所述方法包括：
    在所述非可信执行环境需使用设备数据情况下，发送加密后的设备数据至所述可信执行环境；
    所述可信执行环境利用密钥解密所述加密后的设备数据获得所述设备数据；
    发送所述设备数据至所述非可信执行环境。
  17. 如权利要求16所述的方法，其特征在于，在所述非可信执行环境需使用设备数据情况下，发送加密后的设备数据至所述可信执行环境，包括：
    在非可信执行环境需要使用文件的情况下，通过文件中各个部分的状态；
    将具有加密状态的各个部分，确定为加密后的设备数据；
    发送加密后的设备数据至可信执行环境。
  18. 如权利要求16所述的方法，其特征在于，
    所述发送所述加密后的设备数据至所述可信执行环境，包括：
    所述非可信执行环境中的设备指纹客户应用调用所述可信应用环境的应用程序接口、发送所述加密后的设备数据至所述可信执行环境的设备指纹安全应用；
    所述发送所述设备数据至所述非可信执行环境，包括：所述可信执行环境的设备指纹安全应用调用所述应用程序接口、发送所述设备数据至所述非可信执行环境的设备指纹客户应用。
  19. 如权利要求16所述的方法，其特征在于，所述可信执行环境利用所述密钥解密所述加密后的设备数据获得所述设备数据，包括：
    所述可信执行环境中的设备指纹安全应用发送加密后的设备数据至所述可信执行环境的操作系统；
    所述可信执行环境的操作系统从可信存储区域获取密钥，并利用所述密钥解密所述加密后的设备数据获得所述设备数据；
    所述设备指纹安全应用调用所述非可信应用环境的应用程序接口、发送所述设备数据至所述非可信执行环境的设备指纹客户应用。
  20. 如权利要求19所述的方法，其特征在于，所述可信执行环境的操作系统从可信存储区域获取密钥，包括：
    所述可信执行环境的操作系统从所述可信存储区域获取加密的密钥，并从所述安全硬件设备获取根密钥RKEK；其中，每个安全硬件设备的根密钥RKEK均不同；
    所述可信执行环境的操作系统利用根密钥RKEK对所述加密的密钥执行解密操作， 获得解密后的密钥。
  21. 如权利要求16-20任一项所述的方法，其特征在于，所述密钥包括对称密钥。
  22. 一种设备数据处理系统，其特征在于，包括：
    主机端，用于确定对设备数据进行加密的密钥，利用所述密钥对所述设备数据执行加密操作，并将加密后的设备数据和表示所述设备数据的数据标识烧录至设备端；
    设备端，用于确定对设备数据进行加密的密钥，并保存所述密钥和表示所述设备数据的数据标识至可信执行环境的可信存储区域，在非可信执行环境接收并保存所述主机端烧录的加密后的设备数据和所述数据标识。
  23. 如权利要求22所述的系统，其特征在于，
    所述主机端执行确定对设备数据进行加密的密钥的过程，具体包括：生成对设备数据进行加密的密钥，并将所述密钥和表示所述设备数据的数据标识烧录至设备端；
    所述设备端执行确定对设备数据进行加密的密钥的过程，具体包括：在非可信执行环境接收所述主机端烧录的所述密钥和表示所述设备数据的数据标识。
  24. 如权利要求22所述的系统，其特征在于，
    所述设备端执行确定对设备数据进行加密的密钥的过程，具体包括：所述设备端在可信执行环境生成对设备数据进行加密的密钥，发送所述密钥和用于表示所述设备数据的数据标识至所述主机端；
    所述主机端执行确定对设备数据进行加密的密钥的过程，具体包括：接收所述设备端发送的对设备数据进行加密的密钥和数据标识，并对应保存所述密钥和所述数据标识。
  25. 如权利要求23或24所述的系统，其特征在于，所述设备端执行对应保存所述密钥和数据标识至可信执行环境的可信存储区域的过程，具体包括：
    所述可信执行环境在安全硬件设备中获取根密钥RKEK，并利用所述根密钥RKEK对所述密钥执行加密操作；
    所述可信执行环境对应存储加密后的密钥和所述数据标识至所述可信存储区域。
  26. 如权利要求22所述的系统，其特征在于，
    所述设备端，还用于在非可信执行环境需使用所述设备数据情况下，发送所述加密后的设备数据和所述数据标识至所述可信执行环境，所述可信执行环境查找与所述数据标识对应的密钥，利用该密钥解密所述加密后的设备数据获得所述设备数据，发送所述设备数据至所述非可信执行环境。
  27. 如权利要求22所述的系统，其特征在于，所述密钥包括对称密钥。
  28. 一种设备数据处理方法，其特征在于，应用于包括非可信执行环境和可信执行环境的设备端，所述方法包括：
    确定对设备数据进行加密的密钥；
    保存所述密钥和表示所述设备数据的数据标识至可信执行环境的可信存储区域；
    在非可信执行环境接收并保存主机端烧录的加密后的设备数据和所述数据标识。
  29. 一种设备数据处理方法，其特征在于，应用于主机端，所述方法包括：
    确定对设备数据进行加密的密钥；
    利用所述密钥对所述设备数据执行加密操作；
    将加密后的设备数据和表示所述设备数据的数据标识烧录至设备端。
  30. 一种设备数据处理方法，其特征在于，应用于包括非可信执行环境和可信执行环境的设备端，所述方法包括：
    在非可信执行环境需使用所述设备数据情况下，发送加密后的设备数据和用于表示设备数据的数据标识至所述可信执行环境；
    所述可信执行环境查找与所述数据标识对应的密钥，利用该密钥解密所述加密后的设备数据获得设备数据；
    发送所述设备数据至所述非可信执行环境。
PCT/CN2018/119741 2017-12-08 2018-12-07 一种设备数据处理方法及系统 WO2019110000A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201711292563.2 2017-12-08
CN201711292563.2A CN109905233B (zh) 2017-12-08 2017-12-08 一种设备数据处理方法及系统

Publications (1)

Publication Number Publication Date
WO2019110000A1 true WO2019110000A1 (zh) 2019-06-13

Family

ID=66750402

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/119741 WO2019110000A1 (zh) 2017-12-08 2018-12-07 一种设备数据处理方法及系统

Country Status (3)

Country Link
CN (1) CN109905233B (zh)
TW (1) TW201926216A (zh)
WO (1) WO2019110000A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112069515A (zh) * 2020-08-20 2020-12-11 博流智能科技（南京）有限公司 安全的efuse烧录方法及系统
US20230291549A1 (en) * 2022-03-14 2023-09-14 Vmware, Inc. Securely sharing secret information through an unsecure channel

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110430051B (zh) * 2019-08-01 2022-08-05 北京永新视博数字电视技术有限公司 一种密钥存储方法、装置及服务器
CN112995109B (zh) * 2019-12-17 2023-05-26 阿里巴巴集团控股有限公司 数据加密系统、方法、数据处理方法、装置及电子设备
WO2021168652A1 (zh) * 2020-02-25 2021-09-02 深圳市欢太科技有限公司 终端设备信息传输方法、设备指纹生成方法及相关产品

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104392188A (zh) * 2014-11-06 2015-03-04 三星电子（中国）研发中心 一种安全数据存储方法和系统
CN105812332A (zh) * 2014-12-31 2016-07-27 北京握奇智能科技有限公司 数据保护方法
CN106033503A (zh) * 2015-03-19 2016-10-19 阿里巴巴集团控股有限公司 在数字内容设备中在线写入应用密钥的方法、装置及系统
US20170277869A1 (en) * 2016-03-25 2017-09-28 Mstar Semiconductor, Inc. Computing device and data processing method

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2759955A1 (en) * 2013-01-28 2014-07-30 ST-Ericsson SA Secure backup and restore of protected storage
CN104244237B (zh) * 2014-09-12 2019-03-22 宇龙计算机通信科技(深圳)有限公司 数据发送、接收方法及接收、发送终端和数据收发装置
CN104636917A (zh) * 2015-02-03 2015-05-20 武汉天喻信息产业股份有限公司 一种具备安全支付功能的移动支付系统及方法
CN106878231A (zh) * 2015-12-10 2017-06-20 中国电信股份有限公司 用于实现用户数据安全传输的方法、用户终端和系统
KR102425368B1 (ko) * 2016-05-02 2022-07-27 삼성전자주식회사 가상 sim 운용 방법 및 그 장치
CN106980794B (zh) * 2017-04-01 2020-03-17 北京元心科技有限公司 基于TrustZone的文件加解密方法、装置及终端设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104392188A (zh) * 2014-11-06 2015-03-04 三星电子（中国）研发中心 一种安全数据存储方法和系统
CN105812332A (zh) * 2014-12-31 2016-07-27 北京握奇智能科技有限公司 数据保护方法
CN106033503A (zh) * 2015-03-19 2016-10-19 阿里巴巴集团控股有限公司 在数字内容设备中在线写入应用密钥的方法、装置及系统
US20170277869A1 (en) * 2016-03-25 2017-09-28 Mstar Semiconductor, Inc. Computing device and data processing method

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112069515A (zh) * 2020-08-20 2020-12-11 博流智能科技（南京）有限公司 安全的efuse烧录方法及系统
CN112069515B (zh) * 2020-08-20 2023-10-13 博流智能科技（南京）有限公司 安全的efuse烧录方法及系统
US20230291549A1 (en) * 2022-03-14 2023-09-14 Vmware, Inc. Securely sharing secret information through an unsecure channel

Also Published As

Publication number Publication date
CN109905233A (zh) 2019-06-18
CN109905233B (zh) 2022-07-29
TW201926216A (zh) 2019-07-01

Similar Documents

Publication Publication Date Title
WO2019110000A1 (zh) 一种设备数据处理方法及系统
US7912223B2 (en) Method and apparatus for data protection
WO2018024056A1 (zh) 用户口令管理的方法和服务器
TW201814496A (zh) 資料儲存方法、資料獲取方法、裝置及系統
TW201740305A (zh) 資料加密方法、資料解密方法、裝置及系統
KR20040075293A (ko) 컴퓨팅 장치를 보안 네트워크에 접속시키기 위한 방법 및시스템
US11405202B2 (en) Key processing method and apparatus
TW202031010A (zh) 資料儲存方法、裝置及設備
CN104866784A (zh) 一种基于bios加密的安全硬盘、数据加密及解密方法
CN113609522A (zh) 数据授权及数据访问方法和装置
US11765133B2 (en) Authentication scheme in a virtual private network
TW201608412A (zh) 用於提供安全性雲端服務的代理器及用於安全性雲端服務的安全性訊標裝置
TW202009773A (zh) 可信執行環境的啟動方法和裝置
US11582028B1 (en) Sharing grouped data in an organized storage system
WO2018054144A1 (zh) 对称密钥动态生成方法、装置、设备及系统
TWM569453U (zh) Digital data processing system
WO2021212516A1 (zh) 应用于短距离通信系统的配对方法和无线设备
WO2016181976A1 (ja) 情報送信装置
WO2019032580A1 (en) APPARATUS AND METHOD FOR ENCAPSULATION OF PRIVATE KEYS OF PROFILE CERTIFICATE OR OTHER DATA
US11831756B2 (en) Sharing access to data externally
US11743044B2 (en) Password-less authentication using key agreement and multi-party computation (MPC)
US11909862B2 (en) Sharing access to data
US20230085843A1 (en) Sharing data in an organized storage system
TWI672653B (zh) 數位資料加密方法、數位資料解密方法及數位資料處理系統
US20230092563A1 (en) Organized Data Storage System

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18885357

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18885357

Country of ref document: EP

Kind code of ref document: A1