WO2008037000A1 - Inhibition du clonage de dispositifs matériels par des processeurs logiciels polyvalents - Google Patents

Inhibition du clonage de dispositifs matériels par des processeurs logiciels polyvalents Download PDF

Info

Publication number
WO2008037000A1
WO2008037000A1 PCT/AU2007/001410 AU2007001410W WO2008037000A1 WO 2008037000 A1 WO2008037000 A1 WO 2008037000A1 AU 2007001410 W AU2007001410 W AU 2007001410W WO 2008037000 A1 WO2008037000 A1 WO 2008037000A1
Authority
WO
WIPO (PCT)
Prior art keywords
requester
authenticator
communications
cryptographic algorithm
cryptographic
Prior art date
Application number
PCT/AU2007/001410
Other languages
English (en)
Inventor
Sean O'neil
Original Assignee
Synaptic Laboratories Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2006905274A external-priority patent/AU2006905274A0/en
Application filed by Synaptic Laboratories Limited filed Critical Synaptic Laboratories Limited
Publication of WO2008037000A1 publication Critical patent/WO2008037000A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Definitions

  • the present invention relates to making more difficult the cloning in software of hardware devices which perform authentication operations.
  • Hardware devices such as RFID (radio frequency identification) tags, smart cards and even integrated circuits currently can include encryption facilities to encrypt the signals going into, and coming out of, the device.
  • RFID radio frequency identification
  • Such hardware devices are routinely initialized with a unique per-device identifier in the form of a binary number that is supplied to a process. The unique per-device identifier is used to identify and potentially authenticate the device.
  • the first method uses a cryptographic authentication process.
  • the second method encrypts the input and output signals of a device.
  • An example of cryptographic devices that have been cloned are smart-cards used in conjunction with set-top boxes for satellite television. "Genuine" smart cards are inserted in set-top boxes to enable de-scrambling of received television signals. The smart cards have been reverse engineered and their functionality and the unique per-device identifier is then incorporated into software that executes efficiently on general-purpose processors, such as personal computers. A physical connection from the personal computer is plugged into the set-top box which would normally receive the genuine smart card.
  • a preferred embodiment of the present invention provides cryptographic challenge-response process, comprising: an authenticator process; and at least one requester process, each of the authenticator and requester processes invokes a cryptographic algorithm, the cryptographic algorithm being iterated at least the number of times which allows the authenticator process to successfully distinguish between; the execution time of a first requester process that implements the cryptographic algorithm in hardware with communications latencies; and the execution time of a second requester process that implements the cryptographic algorithm as software on a general-purpose software processor.
  • the second requester process has communications latencies, these communications latencies being less than the communications latencies of the first requester process.
  • the communications latency of the first requester process is larger than the anticipated worst-case round-trip communications latency between the authenticator process and one or more requester processes.
  • the process further comprises a process of determining whether the communications latency and execution time of a challenge for a given number of iterations is greater than the anticipated worst-case round-trip communications latency and the time required for the given number of iterations of the cryptographic algorithm in a specific hardware device.
  • the cryptographic algorithm is iterated at least twice the number of times that allows the authenticator process to successfully distinguish between the first requester process and the second requester process.
  • the second requester has communications latencies, these communications latencies being less than the communications latencies of the first requester.
  • the communications latency of the first requester is larger than the anticipated worst-case round-trip communications latency between the authenticator and one or more requesters.
  • the apparatus for implementing a cryptographic challenge-response process further comprises a means for determining whether: the communications latency and execution time of a challenge for a given number of iterations is greater than the anticipated worst-case round-trip communications latency and the time required for the given number of iterations of the cryptographic algorithm in a specific hardware device.
  • the cryptographic algorithm is iterated at least twice the number of times that allows the authenticator process to successfully distinguish between the first requester and the second requester.
  • the present invention provides an authenticator for implementing a cryptographic challenge-response process within a system which comprises: an authenticator; and at least one requester, each of the authenticator and requester being adapted to invoke a cryptographic algorithm, the cryptographic algorithm being iterated at least the number of times which allows the authenticator to successfully distinguish between; the execution time of a first requester that implements the cryptographic algorithm in hardware with communications latencies; and the execution time of a second requester that implements the cryptographic algorithm as software on a general-purpose software processor.
  • the second requester has communications latencies, these communications latencies being less than the communications latencies of the first requester.
  • the communications latency of the first requester is larger than the anticipated worst-case round-trip communications latency between the authenticator and one or more requesters.
  • the authenticator further comprises a means for determining whether the communications latency and execution time of a challenge for a given number of iterations is greater than the anticipated worst-case round-trip communications latency and the time required for the given number of iterations of the cryptographic algorithm in a specific hardware device.
  • the cryptographic algorithm is iterated at least twice the number of times that allows the authenticator process to successfully distinguish between the first requester and the second requester.
  • the present invention provides a requester for implementing a cryptographic challenge-response process within a system which comprises: an authenticator; and at least one requester, each of the authenticator and requester being adapted to invoke a cryptographic algorithm, the cryptographic algorithm being iterated at least the number of times which allows the authenticator to successfully distinguish between; the execution time of a first requester that implements the cryptographic algorithm in hardware with communications latencies; and the execution time of a second requester that implements the cryptographic algorithm as software on a general-purpose software processor.
  • the second requester has communications latencies, these communications latencies being less than the communications latencies of the first requester.
  • the communications latency of the first requester is larger than the anticipated worst-case round-trip communications latency between the authenticator and one or more requesters. It is preferred that the requester further comprises a means for determining whether the communications latency and execution time of a challenge for a given number of iterations is greater than the anticipated worst-case round-trip communications latency and the time required for the given number of iterations of the cryptographic algorithm in a specific hardware device.
  • the cryptographic algorithm is iterated at least twice the number of times that allows the authenticator process to successfully distinguish between the first requester and the second requester.
  • the present invention uses iteration to magnify the differences in execution time between a single invocation of a cryptographic algorithm implemented in hardware and the same cryptographic algorithm implemented as software on a processor.
  • This magnification of differences in execution time provides the ability to distinguish between an authorized hardware device and a general-purpose software emulation of the authorized hardware device and can provide a barrier to prevent cloning and real-time simulation of legitimate IDs or authenticators with widely available devices based on general-purpose software processors.
  • figure 1 is a schematic diagram illustrating hardware according to a preferred embodiment of the present invention
  • figures 2 and 3 are block schematic diagrams illustrating components of the embodiment of figure 1
  • figures 4, 5 and 6 illustrate messages that are passed among components of the embodiment of figure 1
  • figure 7 is a graph illustrating performance of the embodiment of figure 1
  • figure 8 is a flow-chart illustrating processes according to the embodiment of figure 1
  • figure 9 illustrates a sub-process of the flow-chart of figure 8.
  • Figure 1 illustrates a preferred embodiment 100 of the current invention.
  • the embodiment of figure 1 includes a general-purpose computer 101, a portable token reader 102 which can interface with a smart card token 103, a general-purpose computer 104 which can interface with a USB token 106 over the universal serial bus and a public network 107.
  • the general-purpose computer 101 is called an authenticator.
  • the smart card token 103 and the USB token 106 are called requesters.
  • the portable token reader 102 enables the requester 103 to communicate with one or more computers connected to the public network 107.
  • the general-purpose computer 104 enables the requester 106 to communicate with one or more computers connected to the public network 107.
  • Round-trip time is the elapsed time for transit of an electronic message originating from a first device to be transmitted to and received by a second device and the second device transmitting back a corresponding electronic message that is received by the first device.
  • FIG. 2 is a block schematic diagram of the authenticator 101 of figure 1.
  • the authenticator 101 is implemented using a general-purpose computer.
  • Authenticator 101 includes a central processing unit 201, random access memory 202, an input / output system 203 and a dedicated cryptographic processor 204 that implements a hash function.
  • FIG 3 is a block schematic diagram of the requesters 103 and 106 of figure 1.
  • the requester 103 or 106 includes a central processing unit 301, random access memory 302, an input / output system 303, a dedicated cryptographic processor 304 that implements a hash function, a "true" random number generator 306 and non volatile memory 307.
  • Figures 4, 5 and 6 illustrate messages passed among the components of figure 1, and fields in those messages.
  • Figure 4 illustrates the structure of message 400 which passes from the authenticator 101 to either of requesters 103 and 106.
  • the message 400 contains two fields 401, and 402.
  • field 401 is 32-bits in length and field 402 is 256-bits in length.
  • Figure 5 illustrates the structure of message 500 which passes from either of the requesters 103 and 106 to the authenticator 101.
  • the message 500 contains three fields 501, 502 and 503.
  • field 501 is 32-bits in length
  • field 502 is 256-bits in length
  • field 503 is 512-bits in length.
  • Figure 6 illustrates the structure of message 600 which passes from the authenticator 101 to either of requesters 103 and 106.
  • the message 600 contains one field 601.
  • field 401 is 32-bits in length.
  • Figure 7 shows a graph 700 which illustrates performance of the presently-described embodiment of the invention.
  • the vertical axis 701 of the graph 700 represents time in seconds.
  • the horizontal axis 702 of the graph 700 represents iterations of a cryptographic algorithm.
  • a preferred form of cryptographic algorithm is a collision-resistant hash function.
  • the collision-resistant hash function is SHA-I.
  • the line 703 illustrates the performance of a first requester solving a challenge using a collision-resistant hash function implemented in a dedicated cryptographic processor with a worst-case communications round-trip time latency of 1 second between the challenge and response process. Every iteration of the collision-resistant hash function implemented in the dedicated cryptographic processor requires 66 nanoseconds.
  • the line 704 illustrates the performance of second requester solving the same challenge using the collision-resistant hash function implemented on a general-purpose processor with no communications latency between the challenge and response process. Every iteration of the collision-resistant hash function implemented in the general-purpose processor requires 944 nanoseconds.
  • the point 706 illustrates a cross-over point.
  • the region 707 on the graph 700 is bounded on its left-hand side by a vertical line corresponding to twice the number of cross-over iterations, on its bottom by the horizontal axis, and on its upper side by the line 703. We refer to the significance of the region 707 further below in this description.
  • the collision-resistant hash is a proprietary primitive.
  • the use of a proprietary cryptographic primitive ensures that off- the-shelf standards-based hardware cryptographic accelerator boards cannot be used to emulate hardware according to the present invention.
  • the collision-resistant hash is keyed with a shared secret known to the authenticator and to the requester.
  • FIG 8 is a drawing of a flow chart 800 of a preferred embodiment of the present invention.
  • the left-hand side 801 of the flow chart 800 illustrates a cryptographic challenge-response process for authenticator 101 in figure 1.
  • the right-hand 802 of the flow chart 800 illustrates a cryptographic challenge-response process for requester 103 in figure 1.
  • the process 801 and process 802 run concurrently.
  • the arrows 803, 804 and 805 illustrate message flows between processes 801 and 802.
  • the structure of the message sent in message flow 803 is of type 400 of figure 4.
  • the structure of the message sent in message flow 804 is of type 500 of figure 5.
  • the structure of the message sent in message flow 805 is of type 600 of figure 6.
  • the authenticator 101 and requester 103 have established a bidirectional communications session.
  • the requester 103 has provided identification information to the authenticator 101 over this communications session.
  • the message flows 803, 804 and 805 are sent and received over this communications session.
  • the authenticator 101 invokes the cryptographic challenge process 810.
  • the requester 103 invokes the cryptographic response process 831.
  • step 811 a message of type 400 is instantiated.
  • Field 401 of this message is set to a value indicating the number of iterations to be invoked of the collision-resistant hash function before releasing a solution to the challenge. We refer to the significance of the number of iterations of the collision-resistant hash function between releasing a solution further below in this description.
  • Field 402 of this message is set to the value of a freshly generated nonce.
  • step 812 a copy of the message of type 400 in step 811 is transmitted 803 and successfully received in step 832.
  • step 813 the time of the transmission of the message 400 is recorded in random access memory 202.
  • a first message of type 500 is instantiated.
  • Field 501 is set to the value zero.
  • Field 502 and 503 are set to zero.
  • a second message of type 500 is instantiated and none of its fields are initialized.
  • a message of type 600 is instantiated and none of its fields are initialized.
  • a third message of type 500 is instantiated.
  • Field 501 is set to the value zero.
  • Field 502 of this message is set to the value of a freshly generated nonce of at least 128 bits. According to the presently-described embodiment this freshly generated nonce is generated by the requester. According to other preferred embodiments, this freshly generated nonce is generated by a party other than the authenticator or the requester.
  • the values of field 403 and of the field 502 of the third message of type 500 are supplied to a collision-resistant hash, with the message digest stored in field 504 of the third message of type 500.
  • step 836 the iterated hash process 901 of figure 9 is invoked.
  • the iterated hash process 901 receives as input a pointer to the third message of type 500 instantiated in step 833.
  • the values of fields 501 and 503 are modified by the process described in figure 9.
  • the iterated hash process 901 also receives message of type 400 received in step 832.
  • step 837 a copy of the third message of type 500 instantiated in step 833 is transmitted 804 and successfully received in step 816 and stored in the second message of type 500 instantiated in step 813.
  • Step 838 evaluates if a message has been received across message flow 805. In step 839 if no message has been received, the process continues from step 836.
  • step 817 the time of the reception of the message 804 is recorded in random access memory 202.
  • We define the challenge execution time as the difference between the time of the reception of the message 804 and the time of the transmission of the message 400 in step 813.
  • step 818 if the values of fields 501 and 502 of the first message of type 500 instantiated in step 813 are zero: the value of field 501 is set with the value of 501 of the second message of type
  • step 813 the value of 502 is set with the value of 502 of the second message of type 500 instantiated in step 813; and the value of 403 and the value of 501 of the first message are supplied to a collision-resistant hash, with the message digest stored in field 503 of the first message of type 500 instantiated in step 813.
  • step 819 the iterated hash process 901 of figure 9 is invoked.
  • the iterated hash process 901 receives as input a pointer to the second message of type 500 instantiated in step 813.
  • the values of fields 501 and 503 are modified by the process described in figure 9.
  • the iterated hash process 901 also receives message of type 400 instantiated in step 811.
  • decision step 821 the iterated hash process 901 of figure 9 is invoked.
  • the iterated hash process 901 receives as input a pointer to the second message of type 500 instantiated in step 813.
  • the values of fields 501 and 503 are modified by the process described in figure 9.
  • the iterated hash process 901 also receives message of type 400 instantiated in step 811.
  • step 813 the value of the field 501 of the first message of type 500 is instantiated in step 813. It will also be recalled that the value of the field 501 of the second message of type 500 is also instantiated in step 813. If the values of the field 501 are not the same in the two instantiations then the value of value of field 601 of message of type 600 instantiated in step 813 is set to indicate a failure and the process continues executing from step 822. This test verifies that the claimed number of iterations used to solve the solution by processes 810 and 831 match.
  • step 813 the value of the field 503 of the first message of type 500 is instantiated in step 813. It will also be recalled that the value of the field 503 of the second message of type 500 is also instantiated in step 813. If the values of the field 503 are not the same in the two instantiations then the value of value of field 601 of message of type 600 instantiated in step 813 is set to indicate a failure and the process continues executing from step 822. This test ensures that the solutions independently calculated by processes 810 and 831 match.
  • step 501 of the first message of type 500 the value of field 601 of message of type 600 instantiated in step 813 is set to indicate a failure and the process continues executing from step 822. This test ensures that the solution falls within the tolerated execution latencies.
  • the value of field 501 of the first message of type 500 instantiated in step 813 is compared with the value of the number of cross-over iterations. If the number of iterations executed is less than the number of cross-over iterations it is not possible to reliably distinguish between: a first solution executed on a first requester being located within the typical worst-case communications latency and having the collision-resistant hash function is implemented in a dedicated cryptographic processor; and a second solution executed on a second requester with zero communications latency, having the collision-resistant hash function implemented on a general-purpose processor.
  • step 816 If more iterations are desired by the challenge process, the process continues executing from step 816.
  • the value of field 601 of message of type 600 instantiated in step 813 is set to indicate a success and the process continues executing from step 822.
  • step 822 a copy of the message of type 600 instantiated in step 813 is transmitted 805 and successfully received in step 841.
  • the message of type 600 is now shared across processes 801 and 802.
  • Step 823 completes the challenge process, returning the result of the challenge to the caller.
  • Step 842 completes the response process, returning the result of the challenge to the caller.
  • Figure 9 is a drawing of a flow chart 900 illustrating an iterated hash process invoked from figure 8.
  • step 902 the process 901 receives as input a pointer to a message of type 500.
  • the values of fields 501 and 503 will be modified by this process and the results visible to the calling process.
  • the process 901 also receives message of type 400. Reference to fields 501, 503 and 400 in this process refer to the fields supplied to the process.
  • step 903 a 32-bit counter is instantiated. It will be recalled field 401 is set to a value indicating the number of iterations to be invoked of the collision-resistant hash function before releasing a solution to the challenge. The value of the counter is set to the value of field 401.
  • step 904 a single invocation to the collision resistant hash function is made, passing as input field 504 and releasing as output a value that replaces the value of field 504.
  • step 905 the value of the counter is decremented by 1. It will be recalled field 501 indicates the number of iterations applied to the challenge. The value of field 501 is incremented by 1.
  • step 906 if the value of the counter is larger than zero the process continues at step 904.
  • step 907 the process 901 ends.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

Cette invention concerne un processus question-réponse cryptographique (800) qui met en oeuvre un processus authentificateur (810) et au moins un processus demandeur (831). Le processus authentificateur (810) et le processus demandeur (831) utilisent chacun un algorithme cryptographique (904). L'algorithme cryptographique (904) est itéré un certain nombre de fois, ce qui permet au processus authentificateur (810) de distinguer avec succès un premier demandeur d'un deuxième demandeur. Le premier demandeur (103) met en oeuvre l'algorithme cryptographique (904) dans le matériel et comporte des latences de communication. Le deuxième demandeur met en oeuvre l'algorithme cryptographique sous la forme d'un logiciel sur un processeur logiciel.
PCT/AU2007/001410 2006-09-25 2007-09-24 Inhibition du clonage de dispositifs matériels par des processeurs logiciels polyvalents WO2008037000A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2006905274 2006-09-25
AU2006905274A AU2006905274A0 (en) 2006-09-25 Inhibiting Cloning of Hardware Devices by General Purpose Software Processors

Publications (1)

Publication Number Publication Date
WO2008037000A1 true WO2008037000A1 (fr) 2008-04-03

Family

ID=39229618

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2007/001410 WO2008037000A1 (fr) 2006-09-25 2007-09-24 Inhibition du clonage de dispositifs matériels par des processeurs logiciels polyvalents

Country Status (1)

Country Link
WO (1) WO2008037000A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009017844B4 (de) * 2008-04-17 2017-12-21 Atmel Corporation Einrichtung, Systeme und Verfahren zur Authentisierung von Verschlüsselungen
JP2018107805A (ja) * 2017-12-25 2018-07-05 ヒューレット−パッカード デベロップメント カンパニー エル．ピー．Ｈｅｗｌｅｔｔ‐Ｐａｃｋａｒｄ Ｄｅｖｅｌｏｐｍｅｎｔ Ｃｏｍｐａｎｙ， Ｌ．Ｐ． チャレンジ・レスポンスを時間計測することによる供給装置認証
US10987936B2 (en) 2013-08-30 2021-04-27 Hewlett-Packard Development Company, L.P. Supply authentication via timing challenge response

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KENNEL ET AL.: "Establishing The Genuinity Of Remote Computer Systems", PROCEEDINGS OF THE 12TH USENIX SECURITY SYMPOSIUM, WASHINGTON, D.C. USA, 4 August 2003 (2003-08-04) - 8 August 2003 (2003-08-08), pages 295 - 310 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009017844B4 (de) * 2008-04-17 2017-12-21 Atmel Corporation Einrichtung, Systeme und Verfahren zur Authentisierung von Verschlüsselungen
US10987936B2 (en) 2013-08-30 2021-04-27 Hewlett-Packard Development Company, L.P. Supply authentication via timing challenge response
US11014370B2 (en) 2013-08-30 2021-05-25 Hewlett-Packard Development Company, L.P. Supply authentication via timing challenge response
US11020976B2 (en) 2013-08-30 2021-06-01 Hewlett-Packard Development Company, L.P. Supply authentication via timing challenge response
US11027554B2 (en) 2013-08-30 2021-06-08 Hewlett-Packard Development Company, L.P. Supply authentication via timing challenge response
US11123994B2 (en) 2013-08-30 2021-09-21 Hewlett-Packard Development Company, L.P. Supply authentication via timing challenge response
US11691429B2 (en) 2013-08-30 2023-07-04 Hewlett-Packard Development Company L.P. Supply authentication via timing challenge response
JP2018107805A (ja) * 2017-12-25 2018-07-05 ヒューレット−パッカード デベロップメント カンパニー エル．ピー．Ｈｅｗｌｅｔｔ‐Ｐａｃｋａｒｄ Ｄｅｖｅｌｏｐｍｅｎｔ Ｃｏｍｐａｎｙ， Ｌ．Ｐ． チャレンジ・レスポンスを時間計測することによる供給装置認証

Similar Documents

Publication Publication Date Title
US6389533B1 (en) Anonymity server
He et al. A strong user authentication scheme with smart cards for wireless communications
JP6880071B2 (ja) コピー攻撃を防ぐための処理方法並びにサーバ及びクライアント
Yoon et al. Improving the dynamic ID-based remote mutual authentication scheme
WO2000002132A1 (fr) Procede et dispositif de verification d'integrite, d'authentification, et de liaison securisee de modules logiciels
EP1362274A2 (fr) Procede et appareil assurant une commande d'acces a des fonctions selon differents niveaux de securite
EP1346511A1 (fr) Plate-forme et procede de transmission securisee de donnees d'autorisation
CN100596188C (zh) 机顶盒终端及其验证方法
CN113132087A (zh) 物联网、身份认证及保密通信方法、芯片、设备及介质
US20120008784A1 (en) Delegated Key Exchange System and Method of Operation
JP6188633B2 (ja) コンピュータシステム、コンピュータ、半導体装置、情報処理方法およびコンピュータプログラム
US20210067961A1 (en) Secure simultaneous authentication of equals anti-clogging mechanism
Olakanmi et al. Compromise-resilient anonymous mutual authentication scheme for n by m-times ubiquitous mobile cloud computing services
Tsuji et al. One-time password authentication protocol against theft attacks
WO2008037000A1 (fr) Inhibition du clonage de dispositifs matériels par des processeurs logiciels polyvalents
CN113630244A (zh) 面对通信传感网的端到端安全保障方法及边缘服务器
EP4333360A1 (fr) Sécurisation de communications de réseau à l'aide de clés secrètes générées dynamiquement et localement
Peeters et al. IBIHOP: Proper privacy preserving mutual RFID authentication
CN114173327B (zh) 基于5g行业专网的认证方法及终端
GB2505231A (en) Verification by identifying an algorithm via a second channel
Lee et al. Efficient and secure remote authenticated key agreement scheme for multi-server using mobile equipment
KR20040014400A (ko) 인터넷 프로토콜 전화 보안 체계
CN115277240A (zh) 一种物联网设备的认证方法及装置
CN111651740B (zh) 一种面向分布式智能嵌入式系统的可信平台共享系统
Srivastava et al. A review on remote user authentication schemes using smart cards

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07815228

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07815228

Country of ref document: EP

Kind code of ref document: A1