text: US20160285836A1 - Privacy Preserving Registry Browsing - Google Patents
  US20160285836A1
  US20160285836A1 US15/173,608 US201615173608A US2016285836A1 US 20160285836 A1 US20160285836 A1 US 20160285836A1 US 201615173608 A US201615173608 A US 201615173608A US 2016285836 A1 US2016285836 A1 US 2016285836A1
  US15/173,608
  US9866536B2 (en
  2016-06-03 Application filed by VeriSign Inc filed Critical VeriSign Inc
  2016-06-03 Priority to US15/173,608 priority patent/US9866536B2/en
  2016-06-03 Assigned to VERISIGN, INC. reassignment VERISIGN, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KALISKI, BURTON S., JR.
  2016-09-29 Publication of US20160285836A1 publication Critical patent/US20160285836A1/en
  2018-01-09 Publication of US9866536B2 publication Critical patent/US9866536B2/en
  A method. system. and computer-readable memory containing instructions include requesting a tokenizing authority to provide a tokenized string that represents a domain name. using the tokenized domain name string to perform a lookup against a database of registered tokenized domain name strings, determining whether the tokenized domain name string exists in the database, and returning results based on the existence of tokenized domain name strings and optionally variants thereof. The method, system, and computer-readable memory may further include returning an encryption key corresponding to an encrypted record of information related to the domain name corresponding to the tokenized domain name string.
  This application is a continuation of the co-pending U.S. patent application titled, "PRIVACY PRESERVING REGISTRY BROWSING," filed on Jan. 2, 2013 and having application Ser. No. 13/732,815, which is a continuation-in-part of US patent application titled, "PRIVACY PRESERVING DATA QUERYING," filed on Oct. 25, 2012 and having application Ser. No. 13/660,838, now U.S. Pat. No. 9,202,079. The subject matter of these related applications is hereby incorporated herein by reference.
  The tokenizing authority 140 and tokenized list holder 150 may be implemented in software as software modules or programs that may be stored on one or more local or remote computing systems. For example, the functionality of the tokenizing authority 140 and tokenized list holder 150 may each comprise one or more applications, including computer-readable instructions which, when executed by a processor, cause one or more computers to perform steps of a method. In implementations, the architecture illustrated in FIG. 1 may support execution of program code on one or more computers to accomplish the overall system and method. Computer-readable instructions may be stored on a computer-readable medium, without limitation such as a memory or disk. Such media typically provide non-transitory storage. One or more of the components depicted in FIG. 1 may be hardware components or combinations of hardware, software, operating system and other resources, such as, for example, special purpose computers or general purpose computers, in implementations, one or more of the components shown in FIG. 1 can also or instead be implemented in the form of physical or virtual network-based software or services. Any one or more of those components can for instance be hosted or implemented using cloud-based networks.
  A computer or computer system, such as those that may comprise any of the components illustrated in FIG. 1, may also include internal or external databases. The database may compose one or more individual databases or databases configured to act together. The database may be implemented in a commercial, open source, or proprietary database program or may be contained in log flies, flat files, or any other data storage mechanism. The database may alter natively be referred to as to data store, store, or storage. The components of a computer or computer system may, among other things, connect through a local bus interface or over a local or wide area network, either individually or any combination thereof. The components depicted in FIG. 1 may be operatively connected to one another via a network, not shown, such as the Internet, an intranet, or any type of wired or wireless communication system. Connections may be implemented through a direct communication link, a local area network (LAN), a wide area network (WAN) and/or other suitable connections. In implementations, some or all of the entities and resources shown in FIG. 1 can also be implemented in a cloud-based network, or other distributed platform, network, service, or system.
  In step 220, the tokenizing authority 140 can tokenize the domain name. In tokenizing the domain name, the tokenizing authority 140 may optionally run a separation algorithm on the domain name to split the domain name into two or more distinct segments or pieces, and tokenize those pieces independently. For example, the domain name "ExampleName.com" could be split into two strings "ExampleName" and "com." Each of these strings in turn may be tokenized separately. Thus, the information being tokenized can either be a fully qualified domain name (FQDN) such "ExampleName.com" or a portion of a FQDN such as a be "ExampleName" or some other portion such as "Example". (In this example, only two levels of labels are given, but in longer domain names, third, fourth or other levels, or multiple levels, or other portions, could be tokenized, and searched in a repository of information of the appropriate type. If only the second-level label, i.e., "Example" is tokenized and searched, then the appropriate repository may be one in which the first-level label, i.e., "com", is a known and agreed value.) With separate tokenization strings, in the event that the desired domain name is unavailable for registration, the one or more registries 130 may be able to suggest alternative names even though they may not know either the desired name or the pieces of the desired name. This will be explained in greater detail below. As another example, the domain name "ExampleBiaster.com" could be split into three strings, "Example," "Blaster," and "com." Alternatively, the TLD portion need not be tokenized at all. Thus, in this example the word "Example" and "Blaster" would be tokenized, but "com" would not. This would allow a registrar 120, the one or more registries 130, or tokenized list holder 150 to more easily provide at least alternative TLDs to the TLD specified in the privacy preserving domain name query.
  FIG. 4 illustrates an example process 400 that uses tokenized domain names for domain name availability lookup, and includes techniques to suggest variants of the tokenized domain name submitted for lookup. In step 410, the tokenized domain string is received by, for example, the tokenized list holder 150. The tokenized domain string may consist of one or more tokenized strings in addition to the desired TLD in the clear. For example, if the desired domain name was "ExampleName.com," then the tokenized domain string may comprise "ExampleName" in the tokenized format and an indicator that "com" is the desired TLD. Where step 220, as discussed above, splits the domain name prior to tokenization, the tokenized domain string may comprise multiple singular tokenized strings in addition to the indicator of the desired TLD. For example, if the desired domain string was "ExampleBiaster.com," then the strings "Example" and "Blaster" may both be tokenized individually, and the request may include both strings, an indicator of the order of the preference of the strings, an indicator of any desired separation characters such as a dash ("-"), and an indicator of the desired TLD.
  In step 420, the tokenized list holder 150 may compare the received tokenized string or strings to the tokenized domain name database. In the case of multiple strings, the tokenized domain name database may support comparing multiple strings to the list of tokenized registered domain names. In other words, the tokenizing authority 140 may return tokenized versions of domain names consistently when processing a domain name that may be split. The database maintained by the tokenized list holder 150 may contain multiple versions of the same domain name, to support options such as split string tokenization and whole string tokenization. For example, when the process 200 is executing step 220 for domain names that have already been registered, the tokenizing authority 140 may return multiple versions of the tokenized domain string format for a particular domain name, e.g., for the domain name "ExampleBiaster.com," the tokenizing authority 140 may return one result for the entire string "ExampleBiaster.com," one result for a non-TLD-specific split string "ExampleBlaster" and a "com" indicator, and one result for a completely split string "Example," "Blaster," and an indicator for "com." By storing multiple versions of the same domain string, the one or more registries 130 can support varying levels of privacy preservation for domain name lookups, where less domain name splitting is presumed to be more private.
  In step 520, where the domain name lookup request includes multiple tokenized strings, the tokenizing authority 140 may develop variants by mixing the order of the tokenized strings. For example, if the availability of the domain name "ExampleBiaster.com" is requested and "Example" and "Blaster" were tokenized separately, then a variant could include "BiasterExample.com."
  In step 530, where the domain name lookup request includes multiple tokenized strings, the tokenizing authority 140 may develop variants by including separator characters between tokenized strings. For example, if the availability of the domain name "ExampleBiaster.com" is requested and "Example" and "Blaster" were tokenized separately then a variant may include "Example-Biaster.com." Presently, the only non-alphanumeric character allowed in a domain name is a dash ("-"), but other separator characters may include characters such as "e," "o," "i," and so forth. For example, another variant of "ExampleBiaster.com" could be "ExampleEBiaster.com." One skilled in the art will understand the separator characters may include a string of any number of characters. In the case where separator characters are not tokenized, however, for practical purposes, the number of available separator character strings will likely be a limited set of characters because the tokenized list holder 150 must hold all the variants of registered domain names in a tokenized or partially tokenized form.
  As noted, it will be appreciated that other techniques and approaches for developing variants for the domain name substrings or other components can be used. Those other techniques can be or include, for instance, those shown in co-pending U.S. application Ser. No. 9/970,096, filed Oct. 2, 2001, entitled "Determining Alternative Textual Identifiers Such As For Registered Domain Names," assigned or under obligation to the same entity as this application, which co-pending application is incorporated by reference in its entirety herein. Those other techniques can likewise include, for further instance, those shown in co-pending U.S. application Ser. No. 13/249,429, filed Sep. 30, 2011, entitled "Domain Name Tokenization and Alternative Domain Name Generation," assigned or under obligation to the same entity as this application, which co-pending application is likewise incorporated by reference in its entirety herein.
  As an example of a typical blind signature technique, a first party, Alice, obtains the signature of a second party, Bob, on a message m via the following or similar steps. Alice first computes a blinded version m′ of the message m, and sends m′ to Bob. Bob then computes a signature s′ on the message m using Bob's signature function, and returns s′ to Alice. Alice then unblinds s′ to recovers, the actual signature on m. One example of such a technique involves the RSA signature scheme, where Bob's signature function ism′=(sf mod n where (n,d) is Bob's RSA private key. Alice obtains Bob's RSA public key (n,e). An appropriate blinding function in this case is for Alice to compute m′=mr: mod n where r is a random value between 0 and n−1. The signature s′ can be unblinded by Alice by computing s=s′{1 mod n. (The well-known proof that unblinding reverses blinding is given by expanding the formulas: s=s′{1=(m′)d;1=(mr)d,−1=md red,−1=md mod n.)
  Third, the tokenizing authority 140 computes the signature s′ on the blinded input m′, and returns' as the blinded output. Fourth, the potential registrant 110 or one or more registries 130 unblinds the blinded output s′, obtaining the actual signature s as above. Fifth, the potential registrant 110 or one or more registries 130 applies a cryptographic hash function to the signature s (and possibly other inputs) to map it to a tokenized domain name. Thus, one implementation may have m=H1(domain name) where H1 is a first hash function, and tokenized domain name H2(s) where H2 is a second (optionally distinct) hash function.
  While FIG. 9 illustrates certain illustrative logging and inference techniques, other techniques related to logging data related to the tokenization and registration process can be used. For instance, logging, inference, and other associated techniques such as those described in U.S. Pat. No. 8,224,923, issued Jul. 17, 2012, entitled "Characterizing Unregistered Domain Names," and in co-pending U.S. application Ser. No. 12/755,049 filed Apr. 6, 2010, entitled "Domain Popularity Scoring," each of which is assigned or under obligation to the same entity as this application, and each of which is incorporated by reference in its entirety herein, can also or instead be used.
  Although a single tokenizing function is sufficient to enable multiple requesters and data sources, it may be beneficial to have multiple tokenizing functions. Different tokenizing functions may be employed at different points in time, to reduce concern about the compromise of secret keys associated with the functions. Different functions may be employed for data values of different classifications, which may be based on security attributes, geolocation, or other factors. The data source may select one or more tokenizing functions to employ for a given data value based on the classification(s) of the data. Likewise, a requester may select one or more tokenizing functions based on the requesters permissions to access data values of certain classification(s). A requester may thus only learn that its data value matches a data source's data value if the requester has permission for the tokenizing function associated with appropriate classification. Furthermore, different tokenizing functions may be employed for determining encryption or decryption keys depending on metadata classification, and the tokenizing function for determining the tokenized query term may be different than the tokenization function(s) for determining the associated encryption or decryption key(s). Different metadata associated with the same data value may have different classifications and would then be encrypted with different keys. Thus, even if a requester is able to learn that its data value matches a data source's data value, the requester may only obtain associated metadata on a "need-to-know" basis.
  receiving a client computer request for information related to determine domain name registration availability that comprises at least one tokenized string representing the domain name, wherein the tokenized string was tokenized by a tokenizing authority computer different from the client computer and operatively coupled to the client computer through a network;
  comparing the at least one tokenized string to a store of tokenized strings, wherein the tokenized strings in the store have been tokenized by a second tokenizing authority based on a tokenizing function equivalent to a tokenizing function of the first tokenizing authority;
  determining whether the at least one tokenized string is contained in the store of tokenized strings; and
  4. The method of claim 1, further comprising determining the at least tokenized stream from the domain name using a blinding function and an unblinding function.
  5. The method of claim 1, wherein the request comprises a request for encrypted information related to a domain name.
  6. The method of claim 6, wherein the at least one tokenized string is contained in the store of tokenized strings, and further comprising determining that the encrypted information is available, and returning the encrypted information.
  7. A non-transitory computer-readable storage medium including instructions that, when executed by a processor, cause the processor to perform the steps of:
  US15/173,608 2012-10-25 2016-06-03 Privacy preserving registry browsing Active US9866536B2 (en)
  US13/732,815 Continuation US9363288B2 (en) 2012-10-25 2013-01-02 Privacy preserving registry browsing
  US15/271,192 Continuation-In-Part US20170262651A1 (en) 2012-10-25 2016-09-20 Privacy - Preserving Data Querying with Authenticated Denial of Existence
  US20160285836A1 true US20160285836A1 (en) 2016-09-29
  US9866536B2 US9866536B2 (en) 2018-01-09
  JP5144991B2 (en) 2006-08-22 2013-02-13 株式会社エヌ・ティ・ティ・データ Ciphertext decryption authority delegation system
  CN102119506A (en) 2008-05-27 2011-07-06 科技研究局 A method and system for sharing data
  KR101190059B1 (en) 2008-12-12 2012-10-16 한국전자통신연구원 Method for data encryption and method for conjunctive keyword search of encrypted data
  US9363288B2 (en) 2016-06-07
  Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KALISKI, BURTON S., JR.;REEL/FRAME:038808/0848