WO2019132650A1

WO2019132650A1 - Physical access control through challenge response interaction

Info

Publication number: WO2019132650A1
Application number: PCT/MY2018/050090
Authority: WO
Inventors: Chuan Hsian PU; Sazzad HOSSAIN; Alwyn Goh; Ahmad Syarif MUNALIH; Seyedvahid DIANAT
Original assignee: Mimos Berhad
Priority date: 2017-12-29
Filing date: 2018-12-07
Publication date: 2019-07-04
Also published as: MY191618A

Abstract

The present invention provides a system and method for physical access control by utilizing challenge response interaction. The present invention comprising at least one Authenticator Component (102) for online registration of user's credential or offline registration of user's credentials; at least one User Registration Server (106) for registration of user's credential and for generating user-specific credential; at least one Access Control Component (504) for communication with the Authenticator Component (102); at least one Access Control Registration Server (502) for registration of Access Control Component (504) and for generating component lock-specific credential; at least one Access Control Authentication Server (700) for verification of outcome and Access Control Component (504); and at least one Authentication Server (108) for authentication of user to access a physical device upon receipt of confirmation from the Access Control Authentication Server (700).

Description

PHYSICAL ACCESS CONTROL THROUGH CHALLENGE RESPONSE INTERACTION

FIELD OF INVENTION

The present invention relates to a system and method for physical access control by utilizing challenge response interaction. In particular, the present invention utilizes challenge response to prevent from reply attack.

BACKGROUND ART

Significant growth of Internet of Things (IOT) allows connectivity of users to daily household devices. The growth of IOT provides challenges in the form of vulnerability to user’s sensitive information which further increases security risk. Research is still ongoing to prevent high level security attacks in reduction of the flaws of the existing system connected through Internet of Things.

United States Patent No. US 7,315,823 B2 (hereinafter referred to as the US 823 B2 Patent) entitled“Wireless reservation, check-in, access control, check-out and payment” having a filing date of 25 February 2000 (Patentee: Telefonaktiebolaget L M Ericsson ) relates to wireless services for reservation, check-in, access control, check-out and payment, preferably for hotel customers by means of wireless application programs employing standard protocols operating on wireless user terminals provided with a wireless long or medium range communications and processing unit, such as a mobile telephone, and wireless short range device, such as a device complying with the Bluetooth industry standard. In the US 823 B2 Patent, secret keys are utilized in hotel-booking systems whereby the distribution of the secret key to client’s mobile terminal upon online booking is a key issue in key management. Further, in the US 823 B2 Patent, it is disclosed that for its door lock apparatus, the unlocking decision is solely based on administrator’s authorization on server. It is further disclosed in the US 823 B2 Patent that the access control right is issued upon first check-in to hotel and client terminal is interacted with administrator’s server directly.

United States Patent No. US 8,274,365 B2 (hereinafter referred to as the US 365 Patent) entitled“Smart lock system” having a filing date of 14 April 2008 (Patentee: Eastern Co) relates to systems and devices for access control and, particularly, to electronic key systems and devices for access control and monitoring. The US 365 Patent discloses an invention with its lock apparatus and key card with no access to network. Further, the US 365 Patent verifies user by performing matching of information to unlock door with public key cryptographic to protect the credential information over unprotected channels.

Untied States Patent Publication No. US2014/0077929 A1 (hereinafter referred to as the US 929 A1 Publication) entitled“Wireless access control system and related methods” having a filing date of 8 March 2012 (Applicant: UNIKEY TECHNOLOGIES Inc) relates to a wireless access control system includes a remote access device and an electronic lock. In the US 929 A1 Publication, the physical location of the user and their credential information is disclosed as evidence for authentication. These location and user credentials are verified in parallel for authorizing requests for door access. In a Technical Report UCB/EECS-2016-1 1 , it is identified that false geo-location can be spoofed onto mobile device of authorized user to make a smartlock suck as Danalock to believe that the authorized user is in nearby location, then intruder can unlock door by touch- to-unlock. It is further disclosed in the Technical Report that attack which arises from standalone door lock relays credential information through mobile device’s online connectivity for the establishment of required link for data interchange as the door lock does not have access to internet. From the Technical Report, it is disclosed that any update or information interchange must relay via mobile terminal as the only online path.

Accordingly, it can be seen in the prior arts that there exists a need to provide a challenge - response authentication for solving the problem of replay attack.

SUMMARY OF INVENTION

The present invention relates to a system and method for physical access control by utilizing challenge response interaction. In particular, the present invention physical access control is provided as a single-use challenge response interaction between authenticator and Access Control Components.

One aspect of the invention provides a system (100) for physical access control by utilizing challenge response interaction. The system comprises at least one Authenticator Component (102) for online registration of user’s credential or offline registration of user’s credential; at least one User Registration Server (106) for registration of user’s credential and for generating user-specific credential; at least one Access Control Component (504) for communication with the Authenticator Component (102) during challenge response authentication; at least one Access Control Registration Server (502) for registration of Access Control Component (504) and for generating component lock-specific credential; at least one Access Control Authentication Server (700) for verification of outcome resulted from challenge response authentication between the Authentication Component (102) and Access Control Component (504); and at least one Authentication Server (108) for authentication of user to access a physical device upon receipt of confirmation from the Access Control Authentication Server (700).

Another aspect of the invention provides a method (200) for physical access control by utilizing challenge response interaction. The method comprises steps of registering a user

(101 ) as an authenticator by associating an Authenticator Component (102) to the user (101 ) with an authentication service provider (202); registering an Access Control Component (504) with an access control provider and determining as to whether the user (101 ) is allowed physical access controlled by a particular lock between registered authenticator

(102) and Access Control Component (504) (204); performing authentication on identity of user through Authenticator Component (102) on a mobile device in possession of the user (101 ) (206); performing access control operations through Access Control Component (504) attached to the particular lock which provides for physical access control (208); verifying challenge outcome from the Access Control Component (504) in context of present interaction (210); and authenticating response outcome originated from Authenticator Component (102) in context of interaction of particular challenge issued (212). The step of performing access control operations through Access Control Component (504) attached to the particular lock which provides for physical access control (208) further comprises steps of (300) establishing user-specific credential from registration of Authenticator Component (102) (302); and establishing lock-specific credential from registration of Access Control Component (504) (304) by undergoing challenge response interaction by the Authenticator (102) and the Access Control Component (504); and verifying computation outcome of challenge-response interaction by the Access Control Authentication Server ( 700) ); said challenge outcome originates from particular Access Control Component in context of present interaction, and said response outcome as can only be correctly computed from particular authentication component in context of particular challenge issued in present interaction.

A further aspect of the invention provides for registering a user (101 ) as an authenticator by associating an Authenticator Component (102) to the user (101 ) with an authentication service provider (202) which further comprises steps of (400) computing a first outcome of public key cryptography (PKC) for a private-key unique to Authenticator Component (102) and registration interaction of interest (402); computing a second outcome of corresponding PKC public-key for unique association of Authenticator Component (102) to entity of interest (404); computing a third outcome of encryption key for Authenticator Component’s (102) secure storage of server-side computation outcomes (406); computing a fourth outcome of transport pre-key for server-to-client secure transport of computation outcomes (408); and performing client-to-server transmission of second and fourth outcomes, on primary communication channel (410).

Yet another aspect of the invention provides for performing client-to-server transmission of second and fourth outcomes, on primary communication channel (410) which further comprises server response and further steps of (500) computing a first outcome of entity identifier (EID) with public key and private key for unique association of client-side component to entity of interest (21 1 ) (502); computing a second outcome of HMAC key for Authentication Server (108) verification of client association with registration interaction, and compute Client component engagement in challenge-response interactions (21 1 ) (504); computing a third outcome of transport key from inputs of transport pre-key and context of present registration (212) (506); computing a fourth outcome of secure transport element from inputs of first, second and third outcomes, for subsequent client-side recovery and verification (508); and performing server-to-client transmission of fourth outcome (213), on secondary communication channel, as out of band (OOB) with respect to primary communication channel (510).

Still another aspect of the invention provides that the server response (500) further comprises server finalization which comprises steps of (500a) computing a first outcome of HMAC verification from inputs of established HMAC key and measured context of registration (502a); and computing a second outcome of PKC signature verification from inputs of established PKC public-key and measured context of registration (504a).

Another aspect of the invention provides that the step of performing client-to-server transmission of second and fourth outcomes, on primary communication channel (410) further comprises client test interaction with steps of (600) computing a first outcome of EID and HMAC key as retrieved from secure transport element of interest (241 ) (602); computing a second outcome of HMAC authenticator from inputs of retrieved HMAC key and measured context of registration (242) (604); computing a third outcome of PKC signature from inputs of PKC private-key, HMAC authenticator and context of registration (606); computing a fourth outcome of secure storage element from inputs of storage key, EID and HMAC key, for subsequent client-side recovery and verification prior to engagement in challenge- response interaction (608); and performing client-to-server transmission of first, and one of second and third outcomes, on primary communications channel (610).

A further aspect of the invention provides that the step of performing authentication on identity of user through Authenticator Component (102) on a mobile device in possession of the user (101 ) (206) further comprises steps of (800) computing of PKC private-key at client- side (21 1 ) (802); saving into client-side secure storage (212) unique identifier (UID) (241 ) and hash message authentication code (HMAC) key assigned by Registration Server.(804); computing HMAC authenticator or PKC signature at client-side of UID (806); verifying of authenticator or signature correctness at server-side verification (808); and associating the UID and PKC public-key with the user as registered (810).

Still another aspect of the invention provides that registering an Access Control Component (504) with an access control provider and determining as to whether the user (101 ) is allowed physical access controlled by a particular lock between registered authenticator (102) and Access Control Component (504) (204) further comprises steps of (900) computing of the PKC private-key at client-side (902); saving into client-side secure storage unique access control identifier (LID) (600) and HMAC key assigned by Registration Server (904); computing of HMAC authenticator or PKC signature with the client-side presentation of LID (906); verifying authenticator or signature correctness at server-side verification; and associating the LID and PKC public-key with particular lock as registered (908).

Yet another aspect of the invention provides that the step of verifying challenge outcome from the Access Control Component (504) in context of present interaction (210) further comprises steps of (1000) computing a first outcome of controller-specific PKC private-key (1002); computing a second outcome of LID and HMAC key retrieved from controller-side secure storage, on input of PKC private-key (822) (1004); computing a third outcome of encryption keys for transport security on subsequent controller-server communications, and HMAC authenticator, on inputs of retrieved HMAC key and measured context of present challenge-response interaction (823) and performing controller-to-device transmission of LID, and one of HMAC authenticator or PKC signature as lock challenge, on short-range point-to-point channel (812) (1006); computing a fourth outcome of PKC signature on inputs of PKC private-key and context of present challenge-response interaction (1008); and undertaking controller-to-device transmission of LID, and one of HMAC authenticator or PKC signature as lock challenge on short-range point-to-point channel (1010).

Still another aspect of the invention provides that the step of verifying challenge outcome from the Access Control Component (504) in context of present interaction further comprises steps of (1000a) computing a first outcome of user-specific PKC private-key as computed (1002a); computing a second outcome of UID and HMAC key as retrieved from device-side secure storage, on input of PKC private-key (822) (1004a); computing a third outcome of PKC signature on inputs of PKC private-key, measured context of present challenge- response interaction, and controller-computed challenge (812) (1006a); and computing a fourth outcome of HMAC authenticator on inputs of retrieved HMAC key, and controller- computed challenge; and upon reciprocal device-to-controller transmission of UID, and one of PKC signature or HMAC authenticator as user response, on previously established short- range point-to-point channel (813) (1008a); and undertaking reciprocal device-to-controller transmission of UID, and one of PKC signature or HMAC authenticator as user response, on established short-range point-to-point channel (1010a).

Another aspect of the invention provides that the step of authenticating response outcome originated from Authenticator Component (102) in context of interaction of particular challenge issued (212) further comprises steps of (1 100) performing onward transmission from Access Control Component (504) to access control server of LID and secure transport element on primary communication channel (1 102); and computing Secure transport element from inputs of transport key, lock challenge, UID and user response (1 104).

A further aspect of the invention provides that the step of establishing a lock-specific credential from registration of the Access Control Component (504) (304) by undergoing challenge-response interaction by the Authenticator (102) and the Access Control Component (504); and verifying computation outcome of challenge-response interaction by the Access Control Authentication Server (700) further comprises steps of first outcome of previously associated lock-specific HMAC key as presently computed, or alternatively PKC public-key as retrieved, on input of LID; second outcome of transport keys for recovery of presently received secure transport element and subsequent server-to-controller communication, as applicable; third outcome of lock challenge, UID and user response retrieved from secure transport element of interest; fourth outcome of verification status relating to lock challenge on input of measured context of present challenge-response interaction, and one of HMAC key or PKC public-key; and fifth outcome of verification status of relating to user access rights on input of UID with respect to previously established access control list; and onward transmission from access control server to authentication server on primary communications channel, of UID, lock challenge and user response, subject to positive verification of lock challenge and user access rights.

Yet another aspect of the invention provides that the challenge response interaction further comprises steps of first outcome of previously associated user-specific PKC public-key as retrieved, HMAC key as presently computed, on input of UID; second outcome of verification status relating to user response, on input of measured context of present challenge-response interaction, and one of PKC public-key or HMAC key; and reciprocal transmission from authentication server to access control server of verification status, on primary communications channel.

Still another aspect of the invention provides that the challenge response interaction further comprises steps of first outcome of lock response from input of particular lock challenge for enabling only pairwise corresponding challenge-response valuations results in singular output valuation corresponding to controller assuming unlocked state and all other challenge-response valuations results in non-singular output valuation corresponding to controller remaining in locked state; said outcome specifies singular valuation if lock challenge is verified as correct, and random non-singular valuation if lock challenge cannot be verified as correct; second outcome of secure transport element, on inputs of transport key and lock response; and reciprocal transmission from access control server to controller of secure transport element on primary communications channel.

Another aspect of the invention provides that the challenge response interaction further comprises steps of first outcome of lock response as retrieved from secure transport element, on input of transport key; second outcome of challenge-response valuation, on input of challenge and response valuations; and undertaking of actions on attached lock apparatus corresponding to challenge-response valuation. A further aspect of the invention provides that the challenge response interaction further comprises steps of state model comprising constituent initial, passive and active states enabling component transitions from initial state to default passive state upon successful conclusion of user registration process, and reverting to initial state upon reset of component; and component transitions from passive state to active state upon detection of physically proximate access control component, as associated with particular lock of interest and reverting to passive state upon either failure of such detection, or transmission of response to particular challenge from access control component,.

Yet another aspect of the invention provides that the challenge response interaction further comprises steps of undertaking of mechanical or electrical actions on first component of lock apparatus, in correspondence with lock challenge as transmitted to particular authenticator component of interest; and undertaking equivalent actions on second component of lock apparatus, in correspondence with random parameter generated on access control component lock apparatus remains in locked state pending receipt of lock response from access control server.

Still another aspect of the invention provides that the challenge response interaction further comprises steps of undertaking of mechanical or electrical actions on second component of lock apparatus, in correspondence with lock response as presently received from access control server enabling lock apparatus remains in locked state, unless pairwise inputs of lock challenge and response valuations results in output of singular valuation, corresponding to alignment of first and second components of lock apparatus allowing for physical attainment of unlocked state.

The present invention consists of features and a combination of parts hereinafter fully described and illustrated in the accompanying drawings, it being understood that various changes in the details may be made without departing from the scope of the invention or sacrificing any of the advantages of the present invention. BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS

To further clarify various aspects of some embodiments of the present invention, a more particular description of the invention will be rendered by references to specific embodiments thereof, which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail through the accompanying drawings.

FIG. 1.0 illustrates the general architecture of the system of the present invention.

FIG 1 .0a is a general diagram illustrating the application of the present invention.

FIG. 1.Ob is a diagram illustrating online registration for Authenticator Component.

FIG. 2.0 is a flowchart illustrating the general methodology of the present invention.

FIG. 3.0 is a flowchart illustrating the steps involved in performing access control operations through Access Control Component attached to a particular lock which provides for physical access control.

FIG. 3.0a is a diagram illustrating timeline of online registration for Authenticator’s Component.

FIG. 4.0 is a flowchart illustrating the steps involved in registering a user as an authenticator by associating an Authenticator Component to the user with an authentication service provider.

FIG. 4.0a is a diagram illustrating offline registration for Authenticator’s Component.

FIG. 4.0b is diagram illustrating timeline of offline registration for Authenticator’s Component.

FIG. 5.0 is a flowchart illustrating the steps involved in performing client-to-server transmission of second and fourth outcomes, on primary communication channel.

FIG. 5.0a is a flowchart illustrating the steps involved in server response. FIG. 6.0 is a flowchart illustrating the steps involved in performing client-to-server transmission of second and fourth outcomes, on primary communication channel which further comprises client test interaction.

FIG. 7.0 is a diagram illustrating registration of Access Control Component.

FIG. 7.0a is a diagram illustrating the timeline of registration of Access Control Component.

FIG. 8.0 is a flowchart illustrating the steps involved in performing authentication on identity of user through Authenticator Component on a mobile device in possession of the user.

FIG. 8.0a is a diagram illustrating Access Control Authentication Process.

FIG. 8.0b is a timeline diagram for Access Control Authentication.

FIG. 9.0 is a flowchart illustrating the steps involved in registering an Access Control Component with an access control provider and determining as to whether the user is allowed physical access controlled by a particular lock between registered authenticator and Access Control Component.

FIG. 10.0 is a flowchart illustrating the steps involved in verifying challenge outcome from the Access Control Component in context of present interation.

FIG. 10.0a is a flowchart illustrating the steps involved in verifying challenge outcome from the Access Control Component in context of present interaction.

FIG. 1 1.0 is a flowchart illustrating the steps involved in authenticating response outcome originated from Authenticator Component in context of interaction of particular challenge issued. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention relates to a system and method for physical access control by utilizing challenge response interaction. In particular, the present invention physical access control is provided as a single-use challenge response interaction between Authenticator and Access Control Components. Further, challenge-response interaction is conducted over a short range point-to-point channel between the Authenticator and Access Control Components. Hereinafter, this specification will describe the present invention according to the preferred embodiments. It is to be understood that limiting the description to the preferred embodiments of the invention is merely to facilitate discussion of the present invention and it is envisioned without departing from the scope of the appended claims.

Reference is first made to FIG. 1.0 which illustrates the general architecture of the system of the present invention. As illustrated in FIG. 1.0, the system (100) of the present invention for physical access control by utilizing challenge response interaction comprises at least one Authenticator Component (102) for online registration of user’s credential or offline registration of user’s credential; at least one User Registration Server (106) for registration of user’s credential and for generating user-specific credential; at least one Access Control Component (504) for communication with the Authenticator Component (102) during challenge response authentication; at least one Access Control Registration Server (502) for registration of Access Control Component (504) and for generating component lock-specific credential; at least one Access Control Authentication Server (700) for verification of outcome resulted from challenge response authentication between the Authentication Component and Access Control Component (504); and at least one Authentication Server (108) for authentication of user to access a physical device upon receipt of confirmation from the Access Control Authentication Server (700).

Reference is now made to FIG. 1.0a which is a general diagram illustrating the application of the present invention. FIG. 1.0a shows three possible states transition from the architecture and application perspectives. State 00 is a Null or zero state during registration process. State 10 is a passive state that is achieved after Barcode registration and activation state 01 in system. In addition, door scanning process can be triggered in state 1 1 during state 10 then move to the active state 20 once connection between Authenticator Component (102) and Access Control Component (504) have been successfully established. Reset state 12 transition is another possible transition from passive state to Null state. State 20 is the active state that can move the current state to passive state by two possible situations. One of the possible situations is that no door found or detected at state 21 during the active state 20 so it is moved to passive state 10. Another one refers to completed and successful handshake at state 22 between a mobile device and the door then state transition to the passive state. There are two options for user registration process, i.e. user registration via online channel and offline channel.

Reference is now made to FIG. 1 .0b which describes user registration procedure of proposed invention through the online channel. User (101 ) is required to install mobile application on user’s mobile device which will act as Authenticator Component (102). After the mobile application has been successfully installed on Authenticator Component (102), automatically the mobile state is in null state (00) and user (101 ) is able to choose to register through online channel. The Authenticator Component (102) then sends request for registration (101 ) including the registration payload to User Registration Server (106). The User Registration Server (106) verify the payload and send the verification SMS (103) to the user (101 ). The user (101 ) then verify the received SMS, if the SMS has been verified successfully the mobile application state is changed to passive state (10) and subsequently sends the notification (105) to the User Registration Server (106).

Reference is made to FIG. 2.0 which is a flowchart illustrating the general methodology of the present invention. As illustrated in FIG. 2.0, a user (101 ) is first registered as an authenticator by associating an Authenticator Component (102) to the user (101 ) with an authentication service provider (202). Subsequently, the Access Control Component (504) is registered with an access control provider and it is determined as to whether the user (101 ) is allowed physical access controlled by a particular lock between registered authenticator (102) and Access Control Component (504) (204). Thereafter, authentication is performed on identity of user (101 ) through Authenticator Component (102) on a mobile device in possession of the user (101 ) (206). Access control operations are performed through Access Control Component (504) attached to the particular lock which provides for physical access control (208). Subsequently, challenge outcome from the Access Control Component (504) is verified in context of present interaction (210). The response outcome originated from the Authenticator Component (102) is authenticated in context of interaction of particular challenge issued (212).

Reference is now made to FIG. 3.0 which is a flowchart illustrating the steps involved in performing access control operations through Access Control Component (504) attached to the particular lock which provides for physical access control. As illustrated in FIG. 3.0, in performing access control operations through Access Control Component (504) attached to the particular lock which provides for physical access control (208) further comprises steps of (300) establishing user-specific credential from registration of Authenticator Component (102) (302); and establishing lock-specific credential from registration of Access Control Component (504) (304) by undergoing challenge response interaction by the Authenticator (102) and the Access Control Component (504); and verifying computation outcome of challenge-response interaction by the Access Control Authentication Server ( 700); said challenge outcome originates from particular Access Control Component in context of present interaction, and said response outcome as can only be correctly computed from particular authentication component in context of particular challenge issued in present interaction.

In establishing a lock-specific credential from registration of the Access Control Component (504) (304) by undergoing challenge-response interaction by the Authenticator (102) and the Access Control Component (504); and verifying computation outcome of challenge-response interaction by the Access Control Authentication Server (700) further comprises steps of first outcome of previously associated lock-specific HMAC key as presently computed, or alternatively PKC public-key as retrieved, on input of LID; second outcome of transport keys for recovery of presently received secure transport element and subsequent server-to- controller communication, as applicable; third outcome of lock challenge, UID and user response retrieved from secure transport element of interest; fourth outcome of verification status relating to lock challenge on input of measured context of present challenge-response interaction, and one of HMAC key or PKC public-key; and fifth outcome of verification status of relating to user access rights on input of UID with respect to previously established access control list; and onward transmission from access control server to authentication server on primary communications channel, of UID, lock challenge and user response, subject to positive verification of lock challenge and user access rights.

The challenge response interaction of authentication verification on part of Authentication Server further comprises steps of first outcome of previously associated user-specific PKC public-key as retrieved, HMAC key as presently computed, on input of UID; second outcome of verification status relating to user response, on input of measured context of present challenge-response interaction, and one of PKC public-key or HMAC key; and reciprocal transmission from authentication server to access control server of verification status, on primary communications channel.

The challenge response interaction of access response on part of Access Control Server further comprises steps of first outcome of lock response from input of particular lock challenge for enabling only pairwise corresponding challenge-response valuations results in singular output valuation corresponding to controller assuming unlocked state and all other challenge-response valuations results in non-singular output valuation corresponding to controller remaining in locked state; said outcome specifies singular valuation if lock challenge is verified as correct, and random non-singular valuation if lock challenge cannot be verified as correct; second outcome of secure transport element, on inputs of transport key and lock response; and reciprocal transmission from access control server to controller of secure transport element on primary communications channel.

The challenge response interaction of access response on part of Access Control Server further comprises steps first outcome of lock response as retrieved from secure transport element, on input of transport key; second outcome of challenge-response valuation, on input of challenge and response valuations; and undertaking of actions on attached lock apparatus corresponding to challenge-response valuation.

The challenge response interaction for Authentication component on mobile device associated with particular user of interest further comprises steps of state model comprising constituent initial, passive and active states enabling component transitions from initial state to default passive state upon successful conclusion of user registration process, and reverting to initial state upon reset of component; and component transitions from passive state to active state upon detection of physically proximate access control component, as associated with particular lock of interest and reverting to passive state upon either failure of such detection, or transmission of response to particular challenge from access control component.

The challenge response interaction for Access Control Component as attached to particular lock apparatus of interest further comprises steps of undertaking of mechanical or electrical actions on first component of lock apparatus, in correspondence with lock challenge as transmitted to particular authenticator component of interest; and undertaking equivalent actions on second component of lock apparatus, in correspondence with random parameter generated on access control component lock apparatus remains in locked state pending receipt of lock response from access control server.

The conclusion of challenge response interaction for Access Control Component further comprises steps of undertaking of mechanical or electrical actions on second component of lock apparatus, in correspondence with lock response as presently received from access control server enabling lock apparatus remains in locked state, unless pairwise inputs of lock challenge and response valuations results in output of singular valuation, corresponding to alignment of first and second components of lock apparatus allowing for physical attainment of unlocked state.

Reference is now made to FIG. 3.0a which illustrates the timeline diagram of online registration for authenticator’s component. User (101 ) runs the mobile application (201 ) on Authenticator Component (102). Then Authenticator Component (102) generates public key and private key (21 1 ). Private key is generated by HMAC(k’,t1 ) based on k’= SHA-256(IMEI) or for IOS user SHA-256 and t1 = system time. In addition, the Authenticator Component (102) also generates storage key with hash(K_pri) and create transport pre-key with hash (storage key) (212) and sends combination of (Transport Pre-key+Kpub) as Registration Payload (213) to User Registration Server (106). The User Registration Server (106) sends public key (231 ) to Authentication Server (108) along with the registration payload. The Authentication Server (108) generates user identifier (UID) (241 ) based on universally unique identifier (UUID) and timestamp extracted from Registration payload. At step (242) , the Authentication Server (108) generates K_user = HMAC (K_master, UID), K_master is the master key for all users stored. The Authentication Server (108) generates Transport Key S = HMAC (Transport Pre-key, t2) (243) and also calculates SMS payload with encryption function based on parameters of (K_user, UID, hash(K_user, UID)) (244). Subsequently, the Authentication Server (108) stores UID and Public Key (245) into database and also sends UID and SMS payload (246) to the registration server (106). User Registration Server (106) forwards the SMS payload (232) to (102) then stores UID in lightweight directory access protocol (LDAP) (233). The Authenticator Component (102) which is a mobile device decrypts SMS payload (214) and further verifies the SMS content. (102) encrypts Storage Key Y, Encrypt E_y = (K_user, UID, hash(K_user, UID)) and then stores it (215). (102) displays status (216) to the user (101 ).

Reference is now made to FIG. 4.0 which is a flowchart illustrating the steps involved in registering a user as an authenticator by associating an Authenticator Component (102) to the user with an authentication service provider. As illustrated in FIG. 4.0, in registering a user (101 ) as an authenticator by associating an Authenticator Component (102) to the user (101 ) with an authentication service provider (202) further comprises steps of (400) first computing a first outcome of public key cryptography (PKC) for a private-key unique to Authenticator Component (102) and registration interaction of interest (402). Thereafter, a second outcome of corresponding PKC public-key for unique association of Authenticator Component (102) to entity of interest is computed (404). Subsequently, a third outcome of encryption key is computed for subsequent Authenticator Component’s (102) secure storage of server-side computation outcomes (406). A fourth outcome is computed for transport pre key for server-to-client secure transport of computation outcomes (408). Upon computing all outcomes, client-to-server transmission is performed on second and fourth outcomes, on primary communication channel (410). Reference is made to FIG. 4.0a which is a diagram illustrating offline registration for Authenticator’s Component. FIG. 4.0a merely describes a situation if the user is offline without any internet data on user’s mobile device. User (101 ) is required to install mobile application on user’s mobile device which acts as Authenticator Component (102). After the mobile application has been successfully installed on (102), the mobile state is automatically in null state (00) and a registration Barcode will appear when the mobile application is accessed. The registration Barcode having UID which is generated from the mobile device’s International Mobile Equipment Identity (IMEI), time and private key. User (101 ) is required to show the Barcode to browser (104) and let the application web service to capture the Barcode and send a user request registration (101 ) to User Registration Server (106) through online channel. Registration server then generates a public key and sent it to the user through short messaging system (SMS) (103). The mobile application then verifies the received SMS. If the SMS has been verified successfully the mobile application state is changed to passive state (10) and now the mobile application is able to generate authentication Barcode. In the final step of registration process, user (101 ) is required to show the authentication Barcode which appeared on (102) to the browser (104). Then the browser (104) sends it to the User Registration Server (106) in order to notify the User Registration Server (106) that the mobile application state has been successfully changed.

Reference is now made to FIG. 4.0b which is a diagram illustrating the timeline of offline registration for Authenticator’s Component (102). As illustrated in FIG. 4.0b, user (101 ) runs the mobile application (401 ) on Authenticator Component (102). Then (102) generates public key and private key (41 1 ). Private key is generated by HMAC(k’,t1 ) based on k’= SHA- 256(IMEI) or for IOS user SHA-256 and t1 = system time. In addition (102) also generates storage key with hash(Kpri) and create transport pre-key with hash(storage key) (412) and thereafter generates barcode based on combination of (Transport Pre-key+Kpub) (413). User (101 ) is required to present the barcode (402) which appeared on (102) to browser (104). Once (104) capture the Barcode, browser (104) decodes the Barcode (421 ). Then, (104) sends Barcode content (422) to User Registration Server (106). (106) send the public key (431 ) to the Authentication Server (108) along with the content of the Barcode. The Authentication Server (108) generates UID (441 ) based on UID and timestamp extracted from Barcode content. At step (442), the Authentication Server (108) generates Kuser = HMAC (Kmaster, UID) (442), Kmaster is the master key for all users stored. The Authentication Server (108) generates Transport Key S = HMAC (Transport Pre-key, t2) (443), and also calculates SMS payload with encryption function based on parameters of (Kuser, UID, hash(Kuser, UID)) (444). Then, the Authentication Server (108) stores UID and Public Key (445) into database and also sends UID and SMS payload (446) to User Registration Server (106). User Registration Server (106) forwards the SMS payload (432) to (102) and subsequently stores UID in LDAP (433). (102) decrypts SMS payload (414) that is received through SMS and further performs verification for SMS content. Mobile device (102) encrypts Storage Key Y, Encrypt Ey = (Kuser, UID, hash(Kuser, UID)) (415) and stores it. Finally, (102) displays status (416) to the user (101 ).

Reference is now made to FIG. 5.0 which is a flowchart illustrating the steps involved in performing client-to-server transmission of second and fourth outcomes, on primary communication channel. As illustrated in FIG. 5.0, in performing client-to-server transmission of second and fourth outcomes, on primary communication channel (410) further comprises server response with steps of (500) of computing a first outcome of entity identifier (EID) with public key and private key for unique association of client-side component to entity of interest (21 1 ) (502); computing a second outcome of HMAC key for Server verification of client association with registration interaction, and compute Client component engagement in challenge-response interactions (21 1 ) (504); computing a third outcome of transport key from inputs of transport pre-key and context of present registration (212) (506); computing a fourth outcome of secure transport element from inputs of first, second and third outcomes, for subsequent client-side recovery and verification (508); and performing server-to-client transmission of fourth outcome (213), on secondary communication channel, as out of band (OOB) with respect to primary communication channel (510).

Reference is now made to FIG. 5.0a which is a flowchart illustrating the steps involved in server response. The server response (500) further comprises server finalization which comprises steps of (500a) computing a first outcome of FIMAC verification from inputs of established FIMAC key and measured context of registration (502a) and subsequently computing a second outcome of PKC signature verification from inputs of established PKC public-key and measured context of registration (504a).

Reference is now made to FIG. 6.0 which is a flowchart illustrating the steps involved in performing client-to-server transmission of second and fourth outcomes, on primary communication channel which further comprises client test interaction. As illustrated in FIG. 6.0, a first outcome of EID and FIMAC key as retrieved from secure transport element of interest is computed (241 ) (602). Upon computing a first outcome, a second outcome of FIMAC authenticator is computed from inputs of retrieved FIMAC key and measured context of registration (242) (604). Thereafter, upon computing of a second outcome, a third outcome of PKC signature is computed from inputs of PKC private-key, FIMAC authenticator and context of registration (606). Subsequently, a fourth outcome of secure storage element is computed from inputs of storage key, EID and HMAC key, for subsequent client-side recovery and verification prior to engagement in challenge-response interaction (608). Upon computation of the first to fourth outcome, client-to-server transmission of first, and one of second and third outcomes is performed on primary communications channel (610).

Reference is now made to FIG. 7.0 which is a diagram illustrating registration of Access Control Component. As illustrated in FIG. 7.0, the Access Control Component (504) is any loT device which supports wifi or Bluetooth connectivity. The first Access Control Registration Server (502) generates a unique access control ID (LID) and sends LID + Flmac(t) (501 ) to Access Control Component (504) to be stored permanently. Reference is then made to FIG. 7.0a which is a diagram illustrating the timeline of registration of Access Control Component (504). As illustrated in FIG. 7.0a, the first Access Control Registration sever (502) generates a unique access control ID (LID) + Flmac(t) (600) and sends them (601 ) to the Access Control Component (504) to be stored permanently.

FIG. 8.0 is a flowchart illustrating the steps involved in performing authentication on identity of user through Authenticator Component (102) on a mobile device in possession of the user. In performing authentication on identity of user through Authenticator Component (102) on a mobile device in possession of the user (101 ) (206) further comprises steps of (800) computing of PKC private-key at client-side (21 1 ) (802); saving into client-side secure storage (212) unique identifier (UID) (241 ) and hash message authentication code (FIMAC) key assigned by Registration Server (804); computing FIMAC authenticator or PKC signature at client-side of UID (806); verifying of authenticator or signature correctness at server-side verification (808); and associating the UID and PKC public-key with the user as registered (810).

Reference is now made to FIG. 8.0a. FIG 8.0a is a diagram illustrating Access Control Authentication Process. As illustrated in FIG. 8.0a, user (101 ) accesses a mobile application which has been installed in user’s Authenticator Component (102). The Authenticator Component (102) can be any mobile device which runs on Apple’s IOS or Android OS. Then (100) shakes (102) to trigger the Bluetooth Low Energy (BLE) scanning operation. If Bluetooth in the Authenticator Component (102) is not in ON” mode, (100) is requested to switch on the Bluetooth device on the mobile device with a pop-up message. (102) performs scanning to discover the challenge which is broadcasted (701 ) by the nearest Access Control Component (104). The present invention is able to work with any loT device as long the device has a support of both bluetooth low energy (BLE) and wireless local area network (WIFI) connection. Once the connection has been established, the Authenticator Component (102) sends the Authentication payload (703) to the Access Control Component (504). The Access Control Component (504) combines it with another information such as lock ID (LID), user id and then send it as Authentication Packet (705) to the Access Control Authentication Server (700) through online channel. (700) then verifies it, the verification result is encrypted and being sent from (707) to (504). (504) decrypts the encrypted result and performs an action based on the result, opens the door if verification result is successful. Otherwise close the door or refuse to grant access. After registration processes are completed for both authenticator and Access Control Component (504), the authentication process can be performed by user in order to be able to access a specific door.

Reference is now made to FIG. 8.0b which illustrates the timeline diagram for access control’s authentication process. User (101 ) runs the mobile application (801 ) which has been installed on (102). (100) shakes (102) in order to trigger BLE scanning (802) to obtain the door id which is broadcasted (821 ) by (504). (102) then connects to the nearest (81 1 ) Access Control Component (504). Once the BLE connection has been established (504) HashMac is generated over time (Hmac(t)) (822) then sends it with LID (823) to (102). Once (102) receives (823), (102) generates an authentication signature (812) based on (823) and send the generated signature and UID (813) to (504). (504) combines it with (LID) and Hmac(t) and sends them (823) to Access Control Authentication Server (700) through internet. (700) looks up UID and LID (831 ) in Database and verify received HMAC(t’) (832). If HMAC(t’) is verified, (504) sends UID + LID + Hmac(t) + signature (833) to Authentication Server (108). The Authentication Server (108) verifies the received signature (841 ) and send the result (842) back to (700). If the result is 1 , the signature has been successfully verified, otherwise 0. (700) generates HMAC(t’)_bar (834) and sends it from (835) to (504). If (504) successfully complements the received HMAC(t’)_bar the door will be opened. Otherwise, the door will be closed.

Reference is now made to FIG. 9.0 which is a flowchart illustrating the steps involved in registering an Access Control Component (504) with an access control provider and determining as to whether the user is allowed physical access controlled by a particular lock between registered authenticator and Access Control Component (504). As illustrated in FIG. 9.0 the PKC private-key is first computed at the client-side (902) and an unique access control identifier (LID) (600) and HMAC key is computed at client-side secure storage of server (904). Thereafter, the HMAC authenticator or PKC signature is computed with the client-side presentation of LID (906). Subsequently, authenticator or signature correctness is verified at the server-side verification; and associating the LID and PKC public-key with particular lock (908).

Reference is now made to FIG. 10.0 which is a flowchart which illustrates the steps involved in verifying challenge outcome from the Access Control Component (504) in context of preset interaction (210). As illustrated in FIG. 10.0, In verifying challenge outcome from the Access Control Component (504) in context of present interaction (210) further comprises steps of (1000) computing a first outcome of controller-specific PKC private-key (1002) and subsequently computing a second outcome of LID and HMAC key retrieved from controller- side secure storage, on input of PKC private-key (822) (1004). Thereafter, a third outcome of encryption keys is computed for transport security on subsequent controller-server communications, and HMAC authenticator, on inputs of retrieved HMAC key and measured context of present challenge-response interaction (823) and further performing controller-to- device transmission of LID, and one of HMAC authenticator or PKC signature as lock challenge, on short-range point-to-point channel (812) (1006). Subsequently, a fourth outcome of PKC signature is computed on inputs of PKC private-key and context of present challenge-response interaction (1008). Thereafter, controller-to-device transmission of LID and one of HMAC authenticator or PKC signature is undertaken as lock challenge on short- range point-to-point channel (1010).

Reference is now made to FIG. 10.0a which is a flowchart illustrating the steps involved in verifying challenge outcome from the Access Control Component (504) in context of present interaction. As illustrated in FIG. 10.0a, a first outcome of user-specific PKC private-key is computed (1002a). Subsequently, a second outcome of UID and HMAC key as retrieved from device-side secure storage is computed on input of PKC private-key (822) (1004a). Thereafter, a third outcome of PKC signature is computed on inputs of PKC private-key, measured context of present challenge-response interaction, and controller-computed challenge (812) (1006a) and a fourth outcome of HMAC authenticator is computed on inputs of retrieved HMAC key, and controller-computed challenge; and upon reciprocal device-to- controller transmission of UID, and one of PKC signature or HMAC authenticator as user response, on previously established short-range point-to-point channel (813) (1008a). Thereafter, reciprocal device-to-controller transmission of UID, and one of PKC signature or HMAC authenticator is undertaken as user response, on established short-range point-to- point channel (1010a).

Reference is now made to FIG. 1 1.0 which is a flowchart illustrating the steps involved in authenticating response outcome originated from Authenticator Component (102) in context of interaction of particular challenge issued. As illustrated in FIG. 1 1.0, onward transmission is performed from controller to access control server of LID and secure transport element on primary communication channel (1 102). Thereafter, Secure transport element is computed from inputs of transport key, lock challenge, UID and user response (1 104).

The present invention relates to a secure physical access control system and a method of cryptographic computations, and communications which arising from outcomes of such computations, as undertaken by authenticator, access control server, Access Control Authentication Server (700) and registration component to particular user associating with the Authenticator Component (102) with access control provider. The present invention particularly provides a secure a passage by using challenge-response authentication to prevent replay attack. Unless the context requires otherwise or specifically stated to the contrary, integers, steps or elements of the invention recited herein as singular integers, steps or elements clearly encompass both singular and plural forms of the recited integers, steps or elements.

Throughout this specification, unless the context requires otherwise, the word“comprise”, or variations such as“comprises” or“comprising”, will be understood to imply the inclusion of a stated step or element or integer or group of steps or elements or integers, but not the exclusion of any other step or element or integer or group of steps, elements or integers. Thus, in the context of this specification, the term“comprising” is used in an inclusive sense and thus should be understood as meaning“including principally, but not necessarily solely”.

Claims

1. A system (100) for physical access control by utilizing challenge response interaction comprises:

at least one Authenticator Component (102) for online registration of user’s credential or offline registration of user’s credential;

at least one User Registration Server (106) for registration of user’s credential and for generating user-specific credential;

at least one Access Control Component (504) for communication with the Authenticator Component (102) during challenge response authentication; at least one Access Control Registration Server (502) for registration of Access Control Component (504) and for generating a component lock- specific credential;

at least one Access Control Authentication Server (700) for verification of outcome resulted from challenge response authentication between the Authentication Component (102) and Access Control Component (504); and at least one Authentication Server (108) for authentication of user to access a physical device upon receipt of confirmation from the Access Control Authentication Server (700).

2. A method (200) for physical access control by utilizing challenge response interaction comprises steps of:

registering a user (101 ) as an authenticator by associating an Authenticator Component (102) to the user (101 ) with an authentication service provider (202);

registering an Access Control Component (504) with an access control provider and determining as to whether the user (101 ) is allowed physical access controlled by a particular lock between registered authenticator (102) and Access Control Component (504) (204);

performing authentication on identity of user (101 ) through Authenticator Component (102) on a mobile device in possession of the user (101 ) (206); performing access control operations through the Access Control Component (504) attached to the particular lock which provides for physical access control (208);

verifying challenge outcome from the Access Control Component (504) in context of present interaction (210); and authenticating response outcome originated from the Authenticator Component (102) in context of interaction of particular challenge issued (212);

characterized by the steps of

performing access control operations through the Access Control Component (504) attached to the particular lock which provides for physical access control (208) further comprises steps of (300):

establishing a user-specific credential from registration of the Authenticator Component (102) (302); and

establishing a lock-specific credential from registration of the Access Control Component (504) (304) by undergoing challenge-response interaction by the Authenticator (102) and the Access Control Component (504); and verifying computation outcome of challenge- response interaction by the Access Control Authentication Server ( 700); said challenge outcome originates from particular Access Control Component in context of present interaction, and said response outcome as can only be correctly computed from particular authentication component in context of particular challenge issued in present interaction.

3. The method (200) according to Claim 2, wherein registering a user (101 ) as an authenticator by associating an Authenticator Component (102) to the user (101 ) with an authentication service provider (202) further comprises steps of (400):

computing a first outcome of public key cryptography (PKC) for a private-key unique to Authenticator Component (102) and registration interaction of interest (402);

computing a second outcome of corresponding PKC public-key for unique association of Authenticator Component (102) to entity of interest (404);

computing a third outcome of encryption key for Authenticator Component’s (102) secure storage of server-side computation outcomes (406); computing a fourth outcome of transport pre-key for server-to-client secure transport of computation outcomes (408); and

performing client-to-server transmission of second and fourth outcomes, on primary communication channel (410).

4. The method (200) according to Claim 3, wherein performing client-to-server transmission of second and fourth outcomes, on primary communication channel (410) further comprises server response with steps of (500):

computing a first outcome of entity identifier (EID) with public key and private key for unique association of client-side component to entity of interest (21 1 ) (502);

computing a second outcome of hash message authentication code (HMAC) key for Authentication Server (108) verification of client association with registration interaction, and compute Client component engagement in challenge-response interactions (21 1 ) (504);

computing a third outcome of transport key from inputs of transport pre-key and context of present registration (212) (506);

computing a fourth outcome of secure transport element from inputs of first, second and third outcomes, for subsequent client-side recovery and verification (508); and

performing server-to-client transmission of fourth outcome (213), on secondary communication channel, as out of band (OOB) with respect to primary communication channel (510).

5. The method (200) according to Claim 4, wherein server response (500) further comprises server finalization which comprises steps of (500a):

computing a first outcome of hash message authentication code (HMAC) verification from inputs of established HMAC key and measured context of registration (502a); and

computing a second outcome of PKC signature verification from inputs of established PKC public-key and measured context of registration (504a).

6. The method (200) according to Claim 3, wherein performing client-to-server transmission of second and fourth outcomes, on primary communication channel (410) further comprises client test interaction with steps of (600):

computing a first outcome of EID and HMAC key as retrieved from secure transport element of interest (241 ) (602);

computing a second outcome of HMAC authenticator from inputs of retrieved HMAC key and measured context of registration (242) (604);

computing a third outcome of PKC signature from inputs of PKC private-key, HMAC authenticator and context of registration (606); computing a fourth outcome of secure storage element from inputs of storage key, EID and HMAC key, for subsequent client-side recovery and verification prior to engagement in challenge-response interaction (608); and

performing client-to-server transmission of first, and one of second and third outcomes, on primary communications channel (610).

7. The method (200) according to Claim 2, wherein performing authentication on identity of user (101 ) through Authenticator Component (102) on a mobile device in possession of the user (101 ) (206) further comprises steps of (800):

computing of PKC private-key at a client-side (21 1 ) (802);

saving into client-side secure storage (212), unique identifier (UID) (241 ) and hash message authentication code (HMAC) key, assigned by Registration Server (804);

computing HMAC authenticator or PKC signature at client-side (806); verifying of authenticator or signature correctness at server-side verification (808); and

associating the UID and PKC public-key with the user as registered (810).

8. The method (200) according to Claim 2, wherein registering an Access Control Component (504) with an access control provider and determining as to whether the user (101 ) is allowed physical access controlled by a particular lock between registered authenticator (102) and Access Control Component (504) (204) further comprises steps of (900):

computing of the PKC private-key at client-side (902);

saving into client-side secure storage, unique access control identifier (LID)

(600) and HMAC key assigned by registration server (904);

computing of HMAC authenticator or PKC signature with the client-side presentation of LID (906);

verifying authenticator or signature correctness at server-side verification; and associating the LID and PKC public-key with particular lock as registered (908).

9. The method (200) according to Claim 2, wherein verifying challenge outcome from the Access Control Component (504) in context of present interaction (210) further comprises steps of (1000):

computing a first outcome of controller-specific PKC private-key (1002); computing a second outcome of LID and HMAC key retrieved from controller- side secure storage, on input of PKC private-key (822) (1004);

computing a third outcome of encryption keys for transport security on subsequent controller-server communications, and HMAC authenticator, on inputs of retrieved HMAC key;

measured context of present challenge-response interaction (823) and performing controller-to-device transmission of LID, and one of HMAC authenticator or PKC signature as lock challenge, on short-range point-to- point channel (812) (1006);

computing a fourth outcome of PKC signature on inputs of PKC private-key and context of present challenge-response interaction (1008); and undertaking controller-to-device transmission of LID, and one of HMAC authenticator or PKC signature as lock challenge on short-range point-to- point channel (1010).

10. The method (200) according to Claim 9, wherein verifying challenge outcome from the Access Control Component (504) in context of present interaction (210) further comprises steps of (1000a):

computing a first outcome of user-specific PKC private-key as computed (1002a);

computing a second outcome of UID and HMAC key as retrieved from device-side secure storage, on input of PKC private-key (822) (1004a);

computing a third outcome of PKC signature on inputs of PKC private-key, measured context of present challenge-response interaction, and controller- computed challenge (812) (1006a);

computing a fourth outcome of HMAC authenticator on inputs of retrieved HMAC key, and controller-computed challenge upon reciprocal device-to- controller transmission of UID, and one of PKC signature or HMAC authenticator as user response, on previously established short-range point- to-point channel (813) (1008a); and

undertaking reciprocal device-to-controller transmission of UID, and one of PKC signature or HMAC authenticator as user response, on established short-range point-to-point channel (1010a).

1 1 . The method (200) according to Claim 2, wherein authenticating response outcome originated from Authenticator Component (102) in context of interaction of particular challenge issued (212) further comprises steps of (1 100):

performing onward transmission from controller to Access Control Component (504) of LID and secure transport element on primary communication channel (1 102); and

computing Secure transport element from inputs of transport key, lock challenge, UID and user response (1 104).

12. The method (200) according to Claim 2, wherein establishing a lock-specific credential from registration of the Access Control Component (504) (304) by undergoing challenge-response interaction by the Authenticator (102) and the Access Control Component (504); and verifying computation outcome of challenge- response interaction by the Access Control Authentication Server (700) further comprises steps of:

first outcome of previously associated lock-specific HMAC key as presently computed, or alternatively PKC public-key as retrieved, on input of LID;

second outcome of transport keys for recovery of presently received secure transport element and subsequent server-to-controller communication, as applicable;

third outcome of lock challenge, UID and user response retrieved from secure transport element of interest;

fourth outcome of verification status relating to lock challenge on input of measured context of present challenge-response interaction, and one of HMAC key or PKC public-key; and

fifth outcome of verification status of relating to user access rights on input of UID with respect to previously established access control list; and onward transmission from access control server to authentication server on primary communications channel, of UID, lock challenge and user response, subject to positive verification of lock challenge and user access rights.

13. The method (200) according to Claim 12 wherein the challenge response interaction further comprises steps of:

first outcome of previously associated user-specific PKC public-key as retrieved, HMAC key as presently computed, on input of UID; second outcome of verification status relating to user response, on input of measured context of present challenge-response interaction, and one of PKC public-key or HMAC key; and

reciprocal transmission from authentication server to access control server of verification status, on primary communications channel.

14. The method (200) according to Claim 12, wherein the challenge response interaction further comprises steps of:

first outcome of lock response from input of particular lock challenge for enabling only pairwise corresponding challenge-response valuations results in singular output valuation corresponding to controller assuming unlocked state and all other challenge-response valuations results in non-singular output valuation corresponding to controller remaining in locked state; said outcome specifies singular valuation if lock challenge is verified as correct, and random non-singular valuation if lock challenge cannot be verified as correct;

second outcome of secure transport element, on inputs of transport key and lock response; and

reciprocal transmission from access control server to controller of secure transport element on primary communications channel.

15. The method (200) according to Claim 12, wherein the challenge response interaction further comprises steps of:

first outcome of lock response as retrieved from secure transport element, on input of transport key;

second outcome of challenge-response valuation, on input of challenge and response valuations; and

undertaking of actions on attached lock apparatus corresponding to challenge-response valuation.

16. The method (200) according to Claim 12, wherein the challenge response interaction further comprises steps of:

state model comprising constituent initial, passive and active states enabling component transitions from initial state to default passive state upon successful conclusion of user registration process, and reverting to initial state upon reset of component; and component transitions from passive state to active state upon detection of physically proximate access control component, as associated with particular lock of interest and reverting to passive state upon either failure of such detection, or transmission of response to particular challenge from access control component.

17. The method (200) according to Claim 12, wherein the challenge response interaction further comprises steps of:

undertaking of mechanical or electrical actions on first component of lock apparatus, in correspondence with lock challenge as transmitted to particular authenticator component of interest; and

undertaking equivalent actions on second component of lock apparatus, in correspondence with random parameter generated on access control component lock apparatus remains in locked state pending receipt of lock response from access control server.

18. The method (200) according to Claim 12, wherein the challenge response interaction further comprises steps of:

undertaking of mechanical or electrical actions on second component of lock apparatus, in correspondence with lock response as presently received from access control server enabling lock apparatus remains in locked state, unless pairwise inputs of lock challenge and response valuations results in output of singular valuation, corresponding to alignment of first and second components of lock apparatus allowing for physical attainment of unlocked state.