Skip to main content



Authentication is the cornerstone of secure information exchange in BluSKY®, because each party must be able to verify that they are communicating with a trusted partner.

Authentication is the process whereby each party verifies the mutual identity. Within the BluBØX architecture, there are two exchanges requiring such verification: administrative login to the BluBØX applications, and control panel communication with the data center.

Administrator Authentication

An administrator is a BluBØX customer with privileges to sign in to the BluSKY application and observe or make changes to an account that controls one or more sites. For an administrator to securely establish a session with the BluBØX cloud, BluBØX must be able to verify the identity of the administrator. The administrator also must be able to verify that he or she is, in fact, logging into the BluBØX website and not an imposter website.

Administrators are authenticated by entering an administrator ID and password to the BluSKY application. The ID/ password combination allows BluBØX to verify that the person attempting to connect to BluBØX is, in fact, using a valid pair of identifiers to gain access to the system. Optionally, administrators may add a second factor for authentication of each log-on using an out-of-band Short Service Message (SMS). This feature affects all administrators within an account. Once activated, when an administrator logs into the system, he or she will receive an email with a login token that must be used to complete the login process. The token is only valid for a limited time and is sent to the email address on file within the administrator’s profile.

The entire ID/password exchange takes place within a Transport Layer Security (TLS) session that begins when the administrator accesses the logon page of the BluSKY® application via Hypertext Transfer Protocol Secure (HTTPS). The TLS session protects the exchange of authentication data by encrypting it, thus establishing secure communication.

Steps are also taken to ensure that the BluSKY administrator can be sure that they are logging in to the real BluSKY® application. This is accomplished through the establishment of the TLS session itself. By checking the validity of the digital certificate presented at the beginning of the TLS session, the administrator can verify that he or she is indeed connected to BluBØX and not another website masquerading as BluBØX. This is possible because BluBØX uses a digital certificate (see section titled “Digital Certificates”) issued by a recognized third-party Certificate Authority who took steps to verify BluBØX’s corporate identity in the process of issuing the certificate.

Through the process outlined above, the administrator may now be assured that access to an account in the BluBØX system is legitimate.

Mobile Applications

BluBØX meets market demand for mobile access and credentials with our BluSKY for iOS and Android application and our BluBØX Mobile Pass application. These mobile applications seamlessly extend the BluBØX access control and video surveillance platform to a smartphone, integrating door control and credential management with live and recorded video.

BluSKY for iOS and Android is an application designed for use by administrators for mobile access to their account functions. Communications are secured using TLS. The software on the mobile device follows industry best practices by using the iOS Keychain or Android’s Private Mode to secure access. The ID and password used to sign in are secured and stored in the iOS keychain and in Private Mode for Android.

BluBØX Mobile Pass is an iOS or Android application that can be used in place of a physical credential when the BluSKY administrator grants these permissions. It is used to collect, organize, and use digital access passes that have been issued to the application user by their site administrator. Communications are secured using TLS. The BluBØX Mobile Pass application must authenticate itself to the BluBØX API every time it is used. As with BluSKY for iOS and Android, the software on the mobile device follows industry best practices by using the iOS Keychain or Android’s Private Mode to secure access. The iOS Keychain is used to store refresh tokens. Android tokens are secured and stored in Private Mode so only the application has access to the data. BluBØX’s cloud based infrastructure and backend monitoring support provides our operations team the detailed analytics tools they need to detect and investigate security concerns and manage anomalies.

The data flow of BluBØX’s mobile credentials builds upon industry best practices for credential application, issuance, management and usage. The application process begins with an authorized administrator sending an Invite to the user by email. The email contains a onetime authorization code that can be used to download the unique digital credential for that person. The application user uses the link in their email to activate the application and redeem their digital credential. The application uses a onetime authorization code to ensure that the credential can be redeemed only once. The account administrator retains complete control over the credential with respect to the access rights for sites, groups, and doors where the credential can be used. Control remains centralized so the same rules and policies that apply to the traditional credentials apply to digital credentials as well; credentials can be suspended or revoked at any time. Administrators have confidence that security policy access rules are enforced using the same familiar tools and techniques, while still being able to react quickly to urgent situational and environmental conditions without issuing new credentials. Once redeemed, the pass is available to use whenever the person needs to open an appropriately provisioned door. The unique traits of the digital pass provide both security and privacy enhancing benefits. Users only see the list of sites and doors to which they have permissions. All attempts to use the pass are audited with the same degree of traceability to which administrators are accustomed to in BluSKY.

Whenever mobile devices are used for physical access, BluBØX recommends a PIN (or equivalent security mechanism on the mobile device) be used to secure access to the mobile device. On an iOS device, iCloud can be used to erase all data remotely. On an Android device, data can be erased remotely if the mobile device is linked to a Google account.

For any of BluBØX’s mobile applications, if the mobile device is stolen or compromised, administrators should immediately revoke or suspend any mobile passes associated with that user.

Control Panel Authentication

A control panel is dedicated hardware containing a microprocessor, memory, and I/O interfaces that allow it to interconnect to credential input devices such as readers, and door control and sensor hardware such as latches and switches. BluBØX has designed and manufactured several models of control panels which differ in capacity, communication options, and features.

Control Panel Verifies BluBØX’s Identity

All control panels exchange credential and event information with BluBØX’s data center, and therefore must be assured that they are communicating with BluBØX and not an imposter. Additionally, BluBØX must be sure that a device attempting to connect as a control panel is, in fact, an authorized device, and that it is only asking for the information it is authorized to receive.

The control panel uses the same method as the administrator to verify BluBØX’s identity: namely, checking a digital certificate on the servers at BluBØX’s data center. Like a browser, a control panel establishes a TLS session with BluBØX before it begins to exchange information. In doing so, BluBØX presents its digital certificate to the control panel, which it can check in much the same manner as an administrator might.

In the case of the control panel, however, the process of checking the digital certificate must be automated because there is no human present to check its validity.

The first step of this automation occurs during manufacturing by embedding information in the control panel that will allow it to check the validity of the digital certificate presented by the BluBØX data center. Specifically, the control panel has knowledge of the ‘public key’ associated with the digital certificate on one or more BluBØX web servers.

The second step of the identity verification process takes place when setting up the TLS session used to exchange event and credential data. If the certificate presented by the BluBØX data center (or an imposter) does not match the certificate that the control panel expects, then it will refuse to communicate with the BluBØX data center.

BluBØX Verifies Control Panels’ Identity

It is just as important for the servers at BluBØX to be able to verify the identity of a control panel to ensure data is shared with only genuine and authorized control panels.

Our servers are able to verify the control panel’s identity because BluBØX installs a unique digital certificate (used as a client certificate in the context of TLS) on each control panel at the time of manufacture. This certificate is digitally signed by BluBØX so that its origin can always be confirmed at a later time and cannot be faked.

When a control panel attempts to establish a TLS session to download data or report events, BluBØX’s servers force it to present its client certificate before gaining access to the system. If it has a valid certificate that was issued by BluBØX, then a TLS session is initiated and it is allowed to download data and upload event information. If not, it is blocked for any further activity on the server.

In addition to blocking attempts at spoofing or impersonation, the client certificate requirement also blocks out unauthorized attempts to gain access to these web servers.

API User Security and Authentication

The BluBØX API uses the OAuth2 three-legged authorization code workflow for account access. Account Administrators are provided the ability to selectively enable API connections to their BluSKY account. All communications via the API are secured via TLS.2

Digital Certificates

The preceding two sections discuss the use of a digital certificate to provide authentication between various parties in the BluBØX system architecture. But what is a digital certificate?

A digital certificate is an electronic document containing unique data that allows a device (or person) to authenticate itself to another device (or person). Its use in this context is part of a cryptographic protocol known as public key infrastructure or PKI. In particular, a digital certificate contains the public key of the owner of the certificate. This public key is shared with other people or systems to whom you wish to communicate.

A corresponding private key is held secret and not shared with anyone else. When two parties – say Alice and Bob – wish to authenticate themselves to each other, they present digital signatures based on their private keys. They can each then check the respective signatures using each other’s public key to verify that they are indeed communicating with the right party.

If Bob then wishes to send an encrypted message to Alice, he can encrypt the message with Alice’s public key. The message can then be decrypted only by Alice’s private key, which she has kept the secret to herself.

In the BluBØX architecture, both the data center and the control panel have digital certificates that allow them to verify the identity of the other, and subsequently, encrypt their communications so that no one else can intercept them. This is true regardless of whether the communications occur on wired or wireless media.


BluBØX uses a type of digital certificates described by the ANSI X.509 specification for public key infrastructure (PKI) systems.

The reference architecture calls for a certificate authority (CA) – a trusted party which can externally validate the identity of certificate holders prior to their issuance – to manage the creation, management, and revocation of certificates.

For control panels, BluBØX acts as its own CA because it can guarantee a physical chain of custody during the installation of certificates into control panels in our manufacturing process, and because there are no third parties communicating with those panels who need to be part of the authentication process.


256-Bit TLS refers to the length of the encryption key used to encrypt the data exchange session. Generally speaking, the bigger the key, the more secure your data will be.

The encryption algorithm uses this key to create a unique session. In the BluBØX system, the 256-bit encryption between the control panel and host uses the Digital Signature Algorithm (DSA) verified with a digital certificate signed with a key length of either 1,024 or 2,048 bits, depending on the device.

Our web applications and APIs communicate over HTTPS (TLS 1.1 or higher) using the SHA-256 algorithm with a 2048-bit RSA key.

TLS Encryption

There have been numerous references to the Transport Layer Security (TLS) in the preceding sections. While it is a familiar term to most web users, it can be used in several different ways. In the case of BluSKY®, it is used for both its embedded encryption functions, as well as its authentication capabilities.

First, some background on TLS is needed. TLS and its predecessor SSL are best known as an encryption protocols favored by such secure web services as online banking, stock trading sites, and e-commerce in general. It is used in these contexts because of its wide availability in commercial browsers and software libraries, and because it is highly secure. Properly implemented, TLS is virtually invulnerable to attack.

TLS is most commonly used to encrypt sessions between a browser and a web site. In these applications, the website typically uses a digital certificate as part of the TLS handshake, which is what allows users to verify that they are starting a secure session with the expected web site. However, the browser client does not typically use a client certificate, which means that the web site cannot verify the identity of the client. In the BluSKY® architecture, both server and client certificates are used so that both parties can verify each other’s identity. The resulting TLS session is therefore both secure and authenticated.

TLS is available in different strengths depending on the size of the cryptographic key used to seed the encryption process. BluBØX’s servers enforce 256-bit encryption, which on average requires billions of processor years to decrypt without the correct keys.



  • Was this article helpful?