Patent Publication Number: US-9432360-B1

Title: Security-aware split-server passcode verification for one-time authentication tokens

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     The present application is a continuation-in-part application of U.S. patent application Ser. No. 14/144,712, entitled “Multi-Server Passcode Verification for One-Time Authentication Tokens with Auxiliary Channel Compatibility,” incorporated by reference herein. 
    
    
     FIELD 
     The field relates generally to authentication, and more particularly to single server and multi-server authentication. 
     BACKGROUND 
     One-time authentication tokens produce unpredictable one-time passcodes (OTP) typically by extracting pseudorandomness from a secret seed, that is stored at the token and shared with the authentication server. To protect against server-side leakage of the underlying seed, tokens may employ split-server verification protocols (see, e.g., U.S. Pat. No. 7,725,730). In a split-server verification protocol, the underlying authentication secret is split into at least two partial secrets, each one kept by a distinct verification server, so that authentication of a user is performed at these servers in a distributed manner so that certain attacks against of one or more servers can be tolerated. 
     A number of such split-server OTP verification protocols have been proposed. See, for example, U.S. patent application Ser. No. 13/404,737, entitled “Method and Apparatus for Authenticating a User Using Multi-Server One-Time Passcode Verification,” (now U.S. Pat. No. 9,118,661); U.S. patent application Ser. No. 13/795,801, entitled “Distributed Cryptography Using Distinct Value Sets Each Comprising At Least One Obscured Secret Value;” and U.S. patent application Ser. No. 14/144,707, entitled “Multi-Server One-Time Passcode Verification of Respective High Order and Low Order Passcode Portions.” 
     Nonetheless, a need remains for an end-to-end server-side architecture for an OTP authentication system that simultaneously employ split-server verification and one or more of Silent Alarms (See, for example, U.S. patent application Ser. No. 13/404,788, entitled “Methods and Apparatus for Silent Alarm Channels Using One-Time Passcode Authentication Tokens”) and Drifting Keys (See, for example, U.S. patent application Ser. No. 13/250,225, entitled “Key Update With Compromise Detection”). 
     SUMMARY 
     Illustrative embodiments of the present invention provide techniques for security-aware split-server passcode verification for one-time authentication tokens. According to one aspect of the invention, an exemplary method comprises the steps of: receiving an authentication passcode generated by a token associated with a user; and processing the received authentication passcode using at least a first authentication server and a second authentication server, wherein the received authentication passcode is based on at least one protocode and embedded auxiliary information and wherein at least one of the first authentication server, the second authentication server and a relying party extract the embedded auxiliary information from the received authentication passcode, wherein the embedded auxiliary information comprises one or more of a silent alarm and a drifting key. 
     In one exemplary embodiment, the token stores a secret silent alarm state SA that changes to a new forward-secure state SA′ if a predefined activity is detected that indicates a potential compromise of the token. In another exemplary embodiment, the embedded auxiliary information provides an indicator of a randomly evolving key of the token. The randomly evolving key of the token is configured to permit at least one of the first authentication server, the second authentication server and the relying party to detect a compromise of an updated key by determining if an inconsistency is present in the corresponding received authentication passcode based at least in part on that received authentication passcode and one or more previously received authentication passcodes. 
     According to another aspect of the invention, an exemplary method comprises the steps of: receiving an authentication passcode generated by a token associated with a user, wherein the received authentication passcode is based on at least one protocode and embedded auxiliary information; and processing the received authentication passcode using a single processing device to extract the embedded auxiliary information from the received authentication passcode, wherein the embedded auxiliary information comprises one or more of a silent alarm and a drifting key. 
     In one exemplary embodiment, the single processing device implements software modules of at least a first authentication server and a second authentication server. In another exemplary embodiment, the single processing device comprises a single source of pseudorandom information for at least two of an auxiliary channel, the silent alarm and the drifting key. In yet another exemplary embodiment, the single processing device comprises a plurality of sources of pseudorandom information for at least two of an auxiliary channel, the silent alarm and the drifting key. 
     According to a further aspect of the invention, an exemplary method comprises the steps of: providing an authentication passcode generated by a token associated with a user to at least one authentication processing device, wherein the user is attempting to access a protected resource; receiving an authentication outcome from the at least one authentication processing device, the authentication outcome comprising an acceptance outcome of the received authentication passcode and at least one of an acceptance outcome with respect to a silent alarm and an acceptance outcome with respect to a drifting key; and providing access of the user to the protected resource based on the authentication outcome and a predefined access policy. 
     The authentication outcome comprises, for example, one or more of an allowance of access, a denial of access, a silent alarm alert indicating a potential compromise of the token and a drifting key inconsistency between the received authentication passcode and one or more previously received authentication passcodes. The predefined access policy comprises, for example, one or more of the following actions: allowing the user restricted access to the protected resource; denying the user access to the protected resource; denying the user access to the protected resource and applying an additional secondary step-up authentication mechanism; and allowing the user restricted access to the protected resource in a non-functional manner such that the user is not notified that a potential attack has been detected. 
     Embodiments of the invention can be implemented in a wide variety of different authentication applications, including, for example, verification of one-time passcodes (OTPs). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates an exemplary client-side generation of passcodes by a token; 
         FIG. 2  illustrates an exemplary split-server passcode verification protocol; 
         FIG. 3  illustrates an exemplary silent alarm protocol; 
         FIG. 4  illustrates an exemplary drifting key protocol; 
         FIG. 5  illustrates exemplary processing of a passcode by a relying party; 
         FIG. 6  illustrates an exemplary passcode search process; 
         FIG. 7  illustrates an exemplary state synchronization process; 
         FIG. 8  illustrates an exemplary auxiliary information processing process; 
         FIG. 9  illustrates an exemplary final response process for the relying party; 
         FIG. 10  illustrates an exemplary single server configuration that employs a split module configuraton; 
         FIG. 11  illustrates an exemplary single server configuration that employs a single module configuraton; 
         FIG. 12  illustrates an exemplary processing platform that may be used to implement at least a portion of one or more embodiments of the invention comprising a cloud infrastructure; and 
         FIG. 13  illustrates another exemplary processing platform that may be used to implement at least a portion of one or more embodiments of the invention. 
     
    
    
     DETAILED DESCRIPTION 
     Illustrative embodiments of the present invention will be described herein with reference to exemplary communication systems and associated servers, clients and other processing devices. It is to be appreciated, however, that the invention is not restricted to use with the particular illustrative system and device configurations shown. Accordingly, the term “communication system” as used herein is intended to be broadly construed, so as to encompass, for example, systems in which multiple processing devices communicate with one another but not necessarily in a manner characterized by a client-server model. 
     As will be described, the present invention in one or more illustrative embodiments provides efficient split-server OTP verification protocols that are compatible with the existence of an auxiliary channel that supports one or more of silent alarms and drifting keys. According to one aspect of the invention, a split-server verification protocol is provided where different servers are responsible for verifying different portions (substrings) of the submitted passcode. According to another aspect of the invention, at least one of the servers and the relying party extract embedded auxiliary information from a presented passcode that comprises one or more of a silent alarm and a drifting key. 
     One-Time Authentication 
     One-time authentication tokens produce a series of unpredictable one-time passcodes (OTPs) as second authentication factors for the authentication of users to remote servers. Passcodes are typically generated on a regular time basis, i.e., in specified time intervals often called epochs (e.g., the SecurID™ token produces a new OTP every one minute). Passcodes are derived by using some secret state, called a seed, that is stored at the token and also shared with the server. Tokens can either be based on software or hardware. Software tokens produce passcodes on-demand, whenever the token&#39;s application is launched in the host device, where a series of passcodes is generated for the epochs following the launching of the application. Hardware tokens produce passcodes on a permanent basis, one passcode per epoch, for the entire lifetime of their battery (e.g., for five years from the time of manufacture). Overall, such tokens produce a time-based series of unpredictable OTPs by extracting pseudorandom bits from their seed which are converted to passcodes. 
     There are three main steps in the functionality of exemplary one-time authentication tokens: 
     1. A passcode P t′  is produced in time epoch t′ through a one-way cryptographic function f applied on the current epoch t′, and the seed σ of the token. Software tokens specify their current epoch based on the host&#39;s device current time, whereas hardware tokens specify their epoch implicitly using a counter. 
     2. A passcode P t′  may then be transmitted to an authentication server to authenticate a user to the server. The transmission of the passcode P t′  to the server may happen either by typing performed by the user or automatically by a software token that is directly communicating to the server through a communication channel offered by the host device. 
     3. On receiving a candidate passcode P t′ , the server verifies this passcode by contrasting it against the passcode P t  that is locally computed by the server, accepting the passcode if and only if p t′ =P t . If the passcode is not accepted the user is not authenticated; otherwise, the user is authenticated if and only if a user&#39;s corresponding PIN is correct. Passcode P t  is computing by the server by applying the same function f on the current epoch t′ specified by the server&#39;s current time and the seed σ of the token stored at the server. To tolerate small discrepancies between the current time of the software (or hardware) token and the current time of the server, P t′  is also contrasted against another 2s passcodes that are defined by epochs that are neighboring epochs to the server&#39;s epoch t, that is, to passcodes {P t−s , . . . ,P t−1 ,P t ,P t+1 , . . . ,P t+s }. 
     Future passcodes remain unpredictable even if an attacker has observed an arbitrarily long history of passcodes produced in the past, because passcodes are produced by applying a one way function f on the token&#39;s seed, as long as the seed remains secret, protected against leakage to an attacker. 
     Protections Against Seed Leakage 
     Accordingly, the security of any one-time authentication token is impaired if an attacker gets access to the secret seed of the token: Using the seed, the attacker can clone the token. In turn, the attacker can increase its chances for impersonating the corresponding user, by either performing a brute-force attack on the user&#39;s PIN or by launching a more sophisticated man-in-the-middle attack for harvesting the user&#39;s PIN. In reality, the fact that the security of the token is based on a secret seed will motivate the attacker to go after this secret seed by following one of the following three attack patterns: 
     1. Server Compromise: The attacker may compromise the authentication server and get the secret seed of the tokens of one or more users. The attacker may compromise the server ephemerally by instantly stealing the seed(s), or permanently by remaining in control of the server for a period of time. 
     2. Token Tampering or Compromise: The attacker may compromise the token and get its secret seed by performing a direct attack against the host device of a software token or by physically tampering with a hardware token to directly read its seed. 
     3. Seed-Record Capturing: The attacker may get the secret seed of the token indirectly by attacking a storage or communication unit used to store or transfer the token&#39;s seed, or through side-channel attacks performed against the token or the server. 
     Although conventional one-time authentication tokens are vulnerable to all such seed-leakage attacks, a general solution has been recently proposed in U.S. patent application Ser. No. 13/837,259, entitled “Configurable One-Time Authentication Tokens with Improved Resilience to Attacks,” (now U.S. Pat. No. 9,270,655), that involves the design of a configurable one-time authentication token which is equipped with several intrusion-detection, intrusion-resilience, tamper-resistance and token-visibility technologies that protect against the above attacks. The exemplary design optionally employs one or more of the following exemplary tamper-resistance and token-visibility techniques, as described in: 
     U.S. patent application Ser. No. 13/826,993, entitled “Time Synchronization Solutions for Forward-Secure One-Time Authentication Tokens;” 
     U.S. patent application Ser. No. 13/828,588, entitled “Randomizing State Transitions for One-Time Authentication Tokens;” 
     U.S. patent application Ser. No. 13/826,924, entitled “Event-Based Data-Signing Via Time-Based One-Time Authentication Passcodes,” (now U.S. Pat. No. 9,225,717); 
     U.S. patent application Ser. No. 13/250,225, entitled “Key Update With Compromise Detection;” 
     U.S. patent application Ser. No. 13/728,271, entitled “Time Synchronisation &amp; Forward Clock Attack,” (now U.S. Pat. No. 9,083,515); 
     U.S. patent application Ser. No. 13/404,780, entitled “Method and Apparatus for Embedding Auxiliary Information in One-Time Passcode Authentication Tokens,” (now U.S. Pat. No. 8,984,609); 
     U.S. patent application Ser. No. 13/404,788, entitled “Methods and Apparatus for Silent Alarm Channels Using One-Time Passcode Authentication Tokens;” 
     U.S. patent application Ser. No. 13/334,709, entitled “Methods and Apparatus for Generating Forward Secure Pseudorandom Numbers,” (now U.S. Pat. No. 9,008,303); and 
     U.S. patent application Ser. No. 13/404,737, entitled “Method and Apparatus for Authenticating a User Using Multi-Server One-Time Passcode Verification,” (now U.S. Pat. No. 9,118,661). 
     Each of the above-referenced patent applications are incorporated by reference herein. 
     The exemplary design also employs one or more of the following exemplary intrusion-detection, and intrusion-resilience techniques. For a discussion of exemplary split-server passcode verification techniques, see, for example, U.S. patent application Ser. No. 13/404,737, entitled “Method and Apparatus for Authenticating a User Using Multi-Server One-Time Passcode Verification,” (now U.S. Pat. No. 9,118,661); U.S. patent application Ser. No. 13/795,801, entitled “Distributed Cryptography Using Distinct Value Sets Each Comprising At Least One Obscured Secret Value;” and U.S. patent application Ser. No. 14/144,707, entitled “Multi-Server One-Time Passcode Verification of Respective High Order and Low Order Passcode Portions,” each incorporated by reference herein. 
     For a discussion of exemplary silent alarm techniques, see, for example, U.S. patent application Ser. No. 13/404,788, entitled “Methods and Apparatus for Silent Alarm Channels Using One-Time Passcode Authentication Tokens” incorporated by reference herein. For a discussion of exemplary Drifting Keys techniques, see, for example, U.S. patent application Ser. No. 13/250,225, entitled “Key Update With Compromise Detection,” incorporated by reference herein. Silent alarms and drifting keys further employ the use of an auxiliary channel. See, for example, U.S. patent application Ser. No. 13/404,780, entitled “Method and Apparatus for Embedding Auxiliary Information in One-Time Passcode Authentication Tokens,” (now U.S. Pat. No. 8,984,609), incorporated by reference herein. 
     Extensions of the exemplary split-server passcode verification protocols are disclosed herein that are compatible with the use of an auxiliary channel. See, for example, U.S. patent application Ser. No. 14/144,712, entitled “Multi-Server Passcode Verification for One-Time Authentication Tokens with Auxiliary Channel Compatibility,” incorporated by reference herein. 
     1. Split-Server Passcode Verification: This technique involves dispersing the task of verifying a candidate passcode (provided by a user or token) among two or more verification servers so that each such participating server S i  stores only a partial secret state σ i . Then, verification is securely implemented in a distributed manner so that leakage of one or more, but up to a specified threshold, partial secret states does not compromise the security of the token. 
     Typically, the seed is split into two pieces, often called the red and the blue partial seeds, stored separately by the red server and the blue server. Upon receiving a candidate passcode P t′ , the two servers interact through a secure protocol to jointly compute the passcode P t  against which the candidate passcode is contrasted, and accordingly P t′  is rejected if any of the two servers outputs “reject.” This decision is typically made by a so-called relying party (RP) server that is stateless and responsible for the final decision about the acceptance of P t′  based on the individual outputs of the red and the blue servers. 
     The additional feature of proactivization can be used according to which the partial states of the (e.g., two) servers evolve over time and where the servers periodically exchange secure descriptions (e.g., hashes) of their partial secret states, which are then used to create their new partial secret states. 
     2. Silent Alarms: This technique detects token compromise and eventually prevents certain impersonation attempts by an attacker. The token stores a secret silent alarm state SA that changes to a new state SA′ once the token senses/detects a suspicious activity that indicates possible token compromise; this change serves as an alert flag. This change is performed in a forward-secure and stealthy manner. Even after the complete token compromise by an attacker, the new state SA′ alone is not indicative of whether or not any alert flag has been raised (thus, the alert serves as a silent alarm) and the new state cannot be reverted to the old state (thus, the alarm cannot be shut off). 
     Using an auxiliary channel, the silent alarm state can be embedded into the passcodes produced by the token, and thus passed to the authentication server. By decoding and reading these states, the authentication server, in turn, can eventually learn about one or more raised alert flags and then appropriately handle the current authentication attempt by the user. Successful decoding of an embedded alert flag is a probabilistic event that happens with some positive probability. The alert flag will be eventually received in one of the next few transmitted passcodes. False negatives exist, but no false positives (other than with negligible probability). A received alert flag always indicates a suspicious (according to some alerting policy) event that happens at the token. 
     3. Drifting Keys: This technique detects token cloning and eventually prevents certain impersonation attempts by an attacker. The token stores a drifting key state DK that changes over time randomly. This random state change corresponds to a unique fingerprint of the token, which evolves over time at some low rate (e.g., a few new random bits are added to the state every week). These small changes in the token&#39;s drifting-key fingerprint are then embedded into the produced passcodes, and thus passed to the server. Thus, assuming some frequent enough usage of the token by the user, the server gradually learns (partially or completely) the token&#39;s fingerprint. 
     Because this randomly evolving fingerprint is unique over the lifetime of the token, if a cloned token starts reporting cloned drifting-key updates to the server, these will not match the drifting key updates reported by the original, cloned, token. Thus, as long as the original token and the cloned one are being used during some long enough time window by the legitimate user and the attacker respectively, with overwhelming probability the server will notice an inconsistency in the received fingerprint (even if the server only has partial knowledge of it). The server may not be able to distinguish the cloned token from the original one, but it will be alerted that a possible cloning attack has been performed and will react to this—according to a certain policy. 
     Again, successful decoding of an embedded DK update is a probabilistic event happening with some positive probability. Fingerprint updates will be eventually received in one of the next few transmitted passcodes. False negatives exist, but no false positives (other than with negligible probability). A received inconsistent drifting-key update always indicates a cloning attack against the token. 
     It is noted that all of the above three security mechanisms (as well as the underlying auxiliary channel) require the use of pseudorandomness, in particular, of a forward-secure pseudorandom number generator (FS-PRNG), e.g., as described in U.S. patent application Ser. No. 13/334,709, entitled “Methods and Apparatus for Generating Forward Secure Pseudorandom Numbers,” (now U.S. Pat. No. 9,008,303). Forward security can be applied to management of the internal state of one-time authentication tokens. Instead of using a fixed global secret state, e.g., a seed, for the entire lifetime of the token, the secret state can evolve over time in a one-way cryptographic manner so that older states cannot be computed from newer states (e.g., new seeds may be computed using a one-way hash chain). By using elaborate hierarchical hashing schemes, it is possible to improve the server-side performance with respect to management of time-evolving seeds. 
     However, supporting simultaneously the use of all these three security mechanisms in an end-to-end integrated design of the server-side functionality of an OTP authentication token is not a trivial task. Typically, existing schemes, such as those referred to above as split-server authentication, silent alarm and drifting key schemes, implement only one of these mechanisms. Therefore, as noted above, there exists a need for designing a server-side architecture of an OTP authentication token that employs split-server authentication and simultaneously allows for one or more of silent alarms and drifting keys. 
     Server-Side Architecture 
     As noted above, one aspect of the invention provides an architectural design for the server-side operation of an OTP authentication token that fully supports split-server passcode verification, silent alarms and drifting keys. A corresponding client-side token design is assumed that supports all three of these mechanisms, for instance, the design of U.S. patent application Ser. No. 13/837,259, entitled “Configurable One-Time Authentication Tokens with Improved Resilience to Attacks,” (now U.S. Pat. No. 9,270,655). In particular, the exemplary embodiment is based on the use of two FS-PRNGs, one called red or G r  and one called blue or G b , in support of the split-server passcode verification functionality. 
     The exemplary embodiment described herein support all three of the above security mechanisms, but the disclosed architecture can be simplified to support only one of the silent alarms or drifting keys mechanisms, as would be apparent to a person of ordinary skill in the art. 
     An asymmetric configuration is assumed, as the one used in U.S. patent application Ser. No. 13/837,259 (now U.S. Pat. No. 9,270,655), where the pseudorandomness required for supporting silent alarms, drifting keys and the underlying auxiliary channel is provided by only one of two FS-PRNGs in use, without loss of generality by the blue FS-PRNG G b . Such an asymmetric configuration makes sense, as silent alarms and drifting keys (along with their underlying auxiliary channel) do not individually require any distributed-crypto or split-state technical considerations. However, simple extensions of the exemplary architectural design are presented where the silent alarms and/or drifting keys makes use of pseudorandomness that is derived by a different FS-PRNG (say the red one G r ) than the one employed by the underlying auxiliary channel (say the blue one G b ). 
       FIG. 1  illustrates an exemplary client-side generation of passcodes by a token  100 . As shown in  FIG. 1 , the exemplary token  100  comprises a red and a blue FS-PRNG, G r  and G b , respectively, that produce protocodes P R,t  and P B,t , respectively, for each epoch t. Additionally, in the exemplary embodiment, the blue FS-PRNG G b  produces pseudorandom information that is used for the auxiliary channel (AC), drifting keys (DK) and silent alarm (SA), which, in turn, is optionally used by the auxiliary channel  110  to embed additional information into the two produced protocodes, finally producing the transmitted passcode P t . 
     Generally, R T,c   t  denotes the pseudorandomness derived by FS-PRNG G c , cε{b,r}, (in server B or R) for epoch t and that is used in security mechanism T, Tε{AC,SA,DK}, where AC, SA and DK stand respectively from “auxiliary channel,” “silent alarms” and “drifting keys.” 
     In at least one embodiment, a given message in the message space is mapped to a binary codeword in a binary codebook and the binary codeword is mapped to a decimal codeword in a decimal codebook using a shared key. An exemplary auxiliary channel  110  operates as follows. An embedded message m consists of a small number of k bits. A fixed (and possibly known) binary codebook B is used to map (through mapping B(·)) a k-bit message m=m k−1,t m k−2,t  . . . m 0,t  into a binary codeword q=B(m)=q l−1,t q l−2,t  . . . q 0,t  of size l, where l equals the number of digits in the final passcode. Here, typical values are as follows: k=4 and l=6 or l=8. Thus, B can take the form of a [8, 4, 4] or [6, 4, 2] error correcting code (specifically, the [8, 4, 4] extended Hamming code or a corresponding [6, 4, 2] Hamming code). Then, using pseudorandom bits, for example, in R AC,b   t , the auxiliary channel  110  maps (through mapping C t (·)) codeword q to an l-bit digital codeword c t =C t (q)=c l−1,t c l−2,t  . . . c 0,t  as follows: if q i,t ≠0 then c i,t  is randomly selected from {1,2,3,4,56,7,8,9 else c i,t =0. Note that with this mapping, any two digital codewords C t (B(m)) and C t (B(m′)) have Hamming distance that is at least the Hamming distance between their corresponding binary codewords B(m) and B(m′); thus, mapping C t  can be itself considered a Hamming code (over zero and non-zero digits). 
     The final exemplary passcode P t  is computed using digit-wise modulo  10  addition of values P R,t , P B,t  and c t , denoted here using operator ⊕ as P R,t ⊕P B,t ⊕c t . In this manner, the final exemplary passcode P t  optionally embeds the auxiliary information, such as a silent alarm and/or a drifting key. Thus, the final exemplary passcode P t  can be referred to as an auxiliary-information enriched passcode. 
     To achieve generality in the disclosed server-side architectural design for OTP authentication tokens, first consider the following abstract descriptions of the three exemplary security mechanisms: 
     1. A split-server passcode verification protocol, shown in  FIG. 2 , (or simply split verification protocol) Π SV , as in U.S. patent application Ser. No. 13/404,737, entitled “Method and Apparatus for Authenticating a User Using Multi-Server One-Time Passcode Verification,” (now U.S. Pat. No. 9,118,661); U.S. patent application Ser. No. 13/795,801, entitled “Distributed Cryptography Using Distinct Value Sets Each Comprising At Least One Obscured Secret Value;” and U.S. patent application Ser. No. 14/144,707, entitled “Multi-Server One-Time Passcode Verification of Respective High Order and Low Order Passcode Portions,” is an interactive protocol run by the red server R and the blue server B where given as external input a candidate passcode P′ and a time epoch t, it involves the following operations. As shown in  FIG. 2 , the exemplary split-server passcode verification process  200  is initiated during step  210  when an auxiliary-information enriched candidate passcode P′ is presented to a relying party RP. 
     (a) Using as additional local input the protocode P B,t  and pseudorandomness R AC,b   t , server B computes (intermediate) message m B,t ; 
     (b) Using as additional local input the protocode P R,t  (and possibly pseudorandomness R AC,r   t , as in U.S. patent application Ser. No. 13/404,737, entitled “Method and Apparatus for Authenticating a User Using Multi-Server One-Time Passcode Verification,” now U.S. Pat. No. 9,118,661)), server R computes (intermediate) message m R,t ; 
     (c) Servers B and R exchange messages m B,t  and m R,t  during step  220  (possibly in multiple stateful interactions, e.g., when commitments are used as in U.S. patent application Ser. No. 13/404,737 (now U.S. Pat. No. 9,118,661)); 
     (d) Servers B and R perform a final local computation and each outputs (final) message M B,t  and respectively M R,t ; 
     (e) There exists a verification procedure Check SV  which on input messages M B,t  and M R,t  outputs an auxiliary message aux and a boolean value accept or reject, written as (aux,{accept,reject}}→Check SV (M B,t ,M R,t ). 
     For the above execution of protocol Π SV , 
     (M B,t ,M R,t )→Π SV (t,P′). 
     Example instantiation of Π SV : A possible instantiation of the above abstract protocol may be implemented according to U.S. patent application Ser. No. 14/144,712, entitled “Multi-Server Passcode Verification for One-Time Authentication Tokens with Auxiliary Channel Compatibility,” as follows. For a matrix A consisting of k rows of t-bit vectors, let Ā denote the high-order, left or most-significant half of the matrix consisting of k rows of └t/2┘ bits; and let  A  denote the low-order, right or least-significant half of the matrix A consisting of k rows of ┌t/2┐ bits. For instance, if A is [1234,5678], then Ā=[12,56] and  A =[34,78]. Then, server B uses pseudorandomness R AC,b   t  and a binary codebook B to compute a digital codebook C t = C   t   C   t , and sets m B,t ={ C   t , P   B,t }. Server R sets m R,t = P   R,t . Then, server B sets Ī t  to Ø, computes  d   t = P ′! P   R,t ! P   B,t , where ! may denote the digit-wise modulo  10  subtraction operation, and for each  c   j ε C   t , 1≦j≦2 k , it checks if  c   j = d   t  and if yes, then it sets Ī t →Ī t ∪j; finally B sets M B,t =Ī t . Analogously, R sets  I   t  to Ø, computes  d   t = P ′! P   R,t ! P   B,t , and for each  c j   ε C   t , 1≦j≦2 k , it checks if  c   j = d   t  and if yes, then it sets  I   t → I   t ∪j; finally R sets M R,t = I   t . Moreover, given Ī t  and  I   t , the verification procedure Check SV  outputs mathsfaccept if and only if Ī t ∩ I   t ≠Ø, in which case it sets aux=Ī t ∩ I   t . Otherwise, it outputs (⊥, reject). 
     2. A silent alarm protocol Π SA , as in U.S. patent application Ser. No. 13/404,788, entitled “Methods and Apparatus for Silent Alarm Channels Using One-Time Passcode Authentication Tokens,” is a stateful protocol run by a server where given as external input a hash tag h′ and a time epoch t, it involves the following operations: 
     (a) The server maintains state SA; 
     (b) Using as additional local input state SA and pseudorandomness R SA,c   t , cε{b,r}, the server computes a hash tag h; written as h→HashTag(SA,R SA,c   t ); 
     (c) There exists a verification procedure Check SA  which on input hash tags h, h′ and possibly pseudorandomness R SA,c   t  and state SA, it outputs safe or alert and possibly updates state SA to SA′; ({⊥,SA′},{safe,alert})→Check SA (h,h′,SA,R SA,c   t ). 
     Example instantiation of Π SA :  FIG. 3  illustrates an exemplary instantiation  300  of the silent alarm protocol Π SA  according to U.S. patent application Ser. No. 13/404,788, as follows. State SA is seen as an m-bit binary string for some parameter m. Procedure HashTag(SA,R SA,c   t ) extracts a current (for epoch t) pseudorandom mask x t  such that |x t |=|SA| and returns the dot product of x t ·SA. Also, procedure Check SA (h,h′,SA,R SA,c   t ) returns alert if and only if h≠h′, in which case SA′ may be set to the next pseudorandom value according to a hash chain defined by R SA,c   t  such that h′=HashTag(SA′,R SA,c   t ) where the underlying pseudorandom mask used in the computation is x t . Otherwise, it outputs (SA,safe) or (⊥,safe) depending on whether the SA state is to be updated. 
     3. A drifting key protocol Π DK , as in U.S. patent application Ser. No. 13/250,225, entitled “Key Update With Compromise Detection”, is a stateful protocol run by a server where given as external input an update string upd′ and a time epoch t, it involves the following operations: 
     (a) The server maintains state DK; 
     (b) Using as additional local input state DK and pseudorandomness R DK,c   t , cε{b,r}, the server computes an update tag upd; upd→UpdTag(DK,R DK,c   t ); 
     (c) There exists a verification procedure Check DK  which on input the update tags upd and upd′ and possibly pseudorandomness R DK,c   t  and state DK outputs consistent or inconsistent and possibly updates state DK to DK′; ({⊥,DK′},{consistent,inconsistent})→Check DK (upd,upd′,DK,R DK,c   t ). 
     Example instantiation of Π DK :  FIG. 4  illustrates an exemplary instantiation  400  of the drifting key protocol Π DK  according to U.S. patent application Ser. No. 13/250,225, as follows. State DK is seen as a binary string of size l t  that increases over time, augmented to label some bits in this string as “unknown.” Procedure UpdTag(DK,R DK,c   t ) extracts a current set X t  (for epoch t) of pseudorandom masks {x 1,t , . . . ,x k,t }, such that k≦l t  is the total number of previously successful authentications by the user and |x j,t | equals the drifting-key state size n of the token (a scheme parameter), and returns (as the update tag upd) k dot products (bits) of the form x j,t ·DK j , where DK j  is an appropriate n-bit substring of DK corresponding to the epoch of the j-th previously successful authentication by the user. Given the possible unknown bits in DK, the dot products x j,t ·DK j , 1≦j≦k, along with tag upd define a set E t  of k binary equations. Then, procedure Check DK (upd,upd′,DK,R DK,c   t ) returns inconsistent if and only if the set of binary equations E t ∪{upd′=x t ·DK t } is infeasible, where mask x t  is extracted from R DK,c   t  corresponding to current epoch t and DK t  is a new n-bit string (possibly overlapping with that of DK, but definitely including some unknown bit values) corresponding to current epoch t. In this case DK′ may be set to the binary string corresponding to the new system of equations expressed by E t ∪{upd′=x t ·DK t }. Otherwise, it outputs (DK′,consistent). 
     Exemplary Design 
     In one exemplary design, both the silent alarms and the drifting keys mechanisms are controlled by one of the two, red and blue, servers—without loss of generality by the blue server B. 
     1. The relying party RP is responsible for handling the authentication request by a user and making the final accept/reject decision on this authentication attempt; 
     2. Along with split verification, server B is responsible for maintaining and managing the silent alarm and drifting keys states of the system; 
     3. Server R is solely responsible for split verification. 
     The following multi-server protocol interaction takes place over the above architecture, where s denotes the appropriate slack parameter used to define the length of the exact search window W used by the server-side protocol: 
     1. User&#39;s Passcode Transcription. A user u i  submits an OTP passcode P′ to the high-level application APP; 
     2. Relying Party&#39;s Passcode Processing. As shown in  FIG. 5 , the relying party RP receives from a high-level application APP a pair (u i ,P′), where u i  is the user performing the authentication attempt and P′ the corresponding one-time passcode and performs the following processing: 
     (a) Initialization:  FIG. 5  illustrates an exemplary initialization process  500 . Initially, during step  510 , the relying party RP sets A→Ø and ans OTP →REJECT, and forwards (u i ,P′,t,ACK t ,d) to the two servers B and R, where t is the reference time epoch to which the authentication attempt made by the user corresponds, ACK t =1 is an acknowledgement message controlling the search procedure (e.g., enforcing it to non-exhaustively terminate), and d is a specific traversal ordering of the time epochs that belong in the search window W. 
     (b) Passcode Search:  FIG. 6  illustrates an exemplary passcode search process  600 . During step  610 , for each time epoch t in search window W that is retrieved by B and R, or optionally only by RP, (without repetition) according to traversal ordering d and optionally as long ACK=1, where ACK is the most recent ACK t  sent by RP: 
     i. Servers B and R run the split-server passcode verification protocol Π SV  during step  620 , each time returning back to server RP the outputs (M B,t ,M R,t ,t), where (M B,t ,M R,t )→Π SV (t,P′); 
     ii. Then, during step  630 , the server RP sets (a 1 ,a 2 )→Check SV (M B,t ,M R,t ) and if a 2 =accept then it adds (a 1 ,t) in A, i.e., A→A∪{a 1 ,t}. 
     iii. The server RP optionally sends back to servers B and R a message (t,ACK t ) during step  640 , where t is the next time epoch to be checked for verification, which is in turn selected by RP (without repetition) using the traversal ordering imposed by d over the time epochs that belong in the search window W, and ACK t ε{0,1} being a flag optionally denoting an early termination of the search. 
     (c) State Synchronization:  FIG. 7  illustrates an exemplary state synchronization process  700 . After the passcode search is complete, the two red and blue servers synchronize their state, according to the auxiliary information that has been embedded in the passcode and possibly extracted by the relying party RP as well as the corresponding time epoch during which a successful search was performed: 
     i. The server RP sends servers B and R a final response r during step  710 , where r is computed by processing set A as follows: 
     A. If A=Ø, then RP sets r=(⊥,⊥); 
     B. If A≠Ø, then RP selects an element a*=(aux*,t*) in A according to an election policy E and sets r=a* and ans OTP =ACCEPT. 
     ii. If r≠(⊥,⊥), then the red server R updates its local last successful epoch during step  720  to t*=r(2) (the second component of r). 
     iii. If r≠(⊥,⊥), then the blue server B updates its local last successful epoch during step  720  to t*=r(2) (the second component of r). 
     (d) Auxiliary Information Processing:  FIG. 8  illustrates an exemplary auxiliary information processing process  800 . As shown in  FIG. 8 , the blue server B performs the following processing of the auxiliary information r=a*=(aux*,t*) received during step  810 : 
     i. Silent Alarm Check: During step  820 , Server B sets h′=aux* SA , where aux* SA  is the silent-alarms portion of the auxiliary information (bit-string) aux* and using pseudorandomness R SA,b   t* , it first computes hash tag h→HashTag(SA,R SA,b   t* ) on the current silent alarm state SA and then checks for an alert by running (SA′,result SA )→Check SA (h,h′,SA,R SA,b   t* ). 
     ii. Drifting Keys Check: During step  830 , Server B sets upd′=aux* DK , where aux* DK  is the drifting-keys portion of the auxiliary information (bit-string) aux* and using pseudorandomness R DK,b   t* , it first computes update tag upd→UpdTag(DK,R DK,b   t* ) on the current drifting keys state DK and then checks for an inconsistency by running (DK′,result DK )→Check DK (upd,upd′,DK,R DK,b   t* ). 
     iii. Final Status Response: During step  840 , server B returns to server RP the final response r′=(f(SA,SA′),result SA ,result DK ), where f is a distance function over SA and SA′ states and f(SA,SA′)=⊥ if SA′ is ⊥, and result SA =result DK =⊥ if r=(⊥,⊥). 
     3. Relying Party&#39;s Final Response.  FIG. 9  illustrates an exemplary RP final response process  900 . As shown in  FIG. 9 , the server RP produces and returns to the high-level application APP the final answer by processing the final status response r′=(r 1 ,r 2 ,r 3 ) received by server B, as follows: 
     (a) If r 2 =alert then ans SA →REJECT SA,i  (where i possibly depends on r 1 , if r 1 ≠⊥), else ans SA →ACCEPT SA ; 
     (b) If r 3 =inconsistent then ans DK →REJECT DK , else ans DK →ACCEPT DK ; 
     (c) The server RP finally sets 
     answer=(ans OTP ,ans SA ,ans DK ). 
     As described, the exemplary protocol exhibits a natural trade off between communication and computation with respect to the concrete implementation of the passcode-search process of step 2.b. The relying party RP can either run the verification protocol Π SV  as a subroutine, by communicating to servers B and R the next time epoch t that the verification needs to run on, or RP can completely outsource to servers B and R the complete passcode-search process, by communicating to them only the initial reference time epoch and receiving in batch the evaluations of protocol Π SV  on every time epoch in the search window. Moreover: 
     (a) Depending on the configuration of the passcode-search process, the computation of the next time on which epoch protocol Π SV  should run can be performed by RP or by both B and R. In any case, this computation can be controlled by the traversal ordering parameter d. 
     (b) Depending on the configuration of the passcode-search process, the termination condition of this process may be specified implicitly by exhaustively searching in the search window or explicitly by an acknowledgement message sent in each iteration by the relying party RP. Alternatively, a “kill” signal can be sent by RP to terminate the search process. These “ack” or “kill” signals are decided by RP based on whether or not a successful passcode has been found in the search window as well as the specified false positive or false negative authentication parameters of the system. 
     Depending on the specified false positive or false negative authentication parameters of the system, the election policy E controls the way collisions (which happen with negligible probability) may be handled by RP. 
     The exemplary final outcome format contains three pieces: ans OTP  is the acceptance outcome with respect to the validity of the submitted passcode; ans SA  is the acceptance outcome with respect to a possible cloning attack against the token; and ans DK  is the acceptance outcome with respect to a possible seed-leakage attack against the OTP authentication system. The exact way with which the high-level application APP consumes the final authentication outcome answer is outside the scope of this invention. The exact way with which the high-level application APP can consume the final authentication outcome answer is described in the last section of this invention. 
     Alternative Design 
     In an exemplary alternative design, the silent-alarm state and drifting-keys state SA and DK, respectively, are stored and managed by the relying party RP, instead of being managed by the blue server B. This alternative configuration can have some important practical advantages in certain implementations of the disclosed split-server authentication system as it allows for more flexibility in managing the split-server authentication system (e.g., in implementing efficient recovery strategies). 
     Accordingly, the alternative design entails having server B communicating back to RP in the state synchronization step (c) the pseudorandomness R SA,b   t*  and the pseudorandomness R DK,b   t* , which are required in the computations of the auxiliary information processing step (d), and also having this step (d) run entirely by server RP. 
     Flexibility in Configurations 
     The silent alarms and drifting keys mechanisms are independent of one another. Thus, the silent alarms and/or drifting keys mechanisms can be added to or removed from any of the disclosed server-side system architectures (in particular, both the architecture of the first exemplary design and the architecture of the alternative design presented above) without any complications, in particular, even without any token-side design change in the case where a security mechanism is removed from the system architecture. For instance, in the first exemplary design described above, one of the two security mechanisms of silent alarms or drifting keys can be removed from the end system architecture by not storing the corresponding SA or DK state and not executing the corresponding procedures HashTag and Check SA  or UpdTag and Check DK  respectively, during the auxiliary information processing phase, thus not reporting in the final response phase any acceptance or rejection final state corresponding to the removed security mechanism. 
     Also, in both the first exemplary design and the alternative design described above, silent alarms and drifting keys, when supported, can be configured to be handled by any of the three parties, namely the red server R or the blue server B or the relying party RP, and independently of which server (the blue, the red or the replaying party) is responsible for handling the auxiliary-information channel. For instance, assuming that the client-side design is configured to provide pseudorandomness for silent alarms that is derived by the red forward-secure pseudorandom generator G r , the silent alarm state can be handled (stored and processed) by the red server, and not by the blue server (as in the first exemplary design) or the relying party (as in the alternative design). In such a case, it is straightforward to appropriately adapt the protocols above to support any new configuration. 
     Single-Server Configuration 
     Single-server configurations are also possible to support one or two of the silent alarms and drifting keys security mechanisms as described in the main or alternative designs described above. Indeed, it is possible to configure an architecture where there is only one server and the relying party interacting in the passcode verification protocol by appropriately changing the procedures for implementing passcode search and passcode verification so that they are hosted at one physical machine. Two different exemplary schemes are distinguished to implement such a single-server configuration: 
       FIG. 10  illustrates an exemplary single server configuration  1000  that employs a split module configuraton. The relying party RP and various exchanged values in  FIG. 10  operate in a similar manner to  FIG. 2 . As shown in  FIG. 10 , however, the separate functionalities of the red and blue servers are preserved but they are now implemented as distinct software modules R and B coexisting in the same machine  1010 , e.g., corresponding to two distinct processes running on the same physical or virtual execution environment. In other words, the token-side design supports the use of the red and blue forward-secure pseudorandom generators as discussed above, but now the server-side component of the OTP system does not employ these distinct portions as modules hosted by different machines/entities; instead these modules operate as before but are hosted by the same machine  1010 . Alternatively, this configuration can be supported by only one software module that simultaneously handles the red and blue functionalities, i.e., one process that maintains both the red and the blue pseudorandomness secret states. 
       FIG. 11  illustrates an exemplary single server configuration  1100  that employs a single module configuraton. As shown in  FIG. 11 , the red and blue portions of the OTP functionality are not supported by the token-side or by the server-side designs. Instead, there is only one forward-secure pseudorandom number generator that is employed, that is, one source of pseudorandomness used for the auxiliary channel and the silent alarms or the drifting keys security mechanisms. The separate functionalities of the red and blue servers are implemented by a single verification server  1110  that compares the presented passcode P′ to a computed passcode P t . It is straightforward to implement a passcode search and verification procedure that employs one such pseudorandom source: The server-side module searches in the search window to produce a passcode P t  that matches the candidate passcode P′ and produces valid auxiliary information (that is verified through the auxiliary channel functionality) which is, in turn, used by one or more of the two security mechanisms. 
     In the configurations of  FIGS. 10 and 11 , the silent-alarm and/or drifting key security mechanisms can be handled by either the server (and one of its two modules in the split-module configuration) or by the relying party, as described above. 
     Passcode Acceptance Policies 
     Let answer={ans OTP ,ans SA ,ans DK } be the final answer produced by the split-server (or single-server) passcode verification protocol (in any of the configurations described above). A further aspect of the invention addresses possible reactions of the high-level application APP that performs the authentication request to the relying party RP. Conveniently, by denoting an accept state with 1, a reject state with 0, and an unset state with ⊥, the final answer can be seen as a 3-bit value a 2 a 1 a 0 . 
     Normal Outcome—If answer=111 or answer=0⊥⊥, then APP allows or respectively denies access to the provided service to the end user; here, denial of authentication is due to a mistyping or not having knowledge of the passcode. 
     Silent Alarm Alert—If answer=101 or answer=10⊥, then APP enters in silent-alarm alert mode; this means that a physical or software-based cloning of the token has been detected. 
     Drifting Key Inconsistency—If answer=110 or answer=1⊥0, then APP enters in drifting-key inconsistency mode; this means that it has been detected a general cloning of the token. 
     Severe Danger Alert—If answer=111, then APP enters in severe-danger alert mode; this means that there have been detected two independent indications of cloning of the token. 
     Depending on a predefined policy, in silent-alarm alert mode or drifting-key inconsistency mode, APP may respond as follows by employing one or more of the following actions: 
     Restricted Access—The user is allowed access but in a restricted way. 
     Step-Up Authentication Request—The user is not allowed to access the service but instead the user is requested to make use of an additional secondary step-up authentication mechanism. 
     Access Denial Only—The user is simply denied access. 
     Honeypot Access—The user is virtually provided access but in a non-functional manner (e.g., seeing fake information, or fake out-of-service message, or experiencing a different API) so that at the same time the system is not at risk by the logged-in possible attacker, but the possible attacker is not notified that the system knows about the underlying attack, therefore, identification and punishment measures can be applied. 
     Depending on policy, in severe-danger alert mode, APP may respond by a stricter reaction. For instance it may deny access of the user to the service, permanently inactivate the user&#39;s account and notify the system administrator about the need to investigate on this token cloning strong evidence. 
     Conclusion 
     The foregoing applications and associated embodiments should be considered as illustrative only, and numerous other embodiments can be configured using the techniques disclosed herein, in a wide variety of different cryptography applications. 
     For example, both the split server and the auxiliary-channel handling methods described herein can be extended in the case of more than two servers, assuming a token-side design that supports such extensions. For instance, if a passcode comprises of three protocode parts, say red, blue and green, then vertical splitting can be considered into three corresponding parts. Splitting into more parts than the number of protocodes is also possible if the appropriate pseudorandom information is appropriately disseminated among the servers. Similarly, auxiliary-channel handling can be supported in multi-server settings. 
     It should also be understood that split-server verification, as described herein, can be implemented at least in part in the form of one or more software programs stored in memory and executed by a processor of a processing device such as a computer. As mentioned previously, a memory or other storage device having such program code embodied therein is an example of what is more generally referred to herein as a “computer program product.” 
     The embodiments described herein can provide a number of significant advantages relative to conventional practice. For example, these embodiments can advantageously provide improved scalability and support of auxiliary channels. Also, a wide variety of different OTP verification protocols can be implemented using the disclosed techniques. 
     Authentication processes in other embodiments may make use of one or more operations commonly used in the context of conventional authentication processes. Examples of conventional authentication processes are disclosed in A. J. Menezes et al., Handbook of Applied Cryptography, CRC Press, 1997, which is incorporated by reference herein. These conventional processes, being well known to those skilled in the art, will not be described in further detail herein, although embodiments of the present invention may incorporate aspects of such processes. 
     The communication system may be implemented using one or more processing platforms. One or more of the processing modules or other components may therefore each run on a computer, storage device or other processing platform element. A given such element may be viewed as an example of what is more generally referred to herein as a “processing device.” 
     Referring now to  FIG. 12 , one possible processing platform that may be used to implement at least a portion of one or more embodiments of the invention comprises cloud infrastructure  1200 . The cloud infrastructure  1200  in this exemplary processing platform comprises virtual machines (VMs)  1202 - 1 ,  1202 - 2 , . . .  1202 -M implemented using a hypervisor  1204 . The hypervisor  1204  runs on physical infrastructure  1205 . The cloud infrastructure  1200  further comprises sets of applications  1210 - 1 ,  1210 - 2 , . . .  1210 -M running on respective ones of the virtual machines  1202 - 1 ,  1202 - 2 , . . .  1202 -M under the control of the hypervisor  1204 . 
     The cloud infrastructure  1200  may encompass the entire given system or only portions of that given system, such as one or more of client, servers, controller, authentication server or relying server in the system. 
     Although only a single hypervisor  1204  is shown in the embodiment of  FIG. 12 , the system may of course include multiple hypervisors each providing a set of virtual machines using at least one underlying physical machine. 
     An example of a commercially available hypervisor platform that may be used to implement hypervisor  1204  and possibly other portions of the system in one or more embodiments of the invention is the VMware® vSphere™ which may have an associated virtual infrastructure management system such as the VMware® vCenter™. The underlying physical machines may comprise one or more distributed processing platforms that include storage products, such as VNX and Symmetrix VMAX, both commercially available from EMC Corporation of Hopkinton, Mass. A variety of other storage products may be utilized to implement at least a portion of the system. 
     Another example of a processing platform is processing platform  1300  shown in  FIG. 13 . The processing platform  1300  in this embodiment comprises at least a portion of the given system and includes a plurality of processing devices, denoted  1302 - 1 ,  1302 - 2 ,  1302 - 3 , . . .  1302 -D, which communicate with one another over a network  1304 . The network  1304  may comprise any type of network, such as a WAN, a LAN, a satellite network, a telephone or cable network, a cellular network, a wireless network such as WiFi or WiMAX, or various portions or combinations of these and other types of networks. 
     The processing device  1302 - 1  in the processing platform  1300  comprises a processor  1310  coupled to a memory  1312 . The processor  1310  may comprise a microprocessor, a microcontroller, an ASIC, an FPGA or other type of processing circuitry, as well as portions or combinations of such circuitry elements, and the memory  1312 , which may be viewed as an example of a “computer program product” having executable computer program code embodied therein, may comprise RAM, ROM or other types of memory, in any combination. 
     Also included in the processing device  1302 - 1  is network interface circuitry  1314 , which is used to interface the processing device with the network  1304  and other system components, and may comprise conventional transceivers. 
     The other processing devices  1302  of the processing platform  1300  are assumed to be configured in a manner similar to that shown for processing device  1302 - 1  in the figure. 
     Again, the particular processing platform  1300  shown in the figure is presented by way of example only, and the given system may include additional or alternative processing platforms, as well as numerous distinct processing platforms in any combination, with each such platform comprising one or more computers, storage devices or other processing devices. 
     Multiple elements of system may be collectively implemented on a common processing platform of the type shown in  FIG. 12 or 13 , or each such element may be implemented on a separate processing platform. 
     As is known in the art, the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a computer readable medium having computer readable code means embodied thereon. The computer readable program code means is operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein. The computer readable medium may be a tangible recordable medium (e.g., floppy disks, hard drives, compact disks, memory cards, semiconductor devices, chips, application specific integrated circuits (ASICs)) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used. The computer-readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic media or height variations on the surface of a compact disk. 
     As is known in the art, the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a machine readable recordable storage medium containing one or more programs. The one or more programs are operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein. 
     It should again be emphasized that the above-described embodiments of the invention are presented for purposes of illustration only. Many variations and other alternative embodiments may be used. For example, the techniques are applicable to a wide variety of other types of cryptographic devices and authentication systems that can benefit from distributed cryptography using distinct value sets as disclosed herein. Also, the particular configuration of communication system and processing device elements shown herein, and the associated authentication techniques, can be varied in other embodiments. Moreover, the various simplifying assumptions made above in the course of describing the illustrative embodiments should also be viewed as exemplary rather than as requirements or limitations of the invention. Numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.