Patent Publication Number: US-9430655-B1

Title: Split tokenization

Description:
BACKGROUND 
     Some conventional secure computer systems protect a secret by exchanging a token for that secret. For example, suppose that a merchant accepts credit cards for payment. For such a merchant, locally storing customers&#39; credit card numbers carries a risk of exposing those credit card numbers to an adversary. The merchant can replace each credit card number with a corresponding token, or a number meaningless to the adversary, generated by a secure tokenization server. The merchant would then recover a credit card number by sending the corresponding token back to the tokenization server. 
     The tokenization server generates tokens from secrets in such a way that an adversary would have very little chance in deducing the secret from the token. For example, the tokenization server can generate a token from a credit card number by applying a cryptographic function to the credit card number. Such a cryptographic function relies on a key which is used to recover the credit card number from the token. The tokenization server can also use a lookup table in a database to recover the credit card number from the token. 
     SUMMARY 
     Unfortunately, there are deficiencies with the above-described conventional secure computer systems. For example, an adversary may compromise the tokenization server in order to illicitly gain access to secrets stored there. Along the lines of the above example, if such an adversary were to gain access to a key used in a cryptographic function for generating tokens, that adversary could compromise credit card numbers from any tokens generated from that key. Further, that adversary could also compromise credit card numbers taken from a database on the tokenization server. 
     In contrast to the conventional secure computer systems having a tokenization server that stores secrets that can be compromised by a single illicit access of the tokenization server, an improved technique involves providing protection of secrets by splitting the secret into secret shares and providing tokens for each secret share. Along these lines, a terminal splits a secret such as a credit card number into shares. The terminal then transmits each share to a separate and distinct token server. Each token server, upon receiving a secret share, generates a corresponding token and sends that token to an application server. In some cases, when a user at the application server requires access to the secret, the application server sends each token to the token server form which the token was generated. The token servers each send, in return, a secret share to the application server. The application server combines the secret shares to recover the secret. 
     Advantageously, the improved technique creates conditions in which an adversary has a much smaller chance of retrieving a secret because that secret is split among several token servers. For example, if the adversary can access a token server with probability ρ, then that adversary may access two token servers with probability ρ 2 &lt;ρ. Further, the chance of such an adversary successfully compromising the secret may be further reduced by proactively updating the shares in such a way as to preserve the secret. 
     One embodiment of the improved technique is directed to a method of protecting a secret. The method includes performing a secret splitting operation that produces a first secret share and a second secret share. The method also includes sending the first secret share to a first token server, the first token server being constructed and arranged to i) generate a first token from the first secret share and ii) send the first token to an application server. The method further includes sending the second secret share to a second token server that is different from the first token server, the second token server being constructed and arranged to i) generate a second token from the second secret share and ii) send the second token to the application server, the application server being constructed and arranged to recover the secret from the first secret share and the second secret share by exchanging the first token for the first secret share with the first token server and exchanging the second token for the second secret share with the second token server. 
     Another embodiment of the improved technique is directed to a method of recovering a secret. The method includes sending a first token to a first token server, the first token server being constructed and arranged to generate a first secret share in response to receiving the first token, the first secret share being based on the first token. The method also includes sending a second token to a second token server, the second token server being constructed and arranged to generate a second secret share in response to receiving the second token, the second secret share being based on the second token. The method further includes receiving the first secret share from the first token server and receiving the second secret share from the second token server. The method further includes performing a combination operation on the first secret share and the second secret share to produce the secret. 
     Additionally, some embodiments of the improved technique are directed to a system constructed and arranged to protect a secret. The system includes a network interface, memory, and a controller including controlling circuitry constructed and arranged to carry out the method of protecting a secret. 
     Furthermore, some embodiments of the improved technique are directed to a computer program product having a non-transitory computer readable storage medium which stores code including a set of instructions to carry the method of protecting a secret. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWING 
       The foregoing and other objects, features and advantages will be apparent from the following description of particular embodiments of the invention, as illustrated in the accompanying figures in which like reference characters refer to the same parts throughout the different views. 
         FIG. 1  is a block diagram illustrating an example electronic environment for carrying out an aspect of the improved technique. 
         FIG. 2  is a block diagram illustrating an example electronic environment for carrying out another aspect of the improved technique. 
         FIG. 3 a    is a block diagram illustrating an example terminal within the electronic environment shown in  FIG. 1 . 
         FIG. 3 b    is a block diagram illustrating an example application server within the electronic environments shown in  FIG. 2 . 
         FIG. 3 c    is a block diagram illustrating an example token server within the electronic environments shown in  FIGS. 1 and 2 . 
         FIG. 4  is a block diagram illustrating an example proactivization engine within the token server shown in  FIG. 3 . 
         FIG. 5  is a flow chart illustrating an example variable schedule based on epochs of random length within the electronic system shown in  FIG. 1 . 
         FIG. 6  is a flow chart illustrating a method of carrying out the improved technique within the electronic environment shown in  FIG. 2 . 
     
    
    
     DETAILED DESCRIPTION 
     An improved technique involves providing protection of secrets by splitting the secret into secret shares and providing tokens for each secret share. Along these lines, a terminal splits a secret such as a credit card number into shares. The terminal then transmits each share to a separate and distinct token server. Each token server, upon receiving a secret share, generates a corresponding token and sends that token to an application server. In some cases, when a user at the application server requires access to the secret, the application server sends each token to the token server form which the token was generated. The token servers each send, in return, a secret share to the application server. The application server combines the secret shares to recover the secret. 
     Advantageously, the improved technique creates conditions in which an adversary has a much smaller chance of retrieving a secret because that secret is split among several token servers. For example, if the adversary can access a token server with probability ρ, then that adversary may access two token servers with probability ρ 2 &lt;ρ. Further, the chance of such an adversary successfully compromising the secret may be further reduced by proactively updating the shares in such a way as to preserve the secret. 
       FIG. 1  illustrates an example electronic environment  10  for carrying out the improved technique. Electronic environment  10  includes terminal  12 , application server  14 , token server  16   a ,  16   bm    16   c ,  16   d  (token servers  16 ), and communications medium  32 . 
     Terminal  12  is configured to accept a secret  18 ′ such as a credit card number from a user (not pictured). Terminal  12  is further configured to split secret  18  into a set of secret shares  18   a ,  18   b ,  18   c ,  18   d  (secret shares  18 ) and send secret shares  18  to corresponding token servers  16 . In some arrangements, such as in an on-line shopping scenario, terminal  12  takes the form of a desktop computer. In other arrangements, such as in a brick-and-mortar shopping scenario, terminal  12  takes the form of a credit card reader. 
     Application server  14  is configured to receive tokens  20   a ,  20   b ,  20   c , and  20   d  (tokens  20 ) from token servers  16 . Application server  14  typically takes the form of a web server, although, in some arrangements, application server may be a desktop computer. 
     Token servers  16   a ,  16   b ,  16   c , and  16   d  (token server  16 ) are configured to receive a secret share  18   a ,  18   b ,  18   c , or  18   d , respectively, and generate a token  20   a ,  20   b ,  20   c , or  20   d , respectively, from corresponding secret share  18 . Token servers  16  are further configured to send tokens  20  to application server  14 . 
     Communication medium  32  provides network connections between terminal  12 , application server  14 , and token servers  16 . Communications medium  32  may implement a variety of protocols such as TCP/IP, UDP, ATM, Ethernet, Fibre Channel, combinations thereof, and the like. Furthermore, communications media  32  may include various components (e.g., cables, switches/routers, gateways/bridges, NAS/SAN appliances/nodes, interfaces, etc.). Moreover, the communications medium  32  are capable of having a variety of topologies (e.g., queue manager-and-spoke, ring, backbone, multi drop, point to-point, irregular, combinations thereof, and so on). 
     In some arrangements, communications medium  32  includes a content delivery network (CDN) including a set of Edge servers (not pictured) through which content is routed between terminal  12  and token servers  16 . 
     During operation, terminal  12  receives a secret  18 ′ from a user. For example, terminal  12  receives a credit card number from the user as the user attempts to make a purchase. In some arrangements, the user inputs the credit card number into terminal  12  via an internet browser. In other arrangements, the user inputs the credit card number into terminal  12  via a swiping mechanism in a dedicated device or a smartphone. 
     Upon receiving secret  18 ′, terminal  12  performs a splitting operation on secret  18 ′ to produce secret shares  18   a ,  18   b ,  18   c , and  18   d  such that a combination operation (i.e., an inverse of the splitting operation) recovers secret  18 ′. For example, suppose that the splitting operation involves generating three random, 16-digit numbers, and then performing a bitwise XOR operation on those three random numbers and a credit card number  18 ′ input into terminal  12  to produce a fourth number. Each of the generated random numbers and the fourth number then is a secret share  18 . The credit card number  18 ′ may be recovered by performing the bitwise XOR operation on the secret shares  18 . In some arrangements, the Edge servers in the CDN may perform the splitting operation. 
     Terminal  12  also generates a random nonce  22  along with secret shares  18 . Terminal  12  provides random nonce  22  as proof that terminal  12  generated secret shares  18  together. 
     Upon producing secret shares  18   a ,  18   b ,  18   c , and  18   d , terminal  12  sends each secret share  18  to a corresponding token server  16   a ,  16   b ,  16   c , or  16   d  via communications medium  32 . Terminal  12  also sends random nonce  22  to each token server  16  with corresponding secret share  18 . Terminal  12  also sends a destination address (i.e., IP address) of application server to each token server with random nonce  22  and corresponding secret share  18 . In some arrangements, terminal  12  encrypts secret share  18 , random nonce  22 , and the destination address (i.e., using a public key of the corresponding token server  16 ) prior to sending. In some arrangements, terminal  12  also send identification information corresponding to the owner of secret  18 ′. 
     Token servers  16   a ,  16   b ,  16   c , and  16   d  each receive corresponding secret share  18 , random nonce  22 , and the destination address from terminal  12 . In some arrangements, each token server  16  decrypts what was received using a private key corresponding to the public key used for encryption to reveal secret share  18 , random nonce  22 , and the destination address, 
     Upon receiving secret share  18   a ,  18   b ,  18   c , or  18   d , each token server  16   a ,  16   b ,  16   c , or  16   d  generates a corresponding token  20   a ,  20   b ,  20   c , or  20   d . Token server  16  applies a transformation to secret share  18  such as a keyed cryptographic function having a key in order to produce token  20 . In some arrangements, upon generating token  20 , token server  16  stores the key from the keyed cryptographic function with the stored token in a database (not pictured). 
     After generating token  20 , token server  16  sends token  20  and random nonce  22  to application server  14  at the destination address received from terminal  12 . Upon receiving tokens  20 , application server stores tokens  20  on an accessible storage device. In some arrangements, application server  14  combines tokens  20  into a single, combined token. 
     It should be understood that, in some arrangements, each token server  16  sends its corresponding token  20  back to terminal  12 . In such a case, terminal  12  sends tokens  20  to application server  14  after receiving tokens  20 . Further, terminal  12  need not send a destination address to token servers  16  when sending corresponding secret shares  18 . 
       FIG. 2  illustrates another example electronic environment  10 ′ for carrying out the improved technique. Electronic environment  10 ′ includes application server  14 , token servers  16   a ,  16   bm    16   c ,  16   d  (token servers  16 ), secret-handling terminal  28 , and communications medium  32 . 
     Application server  14  is configured to send tokens  24   a ,  24   b ,  24   c ,  24   d  (tokens  24 ) to corresponding token server  16   a ,  16   b ,  16   c , and  16   d  from which tokens  24  were generated. Application server  14  is further configured to receive secret shares  30   a ,  30   b ,  30   c , and  30   d  (secrets shares  30 ) from corresponding token servers  16 . Application server  14  is further configured to combine secret shares  30  to recover secret  18 ′. In some arrangements, application server is further configured to send secret  18 ′ to a secret-handling terminal  26 . As an example, a merchant that recovers a credit card number  18 ′ from tokens  20  would send credit card number  18 ′ to a terminal  26  at a credit card company. 
     During operation, application server  14  sends tokens  24  and random nonce  22  (see  FIG. 1 ) to corresponding token servers  16  in response to a request to recover secret  18 ′. Tokens  24  are equivalent to corresponding tokens  20 , but in some arrangements, tokens  24  each represent identical, combined tokens. In some arrangements, application server generates a hash of random nonce  22  before transmission to token servers  16 . 
     Upon receiving token  24 , corresponding token server  16  recovers secret share  30  from token  24 . For example, token server  16  applies a cryptographic function having a key related to the key that used to generate token  20  from secret share  18  to token  24  to recover secret share  30 . In some arrangements, token  24  is identical to token  20 , and secret share  30  is identical to secret share  18 . In other arrangements, however, token  24  results from a combination of tokens  20   a ,  20   b ,  20   c , and  20   d  and is identical for all token servers. In still other arrangements, each secret share  30  differs from the corresponding secret share  18  in such a way that a combination operation performed on secret shares  30  still yields secret  18 ′. Details of such an arrangement are discussed below with respect to  FIG. 4 . 
     It should be understood that, as an additional security measure, token servers  16  check each request for secret shares  30  from application server  14  for random nonce  22 . Token servers  16  will generate secret shares  30  when random nonce  22  matches that token servers  16  sent to application server  14  along with tokens  20 . As illustrated in  FIG. 2 , token servers  16  generate a hash of random nonce  22  previously stored, and compare this hash to hash  28  sent from application server  14 . 
     It should also be understood that application server  14  may also encrypt tokens  30 , random nonce  22  (or its hash), and any identification information pertaining to the owner of secret  18 ′. Token servers  16  are then configured to decrypt such a transmission using a private key corresponding to a public key used to encrypt the transmission. 
     When random nonce  22  provides a match, token servers  16  send corresponding token shares  30  to application server  14 . Upon receipt of token shares  30 , application server  14  performs a combination operation on token shares  30  to produce secret  18 ′. In some arrangements, application server  14  sends secret  18 ′ to secret-handling terminal  26  and does not store secret  18 ′ on an accessible storage device. Further details of an example combination operation are discussed below with respect to  FIG. 3   c.    
     Further details of terminal  12  are discussed below with respect to  FIG. 3 a    below. 
       FIG. 3 a    illustrates an example terminal  12 . Terminal  12  includes controller  40  which in turn includes processor  44  and memory  46 , and network interface  42 . 
     Network interface  42  takes the form of an Ethernet card; in some arrangements, network interface  42  takes other forms including a wireless receiver and a token ring card. 
     Memory  46  is configured to store code which includes share generation code  54 , random number generation code  56 , and encryption code  58 . Memory  46  generally takes the form of, e.g., random access memory, flash memory or a non-volatile memory. 
     Processor  44  takes the form of, but is not limited to, Intel or AMD-based MPUs, and can include a single or multi-cores each running single or multiple threads. Processor  44  is coupled to memory  46  and is configured to execute instructions from share generation code  54 , random number generation code  56 , and encryption code  58 . Processor  44  includes share generation engine  48 , random number generation engine  50 , and encryption engine  52  which are configured to execute instructions derived from share generation code  54 , random number generation code  56 , and encryption code  58 , respectively. 
     During operation, share generation engine  48  generates random shares  18  from secret  18 ′ by performing a splitting operation on secret  18 ′. In some arrangements, the splitting operation involves generating three random, 16-digit numbers, and then performing a bitwise XOR operation on those three random numbers and a credit card number  18 ′ input into terminal  12  to produce a fourth number. Each of the generated random numbers and the fourth number then is a secret share  18 . The credit card number  18 ′ may be recovered by performing the bitwise XOR operation on the secret shares  18 . 
     In other arrangements, however, secret  18 ′ is split into multiplicative factors according to a cyclic group having a particular generator. Further details of such a splitting will be discussed below with respect to  FIG. 3   b.    
     Random number generation engine  50  generates random nonce  22 . For example, random number generation engine outputs a 256-bit nonce according to a uniform distribution. In some arrangements, random number generation engine  50  generates nonce  22  upon generation of random shares  18 ; in other arrangements, random number generation engine  50  generates nonce  22  periodically. 
     Encryption engine  52  then performs an encryption operation on each transmission to token servers  16  that includes a shared secret  18 . For example, in some arrangements, processor  44  forms a string by concatenating a shared secret  18 , random nonce  22 , and a destination address of application server  14 . Encryption engine  52  then applies, to the string, a public key corresponding to the private key of the token server  16  to which that secret share  18  is to be transmitted. Processor  44  then sends the encrypted string to a token server  16  via network interface  42 . 
     Further details of each token server  16  are discussed below with respect to  FIG. 3   b.    
       FIG. 3 b    illustrates an example token server  16 . Token server  16  includes controller  60  which in turn includes processor  64  and memory  66 , and network interface  62 . 
     Network interface  62  takes the form of an Ethernet card; in some arrangements, network interface  62  takes other forms including a wireless receiver and a token ring card. 
     Memory  66  is configured to store code which includes token generation code  74 , hashing code  76 , and proactivization code  78 . Memory  66  generally takes the form of, e.g., random access memory, flash memory or a non-volatile memory. 
     Processor  64  takes the form of, but is not limited to, Intel or AMD-based MPUs, and can include a single or multi-cores each running single or multiple threads. Processor  64  is coupled to memory  66  and is configured to execute instructions from token generation code  74 , hashing code  76 , and proactivization code  78 . Processor  64  includes token generation engine  68 , hashing engine  70 , and proactivization engine  72  which are configured to execute instructions derived from token generation code  74 , hashing code  76 , and proactivization code  78 , respectively. 
     During operation, processor  64  receives a secret share  18  via network interface  82 . In some arrangements, processor  44  receives an encrypted string that, when decrypted by processor  64  using a private key, reveals secret share  18 , random nonce  22 , and the destination address of application server  14 . 
     Token generation engine  88  generates a token  20  from secret share  18 . In some arrangements, token generation engine  88  corresponding to token server  16   i , where iε{a,b,c,d}, utilizes a cryptographic function T I (K i ,S i ) to generate a token T i , S i  being secret share  18   i , K i  representing a secret key, and Iε{A,B,C,D} corresponding to iε{a,b,c,d}. That is, T i =T I (K i ,S i ). Token generation engine  88  keeps track of pairs (K i ,T i ) for eventual recovery of a secret share from a token. Hashing engine  70  also generates a hash of nonce  28 . 
     Processor  64  then sends token  20  (T i ) and nonce  22  to application server  14 . Further details of application server  14  are discussed below with respect to  FIG. 3   c.    
       FIG. 3 c    illustrates an example application server  14 . Application server  14  includes controller  80  which in turn includes processor  84  and memory  86 , and network interface  82 . 
     Network interface  82  takes the form of an Ethernet card; in some arrangements, network interface  82  takes other forms including a wireless receiver and a token ring card. 
     Memory  86  is configured to store code which includes share combination code  92  and hashing code  94 . Memory  86  generally takes the form of, e.g., random access memory, flash memory or a non-volatile memory. 
     Processor  84  takes the form of, but is not limited to, Intel or AMD-based MPUs, and can include a single or multi-cores each running single or multiple threads. Processor  84  is coupled to memory  86  and is configured to execute instructions from share combination code  92  and hashing code  94 . Processor  84  includes share combination engine  88  and hashing engine  90  which are configured to execute instructions derived from share combination code  92  and hashing code  94 , respectively. 
     During operation, processor  84  receives, via network interface, token  20  and nonce  22  from each token server  16 . Processor  84  checks that each nonce  22  received is identical to the other nonces received. Processor  84  then stores each token  20  in an accessible storage device. In some arrangements, processor  84  performs a combination operation on tokens  20  to produce a combined token T C , preferable by concatenating tokens T i  for iε[a,b,c,d] in order. 
     Hashing engine  70  applies a hash function h to random nonce  22 , denoted by N to produce hashed nonce  28 , i.e., h(N). In some arrangements, processor  84  concatenates h(N) with combined token T C . 
     Sometime later, when a user (not pictured) wishes to recover secret  18 ′, denoted by S, processor  84  sends tokens  24  and hashed nonce  28  to each token server  16 . It should be understood that tokens  24  may be identical to corresponding tokens  18 , i.e., T i . In some arrangements, however, each token  24  is the combined token T C . 
     Referring back to  FIG. 3 b   , processor  64  of token server  16  receives, via network interface  62 , corresponding token  24  and hashed nonce  28 . In response, processor  64  compares the hashing result from hashing engine  70  to hashed nonce  28 . If there is a mismatch, processor  70  sends an error message to application engine  14 . 
     If there is a match, processor  64  performs a lookup operation on token T i  in order to find the corresponding key K i . In some arrangements, when processor  64  receives combined token T C , processor  64  performs a token separation operation to recover the token T i . Such a token separation operation is common to all token servers  16 . 
     Token generation engine  68  then utilizes another cryptographic function, D I (K i ,T i ) to produce a new secret share  30 , denoted as D i =D I (K i ,T i ) such that, when the secret splitting operation split secret  18 ′ (S) into products under a cyclic group G, the product of the new secret shares  30  produce secret S. That is, S=S a S b S c S d =D a D b D c D d , where multiplication is understood to be under G. 
     In some arrangements, token servers  16 , via proactivization engine  72 , proactively update keys at regular intervals in order to provide deeper security for the split tokenization process outlined here. That is, token servers synchronously update the keys while preserving the value of S=D a D b D c D d . The following represents a scheme for proactive updates in the manner described, and is described with respect to  FIG. 4  below. 
       FIG. 4  represents the above scheme by which cryptographic keys used to generate tokens and secret shares are updated proactively. Consider the following tokenization function: T I (K i ,S i )=S i g K     i   , where g is the generator of G. Consider further the following “share-ization” function D I (K i ,T i )=T i g −K     i    that returns a secret share D i  from a token. At some point in time, token servers  16  update their respective keys by adding to each key a quantity x i . Then each new share D′ i =D I (K i +x i ,T I (K i ,S i ))=T i g −K     i     −x     i   =S i g K     i   g −K     i     −x     i   =S i g −x     i   , where addition is understood to be under G. The product of the new shares over the token servers is then S a S b S c S d g −(x     a     +x     b     +x     c     +x     d     ) . To recover the secret, the updates should satisfy the following condition: x a +x b +x c +x d =0. 
       FIG. 4  illustrates a scenario in which there are two token servers,  16   a  and  16   b , involved in the updates. In this scenario, x a =−x b . Note that proactivization engine  72  in each token server has a synchronized random number generator (not pictured) for generating such updates. In the case of four token servers above, such synchronized random number generators would follow a more complex scheme. In general, the split tokenization scheme outlined here may work with any number of token servers. 
     It should be understood that, in the above examples, it was assumed that there was no interaction between token servers  16 . In some arrangements, however, more general cryptographic functions may be used when there is such interaction. In such a scenario, application server produces a combined token T C =T a T b T c T d  and sends T C  to token servers  30 . A token server  16  then utilizes a “share-ization” function D I (K a ,K b ,K c ,K d ,T C )=T C g −[(K]     a     +K     b     +K     c     +K     d     ) . An updating scheme as outlined above will also produce the secret  18 ′ here as well. 
     It should also be understood that there are alternatives to using cryptographic functions in generating tokens from secret shares and vice-versa. For example, token server  16  may utilize tables of tokens and corresponding secret shares. Such tables are implemented using a function T i =T I (S i ). Such tables may be proactively updated as follows. Suppose that there are two token servers. Further suppose that each token server maintains a first skip list that stores entries [[T] I (S i ),h(N),S i ] ordered according to T I (S i ) primarily and h(N) secondarily, and a second skip list that stores entries [[S i ,T] I (S i )] according to S i . The token servers then agree on a joint random bit string Σ and chunk size c. The first c entries in [[S i ,T] I (S i )] in the second skip list are updated to [[S I i,T] I I(S I i)]⊕ “Hash” (Σ∥S I i), where ⊕ represents a bitwise XOR operation. During this update, the corresponding entries [[T] I (S i ),h(N),S i ] in the first skip list are updated to [[T] I I(S I i)⊕“Hash” (Σ∥S I i),h(N),S I i] and copied to a new ordered list. Each token server  16  then replaces Σ with a one-way function f(Σ) and proceeds with a second chunk of c entries. Continuing along these lines for each token server  16  will result in a secure update that may be used to recover secret shares from tokens [T a ∥T b ∥h(N)]. 
       FIG. 5  illustrates a method  100  of protecting a secret, which includes steps  102 ,  104 , and  106 . In step  102 , a secret splitting operation that produces a first secret share and a second secret share is performed. In step  104 , the first secret share is sent to a first token server, the first token server being constructed and arranged to i) generate a first token from the first secret share and ii) send the first token to an application server. In step  106 , the second secret share is sent to a second token server that is different from the first token server, the second token server being constructed and arranged to i) generate a second token from the second secret share and ii) send the second token to the application server, the application server being constructed and arranged to recover the secret from the first secret share and the second secret share by exchanging the first token for the first secret share with the first token server and exchanging the second token for the second secret share with the second token server. 
       FIG. 6  illustrates a method  110  of recovering a secret, which includes steps  112 ,  114 ,  116 ,  118 , and  120 . In step  112 , a first token is sent to a first token server, the first token server being constructed and arranged to generate a first secret share in response to receiving the first token, the first secret share being based on the first token. In step  114 , a second token is sent to a second token server, the second token server being constructed and arranged to generate a second secret share in response to receiving the second token, the second secret share being based on the second token. In step  116 , the first secret share is received from the first token server. In step  118 , the second secret share is received from the second token server. In step  120 , a combination operation is performed on the first secret share and the second secret share to produce the secret. 
     While various embodiments of the invention have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. 
     For example, the examples above assumed that the secret took the form of personal credit information (PCI) such as credit card numbers. Nevertheless, the improved techniques described above are also useful for health records, insurance information, social security numbers, and other examples of PII and PHI information. 
     Furthermore, it should be understood that some embodiments are directed to terminal  12 , which is constructed and arranged to protect a secret. Some embodiments are directed to a process of protecting a secret. Also, some embodiments are directed to a computer program product which enables computer logic to protect a secret. 
     Moreover, it should be understood that some embodiments are directed to application server, which is constructed and arranged to recover a secret. Some embodiments are directed to a process of recovering a secret. Also, some embodiments are directed to a computer program product which enables computer logic to recover a secret. 
     In some arrangements, terminal  12  is implemented by a set of processors or other types of control/processing circuitry running software. In such arrangements, the software instructions can be delivered, within terminal  12 , in the form of a computer program product  130  (see  FIG. 3 a   ), each computer program product having a computer readable storage medium which stores the instructions in a non-volatile manner. Alternative examples of suitable computer readable storage media include tangible articles of manufacture and apparatus such as CD-ROM, flash memory, disk memory, tape memory, and the like. 
     In some arrangements, application server  14  is implemented by a set of processors or other types of control/processing circuitry running software. In such arrangements, the software instructions can be delivered, within application server  14 , in the form of a computer program product  150  (see  FIG. 3 c   ), each computer program product having a computer readable storage medium which stores the instructions in a non-volatile manner. Alternative examples of suitable computer readable storage media include tangible articles of manufacture and apparatus such as CD-ROM, flash memory, disk memory, tape memory, and the like. 
     In some arrangements, token server  16  is implemented by a set of processors or other types of control/processing circuitry running software. In such arrangements, the software instructions can be delivered, within token server  16 , in the form of a computer program product  140  (see  FIG. 3 b   ), each computer program product having a computer readable storage medium which stores the instructions in a non-volatile manner. Alternative examples of suitable computer readable storage media include tangible articles of manufacture and apparatus such as CD-ROM, flash memory, disk memory, tape memory, and the like.