Comment ajouter un cryptage au niveau de l'application à une connexion Android BLE?
Le Bluetooth Low Energy Android documentation recommande d' ajouter le chiffrement de couche d'application en haut de la connexion BLE si les données échangées sont sensibles:
Attention : lorsqu'un utilisateur associe son appareil à un autre appareil à l'aide de BLE, les données communiquées entre les deux appareils sont accessibles à toutes les applications sur l'appareil de l'utilisateur.
Pour cette raison, si votre application capture des données sensibles, vous devez mettre en œuvre la sécurité de la couche d'application pour protéger la confidentialité de ces données.
Comme je voudrais éviter de "rouler mon propre cryptage", je recherche un moyen prêt pour la production de crypter des paquets.
J'ai un canal hors bande pour échanger un message (par exemple une clé) d'un participant à l'autre (code QR). Les deux participants sont des appareils Android, l'un fonctionnant en mode serveur (périphérique) et l'autre en tant que client (central).
J'ai regardé le Noise Protocol Framework comme une alternative plus légère à TLS, mais j'ai l' impression que c'est encore trop de travail manuel (?).
Existe-t-il une solution simple? Il semble que ce soit un problème résolu.
Réponses
Tout d'abord, un conseil: StackExchange n'est pas destiné à recommander des produits spécifiques, je vais donc être relativement général ici. Quiconque lit cela à l'avenir peut se trouver dans un monde où il existe de nouvelles et bien meilleures alternatives, ou même où la vieille garde s'est avérée brisée.
Il existe plusieurs bibliothèques de chiffrement de haut niveau qui, avec une clé pré-partagée, gèrent le chiffrement des messages ou éventuellement du flux (et les exigences de sécurité associées telles que l'intégrité des données) avec un minimum d'effort. Une simple recherche de "bibliothèque cryptographique facile" vous permettra de trouver des candidats. Notez que beaucoup de gens ignorent le conseil de ne pas lancer votre propre crypto, et certains d'entre eux le publient, vous voulez donc vous assurer que la bibliothèque que vous choisissez est bien examinée par des experts, idéalement sans rapport avec son développement.
Vous voudrez également tenir compte de ce que vous voulez (et avez besoin) exactement de votre bibliothèque. Doit-il prendre en charge des flux chiffrés de longueur arbitraire (ou des messages très volumineux qui ne tiennent pas facilement en mémoire), ou un simple protocole basé sur des messages fonctionnera-t-il? La bibliothèque doit-elle être très petite, en termes d'encombrement d'installation ou d'utilisation de RAM? Très rapide, sur un processeur particulier? Compatible avec une autre bibliothèque particulière? Utilisez des chiffrements spécifiques ou d'autres primitives pour des raisons de conformité (j'espère que non)? Disponible dans une langue particulière?
Pour quelques exemples bien considérés à la mi-2020, considérez LibSodium ou Monocypher . Les deux sont bien considérés, évalués et axés sur la facilité d'utilisation. D'autres alternatives sont NaCl, LibHydrogen, et ainsi de suite. Notez que tous ces éléments ne se concentrent pas de manière égale sur la sécurité, la vitesse ou la commodité; par exemple, TweetNaCl met l'accent sur une taille de code minimale, sacrifiant beaucoup de vitesse et potentiellement une certaine sécurité dans le processus, par rapport au NaCl d'origine.