CN111105777A - Voice data acquisition and playing method and device, key packet updating method and device and storage medium - Google Patents

Voice data acquisition and playing method and device, key packet updating method and device and storage medium Download PDF

Info

Publication number
CN111105777A
CN111105777A CN201811253059.6A CN201811253059A CN111105777A CN 111105777 A CN111105777 A CN 111105777A CN 201811253059 A CN201811253059 A CN 201811253059A CN 111105777 A CN111105777 A CN 111105777A
Authority
CN
China
Prior art keywords
key
execution environment
trusted execution
packet
voice data
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
CN201811253059.6A
Other languages
Chinese (zh)
Other versions
CN111105777B (en
Inventor
叶建隆
董民
陶伟成
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
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 Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN201811253059.6A priority Critical patent/CN111105777B/en
Publication of CN111105777A publication Critical patent/CN111105777A/en
Application granted granted Critical
Publication of CN111105777B publication Critical patent/CN111105777B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L13/00—Speech synthesis; Text to speech systems
    • G10L13/02—Methods for producing synthetic speech; Speech synthesisers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • 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
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • 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
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • Acoustics & Sound (AREA)
  • Multimedia (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Telephonic Communication Services (AREA)

Abstract

The application provides a voice data acquisition method and device, a voice data playing method and device, a key package updating method and device and a non-transitory computer readable storage medium. The voice data acquisition method comprises the following steps: storing received voice data into an exclusive memory in a trusted execution environment, wherein the exclusive memory is a memory exclusively occupied by the trusted execution environment; in the trusted execution environment, encapsulating the voice data in the exclusive memory into a voice data packet by using a preset key packet, and writing the voice data packet into a shared memory; and in an untrusted execution environment independent of the trusted execution environment, reading the voice data packet from the shared memory, and sending the voice data packet to a server, wherein the shared memory is a memory shared by the trusted execution environment and the untrusted execution environment.

Description

Voice data acquisition and playing method and device, key packet updating method and device and storage medium
Technical Field
The present application relates to the field of multimedia device control, and in particular, to a method and an apparatus for collecting voice data, a method and an apparatus for playing voice data, a method and an apparatus for updating a key package, and a non-transitory computer-readable storage medium.
Background
With the development of artificial intelligence and embedded technology, intelligent voice technology based on human-computer interaction is more and more widely applied and is likely to become the next entrance of the internet in the future.
Generally, voice data includes privacy information of a user, and belongs to sensitive data, such as dialogue data, voiceprint data, key data and the like of the user, and not only the content of the data includes the privacy of the user, but also the parameter characteristics of the data themselves reflect identity information of the user. Therefore, it is important to protect the security of the voice data.
In general, voice data of a user is collected and preprocessed at a collection device side, and transmitted to a server side (e.g., a cloud side) through a network for processing. And then, after analyzing and processing the voice data of the user, the server side returns the response voice data to the equipment side to be played to the user. Therefore, in the whole link process (including acquisition, preprocessing, transmission and the like) of the voice data use, the security protection of the voice data is very important, and once the voice data is illegally acquired or tampered by a hacker, huge loss is brought to a user.
Disclosure of Invention
The application provides a voice data acquisition method and device, a voice data playing method and device, a key package updating method and device and a non-transitory computer readable storage medium.
According to a first aspect of the present application, there is provided a method for acquiring voice data, including:
storing received voice data into an exclusive memory in a trusted execution environment, wherein the exclusive memory is a memory exclusively occupied by the trusted execution environment;
in the trusted execution environment, encapsulating the voice data in the exclusive memory into a voice data packet by using a preset key packet, and writing the voice data packet into a shared memory;
and in an untrusted execution environment independent of the trusted execution environment, reading the voice data packet from the shared memory, and sending the voice data packet to a server, wherein the shared memory is a memory shared by the trusted execution environment and the untrusted execution environment.
According to a second aspect of the present application, there is provided a method for playing voice data, including:
in the non-trusted execution environment, writing the received voice response packet into a shared memory;
reading the voice response packet from the shared memory in a trusted execution environment independent of the untrusted execution environment, and loading the voice response packet to an exclusive memory, wherein the shared memory is a memory shared by the trusted execution environment and the untrusted execution environment, and the exclusive memory is a memory exclusive to the trusted execution environment;
in the trusted execution environment, verifying the validity of the voice response packet by using a preset key packet;
and acquiring the voice data in the legal voice response packet in the trusted execution environment.
According to a third aspect of the present application, there is provided a method of updating a keybag, comprising:
in a trusted execution environment, triggering a key package updating request based on a key refreshing time interval in a current key package and a preset safety clock;
in the trusted execution environment, based on the key package updating request, packaging the current key package into an updating request package, and writing the updating request package into a shared memory;
reading the update request packet from the shared memory in an untrusted execution environment independent of the trusted execution environment, and sending the update request packet to a server, wherein the shared memory is a memory shared by the trusted execution environment and the untrusted execution environment;
in the non-trusted execution environment, writing the received key updating response packet into a shared memory;
in the trusted execution environment, reading the key update response packet from the shared memory, and loading the key update response packet to an exclusive memory, wherein the exclusive memory is a memory exclusive to the trusted execution environment;
in the trusted execution environment, verifying the validity of the key updating response packet by using the current key packet;
and in the trusted execution environment, replacing the current key packet with an updated key packet in a legal key updating response packet.
According to a fourth aspect of the present application, there is provided an apparatus comprising:
a processor;
a memory for storing one or more programs;
the one or more programs, when executed by the processor, cause the processor to implement any of the methods described above.
According to a fifth aspect of the present application, there is provided a non-transitory computer readable storage medium having stored thereon a computer program which, when executed by a processor, causes the processor to carry out any one of the methods as described above.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the application. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
FIG. 1 shows a flow chart of a method of acquisition of speech data according to an embodiment of the present application;
FIG. 2 shows a flow chart of a method of acquisition of speech data according to another embodiment of the present application;
FIG. 3 shows a flow chart of a method of acquisition of speech data according to another embodiment of the present application;
FIG. 4 is a flowchart illustrating encapsulating voice data in an exclusive memory into a voice data packet using a predetermined key packet in a trusted execution environment according to an embodiment of the present application;
FIG. 5 is a flowchart illustrating encapsulation of voice data in an exclusive memory into a voice data packet using a predetermined key packet in a trusted execution environment according to another embodiment of the present application;
FIG. 6 is a flowchart illustrating encapsulation of voice data in an exclusive memory into a voice data packet using a predetermined key packet in a trusted execution environment according to another embodiment of the present application;
FIG. 7 shows a flow chart of a method of playing voice data according to an embodiment of the present application;
FIG. 8 illustrates a flow diagram for verifying the legitimacy of a voice response packet using a provisioned keybag in a trusted execution environment in accordance with an embodiment of the present application;
FIG. 9 illustrates a flow diagram for verifying the legitimacy of a voice response packet using a provisioned keybag in a trusted execution environment in accordance with another embodiment of the present application;
FIG. 10 is a flow diagram illustrating the steps of retrieving and playing voice data in a legitimate voice response packet in a trusted execution environment according to an embodiment of the present application;
FIG. 11 shows a flow diagram of a method of updating a keybag according to one embodiment of the present application;
fig. 12 is a view illustrating an application scenario of the voice data collection method and the playing method according to the present application.
Detailed Description
Embodiments of the present application are described in detail below with reference to the accompanying drawings. It should be noted that the following description is merely exemplary in nature and is not intended to limit the present application. Further, in the following description, the same reference numbers will be used to refer to the same or like parts in different drawings. The different features in the different embodiments described below can be combined with each other to form further embodiments within the scope of the application.
In order to solve the problems in the prior art, according to the application, a Trusted Execution Environment (TEE) and an untrusted Execution Environment (REE) which are independent of each other can be operated at a device end (for example, an intelligent sound box, an intelligent mobile terminal, an intelligent set-top box with a voice interaction function, an intelligent television or the like) for collecting user voice data. Generally, TEE can also be called Secure World (Secure World) and REE can be called Normal World (Normal World). In the TEE, the collection and the pretreatment of the original voice data of the user can be carried out, then the processed voice data of the user is transferred to the REE through the shared memory of the TEE and the REE, and then the REE sends the voice data to the server side. Because the TEE is a safe operating environment, the TEE has higher safety and is not easy to be attacked, the original voice data is collected and preprocessed by the TEE, the safety of the voice data can be ensured, and then the REE which is relatively independent of the TEE is used as a transfer hub to transfer the processed voice data to the server side. After receiving the voice data of the user, the server side may obtain corresponding feedback voice data through analysis processing, for example, tts (text to speech) voice data synthesized through natural language processing. The server side sends the feedback voice data to the REE, the REE transfers the feedback voice data to the TEE through the shared memory, and the TEE can play the feedback voice data after processing the feedback voice data. Therefore, the original voice data of the user or the voice data fed back by the server side are relatively safe in the whole collection, processing and transmission processes, and the safety of the voice data is ensured.
Fig. 1 shows a flow chart of a method of collecting voice data according to an embodiment of the present application. As shown in fig. 1, the method 100 may include steps S110 to S130. In step S110, the received voice data is stored in the trusted execution environment into the exclusive memory. The exclusive memory is a secure memory, and may be a secure memory specially set for the trusted execution environment at the voice data acquisition device side. The exclusive memory is only used by the trusted execution environment and cannot be accessed by any entity in the untrusted execution environment, so that the exclusive memory has higher security and is not easy to attack. Therefore, the received original voice data of the user is stored in the exclusive memory, and the safety of the collected original voice data can be ensured. The original voice data of the user may be voice data collected by an input device such as a microphone at the end of the collecting device, for example, voice data in the process of human-computer interaction, and the general format is Pulse Code Modulation (PCM). It will be appreciated that the user's raw speech data may also be captured by a Secure Audio capture (Secure Audio Capturer) device under the control of a trusted execution environment.
In step S120, in the trusted execution environment, the voice data in the exclusive memory is encapsulated into a voice data packet by using a preset key packet, and the voice data packet is written into the shared memory. A key package may be preset at the device side for acquiring the voice data, and in the trusted execution environment, the key package may be used to encapsulate the voice data stored in the exclusive memory in step S110, so as to generate a voice data package. The specific packaging operation will be described in detail below. The generated voice data packet is written into a shared memory of the acquisition equipment terminal. The shared memory is a memory which is set at the acquisition device end and can be used by both the trusted execution environment and the untrusted execution environment, and is used for sharing and transferring data in the trusted execution environment and the untrusted execution environment. Shared memory may be referred to as non-secure memory relative to exclusive memory, which is referred to as secure memory.
In step S130, in the untrusted execution environment, the voice data packet is read from the shared memory and sent to the server. As described above, the untrusted execution environment is independent of the trusted execution environment, and the shared memory is memory that is usable by both to share and transfer data between the two. Therefore, the voice data in the shared memory can be taken out and sent to the server side in the non-trusted execution environment.
Therefore, the original voice data of the user can be collected and preprocessed in a trusted execution environment with relatively high safety. And then, the processed voice data can be acquired by the untrusted execution environment through the shared memory and forwarded to the server side. Therefore, the original voice data is protected in the trusted execution environment and cannot be illegally acquired, and in the untrusted execution environment, because the voice data is subjected to encapsulation processing of the key package, even if the voice data package is illegally acquired, the original voice data cannot be easily acquired and/or tampered, so that the safety of the voice data is improved, and the authenticity of the voice data received by the server side is ensured.
Fig. 2 shows a flow chart of a method of collecting voice data according to another embodiment of the present application. As shown in fig. 2, the method 100 may further include steps S140 and S150 in addition to steps S110 to S130. For the sake of brevity, only the differences of the embodiment shown in fig. 2 from fig. 1 will be described below, and detailed descriptions of the same parts will be omitted.
In step S140, in the untrusted execution environment, the key package pre-stored in the read-only memory partition is read, and the key package is written into the shared memory. The voice data acquisition equipment end can be preset with a read-only memory partition which can be mapped to the read-only partition of the file system, wherein the stored data can not be modified or deleted, and can not be modified or deleted even if the system is restarted or the mirror image is upgraded on line. When the voice data acquisition equipment leaves the factory, a unique key package of the equipment can be stored in a read-only storage partition in the equipment in advance. The keybag may be distributed by a key distribution center and may contain a key for encryption (e.g., 16 bytes in length), a key for signature (e.g., 16 bytes in length), and key overhead information (e.g., a key ID). The content in the keybag is used to encrypt, sign, etc. the voice data in the trusted execution environment. In step S140, the untrusted execution environment may fetch the key package from the read-only memory partition of the collection device and write the key package into the shared memory.
Subsequently, in step S150, in the trusted execution environment, the key package is read from the shared memory and loaded into the exclusive memory. In order to encrypt and sign voice data by using the key package in the trusted execution environment, the key package can be taken out from the shared memory in the trusted execution environment and loaded to the exclusive memory, so that the security of subsequent operations is ensured.
Fig. 3 shows a flow chart of a method of collecting voice data according to another embodiment of the present application. As shown in fig. 3, the method 100 may further include a step S160 in addition to the steps S110 to S150. For the sake of brevity, only the differences of the embodiment shown in fig. 3 from fig. 2 will be described below, and detailed descriptions of the same parts will be omitted.
In step S160, in the trusted execution environment, the key package loaded into the exclusive memory is decrypted and signature verified by using the encryption key and the signature key preset in the trusted execution environment, so as to obtain the encryption key, the signature key, and the key ID in the key package. In order to ensure the security of the key package, when the collection device of the voice data leaves the factory, the key package may be encrypted and signed and then stored in the read-only storage partition of the collection device, and a key (different from an encryption key and a signature key used for encapsulating the voice data in the key package) used in the encryption and signature operations at this time may be set in the trusted execution environment, so that in subsequent operations, the trusted execution environment decrypts and verifies the signature of the key package from the shared memory, that is, in step S160. For example, when the collection device is shipped from a factory, a device manufacturer may sign and encrypt the key package using a signing key and an encryption key in a secure encryption module in a trusted execution environment of the device. Alternatively, the preset encryption key and signature key may be set in the code in the trusted execution environment at the time of factory shipment of the voice data acquisition device.
Therefore, the encryption key, the signature key and the key ID contained in the key package can be obtained in the trusted execution environment for the packaging operation of the voice data, so that the data in the key package is prevented from being leaked.
Fig. 4 is a flowchart illustrating encapsulating voice data in an exclusive memory into a voice data packet by using a predetermined key packet in a trusted execution environment according to an embodiment of the present application. As shown in fig. 4, the above step S120 may include sub-steps S121 and S122.
In sub-step S121, the speech data is compressed in the trusted execution environment. And the voice data is compressed, so that the transmission efficiency to the server side can be improved, and the bandwidth can be saved. The voice data may be compressed using mp3, m4a, ogg, etc. techniques.
In sub-step S122, in the trusted execution environment, a signature is generated and encrypted for the compressed voice data by using the encryption key and the signature key in the key package to generate a voice data package. After the voice data is compressed, a signature may be generated and encrypted for the voice data in the trusted execution environment by using the encryption key and the signature key in the key package acquired in step S160, and the generated voice data package is the voice data package encapsulated by the encryption key and the signature key in the key package.
Fig. 5 is a flowchart illustrating encapsulating voice data in an exclusive memory into a voice data packet using a predetermined key packet in a trusted execution environment according to another embodiment of the present application. As shown in fig. 5, the above step S120 may further include a substep S123 in addition to the substeps S121 and S122. For the sake of brevity, only the differences of the embodiment shown in fig. 5 from fig. 4 will be described below, and detailed descriptions of the same parts will be omitted.
In sub-step S123, in the trusted execution environment, a key ID is added to the voice data packet. In step S160, the key ID in the key package, which characterizes the unique key package as the acquisition device, is obtained in addition to the encryption key and the signature key in the key package. Therefore, when the server side receives the voice data packet, the server side can know which key packet the server side corresponds to through the key ID, and therefore the server side can process the received voice data packet by using the corresponding key packet.
Fig. 6 is a flowchart illustrating encapsulating voice data in an exclusive memory into a voice data packet using a predetermined key packet in a trusted execution environment according to another embodiment of the present application. As shown in fig. 6, the above step S120 may further include a substep S124 in addition to the substeps S121 and S122. For the sake of brevity, only the differences of the embodiment shown in fig. 6 from fig. 4 will be described below, and detailed descriptions of the same parts will be omitted.
In sub-step S124, a random number is added to the compressed speech data in the trusted execution environment. The random number is randomly generated in the trusted execution environment for being added in the voice data packet, and the server side should also include the random number in the returned voice response packet for verification. If the voice response packet received from the server does not contain the random number, it can be considered that the voice response packet may be intercepted or tampered during the transmission of the voice data, and the voice response packet may not be secure.
Through the above description, the voice data of the user can be collected and preprocessed at the voice data collecting device end and sent to the server end, the whole collecting and processing process is carried out in a safe environment, and when the voice data is transmitted to an external open environment, the voice data is signed and encrypted, so that the safety of the voice data is ensured.
After receiving the voice data packet, the server can know which key packet corresponds to the voice data packet through the key ID, so that the voice data packet is decrypted and signed and verified by using the encryption key and the signature key in the key packet, and the voice data in the voice data packet is obtained. The server side can generate response voice data, for example, TTS voice data, through processing and analyzing the voice data. After compressing the response voice data, the server side can sign and encrypt the random numbers in the received voice data packet by using the encryption key and the signature key in the key packet to generate a voice response packet. And then, the key ID can be added to the voice response packet and then sent to the voice data acquisition equipment.
Fig. 7 shows a flowchart of a playing method of voice data according to an embodiment of the present application. As shown in fig. 7, the method 200 may include steps S210 to S240. In step S210, in the untrusted execution environment, the received voice response packet is written into the shared memory. As described above, the shared memory is a memory that is provided on the acquisition device side and is usable by both the trusted execution environment and the untrusted execution environment, and is used for sharing and transferring data between the trusted execution environment and the untrusted execution environment. After receiving the voice response packet at the device end used by the user, the untrusted execution environment writes the voice response packet into the shared memory.
In step S220, in the trusted execution environment, the voice response packet is read from the shared memory and loaded into the exclusive memory. As described above, the exclusive memory is a secure memory that is set exclusively for the trusted execution environment on the device side used by the user, and is only used by the trusted execution environment and cannot be accessed by any entity in the untrusted execution environment, so that the exclusive memory has higher security and is not easy to be attacked. Therefore, in this step, the trusted execution environment is used to take out the voice response packet from the shared memory and load the voice response packet into the exclusive memory, so that the voice response packet can be subsequently processed in the trusted execution environment, and the security of the voice data can be improved.
In step S230, in the trusted execution environment, the validity of the voice response packet is verified by using a preset key packet. As described above, the key package may be preset at the device side for acquiring the voice data, and the validity of the voice response package may be verified in the trusted execution environment by using the content in the key package. The specific authentication process will be described in detail below.
In step S240, in the trusted execution environment, the voice data in the legitimate voice response packet is acquired. According to actual needs or settings, the voice data obtained in this step can be played in a trusted execution environment or an untrusted execution environment. Therefore, the voice response packet from the server side can be verified under the trusted execution environment, and the voice data passing the verification can be played, so that the safety and the reliability of the voice response packet are ensured.
FIG. 8 illustrates a flow diagram for verifying the legitimacy of a voice response packet using a provisioned keybag in a trusted execution environment in accordance with one embodiment of the present application. As shown in fig. 8, the above step S230 may include sub-steps S231 and S232. In sub-step S231, in the trusted execution environment, a key packet corresponding to the key ID is searched for according to the key ID of the voice response packet. As described above, the server may add the key ID of the key package to the voice response package when generating the voice response package. The key ID is known when the device used by the user receives the voice response packet. In the trusted execution environment on the user equipment side, the corresponding keybag can be validated by the key ID.
Subsequently, in sub-step S232, the voice response package is decrypted and signed and authenticated by using the encryption key and the signature key in the key package in the trusted execution environment. After the corresponding key package is obtained, the voice response package generated by the server side can be decrypted and signed and authenticated by using the encryption key and the signature key in the key package in the trusted execution environment. Therefore, the validity of the voice response packet can be verified through the key packet preset by the user equipment. And the whole verification process is completed in a trusted execution environment, so that the safety of voice data and key data is effectively protected.
FIG. 9 illustrates a flow diagram for verifying the legitimacy of a voice response packet using a provisioned keybag in a trusted execution environment in accordance with another embodiment of the present application. As shown in fig. 9, the above-described step S230 may further include a sub-step S233 in addition to the sub-steps S231 and S232. For the sake of brevity, only the differences of the embodiment shown in fig. 9 from fig. 8 will be described below, and detailed descriptions of the same parts will be omitted.
In sub-step S233, in the trusted execution environment, the validity of the voice response packet is checked by using a preset random number. As described above, when the user equipment sends a voice data packet to the server, the voice data packet contains a random number for verification, and when the server generates a voice response packet, the server contains the random number. Therefore, the validity of the voice response packet is verified by checking whether the random number is included in the voice response packet. If the voice response packet contains the random number, the voice response packet is legal. Otherwise, if the random number is not contained in the voice response packet, it indicates that the voice response packet is illegal, and the voice data therein may have been intercepted or tampered.
Fig. 10 shows a flowchart for acquiring and playing voice data in a legitimate voice response packet in a trusted execution environment according to an embodiment of the present application. As shown in fig. 10, the above step S240 may include sub-steps S241 and S242. In sub-step S241, compressed voice data is extracted from the legitimate voice response packet in the trusted execution environment. As described above, in order to improve transmission efficiency and save bandwidth, the voice data in the voice response packet from the server side may be compressed data. Thus, when the voice response packet has been verified to be legitimate, compressed voice data can be extracted from the voice response packet in the trusted execution environment.
Subsequently, in sub-step S242, the compressed speech data is decompressed in the trusted execution environment. Therefore, the decompression of the voice data from the server side is carried out under the trusted execution environment, so that the security of the voice data is protected.
In the above description, the key package is unique to each device, and when the key package of one device is inadvertently intercepted or leaked, the security of the key package on the other device is not affected. The key package in the device may be a key package Unique to the device, which is applied by a device manufacturer to the key distribution center by using a UUID (universal Unique Identifier: device Unique ID) of the device, and the key distribution center may ensure that both the key ID and the key information in the key package corresponding to the UUID of the device have uniqueness. However, if the update can be performed dynamically during the use of the keybag, the security is further improved.
FIG. 11 shows a flow diagram of a method of updating a keybag according to one embodiment of the present application. As shown in fig. 11, the method 300 may include steps S310 to S370. In step S310, in the trusted execution environment, a key package update request is triggered based on a key refresh time interval in the current key package and a preset secure clock. As described above, the key packet set at the acquisition device side may contain additional information, which may include a key refresh time interval in addition to the key ID. Thus, after decryption and signature authentication of the keybag in the trusted execution environment, the key refresh interval may be obtained from additional information therein. Furthermore, according to the present embodiment, a secure clock may also run in the trusted execution environment, which is not accessible and modifiable by the untrusted execution environment. Thus, the trusted execution environment may trigger a key package update request based on the secure clock and the key refresh interval.
In step S320, in the trusted execution environment, the current key package is packaged as an update request package based on the key package update request, and the update request package is written into the shared memory. As described above, a key package (i.e., a current key package) may be preset at the device side for acquiring voice data, and in the trusted execution environment, the key package may be encapsulated to generate an update request package. The specific packaging operation will be described in detail below. The generated update request packet is written into the shared memory of the acquisition equipment terminal.
According to one embodiment, step S320 may further include: in the trusted execution environment, a random number is added to the current keybag. As described above, the random number is randomly generated in the trusted execution environment, and may be added to the current key package, and the server side should also include the random number in the returned key update response package for verification. If the key update response packet received from the server side does not contain the random number, it can be considered that there is a possibility that the key update response packet is intercepted or tampered during the transmission of the key packet, and the key update response packet may not be secure.
According to one embodiment, step S320 may include: and in the trusted execution environment, generating a signature for the current key packet by using the encryption key and the signature key in the current key packet and encrypting the signature to generate an updating request packet. That is, the current keybag may be packaged using the encryption key and the signing key in the current keybag to generate the update request package.
According to one embodiment, step S320 may further include: in the trusted execution environment, a key ID preset in the current keybag is added to the update request packet. Therefore, when the server side receives the update request packet, the server side can know which key packet the server side corresponds to through the key ID, and therefore the server side can process the received update request packet by using the corresponding key packet.
In step S330, in the untrusted execution environment, the update request packet is read from the shared memory and sent to the server. As described above, the untrusted execution environment is independent of the trusted execution environment, and the shared memory is memory that is usable by both to share and transfer data between the two. Therefore, the update request packet in the shared memory can be taken out and sent to the server side in the untrusted execution environment. Thus, the current keybag may be packaged as an update request package in a trusted execution environment that is relatively highly secure. And then, acquiring an update request packet by the untrusted execution environment through the shared memory, and forwarding the update request packet to the server. Therefore, the key package is protected in the trusted execution environment and cannot be illegally acquired, and in the untrusted execution environment, because the update request package is packaged, the key package cannot be easily acquired and/or tampered even if the update request package is illegally acquired, so that the security of the key information is improved, and the authenticity of the key information received by the server side is ensured.
After receiving the update request packet, the server side can know which key packet corresponds to the update request packet through the key ID information in the update request packet, so that the update request packet is decrypted and signed and verified by using the encryption key and the signature key in the key packet to obtain the current key packet in the update request packet. The server side can randomly generate a new key package. The server side may sign and encrypt the new keybag and the random number in the received update request packet by using the encryption key and the signature key in the old keybag (i.e., the current keybag) to generate a keyupdate response packet. In addition, the server side can also add a new key ID corresponding to the new key packet into the key updating response packet. Then, the key ID (ID of the old key package, so as to facilitate the acquisition device side to search for the corresponding current key package to be updated) may be added to the key update response package, and then sent to the acquisition device side of the voice data.
In step S340, in the untrusted execution environment, the received key update response packet is written into the shared memory. After the device used by the user receives the key update response packet, the untrusted execution environment first writes the key update response packet into the shared memory.
In step S350, in the trusted execution environment, the key update response packet is read from the shared memory and loaded into the exclusive memory. As described above, the exclusive memory is a secure memory that is set exclusively for the trusted execution environment on the device side used by the user, and is only used by the trusted execution environment and cannot be accessed by any entity in the untrusted execution environment, so that the exclusive memory has higher security and is not easy to be attacked. Therefore, in this step, the trusted execution environment is used to take out the key update response packet from the shared memory and load the key update response packet into the exclusive memory, so that subsequent processing in the trusted execution environment is facilitated, and the security of the update key packet is improved.
In step S360, the validity of the key update response package is verified with the current key package in the trusted execution environment.
According to one embodiment, in the trusted execution environment, the key update response packet can be decrypted and signed and authenticated by using the encryption key and the signature key in the current key packet, so that the validity of the key update response packet can be verified. After the key update response packet is obtained, the encryption key and the signature key in the current key packet (old key packet) can be used to decrypt and sign and authenticate the key update response packet generated by the server side in the trusted execution environment. Therefore, the validity of the key updating response packet can be verified through the current key packet. And the whole verification process is completed in the trusted execution environment, so that the safety of the key data is effectively protected.
According to one embodiment, in the trusted execution environment, the validity of the key update response packet is checked by using the random number. As described above, when the user equipment sends the update request packet to the server, the update request packet includes the random number for verification, and when the server generates the key update response packet, the server includes the random number therein. Therefore, the validity of the key update response packet is verified by checking whether the random number is included in the key update response packet. If the random number is contained in the key updating response packet, the key updating response packet is legal. On the contrary, if the random number is not contained in the key update response packet, it indicates that the key update response packet is illegal, and the key data therein may have been intercepted or tampered.
In step S370, in the trusted execution environment, the current keybag is replaced with an update keybag in a legitimate rekeying response package. Therefore, the key updating response packet from the server side can be verified in the trusted execution environment, and the verified updating key packet is used as a new key packet in the equipment, so that the updating of the key packet is realized, and the safety and the reliability of the updating key packet are ensured.
Fig. 12 is a view illustrating an application scenario of the voice data collection method and the playing method according to the present application. As shown in fig. 12, the application scenario includes a device manufacturer 410, a voice server 420, and a voice device 430. The device manufacturer 410 is the manufacturer that produces the voice device side 430; the voice device end 430 is a terminal device for performing human-computer voice interaction with a user, for example, an intelligent sound box, an intelligent mobile terminal, an intelligent set-top box with a voice interaction function, or an intelligent television; the speech service end 420 is a service end providing background computing processing and speech service, and receives speech data sent from the speech device end 430 through the network, and after analysis processing, synthesizes TTS speech data and sends the TTS speech data back to the speech device end 430, so that the speech device end 430 plays the TTS speech data to a user for listening.
The voice device side 430 has a user space and a kernel space, and the untrusted execution environment REE and the trusted execution environment TEE run independently of each other in the voice device side 430. The untrusted execution environment REE includes an untrusted voice application and a general OS (Operating System), the untrusted voice application is in a user space, the general OS is in a kernel space, and an encrypted key package is stored in a read-only partition of a file System of the general OS. The trusted execution environment TEE comprises a trusted voice application and a secure OS, the trusted voice application is in a user space, the secure OS is in a kernel space, and the secure OS comprises a secure encryption module and a secure audio module.
Before the voice device 430 leaves the factory, the device manufacturer 410 may apply for a key package unique to the device to the key distribution center using the UUID of the device. The key package may contain an encryption key, a signing key, and additional information, which may include information such as a key ID and a key refresh interval. The key distribution center ensures that the key ID and the key information in the key package corresponding to the UUID of each device have uniqueness. The device manufacturer 410 may sign the keybag with a signing key in the secure encryption module of the voice device side 430 and encrypt it with an encryption key in the secure encryption module. The encrypted keybag may be stored in a read-only memory partition of the voice device side 430.
When the voice device 430 performs man-machine voice interaction with a user, the untrusted voice application may read the encrypted key package from the read-only memory partition of the file system of the general OS, and forward the encrypted key package to the trusted voice application through the shared memory (not shown in the figure) of the trusted execution environment TEE and the untrusted execution environment REE. The trusted voice application may decrypt and verify the signature of the encrypted key package by using an encryption key and a signature key preset in the secure encryption module, and the decrypted key package may be stored in a secure memory (not shown) exclusively occupied by the trusted execution environment. The encryption key, the signature key, and additional information (e.g., key ID, key refresh interval, etc.) in the key package can be obtained by parsing the signature authenticated key package. It should be noted that the encryption key and the signature key in the key package obtained in this operation are different from the encryption key and the signature key preset in the secure encryption module.
When the user makes a sound, the trusted voice application of the voice device 430 uses the secure audio module to obtain the original voice data, and stores the original voice data in the secure memory of the trusted execution environment. In order to improve the efficiency of subsequent transmission and save bandwidth, it is usually necessary to compress the original speech data in a trusted execution environment, and the compression may be performed by using techniques such as mp3, m4a, ogg, and so on. In the trusted execution environment, 16 bytes of alignment can be carried out after additional information is added to the tail part of the compressed voice data, and the voice data is packaged into a request data packet. The additional information may include a key ID, a random number, and signature data, wherein the key ID is for the voice server 420 to identify and accordingly obtain a corresponding key package; the random number is randomly generated in a trusted execution environment, and is intended to prevent replay attack, and the random number should also be included in TTS voice data returned by the voice server 420 for verification; the signature data is to ensure the integrity of the voice data transmission process. Then, the request data packet is encrypted by using the encryption key in the key packet, and the key ID is added at the tail part of the request data packet, wherein the key ID is the same as the additional information key ID in the request data packet. The generated request data packet is forwarded to the untrusted voice application through the shared memory, and then transmitted to the voice server 420.
After receiving the request packet, the voice server 420 can know which key packet it corresponds to according to the key ID therein. After the voice server 420 decrypts and verifies the signature of the request packet, the voice data (and the random number therein) in the request packet can be obtained. The speech server 420 may generate responsive speech data, e.g., synthesized TTS speech data, by processing and analyzing the speech data. The voice server 420 compresses the response voice data, adds additional information, performs 16-byte alignment, and packs the response packet, where the additional information includes the key ID, the random number, and the signature data. Then, the voice server 420 encrypts the response packet, adds the key ID to the tail, and sends the encrypted response packet to the voice device 430.
After receiving the response packet, the untrusted voice application of the voice device 430 is forwarded to the trusted voice application through the shared memory. The trusted voice application loads the response data packet to the secure memory, and finds the corresponding key packet through the key ID in the response data packet. The trusted voice application decrypts and verifies the signature of the response data packet through the encryption key and the signature key of the key packet, and verifies whether the response data packet contains the random number in the request data packet sent previously. After the verification and verification, the trusted voice application extracts compressed TTS voice data from the decrypted response data packet and decompresses the compressed TTS voice data to obtain TTS voice data. And then, the trusted voice application completes the playing of the TTS voice data by utilizing the secure audio module.
When the voice device 430 updates the key package, the trusted voice application first uses a secure clock (not shown in the figure) disposed in the trusted execution environment TEE to trigger the key update request at regular time, where the trigger time can be defined according to the security required for voice interaction, and the shorter the time interval, the higher the security. As described above, when the device manufacturer 410 applies for the key package, the additional information in the key package includes key refresh interval information.
Based on the key update request, the trusted voice application adds the additional information to the tail of the currently used key package according to the signature key, the encryption key and the additional information in the currently used key package, then performs 16-byte alignment, and packages the additional information into a key update request package, wherein the additional information comprises a key ID, a random number and signature data. Then, the trusted voice application encrypts the key update request packet (by using the encryption key in the current key packet), adds the key ID to the tail, and forwards the generated key update request packet to the untrusted voice application through the shared memory. The untrusted voice application sends a key update request packet to the voice server 420 over the network, where the key update request packet is opaque and invisible to the untrusted voice application.
After receiving the key update request packet, the voice server 420 first knows which key packet it corresponds to according to the key ID therein. After the voice server 420 decrypts and verifies the signature of the key update request packet, the random number therein can be obtained. Subsequently, the voice server 420 randomly generates a new key packet, adds additional information to the tail of the new key packet, performs 16-byte alignment, and packages the new key packet into a key update response packet, where the additional information includes a key ID (newly generated key ID), the random number, and signature data. Then, the voice server 420 encrypts the key update response packet, adds the key ID (the key ID of the original key packet is identical to the key ID in the key update request packet) to the tail, and sends the encrypted key ID to the voice device 430. The signing and encryption keys adopt the signing key and the encryption key in the original key package.
After receiving the key update response packet through the network, the untrusted voice application of the voice device 430 transfers the key update response packet to the trusted voice application through the shared memory. The trusted voice application decrypts and signs the key update response packet by using the current key packet (old key packet), and checks whether the key update response packet contains the random number of the previously sent key update request packet. After the verification and verification, the trusted voice application replaces the currently used old key package with the new key package in the key update response package.
As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method or computer program product. Accordingly, this application may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to as a "circuit," module "or" system. Furthermore, the present application may take the form of a computer program product embodied in any tangible expression medium having computer-usable program code embodied in the medium.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
Although the above description includes many specific arrangements and parameters, it should be noted that these specific arrangements and parameters are merely illustrative of one embodiment of the present application. This should not be taken as limiting the scope of the application. Those skilled in the art will appreciate that various modifications, additions and substitutions are possible, without departing from the scope and spirit of the application. Accordingly, the scope of the application should be construed based on the claims.

Claims (18)

1. A method of collecting voice data, comprising:
storing received voice data into an exclusive memory in a trusted execution environment, wherein the exclusive memory is a memory exclusively occupied by the trusted execution environment;
in the trusted execution environment, encapsulating the voice data in the exclusive memory into a voice data packet by using a preset key packet, and writing the voice data packet into a shared memory;
and in an untrusted execution environment independent of the trusted execution environment, reading the voice data packet from the shared memory, and sending the voice data packet to a server, wherein the shared memory is a memory shared by the trusted execution environment and the untrusted execution environment.
2. The method of claim 1, further comprising:
reading the key package pre-stored in a read-only memory partition in the untrusted execution environment, and writing the key package into the shared memory;
and in the trusted execution environment, reading the key package from the shared memory, and loading the key package to the exclusive memory.
3. The method of claim 2, further comprising:
in the trusted execution environment, the key package loaded into the exclusive memory is decrypted and signed and verified by using an encryption key and a signature key preset in the trusted execution environment, so that the encryption key, the signature key and a key ID in the key package are obtained.
4. The method of claim 3, wherein encapsulating the voice data in the exclusive memory into a voice data packet using a predetermined key packet and writing the voice data packet to a shared memory in the trusted execution environment comprises:
compressing the voice data in the trusted execution environment;
and in the trusted execution environment, generating a signature for the compressed voice data by using an encryption key and a signature key in the key package, and encrypting to generate the voice data package.
5. The method of claim 4, wherein encapsulating the voice data in the exclusive memory into a voice data packet using a predetermined key packet and writing the voice data packet to a shared memory in the trusted execution environment further comprises:
adding, in the trusted execution environment, the key ID to the voice data packet.
6. The method of claim 4, wherein encapsulating the voice data in the exclusive memory into a voice data packet using a predetermined key packet and writing the voice data packet to a shared memory in the trusted execution environment further comprises:
adding a random number to the compressed voice data in the trusted execution environment.
7. A method for playing voice data comprises the following steps:
in the non-trusted execution environment, writing the received voice response packet into a shared memory;
reading the voice response packet from the shared memory in a trusted execution environment independent of the untrusted execution environment, and loading the voice response packet to an exclusive memory, wherein the shared memory is a memory shared by the trusted execution environment and the untrusted execution environment, and the exclusive memory is a memory exclusive to the trusted execution environment;
in the trusted execution environment, verifying the validity of the voice response packet by using a preset key packet;
and acquiring the voice data in the legal voice response packet in the trusted execution environment.
8. The method of claim 7, wherein verifying, in the trusted execution environment, the validity of the voice response packet using a pre-provisioned keybag comprises:
in the trusted execution environment, searching a key packet corresponding to the key ID according to the key ID of the voice response packet;
and in the trusted execution environment, decrypting and signing the voice response packet by using the encryption key and the signature key in the key packet.
9. The method of claim 8, wherein verifying, in the trusted execution environment, the validity of the voice response packet using a pre-provisioned keybag further comprises:
and in the trusted execution environment, checking the validity of the voice response packet by using a preset random number.
10. The method of claim 7, wherein in the trusted execution environment, obtaining voice data in a legitimate voice response packet comprises:
extracting compressed voice data from a legal voice response packet in the trusted execution environment;
decompressing, in the trusted execution environment, the compressed voice data.
11. A method of updating a keybag, comprising:
in a trusted execution environment, triggering a key package updating request based on a key refreshing time interval in a current key package and a preset safety clock;
in the trusted execution environment, based on the key package updating request, packaging the current key package into an updating request package, and writing the updating request package into a shared memory;
reading the update request packet from the shared memory in an untrusted execution environment independent of the trusted execution environment, and sending the update request packet to a server, wherein the shared memory is a memory shared by the trusted execution environment and the untrusted execution environment;
in the non-trusted execution environment, writing the received key updating response packet into a shared memory;
in the trusted execution environment, reading the key update response packet from the shared memory, and loading the key update response packet to an exclusive memory, wherein the exclusive memory is a memory exclusive to the trusted execution environment;
in the trusted execution environment, verifying the validity of the key updating response packet by using the current key packet;
and in the trusted execution environment, replacing the current key packet with an updated key packet in a legal key updating response packet.
12. The method of claim 11, wherein encapsulating, in the trusted execution environment, the current keybag as an update request packet based on the keybag update request, and writing the update request packet to shared memory further comprises:
adding, in the trusted execution environment, a random number to the current keybag.
13. The method of claim 11, wherein encapsulating, in the trusted execution environment, the current keybag as an update request packet based on the keybag update request, and writing the update request packet to shared memory comprises:
and in the trusted execution environment, generating a signature for the current key packet by using an encryption key and a signature key in the current key packet, and encrypting to generate the update request packet.
14. The method of claim 13, wherein encapsulating, in the trusted execution environment, the current keybag as an update request packet based on the keybag update request, and writing the update request packet to shared memory further comprises:
in the trusted execution environment, adding a key ID preset in the current keybag to the update request packet.
15. The method of claim 13, wherein verifying, in the trusted execution environment, the validity of the key update response package with the current keybag comprises:
and in the trusted execution environment, decrypting and signing the key updating response packet by using the encryption key and the signature key in the current key packet.
16. The method of claim 12, wherein verifying, in the trusted execution environment, the validity of the key update response package with the current keybag further comprises:
and in the trusted execution environment, verifying the validity of the key updating response packet by using the random number.
17. An apparatus, comprising:
a processor;
a memory for storing one or more programs;
the one or more programs, when executed by the processor, cause the processor to implement the method of any of claims 1-16.
18. A non-transitory computer readable storage medium having stored thereon a computer program which, when executed by a processor, causes the processor to implement the method of any one of claims 1-16.
CN201811253059.6A 2018-10-25 2018-10-25 Voice data acquisition and playing method and device, key package updating method and device and storage medium Active CN111105777B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811253059.6A CN111105777B (en) 2018-10-25 2018-10-25 Voice data acquisition and playing method and device, key package updating method and device and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811253059.6A CN111105777B (en) 2018-10-25 2018-10-25 Voice data acquisition and playing method and device, key package updating method and device and storage medium

Publications (2)

Publication Number Publication Date
CN111105777A true CN111105777A (en) 2020-05-05
CN111105777B CN111105777B (en) 2023-10-31

Family

ID=70418769

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811253059.6A Active CN111105777B (en) 2018-10-25 2018-10-25 Voice data acquisition and playing method and device, key package updating method and device and storage medium

Country Status (1)

Country Link
CN (1) CN111105777B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022000223A1 (en) * 2020-06-30 2022-01-06 浙江大学 Kernel sensitive data protection method based on custom hardware security attribute

Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102063592A (en) * 2011-01-07 2011-05-18 北京工业大学 Credible platform and method for controlling hardware equipment by using same
US20130111211A1 (en) * 2011-10-31 2013-05-02 L-3 Communications Corporation External Reference Monitor
CN104392188A (en) * 2014-11-06 2015-03-04 三星电子（中国）研发中心 Security data storage method and system
CN104581214A (en) * 2015-01-28 2015-04-29 三星电子（中国）研发中心 Multimedia content protecting method and device based on ARM TrustZone system
US20150358301A1 (en) * 2014-06-05 2015-12-10 Sony Corporation Dynamic Configuration of Trusted Executed Environment Resources
CN105450406A (en) * 2014-07-25 2016-03-30 华为技术有限公司 Data processing method and device
US20160254904A1 (en) * 2015-02-27 2016-09-01 Verizon Patent And Licensing Inc. Network services via trusted execution environment
US20160277439A1 (en) * 2015-03-20 2016-09-22 Ncluud Corporation Locking Applications and Devices Using Secure Out-of-Band Channels
CN106341225A (en) * 2016-09-19 2017-01-18 杭州字节信息技术有限公司 UMTS mobile terminal circuit domain voice encryption communication technology realization method
CN106888451A (en) * 2015-12-15 2017-06-23 ***通信集团公司 Credible performing environment TEE initial methods and equipment
CN107086041A (en) * 2017-03-27 2017-08-22 竹间智能科技（上海）有限公司 Speech emotional analysis method and device based on computations
WO2017147890A1 (en) * 2016-03-04 2017-09-08 华为技术有限公司 Verification code short message display method and mobile terminal
CN107786951A (en) * 2016-08-24 2018-03-09 ***通信有限公司研究院 A kind of information processing method and terminal device
CN107800538A (en) * 2016-09-01 2018-03-13 中电长城(长沙)信息技术有限公司 A kind of self-service device remote cipher key distribution method
WO2018072714A1 (en) * 2016-10-19 2018-04-26 北京豆荚科技有限公司 Multichannel communication system and electronic device
CN108111506A (en) * 2017-12-18 2018-06-01 深圳市恒达移动互联科技有限公司 VOIP encryption call methods and terminal
CN108667608A (en) * 2017-03-28 2018-10-16 阿里巴巴集团控股有限公司 The guard method of data key, device and system

Patent Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102063592A (en) * 2011-01-07 2011-05-18 北京工业大学 Credible platform and method for controlling hardware equipment by using same
US20130111211A1 (en) * 2011-10-31 2013-05-02 L-3 Communications Corporation External Reference Monitor
US20150358301A1 (en) * 2014-06-05 2015-12-10 Sony Corporation Dynamic Configuration of Trusted Executed Environment Resources
CN105450406A (en) * 2014-07-25 2016-03-30 华为技术有限公司 Data processing method and device
CN104392188A (en) * 2014-11-06 2015-03-04 三星电子（中国）研发中心 Security data storage method and system
CN104581214A (en) * 2015-01-28 2015-04-29 三星电子（中国）研发中心 Multimedia content protecting method and device based on ARM TrustZone system
US20160254904A1 (en) * 2015-02-27 2016-09-01 Verizon Patent And Licensing Inc. Network services via trusted execution environment
US20160277439A1 (en) * 2015-03-20 2016-09-22 Ncluud Corporation Locking Applications and Devices Using Secure Out-of-Band Channels
CN106888451A (en) * 2015-12-15 2017-06-23 ***通信集团公司 Credible performing environment TEE initial methods and equipment
WO2017147890A1 (en) * 2016-03-04 2017-09-08 华为技术有限公司 Verification code short message display method and mobile terminal
CN107786951A (en) * 2016-08-24 2018-03-09 ***通信有限公司研究院 A kind of information processing method and terminal device
CN107800538A (en) * 2016-09-01 2018-03-13 中电长城(长沙)信息技术有限公司 A kind of self-service device remote cipher key distribution method
CN106341225A (en) * 2016-09-19 2017-01-18 杭州字节信息技术有限公司 UMTS mobile terminal circuit domain voice encryption communication technology realization method
WO2018072714A1 (en) * 2016-10-19 2018-04-26 北京豆荚科技有限公司 Multichannel communication system and electronic device
CN107086041A (en) * 2017-03-27 2017-08-22 竹间智能科技（上海）有限公司 Speech emotional analysis method and device based on computations
CN108667608A (en) * 2017-03-28 2018-10-16 阿里巴巴集团控股有限公司 The guard method of data key, device and system
CN108111506A (en) * 2017-12-18 2018-06-01 深圳市恒达移动互联科技有限公司 VOIP encryption call methods and terminal

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
陈红松;沈强磊;: "云计算环境下支持高效撤销的新型属性基加密方案", 北京邮电大学学报, no. 03 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022000223A1 (en) * 2020-06-30 2022-01-06 浙江大学 Kernel sensitive data protection method based on custom hardware security attribute

Also Published As

Publication number Publication date
CN111105777B (en) 2023-10-31

Similar Documents

Publication Publication Date Title
CN110099064B (en) File processing method, device, equipment and storage medium based on Internet of things
CN111143869B (en) Application package processing method and device, electronic equipment and storage medium
US11770370B2 (en) System and method for transferring data
US11979498B2 (en) System and method for securely transferring data using generated encryption keys
US11012722B2 (en) System and method for securely transferring data
US9787479B2 (en) Challenge-response method and associated client device
CN113395406B (en) Encryption authentication method and system based on power equipment fingerprint
CN103516524A (en) Security authentication method and system
CN108170461B (en) Differential upgrade package generation method, differential upgrade method and device
CN108431819B (en) Method and system for protecting client access to service of DRM agent of video player
CN114499892B (en) Firmware starting method and device, computer equipment and readable storage medium
CN114244508A (en) Data encryption method, device, equipment and storage medium
JPH1131105A (en) Device and method for producing data capsule
CN114745373A (en) File transmission method, device, equipment and storage medium
CN109960935B (en) Method, device and storage medium for determining trusted state of TPM (trusted platform Module)
CN111105777B (en) Voice data acquisition and playing method and device, key package updating method and device and storage medium
CN113127844A (en) Variable access method, device, system, equipment and medium
CN109286495B (en) DCP public key protection method and device and HDCP equipment
CN110912941A (en) Transmission processing method and device for multicast data
CN109872136B (en) Upgrading method and system for isolated digital wallet, cold wallet and hot wallet
US11321323B2 (en) Method and system for searching for at least a specific datum in a user unit
CN114791834B (en) Application program starting method and device, electronic equipment and storage medium
WO2019136736A1 (en) Software encryption terminal, payment terminal, and software package encryption and decryption method and system
WO2023169409A1 (en) Model invoking method and apparatus, and storage medium
CN116938467A (en) Communication method, system, device and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant