FIELD OF THE INVENTION The present invention relates to a method for operating a door lock by encrypted wireless signals.

BACKGROUND OF THE INVENTION

In recent times, it has become customary that door locks in cars are operated by a wireless remote control, typically called key fob. This implies the risk, however, that the signal is read by electronic receivers operated by unauthorised persons, so called "man-in-the-middle", who later use the read signal to open the car in the attempt of theft; this unauthorised action of reading the signal from the remote control is typically called "sniffing". Car manufacturers have tried to improve the situation by encryption of signals.

Also, door locks of private homes are at risk to be opened by unauthorised persons in the same way as described above, especially if the signal is not encrypted. However, encryption itself is not sufficient for a safe and reliable operation, as the following example shows.

A system for operating a door lock with encrypted signals is disclosed in International patent application WO2002/100040 by Isotale assigned to ELISA Communication OYJ. A terminal, such as a mobile telephone, is used as an intermediary between a lock and a central computer. In order for the lock to open, upon request from the terminal, an encrypted code is generated either by the lock or by the server and transmitted between the lock and the server via the mobile telephone, and the server performs an au- thorisation control and sends it to the lock via the mobile telephone. Thus, all operation is under the supervision of the central server. The telephone is connected to the server via long range telephone signals and to the lock via short range Bluetooth signals.

This system prevents altering of the encrypted commands, as the encryption is per- formed between the telephone and the server, whereas the telephone is only forwarding the encrypted signals. However, when sniffing the Bluetooth opening signal of the door lock, the signal can in principle be repeated in its encrypted form and be used to open the door without authorization, which is a disadvantage. Another disadvantage is that opening or locking requires a working internet connection between the mobile tele- phone and the server. If the Internet connection should fail for some reason, the door lock cannot be opened by the telephone.

Thus, the prior art has some disadvantages. It would therefore be desirable with improvements in the art.

DESCRIPTION / SUMMARY OF THE INVENTION

It is therefore the object of the invention to provide an improved method and system for operating a lock with a mobile device, in particular with a mobile telephone, in a safe way, preventing unauthorised access. This is achieved with a system and method as described in the following.

The system comprises a lock and a mobile device, and optionally also an authentication server that is connected to the Internet for data transfer. The lock comprises a wireless short range data transfer link, for example a Bluetooth transceiver. The mobile device comprises a corresponding wireless short range data transfer link and optionally also comprises means for connecting to the Internet and for data transfer via Internet. The mobile device communicates with the lock only via a short range wireless communica- tion system; optionally, the mobile device communicates with the server by using an Internet connection. For example, no direct connection is established between the server and the lock, because the lock does not have the means for connecting directly to the Internet. This saves electricity and makes the system in the lock simpler and safer. The system is configured to perform the following steps.

A command session is initiated by indication from a user on the mobile device for caus- ing the lock to lock or unlock, the indication comprising a pointer action by the user on a user interface of the mobile device or by keyboard action by the user on the mobile device. Alternatively, the mobile device is provided with an acceleration responsive function that is positive responsive upon knocking on the mobile device by at least two knocks within a time of less than 2 seconds, by which an active state is provided that initiates the command session. In this case, the method comprises initiating a command session by indication from a user for causing the lock to lock or unlock, the indication comprising by a user knocking at least two times on the mobile device within less than 2 seconds. the indication by the user As a further alternative, no pointer action is used but the mobile device is programmed to cause the lock to unlock automatically when the mobile device is within a communication range with the lock. When a short range wireless digital data communication link is established between the mobile device and the lock, the command session is initiated automatically as a response of the established communication link, and the lock is ordered to unlock without further interference from a user.

For example, relatively to the maximum short range signal strength, optionally maximum Bluetooth intensity, a requirement for automatic unlocking is a predetermined fraction of the maximum Bluetooth strength. Examples of such predetermined fraction are at least 20% of the maximum signal strength or at least 40% of the maximum Bluetooth strength. For example, 40% of the maximum signal strength corresponds to a distance of 2 meter. However, in order to adjust the desired distance for automatic unlocking, the user may adjust the pre-set signal strength level, for example by corresponding programming of the mobile device. The pre-set level is advantageously above 10%) of the maximum short range communication signal strength, for example at least 20% of the maximum signal strength. Optionally, such programming is performed with a sliding indicator on the user interface, such as touch screen, on the mobile device. In practice, the user is moving to a distance from the lock at which the user desires un- locking and is subsequently touching a slidable indicator on the user interface of the mobile device and sliding the indicator to position on the user interface in which the predetermined limit for the signal strength is appropriate for automatic opening of the lock.

As a response to the indication from the user by a pointer action or by the knocking on the mobile device or automatically when the mobile device is in near vicinity of the lock as described above, a session encryption key is automatically created by the mobile device or by the lock or by both in cooperation and, correspondingly, digital data are exchanged in encrypted form between the mobile device and the lock by the short range wireless digital data communication link. An operation command is sent from the mobile device to the lock for locking or unlocking according to the user indication. This operation command is part of the encrypted data exchange between the mobile device and the lock during the command session. The received encrypted operation command is decrypted in the lock by using the session encrypted key and the locking or unlocking is performed by the lock in accordance with the operation command.

As an advantage, the command session is initiated and executed without communication between the server system and the mobile device during the execution of the command session and without communication between the server system and the lock during the execution of the command session. This makes execution of the command session with locking and unlocking independent of an internet connection, as all communication is performed via short range communication between the mobile device and the lock.

Advantageously, the operation command is only executed by the lock if the execution is possible prior to a predetermined time limit. For example, such predetermined time limit is calculated as a predetermined time period that runs from a digital time stamp that is submitted as part of the encrypted operation command. For example, the dura- tion of the time period is a few second, optionally 3 seconds.

In a practical embodiment, the session encryption key has validity at most until the predetermined time limit, and the operation command is carried out by the lock only if session encryption key is valid at the time of decryption. If the encryption key is not valid, the decryption may not be carried out, and the lock does not perform any locking or unlocking action. It should be emphasized that the decryption and execution of the operation command are regarded as quasi simultaneously for practical purposes, be- cause the time span between the decryption and the execution of the command is short as compared to the predetermined time period.

In certain embodiments, if the locking or unlocking is prior to the predetermined time limit, the encryption key is only valid until the instance of locking or unlocking by the lock. Thus, in the case where the unlocking or locking action is performed prior to the predetermined time limit, this action overrules the predetermined time limit and the encryptions key loses its validity as soon as the locking or unlocking is performed, even in the event that the predetermined time limit is later than the decryption and execution of the operation command. This implies the advantage that one encryption key can only be used once for locking or unlocking; no re-use of a session encryption key is possible for repeated locking or unlocking. For example, in the event of locking by an authorised person, unauthorised third parties cannot use the same encryption key for a subsequent unlocking action, even if the time span between the locking and unlocking is short.

Apart from locking and unlocking actions, other operational sessions can be performed, for example transmission of log files and dedicated parameter setting of the lock, such as automated locking or unlocking at certain times each day. For such session, session encryption keys are used as well if the transmission of data is desired to be encrypted for such other sessions.

Advantageously, a Phone Lock Encryption Key (PLEK) is provided by a server system. The PLEK is automatically created in the server system and sent to the mobile device via the Internet upon request by the mobile device and stored in a data memory of the mobile device for creation of the session encryption key on the basis of the PLEK. Prior to the command session, the PLEK is sent by the mobile device to the lock and stored in a data memory of the lock. Thus, the means for creating session encryption keys is submitted to the mobile device by an external device, namely a secured server system. This implies a reduced risk for tampering the mobile device and for unauthorised commands to the lock. For example, the mobile device would not accept a false encryption key by third parties, also called "man-in-the-middle", in the attempt of intervening into the system in an unauthorised way.

Advantageous, in order to increase security, the PLEK is received by the mobile device in two versions, wherein one version is in non-encrypted form and another version is in encrypted form. The mobile device is storing the non-encrypted PLEK in the data memory of the mobile device and forwarding the encrypted PLEK to the lock. The encrypted PLEK is encrypted by the server in a way that the mobile device cannot decrypt this PLEK; however, the lock is provided with a decryption algorithm that allows decrypting the received PLEK. Only, once decrypted, the mobile device and the lock have identical PLEKs, and only if identical, a proper command session is possible which may cause the lock to lock or unlock.

In some embodiments, the PLEKs have a certain time of validity and are renewed periodically. Alternatively or in addition, new PLEKs are provided upon request. This increases the security in that there is updated control of validity of operation commands. Once the communication of the mobile device with the server has been terminated, for example after receipt of the PLEK and possible receipt of other data and encryption keys, a command session, for example for locking or unlocking by the lock, is initiated by the mobile device and executed by the lock without further communication between the server and the mobile device. It is also recalled that the lock does not communicate directly with the server. For this reason, a command session is performed without communication between the server and the lock directly and also not via the mobile device.

In further embodiments, in order to increase the security, the command session com- prises the step of submitting from the mobile device to the lock a request for a random or pseudorandom number (NONCE). The NONCE has only a limited validity until the predetermined time limit. The session encryption key is created on the basis of a com- bination of the PLEK and the NONCE. This way, the validity of the session encryption key is time-wise limited by the validity of the NONCE.

In a way to control the time-wise validity of the session encryption key, the method comprises creating by the mobile device a unique identifier of the session encryption key and submitting the unique identifier from the mobile device to the lock. The unique identifier is received by the lock and checked for acceptance in relation to the NONCE and the PLEK. For example, in the case of acceptance, an acceptance signal is sent from the lock to the mobile device. An example of such unique identifier is a secure hash algorithm (SHA) value, for example a SHA-1 value.

Optionally, the method comprises, prior to the command session, by the mobile device establishing an internet connection to a server system and receiving by the mobile device a Server lock Encryption Key, SLEK, from the server system. The SLEK is forwarded by the mobile device to the lock without decrypting the SLEK by the mobile device. Alternatively, the SLEK is provided by the lock and send to the mobile device via the short range communication link and forwarded to the server by an internet connection. In order to increase the data security, the mobile device is incapable of decrypting digital data that are encrypted with the SLEK. However, the lock and the server, after forwarding of the SLEK, are configured for encrypting and decrypting digital data by the SLEK. For example, the above-mentioned encrypted PLEK that is forwarded from the mobile device to the lock is encrypted with the SLEK and can, therefore, only be decrypted by the lock and not by the mobile device or by any other third party or apparatus not being equipped with the correct decryption algorithm from the SLEK.

In further embodiment, the server submits an SLEK-encrypted Phone Lock Communication Initiation Record, PLCIR, to the mobile device, which forwards this PLCIR without decryption to the lock. The PLCIR comprises the PLEK for the lock, an indi- cator for a time period of validity of the PLCIR, and optionally permission data, the permission data indicating the permission for locking the lock or unlocking the lock or both by the specific mobile device, and potentially further permissions for the mobile device, such as the permission to change the setting of the lock. The PLCIR may, op- tionally, in addition, comprise a checksum of the contained data, which is an additional measure that is checked by the lock in order to verify the validity of the PLCIR as received by the lock. Any attempt of third parties to enter the communication system without authorization would fail at one or more of the security measures of the inven- tion.

In order to operate the lock, a corresponding software application may be installed on the mobile device. For operating the lock the user may use the software application to select the lock in question among a number of locks and also initiate sending of com- mands to the lock. Accordingly, in some embodiments, prior to establishing a command session, a short range wireless digital data communication link is established between the mobile device and the lock and other similar locks. In this recognition phase, the exchange of digital data for recognizing potential locks in the vicinity of the mobile device is done without encryption. Each lock has an individual identifier, and during this recognition phase, the targeted lock submits such unique lock identifier, ID, to the mobile device; and other potential similar locks submit their individual identifier to the mobile device. The ID of the targeted lock and the other lock identifiers are indicated on a user interface of the mobile device. By an indication from a user the ID of the targeted lock is selected among the other lock identifiers on the user interface. For exam- pie, the user indication is a pointer action on the user interface, for example a finger touch on a touch-sensitive user display, or a keyboard action on the mobile device, or a knocking action as described above, where the user only knocks a few times, for example two times, on the mobile device, and an acceleration responsive function in the mobile device recognizes this as a user indication. As a response to the user indication, the command session is initiated by the mobile device and executed by the lock, such as a locking or unlocking action.

For example, the server system is used in an initial phase in order to set up the lock and the mobile device in relation to each other. By communication through the Internet, a user protocol is established at a server system with a user ID. The user ID forms the basis for registering one or a plurality of mobile devices in relation to one or a plurality of locks. For example, if a plurality of locks are used for doors in a building, and each one of several operators has a mobile devices for operating these locks, the mobile de- vices of the plurality of operators as well as the locks are registered in the server system. The user ID may then be used in the server system as an administrator of the distribution of rights to the various operators for operating the various locks. The administrator would, typically, also have the possibility to give, take, and change the permis- sions to the various operators with respect to whether, when, how long, and to which extent a specific operator among the respective operators can operate the locks or a selection among the locks. All the date is stored in a database in the server system. In relation to a user ID, which is used by an administrator, operators can be added as well as new locks, and operators can be removed as well as locks from the stored list in the server system. A corresponding user interface, accessible, via the Internet is used for changing the parameters and options for the operators and the locks in relation to a user ID.

The various mobile devices in relation to a single user ID, typically, receive different PLEKs, such that the PLEK itself is uniquely related to a specific mobile device. When permissions to various mobile devices are changed, a typical way to control the change of permission is to invalidate all PLEKs and redistribute new PLEKs to the respective mobile devices. Those mobile devices that do not receive a new PLEK would not any longer be able to operate the respective lock.

Typically, the encryption is a 128 bit encryption, optionally, an Advanced Encryption Standard (AES) based on the Rijndal cipher.

SHORT DESCRIPTION OF THE DRAWINGS

The invention will be explained in more detail with reference to the drawing, where FIG. 1 illustrates the system. DETAILED DESCRIPTION / PREFERRED EMBODIMENT

Fig. 1 discloses a system for operating a lock 1 by wireless communication 6 with a mobile device 2, typically a mobile telephone. For example, the lock 1 is a door lock or a lock for a safe, a drawer, or vehicle. The lock 1 comprises a communication and control module 3, typically incorporated within the housing of the lock, although, it could also be provided externally and functionally connected to the lock 1. In the following, it is assumed that the communication and control module 3 is inside the housing of the lock 1, although, the invention can easily be modified for an external communication and control module 3. Embedded firmware is stored in the lock and executed via a processor functionally connected with the communication and control module 3 of the lock 1. The communication and control module 3 comprises instructions for communicating 6 with mobile devices 1 via a short range wireless protocol when the mobile device 2 is in proximity of the communication and control module 3 of the lock 1. The communication and control module 3 further comprises instructions for controlling an actuator of the lock, such as motor and solenoid devices.

The system also comprises a server system 4 for initial authentication of the lock 1 and the mobile device 2 and for updates of the data related to the communication between the mobile device 2 and the lock 1. Communication 7, 9 between the mobile device 2 and the server system 4 is done via the Internet 8. The server system 4 comprises a computer readable memory 5 and a processor for storing and executing computer programs and comprises an encryption engine that is configured to process authentication requests from the mobile device 2 in connection with the initiation of a control function for the lock 1.

As described in further detail below, when the mobile device 2 is in proximity of the lock 1, a wireless connection 6 is established between the mobile device 2 and the communication and control module 3 of the lock 1, typically via a short-range wireless protocol, for example Bluetooth, Wi-Fi or Zigbee. If the lock 1 has been pre- configured in a memory of the mobile device 2, the mobile device 2 sends operational commands to the communication and control module 3 of the lock 1 through the wireless connection 6, for example upon user input from a user interface 10 displayed on the mobile device 2, such as a touch screen interface. The mobile device 2 is equipped with a corresponding computer application therefore; for example, the mobile device 2 is a smart phone comprising a so called "App", which is specific term for a computer application in a smart phone. The user may be prompted to select a unique individual identifier ID of the lock 1 in a list on the user interface 10 of the mobile device 2 by a pointer action or other indication means and initiate the operation of the lock 1. The communication and control module 3 of the lock 1 is functionally coupled to an actuator drive circuitry of the lock 1, such as motor and solenoid devices in order for the lock to perform opening and closing actions, for example of a door.

Alternatively, the mobile device may be provided with an accelerometer and an acceleration responsive function that is positive responsive upon knocking on the mobile device by at least two knocks within a time of less than 2 seconds, for example within 1 second, by which an active state is provided that initiates the command session and causes the lock 1 to unlock.

As a further alternative, the mobile device 2 is programmed to automatically unlock a lock 1 when the mobile device 2 is within short range of the lock 1, the range given by the range necessary for the short range communication link.

The user interaction with the mobile device 2 initiates specific encrypted digital communication 6 between the mobile device 2 and the lock 1, where the specific encrypted signal comprises a time stamp and is only valid for a certain period of time. When an encrypted communication is used between the mobile device 2 and the lock 1, the digi- tal data sequence of the encrypted command signal is unique and linked to the time stamp, such that the repeated sending of the same encrypted digital data sequence after lapse of a predetermined time period after the time indicated by the time stamp would not cause any operation of the lock 2. For example, the time period after the time stamp is fixed to a typical time period slightly longer than typically needed for an oper- ation such as unlocking or locking a door. Alternatively, the period is variable and terminated as soon as a command has been executed by the lock 1 ; only in the case of no command execution of the lock, the period of validity of the encrypted command is up to a predetermined maximum time length, for example less than 3 seconds, and termi- nated when this maximum time length has lapsed. As a consequence, in the event that third parties sniff the data sequence of the encrypted communication between the mobile device 2 and the lock 1, it would be useless for the third party, because a repeated execution of a specific command, such as re-opening of the lock 1, or unauthorized opening after authorized locking, would not be possible due to the already elapsed time period for validity of the command.

It is pointed out that the communication 6 and command exchange between the mobile device 2 and the lock 1 is performed without the necessity of Internet communication with the server system 4 by the mobile device 2 or the lock 1. Thus, for the operation of the lock 1, only a short range communication protocol is necessary for communication directly between the mobile device 2 and the lock 1.

The role of the server system 4 is a set-up of the lock 1 and the mobile device 2 with respect to permissions and authentication such that the communication between the mobile device 2 and the lock 1 is enabled to the extent that the lock 1 performs the commands received from the mobile device 2. Once enabled, the communication between the mobile device 2 and the lock 1 and the operation of the lock 1 as determined by commands from the mobile device 2 is independent of the server system 4. The server system 4 is also used for providing encryption codes to the lock 1 and the mobile device 2 in an initialization phase and possibly in later phases, where the communication between the server system 4 and the lock 1 is provided through the mobile device 2 as an intermediary. In addition, in such instances where the communication parameters and permissions are changed, the server system 4 is necessary for providing updated set-up data to the mobile device 2 and/or the lock 1. Once updated, the communication between the lock 1 and the mobile device 2 is independent from the server system 4. Once, the initialization phase or update phase is terminated, there is no need for an Internet connection between the server and the mobile device 2 or between the lock 1 and the mobile device 2 in order to operate the lock 1 with the mobile device 2. For operating the lock 1, the encrypted communication between the mobile device 2 and the lock 1 is sufficient. In order to be able to operate a lock or multiple locks of the system, a user accesses the server system 4 via an Internet site on the Internet 9, for example with the mobile device 2 or with any other computer that is connected to the Internet. Upon request, the server 4 creates a user name with corresponding password in the database 5. The communication is encrypted, typically SSL (Secure Sockets Layer) encrypted, for safe communication. A computer application, for example a so called "App" is downloaded into the memory of the mobile device 2 from the Internet site related to the server system 4. The computer application is preconfigured for being used to communicate with the server system 4 and to retrieve data information from the lock 1 and send com- mands to the lock 1 if this is registered in the database 5 of the server system 4.

All communication between the server system 4 and the lock 1 is performed through the mobile device 2 as an intermediary. The latter implies that the lock 1 does not need to be provided with Internet connection capabilities, a short range communication 6 with the mobile device 2 suffices.

A new lock 1 is configured and connected to the server system 4 as follows. The communication and control module 3 of the lock 1 is powered on by use of a hardware key or knob. At this stage, the lock 1 is in a virgin state, also called "vanilla state", such that it is not yet registered with the server system 4 and not yet registered in the mobile device 2 and its software not yet modified. Upon powering on, the lock 1 is configured for short range communication 6 and transmits its ID via the short range communication 6. Once, a communication line 6 is established between the lock 1 and the mobile device 2, the ID is shown on the user interface of the mobile device as part of the com- puter application, such as an "App". Due to the fact that the mobile device 2 may have a number of locks 1 shown on the interface, due to the versatility of operating multiple lock by a single mobile device and/or because more than one lock is within the communication range 6, the lock ID of the lock in a vanilla state may be shown in a special format as long as it is in the vanilla state, for example with underscored alphanumeric letters indicating the lock ID. Once, recognized by the user who is operating the mobile device, the user may use the user interface on the mobile device to accept the lock 1 for a setup procedure in which the lock 1 is registered in the mobile device 2 and in the server system 4 as a new lock 1 for which the user has administrative rights with respect to initialization and operation.

Upon selection of the specific new lock ID on the user interface in the mobile device 2, the user initiates the registration procedure and initiates connection to the server system 4. For example, the user selects a command that performs an installation procedure in relation to the lock ID. After connection to the server system 4, the server system 4 retrieves the request for initialization of the lock 1 based on the lock ID. The server stores in the database 5 a document with the lock 1 information linked to the previous- ly stored user name and user related information. For example, the document contains information on the software and hardware of the lock, the ID of the short range communication system, for example the ID of the Bluetooth module in the lock, the MAC (media access control) address, any user-selected alias name given by the user to the lock 1. This initialization phase can be performed without encryption, whereas the en- cryption keys are created during the initialization phase, and protect the system for all subsequent command and information exchange.

In the initialization phase, in a Key Exchange Session, the lock 1 creates a Server Lock Encryption Key (SLEK) that is used for encrypted communication; typically, it is a 128 bit encryption key. This SLEK is submitted from the lock 1 to the server 4 via the mobile device 2. The server 4 and the lock use this SLEK for the future encrypted communication. This SLEK has a special role for the encryption and will be explained in greater detail below. In short, the SLEK is used for the encrypted communication between the server 4 and the lock via the mobile device 2, however, without the mobile device decrypting this SLEK; although, the mobile device can extract information sent along with the encrypted communication from the server system 4 to the lock 2, where the server system has used the SLEK for encryption, the mobile device 2 cannot amend or even interpret the SLEK itself. In other words, although the mobile device 2 is used as communication tool between the server 4 and the lock 1, the mobile device 2 is largely a passive device with respect to the SLEK. When an encrypted data package is sent from the server system 4 to the mobile device 2, part of the data package may be configured by the server system 4 for use by the mobile device 2, whereas parts of the data package is encrypted by the SLEK and passed on by the mobile device 2 to the lock 1, where it is decrypted and used for communication and setup. The advantage of this feature is that a SLEK for the sake of decryption of commands and information is only accessible at the server 4 and inside the lock 1, but not at the mobile device 2. Thus, a hacking by third parties into the mobile device 2 would not reveal the specific encryption method used for commands send to the lock 1 from the server system 4 via the mobile device 2. This increases the safety against hacking.

Alternatively, the SLEK is sent from the server system 4 to the lock 1 via the mobile device. Important in this context is the role of the SLEK is the unique encryption and decryption code for information between the server 4 and the lock 1 which cannot be decrypted by the mobile device or other third party devices.

The server system 4 is sending further encryption keys to the mobile device 2, where the further encryption keys are used for the operational commands from the mobile device 2 to the lock 1; during the communication between the mobile device 2 and the lock 1, as already pointed out above, there is no need for communication with the server 4. Instead, the necessary encryption key setup is received by the mobile device 2 from the server system 4 as part of the initiation procedure and used later without further interference from the server system 4. This further encryption key received by the mobile device from the server as part of the initiation procedure is here called the Phone Lock Encryption Key (PLEK). The server sends a Phone Lock Communication Initiation Record (PLCIR) to the mobile device as part of the initiation procedure. The PLCIR is encrypted with the SLEK and contains a variety of information, including an encrypted PLEK for the lock, optionally, a time synchronization between the server system 4 and the lock 1, a time stamp for expiry of the PLCIR, an indicator for various permissions for the mobile device and the user. Typically, a non-encrypted PLEK is sent along with the PLCIR for use by the mobile device. Once, the encrypted PLEK is received and decrypted by the lock, and the non-decrypted PLEK is received by the mobile device, both the mobile device and the lock have identical PLEKs for the fur- ther communication. As the PLCIR package is encrypted, it is safe against third parties' possible intervention. A command session is only initiated if the PLEK is valid. Optionally, for convenience, the time validity of the PLCIR and the PLEK is also communicated to the mobile device along with the PLCIR and the mobile device is programmed to not initiate a command session if the PLCIR and the PLEK are not valid. However, even in the case where the mobile device would attempt to initiate a command session, the lack of validity of the encryption due to the invalid PLCIR and PLEK would prevent the lock from executing the attempted command session.

In order to even increase the safety, the PLCIR has attached to it a checksum that is calculated on the basis of the data in the PLCIR. The lock, after decryption, calculates a likewise checksum according to a predetermined checksum algorithm and compares it to the checksum attached to the PLCIR and only accepts the PLCIR as originating from the server if the two checksums are identical.

The PLEK is stored in the mobile device and used for the normal operational communication between the mobile device 2 and the lock 1 after having finalized the initiation procedure. In order for the operational command from the mobile device 2 to the lock 1 not being re-usable after sniffing, the PLEK is combined with a random number (NONCE) as received from the lock 1 upon request by the mobile device 2. The combined PLEK+NONCE is used for encryption during a relatively short duration, after which the encryption key becomes useless. As a further control against attempts by unauthorized intruders, the mobile device, for example a mobile telephone, calculates a secure hash algorithm (SHA) value, for example a SHA-1 value, from the PLEK+NONCE encryption key and send this to the lock, which is then controlled by the lock for allowing the following command receiving session. Thus, also in this case, sniffing of an operational command would be useless, because the re-use of the command would fall outside the time duration where the encryption of the command is valid.

From the server, PLEKs can be regenerated upon request. Alternatively or in addition, PLEKs are generated periodically, for example once each hour or once each day and forwarded from the server to the mobile device when there is an internet connection between the mobile device and the server.

For example, the first initiation may comprise authorization for a number of operators with various mobile devices that are allowed to operate a specific lock, the various mobile devices being equipped with a computer application, such as an "App", and the various operators being registered in the user-related document as stored in the database of the server system 4. Each of the authorized operators uses a mobile device that is set up for sending encrypted command to the lock. The procedure for registering multiple operators for operating a single lock is analogous to the procedure for registering a single operator with a single mobile device. Once the list of authorized operators changes, for example, additional or less operators are desired for being able to operate the lock 1, the administrator by using the user name in the server system activates the mobile device to send a "FetchKey" command to the server 4, upon which a new set of PLEKs are submitted by the server system 4 to the mobile device 2 or mobile devices and to the lock 1. Only those operators that receive the new encryption key PLEK are then able to operate the lock, whereas operators excluded from receiving the new encryption key are prevented from future operation of the lock. This difference between the SLEK and the PLEK is important to notice. The SLEK is used as a basic encryption key that is initiated once and kept for the future correspondence in the system. The accessibility to the SLEK is inside the lock and in the server but not in the mobile device. The PLEK, in turn, is stored in the mobile device and is renewed though communication from the server system with the mobile device. The PLEK is renewed periodically or upon request when the number of operators is changed; for example, when one of the operators should not have the possibility to operate the lock any more, the PLEK is renewed on those mobile devices that are intended to maintain operability with the lock but not on the mobile device of the specific operator that is to be excluded. As the new PLEK is substituting the old PLEK in the lock for encryption, the specific operator will not have the possibility to operate the lock any more. It is noticed that such change of PLEK does not affect the SLEK, which remains the same.

The PLEK is also used by the mobile device for encryption when requesting and re- ceiving access logs and error logs from the lock.

For example, the 128 encryption as mentioned above is provided according to an Advanced Encryption Standard (AES) based on the Rijndal cipher. Once, the lock has performed the command, for example locking or unlocking or change of settings in the lock, the lock send a data sequence back to the mobile device for forwarding to the server in order to keep a log database with the sequence of ac- tions performed by the lock.

As it appears from the foregoing, the PLEK, SLEK, and PLCIR are all in the form of digital data. The SLEK is first digital data that contains information about encryption and decryption of digital data. The PLEK is second digital data that contains infor- mation about encryption and decryption of digital data. The PLCIR is third digital data that contains the second digital data.