U.S. patent application number 14/643501 was filed with the patent office on 2015-10-29 for access control method, and associated lock device and administration server.
The applicant listed for this patent is Phoniro AB. Invention is credited to Olle BLIDING, Lars KNUTSSON.
Application Number | 20150310685 14/643501 |
Document ID | / |
Family ID | 44066779 |
Filed Date | 2015-10-29 |
United States Patent
Application |
20150310685 |
Kind Code |
A1 |
BLIDING; Olle ; et
al. |
October 29, 2015 |
ACCESS CONTROL METHOD, AND ASSOCIATED LOCK DEVICE AND
ADMINISTRATION SERVER
Abstract
An access control method is disclosed in which a lock device
provides conditional access to a protected environment by
short-range wireless communication with a key device having a key
device identifier (KD_ID). In the method, the lock device requests
the key device to provide a challenge response to a challenge
generated by the lock device based on a challenge code kept by the
lock device. The lock device receives the challenge response from
the key device. The challenge response is generated by a remote
administration server and is based on the key device identifier of
the key device. The generated response is sent to the key device
and forwarded from the key device to the lock device. The lock
device then verifies the received challenge response based on the
challenge code and on the key device identifier of the key
device.
Inventors: |
BLIDING; Olle; (Halmstad,
SE) ; KNUTSSON; Lars; (Halmstad, SE) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Phoniro AB |
Halmstad |
|
SE |
|
|
Family ID: |
44066779 |
Appl. No.: |
14/643501 |
Filed: |
March 10, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13504282 |
Apr 26, 2012 |
9024720 |
|
|
PCT/SE2010/051226 |
Nov 9, 2010 |
|
|
|
14643501 |
|
|
|
|
Current U.S.
Class: |
340/5.61 |
Current CPC
Class: |
G07C 9/28 20200101; G07C
9/00904 20130101; G07C 9/27 20200101; G07C 2009/00793 20130101;
G07C 2009/00317 20130101; H04W 4/80 20180201; G07C 2009/00388
20130101; G07C 2009/00769 20130101; G07C 9/00309 20130101; G07C
9/00571 20130101 |
International
Class: |
G07C 9/00 20060101
G07C009/00; H04W 4/00 20060101 H04W004/00 |
Foreign Application Data
Date |
Code |
Application Number |
Nov 27, 2009 |
SE |
0950904-3 |
Claims
1-15. (canceled)
16. A lock device for use in an access control system which
involves a plurality of lock devices, a plurality of key devices,
each key device having a key device identifier, and an
administration server having an associated system database which
defines the conditions under which individual ones of the key
devices may be granted access to protected environments by
individual ones of the lock devices, the lock device comprising: a
transceiver for short-range wireless communication with a key
device among said plurality of key devices; a memory; and a
processing unit, the processing unit being configured for:
detecting the key device identifier of said key device during the
short-range wireless communication with the key device; generating
a challenge code to be stored in said memory; generating a
challenge based on said challenge code; causing said transceiver to
send the generated challenge to said key device; receiving, via
said transceiver, a challenge response from the key device, wherein
the challenge response originates from the administration server;
verifying the received challenge response based on the challenge
code in said memory and on the detected key device identifier of
said key device; and determining whether conditional access may be
given to the key device based on an output from said means for
verifying.
17. The lock device as defined in claim 16, wherein the processing
unit is configured for generating the challenge by encrypting the
challenge code using a key which is based on at least one of a
serial number and a lock device identifier of said lock device.
18. The lock device as defined in claim 16, wherein the processing
unit is configured for: receiving, via said transceiver, an
encrypted challenge response from the key device; and decrypting
the received encrypted challenge response by using a key which is
based on at least one of the lock device serial number and the lock
device identifier of said lock device.
19. The lock device as defined in claim 16, wherein the memory is
for storing of lock access data, said lock access data including
key device identifiers of key devices which are allowed to access
the environment protected by the lock device, and wherein the
processing unit is configured for: when the key device approaches
the lock device and seeks access, detecting the key device
identifier for the key device; checking if the detected key device
identifier matches the lock access data stored in the memory; and
if no match is found, generating said challenge and causing sending
of the generating challenge to the key device.
20. The lock device as defined in claim 16, the short-range
wireless communication being Bluetooth.RTM. communication, wherein
the processing unit is configured for detecting the key device
identifier by reading a Bluetooth.RTM. address assigned to a
Bluetooth.RTM. transceiver used by the key device for the
Bluetooth.RTM. communication with the lock device.
21. An administration server for use in an access control system
which furthermore includes a plurality of lock devices and a
plurality of key devices, each key device having a key device
identifier, the administration server having a system database
associated therewith, wherein the system database defines the
conditions under which individual ones of the key devices may be
granted access to protected environments by individual ones of the
lock devices, and the administration server being configured for:
receiving a challenge from a key device among said plurality of key
devices over a communication network, wherein the challenge
originates from a lock device, among said plurality of lock
devices, to which the key device has sought access; retrieving a
copy of the key device identifier of said key device by searching
the system database using information received from the key device;
deriving a challenge code from the received challenge; generating a
challenge response based on the derived challenge code and the
retrieved copy of the key device identifier; and sending the
generated challenge response to said key device over said
communication network.
22. The administration server as defined in claim 21, further being
configured for: receiving the challenge from the key device;
determining, from information received from the key device, the
lock device from which the challenge originated; searching the
system database associated with the administration server to
retrieve at least one of a serial number and a lock device
identifier of the lock device from which the challenge originated;
and decrypting the received challenge to derive the challenge code
using a key which is based on the retrieved serial number and/or
lock device identifier.
23. The administration server as defined in claim 22, further being
configured for: encrypting the challenge response by using a key
which is based on the retrieved serial number and/or lock device
identifier; and sending the encrypted challenge response to the key
device.
24. The administration server as defined in claim 21, wherein the
challenge response generated by the remote administration server
includes usage restriction data, defining at least one of an
expiration date/time for the challenge response, and a maximum
usage limit for the challenge response.
25. The administration server as defined in claim 21, wherein the
challenge response generated by the remote administration server
includes a part which is readable by the key device and which
defines an expiration date/time for the challenge response, said
part of the challenge response serving to cause the key device to
prevent forwarding of the challenge response to the lock device if
the expiration date/time has lapsed.
26. An access control system which comprises a plurality of lock
devices, a plurality of key devices, each key device having a key
device identifier, and an administration server having an
associated system database which defines the conditions under which
individual ones of the key devices may be granted access to
protected environments by individual ones of the lock devices,
wherein each lock device comprises: a transceiver for short-range
wireless communication with a key device among said plurality of
key devices; a memory; and a processing unit, the processing unit
being configured for: detecting the key device identifier of said
key device during the short-range wireless communication with the
key device; generating a challenge code to be stored in said
memory; generating a challenge based on said challenge code;
causing said transceiver to send the generated challenge to said
key device; receiving, via said transceiver, a challenge response
from the key device, wherein the challenge response originates from
the administration server; verifying the received challenge
response based on the challenge code in said memory and on the
detected key device identifier of said key device; and determining
whether conditional access may be given to the key device based on
an output from said means for verifying.
27. The access control system as defined in claim 26, wherein the
administration server is configured for: receiving the challenge
from the key device over a communication network; retrieving a copy
of the key device identifier of the key device by searching the
system database using information received from the key device;
deriving a challenge code from the received challenge; generating a
challenge response based on the derived challenge code and the
retrieved copy of the key device identifier; and sending the
generated challenge response to the key device over the
communication network.
28. The access control system as defined in claim 26, wherein the
processing unit of the lock device is configured for: generating,
in advance, one or more challenge codes, storing the generated one
or more challenge codes in local memory, and communicating the
generated one or more challenge codes to the administration server
for storage in the system database; wherein the key device is
configured for: requesting and receiving, in advance, a
pre-generated challenge response from the administration server,
and storing the received pre-generated challenge response in local
memory; wherein the administration server is configured for:
retrieving any one of the one or more challenge codes of the lock
device from the system database, and using the retrieved challenge
code when generating the requested pre-generated challenge response
to be sent to the key device; and wherein the key device is
configured, when approaching the lock device and seeking access,
and being requested by the lock device to provide a challenge
response, for: responding by retrieving the pre-generated challenge
response from local memory, and sending the retrieved pre-generated
challenge response to the lock device.
29. The access control system as defined in claim 28, wherein the
processing unit of the lock device is configured for: verifying the
received challenge response by producing a candidate challenge
response from each challenge code stored in its local memory and
the key device identifier of said key device, and matching the
received challenge response against all produced candidate
challenge responses.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to access control, and more
particularly to an access control method in which a lock device
provides conditional access to a protected environment by
short-range wireless communication with a key device having a key
device identifier. The invention also relates to a lock device for
use in an access control system which involves a plurality of lock
devices, a plurality of key devices, each key device having a key
device identifier, and an administration server. In addition, the
invention relates to an administration server having an associated
system database which defines the conditions under which individual
ones of the key devices may be granted access to protected
environments by individual ones of the lock devices.
BACKGROUND OF THE INVENTION
[0002] Access control methods and systems are previously known in
which electronic lock devices are installed at doors, gates, etc.,
so as to provide conditional access to protected environments. A
user that seeks access to such a protected environment will use an
electronic key device which will communicate with the lock device
in question. Based on this communication, the lock device will
decide whether or not to allow the user to access the protected
environment, for instance by controlling an electro-mechanical lock
which is included in or coupled to the lock device.
[0003] Generally, there are two distinctly different categories of
access control systems. In the first category, the key device acts
as an intermediate device to allow communication between the lock
device and a remote central server. Such communication may take
place over existing wide-area data and/or telecommunication
networks. The outcome of this communication will determine whether
or not the key device--and the user carrying it--shall be granted
access to the environment protected by the lock device at any given
moment.
[0004] WO 2006/098690 discloses an access control system of a
second category. In WO 2006/098690, the electronic key devices are
capable of short-range wireless data communication with the lock
devices. Each key device has a key device identifier which is used
for the short-range wireless data communication, and the lock
device is configured to perform authentication of an appearing key
device by detecting the key device identifier of the key device and
using the detected key device identifier, together with some other
parameters, to determine whether access shall be granted. Each lock
device is a stand-alone device with its own internal power source
and requires no wiring to its surroundings. When a key device
approaches and seeks access, the lock device will communicate with
the key device using short-range wireless data communication, but
it will typically not need any further communication with other,
more remote elements in the system, such as a central server. In
order to operate autonomously, the lock device uses local lock
access data which is stored within the lock device and defines the
key device identifiers of key devices which are allowed to access
the protected environment. In one embodiment, the key devices are
mobile terminals or other similar types of portable communication
devices being equipped with short-range wireless data communication
interfaces in the form of Bluetooth.RTM. transceivers. Hence, the
key device identifier of each key device is the unique
Bluetooth.RTM. address assigned to the Bluetooth.RTM. transceiver
in the key device.
[0005] In an access control system of the above second category,
where the lock devices operate autonomously on locally stored lock
access data, there will be an issue when it comes to providing the
lock access data into the lock devices. Initially, when a new lock
device is to be installed at the intended protected environment,
the lock device may be programmed with certain initial lock access
data, either during the manufacturing procedure, or by service
personnel before or during the actual installation. This initial
lock access data will then define an arbitrary number of key
devices which are authorized to access the protected environment,
these key devices being identified in the lock access data by their
respective key device identifier (Bluetooth.RTM. address).
[0006] Once installation is completed, the autonomously operating
lock device has no other contact with the surroundings, except when
an appearing key device seeks access to the environment protected
by the lock device. The access control system of WO 2006/098690 is
therefore configured to exchange various data between key device
and lock device, once the key device has been successfully
authorized and a bi-directional Bluetooth.RTM. link has been
established between the devices. The types of data exchanged
include log file and status data recorded by the lock device
regarding for instance previous attempts by key devices to access
the environment protected, as well as updated lock access data
intended to replace or upgrade the existing lock access data in the
lock device. Such updated lock access data will have been generated
by an administrator at a remote administration server and sent in
advance to the key device over one or more existing communication
networks such as the Internet and/or a telecommunications network.
Upon receipt, the key device will have buffered the updated lock
access data, waiting for an opportunity when the user of the key
device approaches the lock device in question to forward the
updated lock access data to the lock device.
[0007] In this way, service personnel do not have to visit the
premises where the lock device is installed in order to update the
lock access data. Instead, updated lock access data may be sent via
the key device over existing communication networks, as mentioned
above. However, this requires that the key device which visits the
lock device is indeed authorized to access the protected
environment; otherwise there will be no Bluetooth.RTM. link
established between the devices and, consequently, no opportunity
for the key device to forward the updated lock access data to the
lock device. In turn, in order to be considered as authorized by
the lock device, the key device identifier of the key device must
be included in the current lock access data in the lock device. In
other words, the key device must already be known to the lock
device. Actually, in real-world implementations, not all key
devices are typically allowed to bring updated lock access data to
lock devices. Rather, a subset of particularly trusted key devices
is designated as ambassadors; only these will be allowed to bring
updated lock access data to the lock devices. Ambassador key
devices may for instance be possessed and used by managers,
security personnel or other trusted users in the access control
system.
[0008] As time passes, any real-world implementation of an access
control system will experience needs to add new users/key devices
to the system, to change which particular key devices that shall be
able to access each particular lock device, to remove users/key
devices from the system, etc. These needs will be all the more
frequent and complicated, the bigger and more complex the access
control system grows. This will be considered in more detail in a
later section of this document with reference to FIG. 1.
[0009] One particularly problematic situation which needs to be
handled is when a whole set of key devices, which has hitherto been
defined as authorized according to the current lock access data in
one or more lock devices, no longer shall be authorized but instead
be replaced by a new group of key devices. If none of the key
devices in the new group is previously known to a lock device, then
that lock device will not be prepared to communicate with any such
unknown key device and will therefore not be able to receive the
updated lock access data.
[0010] Another particularly problematic situation is when a new key
device is to be added to the list of authorized key devices for a
particular lock device, but that lock device is only visited by an
ambassador key device at infrequent occasions. This may mean that
the new key device's access to the particular lock device is
considerably delayed by as much as a week, month or even more.
[0011] Generally, the invention seeks to find a trade-off between
two opposing interests--to allow for a flexible way of distributing
sets of updated lock access data to all relevant lock devices,
while maintaining security at an acceptable level.
SUMMARY OF THE INVENTION
[0012] In view of the above, an objective of the invention is to
solve or at least reduce the problems discussed above.
[0013] On a conceptual level, the invention is based on the
inventive insight that autonomously operating lock devices (i.e. an
access control system of the above-mentioned second category) can
be provided with additional functionality for requesting a key
device to provide a response to a challenge made by the lock
device. The challenge shall be based on a challenge code generated
and/or stored locally in the lock device, and the response to the
challenge shall be created by a remote administration server and
shall be based on information that serves to identify the key
device.
[0014] In a way, the present invention can be seen to be based upon
a hybrid between the two different categories of access control
systems referred to above.
[0015] In view of the above, a first aspect of the present
invention therefore is an access control method in which a lock
device provides conditional access to a protected environment by
short-range wireless communication with a key device having a key
device identifier, the method involving:
[0016] the lock device requesting the key device to provide a
challenge response to a challenge generated by the lock device
based on a challenge code kept by the lock device;
[0017] the lock device receiving the challenge response from the
key device, wherein the challenge response is generated by a remote
administration server and is based on the key device identifier of
said key device, and wherein the generated response is sent to the
key device and forwarded from the key device to the lock device;
and
[0018] the lock device verifying the received challenge response
based on the challenge code and on the key device identifier of
said key device.
[0019] Advantageously, the remote administration server generates
the challenge response as a function of a copy of said key device
identifier kept by the administration server, and the lock device
detects the key device identifier during the short-range wireless
communication with the key device and uses the detected key device
identifier for verifying the received challenge response.
[0020] In one or more embodiments, the lock device generates the
challenge by encrypting the challenge code using a key which is
based on at least one of a serial number and a lock device
identifier of said lock device.
[0021] In one or more embodiments, the administration server:
[0022] receives the challenge from the key device;
[0023] determines, from information received from the key device,
the lock device from which the challenge originated;
[0024] searches a system database associated with the
administration server to retrieve at least one of a serial number
and a lock device identifier of the lock device from which the
challenge originated; and
[0025] decrypts the received challenge to derive the challenge code
using a key which is based on the retrieved serial number and/or
lock device identifier.
[0026] In this or other embodiment(s), the administration server
further:
[0027] retrieves the copy of said key device identifier by
searching the system database using information received from the
key device; and
[0028] generates the challenge response based on the derived
challenge code and the retrieved copy of said key device
identifier.
[0029] In this or other embodiment(s), the administration server
further:
[0030] encrypts the challenge response by using a key which is
based on the retrieved serial number and/or lock device identifier;
and
[0031] sends the encrypted challenge response to the key
device.
[0032] In this or other embodiments, the lock device:
[0033] receives the encrypted challenge response from the key
device; and
[0034] decrypts the received encrypted challenge response by using
a key which is based on at least one of the lock device serial
number and the lock device identifier of said lock device.
[0035] The challenge response generated by the remote
administration server may include usage restriction data, defining
at least one of an expiration date/time for the challenge response,
and a maximum usage limit for the challenge response.
[0036] Further, the challenge response generated by the remote
administration server may include a part which is readable by the
key device and which defines an expiration date/time for the
challenge response, wherein the key device will prevent forwarding
of the challenge response to the lock device if the expiration
date/time has lapsed.
[0037] In one or more embodiments, where the lock device has a
memory for storing lock access data, said lock access data
including key device identifiers of key devices which are allowed
to access the environment protected by the lock device, the method
comprises the initial steps, performed by the lock device, of:
[0038] when the key device approaches the lock device and seeks
access, detecting the key device identifier for the key device;
[0039] checking if the detected key device identifier matches the
lock access data stored in the memory of the lock device; and
[0040] if no match is found in the checking step, generating said
challenge and sending it to the key device.
[0041] Advantageously, the short-range wireless communication is
Bluetooth.RTM. communication; wherein the lock device may detect
the key device identifier by reading a Bluetooth.RTM. address
assigned to a Bluetooth.RTM. transceiver used by the key device for
the Bluetooth.RTM. communication with the lock device.
[0042] Embodiments of the method may operate in an "Online" mode,
which means that the generated challenge is sent from the lock
device to the key device when the latter seeks access but is denied
this because there is no key device identifier representing that
key device in the lock device's memory (i.e., the key device is
unknown to the lock device). Thus, in Online mode, the generated
challenge is sent from the lock device to the key device using
short-range wireless communication. The key device then forwards
the generated challenge to the administration server over an
available communication channel, which may be a packet-based or
circuit-switched communication channel over a mobile
telecommunications network such as GSM, UMTS, LTE, D-AMPS,
CDMA2000, FOMA or TD-SCDMA. Alternatively or additionally, the
communication channel may comply with a wireless data communication
standard such as WLAN (Wireless Local Area Network).
[0043] Alternatively or additionally, embodiments of the method may
operate in an "Offline" mode. In Offline mode, a challenge code in
instead transferred in advance from the lock device to the
administration server. This may for instance occur in an initial
batch of pre-generated challenge codes generated in or for the lock
device already at the time of manufacturing, assembling or
installation, or in a subsequent batch of challenge codes which are
generated by the lock device, when the initial batch has run out,
and communicated to the administration server by way of another,
trusted and allowed key device when it seeks and gets access at the
lock device.
[0044] Thus, in Offline mode, the lock device in advance generates
one or more challenge codes, stores the challenge code(s) in local
memory, and communicates the challenge code(s) to the
administration server for storage in a system database; the key
device in advance requests and receives a pre-generated challenge
response from the administration server, and stores the received
pre-generated challenge response in local memory;
[0045] when generating the requested pre-generated challenge
response to be sent to the key device, the administration server
retrieves and uses any one of the challenge code(s) of the lock
device from the system database;
[0046] when the key device approaches the lock device and seeks
access, and is requested by the lock device to provide a challenge
response, the key device responds by retrieving the pre-generated
challenge response from local memory, and sending it to the lock
device.
[0047] In Offline mode, the lock device may verify the received
challenge response by producing a candidate challenge response from
each challenge code stored in its local memory and the key device
identifier of said key device, and matching the received challenge
response against all produced candidate challenge responses.
[0048] Advantageously, the Online and Offline modes may be used in
the same embodiment where the lock device, key device and
administration server are capable of operating in the Online mode
or in the Offline mode, depending on whether or not the key device
can access the administration server at the moment when it seeks
access to the lock device.
[0049] Further features of the method according to the first aspect
of the invention are defined in the attached dependent claims.
[0050] A second aspect of the present invention is a lock device
for use in an access control system which involves a plurality of
lock devices, a plurality of key devices, each key device having a
key device identifier, and an administration server having an
associated system database which defines the conditions under which
individual ones of the key devices may be granted access to
protected environments by individual ones of the lock devices. The
lock device has:
[0051] a transceiver for short-range wireless communication with a
key device among said plurality of key devices;
[0052] a memory;
[0053] means for detecting the key device identifier of said key
device during the short-range wireless communication with the key
device;
[0054] means for generating a challenge code to be stored in said
memory;
[0055] means for generating a challenge based on said challenge
code;
[0056] means for causing said transceiver to send the generated
challenge to said key device;
[0057] means for receiving a challenge response from the key
device, wherein the challenge response originates from the
administration server;
[0058] means for verifying the received challenge response based on
the challenge code in said memory and on the detected key device
identifier of said key device; and
[0059] means for determining whether conditional access may be
given to the key device based on an output from said means for
verifying.
[0060] In addition, the second aspect of the present invention may
comprise means or other structural elements capable of performing
any of the lock device functions referred to above for the method
according to the first aspect.
[0061] A third aspect of the present invention is an administration
server for use in an access control system which furthermore
includes a plurality of lock devices and a plurality of key
devices, each key device having a key device identifier. The
administration server has:
[0062] a system database which is associated with the
administration server, wherein the system database defines the
conditions under which individual ones of the key devices may be
granted access to protected environments by individual ones of the
lock devices;
[0063] means for receiving a challenge from a key device among said
plurality of key devices over a communication network, wherein the
challenge originates from a lock device, among said plurality of
lock devices, to which the key device has sought access;
[0064] means for retrieving a copy of the key device identifier of
said key device by searching the system database using information
received from the key device; means for deriving a challenge code
from the received challenge;
[0065] means for generating a challenge response based on the
derived challenge code and the retrieved copy of the key device
identifier; and
[0066] means for sending the generated challenge response to said
key device over said communication network.
[0067] In addition, the third aspect of the present invention may
comprise means or other structural elements capable of performing
any of the administration server functions referred to above for
the method according to the first aspect.
[0068] Other objectives, features and advantages of the present
invention will appear from the following detailed disclosure as
well as from the drawings.
[0069] Generally, all terms used in the claims are to be
interpreted according to their ordinary meaning in the technical
field, unless explicitly defined otherwise herein. All references
to "a/an/the [element, device, component, means, step, etc]" are to
be interpreted openly as referring to at least one instance of said
element, device, component, means, step, etc., unless explicitly
stated otherwise. The steps of any method disclosed herein do not
have to be performed in the exact order disclosed, unless
explicitly stated.
BRIEF DESCRIPTION OF THE DRAWINGS
[0070] The above, as well as additional objectives, features and
advantages of the present invention, will be better understood
through the following illustrative and non-limiting detailed
description of embodiments of the present invention, reference
being made to the appended drawings.
[0071] FIG. 1 is a schematic view of an access control system in
which embodiments of the present invention may be exercised.
[0072] FIG. 2 illustrates an access control method which may be
performed in the access control system of FIG. 1.
[0073] FIG. 3a is a schematic flowchart of an access control method
according to one embodiment, operating in Online mode.
[0074] FIG. 3b is a schematic flowchart of an access control method
according to one embodiment, operating in Offline mode.
[0075] FIG. 4 is a schematic block diagram of a key device which
may interact with a lock device in the access control system of
FIG. 1.
[0076] FIG. 5 is a schematic block diagram of a lock device
according to one embodiment.
DETAILED DESCRIPTION OF EMBODIMENTS
[0077] FIG. 1 illustrates, in a schematic and simplified form, the
layout of an access control system for elderly care. A first team
of caregiver personnel 2 is responsible for the elderly care of a
first group of caretakers, all living in rooms or apartments
covered by respective front doors 50.sub.1-50.sub.n. Lock devices
40.sub.1-40.sub.n are installed on the respective front doors
50.sub.1-50.sub.n and serve as gateways to the respective protected
environment (i.e. room or apartment) behind each door. A first pool
of key devices 1.sub.1-1.sub.m is available to the first team of
caregiver personnel 2. The key devices 1.sub.1-1.sub.m may be
mobile terminals. Each lock device 40.sub.1-40.sub.n contains lock
access data which includes the key device identifiers of the key
devices 1.sub.1-1.sub.m which are allowed to access the lock device
in question.
[0078] When a user in the first team starts his shift, he will
check out one of the key devices 1.sub.1-1.sub.m from a caregiver
central, for instance key device 1.sub.1. During his shift, he will
use key device 1.sub.1 to gain access to various ones of the front
doors 50.sub.1-50.sub.n to provide the care required by the
respective caretakers. This access will be provided by way of
Bluetooth.RTM. communication between key device and lock device, as
indicated at 14 in FIG. 1. Therefore, the key device identifiers
mentioned above may advantageously be represented by the unique
Bluetooth.RTM. addresses assigned to the Bluetooth.RTM.
transceivers in the respective key devices.
[0079] At the end of his shift, the user will again check in and
return the key device 1.sub.1 to the caregiver central. In addition
or alternatively, some or all members of the first team of
caregiver personnel 2 may use their own mobile terminals as key
devices. Not all key devices or members of the first team of
caregiver personnel 2 may be authorized to access all doors, and
they need not all have the same level of authorization in terms of
times and/or dates when access is allowed.
[0080] The access control system of FIG. 1 further involves a
second team of caregiver personnel 2' responsible for serving a
second group of caretakers, the rooms or apartments of which have
respective front doors 50'.sub.1-50'.sub.n to which lock devices
40'.sub.1-40'.sub.n are installed. A second pool of key devices is
available to the second team of caregiver personnel 2'. Of course,
the access control system may in reality include additional teams
of caregiver personnel, additional groups of caretakers, additional
front doors, additional lock devices, and additional pools of key
devices.
[0081] In addition, security personnel 2'' with key devices
1''.sub.1-1''.sub.2 are included in the system. Whereas the key
devices 1.sub.1-1.sub.m, of the first and second teams 2, 2' will
be used by a relatively large number of caregiver persons to access
a relatively small number of lock devices/doors at relatively
frequent occasions, the situation is the opposite for the key
devices 1''.sub.1-1''.sub.2 of the security personnel 2''. These
key devices will be used by a limited number of persons (such as
nurses or guards) at rare occasions, but they nevertheless need to
be able to access a very large number of lock devices/doors--or
even all lock devices/doors that are included in the access control
system.
[0082] For enhanced security, each key device runs an access
control software application in which the user must log on. Also,
all communications with the lock devices are encrypted. Further,
not all users/key devices are allowed to bring updated lock access
data to the lock devices. Rather, in the embodiment of FIG. 1, a
subset of particularly trusted users/key devices are designated as
ambassadors; only these will be allowed to bring updated lock
access data to the lock devices.
[0083] Each team of caregiver personnel 2, 2' may be sub-divided
into sub-groups, for instance a day shift, an evening shift and a
night shift. Also, an individual user may act in or for both teams
2 and 2' (for instance to serve as back-up in situations of
sickness, parental leave or during popular holiday periods),
therefore having a need to use his key device for accessing lock
devices both in the first group of caretakers and in the second
group of caretakers. This is illustrated in FIG. 1 for key device
1.sub.m, which will access not only lock device 40.sub.m in the
first group of caretakers, but also lock device 40'.sub.1 in the
second group of caretakers (see arrow 14a).
[0084] Because of the complex situation in the access control
system, it is apparent that given the very large number of key
devices and lock devices involved, it is a difficult and complex
problem to keep the lock access data in the various lock devices
appropriately updated to reflect changes among the users (caregiver
personnel and security personnel), so that, in each given
situation, a certain lock devices makes a correct decision as to
whether or not a user of a certain key device shall be granted
access.
[0085] FIGS. 2 and 3a-3b illustrate how the invention provides a
solution to this difficult and complex problem, for the embodiment
shown in FIG. 1. In FIG. 2, it is assumed that one of the key
devices 1.sub.1-1.sub.m, 1'.sub.1-1'.sub.m approaches one of the
lock devices 40.sub.1-40.sub.n, 40'.sub.1-40'.sub.n in step 210.
This individual key device is referred to as key device, or KD, 1
in the following, and the main components of the key device 1 are
shown in FIG. 4. The corresponding individual lock device is
referred to as lock device, or LD, 40, and its main components are
shown in FIG. 5. The individual caregiver person that uses the key
device 1 is referred to as user 2. At some earlier point in time,
the key device 1 may have received updated lock access data (ULAD)
456 in a step 200 from the administration server 100 in FIG. 1.
[0086] In the embodiment disclosed in FIG. 4, the key device 1 is a
mobile terminal, e.g. a cellular telephone, personal digital
assistant (PDA), smart phone, etc., which is capable of
communicating with a telecommunications system. Thus, the user 2
may use the key device 1 for various telecommunication services,
such as voice calls, Internet browsing, video calls, data calls,
facsimile transmissions, still image transmissions, video
transmissions, electronic messaging, and e-commerce. Generally,
these telecommunication services are not central within the context
of the present invention; there are no limitations to any
particular set of services in this respect. Therefore, only
components which are somehow pertinent to the inventive
functionality are shown in FIG. 4.
[0087] As seen in FIG. 4, the key device 1 has a network interface
430 for connecting to the Internet/telecommunications network(s)
104. The network interface 430 may comply with any commercially
available mobile telecommunications standard, including but not
limited to GSM, UMTS, LTE, D-AMPS, CDMA2000, FOMA and TD-SCDMA.
Alternatively or additionally, the network interface 430 may comply
with a wireless data communication standard such as WLAN (Wireless
Local Area Network).
[0088] The key device 1 also has a man-to-machine interface (MMI),
or user interface (UI) 420, which may include a display 422 and a
set of keys 424 or other input device, as well as other known UI
elements like a speaker and a microphone. The user 2 may control
the operation of, and exchange data with, the key device 1 over the
user interface 420.
[0089] Further, the key device 1 has an interface 440 for
short-range wireless data communication. In the disclosed
embodiment of FIG. 4, the interface 440 comprises a Bluetooth.RTM.
transceiver, by means which the key device 1 can communicate with,
for instance, the lock device 40 over the Bluetooth.RTM. link 14.
The Bluetooth.RTM. transceiver is assigned a unique Bluetooth.RTM.
address KD_ID, the meaning of which has already been explained
above. Alternatively or additionally, the interface 440 may for
instance comprise transceiver components for IrDA (Infrared Data
Association), WLAN or NFC (Near Field Communication).
[0090] A processing unit 410 is overall responsible for the
operation and control of the different components of the key device
1. The processing unit 410 may be implemented in any known
controller technology, including but not limited to a processor
(PLC, CPU, DSP), FPGA, ASIC or any other suitable digital and/or
analogue circuitry capable of performing the intended
functionality.
[0091] Finally, the key device 1 has a memory 450 which is
operatively connected to the processing unit 410. The memory 450
may be implemented by any known memory technology, including but
not limited to E(E)PROM, S(D)RAM and flash memory, and it may also
include secondary storage such as a magnetic or optical disc.
Physically, the memory 450 may consist of one unit or a plurality
of units which together constitute the memory 450 on a logical
level. In addition to storing various program instructions and data
for the various functions and applications which are typically
available in a mobile terminal, the memory 450 also comprises the
program instructions 452 and work data for the aforementioned
access control software application. Also, any updated lock access
data received in step 200 will be buffered in the memory 450, as
seen at 456.
[0092] With reference to FIG. 5, the lock device 40 generally
comprises the following main components. A processing unit 510 is
overall responsible for the operation and control of the different
components of the lock device 40. The processing unit 510 may be
implemented in any known controller technology, including but not
limited to a processor (PLC, CPU, DSP), FPGA, ASIC or any other
suitable digital and/or analogue circuitry capable of performing
the intended functionality.
[0093] The lock device 40 of this embodiment is a stand-alone,
autonomously operating device which requires no wire-based
installations, neither for communication nor for power supply.
Instead, the lock device 40 is powered solely by a local power unit
520 which comprises one ore more long-life batteries. It interacts
with key devices, as already mentioned, by wireless activities. The
lock device 40 therefore has an interface 540 for short-range
wireless data communication. In the disclosed embodiment of FIG. 5,
the interface 540 comprises a Bluetooth.RTM. transceiver, by means
which the lock device 40 can communicate with, for instance, the
key device 1 over the Bluetooth.RTM. link 14. The Bluetooth.RTM.
transceiver is assigned a unique Bluetooth.RTM. address LD_ID.
Alternatively or additionally, the interface 540 may for instance
comprise transceiver components for IrDA, WLAN or NFC.
[0094] The lock device 40 of the disclosed embodiment further
includes a real-time clock 530 capable of providing the processing
unit 510 with an accurate value of the current time. However,
embodiments are also possible where no real-time clock is
provided.
[0095] Finally, the lock device 40 has a memory 550 which is
operatively connected to the processing unit 510. The memory 550
may be implemented by any known memory technology, including but
not limited to E(E)PROM, S(D)RAM and flash memory, and it may also
include secondary storage such as a magnetic or optical disc.
Physically, the memory 550 may consist of one unit or a plurality
of units which together constitute the memory 550 on a logical
level. The memory 550 serves to store various program instructions
and work data for functions to be performed by the processing unit
510 in order to carry out the tasks of the lock device 40. For
instance, these program instructions define a main access control
module or means 552 which is responsible for the general parts of
the lock device-side functionality shown in FIGS. 2, 3a and 3b.
There is also a challenge generation module or means 554 (cf step
310, FIGS. 3a-3b), a challenge response verification module or
means 556 (cf step 340, FIGS. 3a-3b), an encryption/decryption
module or means 558, and a communication module or means 560 which
handles all communication with key devices in cooperation with the
interface 540.
[0096] Moreover, the memory 550 serves to store a local lock device
database (LD-DB) 570, which includes lock access data 572 upon
which the access control decisions are based (cf steps 230 and 250
in FIG. 2). The lock device database 570 may also store status and
log file data which are referred to further below (cf step 270 in
FIG. 2). Also, the memory 550 serves to store a challenge code 580
generated by the lock device, and in some embodiments also a
plurality of additional challenge codes 582. The lock device 40 has
a serial number which was assigned during manufacturing, assembly,
delivery or installation. This serial number is also stored in the
memory 550, as seen at 590.
[0097] For further implementation details and possible additional
components of the lock device 40, reference is made to the
aforementioned WO 2006/098690, which is fully incorporated herein
by reference.
[0098] Referring back to step 210 in FIG. 2, when the user 2 has
brought his key device 1 near the door 50 which is protected by the
lock device 40, the user may request access by issuing a command in
the user interface of the key device 1, e.g. by invoking a function
in the aforementioned access control software application. In
alternative embodiments, this may instead occur automatically. For
instance, if the lock device 40 has access to the output signal of
a presence sensor on or at the door 50, the lock device 40 may
detect the presence of the user 2 and in response trigger
performance of the remaining steps. As further alternatives, the
key device 1 or the lock device 40 may be configured to regularly
transmit beacon signals (e.g. Bluetooth.RTM. inquiries) which may
be detected and responded to by the other device.
[0099] In a following step 220, the lock device 40 will detect the
key device identifier KD_ID by reading, from the Bluetooth.RTM.
communication traffic between the devices, the Bluetooth.RTM.
address assigned to the Bluetooth.RTM. transceiver 440 in the key
device 1. It is to be noticed that it is not necessary to wait
until a bidirectional Bluetooth.RTM. link has been established in
order to detect the Bluetooth.RTM. address of the key device 1,
since the Bluetooth.RTM. address is included in and can be read
already from the initial Bluetooth.RTM. messages which are sent
between the devices e.g. during paging, handshaking and
initiation.
[0100] Then, in a step 230, the lock device 40 will check if the
detected key device identifier KD_ID matches the lock access data
572 currently stored in its internal memory 550. If so, the lock
device 40 considers the key device 1 as a known key device and
proceeds to an optional step 240, in which further verification of
the key device 1 may take place. Such further verification may
include establishing and further communicating over a bidirectional
Bluetooth.RTM. link 14 between the lock device 40 and key device 1.
For instance, the access control software application in the key
device 1 may prompt the user to enter a PIN code on a keypad of the
key device 1, and the PIN code may be communicated over the
Bluetooth.RTM. link to the lock device 40, which may compare the
received PIN code with a prestored PIN code associated with the key
device identifier KD_ID in the lock access data 572. Alternatively
or additionally, the user 1 may provide some biometric data, such
as a scanned fingerprint, by means of the key device 1, to be
evaluated by the lock device 40 upon receipt.
[0101] In a subsequent step 250, the lock device 40 determines
whether or not the key device 1/user 2 shall be granted access or
not. This may involve checking that the KD_ID of the key device 1
was recognized in step 230 as a known KD_ID which is not included
in a "black list" of blocked key device identifiers in the lock
access data 572. If the optional step 240 is applied, the
determination in step 250 will also include a check that the
further verification in step 240 was successful.
[0102] A favorable decision in step 250 will trigger a step 260 in
which the actual access in made to happen. This may involve
actuating an electric motor to displace a lock plunger or other
mechanism to an unlocked position, or releasing a latch mechanism
so that it will no longer prevent manual or automatic opening of
the door 50. This is collectively referred to as lock actuator 512
in FIG. 5.
[0103] Finally, an optional step 270 may be performed, in which
further data exchange may take place. This may involve transfer
from the lock device 40 to the key device 1 of the log file and
status data recorded by the lock device regarding for instance
previous attempts by key devices to access the protected
environment. Additionally or alternatively, the further data
exchange may involve transfer from the key device 1 to the lock
device 40 of the updated lock access data 456 which was previously
received in step 200, this updated lock access data being intended
to replace or upgrade the existing lock access data 572 in the
local lock device database 570 held by the lock device 40 in its
memory 550.
[0104] An unfavorable decision in step 250 will instead result in
termination of the procedure of FIG. 2, without any performance of
step 260.
[0105] This far, the description of FIG. 2 essentially corresponds
to the disclosure in the aforementioned WO 2006/098690, in which
the skilled person will find any implementation details not
explicitly mentioned in the present patent application. The novel
and inventive functionality will now be described.
[0106] In step 230, if the result of the check is that the detected
key device identifier KD_ID does not match the lock access data 572
currently stored in the internal memory 550 of the lock device 40,
this means that the key device 1 is unknown to the lock device 40.
This situation will trigger a challenge procedure which is shown in
FIGS. 3a and 3b.
[0107] The main steps of the challenge procedure in FIGS. 3a and 3b
are the following. In step 310, a challenge is generated by the
lock device 40. The generated challenge is based on the challenge
code 580. The challenge code 580 may be generated by the lock
device 40 "on the fly", i.e. when needed for step 310, or in
advance. The generated challenge code 580 is stored in the internal
memory 550 of the lock device 40.
[0108] In step 320, the generated challenge is sent to the key
device 1 over the Bluetooth.RTM. link 14. The key device 1 will
then either act in accordance with a first mode of operation, which
is referred to as "Online" throughout this document and which is
illustrated in FIG. 3a, or it will act in accordance with a second
mode of operation, which is referred to as "Offline" (FIG. 3b). The
Online mode typically applies when the key device 1 has momentary
access to the communication network(s) 104 and therefore also to
the administration server 100. Conversely, the Offline mode
typically applies when the key device 1 does not have momentary
access to the communication network(s) 104 and therefore cannot
reach the administration server 100 for the time being. Particulars
of the Online and Offline modes are described in more detail in
later sections of this document, but these modes can be summarized
in the following way:
[0109] As seen in step 321 in FIG. 3a, in the Online mode, the key
device 1 will forward the challenge to the administration server
100 over the communication network(s) 104, thereby in effect making
a request for a challenge response. The administration server 100
will generate a challenge response in step 322, and send the
generated challenge response to the key device 1 in step 323 over
the communication network(s) 104. Upon receipt, the key device 1
will forward the challenge response to the lock device 40 in step
324 over the Bluetooth.RTM. link 14.
[0110] In the Offline mode shown in FIG. 3b, there will be no
communication with the administration server 100 at the moment in
time when steps 310 and 320 are performed (i.e. when the key device
1 has approached the lock device 40 and requests access). Instead,
at some earlier point in time, the user 2 of the key device 1 will
make a request over the communication network(s) 104 for a
pre-generated challenge response from the administration server 100
(step 301). In response, the administration server 100 will
generate the challenge response in step 302, using in this case a
previously stored copy of a valid challenge code for the lock
device 40. This copy will have been generated in advance by the
lock device 40 (e.g. already during the manufacturing of the
system, i.e. prior to delivery and installation), and communicated
to the administration server 100 for storage in the system database
102.
[0111] The pre-generated challenge response is sent to the key
device 1 in step 303 over the communication network(s) 104. Upon
receipt, the key device 1 will store the pre-generated challenge
response in its internal memory 450 in step 304, as seen at 454 in
FIG. 4. In alternative embodiments, the pre-generated challenge
response may be created and sent to the key device 1 on the
administration server's 100 own initiative, rather than in response
to a request from the key device 1.
[0112] Later on, when the lock device 40 sends the generated
challenge to the key device 1 over the Bluetooth.RTM. link 14 in
step 320, the key device 1 will react in step 325 by retrieving the
stored pre-generated challenge response from location 454 in its
internal memory 450. Then, the key device 1 will send the
pre-generated challenge response to the lock device 40 in step 326
over the Bluetooth.RTM. link 14.
[0113] One important feature of the challenge response (in Online
mode as well as Offline mode) is that it, in some way, is based on
(e.g. is a function of, or otherwise depends on or reflects) the
key device identifier of the key device 1. In a particularly
advantageous embodiment, the remote administration server 100 keeps
a copy KD_ID.sub.admin.sub.--.sub.copy of each key device
identifier for the various key devices 1.sub.1-1.sub.m,
1'.sub.1-1'.sub.m, in the system (e.g. by storing such copies in
the access control system database 102 or other parts of its
memory). When generating the challenge response in step 322 or 302,
the administration server 100 will read and use this copy
KD_ID.sub.admin.sub.--.sub.copy of the key device identifier for
the particular key device 1.
[0114] In step 330, the lock device 40 will use the Bluetooth.RTM.
link 14 to receive the challenge response from the key device 1.
Then, in step 340 the lock device 40 will verify the received
challenge response based primarily on i) the challenge code 580
which is stored in the internal memory 550 of the lock device 40,
and ii) the key device identifier of the key device 1. This is
handled by the processing unit 510 which will invoke the challenge
response verification means 556. In the particularly advantageous
embodiment mentioned above, the lock device 40 will detect the key
device identifier KD_ID of the key device 1 sometimes during the
Bluetooth.RTM. communication between lock device 40 and key device
1, i.e. for instance in step 220, 320 or 330. The lock device 40
will use the detected key device identifier KD_ID for verifying the
received challenge response in step 340. This is a security
advantage, since the challenge response (as generated by the
administration server 100) is based on a remotely stored copy of
the key device identifier, whereas the verification of the
challenge response by the lock device 40 will be based on the
"real" key device identifier as detected during actual
communication with the key device. Therefore, a malicious attempt
to use another key device than the one that is the rightful owner
of the key device identifier KD_ID is likely to be detected in the
verification step 340. A favorable output or result from the
verification step 340/challenge response verification means 556 is
therefore issued when the lock device 40 concludes that the
challenge response is as expected and that, conclusively, the
administration server 100 has approved that the key device 1 shall
be given access to the lock device 40.
[0115] In step 350, the lock device 40 determines--based on the
output of the verification step 340/challenge response verification
means 556--whether or not the key device 1 can be regarded as
trusted, even though the key device 1 was a priori unknown to the
lock device 40. Therefore, in case of a favorable verification
result in step 340, the execution will continue to node (B) in FIG.
2, whereupon the optional further verification of the key device 1
may take place in step 240, followed by the access determination
step 250, lock actuation step 260 and further data exchange step
270. In other words, a key device 1 which is a priori unknown to a
lock device may prove its trustiness by presenting to the lock
device 40 a challenge response that the lock device relies on.
[0116] On the other hand, in case of a negative verification result
in step 340, the execution in step 350 may cause the key device 1
to be blocked from further access to the lock device 40. This may
be done by storing the key device identifier KD_ID of the key
device 1 in a black list in the lock access data 572. A key device
which has been blocked by a lock device may then require an
unblocking event brought about by an ambassador device to the lock
device, for the key device to be removed again from the black
list.
[0117] Some of the key steps of the mode referred to as Online
above will now be described in more detail.
[0118] Lock Device--Generation of Challenge
[0119] The lock device 40 generates a challenge code 580 for use in
step 310 in FIGS. 3a and 3b by invoking the challenge generation
module 554. The challenge code 580 may be generated as an n-bit
random number using a random number algorithm where the seed is a
timer value (e.g. from real-time clock 530), some part of the log
file and status data recorded in the local lock device database
570, etc. In one embodiment, n=256.
[0120] Lock Device--Encryption of Challenge
[0121] For enhanced security in the access control system, the
communication between lock device 40 and administration server 100
is encrypted by the sender and decrypted by the receiver. As
regards the lock device 40, the encryption/decryption module 558
handles this by applying an encryption/decryption algorithm or
standard which is known also to the administration server 100. One
embodiment applies AES (Advanced Encryption Standard), using an
encryption/decryption key which is based on a standard function
known as SHA256 (Secure Hash Algorithm 256). In more detail, the
encryption/decryption key is calculated as the output of
SHA256(Algorithm1(serial No 590, LD_ID)), where Algorithm1 should
be known only to the administration server and the lock devices in
the system. The challenge sent in step 320 is then generated by
AES-encrypting the generated challenge code with the
encryption/decryption key.
[0122] Using both the lock device serial number 590 and the lock
device identifier LD_ID (i.e. the unique Bluetooth.RTM. address of
the lock device's Bluetooth.RTM. transceiver 540) represents a high
level of security, since both of these parameters are very unlikely
to be known by anyone else but the administration server 100.
However, other embodiments may use just one of the lock device
serial number 590 and the lock device identifier LD_ID for the
calculation of the encryption/decryption key.
[0123] Administration Server--Decryption of Challenge
[0124] When key device 1 forwards the challenge to the
administration server 100 in step 321, the access control software
application 452 in the key device 1 will also provide sufficient
information for the administration server 100 to determine the lock
device from which the challenge originated (in this case lock
device 40) and to which the challenge response therefore is to be
directed. The administration server 100 will search the system
database 102 and retrieve further information about the lock device
40. This further information includes the serial number and the
lock device identifier of the lock device 40, and it will be used
by the administration server 100 to calculate an
encryption/decryption key as the output of
SHA256(Algorithm1(retrieved lock device serial number, retrieved
lock device identifier)). The administration server 100 will then
decrypt the received challenge by applying the same
encryption/decryption algorithm (AES) as the lock device 40 did,
using the calculated encryption/decryption key. Thus, this
decryption will derive the challenge code. Of course, in
embodiments which use only one of the lock device serial number and
the lock device identifier for the encryption/decryption key at the
lock device side, the same will apply to the administration server
side.
[0125] Administration Server--Generation of Challenge Response
[0126] Then, the administration server 100 will generate the
challenge response in step 322. The challenge response
chlg_resp.sub.--1 will be generated by using an Algorithm2 which
should be known only to the administration server and the lock
devices in the system. The input parameters of Algorithm2 include
the challenge code and the key device identifier of key device 1.
As already explained in conjunction with FIG. 3a above, the key
device identifier of the key device 1 will be given by searching
the system database 102 and retrieving the copy
KD_ID.sub.admin.sub.--.sub.copy of the key device identifier for
key device 1. Sufficient information for this database search will
be provided by the access control software application 452 in the
key device 1 in step 321. Since the user 2 will have logged in to
the software application 452, his identity will be known. By
keeping in the system database 102 a cross-reference list between
user login identities and corresponding key device identifiers, the
correct copy KD_ID.sub.admin.sub.--.sub.copy can be retrieved in
step 322 by the administration server 100. To this end, the server
100 will make a check that the user 2 is authorized to access the
lock device 40 according to data in the system database 102 which
defines the conditions under which individual ones of the key
devices may be granted access to environments 50 protected by
individual ones of the lock devices in the access control
system.
[0127] Advantageously, the generated challenge response also
depends on the lock device identifier, LD_ID, of the lock device
40, as found in the system database 102. In other words, an
additional input parameter of Algorithm2 may be the lock device
identifier.
[0128] In addition, the generated challenge response may include
usage restriction data. The usage restriction may include an
expiration date/time which defines the date/time when the challenge
response may be used at the latest by a key device seeking access
to a lock device, or a limit on the maximum number of times the
challenge response may be used by a key device, or both.
[0129] Particularly for embodiments where the lock device does not
include a real-time clock 530 (thereby preventing the lock device
40 from evaluating a usage restriction in terms of an expiration
date/time), the generated challenge response may include a part
which is based on the key device identifier KD_ID of the key device
1. This will allow the software application 452 in the key device
to check the received challenge response in step 324 for any usage
restriction included therein, and use its own real-time clock (or a
network-based clock service) to determine whether the expiration
date/time has lapsed. If so, the challenge response will not be
forwarded by the key device 1 to the lock device 40. Since the
encryption/decryption algorithm and key should not be known to
intermediate devices like the key device 1, this part of the
generated challenge response should only depend on the key device
identifier KD_ID, which of course, is known to the key device
1.
[0130] Administration Server--Encryption of Challenge Response
[0131] The generated challenge response is encrypted by applying
AES, using an encryption/decryption key calculated from
SHA256(Algorithm3(lock device serial No, LD_ID)), where Algorithm3
should be known only to the administration server and the lock
devices in the system. Algorithm3 may be identical to or different
from Algorithm1. The encrypted challenge response is sent to the
key device 1 in step 323, as previously explained.
[0132] Lock Device--Decryption of Challenge Response
[0133] When the lock device 40 receives the challenge response in
step 330, it will decrypt it by applying the same
encryption/decryption algorithm (AES) and using the same
encryption/decryption key as was used by the administration server
100. Thus, the encryption/decryption module 558 will apply AES,
using an encryption/decryption key calculated from
SHA256(Algorithm3(serial No 590, LD_ID)). The decryption will
reveal the challenge response chlg_resp.sub.--1 as generated by the
administration server 100.
[0134] Lock Device--Verification of Challenge Response
[0135] In step 340, the challenge response verification module 556
will be invoked to verify the decrypted challenge response.
Algorithm2 will be executed, with input parameters (challenge code
580, LD_ID, KD_ID) and output chlg_resp.sub.--2. The challenge code
580 will be read from the internal memory 550, and LD_ID is
available from the interface 540. KD_ID has, as already explained,
been detected by the lock device 40 sometimes during the
Bluetooth.RTM. communication between lock device 40 and key device
1, e.g. in any of the prior steps 220, 320 or 330. In other words,
the lock device 40 produces a candidate challenge response
chlg_resp.sub.--2 by executing Algorithm2.
[0136] A verification result is issued in step 340 by comparing the
received (and decrypted) challenge response chlg_resp.sub.--1 and
the candidate challenge response chlg_resp.sub.--2. These two
instances of the challenge response have been generated by the
administration device and by the lock device, respectively. If they
match, this means that the key device 1 has been appropriately
approved by the administration server 100 for the lock device 40 in
question, even though the key device 1 was a priori unknown to the
lock device 40. Therefore, in case of a match, a favorable result
is issued from the verification step 340.
[0137] Now, some of the key steps of the mode referred to as
Offline above will now be described in more detail. Only
differences with respect to the Online mode will be described.
[0138] Lock Device--Generation of Challenge Codes
[0139] In order to support offline mode, the lock device 40 will in
advance generate a number of challenge codes 580, 582, using the
procedure described above. These challenge codes will be stored in
memory 550 and will moreover be communicated to the administration
server 100 for storage in the system database 102. The challenge
codes may be communicated already during the manufacturing of the
system, i.e. prior to delivery and installation. Alternatively,
they may be generated by the lock device 40 at some prior moment in
time and communicated to the administration server 100 via an
ambassador key device when visiting the lock device.
[0140] Administration Server--Generation of Challenge Response
[0141] There is of course no need for the administration server 100
to decrypt a challenge received from the key device, since no
challenge will be generated by the lock device 40 in offline mode.
Instead, when generating the challenge response in step 302, the
administration server 100 will retrieve any of the previously
stored challenge codes relating to lock device 40 from system
database 102.
[0142] A challenge code may typically only be used once. Therefore,
when the administration server notices that there is for instance
only 1 or 2 unused challenge codes left in the system database 102
for a particular lock device, it may send an alert via an
ambassador key device to the lock device in question. Sooner or
later, when the lock device communicates with this ambassador key
device in step 270, it may read this message and return with new
generated challenge codes which are communicated back to the
administration server 100 by the ambassador key device.
Alternatively, the lock device may itself keep track of the number
of unused challenge codes 580, 582 and generate new challenge codes
as appropriate.
[0143] Lock Device--Verification of Challenge Response
[0144] In this case, the lock device 40 will not know for sure
which particular challenge code 580, 582 that was used by the
administration server 100 for generating the challenge response.
Therefore, the lock device 40 may test the received (and decrypted)
challenge response by executing Algorithm2 for all challenge codes
580, 582 to produce a candidate challenge response
chlg_resp.sub.--2.sub.i for each challenge code, where i=1 . . .
[No of challenge codes]. If any of these candidate challenge
response chlg_resp.sub.--2.sub.i results in a match with the
received challenge response chlg_resp.sub.--1, a favorable result
may be issued from the verification step 340.
* * * * *