Patent ID: 12189754

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Like features have been designated by like references in the various Figures. In particular, the structural and/or functional features that are common of the various embodiments may have the same references and may dispose identical structural, dimensional and material properties.

For the sake of clarity, only the operations and elements that are useful for an understanding of the embodiments described herein have been illustrated and described in detail. In particular, this authentication method can be adapted to the usual communication processes.

Unless indicated otherwise, when reference is made to two elements connected together, this signifies a direct connection without any intermediate elements other than conductors, and when reference is made to two elements coupled together, this signifies that these two elements can be connected or they can be coupled via one or more other elements.

In the following disclosure, unless indicated otherwise, when reference is made to absolute positional qualifiers, such as the terms “front”, “back”, “top”, “bottom”, “left”, “right”, etc., or to relative positional qualifiers, such as the terms “above”, “below”, “higher”, “lower”, etc., or to qualifiers of orientation, such as “horizontal”, “vertical”, etc., reference is made to the orientation shown in the Figures.

Unless specified otherwise, the expressions “around”, “approximately”, “substantially” and “in the order of” signify within 10%, and preferably within 5%.

FIG.1shows, schematically and in block form, an example architecture of an electronic device10.

The electronic device10comprises a processor11(CPU) adapted to implement various instructions to process data stored in the memories of and/or provided by other circuitry to the device10.

The electronic device10further comprises different types of memories, including non-volatile memory12(NVM), volatile memory13(RAM), and/or read-only memory14(ROM). Each memory is adapted to store different types of data. According to one embodiment, the device10may have one or more of these different types of memories, and/or have memories of only one or two of these types.

The electronic device10further comprises different circuits15(FCT) adapted to perform different functions. By way of example, the circuits15may comprise measurement circuits, data conversion circuits, encryption circuits, etc.

The electronic device10may further comprise interface circuits16(IN/OUT) adapted to send and/or receive data from outside the device10. The interface circuitry16may be further adapted to implement a data display such as a display screen. The electronic device10is further particularly adapted to communicate with other electronic devices, and to implement an authentication method to authorize such communication.

The electronic device10further comprises one or more data buses17adapted to transfer data between its various components. In particular, the bus17is used to transfer data stored in the memories12to14to the processor11, circuits15and/or interface circuits16.

FIG.2shows communication, schematically and in block form, between two devices21and22of the type of device10described in connection withFIG.1.

The devices21and22are devices of the type of device10described in connection withFIG.1. The device21is a terminal-type device. InFIG.2, the device21is a printer, for example. The device22is a peripheral-type device, and more particularly device22is a consumable, adapted to be used by device21. InFIG.2, the device22is, an ink cartridge, for example, adapted to be used by device21.

Upon installation of the device22in the device21, the devices21and22implement an authentication method to verify that they are authorized to be used together. According to one example, this authentication method may verify the hardware and/or software compatibility of the devices21and22. According to another example, this authentication method may be able to prevent a malicious device from accessing secret data stored in the devices21and22.

An example of implementation and of authentication method embodiments are described in connection withFIGS.3through7.

FIG.3illustrates, schematically and in block form, an example embodiment of a method for authenticating a device P of the type of device22described in connection withFIG.2with an electronic device V of the type of device21described in connection withFIG.2.

The example described herein is a Verifier/Prover type of authentication method in which a verifier device, in this case the V device, sends data to the prover device, in this case the P device, for it to apply a transformation to it. The prover device then sends the result of the transformation back to the verifier device for verification. If the result of the verification is correct then the prover device is authenticated to the verifier device. The example authentication method is described in more detail below.

FIG.3is split in two, lengthwise, by a dotted line; the left side ofFIG.3relates to the device V, and the right side ofFIG.3relates to the device P.

The authentication method may begin with an optional ID operation, during which the devices V and P exchange identification information. In effect, the devices V and P each have single or multiple identification information, such as at least single identification information v for the device V, and at least single identification information p for the device P. According to one example, the information v and p are binary words representing identification numbers.

Each device V, P then implements a function101(“ID Check” block) that allows them to know if they have already communicated with the other device P, V based on the received identification information p, v. According to one example, the function101is a search function in a memory space storing the identification information of all the electronic devices with the device V or P has already communicated, i.e. the electronic devices with which the authentication method has already been successfully implemented. According to one example, this memory space may be emptied on a regular basis. If the function101indicates that the devices V and P have already communicated with each other recently, the devices V and P may not implement the authentication method and start communicating (not shown inFIG.3). However, if the function101indicates that the devices V and P have never communicated with each other, then the rest of the authentication method is implemented.

The authentication method further comprises a GEN operation, following the identification operation, during which the devices V and P use a same function102(“Data Gen” block) to generate a DataVo and a DataPo data respectively. The devices V and P do not communicate with each other to generate the data DataVo and DataPo. According to one embodiment, if the devices V and P are intended to communicate with each other, then they are adapted to generate data DataVo and DataPo that are identical or affiliated with each other. According to one example, if the authentication method uses a symmetric encryption key as the data DataVo and DataPo, the data DataVo and DataPo are identical. However, if the authentication method uses an asymmetric encryption key as the data DataVo and DataPo, the data DataVo and DataPo are not identical but are affiliated with each other. The function102may be a function for searching the data DataVo and DataPo in memory spaces of the devices V and P.

The GEN operation is directly followed by a VPo verification operation, during which the devices V and P exchange transformed data. The VPo operation comprises the following steps: the device V implements a function103(block “fCo”), taking as input the data DataVo and, optionally, the identification information v and p, to generate a data Co; the device V sends the data Co to the device P; the device P implements a function104(block “fRo”), taking as input the data Co and the data DataPo and, optionally, the identification information v and p, to generate data Ro and secret data sPo; the device P sends the data Ro to the device V; and the device V implements a function105(block “fVo”), taking as input the data Co and Ro and, optionally, the identification information v and p, and the data DataVo, to generate result data vfo and secret data sVo.

The verification operation VPo is followed by a final operation F, during which the devices V and P decide whether they can communicate with each other. In this operation, the device V implements a function106(“Paired?” block), taking as input the identification data v and p, the result data vfo and the secret data sVo. The device P implements a function107(“Paired?” block), taking as input the identification data v and p, and the secret data sPo. The object of the function106is to verify the result data vfo and the secret data sVo. The object of the function107is to verify the secret data sPo. In addition, and optionally, the functions106and107can use the identification information v and p. If the functions106and107consider the verifications successful, then the devices V and P can communicate with each other, their identification information can be registered. Otherwise, no communication starts between devices V and P.

FIG.4illustrates, schematically and in block form, an embodiment of a device authentication method of the type of device22described in connection withFIG.2to an electronic device of the type of device21described in connection withFIG.2.

The method ofFIG.4contains elements in common with the method described in connection withFIG.3. The common elements are not described again, and only the differences between the methods inFIGS.3and4are highlighted.

Like the method inFIG.3, the method inFIG.4comprises the following successive operations: the ID operation, during which the devices V and P exchange their identification information v and p, and implement the function101to check whether they have not already been authenticated to each other; the GEN operation, during which the devices V and P implement the function102to generate the data DataVo and DataPo; the verification operation VPo, during which the devices V and P implement the functions103,104and105, to generate and/or exchange the data Co, Ro, sVo, sPo and vfo; and the operation F, during which the devices V and P implement the functions106and107, to conclude whether they can communicate with each other or not.

Unlike the method ofFIG.3, the method ofFIG.4does not include a single verification operation VPo, but includes N+1 successive verification operations VP0, VP1, . . . , VPN, where N is a natural number greater than 1.

Each operation VPi, with i being a natural number varying from 1 to N, is similar to the verification operation VPo described in relation toFIG.3, and comprises the following successive steps: the device V implements a function203-i(block “fCi”), similar to the function103, taking as input the data DataVo, optionally the identification information v and p, and the secret data sVi−1 of the preceding verification operation VPi−1, to generate data Ci; the device V sends the data Ci to the device P; the device V implements a function204-i(block “fRi”), similar to the function104, taking as input the data Ci and the data DataPo, optionally the identification information v and p, and the secret data sPi−1 from the preceding verification operation VPi−1, to generate data Ri and secret data sPi; the device P sends the data Ri to the device V; and the device V implements a function205-i(block “fVi”), similar to the function105, taking as input the data Ci and Ri, optionally the identification information v and p, and the secret data sVi−1, to generate a result data vfi and a secret data sVi.

According to one embodiment, the functions103,203-1, . . . ,203-N are data generation functions such as random data generation functions. According to one example, the functions103,203-1, . . . ,203-N may additionally be encryption functions, for example, using the data DataVo as an encryption key to encrypt a random data. According to one variant, the functions103,203-1, . . . ,203-N are functions that fetch data from the memories of the devices V and P. According to another embodiment, the functions103,203-1, . . . ,203-N may also be verification functions to validate that the data received from the previous verification operation, the functions103,203-1, . . . ,203-N in this case are, for example, signature functions.

According to one embodiment, the functions104,204-1, . . . ,204-N are encryption functions such as permutations, using the data DataPo as the encryption key. According to another example, the functions104,204-1, . . . ,204-N are signature functions.

According to one embodiment, the functions105,205-1, . . . ,205-N provide data vfo, . . . , vfN as output showing the result of a comparison of the data Co, . . . , CN with the corresponding data Ro, . . . , RN. The data vfo, . . . , vfN are flags, for example, showing a True state and a False state. The True state means that the verification has worked and the False state means the opposite. According to one embodiment, the secret data sVo, . . . , sVN is used as a decryption key by the function105,205-1, . . . ,205-N. The device V decrypts the data Ro, . . . , RN with the secret data sVo, . . . , sVN, and then checks whether it conforms to the expected data. According to another example, the functions105,205-1, . . . ,205-N do not require decryption of the data Ro, . . . , RN.

According to one example of implementation, the secret data sVi, respectively sPi, are all dependent on the secret data sVo, . . . , sVi−1, respectively on the secret data sPo, . . . , sPi−1 generated in the preceding operations VPo, . . . , VPi−1. Thus, the result of the functions205-1, . . . ,205-N always depend on the previous verification operations, and an electronic device that would manage to evade one or more verification operations would not be able to carry out the following verification operations.

According to one example of implementation, at least one of the functions103,203-1, . . . ,203-N is different from the others, and preferably, the functions103,203-1, . . . ,203-N are all different from each other. Similarly, at least one of the functions104,204-1, . . . ,204-N is different from the others, and preferably the functions104,204-1, . . . ,204-N are all different from each other. Similarly, at least one of the functions105,205-1, . . . ,205-N is different from the others, and preferably the functions105,205-1, . . . ,205-N are all different from each other.

One advantage of this embodiment is that it makes the authentication method more complex and thus more difficult to copy.

Another advantage of this embodiment is that it also reduces the exposure of secret data of subsequent verification operations, if the device P (or V) participating in the exchange is not authentic.

FIG.5illustrates, schematically and in block form, another embodiment of a device authentication method of the type of device22described in connection withFIG.2to an electronic device of the type of device21described in connection withFIG.2.

The method ofFIG.5contains elements in common with the method described in connection withFIG.4. The common elements are not described again, and only the differences between the methods inFIGS.4and5are highlighted.

The method inFIG.5differs from the method inFIG.4in that, during implementation of the verification operations VPo, . . . , VPN, all data exchanges between the devices V and P are carried out in an encrypted manner. InFIG.5, all data exchanges of the verification operations VPo, . . . , VPN are carried out in an encrypted manner, but, in a variant, at least one verification operation VPi has its data exchanges carried out in an encrypted manner. Thus each operation VPi, for i varying from 0 to N, comprises the following successive steps: the device V implements the function103or203-ito generate the data Ci; the device V sends the data Ci to the device P in encrypted form as described below; the device V implements the function104or204-ito generate the data Ri and the secret data sPi; the device P sends the data Ri to the device V in an encrypted manner as described below; and the device V implements the function105or205-ito generate the result data vii and the secret data sVi.

To exchange data in an encrypted manner, the device V implements the encryption and decryption functions308-i(“EVi” block), and the device P implements the encryption and decryption functions309-i(“EVi” block).

The functions308-iuse an encryption and decryption key pskVi, and are adapted to: encrypt the data Ci for sending it to the device P by using the pskVi key as the encryption key; the encrypted data Ci is denoted EVi(Ci); and decrypt the data sent by the device P, using the key pskVi as the decryption key.

Similarly, the functions309-iuse a pskPi encryption and decryption key, and are adapted to: decrypt the data sent by the device V, using the pskPi key as the decryption key; and encrypt the data Ri for sending it to the device V, using the key pskPi as the encryption key; the encrypted data Ri is denoted EPi(Ri).

The functions308-i, the functions309-irespectively, are further adapted to provide the encryption and decryption key pskVi+1, the encryption and decryption key pskPi+1 respectively, used in the following verification operation VPi+1. According to one preferred embodiment, the functions308-i, the functions309-irespectively, generate the encryption and decryption key pskVi+1, the encryption and decryption key pskPi+1 respectively, using the encryption and decryption key pskVi, the encryption and decryption key pskPi respectively. Thus, all encryption and decryption keys pskVo, . . . , pskVN, encryption and decryption keys pskPo, . . . , pskPN respectively, are dependent on each other.

According to one exemplary embodiment, the encryption functions308-iand309-iimplement a symmetric encryption algorithm, in which the encryption key is identical to the decryption key. In this case, if the devices V and P are adapted to communicate with each other, then the keys pskVi and pskPi are therefore identical for each implementation of a verification operation VPi.

According to one alternative embodiment, the encryption functions308-iand309-iimplement an asymmetric encryption algorithm, in which the encryption key is different from the decryption key. In this case, the keys pskVi and pskPi are therefore different for each implementation of a verification operation VPi.

The method inFIG.5further differs from the method inFIG.4in that its identification operation Id is followed by a GEN′ operation similar to the GEN operation described in connection withFIGS.3and4. As during the GEN operation, during the GEN′ operation, the devices V and P use the same function102(“Data Gen” block) to generate the data DataVo and the data DataPo respectively. However, during the GEN′ operation, the devices V and P, independently of each other, also implement a function302(“START” block) for generating the encryption and decryption keys pskVo and pskPo. The function302takes as input the data DataVo, the data DataPo respectively, and, operationally, the identification data v and p, and provides as output the key pskVo, the key pskPo respectively.

One advantage of this embodiment is that it protects the data exchanged by the devices V and P. A device that could intercept this data will not be able to implement the method without also having access to the encryption and decryption keys that are never exchanged.

Another advantage of this embodiment is that it also reduces the exposure of the secret data exchanged or generated in the VPi operation to a device that would not have performed the previous VPo, VP1, . . . , VPi−1 operations.

FIG.6illustrates, schematically and in block form, another embodiment of a method for authenticating a device of the type of the device22described in relation toFIG.2with an electronic device of the type of the device21described in relation toFIG.2.

The method ofFIG.6contains elements in common with the method described in connection withFIG.4. The common elements are not described again, and only the differences between the methods inFIGS.4, and6are highlighted.

The method inFIG.6differs from the method inFIG.4in that, of the N+1 verification operations VPo, . . . , VPN, at least one pair of verification operations are linked. InFIG.6, the operations VP1and VPN are considered to form a pair of linked verification operations, but the person skilled in the art will know how to adapt the embodiment described to another pair of linked verification operations. Further, one embodiment of an authentication method may comprise more than one pair of linked verification operations. It is further noted that the method described in connection withFIG.6is compatible with the method described in connection withFIG.5, but they have not been combined so as to not impair the clarity ofFIG.6.

As previously discussed, in the authentication method ofFIG.6, the verification operations VP1and VPN are linked. More particularly, during implementation of the verification operation VP1, data A is generated by the device P and is then stored in the device V to be used only for the VPN authentication operation.

More precisely, during implementation of the verification operation VP1, the function304-1(block “fR1”) of the device P is adapted to generate not only the data Ri and secret data sP1, but also to generate data A. Data A is then sent to the device V at the same time as the data R1. The device V stores the data A. In the verification operation VPN, the function203-N (block “fCN”) takes as input the data DataVo, optionally the identification information v and p, the secret data sVN-1, and the data A, to provide as output the data CN and data B. The data CN and B are sent to the device P. The device P is adapted to implement a function410-N (“GB” block), taking as input the data B to provide data D as output, used by the function204-N. According to one example, the function410-N is an encryption function using the data B to decrypt the data D.

According to one alternative embodiment not shown, the data A may be generated by another function implemented by the device P. The data B may be generated by another function implemented by the device V.

One advantage of this embodiment is that it prevents a device that can evade one or more verification operations from implementing the authentication method.

FIG.7illustrates, schematically and in block form, another embodiment of a method for authenticating a device of the type of device22described in connection withFIG.2with an electronic device of the type of device21described in connection withFIG.2.

The method ofFIG.7contains elements in common with the method described in connection withFIG.4. The common elements are not described again, and only the differences between the methods inFIGS.4and7are highlighted.

The method ofFIG.7differs from the method ofFIG.4in that the GEN operation described in connection withFIG.4is replaced by a GEN″ operation, during which the devices V and P implement a function502(“Data Gen′” block). The function502is similar to the function102but differs in that the function502is adapted to provide as much data DataVi and DataPi, i varying from 0 to N respectively, as verification operations implemented in the authentication method. The devices V and P do not communicate with each other to generate the data DataVi and DataPi. According to one embodiment, if the devices V and P are intended to communicate with each other, then they are adapted to generate data DataVi that is identical or affiliated with the data DataPi. The function502may be a function for searching for data DataVo, . . . , DataVN, and DataPo, . . . , DataPN in the memory spaces of the devices V and P, such as the secure memory spaces of the devices V and P.

Thus, each function103,203-o, . . . ,203-N is adapted to receive the data DataVo, . . . , DataVN respectively, and each function104,204-o, . . . ,204-N is adapted to receive the data DataPo, . . . , DataPN respectively.

It is further noted that the method described in connection withFIG.7is compatible with the methods described in connection withFIGS.5and6, but they have not been combined, so as not to impair the clarity ofFIG.7.

An advantage of this embodiment of the authentication method is that the use of different data DataVi and DataPi at each verification operation makes copying this authentication method more difficult for an electronic device that is not adapted to implement it.

Various embodiments and variants have been described. Those skilled in the art will understand that certain features of these embodiments can be combined and other variants will readily occur to those skilled in the art. The embodiments ofFIGS.4through7may all be combined with each another. In particular, one preferred embodiment of an authentication method comprising a combination of all of these methods is covered in this description.

Further, the present description also relates to devices comprising memories storing sets of data for simulating the implementation of the methods described in connection withFIGS.4to7. More particularly, these devices may include data sets showing at least the following data:the data Co, . . . , CN;the data Ro, . . . , RN;the secret data sVo, . . . , sVN;the secret data sPo, . . . , sPN; andthe information vfo, . . . , vfN.

These data sets may further include data showing the encryption and decryption keys pskVo, . . . , pskVN, and pskPo, . . . , pskPN, or the encrypted data EVo(Co), . . . , EVN(CN), and EPo(Ro), . . . , EPN(RN).

Finally, the practical implementation of the embodiments and variants described herein is within the capabilities of those skilled in the art based on the functional description provided hereinabove.