WO2016130340A1 - Secure and delegated distribution of private keys via domain name service - Google Patents
Secure and delegated distribution of private keys via domain name service Download PDFInfo
- Publication number
- WO2016130340A1 WO2016130340A1 PCT/US2016/015797 US2016015797W WO2016130340A1 WO 2016130340 A1 WO2016130340 A1 WO 2016130340A1 US 2016015797 W US2016015797 W US 2016015797W WO 2016130340 A1 WO2016130340 A1 WO 2016130340A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- key
- private key
- dns
- delegated private
- domain owner
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
- H04L9/3249—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using RSA or related signature schemes, e.g. Rabin scheme
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/24—Key scheduling, i.e. generating round keys or sub-keys for block encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
Definitions
- 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).
- DNS Domain Name Service
- 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.
- systems and methods for securely distributing delegated private keys for public-key cryptography via the Domain Name Service may comprise using public key cryptography to allow secure and automated distribution of private keys via the Domain Name Service (DNS).
- DNS Domain Name Service
- 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.
- 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.
- systems and methods for securely distributing delegated private keys via the Domain Name Service 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.
- systems and methods for securely distributing delegated private keys via the Domain Name Service 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.
- DNS Domain Name Service
- parties that wish to use the public key corresponding to a delegated private key 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.
- a standard signature verification algorithm may then be performed by a message receiver, and the signature may be either verified or rejected.
- the verifying party can use a standard procedure, and does not need to know that a third party entity performed the signature.
- systems and methods for securely distributing delegated private keys via the Domain Name Service 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- DKIM DomainKeys Identified Mail
- 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
- 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 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.
- DNS Domain Name Service
- the Domain Name Service 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.
- 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.
- 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.
- future updates to the delegated private/verifying key pair present similar problems.
- 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.
- 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.
- 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).
- HTTP Hypertext transfer Protocol
- TCP/IP Transmission Control Protocol/Internet Protocol
- URLs Uniform Resource Locators
- DNS Doman Name System
- 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.
- 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.
- 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.
- 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.
- 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.
- the domain owner system 110 includes a key pair generator 115, and a delegated private key 117.
- 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.
- the domain owner system 110 may include additional keys to be used in public key cryptography schemes.
- 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.
- 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.
- the third party system 120 includes a signing module 126, a key pair generator 125, and a decryption key 127.
- 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.
- the third party system 120 may include additional keys to be used in public key cryptography schemes.
- 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.
- 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.
- the key pair generator 125 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 1 10 from whom the third party system 120 is to obtain a delegated private key.
- 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.
- 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.
- 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).
- 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)
- the format of the record that includes the encryption key 146 may vary.
- 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).
- 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.
- the third party system 120 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.
- 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.
- 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.
- 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).
- 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.
- the encrypting algorithm may be RSA-2048.
- 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.
- the domain owner system 110 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.
- this DNS TXT record may be made generally available to any client that submits the appropriate DNS query
- the results of this query may change based on characteristics of the client or query (e.g. client IP address, time of day).
- 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.
- 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.
- the domain owner system 1 10 publishes the DNS record having the encrypted delegated private key 138 within the zone of the domain for which signing is to be authorized.
- the domain owner system 1 10 publishes the DNS record in a location known by the third party system 120, either by convention or by direct communication.
- ExampleCorp is "somedomain.com”.
- the DNS record including the encrypted delegated private key 138 might be published at a domain of
- the format of the record including the encrypted delegated private key 138 may vary.
- 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.
- 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.
- the format of the record may be:
- the domain owner system 1 10 also publishes 275 the verifying key 136 as a record to the domain owner DNS server 130.
- 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.
- the delegated private key 138 is intended for use as a signing key as part of the DKIM process of email authentication.
- the domain and format of the DNS record having the verifying key 136 is dictated by DKIM.
- DER encoded form of the verifying key 136 is
- 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.
- the keys are regenerated in response to events other than the initial configuration the third party system 120.
- the third party system 120 may update its DNS record of the encryption key 146 with a new encrypting key, may trigger this regeneration.
- the domain owner system 110 polls the record including the encryption key 146 on a regular basis to detect such changes.
- 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.
- 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.
- 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. 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.
- 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.).
- 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.
- 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.
- 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.
- 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).
- 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.
- 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.
- PC personal computer
- tablet PC tablet PC
- STB set-top box
- smartphone an internet of things (IoT) appliance
- IoT internet of things
- network router switch or bridge
- 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.
- 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.
- 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
- signal generation device 418 e.g., a speaker
- 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.
- 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.
- 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.
- one or more computer systems e.g., a standalone, client or server computer system
- one or more hardware modules of a computer system e.g., a processor or a group of processors
- software e.g., an application or application portion
- a hardware module may be implemented mechanically or electronically.
- 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.
- processors may be 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).)
- SaaS software as a service
- 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.
- 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).
- the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.
- an "algorithm” is a self-consistent sequence of operations or similar processing leading to a desired result.
- 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.
- 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.
- Coupled and “connected” along with their derivatives.
- 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.
- the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion.
- 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.
- "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).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Storage Device Security (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Description
Claims
Priority Applications (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017560879A JP6526244B2 (en) | 2015-02-14 | 2016-01-29 | Secure Delegated Delivery of Private Keys via Domain Name Service |
CN201680021221.4A CN108604983B (en) | 2015-02-14 | 2016-01-29 | Media and methods for secure delegated distribution of private keys through domain name services |
EP16749597.7A EP3257192B1 (en) | 2015-02-14 | 2016-01-29 | Secure and delegated distribution of private keys via domain name service |
BR112017017425-1A BR112017017425B1 (en) | 2015-02-14 | 2016-01-29 | NON-TRAINER COMPUTER READABLE STORAGE MEDIUM CONFIGURED TO STORE COMPUTER-IMPLEMENTED METHOD AND PROCESS INSTRUCTIONS |
AU2016218340A AU2016218340B2 (en) | 2015-02-14 | 2016-01-29 | Secure and delegated distribution of private keys via domain name service |
CA2976463A CA2976463C (en) | 2015-02-14 | 2016-01-29 | Secure and delegated distribution of private keys via domain name service |
US15/255,118 US9686073B2 (en) | 2015-02-14 | 2016-09-01 | Secure and delegated distribution of private keys via domain name service |
US15/594,505 US9800402B2 (en) | 2015-02-14 | 2017-05-12 | Secure and delegated distribution of private keys via domain name service |
US15/722,680 US20180048460A1 (en) | 2015-02-14 | 2017-10-02 | Secure and delegated distribution of private keys via domain name service |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201562116414P | 2015-02-14 | 2015-02-14 | |
US62/116,414 | 2015-02-14 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/255,118 Continuation US9686073B2 (en) | 2015-02-14 | 2016-09-01 | Secure and delegated distribution of private keys via domain name service |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2016130340A1 true WO2016130340A1 (en) | 2016-08-18 |
Family
ID=56615461
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2016/015797 WO2016130340A1 (en) | 2015-02-14 | 2016-01-29 | Secure and delegated distribution of private keys via domain name service |
Country Status (8)
Country | Link |
---|---|
US (3) | US9686073B2 (en) |
EP (1) | EP3257192B1 (en) |
JP (1) | JP6526244B2 (en) |
CN (1) | CN108604983B (en) |
AU (1) | AU2016218340B2 (en) |
BR (1) | BR112017017425B1 (en) |
CA (1) | CA2976463C (en) |
WO (1) | WO2016130340A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108574569A (en) * | 2017-03-08 | 2018-09-25 | 中国移动通信有限公司研究院 | A kind of authentication method and authentication device based on quantum key |
Families Citing this family (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10205598B2 (en) * | 2015-05-03 | 2019-02-12 | Ronald Francis Sulpizio, JR. | Temporal key generation and PKI gateway |
CA3121771C (en) | 2016-09-30 | 2023-01-03 | The Toronto-Dominion Bank | Information masking using certificate authority |
CN108418678B (en) * | 2017-02-10 | 2019-05-07 | 贵州白山云科技股份有限公司 | A kind of method and device of private key secure storage and distribution |
US10637720B2 (en) * | 2017-02-28 | 2020-04-28 | International Business Machines Corporation | Predictive analytics and device tracking to facilitate minimization of alert events |
US10432584B1 (en) * | 2017-06-23 | 2019-10-01 | Verisign, Inc. | Managing lame delegated domains within a managed DNS service |
US10581909B2 (en) | 2017-06-26 | 2020-03-03 | Oath Inc. | Systems and methods for electronic signing of electronic content requests |
US10715504B2 (en) | 2017-07-12 | 2020-07-14 | Wickr Inc. | Provisioning ephemeral key pools for sending and receiving secure communications |
US11082412B2 (en) | 2017-07-12 | 2021-08-03 | Wickr Inc. | Sending secure communications using a local ephemeral key pool |
US11316666B2 (en) * | 2017-07-12 | 2022-04-26 | Amazon Technologies, Inc. | Generating ephemeral key pools for sending and receiving secure communications |
US10812276B2 (en) | 2018-02-23 | 2020-10-20 | International Business Machines Corporation | Secure trust based distribution of digital certificates |
US10785192B2 (en) | 2018-02-28 | 2020-09-22 | Sling Media Pvt. Ltd. | Methods and systems for secure DNS routing |
US10742696B2 (en) | 2018-02-28 | 2020-08-11 | Sling Media Pvt. Ltd. | Relaying media content via a relay server system without decryption |
US20190305940A1 (en) * | 2018-03-28 | 2019-10-03 | Ca, Inc. | Group shareable credentials |
CN111294379B (en) * | 2018-12-10 | 2022-06-07 | 北京沃东天骏信息技术有限公司 | Block chain network service platform, authority hosting method thereof and storage medium |
US11641363B2 (en) * | 2019-01-14 | 2023-05-02 | Qatar Foundation For Education, Science And Community Development | Methods and systems for verifying the authenticity of a remote service |
US11212139B2 (en) | 2019-08-29 | 2021-12-28 | Charter Communications Operating, Llc | Border gateway protocol (BGP) hijacks prefix signing using public/private keys |
US11296872B2 (en) * | 2019-11-07 | 2022-04-05 | Micron Technology, Inc. | Delegation of cryptographic key to a memory sub-system |
CN110969431B (en) * | 2019-11-27 | 2024-04-19 | 北京贵泽系统技术有限公司 | Secure hosting method, device and system for private key of blockchain digital coin |
US11743257B2 (en) * | 2020-01-22 | 2023-08-29 | Valimail Inc. | Automated authentication and authorization in a communication system |
EP4094418A4 (en) | 2020-01-22 | 2024-03-20 | Valimail Inc. | Interaction control list determination and device adjacency and relative topography |
WO2021150789A1 (en) * | 2020-01-22 | 2021-07-29 | Valimail Inc. | Centrally managed pki provisioning and rotation |
US12069095B2 (en) | 2020-01-22 | 2024-08-20 | Valimail Inc. | Automated authentication and authorization in a communication system |
CN111698088B (en) * | 2020-05-28 | 2022-10-18 | 平安科技(深圳)有限公司 | Key alternation method, key alternation device, electronic equipment and medium |
CN112287364A (en) * | 2020-10-22 | 2021-01-29 | 同盾控股有限公司 | Data sharing method, device, system, medium and electronic equipment |
US11695745B2 (en) | 2020-12-01 | 2023-07-04 | Valimail Inc. | Automated DMARC device discovery and workflow |
WO2022119586A1 (en) | 2020-12-01 | 2022-06-09 | Valimail Inc. | Automated device discovery and workflow enrichment |
CN112751879B (en) * | 2021-01-08 | 2023-06-27 | 北京润通丰华科技有限公司 | Communication encryption and decryption method of mimicry DNS defense system |
US11271894B1 (en) * | 2021-03-10 | 2022-03-08 | Accenture Global Solutions Limited | Systems, devices, and methods for private query and exchange of domain information |
CN114142995B (en) * | 2021-11-05 | 2023-08-22 | 支付宝(杭州)信息技术有限公司 | Key security distribution method and device for block chain relay communication network |
US11991139B2 (en) | 2022-09-16 | 2024-05-21 | Valimail Inc. | Automated email protocol analyzer in a privacy-safe environment |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020059286A1 (en) * | 2000-11-15 | 2002-05-16 | International Business Machines Corporation | Trusted computing platform with dual key trees to support multiple public/private key systems |
US20050039019A1 (en) * | 2003-08-26 | 2005-02-17 | Yahoo! Inc. | Method and system for authenticating a message sender using domain keys |
US20060230461A1 (en) * | 2003-05-30 | 2006-10-12 | Ralf Hauser | System and method for secure communication |
US20080059787A1 (en) * | 2006-02-03 | 2008-03-06 | Hohenberger Susan R | Unidirectional proxy re-encryption |
US20090198997A1 (en) * | 2006-11-20 | 2009-08-06 | Tet Hin Yeap | System and method for secure electronic communication services |
US20100299399A1 (en) * | 2009-04-15 | 2010-11-25 | Kelly Wanser | System and Method for the Management of Message Policy |
US20120060033A1 (en) * | 2009-03-03 | 2012-03-08 | Giuliani Kenneth J | Split key secure access system |
US20120179801A1 (en) * | 2011-01-07 | 2012-07-12 | Michael Luna | System and method for reduction of mobile network traffic used for domain name system (dns) queries |
US20120216040A1 (en) * | 2011-02-17 | 2012-08-23 | Ram Tanamy | System for Email Message Authentication, Classification, Encryption and Message Authenticity |
US20140189348A1 (en) * | 2012-12-31 | 2014-07-03 | Microsoft Corporation | Integrated Data Deduplication and Encryption |
US20140289509A1 (en) * | 2013-03-22 | 2014-09-25 | Davit Baghdasaryan | System and method for delegating trust to a new authenticator |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6834112B1 (en) * | 2000-04-21 | 2004-12-21 | Intel Corporation | Secure distribution of private keys to multiple clients |
US7773754B2 (en) * | 2002-07-08 | 2010-08-10 | Broadcom Corporation | Key management system and method |
PL1636680T3 (en) * | 2003-06-10 | 2016-10-31 | Systems and methods for conducting secure payment transactions using a formatted data structure | |
US6986049B2 (en) * | 2003-08-26 | 2006-01-10 | Yahoo! Inc. | Method and system for authenticating a message sender using domain keys |
CA2586223A1 (en) * | 2007-04-19 | 2007-07-18 | Cannotech Experts-Conseils Inc. | Opt-in process and nameserver system for ietf dnssec |
US20100011420A1 (en) * | 2008-07-02 | 2010-01-14 | Barracuda Networks Inc. | Operating a service on a network as a domain name system server |
US20110296171A1 (en) | 2010-05-28 | 2011-12-01 | Christina Fu | Key recovery mechanism |
JP2012199607A (en) * | 2011-03-18 | 2012-10-18 | Anritsu Networks Kk | Dnssec proxy device |
US9130917B2 (en) * | 2011-05-02 | 2015-09-08 | Verisign, Inc. | DNSSEC signing server |
-
2016
- 2016-01-29 AU AU2016218340A patent/AU2016218340B2/en active Active
- 2016-01-29 EP EP16749597.7A patent/EP3257192B1/en active Active
- 2016-01-29 BR BR112017017425-1A patent/BR112017017425B1/en active IP Right Grant
- 2016-01-29 CA CA2976463A patent/CA2976463C/en active Active
- 2016-01-29 WO PCT/US2016/015797 patent/WO2016130340A1/en active Application Filing
- 2016-01-29 CN CN201680021221.4A patent/CN108604983B/en active Active
- 2016-01-29 JP JP2017560879A patent/JP6526244B2/en active Active
- 2016-09-01 US US15/255,118 patent/US9686073B2/en active Active
-
2017
- 2017-05-12 US US15/594,505 patent/US9800402B2/en active Active
- 2017-10-02 US US15/722,680 patent/US20180048460A1/en not_active Abandoned
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020059286A1 (en) * | 2000-11-15 | 2002-05-16 | International Business Machines Corporation | Trusted computing platform with dual key trees to support multiple public/private key systems |
US20060230461A1 (en) * | 2003-05-30 | 2006-10-12 | Ralf Hauser | System and method for secure communication |
US20050039019A1 (en) * | 2003-08-26 | 2005-02-17 | Yahoo! Inc. | Method and system for authenticating a message sender using domain keys |
US20080059787A1 (en) * | 2006-02-03 | 2008-03-06 | Hohenberger Susan R | Unidirectional proxy re-encryption |
US20090198997A1 (en) * | 2006-11-20 | 2009-08-06 | Tet Hin Yeap | System and method for secure electronic communication services |
US20120060033A1 (en) * | 2009-03-03 | 2012-03-08 | Giuliani Kenneth J | Split key secure access system |
US20100299399A1 (en) * | 2009-04-15 | 2010-11-25 | Kelly Wanser | System and Method for the Management of Message Policy |
US20120179801A1 (en) * | 2011-01-07 | 2012-07-12 | Michael Luna | System and method for reduction of mobile network traffic used for domain name system (dns) queries |
US20120216040A1 (en) * | 2011-02-17 | 2012-08-23 | Ram Tanamy | System for Email Message Authentication, Classification, Encryption and Message Authenticity |
US20140189348A1 (en) * | 2012-12-31 | 2014-07-03 | Microsoft Corporation | Integrated Data Deduplication and Encryption |
US20140289509A1 (en) * | 2013-03-22 | 2014-09-25 | Davit Baghdasaryan | System and method for delegating trust to a new authenticator |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108574569A (en) * | 2017-03-08 | 2018-09-25 | 中国移动通信有限公司研究院 | A kind of authentication method and authentication device based on quantum key |
CN108574569B (en) * | 2017-03-08 | 2021-11-19 | 中国移动通信有限公司研究院 | Authentication method and authentication device based on quantum key |
Also Published As
Publication number | Publication date |
---|---|
US20180048460A1 (en) | 2018-02-15 |
US20160373252A1 (en) | 2016-12-22 |
EP3257192A4 (en) | 2018-08-29 |
CA2976463C (en) | 2024-01-16 |
BR112017017425B1 (en) | 2024-04-30 |
CN108604983B (en) | 2021-06-15 |
JP6526244B2 (en) | 2019-06-05 |
AU2016218340B2 (en) | 2019-01-03 |
US20170250797A1 (en) | 2017-08-31 |
CN108604983A (en) | 2018-09-28 |
EP3257192A1 (en) | 2017-12-20 |
BR112017017425A2 (en) | 2018-04-03 |
CA2976463A1 (en) | 2016-08-18 |
US9800402B2 (en) | 2017-10-24 |
JP2018506939A (en) | 2018-03-08 |
EP3257192B1 (en) | 2020-08-12 |
AU2016218340A1 (en) | 2017-08-31 |
US9686073B2 (en) | 2017-06-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9800402B2 (en) | Secure and delegated distribution of private keys via domain name service | |
US10659468B2 (en) | Access control values | |
US8527769B2 (en) | Secure messaging with read-undeniability and deletion-verifiability | |
US11457018B1 (en) | Federated messaging | |
JP2018506939A5 (en) | ||
US7822974B2 (en) | Implicit trust of authorship certification | |
US8468339B2 (en) | Efficient security information distribution | |
US7120793B2 (en) | System and method for electronic certificate revocation | |
US11329997B2 (en) | Signed message header storing sender account authentication method | |
US10250576B2 (en) | Communication of messages over networks | |
US20160149711A1 (en) | Distributed identification system for peer to peer message transmission | |
US11349659B2 (en) | Transmitting an encrypted communication to a user in a second secure communication network | |
US8719574B2 (en) | Certificate generation using virtual attributes | |
US10791196B2 (en) | Directory lookup for federated messaging with a user from a different secure communication network | |
US11368442B2 (en) | Receiving an encrypted communication from a user in a second secure communication network | |
CN113691495B (en) | Network account sharing and distributing system and method based on asymmetric encryption | |
JP2010245712A (en) | Id validity management device, communication device, id validity management method, data processing method and program | |
Melara | CONIKS: Preserving Secure Communication with Untrusted Identity Providers | |
EP4378120A1 (en) | Method, cloud-service method, cloud server, self-sovereign identity method for providing a self-sovereign identity cloud service to a user |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16749597 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2976463 Country of ref document: CA |
|
ENP | Entry into the national phase |
Ref document number: 2017560879 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
REG | Reference to national code |
Ref country code: BR Ref legal event code: B01A Ref document number: 112017017425 Country of ref document: BR |
|
ENP | Entry into the national phase |
Ref document number: 2016218340 Country of ref document: AU Date of ref document: 20160129 Kind code of ref document: A |
|
REEP | Request for entry into the european phase |
Ref document number: 2016749597 Country of ref document: EP |
|
ENP | Entry into the national phase |
Ref document number: 112017017425 Country of ref document: BR Kind code of ref document: A2 Effective date: 20170814 |