There are many mobile key offerings on the market today, however not all solutions are created equal – especially when it comes to security. In critical infrastructure facilities such as airports, government offices, military bases, or financial institutions, would simply entering a four-digit code that was sent to a smartphone onto a keypad be considered a secure access solution?
A false sense of security can create vulnerabilities. The next step up from simply sending a code for a user to enter on a keypad would be to transmit such a code from the smartphone to the electronic lock over a communication channel such as Bluetooth or NFC. By using the built-in security features of such channels, the code cannot be eavesdropped. However, since the code stays the same for a period of time, a message between smartphone and lock could potentially be recorded and then replayed while pretending to be a valid sender, hence compromising access security to potentially gain access.
Other mobile key solutions start to get serious about security by using an end-to-end symmetric encryption solution which completely hides the access permissions data from any third party. Such a solution involves encrypting the access permission data on the sending end, then transmitting that data, and finally decrypting that data on the receiving side. However, since symmetric encryption is based on a single secret key responsible for encrypting and decrypting the data, it is essential that this key be kept secret at all times.
When applying this method to the mobile keys use-case, fundamental weaknesses arise concerning the distribution and protection of this secret key. Although installing the secret key onto the lock could be done securely at the manufacturer, the difficulty arises in getting the secret key securely onto the mobile phone. Distributing the secret key over the air risks interception which would then compromise all locks using that secret key. And requiring that the smartphone be brought to a secure location to have the secret key installed is clearly not a feasible distribution method. Further, the phone itself could be attacked and the secret key stolen or manipulated, meaning that applying symmetric encryption to the use case of mobile keys yields an inherently insecure solution.
Asymmetric cryptography uses two different but mathematically linked keys – one private and one public.
Modern asymmetric cryptography algorithms are so secure that they are commonly used to provide communications security in computer networks, like for example within the widely used Transport Layer Security protocol, used for Internet banking. In contrast to symmetric encryption, asymmetric cryptography not solely focuses on hiding a piece of information but enables a different kind of cryptographic entity: the digital signature. This signature enables a secure way for verifying the authenticity of a digital message and is created by signing a piece of data with the private key. Vice-versa, the public key can be used to verify the signature and thus the authenticity of the data.
One major advantage of this concept is that there is no need to transmit the private key - only the public key needs to be distributed to another entity for this to work. Distributing a public key over an insecure communication channel implies no security risk - intercepting a public key would be akin to finding half of a physical key on the street – without the other half, it would be effectively useless.
But how does this apply to the world of mobile keys? Generally speaking, there is just no need to encrypt the transmission of data containing the access rights in most applications – the crucial part is the authenticity of this data. Using asymmetric cryptography and digital signatures, this authenticity can be provided between a lock and a smartphone. Although asymmetric cryptography is more complex than symmetric encryption, the processing power of modern embedded devices and mobile phones enables such cryptographic operations in a reasonable amount of time and does not interfere in any kind with a fast and reliable user experience.
For even further security, a trusted managing party can be established. By adopting this to a cloud-based solution, a Public Key Infrastructure (PKI) with the managing party as Root of Trust is established. Consequently, the managing party is used to issue, sign and distribute new access rights securely to a smartphone. In order to securely prove the access rights and verify the signature of the managing party, the lock only requires the public key of the cloud service, which could easily be installed on the lock at production. By attaching the public key of the smartphone to the signed access rights, a challenge-response protocol can be accomplished between lock and smartphone, resulting in mutual authentication between lock and smartphone.
One such implementation for mobile key solutions that is available today and has been in use for a decade is offered by BlueID GmbH, a Munich-based company that got its start with secure vehicle access. “The security requirements of the automotive market are extremely demanding, therefore from the very beginning we designed our solution from this perspective using PKI to be even more secure than traditional car keys. The many simpler methods being currently offered, just cannot ensure that access to or the starting of cars could not be exploited.” says Philipp Spangenberg, BlueID CEO and founder, adding “Our customers such as VW and Audi rely on BlueID’s secure PKI architecture to protect their brand reputation. We offer the same real-world tested platform to the facility market, especially for office buildings, hotels and utilities infrastructure where security is paramount.”
Hotel Use Case
To illustrate the creation and usage of a mobile key, the process begins with integrating the BlueID solution into the Bluetooth chip of the smart lock – with the BlueID Ready2Go firmware offering out-of-the-box solutions for chip series from Nordic Semiconductor and Silicon Labs. The BlueID firmware along with a private and public key pair are loaded during production, resulting in the private key never leaving a secured environment or stored anywhere else than on the lock itself. Consequently, only the public key of the lock is sent to the Trust Center which creates a unique lock ID that is additionally loaded onto the lock at production.
After production, the lock is sent to the facility and installed at a specific room. The BlueID Lock Admin App is subsequently used to get the new lock’s ID and assign the lock to this specific room. The app further informs the Trust Center about the assignment, which finally correlates this data for the front desk software of the hotel. After receiving a reservation by a hotel guest, the front desk creates an app invitation for this guest who just needs to install the hotel’s mobile key app, thereby uniquely identifying his smartphone to the Trust Center.
Within this activation, a public and private key pair are generated on the mobile phone, with only the public key being sent to the Trust Center and the private key being stored securely on the phone. After receiving the activation from the guest’s app, the Trust Center creates credentials for the guest and sends them to the front desk which associates this data to the guest in the hotel’s booking system. Finally, the front desk requests that the Trust Center generates the mobile keys for the guest’s phone, which are created and signed in the Trust Center and distributed to the guest’s mobile key app.
Arriving at the hotel room, the guest simply uses the app to open his room, initiating the verification procedure with the lock that opens the door – typically within a second or two. Within this verification procedure not only the validity and authenticity of the access permissions (e.g. room number, time frame) are verified by the signature of the Trust Center, but also an authentication of the guest’s phone with the lock is performed.
The guest enjoys the convenience of using a phone, while the hotel benefits from PKI security.