US20180048460A1

US20180048460A1 - Secure and delegated distribution of private keys via domain name service

Info

Publication number: US20180048460A1
Application number: US15/722,680
Authority: US
Inventors: Peter Martin Goldstein
Original assignee: Valimail Inc
Current assignee: Valimail Inc
Priority date: 2015-02-14
Filing date: 2017-10-02
Publication date: 2018-02-15
Also published as: BR112017017425A2; EP3257192A1; CN108604983A; CA2976463C; AU2016218340A1; CN108604983B; EP3257192B1; US9686073B2; CA2976463A1; EP3257192A4; US20170250797A1; WO2016130340A1; AU2016218340B2; US20160373252A1; US9800402B2; JP6526244B2; BR112017017425B1; JP2018506939A

Abstract

A third party system generates a public-private key pair, the public key of the key pair being an encryption key, and the private key of the key pair being a decryption key. The third party system publishes the encryption key as a DNS record of a third party system. The third party system receives a request to sign a message on behalf of a domain owner, the message to be sent to a recipient, and accesses an encrypted delegated private key published by the domain owner via a DNS record of the domain owner, the encrypted delegated private key encrypted using the encryption key. The third party system decrypts the encrypted delegated private key using the decryption key, and generates a signature for the message using the delegated private key. The third party system sends the signature and the message to the recipient.

Description

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No. 15/594,505, filed May 12, 2017, which is a continuation of U.S. application Ser. No. 15/255,118, filed Sep. 1, 2016, which is a continuation of PCT Application No. PCT/US2016/015797, filed Jan. 29, 2016, which claims benefit to U.S. Provisional Application No. 62/116,414, filed Feb. 14, 2015, all of which are hereby incorporated by reference in their entirety.

BACKGROUND

Field of Art

The disclosure generally relates to the field of networking, and specifically to secure and delegated distribution of private keys via the Domain Name Service (DNS).

Description of Art

In distributed messaging systems like electronic mail (email), there is a need to validate the originator of a message against the message's purported identity in order to eliminate fraudulent messages. One approach to this problem is to use public key cryptography to verify the messages. In this approach an encrypted hash is used to validate messages as being associated with an identity. One or more public keys are published in a globally visible directory, wherein only the holder of the identity is allowed to publish records in the directory. Authorized senders are in possession of a corresponding private key, which they can use to encrypt a hashed version of the message and include the encrypted hash as metadata for the message. Recipients can decrypt the metadata using the public key and compare it to their own, independently generated hash of the message. If the hashes match, then the sender is valid. DomainKeys Identified Mail (DKIM) is the standard implementation of this system for email.
This approach can be quite effective, but it has some issues when there are multiple signing entities. Private key distribution becomes challenging when there are multiple distinct entities that are allowed to sign messages authorized against a single shared domain (and hence must have a valid private key) from a single shared domain. For example, if an administrator of “acme.com” wishes to allow signing of messages from “ajax.com”, each domain would need a valid private key.
One approach is to allocate different subdomains of the primary domain to the different signing organizations, to eliminate the sharing. In this circumstance each signing organization has complete control of the global directory for its subdomain. While this can work, it fails the primary goal of supporting multiple senders on a single domain as each organization would require a distinct subdomain of the primary domain.
Alternately, each signing entity can generate its own private/public key pair, and provide the public key to the authorizing domain owner to publish in the global directory. By publishing the corresponding public key in the appropriate location in the global directory, the domain owner signals that it is delegating signing authority to the signing entity. However, this manual process tends to be both error-prone and burdensome on the authorizing domain owner. It also makes it difficult to incorporate best practices such as key rotation, as this would require repetition of the manual process each time the key was replaced, causing a situation in practice where a key may not be updated.
Hence, what is lacking is an ability to generate and distribute delegated private keys authorized against a shared domain in a secure and automated fashion to multiple distinct entities, as well as the reliable management and update of such keys.

SUMMARY

In some embodiments, systems and methods for securely distributing delegated private keys for public-key cryptography via the Domain Name Service (DNS) may comprise using public key cryptography to allow secure and automated distribution of private keys via the Domain Name Service (DNS). Such delegated private keys are distributed from domain owners to third-party entities via encrypted data published in DNS. The domain owner publishes the public key in a DNS record within their domain's DNS zone. The third-party entity may then use the corresponding private key for message signing, to negotiate symmetric key exchange, or other purposes as appropriate for the application, on behalf of the domain owner. An automated system handles creating and updating these private/public key pairs, and publishing them to appropriate DNS records on a domain managed by the domain owner.
In some embodiments, third party entities that wish to use private keys authorized by a domain owner (e.g., to sign messages on the domain owner's behalf) generate a dedicated key pair using a public key cryptography algorithm. This key pair will consist of a decryption key and an encryption key. The third party entity publishes the encryption key as a DNS TXT record in a well-defined location (e.g., on a protocol-defined subdomain of a known domain owned by the third party entity), and keeps the decryption key private.
In some embodiments, systems and methods for securely distributing delegated private keys via the Domain Name Service (DNS) may include an automated system that acts on behalf of the owner of an authorizing domain. This automated system is referred to herein as the key pair generator. The key pair generator may be configured to allow a particular third party entity to use a private key associated with a particular authorizing domain. In this circumstance the key pair generator may check for the existence of an encryption key record for the third party entity as described above. In some embodiments, when such an encryption key record is detected and the owner of the authorizing domain wishes to delegate authority to the third party entity, the key pair generator may generate a new public key cryptography key pair that includes a delegated private key (private key) and a verifying key (public key). The key pair generator may encrypt the delegated private key using the encryption key retrieved from the encryption key record, and publish both the verifying key and the encrypted delegated private key in DNS at well-defined locations known respectively as the verifying key record and encrypted delegated private key record. Distinct records may be generated for each third party entity for which the owner of the authorizing domain wishes to generate a key.
In some embodiments, systems and methods for securely distributing delegated private keys via the Domain Name Service (DNS) may include a step whereby a third party entity that wishes to use such a delegated private key (e.g., to sign a message on the authorized domain's behalf), checks for the existence of corresponding verifying key and encrypted delegated private key records. Should these records exist, the third-party entity may then use its private decryption key to decrypt the delegated private key from the encrypted delegated private key record. This delegated private key can then be used by the third party entity on behalf of the authorizing domain.
In further embodiments, parties that wish to use the public key corresponding to a delegated private key (e.g., to verify a message signature, or to securely exchange a symmetric key with the private key holder), may retrieve the verifying key from the verifying key record published by the key pair generator. The exact format of the verifying key record will vary from application to application, and this format should be considered non-limiting.
In the specific example of using this system to generate message signatures, a standard signature verification algorithm may then be performed by a message receiver, and the signature may be either verified or rejected. In either case the verifying party can use a standard procedure, and does not need to know that a third party entity performed the signature.
In further embodiments, systems and methods for securely distributing delegated private keys via the Domain Name Service (DNS) may advance the art of key distribution over the Internet, by leveraging DNS—an existing, globally-available, and authenticated directory system—to support the secure distribution of delegated private keys for public key cryptography. In addition, the methods may support automatic update of said keys, either because of the passage of time or because one or more keys were potentially compromised. This is a substantial improvement to the inherent security and robustness of such systems.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosed embodiments have advantages and features which will be more readily apparent from the detailed description, the appended claims, and the accompanying figures (or drawings). A brief introduction of the figures is below.

Figure (FIG. 1 illustrates an example system capable of secure and delegated distribution of private keys via DNS according to an embodiment.

FIG. 2 is an interaction diagram and flow chart illustrating an exemplary process for enabling a third party system to generate keys on behalf of a domain owner according to one embodiment.

FIG. 3 is an interaction diagram and flow chart illustrating an exemplary process for enabling a third party system 120 to sign messages on behalf of a domain owner according to one embodiment.

FIG. 4 is a block diagram illustrating components of an example machine able to read instructions from a machine-readable medium and execute them in a processor (or controller).

DETAILED DESCRIPTION

The Figures (FIGS.) and the following description relate to preferred embodiments by way of illustration only. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily recognized as viable alternatives that may be employed without departing from the principles of what is claimed.
Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying figures. It is noted that wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict embodiments of the disclosed system (or method) for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

Configuration Overview

Disclosed by way of example embodiments is a system and process capable of secure and delegated distribution of private keys via DNS. In an embodiment, a third party system generates a public-private key pair, the public key of the key pair being an encryption key, and the private key of the key pair being a decryption key. The third party system publishes the encryption key as a DNS record of a third party system. The third party system receives a request to sign a message on behalf of a domain owner, the message to be sent to a recipient, and accesses an encrypted delegated private key published by the domain owner via a DNS record of the domain owner, the encrypted delegated private key encrypted using the encryption key. The third party system decrypts the encrypted delegated private key using the decryption key, and generates a signature for the message using the delegated private key. The third party system sends the signature and the message to the recipient.
In an embodiment, a domain owner system identifies a third party system to delegate signing of messages. The domain owner system accesses an encryption key published by the third party system at a DNS record of the third party system. The domain owner system generates a public-private key pair, the public key of the key pair being a verifying key, and the private key of the key pair being a delegated private key, the delegated private key to be used by the third party system to sign messages on behalf of a domain owner of the domain owner system. The domain owner system encrypts the delegated private key using the encryption key to generate an encrypted delegated private key. The domain owner system publishes the encrypted delegated private key at a DNS record of the domain owner, and publishes the verifying key at the DNS record of the domain owner.

Introduction

Public key cryptography plays an important role in a number of different applications. But for many of these applications there is a significant challenge in automating the underlying processes of distributing private keys to signers, and associating public keys with identities. DNS offers a tool that can be used to support an automated process that addresses both of these challenges.
Consider the specific example application of cryptographic signatures—metadata that can be included with a message to verify both the identity of a message originator, as well as the integrity of the message when received. This cryptographic signing can be performed with one of any number of public key cryptography algorithms (e.g., RSA, DSA). Such cryptographic signatures have wide application, including specific usage in the domain of email message authentication through the use of the DomainKeys Identified Mail (DKIM) protocol.
When creating a cryptographic signature, the originator of a message derives a set of bytes representing the message they want to sign. This is usually done with a hash algorithm such as SHA-512 or MD-5, to ensure that it is extremely difficult to generate another message that yields the same set of representative bytes. In this case the representative set of bytes is known as a message hash.
The originator then encrypts this message hash with the private part of a public key pair, hereafter referred to as a delegated private key. The delegated private key is used to generate the message signature, and by the nature of the underlying cryptographic procedure, it should be impossible for anyone without possession of the delegated private key to generate a correct signature. Possession of the delegated private key is restricted to those who are authorized to sign messages.
The corresponding public part of the public key pair, known as the verifying key, can be used to verify the message signature, and hence the authority and integrity of the message. A recipient of the message can use the same procedure employed by the originator to generate a message hash. The recipient can then use the verifying key to decrypt the message signature and confirm that the decrypted value matches the message hash computed by the recipient. If the value matches, the message signature is confirmed. Otherwise it is rejected.
The message signature will only be confirmed if the signer of the message possesses a delegated private key that is a key pair to the verifying key. So if the recipient can obtain the verifying key in such a way that the source of the verifying key can be authenticated, then this allows the message recipient to authorize that message as ultimately deriving from that source.
The Domain Name Service (DNS) can be used to associate a domain (and hence the identity of the domain's registered owner) with a verifying key in a secure way. In this scenario a DNS TXT record containing the verifying key is published under a well-defined subdomain in a zone registered to the organization. As only the registered owner of an organizational domain, or those parties authorized by the registered owner, can publish DNS records in that zone then the publication of the DNS record containing the verifying key must be authorized by the registered owner.
Cryptographic signing algorithms inherently require that the originator of the message possess the delegated private key. Use of DNS to authenticate the verifying vey requires that the verifying key be available to the registered domain owner or a party they authorize to update their DNS records. As the delegated private key and verifying key can only be generated together as a pair, this presents a challenge when a registered domain owner wants to allow a third party entity to sign messages on their behalf, but does not want to give that entity the ability to publish DNS records in their zone. There must be a distribution of either the delegated private key or the verifying key from one party to another, which presents a number of challenges. Moreover, future updates to the delegated private/verifying key pair present similar problems.

Example Key Delegation System

FIG. 1 illustrates an example system 100 capable of secure and delegated distribution of private keys via DNS according to an embodiment. The system 100 includes a network 150, one or more verifying agents 160, domain owner DNS server 130 and third party DNS server 140, a domain owner system 110, and a third party system 120. Although the illustrated system 100 includes the elements shown in FIG. 1, in other embodiments the system 100 may include different elements. Furthermore, the functionalities of each element may be distributed differently among the elements in other embodiments.
The network 150, which can be wired, wireless, or a combination thereof, enables communications among the verifying agents 160, the DNS systems 130/140, domain owner system 110, and third party system 120, and may include the Internet, a LAN, VLAN (e.g., with VPN), WAN, or other network. In one embodiment, the network 150 uses standard communications technologies and/or protocols, such as Hypertext transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Uniform Resource Locators (URLs), and the Doman Name System (DNS). In another embodiment, the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.
The domain owner DNS server 130 and third party DNS server 140 store DNS entries, such as DNS entries 135, 137, and 145, for use in a DNS system. Each DNS server may comprise one or more computing systems such as the computing system described with reference to FIG. 4.
Each DNS entry may include one or more DNS records for a particular domain, such an A record, MX record, and so on, as known in the art. Some of the DNS entries, such as DNS entries 135, 137, and 145 may include cryptographic keys, such as the verifying key 136, the encrypted delegated private key 138, and the encryption key 146. In one embodiment, these keys are stored as TXT records in each DNS entry. These keys may be used to sign for, and verify, the sender authenticity and contents of data sent through the network 150. Such data may include a message, file, email, and so on. Although the records as illustrated in FIG. 1 are separated into multiple entries and on multiple servers, in other embodiments the records are combined into fewer entries, fewer servers, a single entry, or some other combination.
The domain owner system 110 comprises one or more computing systems, e.g., servers that are used by a domain owner to host a domain and perform activities related to that domain. These activities may include serving web pages, sending and receiving emails, hosting files, performing e-commerce, and so on. In one embodiment, these computing systems are configured similarly to the computing system described with reference to FIG. 4.
As illustrated, the domain owner system 110 includes a key pair generator 115, and a delegated private key 117. Although the illustrated domain owner system 110 includes the elements shown in FIG. 1, in other embodiments the domain owner system 110 may include different elements. For example, the domain owner system 110 may include additional keys to be used in public key cryptography schemes. Furthermore, the functionalities of each element may be distributed differently among the elements in other embodiments.
The key pair generator 115 of the domain owner system 110 generates private and public key pairs. In one embodiment, the key pair generator 115 generates a key pair comprised of a delegated private key 117 and a verifying key 136. The verifying key 136 is the public key in this key pair, while the delegated private key 117 is the private key. The key pair generator 115 places the verifying key 136 as a record in a DNS entry 135 on the domain owner DNS server 130.
The key pair generator 115 further generates an encrypted delegated private key 138 by encrypting the delegated private key 117 with the encryption key 146 stored at the 3rd party DNS server 140, and stores this encrypted delegated private key 138 as a record at domain owner DNS server 130. The encryption key 146 is generated by the third party system 120 as part of a key pair. Thus, only the third party system 120 can decrypt the encrypted delegated private key 138 in order to retrieve the delegated private key 138, which may be used by the third party system 120 to sign and/or encrypt data on behalf of the domain owner.
The third party system 120 signs or encrypts data on behalf of a domain owner using a delegated private key securely passed to the third party system 120 by the domain owner. The third party system 120 comprises one or more computing systems, which may be configured similarly to the computing system described with reference to FIG. 4.
As illustrated, the third party system 120 includes a signing module 126, a key pair generator 125, and a decryption key 127. Although the illustrated third party system 120 includes the elements shown in FIG. 1, in other embodiments the third party system 120 may include different elements. For example, the third party system 120 may include additional keys to be used in public key cryptography schemes. Furthermore, the functionalities of each element may be distributed differently among the elements in other embodiments.
The signing module 126 of the third party system 120 signs messages or other data on behalf of the domain owner using a private key. The signing method may be based on well-known methods of public key cryptography. As an example, the third party system 120 may be a security system, data/message distribution service, or other third party provider that provides a centralized messaging system for multiple domain owners. The third party system 120 may send data and/or other messages on behalf of the domain owner system 110 to one or more recipients, and signs this data so that the recipients may verify that the data is authentic and has not been altered. To do this, the signing module 126 retrieves the encrypted delegated private key 138 provided by the domain owner system 110. The encrypted delegated private key 138 is the delegated private key 117 that has been encrypted using the encryption key 146. The signing module 126 is able to decrypt the encrypted delegated private key 138 using the decryption key 127 stored at the third party system 120, in order to access the delegated private key 117. The signing module 126 uses the decrypted delegated private key 117 to generate a signature for the data that is to be sent to the recipient. The third party system sends the signature and to original data to the recipient.
The key pair generator 125 of the third party system 120 generates public/private key pairs to facilitate the signing of data on behalf of domain owners. In one embodiment, for each domain owner for which the third party system 120 is to sign data, the key pair generator 125 generates a decryption key 127 (the private key) and an encryption key 146 (the public key). The third party system 120 publishes the encryption key 146 in a record at DNS entry 145 on third party DNS server 140, so that the domain owner system 110 may retrieve it to encrypt a delegated private key 117, thus generating the encrypted delegated private key 138.
The verifying agents 160 verify signatures signed by the third party system 120 and may be configured similar to a computing system described with FIG. 4. For example, the verifying agent 160 may be a server receiving data signed by the third party system 120.
The verifying agent 160 includes a signature verifier 165 to verify the signature of data that it has received. This data may have been signed by the third party system 120 on behalf of a domain owner system 110, or signed by the domain owner system 110 itself. To verify the signature, the signature verifier 165 uses the verifying key 136 published in a DNS entry 135 by the domain owner system 110 and determines whether the signature indicates that the received data is valid and authentic. For example, the data received may have been hashed, with the hash encrypted using the delegated private key 117 by the third party system 120. The signature verifier 165 decrypts the hash using the verifying key 136, and determines whether the hash matches a locally computed hash of the data. If the two hashes match, then the signature verifier 165 indicates that the data is legitimate. Otherwise, the signature verifier 165 indicates that the message is not legitimate.
Using the system 100 described above, a third party system 120 is able to sign messages on behalf of a domain owner. This may provide a method by which registered domain owners can securely distribute delegated private keys to third parties to whom they wish to delegate authority associated with their domain identity. In some embodiments, this provides an advantage such that neither the registered domain owner nor the third party needs to manually update DNS records after an initial setup. Additional details regarding the processes described above are described with reference to FIGS. 2-3.

Example Interaction Diagram for Key Pair Generation

FIG. 2 is an interaction diagram and flow chart illustrating an exemplary process for enabling a third party system 120 to generate keys on behalf of a domain owner according to one embodiment. In one embodiment, FIG. 2 attributes the operations in process to the indicated elements. However, some or all of the steps may be performed by other elements. In addition, some embodiments may perform the operations in parallel, perform the operations in different orders, or perform different operations. Also, it is noted that in one example embodiment the steps and/or modules may be embodied as instructions, e.g., instructions 424, that may be executed by the processor 402 described with respect to FIG. 4.
In one embodiment, the third party system 120 generates 210 a decryption and encryption key pair using one of any number of well-known public key encryption algorithms. A non-limiting example of such a public key encryption algorithm would be 2048-bit Rivest-Shamir-Adleman (RSA).
The decryption key 127, which is the private part of this key pair, may be stored internally for later use. The encryption key 146, which is the public part of this key pair, may be published 215 as a record in DNS entry 145 at third party DNS server 140 such that it is available via DNS to any domains that may wish to delegate signing authority to the third party system 120.
The encryption key 146 may be published under any domain. In one embodiment, the publication of the encryption key record may be such that a) the record is published within a zone registered to the third party system 120 and that b) the record location is shared with the domain owner system 110 from whom the third party system 120 is to obtain a delegated private key.
As a non-limiting example of an encryption key publication, a company Example Corp is the registered owner of the domain “examplecorp.com” and is to act as a third party system 120 for a domain owner. In this case the record including the encryption key 146 for Example Corp could be published at the domain zone “_encr._ddkim.examplecorp.com,” as that domain is in a zone registered to Example Corp. The domain owner would be notified of the location of this record, or may automatically locate it based on a standardized naming scheme of the domain zone indicating the location of a record having the encryption key 146.
In one embodiment, a third party system 120 has multiple records with each record including a separate encryption key 146, each intended for use with one or more domain owners (i.e., an authorizing domain). In such a case, a number of different records having encryption keys 146 may be published by the third party system 120. For example, referring back to the previous example, these records may be published at: 1) senderdomain1._encr._ddkim.examplecorp.com, 2) senderdomain2._encr._ddkim.examplecorp.com, 3) senderdomain3._encr._ddkim.examplecorp.com, and so on.
The format of the record that includes the encryption key 146 may vary. In one embodiment the DNS record with the encryption key 146 is in a format that can be read by the domain owner system 110 (and the key pair generator 115). In one embodiment the record with the encryption key 146 also includes a number of other pieces of information including, but limited to: 1) a token that distinguishes this record from other text records that might be published on this domain, 2) the creation time for the record, 3) an expiration time for the record, 4) a selector field that allows publication of multiple encryption keys 146 on the same subdomain, and 5) a field indicating the algorithm to be used for encryption.
An example of such a format is a record with content “v=ENCDDKIM1; k=< . . . >” where the value following ‘k=’ is the Abstract Syntax Notation One Distinguished Encoding Rules (ASN.1 DER)-encoded encryption key value, assuming that the encryption key was generated using RSA-2048.
In one embodiment, should the third party system 120 need to regenerate the encryption key 146 or decryption key 127, then the third party system 120 repeats the process in a similar manner to the case where the key pair is being generated for the first time. This may be needed due to a failure condition, compromised keys, or any other reason.
On the side of the domain owner, the domain owner system 110 identifies 245 the third party system 120 for delegation of the data signing. In one embodiment, to do this, the domain owner system 110 updates a configuration of the key pair generator 115 with identifying information of the third party system 120. The domain owner system 110 checks for the existence of a DNS entry having the encryption key 146 at the third party DNS server 140. The location of the third party DNS server 140 may be provided to the domain owner system 110 externally, or the domain owner system 110 may be able to discover the location of the third party DNS server 140 using a provided domain name of the third party system 120.
The domain owner system 110 checks for the existence of the encryption key 146 by sending a request 282 to DNS. If a DNS record exists, the domain owner system 110 receives a response 284 with a DNS record that includes the encryption key 146 of the third party system 120. The domain owner system 110 extracts 250 the received encryption key 146 from the record.
In one embodiment, the domain owner system 110 also validates 255 the encryption key 146 through one or more different operations which may include: 1) ensuring that the encryption key in the bytes of the received response 284 can be decoded, 2) that the decoded bytes correspond to a valid key for the expected encryption algorithm, or 3) that the metadata in the DNS record of the response 284 meets some criteria.
For example, the domain owner system 110 may ensure that the received DNS TXT record including the encryption key 146 starts with “v=ENCDDKIM1; k=” and that the value following the ‘k=’ corresponds to an ASN.1 DER encoded RSA public key (i.e., the encryption key).
If the validation of the encryption key 146 fails, then the domain owner system 110 may log an error and/or send an alert to an alert channel (not shown). Otherwise, the domain owner system 110 generates 260 a key pair comprising a delegated private key 117 and verifying key 136, using a selected public key algorithm (e.g., RSA-2048, SHA-1).
The domain owner system 110 encrypts 265 the delegated private key 117 using the encryption key 146. The domain owner system 110 may encrypt the delegated private key 117 using a variety of encryption methods, such as using the public key algorithm used to generate the encryption and decryption key pair and/or the delegated private key and verifying key pair. For example, the encrypting algorithm may be RSA-2048. As another example, the domain owner system 110 may divide the delegated private key 117 into blocks of 1024 bytes, and encrypts each block using RSA-2048 with the encryption key 146 as the encryption key. The domain owner system 110 concatenates the resulting output blocks and encodes them in Base64 to produce the encrypted delegated private key 138.
After encrypting the delegated private key 117 to generate the encrypted delegated private key 138, the domain owner system 110 publishes 270 the encrypted delegated private key 138 on the domain owner DNS server 130. Specifically, in one embodiment, the domain owner system 110 publishes the encrypted delegated private key 138 as a TXT record.
While in some embodiments this DNS TXT record may be made generally available to any client that submits the appropriate DNS query, in other embodiments the results of this query may change based on characteristics of the client or query (e.g. client IP address, time of day). In these latter embodiments, this can enable an additional level of security against leaks of the decryption key 127, which may be used to decrypt the encrypted delegated private key 138. For example, the domain owner system 110 may have configured the domain owner DNS server 130 to only respond with the DNS TXT record containing the encrypted delegated private key 138 to a set of IP addresses known to be owned by the third party system 120 (e.g., using split-horizon DNS or split-view DNS). This ensures that, even if the decryption key 127 is compromised, the encrypted delegated private key 138 can only be used from within infrastructure controlled by the third party system 120.
The domain owner system 110 may publish 270 the DNS record having the encrypted delegated private key 138 with any domain. In one embodiment the domain owner system 110 publishes the DNS record having the encrypted delegated private key 138 within the zone of the domain for which signing is to be authorized. In one embodiment, the domain owner system 110 publishes the DNS record in a location known by the third party system 120, either by convention or by direct communication.
So long as the encryption process is well defined and known to the third party system 120, possession of the decryption key 127 allows the third party system 120 to decrypt the encrypted delegated private key 138 to obtain the delegated private key 117. Moreover, only the third party system 120 is able to decrypt the encrypted delegated private key 138, because such decryption would require possession of the decryption key 127. Thus, the publication of the encrypted delegated private key 138 at the domain owner DNS server 130 is secure.
As an example of the above process, assume a third party system 120 belongs to ExampleCorp, and assume that the domain that wishes to delegate a private key to ExampleCorp is “somedomain.com”. The DNS record including the encrypted delegated private key 138 might be published at a domain of “examplecorp._com._sgn._ddkim.somedomain.com”.
The format of the record including the encrypted delegated private key 138 may vary. In one embodiment, the record includes the encrypted delegated private key 138 in a format (e.g., text, binary, big endian, little endian, etc.) that can be read by the third party system 120. In alternative embodiments, the record may also contain a number of other pieces of information including, but not limited to: 1) a token that distinguishes this record from other text records that might be published on this domain, 2) the creation time for the record, 3) an expiration time for the record, and 4) a selector field that allows publication of multiple records having encrypted delegated private keys on the same subdomain.
Referring again to the above example, the format of the record may be: “v=SGNDDKIM1; k=< . . . >” where the bracketed value following ‘k=’ is the encrypted delegated private key 138 described above.
In one embodiment, the domain owner system 110 also publishes 275 the verifying key 136 as a record to the domain owner DNS server 130. In some embodiments the publication domain and exact format of the verifying key 136 is dictated by the use to which the delegated private key 138 is being put, and the corresponding expectations of the parties using the verifying key 136.
For example, assume that the delegated private key 138 is intended for use as a signing key as part of the DKIM process of email authentication. Then the domain and format of the DNS record having the verifying key 136 is dictated by DKIM. In this case, continuing the earlier example and assuming a selector of ‘examplecorp’, the record would be published at “examplecorp._domainkey.somedomain.com” and the record body may be “v=DKIM1; p=< . . . >”, where the value in < . . . > after the ‘p=’ is the ASN1. DER encoded form of the verifying key 136.
In one embodiment, if the third party system 120 has previously been authorized to sign for the domain for which the delegated private key 138 is being issued, then the domain owner system 110 may further delete any pre-existing records from the domain owner DNS server 130 including any prior encrypted delegated private keys or verifying keys, to prevent use of the now obsolete keys. This process may be delayed, however, to allow any messages which may already have been signed, but not yet verified by their recipients, to be successfully verified.
In one embodiment, the keys are regenerated in response to events other than the initial configuration the third party system 120. For example, the third party system 120 may update its DNS record of the encryption key 146 with a new encrypting key, may trigger this regeneration. In one embodiment, the domain owner system 110 polls the record including the encryption key 146 on a regular basis to detect such changes. In one embodiment, the domain owner system 110 reacts to the changes by generating new delegated private keys and verifying keys, however, in other embodiments, the domain owner system 110 simply encrypts the existing delegated private key with the new encrypting key and publishes the new encrypted delegated private key to the domain owner DNS server 130.
In one embodiment, the domain owner system 110 revokes an existing key pair and replaces it with a new key pair using the process described above. This may occur because of some security breach, or simply as a best practice in response to the passage of time.

Example Interaction Diagram for Data Signing

FIG. 3 is an interaction diagram and flow chart illustrating an exemplary process for enabling a third party system 120 to sign messages on behalf of a domain owner according to one embodiment. In one embodiment, FIG. 3 attributes the operations in process to the indicated elements. However, some or all of the steps may be performed by other elements. In addition, some embodiments may perform the operations in parallel, perform the operations in different orders, or perform different operations. Also, it is noted that in one example embodiment the steps and/or modules may be embodied as instructions, e.g., instructions 424, that may be executed by the processor 402 described with respect to FIG. 4.
The third party system 120 may receive 310 a request to sign a message on behalf of a domain owner (not shown). The third party system 120 may access 315 the encrypted delegated private key 138 stored in a known record location on a DNS server, such as domain owner DNS server 130. If this record is not found, the third party system 120 may indicate an error. Otherwise, the third party system 120 decrypts 320 the encrypted delegated private key 138 using the locally stored decryption key 127 which was previously generated by the third party system 120.
In one embodiment, the third party system 120 validates 325 the decrypted delegated private key 117. The validation of the delegated private key 117 may include a number of possible steps, such as: 1) ensuring that the bytes can be decoded, 2) that the decoded bytes correspond to a valid key for the expected encryption algorithm, or 3) that the metadata in the DNS record including the encrypted delegated private key 138 meets some criteria (e.g., expiration time, creation time, encryption algorithm used, etc.).
For example, the third party system 120 may validate that the format of the DNS record including the encrypted delegated private key matches “v=SGNDDKIM1; k=< . . . >”, and that the value following the ‘k=’ corresponds to an encrypted delegated private key as described above.
Assuming that the delegated private key 117 is found to be valid, the third party system 120 uses the delegated private key 117 as an input into a signing process for data. This data may be a message such as email, may be used for symmetric key exchange, and so on. In one embodiment, the third party system 120 generates 330 a signature of the data using the delegated private key 117. This signature is then verified 350 by the verifying agent 160. The exact details of the process are immaterial to the methods, provided that the signature process employs public key cryptographic signatures. One non-limiting example of such a process would be to use the delegated private key 117 as a DKIM signature for outbound email.
The example of message signing is a real-world example of how the system and methods for the distribution of delegated private keys might be used, but the specific case of message signing should be considered non-limiting. As described above, message signing is an important use case for this method, but is not the only such process where this method adds value.

Example Machine Architecture

FIG. 4 is a block diagram illustrating components of an example machine able to read instructions from a machine-readable medium and execute them in a processor (or controller). Specifically, FIG. 4 shows a diagrammatic representation of a machine in the example form of a computer system 400. The computer system 400 can be used to execute instructions 424 (e.g., program code or software) for causing the machine to perform any one or more of the methodologies (or processes) described herein. In alternative embodiments, the machine operates as a standalone device or a connected (e.g., networked) device that connects to other machines. In a networked deployment, the machine may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a smartphone, an internet of things (IoT) appliance, a network router, switch or bridge, or any machine capable of executing instructions 424 (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute instructions 424 to perform any one or more of the methodologies discussed herein.
The example computer system 400 includes one or more processing units (generally processor 402). The processor 402 is, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a controller, a state machine, one or more application specific integrated circuits (ASICs), one or more radio-frequency integrated circuits (RFICs), or any combination of these. The computer system 400 also includes a main memory 404. The computer system may include a storage unit 416. The processor 402, memory 404 and the storage unit 416 communicate via a bus 408.
In addition, the computer system 406 can include a static memory 406, a display driver 410 (e.g., to drive a plasma display panel (PDP), a liquid crystal display (LCD), or a projector). The computer system 400 may also include alphanumeric input device 412 (e.g., a keyboard), a cursor control device 414 (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a signal generation device 418 (e.g., a speaker), and a network interface device 420, which also are configured to communicate via the bus 408.
The storage unit 416 includes a machine-readable medium 422 on which is stored instructions 424 (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions 424 may also reside, completely or at least partially, within the main memory 404 or within the processor 402 (e.g., within a processor's cache memory) during execution thereof by the computer system 400, the main memory 404 and the processor 402 also constituting machine-readable media. The instructions 424 may be transmitted or received over a network 426 via the network interface device 420.
While machine-readable medium 422 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store the instructions 424. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing instructions 424 for execution by the machine and that cause the machine to perform any one or more of the methodologies disclosed herein. The term “machine-readable medium” includes, but not be limited to, data repositories in the form of solid-state memories, optical media, and magnetic media.

Additional Considerations

Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.
Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms, for example, as illustrated in FIGS. 1-5. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.
In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.
The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).)
The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example embodiments, the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.
Some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory (e.g., a computer memory). These algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an “algorithm” is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as “data,” “content,” “bits,” “values,” “elements,” “symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like. These words, however, are merely convenient labels and are to be associated with appropriate physical quantities.
Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.
As used herein any reference to “one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
Some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. For example, some embodiments may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context.
As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).
In addition, use of the “a” or “an” are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.
Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for a system and a process capable of secure and delegated distribution of private keys via DNS. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims

What is claimed is:

1. A non-transitory computer readable storage medium configured to store instructions, the instructions when executed by a processor cause the processor to:

identify, at a domain owner system, a third party system to delegate signing of messages;

access an encryption key published by the third party system at a domain name system (DNS) record of the third party system;

generate a public-private key pair, the public key of the key pair being a verifying key, and the private key of the key pair being a delegated private key, the delegated private key to be used by the third party system to sign messages on behalf of a domain owner of the domain owner system;

encrypt the delegated private key using the encryption key to generate an encrypted delegated private key;

publish the encrypted delegated private key at a DNS record of the domain owner residing on a DNS server;

configure the DNS server to respond with the encrypted delegated private key only in response to requests for the encrypted delegated private key from network addresses of the third party system; and

publish the verifying key at the DNS record of the domain owner.

2. The computer readable storage medium of claim 1, wherein the storage medium stores further instructions, that when executed by a processor cause the processor to:

validate the encryption key by:

determining that the bytes of the accessed DNS record including encryption key can be decoded; and

determining that the decoded encryption key is generated with the same algorithm used to generate the private-public key pair.

3. The computer readable storage medium of claim 1, wherein the storage medium stores further instructions for the encryption of the delegated private key using the encryption key, that when executed by a processor cause the processor to:

divide the delegated private key into one or more blocks;

encrypt each block of the one or more blocks using the encryption key; and

concatenate each encrypted block together to generate the encrypted delegated private key.

4. The computer readable storage medium of claim 1, wherein the storage medium stores further instructions, that when executed by a processor cause the processor to:

determine that the encryption key published by the third party system has updated;

re-encrypt the delegated private key with the updated encryption key; and

publish the re-encrypted delegated private key at the DNS record of the domain owner.

5. A computer-implemented process comprising:

generating a public-private key pair, the public key of the key pair being an encryption key, and the private key of the key pair being a decryption key;

publishing the encryption key as a domain name service (DNS) record of a third party system;

receiving a request to sign a message on behalf of a domain owner, the message to be sent to a recipient;

accessing an encrypted delegated private key published by the domain owner via a DNS record of the domain owner, the encrypted delegated private key encrypted using the encryption key;

decrypting the encrypted delegated private key using the decryption key;

generating a signature for the message using the delegated private key; and

transmitting the signature and the message to the recipient.

6. The process of claim 5, wherein the generating a public-private key pair further comprises:

generating the public-private key pair using 2048-bit RSA.

7. The process of claim 5, wherein publishing the encryption key as a DNS record of the third party system further comprises:

publishing the encryption key under a DNS record indicating the identity of the domain owner; and

wherein the third party system supports signing messages on behalf of a plurality of domain owners.

8. The process of claim 5, wherein the DNS record of the third party system further comprises a token to distinguish the DNS record from other text records published on a domain of the third party system, a creation time for the DNS record, an expiration time for the DNS record, a selector field to allow publication of multiple encryption keys on the same subdomain, and a field to indicate an algorithm used for encryption.

9. The process of claim 5, wherein the DNS record of the third party system storing the encryption key is a DNS TXT record.

10. The process of claim 5, further comprising validating the accessed delegated private key by determining bytes of the encrypted delegated private key to be decrypted by the decryption key.

11. A non-transitory computer readable storage medium configured to store instructions, the instructions when executed by a processor cause the processor to:

publish the encrypted delegated private key at a DNS record of the domain owner; and

publish the verifying key at the DNS record of the domain owner.

12. The computer readable storage medium of claim 11, wherein the storage medium stores further instructions for the generation of the public-private key pair, that when executed by a processor cause the processor to:

generate the public-private key pair using 2048-bit RSA.

13. The computer readable storage medium of claim 11, wherein the storage medium stores further instructions, that when executed by a processor cause the processor to:

validate the encryption key by:

14. The computer readable storage medium of claim 11, wherein the storage medium stores further instructions for the encryption of the delegated private key using the encryption key, that when executed by a processor cause the processor to:

divide the delegated private key into one or more blocks;

encrypt each block of the one or more blocks using the encryption key; and

15. The computer readable storage medium of claim 11, wherein the DNS record of the domain owner storing the encrypted delegated private key is a DNS TXT record.

16. The computer readable storage medium of claim 11, wherein the storage medium stores further instructions for the publication of the encrypted delegated private key at a DNS record of the domain owner, that when executed by a processor cause the processor to:

configure the DNS server to respond with the encrypted delegated private key only in response to requests for the encrypted delegated private key from network addresses of the third party system.

17. The computer readable storage medium of claim 11, wherein the DNS record of the domain owner further comprises a token that distinguishes the DNS record from other text records that are published on a domain of the domain owner, a creation time for the DNS record, an expiration time for the DNS record, a selector field that allows publication of multiple encryption keys on the same subdomain, and a field indicating an algorithm used for encryption.

18. The computer readable storage medium of claim 11, wherein the storage medium stores further instructions for the publication of the verifying key at the DNS record of the domain owner, that when executed by a processor cause the processor to:

format the DNS record storing the verifying key in a format compatible with DomainKeys Identified Mail (DKIM).

19. The computer readable storage medium of claim 11, wherein the storage medium stores further instructions, that when executed by a processor cause the processor to:

re-encrypt the delegated private key with the updated encryption key; and

20. A computer-implemented process, comprising:

identifying, at a domain owner system, a third party system to delegate signing of messages;

accessing an encryption key published by the third party system at a domain name system (DNS) record of the third party system;

generating a public-private key pair, the public key of the key pair being a verifying key, and the private key of the key pair being a delegated private key, the delegated private key to be used by the third party system to sign messages on behalf of a domain owner of the domain owner system;

encrypting the delegated private key using the encryption key to generate an encrypted delegated private key;

publishing the encrypted delegated private key at a DNS record of the domain owner; and

publishing the verifying key at the DNS record of the domain owner.

21. The process of claim 20, wherein the encrypting the delegated private key using the encryption key further comprises:

dividing the delegated private key into one or more blocks;

encrypting each block of the one or more blocks using the encryption key; and

concatenating each encrypted block together to generate the encrypted delegated private key.

22. The process of claim 20, wherein the DNS record of the domain owner storing the encrypted delegated private key is a DNS TXT record.

23. The process of claim 20, wherein the publishing the encrypted delegated private key at a DNS record of the domain owner further comprises:

publishing the encrypted delegated private key at a DNS record of the domain owner residing on a DNS server;

configuring the DNS server to respond with the encrypted delegated private key only in response to requests for the encrypted delegated private key from network addresses of the third party system.

24. The process of claim 20, further comprising:

determining that the encryption key published by the third party system has updated;

re-encrypting the delegated private key with the updated encryption key; and

publishing the re-encrypted delegated private key at the DNS record of the domain owner.