Chiffrement iCloud expliqué : ce qu’Apple protège, ce qu’il ne protège pas

TL;DR

Le chiffrement iCloud standard protège les données en transit et au repos sur les serveurs d’Apple, mais Apple conserve les clés de chiffrement pour la plupart des catégories. La Protection avancée des données (PAD) bascule 23 catégories de données vers un chiffrement de bout en bout, supprimant l’accès d’Apple aux clés. Sauvegarde iCloud, Photos et iCloud Drive rejoignent cette liste uniquement avec la PAD. Même avec la PAD activée, Apple ne peut pas lire vos données de santé, votre trousseau iCloud ou vos réglages Temps d’écran – ceux‑ci étaient déjà chiffrés de bout en bout. Aucun niveau iCloud, y compris la PAD, ne chiffre les métadonnées (noms de fichiers, dates, structure des dossiers) avec des clés contrôlées par l’utilisateur. Un coffre-fort local comme App-Vault, qui n’envoie jamais de données vers un serveur et dérive les clés à l’intérieur du Secure Enclave, fonctionne en dehors de l’infrastructure d’Apple – pas de gestion de clés dans le cloud, pas d’exposition des métadonnées, pas de porte dérobée de récupération de compte.

Apple chiffre les données iCloud. Cette affirmation est vraie, mais elle est aussi incomplète. Le chiffrement se décline en couches, et chaque couche répond à une question différente sur qui peut lire vos données.

La première couche est le chiffrement de transport. Chaque bit qui voyage entre votre iPhone et les serveurs d’Apple circule à l’intérieur d’un tunnel TLS 1.3. Un attaquant sur le même Wi‑Fi de café ne peut pas voir vos photos, vos notes ou vos événements de calendrier en transit. Cette protection est universelle et toujours active.

La deuxième couche est le chiffrement côté serveur. Une fois que les données atteignent les centres de données d’Apple, elles sont écrites sur disque sous forme chiffrée avec AES‑256. Les modules de sécurité matériels (HSM) d’Apple gèrent les clés de gaine. Cela signifie qu’un attaquant physique qui vole des disques durs d’un centre de données Apple ne peut pas lire les octets bruts sans les clés stockées dans ces HSM.

La troisième couche est la propriété des clés. C’est là que se situe la plupart des confusions. Avec le chiffrement iCloud standard, Apple détient les clés. Avec la Protection avancée des données, vous détenez les clés pour la plupart des catégories de données. La différence n’est pas académique – elle détermine si Apple peut se conformer à une demande légale pour vos données, si Apple peut réinitialiser l’accès à votre compte, et si un employé ayant des privilèges dans le centre de données pourrait théoriquement accéder à votre texte en clair.

Ce guide décrit l’architecture de chiffrement d’Apple telle qu’elle se présente sous iOS 19 et macOS Sequoia. Il couvre ce que chaque niveau protège, ce que la Protection avancée des données change réellement, et où un coffre‑fort local comme App-Vault fonctionne en dehors de l’infrastructure d’Apple.

Chiffrement iCloud standard – Apple détient les clés

Lorsque vous vous connectez à iCloud sans activer la Protection avancée des données, Apple chiffre vos données à deux endroits : sur le fil et sur le disque. Mais Apple détient aussi les clés de déchiffrement.

Le mécanisme technique est simple. Votre appareil négocie une session TLS avec les serveurs périphériques d’Apple. Les données sont chiffrées avec des clés de session dérivées lors de cette poignée de main. Sur le serveur, les données sont rechiffrées avec une clé de stockage gérée par le service de gestion de clés d’Apple. Cette clé de stockage réside dans un HSM qui nécessite plusieurs approbations administratives pour fonctionner.

Apple publie une description détaillée des catégories de données et de leur hiérarchie de clés dans le guide de sécurité de la plateforme Apple. Le tableau pertinent liste 23 catégories de données et marque chacune comme « chiffrée de bout en bout » ou « chiffrée avec des clés détenues par Apple ».

Avec le chiffrement standard, les catégories majeures suivantes utilisent des clés détenues par Apple :

• Sauvegarde iCloud (inclut les sauvegardes d’appareil contenant photos, messages, données d’apps)
• Photos iCloud
• iCloud Drive
• Notes (sauf si l’utilisateur a activé la fonction distincte de mot de passe pour Notes)
• Données Calendrier
• Contacts
• Rappels
• Marque‑pages Safari et liste de lecture
• Raccourcis Siri et données d’intention
• Tableaux Freeform
• Passes Wallet
• Recherches et itinéraires récents Plans
• Mail iCloud (Apple ne peut pas lire le courrier en transit, mais le stocke avec des clés détenues par Apple)

Pour chacune de ces catégories, Apple peut déchiffrer les données. C’est voulu – Apple a besoin de l’accès aux clés pour prendre en charge la récupération de compte, l’accès via iCloud.com et des fonctionnalités comme les albums photo partagés où plusieurs utilisateurs doivent déchiffrer le même élément.

La conséquence pratique est directe. Si Apple reçoit une demande légale valide pour vos données iCloud, Apple peut fournir le texte en clair pour n’importe laquelle de ces catégories. Les directives d’Apple concernant les demandes des forces de l’ordre confirment cette capacité. Apple publie un rapport de transparence qui liste le nombre de comptes concernés par de telles demandes.

Protection avancée des données – clés contrôlées par l’utilisateur

La Protection avancée des données, introduite avec iOS 16.2 et étendue depuis, modifie le modèle de propriété des clés pour la plupart des catégories de données iCloud. Au lieu que les HSM d’Apple détiennent les clés de gaine, les clés sont dérivées sur votre appareil et adossées à votre Trousseau iCloud, lui‑même chiffré de bout en bout.

Avec la PAD, les catégories suivantes deviennent chiffrées de bout en bout :

• Sauvegarde iCloud
• Photos iCloud
• iCloud Drive
• Notes
• Données Calendrier
• Contacts
• Rappels
• Marque‑pages Safari
• Raccourcis Siri
• Tableaux Freeform
• Passes Wallet
• Recherches et itinéraires récents Plans
• Mémos vocaux
• Historique Safari
• Informations de paiement (Apple Pay)
• Raccourcis
• Données Bourse
• Données Météo
• Données Maison
• Données News
• Données Game Center
• Mail iCloud (toujours chiffré avec des clés détenues par Apple – Mail est exclu de la PAD)

Apple ne peut déchiffrer aucune de ces catégories lorsque la PAD est activée. Apple ne peut pas se conformer à une demande légale pour le contenu de votre Sauvegarde iCloud, de votre bibliothèque Photos ou de vos fichiers iCloud Drive. Apple ne peut pas réinitialiser vos clés si vous perdez l’accès à votre compte.

La contrepartie est la complexité de récupération. Avec la PAD activée, vous devez configurer au moins un contact de récupération ou générer une clé de récupération de 28 caractères. Sans cela, vos données chiffrées de bout en bout deviennent définitivement inaccessibles si vous perdez l’accès à tous vos appareils de confiance et à votre Trousseau iCloud. Apple ne peut pas vous aider.

La PAD exige également que tous les appareils connectés à votre compte iCloud exécutent au moins iOS 16.2, macOS 13.1 ou watchOS 9.2. Les appareils avec un logiciel plus ancien ne peuvent pas recevoir les données chiffrées de bout en bout et sont exclus de la synchronisation.

Ce que la Protection avancée des données ne couvre PAS

Trois catégories de données iCloud restent chiffrées avec des clés détenues par Apple même avec la PAD :

• Mail iCloud. Apple chiffre le courrier en transit, mais le stocke avec des clés détenues par Apple. Apple peut lire votre courrier si la loi l’exige. En effet, le courrier doit interopérer avec des serveurs de messagerie non‑Apple qui ne prennent pas en charge le chiffrement de bout en bout.
• Contacts, Calendrier et Rappels iCloud lorsque consultés via iCloud.com. L’interface web nécessite qu’Apple ait accès aux clés. La synchronisation sur l’appareil est chiffrée de bout en bout avec la PAD.
• Métadonnées. Les noms de fichiers, dates de création, dates de modification, hiérarchies de dossiers, tailles de fichiers et miniatures ne sont pas chiffrés de bout en bout, quel que soit le niveau. Les serveurs d’Apple ont besoin des métadonnées pour permettre la recherche, le tri et la synchronisation.

Le point sur les métadonnées mérite d’être souligné. Même avec la PAD activée, les serveurs d’Apple savent combien de fichiers vous avez dans iCloud Drive, comment chaque fichier s’appelle, quand il a été créé et dans quel dossier il se trouve. Apple ne connaît pas le contenu des fichiers, mais les métadonnées seules peuvent révéler des informations substantielles sur vos activités.

Chiffrement de la Sauvegarde iCloud – la catégorie la plus importante

La Sauvegarde iCloud mérite sa propre section car c’est le plus grand référentiel de données iPhone pour la plupart des utilisateurs. Une Sauvegarde iCloud standard contient :

• Réglages et préférences de l’appareil
• Messages et pièces jointes
• Photos et vidéos pas déjà dans Photos iCloud
• Données d’applications tierces (pour la plupart)
• Disposition de l’écran d’accueil et organisation des apps
• Données de santé (bien que Santé soit chiffré de bout en bout en transit, il est inclus dans la sauvegarde avec le chiffrement standard)
• Historique des appels
• Messagerie vocale
• État Safari

Avec le chiffrement iCloud standard, Apple détient les clés de votre sauvegarde. Avec la PAD, la sauvegarde devient chiffrée de bout en bout.

La distinction compte pour quiconque stocke des documents sensibles sur son iPhone. Les sources d’un journaliste, les communications privilégiées d’un avocat, les notes d’un professionnel de santé – tout cela peut se retrouver dans la Sauvegarde iCloud même si l’utilisateur ne l’a jamais explicitement placé. Les données des applications sont incluses automatiquement, sauf si le développeur choisit de les exclure.

Apple fournit un mécanisme permettant aux développeurs de marquer des données d’application comme exclues de la sauvegarde. L’attribut NSURLIsExcludedFromBackupKey indique à iOS de ne pas inclure un fichier dans la Sauvegarde iCloud. App-Vault utilise cet attribut pour ses fichiers de coffre‑fort chiffrés. Combiné avec l’architecture zéro‑appel réseau d’App-Vault, le texte chiffré d’App-Vault n’atteint jamais les serveurs d’Apple – pas même dans une sauvegarde protégée par la PAD.

La lacune – ce que le chiffrement iCloud ne peut pas protéger

Le chiffrement iCloud, même à son niveau le plus fort, fonctionne à l’intérieur de l’infrastructure d’Apple. Cela signifie que trois catégories de données restent exposées :

Métadonnées. Comme nous l’avons vu, les noms de fichiers, la structure des dossiers et les horodatages sont visibles par Apple. Pour de nombreux utilisateurs, les métadonnées sont presque aussi révélatrices que le contenu. Un dossier nommé « Documents médicaux 2025 » avec un fichier appelé « Résultat de biopsie.pdf » dit tout à un observateur, même si le contenu du fichier est chiffré.

Données d’applications tierces. Les applications qui stockent des données en clair sur l’appareil et comptent sur la Sauvegarde iCloud pour la persistance laissent ces données accessibles à Apple avec le chiffrement standard. L’utilisateur n’a aucun contrôle sur les données d’apps sauvegardées, sauf si le développeur les exclut explicitement.

Télémétrie réseau. Les services iCloud génèrent des journaux et des analyses qu’Apple utilise pour la supervision opérationnelle. Apple déclare que ces journaux ne contiennent pas de contenu utilisateur, mais ils contiennent des métadonnées sur quand et comment les services sont consultés.

Récupération de compte. Avec le chiffrement standard, Apple peut réinitialiser l’accès à votre compte iCloud. Avec la PAD, vous pouvez définir un contact de récupération ou une clé, mais le processus de récupération lui‑même exige qu’Apple vérifie votre identité – une procédure qui peut être contournée par ingénierie sociale.

Un coffre‑fort local comme App-Vault fonctionne en dehors de toutes ces catégories. App-Vault n’effectue aucun appel réseau par défaut. Aucune métadonnée ne quitte l’appareil. Aucun nom de fichier n’est transmis. Aucun horodatage n’est journalisé. Même le fichier de coffre‑fort chiffré est exclu de la Sauvegarde iCloud. Apple ne voit rien.

Où se situe App-Vault dans le paysage du chiffrement

L’architecture d’App-Vault est fondamentalement différente du chiffrement iCloud car elle n’utilise pas du tout d’infrastructure cloud.

La pile de chiffrement est simple :

• Chiffre : AES‑256 en mode Galois/Counter (GCM), avec un nonce unique de 96 bits généré par fichier. Les références canoniques sont NIST FIPS 197 et NIST SP 800‑38D. Le nonce garantit que chiffrer deux fois le même fichier produit un texte chiffré différent.
• Dérivation de clé : PBKDF2‑SHA256 à 600 000 itérations, avec un sel de 128 bits par installation. Cela suit la recommandation de l’OWASP Password Storage Cheat Sheet pour l’étirement de clé.
• Liaison matérielle : La sortie de PBKDF2 est gainée par une clé générée à l’intérieur du Secure Enclave de l’iPhone. La clé du Secure Enclave ne quitte jamais la puce. Même le propre code d’App-Vault ne peut pas l’extraire.
• Pas de serveurs : App-Vault n’effectue aucun appel réseau par défaut. La sauvegarde iCloud chiffrée est optionnelle, et les fichiers sont scellés avec une clé de sauvegarde par appareil distincte avant l’envoi. Apple ne reçoit que du texte chiffré que le code d’App-Vault peut déchiffrer.
• Pas de compte : Pas d’adresse e-mail, pas de télémétrie, pas de SDK tiers. L’étiquète nutritionnelle de confidentialité déclare « aucune donnée collectée ».
• Chiffrement du catalogue : Même la liste des fichiers – nombre, noms, dates – est scellée. Un attaquant ayant un accès brut à l’appareil ne peut pas déterminer combien de fichiers le coffre‑fort contient.

Cette architecture signifie qu’App-Vault n’a pas besoin de répondre à la question « qui détient les clés ? » car les clés ne quittent jamais l’appareil. Il n’y a pas de gestion de clés dans le cloud, pas de gaine HSM, pas de porte dérobée de récupération de compte. Le coffre‑fort est soit déverrouillé par le motif de l’utilisateur, soit scellé.

La page du modèle de menace (en anglais) documente contre quoi App-Vault se défend et contre quoi il ne se défend pas. La version courte : App-Vault protège contre le vol d’appareil, l’extraction forensique, le shoulder‑surfing et l’accès non autorisé à iCloud. Il ne protège pas contre un appareil compromis avec un jailbreak ni contre un utilisateur contraint de déverrouiller le coffre‑fort.

Recommandations pratiques

Pour la plupart des utilisateurs : Activez la Protection avancée des données. Le compromis sur la complexité de récupération vaut le gain en propriété des clés. Le document d’aide d’Apple vous guide dans la configuration.

Pour les journalistes, avocats et professionnels de santé : Activez la PAD et utilisez un coffre‑fort local comme App-Vault pour les documents qui ne doivent jamais apparaître dans aucune infrastructure cloud. Même avec la PAD, l’exposition des métadonnées et le risque qu’un contact de récupération soit compromis sont des préoccupations réelles.

Pour toute personne vendant ou échangeant un iPhone : La PAD n’aide pas pour les données résiduelles sur l’appareil lui‑même. Une réinitialisation d’usine est nécessaire. Même alors, des outils forensiques peuvent parfois récupérer des fragments. Un coffre‑fort qui chiffre avec des clés liées au Secure Enclave et une architecture zéro‑réseau garantit qu’aucune copie cloud de fichiers sensibles n’existe pour être récupérée plus tard.

Pour les familles partageant un iPad : La fonction Coffre‑fort leurre fournit un second catalogue de coffre‑fort mathématiquement indépendant, accessible via un motif 5×5 distinct. Cela est utile lorsqu’un seul appareil sert plusieurs personnes. Le Lanceur calculatrice offre une couche discrétionnaire supplémentaire – une calculatrice iOS entièrement fonctionnelle avec un raccourci optionnel par appui long sur la touche égale vers le coffre‑fort chiffré.

En résumé

Le chiffrement iCloud est solide, mais sa force dépend entièrement de qui détient les clés. Le chiffrement standard protège contre les attaquants extérieurs mais pas contre Apple lui‑même. La Protection avancée des données transfère la propriété des clés à l’utilisateur pour la plupart des catégories, mais laisse les métadonnées exposées et exige une planification minutieuse de la récupération.

Un coffre‑fort local comme App-Vault fonctionne sur un modèle complètement différent. Pas de cloud, pas de séquestre de clés, pas de transmission de métadonnées, pas de récupération de compte. Le chiffrement AES‑256‑GCM et la gaine de clé par Secure Enclave garantissent que la seule personne qui peut ouvrir le coffre‑fort est celle qui connaît le motif.

Ces deux approches ne sont pas concurrentes. Elles répondent à des modèles de menace différents. Le chiffrement iCloud protège vos données contre la perte d’appareil et les pannes matérielles. Un coffre‑fort local protège vos données contre l’infrastructure cloud elle‑même. Pour toute personne dont les documents nécessitent la plus forte de ces deux garanties, le choix est clair.