CN111431707A - Service data information processing method, device, equipment and readable storage medium - Google Patents

Service data information processing method, device, equipment and readable storage medium Download PDF

Info

Publication number
CN111431707A
CN111431707A CN202010195893.5A CN202010195893A CN111431707A CN 111431707 A CN111431707 A CN 111431707A CN 202010195893 A CN202010195893 A CN 202010195893A CN 111431707 A CN111431707 A CN 111431707A
Authority
CN
China
Prior art keywords
trusted application
information
environment
target user
data information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010195893.5A
Other languages
Chinese (zh)
Other versions
CN111431707B (en
Inventor
李茂材
王宗友
张劲松
孔利
蓝虎
刘攀
刘区城
周开班
朱耿良
杨常青
廖志勇
崔嘉辉
时一防
黄焕坤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202010195893.5A priority Critical patent/CN111431707B/en
Publication of CN111431707A publication Critical patent/CN111431707A/en
Application granted granted Critical
Publication of CN111431707B publication Critical patent/CN111431707B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Storage Device Security (AREA)

Abstract

The application discloses a method, a device, equipment and a readable storage medium for processing service data information, wherein the method comprises the following steps: the first device deployed with the first trusted application environment can acquire service data information associated with a target user and write the service data information into the first trusted application environment; a first trusted application is deployed in the first trusted application environment; obtaining access information associated with a target user, accessing a first trusted application in a first trusted application environment based on the access information; signing the hash value of the service data information through a private key of a target user in the first trusted application to obtain signature information; the signature information is used for indicating the block chain node to write the service data information into the block chain when the signature information is successfully verified. The method and the device can ensure the security of private key acquisition and the reliability of uplink data.

Description

Service data information processing method, device, equipment and readable storage medium
Technical Field
The present application relates to the field of data processing technologies, and in particular, to a method, an apparatus, a device, and a readable storage medium for processing service data information.
Background
At present, before a user needs to request to write some service data information into a block chain, an uplink request associated with the service data information may be generated in a ue corresponding to the user, and the uplink request may carry signature information of the target user. It should be understood that the signature information is obtained by signing the service data information with a private key stored in the user terminal. Then, when an illegal user pretends that the target user illegally steals the private key stored in the user terminal, the service data information needing to be uplinked can be further signed, so that the authenticity of the service data information written in the block chain is difficult to guarantee. Therefore, in the prior art, by directly storing the private key of the target user in the user terminal, there may be a risk of private key leakage, so that the authenticity and reliability of the service data information needing to be uplinked cannot be ensured.
Disclosure of Invention
The application provides a method, a device, equipment and a readable storage medium for processing service data information, which can ensure the safety of data transmission and the reliability of data acquisition.
One aspect of the present application provides a method for processing service data information, where the method is executed by a first device deployed with a first trusted application environment, and the method includes:
acquiring service data information associated with a target user, and writing the service data information into a first trusted application environment; a first trusted application is deployed in the first trusted application environment;
obtaining access information associated with a target user, accessing a first trusted application in a first trusted application environment based on the access information;
signing the hash value of the service data information through a private key of a target user in the first trusted application to obtain signature information; the signature information is used for indicating the block chain node to write the service data information into the block chain when the signature information is successfully verified.
One aspect of the present application provides a service data information processing apparatus, where the apparatus operates in a first device deployed with a first trusted application environment, and includes:
the service data acquisition module is used for acquiring service data information associated with a target user and writing the service data information into a first trusted application environment; a first trusted application is deployed in the first trusted application environment;
an access information acquisition module for acquiring access information associated with a target user, accessing a first trusted application in a first trusted application environment based on the access information;
the private key signature module is used for signing the hash value of the business data information through a private key of a target user in the first trusted application to obtain signature information; the signature information is used for indicating the block chain node to write the service data information into the block chain when the signature information is successfully verified.
Wherein, the service data acquisition module comprises:
the first instruction acquisition unit is used for acquiring a first access instruction sent by second equipment corresponding to a target user through an encrypted transmission channel corresponding to a second trusted application environment; the first access instruction carries encrypted data information, and the encrypted data information is obtained by encrypting the service data information by the second equipment according to the shared secret key; the shared key is configured by a verification server associated with the second device for the first trusted application environment and the second trusted application environment;
the environment access unit is used for accessing the first trusted application environment through the shared key according to the first task carried in the first access instruction;
the first permission determining unit is used for determining that the target user has a first permission to access the first trusted application environment when the first trusted application environment is successfully accessed;
and the first writing unit is used for decrypting the encrypted data information based on the first authority to obtain the service data information associated with the target user, and writing the service data information into a first trusted application environment running a first trusted application.
Wherein, the service data acquisition module comprises:
the verification instruction sending unit is used for sending a verification instruction for verifying the running environment of the first trusted application environment to the verification server; the verification instruction is used for instructing the verification server to verify the legality of the certificate information of the first trusted application in the first trusted application environment; the verification server is further used for verifying the legality of the certificate information of the second trusted application in the second execution environment; the second trusted application environment is an operating environment deployed in second equipment corresponding to the target user;
the shared key returning unit is used for acquiring a shared key which is returned by the verification server and is associated with the first trusted application environment and the second trusted application environment when the verification server determines that the certificate information of the first trusted application is legal and the certificate information of the second trusted application is legal; the shared key is used for instructing the second device to send the first access instruction to the first device through an encrypted transmission channel corresponding to the shared key under the second trusted application environment.
Wherein, the service data acquisition module comprises:
a second instruction receiving unit, configured to receive a second access instruction sent by a first general application in a second device; the second access instruction is obtained by the first common application after hash locking is carried out on the service data information of the target user according to the environment public key of the first credible application environment; the environment public key is configured by the verification server for the first trusted application environment in the first device; the verification server is also used for configuring an environment private key corresponding to the environment public key for the first trusted application environment;
the Hash unlocking unit is used for unlocking the service data information after the Hash locking through an environment private key in the first credible application environment according to a second task carried in the second access instruction;
the second permission determining unit is used for obtaining the service data information when the unlocking is successful, and determining that the target user corresponding to the second device has a second permission to access the first trusted application environment;
and the second writing unit is used for writing the service data information into the first trusted application environment when the target user has the second right.
The first device further comprises a common application environment independent of the first trusted application environment, and the common application environment is provided with a second common application;
the service data acquisition module comprises:
the local instruction sending unit is used for controlling the second common application to send a local access instruction to the first trusted application environment in the first device when the target user logs in the second common application through the target account information; the local access instruction carries information of data to be processed; the data information to be processed is obtained by the second common application after hash locking is carried out on the service data information of the target user through the environment public key of the first credible application environment; the environment public key is returned to the second common application by the verification server when the first trusted application environment is determined to belong to the safe execution environment;
the environment private key acquisition unit is used for acquiring an environment private key returned to the first trusted application environment by the verification server according to a third task carried in the local access instruction;
the environment private key unlocking unit is used for carrying out Hash unlocking on the data information to be processed in the first trusted application environment through the environment private key;
and the third writing unit is used for obtaining the service data information of the target user when the unlocking is successful, and writing the service data information into the first trusted application environment running the first trusted application.
Wherein, the access information acquisition module includes:
the access authentication unit is used for acquiring access information input by a target user and carrying out access authentication on the target user in a first trusted application environment according to the access information;
the application access permission determining unit is used for successfully authenticating if the access serial number matched with the access information exists in the first trusted application environment, and determining that the target user has the permission to access the first trusted application; the access sequence number is determined by the first device according to user registration information submitted when the target user registers the first trusted application;
and the access authorization unit is used for authorizing the target user to access the first trusted application when the target user has the authority of accessing the first trusted application.
The first trusted application comprises a key generation subprogram;
the device still includes:
the user private key generation module is used for generating a private key of a target user based on a key generation rule by using a key generation rule associated with the key generation subprogram;
the private key storage module is used for storing the private key of the target user into a first memory corresponding to the first trusted application; the first memory is a trusted memory in the first trusted application environment.
Wherein, the service data information comprises electronic bill information;
the private key signature module comprises:
the encryption key generation unit is used for calling a key generation subprogram to generate an encryption key for encrypting the electronic bill information if the bill content matched with the private data information of the target user exists in the electronic bill information;
the encrypted data determining unit is used for encrypting the electronic bill information through the encryption key to obtain encrypted bill information;
the user private key acquisition module is used for acquiring a private key of a target user in a first memory of a first trusted application;
and the private key signature unit is used for signing the hash value of the encrypted bill information through a private key of the target user to obtain signature information of the target user.
Wherein, the device still includes:
the first returning module is used for returning the signature information to the second equipment through an encrypted transmission channel between the first trusted application environment and the second trusted application environment; the second equipment is used for generating a data uplink request corresponding to the service data information according to the signature information; the data uplink request is used for indicating a block link point in the block link network to write the service data information into a block link corresponding to the block link network when the signature information is successfully verified.
Wherein, the device still includes:
the second returning module is used for returning the signature information to a second common application in the first equipment;
a uplink request sending module, configured to add the signature information and the service data information to the data uplink request through a second common application, and send the data uplink request to a block chain node in a block chain network; the data uplink request is used for indicating the block chain node to write the service data information into the block chain when the signature information is successfully verified.
The first trusted application also comprises a secret key destroying subprogram;
the device still includes:
and the private key destroying module is used for destroying the private key of the target user in the first application through the private key destroying subprogram when the idle time of the first device reaches the idle threshold.
The first trusted application also comprises an address generation subprogram; the address generation subprogram is used for generating a plurality of address information associated with the target user; one address information corresponds to one public key, and one public key corresponds to one private key; the plurality of address information includes target address information; the target address information is used for storing asset information of a target user; the asset information comprises initial asset information which has a directional asset transfer relationship with a target client of a target user;
the device still includes:
the processing request acquisition module is used for acquiring a service processing request which is sent by a target user through target address information and aims at a target client;
the asset extraction module is used for extracting target asset information from the service processing request and decrypting the target asset information through a private key corresponding to the target address information to obtain initial asset information; the target asset information is obtained by performing Hash locking on the initial asset information by a target user through a public key corresponding to the target address information;
and the service data updating module is used for acquiring the asset transfer record corresponding to the initial asset information and updating the service data information associated with the target user through the asset transfer record.
An aspect of an embodiment of the present application provides a computer device, including: a processor, a memory, a network interface;
the processor is connected with the memory and the network interface, wherein the network interface is used for providing data communication functions, the memory is used for storing computer programs, and the processor is used for calling the computer programs to execute the method in one aspect of the embodiment of the application.
An aspect of the application provides a computer-readable storage medium having stored thereon a computer program comprising program instructions which, when executed by a processor, cause the processor to perform the method of the above-mentioned aspect.
In the embodiment of the application, a first trusted application environment is deployed on a first device, and at this time, the first device may acquire service data information associated with a target user and may write the service data information into the first trusted application environment; the first trusted application environment is deployed with a first trusted application; further, the first device may obtain access information associated with the target user and may access the first trusted application based on the access information in the first trusted application environment; further, the first device may sign the hash value of the service data information by using a private key of a target user in the first trusted application, so as to obtain signature information; the signature information may be used to indicate that the block chain node writes the service data information into the block chain when the signature information is successfully verified. Therefore, before the target user needs to uplink some service data information, the target user needing to access the first trusted application can be authenticated through the acquired access information, so that the target user is allowed to access the first trusted application when the authentication is successful, and the security of the private key of the target user stored in the first trusted application can be ensured as much as possible. Therefore, when the first device signs the service data information through the private key stored in the first trusted application, the security of obtaining the private key of the target user can be ensured, so that the authenticity and reliability of the signature information obtained by adopting the private key of the target user can be ensured, and the reliability of the service data information on a subsequent write-in chain can be further ensured. It should be understood that, since the first trusted application is deployed in the first trusted application environment, it is difficult for an illegal user to obtain the private key of the target user stored in the first trusted application, so that the risk of disclosure of the private key can be avoided as much as possible.
Drawings
In order to more clearly illustrate the technical solutions in the present application or the prior art, the drawings needed for the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1 is a schematic diagram of a blockchain network structure according to an embodiment of the present disclosure;
FIG. 2 is a schematic diagram of a data interaction scenario provided by an embodiment of the present application;
fig. 3 is a schematic flowchart of a service data information processing method provided in the present application;
fig. 4 is a schematic view of a scenario in which a trusted application environment in two devices is verified by a verification server according to an embodiment of the present application;
fig. 5 is a schematic view of a scenario in which a second access instruction is sent according to an embodiment of the present application;
fig. 6 is a schematic view of a scenario where service data information is obtained in the same terminal according to an embodiment of the present application;
fig. 7 is a schematic flowchart of a method for processing service data information according to an embodiment of the present application;
fig. 8 is a schematic view of a scenario in which data interaction is performed with a first trusted application through a second generic application according to an embodiment of the present application;
fig. 9 is a schematic structural diagram of a service data information processing apparatus provided in the present application;
fig. 10 is a schematic diagram of a computer device according to an embodiment of the present application.
Detailed Description
The technical solutions in the present application will be described clearly and completely with reference to the accompanying drawings in the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Please refer to fig. 1, which is a block chain network structure according to an embodiment of the present disclosure. The blockchain network structure shown in fig. 1 may be applied to a blockchain system, which may be a distributed system formed by a plurality of nodes connected by a form of network communication. The blockchain system may include, but is not limited to, a blockchain system corresponding to a federation chain.
The plurality of nodes shown in fig. 1 may specifically include a node 10a, a node 10b, a node 10c, and a node 10 d. As shown in fig. 1, the node 10a, the node 10b, and the node 10d may be respectively connected to the node 10c to form a blockchain network 100a shown in fig. 1. It is understood that in the blockchain network 100a, the nodes 10a, 10b, and 10d can perform data interaction through the network connection with the node 10 c. In addition, the server 4000a shown in fig. 1 may also be used for network connection with the node 10c, so that data interaction can be performed through the network connection with the server 4000 a. In addition, the user terminals 3000a, 3000b, 3000c,. and 3000n shown in fig. 1 may be respectively in network connection with the server 4000a, so that data interaction can be performed through the network connection with the server 4000 a.
In this embodiment, each node (e.g., node 10a, node 10b, node 10c, and node 10d) in the blockchain network 100a may be collectively referred to as a blockchain node. It should be appreciated that these blockchain nodes may be used To maintain the same blockchain (e.g., blockchain 10e shown in fig. 1), and any two blockchain nodes in the blockchain network 100a may form a point-To-point (P2P, Peer To Peer) network, and the point-To-point network may use a P2P Protocol, where the P2P Protocol is an application layer Protocol operating on top of a Transmission Control Protocol (TCP). In a distributed system, any device such as a server, a terminal, etc. may be added to form a blockchain node, where each blockchain node may include a hardware layer, an intermediate layer, an operating system layer, and an application layer.
It can be understood that, in the embodiment of the present application, a blockchain node may be bound for any role (for example, any individual user, any enterprise, any organization, and other entity objects) accessing the blockchain network structure, so that the blockchain network formed by the blockchain nodes is collectively referred to as a federation chain network. For example, the nodes 10a, 10b, 10c, and 10d shown in fig. 1 may be blockchain nodes in the alliance-chain network. For another example, the server 4000a, the user terminal 3000b,. the user terminal 3000n, etc. shown in fig. 1 may also be a block link point in the alliance-link network, which is not limited herein.
It can be understood that, as shown in fig. 1, the node 10a, the node 10b, the node 10c, the node 10d, and the like may respectively have a one-to-one correspondence relationship with corresponding roles (i.e., entity objects in corresponding service scenarios) that need to be accessed to the alliance-link network. The service scenario may specifically include an electronic bill scenario, a social scenario, a credit purchase scenario, a credit scenario, a payment scenario, and the like. At this time, the service data information in the corresponding service scene may specifically include electronic bill information in an electronic bill scene, data interaction information in a social scene, item order information in a credit purchase scene, loan data information in a credit scene, asset transition records in a payment scene, and the like, and specific contents of the service data information in the corresponding service scene are not listed one by one here.
For easy understanding, please refer to fig. 2, which is a schematic view of a data interaction scenario provided in an embodiment of the present application. As shown in fig. 2, the user terminal corresponding to the user a may be the second device 20a shown in fig. 2. As shown in fig. 2, the second device 20a runs the application 30a shown in fig. 2, and for convenience of understanding, in the embodiment of the present application, the application 30a running in the second device 20a may be collectively referred to as a target application associated with the service scenario, where the target application may include, but is not limited to: a social application (e.g., WeChat application, etc.) for issuing and reimbursing electronic tickets, a resource management application for financing public resources, a loan application for managing electronic resources, and a payment application for making material purchases, etc., where a target application running in the second device 20a will not be enumerated one by one.
For convenience of understanding, in the embodiment of the present application, the service scenario described above may be taken as an electronic ticket scenario as an example to illustrate a data interaction process between the second device 20a and the first device 20 b. In this embodiment of the present application, the user a shown in fig. 2 may be collectively referred to as a target user, and the target user may be a certain enterprise in the entity object. For example, in an electronic ticketing scenario, the business may be a billing business that issues electronic tickets. The business data information shown in fig. 2 may be electronic ticket information in an electronic ticket issued by the billing enterprise.
In order to maintain the legitimate rights of the parties associated with the electronic ticket (e.g., billing enterprise, purchaser, etc.), and to secure the electronic transaction, embodiments of the present application may store the private key of the user a (i.e., the private key of the target user, e.g., AAAA) in advance in the trusted application environment. For example, the private key of the user a shown in fig. 2 may be stored in the trusted application environment of the first device 20b shown in fig. 2, because the data stored in the trusted application environment in the embodiment of the present application is difficult to be illegally stolen by an external user, so the private key of the user a may be prevented from being stolen by an illegal user by the trusted application environment 40a shown in fig. 2, and further, the risk that the private key of the target user is leaked may be avoided.
Therein, it should be understood that the first device 20b shown in fig. 2 may be a terminal device independent of the second device 20 a. In the above electronic ticket scenario (which may also be referred to as a tax scenario associated with an electronic ticket), the application 30a running in the second device 20a may be the target application for issuing an electronic ticket.
It should be understood that the target application here may be a second trusted application deployed in another trusted application environment (i.e., a second trusted application environment) in the second device 20a, and optionally, the target application here may also be a first common application deployed in a common application environment (i.e., a first common application environment) in the second device 20 a. The specific existence of the target application will not be limited herein.
For the convenience of understanding, the application 30a shown in fig. 2 is taken as an example of the first general application to illustrate a specific process of data interaction between two different devices in the embodiment of the present application. Here, the user a shown in fig. 2 may perform a trigger operation on the display interface of the application 30a provided by the second device 20a, for example, the trigger operation may be performed on a "confirm" control on the display interface of the application 30a, so as to perform step S1 shown in fig. 2.
In this embodiment, the display interfaces of the application 30a may be collectively referred to as an application display interface. Since the first device 20b is a terminal device independent from the second device 20a, when the second device 20a responds to the trigger operation of the target user (i.e., the user a shown in fig. 2) for the application display interface shown in fig. 2, the access instruction associated with the service data information may be sent to the first device 20b shown in fig. 2 through the application 30a shown in fig. 2. It should be understood that at this point, the access instructions may be collectively referred to as remote access instructions for accessing the trusted application environment 40a in the first device 20 b.
At this time, since the application 30a is a common application (i.e., the first common application, for example, the invoicing application) running in the common application environment of the second device 20a, the first common application may store therein an environment public key (for example, an environment public key 1) allocated by the verification server for the trusted application environment 40a shown in fig. 2. Therefore, before executing step S1, the second device 20a may also lock the service data information (e.g., electronic ticket information) shown in fig. 2 by using the environment public key 1, and further may execute step S1 shown in fig. 2, so that, since the trusted application environment 40a stores therein a key pair (here, the key pair refers to the environment public key 1 and the environment private key 1 'corresponding to the environment public key 1) allocated by the verification server for the trusted application environment 40a, this means that the trusted application environment 40a in the first device 20b can decrypt the locked service data by using the environment private key 1' to obtain the service data information sent by the second device 20 a.
It is to be understood that, in the embodiment of the present application, the common application environments in the second device 20a may be collectively referred to as a first common application environment, and the common applications (for example, the application 30a shown in fig. 2) running in the first common application environment may be collectively referred to as a first common application. Furthermore, embodiments of the present application may collectively refer to the trusted application environment in the first device 20b (e.g., the trusted application environment 40a shown in fig. 2) as the first trusted application environment, and may collectively refer to the trusted application in the first trusted application environment (e.g., the application 30b shown in fig. 2) as the first trusted application. It should be understood that, alternatively, the first device 20b may also include a common application environment independent of the first trusted application environment, and in this embodiment, the common application environment of the first device 20b may be collectively referred to as a second common application environment, and common applications in the second common application environment may be collectively referred to as a second common application.
It is to be appreciated that, as shown in fig. 2, the access instruction transmitted by the second device 20a may be used to instruct the first device 20b to access the application 30b (i.e., the first trusted application) shown in fig. 2 based on the access information (e.g., fingerprint feature information, facial feature information, access serial number, etc.) of the target user when detecting that the target user (i.e., the user a) successfully accesses the trusted application environment 40a through the environment public key 1, so that the private key (e.g., AAAA) of the user a stored in the application 30b (i.e., the first trusted application) can be obtained when successfully accessing the first trusted application.
It is to be understood that the first device 20b, upon detecting that the target user successfully accesses the first trusted application (e.g., the application 30b) in the first trusted application environment, may further perform step S2 shown in fig. 2, that is, the service data information (e.g., the electronic ticket information) may be signed by the private key of the user a in the application 30b to obtain the signature information.
Further, the first device 20b may perform step S3 shown in fig. 2, i.e., may return the signature information to the second device 20a, to perform step S4 shown in fig. 2, i.e., may give a uplink request associated with the service data information (e.g., electronic ticket information) to a block link point (e.g., block link point 20c shown in fig. 2) in the above-mentioned federation chain network. It should be understood that the block link points in the federated chain network may include the block link point 20c shown in fig. 2, and may also include the block link points in the consensus network 200a shown in fig. 2, where the specific number of block link nodes in the federated chain network will be defined herein. It should be understood that the embodiments of the present application may collectively refer to the block link points in the consensus network as consensus nodes.
Further, as shown in fig. 2, after the block link point 20c obtains the uplink request, step S5 shown in fig. 2 may be executed, that is, the block link point 20c may extract signature information carried in the uplink request, and may send the signature information to the common node in the common network 200a, so that the validity of the uplink request sent by the second device 20a may be verified jointly by the common node. For example, the consensus node may perform a signature verification on the signature information carried in the uplink request based on the public key of the user a disclosed on the blockchain (e.g., the federation chain), and may return a signature verification result to the blockchain node 20c, so that the blockchain node 20c may determine whether to successfully verify the signature information based on the signature verification results. Once the block link point 20c determines that the signature information is successfully verified, it may be determined that the request initiator that needs to write the service data information into the block chain is actually the user a (i.e., the target user), so that the service data information uploaded by the second device 20a may be packaged into a block, and the packaged block may be written into the block chain corresponding to the federation chain network.
It can be understood that, since the application 30b shown in fig. 2 is deployed in the trusted application environment 40a shown in fig. 2, in the case that the trusted application environment 40a is a secure operating environment, it can be effectively ensured that the user data stored in the trusted application environment 40a (i.e., the secure operating environment) is not acquired by the external user. For example, the private key of the user a stored in the application 30b may be regarded as the private data information of the target user by the application 30b, so that the private data information may be stored in the trusted memory corresponding to the application 30b, and thus, it is difficult for an external user (e.g., an illegal user or the user a himself) to obtain the private key of the target user from the trusted memory of the application 30b, so that the security and reliability of the private key of the target user stored in the trusted application may be ensured.
Optionally, if the application 30a (i.e., the target application) shown in fig. 2 is a trusted application environment deployed in the second device 20a, the trusted application environment in the second device 20a may be collectively referred to as the second trusted application environment, and at this time, the application 30a deployed in the second device 20a may be collectively referred to as the second trusted application in this case. At this time, before data interaction is performed between the second trusted application environment of the first device 20a and the first trusted application environment of the first device 20b, the verification server needs to verify the security of the two trusted application environments, and then when it is determined that the two trusted application environments belong to the secure execution environment, a shared key for subsequent data interaction may be returned to the two terminal devices (i.e., the second device 20a and the first device 20 b). At this time, the second device 20a may perform encryption processing on the service data information by the shared key in the first terminal to add the encrypted service data information to the access instruction to be transmitted to the first device 20b before performing step S1. It should be understood that, at this time, the first device 20b may determine whether the shared key sent by the second trusted application environment in the second device 20a matches the shared key in the trusted application environment 40a (i.e., the first trusted application environment), and if so, allow the user a to access the trusted application environment 40a, and at the same time, the first device 20b may also decrypt the encrypted service data information through the shared key to obtain the service data information. Further, it is understood that the first device 20b may sign the service data information with the private key of the user a when the target user successfully accesses the application 30 b. Further, for a specific implementation manner of verifying the signature information uploaded by the second device 20a by the block link node, reference may be made to the above description of the second device 20a running the first common application, and details will not be further described here.
Alternatively, it is also understood that the application (e.g., the application 30a) for the invoicing electronic ticket may be integrated into the first device 20b, for example, the application 30a may be deployed in a second general application environment of the first device 20 b. At this time, the application 30a and the application 30b belong to two mutually independent applications in the same device. The application 30a may be a second common application in the first device 20b, and the application 30b may be a first trusted application in the first device 20 b. At this time, for a specific process of data interaction between the second common application and the first trusted application, reference may be made to the description of the process of data interaction between the first common application in the second device 20a and the first trusted application in the first device 20b, and details will not be further described here.
By analogy, for any one of other service scenarios, if the target user needs to write the corresponding service data information into the block chain 10e, the description of the process of performing data interaction between the target application in the electronic ticket scenario and the first trusted application (i.e., the application 30b) in the first trusted application environment (i.e., the trusted application environment 40a shown in fig. 2) may be referred to, and details will not be further described here. The first trusted application may be configured to implement a target task in a corresponding scenario, where the target task may specifically include a data encryption task, a signature task, a private key generation task, an address management task, and the like, and target services that can be implemented by the first trusted application are not listed one by one here.
The specific process of the first device 20b obtaining the private key of the target user and obtaining the signature information may be as follows with reference to the embodiments corresponding to fig. 3 to fig. 8.
Further, please refer to fig. 3, which is a flowchart illustrating a method for processing service data information according to the present application, as shown in fig. 3, the method may be applied to a first device, where the first device may be the terminal device deployed with the first trusted application environment, for example, the first device may be the first device 20b in the embodiment corresponding to fig. 2. The method may specifically comprise the following steps S101-S103.
Step S101, acquiring service data information associated with a target user, and writing the service data information into a first trusted application environment;
specifically, a service data information processing device may be operated on the first device in the embodiment of the present application, and the service data information processing device may be configured to acquire service data information associated with a target user. It is understood that the service data information processing apparatus in the embodiment of the present application may acquire service data information associated with a target user in the following various ways. The first device running the business data information processing apparatus may have a first trusted application environment deployed thereon, and a first trusted application for executing the target task is deployed in the first trusted application environment. Further, when the first device running with the service data information processing apparatus acquires the service data information, the service data information may also be written into the first trusted application environment, so that the following step S102 may be subsequently performed.
It can be understood that, in the embodiment of the present application, the service data processing apparatus may be integrated and run in a first device, where the first device may include, but is not limited to, a background service device of a user terminal used by a target user, and at this time, the user terminal used by the target user and independent of the background service device may be collectively referred to as a second device in the embodiment of the present application. It is understood that the second device in the embodiment of the present application may include, but is not limited to, a smart terminal having a data processing function (e.g., a remote data processing function), such as a smart phone, a tablet computer, a desktop computer, and the like.
It can be understood that, when the first device running with the service data information processing apparatus is independent of the second device corresponding to the target user and belongs to the background service device of the second device, the first device may be configured to obtain the remote access instruction sent by the second device (i.e., the user terminal held by the target user) through the target application. It should be understood that the remote access instruction sent by the target application in the embodiment of the present application may specifically include the following two types of access instructions: a first access instruction and a second access instruction.
The first access instruction may be sent by a second device deployed with a second trusted application environment through an encrypted transmission channel corresponding to the second trusted application environment. At this time, the target application running in the second device may be equivalent to the second trusted application running in the second trusted application environment described above. It should be understood that, before the second device sends the first access instruction to the first device through the second trusted application in the second trusted application environment, both the first device running the first trusted application environment and the second device running the second trusted application environment may send corresponding verification instructions to the verification server. For example, a check instruction (e.g., check instruction 1) sent by the first device may be used to check whether the execution environment of the first trusted application environment is a secure execution environment. Similarly, a check instruction (e.g., check instruction 2) sent by the second device may be used to check whether the execution environment of the second trusted application environment is a secure execution environment. Therefore, before data interaction is performed between the first device and the second device in the embodiment of the present application, security of the trusted application environment running in the respective terminal needs to be ensured through the verification server. The verification server may be a server provided by a service provider for implementing a remote verification service function.
For easy understanding, please refer to fig. 4, which is a schematic view of a scenario in which a trusted application environment in two devices is verified by a verification server according to an embodiment of the present application. The user M shown in fig. 4 may be the target user, and the device 50a held by the user M may be the second device. In addition, the device 60a shown in fig. 4 may be the first device described above independent of the second device. For convenience of understanding, in the embodiment of the present application, a service scenario is taken as the above-mentioned electronic ticket scenario, and then the electronic ticket a shown in fig. 4 may be the above-mentioned service data information. It should be understood that, before the user M needs to uplink the electronic ticket a, a first access instruction may be sent to the device 60a (i.e., the first device) shown in fig. 4, and the target task (i.e., the first task) carried in the first access instruction may be the signature task described above. It will be appreciated that the signing task is used to indicate that the device 60a shown in fig. 4 may access the first trusted application environment by means of the obtained shared key (here, the shared key sent by the device 50a via the trusted application environment 300 a).
It should be understood that, when the second trusted application environment and the first trusted application environment are each other secure execution environments, the shared key configured by the verification server for the trusted application environment of the two devices that currently need to perform data interaction may be the same, so that the shared key subsequently stored in the trusted application environments of the two devices is the same. At this time, the device 60a (i.e., the second device) may access the first trusted application environment through the obtained shared key, and further may determine that the user M (i.e., the target user) has the first right to access the first trusted application environment when the first trusted application environment is successfully accessed, so that the shared key stored in the trusted application environment 300b may be obtained based on the first right, and the obtained encrypted data information may be decrypted according to the shared key, so as to obtain the electronic ticket a (i.e., the above-mentioned service data information) associated with the target user. At this time, the device 60a (i.e., the first device) may write the electronic ticket a to the trusted application environment 300b to perform step S102 described below.
As shown in fig. 4, the trusted application environment 300b running in the device 60a (i.e., the first device) may be the first trusted application environment described above, in which the trusted application 400b shown in fig. 4 is deployed. For ease of understanding, embodiments of the present application may collectively refer to the trusted application 400b deployed in the first trusted application environment as the first trusted application described above. Similarly, as shown in fig. 4, the trusted application environment 300a running in the device 50a (i.e., the second device) may be the second trusted application environment described above, in which the trusted application 400a shown in fig. 4 is deployed. In addition, the trusted application 400a deployed in the second trusted application environment may also be collectively referred to as the second trusted application described above. It should be understood that when the first trusted application is deployed in the first trusted application environment and the second trusted application is deployed in the second trusted application environment, the first trusted application and the second trusted application to be deployed may be signed and issued with unique certificate information through the verification server. In order to distinguish the certificate information of the trusted applications in different trusted application environments, in the embodiment of the present application, the certificate information of the first trusted application stored in the first trusted application environment may be referred to as first certificate information, and the certificate information of the second trusted application stored in the second trusted application environment may be referred to as second certificate information.
Wherein, it should be understood that, before the data interaction between the first device (e.g., device 60a) and the second device (e.g., device 50a), the communication connection relationship between the first trusted application environment in the first device and the second trusted application environment in the second device can be established in a handshaking manner; the communication connection relation is obtained by a data transmission key which is determined by the first device and the second device together according to the key exchange rule provided by the verification server during handshaking. In other words, before data interaction between the first device and the second device, the first device may send a corresponding verification instruction to the verification server shown in fig. 4, so that the verification server, through the database shown in fig. 4, allows the first device and the second device to determine, through the data transmission key (here, the above-mentioned shared key), an encrypted transmission channel between the first trusted application environment (e.g., the trusted application environment 300b) and the second trusted application environment (e.g., the trusted application environment 300a) when the corresponding certificate information is successfully verified.
When the device 60a runs the trusted application environment 300b and the device 50a runs the trusted application environment 300a, the verification server shown in fig. 4 may obtain the verification instruction 1 sent by the device 60a (i.e., the first device) and may also obtain the verification instruction 2 sent by the device 50 a. It is understood that, in the embodiment of the present application, the verification server may obtain first certificate information corresponding to a first trusted application (e.g., the trusted application 400b) uploaded by the first device and second certificate information corresponding to a second trusted application (e.g., the trusted application 400a) uploaded by the second device, further, when the verification server determines that the first certificate information and the second certificate information exist in the certificate chain where the root certificate information is located, the validity of the first certificate information and the second certificate information can be determined, such that the first trusted application environment to which the first trusted application belongs and the second trusted application environment to which the second trusted application belongs can be indirectly determined to be secure execution environments, the first device and the second device may then be allowed to establish an encrypted transmission channel between the first trusted application environment and the second trusted application environment.
In other words, when the verification server completes the verification of the first trusted application environment to which the first trusted application belongs and the second trusted application environment to which the second trusted application belongs, the first device and the second device may both obtain the shared key configured by the verification server for the first trusted application environment and the second trusted application environment (for example, the data transmission key may be KKK). As shown in fig. 4, the second device may send the first access instruction shown in fig. 4 to the trusted application environment 300b (i.e., the second trusted application environment) in the first device through an encrypted transmission channel corresponding to the trusted application environment 300a (i.e., the second trusted application environment). The encrypted data information carried in the first access instruction is obtained by encrypting the service data information (e.g., the electronic ticket a shown in fig. 4) by the second device (i.e., the device 50a) according to the shared key (e.g., KKK); wherein the shared key is configured for the first trusted application environment and the second trusted application environment by a verification server associated with the second device.
Optionally, when the first device deployed with the first trusted application environment is independent of a second device corresponding to a target user and the second device is not deployed with the second trusted application environment, the target application may be deployed in a first common application environment of the second device, and the target applications deployed in the common application environments may be collectively referred to as the first common application, at this time, the second access instruction may be sent by the first common application in the second device for service data information in a corresponding service scenario.
It can be understood that, before the second device sends the second access instruction to the first device, if it is detected that the second trusted application environment is not deployed locally on the second device and certain service data information needs to be uplinked, the second access instruction may be sent to the first device through the first common application (where the second access instruction may be another remote access instruction). In this way, the specific process of the first device acquiring the service data information associated with the target user can be further described as follows: the first equipment receives a second access instruction sent by a first common application in the second equipment; the second access instruction is obtained by the first common application after performing hash locking on the service data information of the target user according to the environment public key of the first trusted application environment; the environment public key is configured by the verification server for the first trusted application environment in the first device; the verification server is also used for configuring an environment private key corresponding to the environment public key for the first trusted application environment; furthermore, the first device may unlock, in the first trusted application environment, the service data information after the hash locking through the environment private key according to a second task carried in the second access instruction, so that the service data information may be obtained when the unlocking is successful, and it may be determined that a target user corresponding to the second device has a second right to access the first trusted application environment; further, the first device may write the service data information into the first trusted application environment when the target user has the second right.
For easy understanding, please refer to fig. 5, which is a schematic view of a scenario for sending the second access instruction according to an embodiment of the present application. The device 50b shown in fig. 5 may be the second device, in which the first general application shown in fig. 5 runs, and it is understood that the first general application may be an application program for performing asset circulation in the environment of a general application running in the second device. For example, after the first general application shown in fig. 5 is used to instruct to transfer the electronic ticket B of the user N (i.e., the target user) from the account address of the user N to the account address of another user (e.g., the user M described above), an asset transfer record associated with the first general application may be generated. It should be understood that the asset transition record here refers to a record for transferring the electronic ticket B from the account address corresponding to the user N to the account address corresponding to the user M.
It will be appreciated that before user N writes the asset flow record shown in fig. 5 into the blockchain, user N (i.e., the target user) needs to obtain the signature information returned by device 60b via the second access instruction shown in fig. 5, and then may add the asset flow record and the signature information to the uplink request, so that the asset flow record may be written into the blockchain subsequently after the signature verification is successful.
Therein, it should be understood that the verification server shown in fig. 5 may obtain the verification instruction 3 sent by the first device (i.e. the device 60b) before the device 50b (the second device) shown in fig. 5 sends the second access instruction to the device 60b (the first device running the first trusted application environment) shown in fig. 5 through the first normal application. It should be understood that the verification instruction 3 herein may be used to instruct the verification server to verify the validity of the certificate information (i.e., the above-mentioned first certificate information) of the first trusted application uploaded by the device 60b (i.e., the first device) by acquiring the certificate information associated with the certificate chain from the database shown in fig. 5 and by using the acquired certificate information. It will be appreciated that when the verification server determines that there is certificate information matching the first certificate information on the certificate chain stored in the database, the validity of the first certificate information uploaded by the device 60d (i.e., the first device) may be determined, and thus the security of the first trusted application environment running the first trusted application may be indirectly determined.
It should be appreciated that the environment key pair shown in fig. 5 may be configured for the first trusted application environment shown in fig. 5 when the verification server determines that the first trusted application environment belongs to the secure execution environment. The environment key pair here may include an environment public key 101a shown in fig. 5 and an environment private key 101b shown in fig. 5. It will be appreciated that the device 60a in which the first trusted application environment is deployed may have stored therein a pair of environment keys returned by the verification server described above. Further, as shown in fig. 5, the device 60b (i.e., the first device) may also send the environment public key 101a to the device 50b (i.e., the second device) running the first common application shown in fig. 5. At this time, the device 50b may send the second access instruction shown in fig. 5 after performing hash locking on the service data information (e.g., the asset flow record shown in fig. 5) based on the environment public key 101a, so that when acquiring the second access instruction, the device 60b (i.e., the first device) may unlock, in the first trusted application environment, the hash-locked service data information (i.e., the hash-locked asset flow record) by using the environment private key 101b based on a target task (e.g., the second task may be the signature task) carried in the second access instruction, so as to obtain the service data information when the unlocking is successful, and may determine that a target user (e.g., the user N) corresponding to the device 50b has a second right to access the first trusted application environment. Further, the device 60b may write the service data information into the first trusted application environment based on the second authority, so that the following step S102 may be performed subsequently.
Optionally, in the embodiment of the present application, while the first trusted application environment is deployed in the first device, a second common application environment for running the target application may also be deployed together. The target application (e.g., the common application) running in the second common application environment may be collectively referred to as the second common application in the embodiments of the present application. At this time, it may be understood that, in the embodiment of the present application, a local access instruction may be sent to the first trusted application environment by a second general application in the same device (for convenience of distinction, the embodiment of the present application may collectively refer to the local access instruction sent by the second general application as a third access instruction), and then, the first trusted application environment in the first device may quickly acquire service data information associated with the target user based on the local access instruction.
For easy understanding, please refer to fig. 6, which is a schematic view of a scenario in which service data information is obtained in the same terminal according to an embodiment of the present application. The device 50c shown in fig. 6 may be the first device. In order to distinguish from the common application environment in the second device, in the embodiment of the present application, the common application environment in the first device may be referred to as a second common application environment, for example, the second common application environment may be a common execution environment corresponding to the common memory 504 shown in fig. 6. As shown in fig. 6, the embodiment of the present application may collectively refer to the common applications 505b running in the second common application environment as second common applications; the trusted applications 505a running in the secure execution environment (i.e., the first trusted application environment) corresponding to the trusted memory 503 are collectively referred to as a first trusted application. As shown in fig. 6, since the first trusted application and the second generic application are both deployed in the same device (i.e., the device 50c shown in fig. 6), when the second generic application needs to invoke the first trusted application, a local access instruction may be sent to the trusted application 505a shown in fig. 6 through the generic application 505b shown in fig. 6. The local access instruction can carry information of data to be processed; the to-be-processed data information is obtained by a second common application (e.g., the common application 505b) after hash-locking the service data information of the target user through an environment public key (e.g., the environment public key 1) of a first trusted application environment (e.g., the trusted application environment 500a shown in fig. 6); the environment public key (e.g., environment public key 1) is returned by the verification server to the second generic application (e.g., generic application 505b) upon determining that the first trusted application environment (e.g., trusted application environment 500a) belongs to the secure execution environment.
It is understood that the processor 501a shown in fig. 6 may be configured to read a local access instruction that needs to be sent by the general application 505b, and may cache the local access instruction into the cache memory 501b shown in fig. 6, so that when the addressor 501c shown in fig. 6 acquires the local access instruction, the trusted application environment 500a shown in fig. 6 may be accessed through the environment public key 1 based on the third task carried by the local access instruction, and further, when the trusted application environment 500a (i.e., the first trusted application environment) is successfully accessed, the environment private key (e.g., the environment private key 1') returned by the verification server to the first trusted application environment may be obtained to hash the to-be-processed data information, so that when the unlocking is successful, the business data information of the user M (i.e., the target user) shown in fig. 6 may be obtained, so that the service data information can be written into the trusted application environment 500a shown in fig. 6 to execute the following step S102.
Therefore, when the business data information associated with the target user is obtained, different forms of access can be realized according to the corresponding access mechanisms, and the safety and reliability of data access can be improved based on the different access mechanisms.
Step S102, obtaining access information associated with a target user, and accessing a first trusted application in a first trusted application environment based on the access information;
specifically, the first device may obtain access information entered by the target user, and may perform access authentication on the target user according to the access information in the first trusted application environment; if the access serial number matched with the access information exists in the first trusted application environment, the authentication is successful, and the first device can further determine that the target user has the authority of accessing the first trusted application; wherein the access sequence number is determined by the first device based on user registration information submitted when the target user registers the first trusted application. Further, the first device may authorize the target user to access the first trusted application when the target user has permission to access the first trusted application.
For convenience of understanding, in the embodiment of the present application, the device 50a and the device 50b in the embodiment corresponding to fig. 4 are taken as an example, and it may be understood that, after the first device completes the step S101, the access information entered by the user M (i.e., the target user) in the display interface corresponding to the second trusted application (e.g., the trusted application 400a shown in fig. 4) before sending the first access instruction may be acquired, for example, the access information may be an access serial number (e.g., an account password, fingerprint information, iris information, and the like) determined when the first device registers the user M with the user registration information (e.g., a user account) submitted when registering the first trusted application. Further, when the target user successfully accesses the trusted application environment 300b, the access information entered by the target user may be obtained, and the target user may be further authenticated based on the access information, which is understood to be mainly to determine whether the target user (e.g., the user M) has the authority to access the first trusted application (e.g., whether the user M has the authority to access the trusted application 400 b). It can be understood that, if the first device finds the access serial number matching the access information in the first trusted execution environment, it may be determined that the authentication is successful, that is, it may be determined that the target user has the right to access the first trusted application. Further, the device 60a (i.e., the first device) may authorize the target user to access the first trusted application (e.g., authorize the user M to access the trusted application 400b) when it is determined that the target user has the right to access the first trusted application, so as to further perform the following step S103.
It should be understood that, for a specific implementation manner of obtaining the access information associated with the target user in the other two manners, reference may be made to the description of obtaining the access information associated with the target user in the first access instruction, and details will not be further described here.
Step S103, signing the hash value of the service data information through a private key of a target user in the first trusted application to obtain signature information; the signature information is used for indicating the block chain node to write the service data information into the block chain when the signature information is successfully verified.
It is understood that, when detecting that the user M shown in fig. 4 successfully accesses the trusted application 400b in the trusted application environment 300b, the first device (for example, the device 60a shown in fig. 4) may obtain the private key of the user M stored in the trusted application 400b, and then may sign the electronic ticket a (i.e., the service data information) shown in fig. 4 through the private key of the user M to obtain the signature information shown in fig. 4. As shown in fig. 4, the device 60a (i.e., the first device) may further return the signature information obtained after the signature to the device 50a (i.e., the second device), so that after the signature information is obtained, the second device may further add the obtained signature information and the service data information to the uplink request, and further may send the uplink request to the block link point in the block link network, for example, may send the uplink request to the block link point 20c shown in fig. 2, so that the block link node 20c may forward the signature information carried in the uplink request to a common node belonging to the same block link network as the block link point 20c, where the common node may be the block link point in the common network 200a in the embodiment corresponding to fig. 2.
It is to be understood that, after acquiring the signature information, the consensus node herein may perform signature verification on the signature information based on the public key of the target user (for example, the public key of the user M shown in fig. 4) disclosed on the blockchain, so as to determine whether a request initiator sending the uplink request is the user M. It is understood that the block chain node 20c may obtain the signature verification results returned by the common identification nodes, and if more than half of the signature verification results exist in the signature verification results, the block chain node 20c may determine to successfully verify the authenticity of the signature information, so that the service data corresponding to the signature information may be packaged into the block writing block chain.
Optionally, it can be understood that, in the electronic bill scenario, the service data information may be electronic bill information in an electronic bill. It can be understood that, after the first device completes the steps S101 and S102, it may further identify whether the electronic ticket information in the electronic ticket has the private data information of the target user through the first trusted application. If the electronic bill information of the electronic bill has the bill content matched with the private data information of the target user, a key generation subprogram in the first trusted application can be called to generate an encryption key for encrypting the electronic bill information. Further, the first device can encrypt the electronic bill information through the encryption key to obtain encrypted bill information; further, the first device may obtain a private key of the target user in the first memory of the first trusted application, and may further sign the hash value of the encrypted ticket information through the private key of the target user to obtain the signature information of the target user. At this time, the first device may return the signature information and the encrypted ticket information to the second device, so that a subsequent target user may request to write the encrypted ticket information to the blockchain to ensure privacy of user data stored on the blockchain.
It should be understood that, when the second trusted application environment is deployed in the second device, the first device may return the signature information to the second device through the encrypted transmission channel between the first trusted application environment and the second trusted application environment. Specifically, reference may be made to the description of the returned signature information in the embodiment corresponding to fig. 4, which will not be described again here. In addition, it can be understood that, at this time, a decryption key for decrypting the encryption key may be stored in the second trusted application of the second device, and thus, after the second device acquires the encrypted ticket information through the encrypted transmission channel, the acquired encrypted ticket information may be decrypted in the second trusted application of the second device through the decryption key, and thus, the decrypted electronic ticket information may be written into the trusted memory corresponding to the second trusted application, so that the difficulty of an external illegal user illegally stealing the personal private data information of the target user is greatly increased, and the security of the personal private data information stored in the trusted memory of the second trusted application may be further avoided.
Optionally, if the second trusted application environment is not deployed in the second device, the first device may return the signature information to a first general application (for example, the first general application in the embodiment corresponding to fig. 5) in the second device, and further may add the signature information and the service data information to the data uplink request through the first general application, and further may send the data uplink request to a block chain node in a block chain network; it is to be understood that the uplink data request herein may be used to instruct the blockchain node to write the service data information (e.g., the asset transition record in the embodiment corresponding to fig. 5) into the blockchain when the signature information is successfully verified.
Optionally, for the embodiment corresponding to fig. 6, because the signing task indicated by the local access instruction is to sign locally on the first device, after the first trusted application in the first device obtains the signature information, the signature information may be returned to a second common application belonging to the same device, so that the first device may continue to add the signature information and the service data information to the data uplink request through the second common application, and further may send the data uplink request to the blockchain node in the blockchain network; at this time, the data uplink request may be used to instruct the blockchain node to write the service data information into the blockchain when the signature information is successfully verified.
In the embodiment of the application, before the target user needs to uplink some service data information, the target user needing to access the first trusted application may be authenticated through the acquired access information, so that when the authentication is successful, the target user is allowed to access the first trusted application, and thus, the security of the private key of the target user stored in the first trusted application may be ensured as much as possible. Therefore, when the first device signs the service data information through the private key stored in the first trusted application, the security of obtaining the private key of the target user can be ensured, so that the authenticity and reliability of the signature information obtained by adopting the private key of the target user can be ensured, and the reliability of the service data information on a subsequent write-in chain can be further ensured. It should be understood that, since the first trusted application is deployed in the first trusted application environment, it is difficult for an illegal user to obtain the private key of the target user stored in the first trusted application, so that the risk of disclosure of the private key can be avoided as much as possible.
Further, please refer to fig. 7, which is a flowchart timing chart of a method for processing service data information according to an embodiment of the present application. As shown in fig. 7, the method may be performed by a first device deployed with a first trusted application environment. The first device may be a user terminal (for example, the user terminal 3000a) integrated with the service data processing apparatus in any one of the block chain networks 100a shown in fig. 1. It can be understood that, when the service data processing apparatus is integrated in a user terminal in the embodiments of the present application, the user terminal integrated with the service data processing apparatus may be collectively referred to as a first device. At this time, the embodiment of the present application may roughly divide the execution environment of the first device into a first trusted application environment and a second normal application environment. It is to be understood that the second generic application environment herein refers to an execution environment running in the first device. In the first device, the second general application environment may be independent from the first trusted application environment, and the second general application environment includes a second general application, for example, the second general application may be the general application 505b in the embodiment corresponding to fig. 6. As shown in fig. 7, the method specifically includes the following steps S201 to S208:
step S201, when the target user logs in the second common application through the target account information, controlling, in the first device, the second common application to send a local access instruction to the first trusted application environment.
The local access instruction can carry information of data to be processed; the data information to be processed is obtained by the second common application after hash locking is carried out on the service data information of the target user through the environment public key of the first credible application environment; and the environment public key is returned to the second common application by the verification server when the first trusted application environment is determined to belong to the safe execution environment.
Step S202, according to a third task carried in the local access instruction, an environment private key returned to the first trusted application environment by the verification server is obtained;
it can be understood that, when the user terminal used by the target user and the background server corresponding to the user terminal belong to the same device (for example, the first device), the check server may be configured to receive the check instruction uploaded by the first device (for example, taking the device 50c in the embodiment corresponding to fig. 6 as an example, the check instruction 4 uploaded by the device 50c may be acquired). Similarly, at this time, the verification server may be configured to verify the security of the first trusted application environment running with the first trusted application based on the certificate information of the first trusted application carried in the verification instruction. It can be understood that, if the verification server finds out that the certificate information matching the certificate information of the first trusted application exists on the certificate chain of the database, it can be determined that the certificate information of the first trusted application is not tampered by an illegal user, so that it can be indirectly reflected that the first trusted application environment running with the first trusted application belongs to the secure execution environment.
It is to be understood that, when the verification server determines the security of the first trusted application environment, a corresponding environment key pair may be configured for the first trusted application environment, and the environment key pair may be returned to the first trusted application environment for storage, that is, the first trusted application environment in the first device may obtain the environment private key and the environment private key returned by the verification server. Further, the first device may further send, through a first trusted application in the first trusted application environment, the environment public key in the environment key pair to a second common application that is to access the first trusted application environment.
For easy understanding, please refer to fig. 8, which is a schematic view of a scenario in which data interaction is performed between a first trusted application and a second generic application according to an embodiment of the present application. As shown in fig. 8, a second common application is deployed in the common memory, and it can be understood that the common memory may be a data storage space corresponding to the common application running in the second trusted application environment. It is understood that, as shown in fig. 8, the second generic application may access the first trusted application environment shown in fig. 8 through a local call function in the second generic application, so that after the first trusted application environment is successfully accessed, the environment private key returned to the first trusted application environment by the verification server may be obtained according to the third task carried in the local access instruction, so that the following step S203 may be performed continuously.
Step S203, performing hash unlocking on the data information to be processed in the first trusted application environment through an environment private key;
and step S204, when the unlocking is successful, obtaining the service data information of the target user, and writing the service data information into a first trusted application environment running with a first trusted application.
Step S205, obtaining access information associated with the target user, and accessing the first trusted application in the first trusted application environment based on the access information.
As shown in fig. 8, when the target user successfully accesses the first trusted application environment, the access information associated with the target user and carried in the local call instruction may be acquired. Further, in the embodiment of the present application, in the first trusted application environment, the address of the memory encryption engine located in the first trusted application environment shown in fig. 8 may be obtained, and then the access information may be sent to the first trusted application shown in fig. 8 by an address request of the memory encryption engine.
It is to be understood that the access information may be determined by the user registration pheromone submitted when the target user registers the first trusted application. The access information may include, but is not limited to, fingerprint information submitted by the target user through the second general application, an access serial number, iris features, and the like. At this time, the first device may perform access authentication on the target user according to the access information in the first trusted application environment, so that when it is determined that the access serial number matched with the access information exists in the first trusted application environment, it is determined that the authentication is successful, that is, at this time, the first device may determine that the target user corresponding to the second common application has the right to access the first trusted application. Therefore, as shown in fig. 8, the first device may authorize the target user to access the first trusted application, so that step S206 may be performed, where corresponding tasks, such as a signing task, an encryption task, and the like, may be implemented by the first trusted application.
It can be understood that, in the embodiment of the present application, another data storage space formed by the memory encryption engine and the trusted memory of fig. 8 may be referred to as the trusted memory shown in fig. 8, where a first trusted application including a plurality of sub-programs is deployed in the trusted memory. As shown in fig. 8, the plurality of subroutines may include subroutine 1, subroutine 2, subroutine 3. These subroutines may be used to accomplish certain of the tasks specified above.
The sub-program 1 may be the key generation sub-program, and the key generation sub-program may be configured to generate the private key of the target user, and may store the private key of the target user in a first memory (e.g., the trusted memory shown in fig. 8) corresponding to the first trusted application. Optionally, the sub-program 1 (for example, the key generation sub-program) may also be configured to generate an encryption key of the first trusted application, so that when the first device recognizes, through the first trusted application, that there is data that matches the private data information of the target user in the service data information, the sub-program 1 may be invoked to generate an encryption key for encrypting the service data information (for example, the electronic ticket information).
Where subroutine 2 may be used to generate the address of the target user. It is understood that a target user in the embodiment of the present application may have multiple addresses (e.g., address a, address B,. and address C), each of which may be used for different customer groups, for example, taking the business data information as the above-mentioned electronic ticket information, address a may be used for asset transfer to customer 1 on the blockchain, address B may be used for asset transfer to customer 2 on the blockchain,. and address C may be used for asset transfer to customer 3 on the blockchain, and so on. It should be understood that, when generating the address a, the sub-program 2 also generates a public key (e.g., the public key 11) and a private key (e.g., the private key 12) associated with the address a. Further, the first device may return the address a and the public key 11 to the target user through the first trusted application shown in fig. 8. The address a may be used to store the asset information of the target user, where the asset information may specifically include initial asset information having a directed asset transfer relationship with the client 1. In this way, the target user can quickly select an account address to be subjected to asset transfer in an account interface of the target user as target address information, and then customers to receive the asset information can be collectively called as target customers.
The subprogram 3 may be an address management subprogram, which may be configured to perform account management on a plurality of addresses generated by the subprogram 2, so that when a target user transfers certain electronic bill information (i.e., the initial asset information) to a client 1 (i.e., a target client) in an address a (i.e., the target address information), the subprogram 3 may be invoked according to an obtained service processing request, so as to determine, by the subprogram 3, a private key (e.g., the private key 12) that matches the target address information, so that the initial asset information after hash locking (here, the target asset information obtained after hash locking the initial asset information by the public key 11) may be unlocked by the private key 12, and further, the initial asset information may be obtained in case that unlocking is successful, and at the same time, the target user can also be proved to be the initial asset information under the address a really owned by the target user, since the target user needs to transfer the initial asset information to the client 1 in a targeted manner to obtain the asset transition record corresponding to the initial asset information, the service data information associated with the target user can be updated by the asset transition record, so that the asset transition record can be requested to be written into the block chain after the signature of the asset transition record is completed. It can be understood that, when the initial asset information is transferred to the client 1, the first device may further perform new hash locking on the initial asset information through the public key of the client 1 (i.e., the target user), so that a double-flower phenomenon may be prevented, and therefore, the subsequent client 1 may perform hash decryption on the newly locked initial asset information through a corresponding private key stored in its terminal, so as to obtain a new asset circulation record subsequently.
Among them, the subroutine 4 may be a key consumption subroutine. The key consumption subroutine may be configured to consume, by the subroutine 4 (i.e., the key consumption subroutine), the private key of the target user stored in the first trusted application when the idle duration of the first device reaches the idle threshold, so as to ensure the security of the private key of the target user. Optionally, it may be understood that, when the target user no longer uses the first device, a destroy instruction may be further sent to the first trusted application program through a common application in the second device, and at this time, the first trusted application program may invoke the subroutine 4 to destroy the private key of the target user based on the consume instruction.
It can be understood that, as shown in fig. 8, in the embodiment of the present application, by dividing a protected area in the data storage space of the first device as a trusted application environment, confidentiality and integrity protection can be provided for corresponding codes and data stored in the trusted memory, so that the corresponding codes and data can be protected from being damaged by malware having special rights (for example, the external application program shown in fig. 8 does not have the right to access the trusted application). In addition, according to the embodiment of the application, the first device is divided into two types of execution environments, that is, a first trusted application environment (which may also be referred to as a secure environment) and a second common application environment (which may also be referred to as a common environment), so that a secure service can be provided for trusted applications for protecting personal private data information, and further resources located in the secure environment are not accessed by components of the common environment, so that isolation of data resources can be achieved in the same device.
Therefore, according to the embodiment of the application, it can be ensured that the application programs outside the first trusted application environment cannot access the trusted memory shown in fig. 8, and the application programs inside the first trusted application environment can access the data storage space belonging to the application programs, so that the trusted application running inside the corresponding trusted application environment can be effectively prevented from stealing the private information and tampering by other malicious software.
Step S206, the hash value of the service data information is signed through the private key of the target user in the first trusted application, and signature information is obtained.
Step S207, the signature information is returned to the second common application in the first device;
as shown in fig. 8, after the first device calls the subprogram 1 in the first trusted application to complete the signing task, the signing information may be directly returned to the second generic application shown in fig. 8, so that the second generic application may continue to perform step S208 described below.
Step S208, signature information and service data information are added to the data uplink request through a second common application, and the data uplink request is sent to a block chain node in a block chain network;
the data uplink request may be used to instruct the blockchain node to write the service data information into the blockchain when the signature information is successfully verified.
It is to be understood that each sub program in the first trusted memory may be regarded as a sub trusted application independent of each other, and the access of the sub trusted application in the embodiment of the present application may be determined based on a target task in an access instruction (e.g., the above local access instruction) sent by the second general application. The target task may include the signature task, the private key generation task, the address management task, the private key destruction task, and the like.
Alternatively, it is understood that in the above credit scenario, the credit agency (i.e., the target user) may upload the credit data information requested by the corresponding client as the service data information to the block chain. Similarly, before the credit agency uploads the credit data information to the block chain through the first device deployed with the first trusted application environment, the credit agency also needs to sign the credit data information through the private key of the credit agency stored in the first trusted application in the first device, so that corresponding signature information can be obtained. It is to be understood that the specific implementation manner of the credit agency obtaining the signature information may refer to the above description of the signature information associated with the asset transfer record, and will not be further described here.
It should be understood that, in the above other application scenarios, once the target user needs to write the corresponding service data information into the block chain, the signature information may be obtained in the data signature manner in the embodiment of the present application, and specific implementation manners for obtaining the corresponding signature information in each application scenario are not listed one by one here.
In the embodiment of the application, before the target user needs to uplink some service data information, the target user needing to access the first trusted application may be authenticated through the acquired access information, so that when the authentication is successful, the target user is allowed to access the first trusted application, and thus, the security of the private key of the target user stored in the first trusted application may be ensured as much as possible. Therefore, when the first device signs the service data information through the private key stored in the first trusted application, the security of obtaining the private key of the target user can be ensured, so that the authenticity and reliability of the signature information obtained by adopting the private key of the target user can be ensured, and the reliability of the service data information on a subsequent write-in chain can be further ensured. It should be understood that, since the first trusted application is deployed in the first trusted application environment, it is difficult for an illegal user to obtain the private key of the target user stored in the first trusted application, so that the risk of disclosure of the private key can be avoided as much as possible.
Further, please refer to fig. 9, which is a schematic structural diagram of a service data information processing apparatus provided in the present application. As shown in fig. 9, the service data information processing apparatus 1 is applicable to a first device in which the first trusted application environment described above is deployed. The service data information processing apparatus 1 may be a computer program (including program code) running in the first device, for example, the service data information processing apparatus 1 may be an application software, and the service data information processing apparatus 1 may be configured to execute corresponding steps in the method provided by the embodiment of the present application. The first device may be the server 4000a in the embodiment corresponding to fig. 1. As shown in fig. 9, the service data information processing apparatus 1 may include: the system comprises a business data acquisition module 101, an access information acquisition module 201 and a private key signature module 301; further, the service data information processing apparatus 1 may further include: the system comprises a user private key generation module 401, a private key storage module 501, a first return module 601, a second return module 701, a cochain request sending module 801, a private key destruction module 901, a processing request acquisition module 902, an asset extraction module 903 and a service data updating module 904;
the service data acquisition module 101 is configured to acquire service data information associated with a target user, and write the service data information into a first trusted application environment; a first trusted application is deployed in the first trusted application environment;
the service data acquiring module 101 includes: a first instruction acquisition unit 1011, a context access unit 1012, a first authority determination unit 1013, a first writing unit 1014; further, the service data acquiring module 101 may further include: a check instruction transmitting unit 1015, a shared key returning unit 1016;
a first instruction obtaining unit 1011, configured to obtain a first access instruction sent by a second device corresponding to a target user through an encrypted transmission channel corresponding to a second trusted application environment; the first access instruction carries encrypted data information, and the encrypted data information is obtained by encrypting the service data information by the second equipment according to the shared secret key; the shared key is configured by a verification server associated with the second device for the first trusted application environment and the second trusted application environment;
an environment access unit 1012, configured to access, according to the first task carried in the first access instruction, the first trusted application environment through the shared key;
a first permission determining unit 1013, configured to determine that the target user has a first permission to access the first trusted application environment when the first trusted application environment is successfully accessed;
the first writing unit 1014 is configured to decrypt, based on the first authority, the service data information associated with the target user from the encrypted data information, and write the service data information into the first trusted application environment running the first trusted application.
Optionally, the verification instruction sending unit 1015 is configured to send, to the verification server, a verification instruction for verifying the operating environment of the first trusted application environment; the verification instruction is used for instructing the verification server to verify the legality of the certificate information of the first trusted application in the first trusted application environment; the verification server is further used for verifying the legality of the certificate information of the second trusted application in the second execution environment; the second trusted application environment is an operating environment deployed in second equipment corresponding to the target user;
a shared key returning unit 1016, configured to, when the verification server determines that the certificate information of the first trusted application is legal and the certificate information of the second trusted application is legal, obtain a shared key associated with the first trusted application environment and the second trusted application environment, which is returned by the verification server; the shared key is used for instructing the second device to send the first access instruction to the first device through an encrypted transmission channel corresponding to the shared key under the second trusted application environment.
For specific implementation manners of the first instruction obtaining unit 1011, the environment access unit 1012, the first authority determining unit 1013, the first writing unit 1014, the check instruction sending unit 1015, and the shared key returning unit 1016, reference may be made to the description of the first access instruction in the embodiment corresponding to fig. 4, which will not be described again here.
Optionally, the service data acquiring module 101 may further include: a second instruction receiving unit 1017, a hash unlocking unit 1018, a second authority determining unit 1019, and a second writing unit 1020;
a second instruction receiving unit 1017, configured to receive a second access instruction sent by a first general application in a second device; the second access instruction is obtained by the first common application after hash locking is carried out on the service data information of the target user according to the environment public key of the first credible application environment; the environment public key is configured by the verification server for the first trusted application environment in the first device; the verification server is also used for configuring an environment private key corresponding to the environment public key for the first trusted application environment;
the hash unlocking unit 1018 is configured to unlock, in the first trusted application environment, the service data information subjected to hash locking by using the environment private key according to the second task carried in the second access instruction;
a second permission determining unit 1019, configured to obtain service data information when the unlocking is successful, and determine that a target user corresponding to the second device has a second permission to access the first trusted application environment;
a second writing unit 1020, configured to write the service data information into the first trusted application environment when the target user has the second right.
The specific implementation manners of the second instruction receiving unit 1017, the hash unlocking unit 1018, the second permission determining unit 1019, and the second writing unit 1020 may refer to the description of the second access instruction in the embodiment corresponding to fig. 5, which will not be described again here.
Optionally, the first device further includes a common application environment independent of the first trusted application environment, and the common application environment is deployed with a second common application;
the service data acquiring module 101 may further include: a local instruction sending unit 1021, an environment private key obtaining unit 1022, an environment private key unlocking unit 1023, and a third writing unit 1024;
a local instruction sending unit 1021, configured to control, in the first device, the second general application to send a local access instruction to the first trusted application environment when the target user logs in the second general application through the target account information; the local access instruction carries information of data to be processed; the data information to be processed is obtained by the second common application after hash locking is carried out on the service data information of the target user through the environment public key of the first credible application environment; the environment public key is returned to the second common application by the verification server when the first trusted application environment is determined to belong to the safe execution environment;
the environment private key obtaining unit 1022 is configured to obtain, according to the third task carried in the local access instruction, an environment private key returned to the first trusted application environment by the verification server;
the environment private key unlocking unit 1023 is used for carrying out hash unlocking on the data information to be processed in the first trusted application environment through the environment private key;
the third writing unit 1024 is configured to, when the unlocking is successful, obtain service data information of the target user, and write the service data information into the first trusted application environment in which the first trusted application runs.
The specific implementation manners of the local instruction sending unit 1021, the environment private key obtaining unit 1022, the environment private key unlocking unit 1023, and the third writing unit 1024 may refer to the description of the local access instruction, which will not be further described here.
An access information obtaining module 201, configured to obtain access information associated with a target user, and access a first trusted application in a first trusted application environment based on the access information;
the access information obtaining module 201 includes: an access authentication unit 2011, an application access authority determination unit 2012 and an access authorization unit 2013;
the access authentication unit 2011 is configured to obtain access information entered by the target user, and perform access authentication on the target user in the first trusted application environment according to the access information;
an application access permission determining unit 2012, configured to, if an access serial number matching the access information exists in the first trusted application environment, successfully authenticate the first trusted application environment, and determine that the target user has permission to access the first trusted application; the access sequence number is determined by the first device according to user registration information submitted when the target user registers the first trusted application;
and the access authorization unit 2013 is used for authorizing the target user to access the first trusted application when the target user has the right to access the first trusted application.
For specific implementation manners of the access authentication unit 2011, the application access right determining unit 2012, and the access authorization unit 2013, reference may be made to the above description of step S102, which will not be further described here.
The private key signature module 301 is configured to sign the hash value of the service data information through a private key of a target user in the first trusted application, so as to obtain signature information; the signature information is used for indicating the block chain node to write the service data information into the block chain when the signature information is successfully verified.
Wherein, the service data information comprises electronic bill information;
the private key signature module 301 includes: an encrypted key generation unit 3011, an encrypted data determination unit 3012, a user private key acquisition module 3013, and a private key signature unit 3014;
an encryption key generation sheet 3011, configured to, if it is recognized that there is a ticket content matching the private data information of the target user in the electronic ticket information, invoke a key generation subroutine to generate an encryption key for encrypting the electronic ticket information;
an encrypted data determining unit 3012, configured to perform encryption processing on the electronic ticket information through an encryption key to obtain encrypted ticket information;
the user private key obtaining module 3013 is configured to obtain a private key of a target user in a first memory of a first trusted application;
and the private key signature unit 3014 is configured to sign the hash value of the encrypted ticket information with a private key of the target user, so as to obtain signature information of the target user.
The specific implementation manners of the encryption key generation unit 3011, the encrypted data determination unit 3012, the user private key acquisition module 3013, and the private key signature unit 3014 may refer to the description of the encrypted ticket information in the embodiment corresponding to fig. 3, which will not be described again here.
Optionally, the first trusted application includes a key generation subroutine;
a user private key generation module 401, configured to generate a private key of a target user based on a key generation rule by using a key generation rule associated with the key generation subroutine;
the private key storage module 501 is configured to store a private key of a target user in a first memory corresponding to a first trusted application; the first memory is a trusted memory in the first trusted application environment.
Optionally, the first returning module 601 is configured to return the signature information to the second device through an encrypted transmission channel between the first trusted application environment and the second trusted application environment; the second equipment is used for generating a data uplink request corresponding to the service data information according to the signature information; the data uplink request is used for indicating a block link point in the block link network to write the service data information into a block link corresponding to the block link network when the signature information is successfully verified.
Optionally, the second returning module 701 is configured to return the signature information to a second common application in the first device;
an uplink request sending module 801, configured to add the signature information and the service data information to the data uplink request through a second common application, and send the data uplink request to a block chain node in a block chain network; the data uplink request is used for indicating the block chain node to write the service data information into the block chain when the signature information is successfully verified.
The first trusted application also comprises a secret key destroying subprogram;
optionally, the private key destruction module 901 is configured to destroy the private key of the target user in the first application through the private key destruction sub-program when the idle duration of the first device reaches the idle threshold.
Optionally, the first trusted application further includes an address generation subroutine; the address generation subprogram is used for generating a plurality of address information associated with the target user; one address information corresponds to one public key, and one public key corresponds to one private key; the plurality of address information includes target address information; the target address information is used for storing asset information of a target user; the asset information comprises initial asset information which has a directional asset transfer relationship with a target client of a target user;
a processing request obtaining module 902, configured to obtain a service processing request, which is sent by a target user through target address information and is addressed to a target client;
the asset extraction module 903 is used for extracting target asset information from the service processing request, and decrypting the target asset information through a private key corresponding to the target address information to obtain initial asset information; the target asset information is obtained by performing Hash locking on the initial asset information by a target user through a public key corresponding to the target address information;
and a service data updating module 904, configured to obtain an asset transition record corresponding to the initial asset information, and update service data information associated with the target user through the asset transition record.
For specific implementation manners of the service data obtaining module 101, the access information obtaining module 201, and the private key signature module 301, reference may be made to the description of steps S101 to S103 in the embodiment corresponding to fig. 3, which will not be further described here. Further, specific implementation manners of the user private key generation module 401, the private key storage module 501, the first returning module 601, the second returning module 701, the uplink request sending module 801, the private key destruction module 901, the processing request obtaining module 902, the asset extracting module 903, and the service data updating module 904 may refer to the descriptions of step S201 to step S208 in the embodiment corresponding to fig. 7, and will not be further described here. In addition, the beneficial effects of the same method are not described in detail.
Further, please refer to fig. 10, which is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 10, the computer apparatus 1000 may be applied to the server 4000a in the embodiment corresponding to fig. 1, and the computer apparatus 1000 may include: the processor 1001, the network interface 1004, and the memory 1005, and the computer device 1000 may further include: a user interface 1003, and at least one communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display screen (Display) and a Keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a standard wireless interface. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1004 may be a high-speed RAM memory or a non-volatile memory (e.g., at least one disk memory). The memory 1005 may optionally be at least one memory device located remotely from the processor 1001. As shown in fig. 10, a memory 1005, which is a kind of computer storage medium, may include therein an operating system, a network communication module, a user interface module, and a device control application program.
The network interface 1004 in the computer device 1000 may also be connected to the above-mentioned block chain link points in the block chain network, and the optional user interface 1003 may also include a Display (Display) and a Keyboard (Keyboard). In the computer device 1000 shown in fig. 10, the network interface 1004 may provide a network communication function; the user interface 1003 is an interface for providing a user with input; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:
acquiring service data information associated with a target user, and writing the service data information into a first trusted application environment; a first trusted application is deployed in the first trusted application environment;
obtaining access information associated with a target user, accessing a first trusted application in a first trusted application environment based on the access information;
signing the hash value of the service data information through a private key of a target user in the first trusted application to obtain signature information; the signature information is used for indicating the block chain node to write the service data information into the block chain when the signature information is successfully verified.
It should be understood that the computer device 1000 described in this embodiment may perform the description of the service data information processing method in the embodiment corresponding to fig. 3 or fig. 7, and may also perform the description of the service data information processing apparatus 1 in the embodiment corresponding to fig. 9, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.
Further, here, it is to be noted that: an embodiment of the present application further provides a computer storage medium, where the computer storage medium stores the aforementioned computer program executed by the data processing apparatus 1, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the service data information processing method in the embodiment corresponding to fig. 3 or fig. 7 can be executed, so that details are not repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in the embodiments of the computer storage medium referred to in the present application, reference is made to the description of the embodiments of the method of the present application. As an example, program instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network, which may comprise a block chain system.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.
The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.

Claims (15)

1. A business data information processing method, which is executed by a first device deployed with a first trusted application environment, includes:
acquiring service data information associated with a target user, and writing the service data information into the first trusted application environment; a first trusted application is deployed in the first trusted application environment;
obtaining access information associated with the target user, accessing the first trusted application in the first trusted application environment based on the access information;
signing the hash value of the service data information through the private key of the target user in the first trusted application to obtain signature information; and the signature information is used for indicating the block chain node to write the service data information into the block chain when the signature information is successfully verified.
2. The method of claim 1, wherein the obtaining business data information associated with a target user, writing the business data information to the first trusted application environment, comprises:
acquiring a first access instruction sent by second equipment corresponding to a target user through an encrypted transmission channel corresponding to a second trusted application environment; the first access instruction carries encrypted data information, and the encrypted data information is obtained by encrypting the service data information by the second equipment according to the shared key; the shared key is configured by a verification server associated with the second device for the first and second trusted application environments;
accessing the first trusted application environment through the shared key according to the first task carried in the first access instruction;
upon successful access of the first trusted application environment, determining that the target user possesses a first right to access the first trusted application environment;
and decrypting the encrypted data information based on the first authority to obtain business data information associated with the target user, and writing the business data information into the first trusted application environment running the first trusted application.
3. The method according to claim 2, wherein before the obtaining of the first access instruction sent by the second device corresponding to the target user through the second execution environment, the method includes:
sending a verification instruction for verifying the running environment of the first trusted application environment to the verification server; the verification instruction is used for instructing the verification server to verify the legality of the certificate information of the first trusted application in the first trusted application environment; the verification server is further used for verifying the legality of the certificate information of the second trusted application in the second execution environment; the second trusted application environment is a running environment deployed in second equipment corresponding to the target user;
when the verification server determines that the certificate information of the first trusted application is legal and the certificate information of the second trusted application is legal, acquiring a shared key which is returned by the verification server and is associated with the first trusted application environment and the second trusted application environment; the shared key is used for instructing the second device to send a first access instruction to the first device through an encrypted transmission channel corresponding to the shared key under the second trusted application environment.
4. The method of claim 1, wherein the obtaining business data information associated with a target user, writing the business data information to the first trusted application environment, comprises:
receiving a second access instruction sent by a first common application in the second equipment; the second access instruction is obtained by the first common application after performing hash locking on the service data information of the target user according to the environment public key of the first trusted application environment; the environment public key is configured by a verification server for the first trusted application environment in the first device; the verification server is further used for configuring an environment private key corresponding to the environment public key for the first trusted application environment;
according to a second task carried in the second access instruction, unlocking the service data information subjected to hash locking in the first trusted application environment through the environment private key;
when the unlocking is successful, the service data information is obtained, and a target user corresponding to the second device is determined to have a second authority for accessing the first trusted application environment;
and when the target user has the second right, writing the service data information into the first trusted application environment.
5. The method of claim 1, further comprising a common application environment independent of the first trusted application environment in the first device, the common application environment having a second common application deployed therein;
the acquiring the service data information associated with the target user and writing the service data information into the first trusted application environment includes:
when a target user logs in the second common application through target account information, controlling the second common application to send a local access instruction to the first trusted application environment in the first device; the local access instruction carries to-be-processed data information; the data information to be processed is obtained by the second common application after hash locking is carried out on the service data information of the target user through the environment public key of the first credible application environment; the environment public key is returned to the second common application by the verification server when the first trusted application environment is determined to belong to the safe execution environment;
according to a third task carried in the local access instruction, acquiring an environment private key returned to the first trusted application environment by the verification server;
carrying out Hash unlocking on the to-be-processed data information in the first trusted application environment through the environment private key;
and when the unlocking is successful, obtaining the service data information of the target user, and writing the service data information into the first trusted application environment running with the first trusted application.
6. The method of claim 1, wherein obtaining access information associated with the target user, accessing the first trusted application in the first trusted application environment based on the access information, comprises:
acquiring access information input by a target user, and performing access authentication on the target user in the first trusted application environment according to the access information;
if the access serial number matched with the access information exists in the first trusted application environment, the authentication is successful, and the target user is determined to have the authority of accessing the first trusted application; the access sequence number is determined by the first device according to user registration information submitted when the target user registers the first trusted application;
authorizing the target user to access the first trusted application when the target user has the right to access the first trusted application.
7. The method of claim 1, the first trusted application comprising a key generation routine;
the method further comprises the following steps:
acquiring a key generation rule associated with the key generation subprogram, and generating a private key of the target user based on the key generation rule;
storing the private key of the target user to a first memory corresponding to the first trusted application; the first memory is a trusted memory in the first trusted application environment.
8. The method of claim 7, wherein the service data information comprises electronic ticket information;
the signing the hash value of the service data information through the private key of the target user in the first trusted application to obtain signature information includes:
if the electronic bill information is identified to have bill content matched with the private data information of the target user, calling the key generation subprogram to generate an encryption key for encrypting the electronic bill information;
encrypting the electronic bill information through the encryption key to obtain encrypted bill information;
obtaining a private key of the target user in a first memory of a first trusted application;
and signing the hash value of the encrypted bill information through the private key of the target user to obtain the signature information of the target user.
9. The method of claim 2, further comprising:
returning the signature information to the second device through the encrypted transmission channel between the first trusted application environment and the second trusted application environment; the second device is configured to generate a data uplink request corresponding to the service data information according to the signature information; and the data uplink request is used for indicating a block chain link point in a block chain network to write the service data information into a block chain corresponding to the block chain network when the signature information is successfully verified.
10. The method of claim 5, further comprising:
returning the signature information to the second generic application in the first device;
adding the signature information and the service data information to a data uplink request through a second common application, and sending the data uplink request to a block chain node in a block chain network; and the data uplink request is used for indicating the block chain node to write the service data information into the block chain when the signature information is successfully verified.
11. The method according to claim 7, wherein the first trusted application further comprises a key destruction sub-routine;
the method further comprises the following steps:
and when the idle time of the first device reaches an idle threshold, destroying the private key of the target user in the first application through the secret key destruction subprogram.
12. The method of claim 11, wherein the first trusted application further comprises an address generation subroutine; the address generation subroutine is used for generating a plurality of address information associated with the target user; one address information corresponds to one public key, and one public key corresponds to one private key; the plurality of address information comprise target address information; the target address information is used for storing asset information of the target user; the asset information comprises initial asset information which has a directional asset transfer relationship with a target client of the target user;
the method further comprises the following steps:
acquiring a service processing request which is sent by a target user through the target address information and aims at the target client;
extracting target asset information from the service processing request, and decrypting the target asset information through a private key corresponding to the target address information to obtain the initial asset information; the target asset information is obtained by the target user after carrying out Hash locking on the initial asset information through a public key corresponding to the target address information;
and acquiring an asset transfer record corresponding to the initial asset information, and updating the service data information associated with the target user through the asset transfer record.
13. A business data information processing apparatus, wherein the apparatus is operated in a first device deployed with a first trusted application environment, and comprises:
the service data acquisition module is used for acquiring service data information associated with a target user and writing the service data information into the first trusted application environment; a first trusted application is deployed in the first trusted application environment;
an access information acquisition module to acquire access information associated with the target user, the first trusted application being accessed in the first trusted application environment based on the access information;
the private key signature module is used for signing the hash value of the business data information through the private key of the target user in the first trusted application to obtain signature information; and the signature information is used for indicating the block chain node to write the service data information into the block chain when the signature information is successfully verified.
14. A computer device, comprising: a processor, a memory, a network interface;
the processor is connected to a memory for providing data communication functions, a network interface for storing a computer program, and a processor for calling the computer program to perform the method according to any one of claims 1 to 12.
15. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program comprising program instructions which, when executed by a processor, perform the method according to any one of claims 1-12.
CN202010195893.5A 2020-03-19 2020-03-19 Service data information processing method, device, equipment and readable storage medium Active CN111431707B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010195893.5A CN111431707B (en) 2020-03-19 2020-03-19 Service data information processing method, device, equipment and readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010195893.5A CN111431707B (en) 2020-03-19 2020-03-19 Service data information processing method, device, equipment and readable storage medium

Publications (2)

Publication Number Publication Date
CN111431707A true CN111431707A (en) 2020-07-17
CN111431707B CN111431707B (en) 2021-03-26

Family

ID=71553551

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010195893.5A Active CN111431707B (en) 2020-03-19 2020-03-19 Service data information processing method, device, equipment and readable storage medium

Country Status (1)

Country Link
CN (1) CN111431707B (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111885050A (en) * 2020-07-21 2020-11-03 腾讯科技（深圳）有限公司 Data storage method and device based on block chain network, related equipment and medium
CN112560019A (en) * 2020-07-31 2021-03-26 支付宝(杭州)信息技术有限公司 Processing method, device and equipment of block chain data
CN112560104A (en) * 2021-01-17 2021-03-26 梁志彬 Data storage method and safety information platform based on cloud computing and block chain
CN112911002A (en) * 2021-02-02 2021-06-04 上海华盖科技发展股份有限公司 Block chain data sharing encryption method
CN113094753A (en) * 2021-05-08 2021-07-09 重庆银行股份有限公司 Big data platform hive data modification method and system based on block chain
CN113300853A (en) * 2021-05-20 2021-08-24 广西大学 Financial credit investigation information management method and device, electronic equipment and storage medium
CN114091027A (en) * 2021-12-01 2022-02-25 海光信息技术股份有限公司 Information configuration method, data access method, related device and equipment

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180374173A1 (en) * 2016-03-01 2018-12-27 Huawei Technologies Co., Ltd Copyright management method and system
CN109525400A (en) * 2018-11-01 2019-03-26 联想(北京)有限公司 Security processing, system and electronic equipment
CN110009356A (en) * 2019-04-16 2019-07-12 北京艾摩瑞策科技有限公司 A kind of business datum cochain method and its system based on block chain
CN110020855A (en) * 2019-01-31 2019-07-16 阿里巴巴集团控股有限公司 Method, the node, storage medium of secret protection are realized in block chain
CN110851870A (en) * 2019-11-14 2020-02-28 中国人民解放军国防科技大学 Block chain privacy protection method, system and medium based on trusted execution environment

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180374173A1 (en) * 2016-03-01 2018-12-27 Huawei Technologies Co., Ltd Copyright management method and system
CN109525400A (en) * 2018-11-01 2019-03-26 联想(北京)有限公司 Security processing, system and electronic equipment
CN110020855A (en) * 2019-01-31 2019-07-16 阿里巴巴集团控股有限公司 Method, the node, storage medium of secret protection are realized in block chain
CN110009356A (en) * 2019-04-16 2019-07-12 北京艾摩瑞策科技有限公司 A kind of business datum cochain method and its system based on block chain
CN110851870A (en) * 2019-11-14 2020-02-28 中国人民解放军国防科技大学 Block chain privacy protection method, system and medium based on trusted execution environment

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111885050A (en) * 2020-07-21 2020-11-03 腾讯科技（深圳）有限公司 Data storage method and device based on block chain network, related equipment and medium
CN111885050B (en) * 2020-07-21 2022-01-11 腾讯科技（深圳）有限公司 Data storage method and device based on block chain network, related equipment and medium
CN112560019A (en) * 2020-07-31 2021-03-26 支付宝(杭州)信息技术有限公司 Processing method, device and equipment of block chain data
CN112560104A (en) * 2021-01-17 2021-03-26 梁志彬 Data storage method and safety information platform based on cloud computing and block chain
CN112911002A (en) * 2021-02-02 2021-06-04 上海华盖科技发展股份有限公司 Block chain data sharing encryption method
CN113094753A (en) * 2021-05-08 2021-07-09 重庆银行股份有限公司 Big data platform hive data modification method and system based on block chain
CN113300853A (en) * 2021-05-20 2021-08-24 广西大学 Financial credit investigation information management method and device, electronic equipment and storage medium
CN113300853B (en) * 2021-05-20 2023-07-25 广西大学 Financial credit information management method, device, electronic equipment and storage medium
CN114091027A (en) * 2021-12-01 2022-02-25 海光信息技术股份有限公司 Information configuration method, data access method, related device and equipment
CN114091027B (en) * 2021-12-01 2023-08-29 海光信息技术股份有限公司 Information configuration method, data access method, related device and equipment

Also Published As

Publication number Publication date
CN111431707B (en) 2021-03-26

Similar Documents

Publication Publication Date Title
CN111429254B (en) Business data processing method and device and readable storage medium
CN111431707B (en) Service data information processing method, device, equipment and readable storage medium
US11757641B2 (en) Decentralized data authentication
CA2838763C (en) Credential authentication methods and systems
US20190050598A1 (en) Secure data storage
CN108055133B (en) Key security signature method based on block chain technology
CN109412812B (en) Data security processing system, method, device and storage medium
JP2023502346A (en) Quantum secure networking
KR20210040078A (en) Systems and methods for safe storage services
JP2005535945A (en) How to protect the integrity of a computer program
US11811945B2 (en) Blockchain identities
Patel et al. DAuth: A decentralized web authentication system using Ethereum based blockchain
CN111460457A (en) Real estate property registration supervision method, device, electronic equipment and storage medium
CN111932261A (en) Asset data management method and device based on verifiable statement
US20180218363A1 (en) Payment instrument management with key tokenization
Lim et al. AuthChain: a decentralized blockchain-based authentication system
Otterbein et al. The German eID as an authentication token on android devices
Kirar et al. An efficient architecture and algorithm to prevent data leakage in Cloud Computing using multi-tier security approach
KR100955880B1 (en) Security method in RFID environment, Recording medium and System using by the same
CN117063174A (en) Security module and method for inter-app trust through app-based identity
Xie et al. VOAuth: A solution to protect OAuth against phishing
Nowroozi et al. Cryptocurrency wallets: assessment and security
KR102542840B1 (en) Method and system for providing finance authentication service based on open api
Khan et al. Review of Security Methods in Cloud Computing
TWI778319B (en) Method for cross-platform authorizing access to resources and authorization system thereof

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40026348

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant