Explication de l’architecture interne d’iMessage

 (jjtech.dev)
3 points par GN⁺ 2023-12-06 | 1 commentaires | Partager sur WhatsApp
  • iMessage utilise APNs non pas comme un simple canal de notification, mais comme une base de transmission bidirectionnelle, et regroupe via IDS l’enregistrement/la consultation des clés publiques ainsi que la préparation de l’acheminement des messages
  • Après s’être connecté à APNs, l’appareil reçoit un push token et filtre le topic iMessage com.apple.madrid pour déterminer le périmètre des messages à recevoir
  • L’enregistrement IDS exige un jeton d’authentification Apple ID, un certificat de longue durée, l’envoi des clés publiques de chiffrement et de signature, ainsi que la soumission de validation data, ce qui est conçu pour rendre difficile l’usage depuis des appareils non Apple
  • Le chiffrement des messages se divise entre l’ancien format pair et le nouveau pair-ec; pair-ec offre une forward secrecy fondée sur des pre-keys, similaire à Signal
  • L’expéditeur peut envoyer séparément une charge utile chiffrée pour chaque destinataire, ou les regrouper, mais pour que les appareils récents puissent déchiffrer, la clé AES doit inclure un tag HMAC

La couche de transport iMessage assurée par APNs

  • L’une des couches de base d’iMessage est Apple Push Notification Service(APNs)
  • APNs est la même couche de service que celle utilisée par les apps de l’App Store pour recevoir des notifications et mises à jour en temps réel même lorsqu’elles sont fermées
  • Dans iMessage, APNs ne sert pas seulement à recevoir des notifications, mais fonctionne aussi comme un service bidirectionnel utilisé pour transmettre des messages
  • Lorsqu’un appareil se connecte à APNs, il reçoit un push token
    • Ce jeton sert à router les notifications vers un appareil précis
    • Il est techniquement différent du jeton reçu via l’API application:didRegisterForRemoteNotificationsWithDeviceToken:
    • Le jeton de cette API est scoped par app et demandé avec le bundle ID de l’application, mais son objectif est similaire
  • Pour envoyer une push notification à un appareil, il faut aussi spécifier le topic du message
    • Un topic ressemble généralement à un Bundle ID
    • Le topic d’iMessage est com.apple.madrid
  • Lorsqu’un appareil se connecte à APNs, il envoie un filter message indiquant au serveur quels messages doivent lui être transmis
    • Le serveur APNs est aussi appelé APNs Courier
    • Un filter message peut contenir une liste de topics par état
    • L’état d’un topic peut être enabled, opertunistic, paused ou disabled

Requêtes IDS au-dessus d’APNs

  • APNs ne sert pas uniquement à la livraison effective des messages iMessage
  • Via une couche pseudo-HTTP au-dessus d’APNs, IDS peut envoyer des requêtes et recevoir des réponses
  • Pour se connecter à APNs, un certificat client émis par l’Albert activation server est nécessaire

IDS et flux d’authentification Apple ID

  • IDS joue le rôle de serveur de clés d’iMessage et est aussi utilisé pour d’autres services comme FaceTime
  • IDS semble être l’abréviation de IDentity Services, mais il est indiqué qu’il n’existe pas de confirmation officielle
  • iMessage utilisant le chiffrement de bout en bout, les clés publiques de chaque participant doivent être échangées de manière sûre
  • La première étape de l’enregistrement IDS consiste à obtenir un jeton d’authentification
    • Il faut fournir à l’API le nom d’utilisateur et le mot de passe de l’Apple ID
  • La 2FA a été intégrée ultérieurement à l’API IDS sous une forme adaptée
    • L’ancienne méthode consistait à ajouter directement le code 2FA au mot de passe
    • La méthode GrandSlam prouve, via des “Anisette data”, qu’il s’agit du même appareil afin d’éviter de ressaisir le code 2FA
    • Ensuite, un Password Equivalent Token(PET) peut être obtenu et utilisé comme un mot de passe avec code 2FA
  • Après avoir reçu le jeton d’authentification, il faut immédiatement l’échanger contre un certificat plus durable
    • Ce certificat permet l’enregistrement IDS, mais ne suffit pas à lui seul pour effectuer des consultations de clés

Enregistrement IDS et validation data

  • L’étape la plus importante dans la configuration d’IDS est le registration
  • Lors du registration, les clés publiques de chiffrement et de signature sont envoyées au serveur de clés
  • Diverses client data décrivant les fonctionnalités prises en charge par l’appareil sont également envoyées
  • Une requête de registration IDS exige un blob binaire appelé “validation data”
    • Il s’agit du mécanisme de validation d’Apple visant à empêcher les appareils non Apple d’utiliser iMessage
  • La génération des validation data utilise des informations comme le serial number, le modèle et le disk UUID de l’appareil
    • Toutes les validation data ne peuvent pas être traitées de la même manière
    • Comme avec un Hackintosh, l’âge du compte et le “score” déterminent si un serial erroné peut être utilisé ou si une erreur “customer code” se produit
  • Le binaire qui génère les validation data est fortement obfusqué
    • pypush contourne ce problème en émulant le binaire obfusqué avec un chargeur mach-o personnalisé et Unicorn Engine
    • pypush fournit au binaire émulé les attributs de l’appareil, comme le serial number, dans un fichier data.plist

Consultation de clés et session token

  • Après l’enregistrement IDS, on reçoit une identity keypair
  • Cette keypair permet d’effectuer des consultations de clés publiques
  • En fournissant le compte à consulter, on reçoit une liste d’“identities”
    • Chaque identity correspond à un appareil enregistré sur ce compte
    • Elle contient des informations importantes comme la public key, le push token et le session token
  • Le session token est nécessaire pour envoyer un message à un appareil
    • Il sert à prouver qu’une consultation a été effectuée récemment
    • Le session token expire
    • Il ne peut être utilisé que par le compte ayant effectué la requête de consultation et ne peut donc pas être partagé

Messages reçus et formats de chiffrement

  • Pour recevoir des messages, il suffit de filtrer la connexion APNs sur com.apple.madrid et d’envoyer un active state packet
  • Le format de chiffrement des messages reçus dépend des capabilities annoncées lors de l’enregistrement IDS et de la version d’iOS de l’appareil expéditeur
    • L’ancien format, pré-iOS 13, est pair
    • Le nouveau format est pair-ec
  • Le format pair est davantage documenté et plus facile à implémenter
  • Contrairement au nouveau pair-ec, pair n’offre pas de forward secrecy via des “pre-keys”
  • Les messages peuvent être déchiffrés en s’appuyant sur plusieurs articles de recherche et sur l’implémentation de pypush
  • La vérification des signatures des messages est facultative, mais importante pour créer un client sûr

Modes d’envoi et points d’attention pour l’implémentation

  • L’envoi de messages ressemble assez au processus inverse de la réception
  • Les messages peuvent être envoyés individuellement à chaque destinataire
  • Il est aussi possible de regrouper plusieurs destinataires et la charge utile chiffrée destinée à chacun dans un grand bundle
    • Dans ce cas, APNs le sépare
  • Les messages sont transmis à tous les participants de la conversation
    • Ils sont aussi transmis aux autres appareils de son propre compte
  • Un point souvent oublié lors de l’envoi est que l’AES key n’est pas totalement aléatoire
    • Un HMAC est attaché à l’AES key sous forme de tag
    • Si l’on utilise une AES key totalement aléatoire, le déchiffrement du message échoue sur les appareils récents

Implémentations liées et références

À lire aussi

1 commentaires

 
GN⁺ 2023-12-06
Commentaires sur Hacker News

  • On dirait qu’Apple va commencer à verrouiller iMessage avec l’attestation (DeviceCheck)
    Le problème, c’est que les anciens appareils auraient alors besoin d’une mise à jour logicielle

    • En partie, c’est déjà le cas
      Lors de la création des « validation data », des informations comme le numéro de série de l’appareil, le modèle ou l’UUID du disque sont utilisées, et selon l’âge du compte et son « score », comme sur un Hackintosh, cela détermine si l’on peut utiliser un faux numéro de série ou si l’on obtient une erreur « customer code »
      L’erreur « customer code » est en fait pratiquement une invite d’échec d’attestation d’Apple ; une fois qu’on y est confronté, il faut contacter l’assistance Apple pour faire lever le verrouillage de l’Apple ID
      Les clients légitimes passent facilement cette étape en approuvant la connexion depuis un appareil autorisé, mais les utilisateurs de Hackintosh contournent ce processus avec diverses techniques
      https://old.reddit.com/r/hackintosh/comments/gij9rt/getting_...
    • Apple fournit déjà des mises à jour de sécurité aux appareils iOS des cinq dernières années environ, donc il ne devrait pas falloir très longtemps avant qu’une mise à jour soit déployée sur la quasi-totalité des appareils iOS encore réellement utilisés
    • Pour les anciens appareils, c’est-à-dire sans TPM, il semble qu’il faille une mise à jour matérielle plutôt que logicielle
    • Il me semble que BBM fonctionnait de cette façon, sans certitude
      Cela ressemble moins à un élément de la sécurité de l’OS entier qu’à une fonction qui devrait au minimum faire partie du mode Isolement d’Apple
    • C’est possible, mais Apple vient aussi d’annoncer la prise en charge de RCS : https://9to5mac.com/2023/11/16/apple-rcs-coming-to-iphone/
      Peut-être qu’ils considèrent que c’est le bon moment pour s’orienter vers davantage d’ouverture

  • C’est impressionnant d’avoir reconstitué le protocole, mais je suis aussi curieux de la pile d’infrastructure iMessage
    L’échelle est énorme et pourtant tout fonctionne si bien, alors que les autres services web d’Apple, comme les forums ou le portail développeur, sont pleins de bugs et donnent une impression d’inachevé, ce qui rend la chose encore plus étonnante

    • La véritable échelle impressionnante, c’est que le service Apple Push Notification ne transporte pas seulement iMessage
      Les notifications push de toutes les applis de messagerie tierces passent aussi par là, et il en va de même pour les applis non liées à la messagerie qui ont des notifications
      Y compris les notifications internes silencieuses. Si vous ajoutez une réunion au calendrier sur Mac, un push est envoyé à l’iPhone pour lui dire que les données iCloud ont changé et qu’il doit se mettre à jour ; si vous modifiez un fichier iCloud Drive, un push part pour synchroniser les autres appareils
      Quand vous recevez un appel, votre Mac sonne aussi via Continuité, et cela aussi passe par une notification push chiffrée, comme iMessage
      Je me demande combien de messages par seconde transitent réellement par ce service

  • C’est exactement le genre de ressource qu’il faut pour Hack Club. Ce serait bien de s’y impliquer : https://hackclub.com/

  • Travail vraiment impressionnant
    Ce serait bien d’écrire aussi quelques lignes sur la manière dont tu es entré dans ce domaine
    Sur Reddit, beaucoup de lycéens et d’étudiants sont doués techniquement, apprennent à programmer et essaient de comprendre comment décrocher un emploi dans la tech ; ce point de vue pourrait vraiment les aider

    • Plutôt qu’une recette secrète, cela ressemble surtout à une énorme quantité de pratique régulière, à l’énergie quasiment illimitée qu’on peut consacrer jeune à ce qu’on aime, et probablement au fait d’avoir eu des parents ouverts d’esprit ou des modèles
    • Au lycée, j’avais pratiquement toute la journée pour avancer sur mes projets
      Entre le fait de finir tôt, les heures creuses et le fait de travailler discrètement sur mes trucs quand je n’étais pas censé le faire, j’ai pu créer et publier une appli en environ six mois, et j’étais extrêmement productif

  • Je suis vraiment curieux de savoir si le sujet peut réellement être opertunistic ou s’il s’agit simplement d’une faute de frappe de l’auteur
    C’est intéressant de voir comment certaines coquilles se fossilisent au fil des générations, comme referer

    • Malheureusement, mon code contient beaucoup de fautes de frappe :P
      Je ne sais pas si celle-ci vient d’Apple, mais c’est clairement étrange. Ici, il faudrait WindowSerial et non quelque chose avec un s en plus comme WindowsSerial
      https://github.com/JJTech0130/pypush/blob/8b33c0ee5d540d8ac7...
    • On dirait que cette valeur n’est pas utilisée dans le code, mais comme il s’agit probablement d’un code entier, il semble plus vraisemblable que ce soit une erreur d’orthographe de l’auteur

  • Il y a aussi cette discussion liée : https://news.ycombinator.com/item?id=38531759

  • Le projet open source pypush, à l’origine des annonces d’aujourd’hui sur le reverse engineering d’iMessage, est distribué sous la Server Side Public License de MongoDB, et appartient à Beeper
    D’après ce que JJTech a dit sur Discord, il aurait vendu les droits à Beeper
    La bibliothèque est excellente, mais c’est une licence à copyleft très fort, donc cela risque d’influencer les usages possibles

    • Il est maintenant temps de faire du reverse engineering inversé

  • On dit que les « validation data » nécessaires à la création d’une requête d’enregistrement IDS constituent le mécanisme par lequel Apple vérifie que des appareils non Apple ne puissent pas utiliser iMessage ; je me demande si cela deviendrait une infraction une fois le DSA ou le DMA de l’UE appliqués

    • Le DSA et le DMA ne donnent pas magiquement le droit d’envoyer à volonté des requêtes aux serveurs d’Apple, ni n’obligent Apple à fournir une réponse valide dans tous les cas
      Quelle que soit la manière dont Apple se conformera au DSA et au DMA, ce ne sera probablement pas celle-ci
    • D’autant plus que iOS prend désormais en charge RCS
      Un iMessage multiplateforme first-party relève surtout du fantasme de technophiles, et personnellement ça me va très bien comme ça

  • Si l’on lit l’annonce de Beeper Mini [1], il est clairement indiqué que les utilisateurs peuvent enregistrer leur numéro de téléphone et envoyer/recevoir des iMessages sans Apple ID
    Il est aussi expliqué que l’appareil et Apple communiquent directement
    Pourtant, ce texte dit que l’IDS sert de serveur de clés pour iMessage, que la première étape de l’enregistrement IDS consiste à obtenir un jeton d’authentification avec un identifiant Apple ID et un mot de passe, puis qu’après l’enregistrement, la paire de clés d’identité reçue sert aux requêtes de clé publique
    On peut donc se demander comment l’appli Beeper Mini enregistre comme clé publique dans l’IDS le numéro de téléphone d’un Android arbitraire, puis effectue les requêtes de clé publique du destinataire sans Apple ID
    La réponse semble être la passerelle SMS, à peine expliquée dans l’article d’origine ou dans [1], et qui paraît être l’ingrédient secret
    [1] https://blog.beeper.com/i/139416474/security-and-privacy

    • J’ai installé Beeper Mini sur un téléphone Android, et après un échec lors de la tentative d’envoi d’un SMS à Apple pour enregistrer le numéro de téléphone, une fenêtre m’a demandé de saisir un Apple ID

  • Travail vraiment remarquable
    En revanche, un point me gêne dans le texte : il dit que l’ancien format pair est mieux documenté et plus simple à implémenter, mais qu’il n’offre pas la confidentialité persistante du nouveau format pair-ec, similaire à Signal avec ses « pre-keys »
    Je ne sais pas sur quoi repose l’affirmation selon laquelle iMessage moderne, c’est-à-dire avec ECIES, utiliserait réellement des pre-keys
    À mes yeux, il semble seulement qu’ECIES remplace RSA dans le chiffrement, voire peut-être dans la signature, mais cela ne suffit pas en soi à fournir la confidentialité persistante
    S’il n’y a pas de preuve, il se peut que la relation entre RSA, courbes elliptiques et confidentialité persistante ait été mal interprétée
    L’article Wikipedia sur iMessage semble répéter la même erreur, et la référence citée n’avance en réalité pas cette affirmation