I am new to the nuki ecosystem and we are currently searching a solution to give users access to nuki via our custom app. Our app users should have temporary access to a nuki lock and nuki box. The moment the user is unlocking, the users mobile phone probably has no internet connection. Though the user and the app has obviously internet connection before the unlock. There is also no physical contact with the user or the users device before the unlock command.
When thinking it through. I found no solutions to implement something like that with the nuki being offline, only with the bluetooth api. Since it’s not possible to successfully respond to the nuki’s challenge in the unlock command, without sharing the key with the app.
Let’s assume we also have the nuki bridge. Would it then be possible to implement something like that with the web api? Could anyone help me out here?
For such scenarios the recommended solution is to use the bluetooth API with one key that you use for all users and that you share within your own app ecosystem. i.e. you implement the rights management inside your app.
If the Smart Lock has a bridge and is - like the Nuki box - accessible via the Nuki Web API you could lock/unlock through simple HTTP calls to the Web API from either your server or directly your app. Problem in your case would be that the user needs to have internet connectivity when he is in front of the door and you would (most likely) need some sort of geofencing / location check in your app in order to prevent abuse (i.e. users sending lock commands even when they are not in front of the door).
Another way to work around the complexity of the BLE API and/or the offline problem is to install Nuki Keypads and just share 6 digit codes with your users, which is usually much easier from a technical point of view. The Keypad is not supported by the Nuki box though (but it is by the Opener, which can also act as relay which shortens a contact for an existing electrical strike).
We were also thinking about that. I would like this option very much if it works.
So in this case i would have to create some sort of pairing in the first place to generate the key and store it on our servers. Or is there a better way to generate the key? I i just thought that it might not be the best option. Because i thought that it might be possible that one somehow reads the key of the app and has permanent access. I am not a mobile security expert though and do now know how hard this would be.
The Box does not support the generation of locally generated keys. They are generated server side through invites for it. You might need some help with this from qualified Nuki stuff once you are at this point.
That depends on the security measures you take inside your app and whether you trust the OS of the app (usually apps are sandboxed and you can not access it’s local storage unless the OS is rooted / jailbreaked). Obviously the best option would be do not store the key inside your app at all (which is easy to achieve if you have an internet connection and every lock command simply requests the encrypted BLE payload from your server and your app forwards that to the lock back and forth. i.e. it acts like a bridge and does not decrypt and store the data locally at all). As you plan to support the offline case where the Smartphone does not have an internet connection, this does not work and you would need to create at least a temporary local storage for the key inside your app.
Btw. each Nuki does have per user keys. Which means you could create several users/keys which you could also delete separately. It does not have to be exactly one key that you share. You could also use a system where you exchange the key every month and create eg. keys that work exactly for one month upfront, which also reduces the risk that someone can create damage with a lost key.
