US20110231650A1 - Use and generation of a session key in a secure socket layer connection - Google Patents
Use and generation of a session key in a secure socket layer connection Download PDFInfo
- Publication number
- US20110231650A1 US20110231650A1 US13/117,656 US201113117656A US2011231650A1 US 20110231650 A1 US20110231650 A1 US 20110231650A1 US 201113117656 A US201113117656 A US 201113117656A US 2011231650 A1 US2011231650 A1 US 2011231650A1
- Authority
- US
- United States
- Prior art keywords
- server
- client
- authentication
- key
- public key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
Definitions
- the invention relates generally to establishing secure connections over a network, and more particularly to establishing a secure socket layer type connection over a digital public network.
- Extended development and public acceptance have made electronic commerce and distributed transactions over public networks widespread. As shown in FIG. 1 , many of these transactions involve a client device 110 , such as a personal computer, accessing and communicating with a server 120 .
- the connection between the client 110 and the server 120 maybe used to exchange confidential information or enable the server to provide restricted or secured access.
- the need for security in transactions between a client and a server occurring over a digital connection on a network has become widespread as well. Therefore, in many cases, the connection between the client 110 and the server 120 is an encrypted and mutually authenticated connection 130 .
- the prior art includes several methods that attempt to resolve this need for security that requires mutual authentication and encrypted communication between the server and client.
- One method utilizes a symmetrical encryption algorithm based on a shared secret.
- a shared secret is known to both the client and the server.
- a shared secret may sometimes also be possessed by a trusted third party.
- a shared secret is not known to or easily determined by the public at large.
- the shared secret is used to derive an encryption key.
- the encryption key is then used to encrypt communication between the server and the client using a symmetrical encryption algorithm.
- the symmetrical encryption algorithm achieves confidentiality because the encrypted messages can't be read without knowing the shared secret.
- the method achieves authentication in that only a participant to the connection who possesses the shared secret may properly encrypt and decrypt messages with another participant. Thus, if a participant can read and generate a message or connection request that is encrypted, the party must possess the secret and is deemed authenticated.
- the shared secret often originates from the client side by a physical person operating the client side (e.g. by typing in a password).
- the size of the shared secret e.g. the number of characters in a password
- the cryptographic strength of the symmetric encryption key derived from that shared secret is also rather limited.
- Another method used by previous systems involves an asymmetric cryptographic algorithm and public key infrastructure (PKI) certificates for the server and the client.
- PKI public key infrastructure
- This method does not utilize a shared secret known to both ends of a connection before setting up the connection. Rather, a client and a server exchange certificates when they establish a connection. The client and server then authenticate one another by validating each other's certificates. Next, dynamically generated random data is exchanged by the client and server using the public keys certified by each other's certificates. Both the client and the server use this dynamically generated data to compute separate but identical symmetric encryption key. This symmetric encryption key is then used to encrypt further communication between the client and the server and thereby provide confidentiality. In practice, it may be impractical to provide clients with certificates.
- PKI public key infrastructure
- the server certificate is sufficient to authenticate the server and to establish the symmetric encryption key that provides confidentiality.
- Another method must be used to authenticate the client.
- the client may provide proof to the server that it possesses a shared secret known only to the server and the client (e.g. the client might send the server a password).
- the server end in a secure socket layer connection is authenticated by validating or verifying the server's certificate.
- the server certificate includes a digital signature generated by a certification authority (CA) linking the server's public key to the server's identity.
- the public key of the CA may then be certified by another higher-level CA.
- an entire hierarchy or chain of certificates may require verification. Regardless of the number of levels in a server's certificate chain, the client must have the public key of the highest level or root CA to be able to validate the entire chain.
- the security of this method depends on the trustworthiness of the root's public key.
- the data to be signed is assembled. This data includes the public key and data identifying the entity associated with that public key. This data may be considered a message.
- a message digest is created and then the message digest is encrypted.
- the message digest is a has of the message or the set of data to be signed.
- the encrypted message digest is the signature.
- a bank operating a website that allows bank customers to consult their accounts and perform financial transactions online. Only the rightful owner of an account should have access to their account. Therefore, the bank might require its customers to authenticate themselves by entering a password when accessing the site.
- clients connect to the bank's website using the SSL protocol.
- a entity who wants to compromise the account of a legitimate bank customer could mount a man-in-the-middle. To do so, the entity could set up a website that mimics the legitimate bank website. The entity generates a certificate for the fraudulent website with a bogus certification authority.
- the entity tricks the legitimate customer into adding the root certificate of the bogus CA to his list of trusted roots. If the legitimate customer now connects to the fraudulent website, the legitimate customer will think it's the legitimate bank website and enter a password. The entity has now obtained a valid password and can access the real bank website posing as the legitimate user to e.g. transfer money from the legitimate user's account to the entity's account.
- a technique that requires a client to trust the public key of the root CA of a server's SSL certificate to validate the authenticity of that server may reduce the security level of a secure socket layer connection and jeopardize server security.
- a client system should be able to verify the validity of a server's certificate or validate the link between the server's public key and its claimed identity without the client system having to trust the root CA or some intermediate CA of the server's certificate chain.
- the invention satisfies the shortcomings of the prior art by providing a method and system for verifying the link between a public key and a server's identity as claimed in the server's certificate without relying on the trustworthiness of the root certificate of the server's certificate chain.
- a secure socket layer type connection is established between a client and a server. While establishing the connection, the server transmits the server's certificate information to the client. Next, information is sent from the client to the server. Then, the client and the server independently create identical authentication keys by utilizing a shared secret known to the server and the client.
- the server transmits a first encrypted message to the client over the secure socket layer connection, wherein the first encrypted message is encrypted with the server authentication key and wherein the correctness of the contents of the first message can be verified by the client.
- the client decrypts the first encrypted message and validates the decrypted first message thus authenticating the server.
- the client transmits a second encrypted message to the server, wherein the second encrypted message is encrypted with the client authentication key and wherein the correctness of the contents of the second message can be verified by the server.
- the server decrypts the second encrypted message and validates the decrypted second message thus authenticating the client.
- the first encrypted message sent by the server to the client contains the server's certificate or public key that was used during the set-up of the secure socket layer type connection.
- the shared secret used to create the authentication key may be the response of a strong authentication token.
- the strong authentication token maybe a challenge-response, event, internal counter-based or time-based token, or any combination of these three strong authentication token variants.
- FIG. 1 is a illustration of a server client connection requiring a secured mutually authenticating connection in accordance with the prior art
- FIG. 2 is an illustration of a method for mutual authentication of an SSL connection in accordance with one embodiment of the present invention
- FIG. 3 is an illustration of a method for mutual authentication of an SSL connection in accordance with one embodiment of the present invention
- FIG. 4 is an illustration of a method for mutual authentication of an SSL connection, in accordance with one embodiment of the present invention.
- FIG. 5 is an illustration of a method for an authentication key generation process in accordance with one embodiment of the present invention.
- the present invention solves the problems of prior systems by using a secret to verify the link between a public key and a server's identity as claimed in the server's certificate without relying on the trustworthiness of the root certificate of the server's certificate chain.
- the invention takes the advantages of an SSL type connection without relying on the root certificate needed to verify the server's identity. This is achieved using a symmetric encryption authentication key that the client and server generate independently from each other. The authentication key is used by the server to encrypt the server's public key or certificate that was used to set-up the SSL connection.
- the present invention achieves mutual authentication and encryption without depending on the trustworthiness of the server certificate.
- One method for establishing a secure connection between a client and server involves using public key infrastructure (PKI) certificates for the server and the client.
- PKI public key infrastructure
- the first step in this method includes a client and a server exchanging certificates as they establish a connection.
- the client and server may validate each other's certificates to authenticate one another. However, in some instances, the client may not provide a certificate.
- dynamically generated random data is exchanged by the client and server using an asymmetric cryptographic algorithm and the public keys certified by the client and server (each by their own cert) certificates. Both the client and the server use this dynamically generated data to compute identical symmetric encryption keys.
- This symmetric encryption key uses asymmetric encryption algorithm to encrypt all further communication during the connection between the client and the server.
- a secure socket layer connection or just a secure connection shall include all types of connections that are established using the certificate-based method discussed above. Examples of such connections include a secure socket layer (SSL) connection, a transaction layer security (TLS) connections, a wireless TLS (WTLS) connection, an IP secure (IPSEC) connections.
- SSL secure socket layer
- TLS transaction layer security
- WTLS wireless TLS
- IPSEC IP secure
- the first level of encryption involves the encryption provided by the SSL connection. Messages sent over an SSL connection are encrypted.
- the second level of encryption involves the encryption performed by an authentication key.
- the authentication key is used to encrypt and decrypt messages to ensure that a client or server is who it represents itself to be. Unless otherwise specified, references to encryption herein are intended to pertain to the encryption performed by an authentication key.
- a method 200 for establishing a server connection between the server and the client in accordance with one embodiment of the present invention is shown in FIG. 2 .
- a client and server establish an SSL connection in step 201 .
- This SSL connection may be established with or without using a client certificate. While the SSL connection is being established, the client receives the server's certificate. All further communication between client and server occurs through this SSL connection. In one embodiment, the result of the verification of the server' certificate chain may be ignored.
- the authentication key to be used for mutually authenticating the server and the client is created.
- the client and server exchange some information in step 202 .
- the client and server each use the same shared secret to independently compute a symmetric encryption key in steps 203 and 204 .
- This symmetric encryption key is the authentication key.
- a shared secret as used herein is generally defined as a secret possessed by the client and the server.
- a third party such as a certificate authority may possess the secret.
- a secret known to a third party is still considered secret from the public at large.
- the shared secret is not transferred between the server and the client.
- the client and server are both authenticated.
- the server encrypts server authentication information in step 205 .
- the server constructs this server authentication information so the client may verify its correctness.
- the server then encrypts the server authentication information with the authentication key generated in the previous step and transmits the encrypted server authentication information to the client in step 206 .
- the client authenticates the server end of the SSL connection and establishes the trustworthiness of the SSL connection.
- the client encrypts client authentication information in step 208 with the same authentication key generated in step 203 and sends the encrypted client authentication information to the server in step 209 .
- the server then decrypts the encrypted client authentication information received from the client and verifies its correctness in step 210 .
- the server authenticates the client.
- the client authentication information can include the username and/or part of the information exchanged between client and server earlier on.
- the authentication key can be used to encrypt any further communication between the server and the client in addition to the encryption already provided by the SSL connection.
- FIG. 3 illustrates a method for establishing a secure connection between a client and a server in another embodiment of the present invention.
- the server authentication information includes the server's public key that is certified previously by the SSL server certificate.
- verifying the correctness of the server authentication information by the client includes verifying that the public key included in the server authentication information is the same as the public key certified by the SSL server certificate.
- the advantage of this embodiment is that the server's SSL certificate has been authenticated in a way which does not rely on using the public key of the certification authority that signed the SSL server certificate.
- the SSL connection can now be considered to be a secure, mutually authenticated connection that provides integrity and confidentiality, without the client side having to rely on the trustworthiness of the root certificate that holds the key of the certification authority that signed the SSL server certificate and has been stored on the client.
- Method 300 of FIG. 3 begins when the server and client establish a secure socket layer type connection in step 301 .
- This step is similar to the step of 201 in FIG. 2 except that the server sends its certificate to the client.
- the client then stores the certificate in step 302 . Once the connection is established, all communication between the client and server will occur through this connection.
- the server and client compute authentication keys.
- the client and server exchange information in step 303 .
- the client and server each use the same shared secret to independently compute a symmetric encryption key in steps 304 and 305 .
- This symmetric encryption key is the authentication key.
- the server encrypts the server certificate using the symmetric encryption key in step 306 and transmits the encrypted server certificate to the client in step 307 .
- the client compares the stored server certificate from step 302 to the encrypted server certificate sent in step 308 to authenticate the server.
- the client then encrypts client authentication information in step 309 .
- the encrypted client authentication information is then sent to the server from the client in step 310 .
- the server then decrypts the client authentication information to authenticate the client in step 311 .
- the entire SSL server certificate maybe included in the server authentication information in step 301 .
- Verifying the correctness of the server authentication information by the client in step 308 then includes verifying that the certificate included in the server authentication information is the same as the SSL server certificate received during the set-up of the SSL connection in step 301 .
- the shared secret used by the client and the server to generate the authentication key is the output of a strong authentication token (SAT).
- SAT strong authentication token
- the output of the token is the dynamic password generated by the token.
- the output of a SAT is provided to both the client and the server. The client and server generate an authentication key using the SAT output. The SAT is not transmitted between the client and the server before generating an authentication key.
- the SAT maybe a challenge-response token.
- the output of the SAT may rely on a challenge to generate a response. If a strong authentication token requires a challenge from the server to generate a dynamic password, the server side of the SSL connection sends this challenge to the client side of the SSL connection. The client and server will both independently generate a separate but identical response to the challenge. The SAT response is then considered the shared secret between the server and client and is used to generate the authentication key.
- the token may be a time-based SAT.
- This embodiment of a SAT may introduce synchronization issues to generating an authentication key.
- the server may allow a limited set of possible SAT responses rather than one single SAT response.
- One reason for allowing multiple SAT responses is to overcome synchronization issues. If a strong authentication token is time based, the server may not be capable of knowing exactly which value of the time the SAT has used to generate its response. This is because the internal clock of the SAT might slightly drift with respect to the server's clock and because the user interaction with the SAT always takes some varying unpredictable time.
- the server may allow a certain number of possible responses rather than a single response. In one embodiment of the present invention, the number of possible responses is relatively small.
- the server will use a window of time around the current time of its real-time clock and will allow multiple responses that can be generated on the basis of time values in that window.
- the server will allow multiple responses that can be generated on the basis of the current value of the server's counter and a limited number of consecutive counter values.
- the server should allow more than one authentication key. However, since the server first sends data to the client encrypted with the authentication key, the server should already know which of the possible authentication keys to use because the client only has one authentication key. To enable the server to figure out which key of the set of possible authentication keys is the one being used by the client, a synchronization phase may be implemented.
- FIG. 4 illustrates a method 400 for using a SAT to generate an authentication key.
- the method 400 begins when the client and server set up an SSL connection in operation 401 , with or without client authentication. While the connection is established, the server sends the server certificate to the client. The client obtains and stores the server's certificate in operation 402 . Once the connection is established, all further communication between client and server happen through this SSL connection.
- the authentication key is established as represented by steps 403 and 404 .
- the client sends information to the server.
- the information is the username or other client authentication information identifying the user at the client end.
- the server and the client exchange some data that will be used in calculating the authentication key in step 404 .
- the data exchanged are random seeds created independently by the client and server.
- the server sends a challenge to the client in operation 405 .
- the client and server independently generate an identical symmetric encryption key using the response of the SAT and the data exchanged in the operation 404 .
- This symmetric encryption key is the authentication key.
- the server sends a synchronization challenge to the client in step 408 .
- the client encrypts this synchronization challenge with the authentication key it has computed at step 409 .
- the client then sends the encrypted synchronization challenge back to the server in step 410 .
- the server determines what authentication key to use instep 411 .
- the server computes several acceptable SAT responses using information that may include the SAT challenge, the value of its clock and the current value of the event counter.
- the server computes all the acceptable SAT responses. Then, based on the acceptable SAT responses computed and the data exchanged, the server computes a set of candidate authentication keys in operation.
- the server may decrypt the encrypted synchronization challenge it received from the client with each of the authentication keys that are allowed on the basis of its clock or event counter in step 410 .
- the key from the set of allowed keys that successfully decrypts the encrypted synchronization challenge is the key that will be used by the server for authentication purposes.
- the client and server are authenticated.
- the server encrypts the certificate that it has sent to the client during the set-up of the SSL connection with its authentication key.
- the server sends this encrypted certificate to the client in operation 413 .
- the client decrypts the certificate received from the server and compares it to the certificate received from the client in the set-up of the SSL connection.
- the client Upon successfully decrypting of the encrypted server certificate and verifying it is the same certificate that the client has obtained during the set-up of the SSL connection, the client authenticates the server end of the SSL connection and establishes the trustworthiness of the SSL connection.
- step 415 the client encrypts the username or other client authentication information sent to the server in step 403 with the same authentication key.
- the client sends this encrypted information to the server in operations 416 .
- the server then decrypts the information and compares it to the information received from the client in step 417 .
- the server Upon successfully decrypting the encrypted username or other information previously received, the server authenticates the client.
- the SSL connection can now be considered to be a secure, mutually authenticated connection that provides integrity and confidentiality, without relying on the trustworthiness of the root certificate that has been stored on the client.
- the authentication key can be used to encrypt any further communication between the server and the client on top of the encryption already offered by the SSL connection.
- FIG. 5 is a flow chart of a process 500 showing a key generation algorithm based on the dynamic password of a challenge-response token in accordance with one embodiment of the present invention.
- the client and server exchange random seeds.
- the seeds are 256 bits in length are processed by both the client and the server in a similar fashion.
- the seeds are then combined in an operation 503 .
- the random seeds are combined using an XOR function. If the token is a challenge-response token the server will also provide the client with a challenge for the token.
- the initial generation vector is created.
- the user name which is known to the both the server and the client at the time of the session key generation is repeated to yield a string of 128 bits in operation 504 .
- a challenge issued by a server and known to both the server and the client is then repeated to yield a string of 128 bits in operation 506 .
- the first 128 bits of the combined random seeds and the expanded user name and the expanded challenge are then combined to yield the Initial Generation Vector in operation 507 .
- the elements are all combined using an XOR function.
- the generation key is created.
- the response to the challenge is repeated to yield a string of 128 bits in operation 509 .
- the response is independently generated by both the server and the client.
- the elements are combined using an XOR function.
- the symmetrical block cipher algorithm is applied X number of times on the Initial Generation Vector with the output of round N serving as the input to round N+1, where X is a fixed number known in advance by both client and server such that the described calculation takes something between 10 and 100 milliseconds on a typical client.
- the resulting 128 bits of this calculation are the Authentication Key in operation 512 .
- the symmetrical block cipher algorithm is the 3 DES algorithm.
- the symmetrical block cipher algorithm is the AES algorithm.
- the present invention solves the problems of prior systems by using a secret to verify the link between a public key and a server's identity as claimed in the server's certificate without relying on the trustworthiness of the root certificate of the server's certificate chain.
- the invention takes the advantages of an SSL type connection without relying on the root certificate needed to verify the server's identity. This is achieved using a symmetric encryption authentication key that the client and server generate independently from each other. The authentication key is used by the server to encrypt the server's public key or certificate that was used to set-up the SSL connection.
- the present invention achieves mutual authentication and encryption without depending on the trustworthiness of the server certificate.
Abstract
The invention describes a method and system for verifying the link between a public key and a server's identity without relying on the trustworthiness of the root certificate of the server's certificate chain. The system establishes a secure socket layer type connection between a client and a server. The client and the server create an identical authentication key using a shared secret known to the server and the client. Next, the server transmits a first encrypted message to the client, wherein the first encrypted message includes the server's public key encrypted with the authentication key. Then, the client decrypts the first encrypted message and verifies the correctness of that message including comparing the public key included in the decrypted first encrypted message to the public key transmitted during the set-up of the secure socket layer type connection to authenticate the client.
Description
- The present application is a continuation application of application Ser. No. 10/135,163 filed Apr. 30, 2002, which claims the benefit of priority under 35 U.S.C. .§.119(e) to U.S. Provisional Patent Application entitled “Use and Generation of a Session Key in a Secure Socket Layer Connection”, Ser. No. 60/287,858, filed on May 1, 2001, which application is incorporated herein by reference.
- The present application is related to the following United States patents and patent applications, which patent/applications are assigned to the owner of the present invention, and which patents/applications are incorporated by reference herein in their entirety:
- U.S. patent application Ser. No. 09/789,197, entitled “Field Programmable Smart Card Terminal and Token Device”, filed on Feb. 20, 2001, currently pending;
- U.S. Pat. No. 4,599,489, entitled “Solid State Key for Controlling Access to Computer Software”, filed on Feb. 22, 1984, issued on Jul. 8, 1986;
- U.S. Pat. No. 4,609,777, entitled “Solid State Key for Controlling Access to Computer Software”, filed on Dec. 23, 1985, issued on Sep. 2, 1986; and
- U.S. Pat. No. 4,819,267, entitled “Solid State Key for Controlling Access to Computer Systems and to Computer Software and/or for Secure Communications, filed on Jun. 9, 1987, issued on Apr. 4, 1989.
- The invention relates generally to establishing secure connections over a network, and more particularly to establishing a secure socket layer type connection over a digital public network.
- Extended development and public acceptance have made electronic commerce and distributed transactions over public networks widespread. As shown in
FIG. 1 , many of these transactions involve aclient device 110, such as a personal computer, accessing and communicating with aserver 120. The connection between theclient 110 and theserver 120 maybe used to exchange confidential information or enable the server to provide restricted or secured access. As a result, the need for security in transactions between a client and a server occurring over a digital connection on a network has become widespread as well. Therefore, in many cases, the connection between theclient 110 and theserver 120 is an encrypted and mutuallyauthenticated connection 130. - The prior art includes several methods that attempt to resolve this need for security that requires mutual authentication and encrypted communication between the server and client. One method utilizes a symmetrical encryption algorithm based on a shared secret. In general, a shared secret is known to both the client and the server. However, a shared secret may sometimes also be possessed by a trusted third party. In general, a shared secret is not known to or easily determined by the public at large. The shared secret is used to derive an encryption key. The encryption key is then used to encrypt communication between the server and the client using a symmetrical encryption algorithm. The symmetrical encryption algorithm achieves confidentiality because the encrypted messages can't be read without knowing the shared secret. The method achieves authentication in that only a participant to the connection who possesses the shared secret may properly encrypt and decrypt messages with another participant. Thus, if a participant can read and generate a message or connection request that is encrypted, the party must possess the secret and is deemed authenticated. For practical reasons, the shared secret often originates from the client side by a physical person operating the client side (e.g. by typing in a password). For ergonomic reasons, the size of the shared secret (e.g. the number of characters in a password) is therefore quite limited. As a result, the cryptographic strength of the symmetric encryption key derived from that shared secret is also rather limited.
- Another method used by previous systems involves an asymmetric cryptographic algorithm and public key infrastructure (PKI) certificates for the server and the client. This method does not utilize a shared secret known to both ends of a connection before setting up the connection. Rather, a client and a server exchange certificates when they establish a connection. The client and server then authenticate one another by validating each other's certificates. Next, dynamically generated random data is exchanged by the client and server using the public keys certified by each other's certificates. Both the client and the server use this dynamically generated data to compute separate but identical symmetric encryption key. This symmetric encryption key is then used to encrypt further communication between the client and the server and thereby provide confidentiality. In practice, it may be impractical to provide clients with certificates. As a result, sometimes only the server has a certificate to be validated. In this case, the server certificate is sufficient to authenticate the server and to establish the symmetric encryption key that provides confidentiality. Another method must be used to authenticate the client. For example, the client may provide proof to the server that it possesses a shared secret known only to the server and the client (e.g. the client might send the server a password). As mentioned above, the server end in a secure socket layer connection is authenticated by validating or verifying the server's certificate. The server certificate includes a digital signature generated by a certification authority (CA) linking the server's public key to the server's identity. The public key of the CA may then be certified by another higher-level CA. In theory, an entire hierarchy or chain of certificates may require verification. Regardless of the number of levels in a server's certificate chain, the client must have the public key of the highest level or root CA to be able to validate the entire chain. Thus, the security of this method depends on the trustworthiness of the root's public key.
- There are several steps in preparing a PKI certificate. First the data to be signed is assembled. This data includes the public key and data identifying the entity associated with that public key. This data may be considered a message. Next a message digest is created and then the message digest is encrypted. The message digest is a has of the message or the set of data to be signed. The encrypted message digest is the signature.
- In practice, many client systems and network browsers have an extensive list of certificate roots that the client “trusts.” It is usually not difficult to convince a user to add additional certificate roots to their list of trusted roots. Thus, a user may unknowingly add a tainted or false certificate root by an illegitimate CA. This false root may have been used by a dishonest entity to generate a certificate for an illegitimate server that poses as a legitimate server. In this way, a dishonest entity may lead a client to make a connection with the illegitimate server and unknowingly provide sensitive information such as the user's password to the legitimate server.
- For purposes of illustration, one may consider a bank operating a website that allows bank customers to consult their accounts and perform financial transactions online. Only the rightful owner of an account should have access to their account. Therefore, the bank might require its customers to authenticate themselves by entering a password when accessing the site. To protect the confidentiality of information exchanged between the client and the bank's website such as a user password, clients connect to the bank's website using the SSL protocol. A entity who wants to compromise the account of a legitimate bank customer could mount a man-in-the-middle. To do so, the entity could set up a website that mimics the legitimate bank website. The entity generates a certificate for the fraudulent website with a bogus certification authority. The entity tricks the legitimate customer into adding the root certificate of the bogus CA to his list of trusted roots. If the legitimate customer now connects to the fraudulent website, the legitimate customer will think it's the legitimate bank website and enter a password. The entity has now obtained a valid password and can access the real bank website posing as the legitimate user to e.g. transfer money from the legitimate user's account to the entity's account. Thus, relying on a technique that requires a client to trust the public key of the root CA of a server's SSL certificate to validate the authenticity of that server may reduce the security level of a secure socket layer connection and jeopardize server security.
- What is therefore needed is away to increase the security of a secure socket layer connection. A client system should be able to verify the validity of a server's certificate or validate the link between the server's public key and its claimed identity without the client system having to trust the root CA or some intermediate CA of the server's certificate chain.
- The invention satisfies the shortcomings of the prior art by providing a method and system for verifying the link between a public key and a server's identity as claimed in the server's certificate without relying on the trustworthiness of the root certificate of the server's certificate chain. A secure socket layer type connection is established between a client and a server. While establishing the connection, the server transmits the server's certificate information to the client. Next, information is sent from the client to the server. Then, the client and the server independently create identical authentication keys by utilizing a shared secret known to the server and the client. Next, the server transmits a first encrypted message to the client over the secure socket layer connection, wherein the first encrypted message is encrypted with the server authentication key and wherein the correctness of the contents of the first message can be verified by the client. Then, the client decrypts the first encrypted message and validates the decrypted first message thus authenticating the server. The client then transmits a second encrypted message to the server, wherein the second encrypted message is encrypted with the client authentication key and wherein the correctness of the contents of the second message can be verified by the server. Finally, the server decrypts the second encrypted message and validates the decrypted second message thus authenticating the client. In one embodiment, the first encrypted message sent by the server to the client contains the server's certificate or public key that was used during the set-up of the secure socket layer type connection. In one embodiment, the shared secret used to create the authentication key may be the response of a strong authentication token. In this embodiment, the strong authentication token maybe a challenge-response, event, internal counter-based or time-based token, or any combination of these three strong authentication token variants.
-
FIG. 1 is a illustration of a server client connection requiring a secured mutually authenticating connection in accordance with the prior art; -
FIG. 2 is an illustration of a method for mutual authentication of an SSL connection in accordance with one embodiment of the present invention; -
FIG. 3 is an illustration of a method for mutual authentication of an SSL connection in accordance with one embodiment of the present invention; -
FIG. 4 is an illustration of a method for mutual authentication of an SSL connection, in accordance with one embodiment of the present invention; and -
FIG. 5 is an illustration of a method for an authentication key generation process in accordance with one embodiment of the present invention. - The present invention solves the problems of prior systems by using a secret to verify the link between a public key and a server's identity as claimed in the server's certificate without relying on the trustworthiness of the root certificate of the server's certificate chain. The invention takes the advantages of an SSL type connection without relying on the root certificate needed to verify the server's identity. This is achieved using a symmetric encryption authentication key that the client and server generate independently from each other. The authentication key is used by the server to encrypt the server's public key or certificate that was used to set-up the SSL connection. Thus, the present invention achieves mutual authentication and encryption without depending on the trustworthiness of the server certificate.
- One method for establishing a secure connection between a client and server involves using public key infrastructure (PKI) certificates for the server and the client. The first step in this method includes a client and a server exchanging certificates as they establish a connection. The client and server may validate each other's certificates to authenticate one another. However, in some instances, the client may not provide a certificate. Next, dynamically generated random data is exchanged by the client and server using an asymmetric cryptographic algorithm and the public keys certified by the client and server (each by their own cert) certificates. Both the client and the server use this dynamically generated data to compute identical symmetric encryption keys. This symmetric encryption key uses asymmetric encryption algorithm to encrypt all further communication during the connection between the client and the server. A secure socket layer connection or just a secure connection, as used herein shall include all types of connections that are established using the certificate-based method discussed above. Examples of such connections include a secure socket layer (SSL) connection, a transaction layer security (TLS) connections, a wireless TLS (WTLS) connection, an IP secure (IPSEC) connections.
- In one embodiment of the present invention, two types of encryption are occurring. The first level of encryption involves the encryption provided by the SSL connection. Messages sent over an SSL connection are encrypted. The second level of encryption involves the encryption performed by an authentication key. The authentication key is used to encrypt and decrypt messages to ensure that a client or server is who it represents itself to be. Unless otherwise specified, references to encryption herein are intended to pertain to the encryption performed by an authentication key.
- A
method 200 for establishing a server connection between the server and the client in accordance with one embodiment of the present invention is shown inFIG. 2 . Inmethod 200, a client and server establish an SSL connection instep 201. This SSL connection may be established with or without using a client certificate. While the SSL connection is being established, the client receives the server's certificate. All further communication between client and server occurs through this SSL connection. In one embodiment, the result of the verification of the server' certificate chain may be ignored. - Next, the authentication key to be used for mutually authenticating the server and the client is created. First, the client and server exchange some information in
step 202. Then, the client and server each use the same shared secret to independently compute a symmetric encryption key insteps - Next, the client and server are both authenticated. First, the server encrypts server authentication information in
step 205. The server constructs this server authentication information so the client may verify its correctness. The server then encrypts the server authentication information with the authentication key generated in the previous step and transmits the encrypted server authentication information to the client instep 206. By successfully decrypting this encrypted server authentication information and verifying its correctness instep 207, the client authenticates the server end of the SSL connection and establishes the trustworthiness of the SSL connection. Next, the client encrypts client authentication information instep 208 with the same authentication key generated instep 203 and sends the encrypted client authentication information to the server instep 209. The server then decrypts the encrypted client authentication information received from the client and verifies its correctness instep 210. By successfully decrypting and verifying the encrypted client authentication information, the server authenticates the client. The client authentication information can include the username and/or part of the information exchanged between client and server earlier on. The authentication key can be used to encrypt any further communication between the server and the client in addition to the encryption already provided by the SSL connection. -
FIG. 3 illustrates a method for establishing a secure connection between a client and a server in another embodiment of the present invention. InFIG. 3 , the server authentication information includes the server's public key that is certified previously by the SSL server certificate. Thus, verifying the correctness of the server authentication information by the client includes verifying that the public key included in the server authentication information is the same as the public key certified by the SSL server certificate. The advantage of this embodiment is that the server's SSL certificate has been authenticated in a way which does not rely on using the public key of the certification authority that signed the SSL server certificate. The SSL connection can now be considered to be a secure, mutually authenticated connection that provides integrity and confidentiality, without the client side having to rely on the trustworthiness of the root certificate that holds the key of the certification authority that signed the SSL server certificate and has been stored on the client. -
Method 300 ofFIG. 3 begins when the server and client establish a secure socket layer type connection instep 301. This step is similar to the step of 201 inFIG. 2 except that the server sends its certificate to the client. The client then stores the certificate instep 302. Once the connection is established, all communication between the client and server will occur through this connection. - Next, the server and client compute authentication keys. First, the client and server exchange information in
step 303. Then, the client and server each use the same shared secret to independently compute a symmetric encryption key insteps step 306 and transmits the encrypted server certificate to the client instep 307. The client compares the stored server certificate fromstep 302 to the encrypted server certificate sent instep 308 to authenticate the server. The client then encrypts client authentication information instep 309. The encrypted client authentication information is then sent to the server from the client instep 310. The server then decrypts the client authentication information to authenticate the client in step 311. - In another embodiment of the present invention, the entire SSL server certificate maybe included in the server authentication information in
step 301. Verifying the correctness of the server authentication information by the client instep 308 then includes verifying that the certificate included in the server authentication information is the same as the SSL server certificate received during the set-up of the SSL connection instep 301. - In one embodiment of the present invention, the shared secret used by the client and the server to generate the authentication key is the output of a strong authentication token (SAT). In a preferred embodiment of the invention, the output of the token is the dynamic password generated by the token. In this embodiment, the output of a SAT is provided to both the client and the server. The client and server generate an authentication key using the SAT output. The SAT is not transmitted between the client and the server before generating an authentication key.
- In one embodiment of the present invention, the SAT maybe a challenge-response token. In this embodiment, the output of the SAT may rely on a challenge to generate a response. If a strong authentication token requires a challenge from the server to generate a dynamic password, the server side of the SSL connection sends this challenge to the client side of the SSL connection. The client and server will both independently generate a separate but identical response to the challenge. The SAT response is then considered the shared secret between the server and client and is used to generate the authentication key.
- In another embodiment, the token may be a time-based SAT. This embodiment of a SAT may introduce synchronization issues to generating an authentication key. In one embodiment where strong authentication tokens are based on an internal real-time clock and/or an event such as an internal counter, the server may allow a limited set of possible SAT responses rather than one single SAT response. One reason for allowing multiple SAT responses is to overcome synchronization issues. If a strong authentication token is time based, the server may not be capable of knowing exactly which value of the time the SAT has used to generate its response. This is because the internal clock of the SAT might slightly drift with respect to the server's clock and because the user interaction with the SAT always takes some varying unpredictable time. Similarly, if a strong authentication token is event based, the server is often not capable of knowing exactly which value of the event counter the SAT has used to generate its response. This is because it maybe possible that the SAT has generated a response that incremented a counter but didn't reach the server. Thus, the server would not be aware that the event counter has been increased. To overcome the synchronization problems in case of a time or event based SAT, the server may allow a certain number of possible responses rather than a single response. In one embodiment of the present invention, the number of possible responses is relatively small. In the case of a time based SAT, the server will use a window of time around the current time of its real-time clock and will allow multiple responses that can be generated on the basis of time values in that window. Similarly, in the case of an event based token the server will allow multiple responses that can be generated on the basis of the current value of the server's counter and a limited number of consecutive counter values.
- In one embodiment, to account for more than one valid response, the server should allow more than one authentication key. However, since the server first sends data to the client encrypted with the authentication key, the server should already know which of the possible authentication keys to use because the client only has one authentication key. To enable the server to figure out which key of the set of possible authentication keys is the one being used by the client, a synchronization phase may be implemented.
-
FIG. 4 illustrates amethod 400 for using a SAT to generate an authentication key. Themethod 400 begins when the client and server set up an SSL connection inoperation 401, with or without client authentication. While the connection is established, the server sends the server certificate to the client. The client obtains and stores the server's certificate inoperation 402. Once the connection is established, all further communication between client and server happen through this SSL connection. - Next, the authentication key is established as represented by
steps 403 and 404. In operation 403, the client sends information to the server. In one embodiment of the invention, the information is the username or other client authentication information identifying the user at the client end. Next, the server and the client exchange some data that will be used in calculating the authentication key instep 404. In one embodiment of the present invention, the data exchanged are random seeds created independently by the client and server. Next, if the SAT is a challenge-response SAT, the server sends a challenge to the client in operation 405. Then, inoperation operation 404. This symmetric encryption key is the authentication key. Next, if the SAT is a time-based or event-based SAT, the server sends a synchronization challenge to the client instep 408. Then, the client encrypts this synchronization challenge with the authentication key it has computed atstep 409. The client then sends the encrypted synchronization challenge back to the server in step 410. - The server then determines what authentication key to use instep 411. In one embodiment, the server computes several acceptable SAT responses using information that may include the SAT challenge, the value of its clock and the current value of the event counter. In one embodiment, the server computes all the acceptable SAT responses. Then, based on the acceptable SAT responses computed and the data exchanged, the server computes a set of candidate authentication keys in operation.
- In one embodiment, the server may decrypt the encrypted synchronization challenge it received from the client with each of the authentication keys that are allowed on the basis of its clock or event counter in step 410. The key from the set of allowed keys that successfully decrypts the encrypted synchronization challenge is the key that will be used by the server for authentication purposes.
- Next, the client and server are authenticated. First, in
operation 412 the server encrypts the certificate that it has sent to the client during the set-up of the SSL connection with its authentication key. The server sends this encrypted certificate to the client inoperation 413. Then, inoperation 414, the client decrypts the certificate received from the server and compares it to the certificate received from the client in the set-up of the SSL connection. Upon successfully decrypting of the encrypted server certificate and verifying it is the same certificate that the client has obtained during the set-up of the SSL connection, the client authenticates the server end of the SSL connection and establishes the trustworthiness of the SSL connection. Next, in step 415 the client encrypts the username or other client authentication information sent to the server in step 403 with the same authentication key. The client sends this encrypted information to the server in operations 416. The server then decrypts the information and compares it to the information received from the client in step 417. Upon successfully decrypting the encrypted username or other information previously received, the server authenticates the client. The SSL connection can now be considered to be a secure, mutually authenticated connection that provides integrity and confidentiality, without relying on the trustworthiness of the root certificate that has been stored on the client. The authentication key can be used to encrypt any further communication between the server and the client on top of the encryption already offered by the SSL connection. -
FIG. 5 is a flow chart of a process 500 showing a key generation algorithm based on the dynamic password of a challenge-response token in accordance with one embodiment of the present invention. First, inoperations operation 503. In one embodiment, the random seeds are combined using an XOR function. If the token is a challenge-response token the server will also provide the client with a challenge for the token. Next, the initial generation vector is created. First, the user name which is known to the both the server and the client at the time of the session key generation is repeated to yield a string of 128 bits inoperation 504. A challenge issued by a server and known to both the server and the client is then repeated to yield a string of 128 bits inoperation 506. Next, the first 128 bits of the combined random seeds and the expanded user name and the expanded challenge are then combined to yield the Initial Generation Vector inoperation 507. In one embodiment of the present invention, the elements are all combined using an XOR function. - Next, the generation key is created. First, the response to the challenge is repeated to yield a string of 128 bits in
operation 509. The response is independently generated by both the server and the client. - Then, the last 128 bits of the combined seeds and the expanded response are combined to yield the Generating Key. In one embodiment, the elements are combined using an XOR function.
- Then, in
operation 511, using the generating key as a symmetrical block cypher key, the symmetrical block cipher algorithm is applied X number of times on the Initial Generation Vector with the output of round N serving as the input to round N+1, where X is a fixed number known in advance by both client and server such that the described calculation takes something between 10 and 100 milliseconds on a typical client. Finally, the resulting 128 bits of this calculation are the Authentication Key in operation 512. In one embodiment the symmetrical block cipher algorithm is the 3 DES algorithm. In another embodiment the symmetrical block cipher algorithm is the AES algorithm. - The present invention solves the problems of prior systems by using a secret to verify the link between a public key and a server's identity as claimed in the server's certificate without relying on the trustworthiness of the root certificate of the server's certificate chain. The invention takes the advantages of an SSL type connection without relying on the root certificate needed to verify the server's identity. This is achieved using a symmetric encryption authentication key that the client and server generate independently from each other. The authentication key is used by the server to encrypt the server's public key or certificate that was used to set-up the SSL connection. Thus, the present invention achieves mutual authentication and encryption without depending on the trustworthiness of the server certificate.
- Other features, aspects and objects of the invention can be obtained from a review of the figures and the claims. It is to be understood that other embodiments of the invention can be developed and fall within the spirit and scope of the invention and claims.
- The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to the practitioner skilled in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence.
Claims (46)
1. A method for establishing a secure connection and authenticating a server in connections formed with PKI procedures, wherein a server public key, obtained from the server by a client, is used with asymmetric cryptography to establish a symmetric session key for encryption of communications with symmetric cryptography during the connection, said method offering an alternative for authenticating the server public key, and comprising:
generating a server authentication key by the server,
transmitting said server public key by the server to the client in clear text form;
generating a client authentication key by the client, the server authentication key and the client authentication key being identical to each other as both are generated using a common secret;
generating server authentication information from data derived from the server public key and processed with a symmetric cryptographic algorithm and the server authentication key,
sending said server authentication information to the client,
verifying the server authentication information at the client in order to authenticate the server public key, said verifying using the client authentication key to determine that the server authentication information is based on said server authentication key and the server public key used in establishing the secure connection and received from the server.
2. A method as recited in claim 1 wherein:
the server authentication key is used for encrypting the server authentication information with a symmetric encryption algorithm; and which further includes:
decrypting, at the client, the received server authentication information with the client authentication key and a symmetric decryption algorithm, and
wherein said verifying implements verifying the correctness of the server authentication information at the client by comparing the decrypted server authentication information with the server public key used in establishing the secure connection and received from the server.
3. The method of claim 2 wherein the server authentication information includes a server certificate.
4. The method of claim 2 wherein the secure connection includes an SSL connection.
5. The method of claim 2 wherein the secure connection includes an WTLS connection.
6. The method of claim 2 wherein the secure connection includes an IPSEC connection.
7. The method of claim 2 wherein the secure connection includes a TLS connection.
8. The method of claim 2 wherein the secret is generated by a strong authentication token.
9. The method as recited in claim 2 which further includes:
sending client information to the server to authenticate the client, the client information encrypted by the client using the client authentication key and decrypted by the server using the server authentication key, the correctness of the client information verified by the server.
10. The method of claim 2 wherein the server authentication information includes the server public key.
11. The method of claim 2 wherein the server authentication information includes data derived from the server public key.
12. The method of claim 8 wherein the strong authentication token is a challenge response token, wherein generating an authentication key by both the server and the client includes:
sending a challenge from a server to the strong authentication token;
generating a first strong authentication token response to the challenge at the client;
generating a second strong authentication token response to the challenge at the server, the first response identical to the second response when the secret is common to the client and server;
deriving a client authentication key by the client from the first strong authentication token response;
deriving a server authentication key by the server from the second strong authentication token response.
13. A method for authenticating a server public key and establishing a secure connection between a client and a server, the connection formed with PKI procedures and including a symmetric key established using the server public key with asymmetric cryptography, said symmetric key used to encrypt communications during the connection with symmetric cryptography, the method offering an alternative for authenticating the server public key, and comprising:
transmitting a server certificate from the server to the client, the server certificate including server public key information;
generating separate authentication keys by the server and the client, the keys being identical as generated using a common secret, said generating separate authentication keys including:
sending user authentication information from the client to the server;
exchanging dynamic information between the client and the server;
generating a secret by the client and the server from the response of a strong authentication token; and
generating authentication keys at client and server using the user authentication information, the dynamic information, and the secret; thereafter
generating server authentication information at the server from data derived from the server public key and processed with a symmetric cryptographic algorithm and the server authentication key;
sending said server authentication information to the client;
receiving the server authentication information at the client, and
verifying the server authentication information at the client in order to authenticate the server public key, said verifying using the client authentication key to determine that the server authentication information is based on said server authentication key and the server public key information from the server certificate.
14. A method as recited in claim 13 wherein:
said generating server authentication information comprises encrypting data related to the server public key using the server authentication key and a symmetric encryption algorithm;
said verifying includes decrypting the received server authentication information at the client using a symmetric decryption algorithm and the client authentication key; and
determining the correctness of the server authentication information by comparing the decrypted server authentication information with the server public key information from the server certificate.
15. The method of claim 14 wherein the user authentication information includes a user identification information.
16. The method of claim 14 wherein the secure connection is an SSL connection.
17. The method of claim 14 wherein the dynamic information includes random information.
18. The method of claim 14 wherein the strong authentication token includes a challenge- response strong authentication token, wherein the secret is derived from the response of the challenge response token.
19. The method as recited in claim 14 further including:
sending encrypted user authentication information to the server, the user authentication information encrypted by the client using the authentication key generated by the client; and
receiving and decrypting the user authentication information by the server, the server decrypting the user authentication information using the authentication key created by the server, the correctness of the user authentication information verified by the server.
20. The method of claim 14 wherein the server certificate transmitted to the client includes the server public key.
21. The method of claim 14 wherein the server authentication information includes the server public key.
22. The method of claim 14 wherein the server authentication information includes data derived from the server public key.
23. The method of claim 11 wherein the data derived from the server public key includes a hash of the server public key.
24. The method of claim 22 wherein the data derived from the server public key includes a hash of the server public key.
25. A method for establishing a secure connection using PKI procedures and authenticating a server public key, wherein the server public key, obtained from the server by a client, is used with asymmetric cryptography to establish a symmetric session key for encryption of communications with symmetric cryptography during the connection and offering an alternative for authenticating the server public key where a server authentication key is generated by the server and used to create server authentication information for transmission to the client, said method comprising
generating a client authentication key by the client, the server authentication key and the client authentication key being identical to each other as both are generated using a common secret;
receiving the server public key in clear text form from the server;
receiving the server authentication information at the client to authenticate the server public key, the server authentication information including data derived from the server's public key and processed with a server authentication key and with a symmetric cryptographic algorithm; and
verifying the server authentication information at the client in order to authenticate the server public key, said verifying using the client authentication key to determine that the server authentication information is based on the server authentication key and the server public key used in establishing the secure connection and received from the server.
26. A method as recited in claim 25 wherein the server authentication key is used to encrypt the server authentication information for transmission to the client, wherein said method further includes:
decrypting, at the client, the received server authentication information with the client authentication key and a symmetric decryption algorithm to obtain decrypted data, and
wherein said verifying includes verifying the correctness of the server authentication information at the client in order to authenticate the server public key by comparing the decrypted data with the server public key used in establishing the secure connection and received from the server.
27. The method of claim 26 wherein the server authentication information includes a server certificate.
28. The method of claim 26 wherein the secure connection includes an SSL connection.
29. The method of claim 26 wherein the secure connection includes an WTLS connection.
30. The method of claim 26 wherein the secure connection includes an IPSEC connection.
31. The method of claim 26 wherein the secure connection includes a TLS connection.
32. The method of claim 26 wherein the secret is generated by a client strong authentication token.
33. The method as recited in claim 26 which further includes:
sending client information to the server to authenticate the client, the client information encrypted by the client using the client authentication key.
34. The method of claim 26 wherein the server authentication information includes the server public key.
35. The method of claim 32 wherein the strong authentication token is a challenge response token, wherein generating an authentication key by the client includes:
receiving a challenge from the server for the strong authentication token;
generating a strong authentication token response to the challenge at the client; and
deriving a client authentication key by the client from the strong authentication token response.
36. A method for authenticating a server public key and establishing a secure connection between a client and a server, the connection formed with PKI procedures and including a symmetric key, established using the server public key with asymmetric cryptography, to encrypt communications during the connection with symmetric cryptography, the method offering an alternative for authenticating the server public key, and comprising:
receiving a server certificate at the client, the server certificate including server public key information in clear text form;
generating an authentication key by the client corresponding to an authentication key generated at the server, the keys being identical as generated using a common secret, said generating an authentication key by the client including:
sending user authentication information from the client to the server;
exchanging dynamic information between the client and server,
generating a secret by the client from a response of a client strong authentication token corresponding to a secret generated by the server; and
the client generating said authentication key, corresponding to an authentication key generated at the server, using the user authentication information, the dynamic information, and the secret; thereafter
receiving server authentication information at the client, the server authentication information including data derived from the server public key, processed using the authentication key generated by the server and a symmetric cryptographic algorithm; and
verifying the server authentication information at the client by using the client authentication key to determine that the server authentication information is based on the server authentication key and the server public key information received in clear text form.
37. A method as recited in claim 36 wherein;
said receiving server authentication information comprises receiving server authentication information encrypted using the authentication key generated by the server and a symmetric encryption algorithm, and wherein
said verifying further comprises;
decrypting the server authentication information by the client, the client decrypting the server authentication information using a symmetric decryption algorithm and the authentication key created by the client, and
comparing the decrypted server authentication information at the client with server public key information received in clear text form.
38. The method of claim 36 wherein the user authentication information includes a user identification information.
39. The method of claim 36 wherein the secure connection is an SSL connection.
40. The method of claim 36 wherein the dynamic information includes random information.
41. The method of claim 36 wherein the strong authentication token includes a challenge-response strong authentication token, wherein the secret is derived from the response of the challenge response token.
42. The method as recited in claim 36 further including:
sending encrypted user authentication information to the server, the user authentication information encrypted by the client using the authentication key generated by the client.
43. The method of claim 36 wherein the server certificate received by the client includes the server public key.
44. The method of claim 36 wherein the server authentication information includes the server public key.
45. The method of claim 26 wherein the data derived from the server public key includes a hash of the server public key.
46. The method of claim 37 wherein the data derived from the server public key includes a hash of the server public key.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/117,656 US20110231650A1 (en) | 2001-05-01 | 2011-05-27 | Use and generation of a session key in a secure socket layer connection |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US28785801P | 2001-05-01 | 2001-05-01 | |
US10/135,163 US7975139B2 (en) | 2001-05-01 | 2002-04-30 | Use and generation of a session key in a secure socket layer connection |
US13/117,656 US20110231650A1 (en) | 2001-05-01 | 2011-05-27 | Use and generation of a session key in a secure socket layer connection |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/135,163 Continuation US7975139B2 (en) | 2001-05-01 | 2002-04-30 | Use and generation of a session key in a secure socket layer connection |
Publications (1)
Publication Number | Publication Date |
---|---|
US20110231650A1 true US20110231650A1 (en) | 2011-09-22 |
Family
ID=23104655
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/135,163 Expired - Fee Related US7975139B2 (en) | 2001-05-01 | 2002-04-30 | Use and generation of a session key in a secure socket layer connection |
US13/117,656 Abandoned US20110231650A1 (en) | 2001-05-01 | 2011-05-27 | Use and generation of a session key in a secure socket layer connection |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/135,163 Expired - Fee Related US7975139B2 (en) | 2001-05-01 | 2002-04-30 | Use and generation of a session key in a secure socket layer connection |
Country Status (4)
Country | Link |
---|---|
US (2) | US7975139B2 (en) |
EP (1) | EP1391073B8 (en) |
CA (1) | CA2446304C (en) |
WO (1) | WO2002091662A1 (en) |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110078776A1 (en) * | 2005-04-06 | 2011-03-31 | John Jules Alexander Boyer | Secure digital credential sharing arrangement |
CN102811224A (en) * | 2012-08-02 | 2012-12-05 | 天津赢达信科技有限公司 | Method, device and system for implementation of SSL (secure socket layer)/TLS (transport layer security) connection |
US8583926B1 (en) * | 2005-09-19 | 2013-11-12 | Jpmorgan Chase Bank, N.A. | System and method for anti-phishing authentication |
US20140040991A1 (en) * | 2011-01-05 | 2014-02-06 | Gelmalto Sa | Method for communicating between a server and a client and corresponding client, server and system |
US20140062670A1 (en) * | 2012-09-04 | 2014-03-06 | Honeywell International Inc. | Standby activation |
WO2014142901A1 (en) * | 2013-03-14 | 2014-09-18 | Mcafee, Inc. | Decryption of data between a client and a server |
WO2014200496A1 (en) * | 2013-06-13 | 2014-12-18 | Intel Corporation | Secure pairing for communication across devices |
WO2015026336A1 (en) * | 2013-08-21 | 2015-02-26 | Intel Corporation | Processing data privately in the cloud |
US20150188896A1 (en) * | 2013-12-27 | 2015-07-02 | Canon U.S.A., Inc. | Method for associating an image-forming device, a mobile device, and a user |
WO2015119610A1 (en) * | 2014-02-06 | 2015-08-13 | Empire Technology Development, Llc | Server-client secret generation with cached data |
US20180227125A1 (en) * | 2015-08-07 | 2018-08-09 | Atf Cyber, Inc. | Multi-use long string anti-tampering authentication system |
EP3499794A4 (en) * | 2016-08-08 | 2020-02-26 | NTI, Inc. | Ssl communication system, client, server, ssl communication method, and computer program |
CN111406390A (en) * | 2018-12-26 | 2020-07-10 | 深圳市大疆创新科技有限公司 | Encrypted communication method, device, system and computer storage medium |
KR20200086436A (en) * | 2019-01-09 | 2020-07-17 | 주식회사 엘지유플러스 | Method for evading mitm attack for https protocol |
CN111865924A (en) * | 2020-06-24 | 2020-10-30 | 新浪网技术(中国)有限公司 | Method and system for monitoring user side |
US11005658B2 (en) * | 2017-12-13 | 2021-05-11 | Delta Electronics, Inc. | Data transmission system with security mechanism and method thereof |
Families Citing this family (95)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7669233B2 (en) * | 1999-09-10 | 2010-02-23 | Metavante Corporation | Methods and systems for secure transmission of identification information over public networks |
US20030154286A1 (en) * | 2002-02-13 | 2003-08-14 | Infowave Software, Inc. | System for and method of protecting a username during authentication over a non-encrypted channel |
US20040030887A1 (en) * | 2002-08-07 | 2004-02-12 | Harrisville-Wolff Carol L. | System and method for providing secure communications between clients and service providers |
US7311029B2 (en) * | 2002-08-09 | 2007-12-25 | Black & Decker Inc. | Quick-pin blade tensioning device |
US7764791B2 (en) * | 2002-10-03 | 2010-07-27 | Daniel Lecomte | Method for secured transmission of audiovisual files |
US7302568B2 (en) * | 2003-03-14 | 2007-11-27 | Sun Microsystems, Inc. | Method, system, and article of manufacture for remote management of devices |
US7395424B2 (en) | 2003-07-17 | 2008-07-01 | International Business Machines Corporation | Method and system for stepping up to certificate-based authentication without breaking an existing SSL session |
JP5058600B2 (en) * | 2003-09-12 | 2012-10-24 | イーエムシー コーポレイション | System and method for providing contactless authentication |
US20050086468A1 (en) * | 2003-10-17 | 2005-04-21 | Branislav Meandzija | Digital certificate related to user terminal hardware in a wireless network |
US7430606B1 (en) | 2003-10-17 | 2008-09-30 | Arraycomm, Llc | Reducing certificate revocation lists at access points in a wireless access network |
FR2869175B1 (en) * | 2004-04-16 | 2008-04-18 | Audiosmartcard Internat Sa Sa | METHOD FOR SECURING OPERATIONS ON A NETWORK AND ASSOCIATED DEVICES |
JP4270033B2 (en) * | 2004-06-11 | 2009-05-27 | ソニー株式会社 | Communication system and communication method |
WO2006012058A1 (en) | 2004-06-28 | 2006-02-02 | Japan Communications, Inc. | Systems and methods for mutual authentication of network |
US7725716B2 (en) | 2004-06-28 | 2010-05-25 | Japan Communications, Inc. | Methods and systems for encrypting, transmitting, and storing electronic information and files |
US8117452B2 (en) * | 2004-11-03 | 2012-02-14 | Cisco Technology, Inc. | System and method for establishing a secure association between a dedicated appliance and a computing platform |
US20060143695A1 (en) * | 2004-12-27 | 2006-06-29 | Amiram Grynberg | Anonymous Spoof resistant authentication and enrollment methods |
US7836306B2 (en) * | 2005-06-29 | 2010-11-16 | Microsoft Corporation | Establishing secure mutual trust using an insecure password |
WO2007000179A1 (en) * | 2005-06-29 | 2007-01-04 | Telecom Italia S.P.A. | Short authentication procedure in wireless data communications networks |
US8181232B2 (en) * | 2005-07-29 | 2012-05-15 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
WO2007022800A1 (en) * | 2005-08-26 | 2007-03-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for providing access security in a communications network |
FR2890201A1 (en) * | 2005-08-31 | 2007-03-02 | Proton World Internatinal Nv | Digital data e.g. music files, storing method for e.g. digital floppy disk, involves encrypting digital data using symmetric algorithm with encryption key independent to recorder, and transferring key onto physical medium or microcircuit |
US9768963B2 (en) | 2005-12-09 | 2017-09-19 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for secure user authentication |
US9002750B1 (en) | 2005-12-09 | 2015-04-07 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for secure user authentication |
US7904946B1 (en) | 2005-12-09 | 2011-03-08 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
US7962742B2 (en) * | 2006-02-22 | 2011-06-14 | Henry Samuel Schwarz | Internet secure terminal for personal computers |
US8533338B2 (en) | 2006-03-21 | 2013-09-10 | Japan Communications, Inc. | Systems and methods for providing secure communications for transactions |
US7966646B2 (en) * | 2006-07-31 | 2011-06-21 | Aruba Networks, Inc. | Stateless cryptographic protocol-based hardware acceleration |
CN1913437B (en) * | 2006-08-25 | 2011-01-05 | 华为技术有限公司 | Initial session protocol application network and device and method for set-up of safety channel |
US8327142B2 (en) | 2006-09-27 | 2012-12-04 | Secureauth Corporation | System and method for facilitating secure online transactions |
JP5186648B2 (en) * | 2006-09-27 | 2013-04-17 | セキュアオース コーポレイション | System and method for facilitating secure online transactions |
DE102006060760A1 (en) * | 2006-09-29 | 2008-04-10 | Siemens Ag | Subscribers authenticating method for radio frequency identification communication system, involves encrypting calculated response and certificate associated with subscriber in randomized manner, and decrypting and authenticating response |
US20080115125A1 (en) * | 2006-11-13 | 2008-05-15 | Cingular Wireless Ii, Llc | Optimizing static dictionary usage for signal compression and for hypertext transfer protocol compression in a wireless network |
KR101366243B1 (en) * | 2006-12-04 | 2014-02-20 | 삼성전자주식회사 | Method for transmitting data through authenticating and apparatus therefor |
US8356170B2 (en) * | 2007-10-12 | 2013-01-15 | Panasonic Corporation | Management-apparatus card, measuring apparatus, health care system, and method for communicating vital sign data |
US9281947B2 (en) * | 2008-01-23 | 2016-03-08 | Microsoft Technology Licensing, Llc | Security mechanism within a local area network |
US20090210712A1 (en) * | 2008-02-19 | 2009-08-20 | Nicolas Fort | Method for server-side detection of man-in-the-middle attacks |
JP2010015541A (en) * | 2008-06-04 | 2010-01-21 | Fujitsu Ltd | Authentication system, terminal device, password issuing apparatus, and authentication method |
US20100077208A1 (en) * | 2008-09-19 | 2010-03-25 | Microsoft Corporation | Certificate based authentication for online services |
DE102009024604B4 (en) * | 2009-06-10 | 2011-05-05 | Infineon Technologies Ag | Generation of a session key for authentication and secure data transmission |
US9225525B2 (en) * | 2010-02-26 | 2015-12-29 | Red Hat, Inc. | Identity management certificate operations |
US8898457B2 (en) * | 2010-02-26 | 2014-11-25 | Red Hat, Inc. | Automatically generating a certificate operation request |
CN101938465B (en) * | 2010-07-05 | 2013-05-01 | 北京广电天地科技有限公司 | Method and system based on webservice authentication |
US8555067B2 (en) | 2010-10-28 | 2013-10-08 | Apple Inc. | Methods and apparatus for delivering electronic identification components over a wireless network |
US8924715B2 (en) | 2010-10-28 | 2014-12-30 | Stephan V. Schell | Methods and apparatus for storage and execution of access control clients |
KR20130003616A (en) * | 2011-06-30 | 2013-01-09 | 한국전자통신연구원 | Apparatus and method for generating session key and cluster key |
US20130209982A1 (en) * | 2012-02-15 | 2013-08-15 | Turning Technologies, Llc | System and method for managing and administering a high stakes test |
EP2831851A4 (en) * | 2012-03-30 | 2015-08-26 | Nokia Technologies Oy | Identity based ticketing |
EP2674887B1 (en) * | 2012-06-13 | 2020-01-01 | F. Hoffmann-La Roche AG | Controlling an analysis system of biological samples |
KR101367621B1 (en) * | 2012-06-28 | 2014-02-28 | 삼성에스디에스 주식회사 | System and method for authentication based on one-time password |
US11360851B2 (en) * | 2012-08-31 | 2022-06-14 | Pure Storage, Inc. | Duplicating authentication information between connections |
WO2014100640A1 (en) * | 2012-12-21 | 2014-06-26 | Advanced Biometric Controls, Llc | Verification of password using a keyboard with a secure password entry mode |
US8972730B2 (en) * | 2013-03-08 | 2015-03-03 | Honeywell International Inc. | System and method of using a signed GUID |
US9871785B1 (en) * | 2013-03-14 | 2018-01-16 | EMC IP Holding Company LLC | Forward secure one-time authentication tokens with embedded time hints |
CN103391286B (en) * | 2013-07-11 | 2016-05-18 | 北京天地互连信息技术有限公司 | Safety authentication method applied to all-IP remote monitoring network system |
KR20150050231A (en) * | 2013-10-31 | 2015-05-08 | 한국전자통신연구원 | Apparatus and method for performing key derivation on closed domain |
DE102013019870B4 (en) * | 2013-11-28 | 2019-08-08 | Friedrich Kisters | Authentication and / or identification method in a communication network |
CN104023013B (en) * | 2014-05-30 | 2017-04-12 | 上海帝联信息科技股份有限公司 | Data transmission method, server side and client |
CN105991569A (en) * | 2015-02-09 | 2016-10-05 | 中国科学院信息工程研究所 | Safe transmission method of TLS communication data |
US9338147B1 (en) | 2015-04-24 | 2016-05-10 | Extrahop Networks, Inc. | Secure communication secret sharing |
US10019718B2 (en) | 2015-05-12 | 2018-07-10 | Bank Of America Corporation | Customer-based associate interfaces |
US10644875B2 (en) * | 2016-04-28 | 2020-05-05 | International Business Machines Corporation | Pre-authorization of public key infrastructure |
KR101838511B1 (en) * | 2016-05-17 | 2018-03-14 | 현대자동차주식회사 | Method of providing security for controller using encryption and appratus for implementing the same |
CN106487783A (en) * | 2016-09-28 | 2017-03-08 | 深圳市速美特电子科技有限公司 | The encryption method connecting for vehicle communication and device |
CN106656992B (en) * | 2016-11-03 | 2020-06-19 | 林锦吾 | Information verification method |
US10425417B2 (en) * | 2017-03-08 | 2019-09-24 | Bank Of America Corporation | Certificate system for verifying authorized and unauthorized secure sessions |
US10476673B2 (en) | 2017-03-22 | 2019-11-12 | Extrahop Networks, Inc. | Managing session secrets for continuous packet capture systems |
JP6918582B2 (en) * | 2017-06-02 | 2021-08-11 | パナソニック株式会社 | Random number verification system and random number verification method |
US11172359B2 (en) * | 2017-08-09 | 2021-11-09 | Lenovo (Singapore) Pte. Ltd. | Method and apparatus for attach procedure with security key exchange for restricted services for unauthenticated user equipment |
US9967292B1 (en) | 2017-10-25 | 2018-05-08 | Extrahop Networks, Inc. | Inline secret sharing |
US10389574B1 (en) | 2018-02-07 | 2019-08-20 | Extrahop Networks, Inc. | Ranking alerts based on network monitoring |
US10038611B1 (en) | 2018-02-08 | 2018-07-31 | Extrahop Networks, Inc. | Personalization of alerts based on network monitoring |
US10270794B1 (en) | 2018-02-09 | 2019-04-23 | Extrahop Networks, Inc. | Detection of denial of service attacks |
US10411978B1 (en) | 2018-08-09 | 2019-09-10 | Extrahop Networks, Inc. | Correlating causes and effects associated with network activity |
US10594718B1 (en) | 2018-08-21 | 2020-03-17 | Extrahop Networks, Inc. | Managing incident response operations based on monitored network activity |
CN109462476B (en) * | 2018-11-23 | 2021-10-08 | 成都卫士通信息产业股份有限公司 | Key agreement method, device, terminal and computer readable storage medium |
US11431493B1 (en) * | 2019-01-10 | 2022-08-30 | Meta Platforms, Inc. | Systems and methods for secure authentication |
CN110266477B (en) * | 2019-05-23 | 2023-03-24 | 广州河东科技有限公司 | Dynamic encryption method for UDP communication |
US10965702B2 (en) | 2019-05-28 | 2021-03-30 | Extrahop Networks, Inc. | Detecting injection attacks using passive network monitoring |
US11165814B2 (en) | 2019-07-29 | 2021-11-02 | Extrahop Networks, Inc. | Modifying triage information based on network monitoring |
US11388072B2 (en) | 2019-08-05 | 2022-07-12 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
US10742530B1 (en) | 2019-08-05 | 2020-08-11 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
US11251958B2 (en) | 2019-08-12 | 2022-02-15 | Bank Of America Corporation | Security system with adaptive authentication based on tokenization chaining |
US10742677B1 (en) | 2019-09-04 | 2020-08-11 | Extrahop Networks, Inc. | Automatic determination of user roles and asset types based on network monitoring |
US11259082B2 (en) | 2019-10-22 | 2022-02-22 | Synamedia Limited | Systems and methods for data processing, storage, and retrieval from a server |
US11165823B2 (en) | 2019-12-17 | 2021-11-02 | Extrahop Networks, Inc. | Automated preemptive polymorphic deception |
US11153080B1 (en) * | 2020-07-29 | 2021-10-19 | John A. Nix | Network securing device data using two post-quantum cryptography key encapsulation mechanisms |
US11463466B2 (en) | 2020-09-23 | 2022-10-04 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
EP4218212A1 (en) | 2020-09-23 | 2023-08-02 | ExtraHop Networks, Inc. | Monitoring encrypted network traffic |
WO2022071789A1 (en) * | 2020-09-30 | 2022-04-07 | Mimos Berhad | Socket association for transfer of socket authentication status |
WO2022115491A1 (en) * | 2020-11-24 | 2022-06-02 | Nix John A | Multiple post-quantum cryptography key encapsulations with authentication and forward secrecy |
US11610004B2 (en) | 2021-04-14 | 2023-03-21 | Bank Of America Corporation | System for implementing enhanced file encryption technique |
US11349861B1 (en) | 2021-06-18 | 2022-05-31 | Extrahop Networks, Inc. | Identifying network entities based on beaconing activity |
US11296967B1 (en) | 2021-09-23 | 2022-04-05 | Extrahop Networks, Inc. | Combining passive network analysis and active probing |
US11843606B2 (en) | 2022-03-30 | 2023-12-12 | Extrahop Networks, Inc. | Detecting abnormal data access based on data similarity |
FR3140503A1 (en) * | 2022-09-29 | 2024-04-05 | Orange | Methods for proving and verifying the use of a cipher suite, verification entity, communication devices, terminal, and associated computer program |
Citations (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5241599A (en) * | 1991-10-02 | 1993-08-31 | At&T Bell Laboratories | Cryptographic protocol for secure communications |
US5351293A (en) * | 1993-02-01 | 1994-09-27 | Wave Systems Corp. | System method and apparatus for authenticating an encrypted signal |
US5371796A (en) * | 1992-06-02 | 1994-12-06 | Racal-Datacom | Data communication system |
US5689563A (en) * | 1993-06-29 | 1997-11-18 | Motorola, Inc. | Method and apparatus for efficient real-time authentication and encryption in a communication system |
US5825890A (en) * | 1995-08-25 | 1998-10-20 | Netscape Communications Corporation | Secure socket layer application program apparatus and method |
US5953420A (en) * | 1996-10-25 | 1999-09-14 | International Business Machines Corporation | Method and apparatus for establishing an authenticated shared secret value between a pair of users |
US5953424A (en) * | 1997-03-18 | 1999-09-14 | Hitachi Data Systems Corporation | Cryptographic system and protocol for establishing secure authenticated remote access |
US6009177A (en) * | 1994-01-13 | 1999-12-28 | Certco Llc | Enhanced cryptographic system and method with key escrow feature |
US6009173A (en) * | 1997-01-31 | 1999-12-28 | Motorola, Inc. | Encryption and decryption method and apparatus |
US6061796A (en) * | 1997-08-26 | 2000-05-09 | V-One Corporation | Multi-access virtual private network |
US6085320A (en) * | 1996-05-15 | 2000-07-04 | Rsa Security Inc. | Client/server protocol for proving authenticity |
US6088805A (en) * | 1998-02-13 | 2000-07-11 | International Business Machines Corporation | Systems, methods and computer program products for authenticating client requests with client certificate information |
US6094485A (en) * | 1997-09-18 | 2000-07-25 | Netscape Communications Corporation | SSL step-up |
US6134327A (en) * | 1997-10-24 | 2000-10-17 | Entrust Technologies Ltd. | Method and apparatus for creating communities of trust in a secure communication system |
US6148404A (en) * | 1997-05-28 | 2000-11-14 | Nihon Unisys, Ltd. | Authentication system using authentication information valid one-time |
US6173400B1 (en) * | 1998-07-31 | 2001-01-09 | Sun Microsystems, Inc. | Methods and systems for establishing a shared secret using an authentication token |
US6233341B1 (en) * | 1998-05-19 | 2001-05-15 | Visto Corporation | System and method for installing and using a temporary certificate at a remote site |
USRE37178E1 (en) * | 1992-11-03 | 2001-05-15 | Novell, Inc. | Method and apparatus for authentication of client server communication |
US6246771B1 (en) * | 1997-11-26 | 2001-06-12 | V-One Corporation | Session key recovery system and method |
US6285991B1 (en) * | 1996-12-13 | 2001-09-04 | Visa International Service Association | Secure interactive electronic account statement delivery system |
US6317829B1 (en) * | 1998-06-19 | 2001-11-13 | Entrust Technologies Limited | Public key cryptography based security system to facilitate secure roaming of users |
US20010042051A1 (en) * | 1998-06-26 | 2001-11-15 | Jeremey L. Barrett | Network transaction system for minimizing software requirements on client computers |
US20020157019A1 (en) * | 2001-04-19 | 2002-10-24 | Kadyk Donald J. | Negotiating secure connections through a proxy server |
US20030041244A1 (en) * | 2000-04-28 | 2003-02-27 | Levente Buttyan | Method for securing communications between a terminal and an additional user equipment |
US6535980B1 (en) * | 1999-06-21 | 2003-03-18 | International Business Machines Corporation | Keyless encryption of messages using challenge response |
US6550011B1 (en) * | 1998-08-05 | 2003-04-15 | Hewlett Packard Development Company, L.P. | Media content protection utilizing public key cryptography |
US6633979B1 (en) * | 1999-06-25 | 2003-10-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and arrangements for secure linking of entity authentication and ciphering key generation |
US6718467B1 (en) * | 1999-10-28 | 2004-04-06 | Cisco Technology, Inc. | Password based protocol for secure communications |
US6769060B1 (en) * | 2000-10-25 | 2004-07-27 | Ericsson Inc. | Method of bilateral identity authentication |
US6823454B1 (en) * | 1999-11-08 | 2004-11-23 | International Business Machines Corporation | Using device certificates to authenticate servers before automatic address assignment |
US6874084B1 (en) * | 2000-05-02 | 2005-03-29 | International Business Machines Corporation | Method and apparatus for establishing a secure communication connection between a java application and secure server |
US6895507B1 (en) * | 1999-07-02 | 2005-05-17 | Time Certain, Llc | Method and system for determining and maintaining trust in digital data files with certifiable time |
US6953424B2 (en) * | 2002-07-31 | 2005-10-11 | Hitachi Koki Co., Ltd. | Rotor driving apparatus with temperature adjustment of elastic supporting portion |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5602918A (en) * | 1995-12-22 | 1997-02-11 | Virtual Open Network Environment Corp. | Application level security system and method |
US5784463A (en) * | 1996-12-04 | 1998-07-21 | V-One Corporation | Token distribution, registration, and dynamic configuration of user entitlement for an application level security system and method |
US7047409B1 (en) * | 2000-06-09 | 2006-05-16 | Northrop Grumman Corporation | Automated tracking of certificate pedigree |
AU2001271704A1 (en) * | 2000-06-29 | 2002-01-14 | Cachestream Corporation | Digital rights management |
JP2002288375A (en) * | 2001-03-26 | 2002-10-04 | Sanyo Electric Co Ltd | Contents providing device and contents providing method and license server |
-
2002
- 2002-04-30 CA CA2446304A patent/CA2446304C/en not_active Expired - Fee Related
- 2002-04-30 WO PCT/US2002/013521 patent/WO2002091662A1/en active IP Right Grant
- 2002-04-30 EP EP02729059.2A patent/EP1391073B8/en not_active Expired - Lifetime
- 2002-04-30 US US10/135,163 patent/US7975139B2/en not_active Expired - Fee Related
-
2011
- 2011-05-27 US US13/117,656 patent/US20110231650A1/en not_active Abandoned
Patent Citations (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5241599A (en) * | 1991-10-02 | 1993-08-31 | At&T Bell Laboratories | Cryptographic protocol for secure communications |
US5371796A (en) * | 1992-06-02 | 1994-12-06 | Racal-Datacom | Data communication system |
USRE37178E1 (en) * | 1992-11-03 | 2001-05-15 | Novell, Inc. | Method and apparatus for authentication of client server communication |
US5351293A (en) * | 1993-02-01 | 1994-09-27 | Wave Systems Corp. | System method and apparatus for authenticating an encrypted signal |
US5689563A (en) * | 1993-06-29 | 1997-11-18 | Motorola, Inc. | Method and apparatus for efficient real-time authentication and encryption in a communication system |
US6009177A (en) * | 1994-01-13 | 1999-12-28 | Certco Llc | Enhanced cryptographic system and method with key escrow feature |
US5825890A (en) * | 1995-08-25 | 1998-10-20 | Netscape Communications Corporation | Secure socket layer application program apparatus and method |
US6189098B1 (en) * | 1996-05-15 | 2001-02-13 | Rsa Security Inc. | Client/server protocol for proving authenticity |
US6085320A (en) * | 1996-05-15 | 2000-07-04 | Rsa Security Inc. | Client/server protocol for proving authenticity |
US5953420A (en) * | 1996-10-25 | 1999-09-14 | International Business Machines Corporation | Method and apparatus for establishing an authenticated shared secret value between a pair of users |
US6285991B1 (en) * | 1996-12-13 | 2001-09-04 | Visa International Service Association | Secure interactive electronic account statement delivery system |
US6009173A (en) * | 1997-01-31 | 1999-12-28 | Motorola, Inc. | Encryption and decryption method and apparatus |
US5953424A (en) * | 1997-03-18 | 1999-09-14 | Hitachi Data Systems Corporation | Cryptographic system and protocol for establishing secure authenticated remote access |
US6148404A (en) * | 1997-05-28 | 2000-11-14 | Nihon Unisys, Ltd. | Authentication system using authentication information valid one-time |
US6061796A (en) * | 1997-08-26 | 2000-05-09 | V-One Corporation | Multi-access virtual private network |
US6094485A (en) * | 1997-09-18 | 2000-07-25 | Netscape Communications Corporation | SSL step-up |
US6134327A (en) * | 1997-10-24 | 2000-10-17 | Entrust Technologies Ltd. | Method and apparatus for creating communities of trust in a secure communication system |
US6246771B1 (en) * | 1997-11-26 | 2001-06-12 | V-One Corporation | Session key recovery system and method |
US6088805A (en) * | 1998-02-13 | 2000-07-11 | International Business Machines Corporation | Systems, methods and computer program products for authenticating client requests with client certificate information |
US6233341B1 (en) * | 1998-05-19 | 2001-05-15 | Visto Corporation | System and method for installing and using a temporary certificate at a remote site |
US6317829B1 (en) * | 1998-06-19 | 2001-11-13 | Entrust Technologies Limited | Public key cryptography based security system to facilitate secure roaming of users |
US20010042051A1 (en) * | 1998-06-26 | 2001-11-15 | Jeremey L. Barrett | Network transaction system for minimizing software requirements on client computers |
US6173400B1 (en) * | 1998-07-31 | 2001-01-09 | Sun Microsystems, Inc. | Methods and systems for establishing a shared secret using an authentication token |
US6550011B1 (en) * | 1998-08-05 | 2003-04-15 | Hewlett Packard Development Company, L.P. | Media content protection utilizing public key cryptography |
US6535980B1 (en) * | 1999-06-21 | 2003-03-18 | International Business Machines Corporation | Keyless encryption of messages using challenge response |
US6633979B1 (en) * | 1999-06-25 | 2003-10-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and arrangements for secure linking of entity authentication and ciphering key generation |
US6895507B1 (en) * | 1999-07-02 | 2005-05-17 | Time Certain, Llc | Method and system for determining and maintaining trust in digital data files with certifiable time |
US6718467B1 (en) * | 1999-10-28 | 2004-04-06 | Cisco Technology, Inc. | Password based protocol for secure communications |
US6823454B1 (en) * | 1999-11-08 | 2004-11-23 | International Business Machines Corporation | Using device certificates to authenticate servers before automatic address assignment |
US20030041244A1 (en) * | 2000-04-28 | 2003-02-27 | Levente Buttyan | Method for securing communications between a terminal and an additional user equipment |
US6874084B1 (en) * | 2000-05-02 | 2005-03-29 | International Business Machines Corporation | Method and apparatus for establishing a secure communication connection between a java application and secure server |
US6769060B1 (en) * | 2000-10-25 | 2004-07-27 | Ericsson Inc. | Method of bilateral identity authentication |
US20020157019A1 (en) * | 2001-04-19 | 2002-10-24 | Kadyk Donald J. | Negotiating secure connections through a proxy server |
US6953424B2 (en) * | 2002-07-31 | 2005-10-11 | Hitachi Koki Co., Ltd. | Rotor driving apparatus with temperature adjustment of elastic supporting portion |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9563757B1 (en) * | 2005-04-06 | 2017-02-07 | Assa Abloy Ab | Secure digital credential sharing arrangement |
US20110078776A1 (en) * | 2005-04-06 | 2011-03-31 | John Jules Alexander Boyer | Secure digital credential sharing arrangement |
US10027707B2 (en) * | 2005-09-19 | 2018-07-17 | Jpmorgan Chase Bank, N.A. | System and method for anti-phishing authentication |
US8583926B1 (en) * | 2005-09-19 | 2013-11-12 | Jpmorgan Chase Bank, N.A. | System and method for anti-phishing authentication |
US20170279851A1 (en) * | 2005-09-19 | 2017-09-28 | Jpmorgan Chase Bank, N.A. | System and Method for Anti-Phishing Authentication |
US9374366B1 (en) * | 2005-09-19 | 2016-06-21 | Jpmorgan Chase Bank, N.A. | System and method for anti-phishing authentication |
US9661021B2 (en) * | 2005-09-19 | 2017-05-23 | Jpmorgan Chase Bank, N.A. | System and method for anti-phishing authentication |
US20160261630A1 (en) * | 2005-09-19 | 2016-09-08 | Jpmorgan Chase Bank, N.A. | System and Method for Anti-Phishing Authentication |
US20140040991A1 (en) * | 2011-01-05 | 2014-02-06 | Gelmalto Sa | Method for communicating between a server and a client and corresponding client, server and system |
US9742745B2 (en) * | 2011-01-05 | 2017-08-22 | Gemalto Sa | Method for communicating between a server and a client and corresponding client, server and system wherein the server controls an open communication session with the client |
CN102811224A (en) * | 2012-08-02 | 2012-12-05 | 天津赢达信科技有限公司 | Method, device and system for implementation of SSL (secure socket layer)/TLS (transport layer security) connection |
US9024730B2 (en) * | 2012-09-04 | 2015-05-05 | Honeywell International Inc. | Standby activation |
US20140062670A1 (en) * | 2012-09-04 | 2014-03-06 | Honeywell International Inc. | Standby activation |
WO2014142901A1 (en) * | 2013-03-14 | 2014-09-18 | Mcafee, Inc. | Decryption of data between a client and a server |
US10079838B2 (en) | 2013-03-14 | 2018-09-18 | Mcafee, Llc | Decryption of data between a client and a server |
WO2014200496A1 (en) * | 2013-06-13 | 2014-12-18 | Intel Corporation | Secure pairing for communication across devices |
US9559851B2 (en) | 2013-06-13 | 2017-01-31 | Intel Corporation | Secure pairing for secure communication across devices |
WO2015026336A1 (en) * | 2013-08-21 | 2015-02-26 | Intel Corporation | Processing data privately in the cloud |
US9521126B2 (en) * | 2013-08-21 | 2016-12-13 | Intel Corporation | Processing data privately in the cloud |
US20150188896A1 (en) * | 2013-12-27 | 2015-07-02 | Canon U.S.A., Inc. | Method for associating an image-forming device, a mobile device, and a user |
US9240982B2 (en) * | 2013-12-27 | 2016-01-19 | Canon Information And Imaging Solutions, Inc. | Method for associating an image-forming device, a mobile device, and a user |
US9391771B2 (en) | 2014-02-06 | 2016-07-12 | Empire Technology Development Llc | Server-client secret generation with cached data |
WO2015119610A1 (en) * | 2014-02-06 | 2015-08-13 | Empire Technology Development, Llc | Server-client secret generation with cached data |
US20180227125A1 (en) * | 2015-08-07 | 2018-08-09 | Atf Cyber, Inc. | Multi-use long string anti-tampering authentication system |
EP3499794A4 (en) * | 2016-08-08 | 2020-02-26 | NTI, Inc. | Ssl communication system, client, server, ssl communication method, and computer program |
US11005658B2 (en) * | 2017-12-13 | 2021-05-11 | Delta Electronics, Inc. | Data transmission system with security mechanism and method thereof |
CN111406390A (en) * | 2018-12-26 | 2020-07-10 | 深圳市大疆创新科技有限公司 | Encrypted communication method, device, system and computer storage medium |
KR102145679B1 (en) * | 2019-01-09 | 2020-08-18 | 주식회사 엘지유플러스 | Method for evading mitm attack for https protocol |
KR20200086436A (en) * | 2019-01-09 | 2020-07-17 | 주식회사 엘지유플러스 | Method for evading mitm attack for https protocol |
CN111865924A (en) * | 2020-06-24 | 2020-10-30 | 新浪网技术(中国)有限公司 | Method and system for monitoring user side |
Also Published As
Publication number | Publication date |
---|---|
CA2446304C (en) | 2012-03-20 |
CA2446304A1 (en) | 2002-11-14 |
WO2002091662A8 (en) | 2003-08-14 |
WO2002091662A1 (en) | 2002-11-14 |
EP1391073B1 (en) | 2018-07-25 |
EP1391073A4 (en) | 2009-08-26 |
EP1391073A1 (en) | 2004-02-25 |
US7975139B2 (en) | 2011-07-05 |
EP1391073B8 (en) | 2018-09-05 |
US20020166048A1 (en) | 2002-11-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7975139B2 (en) | Use and generation of a session key in a secure socket layer connection | |
CN109728909B (en) | Identity authentication method and system based on USBKey | |
US9819666B2 (en) | Pass-thru for client authentication | |
US6189098B1 (en) | Client/server protocol for proving authenticity | |
US6732270B1 (en) | Method to authenticate a network access server to an authentication server | |
US7607012B2 (en) | Method for securing a communication | |
US8132020B2 (en) | System and method for user authentication with exposed and hidden keys | |
US7840993B2 (en) | Protecting one-time-passwords against man-in-the-middle attacks | |
EP1697818B1 (en) | Authentication system for networked computer applications | |
US20090210712A1 (en) | Method for server-side detection of man-in-the-middle attacks | |
US20030115452A1 (en) | One time password entry to access multiple network sites | |
US20080134311A1 (en) | Authentication delegation based on re-verification of cryptographic evidence | |
US20110179478A1 (en) | Method for secure transmission of sensitive data utilizing network communications and for one time passcode and multi-factor authentication | |
WO1998025375A1 (en) | Token distribution and registration system and method | |
EP1079565A2 (en) | Method of securely establishing a secure communication link via an unsecured communication network | |
EP1623551B1 (en) | Network security method and system | |
CN114666114A (en) | Mobile cloud data security authentication method based on biological characteristics | |
Chatterjee et al. | A novel multi-server authentication scheme for e-commerce applications using smart card | |
AU2002259074B2 (en) | Use and generation of a session key in a secure socket layer connection | |
Godfrey | A Comparison of Security Protocols in a Wireless Network Environment | |
AU2002259074A1 (en) | Use and generation of a session key in a secure socket layer connection | |
CN117527421A (en) | Method for realizing HTTP protocol safety transmission | |
CN116319051A (en) | Heterogeneous network secure communication authentication method based on alliance chain | |
Kshemkalyani et al. | Authentication in Distributed System | |
KADIRIRE | ONLINE TRANSACTIONS’SECURITY |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |