CN101820346B - Secure digital signature method - Google Patents

Secure digital signature method Download PDF

Info

Publication number
CN101820346B
CN101820346B CN2010101682067A CN201010168206A CN101820346B CN 101820346 B CN101820346 B CN 101820346B CN 2010101682067 A CN2010101682067 A CN 2010101682067A CN 201010168206 A CN201010168206 A CN 201010168206A CN 101820346 B CN101820346 B CN 101820346B
Authority
CN
China
Prior art keywords
signed
data
usbkey
client host
transaction
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.)
Expired - Fee Related
Application number
CN2010101682067A
Other languages
Chinese (zh)
Other versions
CN101820346A (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.)
Feitian Technologies Co Ltd
Original Assignee
Feitian Technologies 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 Feitian Technologies Co Ltd filed Critical Feitian Technologies Co Ltd
Priority to CN2010101682067A priority Critical patent/CN101820346B/en
Publication of CN101820346A publication Critical patent/CN101820346A/en
Application granted granted Critical
Publication of CN101820346B publication Critical patent/CN101820346B/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Computer And Data Communications (AREA)

Abstract

The invention discloses a secure digital signature method, belonging to the field of information security. The method comprises the following steps: a client host sends trading information to a trading server; the trading server generates video and/or audio trading confirmation data based on the trading information; the client host assigns a signature command and the trading confirmation data to a usbkey; the usbkey outputs the trading confirmation data, and waits for a confirmation signal; if the usbkey receives the confirmation signal, the digital signature operation is carried out on the trading confirmation data; and a digital signature result is returned to the trading server by the client host, and the trading server executes the trading operation after the digital signature result is verified to be accurate.

Description

Secure digital signature method
Technical Field
The invention relates to the field of information security, in particular to a secure digital signature method.
Background
The popularization of the internet banking brings convenience to the life of people, but the transaction of the internet banking needs to be carried out through the network, so that the potential safety hazard exists in the transaction of the internet banking, and lawless persons change various attacking means aiming at the internet banking, so that the safety problem is mainly solved in the health development of the internet banking.
In order to ensure the fund security of the user, the bank takes various measures to improve the security of the user identity authentication. Currently, the most common use of internet banking is a usb key (smart key device) secure digital certificate based on a smart card. The usbkey combines the smart card technology and the PKI (Public Key Infrastructure) technology, and uses a smart card chip with a built-in operating system to protect the private Key of a user, thereby realizing reliable digital identity authentication and digital signature.
In order to further ensure the security of the transaction, the new generation of usbkey generally has a display function, that is, some relatively sensitive transaction information in the transaction is displayed to the user in a text form through a display screen, and the usbkey executes a digital signature operation after the user confirms the transaction information. However, at present, such usbkey has at least the following problems: the existing usbkey with the display function is usually internally provided with a huge word stock so as to ensure that the transaction information can be completely and correctly output; meanwhile, the usbkey may also be required to have partial word processing functions, such as different sizes of English characters, word line feed, and the like. These problems limit the applicability of usbkey.
The Crypto API is a set of public interfaces provided by Microsoft, comprises a series of functions, and provides security services such as encryption and decryption, digital signature, hash (hash) and the like for an application program, and the application program does not need to be concerned about the specific implementation of the application program. Different vendors may develop independent Cryptographic modules called Cryptographic Service Providers (CSPs) that perform key generation/exchange, data encryption/decryption, digital signature, authentication, and other services. Multiple CSP modules may be loaded in a system, independent of each other. The application may use any one of the CSP modules without regard to its specific implementation, each CSP implementing a different implementation of the Crypto API.
Disclosure of Invention
The invention provides a secure digital signature method. The technical scheme is as follows:
a secure digital signature method, the method comprising:
the client host sends transaction information to a transaction server;
the transaction server generates data to be signed in an image and/or audio form according to the transaction information and sends the data to be signed to the client host;
the client host sends a signature instruction and the data to be signed to the usbkey;
the usbkey outputs the data to be signed and waits for a confirmation signal;
if the usb key receives the confirmation signal, performing digital signature operation on the data to be signed;
and returning the result of the digital signature to the transaction server through the client host, and executing transaction operation after the transaction server verifies that the result of the digital signature is correct, and ending.
The transaction information sent by the client host to the transaction server specifically includes, but is not limited to, a transaction account number, a transaction amount, and a transaction type.
The transaction server generates data to be signed in the form of images and/or audio according to the transaction information, and the method further comprises the following steps:
the language used in the data to be signed is the language specified in the transaction information; or
And the transaction server judges the region of the client host and uses the language of the region of the client host as the language used in the data to be signed.
The transaction server generates data to be signed in the form of images and/or audio according to the transaction information, and the method further comprises the following steps:
the transaction server generates the data to be signed in the form of the image and/or the audio according to the type of the data to be signed specified in the transaction information; or
And the transaction server generates the data to be signed in the form of the image and/or the audio according to the default data type to be signed which is determined in advance.
The transaction server generates data to be signed in an image and/or audio form according to the transaction information, wherein the image comprises a static picture and a dynamic video;
the format of the still picture includes, but is not limited to, a bitmap format;
the format of the dynamic video and/or audio includes, but is not limited to, a streaming media format.
The usbkey outputs the data to be signed, and the method specifically comprises the following steps:
and the usb key outputs the data to be signed in the form of the image and/or the audio through a screen and/or an audio playing device carried by the usb key.
The usbkey outputs the data to be signed, and the method further comprises the following steps:
the usb key judges the type of the data to be signed and selects a proper mode to output the data to be signed according to the judgment result; or
And the usbkey selects a corresponding mode to output the data to be signed according to the received description of the type of the data to be signed, which is issued by the client host.
After the usbkey receives the signature instruction, the method further comprises:
the usbkey starts timing after receiving the signature command;
if the usbkey does not receive the confirmation signal, judging whether the time obtained by timing exceeds preset time or not;
and if the time counted exceeds the preset time, canceling the execution of the received signature instruction.
After the usb key receives the signature instruction and before performing a digital signature operation on the data to be signed, the method further includes:
and the usbkey performs identity authentication on the user.
The method for authenticating the user by the usbkey specifically comprises the following steps:
the usbkey receives a PIN code or biological characteristic information input by a user;
and if the usbkey verifies that the PIN code or the biological characteristic information is correct, the user identity is legal.
The method for the usbkey to receive the PIN code or the biological characteristic information input by the user comprises the following steps:
the usb key receives the PIN code or the biological characteristic information input by the user through a keyboard or a biological characteristic receiving device of the usb key;
or
And the client host receives the PIN code or the biological characteristic information input by the user and sends the PIN code or the biological characteristic information input by the user to the usbkey.
Before the usbkey digitally signs the data to be signed, the method further comprises:
the usb key receives the data to be signed sent by the client host, performs hash operation on the data to be signed, adds an algorithm identification string to a hash value obtained by the hash operation, and performs bit supplementing on the hash value added with the algorithm identification string according to a public key cryptography standard; or
The usb key receives a hash value sent by a client host and subjected to hash operation on the data to be signed, adds an algorithm identification string to the hash value, and performs bit complement on the hash value added with the algorithm identification string according to a public key cryptography standard; or
The usbkey receives a hash value which is sent by the client host and used for carrying out hash operation on the data to be signed and adding the algorithm identification string, and the hash value added with the algorithm identification string is subjected to bit supplementing according to the public key cryptography standard; or
And the usbkey receives a hash value which is sent by the client host and obtained by carrying out hash operation, adding an algorithm identification string and carrying out bit complementing according to the public key cryptography standard on the data to be signed in sequence.
The returning the result of the digital signature to the transaction server through the client host, the method further comprising:
and if the transaction server verifies that the result of the digital signature is wrong, the transaction server returns error information to the client host and stops transaction operation.
The technical scheme provided by the invention has the beneficial effects that:
the transaction server side encapsulates the transaction information in the form of multimedia data such as images and sounds, the usbkey only needs to output the transaction information in the form of images or sounds according to a set format, other processing on the data is not needed, and the safety and maintainability of the transaction system are improved.
Drawings
Fig. 1 is a flowchart of a secure digital signature method provided in embodiment 1 of the present invention;
fig. 2 is a flowchart of another secure digital signature method provided in embodiment 1 of the present invention;
fig. 3 is a diagram illustrating data to be signed in a secure digital signature method according to embodiment 1 of the present invention;
fig. 4 is a diagram illustrating data to be signed in a secure digital signature method according to embodiment 1 of the present invention;
fig. 5 is a diagram illustrating data to be signed in a secure digital signature method according to embodiment 1 of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
Example 1
The usbkey in this embodiment has SHA1(Secure Hash Algorithm) and RSA Algorithm built in. The usbkey receives an instruction from the client host, the received instruction is generally an instruction in an APDU (application protocol data unit) format, and the usbkey completes various operations according to the instruction. The client host is provided with middleware used with the usbkey, and the middleware provides a Microsoft defined Crypto API interface for an upper-layer application program (such as an IE browser). When the upper application program calls the interface, the middleware generates a corresponding APDU instruction and sends the APDU instruction to the usbkey, and the usbkey is informed to operate. Referring to fig. 1, embodiment 1 of the present invention provides a secure digital signature method, including:
step 101, a client host sends a transaction request and transaction information to a transaction server;
in the embodiment of the invention, the client host is used as a transaction client to submit the transaction request and the transaction information of a user to the transaction server;
specifically, the transaction information includes, but is not limited to, a transaction type, a transaction amount, a transaction account number, specified language information, a data type to be signed, and the like;
the appointed language information is used for appointing a language used in the transaction process, and comprises the language used by data to be signed generated in a transaction server;
the data type to be signed comprises multimedia data such as pictures, videos and/or audios in streaming media formats and the like;
wherein, the specified language information and the data type to be signed can be defaults.
In this embodiment, the transaction type is a transfer transaction, and the transaction information submitted by the client host includes the transaction type (transfer), a transfer destination account number, and a transaction amount.
102, the transaction server generates data to be signed according to the received transaction information and sends the data to be signed to the client host;
in this step, the transaction server generates data to be signed including part or all of the transaction information according to the received transaction information submitted by the client host, and the method specifically comprises the following steps:
the transaction server processes the data contained in the transaction information according to a preset format to generate data to be signed;
the data to be signed generated by the transaction server is one or more pictures containing all or part of transaction information, and the pictures can adopt a bitmap format; in addition, the data to be signed generated by the transaction server can also be multimedia data of a piece of video and/or audio in streaming media format.
When the type of the data to be signed in the transaction information submitted by the client host is default, the transaction server generates the data to be signed according to a predetermined format;
in this embodiment, the format of the data to be signed generated by the transaction server when the type of the data to be signed is the default is a bitmap.
The language used in the data to be signed generated by the transaction server is the language specified in the specified language information in the transaction information submitted by the client host;
when the specified language information in the transaction information submitted by the client host is default, the transaction server judges the region of the client according to the IP address of the client host, and uses the native language of the region in the generated data to be signed; or the data to be signed is generated by using a default language in the transaction server, such as english, chinese (simplified, mandarin), and the like, for example, one piece of data to be signed may be generated by using english and then issued, or three pieces of data to be signed having the same meaning may be generated by using english, chinese, and japanese at the same time and then issued.
Step 103, after the client host receives the data to be signed, the upper application program calls a Crypto API interface to create a context;
specifically, an upper-layer application program in the client host calls a function CryptAcquireContext (& hProv, sz conteniername, sz cpname, dwKeySpec, 0) in a Crypto API interface to create a context, that is, performs initialization operation of a digital signature;
when the upper application calls the CryptoCquireContext function to obtain a CSP operation handle, the type and name of the CSP can be specified. If a type and name are specified, only CSP modules whose two attributes match will be called. After the calling is successful, the function returns the operation handle of the CSP, and then the upper application program can access the CSP and the key container in the CSP through the handle.
104, the upper application program sends the data to be signed and a hash command to the usbkey;
specifically, the upper application calls a cryptCreateHash (hProv, ALG _ ID, 0, 0, & hHash) function to create a hash object;
wherein the ALG _ ID parameter of the CryptCreateHash function is the hash algorithm identifier. Common hash algorithm identifiers include CALG _ MD5, CALG _ SHA1, CALG _ SSL3_ SHAMD5, and the like. CALG _ MD5 and CALG _ SHA1 correspond to MD5 and SHA1 algorithms respectively, and CALG _ SSL3_ SHAD 5 corresponds to the method that the same section of data is subjected to hash operation by using MD5 and SHA1 respectively, and then two sections of hash results are spliced together.
In the embodiment of the present invention, the algorithm identifier set by the upper layer application is CALG _ SHA1, and the APDU instruction issued by the middleware to the usbkey is approximately as follows:
a/hash instruction, into which the data to be signed is transferred
00 2a 90 80……
In this step, the client host receives the data to be signed sent by the transaction server and then directly sends the data to the usbkey without any processing;
in addition, the client host can also analyze the received data to be signed, analyze that the type of the data to be signed is picture, sound or other types, and send the result obtained by analysis to the usbkey, so that the usbkey can directly select a correct mode to output the data to be signed according to the result.
105, the usbkey performs hash operation on the data to be signed by using the SHA1 algorithm specified in the hash command, and caches the operation result and the data to be signed in the usbkey;
in addition, after the hash operation, the usbkey returns the status code 0x9000 of the successful operation to the client host, and at this time, the hash operation result can also be returned to the client host.
106, the client host sends an MSE (Make Security Environment establishment) instruction to the usbkey;
the MSE instruction issued by the client host is an APDU instruction sequence, the MSE instruction instructs the usbkey to adopt SHA1-RSA as a signature algorithm, and instructs an RSA key ID, and the contents contained in the APDU instruction sequence are as follows in sequence: the MSE instruction identification, the signature algorithm are SHA1-RSA algorithm identification and RSA key ID, and the specific instruction sequence is roughly as follows:
v/MSE instruction, set algorithm ID and RSA key ID
00 22 41 B6 07 80 01 12 81 02 00 01…
Wherein, the key ID of RSA specified in the MSE instruction is specified when the upper layer application calls the CryptAcquireContext function of the Crypto API interface to create a context in step 103.
Step 107, after the usbkey receives the MSE instruction, setting a currently used RSA key according to the key ID in the instruction;
after the usbkey setting is completed, a pre-agreed status code 0x9000 representing successful operation is returned to the client host.
Step 108, the client host sends a signature command to the usbkey;
the client host issues a signature command expressed in an APDU format to the usbkey, and the APDU command sequence issued by the client host is as follows: 002 a 9E 000000.
Step 109, the usbkey outputs data to be signed, and waits for a signal for confirming the signature data;
after receiving the signature command, the usbkey needs to output data to be signed and wait for a user to input a confirmation signal, in the process, the usbkey returns a state code 0x6666 which is agreed in advance and represents that a key needs to be pressed to the client host, and meanwhile, the usbkey starts timing;
the usb key can output pictures and videos on the liquid crystal screen or output audio data to be signed through a voice player of the usb key, and waits for a user to input a confirmation signal;
if the data to be signed received by the usbkey is in a bitmap format, the usbkey displays the data to be signed in a whole screen or in a split screen mode according to the pixel size, and the data to be signed can also be displayed in a reduced screen mode through a picture compression technology.
Meanwhile, the client host can prompt the user to input a confirmation signal after confirming that the data to be signed is correct in modes of images, characters, sounds and the like according to the state code returned by the usbkey.
The effect of displaying the data to be signed in the bitmap format in the usbkey is shown in fig. 3, 4 and 5.
Step 110, judging whether a confirmation signal input by a user through the usbkey is received by the usbkey; if a confirmation signal input by the user is received, 113 is executed; if the confirmation signal input by the user is not received, executing step 111;
the user judges whether the transaction information is correct or not according to the data to be signed output by the usbkey, and inputs a confirmation signal to the usbkey after judging that the transaction information is correct;
specifically, the method of inputting the confirmation signal includes:
the user inputs the confirmation signal through the keyboard on the usbkey, and the usbkey executes step 113 after receiving the confirmation signal.
In order to ensure that the user has the operation authority, the user may be authenticated by the usbkey before the user inputs the confirmation signal, and specific authentication manners include, but are not limited to: a PIN (Personal identification number) code verification mode, a biometric verification mode and the like, wherein the PIN code or the biometric can be acquired by the usbkey through a keyboard or a biometric receiving device of the usbkey, or can be acquired by the client host and then transmitted to the usbkey for verification. For example:
the user inputs the PIN code of the usbkey through a keyboard on the usbkey, and the step 113 is executed after the USbkey verifies that the PIN code is correct;
or,
the user inputs the PIN code of the usbkey through the client host, and sends the PIN code to the usbkey to verify whether the PIN code is correct, and the usbkey executes step 113 after verifying that the PIN code is correct.
Step 111, the usbkey judges whether the current time obtained by timing exceeds the preset time, if the current time obtained by timing does not exceed the preset time, the step 112 is executed; if the current time obtained by timing exceeds the preset time, executing step 117;
step 112, the usbkey receives a command for acquiring a signature result sent by the client host;
after the client host receives the status code 0x6666, the client host can repeatedly send a command for acquiring a signature result to the usbkey;
the APDU instruction sequence corresponding to the instruction for acquiring the signature result is as follows: 80E 300000000
And if the usbkey receives the instruction for acquiring the signature result sent by the client host, returning to execute 111.
In addition, after receiving the status code 0x6666, the client host may also send a command to cancel the signature to the usbkey, so that the usbkey needs to determine whether to receive a command to acquire a signature result or a command to cancel the signature, which is sent by the client host; if an instruction for acquiring a signature result sent by the client host is received, executing 111; if an instruction for canceling the signature sent by the client host is received, the usbkey stops performing the digital signature operation;
the APDU command sequence corresponding to the above-mentioned signature canceling command is: 80E 500000000.
113, signing the data to be signed by the usb key, and sending a signature result to the client host;
the usbkey adds an algorithm identification string defined by the X.509 specification in front of the hash value obtained by calculation in the step 105 according to the algorithm identification specified by the MSE instruction, and then performs bit supplementing according to the public key cryptography standard (PKCS # 1);
for example: the SHA1 algorithm identification string is 3020300 c 06082 a 864886 f 70 d 020505000410.
And performing RSA operation on the data after bit complementing to obtain a signature result, and simultaneously sending the signature result to the client machine, and returning a state code 0x9000 with successful operation.
Step 114, the client host sends the result of the digital signature to the transaction server, the transaction server verifies whether the received signature result is correct, if so, step 115 is executed; otherwise, go to step 116;
after receiving the signature result, the transaction server decrypts the received signature result by using the public key of the user and removes the complementary bit, the transaction server performs the same hash operation as that in the usbkey on the data to be signed generated in the step 102, the transaction server compares the data obtained after decrypting the signature result and removing the complementary bit with the hash value obtained through the hash operation in the transaction server, and if the two are the same, the signature result received by the transaction server is correct.
And step 115, executing subsequent transaction operation and ending the transaction flow.
And step 116, the transaction server returns error information to the client host, stops the transaction operation and ends the transaction process.
And the client host outputs the error information after receiving the error information returned by the transaction server.
Step 117.usbkey sends a signal to the client host to cancel the transaction.
The usbkey returns a state code 0x7777 which is agreed in advance and represents canceling the transaction to the client host, and the client host sends the canceling transaction information to the transaction server to finish the transaction flow.
In embodiment 1 of the present invention, the process of performing hash operation on data to be signed is completed in the usbkey, and in addition, the client host may perform hash operation on the data to be signed according to a hash algorithm agreed in advance, add an algorithm identification string defined by the x.509 specification in front of a hash value, and perform bit padding according to the public key cryptography standard (PKCS # 1); correspondingly, when the digital signature is carried out, the client host sends the hash operation result of the data to be signed and the data to be signed after bit complementing to the usbkey, the usbkey outputs the data to be signed, and after the confirmation signal is received, the digital signature is carried out on the hash operation result of the received data to be signed after bit complementing; or the client host performs hash operation on the data to be signed according to a hash algorithm agreed in advance, the client host sends the hash operation result to the usbkey, the usbkey adds an algorithm identification string defined by an X.509 specification in front of the hash value, performs bit complement according to a public key cryptography standard (PKCS #1), and then performs digital signature.
Example 2
The usbkey in this embodiment receives an instruction from the client host, where the received instruction is generally an instruction in an APDU (application protocol data unit) format, and the usbkey completes various operations according to the instruction. The client host is provided with middleware used by the usbkey, and the middleware provides a PKCS #11 interface for upper-layer application programs (such as FireFox). When the upper application program calls the interface, the middleware generates a corresponding APDU instruction and sends the APDU instruction to the usbkey, and the usbkey is informed to operate. Referring to fig. 1, embodiment 2 of the present invention provides a secure digital signature method, including:
step 201, an upper application program in a client host sends a transaction request and transaction information to a transaction server;
in the embodiment of the invention, the client host is used as a transaction client to submit the transaction request and the transaction information of a user to the transaction server;
specifically, the transaction information includes, but is not limited to, a transaction type, a transaction amount, a transaction account number, specified language information, a data type to be signed, and the like;
wherein, the specified language information and the data type to be signed can be defaults.
In this embodiment, the transaction type is a transfer transaction, and the transaction information submitted by the client host includes the transaction type (transfer), a transfer destination account number, and a transaction amount.
Step 202, the transaction server generates data to be signed according to the received transaction information and sends the data to be signed to the client host;
in this step, the transaction server generates data to be signed including part or all of the transaction information according to the received transaction information submitted by the client host, and the method specifically comprises the following steps:
the transaction server processes the data contained in the transaction information according to a preset format to generate data to be signed; the data to be signed contains all or part of transaction information.
The data to be signed generated by the transaction server can be one or more pictures containing text information, and the pictures can adopt a bitmap format; in addition, the data to be signed generated by the transaction server may also be a piece of multimedia data, for example, an audio multimedia file which may be in a streaming media format.
When the type of the data to be signed in the transaction information is default, the transaction server generates the data to be signed according to a predetermined format;
in this embodiment, the format of the data to be signed generated by the transaction server when the type of the data to be signed is the default is a picture.
The language used in the data to be signed generated by the transaction server is the language specified in the specified language information in the transaction information submitted by the client host;
or the transaction server judges the region of the client according to the IP address of the client, and uses the native language of the region in the data to be signed; or, one or more pieces of data to be signed are generated by using a default language in the transaction server, such as english, chinese (simplified, mandarin), and the like, for example, one piece of data to be signed may be generated by using english and then issued, or three pieces of data to be signed having the same meaning may be generated by using english, chinese, and japanese at the same time and then issued.
Step 203, after the client host receives the data to be signed, the upper application program calls a PKCS #11 interface to carry out initialization operation before signing, and a session is established with the usbkey;
the upper application program calls the following PKCS #11 interface functions to perform initialization operation before signature, and establishes a session with the usbkey:
v/interface initialization
C_Initialize(NULL_PTR);
// get slot list
C_GetSlotList(TRUE,pSlotList,&ulCount);
// establishing a session
C_OpenSession(m_pSlotList[0],CKF_RW_SESSION|CKF_SERIAL_SESSION,
NULL_PTR,NULL_PTR,&hSession);
Step 204, the client host performs hash operation on the data to be signed according to an agreed hash algorithm;
the client host calls a PKCS #11 interface, sets a hash algorithm as a predetermined algorithm, and then performs hash operation on data to be signed;
the called PKCS #11 interface function is as follows:
// set hash algorithm
CK_MECHANISM ckMechanismHash={CKM_SHA_1,NULL_PTR,0};
C_DigestInit(hSession,&ckMechanismHash);
V/carry out hash operation
C_Digest(hSession,pbMsg,ulMsgLen,pDigest,&ulDigestLen);
C_DigestFinal(hSession,pDigest,&ulDigestLen);
The client host adds an algorithm identification string defined by X.509 specification to the hash value obtained after the hash operation, and then carries out bit complementing according to public key cryptography standard (PKCS # 1);
for example: the SHA1 algorithm identification string is 3020300 c 06082 a 864886 f 70 d 020505000410.
In embodiment 2 of the present invention, the pre-agreed hash algorithm is the SHA1 algorithm, and the corresponding algorithm identifier is CKM _ SHA _ 1.
Step 205, the client host issues an MSE instruction to the usbkey, and sets a signature algorithm and a key used by signature;
before issuing an MSE instruction to the usbkey, the client host calls a C _ Login function of a PKCS #11 interface, logs in the usbkey to acquire the use authority of a key, then calls a CK _ MECHANISMCKMechanismSign function to set an algorithm used by a digital signature, and calls a C _ SignInit function to set a key used by the signature;
the PKCS #11 interface function called by the client host is specifically as follows:
v/log in, get Key usage Authority
C_Login(hSession,CKU_USER,ucPin,lstrlen(ucPin));
V/set signature Algorithm and signature Key
CK_MECHANISM ckMechanismSign={CKM_RSA_PKCS,NULL_PTR,0};
C_SignInit(hSession,&ckMechanismSign,hPriKey);
After the client host calls a PKCS #11 interface to complete the operation, an MSE instruction is issued to the usbkey, and a signature algorithm and a key used for signature are set;
v/MSE instruction, set signature Algorithm and Key
00 22 41 B6 80 01 12 84 02 00 23
Step 206, the usbkey sets a signature algorithm and a key according to the received MSE instruction;
after the usbkey setting is completed, a pre-agreed status code 0x9000 representing successful operation is returned to the client host.
Step 207, the client host sends the hash value and the signature command of the data to be signed to the usbkey;
and before the client host issues the hash value and the signature instruction of the data to be signed to the usbkey, the data to be signed is also sent to the usbkey.
The client host calls a C _ Sign function of a PKCS #11 interface, transmits a hash value of data to be signed through the function and acquires a signature result, and the method specifically comprises the following steps:
v/signature, get signature result
C_Sign(hSession,pDigest,ulDigestLen,bSignatureBuffer,&ulSignatureLen);
The parameter "pDigest" represents data needing digital signature, namely a hash value of data to be signed; "bSignatureBuffer" is the result of the digital signature.
The client host issues a signature command expressed in an APDU format to the usbkey, and the APDU command sequence issued by the client host is as follows: 002 a 9E 000000.
208, the usbkey outputs data to be signed, and waits for a signal for confirming the signature data;
after receiving the signature command, the usbkey needs to output data to be signed and wait for a user to input a confirmation signal, in the process, the usbkey returns a state code 0x6666 which is agreed in advance and represents that a key needs to be pressed to the client host, and meanwhile, the usbkey starts timing;
the usb key can output pictures and videos on the liquid crystal screen or output audio data to be signed through a voice player of the usb key, and waits for a user to input a confirmation signal;
if the data to be signed received by the usbkey is in a bitmap format, the usbkey displays the data to be signed in a whole screen or in a split screen mode according to the pixel size, and the data to be signed can also be displayed in a reduced screen mode through a picture compression technology.
Meanwhile, the client host can prompt the user to input a confirmation signal after confirming that the data to be signed is correct in modes of images, characters, sounds and the like according to the state code returned by the usbkey.
The effect of displaying the data to be signed in the bitmap format in the usbkey is shown in fig. 3, 4 and 5.
Step 209, judging whether a confirmation signal input by a user through the usbkey is received or not by the usbkey; if a confirmation signal of the user input is received, 212 is executed; if the confirmation signal input by the user is not received, executing step 210;
the user judges whether the transaction information is correct or not according to the data to be signed output by the usbkey, and inputs a confirmation signal to the usbkey after judging that the transaction information is correct;
specifically, the method of inputting the confirmation signal includes:
the user inputs the confirmation signal through the keyboard on the usbkey, and the usbkey executes step 212 after receiving the confirmation signal.
In order to ensure that the user has the operation authority, the user may be authenticated by the usbkey before the user inputs the confirmation signal, and specific authentication manners include, but are not limited to: a PIN (Personal identification number) code verification mode, a biometric verification mode and the like, wherein the PIN code or the biometric can be acquired by the usbkey through a keyboard or a biometric receiving device of the usbkey, or can be acquired by the client host and then transmitted to the usbkey for verification.
For example:
the user inputs the PIN code of the usbkey through a keyboard on the usbkey, and the step 212 is executed after the USbkey verifies that the PIN code is correct;
or,
the user inputs the PIN code of the usbkey through the client host, and sends the PIN code to the usbkey to verify whether the PIN code is correct, and the usbkey performs step 212 after verifying that the PIN code is correct.
Step 210, the usbkey judges whether the current time obtained by timing exceeds the preset time, if the current time obtained by timing does not exceed the preset time, 211 is executed; if the current time obtained by timing exceeds the preset time, executing the step 216;
step 211, the usbkey receives a command for acquiring a signature result, which is issued by the client host;
after the client host receives the status code 0x6666, the client host can repeatedly send a command for acquiring a signature result to the usbkey;
the APDU instruction sequence corresponding to the instruction for acquiring the signature result is as follows: 80E 300000000
And if the usbkey receives the instruction for acquiring the signature result sent by the client host, returning to execute 210.
In addition, after receiving the status code 0x6666, the client host may also send a command to cancel the signature to the usbkey, so that the usbkey needs to determine whether to receive a command to acquire a signature result or a command to cancel the signature, which is sent by the client host; if an instruction for acquiring a signature result sent by the client host is received, returning to execute 210; if an instruction for canceling the signature sent by the client host is received, the usbkey stops performing the digital signature operation;
the APDU command sequence corresponding to the above-mentioned signature canceling command is: 80E 500000000.
Step 212, the usbkey executes digital signature operation and sends a signature result to the client host;
the usbkey performs the RSA operation on the hash value of the received data to be signed by using the algorithm and the key set in step 206 (that is, specified by the client host in step 205), and the result of the RSA operation is the result of the digital signature;
the usbkey sends the result of the digital signature to the client host, and returns the status code 0x9000 with successful operation.
Step 213, the client host sends the result of the digital signature to the transaction server, the transaction server verifies whether the received signature result is correct, if so, step 214 is executed; otherwise, go to step 215;
and after receiving the signature result, the transaction server decrypts the received signature result by using the public key of the user and removes the complementary bit, then performs the same hash operation as that in the client host on the data to be signed generated in the step 202, and compares the data obtained by removing the complementary bit after decrypting the signature result with the hash value obtained by the hash operation in the transaction server, if the two are the same, then the signature result received by the transaction server is correct.
And step 214, executing subsequent transaction operation and ending the transaction flow.
Step 215, the transaction server returns the error information to the client host, stops the transaction operation, and ends the transaction process.
And the client host outputs the error information after receiving the error information returned by the transaction server.
And step 216. the usbkey sends a signal for canceling the transaction to the client host.
The usbkey returns a state code 0x7777 which is agreed in advance and represents canceling the transaction to the client host, and the client host sends the canceling transaction information to the transaction server to finish the transaction flow.
In embodiment 2 of the present invention, the process of performing hash operation on the data to be signed is completed in the client host, in addition, the usb key may perform hash operation and bit padding on the data to be signed, and the corresponding signing process and the invoked PKCS #11 interface are changed as follows:
accordingly, on the basis of the above steps 201 to 216, the following steps may be respectively replaced: steps 204 and 205 may be replaced with step 204 ', step 207 with step 207 ', and step 212 with step 212 '.
Step 204', the client host issues an MSE instruction to the usbkey, and a hash algorithm, a signature algorithm and a key used by signature are set;
the called PKCS #11 interface function is:
v/log in, get Key usage Authority
C_Login(hSession,CKU_USER,ucPin,lstrlen(ucPin));
V/set signature Algorithm and signature Key
CK_MECHANISM ckMechanismSign={CKM_SHA1_RSA_PKCS,NULL_PTR,0};
C_SignInit(hSession,&ckMechanismSign,hPriKey);
Commonly used signature algorithm identifiers include CKM _ SHA1_ RSA _ PKCS, CKM _ MD5_ RSA _ PKCS, CKM _ MD2_ RSA _ PKCS, and the like;
in embodiment 2 of the present invention, an upper application of a client host sets an algorithm identifier as CKM _ SHA1_ RSA _ PKCS, which indicates that a hash operation uses a SHA1 algorithm and a digital signature uses an RSA algorithm, and an APDU instruction issued by a middleware to an intelligent key device is substantially as follows:
the/MSE instruction, set hash algorithm and RSA Key ID
00 22 41 B6 80 01 32 83 02 00 23
Step 207', the client host issues data to be signed and a signature command to the usbkey;
the client host calls a C _ Sign function of a PKCS #11 interface, transmits data to be signed through the function and acquires a signature result, and the method specifically comprises the following steps:
v/signature, get signature result
C_Sign(hSession,pDigest,ulDigestLen,bSignatureBuffer,&ulSignatureLen);
The parameter "pDigest" represents data which needs to be digitally signed, namely data to be signed; "bSignatureBuffer" is the result of the digital signature.
The client host issues a signature command expressed in an APDU format to the usbkey, and the APDU command sequence issued by the client host is as follows: 002 a 9E 000000.
Step 212', the usbkey executes digital signature operation and sends a signature result to the client host;
before the usbkey performs the digital signature operation, the usbkey performs a hash operation on the received data to be signed by using the hash algorithm, the signature algorithm and the key set in step 206 (i.e. specified by the client host in step 204');
in embodiment 2 of the present invention, the algorithm identifier received by the usbkey is CKM _ SHA1_ RSA _ PKCS, which indicates that the hash operation uses the SHA1 algorithm and the digital signature uses the RSA algorithm;
then, adding an algorithm identification string defined by an X.509 specification in front of a hash value obtained by hash operation, and performing bit complementing according to a public key cryptography standard (PKCS # 1);
for example: the SHA1 algorithm identification string is 3020300 c 06082 a 864886 f 70 d 020505000410.
And finally, the usbkey performs RSA operation on the data after bit complementing to obtain a signature result, sends the signature result to the client, and returns a state code 0x9000 with successful operation.
In the above technical solution, the hash operation on the data to be signed is performed by the usbkey, but in a specific implementation process, the hash operation on the data to be signed by the usbkey can be adjusted according to needs, and the hash operation can be performed after the signing instruction is received, or after the usbkey receives the MSE instruction and sets the hash algorithm, the signing algorithm and the key.
In the prior art, the adopted scheme is a method for embedding a word stock in a usbkey, but in the implementation process of the method, a large storage space is required in the usbkey for storing the word stock so as to ensure that all transaction information can be correctly output, and meanwhile, the processing of characters in the usbkey has many problems and consumes a large amount of hardware resources;
in the invention, the transaction server side adopts the form of multimedia data such as pictures or sound to package the transaction information, and the usbkey only needs to output the transaction information in the form of pictures or sound according to a set format without performing other processing on the data; on the other hand, the method for packaging the transaction information by the client host is not adopted, because the transaction server in the actual application can be upgraded at any time due to the requirement of service expansion, the client host cannot be ensured to completely support new transaction processing after the transaction server is upgraded, and the difficulty of upgrading and maintaining is high, so that the method is not adopted.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like that fall within the spirit and principle of the present invention are intended to be included therein.

Claims (13)

1. A secure digital signature method, the method comprising:
the client host sends transaction information to a transaction server;
the transaction server generates data to be signed in an image and/or audio form according to the transaction information and sends the data to be signed to the client host;
the client host sends a signature instruction and the data to be signed to a usbkey with a screen and/or an audio playing device;
the usb key outputs the data to be signed through a screen and/or audio playing equipment of the usb key, and waits for a confirmation signal;
if the usb key receives the confirmation signal, performing digital signature operation on the data to be signed;
and returning the result of the digital signature to the transaction server through the client host, and executing transaction operation after the transaction server verifies that the result of the digital signature is correct, and ending.
2. A secure digital signature method as recited in claim 1 wherein the transaction information sent by said client host to said transaction server includes in particular a transaction account number, a transaction amount, and a transaction type.
3. A secure digital signature method as recited in claim 1 wherein said transaction server generates data to be signed in the form of images and/or audio from said transaction information, said method further comprising:
the language used in the data to be signed is the language specified in the transaction information; or
And the transaction server judges the region of the client host and uses the language of the region of the client host as the language used in the data to be signed.
4. A secure digital signature method as recited in claim 1 wherein said transaction server generates data to be signed in the form of images and/or audio from said transaction information, said method further comprising:
the transaction server generates the data to be signed in the form of the image and/or the audio according to the type of the data to be signed specified in the transaction information; or
And the transaction server generates the data to be signed in the form of the image and/or the audio according to the default data type to be signed which is determined in advance.
5. A secure digital signature method as recited in claim 1 wherein said transaction server generates data to be signed in the form of images and/or audio from said transaction information, said images including still pictures and moving video;
6. a secure digital signature method as recited in claim 5,
the format of the static picture comprises a bitmap format;
the format of the dynamic video and/or audio includes a streaming media format.
7. A secure digital signature method as recited in claim 1, wherein said usbkey outputs said data to be signed, said method further comprising:
the usb key judges the type of the data to be signed and selects a proper mode to output the data to be signed according to the judgment result; or
And the usbkey selects a corresponding mode to output the data to be signed according to the received description of the type of the data to be signed, which is issued by the client host.
8. A secure digital signature method as recited in claim 1, wherein after the usbkey receives the signature instruction, the method further comprises:
the usbkey starts timing after receiving the signature command;
if the usbkey does not receive the confirmation signal, judging whether the time obtained by timing exceeds preset time or not;
and if the time counted exceeds the preset time, canceling the execution of the received signature instruction.
9. The secure digital signature method as recited in claim 1, wherein after the usb key receives the signature instruction and before performing a digital signature operation on the data to be signed, the method further comprises:
and the usbkey performs identity authentication on the user.
10. The secure digital signature method as recited in claim 9, wherein the method for authenticating the user by the usbkey specifically comprises:
the usbkey receives a PIN code or biological characteristic information input by a user;
and if the usbkey verifies that the PIN code or the biological characteristic information is correct, the user identity is legal.
11. A secure digital signature method as claimed in claim 10, wherein said method of the usbkey receiving a PIN code or biometric information entered by a user comprises:
the usb key receives the PIN code or the biological characteristic information input by the user through a keyboard or a biological characteristic receiving device of the usb key;
or
And the client host receives the PIN code or the biological characteristic information input by the user and sends the PIN code or the biological characteristic information input by the user to the usbkey.
12. A secure digital signature method as recited in claim 1, wherein prior to the usbkey digitally signing the data to be signed, the method further comprises:
the usb key receives the data to be signed sent by the client host, performs hash operation on the data to be signed, adds an algorithm identification string to a hash value obtained by the hash operation, and performs bit supplementing on the hash value added with the algorithm identification string according to a public key cryptography standard; or
The usb key receives a hash value sent by a client host and subjected to hash operation on the data to be signed, adds an algorithm identification string to the hash value, and performs bit complement on the hash value added with the algorithm identification string according to a public key cryptography standard; or
The usbkey receives a hash value which is sent by the client host and used for carrying out hash operation on the data to be signed and adding the algorithm identification string, and the hash value added with the algorithm identification string is subjected to bit supplementing according to the public key cryptography standard; or
And the usbkey receives a hash value which is sent by the client host and obtained by carrying out hash operation, adding an algorithm identification string and carrying out bit complementing according to the public key cryptography standard on the data to be signed in sequence.
13. A secure digital signature method as recited in claim 1 wherein said returning the result of said digital signature to said transaction server through said client host, said method further comprising:
and if the transaction server verifies that the result of the digital signature is wrong, the transaction server returns error information to the client host and stops transaction operation.
CN2010101682067A 2010-05-04 2010-05-04 Secure digital signature method Expired - Fee Related CN101820346B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN2010101682067A CN101820346B (en) 2010-05-04 2010-05-04 Secure digital signature method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2010101682067A CN101820346B (en) 2010-05-04 2010-05-04 Secure digital signature method

Publications (2)

Publication Number Publication Date
CN101820346A CN101820346A (en) 2010-09-01
CN101820346B true CN101820346B (en) 2012-06-27

Family

ID=42655302

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2010101682067A Expired - Fee Related CN101820346B (en) 2010-05-04 2010-05-04 Secure digital signature method

Country Status (1)

Country Link
CN (1) CN101820346B (en)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102571335B (en) * 2010-12-08 2016-02-17 中国科学院信息工程研究所 Dual factors digital signature method and system and server and client side
CN102075547B (en) * 2011-02-18 2014-03-26 天地融科技股份有限公司 Dynamic password generating method and device and authentication method and system
CN102347942B (en) * 2011-07-01 2016-09-28 飞天诚信科技股份有限公司 A kind of information security method based on image acquisition and system
CN102324008A (en) * 2011-09-23 2012-01-18 郑州信大捷安信息技术股份有限公司 Web bank's FTP client FTP and method of application based on USB safety storing encrypted card
CN103166924B (en) * 2011-12-14 2017-11-03 中国银联股份有限公司 The security information interaction system and method for feature based Parameter analysis
CN102420829B (en) * 2011-12-15 2014-07-02 北京握奇数据系统有限公司 Service data signature method, device, system and digital certification terminal
CN102651058B (en) * 2012-03-30 2015-01-28 恒宝股份有限公司 Method for realizing follow attack prevention in device with data sign determining function
CN102761420B (en) * 2012-08-08 2014-10-29 飞天诚信科技股份有限公司 Security certification method
CN102938034B (en) * 2012-10-26 2015-03-04 飞天诚信科技股份有限公司 Working method for conversion device
CN103020506B (en) * 2012-11-22 2015-10-07 北京握奇数据系统有限公司 A kind of combination is taken pictures and the Key equipment of bar code identification technology and method
CN103747012B (en) * 2013-08-01 2017-12-19 戴林巧 Safe verification method, the apparatus and system of network trading
CN104954126B (en) * 2014-03-26 2020-01-10 腾讯科技(深圳)有限公司 Sensitive operation verification method, device and system
CN103944726B (en) * 2014-04-25 2018-05-29 天地融科技股份有限公司 Operation requests processing system
CN104092683B (en) * 2014-07-04 2017-05-10 飞天诚信科技股份有限公司 PIN code protecting method and system
CN104301113B (en) * 2014-10-17 2017-07-14 飞天诚信科技股份有限公司 One kind is based on the multiduty digital signature method of many certificates and system
CN104734855A (en) * 2015-02-12 2015-06-24 天地融科技股份有限公司 Communication methods and system of intelligent secret key device and intelligent secret key device
CN104992329B (en) * 2015-05-14 2018-05-11 飞天诚信科技股份有限公司 A kind of method for safely issuing transaction message
CN105184566B (en) * 2015-06-16 2018-07-17 飞天诚信科技股份有限公司 A kind of working method of intelligent cipher key equipment
CN106059773B (en) * 2016-05-27 2019-08-02 深圳市星龙基电子技术有限公司 Digital signature method and system
CN107104850A (en) * 2017-03-24 2017-08-29 钱德君 A kind of Quantum Chain method of testing
CN107945018A (en) * 2017-11-22 2018-04-20 上海大有信息技术有限公司 A kind of buying signals transmission system across broker
CN109583154A (en) * 2018-12-04 2019-04-05 北京华大智宝电子系统有限公司 A kind of system and method based on Web middleware access intelligent code key
CN110740043B (en) * 2019-10-21 2020-08-07 飞天诚信科技股份有限公司 Intelligent key device and verification method thereof
CN111222178B (en) * 2020-01-16 2022-08-02 亚信科技(成都)有限公司 Data signature method and device

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7568104B2 (en) * 2005-01-19 2009-07-28 International Business Machines Corporation Method and apparatus for adding signature information to electronic documents
CN101374049B (en) * 2008-10-24 2010-10-06 北京飞天诚信科技有限公司 Method and system for improving signature safety
CN101409622B (en) * 2008-11-26 2012-10-31 飞天诚信科技股份有限公司 Digital signing system and method

Also Published As

Publication number Publication date
CN101820346A (en) 2010-09-01

Similar Documents

Publication Publication Date Title
CN101820346B (en) Secure digital signature method
US12125013B2 (en) Systems and method for payment transaction processing with payment application driver
US9900148B1 (en) System and method for encryption
US20170300920A1 (en) Method Of And Apparatus For Authenticating Fingerprint, Smart Terminal And Computer Storage Medium
WO2015101310A1 (en) Service processing method, device and system
CN111431719A (en) Mobile terminal password protection module, mobile terminal and password protection method
JP2018504789A (en) Payment authentication system, method and apparatus
EP2690589A1 (en) Method and system for security information interaction based on internet
CN110740136B (en) Network security control method for open bank and open bank platform
CN110620763B (en) Mobile identity authentication method and system based on mobile terminal APP
US20180343247A1 (en) Method, user terminal and authentication service server for authentication
US11727403B2 (en) System and method for payment authentication
WO2015168878A1 (en) Payment method and device and payment factor processing method and device
TWM601411U (en) System for digital account application by using ATM to obtain authentication
TWI465128B (en) Method, system of server authentication, and a computer-readable medium
US12039527B2 (en) Service providing system, service providing device, service providing method, and service providing program
CN110601836B (en) Key acquisition method, device, server and medium
CN108768655A (en) Dynamic password formation method and system
US8910260B2 (en) System and method for real time secure image based key generation using partial polygons assembled into a master composite image
CN112995160B (en) Data decryption system and method, terminal, server and non-transient storage medium
WO2022073336A1 (en) Secure payment method and apparatus, electronic device, and storage medium
TW202207665A (en) Data processing system, method and a chip card for the method
WO2024138322A1 (en) Processor, information authentication system and information authentication method
CN115147101A (en) Secure payment method, apparatus, electronic device, medium, and program product
WO2024173605A1 (en) Authentication system and method for windows systems

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20120627