METHOD FOR CONTROLLING ACCESS TO BUILDINGS

Description

[0001] The invention relates to a method and system for controlling access to buildings. The invention also relates to a mobile terminal and an electronic lock for implementing this access control system.

[0002] The applicant is aware of an access control method in which, to unlock an electronic lock, a mobile terminal transmits a cryptographic certificate to the electronic lock. This cryptographic certificate typically contains a mobile terminal identifier, an identifier of the electronic lock to be opened, and an access code. Furthermore, this cryptographic certificate also includes a digital signature constructed from the mobile terminal identifier, the electronic lock identifier, and the access code. This digital signature is a cryptogram obtained by encrypting a hash of the mobile terminal identifier, the electronic lock identifier, and the access code with a secret key and implementing an asymmetric encryption algorithm.The secret key is not stored on the mobile device, so it is not possible to create a new cryptographic certificate solely from the data on that device to, for example, unlock another electronic lock. Therefore, if the data on that mobile device is compromised, it does not compromise the security of the system.

[0003] Electronic locks contain only the public key, which is used to verify the integrity and authenticity of the received cryptographic certificate. If the integrity and authenticity of the received certificate are confirmed, the electronic lock moves to its unlocked state to allow access to the building. Otherwise, access is denied.

[0004] Such a process is disclosed, for example, in application EP1321901.

[0005] This method offers several advantages. First, it eliminates the need to establish a secure channel between the lock and the mobile device and then use that secure channel to transmit access authorizations to the electronic lock. Establishing a secure channel requires generating a session key in both the mobile device and the electronic lock, a key that changes each time the mobile device is presented to the lock. This session key must then be used to encrypt all information exchanged between the mobile device and the electronic lock using a symmetric encryption algorithm. Since no secure channel is established in the depositor's known method, this avoids the need to generate such session keys. Consequently, it reduces the number of data frames exchanged between the mobile device and the electronic lock.

[0006] Secondly, in the process described in application EP1321901, the private key used to generate a cryptographic certificate that unlocks an electronic lock is not contained within the mobile terminal or the electronic lock itself. Therefore, even if the security of the electronic lock or mobile terminal is compromised, it is not possible to generate new, valid cryptographic certificates to unlock other electronic locks using only the information contained within that electronic lock or mobile terminal. Consequently, the fact that the security of an electronic lock or mobile terminal is compromised does not affect the security of the access control system.

[0007] Third, as highlighted in application EP1321901, this access control method is advantageous because it only requires configuring mobile devices, not electronic locks, to authorize unlocking. Specifically, for a mobile device to be authorized to unlock a particular electronic lock, it is sufficient to store the cryptographic certificate corresponding to that device and that electronic lock in its memory. Programming the electronic lock is not necessary. Consequently, electronic locks do not need to be directly connected to a telecommunications network or similar infrastructure.

[0008] However, verifying a cryptographic certificate requires the implementation of asymmetric encryption algorithms. These algorithms are complex and consume more energy than, for example, symmetric encryption / decryption algorithms. Yet, in most access control systems, mobile terminals and / or electronic locks are powered by a battery. Therefore, it is desirable to have an access control method that offers the same advantages as that described in EP1321901, but also allows the use of symmetric encryption algorithms instead of asymmetric ones.

[0009] Furthermore, the procedure described in application EP1321901 requires programming each mobile terminal to be able to open an electronic lock. However, sometimes, rather than programming a mobile terminal, it is preferable, for example, because it is simpler, to program the electronic lock itself. Therefore, it is also desirable to have an access control procedure that offers the same advantages as that described in application EP1321901, while also allowing for reverse operation. This reverse operation involves programming an electronic lock to unlock when a specific mobile terminal is presented, even if that particular mobile terminal has not been previously programmed to open that specific electronic lock. Moreover, this reverse operation must not compromise the security of the access control system.For example, it would be unacceptable to require the electronic lock to transmit a cryptographic certificate to the mobile device and for the electronic lock to be unlocked as soon as the mobile device confirms the validity, integrity, and authenticity of the received cryptographic certificate. Indeed, a mobile device could easily be modified to consistently report that the received cryptographic certificate is valid when it is not, thereby triggering the unlocking of the electronic lock.

[0010] In known methods, when a mobile terminal needs to be disabled, it is necessary to reprogram either the terminal or the electronic lock so that the lock no longer moves in its unlocked state when the mobile terminal is presented. In this text, "disabling a mobile terminal" means revoking the mobile terminal's access permissions so that it can no longer unlock an electronic lock that it was previously able to unlock. For example, in the case of the method described in application EP1321901, a mobile terminal can be disabled by withholding the cryptographic certificate that authorizes it to unlock a particular electronic lock. A mobile terminal can also be disabled by revoking its cryptographic certificate. When an electronic lock is moved from one building to another, it may be necessary to disable all mobile terminals that were authorized to unlock that electronic lock.In this case, each mobile device must be individually disabled, which is a lengthy and tedious process if there are many devices. Therefore, a simpler method for disabling all mobile devices that were previously authorized to unlock a particular electronic lock would be desirable.

[0011] The prior art is also known from: WO2016 / 023558A1 and US2011 / 084799A1.

[0012] The invention aims to provide an access control method that satisfies at least one of the above requirements.

[0013] The invention is described in the attached set of claims.

[0014] The invention will be better understood upon reading the following description, given solely by way of non-limiting example and made with reference to the drawings in which: there figure 1is a schematic illustration of the architecture of a building access control system; the figure 2 is a schematic illustration in vertical cross-section of an electronic lock from the access control system of the figure 1 ; there figure 3 is a schematic illustration of an access authorization table contained in the electronic lock of the figure 2 ; there figure 4 is a schematic illustration of a list of mobile terminal indices contained in the electronic lock of the figure 2 ; there figure 5 is a schematic illustration of the contents of a memory on a mobile terminal of the access control system of the figure 1 ; there figure 6 is a schematic illustration of an access authorization table contained in the memory represented on the figure 5 ; there figure 7 is a flowchart of a building access control process implemented in the access control system of the figure 1; there figure 8 is a schematic illustration of the architecture of a first information frame transmitted from a mobile terminal to an electronic lock of the system of the figure 1 , and the figure 9 is a schematic illustration of the architecture of a second information frame transmitted from a mobile terminal to an electronic lock of the system of the figure 1 .

[0015] In the remainder of this description, the well-known characteristics and functions of a person skilled in the art are not described in detail.

[0016] In this description, detailed examples of embodiments are first described in Chapter I with reference to the figures. Then, in Chapter II, variations of these embodiments are presented. Finally, the advantages of the different embodiments are presented in Chapter III. Chapter I: Examples of detailed implementation

[0017] There figure 1represents a system 2 for access control to buildings, each equipped with at least one access door. To simplify the figure 1 Only one building, 4, equipped with an access door, 6, is shown. Door 6 is equipped with an electronic lock, 10.

[0018] Door 6 can be moved between an open and a closed position. In the closed position, it prevents access to the interior of building 4. In the open position, a visitor or resident can freely enter building 4.

[0019] To control access to building 4, system 2 also includes several mobile opening terminals. Only one mobile terminal 16 is shown on the figure 1 .

[0020] Typically, system 2 comprises several access doors, each equipped with an electronic lock to control access to multiple buildings or different parts of the same building. The various electronic locks and mobile terminals then operate as described for lock 10 and terminal 16, respectively. Therefore, these other electronic locks and mobile terminals are not described in detail and are not shown in the diagram. figure 1 .

[0021] Here, the lock 10 and the terminal 16 are, for example, structurally identical, respectively, to the lock and the electronic key described in application EP3431684. Thus, subsequently, only the characteristics of the lock 10 and the terminal 16 necessary to understand the invention are described.

[0022] The lock 10 moves reversibly between a locked and an unlocked state. In the locked state, it holds the door 6 in its closed position. In the unlocked state, the door 6 can be freely moved from its closed position to its open position. The lock 10 moves from its locked state to its unlocked state when a mobile terminal authorized to unlock this lock 10 is presented to it.

[0023] In this embodiment, the lock 10 has no internal power supply and is not connected to a public power grid. The lock 10 is powered by the terminal 16 when the latter is brought before the lock 10. The lock 10 also lacks a transceiver capable of directly establishing a long-distance data transmission link with a remote device, such as an access rights server or an administration workstation. The lock 10 is only capable of communicating with the terminal 16 and a programmer, such as the programmer 90 described later, via a short-distance link. In this text, a short-distance link is a data transmission link that can be established between two devices only if they are less than 10 m apart and, preferably, less than 50 cm or 10 cm apart.

[0024] Terminal 16 is easily transportable by hand by a human being. Here, terminal 16 is an electronic key equipped with a blade 38. Terminal 16 includes a microprocessor 40, non-volatile memory 42, and a battery 44. Although terminal 16 is here in the form of a mechanical key, in this text, the term "terminal" is used to avoid confusion with the cryptographic keys described later.

[0025] Blade 38 is intended to be inserted into lock 10. Thus, in this case, presenting terminal 16 to lock 10 is equivalent to inserting blade 38 into lock 10. When blade 38 is inserted into lock 10, this establishes wired connections between terminal 16 and lock 10. It is through these wired connections that terminal 16 supplies power to lock 10 and exchanges information frames with lock 10. A possible example of a mechanism for establishing these wired connections is described in detail in application EP3431684.

[0026] System 2 also includes an access rights server 50 and an administration workstation 60 to manage access permissions to the various buildings within System 2. Server 50 and workstation 60 are connected to each other via a long-distance data transmission network 80. This network 80 is, for example, a packet-switched network such as the Internet. Neither lock 10 nor terminal 16 is directly connected to this network 80.

[0027] Server 50 is capable of generating access authorizations to be stored in memory 42 and in the lock 10. An access authorization contains all the information necessary to be stored in a mobile terminal or an electronic lock so that the terminal can unlock the electronic lock. Thus, without this access authorization, the mobile terminal cannot unlock the electronic lock. To this end, server 50 includes a microprocessor 52 and a memory 54. Memory 54 contains the instructions and data necessary to implement the process of the figure 7 when these instructions are executed by microprocessor 52.

[0028] The administration workstation 60 allows a user to manage access permissions. To this end, it allows the user, under command, to trigger the creation of new access permissions by the server 50. It also allows the user, again under command, to instruct the server 50 to generate commands to invalidate previously created access permissions. For this purpose, workstation 60 includes, for example, a central processing unit 62 and a human-machine interface 64. As an illustration, the interface 64 here includes a screen 66 and a keyboard 68.

[0029] The central unit 62 includes a microprocessor 70 and a memory 72. The memory 72 contains the instructions and data necessary to implement the process of the figure 7 when these instructions are executed by microprocessor 70.

[0030] In this embodiment, station 60 is also used to program access permissions in mobile terminals. For this purpose, station 60 is connected to a mobile terminal programmer 90, for example, via a wired or wireless connection. The programmer 90 is capable of writing to the memory 42 of terminal 16. For example, it establishes a short-range connection with terminal 16 when the latter is located nearby. For example, programmer 90 has an opening that allows the blade 38 to be inserted into the programmer 90 to establish wired connections with the mobile terminal 16. Programmer 90 is used to write access permissions, generated by the server 50 and then transmitted to station 60, into memory 42.

[0031] In this embodiment, the programmer 90 also allows writing to a memory in the lock 10. For example, for this purpose, the programmer 90 includes a blade, identical to the blade 38, which can be inserted into the lock 10 to establish the wired connections between the programmer 90 and the lock 10. In this case, preferably, the programmer 90 is a portable device that can easily be carried by hand. Furthermore, the programmer 90 includes a buffer 92 in which the access permissions to be recorded in an electronic lock are temporarily stored. Thus, the access permissions can be transferred from station 60 to this buffer 92. Then, the programmer 90 is disconnected from station 60 and carried to the lock 10.Its blade is then inserted inside lock 10 and the access permissions stored in its buffer 92 are transferred into the memory of lock 10.

[0032] There figure 2 represents in more detail the architecture of lock 10. Lock 10 has a cylinder 100 conforming to the European format. This cylinder 100 is shown in profile on the figure 2 . The cylinder 100 has an opening 101 for inserting the blade 38 into the lock 10.

[0033] A lock-release mechanism 102 is housed inside this cylinder 100. This mechanism 102 is capable of moving the lock 10 from its locked state to its unlocked state. For example, the mechanism 102 is similar to that described in application FR3025236 or application EP3431684. To increase readability of the figure 2 The representation of mechanism 102 has been simplified.

[0034] The mechanism 102 typically includes a controllable electrical and / or magnetic actuator 104 and an electronic control unit 106 for this actuator 104.

[0035] The actuator 104 is capable of moving the lock 10 into its unlocked state in response to an unlock command transmitted by the unit 106. In the absence of an unlock command, the actuator 104 keeps the lock 10 in its locked state.

[0036] Unit 106 is fit for duty: to exchange information frames with the mobile terminal introduced inside the lock 10, and when the mobile terminal introduced into the lock is allowed to unlock the lock 10, to transmit to the actuator 104 the unlock command which triggers the movement of the lock 10 into its unlocked state.

[0037] For this purpose, unit 106 includes a microprocessor 108 and a memory 110. The memory 110 contains the instructions necessary to implement the process of the figure 7 when these instructions are executed by the microprocessor 108. Memory 110 also contains the data necessary for the implementation of the process of the figure 7 In particular, it contains: a unique Caes lock key, a Cpub lock identifier, a Cindex lock index, a Ct key derivation constant, a 112 access authorization table for mobile terminals authorized to unlock lock 10, and a 114 list of terminal indices.

[0038] The Caes key is a unique encryption key within System 2. In other words, no other electronic lock in System 2 contains the same Caes key. The Caes key is known only to lock 10 and server 50. For example, here, the Caes key is stored in a non-rewritable area of ​​memory 110. This non-rewritable area is created by making it impossible to write to this area using software and / or hardware. Thus, this Caes key cannot be modified or erased.

[0039] The Cpub identifier is an identifier that allows the lock 10 to be identified among all the electronic locks of the system 2. The Cpub identifier is also stored in the non-rewritable area of ​​memory 110.

[0040] The index Cindice is an index that was programmed into the lock 10, for example, during its initial commissioning. The index Cindice is stored in a rewritable area of ​​memory 110 so that it can be modified later after the initial commissioning of the lock 10.

[0041] The constant Ct is a constant whose value is the same in all electronic locks of system 2.

[0042] There figure 3This section provides a more detailed description of Table 112, the access authorization table. Table 112 has four columns: 120, 122, 124, and 126, and can contain from zero to several rows. For each row in Table 112, column 120 contains a terminal's Kpub identifier, column 122 contains a KKpub cryptogram, column 124 contains a priority Cpr index, and column 126 contains an Ov access code. All data within the same row of this table is associated with the Kpub identifier contained in column 120 of that row.

[0043] There figure 4 This represents list 114 in more detail. List 114 has two columns, 130 and 132, and rows. Each row contains, in column 130, a Kpub identifier of a terminal and, in column 132, an index Kindex associated with this Kpub identifier.

[0044] The various data contained in Table 112 and List 114, and their uses, are described later. Table 112 and List 114 are stored in the rewritable area of ​​memory 110.

[0045] There figure 5 represents in more detail the memory 42 of terminal 16. Memory 42 contains: a unique terminal key Kaes, a terminal identifier Kpub, a terminal index Kindex, a key derivation constant Ct, and an access authorization table 140 for electronic locks that this terminal is authorized to unlock.

[0046] The Kaes key is a unique encryption key within System 2. In other words, no other mobile device on System 2 contains the same Kaes key. The Kaes key is known only to device 16 and server 50. For example, here, the Kaes key is stored in a non-rewritable area of ​​memory 42. Thus, this Kaes key cannot be modified or erased.

[0047] The Kpub identifier is an identifier that allows the terminal 16 to be identified among all the mobile terminals of the system 2. The Kpub identifier is stored in memory 42. For example, the Kpub identifier is stored in an area of ​​memory 42 which can be written when the terminal 16 is programmed for the first time.

[0048] The Kindice is an index that was programmed into terminal 16, for example, during its initial setup or when its access permissions were updated. The Kindice is stored in a memory area 42 that can be modified after the initial setup of terminal 16.

[0049] The constant Ct recorded in memory 42 is the same in all mobile terminals of system 2. It is equal to the constant Ct recorded in all electronic locks of system 2.

[0050] There figure 6Table 140, the access authorization table, is described in more detail. Table 140 has four columns: 142, 144, 146, and 148, and from zero to several rows. For each row in Table 140, column 142 contains a lock identifier (Cpub), column 144 contains a cryptogram (KCpub), column 146 contains a priority index (Kpr), and column 148 contains an access code (Ov). The Ov code can take one first value and, alternatively, a second, different value. The first value indicates that terminal 16 is authorized to unlock lock 10. The other values ​​of this Ov code indicate that terminal 16 is not authorized to unlock lock 10. The data in a single row of Table 140 are all associated with the Cpub identifier contained in column 142 of that row.

[0051] The operation of system 2 will now be described with reference to the process of the figure 7 .

[0052] Initially, during phase 148, system 2 is installed. This phase 148 consists primarily of supplying the various electronic locks used in system 2 and installing them on the respective doors. During phase 148, the mobile terminals used in system 2 are also supplied.

[0053] Next, during phase 150, access authorizations are programmed in one or more mobile terminals of system 2. Here, this phase 150 is described in the particular case of terminal 16. However, what is described in this particular case applies to all mobile terminals of system 2.

[0054] During phase 150, for example, an administrator, using workstation 60, identifies the electronic locks of system 2 that terminal 16 can unlock. Then, they trigger the generation by server 50 of access permissions to be recorded in table 140 of terminal 16 for each of the identified electronic locks. The generation of these access permissions is illustrated here in the specific case where terminal 16 needs to be authorized to unlock lock 10. To do this, server 50 constructs the KCpub cryptogram by encrypting the following data using the Caes key of lock 10: the Kpub identifier of terminal 16, the Kindex of terminal 16, the Cpub identifier of lock 10, and the Cindex of lock 10.

[0055] In other words, the KCpub ciphertext is constructed using the following relationship: KCpub = CBC_MAC(Caes; Kpub; Kindice; Cpub; Cindice), where CBC_MAC() is a predetermined construction function parameterized by an encryption key and plaintext data. The term "plaintext data" refers to data that is directly usable without requiring prior decryption. Furthermore, in the argument list of the CBC_MAC() function, the encryption key is placed first, before the data to be encrypted. Here, this CBC_MAC() function implements only a symmetric encryption algorithm. No asymmetric encryption algorithm is used. For example, in this embodiment, the CBC_MAC() function is a symmetric encryption function such as the symmetric encryption function known by the acronym AES ("Advanced Encryption Standard").

[0056] In the case of constructing the KCpub cryptogram, the encryption key is the Caes key, and the plaintext data consists of Kpub, Kindice, Cpub, and Cindice. The constructed KCpub cryptogram is therefore specific to terminal 16, as it depends on its Kpub identifier, and also specific to lock 10, as it depends on the Caes key and the Cpub identifier. The KCpub cryptogram thus constitutes an access authorization for a particular mobile terminal to a particular electronic lock. Consequently, server 50 constructs a KCpub cryptogram for each electronic lock that must be unlocked by terminal 16.

[0057] Each time a new KCpub cryptogram is constructed for the same mobile terminal and for the same electronic lock, the Kpr index associated with that mobile terminal and that electronic lock is incremented, for example, by 1 compared to its previous value.

[0058] Furthermore, if terminal 16 is programmed to replace a previous instance of terminal 16 which, for example, has been lost: an identifier Kpub identical to that of the lost terminal 16 is stored in its memory 42 so that the identifiers Kpub of the programmed terminal 16 and the lost terminal 16 are identical, and the index Kindex of the programmed terminal 16 is incremented by a predetermined step, for example equal to 1, with respect to the index Kindex of the lost terminal 16.

[0059] Finally, the Cpub identifier of lock 10, the KCpub cryptogram constructed by server 50 for lock 10, the incremented Kpr index and, possibly, the incremented Kindex are transmitted to station 60.

[0060] When terminal 16 is connected to programmer 90, station 60 in turn transmits this data to programmer 90, who then transmits it to terminal 16. Terminal 16 stores this data in a row of its table 140. If table 140 already contains a row for the identifier Cpub, the new data replaces the existing data in columns 144, 146, and 148. Otherwise, a new row is created in table 140 to store the received data associated with the identifier Cpub. If an incremented index Kindex is also transmitted to terminal 16, it replaces the previous index Kindex stored in memory 42.

[0061] Terminal 16 does not contain the Caes key. Therefore, the information in memory 42 is insufficient on its own to construct other KCpub cryptograms that would allow Terminal 16 to unlock other electronic locks in System 2. Consequently, even if the information in memory 42 is compromised, this does not compromise the security of System 2. Indeed, it is not possible to construct access authorizations to unlock other electronic locks from this information. Furthermore, simply copying the information from table 140 of Terminal 16 into memory 42 of another terminal does not allow for the creation of a duplicate of Terminal 16.Indeed, the Kpub identifier of this other terminal is then different from the Kpub identifier of terminal 16, which prevents unlocking an electronic lock using a KCpub cryptogram specifically built for terminal 16.

[0062] Phase 150 can be executed at any time and not only when a new mobile terminal is put into service.

[0063] In parallel, a phase 160 configuration for access authorization in an electronic lock can be executed. This phase 160 is executed, for example, if it is simpler to configure an electronic lock rather than configuring each of the mobile devices that need to be authorized to unlock that electronic lock.

[0064] Here, this phase 160 is described in the particular case where the lock 10 must be configured to be moved into its unlocked state by the terminal 16.

[0065] To do this, the user, using station 60, identifies the mobile terminal(s) of system 2 which are authorized to unlock lock 10. Then, he triggers the generation by server 50 of the access authorizations necessary to be recorded in table 112 of lock 10.

[0066] To this end, server 50 constructs a KKpub cryptogram by encrypting the following data using the Kaes key from terminal 16: the Kpub identifier of terminal 16, the Kindex of terminal 16, the Cpub identifier of lock 10, and the Cindex of lock 10.

[0067] In other words, the KKpub cryptogram is constructed using the following relation: KKpub = CBC_MAC(Kaes; Kpub; Kindice; Cpub; Cindice), where CBC_MAC() is the same function as that used to construct the KCpub cryptogram.

[0068] The resulting KKpub cryptogram is also specific to terminal 16, as it depends on the Kpub identifier and the Kaes key, and also specific to lock 10, as it depends on the Cpub identifier. The KKpub cryptogram therefore constitutes an access authorization for a particular terminal to a particular electronic lock. Server 50 thus constructs a KKpub cryptogram for each mobile terminal that needs to be authorized to unlock lock 10.

[0069] Each time a new KKpub cryptogram is constructed for a particular mobile terminal and for lock 10, the previous value of the index Cpr associated with that mobile terminal and that lock 10 is incremented by the same step as that used to increment the index Kpr.

[0070] The Kpub identifier of terminal 16, the constructed KKpub cryptogram, and the incremented Cpr index are transmitted to station 60 and then stored in the buffer 92 of programmer 90. Programmer 90 is then disconnected from station 60 and transported to lock 10. Its blade is then inserted into lock 10, and the data stored in its buffer 92 is recorded in table 112 of lock 10. This is similar to what has already been described for recording data in table 140: If the Cpub identifier is already contained in table 112, the transferred data is used to update the contents of columns 122, 124 and 126 already associated with this Cpub identifier, and otherwise, a new row is created in table 112 and the transferred data is recorded there.

[0071] The Kaes key is not contained in lock 10. Therefore, the information contained in lock 10 alone is insufficient to construct a KKpub cryptogram. Consequently, if the data contained in an electronic lock is compromised, this does not allow the creation of new access permissions to authorize other mobile devices to unlock lock 10.

[0072] Alternatively, the Kpub identifier of terminal 16, the constructed KKpub cryptogram, and the incremented Cpr index are transmitted from station 60 to programmer 90, and then from programmer 90 to a different mobile terminal than terminal 16. This other mobile terminal stores these access permissions for terminal 16 in its memory 42. Then, when this other mobile terminal is inserted into lock 10, it transmits the access permissions for terminal 16 to lock 10, and in response, lock 10 stores them in its table 112 as previously described. Thus, in this latter case, it is not programmer 90 that is used to transport the access permissions from terminal 16 to lock 10, but another mobile terminal of system 2.

[0073] During phase 160, it is possible to generate a generic invalidation command for all mobile terminals previously authorized to unlock lock 10. This generic invalidation command is transmitted to lock 10 via the same possible paths described above for transmitting access permissions to lock 10. When this generic invalidation command is received by lock 10, lock 10 increments its index Cindex stored in its memory 110 by a predetermined step. Simultaneously, the access permissions stored in the mobile terminals to unlock lock 10 remain unchanged. As explained later, the incrementing of the index Cindex in lock 10 then invalidates all mobile terminals previously programmed to unlock that lock 10.

[0074] Phase 160 can be executed at any time and not only at the time of commissioning of an electronic lock.

[0075] After executing at least one of phases 150 and 160, an access control phase 170 is executed. Here, phase 170 is described in the specific case where, beforehand: Phase 150 was executed to allow terminal 16 to unlock lock 10, and phase 160 was executed to allow terminal 16 to unlock lock 10. Thus, terminal 16 has access permissions to unlock lock 10 and lock 10 also has access permissions to be unlocked by terminal 16.

[0076] When a resident wishes to open door 6, in step 172, they insert the blade 38 of terminal 16 into the hole 101 of lock 10. The wired connections between terminal 16 and lock 10 are then established, and terminal 16 powers lock 10 and its microprocessor 108. In response to the power being supplied to lock 10, in step 174, the microprocessor 108 generates a value, hereafter referred to as the "nonce," which varies each time step 174 is executed. For example, this value is generated by random or pseudo-random selection.

[0077] Then, in step 176, the microprocessor 108 transmits an information frame, called here a T ini frame, to terminal 16 via the established wired links.

[0078] The Tini frame notably contains the following data in plain text: the identifier Cpub and the index Cindice stored in memory 110 of lock 10, and the nonce generated during step 174.

[0079] In response to the reception of the T ini frame, during a step 178, the microprocessor 40 of the terminal 16 searches in the table 140 stored in its memory 42 if it contains a KCpub cryptogram associated with the Cpub identifier contained in the received T ini frame.

[0080] If so, the microprocessor 40 proceeds to a step 180 of constructing and transmitting a T 180 frame ( figure 8 ). If not, the microprocessor 40 proceeds to a step 182 of constructing and transmitting a T 182 frame ( figure 9 ).

[0081] The T 180 frame contains D 180 data in plain text, possibly A 180 access permissions for other mobile terminals and an S 180 digital signature.

[0082] The D 180 data includes: the identifier Kpub and the index Kindice contained in memory 42 of terminal 16, the index Kpr and the access code Ov associated with the identifier Cpub found in table 140.

[0083] A180 authorizations correspond to access permissions intended to be recorded in table 112 of lock 10 to allow mobile terminals other than terminal 16 to unlock this lock 10. These A180 access permissions are recorded in terminal 16 during phase 160 as described previously. If terminal 16 does not have any A180 access permissions intended for lock 10, the T180 frame is then devoid of such A180 access permissions. Thus, subsequently, all A180 access permission processing operations are performed only if terminal 16 has access permissions to be recorded in table 112 of lock 10. Otherwise, the A180 authorization processing is omitted.

[0084] The S180 signature allows verification of the integrity and authenticity of the D180 data and A180 access permissions contained within the T180 frame. Here, "verifying integrity" means verifying that the data and access permissions within a frame have not been modified since the frame was transmitted by a mobile terminal. "Verifying authenticity" means verifying that a frame was indeed generated and transmitted by the mobile terminal claiming to have transmitted that information frame. The S180 signature is constructed from the D180 data, the A180 permissions, and the nonce exchanged during step 176.

[0085] The T 182 frame ( figure 9 ) also contains D 182 data in plain text and a digital signature S' 182. The D 182 data here includes in particular the Kpub identifier of the mobile terminal which emits the T 182 frame.

[0086] The S' 182 signature is constructed from the Kpub identifier contained in memory 42 of the mobile terminal and the nonce exchanged during step 176.

[0087] Step 180 begins with an operation 184 deriving a key KCpub1 from the cryptogram KCpub found in table 140. For this, the microprocessor 108 executes a predetermined key derivation function AES_CBC(). For example, in this mode of interaction, the AES_CBC() function only implements a symmetric encryption algorithm such as the algorithm known by the acronym AES (Advanced Encryption System). For example, here, the key KCpub1 is the result of encrypting the constant Ct pre-recorded in memory 42 by implementing the AES_CBC() function and using the cryptogram KCpub as the encryption key. Thus, the key KCpub1 is obtained using the following relationship: KCpub1 = AES_CBC(KCpub; Ct).

[0088] The AES_CBC() function executed is always the same at each execution of operation 184. Thus, the key KCpub1 derived from the cryptogram KCpub is always the same at each execution of phase 170 between terminal 16 and lock 10 as long as the cryptogram KCpub found in table 140 is the same.

[0089] Next, during operation 186, microprocessor 40 generates frame T 180. To do this, microprocessor 40 constructs signature S 180 using data D 180, access permissions A 180 to be transmitted to lock 10, and the nonce exchanged during step 176. To obtain this signature, a predetermined construction function parameterized by the key KCpub1 is implemented. This predetermined function involves symmetric encryption operations and no asymmetric encryption operations. Here, this construction function is the same CBC_MAC() function used to construct the KCpub and KKpub cryptograms. Thus, here, signature S 180 is obtained using the following relation: S 180 = CBC_MAC(KCpub1; Kpub; Kindice; Kpr; Ov; A 180; nonce) where: KCpub1 is the encryption key derived during operation 184, Kpub, Kindice, Kpr, Ov are the D 180 data associated in table 140 with the index Cpub found, the nonce is the one exchanged during step 176.

[0090] Next, the S 180 signature thus obtained is concatenated with the D 180 data in plain text and the A 180 access authorizations to form the T 180 frame.

[0091] During operation 188, the T 180 frame thus generated is transmitted to the lock 10 via the established wired connections. Step 180 is then completed.

[0092] In response to the reception of the T 180 frame, during a step 190, the microprocessor 108 of the lock 10 searches in its table 112 if it contains a line associated with the identifier Kpub contained in the data D 180 of the T 180 frame.

[0093] If not, the microprocessor 108 proceeds directly to step 192 of verifying the integrity and authenticity of the received T 180 frame.

[0094] Otherwise, during a step 194, the microprocessor 108 compares the index Kpr contained in the received data D 180 to the index Cpr associated by table 112 with the received identifier Kpub.

[0095] If the received Kpr index is greater than or equal to the Cpr index, the process continues directly through step 192. Conversely, if the received Kpr index is strictly less than the Cpr index recorded in table 112, during a step 196, the microprocessor 108 transmits a T 196 frame to terminal 16. In response to the reception of this T 196 frame, the microprocessor 40 of terminal 16 executes step 182 to construct and transmit the T 182 frame.

[0096] During step 192, microprocessor 108 verifies that the access authorization recorded in table 140 for lock 10 is a valid access authorization. To do this, it checks the integrity and authenticity of the received T 180 frame.

[0097] More specifically, the 108 microprocessor begins by constructing a cryptogram KCpub' using the following relation: KCpub' = CBC_MAC(Caes ; Kpub ; Kindice ; Cpub ; Cindice), where: CBC_MAC() is the same construction function as that implemented by server 50 during phase 150 to construct the cryptogram KCpub, Caes is the unique encryption key stored in memory 110 of lock 10, Kpub and Kindice are respectively the terminal identifier and terminal index contained in the received T 180 frame, Cpub and Cindice are, respectively, the lock identifier and lock index contained in memory 110 of lock 10.

[0098] Next, microprocessor 108 verifies that the constructed cryptogram KCpub' is identical to the cryptogram KCpub used to construct the received S 180 signature. To do this, microprocessor 108 derives a key KCpub1' from the cryptogram KCpub'. The key KCpub1' is calculated using the following relation: KCpub1' = AES_CBC(KCpub' ; Ct), where: AES_CBC() is the same key derivation function as that implemented during operation 184, KCpub' is the cryptogram that has just been constructed by the microprocessor 108, and Ct is the constant stored in memory 110.

[0099] Next, the microprocessor 108 constructs a signature S' 180 calculated using the following relation: S' 180 = CBC_MAC(KCpub1' ; Kpub ; Kindice ; Kpr ; Ov ; A 180 ; nonce), where: CBC_MAC() is the same construction function as that implemented during operation 186, KCpub1' is the key previously derived from the cryptogram KCpub', Kpub, Kindice, Kpr and Ov come from the D 180 data contained in the received T 180 frame, A 180 are the access permissions contained in the T 180 frame if it contains any, and "nonce" is the nonce transmitted by lock 10 to terminal 16 during step 176.

[0100] Finally, the microprocessor 108 compares the obtained signature S' 180 to the signature S 180 contained in the received frame T 180. If these two signatures, S' 180 and S 180, are equal, this means that the cryptograms KCpub and KCpub' are equal, and therefore that the identifiers Kpub, Cpub, Kindice, and Cindice used to construct them are identical. Furthermore, in this case, the integrity and authenticity of the frame T 180 are confirmed. When the integrity and authenticity of the frame T 180 are confirmed, the process continues with step 198, during which the A 180 access permissions are recorded in table 112. If the frame T 180 does not contain any A 180 access permissions, step 198 is omitted.

[0101] Then, in a step 200, the microprocessor 108 compares the index Kindex contained in the frame T 180 to the index Kindex recorded in the list 114 and associated with the identifier Kpub contained in the frame T 180.

[0102] If the index Kindex contained in frame T 180 is greater than the index Kindex contained in list 114, at a step 202, the microprocessor 108 replaces the index Kindex associated with the identifier Kpub in list 114 with the index Kindex contained in frame T 180.

[0103] If there is no Kindex associated with the received Kpub identifier in table 114, the microprocessor 108 adds, during step 202, a row in table 114. The added row contains the received Kpub identifier in column 130 and the received Kindex in column 132.

[0104] After step 202, the microprocessor 108 proceeds to a step 204 during which it tests the value of the Ov code contained in the T 180 frame.

[0105] If the value of the received Ov code is equal to the first value, then, at step 206, the microprocessor 108 generates the unlock command and transmits it to the actuator 104.

[0106] In response, during step 208, the actuator 104 moves the lock 10 into its unlocked state and the door 6 can be opened.

[0107] If the received Kindex index is equal to the Kindex index associated with the received Kpub identifier in table 114, then the process continues directly to step 204 without executing step 202.

[0108] If during step 192, the integrity and authenticity of the T 180 frame is not confirmed or if the received Kindex is less than the Kindex contained in table 114 or if during step 204, the microprocessor 108 determines that the value of the Ov code is different from the first value, then the execution of steps 206 and 208 is inhibited and the lock 10 remains in its locked state.

[0109] It is emphasized that the integrity and authenticity of the T 180 frame can only be confirmed if the KCpub cryptogram used by terminal 16 to construct the S 180 signature is indeed the one corresponding to terminal 16 and lock 10. This KCpub cryptogram depends on the Kpub identifier and the unique Caes key. Therefore, it cannot be used by any mobile terminal other than terminal 16 to unlock an electronic lock. Nor can it be used to unlock any electronic lock other than lock 10.

[0110] The integrity and authenticity of the T 180 frame is confirmed only if the index Cindex used to construct the KCpub cryptogram is equal to the index Cindex recorded in the lock 10. Thus, incrementing the index Cindex contained in the memory 110 of the lock 10, for example using the programmer 90, allows in a single operation to invalidate all mobile terminals which were previously authorized to unlock this lock.

[0111] To allow a new mobile terminal to unlock lock 10, simply program this new mobile terminal as described in phase 150. It is not necessary to also program lock 10 for this.

[0112] In this mode of communication, no asymmetric encryption algorithm is implemented to verify the integrity and authenticity of the T 180 frame. This limits the energy consumption required to do so.

[0113] Step 182 begins with an operation 220 to construct a cryptogram KKpub' by the microprocessor 42 of terminal 16. This cryptogram KKpub' is constructed by implementing the following relation: KKpub' = CBC_MAC(Kaes ; Kpub ; Kindice ; Cpub ; Cindice), where: Kaes, Kpub and Kindice are, respectively, the unique key Kaes, the identifier Kpub and the index Kindice stored in memory 42 of terminal 16, and Cpub and Cindice are, respectively, the lock identifier and the lock index contained in the T ini frame.

[0114] Next, during operation 222, the microprocessor 40 derives a key KKpub1' from the cryptogram KKpub' constructed during operation 220. For this, a predetermined key derivation function is executed. Here, the key KKpub1' is obtained using the following relation: KKpub1' = AES_CBC(KKpub' ; Ct), where: AES_CBC() is the same derivation function as that used in phase 160, and Ct is the constant stored in memory 42.

[0115] During operation 224, microprocessor 40 generates frame T 182. To do this, microprocessor 40 constructs the signature S' 182 from the data D 182, the nonce exchanged during step 176, and by implementing the CBC_MAC() function parameterized by the key KKpub1'. The signature S' 182 is therefore constructed by implementing the following relation: S' 182 = CBC_MAC(KKpub1' ; Kpub ; nonce).

[0116] Next, the constructed signature S' 182 is concatenated with the data D 182 to form the frame T 182.

[0117] During operation 226, the constructed T 182 frame is transmitted to lock 10 via the established wired links.

[0118] In response to the reception of frame T 182, during step 230, the microprocessor 108 searches table 112 to see if it contains a row associated with the identifier Kpub contained in the data D 182 of frame T 182. If not, the execution of steps 206 and 208 is inhibited and lock 10 remains in its locked state.

[0119] If a line in table 112 contains the same Kpub identifier as the one received, the microprocessor 108 proceeds to a step 232 of verifying the integrity and authenticity of the received T 182 frame.

[0120] In step 232, microprocessor 108 selects from table 112 the cryptogram KKpub associated with the received identifier Kpub. Then, microprocessor 108 derives a key KKpub1 from the selected cryptogram KKpub. For this, the following relationship is implemented: KKpub1 = AES_CBC(KKpub ; Ct), where: AES_CBC() is the same key derivation function as that implemented during operation 222, KKpub is the cryptogram associated with the identifier Kpub received in table 112, Ct is the constant stored in its memory 110.

[0121] The microprocessor 108 then constructs an S 182 signature by implementing the following relationship: S 182 = CBC_MAC(KKpub1 ; Kpub ; nonce), where: CBC_MAC() is the same constructor function as that implemented during operation 224, Kpub is the Kpub identifier contained in frame T 182, and "nonce" is the nonce exchanged during step 176.

[0122] Finally, the microprocessor 108 compares the obtained signature S 182 to the signature S' 182 contained in the received frame T 182. If the two signatures S 182 and S' 182 are equal, the integrity and authenticity of the frame T 182 is confirmed.

[0123] In this case, the process continues with a step 234 of testing the value of the Ov code associated with the Kpub identifier received in table 112.

[0124] If the value of the code Ov read in table 112 is equal to the first value, then the process continues by executing steps 206 and 208 to move the lock 10 into its unlocked state.

[0125] If, during step 232, the integrity and authenticity of the S 182 signature are not confirmed, or if the value of the Ov code associated with the received Kpub identifier differs from the initial value, the execution of steps 206 and 208 is inhibited. Thus, the Ov code allows a specific terminal to be invalidated without requiring reprogramming that terminal or incrementing the Cindex of that lock.

[0126] Thus, in this embodiment, if a mobile terminal does not have access authorization to unlock lock 10, but lock 10 contains access authorization for that mobile terminal in its table 112, lock 10 is moved to its unlocked state. Therefore, system 2 also allows the use of mobile terminals that have not been pre-programmed to open a particular electronic lock.

[0127] The use of Kpr and Cpr indices also ensures that when a mobile terminal and an electronic lock both have access permissions for each other, only the most recent access permission is consistently used. Chapter II: Variants: Variations of the access control system:

[0128] Door 6 is not necessarily a building entrance door. It could also be an access door to a room located inside the building, such as a garage or a garbage room.

[0129] Here, server 50 has been described as a single entity. However, server 50 can, in reality, consist of one or more redundant servers or several interconnected servers, each fulfilling a specific function to manage access permissions.

[0130] The administration station 60 can be implemented differently. For example, in another embodiment, station 60 is a smart phone, more commonly known as a "smartphone", which runs a system administration module 2. In this case, the human-machine interface is typically a touchscreen.

[0131] The system 2 administration and mobile terminal programming functions can be distributed across two different machines, one dedicated to system 2 administration and the other to mobile terminal programming. The machine dedicated to system 2 administration is not connected to programmer 90.

[0132] Alternatively, the electronic lock is powered, while the mobile terminal lacks a power source. For example, the electronic lock may have a battery or be connected to a mains power supply. In this case, the electronic lock powers the mobile terminal when it is presented to the lock. In another embodiment, either the mobile terminal or the electronic lock is equipped with a mechanism that converts the mechanical movement of the mobile terminal within the electronic lock into electrical energy. For example, such an energy harvesting mechanism is described in application EP2765264.

[0133] The electronic lock can be made of two mechanically separate parts: an unlocking mechanism and the control unit 106. The unlocking mechanism includes the actuator 104. In this case, the control unit 106 is connected to the actuator 104 by a wired connection. The unit 106 is, for example, identical to the one previously described except that it is housed outside the cylinder 100. For example, the unit 106 is housed inside an access control unit located near the door. Such an access control unit typically includes, at a minimum, a reader capable of establishing a short-range information transmission link with mobile terminals. In this case, for example, each mobile terminal has an RFID (Radio Frequency Identification) tag capable of establishing this short-range link.

[0134] Alternatively, programmer 90 can only be used to program a mobile terminal and not an electronic lock. In this case, the access permissions to be recorded in table 112 are systematically transferred to the lock 10 using mobile terminals, as described earlier in phase 160. Alternatively, or in addition, a separate programmer specifically for programming electronic locks is used when an electronic lock needs to be programmed directly. If programmer 90 can only be used to program a mobile terminal, the blade function of this programmer 90 can be omitted.

[0135] The short-range link between programmer 90 and terminal 16 is not necessarily a wired link. Alternatively, it is replaced by a wireless short-range link.

[0136] Other implementations of mobile terminals are possible. For example, the wired connections between the mobile terminal and the electronic lock used to transmit information frames can be replaced by a short-range wireless transmission link. For example, this short-range link is a Bluetooth-compliant link or uses Near Field Communication (NFC).

[0137] The mobile terminal can also be a mobile phone equipped with the microprocessor 40 and the memory 42. In this case, the memory 42 is preferably only accessible from the microprocessor 40. Generally, the mobile phone does not have a blade 38 and the information transmission link between the mobile phone and the electronic lock is a wireless link as described in the previous paragraph.

[0138] In this application, the memories of terminal 16 and lock 10 have been represented as a single memory block for simplicity. However, in practice, these memories may each be composed of several distinct memory blocks. Variations of the process:

[0139] The nonce can be generated by a method other than random or pseudo-random sampling. For example, during each execution of step 174, the nonce is simply incremented by a predetermined step, for example, from a combination of variable parameters of lock 10.

[0140] Selecting the KCpub cryptogram from the received Cpub identifier can be done in different ways. For example, terminal 16 selects the first KCpub cryptogram from table 140, and then steps 180, 190, and 192 are executed. If this does not unlock lock 10, these steps are repeated, this time using the KCpub program recorded in the next row of table 140. By repeating these operations, it is possible to find the KCpub cryptogram that unlocks lock 10 without first needing to receive the Kpub identifier for that electronic lock. If no KCpub cryptogram from table 140 unlocks the electronic lock, then step 194 is executed. Such a variant is more particularly suited to the case of access control systems in which the number of electronic locks is low, i.e. less than four or five or equal to one.In this variant, it is not necessary for the electronic lock to transmit its Cpub identifier to the mobile terminal in the T ini frame.

[0141] The same cryptogram selection method described in the previous paragraph can also be used to select the KKpub cryptogram from table 112 of the electronic lock without first receiving the Kpub identifier from the terminal. In this case, the transmission of the Kpub identifier to the electronic lock can be omitted.

[0142] Step 200 can be omitted in all embodiments where the cryptogram KCpub is constructed based on the index Kindice. Indeed, in this case, if the index Kindice contained in terminal 16 is different from that contained in list 114 of lock 10, then the cryptograms KCpub and KCpub' are different, and step 192 fails. Lock 10 therefore remains systematically locked.

[0143] Step 202 can be performed differently. For example, instead of replacing the old Kindex with the received incremented Kindex, microprocessor 108 adds a new line to list 114 and records the incremented Kindex associated with the Kpub identifier there. The line in list 114 containing the old Kindex is not deleted. In this case, during step 200, microprocessor 108 compares the Kindex contained in frame T 180 to the highest Kindex recorded in list 114 and associated with the Kpub identifier contained in frame T 180. Variations of information frames:

[0144] Alternatively, the nonce can be generated within the key. In this case, the T180 frame does not contain the nonce. Instead, the nonce is embedded in the plaintext D180 and D182 data of the T180 and T182 frames, respectively. However, this implementation is less advantageous than the one described in Chapter I. Indeed, in this case, a replay attack is possible by recording and then replaying the T180 or T182 frame generated by a valid terminal.

[0145] In another embodiment, the access code Ov is not used. It can therefore be omitted from the T 180 frame and from tables 112 and 140. In this case, step 204, which tests the value of this Ov code, is omitted, and after step 200 or 202, the process systematically continues with steps 206 and 208. Thus, as soon as the integrity and authenticity of the T 180 frame are confirmed and the received index Kindex is greater than or equal to that stored in list 114, the electronic lock systematically moves to its unlocked state. In this case, step 234 can also be omitted. In another variant, the Ov code is omitted only from table 112 of the locks or only from table 140 of the terminals. Thus, either of steps 204 and 234 can be retained.

[0146] The S 180 signature can be constructed using data other than that previously described, or conversely, using less data than previously described. For example, the D 180 data can include additional information such as information frame headers. The D 180 data can also include a current date and time. The current date and time are used, for example, to authorize the unlocking of lock 10 using terminal 16 only during certain time slots and only on certain days pre-recorded in lock 10.

[0147] In another simplified embodiment, the Kindex is not used and can therefore be omitted. In this case, list 114 is also omitted. In this simplified embodiment, it is not possible to disable a mobile terminal simply by introducing a new mobile terminal with the same Kpub identifier and an incremented Kindex into the electronic lock. Disabling a mobile terminal is typically implemented differently without using a Kindex. For example, disabling mobile terminals is managed using a blacklist stored in memory 110 containing the Kpub identifiers of all mobile terminals that are no longer authorized to unlock this electronic lock. Disabling mobile terminals can also be managed using a "whitelist" contained in memory 110 of each electronic lock.A whitelist is a list containing the Kpub identifiers of each mobile device authorized to unlock the electronic lock. Unlocking the electronic lock is then prohibited for any mobile device whose Kpub identifier does not belong to this whitelist.

[0148] The use of the Kpr and Cpr indices can also be omitted. In this case, steps 194 and 196 are omitted. Therefore, if a mobile terminal has an access authorization for lock 10 in its table 140, this access authorization is always used, even if table 112 for lock 10 also contains access authorizations for the same mobile terminal. This variant is also applicable in the specific case where the locks are never programmed, i.e., where step 160 is omitted.

[0149] Other implementations of the CBC_MAC() function are possible. In the previously described examples, it is not necessary to be able to decrypt the KCpub or KKpub cryptogram constructed to verify the integrity and authenticity of the transmitted data frames. Therefore, the CBC_MAC() function can be a one-way function, that is, a non-invertible function, parameterized by an encryption key. For example, the CBC_MAC() function first generates a digest or digital fingerprint (called a "hash") of the plaintext data to be signed using a predetermined hash function, and then this digest is encrypted using a symmetric encryption algorithm and an encryption key.

[0150] In an advantageous embodiment, the CBC_MAC() function is equivalent to the combination of a key derivation algorithm and an encryption algorithm. This is illustrated in the case of constructing the KCpub cryptogram. In this embodiment, to construct the KCpub cryptogram, the execution of the CBC_MAC() function first triggers the execution of the key derivation algorithm. Thus, an encryption key Caes1 is derived from the encryption key Caes. This encryption key Caes1 is different from the Caes key. For example, the Caes1 key is obtained using the following relation: Caes1 = AES_CBC(Caes; Ct). Then, the encryption algorithm parameterized by the Caes1 key is executed to obtain the KCpub cryptogram. Thus, in this embodiment, the cryptogram KCpub is obtained by encrypting the data Kpub, Kindice, Cpub and Cindice using the key Caes1 derived from the key Caes.In this case as well, the KCpub cryptogram is constructed using the Caes key. Similarly, this embodiment can be applied to the CBC_MAC() function used to construct the KKpub cryptogram. Thus, in this latter case, when the CBC_MAC() function is executed, a Kaes1 key is first derived from the Kaes key, and then the Kaes1 key is used as the encryption key for the Kpub, Kindice, Cpub, and Cindice data.

[0151] Alternatively, the encryption algorithm implemented during the execution of the CBC_MAC() function is an asymmetric encryption algorithm. Since the S180 and S182 signatures are not decrypted, even in this variant, the execution of a decryption algorithm using the public key corresponding to the private key used to construct the S180 and S182 signatures is not implemented.

[0152] The construction functions used to build KCpub, KKpub cryptograms and S180 and S182 signatures can be different from each other. However, preferably, each of these functions only involves symmetric encryption algorithms.

[0153] The variants described above in the particular case of the CBC_MAC() function are transposable to the AES_CBC() function.

[0154] Alternatively, the KCpub cryptogram is constructed without taking the Cpub identifier into account. In this case as well, the KCpub program only allows unlocking lock 10 because this cryptogram depends on the unique key Caes of this lock 10.

[0155] In another simplified embodiment, the key derivation operations for KCpub1 and KKpub1 simply consist of taking the keys KCpub1 and KKpub1 that are equivalent to the cryptograms KCpub and KKpub, respectively. In this case, the cryptograms KCpub and KKpub are directly used as the encryption keys to construct the S 180 and S 182 signatures. Variations in the use of the KCpub cryptogram :

[0156] The features, referred to herein as "feature A)," which provide the same advantages as those obtained using the access control method of application EP1321901 while enabling the use of symmetric encryption algorithms instead of asymmetric encryption algorithms, can be implemented independently of the other features of the access control methods described herein. For example, in a simplified embodiment, table 112 is omitted. In this case, no access authorization can be recorded in the electronic lock. Consequently, phase 160 and steps 182, 194, 196, 230, 232, and 234 are omitted. In such an embodiment, it is not possible to program an electronic lock to move in its unlocked state when a mobile terminal that has not been previously programmed to unlock that lock is presented.

[0157] Similarly, features A) are independent of the use of the previously described index Cindice. Thus, alternatively, the index Cindice is not used and can be omitted. In this case, it is not possible to invalidate, in a single operation, all the mobile terminals that were previously authorized to unlock this lock 10. In this embodiment, the cryptograms KCpub and KKpub are constructed without using the index Cindice. Variations in the use of the KKpub cryptogram

[0158] The features, referred to here as "features B)," which allow the use of both mobile terminals programmed to open lock 10 and mobile terminals not programmed to open lock 10, can be implemented independently of features A). In this case, the CBC_MAC() and / or AES_MAC() functions can be replaced by functions that perform the same role but employ asymmetric encryption algorithms. For example, the T 180 frame contains a cryptographic certificate. This cryptographic certificate contains the plaintext data D 180, the authorizations A 180, the nonce, and a digital signature S 180 of the data D 180, the authorizations A 180, and the nonce. In this case, the digital signature S 180 is typically constructed using an asymmetric encryption algorithm parameterized by a private key.Verifying the integrity and authenticity of the data contained in the T180 frame received by the electronic lock involves verifying the integrity and authenticity of the received cryptographic certificate using the public key corresponding to the private key used to sign that certificate. In this embodiment, verifying integrity and authenticity requires the execution of asymmetric encryption algorithms.

[0159] Characteristics B) can also be implemented independently of the use of the index Cindex or the use of a nonce.

[0160] Features B) can also be implemented with other methods to verify that the constructed and pre-recorded cryptograms are identical. For example, in a simplified embodiment, the S 180 signature is replaced by the KCpub cryptogram pre-recorded in terminal 16. In this simplified case, verifying that the KCpub cryptogram is identical to the constructed KCpub' cryptogram simply involves comparing the KCpub cryptogram contained in frame T 180 to the KCpub' cryptogram constructed by lock 10. Similarly, the S 182 signature is replaced by the KKpub' cryptogram constructed by terminal 16. Verifying that the KKpub' cryptogram is identical to the KKpub cryptogram then simply involves comparing the KKpub' cryptogram contained in frame T 182 to the KKpub cryptogram contained in table 112.In this case, preferably, a mechanism to avoid replay attacks and which does not use S 180 and S 182 signatures is also implemented.

[0161] Features B) can also be implemented in a system where access permissions are transmitted via a secure channel.

[0162] For the implementation of features B), the Kaes and Caes keys do not need to be unique. Thus, the Kaes key and / or the Caes key can be common to several mobile terminals and several electronic locks, respectively. Variations in the use of the Cindice index:

[0163] The use of the Cindice index described here to invalidate, in a single operation, all mobile terminals previously authorized to unlock the lock 10, can also be implemented independently of features A) and B). For example, the use of the Cindice index as described here can be implemented in access control processes where the verification of the integrity and authenticity of the transmitted Cindice index is performed differently than described here. For example, the use of the Cindice index can be implemented in the access control processes described in application EP1024239A1. In this latter case, the Cindice index is, for example, included in the access authorization aij generated by an access rights server and transmitted in encrypted form by the mobile terminal to the electronic lock.In request EP1024239A1, access authorization aij is encrypted with a key sj known only to the access rights server and the electronic locks, so that the mobile terminal cannot falsify access authorization aij. In the electronic lock, access authorization aij is decrypted with the key sj, and then the index Cindex contained in the decrypted access authorization aij is compared to a pre-recorded index Cindex stored in the electronic lock's memory. If the index Cindex contained in access authorization aij is less than the pre-recorded index Cindex, then the movement of the electronic lock to its unlocked state is systematically inhibited.

[0164] In the context of the access control process described in request EP1321901, the Cindice index transmitted by the mobile terminal can be incorporated into the cryptographic certificate transmitted by that mobile terminal to the electronic lock. The remaining operation is then explained in this text. Chapter III: Advantages of the described embodiments: Advantages of the process using the KCpub cryptogram :

[0165] Because the electronic lock reconstructs the KCpub cryptogram from its unique Caes key and the received Kpub identifier, the electronic lock does not need to be pre-programmed to move to its unlocked state when an authorized unlocking terminal is presented. In other words, the electronic lock does not need to be pre-programmed to be unlocked by mobile terminals.

[0166] Because the Caes key is unique for each electronic lock in System 2, if the information contained in a particular electronic lock is compromised, this does not compromise the security of System 2. In particular, it does not compromise the security of the other electronic locks in System 2. Indeed, the compromised information is unusable for unlocking other electronic locks in System 2.

[0167] Conversely, the fact that each mobile terminal does not contain the Caes key of the electronic lock it is authorized to unlock, but only the KCpub cryptogram corresponding to that electronic lock, guarantees that if this information is compromised, then this does not call into question the security of system 2 either. Indeed, since the KCpub cryptograms contained in the mobile terminals are, each, specific to an electronic lock and to that mobile terminal, they cannot be used by other mobile terminals to unlock other electronic locks.

[0168] The access control method described here allows an electronic lock to be unlocked even without any information transmission link to the access rights server. Furthermore, the fact that the nonce is used to construct the S180 signature makes the system robust against replay attacks. This method also does not use a secure channel to transmit access authorizations. Therefore, it is not necessary to generate session keys to create such a secure information transmission channel.

[0169] In fact, by implementing the teaching described here, a robust pairing is created between each mobile terminal and each electronic lock that this mobile terminal is capable of unlocking. Indeed, the KCpub cryptogram depends both on the Kpub identifier of this terminal and on the unique Caes key of the electronic lock to be unlocked. Thus, this cryptogram can only be used by this mobile terminal to unlock this electronic lock.

[0170] Transmitting the Cpub identifier to the mobile terminal allows the mobile terminal to quickly select the KCpub cryptogram to use.

[0171] Building the KCpub key based on the Cpub identifier makes it even more difficult to falsify the identity of the electronic lock to be unlocked.

[0172] If the mobile terminal does not contain a KCpub cryptogram to unlock the electronic lock, transmitting the T182 frame instead of the T180 frame will trigger the unlocking of the electronic lock, even if the mobile terminal was not explicitly programmed to do so. Furthermore, this result is robust against cases where the data in the mobile terminal or the electronic lock is compromised. This is because the KCpub cryptogram depends on both the terminal's unique Kaes key and the electronic lock's Cpub identifier. Therefore, the information contained in this mobile terminal and this lock cannot be used to establish valid access authorizations to unlock another electronic lock in the system or to authorize another mobile terminal to unlock this electronic lock.

[0173] Using the Kpub identifier to select the KKpub cryptogram stored in memory 110 of the electronic lock allows for quick selection of this KKpub identifier.

[0174] Using symmetric encryption algorithms instead of asymmetric ones simplifies the functions performed by the electronic lock and the mobile terminal to construct the S180 and S182 digital signatures. Consequently, the implemented functions are simpler and less energy-intensive. The power consumption of the mobile terminals and electronic locks is therefore reduced compared to the scenario where asymmetric encryption algorithms would be used.

[0175] The use of the Kindice index to construct the KCpub cryptogram makes the access control process robust against falsification attempts aimed at making a previously invalidated mobile terminal valid again.

[0176] Using an access code Ov for each lock a terminal is authorized to unlock avoids having to reprogram all of that terminal's access rights when only one of them is modified. For example, if terminal 16 is initially authorized to unlock a first and a second lock, then later, to prevent it from unlocking only the second lock, it is sufficient to modify the value of the access code Ov associated with the Cpub identifier of the second lock in its table 140, while leaving its index Kindex unchanged. When the access code Ov is not used, the only way to prevent terminal 16 from unlocking the second lock is to increment its index Kindex.Therefore, simultaneously, the KCpub cryptogram that allows it to unlock the first lock must also be immediately reconstructed using the new value of the Kindices index; otherwise, terminal 16 can no longer unlock the first lock. Furthermore, embedding the Ov code within the data used to construct the S 180 signature makes it difficult to falsify the value of this Ov code. Advantages of the process using the KKpub cryptogram :

[0177] The access control method described here offers the same advantages as that described in application EP1321901. In particular, it allows a mobile terminal to be programmed to move a specific electronic lock to its unlocked state. In this case, it is not necessary to program the electronic lock itself. Only the mobile terminal needs to be programmed to unlock it. Furthermore, the reverse operation is also possible. Each electronic lock can be programmed to move to its unlocked state when a specific, unprogrammed mobile terminal is presented to it. In this second case, it is not necessary to have programmed the mobile terminal beforehand. Only the electronic lock has been programmed.

[0178] The implementation of the reverse functionality is carried out here without compromising the security of the access control system. Indeed, the fact that the KKpub cryptogram is a function of the Kpub identifier of the mobile terminal makes it difficult to falsify the Kpub identifier transmitted in the T 182 frame.

[0179] The fact that the KKpub cryptogram used to verify the integrity and authenticity of the S 182 signature is a function of the terminal's Kpub identifier and the electronic lock's Cpub identifier prevents the security of system 2 from being compromised if the information contained in the lock's memory 110 is compromised. Indeed, the KKpub cryptograms stored in memory 110 cannot be used to unlock other electronic locks in system 2.

[0180] The fact that the KKpub cryptogram is constructed using the Kaes key which is not contained in the memory of lock 10 makes it impossible to construct new access authorizations for this lock 10 from the information contained solely in its memory 110.

[0181] The fact that the Kaes key is unique also guarantees that if the information contained in memory 42 of terminal 16 is compromised, the security of other electronic locks and mobile terminals is not affected. Indeed, the unique Kaes key only allows the construction of KKpub' cryptograms for that specific terminal 16 and not for other mobile terminals. Furthermore, if another electronic lock does not contain a KKpub cryptogram corresponding to terminal 16, knowing the unique Kaes key of terminal 16 is of no use in unlocking that other electronic lock.

[0182] The use of priority indices Kpr and Cpr ensures that when access permissions are recorded in both a mobile terminal and an electronic lock, the most recent access permissions are always used. This prevents the use of expired access permissions in such a situation.

[0183] Using a mobile terminal to transmit access permissions to an electronic lock avoids the need to connect that electronic lock to a long-distance information transmission network to program it.

[0184] The fact that the digital signatures transmitted from the mobile device to the electronic lock are dependent on a nonce makes the process robust against replay attacks. These replay attacks consist of recording and then replaying the data frames transmitted from the mobile device to the electronic lock. Furthermore, this robustness is achieved without the need to communicate with the electronic lock via a secure communication channel.

[0185] Establishing the identity of the cryptograms KKpub and KKpub' from the identity of the signatures S 182 and S' 182 makes it possible to establish the identity of these cryptograms without transmitting them between the mobile terminal and the electronic lock. Advantages of processes using the Cindex:

[0186] Using the Cindice index allows you to disable the unlocking of this electronic lock by all mobile devices that were previously authorized to unlock it in a single operation. This is achieved simply by incrementing the Cindice index stored in the electronic lock's memory (memory 110). When a large number of mobile devices are authorized to unlock an electronic lock, this method of disabling all mobile devices is much faster and simpler than if each mobile device had to be individually reprogrammed to prevent it from unlocking the electronic lock. Typically, such a procedure is particularly useful when an electronic lock is moved from one building to another.

[0187] Using the Cindice index to construct the KCpub cryptogram makes it easy to make the access control process very robust against attempts to falsify this Cindice index in a mobile terminal.

[0188] Using one of the mobile terminals to transmit the generic invalidation command to an electronic lock avoids having to connect that electronic lock to a long-distance information transmission network to program it.

Claims

1. A method for controlling access to buildings, the method comprising: - providing (148) a plurality of electronic locks, each of which is movable between: - a locked state in which it prevents access to the building, and - an unlocked state in which it permits access to the building, each electronic lock comprising a microprocessor and a memory containing a unique lock key (Caes) different from all the unique lock keys of the other electronic locks, and - providing (148) a plurality of mobile opening terminals, each of these mobile terminals comprising a microprocessor and a memory containing a terminal identifier (Kpub) that uniquely identifies that mobile terminal amongst the set of mobile terminals provided, - programming (150) at least one first of the provided mobile terminals to authorise it to move a first of the provided electronic locks into its unlocked state, this programming comprising the storage, in the memory of this first mobile terminal, of a first cryptogram (KCpub) constructed from the identifier (Kpub) of this first mobile terminal and by implementing a predetermined encryption algorithm parameterised by the unique key (Caes) of the first electronic lock, the unique key (Caes) of the first electronic lock not being stored in the memory of this first mobile terminal, such that it is not possible to construct the first cryptogram (KCpub) solely from the information contained in the memory of this first mobile terminal, the method comprising the following steps each time the first mobile terminal wishes to move the first electronic lock to its unlocked state: 1) the first mobile terminal and the first electronic lock exchange (176) a number, referred to as a "nonce", such that this nonce is known to both the first mobile terminal and the first electronic lock, this nonce varying each time the first mobile terminal wishes to switch the first electronic lock to its unlocked state, 2) the first mobile terminal constructs (186) a first digital signature (S180 ) from first data (D180 ) and by applying a predetermined encryption algorithm configured by an encryption key derived from the first cryptogram (KCpub) contained in the memory of this first mobile terminal, this first data containing at least the nonce exchanged with the first electronic lock, then 3) the first mobile terminal transmits (188) to the first electronic lock a first data frame (T180 ), this first data frame comprising its terminal identifier (Kpub) and the constructed first digital signature (S180 ), then 4) in response, the first electronic lock constructs (192) a second cryptogram (KCpub') from the terminal identifier (Kpub) contained in the first data frame and by employing the same predetermined encryption algorithm as that used to construct the first cryptogram (KCpub) parameterised by the unique key (Caes) contained in the memory of the first electronic lock, then 5) the first electronic lock verifies, using the exchanged nonce and the first digital signature received, that the second cryptogram (KCpub') constructed is identical to the first cryptogram (KCpub) used to construct the first digital signature (S180 ) contained in the first data frame, and in the event that the second cryptogram differs from the first cryptogram, the transition of the electronic lock from its locked state to its unlocked state is systematically prohibited.

2. A method according to claim 1, wherein: - the provision (148) of a plurality of electronic locks comprises the provision of a plurality of electronic locks, the memory of each of these electronic locks containing an identifier (Cpub) for that electronic lock which is different from all the identifiers of the other electronic locks provided, - the programming (150) of the first mobile terminal to authorise it to move the first electronic lock to its unlocked state further comprises storing, in the memory of said first terminal, the identifier (Cpub) of the first electronic lock associated with the first cryptogram, and - each time the first mobile terminal wishes to move the first electronic lock to its unlocked state, prior to step 2), the method comprises the following steps: - the first electronic lock transmits (176) to the first mobile terminal its lock identifier (Cpub) contained in its memory, - in response, the first mobile terminal searches (178) its memory to see if there is a first cryptogram associated with the transmitted lock identifier, then - when such a first cryptogram is found in the memory of the first terminal, the first mobile terminal uses this found first cryptogram to perform step 2) and, otherwise, step 2) is not performed.

3. A method according to claim 2, wherein: - during the programming (150) of the first mobile terminal to authorise it to move the first electronic lock to its unlocked state, the first cryptogram (KCpub) stored in its memory is additionally constructed from the identifier (Cpub) of the first electronic lock, and - during step 4), the second cryptogram (KCpub') is additionally constructed from the lock identifier contained in the memory of the first electronic lock.

4. A method according to claim 2 or 3, wherein: - the provision (150) of a plurality of mobile terminals comprises the provision of a plurality of mobile terminals, the memory of each of which comprises a unique terminal key (Kaes) that is different from all the unique terminal keys of the other mobile terminals provided, and - the method comprises programming (160) a second of the supplied electronic locks to authorise it to be moved to its unlocked state by the first mobile terminal, this programming comprising the storage, in the memory of the second electronic lock, of a third cryptogram (KKpub) constructed from the identifier (Cpub) of this second electronic lock and by implementing a predetermined encryption algorithm parameterised by the unique key (Kaes) of the first mobile terminal, the unique key (Kaes) of the first mobile terminal not being stored in the memory of the second electronic lock, so that it is not possible to construct the third cryptogram (KKpub) solely from the information contained in the memory of this second electronic lock, and - each time the first mobile terminal wishes to set the second electronic lock to its unlocked state, the method comprises the following steps: - the first mobile terminal and the second electronic lock exchange (176) a number, known as a "nonce", such that this nonce is known to both the first mobile terminal and the second electronic lock, this nonce varying each time the access control process is executed between the first mobile terminal and the second electronic lock, - the second electronic lock transmits (176) its lock identifier (Cpub) to the first mobile terminal, - in response, the first mobile terminal searches (178) its memory for a first cryptogram associated with the transmitted lock identifier, then - if no first cryptogram (KCpub) associated with the transmitted lock identifier is found in the memory of the first mobile terminal: - the first mobile terminal constructs (220) a fourth cryptogram (KKpub') from the (Cpub) transmitted by the second electronic lock and by using the same predetermined encryption algorithm as that used to construct the third cryptogram (KKpub) parameterised by the unique key (Kaes) contained in the memory of this first mobile terminal, then - the first mobile terminal constructs (224) a second digital signature (S182 ) from second data (D182 ) and by applying a predetermined encryption algorithm parameterised by an encryption key derived from the constructed fourth cryptogram (KKpub'), these second data containing at least the nonce exchanged with the second electronic lock, then - the first mobile terminal transmits (226) a second data frame (T182) to the second electronic lock, in place of the first data frame (T180), this second data frame containing the second digital signature that has been generated, and then - in response, the second electronic lock verifies, using the exchanged nonce and the second digital signature received, that the third cryptogram (KKpub) stored in its memory is identical to the fourth cryptogram (KKpub') used to construct the second digital signature contained in the second data frame; and in the event that the third cryptogram differs from the fourth cryptogram, the transition of the second electronic lock from its locked state to its unlocked state is systematically prohibited.

5. A method according to claim 4, wherein: - the programming (160) of the second electronic lock to authorise it to be moved to its unlocked state by the first mobile terminal further comprises storing, in the memory of the second electronic lock, the identifier (Kpub) of the first terminal associated with the third cryptogram (KKpub), and - the second information frame (T182) also contains the terminal identifier of the first mobile terminal, - in response to receiving the second information frame, the electronic lock searches (230) its memory for the third cryptogram (KKpub) associated with the terminal identifier contained in the second information frame, then - if such a third cryptogram is found, then the second electronic lock verifies that this third cryptogram found is identical to the fourth cryptogram and, in the contrary case where no third cryptogram is found, the transition of the second electronic lock from its locked state to its unlocked state is systematically prohibited.

6. A method according to any of the preceding claims, wherein the encryption algorithms used are symmetric encryption algorithms.

7. A method according to any one of the preceding claims, in which: - the method comprises storing (160) a lock index (Cindex) in the memory of the first electronic lock, - the method comprises programming (150) a plurality of first mobile terminals to authorise them to move the first electronic lock to its unlocked state; during this programming, the first cryptogram (KCpub) stored in the memory of each of these first terminals is additionally constructed from the lock index (Cindex) stored in the first electronic lock, and - during step 4), the first electronic lock constructs (192) the second cryptogram (KCpub') additionally from the lock index (Cindex) stored in its memory, and - after programming (150) the plurality of first mobile terminals to authorise them to move the first electronic lock to its unlocked state, the method comprises modifying (160) the lock index (Cindex) stored in the memory of the first electronic lock without modifying the first cryptograms stored in the first mobile terminals to prevent all of these first mobile terminals from moving said first electronic lock into its unlocked state.

8. A method according to any one of the preceding claims, wherein: - during the programming (150) of the first mobile terminal to authorise it to move the first electronic lock to its unlocked state, the first cryptogram (KCpub) stored in its memory is additionally constructed from a terminal index (Kindice) contained in the memory of that first terminal, and - the method comprises storing (202), in the memory of the first electronic lock, the terminal identifier (Kpub) of the first mobile terminal and the terminal index (Kindice) contained in the memory of said first mobile terminal associated with said terminal identifier, - during step 4), the first electronic lock constructs the second cryptogram (KCpub') additionally from the terminal index associated, in its memory, with the terminal identifier (Kpub) contained in the first data frame, and - after programming (150) the first mobile terminal to authorise it to move the first electronic lock to its unlocked state, the method comprises modifying (202), in the memory of the first electronic lock, of the sole terminal identifier associated with the terminal identifier (Kpub) of the first mobile terminal to prevent that first mobile terminal from moving the first electronic lock into its unlocked state.

9. A method according to any of the preceding claims, wherein: - the programming (150) of the first mobile terminal to authorise it to move the first electronic lock to its unlocked state further comprises storing the value of an access code (Ov) in the memory of said first terminal, the value of the access code being equal to a first value to indicate that the first mobile terminal is authorised to set the first electronic lock to its unlocked state and being different from this first value to indicate that the first mobile terminal is not authorised to set the first electronic lock to its unlocked state, - in step 2), the first digital signature (S180 ) is additionally constructed from the value of the access code contained in the memory of the first mobile terminal, - in step 3), the first data frame further contains the access code stored in the memory of the first mobile terminal, and, - after step 5), the electronic lock moves to its unlocked state only if the value of the access code contained in the first data frame is equal to the first value.

10. A building access control system comprising: - a plurality of electronic locks (10), each of which is movable between: - a locked state in which it denies access to the building, and - an unlocked state in which it permits access to the building, each electronic lock comprising a microprocessor (108) and a memory (110) containing a unique lock key (Caes) that is different from all the unique lock keys of the other electronic locks in the access control system, and - a plurality of mobile opening terminals (16), each of these mobile terminals comprising a microprocessor (40) and a memory (42) containing a terminal identifier (Kpub) that uniquely identifies that mobile terminal amongst all the mobile terminals of the access control system, at least a first of these mobile terminals (16) being authorised to move a first of the electronic locks into its unlocked state, the memory of this first mobile terminal containing, for this purpose, a first cryptogram (KCpub) constructed from the identifier (Kpub) of this first mobile terminal and by implementing a predetermined encryption algorithm parameterised by the unique key (Caes) of the first electronic lock, the unique key (Caes) of the first electronic lock not being stored in the memory of this first mobile terminal, such that it is not possible to construct the first cryptogram (KCpub) solely from the information contained in the memory of this first mobile terminal, the first mobile terminal (16) and the first electronic lock (10) being configured to perform the following steps each time the first mobile terminal wishes to move the first electronic lock to its unlocked state: 1) the first mobile terminal and the first electronic lock exchange a number, referred to as a "nonce", such that this nonce is known to both the first mobile terminal and the first electronic lock, this nonce varying each time the first mobile terminal wishes to move the first electronic lock to its unlocked state, 2) the first mobile terminal constructs a first digital signature (S180 ) from first data (D180 ) and by applying a predetermined encryption algorithm configured by an encryption key derived from the first cryptogram (KCpub) contained in the memory of this first mobile terminal, this first data containing at least the nonce exchanged with the first electronic lock, then 3) the first mobile terminal transmits to the first electronic lock a first data frame (T180 ), this first data frame comprising its terminal identifier (Kpub) and the constructed first digital signature (S180 ), then 4) in response, the first electronic lock generates (192) a second cryptogram (KCpub') from the terminal identifier (Kpub) contained in the first data frame and by applying the same predetermined encryption algorithm as that used to construct the first cryptogram (KCpub), parameterised by the unique key (Caes) contained in the memory of the first electronic lock, then 5) the first electronic lock verifies, using the exchanged nonce and the first digital signature received, that the second cryptogram (KCpub') constructed is identical to the first cryptogram (KCpub) used to construct the first digital signature (S180 ) contained in the first data frame, and in the event that the second cryptogram differs from the first cryptogram, the transition of the electronic lock from its locked state to its unlocked state is systematically prohibited.

11. Mobile terminal for implementing a building access control system in accordance with claim 10, wherein the mobile terminal comprises a microprocessor (40) and a memory (42) containing a terminal identifier (Kpub) which uniquely identifies this mobile terminal amongst all the mobile terminals of the access control system, said mobile terminal (16) being configured to be authorised to move a first electronic lock of the access control system to its unlocked state, the memory of said mobile terminal containing, for this purpose, a first cryptogram (KCpub) constructed from the identifier (Kpub) of said mobile terminal and by implementing a predetermined encryption algorithm parameterised by the unique key (Caes) of the first electronic lock, the unique key (Caes) of the first electronic lock not being stored in the memory of this mobile terminal, such that it is not possible to construct the first cryptogram (KCpub) solely from the information contained in the memory of this first mobile terminal, the mobile terminal (16) being configured to perform the following steps each time the mobile terminal wishes to move the first electronic lock to its unlocked state: 1) the mobile terminal and the first electronic lock exchange a number, referred to as a "nonce", such that this nonce is known to both the mobile terminal and the first electronic lock, this nonce varying each time the first mobile terminal wishes to move the first electronic lock to its unlocked state, 2) the mobile terminal constructs a first digital signature (S180 ) from first data (D180 ) and by applying a predetermined encryption algorithm configured by an encryption key derived from the first cryptogram (KCpub) contained in the memory of this first mobile terminal, these first data containing at least the nonce exchanged with the first electronic lock, then 3) the mobile terminal transmits to the first electronic lock a first data frame (T180 ), this first data frame containing its terminal identifier (Kpub) and the constructed first digital signature (S180 ).

12. A terminal according to claim 11, wherein the identifier of this mobile terminal is stored in a non-rewritable memory area.

13. First electronic lock for implementing a building access control system in accordance with claim 10, wherein the first electronic lock (10) is movable between: - a locked state in which it prevents access to the building, and - an unlocked state in which it permits access to the building, the electronic lock comprising a microprocessor (108) and a memory (110) containing a unique lock key (Caes) different from all the unique lock keys of the other electronic locks in the access control system, the first electronic lock (10) being configured to perform the following steps each time the first mobile terminal wishes to switch the first electronic lock to its unlocked state: - the first mobile terminal and the first electronic lock exchange a number, referred to as a "nonce", such that this nonce is known to both the first mobile terminal and the first electronic lock, this nonce varying each time the first mobile terminal wishes to switch the first electronic lock to its unlocked state, - in response to receiving the first data frame (T180 ), the first electronic lock constructs (192) a second cryptogram (KCpub') from the terminal identifier (Kpub) contained in the first data frame and by employing the same predetermined encryption algorithm as that employed to construct the first cryptogram (KCpub) parameterised by the unique key (Caes) contained in the memory of the first electronic lock, then - the first electronic lock verifies, using the exchanged nonce and the first digital signature received, that the second cryptogram (KCpub') constructed is identical to the first cryptogram (KCpub) used to construct the first digital signature (S180 ) contained in the first data frame; and in the event that the second cryptogram differs from the first cryptogram, the transition of the electronic lock from its locked state to its unlocked state is systematically prohibited.