WO2017040124A1 - System and method for detection of cloned devices - Google Patents

Abstract

Systems and methods are described for detecting cloning of authentication devices. In an exemplary embodiment, authorized users are provided with valid authentication devices (e.g. tokens). Each device internally generates a random anti-cloning key, such that the key is unknown to the device manufacturer. In use, a valid device receives an authentication challenge and provides a response that includes the anti-cloning key (or encrypted version thereof) in a subliminal channel. A cloned device may fail to make proper use of the subliminal channel, or if it does, it is unlikely to use the same internally-generated anti-cloning key as a valid device. A cloning detection system recognizes when different anti-cloning keys purport to be from the same valid device, indicating likely cloning of the valid device.

Description

SYSTEM AND METHOD FOR DETECTION OF CLONED DEVICES

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims priority to Provisional Application Serial No. 62/212,373, filed August 31, 2015, titled "SYSTEM AND METHOD FOR DETECTION OF CLONED DEVICES", which is incorporated in its entirety by reference.

BACKGROUND

[0002] Bulk theft of cryptographic keys from device manufacturers is an especially potent form of attack, as it permits an attacker to clone targeted devices clandestinely at will. Theft of a cryptographic key allows an attacker to create a device that is logically identical (though not necessarily physical identical) to a target device. Such cloning is a real and serious problem in practice.

[0003] For example, in 2010, authentication-token keys were stolen from RSA, the security division of EMC, and the keys were used to clone tokens and attack RSA customers such as Lockheed Martin. As another example, documents leaked by Edward Snowden appeared to reveal bulk compromise of SIM card keys (for mobile phones) from Gemalto by the NSA / GCHQ. In addition to compromise at the time of manufacture, cryptographic keys may be compromised in bulk due to poor randomization. Cryptographic keys also may be recovered on a per-device basis through side-channel attacks or hardware probing.

[0004] Apart from authentication tokens, an increasingly prevalent area of use for public-key cryptography is authentication of Internet-of-Things (IoT) devices, such as smart meters. Consequently, key compromise increasingly threatens the security of the physical infrastructure.

[0005] Swift detection of key compromise for embedded computing devices is thus of paramount importance in cybersecurity.

[0006] Known techniques for detection of cloned devices often rely on contextual information, such as the IP address, time of day, and other behavioral features associated with a login attempt. While it is an important element of defense in depth, contextual authentication is fragile and used only because compromise of the cryptographic keys of devices today generally permits perfect cloning of target devices. Contextual authentication systems tend either to encumber security operations centers with high false positive rates or have high false negative rates and overlook important anomalies.

[0007] Another approach to clone detection is to rely on a deterministically-changing device state, such as a counter, to derive an authentication value for transmission by the device. This technique is used to authenticate RFID / NFC-based credit-card transactions, thereby providing partial protection against "skimming" attacks, in which an attacker harvests codes from a device and replays them. See T.S. Heydt-Benjamin et al., Vulnerabilities in First-Generation RFID- Enabled Credit Cards, FINANCIAL CRYPTOGRAPHY AND DATA SECURITY, 2-14 (2007). The technique also provides partial protection against device compromise: given different transaction histories, the original and cloned devices may produce authentication- value sequences with clear duplication. It is used for this purpose, for instance, in the U2F standard of the FIDO Alliance. See Srinivas, Sampath, Dirk Balfanz, and Eric Tiffany, FIDO Universal 2nd Factor (U2F) Overview, FIDO ALLIANCE, (Feb. 2014) (Version vl . 0-rd-20140209).

[0008] Researchers have proposed schemes in which the state of a device evolves randomly, creating a difference in state between the true device and a cloned device. An observer of the states of the two devices may therefore detect a cloning attack.

[0009] A clone detection scheme has been proposed involving drifting keys (DKs) and device marking. See K. D. Bowers, A. Juels, R. L. Rivest, E. Shen, Drifting Keys: Impersonation Detection for Constrained Devices, INFOCOM, 1025-1033 (2013) and A.L. Young and M. M. Yung, The Prevalence ofKleptographic Attacks on Discrete-Log Based Cryptosy stems, CRYPTO, 264-276 (1997). These approaches involve leakage of secret state in a device output to a cloning detection system (CDS). The CDS uses this state to determine whether or not some output originated in a cloned device and thus the cryptographic key of the device has been compromised. Drifting keys, however, are specific to one-time passcode device, giving them a narrow field of use. Designs exist for their use only with symmetric-key cryptography, which exposes them to detection by an attacker that has compromised a device's cryptographic key.

[0010] Device marking is a technique using the process of kleptography— covert leakage of data from a cryptographic device— to detect device compromise. Device marking relies, however, on a channel specific to the Digital Signature Algorithm (DSA) standard, limiting its use. It has two other distinct technical drawbacks: (1) it requires pre-programming of a serial number, which either requires revealing the presence of the scheme to the device manufacturer or having a trusted entity program the device after manufacture, and (2) it leaks the device's cryptographic key to the CDS, undermining device integrity. The "device marking" scheme for detecting device compromise involves leakage of a pre-programmed 26-bit serial number through a kleptographic channel. See A.L. Young and M. M. Yung, The Prevalence of Kleptographic Attacks on Discrete- Log Based Cryptosy stems, CRYPTO, 264-276 (1997). The idea is that the CDS may check whether the serial number is correct in order to determine if a signature is a forgery resulting from theft of the device's cryptographic key. As noted above, this approach is technically narrow— applicable, in fact, only to DSA. Additionally, it has two other weaknesses: it requires pre- programing of the device with a serial number, which results in manufacturer knowledge of the serial number or owner access to the device to perform programming, and it leaks the cryptographic key to the CDS, which compromises the cryptographic integrity of the device.

[0011] In the case of RFID / NFC-based credit cards, the CVC or trailing digits of the card number are repurposed as designated fields for changing authentication values. See T.S. Heydt- Benjamin, et al., Vulnerabilities in First-Generation RFID-Enabled Credit Cards, FINANCIAL CRYPTOGRAPHY AND DATA SECURITY, 2-14 (2007). As part of the protocol specification (or as a result of output-based reverse-engineering), these fields and their use are visible to an adversary. Thus they may not be used surreptitiously to detect a cloning attack.

[0012] A similar issue exists for a scheme proposed by G. Itkis. See G. Itkis, Cryptographic Tamper Evidence, ACM CONFERENCE ON COMPUTER AND COMMUNICATIONS SECURITY, 355-364 (2003). The scheme protects a digital signing device against eavesdropping attacks and passive device compromise. This scheme involves a device building a randomly evolving certificate chain. Like the previous approach, this one requires modification of device outputs, and in fact consumes considerable bandwidth for a wirelessly-enabled embedded device. Its use is also visible to an attacker as part of the protocol specification or simply in the format of device outputs.

[0013] Similar drawbacks are characteristic of the related idea of "intrusion-resilient" cryptographic schemes, which protect both past and future keys against discovery when a device is compromised, rather than yielding evidence of compromise of keys. Additionally, while these schemes offer stronger security than cloning detection, they require that a device interact with a trusted third party called a "base" for each cryptographic operation, which is often impractical. See M. Franklin, A Survey of Key Evolving Cryptosy stems, 1(1) INTERNATIONAL JOURNAL OF SECURITY AND NETWORKS, 46-53 (2006) and G. Itkis, Forward Security - Adaptive Cryptography: Time Evolution, 3 HANDBOOK OF INFORMATION SECURITY, Chapter 199 (2006) (H. Bidgoli, ed., Wiley Publishers).

[0014] The article K. D. Bowers, A. Juels, R. L. Rivest, E. Shen, Drifting Keys: Impersonation Detection for Constrained Devices, INFOCOM, 1025-1033 (2013), proposed an alternative idea, called "drifting keys" (DKs), that is specifically tailored to low-bandwidth devices. See also U.S. Pat. No. 8,874,904. This scheme involves random evolution of a drifting key (DK) and regular partial transmission of its state. This technique may eliminate the two drawbacks noted above for other approaches. However, the technique has a major shortcoming: it does not work if the original device is unused for a long period of time. Additionally, DKs are a technique for transmitting a device secret; to use them, it is necessary to specify a channel for transmission. The only proposed channel for DKs is in one-time symmetric-key passcodes. See K. D. Bowers, A. Juels, R. L. Rivest, E. Shen, Drifting Keys: Impersonation Detection for Constrained Devices, INFOCOM, 1025-1033 (2013) and U.S. patent 8,984,609. In this setting, an attacker that compromises the device key of the authentication token may extract information from passcodes about the DK. In fact, given enough passcodes, an attacker may completely reconstruct the DK state and perfectly clone the device for a period of time. A weaker, related scheme for non-cryptographically enabled RFID tags is proposed by Zanetti et al. See D. Zanetti, S. Capkun, and A. Juels, Tailing RFID Tags for Clone Detection, DSS (2013).

SUMMARY

[0015] The present specification introduces systems and methods that permit detection of cloned devices that use stolen cryptographic keys. In some embodiments, the proposed systems and methods are implemented without special-purpose cryptographic hardware and, in many cases, without modification to output formats for the device being protected.

[0016] Exemplary systems and methods disclosed herein implement a beneficial use of a technique referred to as kleptography. Kleptography is a technique that may be used by attackers for the stealing of cryptographic keys. However, in the present disclosure, kleptography is employed defensively as a subliminal channel to relay a device-specific anti-cloning key (ACK) covertly to the device owner or another trusted entity. A cloned device created using a stolen private key will emit the wrong ACK, leading to its detection.

[0017] In a further aspect of the present disclosure, a new kleptographic channel is proposed for use with DSA (the Digital Signature Algorithm) or ECDSA (Elliptic Curve Digital Signature Algorithm). In exemplary embodiments, the new kleptographic channel does not require leakage of a device's private key to the entity performing cloning detection.

[0018] Systems and methods described herein operate to allow detection of compromise of device private keys. Such systems and methods may be used to protect against the most common and dangerous forms of bulk secret / private key compromise of devices, such as theft of programmed cryptographic keys from a device manufacturer (as allegedly happened to RSA). Exemplary systems and methods disclosed herein enable detection of such compromise upon reception of outputs from both real and cloned devices.

[0019] In at least some embodiments, the use of the systems and methods disclosed herein is clandestine, such that the use of the systems and methods is not detectable in device outputs by any entity other than the cloning detection system (CDS). In the view of all other entities, the format and data contents of device outputs are indistinguishable from those of standard cryptographic protocol implementations in which no compromise-detection scheme is present. [0020] The present disclosure describes embodiments including (1) the use of kleptography to achieve cloning detection while preserving the confidentiality of the private key of the device with respect to the CDS; in this case, the ACK may be generated at any time and may be selected by or transmitted to the CDS, as in "device marking" solutions; and (2) The use of kleptography with an ACK not used or stored by the CDS; in this case, the device private key may or may not be kept confidential with respect to the CDS.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] FIG. 1 is a functional block diagram of a cryptographic device and a cloning detection system.

[0022] FIG. 2 is a flowchart of an exemplary method of responding to a challenge message.

[0023] FIG. 3 is a flowchart of an exemplary method of determining validity of devices sending challenge message responses.

[0024] FIG. 4 is a functional block diagram of an exemplary wireless transmit/receive unit (WTRU) that may be used as a device, such as an authentication token, in some embodiments.

[0025] FIG. 5 is a functional block diagram of an exemplary network entity that may be used as a cloning detection system in some embodiments.

DETAILED DESCRIPTION

[0026] Most previous techniques for compromise detection that are based on either deterministic or randomized state evolution have two drawbacks: (1) they require designated fields in device transmissions for authentication values, and thus consume extra bandwidth and (2) their compromise-detection mechanism is an explicit and visible protocol element. Thus an adversary may easily learn of the existence of such schemes in a targeted device.

Anti-Cloning Key.

[0027] In the present disclosure, a secondary key used to detect a cloned device is referred to as an anti-cloning key (ACK).

[0028] In an exemplary embodiment, at a time subsequent to manufacture of a secured device such as an authentication token— e.g., on the first use of the device— the device randomly generates an ACK. Both the value of the ACK and even the existence and use of the ACK may be treated by the device owner (and/or the operator of a cloning detection system) as secrets.

[0029] The ACK, or at least a portion of the ACK, is embedded in device outputs using a kleptographic channel. A cloning detection system (CDS) receives the device output and may extract ACK data from device outputs, but it is not feasible for any other entity to extract ACK data (or even to detect the existence of the ACK data).

[0030] On receiving multiple device outputs, the CDS extracts the ACKs embedded in these outputs. It checks that the ACK values they contain are consistent. If they are not consistent, the CDS determines that the device has been cloned.

[0031] If an adversary steals the device private key but does not know about the existence of the ACK, the adversary may attempt to use an ordinary cryptographic algorithm, rather than one instrumented to transmit an ACK. In this case, the ACKs extracted by the CDS will be essentially random and thus have a high probability of differing from one another and from the ACK of the true device. Thus, the CDS detects the production of the clone. If the adversary does know about the existence of the ACK, it may create a clone device that transmits a consistent ACK. However, if the adversary does not know the value of the true ACK, then the cloned ACK will differ from the true ACK with high probability. Thus, the CDS is still very likely detect the existence of the clone.

[0032] In general, the systems and methods disclosed herein may detect device cloning provided that an adversary does not physically tamper with targeted devices post-manufacture and recover their ACKs. Because such an attack would require physical handling of individual devices, this attack is impractical for an adversary to mount at scale.

Exemplary Features.

[0033] Exemplary systems and methods disclosed herein provide reliable detection of device compromise. The disclosed use of a kleptographic channel provides some advantages over the use of other channels for compromise detection in cryptographic devices. For example, exemplary methods use public-key cryptography, so that even an attacker that has compromised a device's cryptographic key may not learn the device's ACK. The ACK is generated internally and is not susceptible to discovery by an external attacker. Moreover, exemplary methods preserve the output format of standard cryptographic protocols and thus are clandestine in the sense that a kleptographically-enabled device is, from the point of view of an eavesdropper, practically indistinguishable from an ordinary device that does not use kleptography.

[0034] At least some of the embodiments of the disclosed systems and methods have certain advantages over device marking. For example, exemplary embodiments do not require the preprogramming of a serial number in a device. The ACK is generated internally and does not need to be generated externally and stored in the device. Thus use of the disclosed techniques need not be revealed to the device manufacturer and there is no need to introduce a secret programming step for devices outside the manufacturer facility. The disclosed systems and methods are furthermore not limited to the use of DSA. Rather, exemplary methods may be implemented using any cryptographic system in which there is a kleptographic channel capable of transmitting arbitrary data. Several such channels are known to those of ordinary skill in the art.

[0035] Further disclosed herein is a new kleptographic channel for DSA and ECDSA. This kleptographic channel does not require leakage of the device cryptographic key to the CDS. Leakage of a device's cryptographic key undermines the device' s cryptographic integrity. In exemplary embodiments, the CDS is able to detect cloning without having access to the device' s cryptographic key.

Exemplary Embodiments.

[0036] FIG. 1 provides an illustration of a cryptographic device and a cloning detection system. In the illustration of FIG. 1, dashed lines indicate message flows for static values; these flows occur only once in the system, e.g., for programming of static keys. Solid lines indicate message flows that occur repeatedly, upon each use of the crypto module.

[0037] Exemplary embodiments are implemented using an authentication device 160 that contains a cryptographic module 162 and has an associated device-specific private / public key pair (SKd, PKd), where dis a unique device identifier. The private key SKd may be stored at memory location 164. The pair (SKd, PKd) is referred to as a pair of device keys. The device key pair may be generated externally or internally, although an external device-key generator 168 is illustrated by way of example in FIG. 1.

[0038] In an ordinary cryptographically-enabled device, such as a smartcard, a crypto module 162 in the device 160 stores the key SKd. The device 160 takes as input a challenge message , and applies the key SKd to yield an output value∑. For example, if the device computes digital signatures, it executes an algorithm "Sign" that yields as output a signature∑. An external verifier with knowledge of PKd may check that∑ was produced by application of the correct private key SKd to the message M.

[0039] One example is a smartcard, such as an EMV card, a device used to execute payments. When making an offline payment, an EMV card receives a message M containing transaction details, digitally signs them (using an RSA-based digital signature algorithm specified in the ISO/IEC 9796-2 standard), and transmits a signature 27. The card also transmits a digital certificate containing PKd . An external device, such as a payment terminal, may verify the correctness of∑ using PKd and thus determine that a valid card was used in the transaction. [0040] FIG. 1 shows the system components and main message flows in an exemplary clone detection infrastructure 140. The cloning detection system (CDS) 150 detects thefts of the key SKd and its use in a clone device. The CDS 150 has its own associated private / public key pair (sk, pk) referred to herein as the klepto-key pair.

[0041] In an exemplary embodiment, an authentication device 160 has a communication interface for receiving challenge messages and sending challenge message responses. The authentication device 160 also has an anti-cloning key generation module 166 to generate a random anti-cloning key (ACK). In at least one embodiment, the anti-cloning key generation module is operative to generate the anti-cloning key only once. The ACK and a private key are stored in a non-transitory storage medium. The authentication device 160 also has a cryptographic module 162 that is operative to generate a challenge response that is based on the challenge message and the private key. The challenge response includes the anti-cloning key in a subliminal channel. In one embodiment, generation of the challenge response comprises generating at least one digital signature of the challenge message using the private key and selecting one of the generated digital signatures that is consistent with the anti-cloning key.

[0042] In an exemplary embodiment, the crypto module 162 on the device 160 receives two additional inputs. The first is public klepto-key pk generated by the CDS' klepto-key generator 152 in one embodiment. The second is a device-specific anti-cloning key (ACK) rtid*. The key rtid* is randomly generated in the device 160 itself.

[0043] In an exemplary embodiment, when the device 160 performs digital signing, it executes a special digital signature algorithm "klepto-sign" (rather than an ordinary digital signature algorithm "sign"). The algorithm klepto-sign takes as input the two values pk and rtid*, which an ordinary digital signature algorithm sign does not. These inputs may be stored within the crypto module 162 of the device 160 (or, in an alternative embodiment, stored in external memory). Like an ordinary digital signature algorithm, klepto-sign also takes as input a message M and outputs a signature 27. A special feature of 27 for klepto-sign, however, is that it contains some portion of the ACK rtid* encrypted under the public klepto-key pk using, for example, an XOR operation with a Diffie-Hellman-type key, as described in greater detail below.

[0044] To an uninformed external observer, such as an eavesdropper, the functionality of the crypto module 162 in exemplary embodiments is indistinguishable from the functionality of an ordinary one performing the same public-key cryptographic algorithm. Thus, without knowledge of sk, no external entity may distinguish between execution of "klepto-sign" and "sign".

[0045] The CDS 150 receives messages produced by (or purporting to be produced by) the device d 160, specifically output, device ID pairs (27, IDd), where H¾ is a unique identifier for device d 160— e.g., the public key PKd. Using a function "extract" on inputs sk and∑, an ACK Extractor 154 of the CDS extracts the ACK (or a portion thereof) from∑. The CDS 150 stores in a database all ACK values recovered for a particular device d 160. If inconsistent ACK values arise for a given device 160, a Cloning Detector 156 of the CDS outputs an alert in the form of a cloning detection report R. The report R indicates the identifier d of the cloned device 160, but it may include other contextual information as well (e.g., timestamps on receipt of device outputs).

[0046] The path for transmission of ACKs in signatures may be viewed as a communication channel; specifically, as it is detectable only by the CDS 150, it is a kleptographic channel. Disclosed herein is a new kleptographic channel that, unlike those in previous schemes, does not leak the private key SKd. This channel may be implemented in DSA and ECDSA, two popular digital signature schemes.

Challenge Messages.

[0047] FIG. 2 is a flowchart of an exemplary method for responding to a challenge message. The method 200 has a device randomly generate an anti-cloning key (ACK) 202. In some embodiments, the generation of an anti-cloning key is performed only once, e.g. in a setup process, or upon the first use of the device. In operation of the device to perform an authentication function, the device receives a challenge message 204. The device encrypts an ACK as part of generating a digital signature of the challenge message 206. In one embodiment, the at least one digital signature is generated using the Digital Signature Algorithm, which is described below. In another embodiment, the at least one digital signature is generated using the Elliptic Curve Digital Signature Algorithm, which is also described below. In one embodiment, the generation of the anti-cloning key is performed only once by the device. The encryption of the ACK may be performed, for example, so that a shared key generated by the Diffie-Hellman key generation process may be used for decryption. Also, the encryption of the anti-cloning key may be performed using a shared key K. An extraction function is applied to the digital signature to extract a predetermined number of bits (one or more bits) from the signature. The device may reject the digital signature calculated because it is inconsistent with the ACK, a process that compares the extracted bits with the encrypted anti-cloning key (ACK). The device calculates a new digital signature and compares it with the ACK for consistency 208. This process is repeated until a digital signature is calculated that is consistent with the ACK. In some embodiments, the digital signature is considered to be consistent with the anti-cloning key if and only if the extracted bits are equal to the encrypted anti-cloning key. Once a consistent digital signature is generated, the device will respond to the challenge message with the selected digital signature 210. Method 200 is described in more detail below as part of an example. [0048] FIG. 3 is a flowchart of an exemplary method for detection of cloned device. In step 302a, a challenge message is sent by a cloning detection system to a device seeking authentication. In this example, the challenge message sent in step 302a is received by an authentic (uncloned) device. In step 303a, the device generates and sends a response to the challenge message, with the response being selected so as to convey the anti-cloning key (ACK), or at least a portion thereof, in a subliminal channel. It should be understood that the challenge response may also undergo conventional tests for validity, such as confirmation that the challenge response includes a valid digital signature, but such steps are not illustrated in FIG. 3. In step 304a, the cloning detection system extracts the ACK from the subliminal channel. Because the ACK is generated internally by each device, the cloning detection system does not initially have information for identifying a "correct" ACK for a particular device. Rather, the cloning detection system stores information on previously-extracted ACKs from devices that purport to be the same device and checks that information for consistency.

[0049] The cloning detection system may send out another challenge message in step 302b. The message is received and used to generate another challenge response by the valid device in step 303b, with the ACK being provided in a subliminal channel of the response. In step 304b, the cloning detection extracts the ACK. In step 302c, however, the cloning detection system sends a challenge message to a device that is a clone of the authentic device. In step 303c, the clone generates and sends a challenge response. If the clone has been generated using the private key of the authentic device, the clone may succeed in generating a valid response in the challenge- response protocol (e.g. by digitally signing the challenge message using the stolen private key). However, the clone is not likely to provide the same ACK as the authentic device, either because the party responsible for the clone is unaware that an ACK is being used at all, or because that party, though aware of the use of an ACK, has no access to the internally-generated ACK of the valid device. Thus, in step 304c, when the cloning detection system extracts the ACK, the result is likely to be different from the results obtained in steps 304a and 304b. In step 306, the extracted ACKs are compared.

[0050] In the embodiment of FIG. 3, the comparison is performed to determine whether all extracted ACKs that purport to be from the same device are identical (step 307). If so, continued use of the device for authentication purposes is permitted (step 306). If, however, at least one of the extracted ACKs that purport to be from the same device is different from the others, then it is likely that the device has been cloned. An alert may be issued (step 308), and, among other possible actions, further authentication by a cloned device may be disallowed. For example, a digital certificate associated with the cloned device may be revoked. [0051] A comparison 307 that detects whether all ACKs that purport to be from the same device are identical is just one example of comparisons that can be performed. For example, the ACK of a device may be configured to change slowly but randomly over time. In such an embodiment, small differences between consecutive extracted ACKs may not be sufficient to indicate a clone. Rather, cloning may be detected when differences between consecutive ACKs are unexpectedly large (e.g. statistically improbable) given a known elapsed time between authentications. Other techniques for clone detection using extracted ACKs may also be used.

[0052] In some embodiments, extracting an anti-cloning key from a challenge response, as in steps 304a, 304b, and 304c, comprises generating a shared key K, extracting a predetermined number of bits from the challenge response to generate an outcome, and decrypting the outcome with the shared key K, wherein the decrypted outcome is the anti-cloning key.

Exemplary Kleptographic Channel.

[0053] Publication FIPS PUB 186-4: Digital Signature Standard (DSS) , July 2013, describes the Digital Signature Algorithm (DSA). The operation of the DSA may be described as follows. Let q and p be prime numbers with bit lengths given by a parameter option specified in the publication (e.g., \q\ = 160, \p\ = 1024). Let N be the bit length of q. Let min(N, outlen) denote the minimum of the positive integers N and outlen, where outlen is the bit length of the output block of the hash function HQ. Let & be a value selected uniformly at random from [1, q]. Let g be a q^ root of 1 mod p, x in [0, q-l] be a private DSA key, and .y = g^x mod p be the corresponding public key.

[0054] Given the foregoing, the DSA signature of a message M includes a pair of numbers r and s that are computed according to the following equations:

r = (g^k mod p) mod q. z = the leftmost min(N, outlen) bits of H(M). s = (k^~l (z + xr)) mod q.

[0055] It is observed that

_mod p = g^k mod p in the article A.L. Young and M. M. Yung, The Prevalence of Kleptographic Attacks on Discrete-Log Based Cryptosy stems, CRYPTO, 264-276 (1997). Thus, given the public key y, a receiver of (r, s) can compute g . Let x* denote a private key for the kleptographic channel receiver (CDS) and_y* = g^x* be the corresponding public key.

[0056] Let bit{K) denote a one-bit predicate on a key K (of length outlen). Let bit*(r, s) denote a one-bit predicate on the pair (r, s). For example, bit() may be the first bit of K and bit*() may be the first bit of H(M \\ r \\ s). [0057] An exemplary procedure for the device to embed a one-bit message m* into a kleptographic channel is a procedure "klepto-sign" with inputs p, q, g, x, M, m*, and y*. The exemplary procedure operates as follows:

1. Generate a signature (r, s) on the target message M. using the random per-message value k.

2. Generate a key K, where K = H((y*†) = Hig?^). This calculation may be viewed as a Diffie-Hellman key derivation.

3. Encrypt the message m* by calculating c = bit(K) XOR m*

4. 1f c≠ bit*(r,s) go back to Step 1, using a newly-generated value for k.

5. Output (r,s).

[0058] An exemplary procedure for recovery of one-bit message m * may be performed executed via a procedure "extract" using inputs p, q, g, (r, s), and x*. The procedure "extract" may operate as follows.

1. Compute

= g mod p.

2. Compute K = H((g*/^*) = Hfe^***).

3. Output bit*(r,s) XOR bit(K).

[0059] It is likely to be provable that if an adversary given , y, and (r, s) may only guess bit{K = H(ff^* )) with non-negligible advantage, then the signature scheme induced by this embedding achieves security against signature forgery close to that of DSA. Such non-negligible advantage holds for the example bitQ function (first bit of K) in the random oracle model under the Computational Diffie-Hellman (CDH) assumption.

[0060] The expected running time of the "klepto-sign" procedure (in terms of the number of loops) is 2^|m*L Thus, it is only efficient for small m*. For the purposes of clone detection, this computational overhead is not unduly burdensome. Even a one-bit ACK may detect a cloning attack with high probability given a few compromised devices, because it is unlikely that all clones will provide the same bit. The procedure "extract" uses two modular exponentiations and is efficient for any length of ACK m* that may be embedded in the target digital signature scheme.

[0061] The kleptographic channel construction described above may also be used to convey messages m* of length greater than 1 bit. To do this, the functions bitQ and bit*Q for extracting a single bit may be replaced with multi-bit equivalents for extracting a predetermined number of bits, e.g. returning the first N bits of their respective operands, or N bits arranged in at predetermined locations in the operand (e.g., at the third, fifth, seventh, and ninth positions of the operand), and the XOR operations are replaced with corresponding bitwise operations.

[0062] As a simplified but concrete example, a device may generate a two-bit random ACK, which may, for example, be ' 10' . The device encrypts the ACK in a way that may be decrypted by the CDS, for example using a Diffie-Hellman key generated using the public key of the CDS. For the purpose of this example, assume the encrypted ACK has the value ' 11 ' . In operation of the device, the device may receive a challenge message M, such as Ί 10011110011 ' . The device runs a signature algorithm on the challenge message, generating a signature∑ having a length of four bits. In this exemplary embodiment, the device repeats the signature algorithm until the final two bits of the signature∑ are equal to the two bits ' 11 ' of the encrypted ACK value. For example, the first time the message M is signed, the signature output may be∑= 1100. This signature is rejected because the final two digits are not Ί . The signature algorithm is performed again, resulting in ∑ = 1100. This signature is again rejected. On a third attempt, the device generates a signature ∑ = 1011. This signature is accepted because its final two digits are ' 11.'

[0063] As an alternative to matching the last two (or last N) digits of the digital signature with the ACK, other techniques may be employed to determine whether the signature is consistent with the ACK. For example, the system may implement a requirement that a predetermined number of bits extracted from the signature∑ (e.g. extracted from predetermined positions, or extracted using a checksum, a hash function, a modular sum, or other function) be equal to the ACK value or to the encrypted ACK value.

[0064] The kleptographic channel may also be implemented via the Elliptic Curve Digital Signature Algorithm (ECDSA). The process is almost identical with that for ordinary DSA, except that g^k is a point on an elliptic curve that is expressed in terms of its x-coordinate. The process is simpler in ECDSA, as is given explicitly in the signature pair value r as the x-coordinate of an elliptic curve point representing g*.

[0065] In some embodiments, the ACK value varies over time. Such embodiments allow detection of cloning of devices that have been physically tampered with in the field. However, tradeoffs may include engineering complexity and the difficulty of detecting cloning of devices that have gone unused for a long time.

[0066] In some embodiments, the clone detection systems and methods described herein are implemented using ACK information embedded in non-cryptographic outputs. For example, the low order bits of device-output timestamps are used in some embodiments as a channel for transmission of ACKs. Other subliminal channels and/or steganographic channels may also be used by a clone detection system. [0067] In some embodiments, the CDS database stores, in addition to extracted ACK values, timestamps and other contextual information around its reception of device outputs. For example, if the device is an EMV card, the CDS database may receive and store information identifying the point-of-sale device with which it was used. Such information may be helpful for investigations into key theft and/or device cloning.

Further Exemplary Embodiments.

[0068] Embodiments disclosed herein may be implemented to improve systems where public- key cryptography is used to authenticate embedded devices and their data, and thus where the threat of key compromise exists. Devices and systems that may benefit from clone detection embodiments include the following, among other devices and systems.

[0069] Authentication tokens. Some embodiments are used to improve the security of authentication tokens. User-authentication devices are increasingly making use of public-key cryptography. Theft of device keys from authentication tokens permits impersonation of users using cloned tokens. Some authentication tokens, such as U2F tokens, may not contain pre- installed device keys, but contain batch keys that authenticate their provenance. Theft of batch keys would permit black-market tokens to be manufactured.

[0070] IoT Devices. As physical devices such as sensors and household appliances are increasingly connected to the internet to form an "internet of things" (IoT), authentication will serve a variety of purposes, e.g., authorization of firmware updates and authentication of data used for analytics on device-generated data. For example, a home monitoring system may authenticate itself, its owner, and the video / audio it produces to a service provider. Theft of keys could permit the manufacture of black-market clone devices as well as enabling privacy violations resulting from unauthorized access to device data. Stolen keys for a home-monitoring device could be used to impersonate the owner and steal her video / audio feeds.

[0071] Smart Meters. The declining cost of low-cost microcontrollers makes use of public-key cryptography increasingly viable for a wide range of smart grid devices (a key subclass of IoT device), such as smart electric meters. Theft of keys could enable clone devices to be created that bill costs to victims.

[0072] Payment Devices. As noted above, EMV cards use public-key cryptography to authenticate offline transactions. Smartwatches often have NFC interfaces, and could use similar technologies. Theft of keys would permit authentication of bogus transactions.

[0073] Hardware Roots of Trust: Hardware-root-of-trust technologies, such as Trusted Platform Modules (TPMs) and Intel's soon-to-be-released SGX (Software Guard extensions) include device keys that authenticate their provenance. An attacker that may clone these devices may bypass the hardware security guarantees provided by these technologies.

[0074] In an exemplary embodiment, the systems and methods disclosed herein operate to detect cloning of a public-key-based enterprise authentication token with a pre-installed key pair. This type of token typically authenticates a user by releasing digital signatures on random challenges sent to the token (by, e.g., a website). A public-key-based token does not support user passcode transcription. Thus, the token may be plugged into a USB port or communicate with a user device via a short-range wireless protocol such as NFC, as is done with some models from YubiKey, for example.

[0075] In this exemplary embodiment, when the token manufacturer produces a token with identity d, the manufacturer generates a key pair (SKd, PKd) and programs the private (secret) key ,S¾into the token. When a customer buys the token, the manufacturer also supplies the customer with the public key PKd— potentially with an accompanying certificate— for use in an authentication system.

[0076] During or after manufacture, the token internally generates and stores an ACK ntd*. This operation may be performed using, for example, a random number generator or pseudorandom number generator internal to the token. As used in this disclosure, the term "random" includes "pseudorandom" unless otherwise specified.

[0077] Enterprise employees use tokens to authenticate themselves when accessing enterprise resources, such as email or intranet resources. When the token is used, it takes as input a challenge M and outputs a pair (∑, IDd), where∑ is a signature on Musing SKd. The pair is validated by an enterprise authentication server against the device public key PKd.

[0078] A CDS, which may be run by the enterprise security operations center or by an external security provider, receives all pairs (∑, IDd) generated by tokens in the enterprise. If it detects inconsistent ACKs associated with a given token, and thus suspected cloning of the token, it generates a report R for the enterprise security operations center.

[0079] Upon detection of token cloning, a security operations center may take actions such as deactivating the relevant user account, or instigating a forensic investigation to determine the source of key leakage, among other actions.

[0080] Some embodiments of the systems and methods disclosed herein permit implementation without requiring changes to existing cryptographic or other standards.

[0081] Companies involved in the sale or manufacture of a cryptographically-enabled device that uses public-key cryptography would benefit from use of this invention, particularly given incidents of key theft in the security industry. Wirelessly-enabled embedded devices are especially prominent in this category, and, as noted above, include a variety of IoT devices. Pertinent devices also include cryptographic authentication tokens (e.g., the Google-supported YubiKey, RSA SecurlD 800), RFID / NFC payment devices that use public-key versions of EMV (primarily in Europe), and the like. Note that the manufacturers of such devices often outsource their production to third parties, from whom cryptographic keys may be stolen.

[0082] Note that various hardware elements of one or more of the described embodiments are referred to as "modules" that carry out (i.e., perform, execute, and the like) various functions that are described herein in connection with the respective modules. As used herein, a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices) deemed suitable by those of skill in the relevant art for a given implementation. Each described module may also include instructions executable for carrying out the one or more functions described as being carried out by the respective module, and it is noted that those instructions could take the form of or include hardware (i.e., hardwired) instructions, firmware instructions, software instructions, and/or the like, and may be stored in any suitable non-transitory computer- readable medium or media, such as commonly referred to as RAM, ROM, etc.

[0083] Exemplary embodiments disclosed herein are implemented using one or more wired and/or wireless network nodes, such as a wireless transmit/receive unit (WTRU) or other network entity.

[0084] FIG. 4 is a system diagram of an exemplary WTRU 102, which may be employed as an authentication device in embodiments described herein. As shown in FIG. 4, the WTRU 102 may include a processor 118, a communication interface 119 including a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and sensors 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0085] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 4 depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0086] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station over the air interface 115/116/117. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0087] In addition, although the transmit/receive element 122 is depicted in FIG. 4 as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MTMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

[0088] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples.

[0089] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), readonly memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SFM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0090] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. As examples, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), and the like), solar cells, fuel cells, and the like.

[0091] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0092] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include sensors such as an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0093] FIG. 5 depicts an exemplary network entity 190 that may be used in embodiments of the present disclosure, for example as a cloning detection system. As depicted in FIG. 5, network entity 190 includes a communication interface 192, a processor 194, and non-transitory data storage 196, all of which are communicatively linked by a bus, network, or other communication path 198.

[0094] Communication interface 192 may include one or more wired communication interfaces and/or one or more wireless-communication interfaces. With respect to wired communication, communication interface 192 may include one or more interfaces such as Ethernet interfaces, as an example. With respect to wireless communication, communication interface 192 may include components such as one or more antennae, one or more transceivers/chipsets designed and configured for one or more types of wireless (e.g., LTE) communication, and/or any other components deemed suitable by those of skill in the relevant art. And further with respect to wireless communication, communication interface 192 may be equipped at a scale and with a configuration appropriate for acting on the network side— as opposed to the client side— of wireless communications (e.g., LTE communications, Wi-Fi communications, and the like). Thus, communication interface 192 may include the appropriate equipment and circuitry (perhaps including multiple transceivers) for serving multiple mobile stations, UEs, or other access terminals in a coverage area.

[0095] Processor 194 may include one or more processors of any type deemed suitable by those of skill in the relevant art, some examples including a general-purpose microprocessor and a dedicated DSP.

[0096] Data storage 196 may take the form of any non-transitory computer-readable medium or combination of such media, some examples including flash memory, read-only memory (ROM), and random-access memory (RAM) to name but a few, as any one or more types of non-transitory data storage deemed suitable by those of skill in the relevant art could be used. As depicted in FIG. 5, data storage 196 contains program instructions 197 executable by processor 194 for carrying out various combinations of the various network-entity functions described herein.

[0097] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a device to be authenticated, the method comprising:

randomly generating an anti-cloning key;

receiving a challenge message;

generating at least one digital signature of the challenge message;

from among the generated digital signatures, selecting one of the digital signatures that is consistent with the anti-cloning key; and

responding to the challenge message with the selected digital signature.

2. The method of claim 1, further comprising generating a shared key K, wherein selecting a digital signature that is consistent with the anti-cloning key includes:

encrypting the anti-cloning key using the shared key K;

extracting a predetermined number of bits from the digital signature; and

determining whether the extracted bits are equal to the encrypted anti-cloning key, wherein the digital signature is consistent with the anti-cloning key if and only if the extracted bits are equal to the encrypted anti-cloning key.

3. The method of claim 2, wherein the shared key K is generated using wherein His a hash function, y* is a public key associated with a cloning detection system, and & is a random per-message value used in generating the digital signature.

4. The method of claim 2, wherein the extracting of a predetermined number of bits is performed by selecting bits from at least one predetermined location in the digital signature.

5. The method of claim 1, wherein selecting a digital signature that is consistent with the anti- cloning key includes:

extracting a predetermined number of bits from the digital signature; and

determining whether the extracted bits are equal to the anti-cloning key, wherein the digital signature is consistent with the anti-cloning key if and only if the extracted bits are equal to the anti-cloning key.

6. The method of any of claims 1-5, wherein each of the digital signatures is generated using a different random per-message value k.

7. The method of any of claims 1-6, wherein the step of generating at least one digital signature is repeated until a digital signature consistent with the anti-cloning key is selected.

8. The method of any of claims 1-7, further comprising responding to a plurality of challenge messages using the same anti-cloning key.

9. The method of any of claims 1-8, wherein the generation of the anti-cloning key is performed only once by the device.

10. The method of any of claims 1-9, wherein the at least one digital signature is generated using the Digital Signature Algorithm.

11. The method of any of claims 1-9, wherein the at least one digital signature is generated using the Elliptic Curve Digital Signature Algorithm.

12. An authentication device comprising:

a communication interface operative to receive a challenge message and send a challenge response;

an anti-cloning key generation module operative to generate a random anti-cloning key; at least one non-transitory storage medium operative to store a private key and the anti- cloning key;

a cryptographic module operative to generate the challenge response based on the challenge message and the private key, the challenge response including the anti-cloning key in a subliminal channel.

13. The authentication device of claim 12, wherein the anti-cloning key generation module is operative to generate the anti-cloning key only once.

14. The authentication device of any of claims 12-13, wherein the cryptographic module is operative to generate the challenge response using steps comprising: generating at least one digital signature of the challenge message using the private key; and

from among the generated digital signatures, selecting one of the digital signatures that is consistent with the anti-cloning key.

15. A clone detection method comprising:

sending a plurality of challenge messages to at least one device purporting to be a valid device;

receiving a plurality of respective challenge responses from the at least one device;

extracting respective anti-cloning keys from the challenge responses by (i) generating a shared key K, (ii) extracting a predetermined number of bits from the challenge response; and (iii) decrypting the extracted bits with the shared key K, wherein the decrypted outcome is the anti- cloning key; and

comparing the extracted anti-cloning keys to determine whether the valid device has been cloned.