À mesure que des quantités croissantes de données précieuses sont stockées dans le cloud, il est d’autant plus important de les protéger solidement. De solides mesures de sécurité autour des services de données cloud comme iCloud profitent à tout le monde : aux utilisateurs finaux, aux fournisseurs de services cloud comme Apple et aux plateformes d’écosystème comme Reincubate.
Les mécanismes de protection de ces données prennent plusieurs formes, et Apple a un bon bilan dans leur mise en œuvre. Cet article examine plusieurs des techniques qu’Apple, ainsi que l’équipe de Reincubate, utilisent.
Stocker moins, si possible
Premièrement, stocker moins plutôt que plus est payant. Il en existe des exemples où des données n’ont jamais été stockées dans iCloud : par exemple, les données de reconnaissance faciale de Photos ne sont pas stockées dans la Photothèque iCloud, mais mises en cache localement. Les données issues de HealthKit, HomeKit et TouchID d’Apple sont traitées de la même façon, tout comme les données de reconnaissance faciale de l’écran de verrouillage d’Android. Bien sûr, il s’agit souvent d’un compromis entre la commodité et l’intérêt de synchroniser ces données entre les appareils. Certains systèmes adoptent une approche partielle. Par exemple, iMessage stocke une quantité limitée de contenu dans le cloud, mais s’appuie sur une synchronisation directe d’autres données entre les appareils.
Les messageries sécurisées comme Telegram ou WhatsApp adoptent une approche totalement différente. Comme aucune donnée (ou du moins très peu) n’est stockée sur leurs serveurs, un ensemble riche de données doit figurer dans toute sauvegarde d’un appareil pour que l’utilisateur puisse réellement sauvegarder et restaurer. D’une certaine façon, pour préserver la sécurité, ces éditeurs d’apps se désengagent de la gestion de ces données et la laissent à l’utilisateur final, qui peut choisir de sauvegarder ses appareils en local ou dans le cloud.
Il existe donc deux extrêmes : on peut opposer WhatsApp, avec peu de choses dans le cloud et tout dans la sauvegarde, à Facebook Messenger, qui ne stocke rien dans la sauvegarde d’un appareil parce que tout est disponible dans le cloud, et doit l’être pour que Facebook puisse proposer son interface web.
Il n’y a pas de bonne solution ici, mais cela mérite réflexion : utiliser une app qui héberge ces données exige que l’éditeur les gère en toute sécurité, alors que les utilisateurs ne savent souvent pas ce qui est stocké ni comment. Utiliser une app qui ne stocke pas les données de façon centralisée signifie que l’utilisateur final doit assumer la sécurité de ses propres données de sauvegarde, à moins de les laisser stocker dans le cloud de sa plateforme, comme c’est le cas avec les sauvegardes iCloud et les sauvegardes d’appareils Android 7.0+ de Google.
Fait intéressant, comme le montre le graphique ci-dessous, certains éditeurs d’apps occupent les deux extrêmes de cette position. L’app Snapchat stocke presque toutes ses données dans le cloud, tandis que le prolongement physique de l’app, Spectacles, stocke toutes les siennes localement sur l’appareil.
Différentes approches de la sécurité des données d’apps
Bien qu’elles n’aient pas été largement diffusées, les Snapchat Spectacles sont assez peu sécurisées : en maintenant le bouton « snap » enfoncé pendant sept secondes, un pirate peut les associer à un nouveau téléphone et obtenir tous les snaps non chiffrés que leur propriétaire légitime y avait stockés. Cela contraste fortement avec les principes de sécurité adoptés pour l’Apple Watch.
Un chiffrement fort
Cela nous amène à la deuxième technique essentielle : un chiffrement fort, idéalement avec un stockage incomplet des clés. Si des données sont jugées trop sensibles pour être sauvegardées de manière à être accessibles en cas de destruction ou de remplacement d’un appareil, d’autres techniques sont possibles. En exigeant l’utilisation d’un appareil précis, la fonctionnalité « Conversations secrètes » de Facebook utilise des identifiants matériels pour chiffrer le contenu. Si l’appareil est perdu, le contenu devient pratiquement irrécupérable.
Certains systèmes emploient une technique similaire, où un jeton propre à l’appareil peut être créé pour garantir que seul un nombre limité d’appareils peuvent accéder au contenu à la fois. Snapchat et WhatsApp en utilisent chacun une variante. Lorsque vous vous connectez à Snapchat sur un appareil, un jeton est créé et partagé entre les serveurs de Snapchat et l’appareil. Si le même utilisateur se connecte sur un autre appareil, un nouveau jeton est créé, remplaçant celui qui se trouvait auparavant dans le cloud et forçant le premier appareil à se déconnecter, car il ne pourrait plus déchiffrer les messages entrants. Cette technique présente une vulnérabilité évidente sur les systèmes peu sûrs : le jeton peut être copié et utilisé ailleurs. S’il fallait un argument pour expliquer pourquoi utiliser un appareil Android rooté ou un appareil iOS jailbreaké est une très mauvaise idée, le voici, et il explique aussi pourquoi il est peu probable qu’un client web pour Snapchat voie le jour prochainement.
S’il est une chose de perdre éventuellement des messages Facebook secrets, certaines données sont à la fois très sensibles et très précieuses pour leur propriétaire. Cela semble contre-intuitif, mais si la valeur personnelle des données est assez grande, elles sont souvent stockées de façon à offrir de nombreuses possibilités de les déchiffrer ou de les récupérer. On échange ainsi de la sécurité contre moins d’impraticabilité. Par exemple, une masse de données est associée aux comptes iCloud et Google, y compris, dans les deux cas, une forme de trousseau cloud distribué qui stocke tous les mots de passe d’un utilisateur. Plus encore, la promotion par Google de ses comptes comme mécanisme d’authentification sur d’autres sites via OAuth signifie que perdre irrémédiablement l’accès à de tels comptes serait une pilule bien amère à avaler.
Ces comptes étant jugés trop précieux pour risquer facilement leur perte définitive, on recourt à une solution intermédiaire où les données sont stockées dans le cloud, mais chiffrées avec un jeton ou un mot de passe que seul l’utilisateur conserve, et qui n’est pas stocké. C’est pourquoi, par exemple, lorsque vous vous connectez à une nouvelle installation du navigateur Chrome de Google, les mots de passe stockés dans le cloud ne sont pas disponibles tant qu’un mot de passe de synchronisation secondaire n’a pas été saisi dans le navigateur.
Partager la charge du chiffrement
Tim Cook, d’Apple, à la fois sérieux et fondamentalement dans le vrai en matière de sécurité, a attesté de sa conviction dans cette technique pas plus tard que l’an dernier :
For many years, we have used encryption to protect our customers’ personal data because we believe it’s the only way to keep their information safe. We have even put that data out of our own reach, because we believe the contents of your iPhone are none of our business.
— Tim Cook in « A Message to Our Customers »
Entre autres avantages, cela peut aider les fournisseurs de cloud à éviter de divulguer l’intégralité des données des utilisateurs aux autorités publiques. S’ils sont contraints de les fournir par un mandat, ils peuvent le faire sans exposer directement les données d’un utilisateur, car celles-ci nécessitent un déchiffrement supplémentaire, qui ne peut être effectué qu’avec une clé que seul l’utilisateur final possède.
Parfois, comme dans le cas de l’authentification multifacteur (MFA), de l’authentification à deux facteurs (2FA) ou de la vérification en deux étapes (2SV), cela signifie que la clé supplémentaire ne peut être envoyée qu’à un appareil précis ou générée que par lui. Les banques et les VPN utilisent souvent des lecteurs de cartes physiques ou des générateurs de graines sécurisés, qui sont des formes de générateurs de mots de passe à usage unique basés sur le temps (OTP ou TOTP). Google comme Apple proposent une MFA simple par SMS ainsi que des systèmes 2FA complets, celui de Google reposant sur HOTP/OATH et celui d’Apple étant propriétaire.
Lorsque des agences de sécurité ou des services chargés de l’application de la loi (LEA) disposent de ces données chiffrées sans la clé de l’utilisateur final pour les déchiffrer, ils peuvent tenter une attaque par force brute avec des machines puissantes, en testant les données avec des mots de passe devinés automatiquement. Ici, iOS d’Apple a un avantage considérable sur Android de Google : comme Apple contrôle étroitement le matériel de ses appareils, elle peut concevoir des techniques de chiffrement que seul son matériel exécute rapidement et que d’autres appareils, comme les ordinateurs de bureau, exécutent lentement. Lorsque Reincubate est devenue la première entreprise au monde à prendre en charge le déchiffrement des données de la version 10.2, l’importance ne tenait pas seulement au fait que l’entreprise avait été la première à comprendre le fonctionnement de la 10.2 : nous avons été les premiers à passer à l’échelle le déchiffrement rapide de la technique astucieuse d’Apple. En faisant en sorte que chaque tentative de déchiffrement prenne plusieurs secondes sur du matériel conventionnel, la force brute est devenue impraticable pour les pirates ou les LEA.
La sécurité par l’obscurité
Il serait inconvenant de passer en revue ces techniques sans aborder une technique où Apple excelle particulièrement : la sécurité par l’obscurité. En ne publiant pas d’API publiques ni de documentation détaillée, et en communiquant même très peu sur ces systèmes, l’entreprise évite d’attirer l’attention des pirates sur d’éventuels vecteurs d’attaque. Pendant longtemps, l’argument contre l’obscurité était que la divulgation et l’open source conduisaient à de meilleurs résultats en matière de sécurité, mais c’était avant la découverte, en 2014, qu’OpenSSL, une bibliothèque de sécurité open source essentielle que presque tout le monde utilise, était, et a presque toujours été, fondamentalement peu sûre.
N’hésitez pas à nous contacter si vous souhaitez explorer des façons de travailler avec des données d’apps ou du cloud, ou si vous souhaitez mieux comprendre la dynamique des différentes approches.
