WO2020150880A1

WO2020150880A1 - Publicly verifiable compressed fingerprints and an application in securing domain name systems

Info

Publication number: WO2020150880A1
Application number: PCT/CN2019/072612
Authority: WO
Inventors: 荣兵蒋
Original assignee: 道里云信息技术(北京)有限公司
Priority date: 2019-01-22
Filing date: 2019-01-22
Publication date: 2020-07-30

Abstract

Aspects of the disclosure provide a method of securely transmitting information, including receiving, by a Domain Name System (DNS) asking device, a domain name query including a full domain name, and communicating, by the DNS asking device, with an authoritative DNS answering device. The communicating includes sending, by the DNS asking device, the query to the DNS answering device, generating, by the DNS answering device, an authoritative response including a binding record, digitally signing, by the DNS answering device, the authoritative response to output a unique fingerprint on the authoritative response to generate an authoritative signed response, sending, by the DNS answering device, the authoritative signed response to the DNS asking device, and publicly verifying, by the DNS asking device, the authoritative signed response using only the full domain name to deterministically derive a verification public key corresponding to a signing private key of the DNS answering device.

Description

PUBLICLY VERIFIABLE COMPRESSED FINGERPRINTS AND AN APPLICATION IN SECURING DOMAIN NAME SYSTEMS

BACKGROUND

1. Field of the Disclosure

At least one example in accordance with the present disclosure relates generally to cryptography.

2. Discussion of Related Art

The use of cryptographical methods to securely transmit information between two entities is known. A digital signature method generally includes two primary objectives. A first objective is to ensure that the data which is received by a receiving entity has not been altered or tampered with after being sent by a sending entity. A second objective is to ensure that the data which is received by a receiving entity was actually sent by a sending entity which purports to have sent the data.

SUMMARY

According to at least one aspect of the present disclosure, a method of securely transmitting information is provided, including receiving, by a Domain Name System (DNS) asking device, a full domain name query including a full domain name organized in a sequential order, and communicating, by the DNS asking device, with at least one DNS answering device including an authoritative DNS answering device associated with the full domain name, wherein the communicating includes sending, by the DNS asking device, the full domain name query to the authoritative DNS answering device, generating, by the authoritative DNS answering device, an authoritative response including a binding record between the full domain name and a corresponding resource, digitally signing, by the authoritative DNS answering device, the authoritative response to output a unique fingerprint on the authoritative response to generate an authoritative signed response, sending, by the authoritative DNS answering device, the authoritative signed response to the DNS asking device, and publicly verifying, by the DNS asking device, the authoritative signed response using only the full domain name to deterministically derive a verification public key corresponding to a signing private key of the authoritative DNS answering device.

In one example, the method further includes receiving, by the DNS asking device, the full domain name query from a client, and sending, by the DNS asking device, the binding record to the client responsive to determining that the binding record is stored locally and satisfies a validity criterion. In an example, the method further includes publicly verifying, by the client, the authoritative signed response using only the full domain name to deterministically derive the verification public key corresponding to the signing private key of the authoritative DNS answering device.

In examples, the method includes registering, by the authoritative DNS answering device prior to receiving the full domain name query, an association between the full domain name to deterministically derive the verification public key and the signing private key of the authoritative DNS answering device, wherein the signing private key is used to digitally sign the authoritative response. In one example, publicly verifying the authoritative signed response includes executing data integrity validation and entity authentication in a single computation.

In an example, the at least one DNS answering device includes a plurality of DNS answering devices, further comprising generating, by each DNS answering device, a respective message, digitally signing, by each DNS answering device, the respective message to output a respective unique fingerprint on the respective message, sending, by each DNS answering device, the respective message to the DNS asking device, and publicly verifying, by the DNS asking device, the respective message using only a respective domain name of a respective DNS answering device to deterministically derive a respective verification public key corresponding to a respective signing private key of the respective DNS answering device. In some examples, outputting the respective unique fingerprint on the respective message includes compressing the respective unique fingerprint into a superordinate fingerprint without expanding a size of the superordinate fingerprint.

According to one aspect, a system for securely transmitting information is provided, comprising a Domain Name System (DNS) asking device, and at least one DNS answering device including an authoritative DNS answering device, the at least one DNS answering device being configured to be communicatively coupled to the DNS asking device, wherein the DNS asking device and the authoritative DNS answering device are configured to receive, by the DNS asking device, a full domain name query including a full domain name organized in a sequential order and being associated with the authoritative DNS answering device, send, by the DNS asking device, the full domain name query to the authoritative DNS answering device, generate, by the authoritative DNS answering device, an authoritative response including a binding record between the full domain name and a corresponding resource, digitally sign, by the authoritative DNS answering device, the authoritative response to output a unique fingerprint on the authoritative response to generate an authoritative signed response, send, by the authoritative DNS answering device, the authoritative signed response to the DNS asking device, and publicly verify, by the DNS asking device, the authoritative signed response using only the full domain name to deterministically derive a verification public key corresponding to a signing private key of the authoritative DNS answering device.

In an example, the DNS asking device is further configured to receive the full domain name query from a client, and send the binding to the client responsive to determining that the binding record is stored locally and satisfies a validity criterion. In one example, the system includes the client, wherein the client is configured to publicly verify the authoritative signed response using only the full domain name to deterministically derive the verification public key corresponding to a signing private key of the authoritative DNS answering device. In examples, the authoritative DNS answering device is further configured to register, prior to receiving the full domain name query, an association between the full domain name to deterministically derive the verification public key and the signing private key of the authoritative DNS answering device, wherein the signing private key is used to digitally sign the authoritative response.

In some examples, publicly verifying the authoritative signed response includes executing data integrity validation and entity authentication in a single computation. In an example, the at least one DNS answering device includes a plurality of DNS answering devices, and wherein the DNS answering device and the plurality of DNS answering devices are configured to generate, by each DNS answering device, a respective message, digitally sign, by each DNS answering device, the respective message to output a respective unique fingerprint on the respective message, send, by each DNS answering device, the respective message to the DNS asking device, and publicly verify, by the DNS asking device, each respective message using only a respective domain name of a respective DNS answering device to deterministically derive a respective verification public key corresponding to a respective signing private key of the respective DNS answering device. In an example, in outputting the respective unique fingerprint on the respective message, each DNS answering device is configured to compress the respective unique fingerprint into a superordinate fingerprint without expanding a size of the superordinate fingerprint.

According to an aspect of the disclosure, an authoritative Domain Name System (DNS) answering device is provided including a module for receiving, from a DNS asking device, a full domain name query including a full domain name organized in a sequential order, a module for generating an authoritative response including a binding record between the full domain name and a corresponding resource, a module for digitally signing the authoritative response to output a unique fingerprint on the authoritative response to generate an authoritative signed response, and a module for sending, by the authoritative DNS answering device, the authoritative signed response to the DNS asking device, wherein the authoritative signed response is capable of being publicly verified by the DNS asking device using only the full domain name to deterministically derive a verification public key corresponding to a signing private key of the authoritative DNS answering device.

In an example, the DNS answering device includes a module for registering, by the authoritative DNS answering device prior to receiving the full domain name query, an association between the full domain name to deterministically derive the verification public key and the signing private key of the authoritative DNS answering device. In one example, the full domain name query is received, via the DNS asking device, from a client-side stub resolver. In some examples, the authoritative signed response is capable of being publicly verified, by the client-side stub resolver, using only the full domain name to deterministically derive a verification public key corresponding to the signing private key of a DNS answering device. In one example, the signing private key is used to digitally sign the authoritative response. In an example, the authoritative signed response is capable of being publicly verified by executing data integrity validation and entity authentication in a single computation.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects of at least one embodiment are discussed below with reference to the accompanying figures, which are not intended to be drawn to scale. The figures are included to provide an illustration and a further understanding of the various aspects and embodiments, and are incorporated in and constitute a part of this specification, but are not intended as a definition of the limits of any particular embodiment. The drawings, together with the remainder of the specification, serve to explain principles and operations of the described and claimed aspects and embodiments. In the figures, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every figure. In the figures:

FIG. 1 illustrates a block diagram of a Domain Name System (DNS) according to an embodiment;

FIG. 2 illustrates a process of securely transmitting information in a DNS according to an embodiment; and

FIG. 3 illustrates a process of verifying a signed message according to an embodiment.

DETAILED DESCRIPTION

Examples of the methods and systems discussed herein are not limited in application to the details of construction and the arrangement of components set forth in the following description or illustrated in the accompanying drawings. The methods and systems are capable of implementation in other embodiments and of being practiced or of being carried out in various ways. Examples of specific implementations are provided herein for illustrative purposes only and are not intended to be limiting. In particular, acts, components, elements and features discussed in connection with any one or more examples are not intended to be excluded from a similar role in any other examples.

Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. Any references to examples, embodiments, components, elements or acts of the systems and methods herein referred to in the singular may also embrace embodiments including a plurality, and any references in plural to any embodiment, component, element or act herein may also embrace embodiments including only a singularity. References in the singular or plural form are no intended to limit the presently disclosed systems or methods, their components, acts, or elements. The use herein of “including, ” “comprising, ” “having, ” “containing, ” “involving, ” and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.

References to “or” may be construed as inclusive so that any terms described using “or” may indicate any of a single, more than one, and all of the described terms. In addition, in the event of inconsistent usages of terms between this document and documents incorporated herein by reference, the term usage in the incorporated features is supplementary to that of this document; for irreconcilable differences, the term usage in this document controls.

As discussed above, secure communication is characterized in part by two related operations: data integrity validation, and sender identity authentication. Data integrity validation generally refers to acts of verifying that a message sent by a sender has not been altered before being received by a recipient. Sender identity authentication generally refers to acts of verifying that a message purporting to be sent by a sender was in fact sent by the sender.

One example of providing data integrity validation is to execute, by an unidentified sender, a hash function on a message prior to sending the message. A hash function is a mixing compression function capable of accepting, as input, a bit string of arbitrary length, and outputting an output bit string of a specified length. Hash functions enable a recipient of the received message to validate the integrity of the received message to ensure that no one has altered the received message en route from the unidentified sender.

An example of providing sender identity authentication includes providing, in the message sent to the recipient, an additional input to a hash function such as a secret key value. For example, the secret key value may be included with the bit string input to the hash function to add a “fingerprint” (i.e., a unique identifier, or undeniable signature) to the message bit string which is input to the hash function. Such a hash function, which is executed on an input including a key, may be referred to as a keyed hash function. A keyed hash function which is executed on an input including a secret key (for example, a symmetric key) may not be capable of public validation (i.e., capable of being validated by any entity) because only entities knowing the secret key may validate the message.

A publicly verifiable keyed hashing function can compute both the data integrity validation and sender identity authentication processes by a recipient. For example, consider a secure communication system including two entities, the sender having a keypair including a private key and a public key. A first party intending to send a message to a second party may code the message using its own private key to provide message origin authentication. The second party, upon receipt of the message, decodes the message using the first party’s public key to validate the message origin authentication.

However, a conventional public key is a random-looking bit string. Therefore, in obtaining the first party’s public key, the second party must also validate that the public key purporting to correspond to the first party actually does correspond to the first party. The first party may include a digital certificate, provided by an authority such as a Certificate Authority (CA) or some other means for proving identity that the second party trusts, with the public key when the first party provides the public key to the second party. The second party may verify that the binding between the first party’s random-looking public key and the identity of the first party is valid, and that the public key therefore actually corresponds to the first party. Because the second party must also verify the binding between the random looking public key and the identity of the first party, the second party is required to execute two steps to perform the validation of the binding and the signature authentication.

A message encoded according to an Identity-Based Cryptography (IBC) -based Compressed Fingerprint (CF) , in contrast, may be publicly verified without the need to verify any other message. More specifically, and in the context of a Domain Name System (DNS) , the message may be publicly verified using domain names as a public key to perform public verification without needing to validate the legitimacy of the public key. Accordingly, the IBC-based CF enables a receiving party to perform both data integrity validation and sender identity authentication operations in a one-step computation, as opposed to a two-step computation requiring a receiving party to consult an additional validation entity using additional data in a second step. Compressing the data integrity and origin authentication validation on an arbitrary number of senders enables devices and network packets which are not sophisticated enough to support two-step validation-and-authentication computations to validate and authenticate received data having an arbitrarily large number of compressed fingerprints, such as where network packets lack sufficient size to include additional data for validating the public key binding.

Accordingly, embodiments of the present disclosure provide IBC in the context of a DNS. DNS is a one-step, streamlined online hierarchy which provides name binding resource services. Conventional public key-based signatures require two-step validation, including (1) validating a binding between a random-looking public key to a name, and (2) validating a signature using the bound public key. Securing DNS using conventional public key-based signatures therefore requires two steps, which undesirably complicates the one-step, streamlined nature of DNS. Conversely, IBC can be arranged in the same hierarchical structure of the DNS and enables one-step computations.

In one example, the one-step computation may be executed by a DNS resolver. Generally speaking, a DNS resolver is configured to receive a user input including a domain name and determine a resource, e.g., an Internet Protocol (IP) address, associated with the received domain name. DNS resolvers are typically stateless, and communicate using small-size Universal Datagram Protocol (UDP) packets. Because of the stateless nature of DNS resolvers, and the modest UDP packet size limit, it may be difficult for DNS resolvers to execute two-step of (1) validation of binding between a random-looking public key and an identity, and (2) authentication computations for signature validation, and DNS resolvers therefore lack the ability to feasibly validate or authenticate received messages from a small-sized UDP packet.

For example, DNS SECurity (DNSSEC) , or DNS-Based Authentication of Named Entities (DANE) for DNSSEC, provides a conventional public key method of providing DNS resolver authentication and data integrity validation. In DNSSEC or DANE is a security protocol which uses conventional public key cryptography. However, DNSSEC and DANE may be difficult to implement at least because stub recursors in a DNS environment are constrained by modest UDP packet size limits which may not be sufficient to support the conventional public key-based two-step validating method. UDP packets, which will be dropped by firewalls if the UDP packet size is too large, may not have a large enough capacity to contain all information which is necessary for the conventional public key-based communication, such as public key and identity-binding information, and so forth.

By implementing the CF in a DNS environment according to embodiments of the present disclosure, DNS resolvers may be able to implement the one-step validation-and-authentication computation and thereby enhance DNS resolver security by enabling validation and authentication of received messages using domain names as a public key. Each DNS resolver may add a unique identifier to a message which uniquely identifies the device, without expanding a size of the message, and which is which is transmitted in a single DNS UDP packet. A receiver of the DNS UDP packet may verify the packet with a single computation only using a substring of a full domain name query, including a domain name of the sender of the DNS UDP packet and superordinate domains to deterministically derive the needed verification public key. The CF enables an arbitrary number of entity fingerprints to be compressed into a single datagram, because the size of the message is independent of the number of unique fingerprints applied to the message (i.e., the size of the message is not affected by a fingerprint being applied to the message) . Accordingly, even the relatively small size of UDP packets is capable of sustaining an arbitrary number of entities.

The following discussion describes a “CF-way” (i.e., a method involving the use of CFs) of signing, registration, querying, answering, validation and authentication computations performed by devices in a DNS, which secure DNS with the advantages of the streamlined one-step for the signer ID validation and signature authentication. For purposes of the following discussion, certain variables will be defined to illustrate the derivation of the CF-way executed by the DNS. k _M is a master key. G ₁ is a bilinear pairing computable elliptic additive group of a prime order. G ₂ is a number multiplicative group of the same prime order as G ₁. e is a bilinear pairing mapping for which,

G ₁ x G ₁→G ₂

satisfying that, for all elliptic curve points U, V, W in G1,

e (U+V, W) =e (U, W) *e (V, W)

and

e (U, V+W) =e (U, V) *e (U, W)

Throughout the remainder of the technical description, let P be the DNS system-wise master public point in G ₁. F is a hash function mapping from an arbitrary bit string to a point in G ₁. At a startup of the DNS, the master key k _M is generated as,

k _M=Random＜Cardinality (G ₂)

where Random is a random number, and G ₂ is a multiplicative group.

A master public key P _M is defined as,

P _M= [k _M] P

A Key Generation Center (KGC) signature SigKGC is defined as,

SigKGC= [k _M] F ( "KGC" )

where KGC represents a message to be signed by the hash function F.

Because G ₁ is defined as a group of a prime order, just as the system-wise public point P is a group generator, F ( “KGC” ) must also be a group generator where

F ( "KGC" ) ≠∞

As used herein, the term “Master Signature Pair” refers to the pair (F ( “KGC” ) , SigKGC) . The Master Signature Pair may be considered a digital signature because, with respect to the master public key pair (P, P _M) , the Master Signature Pair has the same formulation as an undeniable signature. An undeniable signature is defined over a multiplication group of a finite field in which the verification of a signature requires interaction with the signer (i.e., a two-step computation) . However, in the bilinear pairing mapping e defined above, the Master Signature Pair, which may be considered an undeniable signature, can be verified without interaction with the signer (i.e., a one-step transaction) according to the following pairing evaluation:

Accordingly, from the pairing evaluation

e (P, Sig ( "KGC" ) ) ==e (P _M, F ( "KGC" ) )

it can be seen that a point Sig ( “KGC” ) in G ₁ is generated by the point F ( “KGC” ) in G ₁ using the same secret multiplier that is used to generate a point P _M in G ₁ by the system-wise master public point P in G ₁. Accordingly, the message KGC may be an arbitrary bit string input to the hash function F. Moreover, because the pairing evaluation does not involve any secret term, Sig ( “KGC” ) may be publicly verified, thereby enabling the above-described one-step computation.

For example, suppose a first entity’s public key is an identifiable bit string, “Alice, ” which represents the first entity’s identity. In a pairing-based Identity-Based Cryptography (IBC) operation, the first entity’s private key would be generated by a KGC as,

[k _M] F ( "Alice" )

Embodiments of the present disclosure do not enable the KGC to generate the first entity’s entire private key by the KGC. Instead, to protect the first entity’s privacy from the KGC in one embodiment, the KGC only generates a portion of the first entity’s private key. The first entity also has access to another portion of the private key called “private-key-self-portion” , which is unknown to the KGC and is defined as,

k _Alice=Random＜Cardinality (G ₂)

where Random is a random number, and G ₂ is a multiplicative group.

Furthermore, the first entity’s IBC public key is defined using the first entity’s identity–here, “Alice” –as follows,

P _Alice=Sig _Alice ( "Alice" ) = [k _Alice] F ( "Alice" )

Sig _Alice ( "KGC" ) = [k _Alice] F ( "KGC" )

Just as the term Sig ( “KGC” ) may be publicly verifiable according to the pairing evaluation discussed above, the undeniable signature pair (F ( “KGC” ) , SigAlice ( “KGC” ) ) is publicly verifiable with respect to the first identity’s IBC public key pair, (F ( "Alice" ) , P _Alice) as the following undeniable signature verification,

FIG. 1 illustrates a block diagram of a DNS 100. The DNS 100 includes a root domain 102, Top-Level Domains (TLDs) 104a-104c, and Level Two (L2) domains 106a-106f. The DNS 100 is structured as a hierarchical, decentralized, distributed system operating in a delegation structure. It is to be appreciated that the DNS 100 illustrates only a simplified abstraction of the DNS. For example, the TLDs 104a-104c, which include domains such as com., net., and so forth, represent only a subset of the hundreds of TLDs in the DNS. Similarly, the L2 domains 106a-106f, which include domains such as example. com., gov. cn., hp. com., and so forth, represent only a subset of the many L2 domains in the DNS.

The hierarchical structure of the DNS 100 may continue down to a lowest-level domain until arriving at a DNS server which stores an applicable Address Resource Record (ARR) . A DNS server storing an ARR is referred to as an authoritative name server. The authoritative name server returns a query result, referred to as an authoritative answer, to the entity which generated the FQDN query. The authoritative answer includes a resource, e.g., an IP address, bound to the FQDN. The entity receiving the query result may then use the resource, e.g., IP address to connect to or use a Resource Name (RN) server specified by the resource (IP address) to use services provided by the RN server.

An entity generating a search query including an FQDN may be a client-side computer system. Some applications executed by a client-side computer system, such as a web browser, may include a DNS resolver, referred to as a stub resolver. Stub resolvers operate to receive an FQDN query and determine a resource, e.g., an IP address, corresponding to the FQDN. Stub resolvers may be considered to operate in a recursive manner, because the stub resolver will answer a search query including an FQDN as an authoritative resolver if it can find an authoritative answer (i.e., a binding between an RN and a resource, e.g., an IP address) in its local cache. Otherwise, the stub resolver will submit a search query to another entity in the DNS.

Client-side DNS resolvers store ARRs such that repeated requests may be serviced in a more efficient manner while reducing DNS traffic across the Internet. A requirement of the DNS is that applications and services must be decoupled from the physical status of computing resources. As a result of this decoupling, software development and service provisioning may scale dynamically and elastically.

If the stub resolver is unable to find a locally stored ARR, the stub resolver may forward the query to a default DNS resolver. The client-side computer system may be automatically configured to have access to the default DNS resolver’s IP address in a process similar to Dynamic Host Configuration Protocol (DHCP) . This process may be provided by an Internet Service Provider (ISP) of the client-side computer system. This automatic configuration enables the stub resolver to forward queries to the default DNS resolver when the stub resolver cannot locally locate an ARR.

The DNS is subject to malicious attacks including, for example, cache poisoning, hijacking, phishing, spoofing stub resolvers, default resolvers, and so forth. Additional security could be achieved by authenticating an identity of a DNS resolver, and by verifying the data integrity of data transmitted over the DNS network or cached in resolvers. Furthermore, some users may prefer that their queries remain confidential. The foregoing benefits may be achieved by implementing the CF discussed above in connection with DNS devices, including DNS resolvers.

FIG. 2 illustrates a process 200 of implementing one-step validation-and-authentication in a DNS according to an embodiment. For example, the process 200 may be executed in connection with the DNS 100. At act 202, the process 200 begins. At act 204, DNS registration is performed. As discussed above, the DNS 100 includes root domain 102. In some embodiments, the DNS 100 may include several (e.g., 13) roots. Each root’s IP address acts as an identity of the respective root. The root IP address identities act as KGCs, as discussed above.

Each node in the DNS 100 has a “private-key-self-portion” which is an integer, k _node. During registration of nodes in the DNS 100, subordinate nodes (e.g., the TLD 104a node) must register with a superordinate node (e.g., the root domain 102 node) . The superordinate node issues a “private-key-parent-portion” to the subordinate node, CF _sup, which is in the form,

CF _sup=CF _{sup-1} + [k _sup] F ( "ID _sub" )

where CF _{sup-1} is a CF of a node superordinate to the superordinate node (i.e., a parent node) , k _sup is the “private-key-self-portion” of the superordinate node, and ID _sub is the identity of the subordinate node. Some nodes’ CFs may differ from the above formulation; for example, the root’s CF, CF ₀, may be an empty string. Thus, during registration, domain names are associated with corresponding private keys such that messages generated by DNS entities using their respective CF-way signing private keys may be publicly verified using their respective domain names to deterministically derive a verification public key that corresponds to the CF-way signing private key.

At act 206, full domain name queries are received. For example, full domain name queries, which may include full domain names, may be received from a DNS asking device (e.g., a default resolver) which may, in turn, receive queries from client-side stub resolvers. Domain name queries may be received by any node device in the DNS 100, which are referred to herein as DNS answering devices. As discussed above, queries may be serviced in a hierarchical manner, starting with the root domain 102 and terminating with an authoritative domain (e.g., the L2 domain 106a) .

At act 208, a domain name query response is generated. If the domain node device generating the response is an authoritative device, the response may include information such as a binding record between the full domain name and a corresponding resource (e.g., an IP address) . If the domain node device generating the response is not an authoritative device, the response may include information which can lead the asking resolver to a subordinate node which has more precise resolving knowledge. For example, the resolving knowledge may include a binding record, or yet another subordinate node having even more precise resolving knowledge. Generating the response may include CF-way signing the information as,

CF _node=CF _{node-1} + [k _node] F ( "sub _info" )

where CF _node is a CF-way signature applied by the node, CF _{node-1} is a CF of a directly superordinate node, k _node is the “private-key-self-portion” of the node, and sub _info is the information provided to the asking device, which may include the resource binding record ifthe node is an authoritative resolver, or some subordinate resource information leading the asking device to a subordinate node for more precise resolution in the next level in the DNS hierarchy. As discussed above, the CF-way signature is generated using a portion of signing private key CF which is pre-registered to be associated with a verification public key such that a domain name of the CF-way signing device may be used to deterministically derive the verification public key corresponding to the CF-way signing private key.

At act 210, a determination is made as to whether a binding record has been received (e.g., if sub _info includes the resource binding record) . If so, then the desired binding record is returned to the querying device (e.g., the client-side stub resolver) and the process 200 continues to act 212. Otherwise, the process 200 may return to act 206, where a DNS asking device may query a next-highest domain node which has not yet received the full domain name query. For example, the next-highest domain node may be a node indicated in sub _info.

At act 212, verification is performed. Verification may be performed by an entity or entities that sent the full domain name queries, such as the client-side stub resolver discussed above with respect to act 206, or a DNS asking device asking on behalf of the client-side stub resolver. The verifying entity executes a verification operation to verify the legitimacy of the received message, as discussed below with respect to FIG. 3.

FIG. 3 illustrates a process 300 of verifying message legitimacy according to an embodiment. For example, the process 300 may be executed by a client-side stub resolver, or “client, ” or a DNS asking device asking on behalf of the client.

At act 302, the process 300 begins. At act 304, the client challenges (e.g., via a DNS asking device) a TLD node device to use a random subset of roots, e.g., Root _s, Root _t, ..., Root _u, each having respective public keys (P, [s] P) , (P, [t] P) , ..., (P, [u] P) , and with denoting [x] P= P _x. At act 306, CFs are solicited. The TLD node device solicits a CF expressed as,

CF _TLD= [s] F ( "TLD" ) + [t] F ( "TLD" ) +...+ [u] F ( "TLD" ) + [k _TLD] F ( "L2" )

where TLD is an identity (e.g., a domain name) of the TLD node, and L2 is an identity of a second-level domain node which is immediately subordinate to the TLD node. Act 306 is executed for each node between and including the TLD and an authoritative node A.

At act 308, an authoritative CF signature is computed. For example, the authoritative node A which generates a message ARR computes P _A and CF-way signs the message as,

where CF _{parentA} is a CF ofa node immediately superordinate to A, parentA. At act 310, the authoritative node A sends CF _A and P _A= [k _A] P to the client.

At act 312, the client and/or the DNS asking device verifies the CF-way signed message. Verifying the CF-way signed message may include executing the pairing evaluation

where A is an identity (e.g., a domain name, such as a substring of the full domain name received at act 206) of the authoritative node A. After the client and/or DNS asking device verifies the CF-way signed message, the process 300 ends at act 312.

Because the CF-way of signing and verification is performed in an online challenge-response interaction, the verifier may wish to add more randomness in its challenge as a standard way to enhance security for the challenge-response mechanism. In some embodiments, the verifier may pick one or more random numbers v, and send v to instruct a selected answering device, e.g., X, to use in the computation of its input to CF by multiplying v by its “private-key-self-portion” k _x. This is to instruct the answering device X to use the randomized “private-key-self-portion” v*k _x in the construction of its CF. Then in the right-hand side of the verification of the e (P, CF _A) formulation provided above, the pairing evaluation for the term e (P _X, F ( “subnode _X” ) ) , which corresponds to embodiments in which the random challenge v is unused, should be replaced with e (P _X, F ( “subnode _X” ) ) ^v. Since the verifier has its random and secret selected integer v, it can exclusively conduct the verification of the randomized CF signature. This challenge-response CF-way mechanism is most effective to prevent answering devices in the upper levels of the DNS hierarchy from collusion to forge the CF of a lower-level device X since the randomized “private-key-self-portion” v*k _x is not known to all of these devices in the upper levels of the DNS hierarchy.

In other embodiments, modifications may be made to the process 200. For example, in some embodiments, each of non-authoritative domain devices may not CF-way sign responses using CFs that may be publicly verified using the domain name of the non-authoritative domains. For example, some or all of the non-authoritative domain devices may use conventional DNSSEC or DANE procedures to secure messages. However, an authoritative DNS device may still register an association between a verification public key and a signing private key to CF-way sign responses using CFs that may be publicly verified using the domain name of the authoritative domain even where the non-authoritative domain devices do not. In other words, in some embodiments, only the authoritative domain device may CF-way sign messages in a manner that enables the authenticity of the messages to be publicly verified using the full domain name to deterministically derive a verification public key of the authoritative domain devices.

Furthermore, in some embodiments, the DNS asking device may answer a client request by sending a binding record to the client responsive to determining that the binding record is stored locally, rather than directly soliciting an authoritative device for the binding record in response to receiving the client request. In some embodiments, the DNS asking device may also verify that the locally stored binding record satisfies a validity criterion before sending the binding record. For example, the DNS asking device may first verify that a time to live (TTL) tag associated with the record indicates that the record is still valid.

The ability to perform a one-step validation-and-authentication procedure enables a reduction in the computing power and resources of an entity executing the procedure. As discussed above, certain systems (e.g., DNS) include devices which are not suited to execute two-step validation-and-authentication procedures, but which are able to execute one-step validation-and-authentication procedures. Accordingly, significant security enhancements may be achieved in systems for which it is infeasible to execute two-step validation-and-authentication procedures, but for which it is feasible to execute one-step validation-and-authentication procedures.

Moreover, whereas systems based on a two-step validation-and-authentication procedure (e.g., DNSSEC or DANE) require two server hierarchies, the one-step validation-and-authentication procedures described herein require only one. Thus, the physical resources required to execute one-step validation-and-authentication (e.g., servers) are less than those required to execute two-step validation-and-authentication.

However, it is to be appreciated that even systems for which it is feasible to execute two-step validation-and-authentication procedures may benefit from implementing the one-step validation-and-authentication procedures discussed above. Furthermore, although specific examples have been provided with respect to the DNS architecture, it is to be appreciated that the one-step validation-and-authentication procedure are not limited to implementation in the DNS architecture. For example, the one-step validation-and-authentication procedure may be implemented in connection with any system in which entities are uniquely identifiable. Entities may be identified by a phone number, an email address, a driver’s license number, and so forth. Accordingly, it is to be appreciated that examples have been provided with respect to the DNS architecture for purposes of explanation only, and should not be construed as limiting.

Having thus described several aspects of at least one embodiment, it is to be appreciated various alterations, modifications, and improvements will readily occur to those skilled in the art. Such alterations, modifications, and improvements are intended to be part of, and within the spirit and scope of, this disclosure. Accordingly, the foregoing description and drawings are by way of example only.

What is claimed is:

Claims

A method of securely transmitting information, the method including:

receiving, by a Domain Name System (DNS) asking device, a full domain name query including a full domain name organized in a sequential order; and

communicating, by the DNS asking device, with at least one DNS answering device including an authoritative DNS answering device associated with the full domain name, wherein the communicating includes:

sending, by the DNS asking device, the full domain name query to the authoritative DNS answering device;

generating, by the authoritative DNS answering device, an authoritative response including a binding record between the full domain name and a corresponding resource;

digitally signing, by the authoritative DNS answering device, the authoritative response to output a unique fingerprint on the authoritative response to generate an authoritative signed response;

sending, by the authoritative DNS answering device, the authoritative signed response to the DNS asking device; and

publicly verifying, by the DNS asking device, the authoritative signed response using only the full domain name to deterministically derive a verification public key corresponding to a signing private key of the authoritative DNS answering device.
The method of claim 1, further comprising:

receiving, by the DNS asking device, the full domain name query from a client; and

sending, by the DNS asking device, the binding record to the client responsive to determining that the binding record is stored locally and satisfies a validity criterion.
The method of claim 1, further comprising publicly verifying, by the client, the authoritative signed response using only the full domain name to deterministically derive the verification public key corresponding to the signing private key of the authoritative DNS answering device.
The method of claim 3, further comprising registering, by the authoritative DNS answering device prior to receiving the full domain name query, an association between the full domain name to deterministically derive the verification public key and the signing private key of the authoritative DNS answering device, wherein the signing private key is used to digitally sign the authoritative response.
The method of claim 1, wherein publicly verifying the authoritative signed response includes executing data integrity validation and entity authentication in a single computation.
The method of claim 1, wherein the at least one DNS answering device includes a plurality of DNS answering devices, further comprising:

generating, by each DNS answering device, a respective message;

digitally signing, by each DNS answering device, the respective message to output a respective unique fingerprint on the respective message;

sending, by each DNS answering device, the respective message to the DNS asking device; and

publicly verifying, by the DNS asking device, the respective message using only a respective domain name of a respective DNS answering device to deterministically derive a respective verification public key corresponding to a respective signing private key of the respective DNS answering device.
The method of claim 6, wherein outputting the respective unique fingerprint on the respective message includes compressing the respective unique fingerprint into a superordinate fingerprint without expanding a size of the superordinate fingerprint.
A system for securely transmitting information, the system comprising:

a Domain Name System (DNS) asking device; and

at least one DNS answering device including an authoritative DNS answering device, the at least one DNS answering device being configured to be communicatively coupled to the DNS asking device,

wherein the DNS asking device and the authoritative DNS answering device are configured to:

receive, by the DNS asking device, a full domain name query including a full domain name organized in a sequential order and being associated with the authoritative DNS answering device;

send, by the DNS asking device, the full domain name query to the authoritative DNS answering device;

generate, by the authoritative DNS answering device, an authoritative response including a binding record between the full domain name and a corresponding resource;

digitally sign, by the authoritative DNS answering device, the authoritative response to output a unique fingerprint on the authoritative response to generate an authoritative signed response;

send, by the authoritative DNS answering device, the authoritative signed response to the DNS asking device; and

publicly verify, by the DNS asking device, the authoritative signed response using only the full domain name to deterministically derive a verification public key corresponding to a signing private key of the authoritative DNS answering device.
The system of claim 8, wherein the DNS asking device is further configured to:

receive the full domain name query from a client; and

send the binding to the client responsive to determining that the binding record is stored locally and satisfies a validity criterion.
The system of claim 8, further comprising the client, wherein the client is configured to publicly verify the authoritative signed response using only the full domain name to deterministically derive the verification public key corresponding to a signing private key of the authoritative DNS answering device.
The system of claim 10, wherein the authoritative DNS answering device is further configured to register, prior to receiving the full domain name query, an association between the full domain name to deterministically derive the verification public key and the signing private key of the authoritative DNS answering device, wherein the signing private key is used to digitally sign the authoritative response.
The system of claim 8, wherein publicly verifying the authoritative signed response includes executing data integrity validation and entity authentication in a single computation.
The system of claim 8, wherein the at least one DNS answering device includes a plurality of DNS answering devices, and wherein the DNS answering device and the plurality of DNS answering devices are configured to:

generate, by each DNS answering device, a respective message;

digitally sign, by each DNS answering device, the respective message to output a respective unique fingerprint on the respective message;

send, by each DNS answering device, the respective message to the DNS asking device; and

publicly verify, by the DNS asking device, each respective message using only a respective domain name of a respective DNS answering device to deterministically derive a respective verification public key corresponding to a respective signing private key of the respective DNS answering device.
The system of claim 13, wherein in outputting the respective unique fingerprint on the respective message, each DNS answering device is configured to compress the respective unique fingerprint into a superordinate fingerprint without expanding a size of the superordinate fingerprint.
An authoritative Domain Name System (DNS) answering device comprising:

a module for receiving, from a DNS asking device, a full domain name query including a full domain name organized in a sequential order;

a module for generating an authoritative response including a binding record between the full domain name and a corresponding resource;

a module for digitally signing the authoritative response to output a unique fingerprint on the authoritative response to generate an authoritative signed response; and

a module for sending, by the authoritative DNS answering device, the authoritative signed response to the DNS asking device, wherein the authoritative signed response is capable of being publicly verified by the DNS asking device using only the full domain name to deterministically derive a verification public key corresponding to a signing private key of the authoritative DNS answering device.
The authoritative DNS answering device of claim 15, further comprising a module for registering, by the authoritative DNS answering device prior to receiving the full domain name query, an association between the full domain name to deterministically derive the verification public key and the signing private key of the authoritative DNS answering device.
The authoritative DNS answering device of claim 16, wherein the full domain name query is received, via the DNS asking device, from a client-side stub resolver.
The authoritative DNS answering device of claim 17, wherein the authoritative signed response is capable of being publicly verified, by the client-side stub resolver, using only the full domain name to deterministically derive a verification public key corresponding to the signing private key of a DNS answering device.
The authoritative DNS answering device of claim 16, wherein the signing private key is used to digitally sign the authoritative response.
The authoritative DNS answering device of claim 15, wherein the authoritative signed response is capable of being publicly verified by executing data integrity validation and entity authentication in a single computation.