WO2016107319A1 - 加载安全密钥存储硬件的方法和浏览器客户端装置 - Google Patents

加载安全密钥存储硬件的方法和浏览器客户端装置 Download PDF

Info

Publication number
WO2016107319A1
WO2016107319A1 PCT/CN2015/094847 CN2015094847W WO2016107319A1 WO 2016107319 A1 WO2016107319 A1 WO 2016107319A1 CN 2015094847 W CN2015094847 W CN 2015094847W WO 2016107319 A1 WO2016107319 A1 WO 2016107319A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
certificate
key storage
storage hardware
security key
Prior art date
Application number
PCT/CN2015/094847
Other languages
English (en)
French (fr)
Inventor
杭程
石彦伟
贾正强
Original Assignee
北京奇虎科技有限公司
奇智软件（北京）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京奇虎科技有限公司, 奇智软件（北京）有限公司 filed Critical 北京奇虎科技有限公司
Publication of WO2016107319A1 publication Critical patent/WO2016107319A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method for loading a secure key storage hardware and a browser client device.
  • the browser refers to HTML that can display the web server or file system (Hyper Text Mark-up Language). , a standard universal markup language) file content, and a piece of software that allows users to interact with these files.
  • HTML Hyper Text Mark-up Language
  • the present invention has been made in order to provide a load security key storage hardware method and corresponding browser client device that overcomes the above problems or at least partially solves the above problems.
  • a method for loading a security key storage hardware comprising: automatically identifying and connecting a security key storage hardware inserted in an interface of a terminal where a browser client is located; and reading and displaying by a browser client
  • the security key stores a user certificate stored in the hardware for the user to select; when the browser client receives the user's selection information about the user certificate, the user is authenticated; after the identity verification is passed, the user loads The content of the user certificate corresponding to the selection information.
  • a browser client device comprising: a connection module, a security key storage hardware for automatically identifying and connecting an interface of a terminal where a browser client is located; and a reading module Reading and displaying the user certificate stored in the security key storage hardware for the user to select; the identity verification module, configured to authenticate the user when receiving the selection information of the user certificate by the user; And a module, configured to load the content of the user certificate corresponding to the selection information after the identity verification is passed.
  • a program comprising readable code that, when executed on a computing device, causes the computing device to perform a load security key in accordance with an embodiment of the present invention Storage hardware Methods.
  • a readable medium in which a program as described in an embodiment of the present invention is stored.
  • the method for loading the security key storage hardware can first authenticate the user when loading the user certificate stored in the security key storage hardware, and load the security if the identity verification succeeds and the user identity can be confirmed.
  • the content of the user certificate stored in the key storage hardware thereby solving the problem of information leakage in the process of loading the security key storage hardware, security risks of loading the security key storage hardware, and the like, and obtaining security key storage hardware
  • the stored user credentials are compromised, thereby increasing the security of loading secure key storage hardware.
  • FIG. 1 shows a flow chart of a method of loading secure key storage hardware in accordance with one embodiment of the present invention
  • FIG. 2 shows a flow chart of a method of loading secure key storage hardware in accordance with one embodiment of the present invention
  • FIG. 3 is a schematic diagram showing an agent mechanism of an encryption sub-process according to an embodiment of the present invention
  • FIG. 4 is a schematic diagram showing a handshake process of an encryption sub-process and a network server according to an embodiment of the present invention
  • FIG. 5 illustrates a schematic diagram of prompting a user to insert a USB Key in a browser client according to an embodiment of the present invention
  • FIG. 6 shows a schematic diagram of a pop-up window certificate selection dialog in a browser client, in accordance with one embodiment of the present invention
  • FIG. 7 is a schematic diagram showing a user prompting a user to enter a protection password in a browser client according to an embodiment of the present invention
  • FIG. 8A is a schematic diagram showing loading of general information in a user certificate in a browser client according to an embodiment of the present invention.
  • FIG. 8B is a schematic diagram showing loading detailed information in a user certificate in a browser client according to an embodiment of the present invention.
  • FIG. 9 is a block diagram showing the structure of a browser client device according to an embodiment of the present invention.
  • FIG. 10 is a block diagram showing the structure of a browser client device according to an embodiment of the present invention.
  • Figure 11 is a block diagram showing the structure of a reading module in accordance with one embodiment of the present invention.
  • FIG. 12 is a block diagram showing the structure of a reading module according to an embodiment of the present invention.
  • FIG. 13 is a block diagram showing the structure of an encryption sub-process according to an embodiment of the present invention.
  • FIG. 14 is a block diagram showing the structure of a main service process according to an embodiment of the present invention.
  • FIG. 15 shows a block diagram of a computing device for performing a method of loading secure key storage hardware in accordance with the present invention
  • Figure 16 illustrates a storage unit for maintaining or carrying program code that implements a method of loading secure key storage hardware in accordance with the present invention.
  • Embodiment 1 is a diagrammatic representation of Embodiment 1:
  • FIG. 1 is a flow chart showing the steps of a method for loading a security key storage hardware according to an embodiment of the present invention. Specifically, the method may include the following steps:
  • Step 102 Automatically identify and connect the security key storage hardware inserted in the interface of the terminal where the browser client is located.
  • the browser client When users use the browser client to log in to online payment platforms such as online banking or Alipay, in order to ensure the security of data transmission, users need to insert security key storage hardware. That is, when the user inputs the address of the above website in the address bar of the browser client to request access to the webpage corresponding to the website address, the browser client prompts the user to insert the security key storage hardware.
  • the website address received by the address bar of the browser client may be directly input by the user, or may be input by the user after clicking the search result by searching, which is not limited in this embodiment.
  • the security key storage hardware that is, the USB Key, stores a user certificate in the security key storage hardware, and the user can select the user certificate.
  • a security key storage hardware usually stores a user certificate, and each major bank has its own corresponding security key storage hardware.
  • the security key storage hardware of the online banking of Bank of Beijing stores the user certificate issued by Bank of Beijing; the security key storage hardware of the online bank of CCB stores the user certificate issued by the construction bank.
  • the security key storage hardware is usually set to match a USB (Universal Serial Bus) interface, and can be inserted into a terminal such as a computer through a USB interface.
  • the browser client in this embodiment can automatically identify the security key storage hardware inserted in the interface of the terminal where the browser client is located, and the security key can be stored.
  • the hardware is distinguished from other USB connection hardware. Automatically associated with the security key when it is recognized that the security key storage hardware is inserted into the terminal
  • the storage hardware establishes a connection, where the connection is established, the download driver establishes a communication connection with the security key storage hardware, and the user certificate stored in the security key storage hardware can be read, without being limited to a physical connection.
  • Step 104 The browser client reads and displays the user certificate stored in the security key storage hardware for the user to select.
  • the browser client After the browser client establishes a communication connection with the security key storage hardware, the user certificate stored in the security key storage hardware can be read and displayed, and the user certificate can be displayed for selection by the user.
  • the browser client may display the user certificate in the form of a pop-up window, and may display the user certificate in other manners. This embodiment does not limit the specific display manner, and can display the number of user certificates. , let the user visually see the user certificate to facilitate the user to select the user certificate.
  • Step 106 When the browser client receives the selection information of the user certificate by the user, the user is authenticated.
  • the reason why the browser client needs to automatically identify the security key storage hardware is because it needs to perform security verification when accessing the payment platform such as online banking.
  • the identity of the user needs to be verified, and after the user selects the user certificate, the user is authenticated. It should be noted that although the authentication is performed on the browser client, the bank's network server requires the user to be authenticated to confirm the identity of the user.
  • the identity verification of the user in this embodiment may be implemented in multiple manners.
  • the user can be authenticated by using a password for the user to input the bank card or a separate password for the online bank. Because the bank's web server stores the password of the bank set by the user or the individual password of the online bank, the browser client can send the identity information such as the bank card password input by the user to the web server, and the user identity stored in the web server. The information is matched. If the match is successful, the user's authentication passes; if the match is unsuccessful, the authentication fails.
  • the identity information input by the user may be the above-mentioned bank card password, or may be a protection password, or may be information such as the user's ID number, which can represent the identity of the user.
  • the specific content of the identity information is not limited, and there is no restriction on the specific process of performing identity verification, as long as the identity of the user can be confirmed.
  • Step 108 After the identity verification is passed, load the content of the user certificate corresponding to the selection information.
  • the browser client can confirm that the user is secure, and is not a malicious attacker such as a hacker. At this time, the specific content of the user certificate corresponding to the selection information is loaded.
  • the user certificate displayed in step 104 is only for the user to select, so the content displayed in step 104 may not be the specific content of the user certificate, but the name of the user certificate.
  • the browser client confirms the user security, and loads the specific content of the user certificate corresponding to the selection information.
  • the browser client of the embodiment loads the security key storage hardware, it first automatically identifies and connects the security key storage hardware inserted in the interface of the terminal where the browser client is located; then the browser client reads and Display Dedicating the user certificate stored in the security key storage hardware for the user to select; then, when the browser client receives the user's selection information about the user certificate, authenticating the user; finally, the identity verification is passed After that, the content of the user certificate corresponding to the selection information is loaded.
  • the user when loading the user certificate stored in the security key storage hardware, the user is authenticated first, and when the identity verification is passed, and the user identity can be confirmed, the user certificate stored in the security key storage hardware is loaded. The content can prevent the user certificate stored in the security key storage hardware from being leaked, and improve the security of the loaded security key storage hardware.
  • Embodiment 2 is a diagrammatic representation of Embodiment 1:
  • the embodiment continues to load the method of the security key storage hardware.
  • FIG. 2 is a flow chart showing the steps of a method for loading a security key storage hardware according to an embodiment of the present invention. Specifically, the method may include the following steps:
  • Step 202 Start an encryption sub-process that communicates with the main service process in the browser client, where the encryption sub-process is used as a connection proxy to implement conversion of the first encrypted channel to the second encrypted channel, and data forwarding.
  • HTTP Hyper Text Transfer Protocol
  • the network server uses different encryption protocols or algorithms, so that the two cannot communicate directly and cannot access the webpage of the web server.
  • a secure browser client which also sets an encryption sub-process that communicates with the browser main business process in the browser.
  • the main function of the encryption sub-process is to implement the conversion of the first encrypted channel to the second encrypted channel as a connection proxy, and data forwarding. That is, the encryption sub-process is used as the proxy of the main business process, which can perform encrypted communication with the main business process of the browser, and can also perform secure communication with the network server, such as the business data of the main business process of the browser.
  • An encrypted channel is sent to the encryption sub-process, and the encryption sub-process transmits the service data to the network server through the second encryption channel to implement data forwarding and communication between the two encrypted channels.
  • the main business process of the browser communicates directly with the network server. However, if the communication is performed on the HTTP channel targeted for security, the main business process cannot parse the data information fed back by the network server. And the encryption sub-process is started as a proxy connection, that is, the encryption sub-process acts as a proxy between the main service process and the network server.
  • the first encryption channel is a secure communication channel of the browser main service process and the encryption sub-process; and the second encryption channel is a secure communication channel of the encryption sub-process and the network server.
  • the encryption sub-process realizes the main service process and the network server by converting the encryption sub-process and the first encryption channel of the main service process into a second encryption channel of the encryption sub-process and the network server. Connection agent between.
  • the primary service process is sent through the first encrypted channel.
  • the encryption sub-process may send the service data to the network server through the second encryption channel.
  • the data communicated in the second encrypted channel may be encrypted by using the symmetric encryption algorithm SM4.
  • the browser main service process and the encryption sub-process adopt two kinds of communication modes: proxy and IPC (Inter-Process Communication), so that the encryption sub-process can be used as a connection proxy, and is responsible for the main business process of the browser.
  • An encrypted channel, channel conversion and data forwarding to the second encrypted channel of the network server, and the IPC communication mode is responsible for inter-process data transfer.
  • the encryption sub-process agent implementation mechanism is as shown in FIG. 3, and specifically includes the following structure:
  • Main thread Read various configurations, create a listening thread, main business thread, and IPC pass of the browser main process.
  • Listening thread used to listen to the service port. When there is a connection request in the main business process and accept (accept) successfully execute the corresponding proxy operation.
  • Service processing thread establishes and maintains the corresponding encrypted channel connection with the main business process and the network server respectively, so as to bridge the data exchange between the two ends.
  • the specific process of the service processing thread is as follows: (1) receiving the proxy data, and specifically receiving the http request data of the proxy connection. (2) SSL (Secure Sockets Layer) connection with the network server, including SSL connection establishment, SSL protocol negotiation, algorithm negotiation, client certificate verification (CRL check or OCSP authentication) (3) and web server Interaction. Specifically, the proxy connection http request data is sent to the web server via the national secret SSL channel, and the http response of the web server is obtained. (4) The sending network server returns data to the proxy connection. Specifically, the http response of the web server is transferred to the proxy connection. (5) Close the connection. If an error occurs in the business process flow, the connection is closed and an error page is returned to the agent connection. It should be noted that the second symmetric algorithm may specifically be a national secret algorithm.
  • SSL security technology is widely used to solve network application identity authentication and data confidentiality.
  • SSL modules are also built into mainstream browsers and web servers.
  • Professional SSL hardware products are also widely used.
  • current SSL products still have certain limitations:
  • the current publicly available symmetric algorithms are commonly used in SSL products, which do not meet the confidentiality requirements and have certain risks.
  • the cryptographic product symmetric algorithm uses the SM1 algorithm or the SM4 algorithm.
  • the current certificate asymmetric algorithm uses the RSA algorithm, and the elliptic curve cipher (ECC) used in this embodiment is a public key cipher with higher security and higher efficiency than RSA, with encryption/decryption and digital Important password functions such as signature and key negotiation, which can safely and conveniently meet user identification and electronic information in various information networks.
  • Important information security requirements such as authenticity identification and confidential transmission of information are core technologies in the field of information security, and have been adopted by many international and national standards organizations as public key cryptography standards (IEEE P1363, ANSI X9, ISO/IEC and The IETF, etc., will become one of the mainstream cryptographic technologies used by the information security industry.
  • the ECC (ECDSA+ECDH) algorithm was named SM2.
  • the method for loading the security key storage hardware conforms to the requirements of the PKI mechanism and the password product management policy, and plays a positive role in promoting the standardization of the management of the domestic security products and the rapid growth of the network application.
  • Step 204 The encryption sub-process performs mutual authentication of the digital certificate with the network server by using a handshake process.
  • the two-way authentication is to authenticate each other to the web server and the browser client of the visited website, and confirm that the digital certificate of the accessed web server and the digital certificate loaded by the browser client are safe and effective
  • Certificates that require authentication for two-way authentication include the site certificate of the visited website and the user certificate loaded by the browser client.
  • the step of performing the two-way authentication of the digital certificate with the network server by using the handshake process in the embodiment may be implemented by: the encryption sub-process performing the following steps with the network server through the handshake process
  • Security authentication operations Encrypted data negotiation, certificate authentication, key exchange, and signature authentication.
  • the above-mentioned two-way authentication process is also completed in the handshake process between the browser client and the web server to which the website belongs, and the handshake process can be implemented at least by the following methods:
  • the browser client sends a client hello message ClientHello to the web server, and the web server feeds back the server hello greeting message SeverHello to the browser client to negotiate encrypted data.
  • the network server sends the server certificate message SeverCertificate to the browser client. Because of the mutual authentication, the network server sequentially sends the server key exchange message SeverKeyExchange, the certificate authentication request message SeverRequest, and the server greeting to the browser client. End the message SeverHelloDone. among them.
  • the certificate authentication request message is used to indicate that the client performs certificate authentication.
  • the browser client authenticates the network certificate of the network server by using the asymmetric algorithm SM2.
  • the browser client sends a client certificate message ClientCertificate to the network server, and the client certificate message includes browsing.
  • the user certificate loaded by the client so that the network server authenticates the user certificate loaded by the browser client based on the asymmetric algorithm SM2.
  • the browser client may also send the client key exchange message ClientKeyExchange and the client greeting completion message ClientHelloDone to the network server, and other handshake messages required for key exchange and signature authentication, which are not in this embodiment. Discussion.
  • client hello message (ClientHello message) is the first message of the browser client and the network server handshake protocol, and the encryption sub-process sends the client greeting message to the network server. After that, wait for the web server to return a server greeting message.
  • Client problem message structure definition :
  • Clien_vision indicates the protocol version used by the client in this session.
  • the protocol version number is 1.1.
  • Radom is random information generated by the client, and its content includes always and random numbers.
  • session_id is the session identifier used by the client in the connection.
  • Session_id is a variable length field whose value is determined by the server. If there is no reusable session ID or if you want to negotiate security parameters, this field is blank, otherwise the client wants to reuse the session.
  • This session ID may be the previous connection ID, the current connection ID, or other connection ID in the connected state. After the session ID is generated, it should be consistently kept until the timeout is deleted or the connection associated with this session encounters a fatal error being closed. When a session fails or is closed, the connection associated with it should be forcibly closed.
  • cipher_suites is a list of cipher suites supported by the client.
  • the client should be arranged in the order of priority used by the cipher suite.
  • the cipher suite with the highest priority should be ranked first. If the session ID field is not empty, this field should contain at least the cipher suite used by the session to be reused.
  • Each cipher suite includes a key exchange algorithm, an encryption algorithm, and a check algorithm.
  • the server will select a matching cipher suite in the cipher suite list. If there is no matching cipher suite, the handshake failure alert message should be returned and the connection closed.
  • the compression_methods is a list of compression algorithms supported by the client.
  • the client should be arranged according to the priority order used by the compression algorithm, and the compression algorithm with the highest priority is ranked first.
  • the server will select a matching compression algorithm in the list of compression algorithms.
  • the list must contain a null compression algorithm so that the client and server can always negotiate a consistent compression algorithm.
  • the server can find a matching cipher suite from the client greeting message, the server sends the server hello message (Server Hello message) as a reply to the client greeting message. If no matching cipher suite is found, the server will respond with an alert message.
  • server hello message Server Hello message
  • an asymmetric algorithm is used for authentication in the authentication process of the digital certificate, that is, the sender encrypts the data by using the public key of the receiver, and the corresponding recipient uses the private key to decrypt the data.
  • the asymmetric algorithm of the certificate adopts the SM2 algorithm, uses the signature certificate to implement identity authentication based on the ECDSA signature, and uses the encryption certificate to implement key negotiation based on the ECDH.
  • the encryption sub-process and the network server perform bidirectional certificate authentication, which may be implemented in the following manner:
  • the encryption sub-process receives a server certificate message sent by the network server, where the server certificate message includes a site signing certificate of the network server;
  • the encryption sub-process receives a certificate authentication request message sent by the network server, where the certificate authentication request message is used to indicate that the certificate authentication of the client is performed;
  • the encryption sub-process receives a server-side key exchange message sent by the network server, including key exchange parameter;
  • the encryption sub-process receives a server greeting completion message sent by the network server
  • the encrypting sub-process After the site signing certificate is authenticated, the encrypting sub-process sends a client credential message to the web server, where the client credential message includes a signing certificate of the browser client, so that the web server The signature certificate is authenticated.
  • the foregoing encryption data negotiation, certificate authentication, key exchange, and signature authentication are all performed during the handshake process of the encryption sub-process and the network server of the secure browser client.
  • the two-factor authentication adopts a dual-certificate mechanism
  • the asymmetric algorithm of the certificate adopts the SM2 algorithm
  • the signature certificate is used to implement identity authentication based on the ECDSA signature
  • the encryption certificate is used to implement key negotiation based on the ECDH.
  • the SM4 algorithm used is used to encrypt the data, and the data is summarized using the SM3 algorithm.
  • the SM2 algorithm is an elliptic curve public key cryptographic algorithm with a key length of 256 bits.
  • the SM3 algorithm is a cryptographic hash algorithm with a key length of 128 bits.
  • the SM4 algorithm is a block cipher algorithm with a packet length of 128 bits and a key length of 128 bits.
  • the handshake process between the encryption subprocess and the network server includes:
  • the encryption subprocess sends a client hello message ClientHello to the web server.
  • the web server sends a server-side greeting message SeverHello to the encrypted sub-process of the secure browser client.
  • the network server finds a matching cipher suite from the ClientHello message, sends SeverHello as a reply, and sends an alarm message if no matching cipher suite is found.
  • SeverHello Sever_vision indicates the version number supported by the server, such as 1.1; the random number generated by the Radom server; the session identifier used by the session_id server; the cipher suite selected by the server from the ClientHello message; and the compression_methods server from the ClientHello message.
  • the compression algorithm selected in is a matching cipher suite from the ClientHello message.
  • the network server sends a server certificate message Certificate to the encryption subprocess.
  • this message of SeverCertificate is a signed certificate and an encrypted certificate.
  • the network server sends a certificate authentication request message SeverRequest to the encryption sub-process.
  • the client is required to provide a certificate through the SeverRequest message. Also indicates the type of certification (ECDSA)
  • the network server sends the server key exchange message SeverKeyExchange to the encryption subprocess.
  • SeverKeyExchange is used for client computing to generate a 48-byte pre-master key.
  • the public key can be obtained directly from the server-side encryption certificate. If the client randomly generates the pre-master key pre_master_seceret key and uses the service
  • the public key of the certificate is ECDH
  • the web server sends a greeting completion message SeverHelloDone to the encryption subprocess.
  • SeverHelloDone characterizes the completion of the hello message phase of the handshake process and then waits for the client's response message.
  • the encryption subprocess sends a client key exchange message Certificate to the web server.
  • the ClientCertificate message is the first message after the completion of the hello message phase, such as including the client's signature certificate (X.509 sequence).
  • the encryption subprocess sends the client key exchange message ClientKeyExchange to the network server.
  • the public key of the network server in the ClientKeyExchange message encrypts the pre-master key.
  • the encryption sub-process sends a certificate verification message CertificateVerify to the network server.
  • the CertificateVerify message is used to authenticate that the client is a legitimate holder of the certificate.
  • the user may be prompted to input a protection password, and the protection password is carried in the message to verify whether the user is legal.
  • the client uses the ECC private key of the signed certificate to perform ESDSA signature on the summary of the handshake information.
  • the encryption subprocess sends a client password specification change message ChangeCipherSpec to the network server.
  • the ClientChangeCipherSpec message indicates to the server that the algorithm and key negotiation are completed.
  • the encryption sub-process sends a client handshake end message Finished to the network server.
  • the encryption sub-process calculates the master_seceret according to the random number of the client, the random number of the server, the pre_master_seceret using the key algorithm, and then uses the random number and the master_seceret to calculate the real data encryption key, and then encrypts all the handshake messages and then encrypts them.
  • a ClientFinished message is formed and sent to the server.
  • the network server sends a server-side password specification change message ChangeCipherSpec to the encryption sub-process.
  • the web server sends the server handshake end message Finished to the encryption subprocess.
  • the server verifies the client certificate and verifies the client's signature using the client's signing certificate.
  • the service uses its own encrypted private key and performs ECDH operation to obtain pre_master_seceret. The same algorithm is used to calculate the master_seceret and the data encryption key, verify the correctness of the SeverFinished message, and send a SeverChangeCipherSpec message to the client to indicate the approval algorithm and key agreement. .
  • the authentication and key agreement processes of the browser client and the network server are completed, so that the encryption sub-process and the network server can respectively encrypt the application data by using the negotiated key.
  • Step 206 Automatically identify and connect the security key storage hardware inserted in the interface of the terminal where the browser client is located.
  • the two-way authentication is required for the visited website as an example.
  • the address bar of the browser client receives the website address input by the user that requires two-way authentication
  • the browser client pops up a dialog box prompting the user to insert the security key.
  • the storage hardware prompts the user to insert the USBKey, as shown in Figure 5.
  • Two-way authentication is to authenticate each other to the web server and browser client of the visited website, and confirm the digital certificate of the accessed web server.
  • the digital certificate loaded by the browser client is safe and effective, so the certificate that needs to be authenticated in the two-way authentication includes the website certificate of the visited website and the user certificate loaded by the browser client. Therefore, in the embodiment, the security key storage hardware that is automatically identified and connected to the interface of the terminal where the browser client is located may specifically include the following two sub-steps:
  • Sub-step 1 in the mutual authentication of the digital certificate, the encryption sub-process is associated with the corresponding driving position and the driving interface by the supplier identifier and the product number of the security key storage hardware.
  • the digital certificate specifically includes a site certificate of the visited website and a user certificate stored in the security key storage hardware loaded by the browser client.
  • the encryption sub-process of the browser can be associated to the corresponding drive location and drive interface by the vendor identification and product number of the secure key storage hardware.
  • Sub-step two establishing a connection channel with the security key storage hardware through the driving position and the driving interface. After learning the driving location and the driving interface of the security key storage hardware, a communication channel may be established with the security key storage hardware according to the driving location and the driving interface.
  • the method further includes: the encryptor The process determines whether to receive the certificate authentication request message sent by the network server during the handshake process; when receiving the certificate authentication request message sent by the network server, monitoring whether the interface of the terminal where the browser client is located has a security key storage hardware Insertion; when it is detected that there is a security key storage hardware insertion, the step 206 is performed to automatically identify and connect the security key storage hardware inserted in the interface of the terminal where the browser client is located.
  • Step 208 The browser client reads and displays the user certificate stored in the security key storage hardware for the user to select.
  • the browser client reads and displays the user certificate stored in the security key storage hardware for the user to select. Specifically, the following sub-steps are performed:
  • the encryption sub-process reads the user certificate stored in the security key storage hardware through the connection channel.
  • the encryption sub-process establishes a connection channel with the security key storage hardware according to the driving location and the driving interface, and the storage user certificate can be stored in the security key storage hardware through the connection channel. It should be noted that, at this time, the encryption sub-process reads only the information such as the name of the user certificate and does not include the specific content of the user certificate.
  • the encrypting sub-process reads the user certificate stored in the security key storage hardware through the connection channel, which may include: the encryption sub-process passes the The connection channel reads an application stored in the security key storage hardware, displays the application for selection by a user, wherein each application includes a container and a user certificate stored in the container; opening the user-selected application, loading the user The container under the selected application and the user certificate stored in the container.
  • a certificate selection dialog box is popped up, and the user certificate is loaded in the certificate selection dialog box to mention The user is selected to select the user certificate.
  • a pop-up window certificate selection dialog box is displayed in the browser client, and the certificate selection dialog box may specifically include any one or more of the following: current device, application name, and container.
  • the information such as the name, the certificate CN, the issuer, the effective date, the expiration time, and the name of the user certificate can prompt the user to select the user certificate.
  • This embodiment is not a limitation on the specific form or specific content of the certificate selection dialog box.
  • the CA (Certificate Authority) organization issues different site certificates for different websites, and simultaneously issues different user certificates for different users of different websites.
  • the digital certificate includes the public key of the site or the user, the information of the site or the user, and the digital signature.
  • a certificate selection box may be popped up in the browser client, and the user certificate currently owned by the browser where the browser is located is loaded in the certificate selection box, and the user is in the After selecting the user certificate, the user is prompted to input a protection password.
  • a personal identification number PIN
  • the above user certificate and protection password can be sent to the network server as authentication data in the user certificate authentication process.
  • the method further includes: the encryptor The process performs certificate site identification on the user certificate stored in the security key storage hardware, and classifies the user certificate in a certificate site unit; correspondingly, the sub-step 2 pops up a certificate selection dialog box, where The user certificate is loaded in the certificate selection dialog box to prompt the user to select the user certificate.
  • the method may include: popping up a certificate selection dialog box, and displaying the user certificate by using a certificate site as an index in the certificate selection dialog box.
  • the certificate site is the bank site corresponding to the certificate, and the certificate site may be: CCB, ICBC, and Agricultural Bank.
  • the certificate selection dialog box which bank the user certificate is, and intuitively displays which bank the security key storage hardware is, which is convenient for the user to determine whether it is necessary according to the bank.
  • User certificate that is, according to the certificate site, it is judged whether it is a required user certificate.
  • Step 210 When the browser client receives the selection information of the user certificate by the user, the user is authenticated.
  • the user when the browser client receives the user's selection information about the user certificate, the user is authenticated, which may be implemented by: receiving the user's selection information about the user certificate.
  • the encryption sub-process pops up a password input box and receives a protection password input by the user through the password input box.
  • the user is authenticated according to the protection password entered by the user.
  • the protection password is selected as the identity information of the user for identity verification. In specific implementation, other methods may also be used. Authentication, this embodiment is not a limitation on the specific manner of identity verification.
  • the browser client when the browser client receives the user's selection information about the user certificate, the user is authenticated, and the method further includes: if the identity verification fails And displaying a password error in the password input box and prompting the user to re-enter the protection password, and performing identity verification according to the re-entered protection password. Because the user misplaces the password during the input of the protection password, the user stores the error protection password. Therefore, this optional example does not directly disconnect the security key storage hardware when the authentication fails. Instead, the user is allowed to re-enter the protection password, which usually does not allow the user to enter the protection password an unlimited number of times, so the number of times the password can be protected can be limited.
  • the method further includes: the encryption sub-process setting Describe a maximum number of input times of the password input box.
  • the encryption sub-process setting Describe a maximum number of input times of the password input box.
  • Step 212 After the identity verification is passed, load the content of the user certificate corresponding to the selection information.
  • loading the content of the user certificate corresponding to the selection information may specifically include the following sub-steps:
  • Sub-step 1 after the identity verification is passed, the encryption sub-process obtains the authentication information in the user certificate, and loads the authentication information into the certificate viewer.
  • Sub-step 2 the encryption sub-process starts the certificate viewer according to the trigger indication, and displays the authentication information of the user certificate in the certificate viewer.
  • the authentication information of the user certificate is displayed in the certificate viewer, which may be implemented by: setting a general tab and a detailed tab in the certificate viewer; The tab displays the general information of the user certificate corresponding to the selection information; and displays the detailed information of the user certificate corresponding to the selection information in the detailed tab. That is, the certificate viewer is started according to the triggering instruction, and the general information of the user certificate is loaded in the general tab by the general tab and the detailed tab, respectively, as shown in FIG. 8A, in the certificate viewer. The detailed information of the user certificate is loaded in the detailed tab, as shown in FIG. 8B, the different contents of the user certificate can be viewed by selecting different tabs.
  • the method further includes: the encryption sub-process disconnection and the security key storage hardware Connection.
  • the certificate selection box may be popped up to prompt the user to insert the security key storage hardware, which is a USB Key, which is a
  • the security key storage hardware which is a USB Key
  • a USB interface hardware device built-in single-chip microcomputer or smart card chip, has a certain storage space, can store the user's private key and digital certificate, and utilizes the built-in public key algorithm of the USB Key to realize the authentication of the user identity. Since the user's private key is stored in the password lock, it can theoretically be read in any way, thus ensuring the security of user authentication.
  • the driver that invokes the security key storage hardware loads the certificate information in the security key storage hardware through the certificate selection box, and then receives the certificate information selected by the user;
  • the protection password input window is popped up in the certificate selection box, and the protection password input by the user is received.
  • SKFImagePath specifies the path of the SKF dynamic library.
  • TokenVidPid String format.
  • the VendorID and ProductID of the KEY device are in a format similar to the one in HKEY_LOCAL_MACHINE ⁇ SYSTEM ⁇ CurrentControlSet ⁇ Enum ⁇ USB, which is VID_XXXX&PID_XXXX.
  • the browser will associate the vendorid and the product number productid of the USBKey device to the corresponding driver to complete the related operations.
  • the browser does not store the pin password entered by the user, nor does it store the private key information in the USBKey.
  • the operation process of the USBKey is as follows: connect to the USBKey device; open the corresponding application Application, the Application is determined by the user; open the corresponding container Container, the Container is determined by the user, and then enter the verification PIN code, and the error will prompt to re-enter Then, the signature certificate information is obtained, the encryption certificate information is obtained, and the digital certificate is authenticated.
  • the process of adding and decrypting data is also completed in the USBKey, thereby accessing the website. When finished, shut down the device and disconnect.
  • receiving an allow connection message returned by the network server establishing a secure connection channel for encrypting data transmission between the browser and the web server corresponding to the website, where the permission connection message is
  • the network server sends the security certificate of the user certificate after it is passed.
  • the network server After the certificate authentication is passed, the network server returns an allow connection message. At this time, a secure connection channel for encrypting data transmission between the browser and the corresponding web server of the website is established. The data is transmitted in the secure connection channel. In this embodiment, the data is added and decrypted by using the symmetric algorithm SM4 algorithm.
  • the SM4 algorithm is a block cipher algorithm, and the packet length is 128 bits, and the key length is 128 bits.
  • Embodiment 3 is a diagrammatic representation of Embodiment 3
  • the embodiment further discloses a browser client device.
  • FIG. 9 is a structural block diagram of an embodiment of a browser client device according to an embodiment of the present invention. Specifically, the method may include: a connection module 902, a reading module 904, an identity verification module 906, and a loading module 908. ,
  • connection module 902 is configured to automatically identify and connect the security key storage hardware inserted in the interface of the terminal where the browser client is located;
  • a reading module 904 configured to read and display a user certificate stored in the security key storage hardware for selection by a user;
  • the authentication module 906 is configured to perform identity verification on the user when receiving the selection information of the user certificate by the user;
  • the loading module 908 is configured to load the user certificate content corresponding to the selection information after the identity verification is passed.
  • the connection module 902 first automatically identifies and connects to the security key storage hardware inserted in the interface of the terminal where the browser client is located;
  • the fetch module 904 reads and displays the user certificate stored in the security key storage hardware for the user to select; then the identity verification module 906, when the browser client receives the user's selection information for the user credential, The identity verification is performed; after the identity verification is passed, the last loading module 908 loads the content of the user certificate corresponding to the selection information.
  • the browser client provided in this embodiment loads the user certificate stored in the security key storage hardware, the user is authenticated by the identity verification module 906, and the loading module 908 can confirm the identity of the user after the identity verification is passed.
  • the content of the user certificate stored in the security key storage hardware is loaded, which prevents the user certificate stored in the security key storage hardware from being leaked, thereby improving the security of the browser client when loading the security key storage hardware.
  • the browser client device further includes: a main service process module 910 and an encryption sub-process module 912, where the main service process module 910 is used. Encrypting a sub-process that communicates with the main business process in the browser client, wherein the encryption sub-process is used as a connection proxy to implement conversion of the first encrypted channel to the second encrypted channel, and data forwarding;
  • the process module 912 is configured to perform mutual authentication of the digital certificate with the network server by using a handshake process.
  • the encryption sub-process module is configured to perform the following security authentication operations with the network server by using a handshake process: encrypted data negotiation, certificate authentication, key exchange, and signature authentication. .
  • connection module is configured to associate, by the supplier identifier and the product number of the security key storage hardware, when performing mutual authentication of the digital certificate. To a corresponding driving position and a driving interface; establishing a connection with the security key storage hardware through the driving position and the driving interface Connect the channel.
  • the reading module 904 includes: a reading submodule 9042, configured to read the security key storage hardware through the connection channel.
  • the user certificate is stored;
  • the loading sub-module 9044 is configured to pop up a certificate selection dialog box, and the user certificate is loaded in the certificate selection dialog box to prompt the user to select the user certificate.
  • the reading module 904 further includes: an identifying submodule 9046, configured to read the security key storage hardware through the connection channel. After the user certificate is stored, the user certificate stored in the security key storage hardware is identified by the certificate site, and the user certificate is classified in the certificate site.
  • the loading sub-module 9044 is specifically used for pop-up certificate selection. A dialog box is displayed in the certificate selection dialog box with the certificate site as an index.
  • the reading sub-module is specifically configured to read an application stored in the security key storage hardware through the connection channel, and display the application for a user to perform Selection, wherein each application includes a container and a user certificate stored in the container; opening the user-selected application, loading the container under the user-selected application, and the user certificate stored in the container.
  • the identity verification module is specifically configured to: when receiving the selection information of the user certificate by the user, popping up a password input box, and receiving the user through the password input box Enter the protected password; authenticate the user against the protected password entered by the user.
  • the identity verification module is further configured to: when the identity verification fails, display a password error in the password input box and prompt the user to re-enter the protection password, according to The re-entered protection password is authenticated.
  • the identity verification module is further configured to set a maximum number of input times to the password input box, when the number of times the user inputs the protection password in the password input box reaches the When the maximum number of inputs is entered, the personal password input box is closed and the connection to the secure key storage hardware is disconnected.
  • the loading module is configured to obtain the authentication information in the user book after the identity verification is passed, and load the authentication information into the certificate viewer.
  • the encryption sub-process module is configured to start the certificate viewer according to the trigger indication, and display the authentication information of the user certificate in the certificate viewer.
  • the encryption sub-process module is configured to separately set a general tab and a detailed tab in the certificate viewer; displaying the selection in the regular tab The general information of the user certificate corresponding to the information; displaying the detailed information of the user certificate corresponding to the selection information in the detailed tab.
  • the encryption sub-process module is further configured to determine, during a handshake process, whether to receive a certificate authentication request message sent by the network server, where the connection module is further used to The plus
  • the MME process monitors whether the interface of the terminal where the browser client is located has a security key storage hardware insertion; when it is detected that the security key storage hardware is inserted, it automatically recognizes A secure key storage hardware that is plugged into the interface of the terminal where the browser client is located.
  • the encryption sub-process module is further configured to: after the loading module loads the user certificate content corresponding to the selection information, disconnect the security key storage hardware connection.
  • the encryption sub-process can be understood by referring to the structural block diagram of the encryption sub-process shown in FIG. 13 .
  • the encryption sub-process includes: a configuration module 1302 , a proxy module 1304 , a CTL management module 1306 , and a CRL .
  • the proxy module accepts the connection of the main business process of the browser, and performs corresponding processing according to the type of the connection of the main business process of the browser to form a connection proxy of the main business process of the browser.
  • the CTL module is used to manage the list of trusted root certificates.
  • the CRL management module is used to obtain a CRL list and manage a local CRL list.
  • the Session management module manages the session connection between the agent process and the web server.
  • the SSL connection module is responsible for establishing a secure connection to the web server.
  • the USBKey management module is responsible for operating the USBKey device.
  • the configuration module is responsible for reading and storing the relevant configuration of the client.
  • the CTL management module 1306 the working principle is as follows:
  • the CTL describes a browser trusted root certificate list for verifying the server-side certificate.
  • the supported trusted root certificate is PEM encoding.
  • two kinds of certificate adding methods are supported: 1) adding a trusted root certificate internally; 2) adding a trusted root certificate to the configuration file, and saving the configuration file with des encryption.
  • the CTL can be configured to not support import and export.
  • the CRL describes the certificate revocation list of the certificate authority CA, which is essentially the certificate serial number, and the certificate serial number is represented by the Integer coded by ASN.1.
  • An extension in the X509v3 certificate (OID 2.5.29.31) is used to specify the CRL publishing point for the certificate.
  • the device locally caches the CRL, and the CRL search performs a primary index according to the CA.
  • the steps for verifying the CRL are as follows: (1) Obtain the Issuer entry in the certificate and locate the corresponding CA node. If the Issuer entry does not exist or the corresponding CA entry is not found, it is considered an illegal certificate. (2) Search for all CRL entries under the CA using the binary method.
  • the SSL connection needs to add 4 handshakes based on the TCP 3 handshake.
  • the connection establishment process is time consuming. Therefore, saving the session and multiplexing before multiplexing can effectively optimize the connection performance.
  • the memory index of the host+port to the session is established, and the subsequent session reuses the previous session, for example, the session validity period is 1 hour. When the browser is closed and the USBKey device is unplugged, the previous session will be cleared.
  • the encryption sub-process prompts the user to insert the security key storage hardware, that is, the USBKey device. After the user inserts the security key storage hardware The certificate selection dialog can be automatically identified and popped up, prompting the user to select a certificate.
  • the encryption sub-process automatically recognizes that the security key storage hardware needs to rely on two key information in the CSP registry key: SKFImagePath: specifies the path of the SKF dynamic library and the TokenVidPid: string format.
  • the VendorID and ProductID of the KEY device are in a format similar to the one in HKEY_LOCAL_MACHINE ⁇ SYSTEM ⁇ CurrentControlSet ⁇ Enum ⁇ USB, which is VID_XXXX&PID_XXXX.
  • the browser will associate the corresponding driver with the vendorid and productid of the USBKey device to complete the related operations.
  • the browser does not store the pin password entered by the user, nor does it store the private key information in the USBKey.
  • the specific process is as follows: first connect to the USBKey device; then open the corresponding application (Application), the Application is determined by the user; then open the corresponding container (Container), the Container is determined by the user; then verify the PIN code (personal identification number), After verifying the error, you will be prompted to re-enter; then get the signed certificate information; then get the encrypted certificate information; finally turn off the device and disconnect.
  • Application Application
  • Container Container
  • PIN code personal identification number
  • the certificate verification on the server side occurs in the handshake protocol process, and the browser sends the Certificate message after receiving the ServerHelloDone message.
  • Certificate verification mainly ensures the rationality of the server.
  • the verification process depends on the CTL and CRL modules. The specific process is performed in the sub-process certificate verification thread pool. The check steps are as follows: Initialize the list of trusted root certificates; check whether it is a self-signed certificate; check the certificate extension information; check the certificate trust relationship; check the CRL list; check the certificate signature; check the certificate time validity; check whether the certificate is in the blacklist.
  • the main service process can be understood by referring to the structural block diagram of the main service process shown in FIG. 14.
  • the main service process includes: a certificate display module 1402, a whitelist management module 1404, and a network server certificate.
  • the certificate display module 1402 is responsible for displaying the digital certificate.
  • the whitelist management module 1404 is responsible for managing a web server list supporting the encryption algorithm of the present embodiment.
  • the network server certificate storage module 1406 is for storing a certificate responsible for managing the network server.
  • the proxy setup module 14014 proxy sets the proxy responsible for setting up the encryption subprocess.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • modules in the devices of the embodiments can be adaptively changed and placed in one or more devices different from the embodiment.
  • the modules or units or components of the embodiments may be combined into one module or unit or component, and further they may be divided into a plurality of sub-modules or sub-units or sub-components.
  • any combination of the features disclosed in the specification, including the accompanying claims, the abstract and the drawings, and any methods so disclosed, or All processes or units of the device are combined.
  • Each feature disclosed in this specification (including the accompanying claims, the abstract and the drawings) may be replaced by alternative features that provide the same, equivalent or similar purpose.
  • the various component embodiments of the present invention may be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof.
  • a microprocessor or digital signal processor can be used in practice to implement methods for loading secure key storage hardware and some of browser client device devices in accordance with embodiments of the present invention. Or some or all of the features of all components.
  • the invention can also be implemented as a device or device program (e.g., a computer program and a computer program product) for performing some or all of the methods described herein.
  • a program implementing the invention may be stored on a computer readable medium or may be in the form of one or more signals. Such signals may be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.
  • Figure 15 illustrates a computing device that can implement a method of loading secure key storage hardware in accordance with the present invention.
  • the computing device conventionally includes a processor 1510 and a program product or readable medium in the form of a memory 1520.
  • the memory 1520 may be an electronic memory such as a flash memory, an EEPROM (Electrically Erasable Programmable Read Only Memory), an EPROM, or a ROM.
  • Memory 1520 has a storage space 1530 for program code 1531 for performing any of the method steps described above.
  • storage space 1530 for program code may be included for implementation, respectively.
  • Such a program product is typically a portable or fixed storage unit as described with reference to FIG.
  • the storage unit may have a storage segment, a storage space, and the like that are similarly arranged to the storage 1520 in the computing device of FIG.
  • the program code can be compressed, for example, in an appropriate form.
  • the storage unit includes readable code 1531', ie, code that can be read by a processor, such as, for example, 1510, which when executed by a computing device causes the computing device to perform various steps in the methods described above .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

一种加载安全密钥存储硬件的方法和浏览器客户端装置，所述的方法包括：自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件；浏览器客户端读取并显示所述安全密钥存储硬件中存储的用户证书以供用户进行选择；当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证；所述身份验证通过后，加载所述选择信息对应的用户证书内容。能够确认用户身份的情况下，加载安全密钥存储硬件中存储的用户证书的内容，可以防止安全密钥存储硬件中存储的用户证书被泄露，提高加载安全密钥存储硬件的安全性。

Description

加载安全密钥存储硬件的方法和浏览器客户端装置 技术领域
本发明涉及通信技术领域，特别是涉及一种加载安全密钥存储硬件的方法和一种浏览器客户端装置。
背景技术
随着网络技术的不断发展，越来越多的用户通过浏览器访问网页获取信息，并进行各种操作，其中，浏览器是指可以显示网页服务器或者文件***的HTML(Hyper Text Mark-up Language，标准通用标记语言)文件内容，并让用户与这些文件交互的一种软件。
如在购物网站中购物，在视频网站中观看视频，在银行网站中进行金融业务，在游戏网站中玩游戏等。对于不同网站的网页请求，浏览器会执行不同的访问操作，从而访问该网页。在访问一些网站，如银行网站、支付宝网站等涉及金融业务的网站时，需要加载安全密钥存储硬件，但是加载安全密钥存储硬件中存在安全密钥存储硬件中存储的信息泄露、无法保证加载安全密钥存储硬件的安全性的等问题，给访问涉及金融业务的网站造成阻碍。
发明内容
鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的加载安全密钥存储硬件方法和相应的浏览器客户端装置。
依据本发明的一个方面，提供了一种加载安全密钥存储硬件的方法，包括：自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件；浏览器客户端读取并显示所述安全密钥存储硬件中存储的用户证书以供用户进行选择；当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证；所述身份验证通过后，加载所述选择信息对应的用户证书内容。
根据本发明的另一方面，提供了一种浏览器客户端装置，包括：连接模块，用于自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件；读取模块，用于读取并显示所述安全密钥存储硬件中存储的用户证书以供用户进行选择；身份验证模块，用于当接收到用户对所述用户证书的选择信息时，对用户进行身份验证；加载模块，用于所述身份验证通过后，加载所述选择信息对应的用户证书内容。
根据本发明的另一方面，提供了一种程序，包括可读代码，当所述可读代码在计算设备上运行时，导致所述计算设备执行根据本发明实施例所述的加载安全密钥存储硬件 的方法。
根据本发明的另一方面，提供了一种可读介质，其中存储了如本发明实施例所述的程序。
根据本发明的加载安全密钥存储硬件的方法可以在加载安全密钥存储硬件中存储的用户证书时，先对用户进行了身份验证，在身份验证通过，能够确认用户身份的情况下，加载安全密钥存储硬件中存储的用户证书的内容，由此解决了加载安全密钥存储硬件过程中存在的信息泄露、加载安全密钥存储硬件存在安全隐患等问题，取得了防止安全密钥存储硬件中存储的用户证书被泄露，从而提高加载安全密钥存储硬件的安全性的有益效果。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1示出了根据本发明一个实施例的一种加载安全密钥存储硬件的方法的流程图；
图2示出了根据本发明一个实施例的一种加载安全密钥存储硬件的方法的流程图；
图3示出了根据本发明一个实施例的加密子进程的一种代理机制示意图；
图4示出了根据本发明一个实施例的加密子进程和网络服务器的握手过程示意图；
图5示出了根据本发明一个实施例的在浏览器客户端中提示用户***USBKey的示意图；
图6示出了根据本发明一个实施例的在浏览器客户端中弹窗证书选择对话框的示意图；
图7示出了根据本发明一个实施例的在浏览器客户端中提示用户输入保护口令的示意图；
图8A示出了根据本发明一个实施例的在浏览器客户端中加载用户证书中常规信息的示意图；
图8B示出了根据本发明一个实施例的在浏览器客户端中加载用户证书中详细信息的示意图；
图9示出了根据本发明一个实施例的一种浏览器客户端装置的结构框图；
图10示出了根据本发明一个实施例的一种浏览器客户端装置的结构框图；
图11示出了根据本发明一个实施例的读取模块的结构框图；
图12示出了根据本发明一个实施例的读取模块的结构框图；
图13示出了根据本发明一个实施例的加密子进程的结构框图；
图14示出了根据本发明一个实施例的主业务进程的结构框图；
图15示出了用于执行根据本发明的加载安全密钥存储硬件的方法的计算设备的框图；
图16示出了用于保持或者携带实现根据本发明的加载安全密钥存储硬件的方法的程序代码的存储单元。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
实施例一：
参照图1，示出了根据本发明一个实施例的一种加载安全密钥存储硬件的方法实施例的步骤流程图，具体可以包括如下步骤：
步骤102，自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件。
用户使用浏览器客户端登陆网上银行或支付宝等网上支付平台时，为了保证数据传输的安全性，需要用户***安全密钥存储硬件。即用户在浏览器客户端的地址栏中输入上述网站的地址以请求对该网站地址对应网页进行访问时，浏览器客户端会提示用户***安全密钥存储硬件。浏览器客户端的地址栏所接收的网站地址可能是用户直接输入的，也可以能是用户通过搜索点击搜索结果后输入的，本实施例对此不作限定。
安全密钥存储硬件，即USBKey，安全密钥存储硬件中存储有用户证书，用户可以选择所述用户证书。需要说明的是，一个安全密钥存储硬件中通常存储有一个用户证书，各大银行有自己对应的安全密钥存储硬件。例如，北京银行的网上银行的安全密钥存储硬件中存储有北京银行下发用户证书；建设银行的网上银行的安全密钥存储硬件中存储有建设银行下发的用户证书。
需要说明的是，安全密钥存储硬件通常设置为与USB(Universal Serial Bus，通用串行总线)接口匹配的形式，可以通过USB接口***到电脑等终端上。当所述安全密钥存储硬件通过USB接口***终端后，本实施例中浏览器客户端可以自动识别浏览器客户端所在终端的接口***的安全密钥存储硬件，可以将所述安全密钥存储硬件与其他USB连接硬件区分开来。当识别出是有安全密钥存储硬件***终端后，自动与所述安全密钥 存储硬件建立连接，这里所述建立连接，是下载驱动与所述安全密钥存储硬件建立通信连接，可以读取所述安全密钥存储硬件中存储的用户证书，而不限于物理上的连接。
步骤104，浏览器客户端读取并显示所述安全密钥存储硬件中存储的用户证书以供用户进行选择。
浏览器客户端与所述安全密钥存储硬件建立通信连接之后，可以读取所述安全密钥存储硬件中存储的用户证书，并将所述用户证书显示出来供用户进行选择。具体实现时，浏览器客户端可以通过弹窗的形式显示所述用户证书，也可以通过其他方式显示所述用户证书，本实施例对具体的显示方式不做限制，能够将用户证书显示数来，让用户直观看到用户证书以方便用户选择所述用户证书即可。
步骤106，当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证。
浏览器客户端之所以需要自动识别安全密钥存储硬件，是因为访问网上银行等支付平台时，需要进行安全验证。本实施例中具体需要对用户的身份进行验证，在用户选择用户证书之后，对用户进行身份验证。需要说明的是，身份验证虽然在浏览器客户端进行，其实是银行的网络服务器要求对用户进行身份验证，以确认用户的身份。
需要说明的是，本实施例中对用户进行身份验证可以采取多种方式来实现。对于登录网上银行的情景，可以采用让用户输入银行卡的密码，或网上银行的单独密码的方式，对用户进行身份验证。因为银行的网络服务器中存储有用户设置的银行的密码或是网上银行的单独密码，浏览器客户端可以将用户输入的银行卡密码等身份信息发送到网络服务器，与网络服务器中存储的用户身份信息进行匹配，如果能够成功匹配，则用户的身份验证通过；如果匹配不成功，则身份验证失败。需要说明的是，对用户进行身份验证时，用户输入的身份信息可以是上述银行卡密码，也可以是保护口令，还可以是用户的身份证号等能够代表用户身份的信息，本实施例对身份信息的具体内容不做限制，对进行身份验证的具体过程也不做限制，只要能够确认用户身份即可。
步骤108，所述身份验证通过后，加载所述选择信息对应的用户证书内容。
在身份验证通过后，浏览器客户端可以确认该用户是安全的，不是黑客等恶意攻击的用户，此时加载所述选择信息对应的用户证书的具体内容。步骤104中显示出来的用户证书仅仅为了供用户进行选择，因此步骤104中显示出来的可以不是用户证书的具体内容，而是用户证书的名称。在身份验证通过后，浏览器客户端确认用户安全的情况下，加载所述选择信息对应的用户证书的具体内容。
综上所述，本实施例浏览器客户端在加载安全密钥存储硬件时，首先自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件；然后浏览器客户端读取并显 示所述安全密钥存储硬件中存储的用户证书以供用户进行选择；接着当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证；最后所述身份验证通过后，加载所述选择信息对应的用户证书内容。本实施例在加载安全密钥存储硬件中存储的用户证书时，先对用户进行了身份验证，在身份验证通过，能够确认用户身份的情况下，加载安全密钥存储硬件中存储的用户证书的内容，可以防止安全密钥存储硬件中存储的用户证书被泄露，提高加载安全密钥存储硬件的安全性。
实施例二：
在上述实施例的基础上，本实施例继续加载安全密钥存储硬件的方法。
参照图2，示出了根据本发明一个实施例的一种加载安全密钥存储硬件的方法实施例的步骤流程图，具体可以包括如下步骤：
步骤202，在浏览器客户端中启动与主业务进程进行通信的加密子进程，其中，所述加密子进程用于作为连接代理实现第一加密通道到第二加密通道的转换，以及数据转发。
对于一些网站，如银行网站、支付宝网站等涉及金融业务的网站需要通过以安全为目标的HTTP(Hyper Text Transfer Protocol，超文本传送协议)通道进行加密数据的传输，但是有时浏览器主业务进程与网络服务器采用不同的加密协议或算法，导致两者无法直接通信，无法对该网络服务器的网页进行访问。
本实施例中，提供了一种安全浏览器客户端，其在浏览器中还设置了与浏览器主业务进程进行通信的加密子进程。为了使得安全浏览器能够实现，需要首先在浏览器客户端中启动与浏览器主业务进程进行通信的加密子进程。所述加密子进程的主要功能是作为连接代理实现第一加密通道到第二加密通道的转换，以及数据转发。即采用加密子进程作为主业务进程的代理，其既能与浏览器主业务进程进行加密的安全通行，也能够与网络服务器进行加密的安全通信，如对于浏览器主业务进程的业务数据通过第一加密通道发送给加密子进程，该加密子进程将业务数据通过第二加密通道传输给网络服务器，实现数据转发以及两个加密通道的连通。
需要说明的是，通常情况下，浏览器的主业务进程与网络服务器直接进行通信，但是，在以安全为目标的HTTP通道进行通信时，若主业务进程无法对网络服务器反馈的数据信息进行解析，启动所述加密子进程作为代理连接，即所述加密子进程作为所述主业务进程与所述网络服务器之间的代理。本实施例中上述第一加密通道为所述浏览器主业务进程和所述加密子进程的安全通信通道；所述第二加密通道为所述加密子进程和网络服务器的安全通信通道。因此所述加密子进程通过将加密子进程与所述主业务进程的第一加密通道，转换为加密子进程与网络服务器的第二加密通道，来实现所述主业务进程与所述网络服务器之间的连接代理。当然对于主业务进程通过所述第一加密通道发送 给加密子进程的业务数据，加密子进程可以将所述业务数据通过第二加密通道发送给网络服务器。具体地，可以将在第二加密通道中进行通信的数据采用对称加密算法SM4对业务数据进行加密。
本实施例中，浏览器主业务进程与加密子进程采用代理及IPC(Inter-Process Communication，进程间通信)两种通信方式，从而加密子进程可以作为连接代理，负责和浏览器主业务进程第一加密通道，到和网络服务器的第二加密通道的通道转换及数据转发，而IPC通信方式负责进程间数据传递。本实施例中，加密子进程代理实现机制如图3所示，具体可以包括如下结构：
主线程：读取各类配置，创建监听线程、主业务线程，以及浏览器主进程IPC通。
侦听线程：用于监听服务端口，当有主业务进程存在连接请求并接收(accept)成功执行相应的代理操作。
业务处理线程：与主业务进程和网络服务器两端分别建立相应加密通道连接并维持，从而作为桥梁进行两端的数据交换。
需要说明的是，业务处理线程的具体流程如下：(1)接收代理数据，具体接收代理连接的http request数据。(2)与网络服务器进行SSL(Secure Sockets Layer，安全套接层)连接，具体包括SSL连接的建立，SSL协议协商，算法协商，客户端证书验证(CRL检查或OCSP认证)(3)与web服务器交互。具体将代理连接http request数据经由国密SSL通道发给Web服务器，获取Web服务器的http response。(4)发送网络服务器返回数据给代理连接。具体将网络服务器的http response转给代理连接。(5)关闭连接。业务处理流程中如果发生错误，则关闭连接，同时给代理连接返回错误页面。需要说明的是，所述第二对称算法具体可以是国密算法。
需要说明的是，采用SSL的安全技术解决网络应用身份认证以及数据保密性得到广泛的认可，主流的浏览器和网络服务器中也内置了SSL模块，专业的SSL硬件产品也广泛使用。但当前SSL产品还都存在一定局限性：
(1)当前SSL产品普遍采用单证书机制。而双证书机制是当前PKI(Public Key Infrastructure，公钥基础设施)体系建设的主流模式。本实施例使用签名证书进行身份认证，使用加密证书进行密钥的交换和保护，发挥了PKI技术非对称密钥的优势。
(2)当前的SSL产品中普遍采用国外公开的对称算法，不符合保密要求，具有一定风险性。本实施例中密码产品对称算法采用SM1算法或SM4算法。
(3)当前的证书非对称算法采用RSA算法，而本实施例采用的椭圆曲线密码(ECC)是一种比RSA具有更高安全性、更高效率的公钥密码，具有加密/解密、数字签名和密钥协商等重要的密码功能，可以安全且方便地满足各种信息网络中的用户身份识别、电子 信息的真伪鉴别和保密传输等重要的信息安全需求，是信息安全领域的核心技术，并已逐渐被诸多国际和国家标准组织采纳为公钥密码标准(IEEE P1363、ANSI X9、ISO/IEC和IETF等)，将会成为信息安全产业界使用的主流密码技术之一。将该ECC(ECDSA+ECDH)算法命名为SM2。
本实施例提供的加载安全密钥存储硬件的方法，符合该PKI机制和密码产品管理政策的要求，对国内安全产品的管理的规范性和网络应用的快速增长都起到积极的推动作用。
步骤204，所述加密子进程通过握手过程与所述网络服务器进行数字证书双向认证。
本实施例中，双向认证是对所访问网站的网络服务器和浏览器客户端彼此均要进行认证，确认访问的网络服务器的数字证书以及浏览器客户端所加载的数字证书是安全有效的，因此双向认证时需要认证的证书包括访问的网站的站点证书以及浏览器客户端所加载的用户证书。本实施例中所述加密子进程通过握手过程与所述网络服务器进行数字证书的双向认证的步骤，具体可以通过以下方式来实现：所述加密子进程通过握手过程与所述网络服务器依次执行以下安全认证操作：加密数据协商、证书认证、密钥交换和签名认证。
需要说明的是，上述双向认证的过程同样是在浏览器客户端和网站所属网络服务器的握手过程中完成的，该握手过程至少可以通过以下方式来实现：
首先，浏览器客户端向所述网络服务器发送客户端问候消息ClientHello，所述网络服务器向所述浏览器客户端反馈服务端问候消息SeverHello，协商加密数据。
然后，网络服务器向所述浏览器客户端发送服务端证书消息SeverCertificate，由于要进行双向认证，网络服务器向浏览器客户端依次发送服务端密钥交换消息SeverKeyExchange、证书认证请求消息SeverRequest和服务端问候完结消息SeverHelloDone。其中。所述证书认证请求消息用于指示进行客户端的证书认证。
然后，浏览器客户端采用非对称算法SM2对所述网络服务器的站点证书进行认证，在认证通过后，浏览器客户端向所述网络服务器发送客户端证书消息ClientCertificate，该客户端证书消息包括浏览器客户端加载的用户证书，从而网络服务器基于非对称算法SM2对所述浏览器客户端加载的用户证书进行认证。
后续的握手过程中，浏览器客户端还可以向网络服务器发送客户密钥交换消息ClientKeyExchange和客户端问候完结消息ClientHelloDone，以及密钥交换和签名认证所需的其他握手消息，本实施例不一一论述。
需要说明的是，上述客户端问候消息(ClientHello消息)作为浏览器客户端和网络服务器握手协议的第一条消息，所述加密子进程向所述网络服务器发送客户端问候消息之 后，等待网络服务器返回服务器问候消息。客户端问题消息结构定义：
1、Clien_vision表示客户端在这个会话中使用的协议版本。如协议版本号是1.1。
2、Radom是客户端产生的随机信息，其内容包括始终和随机数。
3、session_id是客户端在连接中使用的会话标识。session_id是一个可变长字段，其值由服务器决定。如果没有可重用的会话标识或希望协商安全参数，该字段为空，否则表示客户端希望重用该会话。这个会话标识可能是之前的连接标识，当前连接标识，或其他处于连接状态的连接标识。会话标识生成后应一致保持到被超时删除或与这个会话相关的连接遇到致命错误被关闭。一个会话失效或被关闭时则与其相关的连接都应被强制关闭。
4、cipher_suites是客户端所支持的密码套件列表，客户端应按照密码套件使用的优先级顺序排列，优先级最高的密码套件应排在首位。如果会话标识字段不为空，本字段应至少包含将重用的会话所使用的密码套件。每个密码套件包括一个密钥交换算法，一个加密算法和一个校验算法。服务器将在密码套件列表中选择一个与之匹配的密码套件，如果没有可匹配的密码套件，应返回握手失败报警消息并且关闭连接。
5、compression_methods是客户端所支持的压缩算法列表，客户端应该按照压缩算法使用的优先级顺序排列，优先级最高的压缩算法排在首位。服务器将在压缩算法列表中选择一个与之匹配的压缩算法，列表中必须包含空压缩算法，这样客户端和服务器总能协商出一致的压缩算法。
需要说明的是，服务器如果能从客户端问候消息中找到匹配的密码套件，服务器发送所述服务端问候消息(Server Hello消息)作为对客户端问候消息的回复。如果找不到匹配的密码套件，服务器将回应报警消息。
本实施例中，数字证书的认证过程中采用非对称算法进行认证，即发送者采用接收者的公钥对数据进行加密，对应接收者采用自己的私钥对数据进行解密。其中，证书的非对称算法采用SM2算法，使用签名证书基于ECDSA签名实现身份认证，使用加密证书基于ECDH实现密钥协商。
在本发明实施例的一种可选示例中，所述加密子进程和所述网络服务器进行双向证书认证，具体可以通过以下方式来实现：
1)所述加密子进程接收所述网络服务器发送的服务端证书消息，所述服务端证书消息包括所述网络服务器的站点签名证书；
2)所述加密子进程接收所述网络服务器发送的证书认证请求消息，所述证书认证请求消息用于指示进行客户端的证书认证；
3)所述加密子进程接收所述网络服务器发送的服务端密钥交换消息，包括密钥交换 参数；
4)所述加密子进程接收所述网络服务器发送的服务端问候完结消息；
5)所述加密子进程对所述站点签名证书进行认证；
6)当所述站点签名证书认证通过后，所述加密子进程向所述网络服务器发送客户端证书消息，所述客户端证书消息包括所述浏览器客户端的签名证书，以使所述网络服务器对所述签名证书进行认证。
本实施例中，上述加密数据协商、证书认证、密钥交换以及签名认证都是在安全浏览器客户端的加密子进程和网络服务器的握手过程中执行的。本实施例中，双向认证采用了双证书机制，证书的非对称算法采用SM2算法，使用签名证书基于ECDSA签名实现身份认证，使用加密证书基于ECDH实现密钥协商。使用的SM4算法对数据进行加密，使用SM3算法对数据进行摘要。
其中，SM2算法(SM2 algorithm)是一种椭圆曲线公钥密码算法，其密钥长度为256比特。SM3算法(SM3 algorithm)是一种密码杂凑算法，其密钥长度为128比特，SM4算法(SM4 algorithm)是一种分组密码算法，分组长度为128比特，密钥长度为128比特。
如图4所示，加密子进程和网络服务器的握手过程包括：
4.02、加密子进程发送客户端问候消息ClientHello给网络服务器。
4.04、网络服务器发送服务端问候消息SeverHello给所述安全浏览器客户端的加密子进程。
其中，网络服务器从ClientHello消息中找到匹配的密码套件，发送SeverHello作为回复，若找不到匹配的密码套件，则发送报警消息。该SeverHello中，Sever_vision，表示服务器支持的版本号，如1.1；Radom服务器端产生的随机数；session_id服务端使用的会话标识；cipher_suites服务端从ClientHello消息中选取的密码套件；compression_methods服务端从ClientHello消息中选取的压缩算法。
4.06、网络服务器发送服务端证书消息Certificate给加密子进程。
即SeverCertificate本消息内容为签名证书和加密证书。如服务端的站点签名证书(X.509序列)
4.08、网络服务器发送证书认证请求消息SeverRequest给加密子进程。
通过SeverRequest消息要求客户端提供证书。同时指明了认证类型(ECDSA)
4.10、网络服务器发送服务端密钥交换消息SeverKeyExchange给加密子进程。
SeverKeyExchange用于客户端计算产生48字节的预主密钥。公钥可以直接从服务器端的加密证书中获取。如客户端随机产生预主密钥pre_master_seceret密钥，并使用服务 器证书的公钥进行ECDH运算
4.12、网络服务器发送问候完结消息SeverHelloDone给加密子进程。
SeverHelloDone表征握手过程的hello消息阶段完成，然后等待客户端的响应消息。
4.14、加密子进程发送客户密钥交换消息Certificate给网络服务器。
即ClientCertificate消息是hello消息阶段完成后的第一条消息，如包括客户的签名证书(X.509序列)。
4.16、加密子进程发送客户密钥交换消息ClientKeyExchange给网络服务器。
ClientKeyExchange消息中网络服务器的公钥加密预主密钥。
4.18、加密子进程发送证书校验消息CertificateVerify给网络服务器。
CertificateVerify消息用于鉴别客户端是够为证书的合法持有者。本实施例中，提示用户***USBKey后可以提示用户输入保护口令，该保护口令即携带在该消息中验证用户是否合法。
如，客户端使用签名证书的ECC私钥对握手信息的摘要进行ESDSA签名
4.20、加密子进程发送客户端密码规格变更消息ChangeCipherSpec给网络服务器。
即ClientChangeCipherSpec消息向服务端表明算法及密钥协商完成。
4.22、加密子进程发送客户端握手结束消息Finished给网络服务器。
本实施例中，加密子进程根据客户端的随机数、服务端的随机数、pre_master_seceret使用密钥算法计算master_seceret，然后再使用随机数和master_seceret计算真正的数据加密密钥，然后将所有握手消息摘要后加密形成ClientFinished消息向服务端发送。
4.24、网络服务器发送服务端密码规格变更消息ChangeCipherSpec给加密子进程。
4.26、网络服务器发送服务端握手结束消息Finished给加密子进程。
服务端验证客户端证书，使用客户端的签名证书验证客户端的签名。服务使用自身的加密私钥和进行ECDH运算，获得pre_master_seceret，采用客户端同样的算法计算master_seceret和数据加密密钥，验证SeverFinished消息的正确性，向客户端发送SeverChangeCipherSpec消息，表示认可算法及密钥协商。
通过上述握手过程完成了浏览器客户端和网络服务器双方的认证、密钥协商等过程，从而加密子进程和网络服务端可以分别使用协商计算出的密钥加密应用数据。
步骤206，自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件。
本实施例以所访问的网站需要进行双向认证为例进行说明，当浏览器客户端的地址栏接收到用户输入的需要双向认证的网站地址时，浏览器客户端弹出对话框提示用户***安全密钥存储硬件，即提示用户***USBKey，如图5所示。双向认证是对所访问网站的网络服务器和浏览器客户端彼此均要进行认证，确认访问的网络服务器的数字证书 以及浏览器客户端所加载的数字证书是安全有效的，因此双向认证时需要认证的证书包括访问的网站的站点证书以及浏览器客户端所加载的用户证书。因此，本实施例中所述自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件，具体可以包括以下两个子步骤：
子步骤一，在进行数字证书的双向认证时，所述加密子进程通过所述安全密钥存储硬件的供应方标识和产品编号关联到对应的驱动位置和驱动接口。需要说明的是，进行双向认证时所述数字证书具体包括访问的网站的站点证书以及浏览器客户端所加载的存储在安全密钥存储硬件中的用户证书。浏览器的加密子进程可以通过所述安全密钥存储硬件的供应方标识和产品编号关联到对应的驱动位置和驱动接口。
子步骤二，通过所述驱动位置和驱动接口与所述安全密钥存储硬件建立连接通道。获知所述安全密钥存储硬件的驱动位置和驱动接口之后，可以根据所述驱动位置和驱动接口与所述安全密钥存储硬件建立通信通道。
需要说明的是，在本发明实施例的一种可选示例中，所述步骤206自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件之前，还包括：所述加密子进程在握手过程中确定是否接收所述网络服务器发送的证书认证请求消息；当接收到所述网络服务器发送的证书认证请求消息时，监测浏览器客户端所在终端的接口是否有安全密钥存储硬件***；当监测到有安全密钥存储硬件***时，执行所述步骤206自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件。
步骤208，浏览器客户端读取并显示所述安全密钥存储硬件中存储的用户证书以供用户进行选择。
本实施例中所述浏览器客户端读取并显示所述安全密钥存储硬件中存储的用户证书以供用户进行选择，具体可以通过以下子步骤：
子步骤一，所述加密子进程通过所述连接通道读取所述安全密钥存储硬件中存储的用户证书。所述加密子进程根据所述驱动位置和驱动接口与所述安全密钥存储硬件建立了连接通道，可以通过所述连接通道读取安全密钥存储硬件中存储用户证书。需要说明的是，此时加密子进程读取到的只是用户证书的名称等不包含用户证书具体内容的信息。在本发明实施例的一种可选示例中，所述加密子进程通过所述连接通道读取所述安全密钥存储硬件中存储的用户证书，具体可以包括：所述加密子进程通过所述连接通道读取所述安全密钥存储硬件中存储的应用，显示所述应用以供用户进行选择，其中每个应用包括容器和容器中存储的用户证书；打开用户选择的应用，加载所述用户选择的应用下的容器和容器中存储的用户证书。
子步骤二，弹出证书选择对话框，在所述证书选择对话框中加载所述用户证书以提 示用户选择所述用户证书。需要说明的是，如图6所示，本实施例在浏览器客户端中弹窗证书选择对话框，证书选择对话框中具体可以包括以下任意一种或几种：当前设备、应用名称、容器名称、证书CN、颁发者、生效日期、失效时间、用户证书的名称等信息，能够提示用户选择所述用户证书即可，本实施例并非对证书选择对话框具体形式或具体内容的限制。
本实施例中，为了保证访问网站和用户的安全，CA(Certificate Authority，认证中心)机构为不同的网站颁布不同的站点证书，同时为不同网站的不同用户颁布不同的用户证书。其中，数字证书中包括站点或用户的公钥，站点或用户的信息，以及数字签名等内容。
因此，在进行数字证书认证之前，优选的，在双向认证过程中，可以在浏览器客户端中弹出证书选择框，在该证书选择框中加载浏览器所在终端当前所具有的用户证书，用户在对用户证书进行选择后，提示用户输入保护口令，如图7所示，输入个人识别码(Personal Identification Number，PIN)，从而在保护口令通过验证后说明该用户对该用户证书具有权项。并且，上述用户证书和保护口令可以作为用户证书认证过程中的认证数据发送给网络服务器。
在本发明实施例的一种可选示例中，所述子步骤一中加密子进程通过所述连接通道读取所述安全密钥存储硬件中存储的用户证书之后，还包括：所述加密子进程对所述安全密钥存储硬件中存储的用户证书进行证书站点识别，以证书站点为单位对所述用户证书进行分类；相应地，所述子步骤二中弹出证书选择对话框，在所述证书选择对话框中加载所述用户证书以提示用户选择所述用户证书，具体可以包括：弹出证书选择对话框，在所述证书选择对话框中以证书站点为索引显示所述用户证书。需要说明的是，证书站点即该证书对应的银行站点，证书站点具体可以是：建行、工行、农行等。换句话说，在本实施例中，具体可以在证书选择对话框中显示用户证书具体是哪个银行的，直观地显示所述安全密钥存储硬件是哪个银行的，方便用户根据银行判断是否是需要的用户证书，即根据所述证书站点判断是否是需要的用户证书。
步骤210，当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证。
本实施例中所述当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证，具体可以通过以下方式来实现：当接收到用户对所述用户证书的选择信息时，所述加密子进程弹出口令输入框，并通过所述口令输入框接收用户输入的保护口令。依据所述用户输入的保护口令对用户进行身份验证。需要说明的是，本实施例中选用保护口令作为用户的身份信息进行身份验证，具体实现时，也可以采用其他方式进行 身份验证，本实施例并非对身份验证具体方式的限定。
在本发明实施例的一种可选示例中，所述当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证，具体还包括：若所述身份验证未通过，则在所述口令输入框中显示口令错误并提示用户重新输入保护口令，依据所述重新输入的保护口令进行身份验证。由于用户在输入保护口令时键盘误操作等原因，用户存储输错保护口令的情况时有发生，因此本可选示例在身份验证未通过时，不是直接断开与安全密钥存储硬件的连接，而是允许用户重新输入保护口令，通常不允许用户无限次的输入保护口令，因此可以对输入保护口令的次数进行限制。即在本发明实施例的一种可选示例中，所述当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证，还包括：所述加密子进程设置所述口令输入框的最大输入次数，当所述口令输入框中用户输入的保护口令的次数达到所述最大输入次数时，关闭所述个人密码输入框，并断开与所述安全密钥存储硬件的连接。这样既可以避免用户一次输错保护口令就断开与所述安全密钥存储硬件的连接，所造成的用户需要重新***所述安全密钥存储硬件进行用户验证的操作繁琐且加载安全密钥存储硬件效率不高的问题，也避免了无限次输入密保口令造成的资源占用或死循环问题，提高了加载安全密钥存储硬件的效率。
步骤212，所述身份验证通过后，加载所述选择信息对应的用户证书内容。
本实施例中所述身份验证通过后，加载所述选择信息对应的用户证书内容，具体可以包括以下子步骤：
子步骤一，所述身份验证通过后，所述加密子进程获取所述用户证书中的认证信息，并将所述认证信息加载到证书查看器中。
子步骤二，所述加密子进程依据触发指示启动所述证书查看器，在所述证书查看器中显示所述用户证书的认证信息。需要说明的是，在所述证书查看器中显示所述用户证书的认证信息，具体可以通过以下方式来实现：在所述证书查看器中分别设置常规选项卡和详细选项卡；在所述常规选项卡中显示所述选择信息对应的用户证书的常规信息；在所述详细选项卡中显示所述选择信息对应的用户证书的详细信息。即根据触发指示启动所述证书查看器，该证书查看器中分别设置由常规选项卡和详细选项卡，在常规选项卡中加载所述用户证书的常规信息，如图8A所示，在所述详细选项卡中加载所述用户证书的详细信息，如图8B所示，通过对不同选项卡的选择可以查看用户证书的不同内容。
需要说明的是，在本发明实施例的一种可选示例中，所述加载所述选择信息对应的用户证书内容之后，还包括：所述加密子进程断开与所述安全密钥存储硬件的连接。
在本发明实施例的一种可选示例中，浏览器客户端加载用户证书时，首先可以弹出证书选择框提示用户***安全密钥存储硬件，该安全密钥存储硬件即USB Key，它是一 种USB接口的硬件设备，内置单片机或智能卡芯片，有一定的存储空间，可以存储用户的私钥以及数字证书，利用USB Key内置的公钥算法实现对用户身份的认证。由于用户私钥保存在密码锁中，理论上使用任何方式都无法读取，因此保证了用户认证的安全性。
在用户***安全密钥存储硬件后，调用所述安全密钥存储硬件的驱动程序在所述通过所述证书选择框中加载安全密钥存储硬件中的证书信息，然后接收用户选择的证书信息；在所述证书选择框中弹出保护口令输入窗口，再接收用户输入的保护口令。
其中，浏览器自动识别USBKey需要依赖CSP(Cryptographic Service Provider，加密服务提供)注册表项中的两个关键信息：SKFImagePath：指定SKF动态库的路径。TokenVidPid：字符串格式。KEY设备的VendorID和ProductID，采用的格式类似HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB中的格式，也即VID_XXXX&PID_XXXX。
浏览器会通过USBKey设备的供应方标识vendorid、产品编号productid关联到相应驱动，完成相关操作。浏览器不会存储用户输入的pin密码，也不会存储USBKey中的私钥信息。对USBKey的操作流程如下：连接到USBKey设备；打开相应的应用Application，Application由用户选择决定；打开相应的容器Container，Container由用户选择决定，然后输入校验PIN码，验证错误后会提示重新输入，然后获取签名证书信息，获取加密证书信息，进行数字证书的认证，后续在与网络服务器进行数据交互的过程中，对数据的加、解密过程也是在USBKey中完成的，从而在对该网站访问完成后关闭设备并断开连接。
本发明一个可选实施例中，接收所述网络服务器返回的允许连接消息，建立所述浏览器和所述网站对应网络服务器之间进行加密数据传输的安全连接通道，所述允许连接消息是由所述网络服务器对所述用户证书的安全认证通过后发送的。
上述证书认证通过后，网络服务器返回允许连接消息，此时建立所述浏览器和所述网站对应网络服务器之间进行加密数据传输的安全连接通道。在该安全连接通道中传输数据，本实施例中，采用对称算法SM4算法对数据进行加、解密，其中SM4算法即SM4 algorithm，是一种分组密码算法，分组长度为128比特，密钥长度为128比特。
对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。
实施例三：
在上述实施例的基础上，本实施例还公开了一种浏览器客户端装置。
参照图9，示出了根据本发明一个实施例的一种浏览器客户端装置实施例的结构框图，具体可以包括：连接模块902、读取模块904、身份验证模块906和加载模块908，其中，
连接模块902，用于自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件；
读取模块904，用于读取并显示所述安全密钥存储硬件中存储的用户证书以供用户进行选择；
身份验证模块906，用于当接收到用户对所述用户证书的选择信息时，对用户进行身份验证；
加载模块908，用于所述身份验证通过后，加载所述选择信息对应的用户证书内容。
综上所述，本实施例提供的浏览器客户端在加载安全密钥存储硬件时，首先通过连接模块902自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件；然后读取模块904读取并显示所述安全密钥存储硬件中存储的用户证书以供用户进行选择；接着身份验证模块906当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证；最后加载模块908在所述身份验证通过后，加载所述选择信息对应的用户证书内容。本实施例提供的浏览器客户端在加载安全密钥存储硬件中存储的用户证书时，先通过身份验证模块906对用户进行了身份验证，加载模块908在身份验证通过，能够确认用户身份的情况下，加载安全密钥存储硬件中存储的用户证书的内容，可以防止安全密钥存储硬件中存储的用户证书被泄露，提高了浏览器客户端加载安全密钥存储硬件时的安全性。
在本发明实施例的如图10所示的一种可选示例中，所说浏览器客户端装置还包括：主业务进程模块910和加密子进程模块912，其中，主业务进程模块910，用于在浏览器客户端中启动与主业务进程进行通信的加密子进程，其中，所述加密子进程用于作为连接代理实现第一加密通道到第二加密通道的转换，以及数据转发；加密子进程模块912，用于通过握手过程与所述网络服务器进行数字证书双向认证。
在本发明实施例的一种可选示例中，所述加密子进程模块，用于通过握手过程与所述网络服务器依次执行以下安全认证操作：加密数据协商、证书认证、密钥交换和签名认证。
在本发明实施例的一种可选示例中，所述连接模块，用于在进行数字证书的双向认证时，所述加密子进程通过所述安全密钥存储硬件的供应方标识和产品编号关联到对应的驱动位置和驱动接口；通过所述驱动位置和驱动接口与所述安全密钥存储硬件建立连 接通道。
在本发明实施例的如图11所示的一种可选示例中，所述读取模块904包括：读取子模块9042，用于通过所述连接通道读取所述安全密钥存储硬件中存储用户证书；加载子模块9044，用于弹出证书选择对话框，在所述证书选择对话框中加载所述用户证书以提示用户选择所述用户证书。
在本发明实施例的如图12所示的一种可选示例中，所述读取模块904还包括：识别子模块9046，用于通过所述连接通道读取所述安全密钥存储硬件中存储的用户证书之后，对所述安全密钥存储硬件中存储的用户证书进行证书站点识别，以证书站点为单位对所述用户证书进行分类；所述加载子模块9044，具体用于弹出证书选择对话框，在所述证书选择对话框中以证书站点为索引显示所述用户证书。
在本发明实施例的一种可选示例中，所述读取子模块，具体用于通过所述连接通道读取所述安全密钥存储硬件中存储的应用，显示所述应用以供用户进行选择，其中每个应用包括容器和容器中存储的用户证书；打开用户选择的应用，加载所述用户选择的应用下的容器和容器中存储的用户证书。
在本发明实施例的一种可选示例中，所述身份验证模块，具体用于当接收到用户对所述用户证书的选择信息时，弹出口令输入框，并通过所述口令输入框接收用户输入的保护口令；依据所述用户输入的保护口令对用户进行身份验证。
在本发明实施例的一种可选示例中，所述身份验证模块，还用于在所述身份验证未通过时，在所述口令输入框中显示口令错误并提示用户重新输入保护口令，依据所述重新输入的保护口令进行身份验证。
在本发明实施例的一种可选示例中，所述身份验证模块，还用于对所述口令输入框设置最大输入次数，当所述口令输入框中用户输入的保护口令的次数达到所述最大输入次数时，关闭所述个人密码输入框，并断开与所述安全密钥存储硬件的连接。
在本发明实施例的一种可选示例中，所述加载模块，具体用于所述身份验证通过后，获取所述用户证书中的认证信息，并将所述认证信息加载到证书查看器中；所述加密子进程模块，用于依据触发指示启动所述证书查看器，在所述证书查看器中显示所述用户证书的认证信息。
在本发明实施例的一种可选示例中，所述加密子进程模块，用于在所述证书查看器中分别设置常规选项卡和详细选项卡；在所述常规选项卡中显示所述选择信息对应的用户证书的常规信息；在所述详细选项卡中显示所述选择信息对应的用户证书的详细信息。
在本发明实施例的一种可选示例中，所述加密子进程模块，还用于在握手过程中确定是否接收所述网络服务器发送的证书认证请求消息；所述连接模块，还用于当所述加 密子进程接收到所述网络服务器发送的证书认证请求消息时，监测浏览器客户端所在终端的接口是否有安全密钥存储硬件***；当监测到有安全密钥存储硬件***时，自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件。
在本发明实施例的一种可选示例中，所述加密子进程模块，还用于所述加载模块加载所述选择信息对应的用户证书内容之后，断开与所述安全密钥存储硬件的连接。
需要说明的是，可以参照图13所示的加密子进程的结构框图对加密子进程进行理解，如图13所示，加密子进程包括：配置模块1302、代理模块1304、CTL管理模块1306、CRL管理模块1308、Session管理模块1310、证书验证模块1312、SSL连接模块1314、USBKey操作模块1316。其中，代理模块接受浏览器主业务进程连接，根据浏览器主业务进程连接的类型进行相应处理，形成浏览器主业务进程的连接代理。CTL模块用于管理信任根证书列表。CRL管理模块用于获取CRL列表，管理本地CRL列表。Session管理模块管理代理进程与web服务器的session连接。SSL连接模块负责建立与web服务器的安全连接。USBKey管理模块负责操作USBKey设备。配置模块负责读取、存储客户端的相关配置。
其中，对于CTL管理模块1306，其工作原理如下：CTL描述的是浏览器信任根证书列表，用于验证服务器端证书。360安全浏览器中，支持的信任根证书为PEM编码方式，同时支持两种证书添加方式：1)程序内部添加信任根证书；2)配置文件添加信任根证书，配置文件采用des加密保存。其中，CTL可以配置为不支持导入导出功能。
对于CRL管理模块1308，其工作原理如下：CRL描述的是证书颁发机构CA的证书撤销列表，其本质是证书序列号，证书序列号以ASN.1编码的Integer表示。X509v3证书中的一个扩展项(OID为2.5.29.31)用于指定该证书的CRL发布点。本实施例的安全浏览器中装置对CRL进行了本地缓存，同时CRL查找根据CA进行一级索引。对CRL的验证操作的步骤如下：(1)获取证书中的Issuer项，定位对应的CA节点，如果Issuer项不存在或者找不到对应的CA项，则认为是非法证书。(2)使用二分法搜索该CA下所有的CRL项。
对于Session管理模块1310，SSL连接需要在TCP 3次握手的基础上增加4次握手，连接建立过程是比较耗时的，因此保存Session、复用之前的连接可以有效优化连接性能。本实施例的安全浏览器装置中在一次SSL连接建立完成之后，会建立host+port到session的内存索引，后续操作会复用之前的session，如session有效期为1小时。浏览器关闭、USBKey设备拔出时会清空之前的session。
对于证书验证模块1312，SSL连接建立过程中如果需要双向认证，所述加密子进程会提示用户***安全密钥存储硬件，即USBKey设备。在用户***安全密钥存储硬件后 能够自动识别并弹出证书选择对话框，提示用户选择证书。所述加密子进程自动识别安全密钥存储硬件需要依赖CSP注册表项中的两个关键信息：SKFImagePath：指定SKF动态库的路径和TokenVidPid：字符串格式。KEY设备的VendorID和ProductID，采用的格式类似HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB中的格式，也即VID_XXXX&PID_XXXX。浏览器会通过USBKey设备的vendorid、productid关联到相应驱动，完成相关操作。浏览器不会存储用户输入的pin密码，也不会存储USBKey中的私钥信息。具体流程如下：首先连接到USBKey设备；然后打开相应应用(Application)，Application由用户选择决定；然后打开相应容器(Container)，Container由用户选择决定；接着校验PIN码(个人身份识别码)，验证错误后会提示重新输入；然后获取签名证书信息；接着获取加密证书信息；最后关闭设备、断开连接。
本实施例中，针对上述方法实施例的证书验证过程，对服务器端的证书验证发生在握手协议过程中，浏览器收到ServerHelloDone消息之后，发送Certificate消息之前。证书验证主要确保服务器的合理性，验证过程依赖于CTL，CRL模块，具体过程在子进程证书验证线程池中进行。检查步骤如下：初始化受信任根证书列表；检查是否是自签名证书；检查证书扩展信息；检查证书信任关系；检查CRL列表；检查证书签名；检查证书时间有效性；检查证书是否在黑名单中。
需要说明的是，可以参照图14所示的主业务进程的结构框图对主业务进程进行理解，如图14所示，主业务进程包括：证书显示模块1402、白名单管理模块1404、网络服务器证书存储模块1406、代理设置模块14014。其中证书显示模块1402负责显示数字证书。白名单管理模块1404负责管理支持本实施例的加密算法的web服务器列表。网络服务器证书存储模块1406用于存储负责管理网络服务器的证书。代理设置模块14014代理设置负责设置与加密子进程的代理。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
在此提供的算法和显示不与任何特定计算机、虚拟***或者其它设备固有相关。各种通用***也可以与基于在此的示教一起使用。根据上面的描述，构造这类***所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的加载安全密钥存储硬件的方法和浏览器客户端装置设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
例如，图15示出了可以实现根据本发明的加载安全密钥存储硬件的方法的计算设备。该计算设备传统上包括处理器1510和以存储器1520形式的程序产品或者可读介质。存储器1520可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM或者ROM之类的电子存储器。存储器1520具有用于执行上述方法中的任何方法步骤的程序代码1531的存储空间1530。例如，用于程序代码的存储空间1530可以包括分别用于实现上 面的方法中的各种步骤的各个程序代码1531。这些程序代码可以从一个或者多个程序产品中读出或者写入到这一个或者多个程序产品中。这些程序产品包括诸如存储卡之类的程序代码载体。这样的程序产品通常为如参考图16所述的便携式或者固定存储单元。该存储单元可以具有与图15的计算设备中的存储器1520类似布置的存储段、存储空间等。程序代码可以例如以适当形式进行压缩。通常，存储单元包括可读代码1531’，即可以由例如诸如1510之类的处理器读取的代码，这些代码当由计算设备运行时，导致该计算设备执行上面所描述的方法中的各个步骤。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (30)

  1. 一种加载安全密钥存储硬件的方法，包括：
    自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件；
    浏览器客户端读取并显示所述安全密钥存储硬件中存储的用户证书以供用户进行选择；
    当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证；
    所述身份验证通过后，加载所述选择信息对应的用户证书内容。
  2. 根据权利要求1所述的方法，其特征在于，还包括：
    在浏览器客户端中启动与主业务进程进行通信的加密子进程，其中，所述加密子进程用于作为连接代理实现第一加密通道到第二加密通道的转换，以及数据转发；
    所述加密子进程通过握手过程与所述网络服务器进行数字证书双向认证。
  3. 根据权利要求2所述的方法，其特征在于，所述加密子进程通过握手过程与所述网络服务器进行数字证书的双向认证的步骤，包括：
    所述加密子进程通过握手过程与所述网络服务器依次执行以下安全认证操作：加密数据协商、证书认证、密钥交换和签名认证。
  4. 根据权利要求3所述的方法，其特征在于，所述自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件，包括：
    在进行数字证书的双向认证时，所述加密子进程通过所述安全密钥存储硬件的供应方标识和产品编号关联到对应的驱动位置和驱动接口；
    通过所述驱动位置和驱动接口与所述安全密钥存储硬件建立连接通道。
  5. 根据权利要求4所述的方法，其特征在于，所述浏览器客户端读取并显示所述安全密钥存储硬件中存储的用户证书以供用户进行选择，包括：
    所述加密子进程通过所述连接通道读取所述安全密钥存储硬件中存储用户证书；
    弹出证书选择对话框，在所述证书选择对话框中加载所述用户证书以提示用户选择所述用户证书。
  6. 根据权利要求5所述的方法，其特征在于，所述加密子进程通过所述连接通道读取所述安全密钥存储硬件中存储的用户证书之后，还包括：
    所述加密子进程对所述安全密钥存储硬件中存储的用户证书进行证书站点识别，以证书站点为单位对所述用户证书进行分类；
    所述弹出证书选择对话框，在所述证书选择对话框中加载所述用户证书以提示用户选择所述用户证书，包括：
    弹出证书选择对话框，在所述证书选择对话框中以证书站点为索引显示所述用户证书。
  7. 根据权利要求5所述的方法，其特征在于，所述加密子进程通过所述连接通道读取所述安全密钥存储硬件中存储的用户证书，包括：
    所述加密子进程通过所述连接通道读取所述安全密钥存储硬件中存储的应用，显示所述应用以供用户进行选择，其中每个应用包括容器和容器中存储的用户证书；
    打开用户选择的应用，加载所述用户选择的应用下的容器和容器中存储的用户证书。
  8. 根据权利要求5所述的方法，其特征在于，所述当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证，包括：
    当接收到用户对所述用户证书的选择信息时，所述加密子进程弹出口令输入框，并通过所述口令输入框接收用户输入的保护口令；
    依据所述用户输入的保护口令对用户进行身份验证。
  9. 根据权利要求8所述的方法，其特征在于，所述当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证，还包括：
    若所述身份验证未通过，则在所述口令输入框中显示口令错误并提示用户重新输入保护口令，依据所述重新输入的保护口令进行身份验证。
  10. 根据权利要求9所述的方法，其特征在于，所述当浏览器客户端接收到用户对所述用户证书的选择信息时，对用户进行身份验证，还包括：
    所述加密子进程设置所述口令输入框的最大输入次数，当所述口令输入框中用户输入的保护口令的次数达到所述最大输入次数时，关闭所述个人密码输入框，并断开与所述安全密钥存储硬件的连接。
  11. 根据权利要求2所述的方法，其特征在于，所述身份验证通过后，加载所述选择信息对应的用户证书内容，包括：
    所述身份验证通过后，所述加密子进程获取所述用户证书中的认证信息，并将所述认证信息加载到证书查看器中；
    所述加密子进程依据触发指示启动所述证书查看器，在所述证书查看器中显示所述用户证书的认证信息。
  12. 根据权利要求11所述的方法，其特征在于，在所述证书查看器中显示所述用户证书的认证信息，包括：
    在所述证书查看器中分别设置常规选项卡和详细选项卡；
    在所述常规选项卡中显示所述选择信息对应的用户证书的常规信息；
    在所述详细选项卡中显示所述选择信息对应的用户证书的详细信息。
  13. 根据权利要求3所述的方法，其特征在于，所述自动识别并连接浏览器客户端 所在终端的接口***的安全密钥存储硬件之前，还包括：
    所述加密子进程在握手过程中确定是否接收所述网络服务器发送的证书认证请求消息；
    当接收到所述网络服务器发送的证书认证请求消息时，监测浏览器客户端所在终端的接口是否有安全密钥存储硬件***；
    当监测到有安全密钥存储硬件***时，执行所述自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件的步骤。
  14. 根据权利要求2所述的方法，其特征在于，所述加载所述选择信息对应的用户证书内容之后，还包括：
    所述加密子进程断开与所述安全密钥存储硬件的连接。
  15. 一种浏览器客户端装置，包括：
    连接模块，用于自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件；
    读取模块，用于读取并显示所述安全密钥存储硬件中存储的用户证书以供用户进行选择；
    身份验证模块，用于当接收到用户对所述用户证书的选择信息时，对用户进行身份验证；
    加载模块，用于所述身份验证通过后，加载所述选择信息对应的用户证书内容。
  16. 根据权利要求15所述的装置，其特征在于，还包括：
    主业务进程模块，用于在浏览器客户端中启动与主业务进程进行通信的加密子进程，其中，所述加密子进程用于作为连接代理实现第一加密通道到第二加密通道的转换，以及数据转发；
    加密子进程模块，用于通过握手过程与所述网络服务器进行数字证书双向认证。
  17. 根据权利要求16所述的装置，其特征在于：
    所述加密子进程模块，用于通过握手过程与所述网络服务器依次执行以下安全认证操作：加密数据协商、证书认证、密钥交换和签名认证。
  18. 根据权利要求17所述的装置，其特征在于：
    所述连接模块，用于在进行数字证书的双向认证时，所述加密子进程通过所述安全密钥存储硬件的供应方标识和产品编号关联到对应的驱动位置和驱动接口；通过所述驱动位置和驱动接口与所述安全密钥存储硬件建立连接通道。
  19. 根据权利要求18所述的装置，其特征在于，所述读取模块，包括：
    读取子模块，用于通过所述连接通道读取所述安全密钥存储硬件中存储用户证书；
    加载子模块，用于弹出证书选择对话框，在所述证书选择对话框中加载所述用户证书以提示用户选择所述用户证书。
  20. 根据权利要求19所述的装置，其特征在于，所述读取模块还包括：
    识别子模块，用于通过所述连接通道读取所述安全密钥存储硬件中存储的用户证书之后，对所述安全密钥存储硬件中存储的用户证书进行证书站点识别，以证书站点为单位对所述用户证书进行分类；
    所述加载子模块，具体用于弹出证书选择对话框，在所述证书选择对话框中以证书站点为索引显示所述用户证书。
  21. 根据权利要求19所述的装置，其特征在于：
    所述读取子模块，具体用于通过所述连接通道读取所述安全密钥存储硬件中存储的应用，显示所述应用以供用户进行选择，其中每个应用包括容器和容器中存储的用户证书；打开用户选择的应用，加载所述用户选择的应用下的容器和容器中存储的用户证书。
  22. 根据权利要求19所述的装置，其特征在于：
    所述身份验证模块，具体用于当接收到用户对所述用户证书的选择信息时，弹出口令输入框，并通过所述口令输入框接收用户输入的保护口令；依据所述用户输入的保护口令对用户进行身份验证。
  23. 根据权利要求22所述的装置，其特征在于：
    所述身份验证模块，还用于在所述身份验证未通过时，在所述口令输入框中显示口令错误并提示用户重新输入保护口令，依据所述重新输入的保护口令进行身份验证。
  24. 根据权利要求23所述的装置，其特征在于：
    所述身份验证模块，还用于对所述口令输入框设置最大输入次数，当所述口令输入框中用户输入的保护口令的次数达到所述最大输入次数时，关闭所述个人密码输入框，并断开与所述安全密钥存储硬件的连接。
  25. 根据权利要求16所述的装置，其特征在于：
    所述加载模块，具体用于所述身份验证通过后，获取所述用户证书中的认证信息，并将所述认证信息加载到证书查看器中；
    所述加密子进程模块，用于依据触发指示启动所述证书查看器，在所述证书查看器中显示所述用户证书的认证信息。
  26. 根据权利要求25所述的装置，其特征在于：
    所述加密子进程模块，用于在所述证书查看器中分别设置常规选项卡和详细选项卡；在所述常规选项卡中显示所述选择信息对应的用户证书的常规信息；在所述详细选项卡中显示所述选择信息对应的用户证书的详细信息。
  27. 根据权利要求17所述的装置，其特征在于：
    所述加密子进程模块，还用于在握手过程中确定是否接收所述网络服务器发送的证书认证请求消息；
    所述连接模块，还用于当所述加密子进程接收到所述网络服务器发送的证书认证请求消息时，监测浏览器客户端所在终端的接口是否有安全密钥存储硬件***；当监测到有安全密钥存储硬件***时，自动识别并连接浏览器客户端所在终端的接口***的安全密钥存储硬件。
  28. 根据权利要求16所述的装置，其特征在于：
    所述加密子进程模块，还用于所述加载模块加载所述选择信息对应的用户证书内容之后，断开与所述安全密钥存储硬件的连接。
  29. 一种程序，包括可读代码，当所述可读代码在计算设备上运行时，导致所述计算设备执行根据权利要求1-14中的任一个所述的加载安全密钥存储硬件的方法。
  30. 一种可读介质，其中存储了如权利要求29所述的程序。
PCT/CN2015/094847 2014-12-30 2015-11-17 加载安全密钥存储硬件的方法和浏览器客户端装置 WO2016107319A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410851890.7A CN104573554A (zh) 2014-12-30 2014-12-30 加载安全密钥存储硬件的方法和浏览器客户端装置
CN201410851890.7 2014-12-30

Publications (1)

Publication Number Publication Date
WO2016107319A1 true WO2016107319A1 (zh) 2016-07-07

Family

ID=53089587

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/094847 WO2016107319A1 (zh) 2014-12-30 2015-11-17 加载安全密钥存储硬件的方法和浏览器客户端装置

Country Status (2)

Country Link
CN (1) CN104573554A (zh)
WO (1) WO2016107319A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114996724A (zh) * 2022-04-25 2022-09-02 麒麟软件有限公司 一种基于国密算法模块的安全操作***
CN116599682A (zh) * 2023-07-13 2023-08-15 ***量子科技有限公司 基于skf接口的用户信息创建和验证方法及***

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104573554A (zh) * 2014-12-30 2015-04-29 北京奇虎科技有限公司 加载安全密钥存储硬件的方法和浏览器客户端装置
CN104618108B (zh) * 2014-12-30 2018-07-27 北京奇虎科技有限公司 安全通信***
CN105337977B (zh) * 2015-11-16 2019-01-25 江苏通付盾科技有限公司 一种动态双向认证的安全移动通讯***及其实现方法
CN107800675B (zh) * 2016-09-07 2020-04-07 深圳市腾讯计算机***有限公司 一种数据传输方法、终端以及服务器
CN106936898B (zh) * 2017-02-23 2020-06-05 中国银行股份有限公司 一种跨区间文件传输方法及***
CN107426151B (zh) * 2017-03-31 2020-07-31 武汉斗鱼网络科技有限公司 一种文件解密方法及装置
CN107968815B (zh) * 2017-10-25 2021-05-14 北京信安世纪科技股份有限公司 一种安全防护的方法及装置
CN109587116A (zh) * 2018-11-06 2019-04-05 交通银行股份有限公司 浏览器输入信息的保护方法、客户端及浏览器
CN109886679B (zh) * 2019-01-24 2021-02-23 杭州趣链科技有限公司 一种基于区块链的密钥扫码签名***
CN110263524B (zh) * 2019-08-05 2020-11-06 厦门亿力吉奥信息科技有限公司 一种移动设备加密u盾
CN111159684B (zh) * 2019-12-31 2023-02-03 郑州信大捷安信息技术股份有限公司 一种基于浏览器的安全防护***和方法
CN111610983B (zh) * 2020-05-04 2023-03-31 同智伟业软件股份有限公司 一种多ukey智能集成识别的方法
CN111865998A (zh) * 2020-07-24 2020-10-30 广西科技大学 网络安全区登录方法及装置
CN112149097B (zh) * 2020-09-22 2023-02-28 龙芯中科(合肥)技术有限公司 身份认证方法、装置、设备及存储介质
CN114676412A (zh) * 2020-12-24 2022-06-28 成都鼎桥通信技术有限公司 Usb key设备的验证方法、装置和存储介质
CN114760042A (zh) * 2020-12-26 2022-07-15 西安西电捷通无线网络通信股份有限公司 一种身份鉴别方法和装置
CN115470513A (zh) * 2021-06-11 2022-12-13 支付宝(杭州)信息技术有限公司 针对隐私计算进行算法协商的方法、装置及***
CN113472793B (zh) * 2021-07-01 2023-04-28 中易通科技股份有限公司 一种基于硬件密码设备的个人数据保护***
CN113672403B (zh) * 2021-07-30 2024-03-29 北京数码大方科技股份有限公司 信息***中的接口调用方法及接口调用装置、管理信息***
CN114598549B (zh) * 2022-03-25 2023-07-07 杭州迪普科技股份有限公司 客户ssl证书验证方法及装置
CN115085942B (zh) * 2022-07-28 2022-11-15 四川省数字证书认证管理中心有限公司 一种基于分布式UKey服务的数字签名方法及***

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101848090A (zh) * 2010-05-11 2010-09-29 武汉珞珈新世纪信息有限公司 认证装置及利用其进行网上身份认证与交易的***与方法
CN102368773A (zh) * 2011-10-31 2012-03-07 北京天地融科技有限公司 移动存储器的访问控制方法、移动存储器及***
CN104573554A (zh) * 2014-12-30 2015-04-29 北京奇虎科技有限公司 加载安全密钥存储硬件的方法和浏览器客户端装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030014629A1 (en) * 2001-07-16 2003-01-16 Zuccherato Robert J. Root certificate management system and method
CN2667807Y (zh) * 2004-01-08 2004-12-29 中国工商银行 网上银行利用USBKey加密、认证的装置
CN1271485C (zh) * 2004-01-08 2006-08-23 中国工商银行股份有限公司 对网上银行数据进行加密、认证方法
US8190875B2 (en) * 2007-03-22 2012-05-29 Cisco Technology, Inc. Reducing processing load in proxies for secure communications
CN101340285A (zh) * 2007-07-05 2009-01-07 杭州中正生物认证技术有限公司 利用指纹USBkey进行身份验证的方法及***
CN101447010B (zh) * 2008-12-30 2012-02-22 飞天诚信科技股份有限公司 登录***及登录方法
CN101587458A (zh) * 2009-06-30 2009-11-25 北京握奇数据***有限公司 智能存储卡的操作方法及装置
CN102567769B (zh) * 2010-12-31 2015-04-01 上海格尔软件股份有限公司 一种带证书选择的usbkey
CN103188074B (zh) * 2011-12-28 2016-08-10 上海格尔软件股份有限公司 一种增强浏览器ssl算法强度的代理方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101848090A (zh) * 2010-05-11 2010-09-29 武汉珞珈新世纪信息有限公司 认证装置及利用其进行网上身份认证与交易的***与方法
CN102368773A (zh) * 2011-10-31 2012-03-07 北京天地融科技有限公司 移动存储器的访问控制方法、移动存储器及***
CN104573554A (zh) * 2014-12-30 2015-04-29 北京奇虎科技有限公司 加载安全密钥存储硬件的方法和浏览器客户端装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114996724A (zh) * 2022-04-25 2022-09-02 麒麟软件有限公司 一种基于国密算法模块的安全操作***
CN114996724B (zh) * 2022-04-25 2024-05-03 麒麟软件有限公司 一种基于国密算法模块的安全操作***
CN116599682A (zh) * 2023-07-13 2023-08-15 ***量子科技有限公司 基于skf接口的用户信息创建和验证方法及***
CN116599682B (zh) * 2023-07-13 2023-09-19 ***量子科技有限公司 基于skf接口的用户信息创建和验证方法及***

Also Published As

Publication number Publication date
CN104573554A (zh) 2015-04-29

Similar Documents

Publication Publication Date Title
WO2016107319A1 (zh) 加载安全密钥存储硬件的方法和浏览器客户端装置
WO2016107321A1 (zh) 安全通信***
WO2016107320A1 (zh) 网站安全信息的加载方法和浏览器装置
WO2016107318A1 (zh) 一种安全通信***
WO2016107322A1 (zh) 安全浏览器的实现方法和安全浏览器装置
CN109088889B (zh) 一种ssl加解密方法、***及计算机可读存储介质
EP2792100B1 (en) Method and device for secure communications over a network using a hardware security engine
US8532620B2 (en) Trusted mobile device based security
US9722972B2 (en) Methods and apparatuses for secure communication
WO2017045552A1 (zh) 一种在ssl或tls通信中加载数字证书的方法和装置
WO2015180691A1 (zh) 验证信息的密钥协商方法及装置
CN103685187B (zh) 一种按需转换ssl认证方式以实现资源访问控制的方法
US11736304B2 (en) Secure authentication of remote equipment
CN106452782A (zh) 为终端设备生成安全通信信道的方法和***
CN107800675A (zh) 一种数据传输方法、终端以及服务器
US8397281B2 (en) Service assisted secret provisioning
CN112714053B (zh) 通信连接方法及装置
CN103546289A (zh) 一种基于USBKey的安全传输数据的方法及***
CN111131416A (zh) 业务服务的提供方法和装置、存储介质、电子装置
CN117081736A (zh) 密钥分发方法、密钥分发装置、通信方法及通信装置
CN113904767A (zh) 一种基于ssl建立通信的***
CN109302425A (zh) 身份认证方法及终端设备
CN106464684B (zh) 业务处理方法及装置
CN114531225A (zh) 端到端通信加密方法、装置、存储介质及终端设备
CN116545673A (zh) 一种数据传输方法、装置、云喇叭、电子设备及存储介质

Legal Events

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

Ref document number: 15874999

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15874999

Country of ref document: EP

Kind code of ref document: A1