Facteurs de sécurisation des données des applications et du cloud
Avec la quantité croissante de données précieuses stockées dans le nuage, il est d'autant plus important que celles-ci soient protégées de manière robuste. Des mesures de sécurité strictes autour des services de données en nuage tels que iCloud profitent à tous: utilisateurs finaux, fournisseurs de services en nuage comme Apple et plates-formes écosystémiques comme Reincubate.
Les mécanismes de protection de ces données prennent plusieurs formes et les résultats obtenus par Apple en la matière sont satisfaisants. Cet article examine un certain nombre de techniques qu’ils ont utilisées, ainsi que l’équipe de Reincubate.
Stocker moins - si possible
Tout d’abord, stocker moins que plus rapporte. Dans certains cas, les 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 artefacts de données de HealthKit, HomeKit et TouchID d'Apple sont traités de la même manière, tout comme les données de reconnaissance faciale sur écran verrouillé d'Android. Bien sûr, cela représente souvent un compromis entre commodité et intérêt de la synchronisation de ces données entre périphériques. Certains systèmes utilisent une approche partielle. Par exemple, iMessage stocke une quantité limitée de contenu dans le cloud, mais repose sur la synchronisation directe d’autres données entre appareils.
Les systèmes de messagerie sécurisés tels que Telegram ou WhatsApp adoptent une approche complètement différente. Etant donné qu'aucune donnée (ou du moins pas beaucoup) n'est stockée sur leurs serveurs, un jeu de données riche doit être inclus dans toute sauvegarde d'un périphérique pour qu'un utilisateur puisse réellement effectuer une sauvegarde et une restauration. D'une certaine manière, pour maintenir la sécurité, ces fournisseurs d'applications se lavent la main de la gestion de ces données et la laissent à l'utilisateur final, qui peut choisir de sauvegarder ses appareils localement ou sur le cloud.
Il existe donc deux extrêmes et on peut opposer WhatsApp - avec peu dans le cloud et tout le contenu de la sauvegarde - à Facebook Messenger, qui ne stocke rien dans une sauvegarde de périphérique car il est facilement disponible dans le cloud, et doit être en ordre pour Facebook pour fournir son interface web.
Il n’ya pas de bonne solution ici, mais il faut réfléchir: l’utilisation d’une application qui héberge ces données nécessite que le fournisseur de l’application les gère de manière sécurisée, souvent les utilisateurs ne savent pas ce qui est stocké et comment. L'utilisation d'une application qui ne stocke pas les données de manière centralisée signifie que l'utilisateur final doit assumer la responsabilité de la sécurité de ses propres données de sauvegarde. 7.0+ sauvegardes de périphériques.
Fait intéressant, comme dans le tableau ci-dessous, certains fabricants d'applications occupent les deux extrêmes de cette position. L’application Snapchat stocke la quasi-totalité de ses données dans le nuage, tandis que son extension physique, Spectacles , stocke l’ensemble de leurs données localement sur l’appareil.
Bien que non largement déployé, Snapchat Spectacles n’est pas très sûr: en maintenant le bouton «Snap» enfoncé pendant sept secondes, un pirate informatique peut les associer à un nouveau téléphone et obtenir l’un des snaps non cryptés qui ont été stockés par le propriétaire légitime. Cela contraste nettement avec les principes de sécurité adoptés pour l'Apple Watch.
Cryptage fort
Cela nous amène à la deuxième technique critique: le cryptage fort , idéalement avec un stockage incomplet des clés. Si les données sont jugées trop sensibles pour être sauvegardées de manière à pouvoir y accéder en cas de destruction ou de remplacement d'un périphérique, d'autres techniques peuvent être utilisées. En exigeant l'utilisation d'un appareil spécifique, la fonction « 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 utilisent une technique similaire dans laquelle un jeton spécifique à un périphérique peut être créé pour garantir que seul un nombre limité de périphériques puisse accéder au contenu à la fois. Snapchat et WhatsApp utilisent chacun une variante de cela. Lors de la connexion à 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 à un autre périphérique, un nouveau jeton sera créé, remplaçant ce qui était auparavant sur le nuage et obligeant le premier périphérique à se déconnecter car il ne pourrait décrypter aucun message entrant. Il existe une vulnérabilité évidente à cette technique lorsqu'elle est utilisée sur des systèmes non sécurisés: le jeton peut être copié et utilisé ailleurs. Si un argument était nécessaire pour expliquer pourquoi l’utilisation d’un appareil Android rooté ou iOS est une idée terrible, c’est cela, et cela explique également pourquoi il est peu probable qu’il y ait un client Web pour Snapchat dans un avenir proche.
S'il est potentiellement dangereux de perdre 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, si les données sont suffisamment volumineuses, est souvent stockée de manière à ce qu’il existe de nombreux moyens de les décrypter ou de les récupérer. Ceci échange la sécurité avec une impraticabilité réduite. Par exemple, il existe une masse de données associée aux comptes iCloud et Google, y compris - dans les deux cas, une forme de trousseau de cloud distribué, stockant tous les mots de passe d'un utilisateur. De plus, la promotion de leurs comptes par Google en tant que mécanisme d'authentification sur d'autres sites dotés de la technologie OAuth signifie que perdre irrémédiablement l'accès à des comptes comme ceux-ci serait une pilule amère à avaler.
Étant donné que ces comptes sont jugés trop précieux pour risquer leur perte définitive, une solution intermédiaire est utilisée lorsque les données sont stockées sur le cloud, mais cryptées avec un jeton ou un mot de passe que seul l'utilisateur conserve et qui ne sont pas stockées. C'est pourquoi, par exemple, lors de la connexion à une nouvelle installation du navigateur Google Chrome, les mots de passe stockés dans le nuage ne sont disponibles que lorsqu'un mot de passe de synchronisation secondaire a été entré dans le navigateur.
Partager la charge du cryptage
Tim Cook d'Apple, qui est à la fois sérieux et fondamentalement respectueux de la sécurité, a attesté de sa confiance en cette technique l'année dernière:
Pendant de nombreuses années, nous avons utilisé le cryptage pour protéger les données personnelles de nos clients, car nous croyons que c'est le seul moyen de protéger leurs informations. Nous avons même mis ces données hors de notre portée, car nous estimons que le contenu de votre iPhone ne nous regarde pas.
- Tim Cook dans " Un message à nos clients "
Mis à part tout, cela peut aider les fournisseurs de cloud à éviter de divulguer des données utilisateur complètes aux acteurs gouvernementaux. S'ils sont obligés de le fournir en vertu d'un mandat, ils peuvent le faire sans exposer directement les données d'un utilisateur, car les données 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 multi-facteurs (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 à ou générée que par un périphérique particulier. Les banques et les VPN utilisent souvent des lecteurs de cartes physiques ou des générateurs de semences sécurisés , qui sont des formes de générateurs de mots de passe à utilisation unique basés sur le temps (OTP ou TOTP). Google et Apple proposent tous deux une simple MFA basée sur SMS, ainsi que des systèmes 2FA complets, Google utilisant HOTP / OATH et Apple étant propriétaire.
Lorsque les agences de sécurité ou de maintien de l'ordre (LEA) disposent de ces données chiffrées mais ne disposent d'aucune clé pour les déchiffrer, elles peuvent tenter de les forcer brutalement à l'aide de machines puissantes pour tester les données en fonction de mots de passe automatiquement devinés. Ici, iOS possède un avantage considérable par rapport à Android de Google: dans la mesure où Apple contrôle étroitement le matériel de leurs appareils, ils sont en mesure de concevoir des techniques de cryptage que seul leur matériel peut exécuter rapidement et que d’autres appareils, tels que les ordinateurs de bureau, exécutent lentement. Lorsque Reincubate est devenu la première entreprise au monde à prendre en charge le déchiffrement des données à partir de 10.2 , il était important de comprendre en premier lieu le fonctionnement de 10.2 - nous étions les premiers à décrypter rapidement la technique intelligente d'Apple. En effectuant chaque tentative de décryptage en quelques secondes sur du matériel classique, il était devenu peu pratique pour les pirates informatiques ou le LEA de recourir à la force brutale.
La sécurité à travers l'obscurité
Il ne serait pas bon de revoir ces techniques sans en couvrir une pour laquelle Apple est particulièrement douée: la sécurité par l'obscurité. En ne libérant pas les API publiques, la documentation détaillée ou même en communiquant beaucoup sur ces systèmes, la société est en mesure d'éviter d'alerter les pirates informatiques des vecteurs d'attaques potentiels. 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é critique Open Source utilisée pratiquement par tout, était et a presque toujours été fondamentalement insécurisée .
Contactez- nous si vous souhaitez explorer des façons de travailler avec des données d'applications ou en nuage, ou si vous souhaitez mieux comprendre la dynamique des différentes approches.
