Authentication using a decentralized and/or hybrid decentralized secure cryptographic key storage method

Abstract

Mutual dependency between two devices is established by creating mutual dependency tokens containing stateful information to be stored on the issuing device and the client device. The tokens can be used for both web/application-level authentication and network-level authentication. Tokens for IP or MAC addresses can be created and stored in a modified route table, allowing for the creation of private virtual subnets.

What is claimed is: 
     
       1. A method of creating mutual dependency between a first network-enabled device and a second network-enabled device, comprising:
 using a store key to encrypt a secret; 
 creating a hash of the store key using a cryptographic hash algorithm; 
 using an unlock key to encrypt the store key; 
 using a naked key to encrypt the unlock key; 
 storing the naked key and encrypted store key in an issuer token in the first network-enabled device; 
 storing the encrypted unlock key in a client token in the second network-enabled device; 
 storing the encrypted secret in either the issuer token, the client token, or both; 
 storing the hash of the store key in in either the issuer token, the client token, or both; and 
 providing the client token to the first network-enabled device for authentication. 
 
     
     
       2. A method of authenticating a connection between an issuer and a client, comprising:
 using a store key to encrypt a secret; 
 creating a hash of the store key using a cryptographic hash algorithm; 
 using an unlock key to encrypt the store key; 
 using a naked key to encrypt the unlock key; 
 storing the naked key and encrypted store key in an issuer token; 
 storing the encrypted unlock key in a client token; 
 storing the encrypted secret in either the issuer token, the client token, or both; and 
 storing the hash of the store key in in either the issuer token, the client token, or both; 
 using the naked key in the issuer token to decrypt the encrypted unlock key in the client token; 
 decrypting the encrypted store key in the issuer token using the decrypted unlock key in the client token to create plain text; 
 hashing the decrypted store key using the cryptographic hash algorithm; and 
 comparing the hash of the decrypted store key to the original store key hash; and 
 authenticating the connection if the hashes match. 
 
     
     
       3. The method of  claim 2 , wherein:
 the client token is stored on a web browser and includes client metadata; and 
 the issuer token is stored in a data store associated with a web server or application and includes issuer metadata. 
 
     
     
       4. The method of  claim 3 , further comprising:
 generating a public key pair including a public key and a private key; 
 storing the public key in both the client metadata and the issuer metadata; 
 storing the private key in the issuer secret; and 
 storing a unique subnet id both client metadata and the issuer metadata. 
 
     
     
       5. The method of  claim 3 , wherein the webserver is configured to invalidate the tokens by storing an expiration date or a flag in the metadata of the issuer token, or by deleting the token from the data store.