Dear Nuki Fans,
Note: There is an updated version of this blog post that explains Nuki’s encryption concept in a simple and understandable way.
Safety and security are among the most important factors for smart home solutions, especially when it comes to opening or locking your door. Today we want to show you the encryption concept we use for Nuki that guarantees a maximum of safety.
Nuki uses Bluetooth Low Energy to communicate with the Nuki App. In order to reach a high security level, we put an own encryption protocol on top of the regular Bluetooth communication.
End-to-End Encryption
Every Nuki App uses its own key to communicate with Nuki. Nobody else than your Nuki and your Nuki App knows that key.
To ensure that the transferred data is always safe from attacks, your data gets encrypted by the sender (e.g. the Nuki App) prior to the data transmission. This means that only encrypted data is transferred via Bluetooth and that it is only decrypted by the recipient (e.g. the Nuki).
For the encryption of your data we use NaCl (crypto_secretbox_xsalsa20poly1305) with 32-byte keys and 24-byte Nonces .
Here is an example:
1. Let’s assume the app wants to send the command “unlock”. For this, the app encrypts this command with a special key. Only the Nuki App and the Nuki know that key.
2. Afterwards, the app transmits the encrypted message via Bluetooth to your Nuki.
3. Since the Nuki also knows the key, it can decrypt the received message and is able to carry out the command successfully.
We offer the Nuki Bridge to be able to check the lock’s status and to control your Nuki even from afar. This Bridge makes your Nuki accessible from anywhere, as it is permanently connected to our servers. This could potentially be a weak spot for hackers. That’s why the data, which is forwarded from and to your Nukis through our servers and your Bridges, is also encrypted. Again, a key is used, which is only known by your Nuki and your Nuki App.
In short, no matter how the Nuki App and the Nuki exchange a message, it is always encrypted with the key that it is only known by the App and Nuki. No one else is able to decrypt this key during the transfer. Not even our servers or the Bridge.
Diffie-Hellman Key Exchange
You might wonder how the information about the key is actually shared between the Nuki App and Nuki, without being noticed by anyone else. During the pairing of your Nuki and the Nuki App, a Diffie-Hellman Key Exchange takes place. This makes it possible to generate a secret key, which is known by both sides without actually transferring the key itself.
Initially, both the Nuki App and Nuki create separate keypairs, which consist of a secret and a public key. As a next step, they exchange their public keys with each other. Then, in each case your Nuki and the Nuki App combine their secret with the public key to create the final and shared key.
The math behind it:
At first, we need two parameters that are known by both sides. On the one hand, we need a very large indivisible number p and on the other hand, the factor g. For a better understanding we use small numbers in the following example: p = 17 and g = 3.
Both sides create a random number (the secret key).
Let’s assume the App chooses a = 9 and Nuki chooses n = 7.
Now both sides calculate the public key with gx mod p.
The App calculates A = ga mod p = 39 mod 17 = 14 and sends this public key to your Nuki. Nuki on the other hand gets N = gn mod p = 37 mod 17 = 11 and sends this public key to the App. Now both sides have all information needed to be able to calculate the common key with Xy mod p.
Nuki calculates An mod p = 147 mod 17 and gets 6.
The App calculates Na mod p = 119 mod 17 and also gets 6.
Thus, 6 is the shared key that is used for further communication.
As already mentioned, we intentionally used very small numbers to make the example as transparent as possible. This method actually uses 32-byte keys and the shared key gets derived from the calculated key with Key Derivation.
Saving the Keys
The keys are saved securely on your smartphone and are unreachable for other apps or users. However, this requires your smartphone not to be rooted or jailbreaked.
If your smartphone gets lost or stolen, the permission to use Nuki can be deleted via another permitted smartphone. If there is no other permitted phone, you can pair another one with your Nuki via Bluetooth or you can simply reset your Nuki to factory defaults.
Challenge-Response
To avoid that hackers can record a command, for example “unlock”, and re-use it to unlock your door by themselves (a so-called “replay-attack”), we integrated the Challenge-Response Process.
One party forwards a very large random number (Challenge), which the other party has to send within its answer (Response). If this number is not sent or does not match, the command will be aborted.
In the example of an unlock-process, the App would receive a 32-byte random number. Only afterwards it can unlock the door with a response to Nuki that includes this random number. If then another command with the same random number is forwarded, the command will be unsuccessful.
This was a short overview of our security concept. Hopefully, we’ve been able to show you, that the safety and security of your home is very important to us.
All the best,
Marc
Head of Tech
Note: There is an updated version of this blog post that explains Nuki’s encryption concept in a simple and understandable way.
Safety and security are among the most important factors for smart home solutions, especially when it comes to opening or locking your door. Today we want to show you the encryption concept we use for Nuki that guarantees a maximum of safety.
Nuki uses Bluetooth Low Energy to communicate with the Nuki App. In order to reach a high security level, we put an own encryption protocol on top of the regular Bluetooth communication.
End-to-End Encryption
Every Nuki App uses its own key to communicate with Nuki. Nobody else than your Nuki and your Nuki App knows that key.
To ensure that the transferred data is always safe from attacks, your data gets encrypted by the sender (e.g. the Nuki App) prior to the data transmission. This means that only encrypted data is transferred via Bluetooth and that it is only decrypted by the recipient (e.g. the Nuki).
For the encryption of your data we use NaCl (crypto_secretbox_xsalsa20poly1305) with 32-byte keys and 24-byte Nonces .
Here is an example:
1. Let’s assume the app wants to send the command “unlock”. For this, the app encrypts this command with a special key. Only the Nuki App and the Nuki know that key.
2. Afterwards, the app transmits the encrypted message via Bluetooth to your Nuki.
3. Since the Nuki also knows the key, it can decrypt the received message and is able to carry out the command successfully.
We offer the Nuki Bridge to be able to check the lock’s status and to control your Nuki even from afar. This Bridge makes your Nuki accessible from anywhere, as it is permanently connected to our servers. This could potentially be a weak spot for hackers. That’s why the data, which is forwarded from and to your Nukis through our servers and your Bridges, is also encrypted. Again, a key is used, which is only known by your Nuki and your Nuki App.In short, no matter how the Nuki App and the Nuki exchange a message, it is always encrypted with the key that it is only known by the App and Nuki. No one else is able to decrypt this key during the transfer. Not even our servers or the Bridge.
Diffie-Hellman Key ExchangeYou might wonder how the information about the key is actually shared between the Nuki App and Nuki, without being noticed by anyone else. During the pairing of your Nuki and the Nuki App, a Diffie-Hellman Key Exchange takes place. This makes it possible to generate a secret key, which is known by both sides without actually transferring the key itself.
Initially, both the Nuki App and Nuki create separate keypairs, which consist of a secret and a public key. As a next step, they exchange their public keys with each other. Then, in each case your Nuki and the Nuki App combine their secret with the public key to create the final and shared key.
The math behind it:
At first, we need two parameters that are known by both sides. On the one hand, we need a very large indivisible number p and on the other hand, the factor g. For a better understanding we use small numbers in the following example: p = 17 and g = 3.
Both sides create a random number (the secret key).
Let’s assume the App chooses a = 9 and Nuki chooses n = 7.
Now both sides calculate the public key with gx mod p.
The App calculates A = ga mod p = 39 mod 17 = 14 and sends this public key to your Nuki. Nuki on the other hand gets N = gn mod p = 37 mod 17 = 11 and sends this public key to the App. Now both sides have all information needed to be able to calculate the common key with Xy mod p.
Nuki calculates An mod p = 147 mod 17 and gets 6.
The App calculates Na mod p = 119 mod 17 and also gets 6.
Thus, 6 is the shared key that is used for further communication.
As already mentioned, we intentionally used very small numbers to make the example as transparent as possible. This method actually uses 32-byte keys and the shared key gets derived from the calculated key with Key Derivation.
Saving the Keys
The keys are saved securely on your smartphone and are unreachable for other apps or users. However, this requires your smartphone not to be rooted or jailbreaked.
If your smartphone gets lost or stolen, the permission to use Nuki can be deleted via another permitted smartphone. If there is no other permitted phone, you can pair another one with your Nuki via Bluetooth or you can simply reset your Nuki to factory defaults.
Challenge-Response
To avoid that hackers can record a command, for example “unlock”, and re-use it to unlock your door by themselves (a so-called “replay-attack”), we integrated the Challenge-Response Process.
One party forwards a very large random number (Challenge), which the other party has to send within its answer (Response). If this number is not sent or does not match, the command will be aborted.
In the example of an unlock-process, the App would receive a 32-byte random number. Only afterwards it can unlock the door with a response to Nuki that includes this random number. If then another command with the same random number is forwarded, the command will be unsuccessful.
This was a short overview of our security concept. Hopefully, we’ve been able to show you, that the safety and security of your home is very important to us.
All the best,
Marc
Head of Tech
