TWI828001B - System for using multiple security levels to verify customer identity and transaction services and method thereof - Google Patents

Abstract

A system for using multiple security levels to verify customer identity and transaction services and a method thereof are provided. By using Fast Identity Online framework to login a financial institution with biometrics by a client, choosing a security verification method corresponding risk level of a transaction service to verify customer’s identity when the client requests the transaction service from the financial institution, and publishing an evidence data that can verify transaction data of the transaction service and verification data generated during the customer’s identity verification to a blockchain by related nodes on the blockchain, the system and the method can establish verification procedures and standards that allow financial institutions to trust each other, and can achieve the effect of increasing complexity and cost of crime, reducing wasted resources of financial institutions, and taking care of security and convenience of transactions.

Description

Systems and methods for verifying customer identity and transaction services using multiple security levels

An identity and transaction verification system and method, particularly a system and method that uses multiple security levels to verify customer identity and transaction services.

The Common Criteria for Information Technology Security Assessment (CC, ISO/IES15408) is an information security product certification framework that has been established for more than 20 years. It is divided into seven security assessment levels. Levels 1 to 4 are for evaluating general products or systems. Security level, level 5 and above are standards for evaluating and designing national security or military equipment products. Under such clear, unified and common standards, IT products produced by countries that adopt CC standards can gain the trust of governments, enterprises and the general public on a large scale, and various systems designed using these products can be quantified Its security, or conversely, select appropriate IT products based on the security strength required by the system.

Moving to the domestic financial industry scene, comprehensive digitalization has become an inevitable trend, but digital financial risk control and information security standards are lacking. For example, in the insurance industry, every insurance company’s underwriting, claims settlement, and preservation Although the verification work process is handled in accordance with regulations, the regulations are only a guidance structure and do not clarify the process and standards. This results in each insurance company's process being usually different and the verification standards being different. In this way, financial institutions cannot trust each other, that is, they cannot trust the verification results of other financial institutions. As a result, each financial institution needs to perform the same verification process, resulting in a waste of resources.

To sum up, it can be seen that there has long been a problem in the previous technology that domestic financial institutions do not have mutually trustworthy verification processes and standards. Therefore, it is necessary to propose improved technical means to solve this problem.

In view of the problem in the prior art that domestic financial institutions do not have mutually trustworthy verification processes and standards, the present invention discloses a system and method for verifying customer identity and transaction services using multiple security levels, wherein:

The system disclosed by the present invention that uses multiple security levels to verify customer identity and transaction services at least includes: a client installed with a trusted module that stores transaction verification data; and a financial institution that provides the client with access to The Fast IDentity Online (FIDO) architecture uses biometrics to log in, and when the client requests transaction services, it determines whether the transaction service meets the basic transaction level. When the transaction service is the basic transaction level, an identity verification request is generated; the platform The terminal is used to receive the identity verification request sent by the financial institution and require the client to perform identity verification, so that the client encrypts the transaction verification data to generate transaction encryption data and sends the transaction encryption data to the platform side, and is used to decrypt the transaction encryption After obtaining the identity verification data and confirming that the identity verification data is consistent with the transaction verification data, the first storage certificate data is generated based on the identity verification request and the transaction encryption data, and the first storage certificate data is published to the blockchain, and the identity verification is sent The results are sent to the financial institution, so that when the identity verification result indicates that the financial institution has passed the verification, the financial institution will generate transaction data corresponding to the requested transaction service; the public trust unit is used to receive the information when the financial institution determines that the transaction service is the actual transaction level. The transaction data is transmitted, and the transaction data is signed to generate a trustworthy signature, and the trustworthy signature is sent to the platform; the authentication side is used to receive the trustworthy signature sent by the platform, and generate a second certificate based on the trustworthy signature. information, and publish the secondary certificate information to the blockchain.

The method disclosed in the present invention uses multiple security levels to verify client identity and transaction services. The steps include at least: the client uses an online fast authentication architecture to log in to the financial institution with biometrics; the financial institution determines when the client requests transaction services. When the transaction service is at the basic transaction level, an identity verification request is sent to the platform, so that the platform requires the client to perform identity verification; the client encrypts the transaction verification data to generate transaction encryption data and sends the transaction encryption data to the platform; the platform decrypts the transaction Encrypt the data to obtain the identity verification data and confirm that the identity verification data is consistent with the transaction verification data, and then send the identity verification results to the financial institution; the platform generates the first certificate data based on the identity verification request and transaction encrypted data and publishes the first Store the certificate data in the blockchain; when the identity verification result indicates that the verification is passed, the financial institution side generates transaction data corresponding to the transaction service; when the financial institution side determines that the transaction service is an actual transaction level, it sends the transaction data to the public trust unit side; The public trust unit signs the transaction data to generate a public trust signature, and transmits the public trust signature to the platform; the platform sends the public trust signature to the authentication end, and the authentication end generates the second certificate data based on the public trust signature and issues the second certificate Certify data into the blockchain.

The system and method disclosed by the present invention are as above. The difference between the system and the prior art is that the present invention uses the online fast authentication architecture to log in to the financial institution through the client using biometrics. When the client requests transaction services, the financial institution will Select the corresponding security verification method for the risk level of the requested transaction service to verify the customer's identity, and publish the certificate data that can verify the verification data generated by the verification process and the transaction data of the requested transaction service to the block. In the chain, it can solve the problems existing in the previous technology, and can achieve the technical effects of increasing the complexity and cost of crime, reducing the wasted resources of financial institutions, and taking into account the security and convenience of transactions.

The features and implementations of the present invention will be described in detail below with reference to the drawings and examples. The content is sufficient to enable any person familiar with the relevant art to easily fully understand the technical means used to solve the technical problems of the present invention and implement them accordingly, thereby achieving The effect that the present invention can achieve.

The present invention allows the financial institution to use different security verification technologies through the platform according to different risk levels of the client's transaction services. Among them, transaction services include financial services that do not involve money, financial transactions involving small amounts of money, financial transactions involving large amounts of money, etc.

The system operation of the present invention is first explained below with reference to "Figure 1", a system architecture diagram of the present invention using multiple security levels to verify client identity and transaction services. As shown in "Figure 1", the system of the present invention includes a client 110, a financial institution terminal 130, a platform terminal 150, a public trust unit terminal 160, an authentication terminal 170, and an add-on server terminal 120. Among them, the client 110, the server 120, the financial institution 130, the platform 150, the public trust unit 160, and the verification terminal 170 can be computing devices, and between the client 110 and the financial institution 130/platform 150, the server 120 and the financial institution side 130/platform side 150, between the financial institution side 130 and the platform side 150/public trust unit side 160, and between the platform side 150 and the public trust unit side 160 can be connected through wired or wireless communication methods, so as to communicate with each other. To transmit information or signals.

The client 110 is installed with a trusted module. The trusted module is a SIM card, a sensor chip, an expansion card and other physical components that can store data. The sensor chip can be attached to the SIM card, and the expansion card can be nested in the SIM card. The client 110 can apply for a trusted module from the platform 150 or the financial institution 130, and can install the trusted module after the trusted module is enabled. In some embodiments, the trusted module can be connected to the client. 110 device identification data binding. It should be noted that the trusted module only provides writing data or reading data to prevent data from being tampered with.

The client 110 can use real-name verification to register on the platform 150, or can receive the login verification information and transaction verification data sent by the platform 150 after completing the registration, and can use the trusted module to store the received login verification information and transaction verification information. Transaction verification information. Among them, real-name verification includes but is not limited to mobile identity recognition (Mobile ID, MID) or digital identity recognition (eID).

The client 110 can also receive the client authentication information transmitted by the platform 150 and store the received client authentication information. Generally speaking, the client 110 can use a trusted module to store client authentication information.

The client 110 can also register on the blockchain 190 through the distributed digital identity (Decentralized Identity, DID) registration (Registry) service to obtain the distributed digital identity information corresponding to the blockchain 190.

The client 110 is also responsible for logging into the financial institution terminal 130 using biometric characteristics, and is responsible for requesting transaction services from the financial institution terminal 13 . For example, the client 110 can use the Fast IDentity Online (FIDO) architecture to log in to the financial institution 130 using biometrics. In more detail, the client 110 can verify the user's biometrics when logging in to the financial institution 130. And after the user's biometric characteristics are recognized, the login verification information and organization login information can be read from the trusted module, and the login verification information and organization login information can be sent to the platform end 150, so as to use the platform end 150 Send the institution login information to the financial institution end 130. Among them, the biometric features mentioned in the present invention include fingerprint features, facial features, iris features, etc., but the present invention is not limited thereto; the institution login information is the information that the user of the client 110 has pre-registered with the financial institution 130 , including but not limited to account password, etc.

The client 110 can also read the login verification information from the trusted module after performing biometric identification on the user, and can encrypt the read login verification information to generate corresponding login encrypted information, and can convert all the login verification information. The generated login encryption information is sent to the platform 150; the client 110 is also responsible for reading the transaction verification data from the trusted module when receiving the identity verification request sent by the platform 150, and encrypting the read transaction verification. data to generate transaction encrypted data, and transmit the generated transaction encrypted data to the platform 150. In some embodiments, the client 110 may also require the platform 150 to issue a verifiable statement (Verifiable Credential) when transmitting the transaction encrypted data. , VC); the client 110 can also read the trusted security information from the trusted module when receiving the module verification request sent by the platform 150, and encrypt the read trusted security information to generate the module. Set encrypted data, and send the generated module encrypted data to the platform 150. Among them, the trusted security data is all the data, part of the data or specific data stored by the trusted module.

The client 110 can use the private key to encrypt the data to be encrypted (such as login verification data, transaction verification data, trusted security data, etc.) to generate corresponding encryption result data (such as login encryption data, transaction encryption data, module encryption data, etc.) , you can also use the time-based One-Time Password (TOTP) received from the platform 150 to encrypt the data to be encrypted to generate encryption result data, or you can first use the private key to encrypt the data to be encrypted to generate an intermediate After the ciphertext, a time-based one-time password is used to encrypt the intermediate ciphertext to generate encryption result data, but the client 110 generates login encryption data/transaction encryption data/module from login verification data/transaction verification data/trusted security data The methods of encrypting data are not limited to the above. The client 110 may use AES, RSA or other similar symmetric or asymmetric algorithms to encrypt the data to be encrypted.

The server 120 can provide the device identification information input to the client 110 so that the platform 150 or the financial institution 130 activates the trusted module applied by the client 110 . Generally speaking, the server 120 can transmit the device identification information to the platform 150 or the financial institution 130 where the client 110 applies for the trusted module through a wired or wireless network. The device identification data of the client 110 is data that can identify the client 110, including but not limited to the product serial number or machine number of the client 110.

The financial institution 130 can generate login verification data and transaction verification data corresponding to the client 110 when the client 110 completes registration through real-name verification, and transmit the generated login verification data and transaction verification data to the client 110 . Generally speaking, the financial institution end 130 can randomly generate login verification data/transaction verification data, but the present invention is not limited to this. For example, the current time can also be hashed or bit rearranged to generate login data. Verification information/transaction verification information. Among them, the login verification information/transaction verification information can be composed of a certain number of words, letters, numbers, and symbols arranged in any order.

The financial institution 130 may also authenticate the personal information of the user of the client 110 .

The financial institution end 130 is responsible for providing the client 110 with biometric login, for example, using the FIDO architecture. The financial institution end 130 can generate a login verification request when requiring the client 110 to log in, and can send the generated login verification request to the platform end 150. It can also receive the institution login information sent by the platform end 150, and check the received When the institution login information passes the verification, the client 110 is allowed to log in to the financial institution end 130. Among them, the financial institution end 130 can use the conventional method to check the institution login information registered by the client 110, so no details are given.

The financial institution end 130 is also responsible for determining the risk level to which the received transaction service belongs when receiving the transaction service from the client 110 . In the present invention, the risk level may include the basic transaction level and the actual transaction level. In some embodiments, the risk level may also include the regulatory transaction level, but the risk level proposed by the present invention is not limited to the above. Among them, the basic transaction level can include all transaction services, that is, it can include transaction services such as inquiries or settings that do not involve money transactions, and all transaction services involving money; the actual transaction level can include all transaction services involving money; supervisory transactions Levels can be transaction services involving large amounts of money (amount greater than the threshold), but the basic transaction level, actual transaction level, and regulatory transaction level are not limited to the above. It should be noted that a transaction service can belong to multiple risk levels at the same time. When determining that the transaction service belongs to a larger risk level, the financial institution 130 can further determine whether the transaction service also belongs to a smaller risk level, for example, The financial institution end 130 can determine whether the transaction service also belongs to the actual transaction level when the transaction service belongs to the basic transaction level, and can determine whether the transaction service also belongs to the regulatory transaction level when the transaction service belongs to the actual transaction level.

The financial institution end 130 is also responsible for generating an identity verification request when it determines that the received transaction service is a basic transaction level, and transmits the generated identity verification request to the platform end 150, and is responsible for receiving the identity verification generated by the platform end 150. As a result, when it is determined that the content recorded in the identity verification result indicates that the user of the client 110 has passed the verification, transaction data corresponding to the requested transaction service is generated to complete the transaction. In some embodiments, the identity verification request may include a request to obtain a verifiable statement related to the financial institution 130 issued using the distributed digital identification data of the user of the client 110, and the identity verification result may be the platform-side 150. At this time, the financial institution end 130 may not receive the identity verification result sent by the platform end 150, but can use the user's distributed digital identification information of the client end 110 to obtain the verification result from the blockchain. 190 obtains the corresponding verifiable statement, and can use the public key of the platform 150 to verify the signature in the obtained verifiable statement (and confirm the validity and expiration time) to verify the obtained verifiable statement. When it can After the verification statement passes the verification and the identity of the user of the client 110 is confirmed in the verifiable statement, the financial institution end 130 can determine that the identity verification result indicates that the verification has been passed.

The financial institution end 130 is also responsible for determining whether the received transaction service is at the actual transaction level. If so, the generated transaction data can be sent to the public trust unit end 160; the financial institution end 130 can also determine whether the transaction service is at the regulatory transaction level. , if so, then the financial institution end 130 can generate a module verification request, and can transmit the generated module verification request to the platform end 150; and if the transaction service does not belong to the actual transaction level or the regulatory transaction level, then the financial institution end 130 Execution ends after transaction services can be provided.

The financial institution terminal 130 can also receive the declaration form sent by the platform terminal 150, and can generate the first declaration information based on the received declaration form, and can transmit the generated first declaration information to the platform terminal 150.

The platform end 150 is responsible for receiving the identity verification request sent by the financial institution end 130, and requiring the client 110 to perform identity verification based on the received identity verification request; the platform end 150 can also receive the module verification request sent by the financial institution end 130 , and requires the client 110 to verify the trusted module based on the received module verification request; the platform 150 can also receive the login verification request sent by the financial institution end 130, and based on the received login verification request. Client 110 provides login verification information.

The platform 150 can also receive the login verification information and the organization login information sent by the client 110, and verify the login verification information, that is, compare the received login verification information with the stored login verification information. If so, then It means that the login verification data has passed the verification. If not, it means that the login verification data has not passed the verification. The platform side 150 may also transmit the received institutional login information to the financial institution side 130 when the login verification information passes the verification.

The platform 150 is also responsible for receiving the transaction encrypted data sent by the client 110, and decrypting the received transaction encrypted data to obtain the identity verification information; the platform 150 can also receive the module encrypted data sent by the client 110, and Decrypt the received module encrypted data to obtain the module verification data; the platform 150 can also receive the login encrypted data sent by the client 110 and decrypt the login encrypted data to obtain the login verification data. Among them, the way the platform end 150 decrypts the encrypted result data (such as login encrypted data, transaction encrypted data, module encrypted data, etc.) differs depending on the way the encrypted result data is encrypted. For example, when the encrypted result data is encrypted by the customer When the client 110 encrypts the data with a private key, the platform 150 can use the public key of the client 110 to decrypt the encryption result data to generate decrypted data (such as login verification data, identity verification data, module verification data, etc.); when encrypting When the result data is encrypted by the client 110 using the time-based one-time password generated by the platform 150, the platform 150 can use the generated one-time password to decrypt and decrypt the encrypted result data to generate the original data; and when the encrypted result data is When it is encrypted by the client 110 using the private key and the one-time password, the platform 150 can first use the one-time password to decrypt the encrypted result data to generate the intermediate ciphertext, and then use the public key of the client 110 to decrypt the intermediate ciphertext to generate original data, but the method by which the client 110 decrypts the login encrypted data/transaction encrypted data/module encrypted data to obtain the login verification data/identity verification data/module verification data is not limited to the above.

The platform 150 is also responsible for confirming whether the identity verification data obtained by decrypting the transaction encrypted data is consistent with the pre-stored transaction verification data of the client 110, and can generate an identity verification result corresponding to the confirmation result. The platform side 150 can send the identity verification result to the client 110 and/or the financial institution side 130 when the identity verification data does not match the transaction verification data; the platform side 150 is also responsible for sending the identity verification result when the identity verification data matches the transaction verification data. Send the generated identity verification results to the financial institution end 130, and be responsible for generating the first certificate data based on the identity verification request and transaction encryption data, and publishing the block containing the generated first certificate data to the blockchain. 190 in. Generally speaking, the platform 150 can first perform a specific operation on the identity verification request and the transaction encryption data to generate the first certificate data, and then generate a block containing the first certificate data, but the present invention is not limited to this. For example, the platform 150 may also generate the first certificate data including the identity verification request and transaction encryption data. Among them, the above-mentioned specific operations include but are not limited to hash operations.

The platform 150 can also receive the statement issuance request sent by the client 110, and when confirming that the obtained identity verification information is consistent with the pre-stored transaction verification information, it can read out the corresponding user based on the received issuance request. data, and generate disclosure information based on all or part of the user information, and use the private key of the platform 150 to sign the disclosure information to generate a verifiable statement, and the signed and generated verifiable statement can be published to the blockchain 190 . The disclosure information may be all or part of the user information read by the client 110, but the present invention is not limited thereto. The disclosure information may also be organized user information; the verifiable statement and the client 110 The user's distributed digital identification data corresponds to the received claim issuance request.

The platform 150 can also compare whether the module verification data generated by decrypting the encrypted data of the module is consistent with the pre-stored trusted security information. If not, the platform 150 can generate a notification message indicating the termination of the transaction, and can The generated notification message is sent to the financial institution end 130; and when the module verification data matches the trusted security information, the platform end 150 can generate or read the declaration form, and send the declaration form to the financial institution end 130. The platform The terminal 150 can also receive the first declaration information sent by the financial institution terminal 130, generate the second declaration information including the first declaration information, and transmit the second declaration information to the regulatory end (not shown in the figure) for storage.

The platform 150 can also generate third certificate data based on the received module verification request, module encryption data and the generated second declaration data, and can publish the generated third certificate data to the blockchain. 190, but the method of generating the third certificate data in the present invention is not limited to the above. For example, the platform 150 can generate the third certificate data including module verification request, module encryption data and second declaration data.

The platform 150 can also compare whether the login verification data generated by decrypting the login encrypted data matches the login verification data generated and stored when the client 110 completes the registration. If not, the platform 150 can generate a corresponding notification message. and transmit the generated notification message to the client 110; and when the login verification information matches the login verification information, the platform end 150 can perform data collection operations. For example, the platform end 150 can obtain an individual certified by the financial institution end 130 data, perform specific operations on the obtained personal data to generate corresponding customer authentication information, and transmit the generated customer authentication information to the client 110. Among them, the above-mentioned specific operations include but are not limited to hash operations such as MD5 or encoding operations such as base64.

The platform end 150 is also responsible for receiving the public trust signature transmitted by the public trust unit end 160, and is responsible for transmitting the received public trust signature to the authentication end 170.

The public trust unit end 160 is responsible for receiving the transaction data transmitted by the financial institution end 130, signing the received transaction data to generate a public trust signature, and transmitting the generated public trust signature to the platform end 150.

The authentication end 170 is responsible for receiving the public trust signature transmitted by the platform end 150 and can store the received public trust signature. The authentication end 170 is also responsible for generating the second certification data based on the public trust signature or can generate the second certification data containing the public trust signature, and can publish the generated second certification data to the blockchain 190 .

Next, an embodiment will be used to explain the operating system and method of the present invention, and please refer to "Figure 2A" for the flow chart of the method for verifying customer identity and transaction services using multiple security levels according to the present invention. In this embodiment, it is assumed that the client 110 can be a mobile phone or a computer, but the invention is not limited thereto.

After the user operates the client 110 to connect to the financial institution terminal 130, the user can operate the client 110 to log in to the financial institution terminal 130 using biometric characteristics (step 210). In this embodiment, it is assumed that the client 110 can use the FIDO architecture to log in to the financial institution terminal 130. Further, this embodiment can be as shown in the process of "Figure 2B" when the client 110 is connected to the financial institution terminal 130. , the financial institution end 130 can require the client 110 to log in, and can send a login verification request to the platform end 150, so that the platform end 150 requires the client 110 to provide login verification information (step 211). After receiving the request to provide login verification information sent by the platform 150, the client 110 can require the user to use biometric features such as fingerprints, face, iris, etc. for biometric identification, and can obtain the user's biometric features and After it is determined that the obtained biometric characteristics have passed the biometric identification, the pre-stored login verification information and the institutional login information of the financial institution side 130 are read from the trusted module, and the read login verification information and institutional login information can be Transmitted to the platform end 150 (step 215). After the platform 150 receives the login verification information and the organization login information sent by the client 110, it can verify the received login verification information. If the login verification data passes the verification of the platform side 150, the platform side 150 can, after judging that the login verification data passes the verification, send the received institution login data to the financial institution side 130, so that the financial institution side 130 allows the client 110 to log in ( Step 219).

Returning to "Figure 2A", after the client 110 uses the FIDO architecture to log in to the financial institution end 130 with biometrics (step 210), the client 110 can request transaction services from the financial institution end 130, that is, send the transaction service to the financial institution end 130. Transaction service requests. The financial institution 130 may determine the risk level of the requested transaction service when receiving a request for the transaction service from the client 110 . When the risk level of the requested transaction service belongs to the basic transaction level, that is, when the requested transaction service is the basic transaction level, the financial institution end 130 can generate an identity verification request and can transmit the generated identity verification request to the platform. The client 150 causes the platform client 150 to require the client 110 to perform identity verification (step 220). In this embodiment, it is assumed that all transaction services are at the basic transaction level.

When the client 110 receives the identity verification request sent by the platform 150, the client 110 can read the transaction verification data from the trusted module, and encrypt the read transaction verification data to generate transaction encryption data, and The generated transaction encryption data can be transmitted to the platform 150 (step 231). In this embodiment, it is assumed that the client 110 and the platform 150 have agreed in advance to encrypt transaction verification data using the private key of the client 110 and the time-based one-time password generated by the platform 150 to generate transaction encrypted data. For example, the client 110 can first use the private key to encrypt the transaction verification data with the RSA algorithm to generate intermediate ciphertext, and then use the one-time password obtained by synchronizing with the platform 150 every predetermined time (such as 60 seconds) to encrypt the intermediate ciphertext to generate When trading encrypted data, the client 110 can also generate a statement issuance request and send it to the platform 150 together with the confidential encrypted data.

After the platform 150 receives the transaction encrypted data sent by the client 110, it can decrypt the received transaction encrypted data to obtain the identity verification information, and can confirm the obtained identity verification information and send it to the client 110 in advance. Whether the transaction verification data is consistent to generate an identity verification result, and the generated identity verification result can be sent to the financial institution end 130 (step 235). In this embodiment, it is assumed that the platform 150 can first use the last generated time-based one-time password to decrypt the transaction encrypted data to generate intermediate ciphertext, and then use the public key of the client 110 to decrypt the intermediate ciphertext to obtain the identity verification data. , then, the platform end 150 can read the transaction verification data of the client 110, and can compare whether the obtained identity verification data is consistent with the read transaction verification data. When the two are consistent, the platform end 150 can generate The identity verification result indicates that the verification is passed. When the two do not match, the platform 150 may generate an identity verification result that indicates that the verification is not passed. In addition, when the identity verification data matches the transaction verification data, the platform 150 can also generate a valid statement corresponding to the distributed digital identity data of the user of the client based on the received statement issuance request sent by the client 110. Verify the claim and can publish the issued verifiable claim to the blockchain 190.

Similarly, after the platform 150 receives the transaction encrypted data sent by the client 110, it can generate the first certificate data based on the identity verification request received from the financial institution 130 and the transaction encrypted data received from the client 110, and can generate the first certificate data. The generated first certificate data is published to the blockchain 190 (step 240), so that the data is certificated through the blockchain 190. In this embodiment, it is assumed that the platform 150 can perform a hash operation on the identity verification request and the transaction encryption data to generate the first certificate data.

After the financial institution end 130 receives the identity verification result generated by the platform end 150, it can determine whether the received identity verification result indicates that the verification has been passed. If not, the financial institution end 130 can reject the transaction service requested by the client 110. , and if the identity verification result indicates that the verification is passed, the financial institution end 130 can generate transaction data corresponding to the transaction service requested by the client 110 (step 250). Among them, the financial institution end 130 can directly determine whether the identity verification result indicates that the identity verification result is passed based on the identity verification result transmitted by the platform end 150, or it can also obtain it from the blockchain 190 based on the distributed digital identity identification data of the user of the client end 110. Verifiable statement (identity verification result), and can use the public key of the platform 150 to verify the signature in the verifiable statement obtained, and confirm the validity and expiration time, thereby verifying the obtained verifiable statement, when it can After the verification statement passes the verification of the financial institution end 130 and the identity of the user of the client 110 is confirmed in the verifiable statement, the financial institution end 130 can determine that the identity verification result indicates that the verification has been passed.

Then, the financial institution end 130 can determine whether the transaction service requested by the client 110 is an actual transaction level, that is, determine whether the risk level of the transaction service belongs to the actual transaction level. If not, the financial institution end 130 can execute the requested transaction. Services, such as data query, etc.; and if the transaction service requested by the client 110 is the actual transaction level, that is, the risk level of the transaction service belongs to the actual transaction level, the financial institution end 130 can transmit the generated transaction data to the public trust unit Terminal 160 (step 261). In this embodiment, it is assumed that the actual transaction level is a transaction service involving monetary transactions, and the transaction data includes data related to commodities traded in monetary transactions.

After the public trust unit end 160 receives the transaction data transmitted by the financial institution end 130, the public trust unit end 160 can sign the transaction data to generate a public trust signature, and can transmit the generated public trust signature to the platform end 150 (step 263).

After the platform end 150 receives the public trust signature transmitted by the public trust unit end 160, it can transmit the received public trust signature to the client 110 or to the verification terminal 170. After receiving the public trust signature transmitted by the platform side 150, the client 110 can store the received public trust signature in the trusted module; after receiving the public trust signature transmitted by the platform side 150, the authentication terminal 170 , the second certifying data can be generated based on the received public trust signature, and the generated second certifying data can be published to the blockchain 190 (step 265), so as to store the data through the blockchain 190 Certificate. In this embodiment, it is assumed that the verification terminal 170 can perform a hash operation on the public signature to generate the second certificate data.

In this way, through the present invention, the financial institution 130 can select the security verification mechanism that needs to be executed according to the risk level of the transaction service requested by the client 110, thereby using different security verification technologies to complete transaction services of different risk levels, just like using multiple keys. By opening different transaction doors, even if one of the keys is lost, the attacker still cannot use a single key to conduct a fake transaction attack. Therefore, the present invention can increase the cost of crime and take into account transaction security and convenience.

In the above embodiment, the risk level of the transaction service may also include the regulatory transaction level. As shown in the process of "Figure 2C", after the financial institution 130 transmits the transaction data to the public trust unit 160 (step 261) (in practice) The platform side 150 can also transmit the public trust signature generated by the public trust unit side 160 to the client 110 and/or the authentication side 170), and the financial institution side 130 can further determine whether the transaction service requested by the client 110 is regulated. The transaction level is to determine whether the risk level of the transaction service belongs to the regulated transaction level. If not, the financial institution end 130 can execute the requested transaction service, such as small-amount transactions; and if the transaction service is the regulated transaction level, the financial institution end 130 130 can generate a module verification request, and can transmit the generated module verification request to the platform end 150, so that the platform end 150 requests the client 110 for trusted module verification (step 271).

When the client 110 receives the request to verify the trusted module sent by the platform 150, the client 110 can read the trusted security information from the trusted module and encrypt the read trusted security information to generate The module encrypts the data, and can transmit the generated module encryption data to the platform 150 (step 273). In this embodiment, it is assumed that the client 110 and the platform 150 have agreed in advance to encrypt trusted security data using the private key of the client 110 and the time-based one-time password generated by the platform 150 to generate module encrypted data, that is, That is, similar to encrypted transaction verification data, the client 110 can first read all, part, or specific data from the trusted module as trusted security data, and can use the private key to encrypt the trusted security data. The intermediate ciphertext is generated, and then the intermediate ciphertext is encrypted using a one-time password obtained by synchronizing with the platform end 150 every predetermined time (such as 30 seconds or less) to generate module encrypted data.

After the platform 150 receives the module encrypted data sent by the client 110, it can decrypt the received module encrypted data to obtain the module verification data, and can compare the obtained module verification data with the pre-set Whether the stored trusted security information matches (step 275). In this embodiment, it is assumed that the platform 150 can first use the last generated time-based one-time password to decrypt the module encrypted data to generate an intermediate ciphertext, and then use the public key of the client 110 to decrypt the intermediate ciphertext to obtain the module verification Verify the data. Then, the platform 150 can read the trusted security information of the client 110, and can compare whether the obtained identity verification data is consistent with the read transaction verification data.

When the module verification data does not match the trusted security data, the financial institution end 130 can refuse to execute the transaction service requested by the client 110; and when the module verification data matches the trusted security information, the financial institution end 130 The first reporting information can be generated and transmitted to the platform terminal 150 (step 277), and the transaction service requested by the client 110 can be performed. In this embodiment, it is assumed that the platform end 150 can generate a comparison result indicating whether the module verification data is consistent with the trusted security information, and can transmit the generated comparison result to the financial institution end 130. When the module When the group inspection information matches the credible security information, the platform side 150 can generate a declaration form, and can transmit the declaration form and the comparison results to the financial institution side 130; the financial institution side 130 can use the comparison generated by the platform side 150 to The client 110 may be selected to refuse service when the result indicates that the module verification data is inconsistent with the trusted security information, or the client 110 may be selected to rely on the information sent by the platform 150 when the comparison result indicates that the module verification data is consistent with the trusted security information. The declaration form generates the first declaration information and completes the large-amount transaction requested by the client 110.

After the platform end 150 receives the first reporting information sent by the financial institution end 130, the platform end 150 can generate the second reporting information including the first reporting information, and can transmit the generated second reporting information to the regulatory end. , and can generate the third storage certificate data based on the module verification request received from the financial institution terminal 130, the module encryption data received from the client 110, and the generated second declaration data, and use the generated third storage certificate data The certification data is published to the blockchain 190 (step 279), so that the data is certified through the blockchain 190. In this embodiment, it is assumed that the platform 150 can perform a hash operation on the module verification request, the module encryption data, and the second declaration data to generate the third certificate data.

In addition, in the above embodiment, as shown in the process of "Figure 3A", before the client 110 uses the FIDO architecture to log in to the financial institution end 130 with biometrics (step 210), the client 110 can send a request to the platform end 150 or The financial institution end 130 applies for a trusted module (step 311). The platform side 150 or the financial institution side 130 can notify the cooperating telecommunications provider to produce a trusted module, and can deliver the trusted module to the user of the client 110 through personal delivery or mail.

Then, the service staff of the platform 150 or the financial institution 130 where the client 110 applies for the trusted module can operate the server 120 to input the device identification information of the client 110 and can transmit the device identification information to the platform 150 through the network. or the financial institution side 130, thereby enabling the trusted module online (step 313), that is, the platform side 150 or the financial institution side 130 records the corresponding relationship between the trusted module and the identification data of the client 110, so that the platform side 150 or The financial institution 130 can confirm that the computing device accessing the trusted module is the client 110 that applied for the trusted module. In this way, after the trusted module is enabled, the user of the client 110 can install the trusted module in the client 110 (step 315). After that, the user of the client 110 can operate the client 110 to perform biometric identification. Identification, the client 110 can access the trusted module after the user's biometrics pass biometric identification to confirm whether the trusted module is successfully activated.

In addition, before the client 110 uses the FIDO architecture to log in to the financial institution 130 with biometrics (step 210), the user can also operate the client 110 to connect to the platform as shown in the process in "Figure 3B". After 150, the client 110 is operated to register on the platform 150, so that the client 110 completes the registration on the platform 150 through real-name verification (step 351).

The platform 150 can generate login verification data and transaction verification data corresponding to the client 110 after the client 110 completes the registration, and can store the generated login verification data, transaction verification data, and the public key of the client 110, and The generated login verification information and transaction verification information can be sent to the client 110 (step 353), so that the client 110 stores the login verification information, transaction verification information, and private key sent by the platform 150 in the trusted module middle.

Later, when the client 110 receives the request for identity verification, the client 110 can ask the user to perform biometric identification. After the user's biometric identification passes the biometric identification, the client 110 can read it out from the trusted module. Login verification data is encrypted to generate login encryption data, and the generated login encryption data can be sent to the platform 150 (step 361). The process of encrypting the login verification data by the client 110 is the same as the above-mentioned encryption process and will not be described again.

After the platform 150 receives the login encrypted information sent by the client 110, the platform 150 can decrypt the login encrypted information to obtain the login verification information, and can compare the login verification information with the stored login information corresponding to the client 110. Log in verification information (step 365). The process of the platform side 150 decrypting the login encrypted data to obtain the login verification data is the same as the above-mentioned decryption process and will not be described again.

When the platform end 150 determines that the login verification information obtained by decryption is consistent with the read login verification information, the platform end 150 can obtain the personal information authenticated by the financial institution end 130, and the platform end 150 or the public trust unit end 160 will verify the platform The personal data obtained by the client 150 performs specific operations to generate corresponding client authentication information and transmits the generated client authentication information to the client 110, so that the client 110 can store the received client authentication information in a trusted mode. In the group, or the financial institution 130 can obtain the customer authentication information (authorization permission) from the client 110 through the oAuth 2.0 mechanism and send the customer authentication information to the platform 150, thereby downloading the personal information corresponding to the customer authentication information from the platform 150 (Step 370).

To sum up, it can be seen that the difference between the present invention and the prior art is that after the client uses the online fast authentication framework to log in to the financial institution with biometrics, the financial institution uses the requested transaction when the client requests transaction services. The risk level of the service selects the corresponding security verification method to verify the customer's identity, and publishes the certificate data that can verify the verification data generated by the verification process and the transaction data of the requested transaction service to the blockchain. Technical means, through this technical means, can solve the problem of previous technology that there is no mutual trust between domestic financial institutions in the verification process and standards, thereby improving the complexity and cost of crime, reducing the wasted resources of financial institutions, and taking into account transactions Technical efficacy for safety and convenience.

Furthermore, the method of using multiple security levels to verify customer identity and transaction services of the present invention can be implemented in hardware, software, or a combination of hardware and software. It can also be implemented in a centralized manner in a computer system or distributed with different components. Implemented in a decentralized manner across several interconnected computer systems.

Although the embodiments of the present invention are disclosed above, the content described is not intended to directly limit the scope of patent protection of the present invention. Anyone with ordinary knowledge in the technical field to which the present invention belongs can make slight modifications and modifications to the form and details of the implementation of the present invention without departing from the spirit and scope disclosed by the present invention, which shall fall under the patent protection of the present invention. Scope. The scope of patent protection for this invention must still be defined by the scope of the attached patent application.

110:Client 120:Server 130: Financial institution side 150:Platform side 160:Public trust unit end 170: Forensic end 190:Blockchain Step 210: The client uses biometrics to log in to the financial institution. Step 211: The financial institution side sends a login verification request to the platform side when requesting the client to log in, so that the platform side requests login verification information from the client side. Step 215: After passing the biometric identification, the client reads the institutional login information and login verification information from the financial institution, and sends the login verification information and institutional login information to the platform. Step 219: After the login verification information is verified, the platform side transmits the institution login information to the financial institution side, so that the financial institution side allows the client to log in. Step 220: When the client requests transaction services and determines that the transaction service is at the basic transaction level, the financial institution sends an identity verification request to the platform, so that the platform requires the client to perform identity verification. Step 231: The client encrypts the transaction verification data to generate transaction encryption data and sends the transaction encryption data to the platform. Step 235: The platform decrypts the transaction encrypted data to obtain the identity verification data and sends the identity verification result indicating whether the identity verification data matches the transaction verification data to the financial institution. Step 240: The platform generates the first certificate data based on the identity verification request and transaction encryption data and publishes it to the blockchain Step 250: When the identity verification result indicates that the verification is passed, the financial institution generates transaction data corresponding to the transaction service. Step 261: When the financial institution determines that the transaction service is at the actual transaction level, it sends the transaction data to the public trust institution. Step 263: The public trust unit signs the transaction data to generate a public trust signature, and transmits the public trust signature to the platform. Step 265: The platform sends the trustworthy signature to the verification side, and the verification side generates the second certificate data based on the trustworthy signature and publishes it to the blockchain. Step 271: When the financial institution determines that the transaction service is at the regulated transaction level, it sends a module verification request to the platform, so that the platform requests the client for trusted module verification. Step 273: The client encrypts the trusted security data stored in the trusted module to generate module encrypted data, and sends the module encrypted data to the platform. Step 275: The platform decrypts the module encrypted data to obtain the module verification data and compares the module verification data with trusted security data. Step 277: When the module verification data matches the trusted security data, the financial institution generates the first declaration data and transmits it to the platform. Step 279: The platform generates the second declaration data including the first declaration data, and generates the third certificate data based on the module verification request, module encryption data and the second declaration data and publishes it to the blockchain Step 311: The client applies for the entity’s trusted module from the platform or financial institution. Step 313: The server enters the client's device identification information online to enable the trusted module. Step 315: Client installs trusted module Step 351: The client completes registration on the platform through real-name verification Step 353: The platform sends login verification information and transaction verification information to the client Step 361: After the client performs biometric identification on the user, it encrypts the login verification data to generate the login encrypted data and sends the login encrypted data to the platform. Step 365: The platform decrypts the login encrypted data to obtain the login verification data and compares the login verification data with the login verification data. Step 370: When the login verification information matches the login verification information, the platform side obtains the personal data authenticated by the financial institution side, and the platform side or the public trust unit side calculates the personal data to generate the corresponding customer authentication data and sends it to The client stores, or the financial institution obtains customer authentication information from the client, and sends the customer authentication information to the platform to download personal information from the platform.

Figure 1 is a system architecture diagram of using multiple security levels to verify customer identity and transaction services according to the present invention. Figure 2A is a flow chart of the method for verifying customer identity and transaction services using multiple security levels according to the present invention. Figure 2B is a flow chart of the method for the client to log in to the financial institution according to the present invention. Figure 2C is a flow chart of an additional method for verifying customer identity and transaction services using multiple security levels according to the present invention. Figure 3A is a flow chart of a method for installing a trusted module on a client according to the present invention. Figure 3B is a flow chart of the method for the client to complete registration on the platform according to the present invention.

Step 210: The client uses biometrics to log in to the financial institution.

Step 220: When the client requests transaction services and determines that the transaction service is at the basic transaction level, the financial institution sends an identity verification request to the platform, so that the platform requires the client to perform identity verification.

Step 231: The client encrypts the transaction verification data to generate transaction encryption data and sends the transaction encryption data to the platform.

Step 235: The platform decrypts the transaction encrypted data to obtain the identity verification data and sends the identity verification result indicating whether the identity verification data matches the transaction verification data to the financial institution.

Step 240: The platform generates the first certificate data based on the identity verification request and transaction encryption data and publishes it to the blockchain

Step 250: When the identity verification result indicates that the verification is passed, the financial institution generates transaction data corresponding to the transaction service.

Step 261: When the financial institution determines that the transaction service is at the actual transaction level, it sends the transaction data to the public trust institution.

Step 263: The public trust unit signs the transaction data to generate a public trust signature, and transmits the public trust signature to the platform.

Step 265: The platform sends the trustworthy signature to the verification side, and the verification side generates the second certificate data based on the trustworthy signature and publishes it to the blockchain.

Claims (10)

A method for verifying client identity and transaction services using multiple security levels. The method at least includes the following steps: a client logs in to a financial institution using biometric characteristics; the financial institution requests a transaction service from the client and determines the transaction service When the risk level is the basic transaction level, the financial institution sends an identity verification request to a platform, so that the platform requires the client to perform identity verification; the client encrypts the information generated by the platform after it is registered on the platform. A transaction verification data to generate a transaction encryption data and the client sends the transaction encryption data to the platform; the platform decrypts the transaction encryption data to obtain an identity verification data and the platform confirms that the identity verification data is consistent with After the transaction verification data generated when the client is registered matches, the platform sends an identity verification result to the financial institution; the platform generates a first certificate of information based on the identity verification request and the transaction encryption data and Publish the first certificate information into a blockchain; when the identity verification result indicates that the verification is passed, the financial institution generates transaction data corresponding to the transaction service; the financial institution determines the transaction When the service is at the actual transaction level, the financial institution sends the transaction data to a trustworthy unit; the trustworthy unit signs the transaction data to generate a trustworthy signature, and the trustworthy unit sends the trustworthy signature to the trustworthy unit. The platform side; and the platform side sends the trustworthy signature to a verification side, and the verification side generates a second certification data based on the public trust signature and publishes the second certification data to the blockchain. The method of using multiple security levels to verify client identity and transaction services as described in request 1, wherein the method further includes the step of determining on the financial institution end that the requested transaction service is an actual transaction level, and further includes the step of determining on the financial institution end that the requested transaction service is an actual transaction level. When the transaction service is at the regulated transaction level, a module verification request is sent to the platform, and the platform requests the client for trusted module verification so that the client encrypts the trusted module installed on the client. Set a stored trusted security data to generate a module encrypted data and send the module encrypted data to the platform. The platform decrypts the module encrypted data to obtain a module verification data and compares the module The module verification information is combined with the trusted security information. When the module verification information matches the credible security information, the financial institution generates a first declaration information and transmits it to the platform. The platform generates a first declaration information containing the trusted security information. The first reporting data and the second reporting data are sent to a supervisory end, and a third storage certification data is generated based on the module verification request, the module encryption data and the second reporting data, and the third storage certification data is released. Steps to authenticate data to the blockchain. The method of using multiple security levels to verify customer identity and transaction services as described in request item 1, wherein the method further includes the step of the client logging in to the financial institution with biometrics, including the client using real-name authentication on the platform. After the verification is completed and the registration is completed, the platform sends a login verification information and a transaction verification information to the client. After the client performs biometric identification on the user, it encrypts the login verification information to generate a login encryption information and sends the login encryption The data is sent to the platform end, and the platform end decrypts the login encrypted information to obtain a login verification information and compares the login verification information with the login verification information. When the login verification information matches the login verification information, the The platform side obtains personal data authenticated by the financial institution side, and the platform side or the public trust unit side performs calculations on the personal data to generate corresponding customer authentication information and transmits it to the client side for storage, or the financial institution side uses The client obtains the customer authentication information and sends the customer authentication information to the platform to download the personal information from the platform. The method of using multiple security levels to verify customer identity and transaction services as described in request 1, wherein the step of the client logging in to the financial institution using biometrics further includes the financial institution requiring the client to use online fast authentication (Fast IDentity) Online, FIDO) architecture sends a login verification request to the platform when logging in, causing the platform to request a login verification information from the client. The client obtains the institutional login information of the financial institution through biometric identification and After reading the login verification information, send the login verification information and the institution's login information to the platform. After the platform successfully verifies the login verification information sent by the client, it sends the institution's login information to the financial institution. , the steps to enable the financial institution to allow the client to log in. The method of using multiple security levels to verify client identity and transaction services as described in request item 1, wherein the method further includes the client sending a request to the platform or the financial institution before the client uses biometrics to log in to the financial institution. After the financial institution applies for a trusted module of the entity, a server inputs the client's device identification information online to enable the trusted module, and the client installs the trusted module. A system that uses multiple security levels to verify customer identity and transaction services. The system at least includes: a client installed with a trusted module that stores a transaction verification data; a financial institution terminal used to provide the The client logs in with biometrics, requests a transaction service from the client, and determines whether the risk level of the transaction service is in compliance with the basic transaction level. When the transaction service is the basic transaction level, an identity verification request is generated; 1. The platform side is used to receive the identity verification request sent by the financial institution side, and require the client side to perform identity verification, so that the client side encrypts the transaction verification data to generate the transaction verification information generated by the platform side after the platform side registers. Transaction encrypted data and transmit the transaction encrypted data to the platform terminal, and is used to decrypt the transaction encrypted data to obtain an identity verification information and confirm that the identity verification information is consistent with the transaction verification information generated when the client is registered, based on the identity verification request and the transaction encryption data Generate a first certificate of deposit information and publish the first certificate of deposit information to a blockchain, and send an identity verification result to the financial institution, so that when the identity verification result indicates that the verification is passed, the financial institution generates and A transaction data corresponding to the requested transaction service; a public trust unit terminal, used to receive the transaction data sent by the financial institution when it determines that the transaction service is an actual transaction level, and sign the transaction data to generate a public trust unit Sign and send the trustworthy signature to the platform; and an authentication terminal to receive the trustworthy signature sent by the platform, generate a second certificated information based on the trustworthy signature, and publish the Secondly, the certificate information is stored in the blockchain. As described in request 6, the system uses multiple security levels to verify customer identity and transaction services, wherein the financial institution is further used to further determine that the transaction service is a regulated transaction level when the transaction service meets the actual transaction level, and transmit A module verification request is sent to the platform, causing the platform to request trusted module verification from the client. The client is further used to encrypt a trusted module stored in the trusted module installed on the client. The security data is used to generate a module encrypted data and send the module encrypted data to the platform. The platform is further used to decrypt the module encrypted data to obtain a module verification data and compare the module verification data. When the module verification information matches the credible security information, the financial institution generates a first reporting data and sends it to the platform. The platform generates a first reporting data containing the first reporting data. A second reporting information is sent to a regulatory end, and a third certifying information is generated based on the module verification request, the module encrypted data and the second reporting information, and the third certifying information is released to the Blockchain. A system that uses multiple security levels to verify customer identity and transaction services as described in request 6, wherein the platform is further used to send a login verification information and the transaction verification information to the customer when the client completes registration through real-name verification. The client is further used to perform biometric identification on the user, encrypt the login verification information to generate an encrypted login information and send the encrypted login information to the platform end, so that the platform end decrypts the encrypted login information to obtain an encrypted login information. Login verification information and compare the login verification information with the login verification information. When the login verification information matches the login verification information, the platform side obtains personal information certified by the financial institution side and the platform side The client or the public trust unit performs calculations on the personal data to generate corresponding client authentication information and sends it to the client for storage, or the financial institution acquires the client authentication information from the client and sends the client authentication information to the client. Platform side to download the personal data from the platform side. A system that uses multiple security levels to verify client identity and transaction services as described in request 6, wherein the financial institution is further configured to send a login verification request to the platform when requiring the client to log in using an online fast authentication framework, The platform side requests a login verification information from the client side, and the client side is further used to obtain the institutional login information of the financial institution side through biometric identification and after the trusted module reads the login verification information, Send the login verification information and the institution's login information to the platform. The platform is further used to send the institution's login information to the financial institution after successfully verifying the login verification information sent by the client, so that the financial institution can The organization allows the client to log in. A system that uses multiple security levels to verify client identity and transaction services as described in request 9, wherein the platform is further configured to receive a statement issuance request sent by the client, and confirm the identity verification information and the transaction When the verification information matches, a verifiable statement corresponding to the user's distributed digital identification information of the client and the statement issuance request is issued, and the verifiable statement is published to the blockchain, and the financial institution end uses Based on the decentralized digital identity of the user of the client The identification data is obtained from the blockchain and verifies the verifiable statement, and when the verifiable statement is verified, it is determined that the identity verification result indicates that the verification has been passed.

Images