Lock administration system

The present invention relates to a lock management system for electromechanical locks. In particular, the present invention relates to a self-powered lock.

Various types of electromechanical locks have been replaced by conventional mechanical locks. Electromechanical locks require an external power source, a battery inside the lock, a battery inside the key, or a means for generating power inside the lock to self-power the lock. Electronic locks offer many advantages over traditional locks. These provide better security and make key control or security tokens easier.

In addition, most electromechanical locks and / or keys and tokens are programmable. The lock can be programmed to accept different keys and reject others.

One issue associated with electromechanical and self-powered locks is lock and key programming. In many known electromechanical lock systems, the lock manufacturer delivers factory-programmed locks to end customers. The lock manufacturer has performed the desired programming of the locks belonging to the designated locking system.

<p> According to one feature of the present invention, a lock management system for self-powered locks is provided: which is connected to the Internet in a usable state and is configured to store information related to the lock system. One ASP (application service provider) server; generates shared secrets for encryption and decryption, and uses one token to generate and encrypt lock access data packets. Controlling that, forwarding those data packets to the ASP server using the public network, receiving encrypted state packets from the ASP server using the public network, controlling the decryption of the state packets, And with at least one customer module configured to send information about the decrypted state packet to the ASP server over the public network; data packets are received from the ASP server over the public network and their data. Includes at least one lock, which is configured to decrypt the packet and send one encrypted state packet to the ASP server over the public network.</p><p> Another feature of the invention provides a method for managing self-powered locking systems, which: One customer module controls the generation of shared secrets for encryption and decryption. Generate lock access data packets with security tokens; encrypt generated lock access data packets with tokens; ASP (Application Service Provider:) encrypted data packets application service provider) Transfer to the server using the public network; store the encrypted data packet in the ASP server; read the encrypted data packet from the server over the public network with one lock; Decrypt data packets in the lock; generate an encrypted state packet in the lock and forward the packet to the ASP server; read one state packet from the ASP server and state by the customer module Controls the decryption of packets; includes transferring information about decrypted state packets from the customer module to the ASP server.</p><p> According to another feature of the present invention, one customer module within a lock management system for self-powered locks is provided, which is connected to the Internet in a ready-to-use state and information related to the lock system. Includes one ASP (application service provider) server configured to store: Customer modules: Generate shared secrets for encryption and decryption, from key data and shared secrets Use one token to generate one unique (unique) key secret; use one security token to generate and encrypt lock access data packets; and use ASP servers and public networks It is configured to communicate.</p><p> According to yet another feature of the present invention, a lock within a lock management system for self-powered locks is provided, which is connected to the Internet in a usable state and provides information related to the lock system. Includes one ASP (application service provider) server configured to store; locks: receive data packets from the ASP server; decrypt the data packets and make the shared secret its It is configured to generate using data packet information, store its shared secrets, and send encrypted state packets to the ASP server.</p>

<p> The present invention has several features. The proposed solution allows flexible locking and key programming. The lock manufacturer or wholesaler maintains the ASP server that stores the lock system database. However, lock and key programming is performed by the end customer. Therefore, the lock manufacturer delivers the lock in its initial state, i.e., not belonging to any particular locking system. The initial lock does not store any sensitive security information.</p><p> In the proposed solution, these locks do not require a dedicated wired connection to the ASP server. Encrypted lock programming data is transferred to the lock over the public network, which may be a wired or wireless connection.</p><p> Some embodiments of the present invention are described below, with reference to the accompanying drawings, only as examples.</p>

<figref num="1">FIG. 1 illustrates an example of the structure of one lock management system.</figref><figref num="2">FIG. 2 illustrates keys and locks.</figref><figref num="3A">FIG. 3A is a flow chart illustrating an example in which a shared secret of a locking system is generated.</figref><figref num="3B">FIG. 3B is a flow diagram illustrating an embodiment in which additional system tokens are generated within the locking system.</figref><figref num="3C">FIG. 3C is a flow chart illustrating an embodiment in which the lock system shared secret is transferred into the lock.</figref><figref num="3D">FIG. 3D is a flow chart illustrating an example in which the key sharing secret is set to a new key.</figref><figref num="3E">FIG. 3E is a flow chart illustrating an example of unlocking a lock with a new key.</figref><figref num="4">FIG. 4 is a signal transmission diagram illustrating one embodiment of the present invention.</figref><figref num="5">FIG. 5 illustrates another example of a key and a lock.</figref>

The following examples are typical examples. This specification refers to "one", "one", and "some" examples in various places, but this is not necessarily the case for each of them. It does not mean that such references are made to the same one or more embodiments, or that the features apply only to a single embodiment. The characteristics of different embodiments may also be combined to provide different embodiments.

<p> With reference to FIG. 1, one example of the structure of a lock management system is illustrated. The system includes an application service provider (ASP) server 100 that is ready to connect to the Internet 104 and is configured to store information related to the locking system in database 102. The database 102 can be implemented with a removable mass storage device or a fixed mass storage device within the server, or can be another computer. Other implementation methods are also possible. Typically, the lock system manufacturer or lock system wholesaler maintains the ASP server 100. The database maintains the data on the locks and keys that belong to the locking system. This data includes, for example, information about lock and key identifiers, key holders, lock and key status and access rights.</p><p> The system also includes a customer module 110. The customer module is customer software that operates in the customer terminal 108 on the customer premises. Typically, the customer terminal 108 is a personal computer or corresponding processing unit connected to the Internet 104 through a wired or wireless connection 106.</p><p> The realization of the customer module 110 will change depending on the customer terminal design. The customer module consists of program instructions coded in a program language, which is a high-level program language such as C, Java®, or a low-level program language such as a machine language or assembler.</p><p> Customer module 110 is configured to manage information about the locking system. For example, the customer module generates a shared secret for encryption and decryption, and uses one security token to generate and encrypt lock access data packets.</p><p> The customer module is connected 112 to a first device 114 configured to connect with the key 118 and the system token 120. The connection 112 between the customer module and the first device is realized by a wired or wireless connection. This connection is made possible by USB, Bluetooth, infrared or other known wireless technologies.</p><p> The first device 114 includes an electronic circuit 116, a key 118, and a container for token 120. The electronic circuit 116 includes a processor, a memory for storing data, and software for the processor. Electronic circuits are configured to perform calculations on locking data and transfer information between customer modules, keys and system tokens. The first device 114 and the customer terminal 108 provide a platform for the customer module 110 and the key 118 and the system token 120 communication. The customer module 110 and ASP server 100 store the shared secrets of the lock system, encrypt and decrypt lock access data packets, and authenticate user access within the lock system. -Communicate with token 120.</p><p> The lock management system also includes a second customer module 126. The second customer module 126 is customer software that operates in the customer terminal 124. The customer terminal 124 is a personal computer, a personal data assistant (pda), or a mobile phone 122 connected to the Internet 104. The second customer module 126 is realized in the same manner as the customer module 110.</p><p> The second customer module 126 is connected 128 to a second device 130 configured to connect with the key 134 and the system token 136. The connection 128 between the second customer module and the second device is realized by a wired or wireless connection. This connection is made possible by USB, Bluetooth®, infrared or other known wireless technology. In addition, the second device has a connection 138 to the lock 140. The connection is wired or wireless. For example, a wired connection is realized by a one-wire bus connection. The wired connection powers the self-powered lock. Wireless connections are made with known wireless protocols.</p><p> The second device 130 and the customer terminal 124 store the shared secret of the locking system for the customer module 126, the key 134, the system token 136 and the lock 140, and encrypt and decrypt the lock access data packet. It also provides a communication platform for authenticating user access within the locking system.</p><p> In one embodiment, the first device and the second device are the same device, respectively.</p><p> In one embodiment, the user of customer module 110 or 126 establishes a session between customer module and ASP server 100 by logging in to ASP server 100. The customer module contacts the ASP server and checks if there is an updated version of the available module. If so, the updated version will be downloaded and installed on the customer's device. When the desired locking system management operation is initiated or performed, the session is terminated by logging out of the ASP server.</p><p> FIG. 2 illustrates the key 118 and the lock 140. The lock 140 is configured to read access data from the key 118 and align the data with predetermined criteria. Key 118 is configured to store access data and perform encryption and decryption calculations. This electronic circuit is, for example, Maxim Integrated Products' iButton® (www.ibutton.com), and such electronic circuits are read using the 1-Wire® protocol. This electronic circuit is installed, for example, in a key or token, but it can also be installed in other suitable equipment or objects. The only thing needed is that the lock can read the data from this electronic circuit. Data transfer from the key to the lock 140 can be performed by any suitable wired or wireless communication technique. In self-powered locks, the amount of energy generated constrains the technology used. Magnetic stripe technology or smart card technology is also used in the key. Wireless technology is, for example, RFID (Radio-frequency identification: Radio-frequency). identification) technology, or mobile phone technology included. The key includes a transponder, RF tag, or any other suitable memory type that can store data.</p><p> The data read from the key is used for authentication by matching the data against predetermined criteria. This certification is SHA-1 (Secure Hash Algorithm: Secure Hash) designed by the National Security Agency (NSA). It is executed by the Algorithm) function. In SHA-1, a compressed digital representation (known as a message digest) is calculated from a given input data sequence (known as a message). This message digest has a high probability of being unique to that message. SHA-1 is called "safe", but it is computationally expensive to find the message that corresponds to a given message digest, or to find two different messages that produce the same message digest for a given algorithm. Because it is infeasible. Every change to a message has a very high probability of resulting in a different message digest. If more security is needed, another hash function within the SHA group (SHA-224, SHA-256, SHA-384 and SHA-512), each with a longer number of digits, collectively as SHA-2. Known ones can be used. Of course, any suitable authentication technique can be used to authenticate the data read from an external source. The choice of certification technique depends on the desired level of safety for the lock 140 and possibly the power consumption allowed to be used for certification (especially certification in user-powered electromechanical locks).</p><p> FIG. 3A is a flow diagram illustrating an embodiment in which a locked system shared secret (SS) is generated and a first system token is created in the locked system. This locking system shared secret is used in the encryption and decryption of lock access data. The system token includes the electronic circuit described above, which is used to generate and store the locking system shared secret within the first device 114. This system token is a special token that is not used as a key, but is used to program the keys and locks of the locking system. Creating a system token is typically the first step in programming locks and keys for a new locking system. A locking system will have multiple system tokens, all of which store the same locking system shared secret.</p><p> Customer module 110 is responsible for controlling locking system shared confidentiality and system token generation. Since the customer module exists in the customer terminal, this process is performed in the customer's facility provided that the customer module is connected to the Internet and the device 114 is connected to the customer terminal 108. In one embodiment, the customer module 110 controls device 114 to perform some or all of the work they are assigned to the customer module below. The lock manufacturer or wholesaler plays no role in this process other than maintaining the ASP server 100.</p><p> This process is started in step 300 when the user sets an empty token 120 in the first device 114.</p><p> At step 302, the customer module 110 requests the user to type in seed 1. Seed 1 is typically an alphanumeric string of 10-20 characters. Seed 1 is not stored in the system. The user must remember.</p><p> In step 304, the customer module 110 uses a random number generator to generate seed 2. Seed 2 is typically a list of numbers 10 to 20 bytes long. Each byte can have any value between 0 and 255.</p><p> In step 306, customer module 110 uses a random number generator to generate seed 3. Seed 3 is typically 10 to 20 bytes long. Each byte can have any value between 0 and 255.</p><p> In step 308, customer module 110 sends seeds 1-3 to token 120. The token receives these seeds and generates one SHA-1 hash used in the locking system shared secret. Token 120 stores the shared secret in its hidden write-only memory. This shared secret is neither returned to the customer module nor revealed to the user.</p><p> This hash can also be generated using some other cryptographic hash function, as those skilled in the art are familiar with. SHA-1 is used herein as merely an example.</p><p> In one embodiment, the customer module 110 is configured to calculate a hash used as a shared secret and send that hash to token 120, which stores the hash.</p><p> In step 310, the customer module 110 stores the seed 3 in the token 120.</p><p> In step 312, customer module 110 transfers seed 2 to the locking system database 102 maintained by the ASP server. This transfer is encrypted, for example, with SSL (Secure Sockets Layer).</p><p> In step 314, the customer module 110 registers the token 120 as a system token in the locking system database 102. Each token has a unique serial number and is stored in database 102. This storage is encrypted with, for example, SSL (Secure Sockets Layer).</p><p> This processing procedure ends at 316.</p><p> FIG. 3B is a flow diagram illustrating one embodiment in which additional system tokens are created within the locking system. This locking system already has at least one system token created using the procedure described in Figure 3A. Customer module 110 is responsible for controlling the generation of additional system tokens. Since the customer module exists in the customer terminal, it is carried out in the customer's facility provided that the customer module has an internet connection and the device 114 is connected to the customer terminal 108. In one embodiment, the customer module 110 controls device 114 to perform some or all of the work they are assigned to the customer module below. The lock manufacturer or wholesaler plays no role in this process other than maintaining the ASP server 100.</p><p> This processing procedure is initiated when the user has one of the existing system tokens 120 installed in device 114.</p><p> In step 322, customer module 110 requests the user to type in seed 1. Seed 1 must be exactly the same as it was typed in when generating the first system token 120.</p><p> In step 324, the customer module 110 lock system database 102 is contacted via the Internet and the seed 2 is read from the database 102.</p><p> In step 326, customer module 110 reads seed 3 from the existing system token 120 installed in device 114.</p><p> In step 328, customer module 110 uses seeds 1-3 to generate one SHA-1 hash.</p><p> At step 330, the customer module 110 validates its hash using the existing system token 120.</p><p> In step 332, the verification result is analyzed. If the validation fails, it is probably because the user has typed in the incorrect seed 1, and the process is either canceled or restarted at step 322.</p><p> Otherwise, processing continues in step 334, where the customer module asks the user to remove the existing system token 120 from device 114 and set one empty token 121 in device 114. To request.</p><p> In step 336, customer module 110 stores seed 3 in a new token 121.</p><p> In step 338, customer module 110 sends seeds 1 and 2 to token 120. This token receives these seeds and uses seeds 1-3 to generate one SHA-1 hash. This generated hash is a locking system shared secret and is identical to that stored in the first system token 120. The token stores this hash as a shared secret in its hidden write-only memory.</p><p> In step 340, customer module 110 registers a new system token 121 in the lock system database 102. This transfer is encrypted, for example, with SSL (Secure Sockets Layer).</p><p> This processing procedure ends at 342.</p><p> FIG. 3C is a flow diagram illustrating an embodiment in which the locking system shared secret is transferred into one lock.</p><p> This processing procedure is initiated in step 350 if the user has an existing system token 120 installed in device 114. Again, customer module 110 is responsible for the initial steps. Since the customer module 110 exists in the customer terminal 108, this process is performed in the customer's facility provided that the customer module 110 is connected to the Internet and the device 114 is connected to the customer terminal 108. .. Initial steps 350-366 should be performed at a site other than where the lock is located. The lock manufacturer or wholesaler has no other role in this process than to maintain the ASP server 100. In one embodiment, the customer module 110 controls device 114 to perform some or all of the work they are assigned to the customer module below.</p><p> In step 352, customer module 110 asks the user to type in seed 1. Seed 1 must be exactly the same as it was typed in when generating the first system token 120.</p><p> In step 354, the customer module 110 contacts the lock system database 102 via the Internet and reads the seed 2 from the database 102.</p><p> In step 356, customer module 110 reads seed 3 from system token 120 installed in device 114.</p><p> In step 358, customer module 110 uses seeds 1-3 to generate one SHA-1 hash. This hash corresponds to the shared secret of the locking system.</p><p> In step 360, the customer module 110 verifies the hash against the shared secret stored in the system token 120 installed in device 114.</p><p> In step 362, the verification result is analyzed. If that validation fails, it is probably because the user has typed in the incorrect seed 1, and this procedure is either canceled or restarted at step 332.</p><p> If not, this process continues in step 364, where seeds 1-3 are encrypted and stored in the system token as a programming job for the lock.</p><p> In step 366, the system token 120 is removed from the device 114 connected to the customer module 110.</p><p> The remaining steps of this processing procedure are performed at the site where the lock is installed. The customer terminal 124 includes a second customer module 126. The customer terminal may be a personal computer, a personal digital assistant (pda), a smart phone or an equivalent device. The second device 130 is connected to the customer terminal and the second customer module, which also has a connection to the lock 140.</p><p> In step 368, the system token 120, which is illustrated as token 132 in FIG. 1, is inserted into device 130 connected to lock 140.</p><p> In step 370, lock 140 reads one programming job from system token 120 and decrypts seeds 1-3 to generate one SHA-1 hash.</p><p> In step 372, the lock 140 verifies the hash against the shared secret stored in the system token 120 installed inside the device 130.</p><p> At step 374, the verification results are analyzed.</p><p> If the verification fails, lock 140 sets an error and does not set the locking system shared secret in step 378.</p><p> If the verification is successful, the shared secret is stored in lock 140 in step 378.</p><p> The processing procedure ends at step 376 or 378.</p><p> Steps 368-378 are repeated on several locks. Locking system It is possible to transfer shared secrets to several locks in the same initial step.</p><p> FIG. 3D is a flow diagram illustrating an example in which a key sharing secret is set on a new key. Customer module 110 is responsible for controlling the generation of shared secrets. Because the client module is present in the customer terminal, this processing is is connected to the Internet the customer module, device 114 to be connected to the customer terminal 108 under the condition mentioned, carried out in the customer's facility. The lock manufacturer or wholesaler plays no role in this process other than maintaining the ASP server 100. In one embodiment, the customer module 110 controls device 114 to perform some or all of the work they are assigned to the customer module below.</p><p> This processing procedure is initiated in step 380 when the new key 118 and the existing system token 120 are connected in device 114.</p><p> In step 382, the customer module 110 reads the key data from the key 118 and sends it to the system token 120. This key data should include the key serial number.</p><p> In step 384, the system token 120 uses the key data and the locking system shared secret to calculate the key shared secret.</p><p> In step 386, the customer module 110 sets its key sharing secret to the new key 118.</p><p> In step 387, the customer module 110 registers its new key 118 in the key system database 102. This transfer is encrypted, for example, with SSL (Secure Sockets Layer).</p><p> This processing procedure ends at 388.</p><p> In addition to the above, additional access data may be programmed into the lock system key. In one embodiment, the key stores a data structure that includes a key identifier, key sharing secrets, and access group data. Each key has a unique identifier ID, which is used to identify the key. Access group data contains one or more access groups to which the key belongs.</p><p> In one embodiment, one key belongs to a lock in one access group that is allowed access to it, or the key has a key identification ID that is allowed access to it. , You can unlock it.</p><p> Access groups greatly enhance key organization. One key is given multiple access groups to allow access to different locations. For example, the same key gives access to the apartment (access group 1), basement (access group 2), garage (access group 3), and empty bottle storage (access group 4). Therefore, one user gives the waste collector one key, including only Access Group 4. Therefore, the vendor is given access to the empty bottle yard, but the key is not authorized to access another part of the building.</p><p> FIG. 3E is a flow diagram illustrating one embodiment when the lock 140 is unlocked with the key 118.</p><p> This processing procedure begins at step 390 when the user inserts the key 118 into the lock 140. At this stage, the self-powered lock has its key inserted into the lock, so that power is generated from the movement of the key. Instead, the lock may contain batteries.</p><p> In step 391, lock 140 reads key data and one hash from key 118.</p><p> In step 392, the lock 140 uses the key data and the locking system shared secret within the lock to calculate one SHA-1 hash.</p><p> In step 393, the lock 140 verifies the hash calculated on the lock against the hash read from the key 118.</p><p> At step 394, the verification results are analyzed.</p><p> If the verification fails in step 399, the lock 140 sets an error and the process ends without unlocking.</p><p> If the verification is successful, the lock 140 verifies its key access data in step 396.</p><p> At step 397, the verification results are analyzed. This key access data contains information about possible access groups to which the key belongs. The lock checks that the access group to which the key belongs matches the access group that is programmed to unlock the lock.</p><p> If the verification fails, lock 140 sets an error and does not unlock. This is done in step 399.</p><p> If the verification is successful, the lock 140 is unlocked in step 398.</p><p> The processing procedure ends at step 398 or 399.</p><p> FIG. 4 illustrates one example when the access right to the lock 140 is changed by the user using the customer module 110. Customer module 110 is responsible for controlling the initial part of this permission change. Since the customer module resides in the customer terminal 108, this processing procedure is performed within the customer's facility provided that the customer module has an internet connection. Prior to the initiation of this processing procedure, the system token 120 is installed in device 114, which is connected to customer terminal 108 and customer module 110. In addition, the customer module logs in to ASP server 100.</p><p> The ASP server maintains database 102, which stores information about locking system locks, keys, and access rights. However, the access rights are not changed by the ASP server. To change the access right, you need to use the system token connected to the customer module via customer modules 110, 126 and devices 114, 130.</p><p> In one embodiment, the customer module provides the user of the system with an interface for changing access rights and programming locks and keys. Customer module 110 is configured to receive new lock access data from the user. Upon receiving such data, the customer module 110 sends a "Program Lock" message 402 to the database 102 maintained by the ASP server 100.</p><p> The ASP server 100 stores the received data in the database 102 and sends the modified lock access data back to the customer module 110 as a Send Job message 404. Customer module 110 receives the message and sends the data as Crypt Job message 406 to system token 120 connected to device 114. The system token 120 encrypts the access data with the lock system shared secret and sends the encrypted lock access data to the customer module 110 as a Send Crypted Job message 408. The customer module receives the encrypted data and sends it to the ASP server 100 as a Send Crypted Job message 410. ASP server 100 puts that data into a work queue (work) that is part of database 102. Install in queue) 400. Work queue 400 is a list of encrypted access data messages that will later be transferred to the lock. Customer module 110 logs out of ASP server 100.</p><p> The remaining steps of this procedure are performed in the field where the lock is installed. First, the user logs in to the ASP server 100 from the customer module 126. At the user's command, the customer module contacts the ASP server and selects one job to be programmed for the lock from work queue 400 with message 412. The work queue 400 responds by sending encrypted lock access data in message 414. The customer module 126 receives the job and stores it in the memory of the customer terminal 124. The lock access data contained in the job data is encrypted, and storing the data in the customer terminal 124 is not a safety hazard.</p><p> The system token 136 is then installed in device 130. A connection is established between device 130 and customer terminal 124 and customer module 126. The customer module is configured to send encrypted lock access data 416 to system token 136 when it receives a "Program Lock" instruction from the user. The user connects the device 130 as programmed into the lock 140. If the lock 140 detects that a connection has been established with the device 130, the lock is configured to request lock access data from system token 136 418. In one embodiment, the lock is configured to authenticate the system token before requesting that data.</p><p> System token 136 responds by sending encrypted data 420. The lock 140 decrypts the data and verifies its signature using the shared secret stored in the lock. If the data is valid, the lock 140 stores the data, sends an encrypted acknowledgment message 422 containing the lock programming state to system token 136, and the program for access data for the lock is complete. Is shown. If the data is not valid, the lock 140 ignores the data and sends a negative confirmation 422 to system token 136, indicating that the lock program has failed. In one embodiment, device 130 is configured to visually indicate to the user the success of lock programming, eg, a green or red light emitting diode.</p><p> System token 136 sends an encrypted lock programming state 424 to customer module 126. This customer module 126 sends an encrypted lock programming state 426 to work queue 400.</p><p> This lock programming state remains in the work queue 400 until the customer module connected to the system token 120 establishes a session with the ASP server 100. The customer module should be configured to check work queue 400 when connected to ASP server 100. In response to inquiry message 428, ASP server 100 sends the encrypted lock programming status to customer module 110 430.</p><p> Upon receiving the encrypted state message 430, the customer module 110 sends the message to the system token 120432, which decrypts the data and sends the decrypted data 434 to the customer module 110. Respond by. The customer module sends its data 436, including the lock 140 state, to the ASP server 100, which stores the lock state in database 102.</p><p> The processing procedure described in connection with Figure 3C installs the locking system shared secret on a single lock. The lock is in its initial state before the locking system shared secret is installed. The initial state lock does not belong to any locking system. It is not configured to authenticate any key, nor to verify key access data. Locking system shared secrets should also be removed from a single key in a procedure similar to the processing procedure in Figure 3C. In one embodiment, the customer module 110 is configured to generate a lock access data packet containing an instruction to return the key to its initial state. After the shared secret is uninstalled, the lock returns to its initial state and can be reused in another locking system without any safety risk. Locking system shared Locks that do not have confidentiality do not contain information that requires safety precautions.</p><p> Locking System When a shared secret is installed inside a lock using the processing procedure in Figure 3C, the lock is a member of that locking system. Only the key belonging to the locking system can unlock it. However, the lock does not verify any additional access data. This state of the lock is called the commissioned state.</p><p> The locking system shared secret is generated by the system token 120 or customer module 110 in device 114 as described in FIG. 3A, based on the seed given by the user. The locking system shared secret is stored in the write-only memory of the system token.</p><p> Locks belonging to one system managed by the described lock management system have the ability to calculate the locking system shared secret as a system token. The keys have a unique identifier for each key and a unique secret generated from the locking system shared secret. The lock is configured to generate a key secret based on the unique identifier read from the key and the lock system shared secret stored within the lock.</p><p> Once the lock access group is installed inside the lock using the processing procedure described in Figure 4, the lock can authenticate the key and verify the key access data. Key access data validation is further described in European Patent Specification 07112675, which is incorporated herein by reference.</p><p> FIG. 5 illustrates an example of a key 118 and a lock 140. In the example of FIG. 5, the key 118 includes a contact array 502 and an electronic circuit 500 connected to a key frame. The electronic circuit 500 may include a memory unit. The electromechanical lock 140 in FIG. 1 is a self-powered lock. The lock 140 includes a power transfer mechanism 504, which converts mechanical energy from the user into a generator 506 and powers the electronic circuit 508 when the key 118 is inserted into the lock 140. In this example, the electronic circuit 508 is configured to communicate with the electronic circuit 500 of the key through the contact array 510 and the key array 502. This communication is achieved by wireless connection or physical conduction.</p><p> The electronic circuit 508 is configured to read key data from the electronic circuit 500 of the key 118 when the key is inserted. The electronic circuit 508 is further configured to authenticate the key and verify the access data as described above. The electronic circuit includes a processor and a memory unit for storing data as well as software required for the processor. The software is configured to perform the processing steps described above for locking system shared confidentiality, access data updates, and key authentication.</p><p> The lock of FIG. 5 further includes an actuating device 512 configured to mechanically set the lock into an unlockable state upon receiving an unlock command. The actuator is powered by the power produced by the generator 506. The actuating device 512 is mechanically set to a locked state, but a detailed description of this would not be necessary to articulate this embodiment.</p><p> When the actuator 512 mechanically sets the lock into an unlockable state, for example, the bolt mechanism 514 is moved by rotating the key 118. The required mechanical force is also generated by the user rotating the door handle or knob (not shown in FIG. 5). Other suitable rotation mechanisms can be used as well.</p><p> The above steps and related functions are not in absolute temporal order, and several steps can be performed simultaneously or in a different order than specified. Other functions can also be performed between or within steps. Some steps or parts of steps can also be omitted or replaced with corresponding steps or parts of steps.</p><p> As will be apparent to those skilled in the art, with the advancement of technology, the concept of the present invention can be realized in various ways. The present invention and examples thereof are not limited to the above examples, but are within the scope of claims.</p>