WO2021148075A1

WO2021148075A1 - Method for authenticating a device component

Info

Publication number: WO2021148075A1
Application number: PCT/DE2021/000006
Authority: WO
Inventors: Frank Schumacher
Original assignee: Frank Schumacher
Priority date: 2020-01-21
Filing date: 2021-01-20
Publication date: 2021-07-29
Also published as: DE102020000336B4; DE102020000336A1

Abstract

The invention relates to a method for authenticating a device component by means of a principal device using a challenge-response-test from a stored list. The object of the method is to allow stored challenge-response pairs, CRP, to be used multiple times, to slow down the consumption of said pairs without compromising security. The principal device stores, in respect of each CRP, the information as to whether it is "error-free", that is to say whether, in every previous test of a component with the same CRP, the response arrived within a specified time limit after the challenge was sent and whether said response matched the stored reference value, and the information as to whether the most recently performed authentication of a component was successful. If yes, authentication is performed using a single challenge-response test, with an error-free CRP being used. If not, authentication is performed using two challenge-response tests, with a CRP test giving an error being used in the first test and an error-free CRP being used in the second test.

Description

description

Designation: Procedure for authenticating a device component

Task

In many different methods according to the prior art, a main device checks whether a component for a test question (challenge) finds a valid solution (response) for its authentication. The following steps describe a general sequence of such a method: a) Storage of a list of at least one data pair, consisting of a test task and a reference solution, by the main device before it is put into operation, b) Selection of a first stored data pair, consisting of a first test task and a first reference solution by the main device and sending the first test task to the component, c) generating a first solution by the component and sending the first solution to the main device, d) receiving a first solution by the main device or aborting the authentication if a Time limits, e) comparison of the first solution with the first reference solution in the main device, f) first decision by the main device to enable the main function, cancel the authentication or to carry out additional steps, g) selection of a second stored data pair consisting of a second test task and a second reference solution by the main device and sending the second test task to the component, h) generating a second solution by the component and sending the second solution to the main device, i) receiving a second solution by the main device or aborting the authentication if exceeded a time limit, j) comparison of the second solution with the second reference solution in the main device, k) second decision to enable the main function by the main device

The aim of authentication is, for example, the detection of counterfeit components. Main devices can be divided into two classes:

The first class includes main devices that are able to check a received solution (response) for a randomly generated test question (challenge).

The second class includes main devices that instead have to access stored data pairs consisting of the test task and reference solution. In the case of a cryptographic method, both options exist for the implementation of the main device: the main device can either be provided with a suitable cryptographic key or with a list of data pairs (challenge-response list). In the case of symmetrical methods, the first approach is more flexible, but the second is more secure because a main device cannot be misused to compromise a secret key.

In the case of methods that are based on inherent group characteristics of circuits and the limited availability of these circuits (such a method is described, for example, in the as yet unpublished document 10 2018 009 143.1), both are also possible: a main device of the first class must have a integrated, authentic circuit instance to generate reference solutions. However, such an implementation is more expensive than an implementation using stored data pairs.

In procedures that are based on inherent features of individual hardware instances, e.g. non-cryptographic PUF solutions [Pa], the main devices always fall into the second class. In summary, second-class master devices for authenticating a component are either secure, cost-effective, or even the only option.

A disadvantage of main devices of the second class, especially when used offline, is that data pairs are only available to a limited extent. In order to limit the consumption of data pairs, the question arises as to whether the main device can use a stored data pair multiple times to authenticate connected components, and if so, how often.

The aim of the disclosed method is, under the following assumptions, to maximize the reuse of stored data pairs without restricting the security compared to data pairs used once.

The disclosed method is suitable for authentication when the main device and component are used in a “friendly environment”, ie when the authentication takes place under the supervision of the user and the user is not a hacker himself. Under this assumption, attackers or malicious devices do not have physical access to the data interface between the main device and the component. A so-called “replay” attack, in which in a first step the communication is read when an authentic component is checked by the main device at this data interface and later, in the second step, the recorded solution in the check of a malicious component is the answer is played back on the same examination task, is therefore not considered. One use case to which the assumption applies is the detection of counterfeit accessory components, provided that the detection is also in the interests of the buyer. In order to make an authentication method with a restricted list of stored challenge-response pairs secure, the main device must store information on the test history and take it into account when selecting a challenge-response pair for an upcoming challenge-response test. For the test history, the main device can, for example, keep track of information as to whether the last authentication of a component was successful or unsuccessful. As a second example of the test history, the main device can store an attribute for each challenge-response pair, which indicates whether the challenge-response pair is "error-free" or "error-prone". “Faultless” means that in every test of a component with the same challenge-response pair that was started before the challenge was sent, the response arrived within a specified time limit and matched the stored reference value.

State of the art

Document Dl describes features of a method for authenticating a component (“Authentication Device”) by a main device (“Interrogator Device”), which overlaps with the present invention in the following aspects: the administration of challenge-response pairs by the main unit , the use of one or more challenge-response tests to authenticate a component, the multiple use of challenge-response pairs and the selection of the challenge-response pair for a challenge-response test depending on one by the main device held test history. Dl is intended to ensure that an attacker who can eavesdrop on the data interface during communication between authentic devices needs as long as possible to learn all the stored challenge-response pairs. For this purpose, the main device restricts the selection probabilities of certain challenge-response pairs. Dl advises the main device, especially if it suspects an attack (e.g. due to frequent authentication requests within a time window), to use as few fresh challenge-response pairs as possible and instead reuse faulty challenge-response pairs.

In contrast to the present publication, Dl does not provide a sufficient criterion according to which a component is to be activated after one or more challenge-response tests. In particular, Dl does not indicate a situation in which an error-free challenge-response pair is to be used.

As an innovation, the present invention provides a precise instruction as to when an error-free challenge-response pair is used in a challenge-response test (if one or more stored challenge-response pairs are faulty): exactly when the last one carried out Authentication of a component not successful, and only after a first challenge-response test with an incorrect challenge-response sponse pair was successful. This feature is not obvious from Dl. It provides a significant security advantage.

Document D2 describes a challenge-response protocol between a hardware token and an untrustworthy device, in which the hardware token - in cross-section with features of the present invention - expects a response within a fixed response time by a certain amount Authenticate actions of the untrusted device.

The mentioned innovation of the present invention does not emerge in an obvious manner from the combination of the documents D1 and D2.

Obvious procedures

Obvious methods for reducing the consumption of data pairs would be, for example:

- Processes in which the main device always uses the same data pair,

- Processes in which the main device uses a data pair for a limited time,

- Processes in which the data pair is changed directly after a wrong solution.

In order to clarify the weaknesses of the state of the art and obvious processes, it is sufficient to consider non-authentic components in two extreme forms:

In the case of strong malicious components, it can be assumed that they will find the solution to an unused examination task in exactly the second attempt. Hardware-inherent authentication features according to the SIMPL paradigm [SIMPL] basically assume that malicious components are so strong because they can simulate authentic components at a slower pace. However, the assumption is also useful for cryptographic procedures, since it implicitly models many attacks: “Relay” attacks (not to be confused with “replay” attacks), in which the malicious component plays a main device to an authentic component in order to get a valid solution to a received test task or attacks by means of a connection to a backend server.

In the case of weak malicious components, assume that they will never find the solution.

The first two obvious methods are not secure against strong malicious components. The third obvious method does not solve the problem: A weak malicious component could be used in a so-called "Denial-of-Service" attack with the aim of overriding a main device by provoking rapid consumption of its stored data pairs.

idea

The solution is based on the equivalence of previously unused data pairs and "error-free" data pairs, i.e. those that have never led to a wrong solution. From the two assumptions mentioned, it can be deduced that a strong malicious component is not able to find a valid answer to the checking task of an error-free data pair within the permissible time frame. As long as a data pair is error-free, it is used for component authentication by means of a single check.

After a negative test result, the data pair should no longer be used solely for component authentication. If the recipient was a strong malicious component, it must be assumed that they can determine the solution by the next check.

However, the data pair still serves the purpose of detecting weak malicious components without wasting unused data pairs. The faulty data pair can be used until a correct solution to its examination task arrives within a set time limit. Then it is assumed that malicious components know the solution.

A second check with an error-free data pair must follow in order to distinguish between an authentic and a strong malicious component.

Technical design

The storage of data pairs before commissioning in step a) typically takes place in a protected environment of the manufacturer. A reference device has a random number generator to generate random test tasks and uses connected components as a generator for reference solutions. The data pairs formed, consisting of the test task and reference solution, are stored on a server.

The server is used to bring data pairs into the main devices in the manufacturer's environment. Each data pair is only brought into one main device and then deleted on the server side.

In online applications, the server is also used to update data pairs for main devices in the field using a suitable update protocol. The online update requires encrypted data transmission between the server and the main device. In the simplest embodiment, the main device stores data pairs as a sequence D [1], D [2], where M is the maximum number of data pairs that can be stored. A data pair D consists of an examination task P and a reference solution R.

The data pairs are used one after the other to test components.

A pointer variable Z points to the current data pair D [Z]. In the simplest embodiment, the selection of a data pair in steps b) and g) is specified by the current value of Z.

A binary variable L with the value 0 or 1 indicates that the last authentication of a component was positive or negative. It corresponds to the first information from claim 1 (I). The second information from claim 1 (m) is contained in Z and L in this embodiment: The pairs D [l]. D [Z-1] are faulty. The pair D [Z] is healthy when L is zero. The pairs D [Z + 1]. D [M] are unused and free of errors.

The authentication of a connected component can be implemented in the simplest version as shown in drawing 1: After receiving a "wake up" signal (101), the main device directly carries out a test (102) using the current data pair D [Z], ie it sends the test task P [Z] and carries out steps d) - e). If the connected component has passed the test (103), i.e. in step e) a match between the received solution and R [Z] was determined, the value of the information L is evaluated (104). In the positive case L = 0, the main function is activated directly (105). In the case of L = 1, it is first checked whether Z = M has already been reached (106). In this case, no more error-free data pairs are available and the authentication is aborted. The termination includes setting the variable L to the value 1 (107). If Z <M applies at (106), the current data pair is changed by increasing Z = Z + i and the variable L is reset (108). Then the connected component is checked again with the unused data pair D [Z] (109), i.e. the checking task P [Z] is sent and steps h) -j) are carried out.

Depending on the comparison (110) in step j), either the main function (105) is started or there is a termination (107). Finally, the main unit goes back to sleep mode (111).

If the pointer variable Z reaches the memory limit of the data pairs, ie if an abort occurs at (106) in drawing 1 and the device is then not to be put out of operation, there are several options. In a variant according to claim 2, the main device then resets L and Z. The process loses its absolute security. For some applications, however, it has already served its purpose at this point. In a favorable version, L is implemented as an error counter instead of a binary variable. Before the test (102), the main device inserts a waiting time. The waiting time increases with increasing error Counter L increases. In this way, the consumption of data pairs can be reduced in terms of time, and resetting only takes place after a sufficiently long time, so that the use of counterfeit components is simply not convenient.

In a special case, the implementation shown in drawing 2 is more favorable for the main device: if the component is a battery, a countermeasure against what is known as a “tear-down” attack is required. In this attack, after a failed test in drawing 1 (103), a malicious battery would attempt to cut off the power supply to the main device before the information L is set to the value one at (107). A strong malicious battery would then be able to go through as authentic in the next run. For this application, the information L is divided into a volatile variable VL and a non-volatile (e.g. in an EEPROM memory) to be stored variable PL. The pointer Z must also be stored in a non-volatile manner. In the case of non-volatile data, the information is retained if the power supply is interrupted. As shown in drawing 2 (201), the non-volatile variable PL is set to 1 at the beginning of the method and is only reset again directly before the start of the main function (203). Instead of the value of L, the value of VL is checked after the first check in (202). This shows the result of the previous authentication of a component. This effectively prevents the aforementioned tar-down attack.

Authentication application in the component

Each component is provided with an authentication application in the manufacturer's environment. This includes the solution function for generating a solution to an examination task.

In the case of cryptographic authentication according to claim 3, the symmetrical standard algorithm HMAC-SHA256 can be used, for example. The solution to an examination task then has the form HMAC (key, examination task), the key being a group-specific secret of authentic components. In a favorable version, the component contains a secure hardware element for storing the secret key and for generating the solution. The component's authentication application then only has to receive the test task, write it to a register in the secure hardware element and then send the solution to the main component. The key is brought in in a strictly secured environment.

In an implementation according to claim 4, the authentication application of the component contains a test program which writes in MCU-internal peripheral registers, excludes values from MCU-internal peripheral registers and uses the read-out values Forms hash sum. On the one hand, the authentication application sets an initial hash buffer depending on the test task and, on the other hand, exchanges program instructions of the test program and executes the modified test program. The hash value generated by the modified test program is sent to the answer as a solution to the test task. Such an authentication application is described in detail in the as yet unpublished document [FS2].

Referenced patents Dl WO 2012/129 641 Al

D2 US 2013/0 111 211 Al

10 2018009 143.1 Procedure for authenticating a device by a host system, as yet unpublished

Other references

[MSU] Michigan State University, "Defining the threat of product counterfeiting,"

2019. https://www.michiganstateuniversityonline.com/resources/ acapp / threat-of-product-counterfeiting /.

[Pa] R. S. Pappu, "Physical one-way functions," PhD thesis, MIT, 2001.

[SIMPL] U. Rührmair, "SIMPL Systems as a keyless cryptographic and security primitive," D. Naccache (Editor), Cryptography and Security: From Theory to Applications - Essays Dedicated to Jean-Jacques Quisquater on the Occasi on of His 65th Birthday . Lecture Notes in Computer Science, Vol. 6805, Springer, 2012.

[FS1] F. Schuhmacher, "MCU intrinsic group features for component authentication",

2020, still unpublished.

[FS2] F. Schuhmacher, “Relaxed freshness in component authentication”,

2020, still unpublished.

Claims

1. A method for authenticating an electronic component by a main device and the dependent activation of a main function, which includes the process steps a) storage of a list of at least one data pair, consisting of a test task and a reference solution, by the main device before it is put into operation, b) selection of one first stored data pair, consisting of a first test task and a first reference solution by the main device and sending the first test task to the component, c) generating a first solution by the component and sending the first solution to the main device, d) receiving a first solution by the main device or cancellation of the authentication when a time limit is exceeded, e) comparison of the first solution with the first reference solution in the main device, f) first decision of the main device to enable the main function, cancel the authentication or to carry out additional steps itte, g) selection of a second stored data pair, consisting of a second test task and a second reference solution by the main device and sending the second test task to the component, h) generation of a second solution by the component and sending the second solution to the main device, i ) Receipt of a second solution by the main device or cancellation of the authentication when a time limit is exceeded, j) comparison of the second solution with the second reference solution in the main device, k) second decision to enable the main function by the main device and is characterized in that

L) the main device stores in a first piece of information whether the authentication of a component started by it last in step b) turned out to be positive, ie whether it led to the activation of the main function in one of steps f) or k), m) the main device in a second piece of information for each data pair, it keeps track of whether the data pair is “error-prone”, ie whether ever, if the data pair was selected in step b) or step g), in the subsequent step d) or e) or step i ) or j) the fault has occurred, n) the main device in the event that the first information indicates that the last authentication was negative, selects an incorrect first data pair in step b), does not enable the main function in step f) and selects an error-free second data pair in step g) .

2. The method as claimed in claim 1, in which the main device, if it no longer has any data pair with a positive attribute, resets the attribute of a data pair to a positive value.

3. The method according to claim 1, in which an authentic component has a secret cryptographic key and uses a cryptographic signature function to generate the solution in steps c) and h).

4. The method according to claim 1, in which the authentic components have a characteristic, hardware-inherent property, and the generation of the solution in steps c) and h) depends on this property.

5. The method of claim 1, wherein the main device is a mobile phone and the component is a battery.