US20220408261A1 - Wireless access credential system - Google Patents
Wireless access credential system Download PDFInfo
- Publication number
- US20220408261A1 US20220408261A1 US17/863,065 US202217863065A US2022408261A1 US 20220408261 A1 US20220408261 A1 US 20220408261A1 US 202217863065 A US202217863065 A US 202217863065A US 2022408261 A1 US2022408261 A1 US 2022408261A1
- Authority
- US
- United States
- Prior art keywords
- credential
- mobile device
- access control
- access
- ble
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 claims abstract description 286
- 238000004891 communication Methods 0.000 claims description 201
- 230000015654 memory Effects 0.000 claims description 97
- 230000002085 persistent effect Effects 0.000 claims description 83
- 230000004044 response Effects 0.000 claims description 62
- 230000007246 mechanism Effects 0.000 claims description 36
- 238000007726 management method Methods 0.000 description 183
- 238000004422 calculation algorithm Methods 0.000 description 60
- 230000006870 function Effects 0.000 description 54
- 230000002093 peripheral effect Effects 0.000 description 51
- 238000012545 processing Methods 0.000 description 37
- 230000008569 process Effects 0.000 description 35
- 238000010586 diagram Methods 0.000 description 30
- 238000012795 verification Methods 0.000 description 25
- 238000005096 rolling process Methods 0.000 description 13
- 238000013478 data encryption standard Methods 0.000 description 12
- 238000012790 confirmation Methods 0.000 description 10
- 239000000284 extract Substances 0.000 description 10
- 238000012550 audit Methods 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 9
- 238000009795 derivation Methods 0.000 description 8
- 230000003993 interaction Effects 0.000 description 8
- 230000001815 facial effect Effects 0.000 description 7
- 210000003813 thumb Anatomy 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 230000009471 action Effects 0.000 description 5
- 230000004888 barrier function Effects 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- 241000270295 Serpentes Species 0.000 description 4
- 241001441724 Tetraodontidae Species 0.000 description 4
- 230000004913 activation Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 238000013475 authorization Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 239000013589 supplement Substances 0.000 description 3
- -1 HOGP Chemical compound 0.000 description 2
- 230000010267 cellular communication Effects 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000010079 rubber tapping Methods 0.000 description 2
- 150000003839 salts Chemical class 0.000 description 2
- 101100477360 Arabidopsis thaliana IPSP gene Proteins 0.000 description 1
- QRABSTLMZWUWIQ-UHFFFAOYSA-N CSCP Chemical compound CSCP QRABSTLMZWUWIQ-UHFFFAOYSA-N 0.000 description 1
- 102100035024 Carboxypeptidase B Human genes 0.000 description 1
- 238000004252 FT/ICR mass spectrometry Methods 0.000 description 1
- 101000946524 Homo sapiens Carboxypeptidase B Proteins 0.000 description 1
- 208000018208 Hyperimmunoglobulinemia D with periodic fever Diseases 0.000 description 1
- KOTOUBGHZHWCCJ-UHFFFAOYSA-N IPSP Chemical compound CCS(=O)CSP(=S)(OC(C)C)OC(C)C KOTOUBGHZHWCCJ-UHFFFAOYSA-N 0.000 description 1
- 206010072219 Mevalonic aciduria Diseases 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000000704 physical effect Effects 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- DTXLBRAVKYTGFE-UHFFFAOYSA-J tetrasodium;2-(1,2-dicarboxylatoethylamino)-3-hydroxybutanedioate Chemical compound [Na+].[Na+].[Na+].[Na+].[O-]C(=O)C(O)C(C([O-])=O)NC(C([O-])=O)CC([O-])=O DTXLBRAVKYTGFE-UHFFFAOYSA-J 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00309—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00857—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys where the code of the data carrier can be programmed
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/03—Protecting confidentiality, e.g. by encryption
- H04W12/037—Protecting confidentiality, e.g. by encryption of the control plane, e.g. signalling traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
- H04W12/041—Key generation or derivation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00309—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
- G07C2009/00388—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks code verification carried out according to the challenge/response method
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00309—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
- G07C2009/00412—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks the transmitted data signal being encrypted
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00857—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys where the code of the data carrier can be programmed
- G07C2009/00865—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys where the code of the data carrier can be programmed remotely by wireless communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/80—Wireless
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys
Definitions
- Access control systems typically involve the use of credentials to manage the operation of an access control device (e.g., a lock device).
- credentials may be assigned to a particular user or device and are often physical in nature, forming at least a portion of, for example, a smartcard, proximity card, key fob, token device, or mobile device.
- credential systems generally require an interaction between the credential and a reader device (e.g., on or secured to the access control device) such that the reader device may read the credential and determine whether access should be granted.
- a user may be required to swipe, tap, or otherwise present the credential to the reader device.
- the user intent is verified via the user's interaction with the reader device (e.g., turning a handle/knob, capacitive touch sense, etc.).
- access control systems generally require an active physical action on behalf of the user in order to grant the user access via the access control device.
- a method of using a wireless access credential in an access control system may include at least a server system, a mobile device, and an access control edge device.
- the method may include encrypting, by the server system and using a symmetric cryptographic key stored by the server system and the access control edge device, a credential blob including a wireless access credential and a first public cryptographic key provided by the mobile device, wherein the first public cryptographic key and a first private cryptographic key are a first asymmetric cryptographic key pair stored by the mobile device, transmitting, by the server system, the encrypted credential blob to the mobile device for storage by the mobile device, establishing a secure wireless communication connection between the mobile device and an access control edge device including generating a shared cryptographic key, encrypting, by the mobile device and using the shared cryptographic key, a credential message including the encrypted credential blob, cryptographically signing, by the mobile device and using the first private cryptographic key, the encrypted credential message, transmitting, by the mobile device, the
- the method may further include cryptographically signing, by the mobile device and using the first private cryptographic key, a credential request including the first public cryptographic key, transmitting, by the mobile device, the signed credential request to the server system, and verifying, by the server system, the credential request signature based on the first public cryptographic key retrieved from the signed credential request, wherein encrypting the credential blob comprises encrypting the credential blob in response to successful verification of the credential request signature.
- the method may further include generating, by the server system, a keyed hash of the encrypted credential blob using the symmetric cryptographic key, wherein transmitting the encrypted credential blob further comprises transmitting the keyed hash to the mobile device for storage by the mobile device, and wherein the credential message further includes the keyed hash.
- the keyed hash may be a keyed-hash message authentication code (HMAC).
- HMAC keyed-hash message authentication code
- the method may further include verifying, by the access control edge device and using the symmetric cryptographic key, the keyed hash in the credential message in response to decrypting the encrypted and signed credential message and verifying, by the access control edge device, the credential message signature based on the first public cryptographic key extracted from the decrypted credential blob.
- the method may further include encrypting, by the access control edge device and using the shared cryptographic key, challenge data, transmitting, by the access control edge device, the encrypted challenge data to the mobile device, and decrypting, by the mobile device and using the shared cryptographic key, the encrypted challenge data, wherein the credential message further includes the challenge data.
- the method may further include verifying, by the access control edge device, the challenge data in response to decrypting the encrypted and signed credential message.
- the method may further include cryptographically signing, by the server system, the encrypted credential blob using a second private cryptographic key, wherein the second private cryptographic key and a second public cryptographic key are a second asymmetric cryptographic key pair stored by the server system, and wherein the second public cryptographic key is stored by the access control edge device, wherein transmitting the encrypted credential blob comprises transmitting the signed and encrypted credential blob to the mobile device for storage by the mobile device, and wherein the credential message includes the signed and encrypted credential blob.
- the method may further include verifying, by the access control edge device, the encrypted credential blob signature based on the second public cryptographic key retrieved from a memory of the access control edge device and verifying, by the access control edge device, the credential message signature based on the first public cryptographic key extracted from the decrypted credential blob.
- the method may further include encrypting, by the access control edge device and using the shared cryptographic key, pin request data, transmitting, by the access control edge device, the encrypted pin request data to the mobile device, decrypting, by the mobile device and using the shared cryptographic key, the pin request data, receiving, by the mobile device, a pin value entered by a user of the mobile device, encrypting, by the mobile device and using the shared cryptographic key, a pin response including the pin value and the pin request data, transmitting, by the mobile device, the encrypted pin response to the access control edge device, decrypting, by the access control edge device and using the shared cryptographic key, the pin response, verifying, by the access control edge device, the pin request data in response to decrypting the pin response, and authenticating the pin value in response to successful verification of the pin request data.
- unlocking the lock mechanism may include unlocking the lock mechanism in response to successful authentication of the wireless access credential and successful authentication of the pin value.
- the first asymmetric cryptographic key pair may be an elliptical curve cryptography key pair.
- generating the shared cryptographic key may include performing an Elliptical Curve Diffie-Hellman key exchange.
- the method may further include encrypting, by the mobile device and using a third public cryptographic key, the encrypted credential blob received from the server system prior to storage of the encrypted credential blob, wherein the third public cryptographic key and a second private cryptographic key are a third asymmetric cryptographic key pair stored by the mobile device and decrypting, by the mobile device and using the third private cryptographic key, the stored encrypted credential blob prior to building the credential message.
- an access control system may include an access control edge system comprising a lock mechanism, a mobile device, and a server system to encrypt, using a symmetric cryptographic key stored by the server system and the access control edge system, a credential blob including a wireless access credential and a first public cryptographic key provided by the mobile device, wherein the first public cryptographic key and a first private cryptographic key are an asymmetric cryptographic key pair stored by the mobile device and transmit the encrypted credential blob to the mobile device for storage by the mobile device.
- an access control edge system comprising a lock mechanism, a mobile device, and a server system to encrypt, using a symmetric cryptographic key stored by the server system and the access control edge system, a credential blob including a wireless access credential and a first public cryptographic key provided by the mobile device, wherein the first public cryptographic key and a first private cryptographic key are an asymmetric cryptographic key pair stored by the mobile device and transmit the encrypted credential blob to the mobile device for storage by
- the mobile device may be to establish a secure wireless communication connection between the mobile device and an access control edge system including generating a shared cryptographic key, encrypt, using the shared cryptographic key, a credential message including the encrypted credential blob, cryptographically sign the encrypted credential message using the first private cryptographic key, and transmit the encrypted and signed credential message to the access control edge system.
- the access control edge system may be to decrypt, using the shared cryptographic key, the encrypted and signed credential message to extract the encrypted credential blob, decrypt, using the symmetric cryptographic key, the encrypted credential blob to extract the wireless access credential, and unlock the lock mechanism in response to successful authentication of the wireless access credential.
- the server system may include at least one cloud-based server.
- the server system may include a credential management system, a key management system, and a mobile access hub.
- the access control edge system may include a Bluetooth chipset, a main chipset, and a cryptography chipset.
- an access control edge device for simultaneous connectivity may include a Bluetooth Low Energy (BLE) communication circuitry, a processor, and a memory comprising a plurality of instructions stored thereon that, in response to execution by the processor, causes the access control edge device to establish a first persistent communication connection with a first device using the BLE communication circuitry and establish a second persistent communication connection with a second device using the BLE communication circuitry without dropping the first persistent communication connection with the first device.
- BLE Bluetooth Low Energy
- the first device may be a gateway device and the second device may be a mobile device.
- the memory may include a local access control database and the plurality of instructions may further cause the access control edge device to receive a BLE access credential from the mobile device while simultaneously receiving a real-time update from a host server via the gateway device and perform an access control decision based on the BLE access credential and the local access control database.
- the plurality of instructions may further cause the access control edge device to transmit, via the BLE communication circuitry, a BLE advertisement to remote devices in a vicinity of the access control edge device while the first persistent communication connection is established, and wherein establishing the second persistent communication connection with the second device may include establishing the second persistent communication connection with the mobile device in response to receipt of the BLE advertisement by the mobile device.
- the plurality of instructions may further cause the access control edge device to receive a BLE access credential from the mobile device via the second persistent communication connection and transmit the BLE access credential to an access control system via the first persistent communication connection with the gateway device to perform an access control decision.
- the access control edge device may include a credential reader.
- the access control edge device may include a physical lock mechanism.
- the first device may be a first mobile device and the second device may be a second mobile device.
- the first device may be an administrative device and the second device may be a user mobile device.
- a method for simultaneous connectivity with an access control edge device may include establishing, by the access control edge device, a first persistent communication connection with a first device using a BLE communication circuitry of the access control edge device and establishing, by the access control edge device, a second persistent communication connection with a second device using the BLE communication circuitry without dropping the first persistent communication connection with the first device.
- establishing the first persistent communication connection may include establishing the first persistent communication connection with a gateway device and establishing the second persistent communication connection may include establishing the second persistent communication connection with a mobile device without dropping the first persistent communication connection with the first device.
- the method may further include receiving, by the access control edge device, a BLE access credential from the mobile device while simultaneously receiving a real-time update from a host server via the gateway device and performing, by the access control edge device, an access control decision based on the BLE access credential and a local access control database stored on the access control edge device.
- the method may further include transmitting, by the access control edge device using the BLE communication circuitry, a BLE advertisement to remote devices in a vicinity of the access control edge device while the first persistent communication connection with the gateway device is established and wherein establishing the second persistent communication connection with the second device may include establishing the second persistent communication connection with the mobile device in response to receipt of the BLE advertisement by the mobile device.
- the method may further include receiving, by the access control edge device, a BLE access credential from the mobile device via the second persistent communication connection and transmitting, by the access control edge device, the BLE access credential to an access control system via the first persistent communication connection with the gateway device to perform an access control decision.
- establishing the first persistent communication connection may include establishing the first persistent communication connection with a first mobile device and establishing the second persistent communication connection may include establishing the second persistent communication connection with a second mobile device without dropping the first persistent communication connection with the first device.
- establishing the first persistent communication connection may include establishing the first persistent communication connection with an administrative device and establishing the second persistent communication connection may include establishing the second persistent communication connection with a user mobile device without dropping the first persistent communication connection with the first device.
- one or more non-transitory machine-readable storage media may include a plurality of instructions stored thereon that, in response to execution by an access control edge device, causes the access control edge device to establish a first persistent communication connection with a first device using a BLE communication circuitry and establish a second persistent communication connection with a second device using the BLE communication circuitry without dropping the first persistent communication connection with the first device.
- the first device may be a gateway device and the second device may be a mobile device.
- the plurality of instructions may further cause the access control edge device to receive a BLE access credential from the mobile device while simultaneously receiving a real-time update from a host server via the gateway device and perform an access control decision based on the BLE access credential and a local access control database stored on the access control edge device.
- the plurality of instructions may further cause the access control edge device to transmit, using the BLE communication circuitry, a BLE advertisement to remote devices in a vicinity of the access control edge device while the first persistent communication connection with the gateway device is established, wherein the second persistent communication connection with the mobile device is established in response to receipt of the BLE advertisement by the mobile device, receive a BLE access credential from the mobile device via the second persistent communication connection, and transmit the BLE access credential to an access control system via the first persistent communication connection with the gateway device to perform an access control decision.
- an access control system may include an administrative system, a mobile access hub, an access control edge system comprising a lock mechanism and a Bluetooth Low Energy (BLE) communication circuitry, and a credential management system to issue a BLE access credential to a user in response to a request for issuance of the BLE access credential by the administrative system and transmit the BLE access credential to the mobile access hub.
- the mobile access hub may be to transmit the BLE access credential to a mobile device associated with the user.
- the administrative system may be to update an access control database to associate the BLE access credential with the mobile device.
- the access control edge system may be to receive the BLE access credential from the mobile device via the BLE communication circuitry and unlock the lock mechanism in response to successful authentication of the BLE access credential.
- transmitting the BLE access credential to the mobile access hub may include calling the mobile access hub via a credential management application programming interface to transmit a message to the mobile device and transmitting the BLE access credential to the mobile device associated with the user may include transmitting the message to the mobile device including a deep link that retrieves the BLE access credential from the mobile access hub via a mobile application.
- transmitting the message may include transmitting a Short Message Service (SMS) message to the mobile device.
- SMS Short Message Service
- the credential management system may further receive the request for issuance of the BLE access credential via a web portal.
- the credential management system may further receive the request for issuance of the BLE access credential via an automated integrated application programming interface between the administrative system and the credential management system.
- issuing the BLE access credential may include ensuring that a credential value of the BLE access credential is unique to a site at which the access control edge system is located.
- issuing the BLE access credential may include issuing the BLE access credential in response to a determination that an entity associated with the administrative system has sufficient credential credits for issuance of a new BLE access credential.
- the access control edge system may further perform authentication of the BLE access credential.
- the access control edge system may include a peripheral controller to authenticate the BLE access credential.
- At least one of the credential management system or the mobile access hub may include a cloud-based system.
- a method may include issuing, by a credential management system, a Bluetooth Low Energy (BLE) access credential to a user in response to a request for issuance of the BLE access credential by an administrative system, transmitting, by the credential management system, the BLE access credential to a mobile device associated with the user, updating, by the administrative system, an access control database to associate the BLE access credential with the mobile device, receiving, by an access control edge device, the BLE access credential from the mobile device via a BLE communication connection between the access control edge device and the mobile device, and unlocking a lock mechanism of an electronic lock in response to successful authentication of the BLE access credential.
- BLE Bluetooth Low Energy
- transmitting the BLE access credential to the mobile device associated with the user may include transmitting, by the credential management system, the BLE access credential to a mobile access hub and transmitting, by the mobile access hub, the BLE access credential to the mobile device.
- transmitting the BLE access credential to the mobile device associated with the user may include calling, by the credential management system, the mobile access hub via a credential management application programming interface to transmit a message to the mobile device and transmitting, by the mobile access hub, the message to the mobile device including a deep link that retrieves the BLE access credential from the mobile access hub via a mobile application.
- transmitting the message may include transmitting a Short Message Service (SMS) message to the mobile device.
- SMS Short Message Service
- the method may further include receiving, by the credential management system, the request for issuance of the BLE access credential via a web portal.
- the method may further include receiving, by the credential management system, the request for issuance of the BLE access credential via an automated integrated application programming interface between the administrative system and the credential management system.
- issuing the BLE access credential may include ensuring that a credential value of the BLE access credential is unique to a site at which the electronic lock is located.
- issuing the BLE access credential may include issuing the BLE access credential in response to a determination that an entity associated with the administrative system has sufficient credential credits for issuance of a new BLE access credential.
- the method may further include performing, by the access control edge device, authentication of the BLE access credential, and the access control edge device may include the electronic lock.
- the method may further include transmitting, by the access control edge device, the BLE access credential to a peripheral controller for authentication.
- the method may further include transmitting, by the mobile device, the BLE access credential to the mobile device via the BLE communication connection in response to a determination of a user intent to access a passageway secured by the electronic lock.
- unlocking the lock mechanism of the electronic lock may include unlocking the lock mechanism in response to a determination of a user intent to access a passageway secured by the electronic lock.
- FIG. 1 is a simplified block diagram of at least one embodiment of an access control system for using a wireless access credential
- FIG. 2 is a simplified block diagram of at least one embodiment of a computing system
- FIGS. 3 - 8 are simplified block diagrams illustrating various communication capabilities of the access control system of FIG. 1 ;
- FIG. 9 is an example data structure of at least one embodiment of a wireless access credential
- FIG. 10 is a simplified flow diagram of at least one embodiment of a method of using a wireless access credential in the access control system of FIG. 1 ;
- FIG. 11 is a simplified flow diagram of at least one embodiment of a method of storing a wireless access credential to a mobile device of the access control system of FIG. 1 ;
- FIGS. 12 - 13 are a simplified flow diagram of at least one embodiment of a method of using the wireless access credential of FIG. 11 ;
- FIG. 14 is a simplified flow diagram of at least one embodiment of a method for further authenticating a user of the mobile device of FIG. 1 ;
- FIG. 15 is a simplified flow diagram of at least one embodiment of another method of storing a wireless access credential to the mobile device of FIG. 1 ;
- FIGS. 16 - 17 are a simplified flow diagram of at least one embodiment of a method of using the wireless access credential of FIG. 15 ;
- FIG. 18 is a simplified flow diagram of at least one embodiment of another method for further authenticating a user of the mobile device of FIG. 1 ;
- FIG. 19 is a simplified flow diagram of at least one embodiment of yet another method of storing a wireless access credential to the mobile device of FIG. 1 ;
- FIGS. 20 - 21 are a simplified flow diagram of at least one embodiment of a method of using the wireless access credential of FIG. 19 ;
- FIGS. 22 - 23 are a simplified flow diagram of at least one embodiment of a method of assigning a wireless access credential
- FIGS. 24 - 25 are a simplified flow diagram of at least one embodiment of a method of storing a wireless access credential to the mobile device of FIG. 1 ;
- FIG. 26 is a simplified flow diagram of at least one embodiment of a method of performing a key exchange between the mobile device and an access control edge device of FIG. 1 ;
- FIGS. 27 - 29 are a simplified flow diagram of at least one embodiment of a method of using the wireless access credential of FIGS. 24 - 25 ;
- FIGS. 30 - 31 are simplified diagrams of a graphical user interface of the mobile device of FIG. 1 ;
- FIG. 32 is a simplified flow diagram of at least one embodiment of a method of revoking a wireless access credential
- FIG. 33 is a chart depicting cryptographic keys associated with at least one embodiment of a cryptography chipset
- FIG. 34 is a simplified block diagram of at least one embodiment of an access control system including a peripheral controller
- FIG. 35 is a simplified block diagram of at least one embodiment of an access control system including an electronic lock
- FIGS. 36 - 37 are simplified block diagrams illustrating various embodiments of no tour implementations in access control systems
- FIGS. 38 - 40 are simplified flow diagrams of embodiments of at least one method of delivering no tour data
- FIG. 41 is a simplified block diagram illustrating cryptographic key provisioning during factor setup of an edge device.
- FIG. 42 is a simplified bloc diagram illustrating rolling cryptographic keys when an edge device is in the field.
- references in the specification to “one embodiment,” “an embodiment,” “an illustrative embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. It should further be appreciated that although reference to a “preferred” component or feature may indicate the desirability of a particular component or feature with respect to an embodiment, the disclosure is not so limiting with respect to other embodiments, which may omit such a component or feature.
- the disclosed embodiments may, in some cases, be implemented in hardware, firmware, software, or a combination thereof.
- the disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors.
- a machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).
- longitudinal, lateral, and transverse may be used to denote motion or spacing along three mutually perpendicular axes, wherein each of the axes defines two opposite directions.
- the directions defined by each axis may also be referred to as positive and negative directions.
- the descriptions that follow may refer to the directions defined by the axes with specific reference to the orientations illustrated in the figures.
- the directions may be referred to as distal/proximal, left/right, and/or up/down. It should be appreciated that such terms may be used simply for ease and convenience of description and, therefore, used without limiting the orientation of the system with respect to the environment unless stated expressly to the contrary.
- references a longitudinal direction may be equally applicable to a vertical direction, a horizontal direction, or an off-axis orientation with respect to the environment.
- motion or spacing along a direction defined by one of the axes need not preclude motion or spacing along a direction defined by another of the axes.
- elements described as being “laterally offset” from one another may also be offset in the longitudinal and/or transverse directions, or may be aligned in the longitudinal and/or transverse directions. The terms are therefore not to be construed as further limiting the scope of the subject matter described herein.
- an access control system 100 for using a wireless access credential includes a credential management system 102 , a credential tracking system 104 , a credential ordering system 106 , a key management system 108 , an administrative system 110 , a mobile access hub 112 , a mobile device 114 , and an access control edge system 116 .
- the access control edge system 116 may include one or more access control edge devices 118 (e.g., a reader device 130 , a lock device 132 ), an access controller 134 , and/or a gateway device 136 depending on the particular embodiment.
- the illustrative access control system 100 leverages wireless access credentials (e.g., Bluetooth or Bluetooth Low Energy (BLE) access credentials) to allow a user to securely gain access to a secured area (e.g., through a door or other passageway) using his or her mobile device 114 even when the mobile device 114 is offline. That is, the credentialed mobile device 114 may permit access without leveraging a real-time connection to the credential management system 102 , the administrative system 110 , and/or other credential management devices and systems.
- the wireless access credentials may be delivered to the edge device 118 via a Bluetooth or, more specifically, a BLE communication connection.
- the wireless access credential may be referred to, for example, as a Bluetooth access credential or a BLE access credential.
- the wireless access credentials may be in the same format as traditional physical credentials, which allows an existing access control system to process the wireless access credentials and grant/deny access without significant changes to the infrastructure.
- the wireless access credentials are generated in a cloud-based computing environment (e.g., a cloud-based credential management system 102 ) and delivered to end user mobile devices 114 (e.g., via a mobile access hub 112 ).
- the mobile device 114 may execute a mobile application to deliver the wireless access credential to a lock device 132 , reader device 130 , and/or other edge device 118 .
- the lock device 132 , reader device 130 , and/or other edge device 118 may establish and simultaneously maintain multiple Bluetooth (e.g., BLE) wireless communication connections.
- the edge device 118 may be persistently connected to a gateway device 136 while simultaneously receiving a BLE access credential from a mobile device 114 . Accordingly, in embodiments that permit multiple simultaneous persistent connections, it is generally unnecessary to periodically break an existing connection in order to establish a connection with another BLE device.
- the access control system 100 allows for the use of a near field communication (NFC) access credential and a BLE access credential via the same mobile application on a mobile device 114 .
- NFC near field communication
- BLE wireless communications established by the various devices of the access control system 100 may be compliant with Bluetooth Core Specification Version 4.2 or newer.
- various embodiments of the illustrative system 100 support improved security, support the authorized transferability of issued/existing credentials to a different mobile device 114 without the purchase of new credentials (e.g., when a using gets a new mobile device 114 ), support the ability of devices (e.g., edge devices 118 ) to have multiple simultaneous and persistent BLE connections, support multiple mobile credential technologies in the same mobile application (e.g., BLE and NFC), support multiple credentials on a single mobile device 114 within the same mobile application (e.g., work credential, gym credential, home credential, etc.), provide for onboarding a mobile device 114 via a user's mobile line number (e.g., even with iOS devices), allow for the revocation and/or expiration of credentials on the mobile device 114 (e.g., for convenience and increased procedural security), allow “no tour” functionality via a BLE credential (e.g., to add user access rights to a lock device 132 without an administrator touring the door and
- the illustrative system 100 further supports openness by virtue of the availability of the corresponding software development kit(s) (SDKs) and application programming interface(s) (APIs).
- SDKs software development kit
- APIs application programming interface
- the credentials may be embedded with OEM partner applications, thereby allowing the OEM partner to leverage the credentials in a custom manner. For example, if a university has created its own application for students, the university could add the credential into that application and use it for access instead of having them use a secondary application for access control.
- the illustrative system 100 is also amendable to subscription based credential issuance models.
- each of the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , the mobile access hub 112 , the mobile device 114 , the edge system 116 , the edge device(s) 118 , the reader device 130 , the lock device 132 , the access controller 134 , and the gateway device 136 may be embodied as any type of device or collection of devices suitable for performing the functions described herein. More specifically, in the illustrative embodiment, the credential management system 102 is configured to manage the issuance of wireless access credentials, provide support for channel partners, and otherwise perform the functions described herein. As depicted in FIG.
- the credential management system 102 includes, serves, or otherwise interfaces with a web application 120 and one or more APIs for interaction with other devices and/or systems.
- the credential management system 102 includes an administrative API 122 for interacting with the administrative system 110 and/or site/facility administrators and a credential API 124 for interacting with the mobile access hub 112 for exchanging credential data and/or related information.
- the credential management system 102 is configured to communicate and/or interact with the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , and the mobile access hub 112 .
- the credential management system 102 may encrypt and issue a new wireless/mobile access credential (e.g., a BLE credential and/or NFC credential) to a user or mobile device in response to a new credential order from the credential ordering system 106 and a credential request from the administrative system 110 .
- the credential management system 102 may also coordinate with the credential tracking system 104 to ensure that the credential value of the issued credential is not duplicative of another issued credential.
- the credential tracking system 104 provides additional security to the access control system 100 by tracking credential values (e.g., credential “card” numbers) that are issued to ensure that the credential values are not duplicated.
- credential values e.g., credential “card” numbers
- the credential tracking system 104 ensures that credential values are not duplicated across a particular site, whereas in other embodiments, the credential tracking system 104 ensures that credential values are not duplicated across all credential values ever used.
- the credential value may be composed of the facility/site code and a unique credential/badge value.
- the credential tracking system 104 ensures that the entire credential value is unique, whereas in other embodiments the credential tracking system 104 ensures that credential/badge value is unique. Such differences may be based, for example, on the bit format of the particular credential.
- the credential ordering system 106 processes orders of credentials placed by a customer such as, for example, an original equipment manufacturer (OEM), systems integrator, wholesaler, locksmith, or other relevant party.
- a customer may submit a purchase order for BLE credentials via the credential ordering system 106 , which interfaces with the credential management system 102 to populate credential credits in the credential management system 102 indicative of a number of credentials available to the customer for issuance to users (e.g., one credential credit equaling one wireless access credential available for issuance).
- the credential management system 102 may include or leverage an Oracle Application (e.g., Oracle Applications Release 11i, Oracle Documentation Library Release 12i, etc.) to perform one or more functions described herein.
- Oracle Application e.g., Oracle Applications Release 11i, Oracle Documentation Library Release 12i, etc.
- the key management system 108 is configured to securely store and control access to cryptographic keys and other secure data (e.g., credentials), and to perform cryptographic functions on behalf of the credential management system 102 .
- the key management system 108 may access an issued credential, generate a credential blob (e.g., a credential-bearing payload) including the credential and/or other relevant data, and encrypt the credential blob for transmittal to the credential management system 102 .
- a credential blob e.g., a credential-bearing payload
- the key management system 108 may leverage or include an Azure Key Vault to perform various functions described herein (e.g., in cloud-based embodiments).
- the key management system 108 may be omitted and/or form a portion of the credential management system 102 . It should be further appreciated that the monikers assigned herein to the various cryptographic keys are for readability and may vary in other embodiments without loss of generality. Additionally, the order and/or other organizational aspects of the data transmitted in payloads described herein may vary depending on the particular embodiment.
- the administrative system 110 includes one or more devices accessible to a site/facility administrator to perform various system administrative functions, maintenance functions, updates, and/or other suitable functions as described herein.
- the site administrator may utilize the administrative system 110 to access the credential management system 102 (e.g., via the web application 120 or portal) to monitor various features associated with the access control system 100 including, for example, the number of credential credits available for distribution of credentials to end user's mobile devices 114 .
- the administrative system 110 may be used to request a new wireless access credential to be assigned/issued and transmitted to a mobile device 114 of an end user.
- the administrative system 110 may manually request the credential issuance via the web application 120 .
- the administrative system 110 may be integrated with the credential management system 102 via the administrative API 122 such that the issuance of credentials may be automated.
- the administrative API 122 may further enable the administrative system 110 to simultaneously issue a credential to a user and add the user to the relevant access control database(s).
- the administrative system 110 may be configured to manage credentials of the access control system 100 with respect to the access control database(s). For example, the administrative system 110 may be responsible for ensuring that the access control database has updated authorized credentials, whitelists, blacklists, device parameters, and/or other suitable data. Additionally, in some embodiments, the administrative system 110 may receive security data, audit data, raw sensor data, and/or other suitable data from various edge devices 118 .
- the mobile access hub 112 interfaces directly with the mobile device 114 of a user and also interfaces with the credential management system 102 via the credential API 124 to receive the user's credential(s) for transmittal to the mobile device 114 via the mobile application. Further, in some embodiments, the mobile access hub 112 is leveraged during the onboarding of a wireless access credential as described below. More specifically, the mobile access hub 112 may generate and transmit a deep link via Short Message Service (SMS) to the mobile device 114 at the mobile device number entered when the credential was issued to the user.
- SMS Short Message Service
- the deep link may be configured to launch a mobile application on the mobile device 114 to securely receive the credential or, if the mobile application not accessible on the mobile device 114 , direct the user to the download location (e.g., an “App store”) to download the relevant mobile application.
- the mobile access hub 112 may interface with Twilio and/or another suitable messaging service for generating and transmitting the appropriate messages to the mobile device 114 .
- the mobile access hub 112 may interface with Branch.IO and/or another suitable service for generating deep links.
- the messages may be transmitted to the mobile device 114 via email and/or another suitable communication mechanism.
- the mobile access hub 112 serves as an interface or hub between the credential management system 102 and mobile devices 114 .
- the mobile access hub 112 may be configured to interface with the access control system 3400 and/or the access control system 3500 described below, for example, for the exchange of various data between the systems. Further, in some embodiments, the mobile access hub 112 may also interface with other systems of the access control system 100 not described herein for brevity of the description.
- the mobile access hub 112 is responsible for the onboarding of mobile devices 114 , the activation/expiration of credentials, revocation of credentials, and/or account recovery. It should be further appreciated that the mobile access hub 112 may also serve as an interface to other access control systems having different protocols, devices, control domains, and/or systems.
- the mobile device 114 may be configured to store multiple/dynamic credentials including a cryptographic bearer token (e.g., a cryptographic macaroon), and the mobile access hub 112 may serve as an interface between the mobile device 114 and a corresponding access control system such as the access control system 100 (or, more specifically, a cloud server thereof) for flexible access control over offline devices described in U.S.
- a cryptographic bearer token e.g., a cryptographic macaroon
- the access control system 100 of the Leveraging Flexible Distributed Tokens application and the cloud server thereof may be embodied as a Schlage® SenseTM system and/or cloud server, respectively.
- the mobile device 114 may be embodied as a mobile computing device, cellular phone, smartphone, wearable computing device, personal digital assistant, Internet of Things (IoT) device, or other mobile device suitable for performing the functions described herein.
- the mobile device 114 is configured to wirelessly communicate with the mobile access hub 112 and various edge devices 118 (e.g., lock devices 132 , reader devices 130 , etc.).
- the mobile device 114 installs and executes a mobile application to securely communicate with the various devices of the access control system 100 .
- the mobile application may be embodied as any suitable application for performing the functions described herein.
- the mobile application is embodied as a smartphone application.
- the application may serve (e.g., in part) as a client-side user interface for a web-based application or service (e.g., of the mobile access hub 112 ).
- a web-based application or service e.g., of the mobile access hub 112
- the mobile application may be embodied as or otherwise include a software development kit (SDK), one or more libraries, and/or user interfaces.
- SDK software development kit
- the mobile application of the mobile device 114 can support both a BLE credential and a NFC credential within the same application. Further, in some embodiments, both credentials for a particular user or mobile number have the same credential value such that there's only one entry in the access control database to identify that user. In some embodiments, in use, the user may have an option to select to send a BLE credential to the edge device 118 or just tap the mobile device 114 to the edge device 118 (or, more specifically, the reader device 130 ) such that a peer-to-peer connection is detected by the mobile device 114 and the mobile device 114 transmits the NFC credential to the edge device 118 .
- the mobile application can support newer BLE-only reader devices 130 in addition to older SMART technology reader devices 130 that support NFC. Further, if necessary (e.g., in high 2.4 GHz BLE frequency areas), NFC may be used as a backup to BLE. Also, the mobile device 114 may transmit a BLE credential in circumstances that previously may have required more user interaction (e.g., transmitting a BLE credential in parking garages without lowering the vehicle window). In other embodiments, it should be appreciated that BLE credential or the NFC credential may be selected based on the user intent, which may be determined according to any suitable technique. Depending on the particular embodiment, the mobile application may also support revocation or expiration of credentials, multiple credentials on the same mobile device 114 , and/or off-line use of the credential.
- the access control edge system 116 includes one or more access control edge devices 118 including, for example, a reader device 130 and/or a lock device 132 . Additionally, in some embodiments, the access control edge system 116 may further include one or more intermediate devices including, for example, an access controller 134 and/or a gateway device 136 . As described in greater detail below in reference to FIGS. 24 - 29 and, for example, in addition to the components described in reference to FIG. 2 , it should be appreciated that each of the access control edge devices 118 may include a BLE chipset 140 , a main chipset 142 , and a cryptography chipset 144 . In such embodiments, the BLE chipset 140 may be configured to transmit, receive, and/or process BLE communications.
- the main chipset 142 may include a main/primary processor of the access control edge device 118 .
- the cryptography chipset 144 may be configured to quickly and efficiently perform various cryptographic functions on behalf of the access control edge device 118 . It should be appreciated that, in some embodiments, each of the chipsets 140 , 142 , 144 may include or be otherwise embodied as one or more integrated circuits and/or other circuitry. Further, in some embodiments, the edge device 118 may include I 2 C and/or similar security between the main chipset 142 and the cryptography chipset 144 .
- the cryptography chipset 144 may be embodied as any integrated circuit(s) and/or other circuitry suitable for performing the functions described herein.
- the cryptography chipset 144 is designed and structured to efficiency perform cryptographic functions based on Elliptical Curve Cryptography (ECC) including, for example, Elliptical Curve Diffie Hellman (ECDH), Elliptical Curve Digital Signature Algorithm (ECDSA), asymmetric (public/private) cryptographic key generation, and cryptographic key storage.
- ECC Elliptical Curve Cryptography
- ECDH Elliptical Curve Diffie Hellman
- ECDSA Elliptical Curve Digital Signature Algorithm
- the cryptography chipset 144 is configured to perform ECDH and ECDSA calculations in fewer than two hundred milliseconds.
- the cryptography chipset 144 includes a set of cryptographic keys (W 1 , W 2 ) that secures the writing of keys such that different cryptographic keys cannot be written to the cryptographic chipset 144 by another party after the cryptography chipset 144 has been factory provisioned. Additionally, in some embodiments, the cryptography chipset 144 includes some cryptographic keys that are designed to change/roll and others that do not. At least one configuration of cryptographic keys provisioned/stored to the cryptography chipset 144 is depicted in the chart 3300 of FIG. 33 . As shown, the chart 3300 depicts specific keys and key pairs and the associated purpose of the key or key pair, and whether the key or key pair can be read, written, and/or rolled.
- the reader device 130 is configured to communicate with mobile devices 114 to receive wireless access credentials (e.g., Bluetooth or BLE credentials) that are processed in order to make a corresponding access control decision with respect to that mobile device 114 .
- the reader device 130 includes Bluetooth and/or other suitable wireless communication circuitry.
- the reader device 130 may be further configured to read contactless credentials (e.g., via RFID or NFC) and/or contact credential presented to the reader device 130 .
- the lock device 132 includes an access control mechanism and is configured to control access through a passageway.
- the access control mechanism may be embodied as a lock mechanism configured to be positioned in a locked state in which access to the passageway is denied, or may be positioned in an unlocked state in which access to the passageway is permitted.
- the lock mechanism includes a deadbolt, latch bolt, lever, and/or other mechanism adapted to move between the locked and unlocked state and otherwise perform the functions described herein.
- the access control mechanism may be embodied as any another mechanism suitable for controlling access through a passageway in other embodiments.
- the lock device 132 may be embodied as an electronic lock including a reader device 130 , whereas in other embodiments, the lock device 132 may be separate from the reader device 130 .
- the reader device 130 may be electrically coupled to an access controller 134 that analyzes the received credential data.
- the reader device 130 may be embodied as an RS-485 reader or Wiegand reader.
- the access controller 134 may be electrically coupled to the lock device 132 such that the access controller 134 may instruct or signal (e.g., via a relay) the lock mechanism to permit/deny access through the barrier based on the access control decision.
- the access controller 134 may be embodied as a “peripheral” controller in the sense that it is not integrated with an electronic lock. That is, in such embodiments, the access controller is not mounted on the door/barrier. Further, in other embodiments, the access controller 134 may be embodied as an access control panel.
- the gateway device 136 may serve as an interface between the access control edge device 118 (e.g., the reader device 130 and/or the lock device 132 ) and the administrative system 110 .
- the gateway device 136 may communicate with the access control edge device 118 over a Wi-Fi Connection and/or a Bluetooth connection, and the gateway device 136 may, in turn, forward the communicated data to the relevant administrative system 110 , management server, and/or access control panel.
- the gateway device 136 may communicate with an access control panel over a serial communication link (e.g., using RS-485 standard communication), and/or the gateway device 136 may communicate with the administrative system 110 over a Wi-Fi connection, an Ethernet connection, or another wired/wireless communication connection (e.g., via the Internet).
- a serial communication link e.g., using RS-485 standard communication
- the gateway device 136 may communicate with the administrative system 110 over a Wi-Fi connection, an Ethernet connection, or another wired/wireless communication connection (e.g., via the Internet).
- each of the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , the mobile access hub 112 , the mobile device 114 , the access control edge system 116 , the access control edge devices 118 , the reader device 130 , the lock device 132 , the access controller 134 , and/or the gateway device 136 may be embodied as a computing device similar to the computing device 200 described below in reference to FIG. 2 .
- each of the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , the mobile access hub 112 , the mobile device 114 , the access control edge system 116 , the access control edge devices 118 , the reader device 130 , the lock device 132 , the access controller 134 , and the gateway device 136 includes a processing device 202 and a memory 206 having stored thereon operating logic 208 for execution by the processing device 202 for operation of the corresponding device.
- the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , and the mobile access hub 112 are described herein as one or more computing devices outside of a cloud computing environment for simplicity of the description, in some embodiments, one or more of the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , and/or the mobile access hub 112 may be embodied as a cloud-based device or collection of devices. Accordingly, as depicted in FIG. 1 , each of those devices/systems may be referred to herein as one or more cloud servers 150 .
- the one or more cloud servers 150 may be referred to herein in the singular (i.e., as the cloud server 150 ).
- the cloud server 150 may be embodied as a server or other type of computing device situated outside of a cloud computing environment (e.g., a distributed server system) in some embodiments unless expressly indicated to the contrary.
- one or both of the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , and/or the mobile access hub 112 may be embodied as a “serverless” or server-ambiguous computing solution, for example, that executes a plurality of instructions on-demand, contains logic to execute instructions only when prompted by a particular activity/trigger, and does not consume computing resources when not in use.
- the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , and/or the mobile access hub 112 may be embodied as a virtual computing environment residing “on” a computing system (e.g., a distributed network of devices) in which various virtual functions (e.g., Lamba functions, Azure functions, Google cloud functions, and/or other suitable virtual functions) may be executed corresponding with the functions of the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , and/or the mobile access hub 112 described herein.
- various virtual functions e.g., Lamba functions, Azure functions, Google cloud functions, and/or other suitable virtual functions
- the virtual computing environment may be communicated with (e.g., via a request to an API of the virtual computing environment), whereby the API may route the request to the correct virtual function (e.g., a particular server-ambiguous computing resource) based on a set of rules.
- the appropriate virtual function(s) may be executed to perform the actions before eliminating the instance of the virtual function(s).
- credential management system 102 Although only one credential management system 102 , one credential tracking system 104 , one credential ordering system 106 , one key management system 108 , one administrative system 110 , one mobile access hub 112 , one mobile device 114 , one access control edge system 116 , one reader device 130 , one lock device 132 , one access controller 134 , and one gateway device 136 are shown in the illustrative embodiment of FIG.
- the system 100 may include multiple credential management systems 102 , credential tracking systems 104 , credential ordering systems 106 , key management systems 108 , administrative systems 110 , mobile access hubs 112 , mobile devices 114 , access control edge systems 116 , reader devices 130 , lock devices 132 , access controllers 134 , and/or gateway devices 136 in other embodiments.
- the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , and/or the mobile access hub 112 may be embodied as multiple servers in a cloud computing environment in some embodiments.
- the mobile device 114 may communicate with multiple access control edge systems 116 at various points in time.
- one or more of the devices and/or systems of the access control system 100 may be omitted or divided into multiple devices/systems. Additionally, in some embodiments, one or more of the devices and/or systems of the access control system 100 may form a portion of another device/system such that the functions are performed therein. For example, in some embodiments, the key management system 108 may form a portion of the credential management system 102 .
- the illustrative computing device 200 depicts at least one embodiment of a credential management system, a credential tracking system, a credential ordering system, a key management system, an administrative system, a mobile access hub, a mobile device, an access control edge system, an access control edge device, a reader device, a lock device, an access controller, and/or a gateway device that may be utilized in connection with the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , the mobile access hub 112 , the mobile device 114 , the access control edge system 116 , the access control edge devices 118 , the reader device 130 , the lock device 132 , the access controller 134 , and/or the gateway device 136 illustrated in FIG.
- the illustrative computing device 200 depicts at least one embodiment of the peripheral controller 3402 , the management server 3404 , the cloud server(s) 3406 , the mobile device 3408 , the mobile device 3410 , the gateway device 3412 , the credential enrollment reader 3414 , the RS-485 reader 3416 , and/or the Wiegand reader 3418 illustrated in FIG. 34 and/or the electronic lock 3502 , the management server 3504 , the cloud server(s) 3506 , the mobile device 3508 , the mobile device 3510 , the gateway device 3512 , and/or the credential enrollment reader 3514 illustrated in FIG. 35 .
- computing device 200 may be embodied as a server, desktop computer, laptop computer, tablet computer, notebook, netbook, UltrabookTM, mobile computing device, cellular phone, smartphone, wearable computing device, personal digital assistant, Internet of Things (IoT) device, reader device, access control device, control panel, processing system, router, gateway, and/or any other computing, processing, and/or communication device capable of performing the functions described herein.
- IoT Internet of Things
- the computing device 200 includes a processing device 202 that executes algorithms and/or processes data in accordance with operating logic 208 , an input/output device 204 that enables communication between the computing device 200 and one or more external devices 210 , and memory 206 which stores, for example, data received from the external device 210 via the input/output device 204 .
- the input/output device 204 allows the computing device 200 to communicate with the external device 210 .
- the input/output device 204 may include a transceiver, a network adapter, a network card, an interface, one or more communication ports (e.g., a USB port, serial port, parallel port, an analog port, a digital port, VGA, DVI, HDMI, FireWire, CAT 5, or any other type of communication port or interface), and/or other communication circuitry.
- Communication circuitry may be configured to use any one or more communication technologies (e.g., wireless or wired communications) and associated protocols (e.g., Ethernet, Bluetooth®, Bluetooth Low Energy (BLE), Wi-Fi®, WiMAX, etc.) to effect such communication depending on the particular computing device 200 .
- the input/output device 204 may include hardware, software, and/or firmware suitable for performing the techniques described herein.
- the external device 210 may be any type of device that allows data to be inputted or outputted from the computing device 200 .
- the external device 210 may be embodied as an access control device, mobile device, management server, gateway device, and/or access control panel.
- the external device 210 may be embodied as another computing device, switch, diagnostic tool, controller, printer, display, alarm, peripheral device (e.g., keyboard, mouse, touch screen display, etc.), and/or any other computing, processing, and/or communication device capable of performing the functions described herein.
- peripheral device e.g., keyboard, mouse, touch screen display, etc.
- the external device 210 may be integrated into the computing device 200 .
- the processing device 202 may be embodied as any type of processor(s) capable of performing the functions described herein.
- the processing device 202 may be embodied as one or more single or multi-core processors, microcontrollers, or other processor or processing/controlling circuits.
- the processing device 202 may include or be embodied as an arithmetic logic unit (ALU), central processing unit (CPU), digital signal processor (DSP), and/or another suitable processor(s).
- ALU arithmetic logic unit
- CPU central processing unit
- DSP digital signal processor
- the processing device 202 may be a programmable type, a dedicated hardwired state machine, or a combination thereof. Processing devices 202 with multiple processing units may utilize distributed, pipelined, and/or parallel processing in various embodiments.
- the processing device 202 may be dedicated to performance of just the operations described herein, or may be utilized in one or more additional applications.
- the processing device 202 is of a programmable variety that executes algorithms and/or processes data in accordance with operating logic 208 as defined by programming instructions (such as software or firmware) stored in memory 206 .
- the operating logic 208 for processing device 202 may be at least partially defined by hardwired logic or other hardware.
- the processing device 202 may include one or more components of any type suitable to process the signals received from input/output device 204 or from other components or devices and to provide desired output signals. Such components may include digital circuitry, analog circuitry, or a combination thereof.
- the memory 206 may be of one or more types of non-transitory computer-readable media, such as a solid-state memory, electromagnetic memory, optical memory, or a combination thereof. Furthermore, the memory 206 may be volatile and/or nonvolatile and, in some embodiments, some or all of the memory 206 may be of a portable variety, such as a disk, tape, memory stick, cartridge, and/or other suitable portable memory. In operation, the memory 206 may store various data and software used during operation of the computing device 200 such as operating systems, applications, programs, libraries, and drivers.
- the memory 206 may store data that is manipulated by the operating logic 208 of processing device 202 , such as, for example, data representative of signals received from and/or sent to the input/output device 204 in addition to or in lieu of storing programming instructions defining operating logic 208 .
- the memory 206 may be included with the processing device 202 and/or coupled to the processing device 202 depending on the particular embodiment.
- the processing device 202 , the memory 206 , and/or other components of the computing device 200 may form a portion of a system-on-a-chip (SoC) and be incorporated on a single integrated circuit chip.
- SoC system-on-a-chip
- various components of the computing device 200 may be communicatively coupled via an input/output subsystem, which may be embodied as circuitry and/or components to facilitate input/output operations with the processing device 202 , the memory 206 , and other components of the computing device 200 .
- the input/output subsystem may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.) and/or other components and subsystems to facilitate the input/output operations.
- the computing device 200 may include other or additional components, such as those commonly found in a typical computing device (e.g., various input/output devices and/or other components), in other embodiments. It should be further appreciated that one or more of the components of the computing device 200 described herein may be distributed across multiple computing devices. In other words, the techniques described herein may be employed by a computing system that includes one or more computing devices. Additionally, although only a single processing device 202 , I/O device 204 , and memory 206 are illustratively shown in FIG. 2 , it should be appreciated that a particular computing device 200 may include multiple processing devices 202 , I/O devices 204 , and/or memories 206 in other embodiments. Further, in some embodiments, more than one external device 210 may be in communication with the computing device 200 .
- Bluetooth includes traditional Bluetooth Basic Rate/Enhanced Rate (BR/EDR) technology and Bluetooth Low Energy (BLE) technology and refers to one or more components, architectures, communication protocols, and/or other systems, structures, or processes defined by and/or compliant with one or more Bluetooth specifications, addendums, and/or supplements overseen by the Bluetooth Special Interest Group (SIG) including, for example, active, legacy, withdrawn, deprecated, and/or subsequently introduced Bluetooth Core Specifications (CSs) (Bluetooth CS Version 1.0B, Bluetooth CS Version 1.1, Bluetooth CS Version 1.2, Bluetooth CS Version 2.0+EDR, Bluetooth CS Version 2.1+EDR, Bluetooth CS Version 3.0+HS, Bluetooth CS Version 4.0, Bluetooth CS Version 4.1, Bluetooth CS Version 4.2, Bluetooth CS Version 5.0); active, legacy, withdrawn, deprecated, and/or subsequently introduced Bluetooth Core Specification Addendums (CSAs) (Bluetooth CSA Version 1, Bluetooth CSA Version 2, Bluetooth CSA Version 3, Bluetooth
- FIGS. 3 - 8 simplified block diagrams illustrating various communication capabilities and use cases of the access control system 100 are shown. More specifically, FIGS. 3 - 8 illustrate communications between subsets of the various devices/systems of the access control device. That is, communication capabilities and use cases of subsystems 300 , 400 , 500 , 600 , 700 , 800 of the access control system 100 are shown.
- the subsystem 300 includes a mobile device 114 , a reader device 130 , an access controller 134 , and a lock device 132 .
- FIG. 3 the subsystem 300 includes a mobile device 114 , a reader device 130 , an access controller 134 , and a lock device 132 .
- the reader device 130 is embodied as a BLE-capable wall mount reader device that receives and processes the BLE access credential from the mobile device 114 and transmits the BLE access credential or a portion thereof to the access controller 134 (e.g., an access control panel) to perform the access control decision.
- the subsystem 300 may be considered to have employed a “decision at host” access control scheme, the “host” being the access control panel.
- the reader device 130 may communicate with the access controller 134 via Wiegand communication lines, which are one-way communication with no feedback, or using the Open Supervised Device Protocol (OSDP), which is generally secure and allows feedback. Further, based on the access control decision, the access controller 134 may transmit a command or signal to the lock device 132 , for example, to unlock the lock mechanism.
- OSDP Open Supervised Device Protocol
- the subsystem 400 includes a mobile device 114 and a lock device 132 .
- the lock device 132 is embodied as an electronic lock with BLE communication circuitry such that the lock device 132 receives and processes the BLE access credential from the mobile device 114 .
- the illustrative lock device 132 is an offline battery-powered electronic lock that includes an internal access control database stored in an internal memory of the lock device 132 such that the lock device 132 can locally make an access control decision based on the BLE access credential.
- the subsystem 400 may be considered to have employed an offline, “decision at door” access control scheme.
- a lock device 132 is considered to be “online” if the lock device 132 has a real-time connection to the host (e.g., the administrative system 110 ′′, whereas the lock device 132 is considered to “offline” if it does not.
- offline devices may, for example, establish a communication connection with the host periodically or in response to an appropriate condition in some embodiments.
- the subsystem 500 includes a mobile device 114 , a lock device 132 , a gateway device 136 , and an access controller 134 .
- the lock device 132 is embodied as an electronic lock with BLE communication circuitry such that the lock device 132 receives and processes the BLE access credential from the mobile device 114 .
- the illustrative lock device 132 is an online electronic lock that transmits the received BLE credential, or a portion thereof, in real-time to the gateway device 136 via BLE communication, which in turn transmits the BLE credential, or a portion thereof, to the access controller 134 (e.g., an access control panel) to perform an access control decision.
- the access controller 134 e.g., an access control panel
- the subsystem 500 may be considered to have employed an online, “decision at host” access control scheme.
- the gateway device 136 has a stable communication connection (e.g., an RSI-485 serial communication connection) to the access controller 134 for transmittal of the BLE credential and/or other relevant data.
- the lock device 132 has a persistent connection to the gateway device 136 and the ability to simultaneously transmit BLE advertisements to BLE devices in the vicinity in order to establish a BLE connection with the mobile device 114 to receive the BLE credential.
- the BLE chipset 140 of the lock device 132 leverages and/or is otherwise compliant with Bluetooth CS Version 4.2 or newer (i.e., subsequently introduced).
- the lock device 132 is capable of establishing at least five simultaneously BLE connections. It should be appreciated that the BLE connection is “persistent” in the sense that the BLE connection disconnects fewer than ten times per day. In other embodiments, the BLE connection may not be so “persistent” but may nonetheless not disconnect periodically by design.
- the subsystem 600 includes a mobile device 114 , a lock device 132 , a gateway device 136 , and a host system (e.g., an administrative system 110 ).
- the lock device 132 is embodied as an electronic lock with BLE communication circuitry such that the lock device 132 receives and processes the BLE access credential from the mobile device 114 .
- the illustrative lock device 132 is an online electronic lock that includes an internal access control database stored in an internal memory of the lock device 132 such that the lock device 132 can locally make an access control decision based on the BLE access credential.
- the subsystem 600 may be considered to have employed an online, “decision at door” access control scheme. It should be appreciated that, in the illustrative subsystem 600 , the lock device 132 has a persistent connection to the gateway device 136 such that the lock device 132 can receive real-time updates from the host server (e.g., the administrative system 110 ) while being connected to one or more mobile devices 114 . As in the subsystem 500 of FIG. 5 , in the subsystem 600 of FIG. 6 , the BLE chipset 140 of the lock device 132 leverages and/or is otherwise compliant with Bluetooth CS Version 4.2 or newer (i.e., subsequently introduced). Further, in some embodiments, the gateway device 136 communicates with the host server (e.g., the administrative system 110 ) via an Ethernet connection (e.g., via the Internet).
- the host server e.g., the administrative system 110
- an Ethernet connection e.g., via the Internet
- the subsystem 700 includes two mobile devices 114 , a reader device 130 , an access controller 134 , and a lock device 132 .
- the reader device 130 is embodied as a BLE-capable wall mount reader device that receives and processes BLE access credentials from the mobile devices 114 and transmits each of the BLE access credentials or a portion thereof to the access controller 134 (e.g., an access control panel) to perform the access control decision.
- the subsystem 300 may be considered to have employed a “decision at host” access control scheme, the “host” being the access control panel.
- the reader device 130 may communicate with the access controller 134 via Wiegand communication lines or using OSDP. Further, based on the access control decision, the access controller 134 may transmit a command or signal to the lock device 132 , for example, to unlock the lock mechanism.
- the subsystem 700 is similar to the subsystem 300 of FIG. 3 . However, the reader device 130 of subsystem 700 is configured to establishing and simultaneously maintain multiple BLE communication connections with other devices (e.g., in conjunction with heavy use doors). In particular, the illustrative reader device 130 of FIG.
- the 7 is configured to establish a BLE communication connection with a first mobile device 114 and maintain that connection while simultaneously establishing and then maintaining a BLE communication connection with a second mobile device 114 . It should be appreciated that permitting multiple mobile devices 114 to connect to the reader device 130 simultaneously, the risk and effect of various malicious attacks such as a denial of service attack is significantly reduced.
- the subsystem 800 includes a mobile device 114 , a lock device 132 , and an administrative device 802 .
- the administrative device 802 may be embodied as a device similar to the mobile device 114 and/or another computing device similar to the computing device 200 described in reference to FIG. 2 . Further, the administrative device 802 may form a portion of the administrative system 110 .
- the lock device 132 is embodied as an electronic lock with BLE communication circuitry such that the lock device 132 receives and processes the BLE access credential from the mobile device 114 .
- the illustrative lock device 132 may be an offline battery-powered electronic lock that includes an internal access control database stored in an internal memory of the lock device 132 such that the lock device 132 can locally make an access control decision based on the BLE access credential. Additionally, the lock device 132 may be configured to communicate with the administrative device 802 via the BLE communication circuitry such that the administrative device 802 may perform various administrative functions, maintenance functions, updates, and/or other suitable functions with respect to the lock device 132 . Similar to the reader device 130 of FIG. 7 , the lock device 132 of FIG.
- the lock device 132 is configured to simultaneously establish and maintain BLE communication connections with the mobile device 114 (e.g., a user mobile device) and the administrative device 802 such that an administrator application can be connected to the lock device 132 , and the lock device 132 can simultaneously advertise and connect with mobile devices 114 via BLE.
- the mobile device 114 e.g., a user mobile device
- the administrative device 802 such that an administrator application can be connected to the lock device 132 , and the lock device 132 can simultaneously advertise and connect with mobile devices 114 via BLE.
- FIG. 9 an example of a data structure of a wireless access credential 900 is shown.
- the illustrative wireless access credential 900 e.g., a BLE access credential
- the illustrative wireless access credential 900 is represented in Concise Binary Object Representation (CBOR) format or, more specifically, according to the RFC7049 CBOR standard, with hexadecimal representations.
- CBOR Concise Binary Object Representation
- each of the payloads and/or encrypted payloads described below may be transmitted in this format.
- FIG. 9 is shown by way of example, and the techniques described herein may be employed for different data representations and/or data structures.
- the illustrative wireless access credential 900 of FIG. 9 includes various data fields.
- the wireless access credential 900 includes data 902 , 904 , 906 , 908 , 910 .
- the data 902 is a tag that indicates the type of the data to follow.
- the data 902 (via “05”) indicates that the data is a credential value with a credential activation time and a credential expiration time.
- tags my include, for example, a nonce, public key(s), signature(s), key exchange data, a unique identifier (e.g., UUID), a PIN request, a PIN reply, key provisioning data (e.g., rolling keys), configuration data, firmware download, status reporting, error handling, reporting data, command information, and/or other suitable information.
- the data 904 indicates the type/length of the data.
- the data 906 indicates the credential bit format and, therefore, indicates (via “ 1 A”) that the credential is in a 26-bit format. Further, the data 906 indicates the credential value, the data 908 indicates an activation time of the credential, and the data 910 indicates an expiration time of the credential. It should be appreciated that the activation and expiration times may be in any suitable format (e.g., date-time, etc.). It should be further appreciated that the number and types of the data fields may vary depending on the particular data and/or the particular embodiment.
- the access control system 100 may execute a method 1000 for using a wireless access credential.
- the illustrative method 1000 begins with block 1002 of FIG. 10 in which the access control system 100 processes a wireless access credential order. More specifically, a customer may place an order for additional credentials via the credential ordering system 106 and/or the credential management system 102 .
- the credential management system 102 populates credential credits (commensurate with the number of credentials purchased) in the credential management system 102 indicative of a number of credentials available to the customer for issuance to users.
- credential credits typicallysurate with the number of credentials purchased
- the techniques described herein may also be employed with respect to other types of wireless access credentials.
- the access control system 100 receives a request for issuance of a credential and issues a credential to a user or the mobile device 114 of the user. In doing so, in block 1006 , the access control system 100 may ensure that the credential value of the credential being issued is unique and, in block 1008 , the access control system 100 may store credential data to an access control database (e.g., stored locally at the edge device 118 and/or remotely at the administrative system 110 or another suitable location).
- an access control database e.g., stored locally at the edge device 118 and/or remotely at the administrative system 110 or another suitable location.
- a site/facility administrator utilizes the administrative system 110 to access the credential management system 102 (e.g., via the web application 120 and/or administrative API 122 ) to request a new wireless access credential to be assigned/issued and transmitted to a mobile device 114 of an end user.
- the credential management system 102 may coordinate with the credential tracking system 104 to ensure that the credential value of the issued credential is not duplicative of another issued credential.
- the administrative system 110 may manually request the credential issuance via the web application 120 , whereas in other embodiments, the administrative system 110 may be integrated with the credential management system 102 via the administrative API 122 such that the request for and issuance of credentials may be automated.
- assigning/issuing the credential to a user further involves transmitting the issued credential and/or other relevant credential data to the administrative system 110 , which is, in turn, stored to the relevant access control database(s).
- the location of the access control database(s) may vary depending, for example, on the particular site's access control and network topologies.
- the access control database(s) may be located on the access control edge device 118 , access controller 134 (e.g., access control panel), host device (e.g., the administrative system 110 ), a cloud-based system, and/or another suitable location.
- the access control database includes the credential, the assigned user (e.g., identified by mobile phone number), and/or other relevant credential data.
- the access control system 100 transmits the issued credential to the appropriate mobile device 114 .
- the appropriate mobile device 114 may be identified, for example, based on the various communication protocols described herein.
- the credential management system 102 transmits the credential to the mobile device 114 via the mobile access hub 112 .
- the credential management system 102 may leverage the credential API 124 to interface with and/or “call” the mobile access hub 112 requesting a message to be transmitted to the user's mobile device 114 (e.g., a text/SMS message).
- the mobile access hub 112 may generate and transmit a deep link via SMS to the mobile device 114 at the mobile device number entered when the credential was issued to the user.
- the mobile access hub 112 may interface with Twilio and/or another suitable messaging service for generating and transmitting the appropriate messages to the mobile device 114 .
- the messages may be transmitted to the mobile device 114 via email and/or another suitable communication mechanism.
- the mobile device 114 may transmit the credential to the access control edge device 118 to make an access control decision with respect to the mobile device 114 and, therefore, with respect to the user.
- the mobile device 114 transmits the credential to the edge device 118 .
- the credential may be transmitted based on the user's express or implied intent to convey the credential to the edge device 118 .
- the credential is transmitted based on a user's selection on a graphical user interface of an option to transmit the credential, whereas in other embodiments, the credential may be transmitted based on sensor data, contextual information, and/or other relevant information.
- the mobile device 114 may determine the user intent based on various factors/options as described herein.
- the edge device 118 and/or other device(s) in the edge system 116 makes an access control decision based on the credential and the access control database. For example, as described above, the edge device 118 itself or another device may perform the access control decision based, for example, on whether a “decision at door” or “decision at host” access control scheme is employed, among other factors.
- the mobile device 114 may execute a mobile application that has a graphical user interface 3000 that allows the user to select a particular door/lock to indicate an intent to access that door, which causes the mobile device 114 to transmit the appropriate credential to the corresponding edge device 118 .
- the graphical user interface 3000 may include a cards tab 3002 , a doors tab 3004 , and a settings tab 3006 .
- the cards tab 3002 when selected, provides the user with options to select various credential stored to the mobile device 114 .
- selection of a particular card may transmit the corresponding credential to the associated edge device 118 , open properties or settings associated with the corresponding credential, and/or perform other suitable functions.
- the graphical user interface 3000 when the doors tab 3004 is selected, the graphical user interface 3000 further displays a recently used tab 3008 and an all doors tab 3010 .
- the illustrative graphical user interface 3000 identifies each of the doors that have been recently accessed.
- the graphical user interface 300 identifies each door associated with an edge device 118 that has performed an access control decision or, alternatively, an access control decision associated with an authenticated credential.
- door may be considered to have been “recently used” if the door is one of a certain number of most recently used doors and/or used within a certain period of time. Such number and/or time may vary depending on the particular embodiment.
- the graphical user interface 3000 may identify the state of each door including, for example, whether the door is unlocked (as depicted by indicia 3012 ) or locked (as depicted by indicia 3014 ). As shown in FIG.
- the illustrative graphical user interface 3000 identifies each of the doors within range of the mobile device 114 than can accept a wireless access credential (e.g., a BLE access credential).
- a wireless access credential e.g., a BLE access credential
- GATT new BLE generic attribute
- the list of doors that the graphical user interface 3000 displays may be significantly reduced.
- the graphical user interface 3000 may display every door within range of the mobile device 114 .
- the mobile device 114 may employ one or more other user intent options in other embodiments.
- the user intent options may vary by the amount of user interaction required to convey the user intent and, in some embodiments, may be configurable by the site administrator (e.g., via the administrative system 110 ).
- a graphical user interface (e.g., similar to the graphical user interface 3000 ) may provide the user with one or more user intent options to select for each of the edge devices 118 accessible to the user.
- user intent options may be permitted at the discretion of the site administrator in some embodiments. For example, a site administrator may permit more relaxed user intent options for an interior door housing nothing secure, whereas the site administrator may permit only more strict user intent options (e.g., express selections of the door) for an exterior door or an interior door securing critical infrastructure.
- the user intent may be conveyed without user interaction.
- the access control system 100 may engage in triangulation (e.g., between BLE edge devices 118 ) and/or leverage GPS circuitry to determine the location of the mobile device 114 .
- the mobile device 114 may transmit the credential (or alternatively, the edge device 118 may only process the received credential) when the mobile device 114 is moving toward the edge device 118 and on the proper side of the edge device 118 (e.g., corresponding with an exterior side of the door).
- the mobile device 114 may transmit the credential to the nearest edge device 118 based on the location data.
- the user may convey an intent to access by walking up to the door (and therefore the corresponding edge device 118 ) and stopping instead of walking by.
- the mobile device 114 and/or the edge device 118 may leverage received signal strength (e.g., signal strength indication (RSSI) values) or time of flight data to determine the distance of the mobile device 114 relative to the edge device 118 in some embodiments.
- the mobile device 114 may automatically transmit the credential to the edge device 118 when the mobile device 114 is within a predetermined distance of the edge device 118 or other reference device/component (e.g., the door) such that the lock device 132 may be automatically unlocked.
- the user intent may be conveyed with user interaction but without removing the mobile device 114 from safekeeping (e.g., without removing the mobile device 114 from the user's pocket, handbag, briefcase, etc.).
- the user may convey the intent by tapping the mobile device 114 . That is, when the mobile device 114 is within a close proximity to the edge device 118 , a tap on the mobile device 114 informs the mobile application to transmit the credential to the edge device 118 .
- the mobile device 114 may include and leverage an accelerometer and/or other inertial sensor(s) to perform such functions.
- the mobile device 114 may be embodied as, or otherwise include, a wearable device, and an indication appears on a display of the wearable device when the user is within range of an edge device 118 .
- a user's tap of the wearable device may be indicative of an intent to access the passageway secured by the edge device 118 .
- the mobile device 114 may sense the tap via an inertial sensor, capacitive sensor, pressure sensor, and/or other suitable sensor.
- the sensors leveraged by the mobile device 114 to determine a user intent may include environmental sensors (e.g., temperature sensors, air pressure sensors, humidity sensors, light sensors, etc.), inertial sensors (accelerometers, gyroscopes, magnetometers, etc.), proximity sensors, optical sensors, electromagnetic sensors, audio sensors (e.g., microphones), motion sensors, cameras, piezoelectric sensors, pressure sensors, and/or other types of sensors.
- environmental sensors e.g., temperature sensors, air pressure sensors, humidity sensors, light sensors, etc.
- inertial sensors accelerometers, gyroscopes, magnetometers, etc.
- proximity sensors e.g., optical sensors, electromagnetic sensors, audio sensors (e.g., microphones), motion sensors, cameras, piezoelectric sensors, pressure sensors, and/or other types of sensors.
- the user intent may involve both user interaction and removal of the mobile device 114 from safekeeping (e.g., removing the moving device 114 from the user's pocket, handbag, briefcase, etc.).
- the near field communication (NFC) circuitry of the mobile device 114 may be used as an intent option to transmit a BLE credential (e.g., by tapping the mobile device 114 to the reader device 130 ).
- the mobile device 114 may utilize a voice recognition system (e.g., via the mobile application, a system application, and/or another application) to determine the user's intent to transmit the credential to an edge device 118 . That is, the user may give an audible command to the mobile device 114 to do so.
- FIGS. 11 - 29 various embodiments of methods for securely transmitting an access credential over a wireless communication connection or, in some embodiments, a BLE communication connection more specifically are shown.
- the illustrative methods of FIGS. 11 - 29 leverage different security and encryption algorithms to secure the data across the wireless/BLE communication connection and/or while stored on specific devices in the access control system 100 .
- one or more devices of the access control system 100 may perform error handling procedures.
- the communication protocol may terminate. It should be appreciated that, in the illustrative methods of FIGS.
- the edge device 118 need not have ever been pre-commissioned to communicate with the mobile device 114 and/or the mobile application thereof. That is, in some embodiments, the edge device 118 has no pre-shared information about the specific mobile device 114 prior to commencing communication with the mobile device 114 .
- the access control system 100 may execute a method 1100 for storing a wireless access credential to the mobile device 114 .
- a method 1100 for storing a wireless access credential may be executed in conjunction with and prior to the method 1200 of FIGS. 12 - 13 .
- the illustrative method 1100 involves one or more cloud servers 150 and a mobile device 114 (e.g., executing a mobile application as described herein).
- the cloud server(s) 150 may be referred to herein in the singular for simplicity.
- the illustrative method 1100 assumes that a cryptographic key exchange has occurred such that the cloud server 150 and an edge device 118 (see, for example, FIGS. 12 - 13 ) share two symmetric cryptographic keys, K and B. It should appreciated that the cloud server 150 and the edge device 118 may employ any suitable key exchange algorithm to do so.
- the illustrative method 1100 further assumes that the mobile device 114 has stored thereon another symmetric cryptographic key, A, which may be generated, for example, by the mobile device 114 in a trusted execution environment (TEE) or secure enclave in some embodiments.
- TEE trusted execution environment
- the symmetric cryptographic keys may vary by type and/or length depending on the particular embodiment.
- the symmetric cryptographic keys, K, B, and A are embodied as 256-bit Advanced Encryption Standard (AES) keys.
- AES Advanced Encryption Standard
- the symmetric cryptographic keys may be associated with another cryptographic algorithm such as, for example, Data Encryption Standard (DES), Triple DES, Blowfish, Twofish, Serpent, and/or another symmetric cryptographic algorithm.
- the keys may be 128-bit keys, 512-bit keys, or another size in other embodiments (e.g., depending on the cryptographic algorithm).
- the cryptographic keys are generated by the cloud server 150 and transmitted to the edge device 118 .
- the illustrative method 1100 begins with flow 1102 of FIG. 11 in which the cloud server 150 and the mobile device 114 coordinate to assign a wireless access credential to a user (and therefore the mobile device 114 of that user) and verify the mobile device 114 (e.g., by confirming that the mobile number corresponds with the mobile device 114 ).
- the access control system 100 may execute the method 2200 of FIGS. 22 - 23 to do so.
- the mobile device 114 may establish a Transport Layer Security (TLS) connection with the cloud server 150 and/or other devices with which the mobile device 114 communicates.
- TLS Transport Layer Security
- the mobile device 114 (e.g., using the mobile application) builds a credential request including a device identifier (e.g., UUID) of the mobile device 114 and the symmetric cryptographic key, A, retrieved from a memory of the mobile device 114 .
- the credential request may identify the payload as a credential request (e.g., via a corresponding flag, CRED_REQ).
- the credential request may be represented as CRED_REQ ⁇ device_ID ⁇ A.
- the device identified may be tied to the mobile device 114 and may allow the edge device 118 to generate the information necessary to identify that the credential is correct any coming from the correct mobile device 114 as described below.
- the mobile device 114 transmits the credential request to the cloud server 150 (e.g., via a TLS connection).
- the cloud server 150 generates a shared cryptographic key, M, based on the symmetric cryptographic key, B, retrieved from a memory of the cloud server 150 and the unique identifier (e.g., UUID) received from the mobile device 114 with the credential request.
- the cryptographic key, M is shared in the sense that the edge device 118 is able to independently derive the same cryptographic key based on the same data (i.e., the key, B, and the unique identifier).
- the shared cryptographic key, M may be generated based on a key derivation function (KDF).
- KDF key derivation function
- the shared cryptographic key, M is generated based on a HKDF, a key derivation function based on a hash-based message authentication code (HMAC).
- HMAC hash-based message authentication code
- the shared cryptographic key, M may be otherwise generated.
- the cloud server 150 builds a credential blob including the credential to be transmitted to the mobile device 114 (i.e., the credential assigned to the mobile device 114 and the user) and the shared cryptographic key, M Further, in some embodiments, the credential blob may further include a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the credential blob may be represented as nonce ⁇ credential ⁇ A .
- the cloud server 150 encrypts the credential blob with the symmetric cryptographic key, K, and, in flow 1114 , the cloud server 150 generates a keyed hash of the encrypted credential blob using the same symmetric cryptographic key, K.
- the cloud server 150 generates an HMAC of the encrypted credential blob based on the symmetric cryptographic key, K (e.g., an HMAC-SHA256 keyed hash).
- K e.g., an HMAC-SHA256 keyed hash
- another type of keyed hash may be generated in other embodiments.
- the cloud server 150 transmits the encrypted credential blob (E K (nonce ⁇ credential ⁇ A)), the keyed hash of the encrypted credential blob (HMAC K ), and the shared cryptographic key (M) to the mobile device 114 .
- a payload including those data may be represented as E K (nonce ⁇ credential ⁇ A) ⁇ HMAC K ) ⁇ M .
- the mobile device 114 stores each of the encrypted credential blob (E K (nonce ⁇ credential ⁇ A)), the keyed hash of the encrypted credential blob (HMAC K ), and the shared cryptographic key (M) to a memory of the mobile device 114 .
- the mobile device 114 now has access to the shared cryptographic key (M), for example, to perform one or more cryptographic functions described below in reference to FIGS. 12 - 13 .
- the mobile device 114 now has a credential stored thereon that is tied to the mobile device 114 , but the mobile device 114 is unable to read the credential data due to the encryption.
- the memory of the mobile device 114 to which such data is stored is a secure memory in some embodiments.
- the access control system 100 may execute a method 1200 for using a wireless access credential (e.g., a wireless access credential stored to the mobile device 114 according to the method 1100 of FIG. 11 ).
- a wireless access credential e.g., a wireless access credential stored to the mobile device 114 according to the method 1100 of FIG. 11 .
- the particular flows of the method 1100 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary.
- the method 1200 of FIGS. 12 - 13 may be executed in conjunction with and subsequent to the method 1100 of FIG. 11 .
- the illustrative method 1200 involves the mobile device 114 (e.g., the mobile device 114 described in reference to FIG. 11 ) and an edge device 118 . Also as described above in reference to FIG. 11 , the illustrative method 1200 assumes that a cryptographic key exchange has occurred such that the cloud server 150 (see, for example, FIG. 11 ) and the edge device 118 share two symmetric cryptographic keys, K and B. Also, the mobile device 114 has stored thereon another symmetric cryptographic key, A. Further, in embodiments involving the method 1100 of FIG. 11 in conjunction with the method 1200 of FIGS.
- the mobile device 114 also has stored thereon the encrypted credential blob (E K (nonce ⁇ credential ⁇ A)), the keyed hash of the encrypted credential blob (HMAC K ), and the shared cryptographic key (M) after the execution of the method 1100 of FIG. 11 .
- E K once ⁇ credential ⁇ A
- HMAC K keyed hash of the encrypted credential blob
- M shared cryptographic key
- the illustrative method 1200 begins with flow 1202 of FIG. 12 in which the mobile device 114 and the edge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4.2 or newer connection). In doing so, the mobile device 114 and/or the edge device 118 may execute various Bluetooth-defined functions including, for example, getDevice ( ), tryConnecting ( ) onSuccess, tryDiscovering ( ), and/or onServicesDiscovered ( ) functions.
- the mobile deice 114 transmits the device identifier (e.g., UUID) of the mobile device 114 to the edge device 118 (e.g., in the clear).
- the device identifier e.g., UUID
- the edge device 118 generates the shared cryptographic key, M, based on the symmetric cryptographic key, B, and the device identifier (e.g., UUID).
- the cryptographic key, M is shared in the sense that the edge device 118 is able to independently derive the same cryptographic key (e.g., based on the key, B, and the unique identifier) used by the cloud device 150 to previously generate the shared cryptographic key, M.
- the edge device 118 may use the same key derivation function and/or other key-generating function used by the cloud device 150 to previously generate the shared cryptographic key, M.
- the shared cryptographic key, M is generated based on a HKDF.
- the edge device 118 encrypts credential request data with the shared cryptographic key, M
- the credential request data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks.
- the encrypted credential request data may be represented as E M (requestData) .
- the edge device 118 transmits the encrypted credential request data, E M (requestData) , to the mobile device 114 via the established Bluetooth communication connection.
- the mobile device 114 decrypts the encrypted credential request data using the shared cryptographic key, M, retrieved from a memory of the mobile device 114 and, in flow 1214 , the mobile device 114 (e.g., using the mobile application) builds a credential message including the credential request data received from the edge device 118 , the encrypted credential blob retrieved from the memory of the mobile device 114 , and the keyed hash retrieved from the memory of the mobile device 114 .
- the credential message may be represented as requestData ⁇ E K (nonce ⁇ credential ⁇ A) ⁇ HMAC K .
- the mobile device 114 encrypts the credential message with the shared cryptographic key, M, and in flow 1218 , the mobile device 114 generates a keyed hash of the encrypted credential message using the symmetric cryptographic key, A, retrieved from the memory of the mobile device 114 .
- mobile device 114 generates an HMAC of the encrypted credential message based on the symmetric cryptographic key, A (e.g., an HMAC-SHA256 keyed hash).
- A e.g., an HMAC-SHA256 keyed hash
- another type of keyed hash may be generated in other embodiments.
- the mobile device 114 transmits the encrypted credential message (E K (requestData ⁇ E K (nonce ⁇ credential ⁇ A) ⁇ HMAC K )) and the keyed hash (HMAC K ) of the encrypted credential message to the edge device 118 .
- the edge device 118 decrypts the encrypted credential message using the shared cryptographic key, K, retrieved from the memory of the edge device 118 .
- the edge device 118 verifies the credential request data. For example, in embodiments in which the credential request data is a nonce, the edge device 118 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 1208 - 1210 of FIG. 12 ). In other embodiments, it should be appreciated that the edge device 118 may otherwise verify and/or validate the decrypted credential request data.
- the edge device 118 verifies the keyed hash (HMAC K ) of the encrypted credential blob (e.g., extracted from the decrypted credential message) using the symmetric cryptographic key, K, retrieved from the memory of the edge device 118 .
- the edge device 118 generates a reference keyed hash (e.g., a reference HMAC) of the encrypted credential blob extracted from the decrypted credential message using the symmetric cryptographic key, K, and compares the reference keyed hash to the keyed hash (HMAC K ) of the encrypted credential blob extracted from the decrypted credential message to confirm the keyed hashes match.
- a reference keyed hash e.g., a reference HMAC
- the edge device 118 decrypts the encrypted credential blob using the symmetric cryptographic key, K, retrieved from the memory of the edge device 118 and, in block 1230 , the edge device 118 extracts the credential and the symmetric cryptographic key, A, from the decrypted credential blob.
- the edge device 118 and the cloud server 150 are capable of encrypting/decrypting the credential blob including the credential, whereas the mobile device 114 is not. Instead, in such embodiments, the mobile device 114 acts as a conduit for the secure transfer of the credential between the cloud server 150 and the edge device 118 .
- the edge device 118 verifies the keyed hash (HMAC A ) of the encrypted credential message using the symmetric cryptographic key, A, extracted from the credential blob. In some embodiments, to do so, the edge device 118 generates a reference keyed hash (e.g., a reference HMAC) of the encrypted credential message received from the mobile device 114 using the symmetric cryptographic key, K, and compares the reference keyed hash to the keyed hash (HMAC A ) of the encrypted credential received from the mobile device 114 to confirm the keyed hashes match.
- a reference keyed hash e.g., a reference HMAC
- the edge device 118 processes the credential extracted from the credential blob. For example, in some embodiments, the edge device 118 and/or other device(s) in the edge system 116 may make an access control decision based on the extracted credential and an access control database. As described above, the edge device 118 itself or another device (e.g., the administrative system 110 , the access controller 134 , etc.) may perform the access control decision based, for example, on whether a “decision at door” or “decision at host” access control scheme is employed, among other factors. Further, in some embodiments, in response to successful authentication of the credential, the lock device 132 may unlock a lock mechanism as described above.
- further authentication of the user and/or the mobile device 114 may be required in advance of, or in conjunction with, the processing of the credential.
- the method 1400 of FIG. 14 may be executed to process a PIN of the user.
- the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, and/or additional information.
- the credential value and/or other portion of the credential may include an indicator that further authentication is required.
- the access control system 100 may execute a method 1400 for further authenticating a user of the mobile device 114 .
- a method 1400 for further authenticating a user of the mobile device 114 may execute a method 1400 for further authenticating a user of the mobile device 114 .
- the particular flows of the method 1400 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary.
- the illustrative method 1400 begins with flow 1402 of FIG. 14 in which the edge device 118 encrypts PIN request data with the shared cryptographic key, M
- the PIN request data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks.
- the encrypted PIN request data may be represented as E M (requestPIN) .
- the edge device 118 transmits the encrypted PIN request data, E M (requestPIN), to the mobile device 114 .
- the mobile device 114 decrypts the encrypted PIN request data using the shared cryptographic key, M, retrieved from a memory of the mobile device 114 .
- mobile device 114 processes the PIN request and receives a PIN from the user.
- the mobile device 144 may present a request to the user for an input of a PIN value via a graphical user interface of the mobile application and receive the user's PIN input.
- the authentication data is described herein as a PIN or PIN value, it should be appreciated that the authentication data requested may vary depending on the particular embodiment. Further, in embodiments involving a PIN, the PIN may or may not be alphanumeric depending on the particular embodiment. Additionally, in some embodiments, the pin request and corresponding PIN may constitute a request and response for multiple data (e.g., in embodiments involving multifactor authentication).
- the mobile device 114 (e.g., using the mobile application) builds a PIN response including the PIN value received from the user and the decrypted PIN request data.
- the PIN response may be represented as requestPlN ⁇ PIN .
- the mobile device 114 encrypts the PIN response with the shared cryptographic key, M, and in flow 1414 , the mobile device 114 generates a keyed hash of the encrypted PIN request using the symmetric cryptographic key, A, retrieved from the memory of the mobile device 114 .
- mobile device 114 generates an HMAC of the encrypted PIN request based on the symmetric cryptographic key, A (e.g., an HMAC-SHA256 keyed hash).
- A e.g., an HMAC-SHA256 keyed hash
- another type of keyed hash may be generated in other embodiments.
- the mobile device 114 transmits the encrypted PIN response (E M (requestPlN ⁇ PIN)) and the keyed hash (HMAC A ) of the encrypted PIN response to the edge device 118 .
- the edge device 118 verifies the keyed hash of the encrypted PIN request using the symmetric cryptographic key, A, retrieved from the memory of the edge device 118 (e.g., subsequently extracted from the decrypted credential blob as described above).
- the edge device 118 to do so, the edge device 118 generates a reference keyed hash (e.g., a reference HMAC) of the encrypted PIN response using the symmetric cryptographic key, A, and compares the reference keyed hash to the keyed hash (HMAC A ) received from the mobile device 114 to confirm the keyed hashes match.
- a reference keyed hash e.g., a reference HMAC
- HMAC A keyed hash received from the mobile device 114 to confirm the keyed hashes match.
- the edge device 118 decrypts the encrypted PIN response using the shared cryptographic key, M, to extract the PIN request data and the user-provided PIN.
- the edge device 118 verifies the PIN request data. For example, in embodiments in which the PIN request data is a nonce, the edge device 118 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 1402 - 1404 of FIG. 14 ). In other embodiments, it should be appreciated that the edge device 118 may otherwise verify and/or validate the decrypted PIN request data.
- the edge device 114 processes the user-provided PIN extracted from the decrypted PIN response. For example, in some embodiments, the edge device 118 and/or other device(s) in the edge system 116 may include a reference PIN value in an access control database against which the user-provided PIN value is compared to determine if the PIN values match.
- the access control system 100 may execute a method 1500 for storing a wireless access credential to the mobile device 114 .
- a method 1500 for storing a wireless access credential may be executed in conjunction with and prior to the method 1600 of FIGS. 16 - 17 .
- the illustrative method 1500 involves one or more cloud servers 150 and a mobile device 114 (e.g., executing a mobile application as described herein).
- the cloud server(s) 150 may be referred to herein in the singular for simplicity.
- the illustrative method 1500 assumes that a cryptographic key exchange has occurred such that the cloud server 150 and an edge device 118 (see, for example, FIGS. 16 - 17 ) share a symmetric cryptographic key, K.
- the cloud server 150 and the edge device 118 may employ any suitable key exchange algorithm to do so.
- the symmetric cryptographic key, K may vary by type and/or length depending on the particular embodiment.
- the symmetric cryptographic key, K is embodied as 256-bit Advanced Encryption Standard (AES) keys.
- AES Advanced Encryption Standard
- the symmetric cryptographic keys may be associated with another cryptographic algorithm such as, for example, Data Encryption Standard (DES), Triple DES, Blowfish, Twofish, Serpent, and/or another symmetric cryptographic algorithm.
- the key may be a 128-bit keys, 512-bit key, or another size in other embodiments (e.g., depending on the cryptographic algorithm).
- the cryptographic key is generated by the cloud server 150 and transmitted to the edge device 118 .
- the illustrative method 1500 begins with flow 1502 of FIG. 15 in which the cloud server 150 and the mobile device 114 coordinate to assign a wireless access credential to a user (and therefore the mobile device 114 of that user) and verify the mobile device 114 (e.g., by confirming that the mobile number corresponds with the mobile device 114 ).
- the access control system 100 may execute the method 2200 of FIGS. 22 - 23 to do so.
- the mobile device 114 may establish a Transport Layer Security (TLS) connection with the cloud server 150 and/or other devices with which the mobile device 114 communicates.
- TLS Transport Layer Security
- the mobile device 114 generates an asymmetric cryptographic key pair, (C, c) , including a private cryptographic key, c, and a public cryptographic key, C, for storage to the mobile device 114 and use as described herein.
- asymmetric cryptographic key pair and corresponding public/private keys may vary by type depending on the particular embodiment.
- the asymmetric cryptographic key pair is generated based on elliptical curve cryptography (ECC) based on the EC P 256 curve.
- ECC elliptical curve cryptography
- the asymmetric cryptographic key pair may be associated with another suitable ECC curve.
- the asymmetric cryptographic key pair may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm.
- DSS Digital Signature Standard
- DSA Digital Signature Algorithm
- RSA Rivest-Shamir-Adleman
- ElGamal ElGamal
- the public/private key sizes may vary depending, for example, on the particular algorithm employed.
- the asymmetric cryptographic key pair may be generated and stored on the mobile device 114 in advance of the execution of the method 1500 of FIG. 15 . Further, it should be appreciated that the mobile device 114 may generate the asymmetric cryptographic key pair, (C,c), in a trusted execution environment (TEE) or secure enclave in some embodiments.
- TEE trusted execution environment
- the mobile device 114 (e.g., using the mobile application) builds a credential request including the public key, C, of the cryptographic key pair (C, c) retrieved from a memory of the mobile device 114 .
- the credential request may identify the payload as a credential request (e.g., via a corresponding flag, CRED_REQ).
- the credential request may be represented as CRED_REQ ⁇ C .
- the mobile device 114 cryptographically signs the credential request using the private key, c, of the cryptographic key pair (C, c) retrieved from a memory of the mobile device 114 .
- the mobile device 114 generates a cryptographic signature of the credential request.
- the mobile device 114 transmits the signed credential request to the cloud server 150 (e.g., via a TLS connection).
- the mobile device 114 transmits the credential request and the signature thereof to the cloud server 150 .
- the cloud server 150 extracts the public key, C, from the credential request received from the mobile device 114 and verifies the credential request signature using that public key. That is, the cloud server 150 verifies that the credential request was signed using the private key that corresponds with the public key, C. It should be appreciated that the cloud server 150 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment).
- the cloud server 150 builds a credential blob including the credential to be transmitted to the mobile device (i.e., the credential assigned to the mobile device 114 and the user) and the public key, C. Further, in some embodiments, the credential blob may further include a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the credential blob may be represented as nonce ⁇ C ⁇ credential .
- the cloud server 150 encrypts the credential blob with the symmetric cryptographic key, K, and, in flow 1518 , the cloud server 150 generates a keyed hash of the encrypted credential blob using the same symmetric cryptographic key, K.
- the cloud server 150 generates an HMAC of the encrypted credential blob based on the symmetric cryptographic key, K (e.g., an HMAC-SHA256 keyed hash).
- K e.g., an HMAC-SHA256 keyed hash
- another type of keyed hash may be generated in other embodiments.
- the cloud server 150 transmits the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)) and the keyed hash of the encrypted credential blob to the mobile device 114 .
- a payload including those data may be represented as E K (nonce ⁇ C ⁇ credential) ⁇ HMAC K .
- the mobile device 114 stores the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)) and the keyed hash of the encrypted credential blob (HMAC K ) to a memory of the mobile device 114 .
- the mobile device 114 now has a credential stored thereon that is tied to the mobile device 114 , but the mobile device 114 is unable to read the credential data due to the encryption. It should be appreciated that, in some embodiments, the memory of the mobile device 114 to which such data is stored is a secure memory.
- the access control system 100 may execute a method 1600 for using a wireless access credential (e.g., a wireless access credential stored to the mobile device 114 according to the method 1500 of FIG. 15 ).
- a wireless access credential e.g., a wireless access credential stored to the mobile device 114 according to the method 1500 of FIG. 15 .
- the particular flows of the method 1600 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary.
- the method 1600 of FIGS. 12 - 13 may be executed in conjunction with and subsequent to the method 1500 of FIG. 15 .
- the illustrative method 1600 involves the mobile device 114 (e.g., the mobile device 114 described in reference to FIG. 15 ) and an edge device 118 . Also as described above in reference to FIG. 15 , the illustrative method 1600 assumes that a cryptographic key exchange has occurred such that the cloud server 150 (see, for example, FIG. 15 ) and the edge device 118 share a symmetric cryptographic key, K. Also, the mobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c) , including a private cryptographic key, c, and a public cryptographic key, C, described above. Further, in embodiments involving the method 1500 of FIG. 15 in conjunction with the method 1600 of FIGS.
- the mobile device 114 also has stored thereon the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)) and the keyed hash of the encrypted credential blob (HMAC K ) after the execution of the method 1500 of FIG. 15 .
- E K once ⁇ C ⁇ credential
- HMAC K keyed hash of the encrypted credential blob
- the illustrative method 1600 begins with flow 1602 of FIG. 16 in which the mobile device 114 and the edge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4.2 or newer connection). In doing so, the mobile device 114 and/or the edge device 118 may execute various Bluetooth-defined functions including, for example, getDevice , tryConnecting ( ), onSuccess, tryDiscovering ( ) and/or onServicesDiscovered ( ) functions. In flow 1604 , the mobile device 114 and the edge device 118 perform a secure key exchange to generate a shared cryptographic session key, s, separately at each of the mobile device 114 and the edge device 118 .
- a Bluetooth communication session/connection e.g., a BLE 4.2 or newer connection.
- the mobile device 114 and/or the edge device 118 may execute various Bluetooth-defined functions including, for example, getDevice , tryConnecting ( ), onSuccess, tryDisc
- the session key, s is generated based on Elliptical Curve Diffie-Hellman (ECDH).
- ECDH Elliptical Curve Diffie-Hellman
- the shared cryptographic session key, s is dynamic in the sense that the key is different every time the key is generated.
- each exchange may have a different session key.
- the mobile device 114 and the edge device 118 may execute a method similar to the method 2600 of FIG. 26 to perform the secure key exchange.
- the session key, s may be generated based on a different key derivation function and/or other suitable algorithm in other embodiments.
- each of the mobile device 114 and the edge device 118 has the same session key, s, stored thereon.
- the edge device 118 encrypts challenge data with the shared cryptographic session key, s.
- the challenge data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks.
- the encrypted challenge data may be represented as E s (challenge) .
- the edge device 118 transmits the encrypted challenge data, E s (challenge) , to the mobile device 114 via the established Bluetooth communication connection.
- the mobile device 114 decrypts the encrypted challenge data using the shared cryptographic session key, s, retrieved from a memory of the mobile device 114 and, in flow 1612 , the mobile device 114 (e.g., using the mobile application) builds a credential message including the challenge data received from the edge device 118 , the encrypted credential blob retrieved from the memory of the mobile device 114 , and the keyed hash retrieved from the memory of the mobile device 114 .
- the credential message may be represented as challenge ⁇ E K (nonce ⁇ MC ⁇ credential) ⁇ HMAC K .
- the mobile device 114 encrypts the credential message with the shared cryptographic session key, s, and in flow 1616 , the mobile device 114 cryptographically signs the encrypted credential message using the private key, c, of the cryptographic key pair (C, c) retrieved from a memory of the mobile device 114 . In other words, the mobile device 114 generates a cryptographic signature (cSig) of the encrypted credential message.
- cSig cryptographic signature
- the mobile device 114 transmits the signed credential message to the edge device 118 .
- the mobile device 114 transmits the encrypted credential message and the signature thereof to the edge device 118 .
- the edge device 118 decrypts the encrypted credential message using the shared cryptographic session key, s, retrieved from the memory of the edge device 118 .
- the edge device 118 verifies the challenge data. For example, in embodiments in which the challenge data is a nonce, the edge device 118 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 1606 - 1608 of FIG. 16 ). In other embodiments, it should be appreciated that the edge device 118 may otherwise verify and/or validate the decrypted challenge data. In flow 1624 , the edge device 118 verifies the keyed hash (HMAC K ) of the encrypted credential blob (e.g., extracted from the decrypted credential message) using the symmetric cryptographic key, K, retrieved from the memory of the edge device 118 .
- HMAC K keyed hash
- the edge device 118 generates a reference keyed hash (e.g., a reference HMAC) of the encrypted credential blob extracted from the decrypted credential message using the symmetric cryptographic key, K, and compares the reference keyed hash to the keyed hash (HMAC K ) of the encrypted credential blob extracted from the decrypted credential message to confirm the keyed hashes match.
- a reference keyed hash e.g., a reference HMAC
- the edge device 118 decrypts the encrypted credential blob using the symmetric cryptographic key, K, retrieved from the memory of the edge device 118 and, in block 1628 , the edge device 118 extracts the credential and the public cryptographic key, C, from the decrypted credential blob.
- the edge device 118 and the cloud server 150 are capable of encrypting/decrypting the credential blob including the credential, whereas the mobile device 114 is not. Instead, in such embodiments, the mobile device 114 acts as a conduit for the secure transfer of the credential between the cloud server 150 and the edge device 118 .
- the public cryptographic key, C is not directly transmitted from the mobile device 114 to the edge device 118 .
- the public cryptographic key, C may be leveraged to verify that the mobile device 114 that made the initial contact with the cloud server 150 is the same device that signed the payload (e.g., the encrypted credential message) toward the end of the communication sequence.
- the edge device 118 verifies the signature of the encrypted credential message using the public cryptographic key, C, extracted from the decrypted credential blob. That is, the edge device 118 verifies that the encrypted credential message was signed using the private key that corresponds with the public key, C. It should be appreciated that the edge device 118 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment).
- the credential payload (e.g., the encrypted credential blob) stored to the mobile device in flow 1522 of FIG. 15 includes the public cryptographic key, C, that is associated with and stored on the mobile device 114 and provided to the mobile access hub 112 at onboarding.
- the public cryptographic key, C verifies that the credential is associated with the same mobile device 114 .
- the verification of the cryptographic signature (cSig) will fail, because the cryptographic key pair (C, c) is unique for each mobile device 114 .
- the use of the cryptographic key pair (C, c) as described herein serves, for example, to prevent the unauthorized copying of a credential to a different mobile device 114 .
- the edge device 118 processes the credential extracted from the credential blob. It should be appreciated that the credential may be processed in a manner similar to that described in reference to flow 1234 of FIG. 13 . As such, in some embodiments, the edge device 118 and/or other device(s) in the edge system 116 may make an access control decision based on the extracted credential and an access control database. Further, the edge device 118 itself or another device (e.g., the administrative system 110 , the access controller 134 , etc.) may perform the access control decision based on the particular embodiment. Further, in some embodiments, in response to successful authentication of the credential, the lock device 132 may unlock a lock mechanism as described above.
- further authentication of the user and/or the mobile device 114 may be required in advance of, or in conjunction with, the processing of the credential.
- the method 1800 of FIG. 18 may be executed to process a PIN of the user.
- the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, and/or additional information.
- the credential value and/or other portion of the credential may include an indicator that further authentication is required.
- the access control system 100 may execute a method 1800 for further authenticating a user of the mobile device 114 .
- the particular flows of the method 1800 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary.
- the techniques are generally described herein in reference to a PIN value, it should be appreciated that similar techniques may be employed with respect to other secondary credential/authentication data.
- facial identification, thumb print, other biometrics, voice recognition, gestures, and/or other relevant authentication data may be used in conjunction with the method 1800 and other techniques described herein.
- the illustrative method 1800 begins with flow 1802 of FIG. 18 in which the edge device 118 encrypts PIN request data with the shared cryptographic session key, s.
- the PIN request data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks.
- the encrypted PIN request data may be represented as E s (requestPIN) .
- the edge device 118 transmits the encrypted PIN request data, E s (requestPIN), to the mobile device 114 .
- the mobile device 114 decrypts the encrypted PIN request data using the shared cryptographic session key, s, retrieved from a memory of the mobile device 114 .
- mobile device 114 processes the PIN request and receives a PIN from the user (e.g., in a manner similar to that described above in reference to the method 1400 of FIG. 14 ).
- the mobile device 144 may present a request to the user for an input of a PIN value via a graphical user interface of the mobile application and receive the user's PIN input.
- the authentication data is described herein as a PIN or PIN value, it should be appreciated that the authentication data requested may vary (e.g., in type, source, format, etc.) depending on the particular embodiment.
- the mobile device 114 (e.g., using the mobile application) builds a PIN response including the PIN value received from the user and the decrypted PIN request data.
- the PIN response may be represented as requestPlN ⁇ PIN .
- the mobile device 114 encrypts the PIN response with the shared cryptographic session key, s, and in flow 1814 , the mobile device 114 transmits the encrypted PIN response (E s (requestPIN ⁇ PIN)) to the edge device 118 .
- the mobile device 114 may further generate a keyed hash of the encrypted PIN request (e.g., as in the method 1400 of FIG. 14 ) or otherwise convey data indicative of the integrity of the message.
- the edge device 118 decrypts the encrypted PIN response using the shared cryptographic session key, s, to extract the PIN request data and the user-provided PIN and, in flow 1818 , the edge device 118 verifies the PIN request data. For example, in embodiments in which the PIN request data is a nonce, the edge device 118 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 1802 - 1804 of FIG. 18 ). In other embodiments, it should be appreciated that the edge device 118 may otherwise verify and/or validate the decrypted PIN request data.
- the edge device 114 processes the user-provided PIN extracted from the decrypted PIN response (e.g., in a manner similar to that described in reference to the method 1400 of FIG. 14 and/or otherwise described herein).
- the edge device 118 and/or other device(s) in the edge system 116 may include a reference PIN value in an access control database against which the user-provided PIN value is compared to determine if the PIN values match.
- the access control system 100 may execute a method 1900 for storing a wireless access credential to the mobile device 114 .
- a method 1900 for storing a wireless access credential may be executed in conjunction with and prior to the method 2000 of FIGS. 20 - 21 .
- the illustrative method 1900 involves one or more cloud servers 150 and a mobile device 114 (e.g., executing a mobile application as described herein).
- the cloud server(s) 150 may be referred to herein in the singular for simplicity.
- the illustrative method 1900 assumes that a cryptographic key exchange has occurred such that the cloud server 150 and an edge device 118 (see, for example, FIGS. 20 - 21 ) share a symmetric cryptographic key, K.
- the cloud server 150 and the edge device 118 may employ any suitable key exchange algorithm to do so.
- the symmetric cryptographic key, K may vary by type and/or length depending on the particular embodiment.
- the symmetric cryptographic key, K is embodied as 256-bit Advanced Encryption Standard (AES) keys.
- AES Advanced Encryption Standard
- the symmetric cryptographic keys may be associated with another cryptographic algorithm such as, for example, Data Encryption Standard (DES), Triple DES, Blowfish, Twofish, Serpent, and/or another symmetric cryptographic algorithm.
- the key may be a 128-bit keys, 512-bit key, or another size in other embodiments (e.g., depending on the cryptographic algorithm).
- the cryptographic key is generated by the cloud server 150 and transmitted to the edge device 118 .
- the illustrative method 1900 further assumes that an asymmetric cryptographic key pair, (D, d), including a private cryptographic key, d, and a public cryptographic key, D, has been generated and stored to the cloud server 150 , and that the public cryptographic key, D, has been stored to the edge device 118 for use as described herein. It should be appreciated that they asymmetric cryptographic key pair, (D, d), and corresponding public/private keys may vary by type depending on the particular embodiment. For example, in the illustrative embodiment, the asymmetric cryptographic key pair, (D, d), is generated based on elliptical curve cryptography (ECC) based on the EC P 256 curve.
- ECC elliptical curve cryptography
- the asymmetric cryptographic key pair may be associated with another suitable ECC curve. Further, in other embodiments, the asymmetric cryptographic key pair may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm. Similarly, the public/private key sizes may vary depending, for example, on the particular algorithm employed. In some embodiments, the asymmetric cryptographic key pair, (D, d), may be generated by the cloud server 150 and the public cryptographic key, D, may be securely transmitted to the edge device 118 according to any suitable exchange protocol or provisioning mechanism.
- DSS Digital Signature Standard
- DSA Digital Signature Algorithm
- RSA Rivest-Shamir-Adleman
- ElGamal Rivest-Shamir-Adleman
- the public/private key sizes may vary depending, for example, on the particular algorithm employed.
- the illustrative method 1900 begins with flow 1902 of FIG. 19 in which the cloud server 150 and the mobile device 114 coordinate to assign a wireless access credential to a user (and therefore the mobile device 114 of that user) and verify the mobile device 114 (e.g., by confirming that the mobile number corresponds with the mobile device 114 ).
- the access control system 100 may execute the method 2200 of FIGS. 22 - 23 to do so.
- the mobile device 114 may establish a Transport Layer Security (TLS) connection with the cloud server 150 and/or other devices with which the mobile device 114 communicates.
- TLS Transport Layer Security
- the mobile device 114 generates an asymmetric cryptographic key pair, (C, c) , including a private cryptographic key, c, and a public cryptographic key, C, for storage to the mobile device 114 and use as described herein. Similar to the asymmetric cryptographic key pair, (D, d) , it should be appreciated that they asymmetric cryptographic key pair, (C, c) , and corresponding public/private keys may vary by type depending on the particular embodiment. In some embodiments, it should be appreciated that the asymmetric cryptographic key pair, (C, c), may be a similar type of key pair as the asymmetric cryptographic key pair, (D, d), described above.
- the asymmetric cryptographic key pair, (C, c) is generated based on elliptical curve cryptography (ECC) based on the EC P 256 curve.
- ECC elliptical curve cryptography
- the asymmetric cryptographic key pair may be associated with another suitable ECC curve.
- the asymmetric cryptographic key pair, (C, c) may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm.
- DSS Digital Signature Standard
- DSA Digital Signature Algorithm
- RSA Rivest-Shamir-Adleman
- ElGamal Rivest-Shamir-Adleman
- the public/private key sizes may vary depending, for example, on the particular algorithm employed.
- the asymmetric cryptographic key pair, (C, c) may be generated and stored on the mobile device 114 in advance of the execution of the method 1900 of FIG. 19 . Further, it should be appreciated that the mobile device 114 may generate the asymmetric cryptographic key pair, (C, c), in a trusted execution environment (TEE) or secure enclave in some embodiments.
- TEE trusted execution environment
- the mobile device 114 (e.g., using the mobile application) builds a credential request including the public key, C, of the cryptographic key pair (C, c) retrieved from a memory of the mobile device 114 .
- the credential request may identify the payload as a credential request (e.g., via a corresponding flag, CRED_REQ).
- the credential request may be represented as C RED_REQ ⁇ C .
- the mobile device 114 cryptographically signs the credential request using the private key, c, of the cryptographic key pair , (C, c), retrieved from a memory of the mobile device 114 .
- the mobile device 114 generates a cryptographic signature of the credential request.
- the mobile device 114 transmits the signed credential request to the cloud server 150 (e.g., via a TLS connection).
- the mobile device 114 transmits the credential request and the signature thereof to the cloud server 150 .
- the cloud server 150 extracts the public key, C, from the credential request received from the mobile device 114 and verifies the credential request signature using that public key. That is, the cloud server 150 verifies that the credential request was signed using the private key that corresponds with the public key, C. It should be appreciated that the cloud server 150 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment).
- the cloud server 150 builds a credential blob including the credential to be transmitted to the mobile device (i.e., the credential assigned to the mobile device 114 and the user) and the public key, C.
- the credential blob may further include a nonce value, for example, to reduce the efficacy of replay attacks.
- the credential blob may be represented as nonce ⁇ C ⁇ credential .
- the cloud server 150 encrypts the credential blob with the symmetric cryptographic key, K, and, in flow 1918 , the cloud server 150 cryptographically signs the encrypted credential blob using the private key, d, of the cryptographic key pair, (D,d) , stored in the memory of the cloud server 150 . In other words, the cloud server 150 generates a cryptographic signature of the encrypted credential blob.
- the cloud server 150 transmits the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)) and the signature thereof to the mobile device 114 .
- the cloud server 150 stores the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)) and the signature thereof to a memory of the mobile device 114 .
- the mobile device 114 now has a credential stored thereon that is tied to the mobile device 114 , but the mobile device 114 is unable to read the credential data due to the encryption.
- the memory of the mobile device 114 to which such data is stored is a secure memory.
- the access control system 100 may execute a method 2000 for using a wireless access credential (e.g., a wireless access credential stored to the mobile device 114 according to the method 1900 of FIG. 19 ).
- a wireless access credential e.g., a wireless access credential stored to the mobile device 114 according to the method 1900 of FIG. 19 .
- the particular flows of the method 2000 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary.
- the method 2000 of FIGS. 20 - 21 may be executed in conjunction with and subsequent to the method 1900 of FIG. 19 .
- the illustrative method 2000 involves the mobile device 114 (e.g., the mobile device 114 described in reference to FIG. 19 ) and an edge device 118 . Also as described above in reference to FIG. 19 , the illustrative method 2000 assumes that a cryptographic key exchange has occurred such that the cloud server 150 (see, for example, FIG. 19 ) and the edge device 118 share a symmetric cryptographic key, K. Also, the mobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c) , including a private cryptographic key, c, and a public cryptographic key, C, described above.
- asymmetric cryptographic key pair, (C, c) including a private cryptographic key, c, and a public cryptographic key, C, described above.
- the illustrative method 2000 further assumes that an asymmetric cryptographic key pair, (D,d), including a private cryptographic key, d, and a public cryptographic key, D, has been stored to the cloud server 150 , and that the public cryptographic key, D, has been stored to the edge device 118 .
- the mobile device 114 also has stored thereon the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)) and signature thereof after the execution of the method 1900 of FIG. 19 .
- the illustrative method 2000 begins with flow 2002 of FIG. 20 in which the mobile device 114 and the edge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4.2 or newer connection). In doing so, the mobile device 114 and/or the edge device 118 may execute various Bluetooth-defined functions including, for example, getDevice , tryConnecting ( ), onSuccess, tryDiscovering ( ) and/or onServicesDiscovered ( ) functions. In flow 2004 , the mobile device 114 and the edge device 118 perform a secure key exchange to generate a shared cryptographic session key, s, separately at each of the mobile device 114 and the edge device 118 .
- a Bluetooth communication session/connection e.g., a BLE 4.2 or newer connection.
- the mobile device 114 and/or the edge device 118 may execute various Bluetooth-defined functions including, for example, getDevice , tryConnecting ( ), onSuccess, tryDiscovering
- the session key, s is generated based on Elliptical Curve Diffie-Hellman (ECDH). More specifically, in some embodiments, the mobile device 114 and the edge device 118 may execute a method similar to the method 2600 of FIG. 26 to perform the secure key exchange. However, it should be appreciated that the session key, s, may be generated based on a different key derivation function and/or other suitable algorithm in other embodiments. Following the execution of the secure key exchange, each of the mobile device 114 and the edge device 118 has the same session key, s, stored thereon.
- ECDH Elliptical Curve Diffie-Hellman
- the edge device 118 encrypts challenge data with the shared cryptographic session key, s.
- the challenge data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks.
- the encrypted challenge data may be represented as E s (challenge) .
- the edge device 118 transmits the encrypted challenge data, E s (challenge) , to the mobile device 114 via the established Bluetooth communication connection.
- the mobile device 114 decrypts the encrypted challenge data using the shared cryptographic session key, s, retrieved from a memory of the mobile device 114 and, in flow 2012 , the mobile device 114 (e.g., using the mobile application) builds a credential message including the challenge data received from the edge device 118 , the encrypted credential blob retrieved from the memory of the mobile device 114 , and the signature of the encrypted credential blob retrieved from the memory of the mobile device 114 .
- the mobile device 114 encrypts the credential message with the shared cryptographic session key, s, and in flow 2016 , the mobile device 114 cryptographically signs the encrypted credential message using the private key, c, of the cryptographic key pair (C, c) retrieved from a memory of the mobile device 114 . In other words, the mobile device 114 generates a cryptographic signature of the encrypted credential message.
- the mobile device 114 transmits the signed and encrypted credential message to the edge device 118 .
- the mobile device 114 transmits the encrypted credential message and the signature thereof to the edge device 118 .
- the edge device 118 decrypts the encrypted credential message using the shared cryptographic session key, s, retrieved from the memory of the edge device 118 .
- the edge device 118 verifies the challenge data. For example, in embodiments in which the challenge data is a nonce, the edge device 118 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 2006 - 2008 of FIG. 20 ). In other embodiments, it should be appreciated that the edge device 118 may otherwise verify and/or validate the decrypted challenge data.
- the edge device 118 verifies the signature of the encrypted credential blob using the public cryptographic key, D, retrieved from the memory of the edge device 118 . That is, the edge device 118 verifies that the encrypted credential blob was signed using the private key that corresponds with the public key, D. It should be appreciated that the edge device 118 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment).
- the edge device 118 decrypts the encrypted credential blob using the symmetric cryptographic key, K, retrieved from the memory of the edge device 118 and, in block 2028 , the edge device 118 extracts the credential and the public cryptographic key, C, from the decrypted credential blob.
- the edge device 118 and the cloud server 150 are capable of encrypting/decrypting the credential blob including the credential, whereas the mobile device 114 is not. Instead, in such embodiments, the mobile device 114 acts as a conduit for the secure transfer of the credential between the cloud server 150 and the edge device 118 .
- the edge device 118 verifies the signature of the encrypted credential message using the public cryptographic key, C, extracted from the decrypted credential blob. That is, the edge device 118 verifies that the encrypted credential message was signed using the private key that corresponds with the public key, C. It should be appreciated that the edge device 118 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). It should be further appreciated that the use of the cryptographic key pair (C, c) serves, for example, to prevent the unauthorized copying of a credential to a different mobile device 114 as described above in reference to FIGS. 15 - 17 .
- the edge device 118 processes the credential extracted from the credential blob. It should be appreciated that the credential may be processed in a manner similar to that described in reference to flow 1234 of FIG. 13 . As such, in some embodiments, the edge device 118 and/or other device(s) in the edge system 116 may make an access control decision based on the extracted credential and an access control database. Further, the edge device 118 itself or another device (e.g., the administrative system 110 , the access controller 134 , etc.) may perform the access control decision based on the particular embodiment. Further, in some embodiments, in response to successful authentication of the credential, the lock device 132 may unlock a lock mechanism as described above.
- further authentication of the user and/or the mobile device 114 may be required in advance of, or in conjunction with, the processing of the credential.
- the method 1800 of FIG. 18 may be executed to process a PIN of the user.
- the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, and/or additional information.
- the credential value and/or other portion of the credential may include an indicator that further authentication is required.
- the access control system 100 may execute a method 2200 for assigning a wireless access credential to a mobile number.
- a method 2200 for assigning a wireless access credential to a mobile number may be executed in conjunction with and prior to the method 2400 of FIGS. 24 - 25 .
- the illustrative method 2200 begins with flow 2202 of FIG. 22 in which the credential management system 102 transmits an indication that a new credential has been assigned to a mobile line/phone number of a user to the mobile access hub 112 .
- the system/site administrator may request that the credential be issued to the user (and/or the mobile line number) by the credential management system 102 , and the credential management system 102 may assign the credential to the user (and/or mobile line number).
- the credential management system 102 may leverage the credential API 124 to interface with and/or “call” the mobile access hub 112 requesting a message to be transmitted to the user's mobile device 114 (e.g., a text/SMS message).
- the mobile access hub 112 In flow 2204 , the mobile access hub 112 generates and transmits a deep link via SMS to the mobile device 114 at the mobile device number provided when the credential was issued to the user. In other embodiments, the mobile access hub 112 may interface with Twilio and/or another suitable messaging service for generating and transmitting the appropriate messages to the mobile device 114 . In flow 2206 , the mobile device 114 launches a corresponding mobile application via the deep link and obtains the mobile number of the mobile device 114 .
- the illustrative deep link is configured to launch a mobile application on the mobile device 114 to securely receive the credential or, if the mobile application not accessible (e.g., not installed) on the mobile device 114 , direct the user to the download location (e.g., an “App store”) to download the relevant mobile application.
- the mobile number may be obtained automatically, semi-automatically, or via user input depending on the particular embodiment. For example, some mobile device operating systems (e.g., Android operating systems) may allow the mobile application to access the mobile number via a simple prompt, whereas other mobile device operating systems (e.g., iOS operating systems) may require the user to manually enter the mobile number into the application.
- the mobile device 114 may establish a Transport Layer Security (TLS) connection with the mobile access hub 112 for secure communications.
- TLS Transport Layer Security
- the mobile device 114 (e.g., via the mobile application) transmits the obtained mobile number to the mobile access hub 112 (e.g., along with a request for a verification code) and, in flow 2210 , the mobile access hub 112 compares the mobile number to a credential database (e.g., an access control database) to determine whether the mobile number is already associated with a wireless access credential (e.g., a BLE credential). In doing so, the mobile access hub 112 may also determine whether the mobile number has already been authenticated (e.g., via a verification code and response).
- a credential database e.g., an access control database
- the method 2200 may advances to flow 2212 in which the mobile access hub 112 generates a verification code (e.g., a 6 -digit verification code) and transmits the verification code to the mobile device 114 via SMS.
- a verification code e.g., a 6 -digit verification code
- the mobile device 114 e.g., via a graphical user interface of the mobile application
- prompts the user to enter the verification code e.g., received by the mobile device 114 via SMS
- received/processes the user's input i.e., the code entry.
- the mobile device 114 generates an asymmetric cryptographic key pair, (P, p) , including a private cryptographic key, p, and a public cryptographic key, P, for storage to the mobile device 114 and use as described herein.
- asymmetric cryptographic key pair, (P, p), and corresponding public/private keys may vary by type depending on the particular embodiment.
- the asymmetric cryptographic key pair, (P, p) is generated based on elliptical curve cryptography (ECC) based on the EC P 256 curve.
- ECC elliptical curve cryptography
- the asymmetric cryptographic key pair may be associated with another suitable ECC curve.
- the asymmetric cryptographic key pair, (P, p) may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm.
- DSS Digital Signature Standard
- DSA Digital Signature Algorithm
- RSA Rivest-Shamir-Adleman
- ElGamal Rivest-Shamir-Adleman
- the public/private key sizes may vary depending, for example, on the particular algorithm employed.
- the asymmetric cryptographic key pair, (P, p) may be generated and stored on the mobile device 114 in advance of the execution of the method 2200 of FIG. 22 . Further, it should be appreciated that the mobile device 114 may generate the asymmetric cryptographic key pair, (P, p), in a trusted execution environment (TEE) or secure enclave in some embodiments.
- TEE trusted execution environment
- the mobile device 114 (e.g., using the mobile application) builds a payload including the public key, P, of the cryptographic key pair (P, p) retrieved from a memory of the mobile device 114 , the user-entered code, and the mobile number of the mobile device 114 .
- the mobile device 114 also builds another payload including a timestamp (e.g., generated from a real-time clock of the mobile device 114 ) and the mobile number of the mobile device 114 .
- the payload including the timestamp and mobile number may be utilized by the mobile access hub 112 as login credentials for the mobile device 114 .
- the mobile device 114 cryptographically signs the payloads using the private key, p, of the cryptographic key pair, (P, p) , retrieved from the memory of the mobile device 114 . In other words, the mobile device 114 generates a cryptographic signature of the payload built in flow 2218 and a cryptographic signature of the payload built in flow 2220 . In some embodiments, it should be appreciated that the mobile device 114 may combine the data of the two payloads into a single payload that is cryptographically signed. In flow 2224 , the mobile device 114 transmits the signed payloads to the mobile access hub 112 (e.g., via a TLS connection).
- the mobile access hub 112 e.g., via a TLS connection
- the mobile device 114 transmits each of the payloads (e.g., from flows 2218 - 2220 ) and the signatures thereof to the mobile access hub 112 .
- the mobile device 114 may transmit a single payload (or combination of payloads) and a single signature thereof to the mobile access hub 112 as indicated above.
- the mobile access hub 112 extracts the public key, P, from the payload (e.g., the first payload) received from the mobile device 114 and verifies the signature(s) of the payload(s) using that public key. That is, the mobile access hub 112 verifies that each of the relevant payloads was signed using the private key that corresponds with the public key, P. It should be appreciated that the mobile access hub 112 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment).
- the mobile access hub 112 extracts the user-entered code received from the mobile device 114 to the verification code transmitted from the mobile access hub 112 to the mobile device 114 in flow 2212 . It should be appreciated that the mobile access hub 112 may consider the mobile device 114 to be the device corresponding with the mobile number if the user-entered code matches the verification code. Otherwise, the mobile access hub 112 may undergo one or more error handling procedures (e.g., re-sending the verification code, etc.). In flow 2230 , the mobile access hub 112 associates the mobile number of the user with the wireless access credential in the credential database (e.g., an access control database).
- the credential database e.g., an access control database
- the mobile access hub 112 may subsequently determine that the mobile number is associated with a particular account (e.g., in flow 2210 of FIG. 22 ) and, for example, transmit a push notification to the mobile application of the mobile device 114 instead of transmitting a deep link to the mobile device 114 (e.g., for pulling multiple credentials associated with a mobile number).
- multiple credentials may be associated with the same mobile number and therefore the same mobile device 114 .
- techniques similar to those of the method 2200 may be used to onboard subsequent credentials after the mobile application has already been instead.
- the flows 2204 - 2214 regarding the downloading of the application and the code verification and the flow 2218 associated with building the payload with the user-entered code may be omitted.
- those flows 2204 - 2214 may be replaced with a flow in which the mobile access hub 112 determines that the mobile number is already associated with a credential and transmits a notification (e.g., a push notification) to the mobile device 114 regarding the assignment of the new credential to the mobile number, and the method 2200 may resume at flow 2216 to obtain the new credential.
- a notification e.g., a push notification
- the method 2200 may include flows (e.g., after the flow 2230 ) in which the mobile device 114 transmits a request to the mobile access hub 112 for a list or identification of the credentials and/or access rights of the mobile device 114 and/or associated with the mobile number (e.g., GET/MobileAccessRights), and the mobile access hub 112 responds with such list or identifiers (e.g., CMSMobileAccess A, CMSMobileAccess B). Based on the list, the mobile device 114 may request the proper credential.
- flows e.g., after the flow 2230
- the mobile device 114 transmits a request to the mobile access hub 112 for a list or identification of the credentials and/or access rights of the mobile device 114 and/or associated with the mobile number (e.g., GET/MobileAccessRights), and the mobile access hub 112 responds with such list or identifiers (e.g., CMSMobileAccess A, CMSMobileAccess B).
- the mobile device 114 may request the proper credential
- a modified version of the method 2200 may also be employed when a user gets a new mobile device 114 or deletes the mobile application such that the user's credentials need to be re-downloaded/on-boarded via the mobile access hub 112 .
- the mobile access hub 112 may re-verify the user's mobile number and re-download the credentials for that user.
- the flow 2204 associated with the transmission of the deep link from the mobile access hub 112 to the mobile device 114 may be omitted.
- the mobile device 114 may launch the newly installed mobile application in flow 2206 and resume execution of the method 2200 to onboard the credential.
- the access control system 100 allows the user to keep the same credentials without purchasing a new credential for each new mobile device 114 .
- the access control system 100 may execute a method 2400 for storing a wireless access credential to the mobile device 114 .
- a method 2400 for storing a wireless access credential to the mobile device 114 .
- the particular flows of the method 2400 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. Additionally, it should be appreciated that, in the illustrative embodiment, the method 2400 may be executed in conjunction with and prior to the method 2700 of FIGS. 27 - 29 and/or in conjunction with and subsequent to the method 2200 of FIGS. 22 - 23 .
- the illustrative method 2400 involves a key management system 108 , a credential management system 102 , a mobile access hub 112 , and a mobile device 114 (e.g., executing a mobile application as described herein).
- a key management system 108 may be embodied as cloud-based systems and/or may form a portion of one another.
- the illustrative method 2400 assumes that a cryptographic key exchange has occurred such that the key management system 108 and an edge device 118 or, more specifically, a main chipset 142 of an edge device 118 (see, for example, FIGS. 26 - 29 ) share a symmetric cryptographic key, K.
- the key management system 108 (and/or other cloud servers 150 ) and the edge device 118 may employ any suitable key exchange algorithm to do so.
- the symmetric cryptographic key, K may vary by type and/or length depending on the particular embodiment.
- the symmetric cryptographic key, K is embodied as 256-bit Advanced Encryption Standard (AES) keys.
- AES Advanced Encryption Standard
- the symmetric cryptographic keys may be associated with another cryptographic algorithm such as, for example, Data Encryption Standard (DES), Triple DES, Blowfish, Twofish, Serpent, and/or another symmetric cryptographic algorithm.
- the key may be a 128-bit keys, 512-bit key, or another size in other embodiments (e.g., depending on the cryptographic algorithm).
- the cryptographic key is generated by the key management system 108 and transmitted to the edge device 118 .
- the illustrative method 2400 further assumes that an asymmetric cryptographic key pair, (D, d), including a private cryptographic key, d, and a public cryptographic key, D, has been generated and stored to the key management system 108 , and that the public cryptographic key, D, has been stored to the edge device 118 or, more specifically, to the cryptography chipset 144 of the edge device 118 for use as described herein. It should be appreciated that they asymmetric cryptographic key pair, (D, d), and corresponding public/private keys may vary by type depending on the particular embodiment.
- the asymmetric cryptographic key pair (D, d), is generated based on elliptical curve cryptography (ECC) based on the EC P 256 curve.
- ECC elliptical curve cryptography
- the asymmetric cryptographic key pair may be associated with another suitable ECC curve.
- the asymmetric cryptographic key pair may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm.
- DSS Digital Signature Standard
- DSA Digital Signature Algorithm
- RSA Rivest-Shamir-Adleman
- ElGamal Rivest-Shamir-Adleman
- the public/private key sizes may vary depending, for example, on the particular algorithm employed.
- the asymmetric cryptographic key pair, (D, d) may be generated by the key management system 108 (or other cloud server 150 ) and the public cryptographic key, D, may be securely transmitted to the edge device 118 according to any suitable exchange protocol or provisioning mechanism.
- the method 2400 further assumes that the asymmetric cryptographic key pair, (P, p), including the private cryptographic key, p, and the public cryptographic key, P, have been generated and stored to the mobile device 114 as described above.
- the illustrative method 2400 begins with flow 2402 of FIG. 24 in which the mobile device 114 generates an asymmetric cryptographic key pair, (C,c), including a private cryptographic key, c, and a public cryptographic key, C, for storage to the mobile device 114 and use as described herein. Similar to the asymmetric cryptographic key pairs, (D, d) and (P, p), it should be appreciated that they asymmetric cryptographic key pair, (C,c), and corresponding public/private keys may vary by type depending on the particular embodiment.
- the asymmetric cryptographic key pair, (C, c) may be a similar type of key pair as the asymmetric cryptographic key pair, (D, d) , and/or the asymmetric cryptographic key pair, (P, p), described above.
- the asymmetric cryptographic key pair, (C,c) is generated based on elliptical curve cryptography (ECC) based on the EC P 256 curve.
- ECC elliptical curve cryptography
- the asymmetric cryptographic key pair may be associated with another suitable ECC curve.
- the asymmetric cryptographic key pair, (C, c) may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm.
- DSS Digital Signature Standard
- DSA Digital Signature Algorithm
- RSA Rivest-Shamir-Adleman
- ElGamal Rivest-Shamir-Adleman
- the public/private key sizes may vary depending, for example, on the particular algorithm employed.
- the asymmetric cryptographic key pair, (C,c) may be generated and stored on the mobile device 114 in advance of the execution of the method 2400 of FIG. 24 . Further, it should be appreciated that the mobile device 114 may generate the asymmetric cryptographic key pair, (C, c) , in a trusted execution environment (TEE) or secure enclave in some embodiments.
- TEE trusted execution environment
- the mobile device 114 (e.g., using the mobile application) builds a credential request including the public key, C, of the cryptographic key pair (C, c) retrieved from a memory of the mobile device 114 .
- the credential request may identify the payload as a credential request (e.g., via a corresponding flag, CRED_REQ).
- the credential request may be represented as CRED_REQ ⁇ C .
- the mobile device 114 cryptographically signs the credential request using the private key, c, of the cryptographic key pair , (C, c) , retrieved from a memory of the mobile device 114 .
- the mobile device 114 generates a cryptographic signature of the credential request.
- the mobile device 114 transmits the signed credential request to the mobile access hub 112 (e.g., via a TLS connection).
- the mobile device 114 transmits the credential request and the signature thereof to the mobile access hub 112 .
- the mobile access hub 112 forwards the signed credential request (e.g., the credential request and signature thereof) to the credential management system 102 .
- the credential management system 102 extracts the public key, C, from the credential request received from the mobile device 114 via the mobile access hub 112 and verifies the credential request signature using that public key. That is, the credential management system 102 verifies that the credential request was signed using the private key that corresponds with the public key, C. It should be appreciated that the credential management system 102 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment).
- the credential management system 102 builds a credential request payload including the public key, C, extracted from the credential request received from the mobile device 114 via the mobile access hub 112 , a facility code, a credential value of the credential, and a bit format of the credential. It should be appreciated that credential value and the bit format are of the credential requested and assigned to the mobile number of the mobile device 114 . Further, in some embodiments, the facility code may be associated with the site and/or organization that owns or administers the edge system 116 . In flow 2416 , the credential management system 102 transmits the credential request payload to the key management system 108 .
- the key management system 108 determines the credential to be transmitted to the mobile device 114 and builds a credential blob based on the credential request payload (e.g., based on the facility code, credential value, bit format, etc.).
- the key management system 108 builds a credential blob including the credential to be transmitted to the mobile device 114 (e.g., the credential assigned to the mobile number and the user) and the public key, C.
- the credential blob may further include a nonce value, for example, to reduce the efficacy of replay attacks.
- the credential blob may be represented as nonce ⁇ C ⁇ credential .
- the key management system 108 encrypts the credential blob with the symmetric cryptographic key, K, and, in flow 2422 , the key management system 108 cryptographically signs the encrypted credential blob using the private key, d, of the cryptographic key pair, (D, d) , stored in the memory of the key management system 108 . In other words, the key management system 108 generates a cryptographic signature of the encrypted credential blob.
- the key management system 108 transmits the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)) and the signature thereof to the credential management system 102 .
- the credential management system 102 records the use of the credential. For example, in some embodiments, the credential management system 102 may reduce the number of credits available to the administrative system 110 for issuance of new credentials. Further, the credential management system 102 may also track the use of the public cryptographic key, C, and/or various credential data (e.g., the credential value used). As indicated above, in some embodiments, one or more of those functions of the credential management system 102 may be performed in conjunction with the credential tracking system 104 and/or the credential ordering system 106 .
- the credential management system 102 transmits/forwards the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)) and the signature thereof to the mobile access hub 112 .
- the mobile access hub 112 may incorporate one or more types of metadata into the payload prior to transmittal to the mobile device 114 .
- the metadata may include one or more mobile access instructions, a list of edge devices 118 and/or lock devices 132 that the credential has access to, an expiration date of the payload, and/or other relevant metadata.
- the metadata is added to the signed and encrypted credential blob in the clear.
- a keyed hash or other integrity-verifying data may be included with the metadata to confirm that the metadata has not been modified.
- the mobile access hub 112 transmits the signed and encrypted credential blob to the mobile device 114 along with any metadata. That is, in the illustrative embodiment, the mobile access hub 112 transmits the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)) and the signature thereof to the mobile device 114 . In flow 2434 , the mobile device 1434 further encrypts the encrypted credential blob with the public cryptographic key, P, using a corresponding asymmetric encryption algorithm. It should be appreciated that, in some embodiments, the further encrypted credential blob may be represented as E p (E K (nonce ⁇ C ⁇ credential)) .
- the mobile device 114 stores the further encrypted credential blob (E P (E K (nonce ⁇ C ⁇ credential))), the signature of the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)), and the metadata (if any) to the memory of the mobile device 114 .
- the signature of the encrypted credential blob may be combined (e.g., concatenated) with the encrypted credential blob prior to asymmetric encryption by the public cryptographic key, P.
- the payload may be represented as E p (E K (nonce ⁇ C ⁇ credential) ⁇ dSig) .
- the credential blob or, more specifically, the encrypted credential blob is encrypted with the public cryptographic key, P, when the data is at rest on the mobile device 114 .
- the mobile device 114 now has a credential stored thereon that is tied to the mobile device 114 , but the mobile device 114 is unable to read the credential data due to the encryption.
- the memory of the mobile device 114 to which such data is stored is a secure memory.
- the metadata may be transmitted in the clear such that the metadata may be read by the mobile device 114 .
- the access control system 100 may execute a method 2600 for performing a key exchange between the mobile device 114 and an edge control device 118 of the access control system 100 .
- the particular flows of the method 2600 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary.
- the method 2600 may be executed in conjunction with the method 2400 of FIGS. 24 - 25 and/or the method 2700 of FIGS. 27 - 29 .
- the method 2600 may be executed subsequent to the method 2400 and prior to the method 2700 .
- a session key, s is generated based on Elliptical Curve Diffie-Hellman (ECDH).
- ECDH Elliptical Curve Diffie-Hellman
- the session key, s may be generated based on a different key derivation function and/or other suitable algorithm in other embodiments.
- the illustrative method 2600 begins with flow 2602 of FIG. 26 in which the mobile device 114 and the edge device 118 or, more specifically, the BLE chipset 140 of the edge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4 . 2 or newer connection).
- the mobile device 114 and/or the BLE chipset 140 of the edge device 118 may execute various Bluetooth-defined functions including, for example, getDevice ( ), tryConnecting ( ), onSuccess, tryDiscovering ( ), and/or onServicesDiscovered ( ) functions.
- the mobile device 114 In flow 2604 , the mobile device 114 generates an ephemeral key pair, (C 1 ,c 1 ), including a public ephemeral key, C 1 , and a private ephemeral key, c 1 .
- the public and private ephemeral keys are ECDH ephemeral keys. However, in embodiments in which other secure key exchange and/or shared key derivation algorithms are employed, the keys may be formed accordingly.
- the mobile device 114 transmits the public ephemeral key, C 1 , to the BLE chipset 140 of the edge device 118 .
- the BLE chipset 140 forwards the public ephemeral key, C 1 , to the main chipset 142 of the edge device 118 , which in flow 2610 forwards the public ephemeral key, C 1 , to the cryptography chipset 144 of the edge device 118 .
- the cryptography chipset 144 generates another ephemeral key pair (R, r) including a public ephemeral key, R, and a private ephemeral key, r.
- R, r ephemeral key pair
- the ephemeral keys of the ephemeral key pair, (R, r) may be of the same type as the ephemeral key pair, (C 1 , c 1 ) .
- the public and private ephemeral keys, R and r are ECDH ephemeral keys.
- the cryptography chipset 144 generates a shared cryptographic session key, s, based on the public ephemeral key, C 1 , received from the mobile device 114 (e.g., via the BLE chipset 140 and the main chipset 142 of the edge device 118 ) and the private ephemeral key, r, newly generated by the cryptography chipset 144 of the edge device 118 .
- the shared cryptographic session key, s may be generated based on generation of the corresponding portion of the ECDH algorithm.
- the cryptography chipset 144 of the edge device 118 transmits the public ephemeral key, R, to the main chipset 142 of the edge device 118 , which in flow 2618 forwards the public ephemeral key, R, to the BLE chipset 140 of the edge device 118 .
- the BLE chipset 140 further transmits the public ephemeral key, R, to the mobile device 114 .
- the mobile device 114 In flow 2622 , the mobile device 114 generates the shared cryptographic session key, s, based on the public ephemeral key, R, received from the edge device 118 (e.g., generated by the cryptography chipset 144 and transmitted via the BLE chipset 140 ) and the private ephemeral key, c 1 , generated by the mobile device 114 .
- the edge device 118 e.g., generated by the cryptography chipset 144 and transmitted via the BLE chipset 140
- the private ephemeral key, c 1 generated by the mobile device 114 .
- the mobile device 114 and the edge device 118 are able to generate the same shared cryptographic session key, s, based on the corresponding public/private ephemeral keys described above (e.g., (C 1 ,r) and (R, c 1 )). It should be further appreciated that the public cryptographic key, C, described herein may be used as the public ephemeral key, C 1 , for the generation of the shared cryptographic session key, s, in some embodiments.
- the access control system 100 may execute a method 2700 for using a wireless access credential (e.g., a wireless access credential stored to the mobile device 114 according to the method 2400 of FIGS. 24 - 25 ).
- a wireless access credential e.g., a wireless access credential stored to the mobile device 114 according to the method 2400 of FIGS. 24 - 25 .
- the particular flows of the method 2700 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary.
- the method 2700 of FIGS. 27 - 29 may be executed in conjunction with and subsequent to the method 2400 of FIGS. 24 - 25 and/or the method 2600 of FIG. 26 .
- the illustrative method 2700 involves the mobile device 114 and an edge device 118 or, more specifically, the BLE chipset 140 , the main chipset 142 , and the cryptography chipset 144 of the edge device 118 . Also, as described above in reference to FIGS. 22 - 26 , the illustrative method 2700 assumes that a cryptographic key exchange has occurred such that the key management system 108 and the edge device 118 or, more specifically, the main chipset 142 of the edge device 118 share a symmetric cryptographic key, K.
- the illustrative method 2700 further assumes that an asymmetric cryptographic key pair, (D,d), including a private cryptographic key, d, and a public cryptographic key, D, has been generated and stored to the key management system 108 , and that the public cryptographic key, D, has been stored to the edge device 118 or, more specifically, to the cryptography chipset 144 of the edge device 118 for use as described herein.
- an asymmetric cryptographic key pair, (D,d) including a private cryptographic key, d, and a public cryptographic key, D
- the mobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c), including a private cryptographic key, c, and a public cryptographic key, C, and the asymmetric cryptographic key pair, (P, p), including the private cryptographic key, p, and the public cryptographic key, P, described above.
- the method 2700 further assumes that a secure key exchange has been performed (e.g., ECDH) such that each of the mobile device 114 and the edge device 118 (or, more specifically, the cryptography chipset 144 ) has the shared cryptographic session key, s, as described above.
- the mobile device 114 and the edge device 118 may execute a method similar to the method 2600 of FIG.
- the mobile device 114 also has stored thereon the double-encrypted credential blob (E P (E K (nonce ⁇ C ⁇ credential))), the signature of the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)), and metadata (if any) after the execution of the method 2400 of FIGS. 24 - 25 as described above.
- E P double-encrypted credential blob
- E K once ⁇ C ⁇ credential
- metadata if any
- the mobile device 114 and the edge device 118 or, more specifically, the BLE chipset 140 of the edge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4.2 or newer connection).
- the mobile device 114 and/or the BLE chipset 140 of the edge device 118 may execute various Bluetooth-defined functions including, for example, getDevice ( ), tryConnecting ( ), onSuccess, tryDiscovering ( ), and/or onServicesDiscovered ( ) functions.
- the illustrative method 2700 begins with flow 2702 of FIG. 27 in which the cryptography chipset 144 of the edge device 118 transmits the shared cryptographic session key, s, generated in by the secure key exchange to the main chipset 142 of the edge device 118 .
- the main chipset 142 of the edge device 118 encrypts challenge data with the shared cryptographic session key, s.
- the challenge data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks.
- the encrypted challenge data may be represented as E s (challenge) .
- the main chipset 142 of the edge device 118 forwards the encrypted challenge data, E s (challenge), to the BLE chipset 140 of the edge device 118 and, in flow 2708 , the BLE chipset 140 transmits the encrypted challenge data, E s (challenge), to the mobile device 114 via the established Bluetooth communication connection.
- the mobile device 114 decrypts the encrypted challenge data using the shared cryptographic session key, s, retrieved from a memory of the mobile device 114 and, in flow 2712 , the mobile device 114 decrypts the stored double-encrypted credential blob (E P (E K (nonce ⁇ C ⁇ credential))) using the private cryptographic key, p, retrieved from the memory of the mobile device 114 .
- the mobile device 114 (e.g., using the mobile application) builds a credential message including the challenge data received from the edge device 118 via the BLE chipset 140 , the encrypted credential blob (E K (nonce ⁇ C ⁇ credential)) retrieved from the memory of the mobile device 114 , and the signature of the encrypted credential blob retrieved from the memory of the mobile device 114 .
- the mobile device 114 encrypts the credential message with the shared cryptographic session key, s, and in flow 2718 , the mobile device 114 cryptographically signs the encrypted credential message using the private key, c, of the cryptographic key pair (C, c) retrieved from a memory of the mobile device 114 . In other words, the mobile device 114 generates a cryptographic signature of the encrypted credential message.
- the mobile device 114 transmits the signed and encrypted credential message to the edge device 118 or, more specifically, to the BLE chipset 140 of the edge device 118 .
- the mobile device 114 transmits the encrypted credential message and the signature thereof to the BLE chipset 140 of the edge device 118 .
- the BLE chipset 140 forwards the signed and encrypted credential message to the main chipset 142 of the edge device 118 .
- the main chipset 142 of the edge device 118 decrypts the encrypted credential message using the shared cryptographic session key, s, retrieved from the memory of the edge device 118 .
- the main chipset 142 verifies the challenge data. For example, in embodiments in which the challenge data is a nonce, the main chipset 142 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 2704 - 2706 of FIG. 27 ). In other embodiments, it should be appreciated that the main chipset 142 of the edge device 118 may otherwise verify and/or validate the decrypted challenge data.
- the main chipset 142 transmits the signature of the encrypted credential blob to the cryptography chipset 144 and, in flow 2730 , the cryptography chipset 144 verifies the signature of the encrypted credential blob using the public cryptographic key, D, retrieved from the memory of the edge device 118 . That is, the cryptography chipset 144 verifies that the encrypted credential blob was signed using the private key that corresponds with the public key, D. It should be appreciated that the cryptography chipset 144 of the edge device 118 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). In flow 2732 , the cryptography chipset 144 transmits the results of the verification to the main chipset 142 .
- the cryptography chipset 144 transmits the results of the verification to the main chipset 142 .
- the main chipset 142 of the edge device 118 decrypts the encrypted credential blob using the symmetric cryptographic key, K, retrieved from the memory of the edge device 118 and, in block 2736 , the edge device 118 extracts the credential and the public cryptographic key, C, from the decrypted credential blob. Further, the main chipset 142 may also extract the signature of the encrypted credential message. It should be appreciated that, in the illustrative embodiment, the edge device 118 and the key management system 108 (and/or other cloud servers 150 ) are capable of encrypting/decrypting the credential blob including the credential, whereas the mobile device 114 is not. Instead, in such embodiments, the mobile device 114 acts as a conduit for the secure transfer of the credential between the key management system 108 and the edge device 118 .
- the main chipset 142 of the edge device 118 transmits the public cryptographic key, C, and the signature of the encrypted credential message extracted from the decrypted credential blob to the cryptography chipset 144 of the edge device 118 .
- the cryptography chipset 144 of the edge device 118 verifies the signature of the encrypted credential message using the public cryptographic key, C, extracted from the decrypted credential blob. That is, the cryptography chipset 144 verifies that the encrypted credential message was signed using the private key that corresponds with the public key, C.
- the cryptography chipset 144 of the edge device 118 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). It should be further appreciated that the use of the cryptographic key pair (C, c) serves, for example, to prevent the unauthorized copying of a credential to a different mobile device 114 as described above in reference to FIGS. 15 - 17 .
- the cryptography chipset 144 transmits the verification results to the main chipset 142 of the edge device 118 .
- the main chipset 144 of the edge device 118 processes the credential extracted from the credential blob. It should be appreciated that the credential may be processed in a manner similar to that described in reference to flow 1234 of FIG. 13 .
- the edge device 118 and/or other device(s) in the edge system 116 may make an access control decision based on the extracted credential and an access control database. Further, the edge device 118 itself or another device (e.g., the administrative system 110 , the access controller 134 , etc.) may perform the access control decision based on the particular embodiment.
- the lock device 132 may unlock a lock mechanism as described above.
- further authentication of the user and/or the mobile device 114 may be required in advance of, or in conjunction with, the processing of the credential.
- the method 1800 of FIG. 18 may be executed to process a PIN of the user.
- the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, and/or additional information.
- the credential value and/or other portion of the credential may include an indicator that further authentication is required.
- flows 2702 - 2744 are described in a relatively serial manner, it should be appreciated that various flows of the method 2700 may be performed in parallel in some embodiments. Further, it should be appreciated that, in other embodiments, one or more of the flows 2702 - 2744 identified as being performed by or associated with the BLE chipset 140 , the main chipset 142 , and/or the cryptography chipset 144 may be performed by or may be associated with another of the BLE chipset 140 , the main chipset 142 , and/or the cryptography chipset 144 .
- the access control system 100 may execute a method 3200 for revoking a wireless access credential. For example, among other reasons, an administrator may determine to revoke a wireless access credential when an employee departs or loses access privileges.
- an administrator may determine to revoke a wireless access credential when an employee departs or loses access privileges.
- the particular flows of the method 3200 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary.
- the illustrative method 3200 involves a credential management system 102 , a mobile access hub 112 , and a mobile device 114 (e.g., executing a mobile application as described herein).
- the method 3200 may be executed in conjunction with and subsequent to the method 2200 of FIGS. 22 - 23 and the method 2400 of FIGS. 24 - 25 (e.g., subsequent to assignment, issuance, and storage of the credential to the mobile device 114 ).
- the illustrative method 3200 begins with flow 3202 in which the credential management system 102 receives a credential revocation instruction from an administrator (e.g., via the administrative system 110 ) to revoke a particular credential, and the credential management system 102 processes that instruction. For example, in some embodiments, the credential management system 102 updates the relevant access control database(s) and/or other databases to reflect that the particular credential has been revoked and therefore is no longer valid. Depending on the particular embodiment, the revoked credential may be deleted, corrupted, tagged, and/or otherwise modified to be identified as a revoked/invalid credential. In other embodiments, it should be appreciated that the access control database(s) and/or other databases may be updated by the mobile access hub 112 .
- the credential management system 102 transmits the credential revocation instruction to the mobile access hub 112 . It should be appreciated that, in some embodiments, one or more unique identifiers of the credential may be transmitted in the credential revocation instruction payload.
- the mobile access hub 112 transmits a notification (e.g., a push notification) to the mobile device 114 indicating that the credential has been revoked and, in flow 3208 , the mobile device 114 launches the mobile application (e.g., automatically or in response to the user's input after reviewing the notification).
- the mobile device 114 builds a payload including a timestamp (e.g., generated from a real-time clock of the mobile device 114 ) and the mobile number of the mobile device 114 .
- the mobile device 114 cryptographically signs the payloads using the private key, p, of the cryptographic key pair, (P, p), described above and retrieved from the memory of the mobile device 114 .
- the mobile device 114 generates a cryptographic signature of the payload built in flow 3210 .
- the mobile device 114 transmits the signed payload to the mobile access hub 112 (e.g., via a TLS connection).
- the mobile device 114 transmits the payload and the signature thereof to the mobile access hub 112 .
- the payload may be utilized by the mobile access hub 112 as login credentials for the mobile device 114 .
- the mobile device 114 transmits a request to the mobile access hub 112 for the credential access rights of the mobile device 114 .
- the mobile access hub 112 determines the credential access rights of the mobile device 114 .
- the mobile access hub 112 may read the data stored in the access control database(s) and/or other relevant databases to determine the current access rights (e.g., as updated following the revocation). Further, in some embodiments, the mobile access hub 112 may communicate with the credential management system 102 to make such a determination.
- the mobile access hub 112 transmits a payload identifying the credential access rights of the mobile device 114 to the mobile device and, in flow 3222 , the mobile device 114 updates the memory of the mobile device 114 to update the credentials stored thereon. For example, in an embodiment in which the mobile number has two credentials and the first credential is revoked, it should be appreciated that the memory of the mobile device 114 is updated to identify only the second credential, thereby reflecting that the first credential is no longer valid.
- access credentials may expire after a certain period of time.
- the mobile application of the mobile device 114 may be required to check in every 48 hours to ensure the credential is still valid.
- the time after which the credential expires on the mobile device 114 may be configuration by the site administrator (e.g., via the administrative system 110 ). It should be further appreciated that, although omitted in part for brevity of the description, the method 3200 may involve one or more of the cryptographic functions described above.
- the illustrative access control system 3400 includes a peripheral controller 3402 , a management server 3404 , one or more cloud servers 3406 , a mobile device 3408 , a mobile device 3410 , a gateway device 3412 , a credential enrollment reader 3414 , an RS-485 reader 3416 , a Wiegand reader 3418 , and a credential 3420 . It should be appreciated that, in some embodiments, the access control system 3400 may “overlap” with the access control system 100 of FIG. 1 .
- the access control systems 100 , 3400 may share one or more devices/systems such that the access control system 3400 includes one or more of the devices/systems of the access control system 100 .
- the mobile access hub 112 of the access control system 100 may be configured to interface with the access control system 3400 or, more specifically, the management server 3404 and/or the cloud server(s) 3406 of the access control system 3400 (e.g., serving as a virtual router) in order to exchange data (e.g., for the control or management of devices in the access control system 100 ).
- the access control system 3400 and the cloud server(s) 3406 thereof may be embodied as a Schlage® ENGAGETM system and/or the Schlage® ENGAGETM cloud, respectively.
- the peripheral controller 3402 may be embodied as an ENGAGETM enabled controller such as, for example, the CTE Single Door Controller with Multi-Technology Reader available from Schlage.
- the access control system 3400 may control access to a passageway (e.g., through a doorway) to grant or deny user access through the passageway based on the credential 3420 presented by the user.
- the peripheral controller 3402 may be electrically and/or communicatively coupled to a credential reader 3416 , 3418 and configured to make an access control decision based on credential data received from a credential presented by a user to the credential reader 3416 , 3418 (e.g., based on an access control database that defines access permissions for various users/credentials).
- the peripheral controller 3402 may be electrically and/or communicatively coupled to an electronic lock, door strike, door latch, and/or other suitable lock mechanism configured to lock/unlock the corresponding passageway barrier (e.g., door/gate) such that the peripheral controller 3402 may instruct or signal (e.g., via a relay) the lock mechanism to permit/deny access through the barrier based on the access control decision.
- the peripheral controller 3402 is “peripheral” in the sense that it is not integrated with an electronic lock. That is, in the illustrative embodiment, the peripheral controller 3402 is not mounted on the door/barrier.
- the peripheral controller 3402 may be configured to communicate with the management server 3404 , the cloud server(s) 3406 , the mobile device 3408 , the mobile device 3410 , the gateway device 3412 , the RS-485 reader 3416 , and/or the Wiegand reader 3418 using various communication connections.
- the peripheral controller 3402 may communicate with the management server 3404 and/or the cloud server(s) 3406 over a Wi-Fi connection or via an Ethernet connection to exchange firmware updates, audits, an access control database or updates thereto, an access control schedule, usage information, and/or other suitable data.
- the peripheral controller 3402 may communicate with the mobile device 3408 (e.g., via a mobile application) over a Bluetooth connection (e.g., BLE) and/or Wi-Fi connection.
- a Bluetooth connection e.g., BLE
- Wi-Fi connection e.g., Wi-Fi connection
- the peripheral controller 3402 may communicate with the mobile device 3408 over a BLE connection to exchange data with a relatively small file size (e.g., configuration data) and over a Wi-Fi connection to exchange data with a relatively large file size (e.g., firmware updates, an access control database or updates thereto, audits, and/or usage information).
- the peripheral controller 3402 may communicate with the mobile device 3410 (e.g., via a mobile application of an OEM) over a Bluetooth connection (e.g., BLE) and/or Wi-Fi connection.
- a Bluetooth connection e.g., BLE
- Wi-Fi connection e.g., BLE
- the peripheral controller 3402 may communicate with the mobile device 3410 over a Wi-Fi connection to exchange firmware data and/or over a BLE connection to exchange configuration data, server commands (e.g., from the management server 3404 ), audits, and/or an access control database or updates thereto.
- the peripheral controller 3402 may communicate with the gateway device 3412 over a Bluetooth (e.g., BLE) connection to exchange credential information, real-time data, and/or firmware updates.
- BLE Bluetooth
- peripheral controller 3402 may communicate with the gateway device 3412 over an Ethernet connection between the peripheral controller 3402 and the gateway device 3412 . Additionally, in some embodiments, the peripheral controller 3402 may communicate directly with the management server 3404 via IP (e.g., using JSON), thereby enabling a direct to host communication connection.
- IP e.g., using JSON
- the peripheral controller 3402 may be communicatively coupled to one or more readers. More specifically, in some embodiments, the peripheral controller 3402 may be communicatively coupled to an RS-485 reader 3416 via an RS-485 link (e.g., a serial communication link) and/or a Wiegand reader 3418 via corresponding Wiegand and control lines. Although the peripheral controller 3402 is described herein as only being communicatively coupled to the readers 3416 , 3418 , it should be appreciated that the peripheral controller 3402 may, additionally or alternatively, be structured and configured to be communicatively coupled to one or more other types of credential readers in other embodiments.
- the management server 3404 may be configured to communicate directly with the peripheral controller 3402 (e.g., via a Wi-Fi or Ethernet connection). Further, in some embodiments, the management server 3404 may be configured to communicate with the gateway device 3412 (e.g., via IP using JSON) and with the mobile device 3410 (e.g., via Wi-Fi, CDMA, LTE, and/or GSM) to exchange firmware/updates, audits, an access control database or updates thereto, an access control schedule, and or usage information. In other words, in such embodiments, the peripheral controller 3402 may communicate with the management server 3404 via the mobile device 3410 and/or the gateway device 3412 .
- the gateway device 3412 e.g., via IP using JSON
- the mobile device 3410 e.g., via Wi-Fi, CDMA, LTE, and/or GSM
- the peripheral controller 3402 may communicate with the management server 3404 via the mobile device 3410 and/or the gateway device 3412 .
- the peripheral controller 3402 may communicate with the gateway device 3412 via a BLE or Ethernet connection, and the gateway device 3412 may, in turn, forward the communicated data to the management server 3404 via IP.
- the management server 3404 may communicate data to the gateway device 3412 and/or mobile device 3410 , which is forwarded to the peripheral controller 3402 via a suitable communication connection.
- the peripheral controller 3402 may communicate with the management server 3404 via an online mode with a persistent real-time communication connection or via an offline mode (e.g., periodically or in response to an appropriate condition) depending on the particular embodiment.
- the gateway device 3412 may be embodied as a hot spot device/reader and/or plug-in device.
- the management server 3404 may be configured to manage credentials of the access control system 3400 .
- the management server 3404 may be responsible for ensuring that the peripheral device 3402 has updated authorized credentials, whitelists, blacklists, device parameters, and/or other suitable data.
- the management server 3404 may be responsible for registering credentials with the access control system 3400 and/or distributing appropriate credentials for authorized access through the passageway controlled by the peripheral controller 3402 .
- the management server 3404 may receive security data, audit data, raw sensor data, and/or other suitable data from the peripheral controller 3402 (e.g., directly or indirectly) for management of the access control system 3400 .
- the management server 3404 may be communicatively coupled with the cloud server(s) 3406 and/or a cloud-based application.
- the management server 3404 may be embodied as an online server or a cloud-based server.
- the management server 3404 may communicate with multiple peripheral controllers 3402 at a single site (e.g., a particular building) and/or across multiple sites. That is, in such embodiments, the management server 3404 may be configured to receive data from peripheral controllers 3402 distributed across a single building, multiple buildings on a single campus, or across multiple locations.
- the cloud server(s) 3406 may be embodied as a cloud-based device or collection of devices within a cloud environment. In such embodiments, it should be appreciated that the server(s) 3406 may be embodied as a “serverless” or server-ambiguous computing solution, for example, similar to the cloud server(s) 150 of FIG. 1 described above.
- the credential enrollment reader 3414 may be embodied as any credential enrollment reader configured to enroll credentials (e.g., no-tour credentials via RFID).
- the credential enrollment reader 3414 may be embodied as a multi-technology enrollment reader such as the Schlage® (formerly aptiQ®) MT20W credential enrollment reader available from Schlage.
- the credential 3420 may be embodied as a MIFARE® Classic or MIFARE DESFireTM EV1 smart credential. It should be appreciated that the credential enrollment reader 3414 may receive “no tour” credential enrollment data from the management server 3404 directly or indirectly.
- the credential enrollment reader 3414 may receive the credential enrollment data directly from the management server 3404 via a Wi-Fi connection or indirectly from the cloud server(s) 3406 via a Wi-Fi connection.
- the credential enrollment reader 3414 may receive the credential enrollment data from the mobile device 3408 which, in turn, may have received the credential enrollment data from the cloud server(s) 3406 or the management server 3404 .
- the mobile device 3408 may be configured to communicate with the cloud server(s) 3406 via a Wi-Fi, CDMA, LTE, and/or GSM connection to exchange data for commissioning the peripheral controller 3402 or an electronic lock, firmware and/or firmware updates, audits, an access control database or updates thereto, usage information, credential enrollment data, and/or other relevant data. Additionally, the mobile device 3408 may be configured to communicate with the credential enrollment reader 3414 via a Bluetooth connection (e.g., BLE) and/or NFC to exchange the credential enrollment data.
- a Bluetooth connection e.g., BLE
- the RS-485 reader 3416 and/or the Weigand reader 3418 may be embodied as a Schlage® (formerly aptiQ®) MT11 multi-technology mullion reader or a Schlage® (formerly aptiQ®) MTK15 multi-technology single-gang keypad reader available from Schlage.
- the credential enrollment reader 3414 may store “no tour” credential enrollment data on the credential 3420 such that the reader 3416 , 3418 may read the credential enrollment data when the credential 3420 is presented to the reader 3416 , 3418 by the user. Further, the reader 3416 , 3418 may forward the credential enrollment data to the peripheral controller 3402 , and the peripheral controller 3402 may update the access control database stored thereon to permit access by the credential 3420 through a passageway controlled by the peripheral controller 3402 . Further, in some embodiments, the peripheral controller 3402 may simultaneously remove access permissions for another credential 3420 based on the credential enrollment data.
- the peripheral controller 3402 upon subsequent presentation of the newly enrolled credential 3420 to the reader 3416 , 3418 , the peripheral controller 3402 will permit access; however, upon subsequent presentation of the other credential 3420 (e.g., the old credential), the peripheral controller 3402 will deny access.
- the peripheral controller 3402 may update a flag, field, bit, byte, or other data structure stored on the “no tour” credential 3420 to indicate that the access control database has been updated. As such, in some embodiments, the peripheral controller 3402 may first analyze that data structure of the “no tour” credential 3420 to determine whether updating the access control database is required. If not, the peripheral controller 3402 may treat the credential 3420 as an ordinary credential and determine whether access is to be granted or denied.
- the illustrative access control system 3500 includes an electronic lock 3502 , a management server 3504 , one or more cloud servers 3506 , a mobile device 3508 , a mobile device 3510 , a gateway device 3512 , a credential enrollment reader 3514 , and a credential 3520 .
- the management server 3504 , the one or more cloud servers 3506 , the mobile device 3508 , the mobile device 3510 , the gateway device 3512 , the credential enrollment reader 3514 , and/or the credential 3520 may be the same device(s) as, or similar to, the management server 3404 , the one or more cloud servers 3406 , the mobile device 3408 , the mobile device 3410 , the gateway device 3412 , the credential enrollment reader 3414 , and the credential 3420 and, therefore, the descriptions of those devices have not been repeated herein for brevity of the disclosure.
- the illustrative access control system 3500 is similar in functionality to the access control system 3400 , however, the peripheral controller 3402 has been replaced with the electronic lock 3502 . Unlike the peripheral controller 3402 , the controller of the electronic lock 3502 is integrated with the electronic lock 3502 and, therefore, not “peripheral” in that sense.
- the access control system 3500 and the cloud server(s) 3506 thereof may be embodied as a Schlage® ENGAGETM system and/or the Schlage® ENGAGETM cloud, respectively.
- the electronic lock 3502 may be embodied as an ENGAGETM enabled lock.
- the access control system 3500 may “overlap” with the access control system 100 of FIG. 1 .
- the access control systems 100 , 3500 may share one or more devices/systems such that the access control system 3500 includes one or more of the devices/systems of the access control system 100 .
- the mobile access hub 112 of the access control system 100 may be configured to interface with the access control system 3500 or, more specifically, the management server 3504 and/or the cloud server(s) 3506 of the access control system 3500 (e.g., serving as a virtual router) in order to exchange data (e.g., for the control or management of devices in the access control system 100 ).
- an offline edge device 118 can update a local access control database on the edge device 118 (or other device of the edge system 116 ) using various techniques.
- the offline edge device 118 may establish a wireless communication connection (e.g., via Wi-Fi) with the cloud server 150 to retrieve access control updates periodically (e.g., daily).
- a system administrator may visit or “tour” the edge device 118 to initiate an access control update locally at the edge device 118 (e.g., via a wired or wireless connection between the edge device 118 and the mobile device 114 of the administrator).
- the system 100 may transmit “no tour” data to the mobile device 114 of a user having access to the edge device 118 for transmission to that edge device 118 . It should be appreciated that such a technique typically eliminates any need for a system administrator to visit the edge device 118 to make updates and also allows for updates to edge devices 118 that have no connectivity (e.g., no Wi-Fi connections or long-range wireless connections available). Such no tour implementations are described herein in reference to at least FIGS. 36 - 40 .
- FIGS. 36 - 37 simplified block diagrams illustrating various embodiments of no tour implementations of an access control system are shown. More specifically, FIGS. 36 - 37 illustrate communications between subsets of the various devices/systems of an access control device. In other words, communication capabilities and use cases of subsystems 3600 , 3700 are shown.
- the subsystem 3600 includes one or more cloud servers 3406 , 3506 , an enrollment reader 3414 , 3514 , a physical credential 3420 , 3520 , and an edge device 3402 , 3502 .
- the cloud servers 3406 , 3506 are configured to transmit data (e.g., access control data) to the enrollment reader 3414 , 3514 via a Wi-Fi communication connection, and the enrollment reader 3414 , 3514 is configured to write that data to a physical credential 3420 , 3520 .
- the edge device 3402 , 3502 receives the data (e.g., access control data) via RFID and/or NFC.
- presentation of the physical credential 3420 , 3520 to the edge device 3402 , 3502 may cause the transfer of access control data to a local database of the edge device 3402 , 3502 and/or other configuration data (e.g., in addition to the transmittal of the access credential of the physical credential 3420 , 3520 itself).
- the no tour data of the subsystem 3600 may be encrypted by a site key and further encrypted by a “smart key.”
- the payload may be represented as E smartkey (E sitekey (no_tour_data)) .
- the site key is a symmetric cryptographic key for encrypting the no tour data (e.g., used by the ENGAGETM system), and the smart key may be embodied as a key configured to encrypt sectors of the physical credential 3420 .
- the subsystem 3700 includes a key management system 108 , a mobile access hub 112 , a mobile device 114 , an edge device 118 , and an access control system 3400 , 3500 .
- the mobile access hub 112 serves the role of the enrollment reader 3414 , 3514 of FIG. 36 and the mobile device 114 (or, more specifically, the mobile application) serves the role of the physical credential 3420 , 3520 of FIG. 36 .
- the key management system 108 is configured to provide a signature of the encrypted payload (e.g., the no tour data) to be delivered to the mobile device 114 using one or more of the communication methods described above for transmittal of a credential.
- the key management system 108 may be embodied as the credential management system 102 , or the credential management system 102 may perform one or more functions of the key management system 108 .
- the no tour data of the subsystem 3500 is secured by a credential key and signed by the cloud server 150 (as described above), so the edge device 118 is able to trust the data source.
- the public key of the mobile device 114 ensures that data cannot be copied/moved to another device as described above, and the salt/nonce further randomizes the data.
- Sector data may also be transmitted to represent the data that would be provided by the reader with no tour data being in different sectors of the credential 3420 , 3520 .
- the payload may be represented as E credkey (E sitekey (no_tour_data) ⁇ sector ⁇ MD public ⁇ SALT)cloudSig, or using the keys described above, may be represented as E K (E sitekey (no_tour_data) ⁇ sector ⁇ C ⁇ nonce)dSig.
- the access control system 100 may execute a method 3800 for delivering no tour data and/or other access control data.
- the particular flows of the method 3800 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary.
- the illustrative method 3800 involves a mobile device 114 and an edge device 118 .
- the method 3800 may be executed in conjunction with one or more of the various methods described above. As such, various details may be omitted herein for brevity of the description.
- the illustrative method 3800 assumes that the mobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c) , including a private cryptographic key, c, and a public cryptographic key, C, described above.
- the illustrative method 3800 begins with flow 3802 in which the mobile device 114 and the edge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4.2 or newer connection) and perform a secure key exchange to generate a shared cryptographic session key, s, separately at each of the mobile device 114 and the edge device 118 .
- the session key, s may generated based on Elliptical Curve Diffie-Hellman (ECDH). More specifically, in some embodiments, the mobile device 114 and the edge device 118 may execute a method similar to the method 2600 of FIG. 26 to perform the secure key exchange.
- ECDH Elliptical Curve Diffie-Hellman
- session key, s may be generated based on a different key derivation function and/or other suitable algorithm in other embodiments.
- each of the mobile device 114 and the edge device 118 has the same session key, s, stored thereon.
- the edge device 118 encrypts challenge data with the shared cryptographic session key, s.
- the challenge data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks.
- the encrypted data may also include the message size and/or other relevant data.
- the encrypted challenge data may be represented as E s (challenge ⁇ size) .
- the edge device 118 transmits the encrypted challenge data, E s (challenge ⁇ size) , to the mobile device 114 via the established Bluetooth communication connection.
- the mobile device 114 decrypts the encrypted challenge data using the shared cryptographic session key, s, retrieved from a memory of the mobile device 114 .
- the mobile device 114 (e.g., using the mobile application) builds a no tour payload including the no tour data (e.g., which may itself be encrypted), the challenge data received from the edge device 118 , and the public cryptographic key, C, and the mobile device 114 encrypts that no tour payload with the shared cryptographic session key, s.
- the mobile device 114 cryptographically signs the encrypted no tour payload using the private key, c, of the cryptographic key pair (C, c) retrieved from a memory of the mobile device 114 . In other words, the mobile device 114 generates a cryptographic signature of the encrypted no tour payload.
- the mobile device 114 transmits the signed and encrypted no tour payload to the edge device 118 .
- the mobile device 114 transmits the encrypted no tour payload and the signature thereof to the edge device 118 .
- the edge device 118 decrypts the encrypted no tour message using the shared cryptographic session key, s, retrieved from the memory of the edge device 118 and verifies the cryptographic signature using the public cryptographic key, C, extracted from the payload in a manner similar to that described above.
- the edge device 118 processes the no tour payload.
- the edge device 118 e.g., an offline access control device
- the no tour data may include access control updates for mobile devices and/or physical credentials different from the mobile device 114 that transmitted the no tour data.
- the edge device 118 generates feedback data based on the processing of the no tour payload and, in flow 3822 , the edge device 118 transmits the feedback data to the mobile device 114 .
- the mobile device 114 processes the feedback data and, if successful, the mobile device 114 removes the no tour payload stored thereon.
- the edge device 118 only transmits feedback data if the processing of the no tour data was successful.
- the access control system 100 may execute a method 3900 for delivering no tour data and/or other access control data.
- the particular flows of the method 3900 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary.
- the illustrative method 3900 involves a cloud server 150 , a mobile device 114 , and an edge device 118 .
- the method 3900 may be executed in conjunction with one or more of the various methods described above. As such, various details may be omitted herein for brevity of the description.
- the illustrative method 3900 assumes that the mobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c), including a private cryptographic key, c, and a public cryptographic key, C, described above.
- the cloud server 150 is referenced herein as a cloud-based device, it should be appreciated that the cloud server 150 may be embodied as one or more computing devices situated outside of a cloud computing environment in some embodiments. In some embodiments, the cloud server 150 of FIG.
- 39 may be embodied as a system that includes one or more of the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , and/or the mobile access hub 112 described in reference to FIG. 1 .
- the illustrative method 3900 begins with flow 3902 in which the cloud server 150 updates access control data associated with one or more edge devices 118 .
- the access control data may be updated in response to the addition, deletion, and/or modification of access permissions for a particular user and/or mobile device 114 of the system 100 (e.g., by a system administrator or other suitable input/stimulus).
- the access control data update may update the access permissions associated with a particular user and/or credential including, for example, the edge devices 118 to which the user and/or credential has access (e.g., among other edge devices 118 ), an access authorization schedule identifying the time(s) at which such access is permission, an access initiation time indicating a first time at which access is authorized, an expiration time indicating a time after which access is unauthorized, and/or other access-related information depending on the particular embodiment.
- the access control data may include configuration data for one or more devices of the edge system 116 , firmware/software updates for one or more devices of the edge system 116 , audit data, usage information, and/or other relevant access control data.
- the mobile device 114 transmits (e.g., securely) its credential to the edge device 118 .
- the mobile device 114 and the edge device 118 may establish a Bluetooth communication session/connection (e.g., a BLE 4 . 2 or new connection) consistent with the techniques described above.
- the edge device 118 processes the credential in an attempt to authenticate the credential.
- the edge device 118 and/or other device(s) in the edge system 116 may make an access control decision based on the extracted credential and an access control database (e.g., stored locally) to determine whether the credential authorizes the user/bearer to perform a requested action (e.g., gain access). Further, in some embodiments, in response to successful authentication of the credential, the edge device 118 may unlock a lock mechanism as described above. In some embodiments, it should be appreciated that further authentication of the user and/or the mobile device 114 may be required in advance of, or in conjunction with, the processing of the credential. For example, in some embodiments, the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, PIN entry, and/or additional information.
- a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, PIN entry, and/or additional information.
- the edge device 118 If the authentication of the credential is unsuccessful (e.g., in response to a determination that the credential/user is not authorized to gain access), in flow 3908 , the edge device 118 generates and transmits a message to the mobile device 114 indicating that access has been denied, which the mobile device 114 transmits to the cloud server 150 in flow 3910 . Depending on the particular embodiment, the mobile device 114 may simply forward the access denied message received from the edge device 118 and/or generate a new message that is indicative of the access denial for transmission to the cloud server 150 .
- the mobile device 114 may establish a wireless communication connection (e.g., a Wi-Fi communication connection, cellular communication connection, telecommunication connection, and/or other suitable long range wireless communication connection) with the cloud server 114 in order to transmit the access denial message.
- a wireless communication connection e.g., a Wi-Fi communication connection, cellular communication connection, telecommunication connection, and/or other suitable long range wireless communication connection
- the cloud server 150 and the edge device 118 establish a secure communication connection/channel via the mobile device 114 .
- the mobile device 114 serves as a secure tunnel and intermediary node between the cloud server 150 and the edge device 118 .
- the establishment of the secure communication channel between the cloud server 150 and the edge device 118 via the mobile device 114 may be done in conjunction with the transmittal of the access denial message from the mobile device 114 to the cloud server 150 .
- the cloud server 150 transmits one or more of the updates to the access control data associated with the edge device 118 to the edge device 118 via the secure communication channel between the cloud server 150 and the edge device 118 (i.e., via the mobile device 114 ).
- the particular access control data transmitted from the cloud server 150 to the edge device 118 may vary depending on the particular embodiment.
- the cloud server 150 may transmit all of the updated access rights associated with the edge device 118 , whereas in other embodiments, the cloud server 150 may transmit only those updated access rights associated with specific users/credentials (e.g., of the mobile device 114 ) to the edge device 118 .
- the cloud server 150 may securely transmit some other subset of updated access rights to the edge device 118 . Further, it should be appreciated that the cloud server 150 may also transmit configuration data, firmware/software updates, and/or other relevant access control data to the edge device 118 . In some embodiments, it should be appreciated that the access control data transmitted from the cloud server 150 to the edge device 118 via the secure communication channel is in an encrypted format and/or otherwise inaccessible to the intermediary mobile device 114 .
- the edge device 118 updates the access control database of the edge system 116 based on the updates received from the cloud server 150 . Further, in some embodiments, the edge system 116 may perform (or schedule to perform) a firmware/software update, re-configuration, and/or other action dictated by a relevant update.
- the mobile device 114 re-transmits (e.g., securely) its credential to the edge device 118 .
- the mobile device 114 may leverage an existing communication connection (e.g., a Bluetooth communication connection) with the edge device 118 or establish a new communication connection/session with the edge device 118 to do so.
- the edge device 118 again processes the credential in an attempt to authenticate the credential.
- the edge device 118 may temporarily store the denied credential for the subsequent authentication attempt following the update to the access control database.
- the edge device 118 generates and transmits an access control decision message to the mobile device 114 indicating whether the credential was successfully authenticated (e.g., and access was gained). Specifically, in some embodiments, the message may indicate whether access was granted or denied. Further, in response to successful authentication of the credential, it should be appreciated that the edge device 116 may unlock a lock mechanism as described above. Further, as described above, in some embodiments, it should be appreciated that further authentication of the user and/or the mobile device 114 may be required in advance of, or in conjunction with, the processing of the credential.
- the edge device 118 may transmit an update confirmation message to the mobile device 114 indicative of whether the update to the access control database of the edge system 116 was successful and/or unsuccessful, which may be transmitted/forwarded to the cloud server 150 in flow 3924 .
- the edge device 118 may only transmit the update confirmation message to the mobile device 114 (and/or the mobile device 114 may only transmit/forward the update confirmation message to the cloud server 150 ) if the update to the access control database of the edge system 116 was successful.
- the edge device 118 may only transmit the update confirmation message to the mobile device 114 (and/or the mobile device 114 may only transmit/forward the update confirmation message to the cloud server 150 ) if the update to the access control database of the edge system 116 was unsuccessful.
- the edge device 118 provides no indication of the success of the update to the access control database of the edge system 116 to the mobile device 114 (and/or the mobile device 114 does not transmit/forward such indication to the cloud server 150 ) and, instead, the cloud server 150 assumes that the transmittal of the updated access control data via the secure communication channel between the cloud server 150 and the edge device 118 via the mobile device 114 (in flow 3914 ) has resulted in a successful update to the access control database of the edge system 116 .
- the access control system 100 may execute a method 4000 for delivering no tour data and/or other access control data.
- the particular flows of the method 4000 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary.
- the illustrative method 4000 involves a cloud server 150 , a mobile device 114 , and an edge device 118 .
- the method 4000 may be executed in conjunction with one or more of the various methods described above. As such, various details may be omitted herein for brevity of the description.
- the illustrative method 4000 assumes that the mobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c), including a private cryptographic key, c, and a public cryptographic key, C, described above.
- the cloud server 150 is referenced herein as a cloud-based device, it should be appreciated that the cloud server 150 may be embodied as one or more computing devices situated outside of a cloud computing environment in some embodiments. In some embodiments, the cloud server 150 of FIG.
- the 40 may be embodied as a system that includes one or more of the credential management system 102 , the credential tracking system 104 , the credential ordering system 106 , the key management system 108 , the administrative system 110 , and/or the mobile access hub 112 described in reference to FIG. 1 .
- the illustrative method 4000 begins with flow 4002 in which the cloud server 150 updates access control data associated with one or more edge devices 118 .
- the access control data may be updated in response to the addition, deletion, and/or modification of access permissions for a particular user and/or mobile device 114 of the system 100 (e.g., by a system administrator or other suitable input/stimulus).
- the access control data update may update the access permissions associated with a particular user and/or credential including, for example, the edge devices 118 to which the user and/or credential has access (e.g., among other edge devices 118 ), an access authorization schedule identifying the time(s) at which such access is permission, an access initiation time indicating a first time at which access is authorized, an expiration time indicating a time after which access is unauthorized, and/or other access-related information depending on the particular embodiment.
- the access control data may include configuration data for one or more devices of the edge system 116 , firmware/software updates for one or more devices of the edge system 116 , audit data, usage information, and/or other relevant access control data.
- the mobile device 114 establishes a wireless communication connection (e.g., a Wi-Fi communication connection, cellular communication connection, telecommunication connection, and/or other suitable long range wireless communication connection) with the cloud server 114 (e.g., via the Internet) and receives one or more of the updates to the access control data from the cloud server 150 .
- the cloud server 150 may determine (e.g., based on an access control database and/or relevant updates thereto) which edge devices 118 to which the user/credential and, therefore, the mobile device 114 is authorized to access, and the cloud server 150 may transmit the updated access control data associated with those edge devices 118 to the mobile device 114 .
- the cloud server 150 may determine (e.g., based on historical data) which edge devices 118 with which the mobile device has previously interacted and transmit the updated access control data associated with each of those edge devices 118 (e.g., on the premise that the mobile device 114 is likely to again interact with such edge devices 118 ). It should be appreciated that the device 114 , 150 initiating the establishment of the wireless communication connection between the mobile device 114 and the cloud server 150 may vary depending on the particular embodiment.
- the particular access control data transmitted from the cloud server 150 to the mobile device 114 may vary depending on the particular embodiment.
- the cloud server 150 may transmit all of the updated access rights associated with each edge device 118 , whereas in other embodiments, the cloud server 150 may transmit only those updated access rights associated with specific users/credentials (e.g., of the mobile device 114 ) for each edge device 118 .
- the cloud server 150 may securely transmit some other subset of updated access rights to the mobile device 114 .
- the cloud server 150 may also transmit configuration data, firmware/software updates, and/or other relevant access control data to the mobile device 114 .
- the access control data transmitted from the cloud server 150 to the mobile device 114 is in an encrypted format and/or otherwise stored in memory of the mobile device 114 in a format inaccessible to the mobile device 114 .
- the mobile device 114 scans (e.g., via Bluetooth) for edge devices 118 within communication range of the mobile device 114 to determine whether the mobile device 114 is within communication range of an edge device 118 for which the mobile device 114 has received updated access control data.
- the edge device 118 transmits a response message to the Bluetooth scan message (e.g., beacon).
- the mobile device 114 and the edge device 118 may establish a Bluetooth communication session/connection (e.g., a BLE 4.2 or new connection) consistent with the techniques described above.
- the mobile device 114 transmits one or more of the updates to the access control data associated with the edge device 118 to the edge device 118 via the secure communication connection between the mobile device 114 and the edge device 118 .
- the particular access control data transmitted from the mobile device 114 to the edge device 118 may vary depending on the particular embodiment.
- the mobile device 114 may transmit all of the updated access rights associated with the edge device 118 stored on the mobile device 114 , whereas in other embodiments, the mobile device 114 may transmit only those updated access rights associated with specific users/credentials (e.g., of the mobile device 114 ) to the edge device 118 .
- the mobile device 114 may securely transmit some other subset of updated access rights to the edge device 118 . Further, as indicated above, it should be appreciated that the mobile device 114 may also transmit configuration data, firmware/software updates, and/or other relevant access control data to the edge device 118 .
- the edge device 118 updates the access control database of the edge system 116 based on the updates received from the mobile device 114 . Further, in some embodiments, the edge system 116 may perform (or schedule to perform) a firmware/software update, re-configuration, and/or other action dictated by a relevant update.
- the mobile device 114 transmits (e.g., securely) its credential to the edge device 118 .
- the mobile device 114 may leverage an existing communication connection (e.g., a Bluetooth communication connection) with the edge device 118 or establish a new communication connection/session with the edge device 118 to do so.
- the mobile device 114 may transmit the updated access control data to the edge device 118 when the mobile device 114 is a first distance from the edge device 118 and subsequently (e.g., after the edge device 118 has updated the access control database) transmit the credential to the edge device 118 when the mobile device is a second (nearer) distance from the edge device 118 .
- the method 4000 may be performed in conjunction with one or more of the user intent techniques described herein.
- the edge device 118 processes the credential in an attempt to authenticate the credential. For example, in some embodiments, the edge device 118 and/or other device(s) in the edge system 116 may make an access control decision based on the extracted credential and an access control database (e.g., stored locally) to determine whether the credential authorizes the user/bearer to perform a requested action (e.g., gain access). Further, in some embodiments, in response to successful authentication of the credential, the edge device 118 may unlock a lock mechanism as described above. In some embodiments, it should be appreciated that further authentication of the user and/or the mobile device 114 may be required in advance of, or in conjunction with, the processing of the credential. For example, in some embodiments, the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, PIN entry, and/or additional information.
- a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other
- the edge device 118 In flow 4018 , the edge device 118 generates and transmits an access control decision message to the mobile device 114 indicating whether the credential was successfully authenticated (e.g., and access was gained). Specifically, in some embodiments, the message may indicate whether access was granted or denied. Additionally, in some embodiments, the edge device 118 may transmit an update confirmation message to the mobile device 114 indicative of whether the update to the access control database of the edge system 116 was successful and/or unsuccessful, which may be transmitted/forwarded to the cloud server 150 in flow 4020 .
- the edge device 118 may only transmit the update confirmation message to the mobile device 114 (and/or the mobile device 114 may only transmit/forward the update confirmation message to the cloud server 150 ) if the update to the access control database of the edge system 116 was successful. In yet other embodiments, the edge device 118 may only transmit the update confirmation message to the mobile device 114 (and/or the mobile device 114 may only transmit/forward the update confirmation message to the cloud server 150 ) if the update to the access control database of the edge system 116 was unsuccessful.
- the edge device 118 provides no indication of the success of the update to the access control database of the edge system 116 to the mobile device 114 (and/or the mobile device 114 does not transmit/forward such indication to the cloud server 150 ) and, instead, the cloud server 150 assumes that the transmittal of the updated access control data to the mobile device 114 (in flow 4004 ) has resulted in a successful update to the access control database of the edge system 116 . Further, in some embodiments, the edge device 118 may not generate or transmit any access control decision message to the mobile device 114 .
- the provisioning system 4100 may involve the provisioning and/or association of various cryptographic keys of the cryptography chipset 144 of the edge device 118 .
- the provisioning system 4100 includes the edge device 118 , a factory tester machine 4102 , a factory service 4104 , and a key management service 4106 .
- the factory tester machine 4102 , the factory service 4104 , and/or the key management service 4104 may be embodied as a device similar to the computing device 200 described in reference to FIG. 2 .
- the key management service 4104 may be embodied as, or form a portion of, the key management system 108 of FIG. 1 .
- the chart 3300 describes various cryptographic keys that are involved in the provisioning depicted in FIG. 41 .
- the edge device 118 when provisioning keys in the factory, the edge device 118 generates a unique asymmetric cryptographic key pair (R 1 , rl) including the public cryptographic key, RI, and the private cryptographic key, rl.
- the public cryptographic key, RI may be shared and stored in the key management service 3906 (e.g., the key management system 108 ) and may be used to generate a shared cryptographic session key, s or S, (e.g., via ECDH) which may be used to encrypt one or more cryptographic keys downloaded in the factory.
- the manufacturer origin public cryptographic keys, HI and H 2 may be downloaded to the edge device 118 .
- an asymmetric cryptographic key pair (F, f) including the public cryptographic key, F, and the private cryptographic key, f, is associated with each product line (e.g., each type of edge device 118 ) such that the private key, f is stored to the edge device 118 and the public key, F, is stored to the key management service 4106 .
- the edge device 118 cryptographically signs the public cryptographic key, RI, using the private cryptographic key, f and transmits both the public key, RI, and its signature (fSig) to the factory tester machine 4102 .
- the factory tester machine 4102 generates a serial number associated with the edge device 118 , generates a provisioning request (e.g., including RI, fSig, the serial number, the model number of the edge device 118 , and/or other relevant data), and transmits the provisioning request to the factory service 4104 , which in turn transmits the provisioning request to the key management service 4106 .
- the key management service 4106 may validate/verify the signature (fSig) of the public key (RI) based on the public key stored by the key management service 4106 , save the validated public key (RI) and process the provisioning request.
- the key management service 4106 may include a secure key vault having stored thereon various cryptographic keys including, for example, the cryptographic key pair (H 1 , hl) , the cryptographic key pair (H 2 , h 2 ) , the cryptographic key pair (D,d) , the symmetric cryptographic key (K), the public cryptographic key (RI) after receiving the provisioning request, and/or the public cryptographic key (F), the significance and properties of each of which is described in the chart 3300 of FIG. 33 .
- various cryptographic keys including, for example, the cryptographic key pair (H 1 , hl) , the cryptographic key pair (H 2 , h 2 ) , the cryptographic key pair (D,d) , the symmetric cryptographic key (K), the public cryptographic key (RI) after receiving the provisioning request, and/or the public cryptographic key (F), the significance and properties of each of which is described in the chart 3300 of FIG. 33 .
- the key management service 4106 generates an ephemeral cryptographic key pair (Q, q) , which is generated on a per-provisioning-request basis and not saved, and generates a provisioning payload.
- the provisioning payload includes the public ephemeral key (Q) and other cryptographic keys including, for example, H 1 , H 2 , K, and D.
- those cryptographic keys may be encrypted and signed according to E s (H 1 )h 2 Sig, E s (H 2 )h 1 Sig, E S (K)[h 1 Sig,h 2 Sig], and E s (D) [h 1 Sig, h 2 Sig].
- the provisioning payload including such cryptographic keys is transmitted by the key management service 4106 to the factory service 4104 , which forwards the provisioning payload to the factory tester machine 4102 , which in turn forwards the provisioning payload to the edge device 118 for provisioning thereon.
- the edge device 118 decrypts the various keys included in the provisioning payload using the shared cryptographic session key, S, cross validates/verifies the various signatures using the corresponding decrypted public cryptographic keys, H 1 and H 2 , and then installs the cryptographic keys from the provisioning payload into the memory of the edge device 118 or, more specifically, into the cryptography chipset 144 in some embodiments.
- FIG. 42 a simplified bloc diagram of a system 4200 for rolling cryptographic keys when the edge device 118 is in the field.
- the system 4200 includes the edge device 118 , the mobile device 114 , and the cloud server 150 of FIG. 1 .
- the public key (RI) are provided to the key management service 4106 (e.g., the key management system 108 ) and the manufacturer origin keys (H 1 and H 2 ) are stored to the edge device 118 .
- the key management service 4106 e.g., the key management system 108
- H 1 and H 2 manufacturer origin keys
- the cloud server 150 is able to generate a new set of cryptographic keys that can be downloaded to the edge device 118 , which may involve an ECDH session key unique to the edge device 118 and a signature by the cloud 150 using a manufacturer origin private key (h 1 or h 2 ) to verify that the key originated from the cloud server 150 . Because the keys used to roll are different from the keys used for rolling, there is an opportunity to recover the keys if a failure occurs.
- the transmission of the rolling payload from the cloud server 150 to the edge device 118 is similar to the transmission of the provisioning payload to the edge device 118 as described in reference to FIG. 41 .
- the cloud server 150 generates an ephemeral cryptographic key pair (Q, q), which is generated on a per-request basis and not saved, and generates a rolling payload.
- the rolling payload includes the public ephemeral key (Q), which is cryptographically signed by the origin key (h 1 ).
- the rolling payload may include the cryptographic keys, H 1 , H 2 , K, and/or D.
- those cryptographic keys may be encrypted and signed according to E s (H 1 )h 2 Sig, E s (H 2 )h 1 Sig, E s (K)(h 1 Sig), and/or E s (D)h 1 Sig
- the rolling payload including such cryptographic keys is transmitted by the cloud server 150 to the mobile device 114 .
- the mobile device 114 then, in turn, transmits the rolling payload (e.g., via BLE) to the edge device 118 .
- the edge device 118 decrypts the various keys included in the rolling payload using the shared cryptographic session key, S, cross validates/verifies the various signatures using the corresponding decrypted public cryptographic keys, H 1 and H 2 , and then installs the new cryptographic key(s) from the rolling payload into the memory of the edge device 118 or, more specifically, into the cryptography chipset 144 in some embodiments.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Power Engineering (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Mobile Radio Communication Systems (AREA)
- Lock And Its Accessories (AREA)
- Chemical Treatment Of Fibers During Manufacturing Processes (AREA)
Abstract
Description
- This application is a continuation of U.S. patent application Ser. No. 16/578,747 filed on Sep. 23, 2019 and issued as U.S. Pat. No. 11,388,595, which claims the benefit of U.S. Provisional Application No. 62/734,548 filed on Sep. 21, 2018, the contents of which each application are incorporated herein by reference in their entirety.
- Access control systems typically involve the use of credentials to manage the operation of an access control device (e.g., a lock device). Such credentials may be assigned to a particular user or device and are often physical in nature, forming at least a portion of, for example, a smartcard, proximity card, key fob, token device, or mobile device. Thus, credential systems generally require an interaction between the credential and a reader device (e.g., on or secured to the access control device) such that the reader device may read the credential and determine whether access should be granted. In particular, a user may be required to swipe, tap, or otherwise present the credential to the reader device. In other embodiments, the user intent is verified via the user's interaction with the reader device (e.g., turning a handle/knob, capacitive touch sense, etc.). As such, access control systems generally require an active physical action on behalf of the user in order to grant the user access via the access control device.
- According to an embodiment, a method of using a wireless access credential in an access control system may include at least a server system, a mobile device, and an access control edge device. The method may include encrypting, by the server system and using a symmetric cryptographic key stored by the server system and the access control edge device, a credential blob including a wireless access credential and a first public cryptographic key provided by the mobile device, wherein the first public cryptographic key and a first private cryptographic key are a first asymmetric cryptographic key pair stored by the mobile device, transmitting, by the server system, the encrypted credential blob to the mobile device for storage by the mobile device, establishing a secure wireless communication connection between the mobile device and an access control edge device including generating a shared cryptographic key, encrypting, by the mobile device and using the shared cryptographic key, a credential message including the encrypted credential blob, cryptographically signing, by the mobile device and using the first private cryptographic key, the encrypted credential message, transmitting, by the mobile device, the encrypted and signed credential message to the access control edge device, decrypting, by the access control edge device and using the shared cryptographic key, the encrypted and signed credential message to extract the encrypted credential blob, decrypting, by the access control edge device and using the symmetric cryptographic key, the encrypted credential blob to extract the wireless access credential, and unlocking a lock mechanism of an electronic lock associated with the access control edge device in response to successful authentication of the wireless access credential.
- In some embodiments, the method may further include cryptographically signing, by the mobile device and using the first private cryptographic key, a credential request including the first public cryptographic key, transmitting, by the mobile device, the signed credential request to the server system, and verifying, by the server system, the credential request signature based on the first public cryptographic key retrieved from the signed credential request, wherein encrypting the credential blob comprises encrypting the credential blob in response to successful verification of the credential request signature.
- In some embodiments, the method may further include generating, by the server system, a keyed hash of the encrypted credential blob using the symmetric cryptographic key, wherein transmitting the encrypted credential blob further comprises transmitting the keyed hash to the mobile device for storage by the mobile device, and wherein the credential message further includes the keyed hash.
- In some embodiments, the keyed hash may be a keyed-hash message authentication code (HMAC).
- In some embodiments, the method may further include verifying, by the access control edge device and using the symmetric cryptographic key, the keyed hash in the credential message in response to decrypting the encrypted and signed credential message and verifying, by the access control edge device, the credential message signature based on the first public cryptographic key extracted from the decrypted credential blob.
- In some embodiments, the method may further include encrypting, by the access control edge device and using the shared cryptographic key, challenge data, transmitting, by the access control edge device, the encrypted challenge data to the mobile device, and decrypting, by the mobile device and using the shared cryptographic key, the encrypted challenge data, wherein the credential message further includes the challenge data.
- In some embodiments, the method may further include verifying, by the access control edge device, the challenge data in response to decrypting the encrypted and signed credential message.
- In some embodiments, the method may further include cryptographically signing, by the server system, the encrypted credential blob using a second private cryptographic key, wherein the second private cryptographic key and a second public cryptographic key are a second asymmetric cryptographic key pair stored by the server system, and wherein the second public cryptographic key is stored by the access control edge device, wherein transmitting the encrypted credential blob comprises transmitting the signed and encrypted credential blob to the mobile device for storage by the mobile device, and wherein the credential message includes the signed and encrypted credential blob.
- In some embodiments, the method may further include verifying, by the access control edge device, the encrypted credential blob signature based on the second public cryptographic key retrieved from a memory of the access control edge device and verifying, by the access control edge device, the credential message signature based on the first public cryptographic key extracted from the decrypted credential blob.
- In some embodiments, the method may further include encrypting, by the access control edge device and using the shared cryptographic key, pin request data, transmitting, by the access control edge device, the encrypted pin request data to the mobile device, decrypting, by the mobile device and using the shared cryptographic key, the pin request data, receiving, by the mobile device, a pin value entered by a user of the mobile device, encrypting, by the mobile device and using the shared cryptographic key, a pin response including the pin value and the pin request data, transmitting, by the mobile device, the encrypted pin response to the access control edge device, decrypting, by the access control edge device and using the shared cryptographic key, the pin response, verifying, by the access control edge device, the pin request data in response to decrypting the pin response, and authenticating the pin value in response to successful verification of the pin request data.
- In some embodiments, unlocking the lock mechanism may include unlocking the lock mechanism in response to successful authentication of the wireless access credential and successful authentication of the pin value.
- In some embodiments, the first asymmetric cryptographic key pair may be an elliptical curve cryptography key pair.
- In some embodiments, generating the shared cryptographic key may include performing an Elliptical Curve Diffie-Hellman key exchange.
- In some embodiments, the method may further include encrypting, by the mobile device and using a third public cryptographic key, the encrypted credential blob received from the server system prior to storage of the encrypted credential blob, wherein the third public cryptographic key and a second private cryptographic key are a third asymmetric cryptographic key pair stored by the mobile device and decrypting, by the mobile device and using the third private cryptographic key, the stored encrypted credential blob prior to building the credential message.
- According to another embodiment, an access control system may include an access control edge system comprising a lock mechanism, a mobile device, and a server system to encrypt, using a symmetric cryptographic key stored by the server system and the access control edge system, a credential blob including a wireless access credential and a first public cryptographic key provided by the mobile device, wherein the first public cryptographic key and a first private cryptographic key are an asymmetric cryptographic key pair stored by the mobile device and transmit the encrypted credential blob to the mobile device for storage by the mobile device. The mobile device may be to establish a secure wireless communication connection between the mobile device and an access control edge system including generating a shared cryptographic key, encrypt, using the shared cryptographic key, a credential message including the encrypted credential blob, cryptographically sign the encrypted credential message using the first private cryptographic key, and transmit the encrypted and signed credential message to the access control edge system. The access control edge system may be to decrypt, using the shared cryptographic key, the encrypted and signed credential message to extract the encrypted credential blob, decrypt, using the symmetric cryptographic key, the encrypted credential blob to extract the wireless access credential, and unlock the lock mechanism in response to successful authentication of the wireless access credential.
- In some embodiments, the server system may include at least one cloud-based server.
- In some embodiments, the server system may include a credential management system, a key management system, and a mobile access hub.
- In some embodiments, the access control edge system may include a Bluetooth chipset, a main chipset, and a cryptography chipset.
- According to an embodiment, an access control edge device for simultaneous connectivity may include a Bluetooth Low Energy (BLE) communication circuitry, a processor, and a memory comprising a plurality of instructions stored thereon that, in response to execution by the processor, causes the access control edge device to establish a first persistent communication connection with a first device using the BLE communication circuitry and establish a second persistent communication connection with a second device using the BLE communication circuitry without dropping the first persistent communication connection with the first device.
- In some embodiments, the first device may be a gateway device and the second device may be a mobile device.
- In some embodiments, the memory may include a local access control database and the plurality of instructions may further cause the access control edge device to receive a BLE access credential from the mobile device while simultaneously receiving a real-time update from a host server via the gateway device and perform an access control decision based on the BLE access credential and the local access control database.
- In some embodiments, the plurality of instructions may further cause the access control edge device to transmit, via the BLE communication circuitry, a BLE advertisement to remote devices in a vicinity of the access control edge device while the first persistent communication connection is established, and wherein establishing the second persistent communication connection with the second device may include establishing the second persistent communication connection with the mobile device in response to receipt of the BLE advertisement by the mobile device.
- In some embodiments, the plurality of instructions may further cause the access control edge device to receive a BLE access credential from the mobile device via the second persistent communication connection and transmit the BLE access credential to an access control system via the first persistent communication connection with the gateway device to perform an access control decision.
- In some embodiments, the access control edge device may include a credential reader.
- In some embodiments, the access control edge device may include a physical lock mechanism.
- In some embodiments, the first device may be a first mobile device and the second device may be a second mobile device.
- In some embodiments, the first device may be an administrative device and the second device may be a user mobile device.
- According to another embodiment, a method for simultaneous connectivity with an access control edge device may include establishing, by the access control edge device, a first persistent communication connection with a first device using a BLE communication circuitry of the access control edge device and establishing, by the access control edge device, a second persistent communication connection with a second device using the BLE communication circuitry without dropping the first persistent communication connection with the first device.
- In some embodiments, establishing the first persistent communication connection may include establishing the first persistent communication connection with a gateway device and establishing the second persistent communication connection may include establishing the second persistent communication connection with a mobile device without dropping the first persistent communication connection with the first device.
- In some embodiments, the method may further include receiving, by the access control edge device, a BLE access credential from the mobile device while simultaneously receiving a real-time update from a host server via the gateway device and performing, by the access control edge device, an access control decision based on the BLE access credential and a local access control database stored on the access control edge device.
- In some embodiments, the method may further include transmitting, by the access control edge device using the BLE communication circuitry, a BLE advertisement to remote devices in a vicinity of the access control edge device while the first persistent communication connection with the gateway device is established and wherein establishing the second persistent communication connection with the second device may include establishing the second persistent communication connection with the mobile device in response to receipt of the BLE advertisement by the mobile device.
- In some embodiments, the method may further include receiving, by the access control edge device, a BLE access credential from the mobile device via the second persistent communication connection and transmitting, by the access control edge device, the BLE access credential to an access control system via the first persistent communication connection with the gateway device to perform an access control decision.
- In some embodiments, establishing the first persistent communication connection may include establishing the first persistent communication connection with a first mobile device and establishing the second persistent communication connection may include establishing the second persistent communication connection with a second mobile device without dropping the first persistent communication connection with the first device.
- In some embodiments, establishing the first persistent communication connection may include establishing the first persistent communication connection with an administrative device and establishing the second persistent communication connection may include establishing the second persistent communication connection with a user mobile device without dropping the first persistent communication connection with the first device.
- According to yet another embodiment, one or more non-transitory machine-readable storage media may include a plurality of instructions stored thereon that, in response to execution by an access control edge device, causes the access control edge device to establish a first persistent communication connection with a first device using a BLE communication circuitry and establish a second persistent communication connection with a second device using the BLE communication circuitry without dropping the first persistent communication connection with the first device.
- In some embodiments, the first device may be a gateway device and the second device may be a mobile device.
- In some embodiments, the plurality of instructions may further cause the access control edge device to receive a BLE access credential from the mobile device while simultaneously receiving a real-time update from a host server via the gateway device and perform an access control decision based on the BLE access credential and a local access control database stored on the access control edge device.
- In some embodiments, the plurality of instructions may further cause the access control edge device to transmit, using the BLE communication circuitry, a BLE advertisement to remote devices in a vicinity of the access control edge device while the first persistent communication connection with the gateway device is established, wherein the second persistent communication connection with the mobile device is established in response to receipt of the BLE advertisement by the mobile device, receive a BLE access credential from the mobile device via the second persistent communication connection, and transmit the BLE access credential to an access control system via the first persistent communication connection with the gateway device to perform an access control decision.
- According to an embodiment, an access control system may include an administrative system, a mobile access hub, an access control edge system comprising a lock mechanism and a Bluetooth Low Energy (BLE) communication circuitry, and a credential management system to issue a BLE access credential to a user in response to a request for issuance of the BLE access credential by the administrative system and transmit the BLE access credential to the mobile access hub. The mobile access hub may be to transmit the BLE access credential to a mobile device associated with the user. The administrative system may be to update an access control database to associate the BLE access credential with the mobile device. The access control edge system may be to receive the BLE access credential from the mobile device via the BLE communication circuitry and unlock the lock mechanism in response to successful authentication of the BLE access credential.
- In some embodiments, transmitting the BLE access credential to the mobile access hub may include calling the mobile access hub via a credential management application programming interface to transmit a message to the mobile device and transmitting the BLE access credential to the mobile device associated with the user may include transmitting the message to the mobile device including a deep link that retrieves the BLE access credential from the mobile access hub via a mobile application.
- In some embodiments, transmitting the message may include transmitting a Short Message Service (SMS) message to the mobile device.
- In some embodiments, the credential management system may further receive the request for issuance of the BLE access credential via a web portal.
- In some embodiments, the credential management system may further receive the request for issuance of the BLE access credential via an automated integrated application programming interface between the administrative system and the credential management system.
- In some embodiments, issuing the BLE access credential may include ensuring that a credential value of the BLE access credential is unique to a site at which the access control edge system is located.
- In some embodiments, issuing the BLE access credential may include issuing the BLE access credential in response to a determination that an entity associated with the administrative system has sufficient credential credits for issuance of a new BLE access credential.
- In some embodiments, the access control edge system may further perform authentication of the BLE access credential.
- In some embodiments, the access control edge system may include a peripheral controller to authenticate the BLE access credential.
- In some embodiments, at least one of the credential management system or the mobile access hub may include a cloud-based system.
- According to another embodiment, a method may include issuing, by a credential management system, a Bluetooth Low Energy (BLE) access credential to a user in response to a request for issuance of the BLE access credential by an administrative system, transmitting, by the credential management system, the BLE access credential to a mobile device associated with the user, updating, by the administrative system, an access control database to associate the BLE access credential with the mobile device, receiving, by an access control edge device, the BLE access credential from the mobile device via a BLE communication connection between the access control edge device and the mobile device, and unlocking a lock mechanism of an electronic lock in response to successful authentication of the BLE access credential.
- In some embodiments, transmitting the BLE access credential to the mobile device associated with the user may include transmitting, by the credential management system, the BLE access credential to a mobile access hub and transmitting, by the mobile access hub, the BLE access credential to the mobile device.
- In some embodiments, transmitting the BLE access credential to the mobile device associated with the user may include calling, by the credential management system, the mobile access hub via a credential management application programming interface to transmit a message to the mobile device and transmitting, by the mobile access hub, the message to the mobile device including a deep link that retrieves the BLE access credential from the mobile access hub via a mobile application.
- In some embodiments, transmitting the message may include transmitting a Short Message Service (SMS) message to the mobile device.
- In some embodiments, the method may further include receiving, by the credential management system, the request for issuance of the BLE access credential via a web portal.
- In some embodiments, the method may further include receiving, by the credential management system, the request for issuance of the BLE access credential via an automated integrated application programming interface between the administrative system and the credential management system.
- In some embodiments, issuing the BLE access credential may include ensuring that a credential value of the BLE access credential is unique to a site at which the electronic lock is located.
- In some embodiments, issuing the BLE access credential may include issuing the BLE access credential in response to a determination that an entity associated with the administrative system has sufficient credential credits for issuance of a new BLE access credential.
- In some embodiments, the method may further include performing, by the access control edge device, authentication of the BLE access credential, and the access control edge device may include the electronic lock.
- In some embodiments, the method may further include transmitting, by the access control edge device, the BLE access credential to a peripheral controller for authentication.
- In some embodiments, the method may further include transmitting, by the mobile device, the BLE access credential to the mobile device via the BLE communication connection in response to a determination of a user intent to access a passageway secured by the electronic lock.
- In some embodiments, unlocking the lock mechanism of the electronic lock may include unlocking the lock mechanism in response to a determination of a user intent to access a passageway secured by the electronic lock.
- Further embodiments, forms, features, and aspects of the present application shall become apparent from the description and figures provided herewith.
- The concepts described herein are illustrative by way of example and not by way of limitation in the accompanying figures. For simplicity and clarity of illustration, elements illustrated in the figures are not necessarily drawn to scale. Where considered appropriate, references labels have been repeated among the figures to indicate corresponding or analogous elements.
-
FIG. 1 is a simplified block diagram of at least one embodiment of an access control system for using a wireless access credential; -
FIG. 2 is a simplified block diagram of at least one embodiment of a computing system; -
FIGS. 3-8 are simplified block diagrams illustrating various communication capabilities of the access control system ofFIG. 1 ; -
FIG. 9 is an example data structure of at least one embodiment of a wireless access credential; -
FIG. 10 is a simplified flow diagram of at least one embodiment of a method of using a wireless access credential in the access control system ofFIG. 1 ; -
FIG. 11 is a simplified flow diagram of at least one embodiment of a method of storing a wireless access credential to a mobile device of the access control system ofFIG. 1 ; -
FIGS. 12-13 are a simplified flow diagram of at least one embodiment of a method of using the wireless access credential ofFIG. 11 ; -
FIG. 14 is a simplified flow diagram of at least one embodiment of a method for further authenticating a user of the mobile device ofFIG. 1 ; -
FIG. 15 is a simplified flow diagram of at least one embodiment of another method of storing a wireless access credential to the mobile device ofFIG. 1 ; -
FIGS. 16-17 are a simplified flow diagram of at least one embodiment of a method of using the wireless access credential ofFIG. 15 ; -
FIG. 18 is a simplified flow diagram of at least one embodiment of another method for further authenticating a user of the mobile device ofFIG. 1 ; -
FIG. 19 is a simplified flow diagram of at least one embodiment of yet another method of storing a wireless access credential to the mobile device ofFIG. 1 ; -
FIGS. 20-21 are a simplified flow diagram of at least one embodiment of a method of using the wireless access credential ofFIG. 19 ; -
FIGS. 22-23 are a simplified flow diagram of at least one embodiment of a method of assigning a wireless access credential; -
FIGS. 24-25 are a simplified flow diagram of at least one embodiment of a method of storing a wireless access credential to the mobile device ofFIG. 1 ; -
FIG. 26 is a simplified flow diagram of at least one embodiment of a method of performing a key exchange between the mobile device and an access control edge device ofFIG. 1 ; -
FIGS. 27-29 are a simplified flow diagram of at least one embodiment of a method of using the wireless access credential ofFIGS. 24-25 ; -
FIGS. 30-31 are simplified diagrams of a graphical user interface of the mobile device ofFIG. 1 ; -
FIG. 32 is a simplified flow diagram of at least one embodiment of a method of revoking a wireless access credential; -
FIG. 33 is a chart depicting cryptographic keys associated with at least one embodiment of a cryptography chipset; -
FIG. 34 is a simplified block diagram of at least one embodiment of an access control system including a peripheral controller; -
FIG. 35 is a simplified block diagram of at least one embodiment of an access control system including an electronic lock; -
FIGS. 36-37 are simplified block diagrams illustrating various embodiments of no tour implementations in access control systems; -
FIGS. 38-40 are simplified flow diagrams of embodiments of at least one method of delivering no tour data; -
FIG. 41 is a simplified block diagram illustrating cryptographic key provisioning during factor setup of an edge device; and -
FIG. 42 is a simplified bloc diagram illustrating rolling cryptographic keys when an edge device is in the field. - Although the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described herein in detail. It should be understood, however, that there is no intent to limit the concepts of the present disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.
- References in the specification to “one embodiment,” “an embodiment,” “an illustrative embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. It should further be appreciated that although reference to a “preferred” component or feature may indicate the desirability of a particular component or feature with respect to an embodiment, the disclosure is not so limiting with respect to other embodiments, which may omit such a component or feature. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. Additionally, it should be appreciated that items included in a list in the form of “at least one of A, B, and C” can mean (A); (B); (C); (A and B); (B and C); (A and C); or (A, B, and C). Similarly, items listed in the form of “at least one of A, B, or C” can mean (A); (B); (C); (A and B); (B and C); (A and C); or (A, B, and C). Further, with respect to the claims, the use of words and phrases such as “a,” “an,” “at least one,” and/or “at least one portion” should not be interpreted so as to be limiting to only one such element unless specifically stated to the contrary, and the use of phrases such as “at least a portion” and/or “a portion” should be interpreted as encompassing both embodiments including only a portion of such element and embodiments including the entirety of such element unless specifically stated to the contrary.
- The disclosed embodiments may, in some cases, be implemented in hardware, firmware, software, or a combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).
- In the drawings, some structural or method features may be shown in specific arrangements and/or orderings. However, it should be appreciated that such specific arrangements and/or orderings may not be required. Rather, in some embodiments, such features may be arranged in a different manner and/or order than shown in the illustrative figures unless indicated to the contrary. Additionally, the inclusion of a structural or method feature in a particular figure is not meant to imply that such feature is required in all embodiments and, in some embodiments, may not be included or may be combined with other features.
- The terms longitudinal, lateral, and transverse may be used to denote motion or spacing along three mutually perpendicular axes, wherein each of the axes defines two opposite directions. The directions defined by each axis may also be referred to as positive and negative directions. Additionally, the descriptions that follow may refer to the directions defined by the axes with specific reference to the orientations illustrated in the figures. For example, the directions may be referred to as distal/proximal, left/right, and/or up/down. It should be appreciated that such terms may be used simply for ease and convenience of description and, therefore, used without limiting the orientation of the system with respect to the environment unless stated expressly to the contrary. For example, descriptions that reference a longitudinal direction may be equally applicable to a vertical direction, a horizontal direction, or an off-axis orientation with respect to the environment. Furthermore, motion or spacing along a direction defined by one of the axes need not preclude motion or spacing along a direction defined by another of the axes. For example, elements described as being “laterally offset” from one another may also be offset in the longitudinal and/or transverse directions, or may be aligned in the longitudinal and/or transverse directions. The terms are therefore not to be construed as further limiting the scope of the subject matter described herein.
- Referring now to
FIG. 1 , in the illustrative embodiment, anaccess control system 100 for using a wireless access credential includes acredential management system 102, acredential tracking system 104, acredential ordering system 106, akey management system 108, anadministrative system 110, amobile access hub 112, amobile device 114, and an accesscontrol edge system 116. Additionally, as shown inFIG. 1 , the accesscontrol edge system 116 may include one or more access control edge devices 118 (e.g., areader device 130, a lock device 132), anaccess controller 134, and/or agateway device 136 depending on the particular embodiment. - As described in detail below, the illustrative
access control system 100 leverages wireless access credentials (e.g., Bluetooth or Bluetooth Low Energy (BLE) access credentials) to allow a user to securely gain access to a secured area (e.g., through a door or other passageway) using his or hermobile device 114 even when themobile device 114 is offline. That is, the credentialedmobile device 114 may permit access without leveraging a real-time connection to thecredential management system 102, theadministrative system 110, and/or other credential management devices and systems. In some embodiments, the wireless access credentials may be delivered to theedge device 118 via a Bluetooth or, more specifically, a BLE communication connection. As such, it should be appreciated that the wireless access credential may be referred to, for example, as a Bluetooth access credential or a BLE access credential. In some embodiments, once decrypted, the wireless access credentials may be in the same format as traditional physical credentials, which allows an existing access control system to process the wireless access credentials and grant/deny access without significant changes to the infrastructure. In the illustrative embodiment, the wireless access credentials are generated in a cloud-based computing environment (e.g., a cloud-based credential management system 102) and delivered to end user mobile devices 114 (e.g., via a mobile access hub 112). Themobile device 114 may execute a mobile application to deliver the wireless access credential to alock device 132,reader device 130, and/orother edge device 118. Additionally, in the illustrative embodiment, thelock device 132,reader device 130, and/orother edge device 118 may establish and simultaneously maintain multiple Bluetooth (e.g., BLE) wireless communication connections. For example, in some embodiments, theedge device 118 may be persistently connected to agateway device 136 while simultaneously receiving a BLE access credential from amobile device 114. Accordingly, in embodiments that permit multiple simultaneous persistent connections, it is generally unnecessary to periodically break an existing connection in order to establish a connection with another BLE device. It should be appreciated that, in some embodiments, theaccess control system 100 allows for the use of a near field communication (NFC) access credential and a BLE access credential via the same mobile application on amobile device 114. In some embodiments, the BLE wireless communications established by the various devices of theaccess control system 100 may be compliant with Bluetooth Core Specification Version 4.2 or newer. - As described herein, various embodiments of the illustrative system 100 support improved security, support the authorized transferability of issued/existing credentials to a different mobile device 114 without the purchase of new credentials (e.g., when a using gets a new mobile device 114), support the ability of devices (e.g., edge devices 118) to have multiple simultaneous and persistent BLE connections, support multiple mobile credential technologies in the same mobile application (e.g., BLE and NFC), support multiple credentials on a single mobile device 114 within the same mobile application (e.g., work credential, gym credential, home credential, etc.), provide for onboarding a mobile device 114 via a user's mobile line number (e.g., even with iOS devices), allow for the revocation and/or expiration of credentials on the mobile device 114 (e.g., for convenience and increased procedural security), allow “no tour” functionality via a BLE credential (e.g., to add user access rights to a lock device 132 without an administrator touring the door and/or using a card), prevent copying of a credential for use on a different mobile device 114, support a secondary credential via the mobile device 114 (e.g., using a PIN without a keypad on the edge device 118), use a cryptography chipset to enhance security and performance, support the ability to roll BLE credential keys in the field securely, and/or support integration with other access control systems and domains (e.g., via the mobile access hub 112). In some embodiments, the
illustrative system 100 further supports openness by virtue of the availability of the corresponding software development kit(s) (SDKs) and application programming interface(s) (APIs). As such, the credentials may be embedded with OEM partner applications, thereby allowing the OEM partner to leverage the credentials in a custom manner. For example, if a university has created its own application for students, the university could add the credential into that application and use it for access instead of having them use a secondary application for access control. Theillustrative system 100 is also amendable to subscription based credential issuance models. - It should be appreciated that each of the
credential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, themobile access hub 112, themobile device 114, theedge system 116, the edge device(s) 118, thereader device 130, thelock device 132, theaccess controller 134, and thegateway device 136 may be embodied as any type of device or collection of devices suitable for performing the functions described herein. More specifically, in the illustrative embodiment, thecredential management system 102 is configured to manage the issuance of wireless access credentials, provide support for channel partners, and otherwise perform the functions described herein. As depicted inFIG. 1 , in some embodiments, thecredential management system 102 includes, serves, or otherwise interfaces with aweb application 120 and one or more APIs for interaction with other devices and/or systems. For example, in the illustrative embodiment, thecredential management system 102 includes anadministrative API 122 for interacting with theadministrative system 110 and/or site/facility administrators and acredential API 124 for interacting with themobile access hub 112 for exchanging credential data and/or related information. In some embodiments, thecredential management system 102 is configured to communicate and/or interact with thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, and themobile access hub 112. For example, as described below, thecredential management system 102 may encrypt and issue a new wireless/mobile access credential (e.g., a BLE credential and/or NFC credential) to a user or mobile device in response to a new credential order from thecredential ordering system 106 and a credential request from theadministrative system 110. Thecredential management system 102 may also coordinate with thecredential tracking system 104 to ensure that the credential value of the issued credential is not duplicative of another issued credential. - The
credential tracking system 104 provides additional security to theaccess control system 100 by tracking credential values (e.g., credential “card” numbers) that are issued to ensure that the credential values are not duplicated. In some embodiments, thecredential tracking system 104 ensures that credential values are not duplicated across a particular site, whereas in other embodiments, thecredential tracking system 104 ensures that credential values are not duplicated across all credential values ever used. For example, the credential value may be composed of the facility/site code and a unique credential/badge value. As such, in some embodiments, thecredential tracking system 104 ensures that the entire credential value is unique, whereas in other embodiments thecredential tracking system 104 ensures that credential/badge value is unique. Such differences may be based, for example, on the bit format of the particular credential. - The
credential ordering system 106 processes orders of credentials placed by a customer such as, for example, an original equipment manufacturer (OEM), systems integrator, wholesaler, locksmith, or other relevant party. In particular, a customer may submit a purchase order for BLE credentials via thecredential ordering system 106, which interfaces with thecredential management system 102 to populate credential credits in thecredential management system 102 indicative of a number of credentials available to the customer for issuance to users (e.g., one credential credit equaling one wireless access credential available for issuance). As such, it should be appreciated that upon issuance of a credential, thecredential management system 102 reduces the number of credential credentials available for issuance of credentials. In some embodiments, thecredential ordering system 106 may include or leverage an Oracle Application (e.g., Oracle Applications Release 11i, Oracle Documentation Library Release 12i, etc.) to perform one or more functions described herein. - The
key management system 108 is configured to securely store and control access to cryptographic keys and other secure data (e.g., credentials), and to perform cryptographic functions on behalf of thecredential management system 102. For example, as described in greater detail below, thekey management system 108 may access an issued credential, generate a credential blob (e.g., a credential-bearing payload) including the credential and/or other relevant data, and encrypt the credential blob for transmittal to thecredential management system 102. In some embodiments, it should be appreciated that thekey management system 108 may leverage or include an Azure Key Vault to perform various functions described herein (e.g., in cloud-based embodiments). In other embodiments, it should be appreciated that thekey management system 108 may be omitted and/or form a portion of thecredential management system 102. It should be further appreciated that the monikers assigned herein to the various cryptographic keys are for readability and may vary in other embodiments without loss of generality. Additionally, the order and/or other organizational aspects of the data transmitted in payloads described herein may vary depending on the particular embodiment. - The
administrative system 110 includes one or more devices accessible to a site/facility administrator to perform various system administrative functions, maintenance functions, updates, and/or other suitable functions as described herein. In some embodiments, the site administrator may utilize theadministrative system 110 to access the credential management system 102 (e.g., via theweb application 120 or portal) to monitor various features associated with theaccess control system 100 including, for example, the number of credential credits available for distribution of credentials to end user'smobile devices 114. Further, theadministrative system 110 may be used to request a new wireless access credential to be assigned/issued and transmitted to amobile device 114 of an end user. For example, in some embodiments, theadministrative system 110 may manually request the credential issuance via theweb application 120. In other embodiments, theadministrative system 110 may be integrated with thecredential management system 102 via theadministrative API 122 such that the issuance of credentials may be automated. Theadministrative API 122 may further enable theadministrative system 110 to simultaneously issue a credential to a user and add the user to the relevant access control database(s). - In some embodiments, the
administrative system 110 may be configured to manage credentials of theaccess control system 100 with respect to the access control database(s). For example, theadministrative system 110 may be responsible for ensuring that the access control database has updated authorized credentials, whitelists, blacklists, device parameters, and/or other suitable data. Additionally, in some embodiments, theadministrative system 110 may receive security data, audit data, raw sensor data, and/or other suitable data fromvarious edge devices 118. - The
mobile access hub 112 interfaces directly with themobile device 114 of a user and also interfaces with thecredential management system 102 via thecredential API 124 to receive the user's credential(s) for transmittal to themobile device 114 via the mobile application. Further, in some embodiments, themobile access hub 112 is leveraged during the onboarding of a wireless access credential as described below. More specifically, themobile access hub 112 may generate and transmit a deep link via Short Message Service (SMS) to themobile device 114 at the mobile device number entered when the credential was issued to the user. As described below, the deep link may be configured to launch a mobile application on themobile device 114 to securely receive the credential or, if the mobile application not accessible on themobile device 114, direct the user to the download location (e.g., an “App store”) to download the relevant mobile application. In other embodiments, themobile access hub 112 may interface with Twilio and/or another suitable messaging service for generating and transmitting the appropriate messages to themobile device 114. Similarly, in some embodiments, themobile access hub 112 may interface with Branch.IO and/or another suitable service for generating deep links. Further, in some embodiments, the messages may be transmitted to themobile device 114 via email and/or another suitable communication mechanism. It should be appreciated that themobile access hub 112 serves as an interface or hub between thecredential management system 102 andmobile devices 114. In some embodiments, themobile access hub 112 may be configured to interface with theaccess control system 3400 and/or theaccess control system 3500 described below, for example, for the exchange of various data between the systems. Further, in some embodiments, themobile access hub 112 may also interface with other systems of theaccess control system 100 not described herein for brevity of the description. - As described herein, in some embodiments, the
mobile access hub 112 is responsible for the onboarding ofmobile devices 114, the activation/expiration of credentials, revocation of credentials, and/or account recovery. It should be further appreciated that themobile access hub 112 may also serve as an interface to other access control systems having different protocols, devices, control domains, and/or systems. For example, in some embodiments, themobile device 114 may be configured to store multiple/dynamic credentials including a cryptographic bearer token (e.g., a cryptographic macaroon), and themobile access hub 112 may serve as an interface between themobile device 114 and a corresponding access control system such as the access control system 100 (or, more specifically, a cloud server thereof) for flexible access control over offline devices described in U.S. Patent Application No. 15/656,641, titled “Leveraging Flexible Distributed Tokens in an Access Control System” and filed on Jul. 21, 2017 (hereinafter the “Leveraging Flexible Distributed Tokens” application), the entirety of which is incorporated herein by reference. In some embodiments, theaccess control system 100 of the Leveraging Flexible Distributed Tokens application and the cloud server thereof may be embodied as a Schlage® Sense™ system and/or cloud server, respectively. - The
mobile device 114 may be embodied as a mobile computing device, cellular phone, smartphone, wearable computing device, personal digital assistant, Internet of Things (IoT) device, or other mobile device suitable for performing the functions described herein. As described herein, themobile device 114 is configured to wirelessly communicate with themobile access hub 112 and various edge devices 118 (e.g.,lock devices 132,reader devices 130, etc.). In some embodiments, themobile device 114 installs and executes a mobile application to securely communicate with the various devices of theaccess control system 100. It should be appreciated that the mobile application may be embodied as any suitable application for performing the functions described herein. For example, in some embodiments, the mobile application is embodied as a smartphone application. In other embodiments, the application may serve (e.g., in part) as a client-side user interface for a web-based application or service (e.g., of the mobile access hub 112). Further, it should be appreciated that, in some embodiments, the mobile application may be embodied as or otherwise include a software development kit (SDK), one or more libraries, and/or user interfaces. - In some embodiments, the mobile application of the
mobile device 114 can support both a BLE credential and a NFC credential within the same application. Further, in some embodiments, both credentials for a particular user or mobile number have the same credential value such that there's only one entry in the access control database to identify that user. In some embodiments, in use, the user may have an option to select to send a BLE credential to theedge device 118 or just tap themobile device 114 to the edge device 118 (or, more specifically, the reader device 130) such that a peer-to-peer connection is detected by themobile device 114 and themobile device 114 transmits the NFC credential to theedge device 118. As such, in some embodiments, the mobile application can support newer BLE-only reader devices 130 in addition to older SMARTtechnology reader devices 130 that support NFC. Further, if necessary (e.g., in high 2.4 GHz BLE frequency areas), NFC may be used as a backup to BLE. Also, themobile device 114 may transmit a BLE credential in circumstances that previously may have required more user interaction (e.g., transmitting a BLE credential in parking garages without lowering the vehicle window). In other embodiments, it should be appreciated that BLE credential or the NFC credential may be selected based on the user intent, which may be determined according to any suitable technique. Depending on the particular embodiment, the mobile application may also support revocation or expiration of credentials, multiple credentials on the samemobile device 114, and/or off-line use of the credential. - The access
control edge system 116 includes one or more accesscontrol edge devices 118 including, for example, areader device 130 and/or alock device 132. Additionally, in some embodiments, the accesscontrol edge system 116 may further include one or more intermediate devices including, for example, anaccess controller 134 and/or agateway device 136. As described in greater detail below in reference toFIGS. 24-29 and, for example, in addition to the components described in reference toFIG. 2 , it should be appreciated that each of the accesscontrol edge devices 118 may include aBLE chipset 140, amain chipset 142, and acryptography chipset 144. In such embodiments, theBLE chipset 140 may be configured to transmit, receive, and/or process BLE communications. Further, themain chipset 142 may include a main/primary processor of the accesscontrol edge device 118. Additionally, thecryptography chipset 144 may be configured to quickly and efficiently perform various cryptographic functions on behalf of the accesscontrol edge device 118. It should be appreciated that, in some embodiments, each of thechipsets edge device 118 may include I2C and/or similar security between themain chipset 142 and thecryptography chipset 144. - It should be appreciated that the
cryptography chipset 144 may be embodied as any integrated circuit(s) and/or other circuitry suitable for performing the functions described herein. However, in the illustrative embodiment, thecryptography chipset 144 is designed and structured to efficiency perform cryptographic functions based on Elliptical Curve Cryptography (ECC) including, for example, Elliptical Curve Diffie Hellman (ECDH), Elliptical Curve Digital Signature Algorithm (ECDSA), asymmetric (public/private) cryptographic key generation, and cryptographic key storage. In some embodiments, thecryptography chipset 144 is configured to perform ECDH and ECDSA calculations in fewer than two hundred milliseconds. Such efficiency improves battery performance and the overall user experience due to the credential being processed quickly. In some embodiments, thecryptography chipset 144 includes a set of cryptographic keys (W1, W2) that secures the writing of keys such that different cryptographic keys cannot be written to thecryptographic chipset 144 by another party after thecryptography chipset 144 has been factory provisioned. Additionally, in some embodiments, thecryptography chipset 144 includes some cryptographic keys that are designed to change/roll and others that do not. At least one configuration of cryptographic keys provisioned/stored to thecryptography chipset 144 is depicted in thechart 3300 ofFIG. 33 . As shown, thechart 3300 depicts specific keys and key pairs and the associated purpose of the key or key pair, and whether the key or key pair can be read, written, and/or rolled. - The
reader device 130 is configured to communicate withmobile devices 114 to receive wireless access credentials (e.g., Bluetooth or BLE credentials) that are processed in order to make a corresponding access control decision with respect to thatmobile device 114. As such, thereader device 130 includes Bluetooth and/or other suitable wireless communication circuitry. Additionally, in some embodiments, thereader device 130 may be further configured to read contactless credentials (e.g., via RFID or NFC) and/or contact credential presented to thereader device 130. - The
lock device 132 includes an access control mechanism and is configured to control access through a passageway. For example, in some embodiments, the access control mechanism may be embodied as a lock mechanism configured to be positioned in a locked state in which access to the passageway is denied, or may be positioned in an unlocked state in which access to the passageway is permitted. In some embodiments, the lock mechanism includes a deadbolt, latch bolt, lever, and/or other mechanism adapted to move between the locked and unlocked state and otherwise perform the functions described herein. However, it should be appreciated that the access control mechanism may be embodied as any another mechanism suitable for controlling access through a passageway in other embodiments. In some embodiments, thelock device 132 may be embodied as an electronic lock including areader device 130, whereas in other embodiments, thelock device 132 may be separate from thereader device 130. - In some embodiments, the
reader device 130 may be electrically coupled to anaccess controller 134 that analyzes the received credential data. For example, thereader device 130 may be embodied as an RS-485 reader or Wiegand reader. Further, in such embodiments, theaccess controller 134 may be electrically coupled to thelock device 132 such that theaccess controller 134 may instruct or signal (e.g., via a relay) the lock mechanism to permit/deny access through the barrier based on the access control decision. In some embodiments, theaccess controller 134 may be embodied as a “peripheral” controller in the sense that it is not integrated with an electronic lock. That is, in such embodiments, the access controller is not mounted on the door/barrier. Further, in other embodiments, theaccess controller 134 may be embodied as an access control panel. - The
gateway device 136 may serve as an interface between the access control edge device 118 (e.g., thereader device 130 and/or the lock device 132) and theadministrative system 110. For example, in some embodiments, thegateway device 136 may communicate with the accesscontrol edge device 118 over a Wi-Fi Connection and/or a Bluetooth connection, and thegateway device 136 may, in turn, forward the communicated data to the relevantadministrative system 110, management server, and/or access control panel. For example, in some embodiments, thegateway device 136 may communicate with an access control panel over a serial communication link (e.g., using RS-485 standard communication), and/or thegateway device 136 may communicate with theadministrative system 110 over a Wi-Fi connection, an Ethernet connection, or another wired/wireless communication connection (e.g., via the Internet). - It should be appreciated that each of the
credential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, themobile access hub 112, themobile device 114, the accesscontrol edge system 116, the accesscontrol edge devices 118, thereader device 130, thelock device 132, theaccess controller 134, and/or thegateway device 136 may be embodied as a computing device similar to thecomputing device 200 described below in reference toFIG. 2 . For example, in the illustrative embodiment, each of thecredential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, themobile access hub 112, themobile device 114, the accesscontrol edge system 116, the accesscontrol edge devices 118, thereader device 130, thelock device 132, theaccess controller 134, and thegateway device 136 includes aprocessing device 202 and amemory 206 having stored thereon operatinglogic 208 for execution by theprocessing device 202 for operation of the corresponding device. - It should be appreciated that, although the
credential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, and themobile access hub 112 are described herein as one or more computing devices outside of a cloud computing environment for simplicity of the description, in some embodiments, one or more of thecredential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, and/or themobile access hub 112 may be embodied as a cloud-based device or collection of devices. Accordingly, as depicted inFIG. 1 , each of those devices/systems may be referred to herein as one ormore cloud servers 150. For simplicity and without limiting the description, it should be appreciated that the one ormore cloud servers 150 may be referred to herein in the singular (i.e., as the cloud server 150). For further clarity, as indicated above, it should be appreciated that one or more of the servers referenced herein as acloud server 150 may be embodied as a server or other type of computing device situated outside of a cloud computing environment (e.g., a distributed server system) in some embodiments unless expressly indicated to the contrary. - Further, in cloud-based embodiments, one or both of the
credential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, and/or themobile access hub 112 may be embodied as a “serverless” or server-ambiguous computing solution, for example, that executes a plurality of instructions on-demand, contains logic to execute instructions only when prompted by a particular activity/trigger, and does not consume computing resources when not in use. That is, thecredential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, and/or themobile access hub 112 may be embodied as a virtual computing environment residing “on” a computing system (e.g., a distributed network of devices) in which various virtual functions (e.g., Lamba functions, Azure functions, Google cloud functions, and/or other suitable virtual functions) may be executed corresponding with the functions of thecredential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, and/or themobile access hub 112 described herein. For example, when an event occurs (e.g., data is transferred for handling), the virtual computing environment may be communicated with (e.g., via a request to an API of the virtual computing environment), whereby the API may route the request to the correct virtual function (e.g., a particular server-ambiguous computing resource) based on a set of rules. As such, when a request for the transmission of particular data is made (e.g., via an appropriate interface tocredential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, and/or the mobile access hub 112), the appropriate virtual function(s) may be executed to perform the actions before eliminating the instance of the virtual function(s). - Although only one
credential management system 102, onecredential tracking system 104, onecredential ordering system 106, onekey management system 108, oneadministrative system 110, onemobile access hub 112, onemobile device 114, one accesscontrol edge system 116, onereader device 130, onelock device 132, oneaccess controller 134, and onegateway device 136 are shown in the illustrative embodiment ofFIG. 1 , thesystem 100 may include multiplecredential management systems 102,credential tracking systems 104,credential ordering systems 106,key management systems 108,administrative systems 110,mobile access hubs 112,mobile devices 114, accesscontrol edge systems 116,reader devices 130,lock devices 132,access controllers 134, and/orgateway devices 136 in other embodiments. For example, as indicated above, thecredential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, and/or themobile access hub 112 may be embodied as multiple servers in a cloud computing environment in some embodiments. Further, themobile device 114 may communicate with multiple accesscontrol edge systems 116 at various points in time. - It should be appreciated that, in some embodiments, one or more of the devices and/or systems of the
access control system 100 may be omitted or divided into multiple devices/systems. Additionally, in some embodiments, one or more of the devices and/or systems of theaccess control system 100 may form a portion of another device/system such that the functions are performed therein. For example, in some embodiments, thekey management system 108 may form a portion of thecredential management system 102. - Referring now to
FIG. 2 , a simplified block diagram of at least one embodiment of acomputing device 200 is shown. Theillustrative computing device 200 depicts at least one embodiment of a credential management system, a credential tracking system, a credential ordering system, a key management system, an administrative system, a mobile access hub, a mobile device, an access control edge system, an access control edge device, a reader device, a lock device, an access controller, and/or a gateway device that may be utilized in connection with thecredential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, themobile access hub 112, themobile device 114, the accesscontrol edge system 116, the accesscontrol edge devices 118, thereader device 130, thelock device 132, theaccess controller 134, and/or thegateway device 136 illustrated inFIG. 1 . Further, in some embodiments, theillustrative computing device 200 depicts at least one embodiment of theperipheral controller 3402, themanagement server 3404, the cloud server(s) 3406, themobile device 3408, themobile device 3410, thegateway device 3412, thecredential enrollment reader 3414, the RS-485reader 3416, and/or theWiegand reader 3418 illustrated inFIG. 34 and/or theelectronic lock 3502, themanagement server 3504, the cloud server(s) 3506, themobile device 3508, the mobile device 3510, thegateway device 3512, and/or thecredential enrollment reader 3514 illustrated inFIG. 35 . - Depending on the particular embodiment,
computing device 200 may be embodied as a server, desktop computer, laptop computer, tablet computer, notebook, netbook, Ultrabook™, mobile computing device, cellular phone, smartphone, wearable computing device, personal digital assistant, Internet of Things (IoT) device, reader device, access control device, control panel, processing system, router, gateway, and/or any other computing, processing, and/or communication device capable of performing the functions described herein. - The
computing device 200 includes aprocessing device 202 that executes algorithms and/or processes data in accordance withoperating logic 208, an input/output device 204 that enables communication between thecomputing device 200 and one or moreexternal devices 210, andmemory 206 which stores, for example, data received from theexternal device 210 via the input/output device 204. - The input/
output device 204 allows thecomputing device 200 to communicate with theexternal device 210. For example, the input/output device 204 may include a transceiver, a network adapter, a network card, an interface, one or more communication ports (e.g., a USB port, serial port, parallel port, an analog port, a digital port, VGA, DVI, HDMI, FireWire, CAT 5, or any other type of communication port or interface), and/or other communication circuitry. Communication circuitry may be configured to use any one or more communication technologies (e.g., wireless or wired communications) and associated protocols (e.g., Ethernet, Bluetooth®, Bluetooth Low Energy (BLE), Wi-Fi®, WiMAX, etc.) to effect such communication depending on theparticular computing device 200. The input/output device 204 may include hardware, software, and/or firmware suitable for performing the techniques described herein. - The
external device 210 may be any type of device that allows data to be inputted or outputted from thecomputing device 200. For example, in various embodiments, theexternal device 210 may be embodied as an access control device, mobile device, management server, gateway device, and/or access control panel. Further, in some embodiments, theexternal device 210 may be embodied as another computing device, switch, diagnostic tool, controller, printer, display, alarm, peripheral device (e.g., keyboard, mouse, touch screen display, etc.), and/or any other computing, processing, and/or communication device capable of performing the functions described herein. Furthermore, in some embodiments, it should be appreciated that theexternal device 210 may be integrated into thecomputing device 200. - The
processing device 202 may be embodied as any type of processor(s) capable of performing the functions described herein. In particular, theprocessing device 202 may be embodied as one or more single or multi-core processors, microcontrollers, or other processor or processing/controlling circuits. For example, in some embodiments, theprocessing device 202 may include or be embodied as an arithmetic logic unit (ALU), central processing unit (CPU), digital signal processor (DSP), and/or another suitable processor(s). Theprocessing device 202 may be a programmable type, a dedicated hardwired state machine, or a combination thereof.Processing devices 202 with multiple processing units may utilize distributed, pipelined, and/or parallel processing in various embodiments. Further, theprocessing device 202 may be dedicated to performance of just the operations described herein, or may be utilized in one or more additional applications. In the illustrative embodiment, theprocessing device 202 is of a programmable variety that executes algorithms and/or processes data in accordance withoperating logic 208 as defined by programming instructions (such as software or firmware) stored inmemory 206. Additionally or alternatively, the operatinglogic 208 forprocessing device 202 may be at least partially defined by hardwired logic or other hardware. Further, theprocessing device 202 may include one or more components of any type suitable to process the signals received from input/output device 204 or from other components or devices and to provide desired output signals. Such components may include digital circuitry, analog circuitry, or a combination thereof. - The
memory 206 may be of one or more types of non-transitory computer-readable media, such as a solid-state memory, electromagnetic memory, optical memory, or a combination thereof. Furthermore, thememory 206 may be volatile and/or nonvolatile and, in some embodiments, some or all of thememory 206 may be of a portable variety, such as a disk, tape, memory stick, cartridge, and/or other suitable portable memory. In operation, thememory 206 may store various data and software used during operation of thecomputing device 200 such as operating systems, applications, programs, libraries, and drivers. It should be appreciated that thememory 206 may store data that is manipulated by the operatinglogic 208 ofprocessing device 202, such as, for example, data representative of signals received from and/or sent to the input/output device 204 in addition to or in lieu of storing programming instructions definingoperating logic 208. As shown inFIG. 2 , thememory 206 may be included with theprocessing device 202 and/or coupled to theprocessing device 202 depending on the particular embodiment. For example, in some embodiments, theprocessing device 202, thememory 206, and/or other components of thecomputing device 200 may form a portion of a system-on-a-chip (SoC) and be incorporated on a single integrated circuit chip. - In some embodiments, various components of the computing device 200 (e.g., the
processing device 202 and the memory 206) may be communicatively coupled via an input/output subsystem, which may be embodied as circuitry and/or components to facilitate input/output operations with theprocessing device 202, thememory 206, and other components of thecomputing device 200. For example, the input/output subsystem may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.) and/or other components and subsystems to facilitate the input/output operations. - The
computing device 200 may include other or additional components, such as those commonly found in a typical computing device (e.g., various input/output devices and/or other components), in other embodiments. It should be further appreciated that one or more of the components of thecomputing device 200 described herein may be distributed across multiple computing devices. In other words, the techniques described herein may be employed by a computing system that includes one or more computing devices. Additionally, although only asingle processing device 202, I/O device 204, andmemory 206 are illustratively shown inFIG. 2 , it should be appreciated that aparticular computing device 200 may includemultiple processing devices 202, I/O devices 204, and/ormemories 206 in other embodiments. Further, in some embodiments, more than oneexternal device 210 may be in communication with thecomputing device 200. - As used herein, “Bluetooth” includes traditional Bluetooth Basic Rate/Enhanced Rate (BR/EDR) technology and Bluetooth Low Energy (BLE) technology and refers to one or more components, architectures, communication protocols, and/or other systems, structures, or processes defined by and/or compliant with one or more Bluetooth specifications, addendums, and/or supplements overseen by the Bluetooth Special Interest Group (SIG) including, for example, active, legacy, withdrawn, deprecated, and/or subsequently introduced Bluetooth Core Specifications (CSs) (Bluetooth CS Version 1.0B, Bluetooth CS Version 1.1, Bluetooth CS Version 1.2, Bluetooth CS Version 2.0+EDR, Bluetooth CS Version 2.1+EDR, Bluetooth CS Version 3.0+HS, Bluetooth CS Version 4.0, Bluetooth CS Version 4.1, Bluetooth CS Version 4.2, Bluetooth CS Version 5.0); active, legacy, withdrawn, deprecated, and/or subsequently introduced Bluetooth Core Specification Addendums (CSAs) (Bluetooth CSA Version 1, Bluetooth CSA Version 2, Bluetooth CSA Version 3, Bluetooth CSA Version 4, Bluetooth CSA Version 5, Bluetooth CSA Version 6); Bluetooth Core Specification Supplements (CSSs) (Bluetooth CSS Version 1, Bluetooth CSS Version 2, Bluetooth CSS Version 3, Bluetooth CSS Version 4, Bluetooth CSS Version 5, Bluetooth CSS Version 6, Bluetooth CSS Version 7); active, legacy, withdrawn, deprecated, and/or subsequently introduced Bluetooth Mesh Networking Specifications (Bluetooth Mesh Profile Specification 1.0, Bluetooth Mesh Model Specification 1.0, Bluetooth Mesh Device Properties 1.0); active, legacy, withdrawn, deprecated, and/or subsequently introduced Bluetooth Traditional Profile Specifications (3DSP, A2DP, AVRCP, BIP, BPP, CTN, DI, DUN, FTP, GAVDP, GNSS, GOEP, GPP, HCRP, HDP, HFP, HID, HSP, MAP, MPS, OPP, PAN, PBAP, SAP, SPP, SYNCH, VDP); active, legacy, withdrawn, deprecated, and/or subsequently introduced Bluetooth Protocol Specifications (AVCTP, AVDTP, BNEP, IrDA, MCAP, RFCOMM, 3WIRE, SD, TCP, UART, USB, WAPB); active, legacy, withdrawn, deprecated, and/or subsequently introduced Bluetooth Generic Attribute Profile (GATT) services, characteristics, declarations, descriptors, and profiles (ANP, ANS, AIOP, AIOS, BAS, BCS, BLP, BLS, BMS, CGMP, CGMS, CPP, CPS, CSCP, CSCS, CTS, DIS, ESP, ESS, FMP, FTMP, FTMS, GSS, GLP, GLS, HIDS, HOGP, HPS, HRP, HRS, HTP, HTS, IAS, IDP, IDS, IPS, IPSP, LLS, LNP, LNS, NDCS, OTP, OTS, PASP, PASS, PXP, PLXP, PLXS, RCP, RCS, RSCP, RSCS, TRUS, ScPP, ScPS, TDS, TIP, TPS, UDS, WSP, WSS); and/or other Bluetooth specifications, addendums, and/or supplements.
- Referring now to
FIGS. 3-8 , simplified block diagrams illustrating various communication capabilities and use cases of theaccess control system 100 are shown. More specifically,FIGS. 3-8 illustrate communications between subsets of the various devices/systems of the access control device. That is, communication capabilities and use cases ofsubsystems access control system 100 are shown. For example, referring now specifically toFIG. 3 , thesubsystem 300 includes amobile device 114, areader device 130, anaccess controller 134, and alock device 132. In the illustrative embodiment ofFIG. 3 , thereader device 130 is embodied as a BLE-capable wall mount reader device that receives and processes the BLE access credential from themobile device 114 and transmits the BLE access credential or a portion thereof to the access controller 134 (e.g., an access control panel) to perform the access control decision. Thesubsystem 300 may be considered to have employed a “decision at host” access control scheme, the “host” being the access control panel. As shown, in some embodiments, thereader device 130 may communicate with theaccess controller 134 via Wiegand communication lines, which are one-way communication with no feedback, or using the Open Supervised Device Protocol (OSDP), which is generally secure and allows feedback. Further, based on the access control decision, theaccess controller 134 may transmit a command or signal to thelock device 132, for example, to unlock the lock mechanism. - Referring now to
FIG. 4 , thesubsystem 400 includes amobile device 114 and alock device 132. In the illustrative embodiment ofFIG. 4 , thelock device 132 is embodied as an electronic lock with BLE communication circuitry such that thelock device 132 receives and processes the BLE access credential from themobile device 114. Further, theillustrative lock device 132 is an offline battery-powered electronic lock that includes an internal access control database stored in an internal memory of thelock device 132 such that thelock device 132 can locally make an access control decision based on the BLE access credential. Thesubsystem 400 may be considered to have employed an offline, “decision at door” access control scheme. It should be appreciated that alock device 132 is considered to be “online” if thelock device 132 has a real-time connection to the host (e.g., theadministrative system 110″, whereas thelock device 132 is considered to “offline” if it does not. As such, offline devices may, for example, establish a communication connection with the host periodically or in response to an appropriate condition in some embodiments. - Referring now to
FIG. 5 , thesubsystem 500 includes amobile device 114, alock device 132, agateway device 136, and anaccess controller 134. In the illustrative embodiment ofFIG. 5 , thelock device 132 is embodied as an electronic lock with BLE communication circuitry such that thelock device 132 receives and processes the BLE access credential from themobile device 114. Further, theillustrative lock device 132 is an online electronic lock that transmits the received BLE credential, or a portion thereof, in real-time to thegateway device 136 via BLE communication, which in turn transmits the BLE credential, or a portion thereof, to the access controller 134 (e.g., an access control panel) to perform an access control decision. - The
subsystem 500 may be considered to have employed an online, “decision at host” access control scheme. In some embodiments, thegateway device 136 has a stable communication connection (e.g., an RSI-485 serial communication connection) to theaccess controller 134 for transmittal of the BLE credential and/or other relevant data. - It should be appreciated that, in the
illustrative subsystem 500, thelock device 132 has a persistent connection to thegateway device 136 and the ability to simultaneously transmit BLE advertisements to BLE devices in the vicinity in order to establish a BLE connection with themobile device 114 to receive the BLE credential. To do so, in the illustrative embodiment, theBLE chipset 140 of thelock device 132 leverages and/or is otherwise compliant with Bluetooth CS Version 4.2 or newer (i.e., subsequently introduced). In some embodiments, thelock device 132 is capable of establishing at least five simultaneously BLE connections. It should be appreciated that the BLE connection is “persistent” in the sense that the BLE connection disconnects fewer than ten times per day. In other embodiments, the BLE connection may not be so “persistent” but may nonetheless not disconnect periodically by design. - Referring now to
FIG. 6 , thesubsystem 600 includes amobile device 114, alock device 132, agateway device 136, and a host system (e.g., an administrative system 110). In the illustrative embodiment ofFIG. 6 , thelock device 132 is embodied as an electronic lock with BLE communication circuitry such that thelock device 132 receives and processes the BLE access credential from themobile device 114. Further, theillustrative lock device 132 is an online electronic lock that includes an internal access control database stored in an internal memory of thelock device 132 such that thelock device 132 can locally make an access control decision based on the BLE access credential. Thesubsystem 600 may be considered to have employed an online, “decision at door” access control scheme. It should be appreciated that, in theillustrative subsystem 600, thelock device 132 has a persistent connection to thegateway device 136 such that thelock device 132 can receive real-time updates from the host server (e.g., the administrative system 110) while being connected to one or moremobile devices 114. As in thesubsystem 500 ofFIG. 5 , in thesubsystem 600 ofFIG. 6 , theBLE chipset 140 of thelock device 132 leverages and/or is otherwise compliant with Bluetooth CS Version 4.2 or newer (i.e., subsequently introduced). Further, in some embodiments, thegateway device 136 communicates with the host server (e.g., the administrative system 110) via an Ethernet connection (e.g., via the Internet). - Referring now to
FIG. 7 , thesubsystem 700 includes twomobile devices 114, areader device 130, anaccess controller 134, and alock device 132. In the illustrative embodiment ofFIG. 7 , thereader device 130 is embodied as a BLE-capable wall mount reader device that receives and processes BLE access credentials from themobile devices 114 and transmits each of the BLE access credentials or a portion thereof to the access controller 134 (e.g., an access control panel) to perform the access control decision. Thesubsystem 300 may be considered to have employed a “decision at host” access control scheme, the “host” being the access control panel. As shown, in some embodiments, thereader device 130 may communicate with theaccess controller 134 via Wiegand communication lines or using OSDP. Further, based on the access control decision, theaccess controller 134 may transmit a command or signal to thelock device 132, for example, to unlock the lock mechanism. As such, it should be appreciated that thesubsystem 700 is similar to thesubsystem 300 ofFIG. 3 . However, thereader device 130 ofsubsystem 700 is configured to establishing and simultaneously maintain multiple BLE communication connections with other devices (e.g., in conjunction with heavy use doors). In particular, theillustrative reader device 130 ofFIG. 7 is configured to establish a BLE communication connection with a firstmobile device 114 and maintain that connection while simultaneously establishing and then maintaining a BLE communication connection with a secondmobile device 114. It should be appreciated that permitting multiplemobile devices 114 to connect to thereader device 130 simultaneously, the risk and effect of various malicious attacks such as a denial of service attack is significantly reduced. - Referring now to
FIG. 8 , thesubsystem 800 includes amobile device 114, alock device 132, and anadministrative device 802. In some embodiments, theadministrative device 802 may be embodied as a device similar to themobile device 114 and/or another computing device similar to thecomputing device 200 described in reference toFIG. 2 . Further, theadministrative device 802 may form a portion of theadministrative system 110. In the illustrative embodiment ofFIG. 8 , thelock device 132 is embodied as an electronic lock with BLE communication circuitry such that thelock device 132 receives and processes the BLE access credential from themobile device 114. Further, in some embodiments, theillustrative lock device 132 may be an offline battery-powered electronic lock that includes an internal access control database stored in an internal memory of thelock device 132 such that thelock device 132 can locally make an access control decision based on the BLE access credential. Additionally, thelock device 132 may be configured to communicate with theadministrative device 802 via the BLE communication circuitry such that theadministrative device 802 may perform various administrative functions, maintenance functions, updates, and/or other suitable functions with respect to thelock device 132. Similar to thereader device 130 ofFIG. 7 , thelock device 132 ofFIG. 8 is configured to simultaneously establish and maintain BLE communication connections with the mobile device 114 (e.g., a user mobile device) and theadministrative device 802 such that an administrator application can be connected to thelock device 132, and thelock device 132 can simultaneously advertise and connect withmobile devices 114 via BLE. - Referring now to
FIG. 9 , an example of a data structure of awireless access credential 900 is shown. In particular, the illustrative wireless access credential 900 (e.g., a BLE access credential) ofFIG. 9 is represented in Concise Binary Object Representation (CBOR) format or, more specifically, according to the RFC7049 CBOR standard, with hexadecimal representations. In some embodiments, each of the payloads and/or encrypted payloads described below may be transmitted in this format. However, it should be appreciated that the example data structure ofFIG. 9 is shown by way of example, and the techniques described herein may be employed for different data representations and/or data structures. - As shown, the illustrative
wireless access credential 900 ofFIG. 9 includes various data fields. In particular, thewireless access credential 900 includesdata data 902 is a tag that indicates the type of the data to follow. In particular, the data 902 (via “05”) indicates that the data is a credential value with a credential activation time and a credential expiration time. Other tags my include, for example, a nonce, public key(s), signature(s), key exchange data, a unique identifier (e.g., UUID), a PIN request, a PIN reply, key provisioning data (e.g., rolling keys), configuration data, firmware download, status reporting, error handling, reporting data, command information, and/or other suitable information. Thedata 904 indicates the type/length of the data. Thedata 906 indicates the credential bit format and, therefore, indicates (via “1A”) that the credential is in a 26-bit format. Further, thedata 906 indicates the credential value, thedata 908 indicates an activation time of the credential, and thedata 910 indicates an expiration time of the credential. It should be appreciated that the activation and expiration times may be in any suitable format (e.g., date-time, etc.). It should be further appreciated that the number and types of the data fields may vary depending on the particular data and/or the particular embodiment. - Referring now to
FIG. 10 , in use, theaccess control system 100 may execute amethod 1000 for using a wireless access credential. It should be appreciated that the particular blocks of themethod 1000 are illustrated by way of example, and such blocks may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. Theillustrative method 1000 begins withblock 1002 ofFIG. 10 in which theaccess control system 100 processes a wireless access credential order. More specifically, a customer may place an order for additional credentials via thecredential ordering system 106 and/or thecredential management system 102. Further, in the illustrative embodiment, thecredential management system 102 populates credential credits (commensurate with the number of credentials purchased) in thecredential management system 102 indicative of a number of credentials available to the customer for issuance to users. Although often described throughout the description as BLE credentials or Bluetooth credentials, it should be appreciated that the techniques described herein may also be employed with respect to other types of wireless access credentials. - In
block 1004, theaccess control system 100 receives a request for issuance of a credential and issues a credential to a user or themobile device 114 of the user. In doing so, inblock 1006, theaccess control system 100 may ensure that the credential value of the credential being issued is unique and, inblock 1008, theaccess control system 100 may store credential data to an access control database (e.g., stored locally at theedge device 118 and/or remotely at theadministrative system 110 or another suitable location). More specifically, in some embodiments, a site/facility administrator utilizes theadministrative system 110 to access the credential management system 102 (e.g., via theweb application 120 and/or administrative API 122) to request a new wireless access credential to be assigned/issued and transmitted to amobile device 114 of an end user. Further, thecredential management system 102 may coordinate with thecredential tracking system 104 to ensure that the credential value of the issued credential is not duplicative of another issued credential. As described above, in some embodiments, theadministrative system 110 may manually request the credential issuance via theweb application 120, whereas in other embodiments, theadministrative system 110 may be integrated with thecredential management system 102 via theadministrative API 122 such that the request for and issuance of credentials may be automated. - In the illustrative embodiment, it should be appreciated that assigning/issuing the credential to a user further involves transmitting the issued credential and/or other relevant credential data to the
administrative system 110, which is, in turn, stored to the relevant access control database(s). It should be appreciated that the location of the access control database(s) may vary depending, for example, on the particular site's access control and network topologies. As such, in various embodiments, the access control database(s) may be located on the accesscontrol edge device 118, access controller 134 (e.g., access control panel), host device (e.g., the administrative system 110), a cloud-based system, and/or another suitable location. It should be appreciated that the access control database includes the credential, the assigned user (e.g., identified by mobile phone number), and/or other relevant credential data. - In
block 1010, theaccess control system 100 transmits the issued credential to the appropriatemobile device 114. The appropriatemobile device 114 may be identified, for example, based on the various communication protocols described herein. In some embodiments, thecredential management system 102 transmits the credential to themobile device 114 via themobile access hub 112. In particular, thecredential management system 102 may leverage thecredential API 124 to interface with and/or “call” themobile access hub 112 requesting a message to be transmitted to the user's mobile device 114 (e.g., a text/SMS message). For example, themobile access hub 112 may generate and transmit a deep link via SMS to themobile device 114 at the mobile device number entered when the credential was issued to the user. In other embodiments, themobile access hub 112 may interface with Twilio and/or another suitable messaging service for generating and transmitting the appropriate messages to themobile device 114. However, in other embodiments, the messages may be transmitted to themobile device 114 via email and/or another suitable communication mechanism. - After the
mobile device 114 has received the issued credential, themobile device 114 may transmit the credential to the accesscontrol edge device 118 to make an access control decision with respect to themobile device 114 and, therefore, with respect to the user. As such, inblock 1012, themobile device 114 transmits the credential to theedge device 118. In some embodiments, it should be appreciated that the credential may be transmitted based on the user's express or implied intent to convey the credential to theedge device 118. For example, in some embodiments, the credential is transmitted based on a user's selection on a graphical user interface of an option to transmit the credential, whereas in other embodiments, the credential may be transmitted based on sensor data, contextual information, and/or other relevant information. Accordingly, inblock 1014, themobile device 114 may determine the user intent based on various factors/options as described herein. Inblock 1016, theedge device 118 and/or other device(s) in theedge system 116 makes an access control decision based on the credential and the access control database. For example, as described above, theedge device 118 itself or another device may perform the access control decision based, for example, on whether a “decision at door” or “decision at host” access control scheme is employed, among other factors. - Although the blocks 1002-1016 are described in a relatively serial manner, it should be appreciated that various blocks of the
method 1000 may be performed in parallel in some embodiments. It should be further appreciated that one or more of the features described in reference to the flow diagrams ofFIGS. 11-29 may be incorporated into themethod 1000 ofFIG. 10 in some embodiments. - Referring now to
FIGS. 30-31 , in some embodiments, themobile device 114 may execute a mobile application that has agraphical user interface 3000 that allows the user to select a particular door/lock to indicate an intent to access that door, which causes themobile device 114 to transmit the appropriate credential to thecorresponding edge device 118. As shown inFIGS. 30-31 , thegraphical user interface 3000 may include a cards tab 3002, a doors tab 3004, and a settings tab 3006. In some embodiments, when selected, the cards tab 3002 provides the user with options to select various credential stored to themobile device 114. Depending on the particular embodiment, selection of a particular card may transmit the corresponding credential to the associatededge device 118, open properties or settings associated with the corresponding credential, and/or perform other suitable functions. As shown in the illustrative embodiment ofFIGS. 30-31 , when the doors tab 3004 is selected, thegraphical user interface 3000 further displays a recently used tab 3008 and an all doors tab 3010. As shown inFIG. 30 , when the recently used tab 3008 is selected, the illustrativegraphical user interface 3000 identifies each of the doors that have been recently accessed. In other words, in some embodiments, thegraphical user interface 300 identifies each door associated with anedge device 118 that has performed an access control decision or, alternatively, an access control decision associated with an authenticated credential. In some embodiments, door may be considered to have been “recently used” if the door is one of a certain number of most recently used doors and/or used within a certain period of time. Such number and/or time may vary depending on the particular embodiment. In some embodiments, thegraphical user interface 3000 may identify the state of each door including, for example, whether the door is unlocked (as depicted by indicia 3012) or locked (as depicted by indicia 3014). As shown inFIG. 31 , when the all doors tab 3010 is selected, the illustrativegraphical user interface 3000 identifies each of the doors within range of themobile device 114 than can accept a wireless access credential (e.g., a BLE access credential). In some embodiments, in order to identify the devices that support a BLE access credential, a new BLE generic attribute (GATT) service may be defined such that the mobile application of themobile device 114 can identify via the advertising data of the nearby BLE devices whether each nearby device supports the BLE access credential. Accordingly, the list of doors that thegraphical user interface 3000 displays may be significantly reduced. However, in other embodiments, thegraphical user interface 3000 may display every door within range of themobile device 114. - It should be appreciated that the
mobile device 114 may employ one or more other user intent options in other embodiments. Further, the user intent options may vary by the amount of user interaction required to convey the user intent and, in some embodiments, may be configurable by the site administrator (e.g., via the administrative system 110). In some embodiments, a graphical user interface (e.g., similar to the graphical user interface 3000) may provide the user with one or more user intent options to select for each of theedge devices 118 accessible to the user. It should be appreciated that such user intent options may be permitted at the discretion of the site administrator in some embodiments. For example, a site administrator may permit more relaxed user intent options for an interior door housing nothing secure, whereas the site administrator may permit only more strict user intent options (e.g., express selections of the door) for an exterior door or an interior door securing critical infrastructure. - In some embodiments, the user intent may be conveyed without user interaction. In particular, the
access control system 100 may engage in triangulation (e.g., between BLE edge devices 118) and/or leverage GPS circuitry to determine the location of themobile device 114. In such embodiments, themobile device 114 may transmit the credential (or alternatively, theedge device 118 may only process the received credential) when themobile device 114 is moving toward theedge device 118 and on the proper side of the edge device 118 (e.g., corresponding with an exterior side of the door). In other embodiments, themobile device 114 may transmit the credential to thenearest edge device 118 based on the location data. In another embodiment, the user may convey an intent to access by walking up to the door (and therefore the corresponding edge device 118) and stopping instead of walking by. It should be appreciated that themobile device 114 and/or theedge device 118 may leverage received signal strength (e.g., signal strength indication (RSSI) values) or time of flight data to determine the distance of themobile device 114 relative to theedge device 118 in some embodiments. Further, in some embodiments, themobile device 114 may automatically transmit the credential to theedge device 118 when themobile device 114 is within a predetermined distance of theedge device 118 or other reference device/component (e.g., the door) such that thelock device 132 may be automatically unlocked. - In other embodiments, the user intent may be conveyed with user interaction but without removing the
mobile device 114 from safekeeping (e.g., without removing themobile device 114 from the user's pocket, handbag, briefcase, etc.). For example, in some embodiments, the user may convey the intent by tapping themobile device 114. That is, when themobile device 114 is within a close proximity to theedge device 118, a tap on themobile device 114 informs the mobile application to transmit the credential to theedge device 118. It should be appreciated that themobile device 114 may include and leverage an accelerometer and/or other inertial sensor(s) to perform such functions. In other embodiments, themobile device 114 may be embodied as, or otherwise include, a wearable device, and an indication appears on a display of the wearable device when the user is within range of anedge device 118. A user's tap of the wearable device may be indicative of an intent to access the passageway secured by theedge device 118. In some embodiments, themobile device 114 may sense the tap via an inertial sensor, capacitive sensor, pressure sensor, and/or other suitable sensor. For example, in various embodiments, the sensors leveraged by themobile device 114 to determine a user intent may include environmental sensors (e.g., temperature sensors, air pressure sensors, humidity sensors, light sensors, etc.), inertial sensors (accelerometers, gyroscopes, magnetometers, etc.), proximity sensors, optical sensors, electromagnetic sensors, audio sensors (e.g., microphones), motion sensors, cameras, piezoelectric sensors, pressure sensors, and/or other types of sensors. - In yet other embodiments, the user intent may involve both user interaction and removal of the
mobile device 114 from safekeeping (e.g., removing the movingdevice 114 from the user's pocket, handbag, briefcase, etc.). For example, in some embodiments, the near field communication (NFC) circuitry of themobile device 114 may be used as an intent option to transmit a BLE credential (e.g., by tapping themobile device 114 to the reader device 130). Further, in some embodiments, themobile device 114 may utilize a voice recognition system (e.g., via the mobile application, a system application, and/or another application) to determine the user's intent to transmit the credential to anedge device 118. That is, the user may give an audible command to themobile device 114 to do so. - Referring now to
FIGS. 11-29 , various embodiments of methods for securely transmitting an access credential over a wireless communication connection or, in some embodiments, a BLE communication connection more specifically are shown. It should be appreciated that the illustrative methods ofFIGS. 11-29 leverage different security and encryption algorithms to secure the data across the wireless/BLE communication connection and/or while stored on specific devices in theaccess control system 100. In some embodiments, it should be appreciated that if a particular verification, validation, authorization, and/or authentication fails, one or more devices of theaccess control system 100 may perform error handling procedures. For example, in some embodiments, the communication protocol may terminate. It should be appreciated that, in the illustrative methods ofFIGS. 11-29 , theedge device 118 need not have ever been pre-commissioned to communicate with themobile device 114 and/or the mobile application thereof. That is, in some embodiments, theedge device 118 has no pre-shared information about the specificmobile device 114 prior to commencing communication with themobile device 114. - Referring now to
FIG. 11 , in use, theaccess control system 100 may execute amethod 1100 for storing a wireless access credential to themobile device 114. It should be appreciated that the particular flows of themethod 1100 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. Additionally, it should be appreciated that, in the illustrative embodiment, themethod 1100 may be executed in conjunction with and prior to themethod 1200 ofFIGS. 12-13 . - As shown, the
illustrative method 1100 involves one ormore cloud servers 150 and a mobile device 114 (e.g., executing a mobile application as described herein). As indicated above, the cloud server(s) 150 may be referred to herein in the singular for simplicity. Further, theillustrative method 1100 assumes that a cryptographic key exchange has occurred such that thecloud server 150 and an edge device 118 (see, for example,FIGS. 12-13 ) share two symmetric cryptographic keys, K and B. It should appreciated that thecloud server 150 and theedge device 118 may employ any suitable key exchange algorithm to do so. Theillustrative method 1100 further assumes that themobile device 114 has stored thereon another symmetric cryptographic key, A, which may be generated, for example, by themobile device 114 in a trusted execution environment (TEE) or secure enclave in some embodiments. Additionally, the symmetric cryptographic keys may vary by type and/or length depending on the particular embodiment. For example, in the illustrative embodiment, the symmetric cryptographic keys, K, B, and A, are embodied as 256-bit Advanced Encryption Standard (AES) keys. In other embodiments, however, the symmetric cryptographic keys may be associated with another cryptographic algorithm such as, for example, Data Encryption Standard (DES), Triple DES, Blowfish, Twofish, Serpent, and/or another symmetric cryptographic algorithm. Similarly, the keys may be 128-bit keys, 512-bit keys, or another size in other embodiments (e.g., depending on the cryptographic algorithm). In some embodiments, the cryptographic keys are generated by thecloud server 150 and transmitted to theedge device 118. - The
illustrative method 1100 begins withflow 1102 ofFIG. 11 in which thecloud server 150 and themobile device 114 coordinate to assign a wireless access credential to a user (and therefore themobile device 114 of that user) and verify the mobile device 114 (e.g., by confirming that the mobile number corresponds with the mobile device 114). It should be appreciated that, in some embodiments, theaccess control system 100 may execute themethod 2200 ofFIGS. 22-23 to do so. Further, in some embodiments, themobile device 114 may establish a Transport Layer Security (TLS) connection with thecloud server 150 and/or other devices with which themobile device 114 communicates. - In
flow 1104, the mobile device 114 (e.g., using the mobile application) builds a credential request including a device identifier (e.g., UUID) of themobile device 114 and the symmetric cryptographic key, A, retrieved from a memory of themobile device 114. Further, in some embodiments, the credential request may identify the payload as a credential request (e.g., via a corresponding flag, CRED_REQ). As such, in some embodiments, the credential request may be represented as CRED_REQ∥device_ID ∥A. It should be appreciated that the device identified (e.g., a UUID) may be tied to themobile device 114 and may allow theedge device 118 to generate the information necessary to identify that the credential is correct any coming from the correctmobile device 114 as described below. Inflow 1106, themobile device 114 transmits the credential request to the cloud server 150 (e.g., via a TLS connection). - In
flow 1108, thecloud server 150 generates a shared cryptographic key, M, based on the symmetric cryptographic key, B, retrieved from a memory of thecloud server 150 and the unique identifier (e.g., UUID) received from themobile device 114 with the credential request. As described below in reference toFIGS. 12-13 , it should be appreciated that the cryptographic key, M, is shared in the sense that theedge device 118 is able to independently derive the same cryptographic key based on the same data (i.e., the key, B, and the unique identifier). It should be appreciated that the shared cryptographic key, M, may be generated based on a key derivation function (KDF). More specifically, in the illustrative embodiment, the shared cryptographic key, M, is generated based on a HKDF, a key derivation function based on a hash-based message authentication code (HMAC). However, in other embodiments, the shared cryptographic key, M, may be otherwise generated. - In
flow 1110, thecloud server 150 builds a credential blob including the credential to be transmitted to the mobile device 114 (i.e., the credential assigned to themobile device 114 and the user) and the shared cryptographic key, M Further, in some embodiments, the credential blob may further include a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the credential blob may be represented as nonce∥credential∥A . Inflow 1112, thecloud server 150 encrypts the credential blob with the symmetric cryptographic key, K, and, inflow 1114, thecloud server 150 generates a keyed hash of the encrypted credential blob using the same symmetric cryptographic key, K. In particular, in the illustrative embodiment, thecloud server 150 generates an HMAC of the encrypted credential blob based on the symmetric cryptographic key, K (e.g., an HMAC-SHA256 keyed hash). However, it should be appreciated that another type of keyed hash may be generated in other embodiments. - In
flow 1116, thecloud server 150 transmits the encrypted credential blob (EK (nonce∥credential∥A)), the keyed hash of the encrypted credential blob (HMACK), and the shared cryptographic key (M) to themobile device 114. In particular, in some embodiments, a payload including those data may be represented as EK (nonce∥credential∥A)∥HMACK )∥M . Inflow 1118, themobile device 114 stores each of the encrypted credential blob (EK (nonce∥credential∥A)), the keyed hash of the encrypted credential blob (HMACK), and the shared cryptographic key (M) to a memory of themobile device 114. As such, it should be appreciated that the mobile device 114 (and the mobile application) now has access to the shared cryptographic key (M), for example, to perform one or more cryptographic functions described below in reference toFIGS. 12-13 . Additionally, in the illustrative embodiment, themobile device 114 now has a credential stored thereon that is tied to themobile device 114, but themobile device 114 is unable to read the credential data due to the encryption. It should be appreciated that the memory of themobile device 114 to which such data is stored is a secure memory in some embodiments. - Although the flows 1102-1118 are described in a relatively serial manner, it should be appreciated that various flows of the
method 1100 may be performed in parallel in some embodiments. - Referring now to
FIGS. 12-13 , in use, theaccess control system 100 may execute amethod 1200 for using a wireless access credential (e.g., a wireless access credential stored to themobile device 114 according to themethod 1100 ofFIG. 11 ). It should be appreciated that the particular flows of themethod 1100 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. In some embodiments, themethod 1200 ofFIGS. 12-13 may be executed in conjunction with and subsequent to themethod 1100 ofFIG. 11 . - As shown, the
illustrative method 1200 involves the mobile device 114 (e.g., themobile device 114 described in reference toFIG. 11 ) and anedge device 118. Also as described above in reference toFIG. 11 , theillustrative method 1200 assumes that a cryptographic key exchange has occurred such that the cloud server 150 (see, for example,FIG. 11 ) and theedge device 118 share two symmetric cryptographic keys, K and B. Also, themobile device 114 has stored thereon another symmetric cryptographic key, A. Further, in embodiments involving themethod 1100 ofFIG. 11 in conjunction with themethod 1200 ofFIGS. 12-13 , themobile device 114 also has stored thereon the encrypted credential blob (EK (nonce∥credential∥A)), the keyed hash of the encrypted credential blob (HMACK), and the shared cryptographic key (M) after the execution of themethod 1100 ofFIG. 11 . - The
illustrative method 1200 begins withflow 1202 ofFIG. 12 in which themobile device 114 and theedge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4.2 or newer connection). In doing so, themobile device 114 and/or theedge device 118 may execute various Bluetooth-defined functions including, for example, getDevice ( ), tryConnecting ( ) onSuccess, tryDiscovering ( ), and/or onServicesDiscovered ( ) functions. Inflow 1204, themobile deice 114 transmits the device identifier (e.g., UUID) of themobile device 114 to the edge device 118 (e.g., in the clear). - In
flow 1206, theedge device 118 generates the shared cryptographic key, M, based on the symmetric cryptographic key, B, and the device identifier (e.g., UUID). As described above in reference toFIG. 11 , in the illustrative embodiment, the cryptographic key, M, is shared in the sense that theedge device 118 is able to independently derive the same cryptographic key (e.g., based on the key, B, and the unique identifier) used by thecloud device 150 to previously generate the shared cryptographic key, M. It should be appreciated that theedge device 118 may use the same key derivation function and/or other key-generating function used by thecloud device 150 to previously generate the shared cryptographic key, M. As such, in the illustrative embodiment, the shared cryptographic key, M, is generated based on a HKDF. - In
flow 1208, theedge device 118 encrypts credential request data with the shared cryptographic key, M In some embodiments, it should be appreciated that the credential request data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the encrypted credential request data may be represented as EM (requestData) . Inflow 1210, theedge device 118 transmits the encrypted credential request data, EM (requestData) , to themobile device 114 via the established Bluetooth communication connection. - In
flow 1212, themobile device 114 decrypts the encrypted credential request data using the shared cryptographic key, M, retrieved from a memory of themobile device 114 and, inflow 1214, the mobile device 114 (e.g., using the mobile application) builds a credential message including the credential request data received from theedge device 118, the encrypted credential blob retrieved from the memory of themobile device 114, and the keyed hash retrieved from the memory of themobile device 114. As such, in some embodiments, the credential message may be represented as requestData∥EK (nonce∥credential∥A)∥HMACK. Inflow 1216, themobile device 114 encrypts the credential message with the shared cryptographic key, M, and inflow 1218, themobile device 114 generates a keyed hash of the encrypted credential message using the symmetric cryptographic key, A, retrieved from the memory of themobile device 114. In particular, in the illustrative embodiment,mobile device 114 generates an HMAC of the encrypted credential message based on the symmetric cryptographic key, A (e.g., an HMAC-SHA256 keyed hash). However, it should be appreciated that another type of keyed hash may be generated in other embodiments. - In
flow 1220, themobile device 114 transmits the encrypted credential message (EK (requestData∥EK (nonce∥credential∥A)∥HMACK)) and the keyed hash (HMACK) of the encrypted credential message to theedge device 118. Inflow 1222, theedge device 118 decrypts the encrypted credential message using the shared cryptographic key, K, retrieved from the memory of theedge device 118. - In
flow 1224 ofFIG. 13 , theedge device 118 verifies the credential request data. For example, in embodiments in which the credential request data is a nonce, theedge device 118 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 1208-1210 ofFIG. 12 ). In other embodiments, it should be appreciated that theedge device 118 may otherwise verify and/or validate the decrypted credential request data. Inflow 1226, theedge device 118 verifies the keyed hash (HMACK) of the encrypted credential blob (e.g., extracted from the decrypted credential message) using the symmetric cryptographic key, K, retrieved from the memory of theedge device 118. In some embodiments, to do so, theedge device 118 generates a reference keyed hash (e.g., a reference HMAC) of the encrypted credential blob extracted from the decrypted credential message using the symmetric cryptographic key, K, and compares the reference keyed hash to the keyed hash (HMACK) of the encrypted credential blob extracted from the decrypted credential message to confirm the keyed hashes match. - In
flow 1228, theedge device 118 decrypts the encrypted credential blob using the symmetric cryptographic key, K, retrieved from the memory of theedge device 118 and, inblock 1230, theedge device 118 extracts the credential and the symmetric cryptographic key, A, from the decrypted credential blob. It should be appreciated that, in the illustrative embodiment, theedge device 118 and thecloud server 150 are capable of encrypting/decrypting the credential blob including the credential, whereas themobile device 114 is not. Instead, in such embodiments, themobile device 114 acts as a conduit for the secure transfer of the credential between thecloud server 150 and theedge device 118. - In
flow 1232, theedge device 118 verifies the keyed hash (HMACA) of the encrypted credential message using the symmetric cryptographic key, A, extracted from the credential blob. In some embodiments, to do so, theedge device 118 generates a reference keyed hash (e.g., a reference HMAC) of the encrypted credential message received from themobile device 114 using the symmetric cryptographic key, K, and compares the reference keyed hash to the keyed hash (HMACA) of the encrypted credential received from themobile device 114 to confirm the keyed hashes match. - In
flow 1234, theedge device 118 processes the credential extracted from the credential blob. For example, in some embodiments, theedge device 118 and/or other device(s) in theedge system 116 may make an access control decision based on the extracted credential and an access control database. As described above, theedge device 118 itself or another device (e.g., theadministrative system 110, theaccess controller 134, etc.) may perform the access control decision based, for example, on whether a “decision at door” or “decision at host” access control scheme is employed, among other factors. Further, in some embodiments, in response to successful authentication of the credential, thelock device 132 may unlock a lock mechanism as described above. In some embodiments, it should be appreciated that further authentication of the user and/or themobile device 114 may be required in advance of, or in conjunction with, the processing of the credential. For example, in some embodiments, themethod 1400 ofFIG. 14 may be executed to process a PIN of the user. In other embodiments, the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, and/or additional information. It should be appreciated that, in some embodiments, the credential value and/or other portion of the credential may include an indicator that further authentication is required. - Although the flows 1202-1236 are described in a relatively serial manner, it should be appreciated that various flows of the
method 1200 may be performed in parallel in some embodiments. - Referring now to
FIG. 14 , in use, theaccess control system 100 may execute amethod 1400 for further authenticating a user of themobile device 114. It should be appreciated that the particular flows of themethod 1400 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. - The
illustrative method 1400 begins withflow 1402 ofFIG. 14 in which theedge device 118 encrypts PIN request data with the shared cryptographic key, M In some embodiments, it should be appreciated that the PIN request data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the encrypted PIN request data may be represented as EM (requestPIN) . Inflow 1404, theedge device 118 transmits the encrypted PIN request data, EM (requestPIN), to themobile device 114. - In
flow 1406, themobile device 114 decrypts the encrypted PIN request data using the shared cryptographic key, M, retrieved from a memory of themobile device 114. Inflow 1408,mobile device 114 processes the PIN request and receives a PIN from the user. For example, in some embodiments, themobile device 144 may present a request to the user for an input of a PIN value via a graphical user interface of the mobile application and receive the user's PIN input. Although the authentication data is described herein as a PIN or PIN value, it should be appreciated that the authentication data requested may vary depending on the particular embodiment. Further, in embodiments involving a PIN, the PIN may or may not be alphanumeric depending on the particular embodiment. Additionally, in some embodiments, the pin request and corresponding PIN may constitute a request and response for multiple data (e.g., in embodiments involving multifactor authentication). - In
flow 1410, the mobile device 114 (e.g., using the mobile application) builds a PIN response including the PIN value received from the user and the decrypted PIN request data. As such, in some embodiments, the PIN response may be represented as requestPlN∥PIN . Inflow 1412, themobile device 114 encrypts the PIN response with the shared cryptographic key, M, and inflow 1414, themobile device 114 generates a keyed hash of the encrypted PIN request using the symmetric cryptographic key, A, retrieved from the memory of themobile device 114. In particular, in the illustrative embodiment,mobile device 114 generates an HMAC of the encrypted PIN request based on the symmetric cryptographic key, A (e.g., an HMAC-SHA256 keyed hash). However, it should be appreciated that another type of keyed hash may be generated in other embodiments. - In
flow 1416, themobile device 114 transmits the encrypted PIN response (EM (requestPlN∥PIN)) and the keyed hash (HMACA) of the encrypted PIN response to theedge device 118. Inflow 1418, theedge device 118 verifies the keyed hash of the encrypted PIN request using the symmetric cryptographic key, A, retrieved from the memory of the edge device 118 (e.g., subsequently extracted from the decrypted credential blob as described above). In some embodiments, to do so, theedge device 118 generates a reference keyed hash (e.g., a reference HMAC) of the encrypted PIN response using the symmetric cryptographic key, A, and compares the reference keyed hash to the keyed hash (HMACA) received from themobile device 114 to confirm the keyed hashes match. Inflow 1420, theedge device 118 decrypts the encrypted PIN response using the shared cryptographic key, M, to extract the PIN request data and the user-provided PIN. - In
flow 1422, theedge device 118 verifies the PIN request data. For example, in embodiments in which the PIN request data is a nonce, theedge device 118 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 1402-1404 ofFIG. 14 ). In other embodiments, it should be appreciated that theedge device 118 may otherwise verify and/or validate the decrypted PIN request data. Inflow 1424, theedge device 114 processes the user-provided PIN extracted from the decrypted PIN response. For example, in some embodiments, theedge device 118 and/or other device(s) in theedge system 116 may include a reference PIN value in an access control database against which the user-provided PIN value is compared to determine if the PIN values match. - Although the flows 1402-1424 are described in a relatively serial manner, it should be appreciated that various flows of the
method 1400 may be performed in parallel in some embodiments. - Referring now to
FIG. 15 , in use, theaccess control system 100 may execute amethod 1500 for storing a wireless access credential to themobile device 114. It should be appreciated that the particular flows of themethod 1500 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. Additionally, it should be appreciated that, in the illustrative embodiment, themethod 1500 may be executed in conjunction with and prior to themethod 1600 ofFIGS. 16-17 . - As shown, the
illustrative method 1500 involves one ormore cloud servers 150 and a mobile device 114 (e.g., executing a mobile application as described herein). As indicated above, the cloud server(s) 150 may be referred to herein in the singular for simplicity. Further, theillustrative method 1500 assumes that a cryptographic key exchange has occurred such that thecloud server 150 and an edge device 118 (see, for example,FIGS. 16-17 ) share a symmetric cryptographic key, K. It should appreciated that thecloud server 150 and theedge device 118 may employ any suitable key exchange algorithm to do so. Additionally, the symmetric cryptographic key, K, may vary by type and/or length depending on the particular embodiment. For example, in the illustrative embodiment, the symmetric cryptographic key, K, is embodied as 256-bit Advanced Encryption Standard (AES) keys. In other embodiments, however, the symmetric cryptographic keys may be associated with another cryptographic algorithm such as, for example, Data Encryption Standard (DES), Triple DES, Blowfish, Twofish, Serpent, and/or another symmetric cryptographic algorithm. Similarly, the key may be a 128-bit keys, 512-bit key, or another size in other embodiments (e.g., depending on the cryptographic algorithm). In some embodiments, the cryptographic key is generated by thecloud server 150 and transmitted to theedge device 118. - The
illustrative method 1500 begins withflow 1502 ofFIG. 15 in which thecloud server 150 and themobile device 114 coordinate to assign a wireless access credential to a user (and therefore themobile device 114 of that user) and verify the mobile device 114 (e.g., by confirming that the mobile number corresponds with the mobile device 114). It should be appreciated that, in some embodiments, theaccess control system 100 may execute themethod 2200 ofFIGS. 22-23 to do so. Further, in some embodiments, themobile device 114 may establish a Transport Layer Security (TLS) connection with thecloud server 150 and/or other devices with which themobile device 114 communicates. - In
flow 1504, themobile device 114 generates an asymmetric cryptographic key pair, (C, c) , including a private cryptographic key, c, and a public cryptographic key, C, for storage to themobile device 114 and use as described herein. It should be appreciated that they asymmetric cryptographic key pair and corresponding public/private keys may vary by type depending on the particular embodiment. For example, in the illustrative embodiment, the asymmetric cryptographic key pair is generated based on elliptical curve cryptography (ECC) based on the EC P256 curve. In other embodiments, the asymmetric cryptographic key pair may be associated with another suitable ECC curve. Further, in other embodiments, the asymmetric cryptographic key pair may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm. Similarly, the public/private key sizes may vary depending, for example, on the particular algorithm employed. In some embodiments, the asymmetric cryptographic key pair may be generated and stored on themobile device 114 in advance of the execution of themethod 1500 ofFIG. 15 . Further, it should be appreciated that themobile device 114 may generate the asymmetric cryptographic key pair, (C,c), in a trusted execution environment (TEE) or secure enclave in some embodiments. - In
flow 1506, the mobile device 114 (e.g., using the mobile application) builds a credential request including the public key, C, of the cryptographic key pair (C, c) retrieved from a memory of themobile device 114. Further, in some embodiments, the credential request may identify the payload as a credential request (e.g., via a corresponding flag, CRED_REQ). As such, in some embodiments, the credential request may be represented as CRED_REQ∥C . Inflow 1508, themobile device 114 cryptographically signs the credential request using the private key, c, of the cryptographic key pair (C, c) retrieved from a memory of themobile device 114. In other words, themobile device 114 generates a cryptographic signature of the credential request. Inflow 1510, themobile device 114 transmits the signed credential request to the cloud server 150 (e.g., via a TLS connection). As such, in the illustrative embodiment, themobile device 114 transmits the credential request and the signature thereof to thecloud server 150. - In
flow 1512, thecloud server 150 extracts the public key, C, from the credential request received from themobile device 114 and verifies the credential request signature using that public key. That is, thecloud server 150 verifies that the credential request was signed using the private key that corresponds with the public key, C. It should be appreciated that thecloud server 150 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). - In
flow 1514, thecloud server 150 builds a credential blob including the credential to be transmitted to the mobile device (i.e., the credential assigned to themobile device 114 and the user) and the public key, C. Further, in some embodiments, the credential blob may further include a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the credential blob may be represented as nonce ∥C∥credential . Inflow 1516, thecloud server 150 encrypts the credential blob with the symmetric cryptographic key, K, and, inflow 1518, thecloud server 150 generates a keyed hash of the encrypted credential blob using the same symmetric cryptographic key, K. In particular, in the illustrative embodiment, thecloud server 150 generates an HMAC of the encrypted credential blob based on the symmetric cryptographic key, K (e.g., an HMAC-SHA256 keyed hash). However, it should be appreciated that another type of keyed hash may be generated in other embodiments. - In
flow 1520, thecloud server 150 transmits the encrypted credential blob (EK (nonce∥C∥credential)) and the keyed hash of the encrypted credential blob to themobile device 114. In particular, in some embodiments, a payload including those data may be represented as EK (nonce∥C∥credential)∥HMACK . Inflow 1522, themobile device 114 stores the encrypted credential blob (EK (nonce∥C∥credential)) and the keyed hash of the encrypted credential blob (HMACK) to a memory of themobile device 114. As such, it should be appreciated that, in the illustrative embodiment, themobile device 114 now has a credential stored thereon that is tied to themobile device 114, but themobile device 114 is unable to read the credential data due to the encryption. It should be appreciated that, in some embodiments, the memory of themobile device 114 to which such data is stored is a secure memory. - Although the flows 1502-1522 are described in a relatively serial manner, it should be appreciated that various flows of the
method 1500 may be performed in parallel in some embodiments. - Referring now to
FIGS. 16-17 , in use, theaccess control system 100 may execute amethod 1600 for using a wireless access credential (e.g., a wireless access credential stored to themobile device 114 according to themethod 1500 ofFIG. 15 ). It should be appreciated that the particular flows of themethod 1600 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. In some embodiments, themethod 1600 ofFIGS. 12-13 may be executed in conjunction with and subsequent to themethod 1500 ofFIG. 15 . - As shown, the
illustrative method 1600 involves the mobile device 114 (e.g., themobile device 114 described in reference toFIG. 15 ) and anedge device 118. Also as described above in reference toFIG. 15 , theillustrative method 1600 assumes that a cryptographic key exchange has occurred such that the cloud server 150 (see, for example,FIG. 15 ) and theedge device 118 share a symmetric cryptographic key, K. Also, themobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c) , including a private cryptographic key, c, and a public cryptographic key, C, described above. Further, in embodiments involving themethod 1500 ofFIG. 15 in conjunction with themethod 1600 ofFIGS. 16-17 , themobile device 114 also has stored thereon the encrypted credential blob (EK (nonce∥C∥credential)) and the keyed hash of the encrypted credential blob (HMACK) after the execution of themethod 1500 ofFIG. 15 . - The
illustrative method 1600 begins withflow 1602 ofFIG. 16 in which themobile device 114 and theedge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4.2 or newer connection). In doing so, themobile device 114 and/or theedge device 118 may execute various Bluetooth-defined functions including, for example, getDevice , tryConnecting ( ), onSuccess, tryDiscovering ( ) and/or onServicesDiscovered ( ) functions. Inflow 1604, themobile device 114 and theedge device 118 perform a secure key exchange to generate a shared cryptographic session key, s, separately at each of themobile device 114 and theedge device 118. In the illustrative embodiment, the session key, s, is generated based on Elliptical Curve Diffie-Hellman (ECDH). By using ECDH instead of HKDF to perform a key exchange, it should be appreciated that the shared cryptographic session key, s, is dynamic in the sense that the key is different every time the key is generated. As such, in some embodiments, each exchange may have a different session key. More specifically, in some embodiments, themobile device 114 and theedge device 118 may execute a method similar to themethod 2600 ofFIG. 26 to perform the secure key exchange. However, it should be appreciated that the session key, s, may be generated based on a different key derivation function and/or other suitable algorithm in other embodiments. Following the execution of the secure key exchange, each of themobile device 114 and theedge device 118 has the same session key, s, stored thereon. - In
flow 1606, theedge device 118 encrypts challenge data with the shared cryptographic session key, s. In some embodiments, it should be appreciated that the challenge data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the encrypted challenge data may be represented as Es (challenge) . Inflow 1608, theedge device 118 transmits the encrypted challenge data, E s(challenge) , to themobile device 114 via the established Bluetooth communication connection. - In
flow 1610, themobile device 114 decrypts the encrypted challenge data using the shared cryptographic session key, s, retrieved from a memory of themobile device 114 and, inflow 1612, the mobile device 114 (e.g., using the mobile application) builds a credential message including the challenge data received from theedge device 118, the encrypted credential blob retrieved from the memory of themobile device 114, and the keyed hash retrieved from the memory of themobile device 114. As such, in some embodiments, the credential message may be represented as challenge∥EK (nonce∥MC∥credential)∥HMACK. Inflow 1614, themobile device 114 encrypts the credential message with the shared cryptographic session key, s, and inflow 1616, themobile device 114 cryptographically signs the encrypted credential message using the private key, c, of the cryptographic key pair (C, c) retrieved from a memory of themobile device 114. In other words, themobile device 114 generates a cryptographic signature (cSig) of the encrypted credential message. - In
flow 1618, themobile device 114 transmits the signed credential message to theedge device 118. As such, in the illustrative embodiment, themobile device 114 transmits the encrypted credential message and the signature thereof to theedge device 118. Inflow 1620, theedge device 118 decrypts the encrypted credential message using the shared cryptographic session key, s, retrieved from the memory of theedge device 118. - In
flow 1622 ofFIG. 17 , theedge device 118 verifies the challenge data. For example, in embodiments in which the challenge data is a nonce, theedge device 118 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 1606-1608 ofFIG. 16 ). In other embodiments, it should be appreciated that theedge device 118 may otherwise verify and/or validate the decrypted challenge data. Inflow 1624, theedge device 118 verifies the keyed hash (HMACK) of the encrypted credential blob (e.g., extracted from the decrypted credential message) using the symmetric cryptographic key, K, retrieved from the memory of theedge device 118. In some embodiments, to do so, theedge device 118 generates a reference keyed hash (e.g., a reference HMAC) of the encrypted credential blob extracted from the decrypted credential message using the symmetric cryptographic key, K, and compares the reference keyed hash to the keyed hash (HMACK) of the encrypted credential blob extracted from the decrypted credential message to confirm the keyed hashes match. - In
flow 1626, theedge device 118 decrypts the encrypted credential blob using the symmetric cryptographic key, K, retrieved from the memory of theedge device 118 and, inblock 1628, theedge device 118 extracts the credential and the public cryptographic key, C, from the decrypted credential blob. It should be appreciated that, in the illustrative embodiment, theedge device 118 and thecloud server 150 are capable of encrypting/decrypting the credential blob including the credential, whereas themobile device 114 is not. Instead, in such embodiments, themobile device 114 acts as a conduit for the secure transfer of the credential between thecloud server 150 and theedge device 118. Further, in the illustrative embodiment, the public cryptographic key, C, is not directly transmitted from themobile device 114 to theedge device 118. As such, the public cryptographic key, C, may be leveraged to verify that themobile device 114 that made the initial contact with thecloud server 150 is the same device that signed the payload (e.g., the encrypted credential message) toward the end of the communication sequence. - In
flow 1630, theedge device 118 verifies the signature of the encrypted credential message using the public cryptographic key, C, extracted from the decrypted credential blob. That is, theedge device 118 verifies that the encrypted credential message was signed using the private key that corresponds with the public key, C. It should be appreciated that theedge device 118 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). - It should be appreciated that the credential payload (e.g., the encrypted credential blob) stored to the mobile device in
flow 1522 ofFIG. 15 includes the public cryptographic key, C, that is associated with and stored on themobile device 114 and provided to themobile access hub 112 at onboarding. As such, when the credential message is subsequently delivered to theedge device 118 with the cryptographic signature (cSig) inflow 1618 ofFIG. 16 , the public cryptographic key, C, verifies that the credential is associated with the samemobile device 114. As such, in the illustrative embodiment, if the credential is copied to a differentmobile device 114, the verification of the cryptographic signature (cSig) will fail, because the cryptographic key pair (C, c) is unique for eachmobile device 114. In other words, the use of the cryptographic key pair (C, c) as described herein serves, for example, to prevent the unauthorized copying of a credential to a differentmobile device 114. - In
flow 1632, theedge device 118 processes the credential extracted from the credential blob. It should be appreciated that the credential may be processed in a manner similar to that described in reference to flow 1234 ofFIG. 13 . As such, in some embodiments, theedge device 118 and/or other device(s) in theedge system 116 may make an access control decision based on the extracted credential and an access control database. Further, theedge device 118 itself or another device (e.g., theadministrative system 110, theaccess controller 134, etc.) may perform the access control decision based on the particular embodiment. Further, in some embodiments, in response to successful authentication of the credential, thelock device 132 may unlock a lock mechanism as described above. In some embodiments, it should be appreciated that further authentication of the user and/or themobile device 114 may be required in advance of, or in conjunction with, the processing of the credential. For example, in some embodiments, themethod 1800 ofFIG. 18 may be executed to process a PIN of the user. In other embodiments, the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, and/or additional information. It should be appreciated that, in some embodiments, the credential value and/or other portion of the credential may include an indicator that further authentication is required. - Although the flows 1602-1632 are described in a relatively serial manner, it should be appreciated that various flows of the
method 1600 may be performed in parallel in some embodiments. - Referring now to
FIG. 18 , in use, theaccess control system 100 may execute amethod 1800 for further authenticating a user of themobile device 114. It should be appreciated that the particular flows of themethod 1800 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. Although the techniques are generally described herein in reference to a PIN value, it should be appreciated that similar techniques may be employed with respect to other secondary credential/authentication data. For example, in some embodiments, facial identification, thumb print, other biometrics, voice recognition, gestures, and/or other relevant authentication data may be used in conjunction with themethod 1800 and other techniques described herein. - The
illustrative method 1800 begins withflow 1802 ofFIG. 18 in which theedge device 118 encrypts PIN request data with the shared cryptographic session key, s. In some embodiments, it should be appreciated that the PIN request data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the encrypted PIN request data may be represented as E s(requestPIN) . Inflow 1804, theedge device 118 transmits the encrypted PIN request data, Es (requestPIN), to themobile device 114. - In
flow 1806, themobile device 114 decrypts the encrypted PIN request data using the shared cryptographic session key, s, retrieved from a memory of themobile device 114. Inflow 1808,mobile device 114 processes the PIN request and receives a PIN from the user (e.g., in a manner similar to that described above in reference to themethod 1400 ofFIG. 14 ). For example, in some embodiments, themobile device 144 may present a request to the user for an input of a PIN value via a graphical user interface of the mobile application and receive the user's PIN input. As indicated above, although the authentication data is described herein as a PIN or PIN value, it should be appreciated that the authentication data requested may vary (e.g., in type, source, format, etc.) depending on the particular embodiment. - In
flow 1810, the mobile device 114 (e.g., using the mobile application) builds a PIN response including the PIN value received from the user and the decrypted PIN request data. As such, in some embodiments, the PIN response may be represented as requestPlN∥PIN . Inflow 1812, themobile device 114 encrypts the PIN response with the shared cryptographic session key, s, and inflow 1814, themobile device 114 transmits the encrypted PIN response (Es(requestPIN∥PIN)) to theedge device 118. It should be appreciated that, in some embodiments, themobile device 114 may further generate a keyed hash of the encrypted PIN request (e.g., as in themethod 1400 ofFIG. 14 ) or otherwise convey data indicative of the integrity of the message. - In
flow 1816, theedge device 118 decrypts the encrypted PIN response using the shared cryptographic session key, s, to extract the PIN request data and the user-provided PIN and, inflow 1818, theedge device 118 verifies the PIN request data. For example, in embodiments in which the PIN request data is a nonce, theedge device 118 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 1802-1804 ofFIG. 18 ). In other embodiments, it should be appreciated that theedge device 118 may otherwise verify and/or validate the decrypted PIN request data. Inflow 1820, theedge device 114 processes the user-provided PIN extracted from the decrypted PIN response (e.g., in a manner similar to that described in reference to themethod 1400 ofFIG. 14 and/or otherwise described herein). For example, in some embodiments, theedge device 118 and/or other device(s) in theedge system 116 may include a reference PIN value in an access control database against which the user-provided PIN value is compared to determine if the PIN values match. - Although the flows 1802-1820 are described in a relatively serial manner, it should be appreciated that various flows of the
method 1800 may be performed in parallel in some embodiments. - Referring now to
FIG. 19 , in use, theaccess control system 100 may execute amethod 1900 for storing a wireless access credential to themobile device 114. It should be appreciated that the particular flows of themethod 1900 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. Additionally, it should be appreciated that, in the illustrative embodiment, themethod 1900 may be executed in conjunction with and prior to themethod 2000 ofFIGS. 20-21 . - As shown, the
illustrative method 1900 involves one ormore cloud servers 150 and a mobile device 114 (e.g., executing a mobile application as described herein). As indicated above, the cloud server(s) 150 may be referred to herein in the singular for simplicity. Further, theillustrative method 1900 assumes that a cryptographic key exchange has occurred such that thecloud server 150 and an edge device 118 (see, for example,FIGS. 20-21 ) share a symmetric cryptographic key, K. It should appreciated that thecloud server 150 and theedge device 118 may employ any suitable key exchange algorithm to do so. Additionally, the symmetric cryptographic key, K, may vary by type and/or length depending on the particular embodiment. For example, in the illustrative embodiment, the symmetric cryptographic key, K, is embodied as 256-bit Advanced Encryption Standard (AES) keys. In other embodiments, however, the symmetric cryptographic keys may be associated with another cryptographic algorithm such as, for example, Data Encryption Standard (DES), Triple DES, Blowfish, Twofish, Serpent, and/or another symmetric cryptographic algorithm. Similarly, the key may be a 128-bit keys, 512-bit key, or another size in other embodiments (e.g., depending on the cryptographic algorithm). In some embodiments, the cryptographic key is generated by thecloud server 150 and transmitted to theedge device 118. - It should also appreciated that the
illustrative method 1900 further assumes that an asymmetric cryptographic key pair, (D, d), including a private cryptographic key, d, and a public cryptographic key, D, has been generated and stored to thecloud server 150, and that the public cryptographic key, D, has been stored to theedge device 118 for use as described herein. It should be appreciated that they asymmetric cryptographic key pair, (D, d), and corresponding public/private keys may vary by type depending on the particular embodiment. For example, in the illustrative embodiment, the asymmetric cryptographic key pair, (D, d), is generated based on elliptical curve cryptography (ECC) based on the EC P256 curve. In other embodiments, the asymmetric cryptographic key pair may be associated with another suitable ECC curve. Further, in other embodiments, the asymmetric cryptographic key pair may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm. Similarly, the public/private key sizes may vary depending, for example, on the particular algorithm employed. In some embodiments, the asymmetric cryptographic key pair, (D, d), may be generated by thecloud server 150 and the public cryptographic key, D, may be securely transmitted to theedge device 118 according to any suitable exchange protocol or provisioning mechanism. - The
illustrative method 1900 begins withflow 1902 ofFIG. 19 in which thecloud server 150 and themobile device 114 coordinate to assign a wireless access credential to a user (and therefore themobile device 114 of that user) and verify the mobile device 114 (e.g., by confirming that the mobile number corresponds with the mobile device 114). It should be appreciated that, in some embodiments, theaccess control system 100 may execute themethod 2200 ofFIGS. 22-23 to do so. Further, in some embodiments, themobile device 114 may establish a Transport Layer Security (TLS) connection with thecloud server 150 and/or other devices with which themobile device 114 communicates. - In
flow 1904, themobile device 114 generates an asymmetric cryptographic key pair, (C, c) , including a private cryptographic key, c, and a public cryptographic key, C, for storage to themobile device 114 and use as described herein. Similar to the asymmetric cryptographic key pair, (D, d) , it should be appreciated that they asymmetric cryptographic key pair, (C, c) , and corresponding public/private keys may vary by type depending on the particular embodiment. In some embodiments, it should be appreciated that the asymmetric cryptographic key pair, (C, c), may be a similar type of key pair as the asymmetric cryptographic key pair, (D, d), described above. For example, in the illustrative embodiment, the asymmetric cryptographic key pair, (C, c) , is generated based on elliptical curve cryptography (ECC) based on the EC P256 curve. In other embodiments, the asymmetric cryptographic key pair may be associated with another suitable ECC curve. Further, in other embodiments, the asymmetric cryptographic key pair, (C, c) , may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm. Similarly, the public/private key sizes may vary depending, for example, on the particular algorithm employed. In some embodiments, the asymmetric cryptographic key pair, (C, c), may be generated and stored on themobile device 114 in advance of the execution of themethod 1900 ofFIG. 19 . Further, it should be appreciated that themobile device 114 may generate the asymmetric cryptographic key pair, (C, c), in a trusted execution environment (TEE) or secure enclave in some embodiments. - In
flow 1906, the mobile device 114 (e.g., using the mobile application) builds a credential request including the public key, C, of the cryptographic key pair (C, c) retrieved from a memory of themobile device 114. Further, in some embodiments, the credential request may identify the payload as a credential request (e.g., via a corresponding flag, CRED_REQ). As such, in some embodiments, the credential request may be represented as C RED_REQ∥C . Inflow 1908, themobile device 114 cryptographically signs the credential request using the private key, c, of the cryptographic key pair , (C, c), retrieved from a memory of themobile device 114. In other words, themobile device 114 generates a cryptographic signature of the credential request. Inflow 1910, themobile device 114 transmits the signed credential request to the cloud server 150 (e.g., via a TLS connection). As such, in the illustrative embodiment, themobile device 114 transmits the credential request and the signature thereof to thecloud server 150. - In
flow 1912, thecloud server 150 extracts the public key, C, from the credential request received from themobile device 114 and verifies the credential request signature using that public key. That is, thecloud server 150 verifies that the credential request was signed using the private key that corresponds with the public key, C. It should be appreciated that thecloud server 150 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). - In
flow 1914, thecloud server 150 builds a credential blob including the credential to be transmitted to the mobile device (i.e., the credential assigned to themobile device 114 and the user) and the public key, C. Further, in some embodiments, the credential blob may further include a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the credential blob may be represented as nonce∥C∥credential . Inflow 1916, thecloud server 150 encrypts the credential blob with the symmetric cryptographic key, K, and, inflow 1918, thecloud server 150 cryptographically signs the encrypted credential blob using the private key, d, of the cryptographic key pair, (D,d) , stored in the memory of thecloud server 150. In other words, thecloud server 150 generates a cryptographic signature of the encrypted credential blob. - In
flow 1920, thecloud server 150 transmits the encrypted credential blob (EK (nonce∥C∥credential)) and the signature thereof to themobile device 114. Inflow 1922, thecloud server 150 stores the encrypted credential blob (EK (nonce∥C∥credential)) and the signature thereof to a memory of themobile device 114. As such, it should be appreciated that, in the illustrative embodiment, themobile device 114 now has a credential stored thereon that is tied to themobile device 114, but themobile device 114 is unable to read the credential data due to the encryption. It should be appreciated that, in some embodiments, the memory of themobile device 114 to which such data is stored is a secure memory. - Although the flows 1902-1922 are described in a relatively serial manner, it should be appreciated that various flows of the
method 1900 may be performed in parallel in some embodiments. - Referring now to
FIGS. 20-21 , in use, theaccess control system 100 may execute amethod 2000 for using a wireless access credential (e.g., a wireless access credential stored to themobile device 114 according to themethod 1900 ofFIG. 19 ). It should be appreciated that the particular flows of themethod 2000 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. In some embodiments, themethod 2000 ofFIGS. 20-21 may be executed in conjunction with and subsequent to themethod 1900 ofFIG. 19 . - As shown, the
illustrative method 2000 involves the mobile device 114 (e.g., themobile device 114 described in reference toFIG. 19 ) and anedge device 118. Also as described above in reference toFIG. 19 , theillustrative method 2000 assumes that a cryptographic key exchange has occurred such that the cloud server 150 (see, for example,FIG. 19 ) and theedge device 118 share a symmetric cryptographic key, K. Also, themobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c) , including a private cryptographic key, c, and a public cryptographic key, C, described above. It should also appreciated that theillustrative method 2000 further assumes that an asymmetric cryptographic key pair, (D,d), including a private cryptographic key, d, and a public cryptographic key, D, has been stored to thecloud server 150, and that the public cryptographic key, D, has been stored to theedge device 118. Further, in embodiments involving themethod 1900 ofFIG. 19 in conjunction with themethod 2000 ofFIGS. 20-21 , themobile device 114 also has stored thereon the encrypted credential blob (EK (nonce∥C∥credential)) and signature thereof after the execution of themethod 1900 ofFIG. 19 . - The
illustrative method 2000 begins withflow 2002 ofFIG. 20 in which themobile device 114 and theedge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4.2 or newer connection). In doing so, themobile device 114 and/or theedge device 118 may execute various Bluetooth-defined functions including, for example, getDevice , tryConnecting ( ), onSuccess, tryDiscovering ( ) and/or onServicesDiscovered ( ) functions. Inflow 2004, themobile device 114 and theedge device 118 perform a secure key exchange to generate a shared cryptographic session key, s, separately at each of themobile device 114 and theedge device 118. In the illustrative embodiment, the session key, s, is generated based on Elliptical Curve Diffie-Hellman (ECDH). More specifically, in some embodiments, themobile device 114 and theedge device 118 may execute a method similar to themethod 2600 ofFIG. 26 to perform the secure key exchange. However, it should be appreciated that the session key, s, may be generated based on a different key derivation function and/or other suitable algorithm in other embodiments. Following the execution of the secure key exchange, each of themobile device 114 and theedge device 118 has the same session key, s, stored thereon. - In
flow 2006, theedge device 118 encrypts challenge data with the shared cryptographic session key, s. In some embodiments, it should be appreciated that the challenge data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the encrypted challenge data may be represented as Es (challenge) . Inflow 2008, theedge device 118 transmits the encrypted challenge data, E s(challenge) , to themobile device 114 via the established Bluetooth communication connection. - In
flow 2010, themobile device 114 decrypts the encrypted challenge data using the shared cryptographic session key, s, retrieved from a memory of themobile device 114 and, inflow 2012, the mobile device 114 (e.g., using the mobile application) builds a credential message including the challenge data received from theedge device 118, the encrypted credential blob retrieved from the memory of themobile device 114, and the signature of the encrypted credential blob retrieved from the memory of themobile device 114. Inflow 2014, themobile device 114 encrypts the credential message with the shared cryptographic session key, s, and inflow 2016, themobile device 114 cryptographically signs the encrypted credential message using the private key, c, of the cryptographic key pair (C, c) retrieved from a memory of themobile device 114. In other words, themobile device 114 generates a cryptographic signature of the encrypted credential message. - In
flow 2018, themobile device 114 transmits the signed and encrypted credential message to theedge device 118. As such, in the illustrative embodiment, themobile device 114 transmits the encrypted credential message and the signature thereof to theedge device 118. Inflow 2020, theedge device 118 decrypts the encrypted credential message using the shared cryptographic session key, s, retrieved from the memory of theedge device 118. - In
flow 2022 ofFIG. 21 , theedge device 118 verifies the challenge data. For example, in embodiments in which the challenge data is a nonce, theedge device 118 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 2006-2008 ofFIG. 20 ). In other embodiments, it should be appreciated that theedge device 118 may otherwise verify and/or validate the decrypted challenge data. Inflow 2024, theedge device 118 verifies the signature of the encrypted credential blob using the public cryptographic key, D, retrieved from the memory of theedge device 118. That is, theedge device 118 verifies that the encrypted credential blob was signed using the private key that corresponds with the public key, D. It should be appreciated that theedge device 118 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). - In
flow 2026, theedge device 118 decrypts the encrypted credential blob using the symmetric cryptographic key, K, retrieved from the memory of theedge device 118 and, inblock 2028, theedge device 118 extracts the credential and the public cryptographic key, C, from the decrypted credential blob. It should be appreciated that, in the illustrative embodiment, theedge device 118 and thecloud server 150 are capable of encrypting/decrypting the credential blob including the credential, whereas themobile device 114 is not. Instead, in such embodiments, themobile device 114 acts as a conduit for the secure transfer of the credential between thecloud server 150 and theedge device 118. - In
flow 2030, theedge device 118 verifies the signature of the encrypted credential message using the public cryptographic key, C, extracted from the decrypted credential blob. That is, theedge device 118 verifies that the encrypted credential message was signed using the private key that corresponds with the public key, C. It should be appreciated that theedge device 118 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). It should be further appreciated that the use of the cryptographic key pair (C, c) serves, for example, to prevent the unauthorized copying of a credential to a differentmobile device 114 as described above in reference toFIGS. 15-17 . - In
flow 2032, theedge device 118 processes the credential extracted from the credential blob. It should be appreciated that the credential may be processed in a manner similar to that described in reference to flow 1234 ofFIG. 13 . As such, in some embodiments, theedge device 118 and/or other device(s) in theedge system 116 may make an access control decision based on the extracted credential and an access control database. Further, theedge device 118 itself or another device (e.g., theadministrative system 110, theaccess controller 134, etc.) may perform the access control decision based on the particular embodiment. Further, in some embodiments, in response to successful authentication of the credential, thelock device 132 may unlock a lock mechanism as described above. In some embodiments, it should be appreciated that further authentication of the user and/or themobile device 114 may be required in advance of, or in conjunction with, the processing of the credential. For example, in some embodiments, themethod 1800 ofFIG. 18 may be executed to process a PIN of the user. In other embodiments, the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, and/or additional information. It should be appreciated that, in some embodiments, the credential value and/or other portion of the credential may include an indicator that further authentication is required. - Although the flows 2002-2032 are described in a relatively serial manner, it should be appreciated that various flows of the
method 2000 may be performed in parallel in some embodiments. - Referring now to
FIGS. 22-23 , in use, theaccess control system 100 may execute amethod 2200 for assigning a wireless access credential to a mobile number. It should be appreciated that the particular flows of themethod 2200 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. As shown, theillustrative method 2200 involves acredential management system 102, amobile access hub 112, and a mobile device 114 (e.g., executing a mobile application as described herein). Additionally, it should be appreciated that, in some embodiments, themethod 2200 may be executed in conjunction with and prior to themethod 2400 ofFIGS. 24-25 . - The
illustrative method 2200 begins withflow 2202 ofFIG. 22 in which thecredential management system 102 transmits an indication that a new credential has been assigned to a mobile line/phone number of a user to themobile access hub 112. For example, as described above, the system/site administrator may request that the credential be issued to the user (and/or the mobile line number) by thecredential management system 102, and thecredential management system 102 may assign the credential to the user (and/or mobile line number). In particular, in some embodiments, thecredential management system 102 may leverage thecredential API 124 to interface with and/or “call” themobile access hub 112 requesting a message to be transmitted to the user's mobile device 114 (e.g., a text/SMS message). - In
flow 2204, themobile access hub 112 generates and transmits a deep link via SMS to themobile device 114 at the mobile device number provided when the credential was issued to the user. In other embodiments, themobile access hub 112 may interface with Twilio and/or another suitable messaging service for generating and transmitting the appropriate messages to themobile device 114. Inflow 2206, themobile device 114 launches a corresponding mobile application via the deep link and obtains the mobile number of themobile device 114. It should be appreciated that the illustrative deep link is configured to launch a mobile application on themobile device 114 to securely receive the credential or, if the mobile application not accessible (e.g., not installed) on themobile device 114, direct the user to the download location (e.g., an “App store”) to download the relevant mobile application. Further, it should be appreciated that the mobile number may be obtained automatically, semi-automatically, or via user input depending on the particular embodiment. For example, some mobile device operating systems (e.g., Android operating systems) may allow the mobile application to access the mobile number via a simple prompt, whereas other mobile device operating systems (e.g., iOS operating systems) may require the user to manually enter the mobile number into the application. - In some embodiments, the
mobile device 114 may establish a Transport Layer Security (TLS) connection with themobile access hub 112 for secure communications. Inflow 2208, the mobile device 114 (e.g., via the mobile application) transmits the obtained mobile number to the mobile access hub 112 (e.g., along with a request for a verification code) and, inflow 2210, themobile access hub 112 compares the mobile number to a credential database (e.g., an access control database) to determine whether the mobile number is already associated with a wireless access credential (e.g., a BLE credential). In doing so, themobile access hub 112 may also determine whether the mobile number has already been authenticated (e.g., via a verification code and response). In some embodiments, if the mobile number is not already associated with a credential (e.g., and therefore not authenticated), themethod 2200 may advances to flow 2212 in which themobile access hub 112 generates a verification code (e.g., a 6-digit verification code) and transmits the verification code to themobile device 114 via SMS. Inflow 2214, the mobile device 114 (e.g., via a graphical user interface of the mobile application) prompts the user to enter the verification code (e.g., received by themobile device 114 via SMS) and received/processes the user's input (i.e., the code entry). - In
flow 2216, themobile device 114 generates an asymmetric cryptographic key pair, (P, p) , including a private cryptographic key, p, and a public cryptographic key, P, for storage to themobile device 114 and use as described herein. It should be appreciated that they asymmetric cryptographic key pair, (P, p), and corresponding public/private keys may vary by type depending on the particular embodiment. For example, in the illustrative embodiment, the asymmetric cryptographic key pair, (P, p), is generated based on elliptical curve cryptography (ECC) based on the EC P256 curve. In other embodiments, the asymmetric cryptographic key pair may be associated with another suitable ECC curve. Further, in other embodiments, the asymmetric cryptographic key pair, (P, p), may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm. Similarly, the public/private key sizes may vary depending, for example, on the particular algorithm employed. In some embodiments, the asymmetric cryptographic key pair, (P, p), may be generated and stored on themobile device 114 in advance of the execution of themethod 2200 ofFIG. 22 . Further, it should be appreciated that themobile device 114 may generate the asymmetric cryptographic key pair, (P, p), in a trusted execution environment (TEE) or secure enclave in some embodiments. - In
flow 2218 ofFIG. 23 , the mobile device 114 (e.g., using the mobile application) builds a payload including the public key, P, of the cryptographic key pair (P, p) retrieved from a memory of themobile device 114, the user-entered code, and the mobile number of themobile device 114. Inflow 2220, themobile device 114 also builds another payload including a timestamp (e.g., generated from a real-time clock of the mobile device 114) and the mobile number of themobile device 114. In some embodiments, the payload including the timestamp and mobile number may be utilized by themobile access hub 112 as login credentials for themobile device 114. Inflow 2222, themobile device 114 cryptographically signs the payloads using the private key, p, of the cryptographic key pair, (P, p) , retrieved from the memory of themobile device 114. In other words, themobile device 114 generates a cryptographic signature of the payload built inflow 2218 and a cryptographic signature of the payload built inflow 2220. In some embodiments, it should be appreciated that themobile device 114 may combine the data of the two payloads into a single payload that is cryptographically signed. Inflow 2224, themobile device 114 transmits the signed payloads to the mobile access hub 112 (e.g., via a TLS connection). As such, in the illustrative embodiment, themobile device 114 transmits each of the payloads (e.g., from flows 2218-2220) and the signatures thereof to themobile access hub 112. However, in other embodiments, themobile device 114 may transmit a single payload (or combination of payloads) and a single signature thereof to themobile access hub 112 as indicated above. - In
flow 2226, themobile access hub 112 extracts the public key, P, from the payload (e.g., the first payload) received from themobile device 114 and verifies the signature(s) of the payload(s) using that public key. That is, themobile access hub 112 verifies that each of the relevant payloads was signed using the private key that corresponds with the public key, P. It should be appreciated that themobile access hub 112 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). - In
flow 2228, themobile access hub 112 extracts the user-entered code received from themobile device 114 to the verification code transmitted from themobile access hub 112 to themobile device 114 inflow 2212. It should be appreciated that themobile access hub 112 may consider themobile device 114 to be the device corresponding with the mobile number if the user-entered code matches the verification code. Otherwise, themobile access hub 112 may undergo one or more error handling procedures (e.g., re-sending the verification code, etc.). Inflow 2230, themobile access hub 112 associates the mobile number of the user with the wireless access credential in the credential database (e.g., an access control database). As such, in some embodiments, themobile access hub 112 may subsequently determine that the mobile number is associated with a particular account (e.g., inflow 2210 ofFIG. 22 ) and, for example, transmit a push notification to the mobile application of themobile device 114 instead of transmitting a deep link to the mobile device 114 (e.g., for pulling multiple credentials associated with a mobile number). - Although the flows 2202-2230 are described in a relatively serial manner, it should be appreciated that various flows of the
method 2200 may be performed in parallel in some embodiments. - As described herein, multiple credentials may be associated with the same mobile number and therefore the same
mobile device 114. As such, it should be appreciated that techniques similar to those of themethod 2200 may be used to onboard subsequent credentials after the mobile application has already been instead. In such embodiments, for example, the flows 2204-2214 regarding the downloading of the application and the code verification and theflow 2218 associated with building the payload with the user-entered code may be omitted. More specifically, in some embodiments, those flows 2204-2214 may be replaced with a flow in which themobile access hub 112 determines that the mobile number is already associated with a credential and transmits a notification (e.g., a push notification) to themobile device 114 regarding the assignment of the new credential to the mobile number, and themethod 2200 may resume atflow 2216 to obtain the new credential. It should be further appreciated that, in some embodiments, themethod 2200 may include flows (e.g., after the flow 2230) in which themobile device 114 transmits a request to themobile access hub 112 for a list or identification of the credentials and/or access rights of themobile device 114 and/or associated with the mobile number (e.g., GET/MobileAccessRights), and themobile access hub 112 responds with such list or identifiers (e.g., CMSMobileAccess A, CMSMobileAccess B). Based on the list, themobile device 114 may request the proper credential. - It should be appreciated that a modified version of the
method 2200 may also be employed when a user gets a newmobile device 114 or deletes the mobile application such that the user's credentials need to be re-downloaded/on-boarded via themobile access hub 112. In such embodiments, themobile access hub 112 may re-verify the user's mobile number and re-download the credentials for that user. For example, theflow 2204 associated with the transmission of the deep link from themobile access hub 112 to themobile device 114 may be omitted. Instead, themobile device 114 may launch the newly installed mobile application inflow 2206 and resume execution of themethod 2200 to onboard the credential. It should be appreciated that theaccess control system 100 allows the user to keep the same credentials without purchasing a new credential for each newmobile device 114. - Referring now to
FIGS. 24-25 , in use, theaccess control system 100 may execute amethod 2400 for storing a wireless access credential to themobile device 114. It should be appreciated that the particular flows of themethod 2400 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. Additionally, it should be appreciated that, in the illustrative embodiment, themethod 2400 may be executed in conjunction with and prior to themethod 2700 ofFIGS. 27-29 and/or in conjunction with and subsequent to themethod 2200 ofFIGS. 22-23 . - As shown, the
illustrative method 2400 involves akey management system 108, acredential management system 102, amobile access hub 112, and a mobile device 114 (e.g., executing a mobile application as described herein). As indicated above, in some embodiments, one or more of thekey management system 108, thecredential management system 102, and/or themobile access hub 112 may be embodied as cloud-based systems and/or may form a portion of one another. - Further, the
illustrative method 2400 assumes that a cryptographic key exchange has occurred such that thekey management system 108 and anedge device 118 or, more specifically, amain chipset 142 of an edge device 118 (see, for example,FIGS. 26-29 ) share a symmetric cryptographic key, K. It should appreciated that the key management system 108 (and/or other cloud servers 150) and theedge device 118 may employ any suitable key exchange algorithm to do so. Additionally, the symmetric cryptographic key, K, may vary by type and/or length depending on the particular embodiment. For example, in the illustrative embodiment, the symmetric cryptographic key, K, is embodied as 256-bit Advanced Encryption Standard (AES) keys. In other embodiments, however, the symmetric cryptographic keys may be associated with another cryptographic algorithm such as, for example, Data Encryption Standard (DES), Triple DES, Blowfish, Twofish, Serpent, and/or another symmetric cryptographic algorithm. Similarly, the key may be a 128-bit keys, 512-bit key, or another size in other embodiments (e.g., depending on the cryptographic algorithm). In some embodiments, the cryptographic key is generated by thekey management system 108 and transmitted to theedge device 118. - It should also appreciated that the
illustrative method 2400 further assumes that an asymmetric cryptographic key pair, (D, d), including a private cryptographic key, d, and a public cryptographic key, D, has been generated and stored to thekey management system 108, and that the public cryptographic key, D, has been stored to theedge device 118 or, more specifically, to thecryptography chipset 144 of theedge device 118 for use as described herein. It should be appreciated that they asymmetric cryptographic key pair, (D, d), and corresponding public/private keys may vary by type depending on the particular embodiment. For example, in the illustrative embodiment, the asymmetric cryptographic key pair, (D, d), is generated based on elliptical curve cryptography (ECC) based on the EC P256 curve. In other embodiments, the asymmetric cryptographic key pair may be associated with another suitable ECC curve. Further, in other embodiments, the asymmetric cryptographic key pair may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm. Similarly, the public/private key sizes may vary depending, for example, on the particular algorithm employed. In some embodiments, the asymmetric cryptographic key pair, (D, d), may be generated by the key management system 108 (or other cloud server 150) and the public cryptographic key, D, may be securely transmitted to theedge device 118 according to any suitable exchange protocol or provisioning mechanism. In some embodiments, themethod 2400 further assumes that the asymmetric cryptographic key pair, (P, p), including the private cryptographic key, p, and the public cryptographic key, P, have been generated and stored to themobile device 114 as described above. - The
illustrative method 2400 begins withflow 2402 ofFIG. 24 in which themobile device 114 generates an asymmetric cryptographic key pair, (C,c), including a private cryptographic key, c, and a public cryptographic key, C, for storage to themobile device 114 and use as described herein. Similar to the asymmetric cryptographic key pairs, (D, d) and (P, p), it should be appreciated that they asymmetric cryptographic key pair, (C,c), and corresponding public/private keys may vary by type depending on the particular embodiment. In some embodiments, it should be appreciated that the asymmetric cryptographic key pair, (C, c), may be a similar type of key pair as the asymmetric cryptographic key pair, (D, d) , and/or the asymmetric cryptographic key pair, (P, p), described above. For example, in the illustrative embodiment, the asymmetric cryptographic key pair, (C,c), is generated based on elliptical curve cryptography (ECC) based on the EC P256 curve. In other embodiments, the asymmetric cryptographic key pair may be associated with another suitable ECC curve. Further, in other embodiments, the asymmetric cryptographic key pair, (C, c), may be associated with another cryptographic algorithm such as, for example, Digital Signature Standard (DSS), Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), ElGamal, and/or another asymmetric cryptographic algorithm. Similarly, the public/private key sizes may vary depending, for example, on the particular algorithm employed. In some embodiments, the asymmetric cryptographic key pair, (C,c), may be generated and stored on themobile device 114 in advance of the execution of themethod 2400 ofFIG. 24 . Further, it should be appreciated that themobile device 114 may generate the asymmetric cryptographic key pair, (C, c) , in a trusted execution environment (TEE) or secure enclave in some embodiments. - In
flow 2404, the mobile device 114 (e.g., using the mobile application) builds a credential request including the public key, C, of the cryptographic key pair (C, c) retrieved from a memory of themobile device 114. Further, in some embodiments, the credential request may identify the payload as a credential request (e.g., via a corresponding flag, CRED_REQ). As such, in some embodiments, the credential request may be represented as CRED_REQ∥C . Inflow 2406, themobile device 114 cryptographically signs the credential request using the private key, c, of the cryptographic key pair , (C, c) , retrieved from a memory of themobile device 114. In other words, themobile device 114 generates a cryptographic signature of the credential request. Inflow 2408, themobile device 114 transmits the signed credential request to the mobile access hub 112 (e.g., via a TLS connection). As such, in the illustrative embodiment, themobile device 114 transmits the credential request and the signature thereof to themobile access hub 112. In turn, inflow 2410, themobile access hub 112 forwards the signed credential request (e.g., the credential request and signature thereof) to thecredential management system 102. - In
flow 2412, thecredential management system 102 extracts the public key, C, from the credential request received from themobile device 114 via themobile access hub 112 and verifies the credential request signature using that public key. That is, thecredential management system 102 verifies that the credential request was signed using the private key that corresponds with the public key, C. It should be appreciated that thecredential management system 102 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). - In
flow 2414, thecredential management system 102 builds a credential request payload including the public key, C, extracted from the credential request received from themobile device 114 via themobile access hub 112, a facility code, a credential value of the credential, and a bit format of the credential. It should be appreciated that credential value and the bit format are of the credential requested and assigned to the mobile number of themobile device 114. Further, in some embodiments, the facility code may be associated with the site and/or organization that owns or administers theedge system 116. Inflow 2416, thecredential management system 102 transmits the credential request payload to thekey management system 108. - In
flow 2418 ofFIG. 25 , thekey management system 108 determines the credential to be transmitted to themobile device 114 and builds a credential blob based on the credential request payload (e.g., based on the facility code, credential value, bit format, etc.). In particular, in the illustrative embodiment, thekey management system 108 builds a credential blob including the credential to be transmitted to the mobile device 114 (e.g., the credential assigned to the mobile number and the user) and the public key, C. Further, in some embodiments, the credential blob may further include a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the credential blob may be represented as nonce∥C∥credential . Inflow 2420, thekey management system 108 encrypts the credential blob with the symmetric cryptographic key, K, and, inflow 2422, thekey management system 108 cryptographically signs the encrypted credential blob using the private key, d, of the cryptographic key pair, (D, d) , stored in the memory of thekey management system 108. In other words, thekey management system 108 generates a cryptographic signature of the encrypted credential blob. - In
flow 2424, thekey management system 108 transmits the encrypted credential blob (EK (nonce∥C∥credential)) and the signature thereof to thecredential management system 102. Inflow 2426, thecredential management system 102 records the use of the credential. For example, in some embodiments, thecredential management system 102 may reduce the number of credits available to theadministrative system 110 for issuance of new credentials. Further, thecredential management system 102 may also track the use of the public cryptographic key, C, and/or various credential data (e.g., the credential value used). As indicated above, in some embodiments, one or more of those functions of thecredential management system 102 may be performed in conjunction with thecredential tracking system 104 and/or thecredential ordering system 106. - In
flow 2428, thecredential management system 102 transmits/forwards the encrypted credential blob (EK (nonce∥C∥credential)) and the signature thereof to themobile access hub 112. Inflow 2430, themobile access hub 112 may incorporate one or more types of metadata into the payload prior to transmittal to themobile device 114. For example, in some embodiments, the metadata may include one or more mobile access instructions, a list ofedge devices 118 and/orlock devices 132 that the credential has access to, an expiration date of the payload, and/or other relevant metadata. It should be appreciated that, in some embodiments, the metadata is added to the signed and encrypted credential blob in the clear. Further, in some embodiments, a keyed hash or other integrity-verifying data may be included with the metadata to confirm that the metadata has not been modified. - In
flow 2432, themobile access hub 112 transmits the signed and encrypted credential blob to themobile device 114 along with any metadata. That is, in the illustrative embodiment, themobile access hub 112 transmits the encrypted credential blob (EK (nonce∥C∥credential)) and the signature thereof to themobile device 114. Inflow 2434, the mobile device 1434 further encrypts the encrypted credential blob with the public cryptographic key, P, using a corresponding asymmetric encryption algorithm. It should be appreciated that, in some embodiments, the further encrypted credential blob may be represented as E p (EK (nonce∥C∥credential)) . Inflow 2436, themobile device 114 stores the further encrypted credential blob (EP (EK (nonce∥C∥credential))), the signature of the encrypted credential blob (EK (nonce∥C∥credential)), and the metadata (if any) to the memory of themobile device 114. In other embodiments, it should be appreciated that the signature of the encrypted credential blob may be combined (e.g., concatenated) with the encrypted credential blob prior to asymmetric encryption by the public cryptographic key, P. In such embodiments, the payload may be represented as E p (EK (nonce∥C∥credential)∥dSig) . As such, in the illustrative embodiment, the credential blob or, more specifically, the encrypted credential blob (EK (nonce∥C∥credential)) is encrypted with the public cryptographic key, P, when the data is at rest on themobile device 114. It should be appreciated that, in the illustrative embodiment, themobile device 114 now has a credential stored thereon that is tied to themobile device 114, but themobile device 114 is unable to read the credential data due to the encryption. It should be appreciated that, in some embodiments, the memory of themobile device 114 to which such data is stored is a secure memory. As indicated above, in some embodiments, the metadata may be transmitted in the clear such that the metadata may be read by themobile device 114. - Although the flows 2402-2436 are described in a relatively serial manner, it should be appreciated that various flows of the
method 2400 may be performed in parallel in some embodiments. - Referring now to
FIG. 26 , in use, theaccess control system 100 may execute amethod 2600 for performing a key exchange between themobile device 114 and anedge control device 118 of theaccess control system 100. It should be appreciated that the particular flows of themethod 2600 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. Additionally, it should be appreciated that, in some embodiments, themethod 2600 may be executed in conjunction with themethod 2400 ofFIGS. 24-25 and/or themethod 2700 ofFIGS. 27-29 . For example, in some embodiments, themethod 2600 may be executed subsequent to themethod 2400 and prior to themethod 2700. In theillustrative method 2600, a session key, s, is generated based on Elliptical Curve Diffie-Hellman (ECDH). In other embodiments, however, it should be appreciated that the session key, s, may be generated based on a different key derivation function and/or other suitable algorithm in other embodiments. - The
illustrative method 2600 begins withflow 2602 ofFIG. 26 in which themobile device 114 and theedge device 118 or, more specifically, theBLE chipset 140 of theedge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4.2 or newer connection). In doing so, themobile device 114 and/or theBLE chipset 140 of theedge device 118 may execute various Bluetooth-defined functions including, for example, getDevice ( ), tryConnecting ( ), onSuccess, tryDiscovering ( ), and/or onServicesDiscovered ( ) functions. - In
flow 2604, themobile device 114 generates an ephemeral key pair, (C1,c1), including a public ephemeral key, C1 , and a private ephemeral key, c1. In the illustrative embodiment, the public and private ephemeral keys are ECDH ephemeral keys. However, in embodiments in which other secure key exchange and/or shared key derivation algorithms are employed, the keys may be formed accordingly. Inflow 2606, themobile device 114 transmits the public ephemeral key, C1, to theBLE chipset 140 of theedge device 118. Further, inflow 2608, theBLE chipset 140 forwards the public ephemeral key, C1, to themain chipset 142 of theedge device 118, which inflow 2610 forwards the public ephemeral key, C1, to thecryptography chipset 144 of theedge device 118. - In
flow 2612, thecryptography chipset 144 generates another ephemeral key pair (R, r) including a public ephemeral key, R, and a private ephemeral key, r. It should be appreciated that the ephemeral keys of the ephemeral key pair, (R, r), may be of the same type as the ephemeral key pair, (C1, c1) . As such, in the illustrative embodiment, the public and private ephemeral keys, R and r, are ECDH ephemeral keys. Inflow 2614, thecryptography chipset 144 generates a shared cryptographic session key, s, based on the public ephemeral key, C1, received from the mobile device 114 (e.g., via theBLE chipset 140 and themain chipset 142 of the edge device 118) and the private ephemeral key, r, newly generated by thecryptography chipset 144 of theedge device 118. For example, the shared cryptographic session key, s, may be generated based on generation of the corresponding portion of the ECDH algorithm. - In
flow 2616, thecryptography chipset 144 of theedge device 118 transmits the public ephemeral key, R, to themain chipset 142 of theedge device 118, which inflow 2618 forwards the public ephemeral key, R, to theBLE chipset 140 of theedge device 118. Inflow 2620, theBLE chipset 140 further transmits the public ephemeral key, R, to themobile device 114. Inflow 2622, themobile device 114 generates the shared cryptographic session key, s, based on the public ephemeral key, R, received from the edge device 118 (e.g., generated by thecryptography chipset 144 and transmitted via the BLE chipset 140) and the private ephemeral key, c1, generated by themobile device 114. - It should be appreciated that the
mobile device 114 and theedge device 118 are able to generate the same shared cryptographic session key, s, based on the corresponding public/private ephemeral keys described above (e.g., (C1,r) and (R, c1)). It should be further appreciated that the public cryptographic key, C, described herein may be used as the public ephemeral key, C1, for the generation of the shared cryptographic session key, s, in some embodiments. - Although the flows 2602-2622 are described in a relatively serial manner, it should be appreciated that various flows of the
method 2600 may be performed in parallel in some embodiments. - Referring now to
FIGS. 27-29 , in use, theaccess control system 100 may execute amethod 2700 for using a wireless access credential (e.g., a wireless access credential stored to themobile device 114 according to themethod 2400 ofFIGS. 24-25 ). It should be appreciated that the particular flows of themethod 2700 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. In some embodiments, themethod 2700 ofFIGS. 27-29 may be executed in conjunction with and subsequent to themethod 2400 ofFIGS. 24-25 and/or themethod 2600 ofFIG. 26 . - As shown, the
illustrative method 2700 involves themobile device 114 and anedge device 118 or, more specifically, theBLE chipset 140, themain chipset 142, and thecryptography chipset 144 of theedge device 118. Also, as described above in reference toFIGS. 22-26 , theillustrative method 2700 assumes that a cryptographic key exchange has occurred such that thekey management system 108 and theedge device 118 or, more specifically, themain chipset 142 of theedge device 118 share a symmetric cryptographic key, K. It should also be appreciated that theillustrative method 2700 further assumes that an asymmetric cryptographic key pair, (D,d), including a private cryptographic key, d, and a public cryptographic key, D, has been generated and stored to thekey management system 108, and that the public cryptographic key, D, has been stored to theedge device 118 or, more specifically, to thecryptography chipset 144 of theedge device 118 for use as described herein. Additionally, themobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c), including a private cryptographic key, c, and a public cryptographic key, C, and the asymmetric cryptographic key pair, (P, p), including the private cryptographic key, p, and the public cryptographic key, P, described above. Themethod 2700 further assumes that a secure key exchange has been performed (e.g., ECDH) such that each of themobile device 114 and the edge device 118 (or, more specifically, the cryptography chipset 144) has the shared cryptographic session key, s, as described above. For example, in some embodiments, themobile device 114 and theedge device 118 may execute a method similar to themethod 2600 ofFIG. 26 to perform the secure key exchange. Further, in embodiments involving themethod 2400 ofFIGS. 24-25 in conjunction with themethod 2700 ofFIGS. 27-29 , themobile device 114 also has stored thereon the double-encrypted credential blob (EP (EK (nonce∥C∥credential))), the signature of the encrypted credential blob (EK (nonce∥C∥credential)), and metadata (if any) after the execution of themethod 2400 ofFIGS. 24-25 as described above. - If not already established, in the illustrative embodiment, the
mobile device 114 and theedge device 118 or, more specifically, theBLE chipset 140 of theedge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4.2 or newer connection). In doing so, themobile device 114 and/or theBLE chipset 140 of theedge device 118 may execute various Bluetooth-defined functions including, for example, getDevice ( ), tryConnecting ( ), onSuccess, tryDiscovering ( ), and/or onServicesDiscovered ( ) functions. - The
illustrative method 2700 begins withflow 2702 ofFIG. 27 in which thecryptography chipset 144 of theedge device 118 transmits the shared cryptographic session key, s, generated in by the secure key exchange to themain chipset 142 of theedge device 118. Inflow 2704, themain chipset 142 of theedge device 118 encrypts challenge data with the shared cryptographic session key, s. In some embodiments, it should be appreciated that the challenge data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks. As such, in some embodiments, the encrypted challenge data may be represented as Es(challenge) . Inflow 2706, themain chipset 142 of theedge device 118 forwards the encrypted challenge data, Es(challenge), to theBLE chipset 140 of theedge device 118 and, inflow 2708, theBLE chipset 140 transmits the encrypted challenge data, E s(challenge), to themobile device 114 via the established Bluetooth communication connection. - In
flow 2710, themobile device 114 decrypts the encrypted challenge data using the shared cryptographic session key, s, retrieved from a memory of themobile device 114 and, inflow 2712, themobile device 114 decrypts the stored double-encrypted credential blob (EP (EK (nonce∥C∥credential))) using the private cryptographic key, p, retrieved from the memory of themobile device 114. Inflow 2714, the mobile device 114 (e.g., using the mobile application) builds a credential message including the challenge data received from theedge device 118 via theBLE chipset 140, the encrypted credential blob (EK (nonce∥C∥credential)) retrieved from the memory of themobile device 114, and the signature of the encrypted credential blob retrieved from the memory of themobile device 114. Inflow 2716, themobile device 114 encrypts the credential message with the shared cryptographic session key, s, and inflow 2718, themobile device 114 cryptographically signs the encrypted credential message using the private key, c, of the cryptographic key pair (C, c) retrieved from a memory of themobile device 114. In other words, themobile device 114 generates a cryptographic signature of the encrypted credential message. - In
flow 2720, themobile device 114 transmits the signed and encrypted credential message to theedge device 118 or, more specifically, to theBLE chipset 140 of theedge device 118. As such, in the illustrative embodiment, themobile device 114 transmits the encrypted credential message and the signature thereof to theBLE chipset 140 of theedge device 118. Inflow 2722, theBLE chipset 140 forwards the signed and encrypted credential message to themain chipset 142 of theedge device 118. Inflow 2724, themain chipset 142 of theedge device 118 decrypts the encrypted credential message using the shared cryptographic session key, s, retrieved from the memory of theedge device 118. - In
flow 2726, themain chipset 142 verifies the challenge data. For example, in embodiments in which the challenge data is a nonce, themain chipset 142 may confirm that the nonce is the same as the nonce previously encrypted and transmitted to the mobile device 114 (see, for example, flows 2704-2706 ofFIG. 27 ). In other embodiments, it should be appreciated that themain chipset 142 of theedge device 118 may otherwise verify and/or validate the decrypted challenge data. Inflow 2728, themain chipset 142 transmits the signature of the encrypted credential blob to thecryptography chipset 144 and, inflow 2730, thecryptography chipset 144 verifies the signature of the encrypted credential blob using the public cryptographic key, D, retrieved from the memory of theedge device 118. That is, thecryptography chipset 144 verifies that the encrypted credential blob was signed using the private key that corresponds with the public key, D. It should be appreciated that thecryptography chipset 144 of theedge device 118 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). Inflow 2732, thecryptography chipset 144 transmits the results of the verification to themain chipset 142. - In
flow 2734, themain chipset 142 of theedge device 118 decrypts the encrypted credential blob using the symmetric cryptographic key, K, retrieved from the memory of theedge device 118 and, inblock 2736, theedge device 118 extracts the credential and the public cryptographic key, C, from the decrypted credential blob. Further, themain chipset 142 may also extract the signature of the encrypted credential message. It should be appreciated that, in the illustrative embodiment, theedge device 118 and the key management system 108 (and/or other cloud servers 150) are capable of encrypting/decrypting the credential blob including the credential, whereas themobile device 114 is not. Instead, in such embodiments, themobile device 114 acts as a conduit for the secure transfer of the credential between thekey management system 108 and theedge device 118. - In
flow 2738, themain chipset 142 of theedge device 118 transmits the public cryptographic key, C, and the signature of the encrypted credential message extracted from the decrypted credential blob to thecryptography chipset 144 of theedge device 118. Inflow 2740, thecryptography chipset 144 of theedge device 118 verifies the signature of the encrypted credential message using the public cryptographic key, C, extracted from the decrypted credential blob. That is, thecryptography chipset 144 verifies that the encrypted credential message was signed using the private key that corresponds with the public key, C. It should be appreciated that thecryptography chipset 144 of theedge device 118 executes the appropriate asymmetric signature verification algorithm based on the type of the cryptographic key pair (e.g., ECC in the illustrative embodiment). It should be further appreciated that the use of the cryptographic key pair (C, c) serves, for example, to prevent the unauthorized copying of a credential to a differentmobile device 114 as described above in reference toFIGS. 15-17 . - In
flow 2742, thecryptography chipset 144 transmits the verification results to themain chipset 142 of theedge device 118. Inflow 2744, themain chipset 144 of theedge device 118 processes the credential extracted from the credential blob. It should be appreciated that the credential may be processed in a manner similar to that described in reference to flow 1234 ofFIG. 13 . As such, in some embodiments, theedge device 118 and/or other device(s) in theedge system 116 may make an access control decision based on the extracted credential and an access control database. Further, theedge device 118 itself or another device (e.g., theadministrative system 110, theaccess controller 134, etc.) may perform the access control decision based on the particular embodiment. Further, in some embodiments, in response to successful authentication of the credential, thelock device 132 may unlock a lock mechanism as described above. In some embodiments, it should be appreciated that further authentication of the user and/or themobile device 114 may be required in advance of, or in conjunction with, the processing of the credential. For example, in some embodiments, themethod 1800 ofFIG. 18 may be executed to process a PIN of the user. In other embodiments, the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, and/or additional information. It should be appreciated that, in some embodiments, the credential value and/or other portion of the credential may include an indicator that further authentication is required. - Although the flows 2702-2744 are described in a relatively serial manner, it should be appreciated that various flows of the
method 2700 may be performed in parallel in some embodiments. Further, it should be appreciated that, in other embodiments, one or more of the flows 2702-2744 identified as being performed by or associated with theBLE chipset 140, themain chipset 142, and/or thecryptography chipset 144 may be performed by or may be associated with another of theBLE chipset 140, themain chipset 142, and/or thecryptography chipset 144. - Referring now to
FIG. 32 , in use, theaccess control system 100 may execute amethod 3200 for revoking a wireless access credential. For example, among other reasons, an administrator may determine to revoke a wireless access credential when an employee departs or loses access privileges. It should be appreciated that the particular flows of themethod 3200 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. As shown, theillustrative method 3200 involves acredential management system 102, amobile access hub 112, and a mobile device 114 (e.g., executing a mobile application as described herein). Additionally, it should be appreciated that, in some embodiments, themethod 3200 may be executed in conjunction with and subsequent to themethod 2200 ofFIGS. 22-23 and themethod 2400 ofFIGS. 24-25 (e.g., subsequent to assignment, issuance, and storage of the credential to the mobile device 114). - The
illustrative method 3200 begins withflow 3202 in which thecredential management system 102 receives a credential revocation instruction from an administrator (e.g., via the administrative system 110) to revoke a particular credential, and thecredential management system 102 processes that instruction. For example, in some embodiments, thecredential management system 102 updates the relevant access control database(s) and/or other databases to reflect that the particular credential has been revoked and therefore is no longer valid. Depending on the particular embodiment, the revoked credential may be deleted, corrupted, tagged, and/or otherwise modified to be identified as a revoked/invalid credential. In other embodiments, it should be appreciated that the access control database(s) and/or other databases may be updated by themobile access hub 112. - In
flow 3204, thecredential management system 102 transmits the credential revocation instruction to themobile access hub 112. It should be appreciated that, in some embodiments, one or more unique identifiers of the credential may be transmitted in the credential revocation instruction payload. Inflow 3206, themobile access hub 112 transmits a notification (e.g., a push notification) to themobile device 114 indicating that the credential has been revoked and, inflow 3208, themobile device 114 launches the mobile application (e.g., automatically or in response to the user's input after reviewing the notification). - In
flow 3210, themobile device 114 builds a payload including a timestamp (e.g., generated from a real-time clock of the mobile device 114) and the mobile number of themobile device 114. Inflow 3212, themobile device 114 cryptographically signs the payloads using the private key, p, of the cryptographic key pair, (P, p), described above and retrieved from the memory of themobile device 114. In other words, themobile device 114 generates a cryptographic signature of the payload built inflow 3210. Inflow 3214, themobile device 114 transmits the signed payload to the mobile access hub 112 (e.g., via a TLS connection). In other words, in the illustrative embodiment, themobile device 114 transmits the payload and the signature thereof to themobile access hub 112. As indicated above, in some embodiments, the payload may be utilized by themobile access hub 112 as login credentials for themobile device 114. - In
flow 3216, themobile device 114 transmits a request to themobile access hub 112 for the credential access rights of themobile device 114. Inflow 3218, themobile access hub 112 determines the credential access rights of themobile device 114. For example, in some embodiments, themobile access hub 112 may read the data stored in the access control database(s) and/or other relevant databases to determine the current access rights (e.g., as updated following the revocation). Further, in some embodiments, themobile access hub 112 may communicate with thecredential management system 102 to make such a determination. Inflow 3220, themobile access hub 112 transmits a payload identifying the credential access rights of themobile device 114 to the mobile device and, inflow 3222, themobile device 114 updates the memory of themobile device 114 to update the credentials stored thereon. For example, in an embodiment in which the mobile number has two credentials and the first credential is revoked, it should be appreciated that the memory of themobile device 114 is updated to identify only the second credential, thereby reflecting that the first credential is no longer valid. - Although the flows 3202-3222 are described in a relatively serial manner, it should be appreciated that various flows of the
method 3200 may be performed in parallel in some embodiments. - It should be appreciated that, in some embodiments, access credentials may expire after a certain period of time. For example, in some embodiments, the mobile application of the
mobile device 114 may be required to check in every 48 hours to ensure the credential is still valid. Further, in some embodiments, the time after which the credential expires on themobile device 114 may be configuration by the site administrator (e.g., via the administrative system 110). It should be further appreciated that, although omitted in part for brevity of the description, themethod 3200 may involve one or more of the cryptographic functions described above. - Referring now to
FIG. 34 , the illustrativeaccess control system 3400 includes aperipheral controller 3402, amanagement server 3404, one ormore cloud servers 3406, amobile device 3408, amobile device 3410, agateway device 3412, acredential enrollment reader 3414, an RS-485reader 3416, aWiegand reader 3418, and acredential 3420. It should be appreciated that, in some embodiments, theaccess control system 3400 may “overlap” with theaccess control system 100 ofFIG. 1 . As such, in some embodiments, theaccess control systems access control system 3400 includes one or more of the devices/systems of theaccess control system 100. Further, as described herein, in some embodiments, themobile access hub 112 of theaccess control system 100 may be configured to interface with theaccess control system 3400 or, more specifically, themanagement server 3404 and/or the cloud server(s) 3406 of the access control system 3400 (e.g., serving as a virtual router) in order to exchange data (e.g., for the control or management of devices in the access control system 100). In some embodiments, theaccess control system 3400 and the cloud server(s) 3406 thereof may be embodied as a Schlage® ENGAGE™ system and/or the Schlage® ENGAGE™ cloud, respectively. As such, in some embodiments, theperipheral controller 3402 may be embodied as an ENGAGETM enabled controller such as, for example, the CTE Single Door Controller with Multi-Technology Reader available from Schlage. - It should be appreciated that the
access control system 3400 may control access to a passageway (e.g., through a doorway) to grant or deny user access through the passageway based on thecredential 3420 presented by the user. In particular, theperipheral controller 3402 may be electrically and/or communicatively coupled to acredential reader credential reader 3416, 3418 (e.g., based on an access control database that defines access permissions for various users/credentials). Further, theperipheral controller 3402 may be electrically and/or communicatively coupled to an electronic lock, door strike, door latch, and/or other suitable lock mechanism configured to lock/unlock the corresponding passageway barrier (e.g., door/gate) such that theperipheral controller 3402 may instruct or signal (e.g., via a relay) the lock mechanism to permit/deny access through the barrier based on the access control decision. It should be appreciated that theperipheral controller 3402 is “peripheral” in the sense that it is not integrated with an electronic lock. That is, in the illustrative embodiment, theperipheral controller 3402 is not mounted on the door/barrier. - The
peripheral controller 3402 may be configured to communicate with themanagement server 3404, the cloud server(s) 3406, themobile device 3408, themobile device 3410, thegateway device 3412, the RS-485reader 3416, and/or theWiegand reader 3418 using various communication connections. In particular, in some embodiments, theperipheral controller 3402 may communicate with themanagement server 3404 and/or the cloud server(s) 3406 over a Wi-Fi connection or via an Ethernet connection to exchange firmware updates, audits, an access control database or updates thereto, an access control schedule, usage information, and/or other suitable data. In some embodiments, theperipheral controller 3402 may communicate with the mobile device 3408 (e.g., via a mobile application) over a Bluetooth connection (e.g., BLE) and/or Wi-Fi connection. For example, theperipheral controller 3402 may communicate with themobile device 3408 over a BLE connection to exchange data with a relatively small file size (e.g., configuration data) and over a Wi-Fi connection to exchange data with a relatively large file size (e.g., firmware updates, an access control database or updates thereto, audits, and/or usage information). Similarly, in some embodiments, theperipheral controller 3402 may communicate with the mobile device 3410 (e.g., via a mobile application of an OEM) over a Bluetooth connection (e.g., BLE) and/or Wi-Fi connection. For example, theperipheral controller 3402 may communicate with themobile device 3410 over a Wi-Fi connection to exchange firmware data and/or over a BLE connection to exchange configuration data, server commands (e.g., from the management server 3404), audits, and/or an access control database or updates thereto. In some embodiments, theperipheral controller 3402 may communicate with thegateway device 3412 over a Bluetooth (e.g., BLE) connection to exchange credential information, real-time data, and/or firmware updates. Further, theperipheral controller 3402 may communicate with thegateway device 3412 over an Ethernet connection between theperipheral controller 3402 and thegateway device 3412. Additionally, in some embodiments, theperipheral controller 3402 may communicate directly with themanagement server 3404 via IP (e.g., using JSON), thereby enabling a direct to host communication connection. - Further, it should be appreciated that the
peripheral controller 3402 may be communicatively coupled to one or more readers. More specifically, in some embodiments, theperipheral controller 3402 may be communicatively coupled to an RS-485reader 3416 via an RS-485 link (e.g., a serial communication link) and/or aWiegand reader 3418 via corresponding Wiegand and control lines. Although theperipheral controller 3402 is described herein as only being communicatively coupled to thereaders peripheral controller 3402 may, additionally or alternatively, be structured and configured to be communicatively coupled to one or more other types of credential readers in other embodiments. - As described above, the
management server 3404 may be configured to communicate directly with the peripheral controller 3402 (e.g., via a Wi-Fi or Ethernet connection). Further, in some embodiments, themanagement server 3404 may be configured to communicate with the gateway device 3412 (e.g., via IP using JSON) and with the mobile device 3410 (e.g., via Wi-Fi, CDMA, LTE, and/or GSM) to exchange firmware/updates, audits, an access control database or updates thereto, an access control schedule, and or usage information. In other words, in such embodiments, theperipheral controller 3402 may communicate with themanagement server 3404 via themobile device 3410 and/or thegateway device 3412. For example, theperipheral controller 3402 may communicate with thegateway device 3412 via a BLE or Ethernet connection, and thegateway device 3412 may, in turn, forward the communicated data to themanagement server 3404 via IP. Similarly, themanagement server 3404 may communicate data to thegateway device 3412 and/ormobile device 3410, which is forwarded to theperipheral controller 3402 via a suitable communication connection. As such, it should be appreciated that theperipheral controller 3402 may communicate with themanagement server 3404 via an online mode with a persistent real-time communication connection or via an offline mode (e.g., periodically or in response to an appropriate condition) depending on the particular embodiment. In some embodiments, thegateway device 3412 may be embodied as a hot spot device/reader and/or plug-in device. - In some embodiments, the
management server 3404 may be configured to manage credentials of theaccess control system 3400. For example, themanagement server 3404 may be responsible for ensuring that theperipheral device 3402 has updated authorized credentials, whitelists, blacklists, device parameters, and/or other suitable data. Similarly, in some embodiments, themanagement server 3404 may be responsible for registering credentials with theaccess control system 3400 and/or distributing appropriate credentials for authorized access through the passageway controlled by theperipheral controller 3402. Additionally, as described herein, themanagement server 3404 may receive security data, audit data, raw sensor data, and/or other suitable data from the peripheral controller 3402 (e.g., directly or indirectly) for management of theaccess control system 3400. In some embodiments, themanagement server 3404 may be communicatively coupled with the cloud server(s) 3406 and/or a cloud-based application. In other embodiments, themanagement server 3404 may be embodied as an online server or a cloud-based server. - Further, in some embodiments, the
management server 3404 may communicate with multipleperipheral controllers 3402 at a single site (e.g., a particular building) and/or across multiple sites. That is, in such embodiments, themanagement server 3404 may be configured to receive data fromperipheral controllers 3402 distributed across a single building, multiple buildings on a single campus, or across multiple locations. In some embodiments, the cloud server(s) 3406 may be embodied as a cloud-based device or collection of devices within a cloud environment. In such embodiments, it should be appreciated that the server(s) 3406 may be embodied as a “serverless” or server-ambiguous computing solution, for example, similar to the cloud server(s) 150 ofFIG. 1 described above. - The
credential enrollment reader 3414 may be embodied as any credential enrollment reader configured to enroll credentials (e.g., no-tour credentials via RFID). For example, in some embodiments, thecredential enrollment reader 3414 may be embodied as a multi-technology enrollment reader such as the Schlage® (formerly aptiQ®) MT20W credential enrollment reader available from Schlage. In some embodiments, thecredential 3420 may be embodied as a MIFARE® Classic or MIFARE DESFire™ EV1 smart credential. It should be appreciated that thecredential enrollment reader 3414 may receive “no tour” credential enrollment data from themanagement server 3404 directly or indirectly. For example, in some embodiments, thecredential enrollment reader 3414 may receive the credential enrollment data directly from themanagement server 3404 via a Wi-Fi connection or indirectly from the cloud server(s) 3406 via a Wi-Fi connection. In another embodiment, thecredential enrollment reader 3414 may receive the credential enrollment data from themobile device 3408 which, in turn, may have received the credential enrollment data from the cloud server(s) 3406 or themanagement server 3404. As such, it should be appreciated that themobile device 3408 may be configured to communicate with the cloud server(s) 3406 via a Wi-Fi, CDMA, LTE, and/or GSM connection to exchange data for commissioning theperipheral controller 3402 or an electronic lock, firmware and/or firmware updates, audits, an access control database or updates thereto, usage information, credential enrollment data, and/or other relevant data. Additionally, themobile device 3408 may be configured to communicate with thecredential enrollment reader 3414 via a Bluetooth connection (e.g., BLE) and/or NFC to exchange the credential enrollment data. In some embodiments, the RS-485reader 3416 and/or theWeigand reader 3418 may be embodied as a Schlage® (formerly aptiQ®) MT11 multi-technology mullion reader or a Schlage® (formerly aptiQ®) MTK15 multi-technology single-gang keypad reader available from Schlage. - It should be appreciated that, in some embodiments, the
credential enrollment reader 3414 may store “no tour” credential enrollment data on thecredential 3420 such that thereader credential 3420 is presented to thereader reader peripheral controller 3402, and theperipheral controller 3402 may update the access control database stored thereon to permit access by thecredential 3420 through a passageway controlled by theperipheral controller 3402. Further, in some embodiments, theperipheral controller 3402 may simultaneously remove access permissions for anothercredential 3420 based on the credential enrollment data. As such, upon subsequent presentation of the newly enrolledcredential 3420 to thereader peripheral controller 3402 will permit access; however, upon subsequent presentation of the other credential 3420 (e.g., the old credential), theperipheral controller 3402 will deny access. In some embodiments, theperipheral controller 3402 may update a flag, field, bit, byte, or other data structure stored on the “no tour”credential 3420 to indicate that the access control database has been updated. As such, in some embodiments, theperipheral controller 3402 may first analyze that data structure of the “no tour”credential 3420 to determine whether updating the access control database is required. If not, theperipheral controller 3402 may treat thecredential 3420 as an ordinary credential and determine whether access is to be granted or denied. - Referring now to
FIG. 35 , the illustrativeaccess control system 3500 includes anelectronic lock 3502, amanagement server 3504, one ormore cloud servers 3506, amobile device 3508, a mobile device 3510, agateway device 3512, acredential enrollment reader 3514, and acredential 3520. It should be appreciated that, in some embodiments, themanagement server 3504, the one ormore cloud servers 3506, themobile device 3508, the mobile device 3510, thegateway device 3512, thecredential enrollment reader 3514, and/or thecredential 3520 may be the same device(s) as, or similar to, themanagement server 3404, the one ormore cloud servers 3406, themobile device 3408, themobile device 3410, thegateway device 3412, thecredential enrollment reader 3414, and thecredential 3420 and, therefore, the descriptions of those devices have not been repeated herein for brevity of the disclosure. The illustrativeaccess control system 3500 is similar in functionality to theaccess control system 3400, however, theperipheral controller 3402 has been replaced with theelectronic lock 3502. Unlike theperipheral controller 3402, the controller of theelectronic lock 3502 is integrated with theelectronic lock 3502 and, therefore, not “peripheral” in that sense. In some embodiments, theaccess control system 3500 and the cloud server(s) 3506 thereof may be embodied as a Schlage® ENGAGE™ system and/or the Schlage® ENGAGE™ cloud, respectively. As such, in some embodiments, theelectronic lock 3502 may be embodied as an ENGAGE™ enabled lock. - It should be further appreciated that, in some embodiments, the
access control system 3500 may “overlap” with theaccess control system 100 ofFIG. 1 . As such, in some embodiments, theaccess control systems access control system 3500 includes one or more of the devices/systems of theaccess control system 100. Further, as described herein, in some embodiments, themobile access hub 112 of theaccess control system 100 may be configured to interface with theaccess control system 3500 or, more specifically, themanagement server 3504 and/or the cloud server(s) 3506 of the access control system 3500 (e.g., serving as a virtual router) in order to exchange data (e.g., for the control or management of devices in the access control system 100). - It should be appreciated that, depending on the particular embodiment, an
offline edge device 118 can update a local access control database on the edge device 118 (or other device of the edge system 116) using various techniques. For example, in some embodiments, theoffline edge device 118 may establish a wireless communication connection (e.g., via Wi-Fi) with thecloud server 150 to retrieve access control updates periodically (e.g., daily). In other embodiment, a system administrator may visit or “tour” theedge device 118 to initiate an access control update locally at the edge device 118 (e.g., via a wired or wireless connection between theedge device 118 and themobile device 114 of the administrator). In yet another embodiment, thesystem 100 may transmit “no tour” data to themobile device 114 of a user having access to theedge device 118 for transmission to thatedge device 118. It should be appreciated that such a technique typically eliminates any need for a system administrator to visit theedge device 118 to make updates and also allows for updates to edgedevices 118 that have no connectivity (e.g., no Wi-Fi connections or long-range wireless connections available). Such no tour implementations are described herein in reference to at leastFIGS. 36-40 . - Referring now to
FIGS. 36-37 , simplified block diagrams illustrating various embodiments of no tour implementations of an access control system are shown. More specifically,FIGS. 36-37 illustrate communications between subsets of the various devices/systems of an access control device. In other words, communication capabilities and use cases ofsubsystems - For example, referring now specifically to
FIG. 36 , thesubsystem 3600 includes one ormore cloud servers enrollment reader physical credential edge device FIG. 36 , thecloud servers enrollment reader enrollment reader physical credential physical credential edge device edge device physical credential edge device edge device physical credential subsystem 3600 may be encrypted by a site key and further encrypted by a “smart key.” As such, the payload may be represented as Esmartkey(Esitekey(no_tour_data)) . It should be appreciated that, in some embodiments, the site key is a symmetric cryptographic key for encrypting the no tour data (e.g., used by the ENGAGE™ system), and the smart key may be embodied as a key configured to encrypt sectors of thephysical credential 3420. - Referring now to
FIG. 37 , thesubsystem 3700 includes akey management system 108, amobile access hub 112, amobile device 114, anedge device 118, and anaccess control system FIG. 37 , themobile access hub 112 serves the role of theenrollment reader FIG. 36 and the mobile device 114 (or, more specifically, the mobile application) serves the role of thephysical credential FIG. 36 . In the illustrative embodiment, thekey management system 108 is configured to provide a signature of the encrypted payload (e.g., the no tour data) to be delivered to themobile device 114 using one or more of the communication methods described above for transmittal of a credential. In some embodiments, it should be appreciated that thekey management system 108 may be embodied as thecredential management system 102, or thecredential management system 102 may perform one or more functions of thekey management system 108. In some embodiments, the no tour data of thesubsystem 3500 is secured by a credential key and signed by the cloud server 150 (as described above), so theedge device 118 is able to trust the data source. Further, the public key of themobile device 114 ensures that data cannot be copied/moved to another device as described above, and the salt/nonce further randomizes the data. Sector data may also be transmitted to represent the data that would be provided by the reader with no tour data being in different sectors of thecredential - Referring now to
FIG. 38 , in use, theaccess control system 100 may execute amethod 3800 for delivering no tour data and/or other access control data. It should be appreciated that the particular flows of themethod 3800 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. As shown, theillustrative method 3800 involves amobile device 114 and anedge device 118. In some embodiments, themethod 3800 may be executed in conjunction with one or more of the various methods described above. As such, various details may be omitted herein for brevity of the description. For example, theillustrative method 3800 assumes that themobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c) , including a private cryptographic key, c, and a public cryptographic key, C, described above. - The
illustrative method 3800 begins withflow 3802 in which themobile device 114 and theedge device 118 establish a Bluetooth communication session/connection with one another (e.g., a BLE 4.2 or newer connection) and perform a secure key exchange to generate a shared cryptographic session key, s, separately at each of themobile device 114 and theedge device 118. As described above, the session key, s, may generated based on Elliptical Curve Diffie-Hellman (ECDH). More specifically, in some embodiments, themobile device 114 and theedge device 118 may execute a method similar to themethod 2600 ofFIG. 26 to perform the secure key exchange. However, it should be appreciated that the session key, s, may be generated based on a different key derivation function and/or other suitable algorithm in other embodiments. Following the execution of the secure key exchange, each of themobile device 114 and theedge device 118 has the same session key, s, stored thereon. - In
flow 3804, theedge device 118 encrypts challenge data with the shared cryptographic session key, s. In some embodiments, it should be appreciated that the challenge data may be embodied as, or otherwise include, a nonce value, for example, to reduce the efficacy of replay attacks. Additionally, in some embodiments, the encrypted data may also include the message size and/or other relevant data. As such, in some embodiments, the encrypted challenge data may be represented as Es(challenge∥size) . Inflow 3806, theedge device 118 transmits the encrypted challenge data, Es(challenge∥size) , to themobile device 114 via the established Bluetooth communication connection. - In
flow 3808, themobile device 114 decrypts the encrypted challenge data using the shared cryptographic session key, s, retrieved from a memory of themobile device 114. Inflow 3810, the mobile device 114 (e.g., using the mobile application) builds a no tour payload including the no tour data (e.g., which may itself be encrypted), the challenge data received from theedge device 118, and the public cryptographic key, C, and themobile device 114 encrypts that no tour payload with the shared cryptographic session key, s. In flow 2812, themobile device 114 cryptographically signs the encrypted no tour payload using the private key, c, of the cryptographic key pair (C, c) retrieved from a memory of themobile device 114. In other words, themobile device 114 generates a cryptographic signature of the encrypted no tour payload. - In
flow 3814, themobile device 114 transmits the signed and encrypted no tour payload to theedge device 118. As such, in the illustrative embodiment, themobile device 114 transmits the encrypted no tour payload and the signature thereof to theedge device 118. Inflow 3816, theedge device 118 decrypts the encrypted no tour message using the shared cryptographic session key, s, retrieved from the memory of theedge device 118 and verifies the cryptographic signature using the public cryptographic key, C, extracted from the payload in a manner similar to that described above. - In
flow 3818, theedge device 118 processes the no tour payload. For example, as described above, the edge device 118 (e.g., an offline access control device) may update its local access control database and/or perform other updates to theedge device 118 or data stored thereon based on the corresponding content of the no tour data. For example, in some embodiments, the no tour data may include access control updates for mobile devices and/or physical credentials different from themobile device 114 that transmitted the no tour data. Inflow 3820, theedge device 118 generates feedback data based on the processing of the no tour payload and, inflow 3822, theedge device 118 transmits the feedback data to themobile device 114. Inflow 3824, themobile device 114 processes the feedback data and, if successful, themobile device 114 removes the no tour payload stored thereon. In some embodiments, it should be appreciated that theedge device 118 only transmits feedback data if the processing of the no tour data was successful. - Although the flows 3802-3824 are described in a relatively serial manner, it should be appreciated that various flows of the
method 3800 may be performed in parallel in some embodiments. - Referring now to
FIG. 39 , in use, theaccess control system 100 may execute amethod 3900 for delivering no tour data and/or other access control data. It should be appreciated that the particular flows of themethod 3900 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. As shown, theillustrative method 3900 involves acloud server 150, amobile device 114, and anedge device 118. In some embodiments, themethod 3900 may be executed in conjunction with one or more of the various methods described above. As such, various details may be omitted herein for brevity of the description. For example, in some embodiments, theillustrative method 3900 assumes that themobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c), including a private cryptographic key, c, and a public cryptographic key, C, described above. Additionally, as described above, although thecloud server 150 is referenced herein as a cloud-based device, it should be appreciated that thecloud server 150 may be embodied as one or more computing devices situated outside of a cloud computing environment in some embodiments. In some embodiments, thecloud server 150 ofFIG. 39 may be embodied as a system that includes one or more of thecredential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, and/or themobile access hub 112 described in reference toFIG. 1 . - The
illustrative method 3900 begins withflow 3902 in which thecloud server 150 updates access control data associated with one ormore edge devices 118. For example, the access control data may be updated in response to the addition, deletion, and/or modification of access permissions for a particular user and/ormobile device 114 of the system 100 (e.g., by a system administrator or other suitable input/stimulus). In particular, in some embodiments, the access control data update may update the access permissions associated with a particular user and/or credential including, for example, theedge devices 118 to which the user and/or credential has access (e.g., among other edge devices 118), an access authorization schedule identifying the time(s) at which such access is permission, an access initiation time indicating a first time at which access is authorized, an expiration time indicating a time after which access is unauthorized, and/or other access-related information depending on the particular embodiment. Further, in some embodiments, the access control data may include configuration data for one or more devices of theedge system 116, firmware/software updates for one or more devices of theedge system 116, audit data, usage information, and/or other relevant access control data. - In
flow 3904, themobile device 114 transmits (e.g., securely) its credential to theedge device 118. For example, in some embodiments, themobile device 114 and theedge device 118 may establish a Bluetooth communication session/connection (e.g., a BLE 4.2 or new connection) consistent with the techniques described above. Inflow 3906, theedge device 118 processes the credential in an attempt to authenticate the credential. For example, in some embodiments, theedge device 118 and/or other device(s) in theedge system 116 may make an access control decision based on the extracted credential and an access control database (e.g., stored locally) to determine whether the credential authorizes the user/bearer to perform a requested action (e.g., gain access). Further, in some embodiments, in response to successful authentication of the credential, theedge device 118 may unlock a lock mechanism as described above. In some embodiments, it should be appreciated that further authentication of the user and/or themobile device 114 may be required in advance of, or in conjunction with, the processing of the credential. For example, in some embodiments, the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, PIN entry, and/or additional information. - If the authentication of the credential is unsuccessful (e.g., in response to a determination that the credential/user is not authorized to gain access), in
flow 3908, theedge device 118 generates and transmits a message to themobile device 114 indicating that access has been denied, which themobile device 114 transmits to thecloud server 150 inflow 3910. Depending on the particular embodiment, themobile device 114 may simply forward the access denied message received from theedge device 118 and/or generate a new message that is indicative of the access denial for transmission to thecloud server 150. In some embodiments, it should be appreciated that themobile device 114 may establish a wireless communication connection (e.g., a Wi-Fi communication connection, cellular communication connection, telecommunication connection, and/or other suitable long range wireless communication connection) with thecloud server 114 in order to transmit the access denial message. - In flow 3912 (e.g., in response to the access denial), the
cloud server 150 and theedge device 118 establish a secure communication connection/channel via themobile device 114. For example, in some embodiments, themobile device 114 serves as a secure tunnel and intermediary node between thecloud server 150 and theedge device 118. In some embodiments, it should be appreciated that the establishment of the secure communication channel between thecloud server 150 and theedge device 118 via themobile device 114 may be done in conjunction with the transmittal of the access denial message from themobile device 114 to thecloud server 150. - In
flow 3914, thecloud server 150 transmits one or more of the updates to the access control data associated with theedge device 118 to theedge device 118 via the secure communication channel between thecloud server 150 and the edge device 118 (i.e., via the mobile device 114). It should be appreciated that the particular access control data transmitted from thecloud server 150 to theedge device 118 may vary depending on the particular embodiment. For example, in some embodiments, thecloud server 150 may transmit all of the updated access rights associated with theedge device 118, whereas in other embodiments, thecloud server 150 may transmit only those updated access rights associated with specific users/credentials (e.g., of the mobile device 114) to theedge device 118. In yet other embodiments, thecloud server 150 may securely transmit some other subset of updated access rights to theedge device 118. Further, it should be appreciated that thecloud server 150 may also transmit configuration data, firmware/software updates, and/or other relevant access control data to theedge device 118. In some embodiments, it should be appreciated that the access control data transmitted from thecloud server 150 to theedge device 118 via the secure communication channel is in an encrypted format and/or otherwise inaccessible to the intermediarymobile device 114. - In
flow 3916, theedge device 118 updates the access control database of theedge system 116 based on the updates received from thecloud server 150. Further, in some embodiments, theedge system 116 may perform (or schedule to perform) a firmware/software update, re-configuration, and/or other action dictated by a relevant update. - In
flow 3918, themobile device 114 re-transmits (e.g., securely) its credential to theedge device 118. Depending on the particular embodiment, themobile device 114 may leverage an existing communication connection (e.g., a Bluetooth communication connection) with theedge device 118 or establish a new communication connection/session with theedge device 118 to do so. Inflow 3920, theedge device 118 again processes the credential in an attempt to authenticate the credential. In some embodiments, rather than processing the credential of themobile device 114 having been re-transmitted to theedge device 118, it should be appreciated that theedge device 118 may temporarily store the denied credential for the subsequent authentication attempt following the update to the access control database. - In
flow 3922, theedge device 118 generates and transmits an access control decision message to themobile device 114 indicating whether the credential was successfully authenticated (e.g., and access was gained). Specifically, in some embodiments, the message may indicate whether access was granted or denied. Further, in response to successful authentication of the credential, it should be appreciated that theedge device 116 may unlock a lock mechanism as described above. Further, as described above, in some embodiments, it should be appreciated that further authentication of the user and/or themobile device 114 may be required in advance of, or in conjunction with, the processing of the credential. - Additionally, in some embodiments, the
edge device 118 may transmit an update confirmation message to themobile device 114 indicative of whether the update to the access control database of theedge system 116 was successful and/or unsuccessful, which may be transmitted/forwarded to thecloud server 150 inflow 3924. In other embodiments, theedge device 118 may only transmit the update confirmation message to the mobile device 114 (and/or themobile device 114 may only transmit/forward the update confirmation message to the cloud server 150) if the update to the access control database of theedge system 116 was successful. In yet other embodiments, theedge device 118 may only transmit the update confirmation message to the mobile device 114 (and/or themobile device 114 may only transmit/forward the update confirmation message to the cloud server 150) if the update to the access control database of theedge system 116 was unsuccessful. In other embodiments, it should be appreciated that theedge device 118 provides no indication of the success of the update to the access control database of theedge system 116 to the mobile device 114 (and/or themobile device 114 does not transmit/forward such indication to the cloud server 150) and, instead, thecloud server 150 assumes that the transmittal of the updated access control data via the secure communication channel between thecloud server 150 and theedge device 118 via the mobile device 114 (in flow 3914) has resulted in a successful update to the access control database of theedge system 116. - Although the flows 3902-3924 are described in a relatively serial manner, it should be appreciated that various flows of the
method 3900 may be performed in parallel in some embodiments. - Referring now to
FIG. 40 , in use, theaccess control system 100 may execute amethod 4000 for delivering no tour data and/or other access control data. It should be appreciated that the particular flows of themethod 4000 are illustrated by way of example, and such flows may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. As shown, theillustrative method 4000 involves acloud server 150, amobile device 114, and anedge device 118. In some embodiments, themethod 4000 may be executed in conjunction with one or more of the various methods described above. As such, various details may be omitted herein for brevity of the description. For example, in some embodiments, theillustrative method 4000 assumes that themobile device 114 has stored thereon the asymmetric cryptographic key pair, (C, c), including a private cryptographic key, c, and a public cryptographic key, C, described above. Additionally, as described above, although thecloud server 150 is referenced herein as a cloud-based device, it should be appreciated that thecloud server 150 may be embodied as one or more computing devices situated outside of a cloud computing environment in some embodiments. In some embodiments, thecloud server 150 ofFIG. 40 may be embodied as a system that includes one or more of thecredential management system 102, thecredential tracking system 104, thecredential ordering system 106, thekey management system 108, theadministrative system 110, and/or themobile access hub 112 described in reference toFIG. 1 . - The
illustrative method 4000 begins withflow 4002 in which thecloud server 150 updates access control data associated with one ormore edge devices 118. For example, similar to themethod 3900 ofFIG. 39 , the access control data may be updated in response to the addition, deletion, and/or modification of access permissions for a particular user and/ormobile device 114 of the system 100 (e.g., by a system administrator or other suitable input/stimulus). In particular, in some embodiments, the access control data update may update the access permissions associated with a particular user and/or credential including, for example, theedge devices 118 to which the user and/or credential has access (e.g., among other edge devices 118), an access authorization schedule identifying the time(s) at which such access is permission, an access initiation time indicating a first time at which access is authorized, an expiration time indicating a time after which access is unauthorized, and/or other access-related information depending on the particular embodiment. Further, in some embodiments, the access control data may include configuration data for one or more devices of theedge system 116, firmware/software updates for one or more devices of theedge system 116, audit data, usage information, and/or other relevant access control data. - In
flow 4004, themobile device 114 establishes a wireless communication connection (e.g., a Wi-Fi communication connection, cellular communication connection, telecommunication connection, and/or other suitable long range wireless communication connection) with the cloud server 114 (e.g., via the Internet) and receives one or more of the updates to the access control data from thecloud server 150. For example, in some embodiments, thecloud server 150 may determine (e.g., based on an access control database and/or relevant updates thereto) whichedge devices 118 to which the user/credential and, therefore, themobile device 114 is authorized to access, and thecloud server 150 may transmit the updated access control data associated with thoseedge devices 118 to themobile device 114. In some embodiments, thecloud server 150 may determine (e.g., based on historical data) whichedge devices 118 with which the mobile device has previously interacted and transmit the updated access control data associated with each of those edge devices 118 (e.g., on the premise that themobile device 114 is likely to again interact with such edge devices 118). It should be appreciated that thedevice mobile device 114 and thecloud server 150 may vary depending on the particular embodiment. - It should be appreciated that the particular access control data transmitted from the
cloud server 150 to themobile device 114 may vary depending on the particular embodiment. For example, in some embodiments, thecloud server 150 may transmit all of the updated access rights associated with eachedge device 118, whereas in other embodiments, thecloud server 150 may transmit only those updated access rights associated with specific users/credentials (e.g., of the mobile device 114) for eachedge device 118. In yet other embodiments, thecloud server 150 may securely transmit some other subset of updated access rights to themobile device 114. Further, it should be appreciated that thecloud server 150 may also transmit configuration data, firmware/software updates, and/or other relevant access control data to themobile device 114. In some embodiments, it should be appreciated that the access control data transmitted from thecloud server 150 to themobile device 114 is in an encrypted format and/or otherwise stored in memory of themobile device 114 in a format inaccessible to themobile device 114. - In
flow 4006, themobile device 114 scans (e.g., via Bluetooth) foredge devices 118 within communication range of themobile device 114 to determine whether themobile device 114 is within communication range of anedge device 118 for which themobile device 114 has received updated access control data. When themobile device 114 is within the relevant communication range (e.g., Bluetooth communication range) of such anedge device 118, inflow 4008, theedge device 118 transmits a response message to the Bluetooth scan message (e.g., beacon). Further, in some embodiments, themobile device 114 and theedge device 118 may establish a Bluetooth communication session/connection (e.g., a BLE 4.2 or new connection) consistent with the techniques described above. - In
flow 4010, themobile device 114 transmits one or more of the updates to the access control data associated with theedge device 118 to theedge device 118 via the secure communication connection between themobile device 114 and theedge device 118. It should be appreciated that the particular access control data transmitted from themobile device 114 to theedge device 118 may vary depending on the particular embodiment. For example, in the illustrative embodiment, themobile device 114 may transmit all of the updated access rights associated with theedge device 118 stored on themobile device 114, whereas in other embodiments, themobile device 114 may transmit only those updated access rights associated with specific users/credentials (e.g., of the mobile device 114) to theedge device 118. In yet other embodiments, themobile device 114 may securely transmit some other subset of updated access rights to theedge device 118. Further, as indicated above, it should be appreciated that themobile device 114 may also transmit configuration data, firmware/software updates, and/or other relevant access control data to theedge device 118. - In
flow 4012, theedge device 118 updates the access control database of theedge system 116 based on the updates received from themobile device 114. Further, in some embodiments, theedge system 116 may perform (or schedule to perform) a firmware/software update, re-configuration, and/or other action dictated by a relevant update. - In
flow 4014, themobile device 114 transmits (e.g., securely) its credential to theedge device 118. Depending on the particular embodiment, themobile device 114 may leverage an existing communication connection (e.g., a Bluetooth communication connection) with theedge device 118 or establish a new communication connection/session with theedge device 118 to do so. Further, it should be appreciated that, in some embodiments, themobile device 114 may transmit the updated access control data to theedge device 118 when themobile device 114 is a first distance from theedge device 118 and subsequently (e.g., after theedge device 118 has updated the access control database) transmit the credential to theedge device 118 when the mobile device is a second (nearer) distance from theedge device 118. Accordingly, it should be appreciated that, in some embodiments, themethod 4000 may be performed in conjunction with one or more of the user intent techniques described herein. - In
flow 4016, theedge device 118 processes the credential in an attempt to authenticate the credential. For example, in some embodiments, theedge device 118 and/or other device(s) in theedge system 116 may make an access control decision based on the extracted credential and an access control database (e.g., stored locally) to determine whether the credential authorizes the user/bearer to perform a requested action (e.g., gain access). Further, in some embodiments, in response to successful authentication of the credential, theedge device 118 may unlock a lock mechanism as described above. In some embodiments, it should be appreciated that further authentication of the user and/or themobile device 114 may be required in advance of, or in conjunction with, the processing of the credential. For example, in some embodiments, the user may be required to comply with a multi-factor authentication protocol requiring, for example, facial identification, thumb print, other biometrics, voice recognition, gestures, PIN entry, and/or additional information. - In
flow 4018, theedge device 118 generates and transmits an access control decision message to themobile device 114 indicating whether the credential was successfully authenticated (e.g., and access was gained). Specifically, in some embodiments, the message may indicate whether access was granted or denied. Additionally, in some embodiments, theedge device 118 may transmit an update confirmation message to themobile device 114 indicative of whether the update to the access control database of theedge system 116 was successful and/or unsuccessful, which may be transmitted/forwarded to thecloud server 150 inflow 4020. In other embodiments, theedge device 118 may only transmit the update confirmation message to the mobile device 114 (and/or themobile device 114 may only transmit/forward the update confirmation message to the cloud server 150) if the update to the access control database of theedge system 116 was successful. In yet other embodiments, theedge device 118 may only transmit the update confirmation message to the mobile device 114 (and/or themobile device 114 may only transmit/forward the update confirmation message to the cloud server 150) if the update to the access control database of theedge system 116 was unsuccessful. In other embodiments, it should be appreciated that theedge device 118 provides no indication of the success of the update to the access control database of theedge system 116 to the mobile device 114 (and/or themobile device 114 does not transmit/forward such indication to the cloud server 150) and, instead, thecloud server 150 assumes that the transmittal of the updated access control data to the mobile device 114 (in flow 4004) has resulted in a successful update to the access control database of theedge system 116. Further, in some embodiments, theedge device 118 may not generate or transmit any access control decision message to themobile device 114. - Although the flows 4002-4020 are described in a relatively serial manner, it should be appreciated that various flows of the
method 4000 may be performed in parallel in some embodiments. - Referring now to
FIG. 41 , a simplified block diagram of aprovisioning system 4100 for cryptographic key provisioning during the factory setup of anedge device 118 is shown. More specifically, in some embodiments, theprovisioning system 4100 may involve the provisioning and/or association of various cryptographic keys of thecryptography chipset 144 of theedge device 118. As shown inFIG. 41 , theprovisioning system 4100 includes theedge device 118, afactory tester machine 4102, afactory service 4104, and akey management service 4106. In some embodiments, thefactory tester machine 4102, thefactory service 4104, and/or thekey management service 4104 may be embodied as a device similar to thecomputing device 200 described in reference toFIG. 2 . Additionally, in some embodiments, thekey management service 4104 may be embodied as, or form a portion of, thekey management system 108 ofFIG. 1 . As shown inFIG. 33 , thechart 3300 describes various cryptographic keys that are involved in the provisioning depicted inFIG. 41 . - In the illustrative embodiment, when provisioning keys in the factory, the
edge device 118 generates a unique asymmetric cryptographic key pair (R1, rl) including the public cryptographic key, RI, and the private cryptographic key, rl. The public cryptographic key, RI, may be shared and stored in the key management service 3906 (e.g., the key management system 108) and may be used to generate a shared cryptographic session key, s or S, (e.g., via ECDH) which may be used to encrypt one or more cryptographic keys downloaded in the factory. Further, during the key download in the factor, the manufacturer origin public cryptographic keys, HI and H2, may be downloaded to theedge device 118. - More specifically, in some embodiments, an asymmetric cryptographic key pair (F, f) including the public cryptographic key, F, and the private cryptographic key, f, is associated with each product line (e.g., each type of edge device 118) such that the private key, f is stored to the
edge device 118 and the public key, F, is stored to thekey management service 4106. As shown inFIG. 41 , theedge device 118 cryptographically signs the public cryptographic key, RI, using the private cryptographic key, f and transmits both the public key, RI, and its signature (fSig) to thefactory tester machine 4102. Thefactory tester machine 4102 generates a serial number associated with theedge device 118, generates a provisioning request (e.g., including RI, fSig, the serial number, the model number of theedge device 118, and/or other relevant data), and transmits the provisioning request to thefactory service 4104, which in turn transmits the provisioning request to thekey management service 4106. Thekey management service 4106 may validate/verify the signature (fSig) of the public key (RI) based on the public key stored by thekey management service 4106, save the validated public key (RI) and process the provisioning request. - It should be appreciated that the
key management service 4106 may include a secure key vault having stored thereon various cryptographic keys including, for example, the cryptographic key pair (H1, hl) , the cryptographic key pair (H2, h2) , the cryptographic key pair (D,d) , the symmetric cryptographic key (K), the public cryptographic key (RI) after receiving the provisioning request, and/or the public cryptographic key (F), the significance and properties of each of which is described in thechart 3300 ofFIG. 33 . - The
key management service 4106 generates an ephemeral cryptographic key pair (Q, q) , which is generated on a per-provisioning-request basis and not saved, and generates a provisioning payload. Further, the shared cryptographic session key, S, may be generated based on the private ephemeral key (q) and the public key (RI). More specifically, in some embodiments, the shared cryptographic session key, S, may be generated according to ECDH(R1, q) =S . In some embodiments, the provisioning payload includes the public ephemeral key (Q) and other cryptographic keys including, for example, H1, H2, K, and D. In particular, in the illustrative embodiment, those cryptographic keys may be encrypted and signed according to E s(H1)h2Sig, E s(H2)h1 Sig, ES(K)[h1Sig,h2Sig], and Es (D) [h1Sig, h2Sig]. - The provisioning payload including such cryptographic keys is transmitted by the
key management service 4106 to thefactory service 4104, which forwards the provisioning payload to thefactory tester machine 4102, which in turn forwards the provisioning payload to theedge device 118 for provisioning thereon. Upon receipt of the provisioning payload, theedge device 118 generates the shared cryptographic session key, S, based on the public ephemeral key (Q) received with the provisioning payload and the private key (r1) retrieved from the memory of theedge device 118. More specifically, in some embodiments, the shared cryptographic session key, S, may be generated according to ECDH(Q, r1)=S . Theedge device 118 decrypts the various keys included in the provisioning payload using the shared cryptographic session key, S, cross validates/verifies the various signatures using the corresponding decrypted public cryptographic keys, H1 and H2, and then installs the cryptographic keys from the provisioning payload into the memory of theedge device 118 or, more specifically, into thecryptography chipset 144 in some embodiments. - Referring now to
FIG. 42 , a simplified bloc diagram of asystem 4200 for rolling cryptographic keys when theedge device 118 is in the field. As shown inFIG. 42 , thesystem 4200 includes theedge device 118, themobile device 114, and thecloud server 150 ofFIG. 1 . As described above (e.g., in reference toFIG. 30 ), during the factory provisioning of cryptographic keys, the public key (RI) are provided to the key management service 4106 (e.g., the key management system 108) and the manufacturer origin keys (H1 and H2) are stored to theedge device 118. As such, thecloud server 150 is able to generate a new set of cryptographic keys that can be downloaded to theedge device 118, which may involve an ECDH session key unique to theedge device 118 and a signature by thecloud 150 using a manufacturer origin private key (h1 or h2) to verify that the key originated from thecloud server 150. Because the keys used to roll are different from the keys used for rolling, there is an opportunity to recover the keys if a failure occurs. - It should be appreciated from
FIG. 42 that the transmission of the rolling payload from thecloud server 150 to theedge device 118 is similar to the transmission of the provisioning payload to theedge device 118 as described in reference toFIG. 41 . In particular, thecloud server 150 generates an ephemeral cryptographic key pair (Q, q), which is generated on a per-request basis and not saved, and generates a rolling payload. Further, the shared cryptographic session key, S, may be generated based on the private ephemeral key (q) and the public key (RI). More specifically, in some embodiments, the shared cryptographic session key, S, may be generated according to ECDH(R1, q)=S . In some embodiments, the rolling payload includes the public ephemeral key (Q), which is cryptographically signed by the origin key (h1). Further, the rolling payload may include the cryptographic keys, H1, H2, K, and/or D. In particular, in the illustrative embodiment, those cryptographic keys may be encrypted and signed according to Es(H1)h2Sig, Es(H2)h1Sig, Es(K)(h1Sig), and/or E s(D)h1Sig - The rolling payload including such cryptographic keys is transmitted by the
cloud server 150 to themobile device 114. Themobile device 114 then, in turn, transmits the rolling payload (e.g., via BLE) to theedge device 118. Upon receipt of the rolling payload, theedge device 118 generates the shared cryptographic session key, S, based on the public ephemeral key (Q) received with the provisioning payload and the private key (r1) retrieved from the memory of theedge device 118. More specifically, in some embodiments, the shared cryptographic session key, S, may be generated according to ECDH(Q, r1)=S . Theedge device 118 decrypts the various keys included in the rolling payload using the shared cryptographic session key, S, cross validates/verifies the various signatures using the corresponding decrypted public cryptographic keys, H1 and H2, and then installs the new cryptographic key(s) from the rolling payload into the memory of theedge device 118 or, more specifically, into thecryptography chipset 144 in some embodiments.
Claims (21)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/863,065 US20220408261A1 (en) | 2018-09-21 | 2022-07-12 | Wireless access credential system |
US17/942,785 US20230007484A1 (en) | 2018-09-21 | 2022-09-12 | Wireless access credential system |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201862734548P | 2018-09-21 | 2018-09-21 | |
US16/578,747 US11388595B2 (en) | 2018-09-21 | 2019-09-23 | Wireless access credential system |
US17/863,065 US20220408261A1 (en) | 2018-09-21 | 2022-07-12 | Wireless access credential system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/578,747 Continuation US11388595B2 (en) | 2018-09-21 | 2019-09-23 | Wireless access credential system |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/942,785 Continuation US20230007484A1 (en) | 2018-09-21 | 2022-09-12 | Wireless access credential system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20220408261A1 true US20220408261A1 (en) | 2022-12-22 |
Family
ID=69884810
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/578,747 Active 2040-05-14 US11388595B2 (en) | 2018-09-21 | 2019-09-23 | Wireless access credential system |
US17/863,065 Pending US20220408261A1 (en) | 2018-09-21 | 2022-07-12 | Wireless access credential system |
US17/942,785 Pending US20230007484A1 (en) | 2018-09-21 | 2022-09-12 | Wireless access credential system |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/578,747 Active 2040-05-14 US11388595B2 (en) | 2018-09-21 | 2019-09-23 | Wireless access credential system |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/942,785 Pending US20230007484A1 (en) | 2018-09-21 | 2022-09-12 | Wireless access credential system |
Country Status (6)
Country | Link |
---|---|
US (3) | US11388595B2 (en) |
EP (1) | EP3854027A4 (en) |
AU (2) | AU2019344067B2 (en) |
CA (2) | CA3121023C (en) |
NZ (1) | NZ774490A (en) |
WO (1) | WO2020061567A1 (en) |
Families Citing this family (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110383349B (en) * | 2017-02-28 | 2022-12-30 | 开利公司 | Body-worn device for capturing user intent when interacting with multiple access control devices |
US11539520B2 (en) * | 2017-10-04 | 2022-12-27 | Delphian Systems, LLC | Emergency lockdown in a local network of interconnected devices |
CN111385345A (en) * | 2018-12-29 | 2020-07-07 | 北京航迹科技有限公司 | System and method for data transmission and storage |
KR20200114074A (en) * | 2019-03-27 | 2020-10-07 | 삼성전자주식회사 | Method of controlling a electronic device and apparatus therefor |
US11803644B2 (en) * | 2019-07-23 | 2023-10-31 | SDG Logic Inc. | Security hardened processing device |
US11751062B1 (en) * | 2019-10-18 | 2023-09-05 | Dialog Semiconductor B.V. | Security apparatus and methods for wireless data exchange |
US11582036B1 (en) * | 2019-10-18 | 2023-02-14 | Splunk Inc. | Scaled authentication of endpoint devices |
US11379574B2 (en) * | 2020-01-02 | 2022-07-05 | Disney Enterprises, Inc. | Secure recognition of mobile devices |
EP3866034A1 (en) * | 2020-02-17 | 2021-08-18 | Bayerische Motoren Werke Aktiengesellschaft | Electronic control unit, apparatus for performing control operations on an electronic control unit, and corresponding methods and computer programs |
US11843692B2 (en) * | 2020-03-02 | 2023-12-12 | Seagate Technology Llc | On-cartridge encryption key storage for cartridge-based library |
US11991292B2 (en) * | 2020-04-03 | 2024-05-21 | Mastercard International Incorporated | Systems and methods for use in appending log entries to data structures |
FR3113801B1 (en) * | 2020-08-31 | 2023-09-22 | Orange | Method for providing a third-party communication terminal with authorization to use a customer account, associated methods and associated devices |
US20220068067A1 (en) * | 2020-09-02 | 2022-03-03 | Level Up Holding Co., Inc. | System and method for a modular entry system |
TWI729959B (en) * | 2020-11-04 | 2021-06-01 | 湛積股份有限公司 | Matching verification system and digital device with multiple-lock structure and matching verification method thereof |
US20220141658A1 (en) * | 2020-11-05 | 2022-05-05 | Visa International Service Association | One-time wireless authentication of an internet-of-things device |
US11606210B1 (en) | 2020-12-17 | 2023-03-14 | ForgeRock, Inc. | Secure activation, service mode access and usage control of IOT devices using bearer tokens |
US11595389B1 (en) * | 2020-12-17 | 2023-02-28 | ForgeRock, Inc. | Secure deployment confirmation of IOT devices via bearer tokens with caveats |
US20220224678A1 (en) * | 2021-01-13 | 2022-07-14 | Delega Treasury AG | Synchronized database authorization automation |
US11968296B2 (en) * | 2021-03-09 | 2024-04-23 | Micron Technology, Inc. | Utilization of a memory device for per-user encryption |
US11783654B2 (en) * | 2021-06-06 | 2023-10-10 | Apple Inc. | Techniques for authenticating building/room access terminals |
US11812266B2 (en) * | 2021-06-22 | 2023-11-07 | Verizon Patent And Licensing Inc. | Systems and methods for network-based authentication for connected vehicle access |
US11995931B2 (en) | 2021-08-20 | 2024-05-28 | Schlage Lock Company Llc | Universal credential |
WO2023027921A2 (en) * | 2021-08-21 | 2023-03-02 | Qualcomm Incorporated | Multi device broadcast network for context and awareness |
US11743044B2 (en) * | 2021-09-21 | 2023-08-29 | Salesforce, Inc. | Password-less authentication using key agreement and multi-party computation (MPC) |
FR3130481B1 (en) * | 2021-12-10 | 2023-11-24 | Akidaia | Method for controlling access to an area to be secured and associated initialization method |
EP4307611A1 (en) * | 2022-07-15 | 2024-01-17 | Mastercard International Incorporated | Data communication and cryptographic operations for secure wireless interactions |
US20240106913A1 (en) * | 2022-09-23 | 2024-03-28 | Jamf Software, Llc | Location-based mobile device management of managed devices based on wireless interactions |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110208953A1 (en) * | 2010-02-19 | 2011-08-25 | James Solomon | Event time management in an electric vehicle charging station without a battery-backed real time clock |
US20180321356A1 (en) * | 2014-09-03 | 2018-11-08 | CloudLeaf, Inc. | Asset location and management system with distributed processing |
US20200250896A1 (en) * | 2015-12-02 | 2020-08-06 | Citifyd, Inc. | Vehicle parking and mass transport beacon system |
US11122147B2 (en) * | 2016-02-22 | 2021-09-14 | Samsung Electronics Co., Ltd. | Dongle and control method therefor |
Family Cites Families (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8015597B2 (en) | 1995-10-02 | 2011-09-06 | Corestreet, Ltd. | Disseminating additional data used for controlling access |
US7822989B2 (en) | 1995-10-02 | 2010-10-26 | Corestreet, Ltd. | Controlling access to an area |
US8732457B2 (en) | 1995-10-02 | 2014-05-20 | Assa Abloy Ab | Scalable certificate validation and simplified PKI management |
US8171524B2 (en) | 1995-10-02 | 2012-05-01 | Corestreet, Ltd. | Physical access control |
CA2240881C (en) | 1998-06-17 | 2007-12-04 | Axs Technologies Inc. | Shared intelligence automated access control system |
GB2364202A (en) | 2000-06-27 | 2002-01-16 | Nokia Mobile Phones Ltd | Mobile phone for opening locks |
EP1384212B2 (en) | 2001-04-30 | 2012-03-07 | Activcard Ireland Limited | Method and system for remote activation and management of personal security devices |
US7730126B2 (en) | 2002-02-25 | 2010-06-01 | Crawford C S Lee | Systems and methods for controlling access within a system of networked and non-networked processor-based systems |
US7219837B2 (en) | 2002-09-12 | 2007-05-22 | Integrated Engineering B.V. | Identification system |
US7145434B2 (en) | 2003-04-21 | 2006-12-05 | Compx International Inc. | System and method for key control in an electronic locking system |
US7716489B1 (en) | 2004-09-29 | 2010-05-11 | Rockwell Automation Technologies, Inc. | Access control method for disconnected automation systems |
US7205882B2 (en) | 2004-11-10 | 2007-04-17 | Corestreet, Ltd. | Actuating a security system using a wireless device |
US7356539B2 (en) | 2005-04-04 | 2008-04-08 | Research In Motion Limited | Policy proxy |
US7706778B2 (en) | 2005-04-05 | 2010-04-27 | Assa Abloy Ab | System and method for remotely assigning and revoking access credentials using a near field communication equipped mobile phone |
US8074271B2 (en) | 2006-08-09 | 2011-12-06 | Assa Abloy Ab | Method and apparatus for making a decision on a card |
US8063734B2 (en) | 2006-11-06 | 2011-11-22 | Harrow Products Llc | Access control system wherein the remote device is automatically updated with a central user list from the central station upon use of the remote device |
WO2009070430A2 (en) * | 2007-11-08 | 2009-06-04 | Suridx, Inc. | Apparatus and methods for providing scalable, dynamic, individualized credential services using mobile telephones |
AT506344B1 (en) | 2008-01-30 | 2015-06-15 | Evva Sicherheitstechnologie | METHOD AND DEVICE FOR CONTROLLING THE ACCESS CONTROL |
US9330514B2 (en) | 2012-07-25 | 2016-05-03 | Utc Fire & Security Corporation | Systems and methods for locking device management |
US10171974B2 (en) | 2012-08-16 | 2019-01-01 | Schlage Lock Company Llc | System and method for using an electronic lock with a smartphone |
EP2888855B1 (en) | 2012-08-21 | 2018-12-19 | Onity Inc. | Systems and methods for lock access management using wireless signals |
DE102014105249B4 (en) * | 2013-12-05 | 2023-11-02 | Deutsche Post Ag | Time synchronization |
WO2015124168A1 (en) | 2014-02-18 | 2015-08-27 | Bekey A/S | Controlling access to a location |
US9558377B2 (en) | 2015-01-07 | 2017-01-31 | WaveLynx Technologies Corporation | Electronic access control systems including pass-through credential communication devices and methods for modifying electronic access control systems to include pass-through credential communication devices |
EP3122084B1 (en) | 2015-07-23 | 2020-02-12 | Legic Identsystems AG | Mobile communication device supported by a cloud-based computer system |
WO2017051917A1 (en) | 2015-09-25 | 2017-03-30 | 日本電産サンキョー株式会社 | Card reader |
US10097544B2 (en) * | 2016-06-01 | 2018-10-09 | International Business Machines Corporation | Protection and verification of user authentication credentials against server compromise |
US10257190B2 (en) | 2016-09-23 | 2019-04-09 | Schlage Lock Company Llc | Wi-fi enabled credential enrollment reader and credential management system for access control |
DE102016123713B4 (en) | 2016-12-07 | 2023-12-28 | Deutsche Post Ag | Subject-specific access authorization information |
US10116635B1 (en) | 2017-04-27 | 2018-10-30 | Otis Elevator Company | Mobile-based equipment service system using encrypted code offloading |
-
2019
- 2019-09-23 AU AU2019344067A patent/AU2019344067B2/en active Active
- 2019-09-23 US US16/578,747 patent/US11388595B2/en active Active
- 2019-09-23 CA CA3121023A patent/CA3121023C/en active Active
- 2019-09-23 WO PCT/US2019/052427 patent/WO2020061567A1/en unknown
- 2019-09-23 CA CA3211184A patent/CA3211184A1/en active Pending
- 2019-09-23 NZ NZ774490A patent/NZ774490A/en unknown
- 2019-09-23 EP EP19862997.4A patent/EP3854027A4/en active Pending
-
2022
- 2022-07-12 US US17/863,065 patent/US20220408261A1/en active Pending
- 2022-09-12 US US17/942,785 patent/US20230007484A1/en active Pending
-
2023
- 2023-04-03 AU AU2023202028A patent/AU2023202028A1/en active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110208953A1 (en) * | 2010-02-19 | 2011-08-25 | James Solomon | Event time management in an electric vehicle charging station without a battery-backed real time clock |
US20180321356A1 (en) * | 2014-09-03 | 2018-11-08 | CloudLeaf, Inc. | Asset location and management system with distributed processing |
US20200250896A1 (en) * | 2015-12-02 | 2020-08-06 | Citifyd, Inc. | Vehicle parking and mass transport beacon system |
US11122147B2 (en) * | 2016-02-22 | 2021-09-14 | Samsung Electronics Co., Ltd. | Dongle and control method therefor |
Also Published As
Publication number | Publication date |
---|---|
AU2019344067B2 (en) | 2023-01-05 |
WO2020061567A1 (en) | 2020-03-26 |
US20230007484A1 (en) | 2023-01-05 |
CA3121023A1 (en) | 2020-03-26 |
US11388595B2 (en) | 2022-07-12 |
CA3121023C (en) | 2023-10-24 |
AU2023202028A1 (en) | 2023-05-04 |
US20200100108A1 (en) | 2020-03-26 |
AU2019344067A1 (en) | 2021-05-06 |
NZ774490A (en) | 2023-05-26 |
EP3854027A4 (en) | 2022-06-15 |
EP3854027A1 (en) | 2021-07-28 |
CA3211184A1 (en) | 2020-03-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11388595B2 (en) | Wireless access credential system | |
US9894066B2 (en) | Wireless firmware updates | |
US10990122B2 (en) | Secure real-time clock update in an access control system | |
JP6596091B2 (en) | Internet platform, apparatus and method | |
EP3362931B1 (en) | Wireless firmware updates | |
JP2017524301A (en) | Wireless key management for authentication | |
CN105408910A (en) | Systems and methods for authenticating access to operating system by user before the operating system is booted using wireless communication token | |
EP3469852B1 (en) | Authorized control of an embedded system using end-to-end secure element communication | |
US11042954B2 (en) | System and method for communication between devices | |
JP2018010449A (en) | Smart lock authentication system and method in smart lock | |
KR20120072032A (en) | The system and method for performing mutual authentication of mobile terminal | |
EP3651484A1 (en) | Tokenized mobile device update systems and methods | |
US11995931B2 (en) | Universal credential | |
US20230344621A1 (en) | Technologies for secure inter-processor communications | |
NZ761969B2 (en) | Secure real-time clock update in an access control system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SCHLAGE LOCK COMPANY LLC, INDIANA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:EVERSON, JONATHAN R.;ROSS, GREGORY;KAUFMAN, SETH;AND OTHERS;SIGNING DATES FROM 20190923 TO 20200817;REEL/FRAME:061372/0677 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |