System overview

Trusted Service

BlueID’s Access control as a service has two main components: - ID, (also called IDaaS - Identity as a Service) is BlueID’s Trusted Service. - ACCESS (also called ACaaS – Access as a Service) is the backend layer on top of ID that adds attribution and grouping.

Trusted Service resides in the cloud and it’s the authority and core part of BlueID where Access Tokens (keys) are created, and Public Key Infrastructure (PKI) security is applied during the initialization phase of both Secured Objects (locks) and Mobile Devices (smartphones and NFC cards). The Trusted Service oversees the sending of encrypted authorization Tokens to mobile devices.

The Trusted Service functionalities are made available in different ways: - Access UI, a backend that customers can use to organize their Tenant, by adding and managing locks, inviting Residents, and creating Access Permissions for them - A full set of REST Apis to integrate the BlueID’s access control service in your own backend - BlueID Keys App receives authorization Tokens and manages lock openings - A mobile SDK to integrate Keys App functionalities in your own app

Mobile Devices and Secured Objects

A Mobile Device is a smartphone or an NFC card which uses BlueID technology for authorization management. First, an initialization process is used to link the identity of the mobile device to a user in the backend. After the subsequent transmission of an electronic authorization – the Token – to the device, a standard security protocol is used to allow authorized access to a secured object: the BlueID Secured Object. This involves verifying the authorization in the Token and identifying the user on the basis of their mobile device. Hence, BlueID provides all the functionalities of conventional locking systems.

By using the special BlueID Software Development Kit (SDK), the BlueID platform allows an uncomplicated, low-cost, and stable integration of its functionality into existing or future mobile apps and computer software applications.

The BlueID Software Development Kit (SDK) enables the use of the following functionalities: • Initializing the BlueID Mobile Device in the BlueID Trust Service • Receiving and synchronizing Tokens • Accessing and managing the operator’s own BlueID Secured Objects using custom BlueID commands.

Mobile Device initialisation

The secured object contains a control device (the control unit) which serves as a remote station for establishing communication with the mobile device. If the user triggers a BlueID command with his smartphone app, this will initiate a connection to the desired control unit. During the process, access is checked and verified via the Token in accordance with the security criteria. This check also works faultlessly even if neither the secured object nor the mobile device is connected to the Trusted Service. This means that neither the secured object nor the smartphone need an Internet connection in the moment of access. BlueID can perform access control securely without Internet connectivity.

Communication between the mobile device and the secured object can be handled by whichever is the most appropriate communications standard for the particular application. Due to its flexibility, speed and range, Bluetooth Smart (Bluetooth Low Energy) and NFC, are very suitable for many applications which require local communication via short range radio. Global control via mobile Internet is also possible at exactly the same security level but will cause higher latency due to the longer way of communication. Communication is always processed via a standard security protocol independent of the wireless standard.

If the user is authorized to execute a particular function, this information is verified independently within the control unit which then triggers the required action to control the secured object.

Executing a token command

Access Tokens

Tokens are the digital keys used to execute a command (e.g. OPEN) toward a lock. Tokens are digitally signed by the BlueID Trusted Service. The secured object verifies the signature, this also works when the object is offline. Hence, it is not possible to change the content of a Token after its creation without being detected by the secured object as invalid.

Each Token represents a 1:1 relationship between one mobile device (e.g. smartphone) and one secured object (e.g. main entrance lock) with a time limit, a specified channel and the allowed command. This allows very specific limitations of access rights for each secured object.

A mobile device can handle more than 64,000 Tokens at once without any performance problems, while NFC cards have obviously tighter limitations (in the 500 range). Finally, as Tokens don’t get stored in locks, there is no limitation to the amount of Tokens that can be created for each secured object.

Token creation workflow