WO2018086279A1 - 一种消息推送方法及终端 - Google Patents

一种消息推送方法及终端 Download PDF

Info

Publication number
WO2018086279A1
WO2018086279A1 PCT/CN2017/075196 CN2017075196W WO2018086279A1 WO 2018086279 A1 WO2018086279 A1 WO 2018086279A1 CN 2017075196 W CN2017075196 W CN 2017075196W WO 2018086279 A1 WO2018086279 A1 WO 2018086279A1
Authority
WO
WIPO (PCT)
Prior art keywords
push
client
push client
message
terminal
Prior art date
Application number
PCT/CN2017/075196
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 华为技术有限公司
Priority to CN201780009070.5A priority Critical patent/CN108605046B/zh
Priority to EP17868863.6A priority patent/EP3447992B1/en
Priority to US16/301,679 priority patent/US11258871B2/en
Publication of WO2018086279A1 publication Critical patent/WO2018086279A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1859—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels
    • 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/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • 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/40—Network security protocols

Definitions

  • the present application relates to the field of electronic technologies, and in particular, to a message push method and a terminal.
  • Push refers to a type of communication connection and message transmission between the server and the client.
  • the server can actively send the message content such as pictures or texts to the computer or the mobile terminal without the latter actively inquiring to the server.
  • the content pushed to the terminal by using the push service involves not only non-sensitive information such as advertisements and application update information, but also sensitive information such as transaction receipts, verification codes, and system configuration information.
  • non-sensitive information such as advertisements and application update information
  • sensitive information such as transaction receipts, verification codes, and system configuration information.
  • FIG. 1 and FIG. 2 there is currently transaction information pushed by a manufacturer to push a message to a user terminal.
  • some transmission encryption mechanisms are added in the existing push transmission process, which can reduce the risk of leakage of push data during transmission.
  • a problem with the prior art is that although the transmission security of the push message is guaranteed, after the push message arrives at the terminal, it is still possible to be acquired and utilized by the malicious program in the terminal to disclose the personal information of the user. Therefore, the existing push service can only guarantee the transmission security of the push message, but there is a security problem after the push message is sent to the terminal.
  • the technical problem to be solved by the embodiments of the present invention is to provide a message pushing method and a terminal, which can solve the problem of secure processing of push messages, thereby reducing the risk of leakage of push data.
  • the first aspect of the application provides a message pushing method.
  • the first push client receives the push message sent by the push server, where the push message includes a security level indicator and push data, and the first push client determines, according to the security level indicator, whether the push message needs to be processed, if not The push message needs to be processed, and the first push client forwards the push data to the second push client, and the second push client processes the push data.
  • the first push client is a push client in the first running environment of the terminal
  • the second push client is a push client in the second running environment of the terminal.
  • the first push client determines whether the push message needs to be processed according to the security level indication flag, and forwards to the second push client for processing when the push message processing is not needed, so that the terminal can be secure according to the security
  • the level indicator is used to differentiate the push messages of different security levels, so that the sensitive information with higher security level is processed securely, and the sensitive information with higher security level is prevented from leaking information during the processing of the terminal, so that the push can be solved.
  • the security of the message is handled.
  • the security level indicator includes a first security level flag or a second security level flag, where the first security level flag is used to indicate that the push data is represented by a REE session key Encryption; the second security level flag is used to indicate that the push data is encrypted by a trusted execution environment TEE session key.
  • the push server encrypts the push data according to the security level indicator, so that the push data can only be decrypted by the push client having the corresponding security level processing authority, and the sensitive information with higher security level is avoided in the terminal.
  • the information leakage occurs during the processing, so that the security processing problem of the push message can be solved.
  • the operating environment is REE
  • the first push client is the push client in the REE of the terminal
  • the second running environment is TEE
  • the second push client is the push client in the TEE of the terminal
  • if the security level indicator If the first security level is marked, the first push client needs to process the push message; if the security level indicator is marked as the second security level mark, the first push client does not need to perform the push message deal with.
  • the push message marked with the security level indicator as the first security level flag is processed by the push client in the REE
  • the push message marked with the security level indicator as the second security level flag is processed by the push client in the TEE.
  • the push message with a higher security level is sent to the push client in the TEE to prevent the information leakage of the sensitive information with higher security level during the processing of the terminal, thereby solving the problem of secure processing of the push message.
  • the first push client forwards the push data to the second push client, and the second push client uses the TEE session The key decrypts the push data.
  • the TEE session key is the second push client and the push server is based on the second push client
  • the generated random number is determined by negotiation with the random number generated by the push server.
  • the first operating environment is a TEE
  • the first push client is a push client in the TEE of the terminal
  • the second operating environment is REE
  • the second push client is the push client in the REE of the terminal
  • if the security level indicator is marked as the first security level flag, the first push client does not need to process the push message
  • the indication mark is the second security level flag, and the first push client needs to process the push message.
  • the push message marked with the security level indicator as the first security level flag is processed by the push client in the REE
  • the push message marked with the security level indicator as the second security level flag is processed by the push client in the TEE.
  • the push message with a higher security level is sent to the push client in the TEE to prevent the information leakage of the sensitive information with higher security level during the processing of the terminal, thereby solving the problem of secure processing of the push message.
  • the first push client forwards the push data to the second push client, and the second push client uses the REE session The key decrypts the push data.
  • the REE session key is the first push client and the push server according to the first push client
  • the generated random number is negotiated with the random number generated by the push server and sent to the second push client.
  • the first push client determines that the push message needs to be processed, the first push client The terminal decrypts the push data using the TEE session key and calls the trusted user interface TUI to display the decrypted push data or save the decrypted push data in the trusted storage space.
  • the push message is generated by encrypting the TEE session key.
  • the first operating environment is a TEE
  • the first push client is a push client in the TEE of the terminal
  • the second operating environment is REE
  • the second push client is the push client in the REE of the terminal
  • the first push client decrypts the push message using the preset TEE session key to obtain the push data
  • the first push client pushes the client to the second The terminal forwards the push data.
  • the push server encrypts the push messages of different security levels by using the TEE session key, and can only be decrypted by the push client in the TEE, and is sent to the corresponding push client according to the security level of the push data after decryption.
  • the processing is performed to prevent the sensitive information of the security level from being leaked during the processing of the REE of the terminal, thereby solving the problem of secure processing of the push message.
  • the TEE session key is a random generated by the first push client and the push server according to the first push client The number is determined by negotiation with the random number generated by the push server.
  • the first operating environment is REE
  • the first push client is a push client in the REE of the terminal
  • the second operating environment is a TEE
  • the second push client is a push client in the terminal's TEE; if the first push client cannot decrypt the push message to obtain the security level indicator, the first push client does not need to push The message is processed.
  • the push server encrypts the push messages of different security levels by using the TEE session key, and can only be decrypted by the push client in the TEE, and is sent to the corresponding push client according to the security level of the push data after decryption.
  • the processing is performed to prevent the sensitive information of the security level from being leaked during the processing of the REE of the terminal, thereby solving the problem of secure processing of the push message.
  • the first push client forwards the push message to the second push client, and the second push client uses The TEE session key decrypts the push message.
  • the push data includes a device wakeup indication
  • the first push client forwards the device wakeup indication to the second push client
  • the second push client decrypts the device wakeup indication by using the TEE session key, and establishes a connection with the second device corresponding to the device wakeup indication according to the device wakeup indication.
  • the terminal processes the device wake-up indication as a higher-level push data in the push client in the TEE, so that the push client in the TEE can indicate the second device associated with the terminal according to the device wake-up indication.
  • a connection is established to ensure that the push server sends the push data to the second device through the push client in the TEE, so as to prevent information leakage of the related push data of the second device during the processing of the terminal, thereby solving the problem of secure processing of the push message.
  • the pushing data includes a device wakeup indication, if the first push client needs to perform the push message
  • the first push client decrypts the device wakeup indication by using the TEE session key, and establishes a connection with the second device corresponding to the device wakeup indication according to the device wakeup indication.
  • the push message further includes a push object identifier, and the first push client The push data and the push object identifier are forwarded to the second push client, and the second push client sends the push data to the target application indicated by the push object identifier.
  • the second push client sends the push data to the second terminal associated with the terminal indicated by the push object identifier The target application on the device.
  • a second aspect of the present application provides a message push method.
  • the first push client receives the push message sent by the push server, where the push message includes a security level indicator and push data, and the first push client determines, according to the security level indicator, whether the push message needs to be processed, if not The push message needs to be processed, and the first push client forwards the push data to the second push client, and the second push client processes the push data.
  • the first push client is a push client in the first running environment of the terminal
  • the second push client is a push client in the second running environment of the terminal.
  • the first push client determines whether the push message needs to be processed according to the security level indication flag, and forwards to the second push client for processing when the push message processing is not needed, so that the terminal can be secure according to the security
  • the level indicator is used to differentiate the push messages of different security levels, so that the sensitive information with higher security level is processed securely, and the sensitive information with higher security level is prevented from leaking information during the processing of the terminal, so that the push can be solved.
  • the security of the message is handled.
  • a third aspect of the present application provides a terminal.
  • the terminal includes a first push client and a second push client.
  • the first push client includes a first transceiver module and a first processing module
  • the second push client includes a second transceiver module and a second processing module.
  • the module implements some or all of the methods of the first aspect and the second aspect.
  • the terminal includes a processor, a memory, and a network interface.
  • the processor is coupled to the memory and network interface, for example, the processor can be coupled to the memory and network interface via a bus.
  • the network interface is used to send and receive messages related to the above methods with the push server.
  • the memory is used to store push messages.
  • the processor is configured to perform some or all of the processes of the first aspect and the second aspect.
  • FIG. 1 is a diagram showing an example of pushing a transaction information provided by a prior art solution
  • FIG. 2 is a diagram showing an example of pushing of another transaction information provided by the prior art solution
  • FIG. 3 is a schematic diagram of a push service architecture in an embodiment of the present application.
  • 4a is a schematic flowchart of a message pushing method in an embodiment of the present application.
  • 4b is a schematic flowchart diagram of another message pushing method in the embodiment of the present application.
  • FIG. 5 is a schematic flowchart of another message pushing method in the embodiment of the present application.
  • FIG. 5b is a schematic flowchart of another message pushing method in the embodiment of the present application.
  • FIG. 6 is a schematic flowchart of a message pushing method of a terminal-based associated device according to an embodiment of the present application.
  • 6b is a schematic flowchart of a message pushing method of another terminal-based associated device in the embodiment of the present application.
  • FIG. 7 is a schematic flowchart of a message pushing method of another terminal-based associated device in the embodiment of the present application.
  • FIG. 7b is a schematic flowchart of a message pushing method of another terminal-based associated device in the embodiment of the present application.
  • FIG. 8 is a schematic flowchart of a key negotiation method in an embodiment of the present application.
  • FIG. 8b is a schematic flowchart of another key negotiation method in the embodiment of the present application.
  • FIG. 9 is a schematic flowchart of a method for registering a terminal application in an embodiment of the present application.
  • FIG. 10 is a schematic structural diagram of a terminal in an embodiment of the present application.
  • FIG. 11 is a schematic structural diagram of another terminal in the embodiment of the present application.
  • the technical solution of the embodiment of the present application is applicable to various push service-based system architectures, such as a push service architecture diagram shown in FIG. 3, including a terminal 101, a push server 102, and at least one application server 103 (shown in FIG. 3).
  • the application server 103a and the application server 103b) are out, wherein the terminal 101 internally includes at least one application client 1011 (the client 1011a and the client 1011b are shown in FIG. 3) and a push client 1012, wherein the application client 1011 and the application
  • the servers 103 correspond to each other, that is, the application client 1011 and the application server 103 are all directed to the same application.
  • the push client 1012 is composed of two entities: a push client 1012a running in a rich execution environment (REE, Rich Execution Environment) of the terminal, and a trusted execution environment (TEE, Trusted Execution Environment) running in the terminal.
  • Push client 1012b wherein the push client 1012a in the rich execution environment and the push client 1012b in the trusted execution environment are connected through a secure channel, for example, a possible secure channel implementation is TEE push
  • the client provides a client API (standard TEE Client API) interface to the REE push client, and the REE push client communicates with the TEE push client by calling the client API.
  • client API standard TEE Client API
  • the rich execution environment REE generally refers to an operating environment that does not have a specific security function.
  • the trusted execution environment TEE is an operating environment coexisting with the rich execution environment REE in the terminal, and can provide a secure application against the software attack for the trusted application.
  • Operating environment. TEE has a CPU core isolated from REE.
  • the CPU core of TEE can be a core that is physically isolated from REE or virtualized from REE.
  • TEE has a storage space that is invisible to REE and realized by secure storage technology. Therefore, TEE can Ensuring that assets in their storage (such as keys, data, software, etc.) are protected from software attacks against certain types of security threats.
  • FIG. 4a and 4b are schematic flowcharts of two message pushing methods in the embodiment of the present application.
  • the first push client is the push client in the terminal's REE
  • the second push client is the push client in the terminal's TEE.
  • the first push client is a push client in the terminal's TEE
  • the second push client is a push client in the terminal's REE.
  • Specific methods include:
  • Step S401 The first application server sends an application push message to the push server, where the application push message carries the push data and the push object identifier.
  • the application push message carries the push data and the push object identifier, that is, the first application server wants to send the push data to the first application in the terminal corresponding to the push object identifier.
  • the push object identifier herein may be a terminal application identifier stored in a push service list of the first application server. That is, the push object identifier is a terminal application identifier in the push service list of the first application server.
  • Step S402 The push server sets a security level indication flag according to the application push message, and determines a preset key to encrypt the push data to generate a push message.
  • the push server can set a security level index for the push message corresponding to the application push message according to the application push message.
  • a flag is displayed, and a key corresponding to the set security level flag is determined, thereby encrypting the push data, and finally generating a push message carrying the security level indication flag and the push data.
  • the security level indicator may include a first security level flag and a second security level flag, wherein the first security level flag indicates a lower security level or a normal security level of push Data, the terminal does not need to perform security processing after receiving, and the second security level flag indicates the push data of a higher security level or a special security level, and the terminal needs to use the TEE for secure processing.
  • the application push message sent by the first application server may carry a security processing indication label to instruct the push server to set the security level indicator of the push message to the second security.
  • the level flag if the application push message sent by the first application server does not carry the security processing indication label, the push server may set the security level indication flag of the push message to the first security level flag.
  • the push server may analyze the application push message sent by the first application server, and determine the push message according to the message feature indicator of the content, data type, priority, and emergency type of the application push message. Security level indicator.
  • the security level indicator here may be added to the message header of the push message, that is, the fixed length byte in the message header occupying the push message.
  • the push server may also encrypt the security level indication mark by using a key corresponding to the key held by the push client that receives the push message, or may not encrypt, and is not specifically limited herein.
  • the security level indicator may be encrypted by using a REE session key generated in advance, if the receiving client of the push message is a push in the TEE The client can encrypt the security level indicator using the pre-negotiated TEE session key.
  • the push data contained in the push message is encrypted and the encrypted key has a correspondence with the security level indicator.
  • the push server sets the security level indicator to the first security level flag
  • the push data included in the push message is generated by the REE session key encryption
  • the push server sets the security level indicator to the second security level flag.
  • the push data contained in the push message is encrypted by the TEE session key, it is generated.
  • Step S403 the push server sends a push message to the first push client.
  • the push server may determine the terminal corresponding to the push object identifier, and send a push message to the first push client in the terminal.
  • the first push client is a push client in the terminal's REE environment
  • the second push client is a push client in the terminal's TEE.
  • the first push client can access the network communication interface to receive the push message sent by the push server, and the second push client cannot directly access the network communication interface, and the first push client needs to receive the push message.
  • the first push client is a push client in the TEE of the terminal.
  • the first push client has the network communication interface access capability and can directly communicate with the push server.
  • Step S404 the first push client determines whether the push message needs to be processed according to the security level indication flag.
  • the first push client may first decrypt the encrypted security level indicator using the REE session key, and then according to the security level. Do not indicate the flag to determine whether the received push message should be processed by the local end.
  • the first push client may first decrypt the encrypted security level indicator using the TEE session key, and then according to the security level indication. Mark to determine whether the received push message should be processed by the local end.
  • step S404 may include step S4041:
  • Step S4041 If the security level indication flag is the first security level flag, the first push client needs to process the push message, and step S405 is performed; if the security level indication flag is the second security level flag, the first push client Steps S406 to S407 are executed without processing the push message.
  • the security level indicator is marked as the first security level flag, indicating that the push message has a lower security level and can be processed in the REE, so the first push client can directly process the push message; the security level indicator is marked as the second security level.
  • the flag indicates that the push message has a high security level and needs to be processed in the TEE, so the first push client does not need to process the push message.
  • step S404 may include step S4042:
  • Step S4042 If the security level indication flag is the first security level flag, the first push client does not need to process the push message, and steps S408-S409 are performed; if the security level indication flag is the second security level flag, the first The push client needs to process the push message, and step S410 is performed.
  • the security level indicator is marked as the first security level flag, indicating that the push message has a lower security level and can be processed in the REE, so the first push client does not need to process the push message; the security level indicator is marked as the second security level.
  • the flag indicates that the push message has a high security level and needs to be processed in the TEE, so the first push client needs to process the push message.
  • Step S405 the first push client decrypts the push data by using a preset REE session key, and processes the decrypted push data.
  • the push server Since the push server encrypts the push data for the first security level tag using the REE session key, the first push client pushes the REE session key pair previously received from the second push client in the key negotiation phase. The data can be decrypted.
  • the first push client may instruct the operating system of the terminal to process the decrypted push data; in another possible implementation scenario, the push server is directed to the first
  • the push message sent by the push client may further include a push object identifier, so that the first push client may send the decrypted push data to the target application indicated by the push object identifier or the REE application part corresponding to the target application, thereby
  • the decrypted push data is processed by the REE application portion of the target application or the target application.
  • the target application may refer to the first application served by the first application server.
  • Step S406 the first push client forwards the push data to the second push client.
  • the first push client does not need to process the push message, and then forwards the push data to the second push client for processing.
  • the push data may be sent to the second push client only, or the push message may be sent to the second push client as a whole, which is not specifically limited.
  • Step S407 the second push client decrypts the push data by using a preset TEE session key, and processes the decrypted push data.
  • the push server uses the TEE session key encryption for the push data of the second security level flag, Therefore, the second push client decrypts the push data using the TEE session key generated in the key agreement phase.
  • the second push client may instruct the TEE to call the Trusted User Interface (TUI) to display the decrypted push data or save the decrypted push data in the trusted storage space;
  • the push message sent by the push server to the first push client may further include a push object identifier, and the first push client also carries the push object identifier when sending the push data to the second push client. Therefore, the second push client can send the decrypted push data to the TEE application part corresponding to the target application indicated by the push object identifier, so that the TEE application part of the target application processes the decrypted push data.
  • the target application may refer to the first application served by the first application server.
  • Step S408 the first push client forwards the push data to the second push client.
  • the first push client does not need to process the push message, and then forwards the encrypted push data to the second push client for processing.
  • the push data may be sent to the second push client only, or the push message may be sent to the second push client as a whole, which is not specifically limited.
  • Step S409 the second push client decrypts the push data using the preset REE session key and processes the decrypted push data.
  • the push server Since the push server encrypts the push data for the first security level tag using the REE session key, the second push client pushes the REE session key pair previously received from the first push client in the key negotiation phase. The data can be decrypted.
  • the second push client may instruct the operating system of the terminal to process the decrypted push data; in another possible implementation scenario, the push server is directed to
  • the push message sent by the push client may further include a push object identifier, and the first push client also carries the push object identifier when sending the push data to the second push client, so that the first push client can send the decrypted push data.
  • the REE application part corresponding to the target application or the target application indicated by the push object identifier is sent, so that the target application or the REE application part of the target application processes the decrypted push data.
  • the target application may refer to the first application served by the first application server.
  • Step S410 the first push client decrypts the push data and processes the decrypted push data by using a preset TEE session key.
  • the first push client decrypts the push data using the TEE session key generated in the key agreement phase.
  • the first push client may instruct the TEE to call the Trusted User Interface (TUI) to display the decrypted push data or save the decrypted push data in the trusted storage space;
  • the push message sent by the push server to the first push client may further include a push object identifier, so that the first push client may send the decrypted push data to the push object identifier.
  • the TEE application part corresponding to the target application causes the TEE application part of the target application to process the decrypted push data.
  • the target application may refer to the first application served by the first application server.
  • the embodiment shown in FIG. 4a and FIG. 4b encrypts the push data of different security levels by using different session keys, and sends the data according to the security level of the push data to the corresponding push client for processing, thereby avoiding a higher security level.
  • the sensitive information is leaked during the processing of the terminal, so that the security processing problem of the push message can be solved.
  • FIG. 5a and 5b are schematic flowcharts of two message pushing methods in the embodiment of the present application.
  • the first push client is a push client in the terminal's REE
  • the second push client is a push client in the terminal's TEE
  • the first push client is a push client in the terminal's TEE
  • the second push client is a push client in the terminal's REE.
  • Specific methods include:
  • Step S501 The first application server sends an application push message to the push client, where the application push message carries the push data and the push object identifier.
  • Step S502 The push server sets a security level indication flag according to the application push message, generates a push message according to the security level indication mark and the push data, and encrypts the push message by using a preset TEE session key.
  • the push server may set a security level indicator for the push message corresponding to the application push message according to the application push message, and finally generate a push message carrying the security level indication mark and the push data.
  • the security level indicator may include a first security level flag and a second security level flag, wherein the first security level flag indicates a lower security level or a normal security level of push Data, the second security level flag indicates push data for a higher security level or a special security level.
  • the push message after the push server generates the push message, the push message can be encrypted using the pre-negotiated generated TEE session key. Therefore, the push message sent by the push server is encrypted as a whole, and the push message includes push data and a security level indication identifier.
  • the push data refers to unencrypted push data.
  • the application push message sent by the first application server may carry a security processing indication label to instruct the push server to set the security level indicator of the push message to the second security.
  • the level flag if the application push message sent by the first application server does not carry the security processing indication label, the push server may set the security level indication flag of the push message to the first security level flag.
  • the push server may analyze the application push message sent by the first application server, and determine the push message according to the message feature indicator of the content, data type, priority, and emergency type of the application push message. Security level indicator.
  • the security level indicator here may be added to the message header of the push message, that is, the fixed length byte in the message header occupying the push message.
  • step S503 the push server sends a push message to the first push client.
  • the push server may determine the terminal corresponding to the push object identifier, and send a push message to the first push client in the terminal.
  • the first push client is a push client in the terminal's REE
  • the second push client is a push client in the terminal's TEE.
  • the first push client can access the network communication interface to receive the push message sent by the push server, and the second push client cannot access the network communication interface, and the first push client needs to receive the push message.
  • the first push client is a push client in the TEE of the terminal.
  • the first push client has the network communication interface access capability and can directly communicate with the push server.
  • Step S504 the first push client determines whether the security level indication flag can be obtained by decrypting from the push message.
  • step S504 may include step S5041:
  • Step S5041 When the first push client cannot decrypt from the push message to obtain the security level indication mark, the first The push client does not need to process the push message, and steps S505 to S510 are performed.
  • the first push client needs to parse the push message to obtain the security level indicator when receiving the push message.
  • the first push client cannot parse the security level indicator in the get push message, the first push client does not need to The push message is processed.
  • the related key is not stored in the first push client, and when the push message is received, it can be directly determined that the security level indicator cannot be decrypted from the push message, and the Pushing the message for processing, performing steps S505-S510; in another possible implementation scenario, the first push client may store other keys, and when the push message is received, the push message may be decrypted, because the push server The sent push message is encrypted by the TEE session key, and the first push client does not have the TEE session key, and the push data cannot be decrypted, so the security level indicator cannot be obtained from the push message, and the push message is not needed. Processing is performed, and steps S505 to S510 are executed.
  • step S504 may include step S5042:
  • Step S5042 When the first push client successfully decrypts and obtains the security level indication flag from the push message, steps S511 to S514 are performed.
  • the push message sent by the push server is encrypted by the TEE session key
  • the first push client has the TEE session key, so the push message can be decrypted to obtain the security level indication flag and the push data, and steps S511-514 are performed.
  • Step S505 the first push client forwards the push message to the second push client.
  • the first push client does not need to process the push message, and then forwards the push message to the second push client.
  • Step S506 the second push client decrypts the push message by using a preset TEE session key.
  • the second push client decrypts the push message using the TEE session key generated in the key negotiation phase, and the push data in the push message can be obtained. .
  • step S507 the second push client determines whether the push message needs to be processed according to the security level indication flag. If the security level indicator is marked as the first security level flag, the second push client does not need to process the push message, and steps S508-S509 are performed; if the security level indicator is marked as the second security level flag, the second push client If the push message needs to be processed, step S510 is performed.
  • Step S508 the second push client forwards the push data to the first push client.
  • step S509 the first push client processes the push data.
  • the first operating system may instruct the operating system of the terminal to process the push data; in another possible implementation scenario, the push server sends the message to the first push client.
  • the push message may further include a push object identifier, so that the first push client may send the push data to the target application indicated by the push object identifier or the REE application portion corresponding to the target application, thereby making the target application or the target application
  • the REE application section processes the decrypted push data.
  • step S510 the second push client processes the push data.
  • the second push client may instruct the TEE to call the Trusted User Interface (TUI) to display the push data or save the push data in the trusted storage space; in another possible
  • the push message sent by the push server to the first push client may further include a push target identifier.
  • the first push client also carries the push object identifier when forwarding the push message to the second push client, so that the second push client can send the push data to the TEE application part corresponding to the target application indicated by the push object identifier, so that The TEE application part of the target application handles the push data.
  • step S511 the first push client determines whether the push message needs to be processed according to the security level indication flag. If the security level indicator is marked as the first security level flag, the first push client does not need to process the push message, and steps S512-S513 are performed; if the security level indicator is marked as the second security level flag, the first push client If the push message needs to be processed, the first push client processes the push message, and then step S514 is performed.
  • Step S512 the first push client forwards the push data to the second push client.
  • step S513 the second push client processes the push data.
  • the second push client may instruct the operating system of the terminal to process the push data after decrypting the push message to obtain the push data; in another possible implementation scenario, the push server pushes the client to the first
  • the push message sent by the terminal may further include a push object identifier, and the first push client also carries the push object identifier when forwarding the push data to the second push client, so that the second push client may send the push data to the push object identifier indication.
  • the target application or the REE application part of the target application so that the REE application part of the target application or the target application processes the push data.
  • step S514 the first push client processes the push data.
  • the first push client may instruct the TEE to call the Trusted User Interface (TUI) to display the push data or save the push data in the trusted storage space; in another possible
  • the push message sent by the push server to the first push client may further include a push object identifier, so that the first push client may send the push data to the TEE application part corresponding to the target application indicated by the push object identifier.
  • the TEE application part of the target application handles the push data.
  • the push messages of different security levels are encrypted by using the TEE session key, and are uniformly decrypted by the push client in the TEE, and sent to the corresponding push according to the security level of the push data.
  • the client processes the information to prevent the sensitive information of the security level from being leaked during the processing of the REE of the terminal, thereby solving the problem of secure processing of the push message.
  • FIG. 6a and 6b are schematic flowcharts of a message pushing method of two terminal-based associated devices in the embodiment of the present application.
  • the first push client is a push client in the terminal's REE
  • the second push client is a push client in the terminal's TEE
  • the first push client is a push client in the terminal's TEE
  • the second push client is a push client in the terminal's REE.
  • Specific methods include:
  • Step S601 The first application server sends an application push message to the push client, where the application push message carries the push data and the push object identifier.
  • the application push message carries the push data and the push object identifier, that is, the first application server wants to send the push data to the terminal corresponding to the push object identifier.
  • the application push message may include a second device security processing tag, the second device security processing tag is used to indicate that the push data in the application push message is used by the second device associated with the terminal. deal with.
  • the push object identifier here may include a terminal identifier and a second device identifier.
  • Step S602 the push server caches the push data according to the application push message, and sets a security level indication mark.
  • a device wake-up indication is generated and a predetermined key is determined to encrypt the device wake-up indication to generate a push message.
  • the push server when the push server receives the push message including the second device security processing tag, the push server may first cache the push data and set the security level indicator to the second security level flag.
  • the second security level flag may indicate push data for the second device associated with the terminal.
  • the push server may further generate a device wakeup indication, and encrypt the device wakeup indication by using a pre-negotiated TEE session key, where the device wakeup indication includes the identifier of the second device associated with the terminal, and It may include actions that the terminal is required to perform, such as scanning the device through the Bluetooth interface and establishing a Bluetooth connection with the device.
  • the push server can generate a push message, in this embodiment, the push message includes a device wakeup indication and a second security level flag.
  • the device wakeup indication contained in the push message is encrypted by the TEE session key.
  • step S603 the push server sends a push message to the first push client.
  • the first push client is the push client in the terminal's REE
  • the second push client is the push client in the terminal's TEE.
  • the first push client can access the network communication interface to receive the push message sent by the push server, and the second push client cannot access the network communication interface, and the first push client needs to receive the push message.
  • the first push client is a push client in the TEE of the terminal.
  • the first push client has the network communication interface access capability and can directly communicate with the push server.
  • Step S604 the first push client determines whether the push message needs to be processed according to the security level indication flag.
  • step S604 may include step S6041:
  • Step S6041 If the security level indication flag is the second security level flag, the first push client does not need to process the push message, and steps S605 to S608 are performed.
  • step S604 may include step S6042:
  • Step S6042 If the security level indication flag is the second security level flag, the first push client needs to process the push message, and steps S609 to S611 are performed.
  • Step S605 the first push client sends a device wakeup indication to the second push client.
  • the first push client does not need to process the push message, and then forwards the device wakeup instruction to the second push client for processing. It should be noted that, in this case, only the device wake-up indication may be sent to the second push client, and the push message may be sent to the second push client as a whole, which is not specifically limited herein.
  • Step S606 The second push client decrypts the device wakeup indication by using a preset TEE session key, and scans the second device associated with the terminal according to the device wakeup indication.
  • the second push client decrypts the device wakeup indication using the TEE session key generated in the key agreement phase.
  • the second push client invokes a Bluetooth Low Energy Global Platform Service (BLE GP Service) interface, and the second device can be scanned according to the device wake-up instruction.
  • BLE GP Service Bluetooth Low Energy Global Platform Service
  • the second device may refer to a wearable device or an Internet of Things device or the like.
  • Step S607 The second push client establishes a connection with the second device associated with the terminal, and notifies the push server.
  • Step S608 the push server sends the cached push data to the second device by using the second push client.
  • the push object identifier may be carried, so that the second push client may send the push data to the target application on the second device associated with the terminal indicated by the push object identifier, thereby achieving the target.
  • the application can process the push data.
  • Step S609 The first push client decrypts the device wakeup indication by using a preset TEE session key, and scans the second device associated with the terminal according to the device wakeup indication.
  • Step S610 The first push client establishes a connection with the second device associated with the terminal, and notifies the push server.
  • Step S611 the push server sends the cached push data to the second device by using the first push client.
  • the device wake-up indication is used as a higher-level push data, which is processed by the push client in the TEE, so that the push client in the TEE can follow the device wake-up instruction and the terminal.
  • the associated second device establishes a connection, and ensures that the push server sends the push data to the second device through the push client in the TEE, so as to prevent information leakage of the related push data of the second device during the processing of the terminal, thereby solving the push message. Handle security issues.
  • FIG. 7a and 7b are schematic flowcharts of a message pushing method of two terminal-based associated devices in the embodiment of the present application.
  • the first push client is a push client in the terminal's REE
  • the second push client is a push client in the terminal's TEE
  • the first push client is a push client in the terminal's TEE
  • the second push client is a push client in the terminal's REE.
  • Specific methods include:
  • Step S701 The first application server sends an application push message to the push client, where the application push message carries the push data and the push object identifier.
  • Step S702 The push server caches the push data according to the application push message, sets a security level indication flag, generates a device wakeup indication, generates a push message according to the device wakeup indication and the security level indication mark, and uses the preset TEE session key pair to push the message. Encrypt.
  • the push server when the push server receives the push message including the second device security processing tag, the push server may first cache the push data and set the security level indicator to the second security level flag.
  • the second security level tag may indicate push data for the second device associated with the terminal.
  • the push server may further generate a device wakeup indication and generate a push message by using the device wakeup indication and the security level indicator.
  • the push message can be encrypted using the pre-negotiated TEE session key.
  • the push message sent by the push server is encrypted, and the push message includes a device wake-up indication and a second security level flag.
  • the device wake-up indication is an unencrypted device wake-up indication.
  • Step S703 the push server sends a push message to the first push client.
  • Step S704 the first push client determines whether the security level indication mark can be obtained by decrypting from the push message.
  • step S704 may include step S7041:
  • step S7041 when the first push client cannot decrypt the security level indication mark from the push message, the first push client does not need to process the push message, and steps S705-S708 are performed.
  • the first push client needs to parse the push message to obtain the security level indication mark when receiving the push message, and the first push client when the first push client cannot parse the security level indicator in the get push message.
  • the push message does not need to be processed at the end.
  • the related key is not stored in the first push client, and when the push message is received, it can be directly determined that the security level indicator cannot be decrypted from the push message, and the Pushing the message for processing, performing steps S705-S708; in another possible implementation scenario, the first push client may store other keys, and when the push message is received, the push message may be decrypted, because the push server
  • the sent push message is encrypted by the TEE session key, and the first push client does not have the TEE session key, and the encrypted push data cannot be decrypted, so the security level indicator cannot be obtained from the push message, and no The push message is processed, and steps S705 to S708 are executed.
  • step S704 may include step S7042:
  • Step S7042 When the first push client successfully decrypts and obtains the security level indication flag from the push message, steps S709-S711 are performed.
  • the push message sent by the push server is encrypted by the TEE session key
  • the first push client has a TEE session key, and the push message can be decrypted, and steps S709-711 are performed.
  • Step S705 the first push client forwards the push message to the second push client.
  • the first push client does not need to process the push message, and then forwards the push message to the second push client for processing.
  • Step S706 The second push client decrypts the push message by using a preset TEE session key, and determines to process the push message according to the security level indication flag and scan the second device associated with the terminal according to the device wakeup indication.
  • the second push client decrypts the push message using the TEE session key generated during the key negotiation phase to obtain the push.
  • the device wakes up indication in the message.
  • the Bluetooth Low Energy Global Platform Service interface can scan the second device according to the push object identifier, where the second device can be a wearable device or an Internet of Things device or the like.
  • Step S707 The second push client establishes a connection with the second device associated with the terminal, and notifies the push server.
  • Step S708 the push server sends the cached push data to the second device by using the second push client.
  • the push object identifier may be carried, so that the second push client may send the push data to the target application on the second device associated with the terminal indicated by the push object identifier, thereby achieving the target.
  • the application can process the push data.
  • Step S709 the first push client determines to process the push message according to the security level indication flag, and scans the second device associated with the terminal according to the device wake-up indication.
  • Step S710 The first push client establishes a connection with the second device associated with the terminal, and notifies the push server.
  • Step S711 The push server sends the cached push data to the second device by using the first push client.
  • the device wake-up indication is processed as a higher-level push data in the push client in the TEE so that the push client in the TEE can associate with the terminal according to the device wake-up indication.
  • the second device establishes a connection, and ensures that the push server sends the push data to the second device through the push client in the TEE, thereby preventing information leakage of the related push data of the second device during the processing of the terminal, thereby solving the push The security of the message is handled.
  • Figures 8a and 8b are detailed descriptions of the key negotiation phase process referred to in the embodiment of Figures 4a-7b, namely how to generate a TEE session key or/and a REE session key and how to save the session key in the first A process in the push client or / second push client.
  • FIG. 8a and 8b are schematic flowcharts of two key negotiation methods in the embodiment of the present application.
  • encryption is required to ensure the transmission of push data is secure. Therefore, before the push server sends a push message to the push client of the terminal, the encryption key needs to be negotiated.
  • the key negotiation process in the embodiment of the present application occurs in the process of the connection between the push client and the push server after the terminal is started.
  • the first push client is the push client in the terminal's REE
  • the second push client is the push client in the terminal's TEE.
  • Specific methods include:
  • Step S801 the first push client sends a secure transport connection establishment request to the second push client.
  • the push client of the terminal needs to establish a connection with the push server to ensure that push data is received at any time.
  • the first push client may send a secure transport connection establishment request to the second push client, and the secure transport connection establishment request indicates that the terminal requests to establish a secure transport layer protocol (TLS) connection with the push server, thereby triggering the key negotiation process.
  • TLS secure transport layer protocol
  • the second push client can access the network communication interface and can directly communicate with the push server, and then perform the following steps S802-S810 or steps S802-805 and S811-S814.
  • Step S802 The second push client generates a first random number according to the secure transmission connection establishment request, and encrypts the first random number by using the first public key acquired in advance.
  • the second push client may generate a first random number and encrypt the first random number by using the pre-acquired first public key.
  • the first public key refers to the public key carried in the certificate of the push server.
  • the second push client may obtain the certificate of the push server in advance, and extract the public key in the certificate for encrypting the random number sent to the push server.
  • Step S803 the second push client sends the encrypted first random number, the signature of the first random number, and the terminal certificate to the push server.
  • the second push client After the second push client generates the encrypted first random number, the encrypted first random number, the signature of the first random number, and the certificate of the terminal itself may be sent to the push server.
  • the certificate of the terminal may be used by the push server to determine that the encrypted first random number is actually sent by the terminal.
  • the push server may use the certificate of the terminal to verify the signature of the first random number, and if the signature is correct, the first random number may be determined. It is indeed sent to the terminal and uses the public key in the terminal certificate to encrypt the second random number generated by the push server.
  • Step S804 the push server decrypts the encrypted first random number by using the first private key corresponding to the first public key to obtain the first random number, generates a second random number, and uses the second public key obtained from the terminal certificate.
  • the second random number is encrypted.
  • the push server decrypts the content encrypted by the push server public key (first public key) by using its private key (first private key); the terminal uses the private key corresponding to the certificate. (Second private key) Decrypts the content encrypted by the terminal certificate public key (second public key).
  • the push server decrypts the encrypted first random number by using the first private key corresponding to the first public key. And fetching the first random number, and further generating the second random number and encrypting the second random number by using the second public key obtained from the terminal certificate.
  • Step S805 the push server sends the encrypted second random number to the second push client.
  • TEE session key is stored in the trusted storage space of the TEE by the second push client
  • REE session key is stored in the storage space of the REE by the first push client.
  • Step S806 the second push client decrypts the encrypted second random number by using the second private key corresponding to the second public key to obtain the second random number, generates the third random number and the fourth random number, and uses the first public The key encrypts the third random number and the fourth random number.
  • the second push client decrypts the encrypted second random number by using the second private key corresponding to the second public key to obtain the second random number, and further generates the third random number and the fourth random number and utilizes the first public
  • the key encrypts the third random number and the fourth random number.
  • Step S807 the second push client sends the encrypted third random number and the fourth random number to the push server.
  • Step S808 The second push client generates a REE session key according to the decrypted first random number, the second random number, and the locally generated third random number, and obtains a first random number, a second random number, and a local number according to the decryption.
  • the generated fourth random number generates a TEE session key.
  • the second push client generates a REE session key according to the first random number, the second random number, and the third random number according to the pre-agreed or set encryption algorithm, according to the first random number, the second random number, and the fourth random number
  • the number generates a TEE session key.
  • the REE session key is a key that is saved and used by the first push client
  • the TEE session key is a key that is saved and used by the second push client.
  • Step S809 the push server generates a REE session key according to the decrypted first random number, the second random number, and the third random number, and generates a TEE session according to the decrypted first random number, the second random number, and the fourth random number. Key.
  • the push server generates a rich environment session key according to the first random number, the second random number, and the third random number according to a pre-agreed or set encryption algorithm, and generates according to the first random number, the second random number, and the fourth random number. Trusted environment session key.
  • step S808 and step S809 is the same algorithm.
  • the second push client may send the agreed encryption algorithm to the push server during the key negotiation process or before the key negotiation process. It is also possible to set an encryption algorithm between the second push client and the push server in advance.
  • Step S810 the second push client sends a REE session key to the first push client.
  • the first push client saves the REE session key for later use.
  • a key ie, a TEE session key
  • steps S811-814 are performed.
  • the TEE session key is stored by the second push client in the trusted storage space of the TEE.
  • Step S811 the second push client decrypts the encrypted second random number by using the second private key corresponding to the second public key to obtain the second random number, generates a third random number, and uses the first public key pair to perform the third random number.
  • the number is encrypted.
  • Step S812 the second push client sends the encrypted third random number to the push server.
  • Step S813 The second push client generates a TEE session key according to the decrypted first random number, the second random number, and the third random number.
  • Step S814 The push server generates a TEE session key according to the decrypted first random number, the second random number, and the third random number.
  • step S803 can include:
  • Step S8031 The second push client sends the encrypted first random number, the signature of the first random number, and the terminal certificate to the first push client.
  • Step S8032 The first push client sends the encrypted first random number, the signature of the first random number, and the terminal certificate to the push server.
  • Step S805 can include:
  • step S8051 the push server sends the encrypted second random number to the first push client.
  • Step S8052 the first push client sends the encrypted second random number to the second push client.
  • Step S807 can include:
  • Step S8071 The second push client sends the encrypted third random number and the fourth random number to the first push client.
  • Step S8072 the first push client sends the encrypted third random number and the fourth random number to the push server.
  • Step S812 can include:
  • Step S8121 The second push client sends the encrypted third random number to the first push client.
  • step S8122 the first push client sends the encrypted third random number to the push server.
  • FIG. 9 is a schematic flowchart of a terminal application registration method in an embodiment of the present application.
  • the terminal and an application running on the terminal need to be registered on the push server, so that the application can be pushed to the terminal later.
  • the program sends push data.
  • the first push client is a push client in the terminal's REE
  • the second push client is a push client in the terminal's TEE.
  • Specific methods include:
  • Step S901 The first application of the terminal sends a first registration request to the first push client, where the first registration request includes the first application identifier.
  • the terminal may send a first registration request to the first push client, where the first registration request includes the first application identifier, where the first application identifier is located. It may refer to the name of the first application or the application access interface, etc., and is not specifically limited herein.
  • the first registration request further includes a push message processing policy
  • the message processing policy may be used to indicate which processing method the second push client should execute after the subsequent push data is acquired.
  • the message processing policy may instruct the second push client to send the obtained push data to the trusted application part corresponding to the first application for display; the message processing policy may also indicate that the second push client is unified in the TEE
  • the TUI Trusted User Interface
  • the message processing policy may also instruct the second push client to pull up the device associated with it, such as a wearable device.
  • the terminal may also obtain an authorization code from the first application server corresponding to the first application for subsequent identity verification.
  • Step S902 the first push client sends a first registration request to the second push client.
  • Step S903 The second push client sends a second registration request to the push server according to the first registration request, where the second registration request includes the first application identifier and the terminal identifier.
  • the second push client may acquire the first application identifier and further add the terminal identifier, thereby generating a second registration request.
  • the terminal identifier may be a device identifier code or a REE identifier of the terminal.
  • the terminal identifier may also be a TEE identifier.
  • the second push client can add the TEE identifier as the terminal identifier and the acquired REE identifier of the first push client as the terminal identifier to the push server in the second registration request, that is, Corresponding to the push service of the two terminal execution environments in the push server.
  • Step S904 The push server generates a terminal application identifier according to the first application identifier and the terminal identifier.
  • the push server may associate the two to obtain a terminal application identifier related to the two, and the terminal application identifier may represent the first application of the current terminal that sends the first registration request.
  • the push server may first determine, according to the first application identifier, whether the push server subscribes to the first application server corresponding to the first application. Signing here may mean that the push server has the right to push the service for the first application server. If the contract has been signed, the terminal application identifier is generated.
  • Step S905 The push server sends the terminal application identifier to the first application.
  • Step S906 the first application sends the terminal application identifier and the authorization code acquired in advance from the first application server to the first application server corresponding to the first application.
  • Step S907 the first application server determines that the authorization code is legal and adds the terminal application identifier to the push service list.
  • the first application server After receiving the authorization code sent by the first application, the first application server first verifies its legality. If the verification succeeds, the received terminal application identifier may be added to the push service list.
  • the terminal application identifiers in the push service list are all terminals that can perform the push service.
  • the first application server performs the push, the first application server performs a push service to each terminal according to the terminal application identifier in the push service list.
  • the first application server may also associate the terminal application identifier with a specific user, that is, the user who successfully logs in to the first application.
  • the first application and the terminal where the first application is registered, the first application server and the push server may send a push message to the terminal where the first application is located.
  • FIG. 10 is a schematic structural diagram of a terminal according to an embodiment of the present application.
  • the terminal includes a first push client 10 and a second push client 20.
  • the first push client 10 includes a first transceiver module 101 and a first processing module 102
  • the second push client includes a second transceiver module 201 and a second processing module 202, wherein:
  • the first transceiver module 101 is configured to receive a push message sent by a push server, where the push message includes a security level indication mark and push data.
  • the first processing module 102 is configured to determine, according to the security level indication flag, whether the push message needs to be processed
  • the first transceiver module 101 is further configured to: when it is determined that the push message is not required to be processed, to the first The second transceiver module forwards the push data;
  • the second transceiver module 201 is configured to receive the push data.
  • the second processing module 202 is configured to process the push data.
  • the first push client is a push client in a first running environment of the terminal
  • the second push client is a push client in a second running environment of the terminal.
  • the security level indicator includes a first security level flag or a second security level flag, where the first security level flag is used to indicate that the push data is encrypted by a REE session key; the second security level A flag is used to indicate that the push data is encrypted by a trusted execution environment TEE session key.
  • the first operating environment is REE
  • the first push client 10 is a push client in the REE of the terminal
  • the second running environment is a TEE
  • the first The second push client 20 is a push client in the TEE of the terminal
  • the first processing module 102 is specifically configured to:
  • the first processing module 102 needs to process the push message; if the security level indication flag is the second security level flag, The first processing module 102 does not need to process the push message.
  • the second processing module 202 is specifically configured to:
  • the push data is decrypted using the TEE session key.
  • the TEE session key is determined by the second processing module 202 and the push server according to a random number generated by the second processing module and a random number generated by the push server.
  • the first operating environment is a TEE
  • the first push client 10 is a push client in a TEE of the terminal
  • the second running environment is REE
  • the second push client 20 is a push client in the REE of the terminal
  • the first processing module 102 is specifically configured to:
  • the first processing module 102 does not need to process the push message; if the security level indication flag is a second security level flag, then the A processing module 102 needs to process the push message.
  • the second processing module 202 is specifically configured to:
  • the push data is decrypted using the REE session key.
  • the REE session key is sent by the first processing module 102 and the push server according to the random number generated by the first processing module 102 and the random number generated by the push server.
  • the second transceiver module 201 is described.
  • the first processing module 102 is further configured to:
  • the push data is decrypted using the TEE session key and the trusted user interface TUI is invoked to display the decrypted push data or to save the decrypted push data to be trusted. In storage space.
  • the push message is generated by being encrypted by a TEE session key.
  • the first operating environment is a TEE
  • the first push client 10 is a push client in a TEE of the terminal
  • the second running environment is REE
  • Second push client 20 Pushing the client in the REE of the terminal
  • the first processing module 102 is further configured to:
  • the push message is decrypted using the TEE session key to obtain the push data.
  • the TEE session key is determined by the first processing module 102 and the push server according to a random number generated by the first processing module 102 and a random number generated by the push server.
  • the first operating environment is REE
  • the first push client 10 is a push client in the REE of the terminal
  • the second running environment is a TEE
  • the second push client 20 is a push client in the TEE of the terminal
  • the first processing module 102 is specifically configured to:
  • the push message need not be processed.
  • the second processing module 202 is specifically configured to:
  • the push message is decrypted using the TEE session key.
  • the push data includes a device wake-up indication
  • the first transceiver module 101 is specifically configured to:
  • the second processing module 202 is specifically configured to:
  • the push data includes a device wake-up indication
  • the first processing module 102 is further configured to:
  • the device wakeup indication is decrypted by using the TEE session key, and the second device corresponding to the device wakeup indication is established according to the device wakeup indication.
  • the push message further includes a push object identifier
  • the first transceiver module 101 is specifically configured to:
  • the second processing module 202 is further configured to:
  • the push data is sent to the target application indicated by the push object identifier.
  • the second processing module 202 is specifically configured to:
  • the terminal sends the push data in the push message to the corresponding push client for processing according to the security level corresponding to the push message, so as to prevent the sensitive information with higher security level from being sent during the processing of the terminal. Leakage, which can solve the security processing problem of push messages.
  • FIG. 11 is a schematic structural diagram of another terminal according to an embodiment of the present invention.
  • the terminal includes a processor 111, a memory 112, and a communication interface 113.
  • the processor 111 is coupled to the memory 112 and the communication interface 113, such as the processor 111 It can be connected to the memory 112 and the communication interface 113 through a bus.
  • the processor 111 is configured to implement the functions of the first processing module 102 and the second processing module 202 shown in FIG.
  • the communication interface 113 is used to implement the functions of the first transceiver module 101 and the second transceiver module 201 shown in FIG.
  • the processor 111 is configured to support the terminal to perform a corresponding function in the message pushing method.
  • the processor 111 can be a central processing unit (CPU), a network processor (English: network processor, NP), a hardware chip, or any combination thereof.
  • the hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof.
  • ASIC application-specific integrated circuit
  • PLD programmable logic device
  • the above PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), and a general array logic (GAL). Or any combination thereof.
  • the memory 112 memory is used to store push messages, program codes, and the like.
  • the memory 112 may include a volatile memory (English: volatile memory), such as random access memory (English: random access memory, abbreviation: RAM); the memory 112 may also include non-volatile memory (English: non-volatile memory) For example, read-only memory (English: read-only memory, abbreviation: ROM), flash memory (English: flash memory), hard disk (English: hard disk drive, abbreviation: HDD) or solid state drive (English: solid-state drive , abbreviation: SSD); the memory 112 may also include a combination of the above types of memory.
  • ROM read-only memory
  • flash memory English: flash memory
  • HDD hard disk drive
  • SSD solid state drive
  • the communication interface 113 is configured to transmit and receive messages related to the above methods to devices such as a push server.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

Abstract

本发明实施例提供了一种消息推送方法，第一推送客户端根据安全级别指示标记判断是否需要对所述推送消息进行处理，在不需要对推送消息进行处理时，将其转发给第二推送客户端进行处理，从而终端可以根据安全级别指示标记对不同安全级别的推送消息进行差异化的处理，使安全级别较高的敏感信息得到安全处理，避免安全级别较高的敏感信息在终端的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。

Description

一种消息推送方法及终端 技术领域
本申请涉及电子技术领域，尤其涉及一种消息推送方法及终端。
背景技术
推送是指服务器和客户端之间的一种通信连接和消息发送方式。利用推送服务，服务器可主动的将图片或文字等消息内容发送给计算机或移动终端，而无需后者主动向服务器查询。目前，随着推送服务的发展，利用推送服务向终端推送的内容不仅涉及广告、应用更新信息等非敏感信息，还涉及到交易小票、验证码、系统配置信息等敏感信息。例如，如图1和图2所示就是目前有厂商通过推送消息给用户终端推送的交易信息。为了保证用户信息的安全，在现有的推送传输过程中添加了一些传输加密机制，可以降低推送数据在传输过程中泄露风险。现有技术的问题在于，虽然保证了推送消息的传输安全，但是当推送消息到达终端之后，仍然有可能被终端内的恶意程序获取和利用，泄露用户的个人信息。因此，现有的推送服务只能保证推送消息的传输安全，但存在推送消息发送到终端后的安全处理问题。
发明内容
本发明实施例所要解决的技术问题在于，提供一种消息推送方法及终端，可以解决推送消息的安全处理问题，从而降低推送数据的泄露风险。
本申请第一方面提供了一种消息推送方法。第一推送客户端接收推送服务器发送的推送消息，所述推送消息中包含安全级别指示标记和推送数据，第一推送客户端根据安全级别指示标记判断是否需要对所述推送消息进行处理，若不需要对推送消息进行处理，则第一推送客户端向第二推送客户端转发推送数据，第二推送客户端对推送数据进行处理。其中，第一推送客户端为终端的第一运行环境中的推送客户端，第二推送客户端为终端的第二运行环境中的推送客户端。
在该技术方案中，第一推送客户端根据安全级别指示标记判断是否需要对所述推送消息进行处理，在不需要对推送消息处理时转发给第二推送客户端进行处理，从而终端可以根据安全级别指示标记对不同安全级别的推送消息进行差异化的处理，使安全级别较高的敏感信息得到安全处理，避免安全级别较高的敏感信息在终端的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。
在第一方面的第一种可能的实现方式中，安全级别指示标记包括第一安全级别标记或第二安全级别标记，所述第一安全级别标记用于指示所述推送数据由REE会话密钥加密；所述第二安全级别标记用于指示所述推送数据由可信执行环境TEE会话密钥加密。
在该技术方案中，推送服务器根据安全级别指示标记对推送数据进行加密，使得推送数据只能被具有对应安全级别处理权限的推送客户端解密后进行处理，避免安全级别较高的敏感信息在终端的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。
结合第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，第 一运行环境为REE，第一推送客户端为终端的REE中的推送客户端；第二运行环境为TEE，第二推送客户端为所述终端的TEE中的推送客户端；若安全级别指示标记为第一安全级别标记，则第一推送客户端需要对所述推送消息进行处理；若安全级别指示标记为所述第二安全级别标记，则第一推送客户端不需要对所述推送消息进行处理。
在该技术方案中，安全级别指示标记为第一安全级别标记的推送消息由REE中的推送客户端处理，安全级别指示标记为第二安全级别标记的推送消息由TEE中的推送客户端处理，即将安全级别较高的推送消息交由TEE中的推送客户端处理，避免安全级别较高的敏感信息在终端的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。
结合第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，第一推送客户端向第二推送客户端转发推送数据，第二推送客户端使用TEE会话密钥对推送数据进行解密。
结合第一方面的第二种或第三种可能的实现方式，在第一方面的第四种可能的实现方式中，TEE会话密钥为第二推送客户端和推送服务器根据第二推送客户端生成的随机数和推送服务器生成的随机数协商确定的。
结合第一方面的第一种可能的实现方式，在第一方面的第五种可能的实现方式中，第一运行环境为TEE，第一推送客户端为终端的TEE中的推送客户端；第二运行环境为REE，第二推送客户端为终端的REE中的推送客户端；若安全级别指示标记为第一安全级别标记，则第一推送客户端不需要对推送消息进行处理；若安全级别指示标记为第二安全级别标记，则第一推送客户端需要对推送消息进行处理。
在该技术方案中，安全级别指示标记为第一安全级别标记的推送消息由REE中的推送客户端处理，安全级别指示标记为第二安全级别标记的推送消息由TEE中的推送客户端处理，即将安全级别较高的推送消息交由TEE中的推送客户端处理，避免安全级别较高的敏感信息在终端的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。
结合第一方面的第五种可能的实现方式，在第一方面的第六种可能的实现方式中，第一推送客户端向第二推送客户端转发推送数据，第二推送客户端使用REE会话密钥对推送数据进行解密。
结合第一方面的第五种或第六种可能的实现方式，在第一方面的第七种可能的实现方式中，REE会话密钥为第一推送客户端和推送服务器根据第一推送客户端生成的随机数和推送服务器生成的随机数协商确定后发送给第二推送客户端的。
结合第一方面的第五种至第七种可能的实现方式，在第一方面的第八种可能的实现方式中，若第一推送客户端确定需要对推送消息进行处理，则第一推送客户端使用TEE会话密钥对推送数据进行解密并调用可信用户界面TUI显示解密后的推送数据或将解密后的推送数据保存于可信存储空间中。
在第一方面的第九种可能的实现方式中，推送消息由TEE会话密钥加密后生成。
结合第一方面的第九种可能的实现方式，在第一方面的第十种可能的实现方式中，第一运行环境为TEE，第一推送客户端为终端的TEE中的推送客户端；第二运行环境为 REE，第二推送客户端为终端的REE中的推送客户端；第一推送客户端使用预设的TEE会话密钥对推送消息进行解密以获取推送数据，第一推送客户端向第二推送客户端转发推送数据。
在该技术方案中，推送服务器将不同安全级别的推送消息利用TEE会话密钥进行加密，且只能由TEE中的推送客户端进行解密，解密后根据推送数据的安全级别发送至相应的推送客户端进行处理，避免安全级别较高的敏感信息在终端的REE的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。
结合第一方面的第十种可能的实现方式，在第一方面的第十一种可能的实现方式中，TEE会话密钥为第一推送客户端和推送服务器根据第一推送客户端生成的随机数和推送服务器生成的随机数协商确定的。
结合第一方面的第九种可能的实现方式，在第一方面的第十二种可能的实现方式中，第一运行环境为REE，第一推送客户端为终端的REE中的推送客户端；第二运行环境为TEE，第二推送客户端为终端的TEE中的推送客户端；若第一推送客户端无法从推送消息中解密获得安全级别指示标记，则第一推送客户端不需要对推送消息进行处理。
在该技术方案中，推送服务器将不同安全级别的推送消息利用TEE会话密钥进行加密，且只能由TEE中的推送客户端进行解密，解密后根据推送数据的安全级别发送至相应的推送客户端进行处理，避免安全级别较高的敏感信息在终端的REE的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。
结合第一方面的第十二种可能的实现方式，在第一方面的第十三种可能的实现方式中，第一推送客户端向第二推送客户端转发推送消息，第二推送客户端使用TEE会话密钥对推送消息进行解密。
结合第一方面的第二种可能的实现方式，在第一方面的第十四种可能的实现方式中，推送数据包括设备唤醒指示，第一推送客户端向第二推送客户端转发设备唤醒指示，第二推送客户端使用TEE会话密钥对设备唤醒指示进行解密，并根据设备唤醒指示与设备唤醒指示对应的第二设备建立连接。
在该技术方案中，终端将设备唤醒指示作为较高级别的推送数据在TEE中的推送客户端对其进行处理，以使TEE中的推送客户端可以根据设备唤醒指示与终端关联的第二设备建立连接，保证推送服务器通过TEE中的推送客户端向第二设备发送推送数据，避免第二设备的相关推送数据在终端的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。
结合第一方面的第五种至第七种可能的实现方式，在第一方面的第十五种可能的实现方式中，推送数据包括设备唤醒指示，若第一推送客户端需要对推送消息进行处理，则第一推送客户端使用TEE会话密钥对设备唤醒指示进行解密，并根据设备唤醒指示与设备唤醒指示对应的第二设备建立连接。
结合第一方面以及第一方面的第一种至第十五种可能的实现方式，在第一方面的第十六种可能的实现方式中，推送消息还包括推送对象标识，第一推送客户端向第二推送客户端转发推送数据以及推送对象标识，第二推送客户端将推送数据发送给推送对象标识指示的目标应用程序。
结合第一方面的第十六种可能的实现方式，在第一方面的第十七种可能的实现方式中，第二推送客户端将推送数据发送给推送对象标识指示的与终端关联的第二设备上的目标应用程序。
本申请第二方面提供了一种消息推送方法。第一推送客户端接收推送服务器发送的推送消息，所述推送消息中包含安全级别指示标记和推送数据，第一推送客户端根据安全级别指示标记判断是否需要对所述推送消息进行处理，若不需要对推送消息进行处理，则第一推送客户端向第二推送客户端转发推送数据，第二推送客户端对推送数据进行处理。其中，第一推送客户端为终端的第一运行环境中的推送客户端，第二推送客户端为终端的第二运行环境中的推送客户端。
在该技术方案中，第一推送客户端根据安全级别指示标记判断是否需要对所述推送消息进行处理，在不需要对推送消息处理时转发给第二推送客户端进行处理，从而终端可以根据安全级别指示标记对不同安全级别的推送消息进行差异化的处理，使安全级别较高的敏感信息得到安全处理，避免安全级别较高的敏感信息在终端的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。
本申请第三方面提供了一种终端。该终端包括第一推送客户端以及第二推送客户端，第一推送客户端包括第一收发模块和第一处理模块，第二推送客户端包括第二收发模块和第二处理模块，终端通过上述模块实现第一方面和第二方面的部分或全部方法。
本申请第四方面提供了另一种终端。该终端包括处理器、存储器以及网络接口。处理器连接到存储器和网络接口，例如处理器可以通过总线连接到存储器和网络接口。网络接口用于与推送服务器收发上述方法中所涉及的消息。存储器用于存储推送消息。处理器用于执行第一方面和第二方面的部分或全部流程。
附图说明
图1是现有技术方案提供的一种交易信息的推送示例图；
图2是现有技术方案提供的另一种交易信息的推送示例图；
图3是本申请实施例中一种推送服务架构示意图；
图4a是本申请实施例中一种消息推送方法的流程示意图；
图4b是本申请实施例中另一种消息推送方法的流程示意图；
图5a是本申请实施例中另一种消息推送方法的流程示意图；
图5b是本申请实施例中另一种消息推送方法的流程示意图；
图6a是本申请实施例中一种基于终端的关联设备的消息推送方法的流程示意图；
图6b是本申请实施例中另一种基于终端的关联设备的消息推送方法的流程示意图；
图7a是本申请实施例中另一种基于终端的关联设备的消息推送方法的流程示意图；
图7b是本申请实施例中另一种基于终端的关联设备的消息推送方法的流程示意图；
图8a是本申请实施例中一种密钥协商方法的流程示意图；
图8b是本申请实施例中另一种密钥协商方法的流程示意图；
图9是本申请实施例中一种终端应用程序注册方法的流程示意图；
图10是本申请实施例中一种终端的结构示意图；
图11是本申请实施例中另一种终端的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。
本申请实施例的技术方案适用于各种基于推送服务的系统架构中，比如图3所示的一种推送服务架构示意图，包括终端101，推送服务器102和至少一个应用服务器103(图3中示出了应用服务器103a和应用服务器103b)，其中终端101内部包括至少一个应用客户端1011(图3中示出了客户端1011a和客户端1011b)和推送客户端1012，其中应用客户端1011与应用服务器103是相互对应的，也就是说，应用客户端1011与应用服务器103都是针对相同的应用程序。在具体实现中，推送客户端1012由两个实体组成：运行在终端的富执行环境(REE，Rich Execution Environment)中的推送客户端1012a以及运行在终端的可信执行环境(TEE，Trusted Execution Environment)中的推送客户端1012b，其中富执行环境中的推送客户端1012a和可信执行环境中的推送客户端1012b之间通过安全通道连接，例如，一种可能的安全通道实现方式是，TEE推送客户端向REE推送客户端提供客户端API(标准的TEE Client API)接口，REE推送客户端通过调用客户端API与TEE推送客户端通信。
这里，富执行环境REE泛指不具备特定安全功能的运行环境，可信执行环境TEE是与富执行环境REE共同存于终端中的运行环境，能够为可信应用提供安全的免受软件攻击的运行环境。TEE具有与REE隔离的CPU核，TEE的CPU核可以是物理上与REE隔离或虚拟的与REE隔离的核；TEE具有对REE不可见的、利用安全存储技术实现的存储空间，因此，TEE能够确保其存储空间中的资产(如密钥、数据、软件等)免受软件攻击，抵抗特定类型的安全威胁。
以下通过图4a—7b所示的实施例对消息推送方法及执行该方法涉及到相关的流程进行详细描述。
图4a和图4b是本申请实施例中两种消息推送方法的流程示意图。图4a所示的实施例中，第一推送客户端为终端的REE中的推送客户端，第二推送客户端为终端的TEE中的推送客户端。图4b所示的实施例中，第一推送客户端为终端的TEE中的推送客户端，第二推送客户端为终端的REE中的推送客户端。具体方法包括：
步骤S401，第一应用服务器向推送服务器发送应用推送消息，所述应用推送消息中携带推送数据和推送对象标识。
应用推送消息中携带推送数据和推送对象标识，也即第一应用服务器希望向推送对象标识对应的终端中的第一应用发送推送数据。需要说明的是，这里的推送对象标识可以是存储在第一应用服务器的推送服务列表中的终端应用标识。也就是说，推送对象标识是第一应用服务器的推送服务列表中的一个终端应用标识。
步骤S402，推送服务器根据应用推送消息，设置安全级别指示标记并确定预设的密钥对推送数据进行加密以生成推送消息。
推送服务器根据应用推送消息，可以为应用推送消息对应的推送消息设置安全级别指 示标记，并且确定与设置的安全级别标记对应的密钥，从而对推送数据进行加密，最终生成携带安全级别指示标记以及推送数据的推送消息。在图4a和图4b所示的实施例中，安全级别指示标记可以包括第一安全级别标记和第二安全级别标记，其中第一安全级别标记指示的是较低安全级别或者普通安全级别的推送数据，终端接收后无需进行安全处理，第二安全级别标记指示的是较高安全级别或者特殊安全级别的推送数据，终端需要利用TEE进行安全地处理。
设置安全级别指示标记时，在一种可能的实施场景中，第一应用服务器发送的应用推送消息中可以携带安全处理指示标签，以指示推送服务器将推送消息的安全级别指示标记设置为第二安全级别标记；若第一应用服务器发送的应用推送消息中未携带安全处理指示标签，则推送服务器可以将推送消息的安全级别指示标记设置为第一安全级别标记。在另一种可能的实施场景中，推送服务器可以对第一应用服务器发送的应用推送消息进行分析，根据应用推送消息的内容、数据类型、优先级以及紧急类型等等消息特征指标，确定推送消息的安全级别指示标记。
需要说明的是，这里的安全级别指示标记可以添加在推送消息的消息头部，即占用推送消息的消息头部中固定长度的字节。进一步的，推送服务器还可以使用与接收推送消息的推送客户端持有的密钥相应的密钥对安全级别指示标记进行加密，也可以不加密，这里不作具体限定。具体来说，若推送消息的接收客户端为REE中的推送客户端，则可以使用预先协商生成的REE会话密钥对安全级别指示标记进行加密，若推送消息的接收客户端为TEE中的推送客户端，则可以使用预先协商生成的TEE会话密钥对安全级别指示标记进行加密。
在图4a和图4b所示的实施例中，推送消息中包含的推送数据是经过加密的且加密的密钥与安全级别指示标记存在对应关系。具体来说，推送服务器将安全级别指示标记设置为第一安全级别标记时，推送消息中包含的推送数据由REE会话密钥加密后生成；推送服务器将安全级别指示标记设置为第二安全级别标记时，推送消息中包含的推送数据由TEE会话密钥加密后生成。
步骤S403，推送服务器向第一推送客户端发送推送消息。
根据推送对象标识，推送服务器可以确定推送对象标识对应的终端，并向该终端中的第一推送客户端发送推送消息。
在图4a所示的实施场景中，第一推送客户端为终端的REE环境中的推送客户端，第二推送客户端为终端的TEE中的推送客户端。在该实施场景中，第一推送客户端可访问网络通信接口，接收推送服务器发送的推送消息，第二推送客户端无法直接访问网络通信接口，需通过第一推送客户端才能接收到推送消息。
在图4b所示的实施场景中，第一推送客户端为终端的TEE中的推送客户端，在该实施场景中，第一推送客户端具备网络通信接口访问能力，能够直接与推送服务器通信。
步骤S404，第一推送客户端根据安全级别指示标记，判断是否需要对推送消息进行处理。
在图4a所示的实施场景中，若接收到的安全级别指示标记是经过加密的，第一推送客户端可以先使用REE会话密钥对加密的安全级别指示标记进行解密，然后根据安全级 别指示标记，判断接收到的推送消息是否应该由本端处理。在图4b所示的实施场景中，若接收到的安全级别指示标记是经过加密的，第一推送客户端可以先使用TEE会话密钥对加密的安全级别指示标记进行解密，然后根据安全级别指示标记，判断接收到的推送消息是否应该由本端处理。
在图4a所示的实施场景中，步骤S404可以包括步骤S4041：
步骤S4041，若安全级别指示标记为第一安全级别标记，则第一推送客户端需要对推送消息进行处理，执行步骤S405；若安全级别指示标记为第二安全级别标记，则第一推送客户端不需要对推送消息进行处理，执行步骤S406～S407。
安全级别指示标记为第一安全级别标记，说明推送消息的安全级别较低，可以在REE中处理，因此第一推送客户端可以直接对该推送消息进行处理；安全级别指示标记为第二安全级别标记，说明推送消息的安全级别较高，需要在TEE中处理，因此第一推送客户端不需要对该推送消息进行处理。
在图4b所示的实施场景中，步骤S404可以包括步骤S4042：
步骤S4042，若安全级别指示标记为第一安全级别标记，则第一推送客户端不需要对推送消息进行处理，执行步骤S408～S409；若安全级别指示标记为第二安全级别标记，则第一推送客户端需要对所述推送消息进行处理，执行步骤S410。
安全级别指示标记为第一安全级别标记，说明推送消息的安全级别较低，可以在REE中处理，因此第一推送客户端不需要对该推送消息进行处理；安全级别指示标记为第二安全级别标记，说明推送消息的安全级别较高，需要在TEE中处理，因此第一推送客户端需要对该推送消息进行处理。
步骤S405，第一推送客户端使用预设的REE会话密钥对推送数据进行解密，并对解密的推送数据进行处理。
由于推送服务器对于第一安全级别标记的推送数据使用的是REE会话密钥加密的，因此第一推送客户端使用在密钥协商阶段中预先从第二推送客户端接收的REE会话密钥对推送数据解密即可。
在一种可能的实施场景中，第一推送客户端在得到解密后的推送数据后，可以指示终端的操作系统处理解密后的推送数据；在另一种可能的实施场景中，推送服务器向第一推送客户端发送的推送消息中还可以包括推送对象标识，从而第一推送客户端可以将解密后的推送数据发送给推送对象标识指示的目标应用程序或目标应用程序对应的REE应用部分，从而使目标应用程序或目标应用程序的REE应用部分处理解密后的推送数据。这里，目标应用程序可以是指第一应用服务器所服务的第一应用程序。
步骤S406，第一推送客户端向第二推送客户端转发推送数据。
第一推送客户端不需要对该推送消息进行处理，则将推送数据转发给第二推送客户端进行处理。需要说明的是，这里可以仅将推送数据发送给第二推送客户端，也可以将推送消息整体发送给第二推送客户端，这里不作具体限定。
步骤S407，第二推送客户端使用预设的TEE会话密钥对推送数据进行解密，并对解密后的推送数据进行处理。
由于推送服务器对于第二安全级别标记的推送数据使用的是TEE会话密钥加密的， 因此第二推送客户端使用在密钥协商阶段中生成的TEE会话密钥对推送数据解密即可。
在一种可能的实施场景中，第二推送客户端可以指示TEE调用可信用户界面(TUI，Trusted User Interface)显示解密后的推送数据或将解密后的推送数据保存于可信存储空间中；在另一种可能的实施场景中，推送服务器向第一推送客户端发送的推送消息中还可以包括推送对象标识，第一推送客户端向第二推送客户端发送推送数据时也携带推送对象标识，从而第二推送客户端可以将解密后的推送数据发送给推送对象标识指示的目标应用程序对应的TEE应用部分，使目标应用程序的TEE应用部分处理解密后的推送数据。这里，目标应用程序可以是指第一应用服务器所服务的第一应用程序。
步骤S408，第一推送客户端向第二推送客户端转发推送数据。
第一推送客户端不需要对该推送消息进行处理，则将加密的推送数据转发给第二推送客户端进行处理。需要说明的是，这里可以仅将推送数据发送给第二推送客户端，也可以将推送消息整体发送给第二推送客户端，这里不作具体限定。
步骤S409，第二推送客户端使用预设的REE会话密钥对推送数据进行解密并对解密后的推送数据进行处理。
由于推送服务器对于第一安全级别标记的推送数据使用的是REE会话密钥加密的，因此第二推送客户端使用在密钥协商阶段中预先从第一推送客户端接收的REE会话密钥对推送数据解密即可。
在一种可能的实施场景中，第二推送客户端在得到解密后的推送数据后，可以指示终端的操作系统处理解密后的推送数据；在另一种可能的实施场景中，推送服务器向第一推送客户端发送的推送消息中还可以包括推送对象标识，第一推送客户端向第二推送客户端发送推送数据时也携带推送对象标识，从而第一推送客户端可以将解密后的推送数据发送给推送对象标识指示的目标应用程序或目标应用程序对应的REE应用部分，从而使目标应用程序或目标应用程序的REE应用部分处理解密后的推送数据。这里，目标应用程序可以是指第一应用服务器所服务的第一应用程序。
步骤S410，第一推送客户端使用预设的TEE会话密钥对推送数据进行解密并对解密的推送数据进行处理。
由于推送服务器对于第二安全级别标记的推送数据使用的是TEE会话密钥加密的，因此第一推送客户端使用在密钥协商阶段中生成的TEE会话密钥对推送数据解密即可。
在一种可能的实施场景中，第一推送客户端可以指示TEE调用可信用户界面(TUI，Trusted User Interface)显示解密后的推送数据或将解密后的推送数据保存于可信存储空间中；在另一种可能的实施场景中，推送服务器向第一推送客户端发送的推送消息中还可以包括推送对象标识，从而第一推送客户端可以将解密后的推送数据发送给推送对象标识指示的目标应用程序对应的TEE应用部分，使目标应用程序的TEE应用部分处理解密后的推送数据。这里，目标应用程序可以是指第一应用服务器所服务的第一应用程序。
图4a和图4b所示的实施例，将不同安全级别的推送数据利用不同的会话密钥进行加密，并根据推送数据的安全级别发送至相应的推送客户端进行处理，避免安全级别较高的敏感信息在终端的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。
图5a和5b是本申请实施例中两种消息推送方法的流程示意图。图5a所示的实施例中，第一推送客户端为终端的REE中的推送客户端，第二推送客户端为终端的TEE中的推送客户端。图5b所示的实施例中，第一推送客户端为终端的TEE中的推送客户端，第二推送客户端为终端的REE中的推送客户端。具体方法包括：
步骤S501，第一应用服务器向推送客户端发送应用推送消息，所述应用推送消息中携带推送数据和推送对象标识。
步骤S502，推送服务器根据应用推送消息设置安全级别指示标记，根据安全级别指示标记与推送数据生成推送消息，并使用预设的TEE会话密钥对推送消息进行加密。
推送服务器根据应用推送消息，可以为应用推送消息对应的推送消息设置安全级别指示标记，最终生成携带安全级别指示标记以及推送数据的推送消息。在图5a和图5b所示的实施例中，安全级别指示标记可以包括第一安全级别标记和第二安全级别标记，其中第一安全级别标记指示的是较低安全级别或者普通安全级别的推送数据，第二安全级别标记指示的是较高安全级别或者特殊安全级别的推送数据。
在图5a和图5b所示的实施例中，推送服务器在生成推送消息后，可以使用预先协商生成的TEE会话密钥对推送消息进行加密。从而推送服务器发出的推送消息是整体经过加密的，推送消息中包括推送数据以及安全级别指示标识。其中，在图5a和图5b所示的实施例中，推送数据是指未加密的推送数据。
设置安全级别指示标记时，在一种可能的实施场景中，第一应用服务器发送的应用推送消息中可以携带安全处理指示标签，以指示推送服务器将推送消息的安全级别指示标记设置为第二安全级别标记；若第一应用服务器发送的应用推送消息中未携带安全处理指示标签，则推送服务器可以将推送消息的安全级别指示标记设置为第一安全级别标记。在另一种可能的实施场景中，推送服务器可以对第一应用服务器发送的应用推送消息进行分析，根据应用推送消息的内容、数据类型、优先级以及紧急类型等等消息特征指标，确定推送消息的安全级别指示标记。
需要说明的是，这里的安全级别指示标记可以添加在推送消息的消息头部，即占用推送消息的消息头部中固定长度的字节。
步骤S503，推送服务器向第一推送客户端发送推送消息。
根据推送对象标识，推送服务器可以确定推送对象标识对应的终端，并向该终端中的第一推送客户端发送推送消息。
在图5a所示的实施场景中，第一推送客户端为终端的REE中的推送客户端，第二推送客户端为终端的TEE中的推送客户端。在该实施场景中，第一推送客户端可访问网络通信接口，接收推送服务器发送的推送消息，第二推送客户端无法访问网络通信接口，需通过第一推送客户端才能接收到推送消息。
在图5b所示的实施场景中，第一推送客户端为终端的TEE中的推送客户端，在该实施场景中，第一推送客户端具备网络通信接口访问能力，能够直接与推送服务器通信。
步骤S504，第一推送客户端判断能否从推送消息中解密获得安全级别指示标记。
在图5a所示的实施场景中，步骤S504可以包括步骤S5041：
步骤S5041，第一推送客户端无法从推送消息中解密获得安全级别指示标记时，第一 推送客户端不需要对推送消息进行处理，执行步骤S505～S510。
第一推送客户端在接收到推送消息时需要对推送消息进行解析以获取安全级别指示标记，当第一推送客户端无法解析获取推送消息中的安全级别指示标记时，第一推送客户端不需要对该推送消息进行处理。具体实施中，在一种可能的实施场景中，第一推送客户端中未存储相关密钥，当接收到推送消息时可以直接判断无法从推送消息中解密获得安全级别指示标记，则不需要对推送消息进行处理，执行步骤S505～S510；在另一种可能的实施场景中，第一推送客户端中可能存储有其他密钥，当接收到推送消息时可以对推送消息进行解密，由于推送服务器发送的推送消息是通过TEE会话密钥加密的，而第一推送客户端不具有TEE会话密钥，则无法解密推送数据，因此无法从推送消息中获取安全级别指示标记，则不需要对推送消息进行处理，执行步骤S505～S510。
在图5b所示的实施场景中，步骤S504可以包括步骤S5042：
步骤S5042，在第一推送客户端成功从推送消息中解密获得安全级别指示标记时，执行步骤S511～S514。
由于推送服务器发送的推送消息是通过TEE会话密钥加密的，第一推送客户端具有TEE会话密钥，因此可以解密推送消息获得安全级别指示标记以及推送数据，则执行步骤S511～514。
步骤S505，第一推送客户端向第二推送客户端转发推送消息。
第一推送客户端不需要对该推送消息进行处理，则将推送消息转发给第二推送客户端。
步骤S506，第二推送客户端使用预设的TEE会话密钥对推送消息进行解密。
由于推送服务器发送的推送消息是通过TEE会话密钥加密的，因此第二推送客户端使用在密钥协商阶段中生成的TEE会话密钥对推送消息解密，即可获取到推送消息中的推送数据。
步骤S507，第二推送客户端根据安全级别指示标记，判断是否需要对推送消息进行处理。若安全级别指示标记为第一安全级别标记，则第二推送客户端不需要对推送消息进行处理，执行步骤S508～S509；若安全级别指示标记为第二安全级别标记，则第二推送客户端需要对推送消息进行处理，则执行步骤S510。
步骤S508，第二推送客户端向第一推送客户端转发推送数据。
步骤S509，第一推送客户端对推送数据进行处理。
在一种可能的实施场景中，第一推送客户端在得到推送数据后，可以指示终端的操作系统处理推送数据；在另一种可能的实施场景中，推送服务器向第一推送客户端发送的推送消息中还可以包括推送对象标识，从而第一推送客户端可以将推送数据发送给推送对象标识指示的目标应用程序或目标应用程序对应的REE应用部分，从而使目标应用程序或目标应用程序的REE应用部分处理解密后的推送数据。
步骤S510，第二推送客户端对推送数据进行处理。
在一种可能的实施场景中，第二推送客户端可以指示TEE调用可信用户界面(TUI，Trusted User Interface)显示推送数据或将推送数据保存于可信存储空间中；在另一种可能的实施场景中，推送服务器向第一推送客户端发送的推送消息中还可以包括推送对象标 识，第一推送客户端向第二推送客户端转发推送消息时也携带推送对象标识，从而第二推送客户端可以将推送数据发送给推送对象标识指示的目标应用程序对应的TEE应用部分，使目标应用程序的TEE应用部分处理推送数据。
步骤S511，第一推送客户端根据安全级别指示标记，判断是否需要对推送消息进行处理。若安全级别指示标记为第一安全级别标记，则第一推送客户端不需要对推送消息进行处理，执行步骤S512～S513；若安全级别指示标记为第二安全级别标记，则第一推送客户端需要对推送消息进行处理，则第一推送客户端对推送消息进行处理，则执行步骤S514。
步骤S512，第一推送客户端向第二推送客户端转发推送数据。
步骤S513，第二推送客户端对推送数据进行处理。
在一种可能的实施场景中，第二推送客户端在解密推送消息得到推送数据后，可以指示终端的操作系统处理推送数据；在另一种可能的实施场景中，推送服务器向第一推送客户端发送的推送消息中还可以包括推送对象标识，第一推送客户端向第二推送客户端转发推送数据时也携带推送对象标识，从而第二推送客户端可以将推送数据发送给推送对象标识指示的目标应用程序或目标应用程序对应的REE应用部分，从而使目标应用程序或目标应用程序的REE应用部分处理推送数据。
步骤S514，第一推送客户端对推送数据进行处理。
在一种可能的实施场景中，第一推送客户端可以指示TEE调用可信用户界面(TUI，Trusted User Interface)显示推送数据或将推送数据保存于可信存储空间中；在另一种可能的实施场景中，推送服务器向第一推送客户端发送的推送消息中还可以包括推送对象标识，从而第一推送客户端可以将推送数据发送给推送对象标识指示的目标应用程序对应的TEE应用部分，使目标应用程序的TEE应用部分处理推送数据。
图5a和图5b所示的实施例，将不同安全级别的推送消息利用TEE会话密钥进行加密，并统一由TEE中的推送客户端进行解密，并根据推送数据的安全级别发送至相应的推送客户端进行处理，避免安全级别较高的敏感信息在终端的REE的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。
图6a和6b是本申请实施例中两种基于终端的关联设备的消息推送方法的流程示意图。图6a所示的实施例中，第一推送客户端为终端的REE中的推送客户端，第二推送客户端为终端的TEE中的推送客户端。图6b所示的实施例中，第一推送客户端为终端的TEE中的推送客户端，第二推送客户端为终端的REE中的推送客户端。具体方法包括：
步骤S601，第一应用服务器向推送客户端发送应用推送消息，所述应用推送消息中携带推送数据和推送对象标识。
应用推送消息中携带推送数据和推送对象标识，也即第一应用服务器希望向推送对象标识对应的终端发送推送数据。在图6a和6b所示的实施例中，应用推送消息中可以包括第二设备安全处理标签，该第二设备安全处理标签用于指示应用推送消息中的推送数据由与终端关联的第二设备处理。这里的推送对象标识可以包含终端标识以及第二设备标识。
步骤S602，推送服务器根据应用推送消息，缓存推送数据，设置安全级别指示标记， 生成设备唤醒指示并确定预设的密钥对设备唤醒指示进行加密以生成推送消息。
在图6a和图6b所示的实施例中，推送服务器在接收到包括第二设备安全处理标签的推送消息时，可以先将推送数据缓存，并将安全级别指示标记设置为第二安全级别标记，第二安全级别标记可以指示针对终端关联的第二设备的推送数据。
第二安全级别标记设置完成后，推送服务器可以进一步生成设备唤醒指示，并将设备唤醒指示使用预先协商生成的TEE会话密钥进行加密，设备唤醒指示包含与终端关联的第二设备的标识，还可包含要求终端执行的动作，如通过蓝牙接口扫描设备并与设备建立蓝牙连接。
从而，推送服务器可以生成推送消息，在该实施例中，推送消息中包含设备唤醒指示以及第二安全级别标记。推送消息中包含的设备唤醒指示是经TEE会话密钥加密的。
步骤S603，推送服务器向第一推送客户端发送推送消息。
在图6a所示的实施场景中，第一推送客户端为终端的REE中的推送客户端，第二推送客户端为终端的TEE中的推送客户端。在该实施场景中，第一推送客户端可访问网络通信接口，接收推送服务器发送的推送消息，第二推送客户端无法访问网络通信接口，需通过第一推送客户端才能接收到推送消息。
在图6b所示的实施场景中，第一推送客户端为终端的TEE中的推送客户端，在该实施场景中，第一推送客户端具备网络通信接口访问能力，能够直接与推送服务器通信。
步骤S604，第一推送客户端根据安全级别指示标记，判断是否需要对推送消息进行处理。
在图6a所示的实施场景中，步骤S604可以包括步骤S6041：
步骤S6041，若安全级别指示标记为第二安全级别标记，则第一推送客户端不需要对推送消息进行处理，执行步骤S605～S608。
在图6b所示的实施场景中，步骤S604可以包括步骤S6042：
步骤S6042，若安全级别指示标记为第二安全级别标记，则第一推送客户端需要对推送消息进行处理，执行步骤S609～S611。
步骤S605，第一推送客户端向第二推送客户端发送设备唤醒指示。
第一推送客户端不需要对该推送消息进行处理，则将设备唤醒指示转发给第二推送客户端进行处理。需要说明的是，这里可以仅将设备唤醒指示发送给第二推送客户端，也可以将推送消息整体发送给第二推送客户端，这里不作具体限定。
步骤S606，第二推送客户端使用预设的TEE会话密钥对设备唤醒指示进行解密，并根据设备唤醒指示扫描与终端关联的第二设备。
由于推送服务器对于第二安全级别标记的设备唤醒指示使用的是TEE会话密钥加密的，因此第二推送客户端使用在密钥协商阶段中生成的TEE会话密钥对设备唤醒指示解密即可。
在得到解密后的设备唤醒指示后，第二推送客户端调用蓝牙低功耗设备安全配置服务(BLE GP Service，Bluetooth Low Energy Global Platform Service)接口，可以根据设备唤醒指示扫描第二设备，这里第二设备可以指可穿戴设备或物联网设备等等。
步骤S607，第二推送客户端与终端关联的第二设备建立连接，并通知推送服务器。
步骤S608，推送服务器通过第二推送客户端向第二设备发送缓存的推送数据。
推送服务器向第二推送客户端发送推送数据时可以携带推送对象标识，从而第二推送客户端可以将推送数据发送给推送对象标识指示的与终端关联的第二设备上的目标应用程序，从而目标应用程序可以对该推送数据进行处理。
步骤S609，第一推送客户端使用预设的TEE会话密钥对设备唤醒指示进行解密，并根据设备唤醒指示扫描与终端关联的第二设备。
步骤S610，第一推送客户端与终端关联的第二设备建立连接，并通知推送服务器。
步骤S611，推送服务器通过第一推送客户端向第二设备发送缓存的推送数据。
图6a和图6b所示的实施例，将设备唤醒指示作为较高级别的推送数据，由TEE中的推送客户端对其进行处理，以使TEE中的推送客户端可以根据设备唤醒指示与终端关联的第二设备建立连接，保证推送服务器通过TEE中的推送客户端向第二设备发送推送数据，避免第二设备的相关推送数据在终端的处理过程中发生信息泄露，从而可以解决推送消息的安全处理问题。
图7a和7b是本申请实施例中两种基于终端的关联设备的消息推送方法的流程示意图。图7a所示的实施例中，第一推送客户端为终端的REE中的推送客户端，第二推送客户端为终端的TEE中的推送客户端。图7b所示的实施例中，第一推送客户端为终端的TEE中的推送客户端，第二推送客户端为终端的REE中的推送客户端。具体方法包括：
步骤S701，第一应用服务器向推送客户端发送应用推送消息，所述应用推送消息中携带推送数据和推送对象标识。
步骤S702，推送服务器根据应用推送消息，缓存推送数据，设置安全级别指示标记，生成设备唤醒指示，根据设备唤醒指示与安全级别指示标记生成推送消息，并使用预设的TEE会话密钥对推送消息进行加密。
在图7a和图7b所示的实施例中，推送服务器在接收到包括第二设备安全处理标签的推送消息时，可以先将推送数据缓存，并将安全级别指示标记设置为第二安全级别标记，第二安全级别标签可以指示针对终端关联的第二设备的推送数据。
第二安全级别标记设置完成后，推送服务器可以进一步生成设备唤醒指示，并利用设备唤醒指示与安全级别指示标记生成推送消息。推送服务器在生成推送消息后，可以使用预先协商生成的TEE会话密钥对推送消息进行加密。从而，推送服务器发出的推送消息是经过加密的，推送消息中包含设备唤醒指示以及第二安全级别标记。其中，在图7a和图7b所示的实施例中，设备唤醒指示是未加密的设备唤醒指示。
步骤S703，推送服务器向第一推送客户端发送推送消息。
步骤S704，第一推送客户端判断能否从推送消息中解密获得安全级别指示标记。
在图7a所示的实施场景中，步骤S704可以包括步骤S7041：
步骤S7041，第一推送客户端无法从推送消息中解密获得安全级别指示标记时，第一推送客户端不需要对推送消息进行处理，执行步骤S705～S708。
第一推送客户端在接收到推送消息时需要对推送消息进行解析以获取安全级别指示标记，当第一推送客户端无法解析获取推送消息中的安全级别指示标记时，第一推送客户 端不需要对该推送消息进行处理。具体实施中，在一种可能的实施场景中，第一推送客户端中未存储相关密钥，当接收到推送消息时可以直接判断无法从推送消息中解密获得安全级别指示标记，则不需要对推送消息进行处理，执行步骤S705～S708；在另一种可能的实施场景中，第一推送客户端中可能存储有其他密钥，当接收到推送消息时可以对推送消息进行解密，由于推送服务器发送的推送消息是通过TEE会话密钥加密的，而第一推送客户端不具有TEE会话密钥，则无法解密加密的推送数据，因此无法从推送消息中获取安全级别指示标记，则不需要对推送消息进行处理，执行步骤S705～S708。
在图7b所示的实施场景中，步骤S704可以包括步骤S7042：
步骤S7042，在第一推送客户端成功从推送消息中解密获得安全级别指示标记时，执行步骤S709～S711。
由于推送服务器发送的推送消息是通过TEE会话密钥加密的，第一推送客户端具有TEE会话密钥，可以解密推送消息，则执行步骤S709～711。
步骤S705，第一推送客户端向第二推送客户端转发推送消息。
第一推送客户端不需要对该推送消息进行处理，则将推送消息转发给第二推送客户端进行处理。
步骤S706，第二推送客户端使用预设的TEE会话密钥对推送消息进行解密，并根据安全级别指示标记确定对该推送消息进行处理并根据设备唤醒指示扫描与终端关联的第二设备。
由于推送服务器对于第二安全级别标记的设备唤醒指示使用的是TEE会话密钥加密的，因此第二推送客户端使用在密钥协商阶段生成的TEE会话密钥对推送消息解密即可获取到推送消息中的设备唤醒指示。
在解密得到设备唤醒指示后，由于检测到第二安全级别标记，确定由第二推送客户端对该推送消息进行处理，第二推送客户端则调用蓝牙低功耗GP安全配置服务(BLE GP Service，Bluetooth Low Energy Global Platform Service)接口，可以根据推送对象标识扫描第二设备，这里第二设备可以指可穿戴设备或物联网设备等等。
步骤S707，第二推送客户端与终端关联的第二设备建立连接，并通知推送服务器。
步骤S708，推送服务器通过第二推送客户端向第二设备发送缓存的推送数据。
推送服务器向第二推送客户端发送推送数据时可以携带推送对象标识，从而第二推送客户端可以将推送数据发送给推送对象标识指示的与终端关联的第二设备上的目标应用程序，从而目标应用程序可以对该推送数据进行处理。
步骤S709，第一推送客户端根据安全级别指示标记确定对该推送消息进行处理，并根据设备唤醒指示扫描与终端关联的第二设备。
步骤S710，第一推送客户端与终端关联的第二设备建立连接，并通知推送服务器。
步骤S711，推送服务器通过第一推送客户端向第二设备发送缓存的推送数据。
图7a和图7b所示的实施例，将设备唤醒指示作为较高级别的推送数据在TEE中的推送客户端对其进行处理，以使TEE中的推送客户端可以根据设备唤醒指示与终端关联的第二设备建立连接，保证推送服务器通过TEE中的推送客户端向第二设备发送推送数据，避免第二设备的相关推送数据在终端的处理过程中发生信息泄露，从而可以解决推送 消息的安全处理问题。
图8a和图8b是对图4a-7b的实施例中提及的密钥协商阶段过程的详细描述，即如何生成TEE会话密钥或/和REE会话密钥以及如何将会话密钥保存在第一推送客户端或/第二推送客户端中的过程。
图8a和图8b是本申请实施例中两种密钥协商方法的流程示意图。在推送客户端与推送服务器进行推送数据交互时，需要进行加密以保证推送数据的传输安全。因此，在推送服务器向终端的推送客户端发送推送消息之前，还需要对加密密钥进行协商。本申请实施例中的密钥协商过程发生在终端启动后，推送客户端与推送服务器进行连接建立的过程中。图8a和图8b所示的实施例中，第一推送客户端为终端的REE中的推送客户端，第二推送客户端为终端的TEE中的推送客户端。具体方法包括：
步骤S801，第一推送客户端向第二推送客户端发送安全传输连接建立请求。
终端的推送客户端需要与推送服务器建立连接以保证随时接收推送数据。第一推送客户端可以向第二推送客户端发送安全传输连接建立请求，安全传输连接建立请求表示终端请求与推送服务器建立安全传输层协议(TLS，Transport Layer Security)连接，从而触发密钥协商过程。
在一种可能的实施情景中，第二推送客户端能够访问网络通信接口，能够直接与推送服务器通信，则执行以下步骤S802～S810或步骤S802～805以及S811～S814。
步骤S802，第二推送客户端根据安全传输连接建立请求，生成第一随机数并利用预先获取到的第一公钥对第一随机数进行加密。
第二推送客户端在接收到安全传输连接建立请求后，就可以生成第一随机数并利用预先获取到的第一公钥对第一随机数进行加密。需要说明的是，第一公钥是指推送服务器的证书中携带的公钥。具体的，第二推送客户端可预先获得推送服务器的证书，并提取证书中的公钥用于加密发给推送服务器的随机数。
步骤S803，第二推送客户端向推送服务器发送加密的第一随机数、第一随机数的签名以及终端证书。
第二推送客户端生成加密的第一随机数后，可以将加密的第一随机数、第一随机数的签名以及终端自身的证书一同发送给推送服务器。终端的证书可以被推送服务器用于确定加密的第一随机数确实为终端所发，具体的，推送服务器可利用终端的证书验证第一随机数的签名，如签名正确则可确定第一随机数确实为终端所发，并使用终端证书中的公钥加密推送服务器生成的第二随机数。
步骤S804，推送服务器使用第一公钥对应的第一私钥对加密的第一随机数进行解密以获取第一随机数，生成第二随机数并利用从终端证书中获取到的第二公钥对第二随机数进行加密。
可以理解的是，在本申请实施例的加密方式中，推送服务器利用其私钥(第一私钥)解密推送服务器公钥(第一公钥)加密的内容；终端利用其证书对应的私钥(第二私钥)解密终端证书公钥(第二公钥)加密的内容。
因此，推送服务器使用第一公钥对应的第一私钥对加密的第一随机数进行解密可以获 取到第一随机数，并进一步生成第二随机数并利用从终端证书中获取到的第二公钥对第二随机数进行加密。
步骤S805，推送服务器向第二推送客户端发送加密的第二随机数。
在图8a所示的实施情景中，协商两种密钥，分别是TEE会话密钥和REE会话密钥，则执行步骤S806～S810。可以理解的，TEE会话密钥被第二推送客户端存储于TEE的可信存储空间中，REE会话密钥被第一推送客户端存储于REE的存储空间中。
步骤S806，第二推送客户端使用第二公钥对应的第二私钥对加密的第二随机数进行解密以获取第二随机数，生成第三随机数和第四随机数并利用第一公钥对第三随机数和第四随机数进行加密。
第二推送客户端使用第二公钥对应的第二私钥对加密的第二随机数进行解密可以获取到第二随机数，并进一步生成第三随机数和第四随机数并利用第一公钥对第三随机数和第四随机数进行加密。
步骤S807，第二推送客户端向推送服务器发送加密的第三随机数和第四随机数。
步骤S808，第二推送客户端根据解密得到的第一随机数、第二随机数和本地生成的第三随机数生成REE会话密钥，根据解密得到的第一随机数、第二随机数和本地生成的第四随机数生成TEE会话密钥。
第二推送客户端根据预先约定的或者设置的加密算法，根据第一随机数、第二随机数和第三随机数生成REE会话密钥，根据第一随机数、第二随机数和第四随机数生成TEE会话密钥。其中，REE会话密钥即由第一推送客户端保存并使用的密钥，TEE会话密钥即由第二推送客户端保存并使用的密钥。
步骤S809，推送服务器根据解密得到的第一随机数、第二随机数和第三随机数生成REE会话密钥，根据解密得到的第一随机数、第二随机数和第四随机数生成TEE会话密钥。
推送服务器根据预先约定的或者设置的加密算法，根据第一随机数、第二随机数和第三随机数生成富环境会话密钥，根据第一随机数、第二随机数和第四随机数生成可信环境会话密钥。
需要说明的是，步骤S808和步骤S809中使用的加密算法为同一算法，具体的，第二推送客户端可以在密钥协商过程中或密钥协商过程之前，向推送服务器发送约定的加密算法，也可以是预先已经设定了第二推送客户端与推送服务器之间的加密算法。
步骤S810，第二推送客户端向第一推送客户端发送REE会话密钥。
第一推送客户端保存REE会话密钥以备后续使用。
在图8b所示的实施情景中，协商一种密钥即TEE会话密钥，则执行步骤S811～814。TEE会话密钥被第二推送客户端存储于TEE的可信存储空间中。
步骤S811，第二推送客户端使用第二公钥对应的第二私钥对加密的第二随机数进行解密以获取第二随机数，生成第三随机数并利用第一公钥对第三随机数进行加密。
步骤S812，第二推送客户端向推送服务器发送加密的第三随机数。
步骤S813，第二推送客户端根据解密得到的第一随机数、第二随机数和第三随机数生成TEE会话密钥。
步骤S814，推送服务器根据解密得到的第一随机数、第二随机数和第三随机数生成TEE会话密钥。
在另一种可能的实施情景中，第二推送客户端无法访问网络通信接口，不能够直接与推送服务器通信，因此需要通过第一推送客户端进行转发。因此，步骤S803可以包括：
步骤S8031，第二推送客户端向第一推送客户端发送加密的第一随机数、第一随机数的签名以及终端证书。
步骤S8032，第一推送客户端向推送服务器发送加密的第一随机数、第一随机数的签名以及终端证书。
步骤S805可以包括：
步骤S8051，推送服务器向第一推送客户端发送加密的第二随机数。
步骤S8052，第一推送客户端向第二推送客户端发送加密的第二随机数。
步骤S807可以包括：
步骤S8071，第二推送客户端向第一推送客户端发送加密的第三随机数和第四随机数。
步骤S8072，第一推送客户端向推送服务器发送加密的第三随机数和第四随机数。
步骤S812可以包括：
步骤S8121，第二推送客户端向第一推送客户端发送加密的第三随机数。
步骤S8122，第一推送客户端向推送服务器发送加密的第三随机数。
图9是本申请实施例中一种终端应用程序注册方法的流程示意图。在应用服务器通过推送服务器向终端的应用程序发送推送消息之前，终端以及在该终端上运行的某一应用程序都需要先在推送服务器上进行注册，从而推送服务器后续才可以向该终端的该应用程序发送推送数据。图9所示的实施例中，第一推送客户端为终端的REE中的推送客户端，第二推送客户端为终端的TEE中的推送客户端。具体方法包括：
步骤S901，终端的第一应用程序向第一推送客户端发送第一注册请求，所述第一注册请求中包括第一应用程序标识。
终端在完成对第一应用程序的安装并被用户登录成功后，可以向第一推送客户端发送第一注册请求，其中第一注册请求中包括第一应用程序标识，这里的第一应用程序标识可以指第一应用程序的名称或应用访问接口等，这里不作具体限定。
在一种可能的实施场景中，第一注册请求中还包括推送消息处理策略，消息处理策略可以用于指示第二推送客户端在后续获取到了推送数据后应该执行哪一种处理方法。具体来说，消息处理策略可以指示第二推送客户端将获取到的推送数据发送给第一应用程序对应的可信应用部分进行显示；消息处理策略也可以指示第二推送客户端在TEE中统一调用可信用户界面(TUI，Trusted User Interface)进行显示；消息处理策略还可以指示第二推送客户端拉起与之关联的设备，例如可穿戴设备等。
进一步的，终端在完成对第一应用程序的安装并被用户登录成功后，还可以从第一应用程序对应的第一应用服务器获取到授权码，用于后续身份验证。
步骤S902，第一推送客户端向第二推送客户端发送第一注册请求。
步骤S903，第二推送客户端根据第一注册请求向推送服务器发送第二注册请求，所述第二注册请求包括第一应用程序标识以及终端标识。
第二推送客户端在接收到第一注册请求之后，可以获取到第一应用程序标识并进一步添加终端标识，从而生成第二注册请求。其中，终端标识可以是终端的设备标识码或REE标识，在本申请实施例中，终端标识还可以是TEE标识。也就是说，第二推送客户端可以将其所在的TEE标识作为终端标识以及获取到的第一推送客户端所在的REE标识共同作为终端标识添加在第二注册请求中发送给推送服务器，也即在推送服务器中对应注册两种终端执行环境的推送服务。
步骤S904，推送服务器根据第一应用程序标识以及终端标识，生成终端应用标识。
推送服务器根据第一应用程序标识以及终端标识，就可以将两者关联从而得到一个与两者相关的终端应用标识，该终端应用标识可以表征发送第一注册请求的当前终端的第一应用程序。
在一种可能的实施场景中，推送服务器在生成终端应用标识之前，可以先根据第一应用程序标识判断推送服务器是否与第一应用程序对应的第一应用服务器签约。这里签约可以指推送服务器具备为第一应用服务器进行推送服务的权限。若已签约，则生成终端应用标识。
步骤S905，推送服务器向第一应用程序发送终端应用标识。
步骤S906，第一应用程序向第一应用程序对应的第一应用服务器发送终端应用标识以及预先从第一应用服务器获取到的授权码。
步骤S907，第一应用服务器确定授权码合法并将终端应用标识添加至推送服务列表。
第一应用服务器在接收到第一应用程序发送的授权码后，首先对其合法性进行验证，若验证成功，则可以将接收到的终端应用标识添加至推送服务列表。推送服务列表中的终端应用标识均为可以进行推送服务的终端，第一应用服务器在进行推送时，就根据推送服务列表中的终端应用标识，向各个终端进行推送服务。
进一步的，第一应用服务器还可以将终端应用标识与特定的用户进行关联，也即成功登陆第一应用程序的用户。
此时，第一应用程序以及其所在的终端完成注册，第一应用服务器以及推送服务器可以向第一应用程序所在的终端发送推送消息。
请参阅图10，图10是本申请实施例提供的一种终端的结构示意图。如图10所示，该终端包括第一推送客户端10和第二推送客户端20，所述第一推送客户端10包括第一收发模块101和第一处理模块102，所述第二推送客户端20包括第二收发模块201和第二处理模块202，其中：
所述第一收发模块101，用于接收推送服务器发送的推送消息，所述推送消息中包含安全级别指示标记和推送数据；
所述第一处理模块102，用于根据安全级别指示标记判断是否需要对所述推送消息进行处理；
所述第一收发模块101还用于：在确定不需要对所述推送消息进行处理时，向所述第 二收发模块转发所述推送数据；
所述第二收发模块201，用于接收所述推送数据；
所述第二处理模块202，用于对所述推送数据进行处理；
其中所述第一推送客户端为所述终端的第一运行环境中的推送客户端，所述第二推送客户端为所述终端的第二运行环境中的推送客户端。
可选的，所述安全级别指示标记包括第一安全级别标记或第二安全级别标记，所述第一安全级别标记用于指示所述推送数据由REE会话密钥加密；所述第二安全级别标记用于指示所述推送数据由可信执行环境TEE会话密钥加密。
在一种可能的实施场景中，所述第一运行环境为REE，所述第一推送客户端10为所述终端的REE中的推送客户端；所述第二运行环境为TEE，所述第二推送客户端20为所述终端的TEE中的推送客户端；
所述第一处理模块102具体用于：
若所述安全级别指示标记为所述第一安全级别标记，则所述第一处理模块102需要对所述推送消息进行处理；若所述安全级别指示标记为所述第二安全级别标记，则所述第一处理模块102不需要对所述推送消息进行处理。
可选的，所述第二处理模块202具体用于：
使用所述TEE会话密钥对所述推送数据进行解密。
可选的，所述TEE会话密钥为所述第二处理模块202和所述推送服务器根据所述第二处理模块生成的随机数和所述推送服务器生成的随机数协商确定的。
在另一种可能的实施场景中，所述第一运行环境为TEE，所述第一推送客户端10为所述终端的TEE中的推送客户端；所述第二运行环境为REE，所述第二推送客户端20为所述终端的REE中的推送客户端；
所述第一处理模块102具体用于：
若所述安全级别指示标记为第一安全级别标记，则所述第一处理模块102不需要对所述推送消息进行处理；若所述安全级别指示标记为第二安全级别标记，则所述第一处理模块102需要对所述推送消息进行处理。
可选的，所述第二处理模块202具体用于：
使用所述REE会话密钥对所述推送数据进行解密。
可选的，所述REE会话密钥为所述第一处理模块102和所述推送服务器根据所述第一处理模块102生成的随机数和所述推送服务器生成的随机数协商确定后发送给所述第二收发模块201的。
可选的，所述第一处理模块102还用于：
若确定需要对所述推送消息进行处理，则使用所述TEE会话密钥对所述推送数据进行解密并调用可信用户界面TUI显示解密后的推送数据或将解密后的推送数据保存于可信存储空间中。
可选的，所述推送消息由TEE会话密钥加密后生成。
在另一种可能的实施场景中，所述第一运行环境为TEE，所述第一推送客户端10为所述终端的TEE中的推送客户端；所述第二运行环境为REE，所述第二推送客户端20 为所述终端的REE中的推送客户端；
所述第一处理模块102还用于：
使用所述TEE会话密钥对所述推送消息进行解密以获取所述推送数据。
可选的，所述TEE会话密钥为所述第一处理模块102和所述推送服务器根据所述第一处理模块102生成的随机数和所述推送服务器生成的随机数协商确定的。
在另一种可能的实施场景中，所述第一运行环境为REE，所述第一推送客户端10为所述终端的REE中的推送客户端；所述第二运行环境为TEE，所述第二推送客户端20为所述终端的TEE中的推送客户端；
所述第一处理模块102具体用于：
若无法从所述推送消息中解密获得所述安全级别指示标记，则不需要对所述推送消息进行处理。
可选的，所述第二处理模块202具体用于：
使用所述TEE会话密钥对所述推送消息进行解密。
可选的，所述推送数据包括设备唤醒指示；
所述第一收发模块101具体用于：
向所述第二收发模块201转发所述设备唤醒指示；
所述第二处理模块202具体用于：
使用所述TEE会话密钥对所述设备唤醒指示进行解密，并根据所述设备唤醒指示与所述设备唤醒指示对应的第二设备建立连接。
可选的，所述推送数据包括设备唤醒指示；
所述第一处理模块102还用于：
若需要对所述推送消息进行处理，则使用所述TEE会话密钥对所述设备唤醒指示进行解密，并根据所述设备唤醒指示与所述设备唤醒指示对应的第二设备建立连接。
可选的，所述推送消息还包括推送对象标识；
所述第一收发模块101具体用于：
向所述第二收发模块201转发所述推送数据以及所述推送对象标识；
所述第二处理模块202还用于：
将所述推送数据发送给所述推送对象标识指示的目标应用程序。
可选的，所述第二处理模块202具体用于：
将所述推送数据发送给所述推送对象标识指示的与所述终端关联的第二设备上的目标应用程序。
图10所示的实施例，终端根据推送消息对应的安全级别，将推送消息中的推送数据发送至相应的推送客户端进行处理，避免安全级别较高的敏感信息在终端的处理过程中发送信息泄露，从而可以解决推送消息的安全处理问题。
图10所示实施例中的终端可以以图11所示的终端实现。请参阅图11，图11是本发明实施例提供的另一种终端的结构示意图。如图11所示，该终端包括处理器111、存储器112以及通信接口113。处理器111连接到存储器112和通信接口113，例如处理器111 可以通过总线连接到存储器112和通信接口113。
在本申请实施例中，处理器111用于实现图10所示的第一处理模块102和第二处理模块202的功能。通信接口113用于实现图10所示的第一收发模块101和第二收发模块201的功能。
其中，处理器111被配置为支持所述终端执行上述消息推送方法中相应的功能。该处理器111可以是中央处理器(英文：central processing unit，CPU)，网络处理器(英文：network processor，NP)，硬件芯片或者其任意组合。上述硬件芯片可以是专用集成电路(英文：application-specific integrated circuit，ASIC)，可编程逻辑器件(英文：programmable logic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(英文：complex programmable logic device，CPLD)，现场可编程逻辑门阵列(英文：field-programmable gate array，FPGA)，通用阵列逻辑(英文：generic array logic，GAL)或其任意组合。
存储器112存储器用于存储推送消息以及程序代码等。存储器112可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(英文：random access memory，缩写：RAM)；存储器112也可以包括非易失性存储器(英文：non-volatile memory)，例如只读存储器(英文：read-only memory，缩写：ROM)，快闪存储器(英文：flash memory)，硬盘(英文：hard disk drive，缩写：HDD)或固态硬盘(英文：solid-state drive，缩写：SSD)；存储器112还可以包括上述种类的存储器的组合。
通信接口113用于与推送服务器等设备收发上述方法中所涉及的消息。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。
以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。

Claims (37)

  1. 一种消息推送方法，其特征在于，包括：
    第一推送客户端接收推送服务器发送的推送消息，所述推送消息中包含安全级别指示标记和推送数据；
    所述第一推送客户端根据安全级别指示标记判断是否需要对所述推送消息进行处理；
    若确定不需要对所述推送消息进行处理，则所述第一推送客户端向第二推送客户端转发所述推送数据，以便所述第二推送客户端对所述推送数据进行处理；
    其中所述第一推送客户端为终端的第一运行环境中的推送客户端，所述第二推送客户端为所述终端的第二运行环境中的推送客户端。
  2. 如权利要求1所述的方法，其特征在于，所述安全级别指示标记包括第一安全级别标记或第二安全级别标记，所述第一安全级别标记用于指示所述推送数据由REE会话密钥加密；所述第二安全级别标记用于指示所述推送数据由可信执行环境TEE会话密钥加密。
  3. 如权利要求2所述的方法，其特征在于，所述第一运行环境为REE，所述第一推送客户端为所述终端的REE中的推送客户端；所述第二运行环境为TEE，所述第二推送客户端为所述终端的TEE中的推送客户端；
    所述第一推送客户端根据安全级别指示标记，判断是否需要对所述推送消息进行处理包括：
    若所述安全级别指示标记为所述第一安全级别标记，则所述第一推送客户端需要对所述推送消息进行处理；若所述安全级别指示标记为所述第二安全级别标记，则所述第一推送客户端不需要对所述推送消息进行处理。
  4. 如权利要求3所述的方法，其特征在于，所述第一推送客户端向第二推送客户端转发所述推送数据，以便所述第二推送客户端对所述推送数据进行处理包括：
    所述第一推送客户端向所述第二推送客户端转发所述推送数据，以便所述第二推送客户端使用所述TEE会话密钥对所述推送数据进行解密。
  5. 如权利要求3或4所述的方法，其特征在于，所述TEE会话密钥为所述第二推送客户端和所述推送服务器根据所述第二推送客户端生成的随机数和所述推送服务器生成的随机数协商确定的。
  6. 如权利要求2所述的方法，其特征在于，所述第一运行环境为TEE，所述第一推送客户端为所述终端的TEE中的推送客户端；所述第二运行环境为REE，所述第二推送客户端为所述终端的REE中的推送客户端；
    所述第一推送客户端根据安全级别指示标记，判断是否需要对所述推送消息进行处理包括：
    若所述安全级别指示标记为第一安全级别标记，则所述第一推送客户端不需要对所述推送消息进行处理；若所述安全级别指示标记为第二安全级别标记，则所述第一推送客户端需要对所述推送消息进行处理。
  7. 如权利要求6所述的方法，其特征在于，所述第一推送客户端向第二推送客户端转发所述推送数据，以便所述第二推送客户端对所述推送数据进行处理，包括：
    所述第一推送客户端向所述第二推送客户端转发所述推送数据，以便所述第二推送客户端使用所述REE会话密钥对所述推送数据进行解密。
  8. 如权利要求6或7所述的方法，其特征在于，所述REE会话密钥为所述第一推送客户端和所述推送服务器根据所述第一推送客户端生成的随机数和所述推送服务器生成的随机数协商确定后发送给所述第二推送客户端的。
  9. 如权利要求6-8任一项所述的方法，其特征在于，所述方法还包括：
    若所述第一推送客户端确定需要对所述推送消息进行处理，则所述第一推送客户端使用所述TEE会话密钥对所述推送数据进行解密并调用可信用户界面TUI显示解密后的推送数据或将解密后的推送数据保存于可信存储空间中。
  10. 如权利要求1所述的方法，其特征在于，所述推送消息由TEE会话密钥加密后生成。
  11. 如权利要求10所述的方法，其特征在于，所述第一运行环境为TEE，所述第一推送客户端为所述终端的TEE中的推送客户端；所述第二运行环境为REE，所述第二推送客户端为所述终端的REE中的推送客户端；
    所述第一推送客户端向第二推送客户端转发所述推送数据包括：
    所述第一推送客户端使用所述TEE会话密钥对所述推送消息进行解密以获取所述推送数据；
    所述第一推送客户端向第二推送客户端转发所述推送数据。
  12. 如权利要求11所述的方法，其特征在于，所述TEE会话密钥为所述第一推送客户端和所述推送服务器根据所述第一推送客户端生成的随机数和所述推送服务器生成的随机数协商确定的。
  13. 如权利要求10所述的方法，其特征在于，所述第一运行环境为REE，所述第一推送客户端为所述终端的REE中的推送客户端；所述第二运行环境为TEE，所述第二推送客户端为所述终端的TEE中的推送客户端；
    所述第一推送客户端根据安全级别指示标记判断是否需要对所述推送消息进行处理包括：
    若所述第一推送客户端无法从所述推送消息中解密获得所述安全级别指示标记，则所述第一推送客户端确定不需要对所述推送消息进行处理。
  14. 如权利要求13所述的方法，其特征在于，所述第一推送客户端向第二推送客户端转发所述推送数据包括：
    所述第一推送客户端向所述第二推送客户端转发所述推送消息，以便所述第二推送客户端使用所述TEE会话密钥对所述推送消息进行解密。
  15. 如权利要求3所述的方法，其特征在于，所述推送数据包括设备唤醒指示；
    所述第一推送客户端向第二推送客户端转发所述推送数据，以便所述第二推送客户端对所述推送数据进行处理包括：
    所述第一推送客户端向所述第二推送客户端转发所述设备唤醒指示，以便所述第二推送客户端使用所述TEE会话密钥对所述设备唤醒指示进行解密，并根据所述设备唤醒指示与所述设备唤醒指示对应的第二设备建立连接。
  16. 如权利要求6-8任一项所述的方法，其特征在于，所述推送数据包括设备唤醒指示；
    所述方法还包括：
    若所述第一推送客户端需要对所述推送消息进行处理，则所述第一推送客户端使用所述TEE会话密钥对所述设备唤醒指示进行解密，并根据所述设备唤醒指示与所述设备唤醒指示对应的第二设备建立连接。
  17. 如权利要求1-16任一项所述的方法，其特征在于，所述推送消息还包括推送对象标识；
    所述第一推送客户端向第二推送客户端转发所述推送数据，以便所述第二推送客户端对所述推送数据进行处理包括：
    所述第一推送客户端向所述第二推送客户端转发所述推送数据以及所述推送对象标识，所述推送对象标识被所述第二推送客户端用于将所述推送数据发送给所述推送对象标识指示的目标应用程序。
  18. 如权利要求17所述的方法，其特征在于，所述推送对象标识被所述第二推送客户端用于将所述推送数据发送给所述推送对象标识指示的与所述终端关联的第二设备上的目标应用程序。
  19. 一种消息推送方法，其特征在于，包括：
    第一推送客户端接收推送服务器发送的推送消息，所述推送消息中包含安全级别指示 标记和推送数据；
    所述第一推送客户端根据安全级别指示标记判断是否需要对所述推送消息进行处理；
    若不需要对所述推送消息进行处理，则所述第一推送客户端向第二推送客户端转发所述推送数据；
    所述第二推送客户端接收所述推送数据并对所述推送数据进行处理；
    其中所述第一推送客户端为终端的第一运行环境下的推送客户端，所述第二推送客户端为所述终端的第二运行环境下的推送客户端。
  20. 一种终端，其特征在于，所述终端包括第一推送客户端和第二推送客户端，所述第一推送客户端包括第一收发模块和第一处理模块，所述第二推送客户端包括第二收发模块和第二处理模块，其中：
    所述第一收发模块，用于接收推送服务器发送的推送消息，所述推送消息中包含安全级别指示标记和推送数据；
    所述第一处理模块，用于根据安全级别指示标记判断是否需要对所述推送消息进行处理；
    所述第一收发模块还用于：在确定不需要对所述推送消息进行处理时，向所述第二收发模块转发所述推送数据；
    所述第二收发模块，用于接收所述推送数据；
    所述第二处理模块，用于对所述推送数据进行处理；
    其中所述第一推送客户端为所述终端的第一运行环境中的推送客户端，所述第二推送客户端为所述终端的第二运行环境中的推送客户端。
  21. 如权利要求20所述的终端，其特征在于，所述安全级别指示标记包括第一安全级别标记或第二安全级别标记，所述第一安全级别标记用于指示所述推送数据由REE会话密钥加密；所述第二安全级别标记用于指示所述推送数据由可信执行环境TEE会话密钥加密。
  22. 如权利要求21所述的终端，其特征在于，所述第一运行环境为REE，所述第一推送客户端为所述终端的REE中的推送客户端；所述第二运行环境为TEE，所述第二推送客户端为所述终端的TEE中的推送客户端；
    所述第一处理模块具体用于：
    若所述安全级别指示标记为所述第一安全级别标记，则所述第一处理模块需要对所述推送消息进行处理；若所述安全级别指示标记为所述第二安全级别标记，则所述第一处理模块不需要对所述推送消息进行处理。
  23. 如权利要求22所述的终端，其特征在于，所述第二处理模块具体用于：
    使用所述TEE会话密钥对所述推送数据进行解密。
  24. 如权利要求22或23所述的终端，其特征在于，所述TEE会话密钥为所述第二处理模块和所述推送服务器根据所述第二处理模块生成的随机数和所述推送服务器生成的随机数协商确定的。
  25. 如权利要求21所述的终端，其特征在于，所述第一运行环境为TEE，所述第一推送客户端为所述终端的TEE中的推送客户端；所述第二运行环境为REE，所述第二推送客户端为所述终端的REE中的推送客户端；
    所述第一处理模块具体用于：
    若所述安全级别指示标记为第一安全级别标记，则所述第一处理模块不需要对所述推送消息进行处理；若所述安全级别指示标记为第二安全级别标记，则所述第一处理模块需要对所述推送消息进行处理。
  26. 如权利要求25所述的终端，其特征在于，所述第二处理模块具体用于：
    使用所述REE会话密钥对所述推送数据进行解密。
  27. 如权利要求25或26所述的终端，其特征在于，所述REE会话密钥为所述第一处理模块和所述推送服务器根据所述第一处理模块生成的随机数和所述推送服务器生成的随机数协商确定后发送给所述第二收发模块的。
  28. 如权利要求25-27任一项所述的终端，其特征在于，所述第一处理模块还用于：
    若确定需要对所述推送消息进行处理，则使用所述TEE会话密钥对所述推送数据进行解密并调用可信用户界面TUI显示解密后的推送数据或将解密后的推送数据保存于可信存储空间中。
  29. 如权利要求20所述的终端，其特征在于，所述推送消息由TEE会话密钥加密后生成。
  30. 如权利要求29所述的终端，其特征在于，所述第一运行环境为TEE，所述第一推送客户端为所述终端的TEE中的推送客户端；所述第二运行环境为REE，所述第二推送客户端为所述终端的REE中的推送客户端；
    所述第一处理模块还用于：
    使用所述TEE会话密钥对所述推送消息进行解密以获取所述推送数据。
  31. 如权利要求30所述的终端，其特征在于，所述TEE会话密钥为所述第一处理模块和所述推送服务器根据所述第一处理模块生成的随机数和所述推送服务器生成的随机数协商确定的。
  32. 如权利要求29所述的终端，其特征在于，所述第一运行环境为REE，所述第一 推送客户端为所述终端的REE中的推送客户端；所述第二运行环境为TEE，所述第二推送客户端为所述终端的TEE中的推送客户端；
    所述第一处理模块具体用于：
    若无法从所述推送消息中解密获得所述安全级别指示标记，则不需要对所述推送消息进行处理。
  33. 如权利要求32所述的终端，其特征在于，所述第二处理模块具体用于：
    使用所述TEE会话密钥对所述推送消息进行解密。
  34. 如权利要求22所述的终端，其特征在于，所述推送数据包括设备唤醒指示；
    所述第一收发模块具体用于：
    向所述第二收发模块转发所述设备唤醒指示；
    所述第二处理模块具体用于：
    使用所述TEE会话密钥对所述设备唤醒指示进行解密，并根据所述设备唤醒指示与所述设备唤醒指示对应的第二设备建立连接。
  35. 如权利要求25-27任一项所述的终端，其特征在于，所述推送数据包括设备唤醒指示；
    所述第一处理模块还用于：
    若需要对所述推送消息进行处理，则使用所述TEE会话密钥对所述设备唤醒指示进行解密，并根据所述设备唤醒指示与所述设备唤醒指示对应的第二设备建立连接。
  36. 如权利要求20-35任一项所述的终端，其特征在于，所述推送消息还包括推送对象标识；
    所述第一收发模块具体用于：
    向所述第二收发模块转发所述推送数据以及所述推送对象标识；
    所述第二处理模块还用于：
    将所述推送数据发送给所述推送对象标识指示的目标应用程序。
  37. 如权利要求36所述的终端，其特征在于，所述第二处理模块具体用于：
    将所述推送数据发送给所述推送对象标识指示的与所述终端关联的第二设备上的目标应用程序。
PCT/CN2017/075196 2016-11-14 2017-02-28 一种消息推送方法及终端 WO2018086279A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201780009070.5A CN108605046B (zh) 2016-11-14 2017-02-28 一种消息推送方法及终端
EP17868863.6A EP3447992B1 (en) 2016-11-14 2017-02-28 Message pushing method and terminal
US16/301,679 US11258871B2 (en) 2016-11-14 2017-02-28 Message push method and terminal

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201611000181.3 2016-11-14
CN201611000181 2016-11-14

Publications (1)

Publication Number Publication Date
WO2018086279A1 true WO2018086279A1 (zh) 2018-05-17

Family

ID=62109999

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/075196 WO2018086279A1 (zh) 2016-11-14 2017-02-28 一种消息推送方法及终端

Country Status (4)

Country Link
US (1) US11258871B2 (zh)
EP (1) EP3447992B1 (zh)
CN (1) CN108605046B (zh)
WO (1) WO2018086279A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI694701B (zh) * 2018-06-19 2020-05-21 大陸商中國銀聯股份有限公司 基於ｔｅｅ和ｒｅｅ的分離式切換方法及其系統

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220255735A1 (en) * 2021-02-08 2022-08-11 Visa International Service Association Blinding techniques for post-quantum public keys

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105592071A (zh) * 2015-11-16 2016-05-18 中国银联股份有限公司 一种在设备之间进行授权的方法和装置
CN105991287A (zh) * 2015-02-26 2016-10-05 阿里巴巴集团控股有限公司 一种签名数据的生成及指纹认证请求方法及装置
US20160321094A1 (en) * 2015-04-28 2016-11-03 Altera Corporation Network functions virtualization platforms with function chaining capabilities

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8064896B2 (en) 2009-03-09 2011-11-22 Apple Inc. Push notification service
CN102333105B (zh) * 2010-07-14 2014-02-19 华为技术有限公司 业务通信的方法、系统、推送客户端和用户设备
KR101637601B1 (ko) 2010-10-15 2016-07-07 삼성전자주식회사 모바일 메시지 수신 장치 및 방법
CN105279398A (zh) 2014-05-29 2016-01-27 宇龙计算机通信科技(深圳)有限公司 信息的保护方法、装置及终端
CN105450406B (zh) 2014-07-25 2018-10-02 华为技术有限公司 数据处理的方法和装置
CN105446713B (zh) 2014-08-13 2019-04-26 阿里巴巴集团控股有限公司 安全存储方法及设备
CN105590061B (zh) 2014-12-17 2018-09-21 中国银联股份有限公司 用于可信执行环境的安全操作系统更新方法
CN105991569A (zh) * 2015-02-09 2016-10-05 中国科学院信息工程研究所 一种tls通讯数据安全传输方法
KR102485830B1 (ko) * 2015-02-13 2023-01-09 삼성전자주식회사 보안 정보의 처리
CN105260663B (zh) 2015-09-15 2017-12-01 中国科学院信息工程研究所 一种基于TrustZone技术的安全存储服务系统及方法
CN105282149A (zh) 2015-09-16 2016-01-27 宇龙计算机通信科技(深圳)有限公司 数据处理方法、装置、终端、数据传输方法、装置和终端
CN105516104B (zh) 2015-12-01 2018-10-26 神州融安科技（北京）有限公司 一种基于tee的动态口令的身份验证方法及系统
CN105335673A (zh) 2015-12-14 2016-02-17 联想(北京)有限公司 一种信息安全处理方法和信息安全处理装置
CN105975867B (zh) 2016-04-28 2018-06-12 东莞市华睿电子科技有限公司 一种数据处理方法
US10225359B2 (en) * 2016-09-22 2019-03-05 International Business Machines Corporation Push notifications from multiple tenant servers

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105991287A (zh) * 2015-02-26 2016-10-05 阿里巴巴集团控股有限公司 一种签名数据的生成及指纹认证请求方法及装置
US20160321094A1 (en) * 2015-04-28 2016-11-03 Altera Corporation Network functions virtualization platforms with function chaining capabilities
CN105592071A (zh) * 2015-11-16 2016-05-18 中国银联股份有限公司 一种在设备之间进行授权的方法和装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI694701B (zh) * 2018-06-19 2020-05-21 大陸商中國銀聯股份有限公司 基於ｔｅｅ和ｒｅｅ的分離式切換方法及其系統

Also Published As

Publication number Publication date
EP3447992A1 (en) 2019-02-27
US20190289090A1 (en) 2019-09-19
CN108605046A (zh) 2018-09-28
EP3447992A4 (en) 2019-05-22
CN108605046B (zh) 2021-02-12
EP3447992B1 (en) 2020-09-23
US11258871B2 (en) 2022-02-22

Similar Documents

Publication Publication Date Title
CN110971415B (zh) 一种天地一体化空间信息网络匿名接入认证方法及系统
JP6923611B2 (ja) サービス層におけるコンテンツセキュリティ
US11902445B2 (en) System and method for enabling secure service-based communications via 5G proxies
JP5978759B2 (ja) サービス要求装置、サービス提供システム、サービス要求方法およびサービス要求プログラム
US20220353247A1 (en) Secure publish-subscribe communication methods and apparatus
EP3609291A1 (en) Method for restoring session, device and computer storage medium
US10680835B2 (en) Secure authentication of remote equipment
KR102433939B1 (ko) 무선 네트워크들에서 빠르고, 안전하며 프라이버시에 해가 되지 않는 인터넷 접속 발견을 위한 방법들
WO2019109852A1 (zh) 一种数据传输方法及系统
CN110769420B (zh) 网络接入方法、装置、终端、基站和可读存储介质
US11218317B1 (en) Secure enclave implementation of proxied cryptographic keys
WO2021089035A1 (zh) 一种签约数据的管理方法、装置
WO2021244569A1 (zh) 数据传输方法、系统、电子设备、存储介质
US10681085B2 (en) Quick transport layer security/secure sockets layer connection for internet of things devices
CA3160111A1 (en) Shared secret implementation of proxied cryptographic keys
EP3720042B1 (en) Method and device for determining trust state of tpm, and storage medium
WO2018086279A1 (zh) 一种消息推送方法及终端
US20230412568A1 (en) Header-based authentication in a virtual private network
WO2021082558A1 (zh) 网络切片的访问控制方法、装置及存储介质
JP2012138729A (ja) データ処理装置、プログラム、およびデータ処理システム
Mohamed et al. A Pre-shared Diffie-Hellman Key Exchange Scheme for a Secure TFTP Protocol

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2017868863

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017868863

Country of ref document: EP

Effective date: 20181121

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

Ref document number: 17868863

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE