Explicação da estrutura interna do iMessage

 (jjtech.dev)
3 pontos por GN⁺ 2023-12-06 | 1 comentários | Compartilhar no WhatsApp
  • O iMessage usa o APNs não apenas como um canal simples de notificações, mas como base de transmissão bidirecional, e por meio do IDS agrupa registro/consulta de chaves públicas com a preparação para entrega de mensagens
  • Depois de se conectar ao APNs, o dispositivo recebe um push token e define o escopo das mensagens que irá receber filtrando o tópico do iMessage, com.apple.madrid
  • O registro no IDS exige token de autenticação do Apple ID, certificado de longa duração, upload de chaves públicas de criptografia e assinatura, além do envio de validation data, o que dificulta o uso em dispositivos não Apple
  • A criptografia de mensagens se divide entre o formato antigo pair e o novo pair-ec, e o pair-ec oferece forward secrecy com base em pre-key, de forma semelhante ao Signal
  • O remetente pode enviar payloads criptografados separadamente para cada destinatário ou agrupá-los, mas para que dispositivos mais novos consigam descriptografar, a chave AES precisa incluir uma tag HMAC

O APNs como base de transporte do iMessage

  • Uma das camadas fundamentais do iMessage é o Apple Push Notification Service (APNs)
  • É a mesma camada de serviço usada por apps da App Store para receber notificações e atualizações em tempo real mesmo quando estão fechados
  • No iMessage, o APNs funciona não só para receber notificações, mas como um serviço bidirecional também usado para a transmissão de mensagens
  • Quando o dispositivo se conecta ao APNs, ele recebe um push token
    • Esse token é usado para rotear notificações para um dispositivo específico
    • Tecnicamente, ele é diferente do token recebido pela API application:didRegisterForRemoteNotificationsWithDeviceToken:
    • O token dessa API tem escopo por app e é solicitado com o bundle ID da aplicação, mas o objetivo é semelhante
  • Ao enviar uma push notification para um dispositivo, também é preciso especificar o topic da mensagem
    • O topic normalmente se parece com um Bundle ID
    • O topic do iMessage é com.apple.madrid
  • Quando o dispositivo se conecta ao APNs, ele envia uma filter message ao servidor informando quais mensagens deseja receber
    • O servidor APNs também é chamado de APNs Courier
    • A filter message pode incluir uma lista de topics por estado
    • O estado do topic pode ser enabled, opertunistic, paused ou disabled

Consultas do IDS operando sobre o APNs

  • O APNs não é usado apenas para a entrega efetiva de mensagens do iMessage
  • Por meio de uma camada pseudo-HTTP sobre o APNs, o IDS pode enviar consultas e receber respostas
  • Para se conectar ao APNs, é necessário um certificado de cliente emitido pelo Albert activation server

IDS e o fluxo de autenticação do Apple ID

  • O IDS atua como servidor de chaves do iMessage e também é usado por outros serviços, como o FaceTime
  • IDS aparentemente significa IDentity Services, embora conste que não haja confirmação oficial
  • Como o iMessage usa criptografia de ponta a ponta, é preciso trocar com segurança as chaves públicas de cada participante
  • A primeira etapa do registro no IDS é obter um token de autenticação
    • É necessário fornecer nome de usuário e senha do Apple ID à API
  • O 2FA foi incorporado ao IDS API posteriormente
    • No método legado, o código 2FA é anexado diretamente à senha
    • No método GrandSlam, o “Anisette data” prova que é o mesmo dispositivo, evitando nova digitação do código 2FA
    • Depois disso, é possível obter um Password Equivalent Token (PET) para usar como se fosse senha e código 2FA
  • Depois de receber o token de autenticação, ele deve ser trocado imediatamente por um certificado de maior duração
    • Esse certificado permite o registro no IDS, mas sozinho não é suficiente para fazer consultas de chaves

Registro no IDS e validation data

  • A etapa mais importante da configuração do IDS é o registration
  • No registration, as chaves públicas de criptografia e de assinatura são enviadas ao servidor de chaves
  • Vários client data sobre os recursos suportados pelo dispositivo também são enviados
  • A requisição de IDS registration exige um blob binário chamado “validation data”
    • Esse é o mecanismo de validação da Apple para impedir que dispositivos não Apple usem o iMessage
  • A geração do validation data usa informações como serial number, modelo e UUID do disco do dispositivo
    • Nem todo validation data pode ser tratado da mesma forma
    • De forma parecida com Hackintosh, a idade da conta e a “score” influenciam se um serial incorreto pode ser usado e se ocorrerá erro de “customer code” ou não
  • O binário que gera o validation data é fortemente ofuscado
    • O pypush contorna isso emulando o binário ofuscado com um carregador mach-o customizado e a Unicorn Engine
    • O pypush fornece ao binário emulado propriedades do dispositivo, como o serial number, em um arquivo data.plist

Consulta de chaves e session token

  • Depois do registro no IDS, recebe-se um identity keypair
  • Esse keypair pode ser usado para consultar chaves públicas
  • Ao informar a conta que se deseja consultar, recebe-se uma lista de “identities”
    • Cada identity corresponde a um dispositivo registrado naquela conta
    • Ela inclui informações importantes como public key, push token e session token
  • O session token é necessário para enviar mensagens ao dispositivo
    • Ele serve como prova de que uma consulta foi feita recentemente
    • O session token expira
    • Só pode ser usado pela conta que realizou a consulta, então não pode ser compartilhado

Mensagens recebidas e formatos de criptografia

  • Para receber mensagens, basta filtrar a conexão APNs por com.apple.madrid e enviar um active state packet
  • O formato de criptografia das mensagens recebidas varia conforme as capabilities informadas no registro do IDS e a versão do iOS do dispositivo remetente
    • O formato antigo, anterior ao iOS 13, é pair
    • O formato novo é pair-ec
  • O formato pair é mais documentado e mais fácil de implementar
  • Diferentemente do pair-ec, o pair não oferece forward secrecy com “pre-keys”
  • As mensagens podem ser descriptografadas com base em vários artigos e na implementação do pypush
  • A verificação de assinatura da mensagem é opcional, mas importante para criar um cliente seguro

Formas de envio e cuidados na implementação

  • O envio de mensagens é praticamente o processo inverso da recepção
  • É possível enviar a mensagem individualmente para cada destinatário
  • Também é possível agrupá-la em um grande bundle com vários destinatários e os payloads criptografados de cada um
    • Nesse caso, o APNs faz a separação
  • As mensagens são entregues a todos os participantes da conversa
    • Inclusive aos outros dispositivos da própria conta
  • Um detalhe frequentemente ignorado no envio é que a chave AES não é totalmente aleatória
    • A chave AES vem com um HMAC anexado como tag
    • Se for usada uma chave AES totalmente aleatória, a descriptografia da mensagem falha em dispositivos mais novos

Implementações relacionadas e materiais de referência

Leituras relacionadas

1 comentários

 
GN⁺ 2023-12-06
Comentários do Hacker News

  • Parece que a Apple vai começar a travar o iMessage com attestation (DeviceCheck)
    Só que há o problema de que dispositivos antigos precisariam de uma atualização de software

    • Em parte, ela já faz isso
      Ao criar “validation data”, são usadas informações como número de série do dispositivo, modelo e UUID do disco; no caso de Hackintosh, dependendo da idade da conta e da “pontuação”, isso determina se é possível usar um número de série inválido ou se aparece um erro de “customer code”
      O erro de “customer code” é, na prática, um prompt de falha de attestation da Apple; uma vez que ele aparece, é preciso entrar em contato com o Apple Support para desbloquear o Apple ID
      Clientes normais passam por isso facilmente, aprovando o login em um dispositivo legítimo, mas usuários de Hackintosh enganam esse processo com técnicas de bypass
      https://old.reddit.com/r/hackintosh/comments/gij9rt/getting_...
    • Como a Apple já fornece atualizações de segurança para dispositivos iOS dos últimos cerca de 5 anos, não deve levar muito tempo até que a atualização chegue a quase todos os dispositivos iOS realmente em uso
    • Para dispositivos antigos, ou seja, dispositivos sem TPM, parece que seria necessária uma atualização de hardware, não de software
    • Acho que o BBM funcionava desse jeito, mas não tenho certeza
      Mais do que algo que faça parte da segurança do sistema operacional inteiro, soa como um recurso que deveria entrar pelo menos no Lockdown Mode da Apple
    • Pode ser, mas a Apple acabou de anunciar também suporte a RCS: https://9to5mac.com/2023/11/16/apple-rcs-coming-to-iphone/
      Talvez ela veja este como um bom momento para mudar de direção rumo a mais abertura

  • É ótimo terem entendido o contrato, mas também fico curioso sobre a stack de infraestrutura do iMessage
    Apesar da escala enorme, ele funciona tão bem, enquanto outros serviços web da Apple, como fóruns ou o portal de desenvolvedores, são cheios de bugs e parecem inacabados, o que torna isso ainda mais curioso

    • A escala realmente impressionante está no fato de que o Apple Push Notification service não transporta só iMessage
      As notificações push de todos os apps de mensagens de terceiros também passam por ele, assim como apps que não são de mensagens mas têm notificações
      Isso inclui notificações silenciosas internas. Quando você adiciona uma reunião ao Calendário no Mac, um push vai para o iPhone dizendo que os dados do iCloud mudaram e que ele deve atualizar; quando você altera um arquivo do iCloud Drive, um push é enviado para sincronizar outros dispositivos
      Quando você recebe uma ligação, o Mac também toca via Continuity, e isso também é uma notificação push criptografada, como no iMessage
      Fico imaginando quantas mensagens por segundo passam por esse serviço

  • Este é um material perfeito para o Hack Club. Seria bom participar: https://hackclub.com/

  • Um trabalho realmente incrível
    Seria legal escrever também, de forma breve, como você entrou nessa área
    No Reddit há muitos alunos do ensino médio e universitários que são bons em tecnologia, estão aprendendo programação e pensam em como conseguir um emprego técnico; essa perspectiva provavelmente seria bem útil

    • Mais do que uma fórmula secreta, parece provável que tenha havido uma quantidade enorme de prática constante, energia quase infinita para se dedicar ao que se gosta quando se é jovem e talvez pais ou modelos de referência esclarecidos
    • No ensino médio, eu tinha praticamente o dia inteiro para trabalhar nas minhas próprias coisas
      Graças a terminar cedo, tempos livres e fazer minhas coisas escondido quando não deveria, consegui criar e lançar um app em cerca de 6 meses, e minha produtividade era muito alta

  • Estou realmente curioso se o assunto pode mesmo ser opertunistic ou se é um erro de digitação do autor
    Esses erros de digitação que se fossilizam ao longo das gerações, como referer, são interessantes

    • Infelizmente, meu código tem muitos erros de digitação :P
      Mas não sei se isso é um erro da Apple; de todo modo, é definitivamente estranho. Aqui é preciso usar WindowSerial, e não algo com um s a mais como WindowsSerial
      https://github.com/JJTech0130/pypush/blob/8b33c0ee5d540d8ac7...
    • Pelo código, parece que esse valor não é usado, mas provavelmente é um código inteiro, então parece bem provável que seja um erro de grafia do autor

  • Há mais conteúdo relacionado: https://news.ycombinator.com/item?id=38531759

  • O projeto open source pypush, que serviu de base para as notícias de hoje sobre engenharia reversa do iMessage, é distribuído sob a Server Side Public License do MongoDB, e o proprietário é a Beeper
    Segundo o que a JJTech disse no Discord, ela vendeu os direitos para a Beeper
    A biblioteca é excelente, mas por ser uma licença copyleft muito forte, isso deve afetar onde ela pode ser usada

    • Agora é hora de fazer engenharia reversa reversa

  • Dizem que os “validation data” necessários para criar uma solicitação de registro no IDS são o mecanismo pelo qual a Apple verifica que dispositivos não Apple não possam usar o iMessage; fico me perguntando se isso seria uma violação quando a DSA ou a DMA da UE entrarem em vigor

    • A DSA e a DMA não concedem magicamente o direito de enviar requisições aos servidores da Apple do jeito que você quiser, nem obrigam a Apple a fornecer uma resposta válida específica
      Seja qual for a forma como a Apple venha a cumprir a DSA e a DMA, não será por esse caminho
    • Especialmente agora que o iOS vai passar a oferecer suporte a RCS
      iMessage multiplataforma first-party é basicamente um sonho vazio de entusiastas de tecnologia e, pessoalmente, acho isso perfeitamente aceitável

  • O anúncio do Beeper Mini [1] diz claramente que o usuário pode registrar um número de telefone e trocar iMessages mesmo sem Apple ID
    Também explica que o dispositivo e a Apple se comunicam diretamente
    Mas este texto diz que o IDS é usado como servidor de chaves do iMessage, que a primeira etapa do registro no IDS exige obter um token de autenticação com nome de usuário e senha do Apple ID, e que, após o registro, a consulta de chaves públicas é feita usando o identity keypair recebido
    Então fica a dúvida: como o app Beeper Mini registra no IDS um número de telefone arbitrário de Android com uma chave pública e ainda consulta a chave pública do destinatário sem Apple ID?
    A resposta parece ser o SMS Gateway, algo quase não explicado nem no texto original nem em [1], e isso parece ser o ingrediente secreto
    [1] https://blog.beeper.com/i/139416474/security-and-privacy

    • Instalei o Beeper Mini em um celular Android; ele tentou enviar um SMS para a Apple para registrar o número de telefone, deu erro de falha e então apareceu uma janela pedindo o Apple ID

  • Trabalho realmente impressionante
    Mas me incomoda a parte em que o texto diz que o formato pair antigo é mais bem documentado e mais fácil de implementar, mas não oferece forward secrecy usando “pre-keys” semelhantes às do Signal, como o novo formato pair-ec
    Não sei se há evidência de que o iMessage mais recente, isto é, o que usa ECIES, realmente use pre-key
    Do meu ponto de vista, parece mais que simplesmente encaixaram ECIES no lugar de RSA na parte de criptografia, talvez também na assinatura; isso por si só não cria forward secrecy
    Se não houver evidência, pode ser uma interpretação incorreta da relação entre RSA, curvas elípticas e forward secrecy
    O artigo da Wikipedia sobre iMessage também parece propagar o mesmo erro, e a referência citada não afirma isso de fato