Chers fans de Nuki,
Note: Il existe une version mise à jour de cet article de blog qui explique le concept de chiffrement Nuki d’une manière simple et plus compréhensible.
La sécurité représente l’un des facteurs les plus importants quand il s’agit de solutions Smart Home – en particulier lorsque la propre porte d’entrée doit être ouverte. C’est pourquoi nous allons vous montrer quels concepts de chiffrement nous utilisons afin de vous offrir un maximum de sécurité.
Nuki utilise Bluetooth Low Energy (BLE) pour la communication avec l’App de Nuki. Afin d’avoir un niveau de sécurité élevé, nous avons rajouté un protocole spécifique de chiffrement pour la communication normale via Bluetooth.
Afin de protéger les données transmises via Bluetooth de pirates, celles-ci sont cryptées avant la transmission par l’émetteur (par ex., l’App).
Une fois les données cryptées, celles-ci sont envoyées via Bluetooth et décryptées une fois arrivées auprès du destinataire (par ex., Nuki).
Pour le chiffrement des données, nous avons recours à la technologie NaCl (Native Client), plus précisément crypto_secretbox_xsalsa20poly1305. À cette fin, nous utilisons des clés de 32 octets et des nonces de 24 octets.
Prenons un moment pour nous pencher sur l’exemple suivant.
Pour pouvoir visionner le statut de votre Nuki également d’en route et pouvoir l’utiliser de tout lieu, nous vous proposons la passerelle Nuki Bridge. Elle rend votre Nuki accessible de partout en maintenant la connexion permanente ouverte vers nos serveurs.
Et c’est à cet endroit que des pirates potentiels pourraient accéder aux données. C’est bien la raison pour laquelle toutes les données transmises depuis nos serveurs et vos Bridges vers vos Nuki sont chiffrées. La clé utilisée est celle que seules votre App et votre Nuki connaissent.
Pour conclure, cela veut dire qu’indépendamment du moyen de communication par lequel un message est échangé entre l’App et Nuki, le message est toujours crypté avec la clé que seules l’App et Nuki connaissent ; il ne peut pas être déchiffré en cours de route, même pas par nos serveurs ou par la Bridge.
Au moment de l’appairage entre l’App et Nuki, l’échange de clés Diffie-Hellman a lieu, qui permet de générer une clé secrète connue des deux côtés sans, toutefois, jamais transférer cette clé.
Au départ, les deux côtés – l’App et Nuki – génèrent une paire de clés qui consiste en une clé secrète et en une clé publique. Puis, chaque côté envoie à l’autre sa clé publique. Ensuite, chaque côté calcule la clé secrète finale pour l’autre en prenant comme référence sa propre clé secrète et la clé publique.
Prenons donc p = 17 et g = 3.
Les deux côtés génèrent un nombre aléatoire (la clé secrète).
L’App choisit par exemple a = 9 et Nuki choisit n = 7.
Maintenant, les deux côtés calculent la clé publique avec la formule gx mod p.
L’App calcule A = ga mod p = 39 mod 17 = 14 et envoie cette clé publique à Nuki. Nuki calcule N = gn mod p = 37 mod 17 = 11 et envoie cette clé publique à l’App. Maintenant, les deux côtés ont les informations requises pour calculer la clé commune avec Xy mod p.
Nuki calcule la clé An mod p = 147 mod 17 et obtient 6.
L’App calcule la clé Na mod p = 119 mod 17 et obtient également 6.
Le chiffre 6 est donc la clé secrète commune qui est utilisée pour la suite de la communication.
Dans cet exemple, nous utilisons, tel que cité plus haut, de tout petits chiffres à des fins de présentation claire. Cette méthode utilise des clés de 32 octets et la clé commune est déduite de la clé calculée au moyen de la dérivation de clé.
Si un Smartphone autorisé a été perdu, son autorisation d’utiliser Nuki peut être retirée à l’aide d’un autre Smartphone autorisé. Si vous n’avez pas de deuxième Smartphone autorisé, vous pouvez soit en autoriser un nouveau sur place via Bluetooth, soit réinitialiser votre Nuki.
D’abord, un très grand nombre aléatoire est communiqué (défi) à l’autre côté par le canal crypté, que celui-ci doit également mentionné dans la réponse (réponse). Si le côté omet de répondre, ou si un mauvais nombre aléatoire est communiqué, la commande est refusée.
Dans l’exemple avec la fonction de déverrouillage, l’App recevrait d’abord un nombre aléatoire de 32 octets et ne pourrait envoyer la commande de déverrouillage uniquement après à Nuki contenant obligatoirement ce nombre aléatoire.
Si, ensuite, une nouvelle commande de déverrouillage est envoyée à Nuki avec le même nombre aléatoire, celle-ci sera refusée par Nuki.
Le petit tour d’horizon de notre concept de sécurité se termine à cet endroit. Nous espérons avoir pu vous démontrer que la sécurité de votre domicile nous tient énormément à cœur et que nous ne faisons aucune concession en la matière.
Au plaisir de vous relire et tout de bon !
Marc
Directeur technique
Note: Il existe une version mise à jour de cet article de blog qui explique le concept de chiffrement Nuki d’une manière simple et plus compréhensible.
La sécurité représente l’un des facteurs les plus importants quand il s’agit de solutions Smart Home – en particulier lorsque la propre porte d’entrée doit être ouverte. C’est pourquoi nous allons vous montrer quels concepts de chiffrement nous utilisons afin de vous offrir un maximum de sécurité.
Nuki utilise Bluetooth Low Energy (BLE) pour la communication avec l’App de Nuki. Afin d’avoir un niveau de sécurité élevé, nous avons rajouté un protocole spécifique de chiffrement pour la communication normale via Bluetooth.
Chiffrement de bout en bout
Chaque App de Nuki utilise une clé spécifique pour la communication avec Nuki, qui n’est connue que de Nuki et de l’App respective. Personne d’autre ne connaît cette clé.Afin de protéger les données transmises via Bluetooth de pirates, celles-ci sont cryptées avant la transmission par l’émetteur (par ex., l’App).
Une fois les données cryptées, celles-ci sont envoyées via Bluetooth et décryptées une fois arrivées auprès du destinataire (par ex., Nuki).
Pour le chiffrement des données, nous avons recours à la technologie NaCl (Native Client), plus précisément crypto_secretbox_xsalsa20poly1305. À cette fin, nous utilisons des clés de 32 octets et des nonces de 24 octets.
Prenons un moment pour nous pencher sur l’exemple suivant.
- Admettons que l’App veuille envoyer la commande « déverrouiller ». La commande est cryptée avec la clé et ce ne sont que l’App et Nuki qui connaissent le chiffrement.
- Ensuite, l’App transmet le message crypté via Bluetooth à Nuki.
- Etant donné que Nuki connaît également la clé, elle peut décrypter le message et exécuter la commande.
Pour pouvoir visionner le statut de votre Nuki également d’en route et pouvoir l’utiliser de tout lieu, nous vous proposons la passerelle Nuki Bridge. Elle rend votre Nuki accessible de partout en maintenant la connexion permanente ouverte vers nos serveurs.Et c’est à cet endroit que des pirates potentiels pourraient accéder aux données. C’est bien la raison pour laquelle toutes les données transmises depuis nos serveurs et vos Bridges vers vos Nuki sont chiffrées. La clé utilisée est celle que seules votre App et votre Nuki connaissent.
Pour conclure, cela veut dire qu’indépendamment du moyen de communication par lequel un message est échangé entre l’App et Nuki, le message est toujours crypté avec la clé que seules l’App et Nuki connaissent ; il ne peut pas être déchiffré en cours de route, même pas par nos serveurs ou par la Bridge.
Échange de clés Diffie-Hellman
Vous vous demandez peut-être comment la clé commune avec laquelle l’App et Nuki chiffrent vos messages entre-elles, ou plutôt comment elle arrive dans l’App et Nuki sans que celle-ci ne soit décelée par autrui.Au moment de l’appairage entre l’App et Nuki, l’échange de clés Diffie-Hellman a lieu, qui permet de générer une clé secrète connue des deux côtés sans, toutefois, jamais transférer cette clé.
Au départ, les deux côtés – l’App et Nuki – génèrent une paire de clés qui consiste en une clé secrète et en une clé publique. Puis, chaque côté envoie à l’autre sa clé publique. Ensuite, chaque côté calcule la clé secrète finale pour l’autre en prenant comme référence sa propre clé secrète et la clé publique.
La mathématique entre en jeu :
Tout d’abord, il faut deux paramètres qui sont connus des deux côtés ; d’une part, un grand nombre premier p et, d’autre part, un facteur g. Dans l’exemple suivant, nous utilisons des nombres tout petits à des fins de présentation claire.Prenons donc p = 17 et g = 3.
Les deux côtés génèrent un nombre aléatoire (la clé secrète).
L’App choisit par exemple a = 9 et Nuki choisit n = 7.
Maintenant, les deux côtés calculent la clé publique avec la formule gx mod p.
L’App calcule A = ga mod p = 39 mod 17 = 14 et envoie cette clé publique à Nuki. Nuki calcule N = gn mod p = 37 mod 17 = 11 et envoie cette clé publique à l’App. Maintenant, les deux côtés ont les informations requises pour calculer la clé commune avec Xy mod p.
Nuki calcule la clé An mod p = 147 mod 17 et obtient 6.
L’App calcule la clé Na mod p = 119 mod 17 et obtient également 6.
Le chiffre 6 est donc la clé secrète commune qui est utilisée pour la suite de la communication.
Dans cet exemple, nous utilisons, tel que cité plus haut, de tout petits chiffres à des fins de présentation claire. Cette méthode utilise des clés de 32 octets et la clé commune est déduite de la clé calculée au moyen de la dérivation de clé.
Sauvegarde des clés
Les clés sont sauvegardées sur le Smartphone en toute sécurité et ne sont pas accessibles pour d’autres utilisateurs ou d’autres Apps. Toutefois, cela implique que le Smartphone n’a pas été enraciné / débridé.Si un Smartphone autorisé a été perdu, son autorisation d’utiliser Nuki peut être retirée à l’aide d’un autre Smartphone autorisé. Si vous n’avez pas de deuxième Smartphone autorisé, vous pouvez soit en autoriser un nouveau sur place via Bluetooth, soit réinitialiser votre Nuki.
Défi-réponse
Pour empêcher qu’un pirate puisse enregistrer un message – par exemple la commande « déverrouiller » – et lancer un nouveau déverrouillage avec ce message enregistré (une attaque par rejeu), nous utilisons la procédure de défi-réponse.D’abord, un très grand nombre aléatoire est communiqué (défi) à l’autre côté par le canal crypté, que celui-ci doit également mentionné dans la réponse (réponse). Si le côté omet de répondre, ou si un mauvais nombre aléatoire est communiqué, la commande est refusée.
Dans l’exemple avec la fonction de déverrouillage, l’App recevrait d’abord un nombre aléatoire de 32 octets et ne pourrait envoyer la commande de déverrouillage uniquement après à Nuki contenant obligatoirement ce nombre aléatoire.
Si, ensuite, une nouvelle commande de déverrouillage est envoyée à Nuki avec le même nombre aléatoire, celle-ci sera refusée par Nuki.
Le petit tour d’horizon de notre concept de sécurité se termine à cet endroit. Nous espérons avoir pu vous démontrer que la sécurité de votre domicile nous tient énormément à cœur et que nous ne faisons aucune concession en la matière.
Au plaisir de vous relire et tout de bon !
Marc
Directeur technique
