Decentralized system for securely resolving domain names

Patent metadata

Field	Value
Publication number	US-11757652-B2
Application number	US-202017032157-A
Country	US
Kind code	B2
Filing date	Sep 25, 2020
Priority date	Sep 25, 2020
Publication date	Sep 12, 2023
Grant date	Sep 12, 2023

Abstract

A decentralized system for securely registering, updating, and/or resolving domain names in a distributed ledger is disclosed. The distributed ledger may comprise a smart contract that includes a look-up table that maps network names to network addresses and/or one or more keys. The smart contract may verify whether any updates and/or changes made to an entry in the look-up table are cryptographically authorized. Additionally, the smart contract may enforce any additional policies implemented by a domain administrator for authenticating changes and/or updates to a domain name entry. The unique combination of storing domain information in a decentralized ledger and validating changes and/or updates to the domain information provides a decentralized root of trust that allows for secure queries of network names (e.g., domain name) for secure cross-entity communications.

First claim

What is claimed is:

1. A method comprising:
receiving, by a computing device from a user device, a request comprising a domain name to create a new federated network;
generating a domain name entry corresponding to the requested domain name for the new federated network;
defining one or more policies for updating the domain name entry;
sending, by the computing device, an indication that the new federated network has been created in association with the requested domain name;
storing the domain name entry in a distributed ledger;
generating, using a private domain key, a signature associated with a query of the distributed ledger, wherein the query obtains a network address of the new federated network; and
establishing, based on the signature and the network address obtained from the query of the distributed ledger, a secure communication channel between a first server of the new federated network and a second server associated with another federated network.

2. The method of claim 1 , wherein the request to create the new federated network comprises at least one of:
a domain name;
record data;
a first signature; or
a second signature.

3. The method of claim 2 , further comprising:
verifying at least one of the first signature and the second signature prior to generating the domain name entry.

4. The method of claim 1 , wherein the new federated network comprises a communication network that supports a secure collaboration application that allows users to communicate via at least one of: messaging, group chats, voice calls, or video calls.

5. The method of claim 1 , wherein the domain name entry comprises an indication of an authentication technique for updating the domain name entry, wherein the authentication technique is enforced by a smart contract associated with the domain name entry.

6. The method of claim 1 , wherein the one or more policies comprise at least one of:
one or more network addresses that are permitted to modify the domain name entry;
a domain password for updating the domain name entry; or
requiring verbal confirmation before allowing the domain name entry to be modified.

7. The method of claim 1 , further comprising:
receiving a second request to modify the domain name entry associated with the federated network;
authenticating the second request to modify the domain name entry; and
modifying the domain name entry.

8. The method of claim 7 , wherein authenticating the second request to modify the domain name entry comprises:
verifying, using a public domain key associated with the federated network, a signature of the second request.

9. The method of claim 7 , wherein authenticating the second request to modify the domain name entry comprises:
verifying at least one of a first signature of the second request generated using a public domain key associated with the federated network or a second signature of the second request generated using a root public key associated with an administrator.

10. The method of claim 7 , wherein authenticating the second request to modify the domain name entry comprises:
verifying a first signature of the second request generated using a public domain key associated with the federated network; and
verifying a second signature of the second request generated using a root public key associated with an administrator.

11. The method of claim 1 , wherein the distributed ledger comprises a blockchain.

12. A method comprising:
receiving, by a first server associated with a first federated network and from a first user device, a first encrypted communication intended for a second user device associated with a second federated network, wherein the encrypted communication comprises a domain name of the second federated network;
generating, using a private domain key, a signature associated with the domain name of the second federated network;
querying a look-up table stored in a distributed ledger, using the domain name of the second federated network, to resolve a network address of the domain name;
obtaining a response from the look-up table, wherein the response comprises a network address of the domain name;
based on the signature and the obtained network address of the domain name, establishing a secure communication channel between the first server and a second server associated with the second federated network; and
sending, from the second server to the first server via the secure communication channel, the encrypted communication.

13. The method of claim 12 , wherein the response further comprises a public key of the second federated network.

14. The method of claim 12 , wherein the network address comprises an internet protocol address.

15. The method of claim 12 , wherein the secure communication channel comprises a channel secured via Transport Layer Security (TLS).

16. A method comprising:
receiving, by a second server associated with a second federated network and from a first server associated with a first federated network, a request comprising a domain name of the first federated network to establish a secure communication channel;
generating, using a private domain key, a signature associated with the domain name of the first federated network;
based on the signature, querying a look-up table stored in a distributed ledger, using the domain name of the first federated network, to obtain a network address of the first federated network and a public key retrieved from a domain name entry of the look-up table, the public key being associated with the first federated network;
responsive to obtaining the network address based on the domain name, establishing, using the public key associated with the first federated network, the secure communication channel between the first server and the second server; and
receiving, by the second server from the first server, an encrypted communication intended for a second user device associated with the second federated network.

17. The method of claim 16 , further comprising:
sending the encrypted communication to the second device.

18. The method of claim 17 , further comprising:
receiving, based on the querying the look-up table, a certificate, wherein the certificate comprises the public key associated with the first federated network.

19. The method of claim 16 , wherein the establishing the secure communication channel between the first server and the second server further comprises using a second public key associated with the second federated network.

Assignees

• Wickr Inc

Inventors

• Alwen Joël
• Leavy Thomas Michael
• Howell Christopher A

Classifications

• H04L61/45 Primary

  Network directories; Name-to-address mapping · CPC title

• H04L9/3247 Primary

  involving digital signatures · CPC title

• H04L61/3025

  Domain name generation or assignment · CPC title

• H04L9/50

  using hash chains, e.g. blockchains or hash trees · CPC title

• H04L9/088

  Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms (network architectures or network communication protocols for using time-dependent keys in a packet data network H04L63/068) · CPC title