Method for the authentication of a slave device by a host device

Abstract

The invention relates to a method for the authentication of a slave device (20) by a host device (10), comprising a step (KGEN) of generating a secret key (Ks) shared by the host device and the slave device, and a plurality of steps of authentication (AUTH) of the slave device by the host device by means of the secret key (Ks). In one embodiment, when the number (n) of authentication steps in which the secret key (Ks) is used is equal to a set value (N), the step (KGEN) of generating the secret key (Ks) is executed again to obtain a new secret key used during a subsequent plurality of steps of authentication (AUTH) of the slave device.

Description

[0001] Description

[0002] Title of the invention: METHOD FOR AUTHENTICATING A SLAVE DEVICE BY A HOST DEVICE

[0003] Technical field

[0004] The present invention relates to a method for authenticating a slave device by a host device, the host device and the slave device each comprising cryptographic calculation means.

[0005] The present invention also relates to the authentication of devices accessory to electrical or electronic devices, such as printer cartridges or batteries.

[0006] State of the art

[0007] Counterfeiting of accessory devices integrated into electrical or electronic devices is a growing threat in the consumables and accessories market. Not only are the revenues of original manufacturers at stake, but the end customer is also affected by reliability and even health issues that can result from the use of counterfeit accessories. The markets concerned are numerous, including ink cartridges and electric batteries for all types of electrical devices or tools. One solution to prevent the counterfeiting of an accessory is to digitally identify and authenticate it. To this end, the accessory is equipped with a chip called a "secure element" capable of performing cryptographic calculations.Such a secure element is capable of responding to cryptographic queries from the device, allowing the device to verify that the accessory is authentic.

[0008] In the remainder of the description, the term "host device" will refer to the device receiving the accessory, and the term "slave device" will refer to the accessory inserted into or associated with the device concerned.

[0009] Typically, the authenticity of the slave device is verified by the host device using the so-called "challenge / response" method (also called

[0010] "challenge / response") involving a cryptographic algorithm. For example, the host device generates a random number or "challenge" and sends it to the slave device. The slave device calculates a cryptogram based on this random number, then sends it back to the host device, which verifies its validity. This authentication method can be implemented using symmetric cryptography algorithms or asymmetric cryptography algorithms. With an asymmetric cryptography algorithm, the slave device calculates the cryptogram using a private key, and the host device verifies the validity of the cryptogram using the slave's public key. With a symmetric cryptography algorithm, the slave device calculates the cryptogram using a secret key, and the host device verifies the validity of the cryptogram using the same secret key.The cryptographic authentication techniques currently offering the highest degree of security are those based on asymmetric cryptography algorithms. However, these algorithms have the disadvantage of being relatively slow to execute, due to the computation time they require. However, it is desirable that the authenticity of the accessory can be verified by the device as many times as necessary, and generally at any time determined by the designer of the device according to its specificities. Under these conditions, the time required to execute authentication by asymmetric cryptographic calculation may prove incompatible with user-friendly and real-time use of the accessory. For example, if the authentication of four ink cartridges of a printer is implemented each time a page is printed, the resulting printer inactivity time may prove prohibitive.Authentication techniques based on symmetric cryptography algorithms, on the other hand, are much faster to execute. To clarify, with an arithmetic coprocessor that optimizes cryptographic computation time, symmetric authentication takes milliseconds or tens of milliseconds, while asymmetric authentication takes hundreds of milliseconds, a ratio of 10 to 10.

[0011] However, symmetric cryptography authentication techniques have security drawbacks. They require the same secret key to be used in both the host and slave devices, for example, if any ink cartridge is to be usable in any compatible printer. Because this secret key is factory-loaded into a memory area of ​​each device, such permanent storage is vulnerable to breach by memory flushing. Thus, if a fraudster gets hold of the secret key of one of the two devices, all other devices will be affected. Asymmetric cryptography techniques do not suffer from this problem, because each slave device has a different private key, which it can use to sign a challenge sent by the host device.The host device can then, using the public key of the slave device, decrypt the received signature and ensure that it is consistent with the challenge initially sent, and thus ensure that the slave device has the expected private key. Asymmetric authentication techniques are therefore generally preferred to symmetric authentication techniques for accessory authentication. To minimize the impact of the duration of the authentication phases on the operation of the device, however, it is necessary to reduce the number of authentication steps or to trigger these steps at times when they do not impact its operation, but this reduces the effectiveness of the protection.

[0012] It might therefore be desirable to provide a method of authenticating an accessory that has little impact on the operation of a device while still offering a high level of security.

[0013] It might also be desirable to provide a method of authenticating an accessory offering a variable and configurable level of security, making it possible to achieve a compromise between its execution time and the degree of security it offers.

[0014] Statement of the invention

[0015] Embodiments of the present invention relate to a method for authenticating a slave device by a host device, the host device and the slave device being connected by a data bus and each comprising cryptographic calculation means, the method comprising a step of generating a secret key shared by the host device and the slave device, comprising between the host device and the slave device an exchange of data from which the host device and the slave device develop the secret key without the latter passing over the data bus, and a plurality of steps of authentication of the slave device by the host device, of the challenge / response type, by means of a symmetric cryptography algorithm and the secret key.According to one embodiment, the host device is configured to count the number of authentication steps in which the secret key is used, and, when this number is equal to a set value, the host device and the slave device execute again the step of generating the secret key to obtain a new secret key usable during a next plurality of authentication steps of the slave device.

[0016] According to one embodiment, the slave device is configured to count the number of authentication steps in which the secret key is used, and, when this number is equal to a set value, the host device and the slave device execute again the step of generating the secret key to obtain a new secret key usable during a next plurality of authentication steps of the slave device.

[0017] According to one embodiment, the setpoint value is configurable and is loaded into a memory or into a register of the host device or the slave device.

[0018] According to one embodiment, the step of generating a secret key comprises a Diffie Hellman key exchange.

[0019] According to one embodiment, the step of generating a secret key comprises steps of generating a secret shared by the host device and the slave device, and steps of generating the secret key from the shared secret and at least one random number.

[0020] According to one embodiment, the method comprises a first step of generating an initial secret key shared by the host device and the slave device, comprising steps of generating a secret shared by the host device and the slave device, and steps of generating the initial secret key from the shared secret and at least one random number, and at least a second step of generating a new secret key shared by the host device and the slave device, from the shared secret generated during the first step of generating a secret key and at least one random number.

[0021] According to one embodiment, the method comprises a first step of generating a secret key shared by the host device and the slave device, comprising between the host device and the slave device an exchange of data from which the host device and the slave device develop the secret key without it passing over the data bus, and at least a second step of generating a secret key shared by the host device and the slave device, from at least one previous value of the secret key and at least one random number.According to one embodiment, each step of authenticating the slave device comprises: sending to the slave device by the host device a random number, calculating a first result by the host device, comprising the transformation of the random number by a cryptography function using the secret key, calculating a second result by the slave device, comprising the transformation of the random number by the same cryptography function using the secret key, sending the second result to the host device by the slave device, and verifying by the host device that the second result is equal to the first result.

[0022] According to one embodiment, the host device is an electronic circuit integrated into an electrical or electronic device operating with an accessory device, and the slave device is an electronic circuit integrated into the accessory.

[0023] According to one embodiment, the accessory device is an ink cartridge or an electric battery.

[0024] Embodiments of the invention also relate to an authentication device comprising a slave device and a host device, the host device and the slave device being connected by a data bus and each comprising cryptographic calculation means, the host device and the slave device being configured to generate a shared secret key, by exchanging data from which the host device and the slave device develop the secret key without it passing over the data bus, and to carry out a plurality of authentication steps of the slave device by the host device, of the challenge / response type, by means of a symmetric cryptography algorithm and the secret key.

[0025] According to one embodiment, the host device is configured to count the number of authentication steps in which the secret key is used, and, when this number is equal to a set value, initiate the renewal of the secret key generation step to obtain a new secret key usable during a next plurality of authentication steps of the slave device. According to one embodiment, the slave device is configured to count the number of authentication steps in which the secret key is used, and, when this number is equal to a set value, initiate the renewal of the secret key generation step to obtain a new secret key usable during a next plurality of authentication steps of the slave device.

[0026] In one embodiment, the setpoint value is loaded into a memory or register of the host device or the slave device. In one embodiment, the host device and the slave device are configured to generate the secret key by a Diffie Hellman key exchange.According to one embodiment, the host device and the slave device are configured to conduct a first step of generating an initial secret key shared by the host device and the slave device, comprising steps of generating a secret shared by the host device and the slave device, and steps of generating the initial secret key from the shared secret and at least one random number, and conduct at least a second step of generating a new secret key shared by the host device and the slave device, from the shared secret generated during the first step of generating a secret key and at least one random number.

[0027] According to one embodiment, the host device is an electronic circuit integrated into an electrical or electronic device operating with an accessory device, and the slave device is an electronic circuit integrated into the accessory.

[0028] Brief description of the figures

[0029] Examples of embodiments of the method of the invention are described below without limitation, in relation to the attached figures among which:

[0030] - [Fig.1] Figure 1 schematically represents an apparatus and an accessory comprising a host device and a slave device implementing the method of the invention,

[0031] - [Fig.2] Figure 2 shows an embodiment of the method of the invention,

[0032] - [Fig.3] Figure 3 shows another embodiment of the method of the invention, - [Fig.4] Figure 4 shows an embodiment of a step of the method of the invention,

[0033] - [Fig.5] Figure 5 shows an embodiment of another step of the method of the invention,

[0034] - [Fig.6] Figure 6 shows another embodiment of the step of Figure 5,

[0035] - [Fig.7] Figure 7 shows a variant of the embodiment of Figure 6,

[0036] - [Fig.8] Figure 8 shows another variant of the embodiment of Figure 6,

[0037] - [Fig.9] Figure 9 shows an example embodiment of a host device, and

[0038] - [Fig .10] Figure 10 shows an example of the realization of a slave device Detailed description

[0039] Figure 1 schematically represents a device 100 configured to receive an accessory 200. The device 100 is equipped with a device 10, or master device, allowing the authentication of the accessory 200. The accessory is equipped with a device 20, or slave device, allowing it to authenticate itself with the device 10. The device 100 is for example a printer or a power tool. The accessory is for example a printer cartridge or a battery. The devices 10, 20 are connected by a data bus 30 allowing them to exchange DT data. The bus 30 is for example an I2C bus or a bus using a proprietary protocol, for example the 1-Wire protocol (“one wire”). In one embodiment, the bus 30 is not secure and the DT data circulates there in clear text, that is to say in an unencrypted form.

[0040] The devices 10, 20 may each take the form of an electronic card or a part of an electronic card. They are configured to implement an authentication method according to the invention, which combines asymmetric cryptography steps and symmetric cryptography steps.

[0041] Figure 2 schematically illustrates an embodiment of the authentication method. The method comprises a KGEN step of joint generation by the device 10 and the device 20 of a shared secret key Ks, and an AUTH step of authentication of the device 20 by the device 10 by means of the shared secret key Ks. During the KGEN step, the devices 10, 20 exchange data DT via the data bus 30, and conduct mathematical calculations until each obtains the value of the secret key Ks. Each device 10, 20 then stores this key in a register or a memory area.

[0042] During the authentication step AUTH, the device 10 sends a challenge to the device 20 via the bus 30. The device 20 returns the challenge in an encrypted form (cryptogram) obtained by means of the secret key Ks and a cryptography function F1 common to the two devices 10, 20. The device 10 then verifies that the cryptogram is correct.

[0043] According to the method of the invention, the authentication step AUTH can be executed multiple times with the same secret key Ks until this number of times reaches a set value N configured in the device 10. When the authentication step AUTH has been repeated N times, the step KGEN is executed again for the generation of a new shared secret key Ks. The new key is then used for a new series of executions of the authentication step AUTH.

[0044] In one embodiment, the counting of the number of executions of the authentication step AUTH is ensured by means of a variable n managed by the device 10. The setpoint value N is loaded into the device 10 during a configuration step S10 which can be executed in the factory or in the field, either after commissioning of the device 100. Before execution of the step KGEN, or after its execution, the variable n, for example a counter value, is set to 0 at a step S11. Before each execution of the authentication step AUTH, the variable n is incremented by one unit (n = n+1) by the device 10 at a step S12. After each execution of the authentication step AUTH and if this is successful, the device 10 checks, in a step S13, whether the variable n is equal to the set value N. If the set value N has not yet been reached (“N”), the device 10 carries out the next authentication step AUTH with the current key Ks.If the setpoint value N has been reached (“Y >>), the device 10 resets the variable n to 0 in the aforementioned step S11 and then reinitiates the step KGEN for the generation of a new secret key Ks. Finally, if the authentication step AUTH is not conclusive, the device 10 rejects the device 20 in a step S14 (“NA” for “Not Authenticated”) following which several actions can be considered, at the discretion of the designer. In particular, the variable n can be reset to zero.

[0045] The times at which the AUTH authentication step is executed are defined by the device 10 or by an application program of the device 100 which communicates with the device 10. Numerous possibilities are available to the designer for defining these times. For example, in the case of a printer and an ink cartridge, the AUTH authentication step can be executed cyclically according to constant or variable time intervals, and / or according to operations in progress, for example each time a print order must be sent to an ink cartridge. In the case of an electric tool and its battery, the AUTH authentication step can similarly be executed according to constant or variable time intervals, or each time the battery is requested by the tool, or even after a certain number of requests.

[0046] The execution of the KGEN step takes longer than that of the AUTH authentication step, which is by nature a symmetric cryptography authentication step. The method of the invention makes it possible to achieve a compromise between security and execution speed due, on the one hand, to the high degree of security offered by the KGEN step, and, on the other hand, the speed of execution of the AUTH authentication steps. More particularly, the robustness of the method is greater the smaller the setpoint value N, because the key Ks is then renewed a greater number of times during the use cycle of the accessory. Conversely, the time saving offered by the method of the invention is greater the larger the setpoint value N, because the number of KGEN steps for renewing the key Ks will be small compared to the number of AUTH authentication steps.Thus, the choice of the setpoint value N makes it possible to achieve a compromise between the security offered by the method and the execution time of a multiplicity of AUTH authentication steps. The time "lost" for the renewal of the key Ks during N authentication steps is all the more important as the setpoint value N is small, for higher security. When N is equal to 1, the key Ks is renewed after each AUTH authentication step, and the execution time of the method is maximum for maximum security. When N is very large, the key is renewed only once for N authentications and the time dedicated to its renewal has a small impact on the execution time of the N AUTH authentication steps.

[0047] Figure 3 shows another embodiment of the method of the invention showing its implementation from the first introduction of the accessory 200 into the device 100. At a step S20, the device 10 detects the presence of the new accessory (“DET”) or is informed of the insertion of the new accessory by the application program executed by the device 100. At a step S21, the device 10 conducts a preliminary and in itself conventional step “CHECK[ID]” of verifying the identity and authenticity of the accessory, for example from its serial number or a certificate that the latter provides it, or any other means. This first verification of the authenticity of the accessory can optionally be conducted with the help of a remote server, via an internet connection.

[0048] In one embodiment, step S21 comprises verifying identification information of the slave device's certificate (manufacturing date, serial number, etc.), then verifying that the certificate and the public key of the slave device it contains are not part of a revocation list. The host device verifies the signature of the slave device's certificate with the latter's public key, which it extracts from its certificate. Optionally, an asymmetric authentication step that is conventional in itself can then be conducted: the host device sends a challenge to the slave device, which the latter signs with its private key. This signature is then verified by the host device using the slave device's public key.

[0049] The device 10 then sets the variable n to 0, during the aforementioned step S11, then sends the slave device 20 a specific command, for example a “GSK” (“Generate Secret Key”) command, to trigger the execution of the KGEN step for generating the secret key Ks. In a step S22, the device 10 then places itself in a waiting state “WAIT[AREQ ]” where it waits to receive an authentication request “AREQ” sent to it by an authentication cycle management program. This program is for example the application program of the device, which decides when and in which cases it is appropriate to reauthenticate the accessory. When the AREQ request is received, the device 10 checks whether the variable n is equal to the setpoint value N in the aforementioned step S13. If the response is positive, the device 10 resets the variable n to 0 in the aforementioned step S11 and re-executes the KGEN step.The device 10 then increments the variable n (step S12) before executing the authentication step AUTH. If the answer is negative, the device 10 executes the authentication step AUTH with the current secret key Ks, after having incremented the variable n (step S12). After the authentication step AUTH, if it is conclusive, the device 10 returns to the waiting step S22 for a new AREQ request. If the authentication step AUTH is not conclusive, the device 10 rejects the accessory at the aforementioned step S14 (“NA >>) and executes any measure deemed appropriate by its designer, such as resetting the variable n.

[0050] In a variant, step KGEN is systematically preceded by step S21 of verifying the identity and authenticity of the accessory, as shown in dotted lines in Figure 3.

[0051] Figure 4 shows an exemplary embodiment of the authentication step AUTH. In a step S30, the device 10 generates a random number or challenge RN1 (“GEN[RN1 ]”). In a step S31, the device 10 sends the challenge RN1 to the device 20 (“SEND[RN1 ] >>). In a step S41, the device 20 receives the challenge RN1 (“RECEIVE[RN1] >>). In a step S32, the device 10 calculates a result R1 by encrypting RN1 using the function F1 and the secret key Ks (R1 = F1 KS(RN1 )). In a step S42, the device 20 itself calculates a result R2 by encrypting RN1 using the function F1 and the secret key Ks (R2 = F1 KS(RN1 )). In a step S43, the device 20 sends the result R2 to the device 10 (“SEND[R2] >>). In a step S33, the device 10 receives the result R2 (“RECEIVE[R2] >>). In a step S34, the device 10 checks that the results R1 and R2 are equal. If the response is positive (“Y”), the device 20 is considered to be validly authenticated.Otherwise, the device 10 returns a negative response (N) leading to the rejection of the device 20 (step S14, Figs. 2 and 3).

[0052] Figure 5 shows an example of implementation KGEN1 of the step KGEN of generating the key Ks using the Diffie-Hellman key exchange method implemented with the modular exponentiation function, the order of the steps retained for the present description not being limiting. In a step S50, the device 10 generates two numbers p, g, p being a prime number and g a number strictly smaller than p. In a step S51, the device 10 sends the numbers p and g to the device 20 (“SEND[p, g]). In a step S61, the device 20 receives the numbers p and g (“RECEIVE[p, g] >>). In a step S52, the device 10 generates a random number x which will form its secret key (“GEN[x] >>). In a step S62, the device 20 generates a random number y which will form its secret key (“GEN[y] >>). At a step S53, the device 10 calculates a number P1 such that: P1 = g A x mod p, or g to the power of x modulo p, calculated with the modular exponentiation function noted "A >>,

[0053] At a step S63, the device 20 calculates a number P2 such that: P2 = g A y mod p, or g to the power y modulo p.

[0054] In a step S54, the device 10 sends the number P1 to the device 20 and receives the number P2 from the device 20 (“SEND[P1], RECEIVE[P2] >>). In a step S64, the device 20 sends the number P2 to the device 10 and receives the number P1 from the device 10 (“SEND[P2], RECEIVE[P1] >>).

[0055] In a step S55, the device 10 calculates the shared secret key Ks using the following formula: Ks = P2 A x mod p, or P2 to the power of x modulo p.

[0056] In a step S65, the device 20 calculates the shared secret key Ks using the following formula:

[0057] Ks = P1 A y mod p, or P1 to the power y modulo p.

[0058] At the end of these steps, the devices 10, 20 therefore each have the same secret key Ks without it having circulated in clear text on the data bus 30.

[0059] In one embodiment, the KGEN step is implemented using the ECDH (Elliptic Curve Diffie-Hellman) algorithm, a Diffie-Hellman key exchange based on elliptic curves, to achieve a higher degree of security.

[0060] In an embodiment KGEN2 of the KGEN step illustrated in Figure 6, it is considered important to maintain a link between the private key of the slave device, used in step S21 for the verification of its authenticity by means of its certificate, and subsequent operations such as the KGEN step. This makes it possible in particular to eliminate the risk that a fraudster uses an authentic slave device to conduct step S21, then substitutes a fraudulent slave device for it to conduct the KGEN step. Thus, according to this embodiment, the KGEN step comprises the following steps, which are here and without limitation implemented by means of the ECDH algorithm:

[0061] - a step S70 of calculation by the host device of a shared secret SST as a function of a private key HPRIVK of the host device and a public key SPUBK of the slave device, such that:

[0062] SST = ECDH(HPRIVK, SPUBK)

[0063] - a step S80 of calculation by the slave device of the shared secret SST as a function of a private key SPRIVK of the slave device and a public key HPUBK of the host device, which the latter has previously communicated to the slave device, such that:

[0064] SST = ECDH(SPRIVK, HPUBK)

[0065] - a step S71 of generating an RN2 challenge by the host device and sending it to the slave device (“GEN[RN2] >>),

[0066] - a step S81 of reception of the RN2 challenge by the slave device

[0067] (“RECEIVE[RN2]”), and

[0068] - steps S72, S82 of calculating the key Ks by each device by means of a function F2, such that:

[0069] Ks = F2(SST, RN2) where the F2 function can be a cryptography function, for example Exclusive OR (“XOR”), the SHA2 function (“Secure Hash Algorithm”) or the HMAC function (“Keyed-Hash Message Authentication Code”).

[0070] In this case, the fact that the key Ks depends on the shared secret SST ensures that the following authentication steps will not be successful if the slave device does not contain the private key SPRIVK used to generate the shared secret. The preliminary authentication of the slave device then becomes completely optional from a security perspective.

[0071] Furthermore, if the shared secret SST is saved by each of the devices, it may be decided not to execute again the steps S70, S80 of generating the shared secret SST during the subsequent steps KGEN of regenerating the key Ks. Thus, in a simplified embodiment KGEN3 of the steps KGEN consecutive to the first step KGEN2, shown in FIG. 7, only the steps S71, S72, S81, S82 are executed to generate new keys Ksi after generation of a first key Ks. The steps S72, S82 are then executed as follows: Ksi = F2'(SST, RN2i)

[0072] RN2i being the challenge generated by the host device in step S71, and SST the previously generated and stored shared secret. The function F2' may here be identical or different from the function F2 used during the execution of step KGEN2.

[0073] In yet another variant, the KGEN2 embodiment and the simplified KGEN3 embodiment of the KGEN step are alternated, for example the KGEN2 embodiment of the KGEN step is executed again after a certain number of executions of the KGEN3 embodiment of the KGEN step.

[0074] Steps S71, S72, S81, S82 are themselves susceptible to various variants. For example, the challenge generated in step KGEN3 may be an RN3 challenge generated by the slave device. In this case:

[0075] Ks = F2(SST, RN3)

[0076] Also, still during the KGEN3 step, the key Ks can be calculated both from an RN2 challenge generated by the host device and from an RN3 challenge generated by the slave device. In this case:

[0077] Ks = F2(SST, RN2, RN3)

[0078] The method of the invention implementing, after a step KGEN2, any of these variants of step KGEN3, makes it possible to achieve an even more advantageous compromise between security and execution speed, since, due to the elimination of the steps for generating the shared secret SST, the subsequent so-called "simplified" steps KGEN3 of step KGEN are much faster to execute than the initial step KGEN2. In yet another simplified embodiment KGEN4 of the KGEN steps following the first step KGEN2, shown in FIG. 8, each generation of a new shared key Ksi+i involves the value of the previous key Ksi, by combining the previous key Ksi with a challenge RN2i+i generated by the host device during the step considered. In this case, steps S72, S82, denoted S72', S82' in FIG. 8, are executed as follows:

[0079] Ksi+i = F3(Ksi, RN2i+i)

[0080] This embodiment can also be implemented by combining the previous key Ksi with a challenge RN3i+i generated by the slave device: Ksi+i = F3(Ksi, RN3i+i) or by combining the previous key Ksi with two new challenges RN2i+i, RN3i+i generated respectively by the host device and the slave device:

[0081] Ksi+i = F3(Ksi, RN2i+i, RN3i+i) the function F3 can, like the function F2, be a cryptography function, for example the Exclusive OR (“XOR >>), the SHA2 function or the HMAC function.

[0082] This variant can also involve the SST shared secret:

[0083] Ksi+i = F3(SST, Ksi, RN2 i+ (i) or, alternatively:

[0084] Ksi+i = F3(SST, Ksi, RN3 i+ i) or, as another variant: Ksi+i = F3(SST, Ksi, RN2 i+ i, RN3 i+i) Ultimately, the following shared key generation steps may differ from the first Ks key generation step, by using the previously calculated SST shared secret or the previous Ks key value, or even a combination of several previous Ks key values, or even a combination of these two variants.

[0085] It is clear to those skilled in the art that the steps which have just been described may also be the subject of various other variants, and may in particular be implemented by means of any type of cryptographic function having a satisfactory degree of security. Furthermore, the term "random number" will be understood, in the present description and the claims, as non-limiting and not having a strict mathematical meaning, and may designate a pseudo-random number or even a number generated by means of a counter.

[0086] In one embodiment, the AUTH authentication step is implemented by means of the aforementioned HMAC function which consists of encrypting the data by means of a hash function. Simpler functions, such as the aforementioned SHA2 function, can also be used. Similarly, the control of the number n of AUTH authentication steps before renewal of the key Ks can be ensured in various ways, for example by decrementing a counter receiving the setpoint N with detection of the crossing to zero of the counting value.

[0087] In one embodiment, the master device 10 comprises a method configuration register into which three configuration values ​​can be loaded. A first value indicates that the key Ks must be generated before each AUTH authentication step. A second value indicates that the key Ks must be generated only once when the accessory is put into service, and that all subsequent authentications will therefore be based on this key. A third value indicates that the number N loaded into the counter must be used to determine the maximum number of AUTH authentication steps before renewing the key Ks. Such a configuration can also be obtained without using a configuration register, by loading predetermined values ​​into the counter which will be interpreted by the device 10 as not consisting of the setpoint value N but as configuration values.

[0088] The master device 10 and the slave device 20 are themselves capable of various embodiments and integration into an electrical or electronic device, and may or may not be equipped with an arithmetic coprocessor. Figures 9 and 10 show by way of example an architecture of the master device 10 and the slave device 20, respectively. Each device 10, 20 comprises an application processor, respectively APROC, APROC2, an arithmetic coprocessor, respectively CPROC1, CPROC2, a non-volatile memory area, respectively MEM10, MEM20, and a volatile memory area, respectively MEM11, MEM21, which may comprise secure registers, and a bus interface circuit, respectively BINT1, BINT2. These elements are connected by an internal data bus DTB and address bus ADB. The bus interface circuits BINT1, BINT2 are connected to each other by the data bus 30.The device 10 may further comprise a wireless communication interface CINT to enable communication with a remote server via an NTW network such as the Internet. The device 10 comprises an application program APPGR1 which manages all of its functionalities and an authentication program AUTPGR1 which executes the steps of the method assigned to the device 10 described above. Similarly, the device 20 comprises an application program APPGR2 which manages all of its functionalities and an authentication program AUTPGR2 which executes the steps of the method assigned to the device 20 described above. The secret key Ks may be stored in the volatile memory MEM11, MEM21 of each device. The volatile memory area MEM11 of the device 10 may further comprise a down-counter register DCREG1 receiving the setpoint value N and a configuration register CREG1 for configuring the method as indicated above.The N instruction can be loaded at the factory into an unalterable area of ​​the MEM10 memory and then loaded into the DCREG1 down-counter register to count down the number of authentication steps.

[0089] In one embodiment, the slave device 11 also receives a setpoint value M. This setpoint value M may be equal to or different from N. The setpoint value M may be factory-loaded into an unalterable area of ​​the memory MEM20 and then loaded into a down-counter register DCREG2 of the memory MEM21 of the slave device for counting down the number of authentication steps.

[0090] The slave device 11 is in this case configured to count the number of times the key Ks is used, then refuse to use it when it has been used M times. This option makes it possible to protect the slave device against side-channel attacks which would consist, by means of a fraudulent host device, of sending multiple challenges to the slave device in order to discover its secret key Ks.

[0091] Furthermore, in the particular case where M is less than N, the slave device responds with an error message when the host device sends it an authentication request of rank M+1, which indicates to the host device that it must reinitiate the KGEN step although its count of the number of authentication steps has not yet reached the set value N.

[0092] In a variant of the method of the invention based on this embodiment of the slave device, the host device does not manage the counting of the number of authentication steps by means of the setpoint value N. This management is delegated to the slave device by means of the setpoint value M. What has been described above concerning the implementation of the method of the invention applies to this variant with, as a difference, the fact that it is the slave device which causes each new execution of the KGEN step of regeneration of the key Ks. A configuration register CREG2 for configuring the method as indicated above can also be provided in the slave device. The triggering of each new execution of the KGEN step can be implemented in various ways. For example, the slave device sends an error message to the host device when the setpoint M is exceeded, as indicated above.Alternatively, the slave device sends the host device a key regeneration request message Ks when the setpoint M is reached. Receiving this key regeneration request then replaces steps S11, S12, S13 of Figure 3, which are in this case executed by the slave device.

[0093] Finally, in yet another embodiment of the method of the invention, the KGEN step is executed only once, which corresponds to an infinite value of N or M. In this case, neither the host device nor the slave device monitors the number of authentication steps performed with the key Ks.

Claims

Demands 1. A method for authenticating a slave device (20) by a host device (10), the host device (10) and the slave device (20) being connected by a data bus (30) and each comprising cryptographic computing means, characterized in that it comprises: - a first step (KGEN, KGEN1, KGEN2) of generating a secret key (Ks) shared by the host device (10) and the slave device (20), comprising an exchange of data between the host device and the slave device from which the host device and the slave device generate the secret key (Ks) without it passing over the data bus, and - a plurality of authentication steps (AUTH) of the slave device by the host device, of challenge / response type, using a symmetric cryptography algorithm and the secret key (Ks), and wherein the host device (10) or the slave device (20) is configured to count the number (n) of authentication steps (AUTH) in which the secret key (Ks) is used, and, when this number is equal to a setpoint value (N, M), the host device (10) and the slave device (20) execute a second step (KGEN3, KGEN4) of generating a new secret key (Ksi, Ksi+i) usable during a subsequent plurality of authentication steps (AUTH) of the slave device.

2. Method according to claim 1, wherein the setpoint value (N, M) is configurable and is loaded into a memory (MEM11, MEM21) or into a register (DCREG1, DCREG2) of the host device (10) or of the slave device (20).

3. A method according to any one of claims 1 and 2, wherein the first step (KGEN1, KGEN2) of generating a secret key (Ks) includes a Diffie-Hellman key exchange.

4. A method according to any one of claims 1 to 3, wherein the first step (KGEN2) of generating a secret key (Ks) comprises steps (S70, S80) of generating a secret (SST) shared by the host device and the slave device, and steps (S72, S82) of generating the secret key (Ks) from the shared secret and at least one random number (RN2).

5. A method according to claim 4, wherein the second step (KGEN3) of generating a new secret key (Ksi) shared by the host device and the slave device comprises a step (S72) of generating the new secret key (Ksi) from the shared secret (SST) generated during the first step (KGEN2) of generating a secret key (Ksi) and at least one random number (RN2i).

6. A method according to any one of claims 1 to 7, wherein the second step (KGEN4) of generating a new secret key (Ksi+i) shared by the host and slave devices comprises a step (S72') of generating the new secret key (Ksi+i) from at least one previous value (Ksi) of the secret key and at least one random number (RN2). i+ i).

7. A method according to any one of claims 1 to 6, wherein each step of the plurality of challenge / response authentication (AUTH) steps of the slave device (20) comprises: - the sending (S31) by the host device of a random number (RN1) to the slave device, - the calculation of a first result (R1) by the host device, including the transformation of the random number by the symmetric cryptography algorithm using the secret key (Ks), - the calculation of a second result (R2) by the slave device, including the transformation of the random number by the same symmetric cryptography algorithm using the secret key (Ks), - the sending of the second result (R2) to the host device by the slave device, and - verification by the host device that the second result (R2) is equal to the first result (R1).

8. A method according to any one of claims 1 to 7, wherein the host device (10) is an electronic circuit integrated into an electrical or electronic apparatus operating with an accessory device, and wherein the slave device (20) is an electronic circuit integrated into the accessory.

9. Method according to claim 8, wherein the accessory device is an ink cartridge or an electric battery.

10. Authentication device comprising a slave device (20) and a host device (10), the host device and the slave device being connected by a data bus and each comprising cryptographic computing means, characterized in that the host device and the slave device are configured to: - execute a first step (KGEN, KGEN1, KGEN2) of generating a shared secret key (Ks), by exchanging data from which the host device and the slave device generate the secret key (Ks) without it passing over the data bus, and - to conduct a plurality of authentication steps (AUTH) of the slave device by the host device, of the challenge / response type, using a symmetric cryptography algorithm and the secret key (Ks), and in which: - the host device (10) or the slave device (20) is configured to count the number (n) of authentication steps (AUTH) in which the secret key (Ks) is used, and, when this number is equal to a setpoint value (N, M), the host device (10) and the slave device (20) are configured to execute a second step (KGEN3, KGEN4) of generating a new secret key (Ksi, Ksi+i) usable during a next plurality of authentication steps (AUTH) of the slave device.

11. Device according to claim 10, wherein the setpoint value (N, M) is loaded into a memory (MEM11, MEM21) or into a register (DCREG1, DCREG2) of the host device (10) or of the slave device (20).

12. Device according to any one of claims 10 and 11, wherein the host device (10) and the slave device (20) are configured to generate the secret key (Ks) by a Diffie Hellman key exchange.

13. Device according to any one of claims 10 to 12, wherein the host device (10) and the slave device (20) are configured to: - during the first step (KGEN2) of generating a secret key (Ks) shared by the host and slave devices, execute steps (S70, S80) of generating a secret (SST) shared by the host and slave devices, and steps (S72, S82) of generating the initial secret key (Ks) from the shared secret and at least one random number (RN2), and - during the second step (KGEN3) of generating a new secret key (Ksi) shared by the host device and the slave device, execute a step (S72) of generating the new secret key (Ksi) from the shared secret generated during the first step (KGEN2) of generating a secret key (Ksi) and at least one random number (RN2i).

14. Device according to any one of claims 10 to 13, wherein the host device (10) is an electronic circuit integrated into an electrical or electronic apparatus operating with an accessory device, and wherein the slave device (20) is an electronic circuit integrated into the accessory.

Images