IOTA Smart Lock — Proof of Concept
Exploring the idea behind our upcoming new innovative solution
Note: this is a translation of a post that was published on LinkedIn in italian a few months ago. A prototype has been realized since then, we will soon release additional information about this solution.
Opening a lock is a very common action, and nowadays we perform it many times everyday without realizing how complex it is on many layers.
In time, locks and keys have become more and more sophisticated, especially in the digital era with electronic locks and digital keys.
The “hidden” function of keys
We are so used to using keys that we sometimes forget that they have two different functions:
- mechanically or electronically activate the lock;
- granting the right and faculty to use the first function.
The second function seems implicit, but it is not: if I find someone else’s lost key I can physically open its lock, but I don’t have the legal right to do so.
On the other hand, if I have guests in my home, I might give them the house keys, and at the same time I also explicitly give the permission to lock and unlock the door.
Keys can be both strong and weak at the same time
A perfect example of how a key/lock system can be very resilient to breaking but very weak when it comes to verify the usage authorization are “keyless” security systems of modern cars.
These systems work with a central unit in the car which identifies the key thanks to radio encrypted messages. It is impossible to clone the key and create alternative messages to unlock the car.
Just like mechanical keys, whoever holds the key can open the lock, but they don’t necessarily have the authorization to do so.
In addition, with these systems it is also possible to unlock the car even without physically holding the key and without using force: only two people and two transceivers are needed.
The first person follows the car’s owner, while the second person waits beside the car. The two transceiver create a radio bridge between the key and the car: the key receives the signal from the car and it activates. Car and key “think” they are in proximity and exchange information. The car unlocks and security systems are deactivated.
With this example, we can see how hard it is even with digital systems to fight potential unauthorized accesses, and how modern solutions end up creating even more attack opportunities. The real problem though is still the total absence of usage authorization control, which is practically impossible with legacy systems and still not completely solved with digital solutions.
IOTA Smart Lock
The goal of this project is to enable an authorization control process for digital keys, and we aim to accomplish it by separating the two functions of keys which we discussed above.
ProductID, our digital identity solution for objects, can be successfully customized and adapted for this purpose, first of all solving the fundamental problem of establishing if a user trying to activate a lock is actually in physical proximity of the lock itself, and then checking if the user is authorized to use the key.
Components of this solution:
- any electronic lock;
- any device able to run a IOTA client as a controller;
- ProductID initialized smart card for the lock’s digital identity;
- web front-end to identify the users;
- back-end to elaborate the info gathered by the front-end and validate the user’s identity.
How it works:
- the smart card is read with a smartphone and opens a web page of the ProductID front-end;
- if the smart card is valid, the front-end redirects the browser to the Smart Lock front-end;
- the Smart Lock fron-end analyzes the validity of the URL of provenience, and gets access to the ID of the smart card, which is connected to a list of authorized users;
- the Smart Lock front-end gathers the parameters for the secure identification of the user (explained in the following paragraph);
- the Smart Lock front-end forwards the identification parameters and, if the user is authorized, the back-end makes the controller open the lock.
User identification procedures
The identification of the user who is trying to open a lock can be achieved with different degrees of security:
- UID + PIN code: this is the simplest and less secure method. If the user ID and the PIN code are in the authorization list, the identification is valid;
- account with external AAA (Google, Facebook, LinkedIn, etc.): if the credentials used to log in are validated by the external server, the identification is valid;
- account with external AAA + facial recognition: the front-end collects an image of the user’s face and the back-end checks with the one set during the configuration.
ProductID is resilient to replay attacks and the smart card can not be cloned.
Radio bridge attack is useless too. The ProductID smart card can be read also offline, but only for the proximity check (proof of location); in order to unlock the door, user credentials are also needed if the verification of the authorization is requested.
If we don’t consider coercion or the use of force to break the lock (which are possible attacks independently of the key), either the user offers a valid identification, or the system can not be tampered with or fooled.