Method and system for asymmetric key security

Exemplary embodiments disclosed herein may include a method and system for creating pair-wise security keys, comprising receiving an identity key from a website, generating a master key, creating a pair-wise symmetric key or asymmetric key pair by utilizing an encryption function of the identity key and the master key, and storing the pair-wise public or symmetric key at the client and the website.

TECHNICAL FIELD

The invention relates generally to the field of electronic security, such as computer and network security. More particularly, the invention relates to authenticating the identity of computer systems and users.

BACKGROUND

Typical electronic security may utilize public key/private key systems to authenticate parties accessing resources over networks such as the Internet. These public key/private key systems operate with one public key that is constant and utilized for many different resources such as websites, and one private key that is accessible by only the originator, such as a client computer accessing the resources. This electronic security key system has significant disadvantages, including that the fixed key identifying the originator may be utilized by the many different websites to obtain much information about the originator and their habits, references, etc. This may be accomplished by the various website operators matching public keys, and exchanging information corresponding to the matched public keys. Furthermore, operators of websites may exchange information about an originator freely on an ongoing basis once the public keys are matched, to obtain more information about a user's habits, etc.

SUMMARY

Exemplary embodiments disclosed herein may include a method and system for alleviating the disadvantages noted above, as well as others. Exemplary embodiments disclosed herein involve a method and system for creating asymmetric key pair(s) comprising generating a master key, receiving an identity key from a server, creating a seed by utilizing an encryption or hashing function of the identity key, the master key, and a constant(s), and using this seed as the input to a process which creates a key or key pair. In an exemplary embodiment disclosed herein, the seed is used to create an asymmetric key pair, and the resulting public asymmetric key is stored at the server.

Other embodiments involve a system and method for authenticating a website and/or server or user system comprising, producing the public asymmetric key on a client computer, determining if that public asymmetric key matches a corresponding asymmetric key available on the server, and authenticating the server and/or client if the asymmetric key is matched.

Yet other embodiments involve a system and method for authenticating a website and/or server or user system comprising, generating a master key, receiving an identity key from a server, creating a seed by utilizing an encryption function of the identity key, the master key, and a constant(s), and using this seed as the input to a process which creates a safe symmetric key, and determining if that symmetric key matches a corresponding symmetric key available on the server by initiating a symmetric authentication process between the server and client.

Exemplary embodiments disclosed herein may be implemented as a computer process, a computing system or as an article of manufacture such as a computer program product. The computer program product may be a computer storage medium readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process.

A more complete appreciation of the present disclosure and its improvements can be obtained by reference to the accompanying drawings, which are briefly summarized below, and to the following detailed description of presently preferred embodiments of the invention, and to the appended claims.

DETAILED DESCRIPTION

FIG. 1is a block diagram of a system, which may be utilized for creating an asymmetrical key pair(s) and authenticating identification according to an exemplary embodiment, generally at100. In this embodiment, system100has clients102,104. Clients102,104are connected to a network112, which, in turn is connected to Server1106, Server2108, and Server3110. Network112may be the Internet, or other communication channel, which may be utilized to communicate between clients102and104and servers106,108,110. Those skilled in the art will appreciate that system100is merely an exemplary communication system with clients and servers, and that many alternative and different configurations may be utilized.

In this embodiment, clients102and104have key creation modules114and115, respectively. Key creation modules114and115are capable of creating a symmetrical key(s) and/or an asymmetrical key pair(s).

In an exemplary embodiment involving asymmetrical keys, the asymmetrical key pair(s) are unique values calculated based on known inputs such that their value can be reproduced by repeating the same function with the same input values. The fixed identification keys of the servers and/or the public keys generated by the key creation modules on the clients are then used to do mutual authentication That is, the client can validate the server and vice versa.

The clients102and104request and send information to the servers106,108,110. Likewise, the servers106,108,110receive requests for information and attempt to respond. Moreover, the servers may themselves request information from the clients. At times, sensitive information is sent to the servers. In order to protect the servers and the clients, system100incorporates symmetrical or asymmetrical key security. Using these security features, client systems are relatively protected from improper server techniques trying to steal information.

Client102may request an identification key116that is associated with Server1106. Client102may then create a master key and utilize identity key116, the master key, and a constant(s) to create an asymmetrical key pair, which includes an asymmetric public key (APK)1120, utilizing key creation module114. Asymmetric public key1120may then be stored on server1106, and a corresponding private asymmetrical key may be stored at client102, such that when client102again visits server1106, and/or a user of client102visits server1106again, it may request proof of knowledge of the asymmetric public key1120such that it may determine if it has previously accessed server1106. This embodiment may also be utilized to determine the authenticity of server1106and/or an associated web site via the asymmetric public key1120. Furthermore, client102may discard the private asymmetric key, later recreating the asymmetric key pair and presenting the asymmetric public key when accessing the server again to prove to the server that an ongoing digital relationship exists.

Client102may present a recreated asymmetric public key when accessing Server1106again to validate the client102to Server1106. Both the client102and server1106may require further assurances from the other to validate identity. These further assurances may be in a form such that only a holder of either the public or private key from the pair may decrypt, understand, and/or be able to respond.

When using asymmetric key mechanisms, since client102generates a different key pair for each server106,108and110, and communicates the public key using an encrypted channel, it may be enough to only present proof of knowledge of the asymmetric public key to validate identity. This means the asymmetric public key may function as a symmetric key when this is convenient. In other cases the server may elect to require proof of possession of the associated private key.

Similarly, another client104may also access server1106and request server1ID key116. Server1ID key116also may be obtained by requesting a certificate, or security certificate from a third party, and parsing the certificate to obtain the identity key, or other identity information. It will be appreciated that other methods and systems for obtaining an identity key and/or security certificate may be utilized without straying from the concepts disclosed herein. Similarly, client104may also create an asymmetric public key (APK)2122utilizing ID key116, a different master key, and optionally a constant(s). Client2104may then associate asymmetric public key2122with server1106. Client104may then save a corresponding private asymmetric key, or discard it and recreate the key pair when subsequently accessing the server.

Asymmetrical public key2122may be created by a key creation module114associated with client104. Similarly to the method described previously, when client104subsequently accesses server1106it may request proof of knowledge of asymmetric public key2122such that it may determine if it has previously accessed server1106and/or provided some identity information to server1106. Similarly, client104may recreate and demonstrate proof of knowledge of asymmetric public key2122to server1106to authenticate the identity of the client104, or may require proof of possession of the associated private key.

Furthermore, client1102may access server2108and request server2ID key118. After receiving ID key118client102may then utilize ID key118and another, or the same, master key, and a constant(s) to create symmetric key3(SK)124(in this case the seed is fed into a module generating a symmetric key rather than an asymmetric key pair). The symmetric key is then communicated to server2108using an encrypted channel.

Client102may then request proof of knowledge of symmetric key3124when accessing server2108again. Similarly, the server can require proof of knowledge of the key by the client. Only the user would have the master key, etc. used to create the symmetric key. Client102may store different symmetric keys at each and every web site and/or server visited, and may be able to request proof of knowledge of those keys to determine if the server has been previously accessed. Furthermore, symmetrical keys may be utilized to authenticate a server, client, and/or web site as only the particular client or user that stored the symmetric key at the server will be able to pass the required mutual authentication.

Similarly, client104may access server3110and request server3identification key120. Client104may then utilize key creation module114to generate a random master key that will be utilized along with server3ID key120and optionally a constant to create asymmetric public key (APK)4126which may then be stored at, or associated with, server3110. Then client104may also encrypt the asymmetric key pair under a symmetric key such as one derived from a master key, server3identification key and some constant, storing this symmetric key made utilizing the asymmetric key pair as seed (SKAK)127on server3in association with asymmetric public key APK4126and the associated identity of the server. Because the symmetric key utilizing asymmetric keys127is encrypted, only client104will be able to decrypt it, or utilize the information to retrieve the asymmetric key pair. Therefore, the symmetric key utilizing asymmetric keys127may be utilized by client104to determine if client104has previously accessed server3110. Furthermore, this configuration may be utilized to authenticate a website and/or server, as only a previously visited server would have an associated the symmetric key utilizing asymmetric keys from a particular client. Yet further, a client capable of decrypting the symmetric key utilizing asymmetric keys when visiting a server may utilize the asymmetric public key to authenticate their own identity to the server.

As described above, dishonest people may try to trick a client, and/or a user of a client, into providing personal information. Unidentified rogue130may try to copy or look like a legitimate server and/or web site to obtain identity and/or other information from a client102,104. With the exemplary embodiments disclosed herein, when the client requests an identity key, unidentified rogue ID key132will be provided to the client and, thus, the client may discern that it is not a server previously visited. Furthermore, when the client requests an asymmetric public key, unidentified rogue will have no an asymmetric public key(s) (APK)134as the client and/or user has not previously accessed the website of the unidentified rogue. Either of these scenarios would alert a user of a client102,104that the web site and/or server is not to be trusted, and the user should be wary of disclosing identity or other information.

Similarly, if unidentified rogue130tries to access any of the servers to obtain identity information of a client, the unidentified rogue130will not be able to demonstrate knowledge of symmetric or asymmetric key required to pose as client or server.

With this exemplary embodiment a server, user and/or client may have another level or two of security that may inhibit unidentified rogues from obtaining personal information by spoofing a web site. Furthermore, this may also inhibit the “man in the middle” interception of information to provide further security.

Since the site-specific asymmetrical public keys or symmetric keys are stored at the servers and/or web sites, a user may take their master key to many different clients and access web sites, and still be somewhat secure in the fact that they are dealing with an authentic web site. Again, they may utilize the server identification key along with their master key(s), and constant(s) to request proof of knowledge of the site's symmetric or public asymmetric keys; or they may request and decrypt the opaque key blob saved at, or associated with, the web site to determine if they have previously visited the server and/or web site. This may also be attractive to users who use multiple machines at home, work, the library, etc. in that they may have much greater comfort in dealing with web sites. It is a significant and central characteristic of this system that the master key needs only to be transported to a new device or computer on one occasion. From it, all site-specific keys and proofs of an ongoing digital relationship can be deduced. This eliminates the need for ongoing resynchronization.

This may be attractive to servers and operators of websites, who may be concerned about fraud. This may provide an extra level of user-generated security that may inhibit unidentified users obtaining confidential information.

FIG. 2illustrates an example of a suitable computing system environment on which embodiments of the invention may be implemented. This system200is representative of one that may be used to serve as a client and/or a server as described above. In its most basic configuration, system200typically includes at least one processing unit202and memory204. Depending on the exact configuration and type of computing device, memory204may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. This most basic configuration is illustrated inFIG. 2by dashed line206. Additionally, system200may also have additional features/functionality. For example, device200may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated inFIG. 2by removable storage208and non-removable storage210. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory204, removable storage208and non-removable storage210are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by system200. Any such computer storage media may be part of system200.

System200may also have input device(s)214such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s)216such as a display, speakers, printer, etc. may also be included. All these devices are well known in the art and need not be discussed at length here.

A computing device, such as system200, typically includes at least some form of computer-readable media. Computer readable media can be any available media that can be accessed by the system200. By way of example, and not limitation, computer-readable media might comprise computer storage media and communication media.

FIG. 3illustrates, at a conceptual level, a system for asymmetrical security key exchange according to an exemplary embodiment, generally at300. This example illustrates system300including a client301and a server306connected via a network314or other channel. As will become apparent, most devices can function as both a client301and a server306at various times. However, for simplicity, these functions are illustrated separately here. Additionally, network314may be almost any type of network including the Internet or may be some other type of channel suitable for establishing communication between the client301and the server306.

Client301may be a client, such as a personal PC accessing a website, or server306via the Internet. It will be appreciated, however, that other devices and configurations may be utilized without straying from the concepts disclosed herein. Similarly, the server306may be a host for a website, device, or other system, or other configuration.

The server306has an associated identity key307. Identity key307has information about the server, among other information. In an embodiment, the information relates to components of the URL, name of the principal owning or operating the system, and/or other “identity” information. When accessing the server306, the client301may request an identity key307, and/or the identity key307may be provided to the client301by the server or other entity. Although identity key307is shown here as residing or originating from server306, it will be appreciated that identity key307may reside or originate from another source, including but not limited to, a verification entity, among others.

In another exemplary embodiment, client301receives a certificate containing information about server306. The information contained within the certificate includes identity key307, or other identity information. Client301parses the certificate to access the identity key307. As described above the certificate may originate from the server, a verification entity, and/or other entity.

The identity information is then used by the client to create a unique asymmetric public key (or symmetric key)309that is stored at the server. The key309is a function of the identity information of the server, a master key generated by the client, and optionally a constant(s). The function may be such that the components utilized to create the function may not be discernable from the final product (i.e. encrypted).

Client301may previously have created a master key302. Master key302may be a randomly generated number and/or a variety of different types of information including, but not limited to, a time stamp, identity information and the like, or other information or combinations thereof. Client301may then utilize an encryption function of the combination of the master key302and the identity key307, and a constant(s) to create one or more seeds used to generate an asymmetric key pair including private key308, and public key309. Thus asymmetric keys308and309may be created for each server306and/or website visited. Alternately, the seed or seeds may be used to generate a symmetric key that can be communicated through an encrypted channel again shown as309.

The key309may then be stored on the server306. In the asymmetric case, the asymmetric private key may be stored at the client301or discarded and the keys recreated when subsequently accessing the server. When the client301accesses the server306again, the client301may request and/or receive proof of knowledge of the key309by server306and compare it to a recreated key on its own system to determine if the client301has previously accessed the server306. The server306may also utilize this method to determine if the client301has previously visited the server306, or in the asymmetric case may require the client to show proof of knowledge of the private key308.

This information may also be utilized to determine the authenticity of the server306, such that the client301and the principal using the client301may be more confidant that the server306and/or associated website are authentic and/or legitimate. This may reduce fraud, and increase user confidence before the user discloses identity information or other information to the server306, as well as many other benefits.

Proof of knowledge may include submitting a digital signature over some information employing a secret that can be verified and/or understood by an entity knowing the secret and/or having the seed(s) and the key. By requesting proof of knowledge of the key previously stored at the server, a user can identify the server/web site, and then can be more certain when disclosing information to the server. Exemplary embodiments may decrease the likelihood that an unidentified system312may try to obtain identity information from the client301by posing as a previously accessed server306. Furthermore, a server306may also utilize the asymmetric private key308to determine the authenticity of a client301trying to access the server306and/or changing or obtaining information about a specific client.

Once created, the asymmetric public key or symmetric key is stored on the web server, or in association with the website for which that key has been created. As a result, the user can revisit the site, and quickly verify/recognize the site through a challenge of the site to demonstrate knowledge of the key. Furthermore, since each system visited may be given a unique pair-wise key the operators of the different systems may not compare keys to collaborate and share information about the client or a user.

The encryption used for proof of knowledge may be an AES 256 function or may be based on a public key algorithm such as RSA, depending on the situation. However, it will be appreciated that other encryption algorithms, functions, and configurations may be utilized without straying from the concepts disclosed herein.

This information may also be utilized to determine the authenticity of the server306, such that the client301and the user of the client301may be more confident that the server306and/or associated websites and systems are authentic and/or legitimate. Among other benefits, this may reduce fraud, and increase user confidence before the user discloses identity information or other sensitive information to the server306. This authentication may provide consistent recognition of an ongoing digital relationship.

If the client301receives anything other than an expected proof of possession of the key309, this may indicate that the client301has not previously accessed this server306. This may also indicate that the legitimate site is being imitated, or that the server306has lost the key, among other scenarios. This may indicate to the user of the client301that the server306is not trustworthy, and that the user should disconnect from the server306, or proceed with caution and/or not divulge any sensitive, confidential, and/or identity information.

A further benefit of the embodiment shown inFIG. 3is that a user may access a website and/or a server306from many different clients with the original master key, and still have a level of assurance that the website is legitimate.

FIG. 4is a flowchart illustrating an exemplary embodiment of a method for creating pair-wise security keys according to an exemplary embodiment, generally at400. Method400includes receive operation402. Receive operation402includes receiving an identity key from a server or other entity. The identity key may include identity information about the server, including, but not limited to a unique URL, a principal owning the system, and/or other identification information. Furthermore, the identity key may be a portion of a certificate, such as a security certificate, or other certificate, that is associated with the server. The identity key may be parsed out of the certificate. Control then passes to generate operation404.

Generate operation404may include generating a master key. The master key may be a random number, identity information, or other unique information and/or combinations thereof. The master key may also have been previously generated and reused for different applications. It will be appreciated that the master key should be stored in a very secure place that will not allow an unauthorized person or entity to break in and view and/or steal the information. Control then passes to get operation406.

Get operation406includes getting a constant(s). The constant(s) may be a randomly created number, or other information, and/or combinations thereof. The constant(s) may only be known to the user who creates the constants, such that they may be reproduced at a later time, when needed. Control then passes to the create function408.

Create operation408may include creating seed as a function of the identity key, the master key, and a constant(s). It will be appreciated that other information and/or combinations of information may be utilized without straying from the concepts disclosed herein. The function may be a one-way encryption of the above information, such that the original information may not be determinable from the resultant seed. This function may be an AES encryption function or other encryption function or algorithm and/or combinations thereof. If a range of seeds needs to be produced, control may pass back to the get function406to get another constant to be utilized in creating another seed utilizing a different constant. The seed(s) may then be utilized by an asymmetric key pair generator to create an asymmetrical key pair(s), or by a symmetric key generating or validation function to create a symmetric key.

FIG. 5is a flow diagram illustrating further operational characteristics involved in creating an asymmetrical key pair(s) and recognizing an ongoing digital relationship according to an exemplary embodiment, generally at500.

Method500include receive function at502. Receive operation502includes receiving a previously created seed(s). Seed(s) are created as described above. Control then passes to the create function504.

Create function504includes creating an asymmetric key pair utilizing the received seed(s). One or more seed(s) may be utilized in the creation of the asymmetric key pair. The number of seed(s) used may depend on the particular type of asymmetric key pair generator used. Control then passes to the store function506.

Store operation506may include storing an asymmetric public key at the server and/or associating the asymmetric public key with the server or web site. The asymmetric public key is associated with the server such that it may be accessed by the client when the client accesses the server again. Furthermore, it may be accessed by the user from another system, such that a user may authenticate or recognize a system or website from many different devices or systems. The client may also recreate the asymmetric public key and present it when subsequently accessing the server again to validate the identification of the client. In this manner, the client may determine if the server has been previously accessed. Furthermore, this information may be utilized to determine the authenticity and/or legitimacy of the server and/or client.

FIG. 6is a flowchart illustrating a method for determining authenticity of a server, client, system, or web site according to an exemplary embodiment, generally at600. According to aspects of method600, processing begins with produce operation602. Produce operation602may include the user/client producing proof of knowledge of the asymmetric public key to the server for verification of the identity of the user/client. The production of the proof of knowledge of the asymmetric public key by the client and/or the server may constitute proof of an ongoing relationship. That is the client and server may have previously exchanged information. The client may also utilize a corresponding private asymmetric key to indicate a prior visit and/or exchange of information with the server. Furthermore, the client may demonstrate knowledge of an asymmetric public key by having stored the key pair or by recreating the asymmetric key pair utilizing the information used to originally create the asymmetric public key. Control then passes to query operation604.

Query operation604includes determining whether the asymmetric public key produced matches asymmetric public key saved and/or recreated and/or decrypted and/or previously stored by the client. Since the client may have saved a corresponding asymmetric public key, the asymmetric public key may be compared to determine if the server has been previously accessed. Furthermore, the client may utilize the identity key and the original master key, among other information to recreate the asymmetric public key to determine if the server has been previously accessed.

If the asymmetric public keys match, control passes to system authenticated606. This indicates that the client has previously accessed the server and stored and/or associated an asymmetric public key with the server. The system authenticated may be the server and/or the client. The client and/or server may optionally request further assurances of the identity of the other before authenticating the identity of the other. This may be to determine if an unidentified rogue has surreptitiously acquired a key. The further assurances may include sending a message or challenge to the other, which can only be decrypted and/or answered utilizing the corresponding key or information previously disclosed, among other information.

If the asymmetric public keys do not match, or an asymmetric public key is not produced, then a user is not authenticated608. After it is determined that a user is not authenticated608, control passes to the request function610. Request function610may include requesting an identity key from the server, or requesting for more information from the client by the server. If a client has previously accessed a server, or website, and this function is initiated, the user and/or server may have some indication that the website is not authentic or the client is not whom they purport to be. This may also indicate to the user or server that another entity is attempting to obtain identity information from the principal. This may also indicate that the server or client has lost the asymmetric public or private key, or the server or client has been tampered with. With any of these scenarios, the user of the client or the server may have an indication that this system is not to be trusted and caution should be used when any information is disclosed to the other.

The logical operations of the various embodiments of the exemplary embodiments may be implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. Accordingly, the logical operations making up the embodiments of the exemplary embodiments described herein are referred to variously as operations, structural devices, acts or modules. It will be recognized by one skilled in the art that these operations, structural devices, acts and modules may be implemented in software, in firmware, in special purpose digital logic, and/or any combination thereof without deviating from the spirit and scope of the present disclosure as recited within the claims attached hereto.

Although the exemplary embodiments have been described in language specific to computer structural features, methodological acts and by computer readable media, it is to be understood that the exemplary embodiments defined in the appended claims is not necessarily limited to the specific structures, acts or media described. As an example, different formats other than XML may be used to encode identification information. Therefore, the specific structural features, acts and mediums are disclosed as exemplary embodiments implementing the claimed invention.

The various embodiments described above are provided by way of illustration only and should not be construed to limit this disclosure. Those skilled in the art will readily recognize various modifications and changes that may be made to the present disclosure without following the exemplary embodiments and applications illustrated and described herein, and without departing from the true spirit and scope of the present disclosure, which is set forth in the following claims.