Explicación de la estructura interna de iMessage

 (jjtech.dev)
3 puntos por GN⁺ 2023-12-06 | 1 comentarios | Compartir por WhatsApp
  • iMessage usa APNs no solo como canal de notificaciones, sino como base de transmisión bidireccional, y mediante IDS integra el registro y la consulta de claves públicas con la preparación para la entrega de mensajes
  • Tras conectarse a APNs, el dispositivo recibe un push token y filtra el topic de iMessage, com.apple.madrid, para definir el alcance de los mensajes que recibirá
  • El registro en IDS requiere un token de autenticación de Apple ID, un certificado de larga duración, la carga de claves públicas de cifrado y firma, y el envío de validation data, lo que está diseñado para dificultar el uso desde dispositivos que no son de Apple
  • El cifrado de mensajes se divide entre el formato antiguo pair y el nuevo pair-ec; pair-ec ofrece forward secrecy basada en pre-key, similar a Signal
  • El remitente puede enviar payloads cifrados separados por destinatario o agruparlos, pero para que los dispositivos recientes puedan descifrarlos, la clave AES debe incluir una etiqueta HMAC

La base de entrega de iMessage a cargo de APNs

  • Una de las capas básicas de iMessage es Apple Push Notification Service(APNs)
  • APNs es la misma capa del servicio que usan las apps de App Store para recibir notificaciones y actualizaciones en tiempo real incluso cuando están cerradas
  • En iMessage, APNs no solo recibe notificaciones, sino que funciona como un servicio bidireccional usado también para transmitir mensajes
  • Cuando un dispositivo se conecta a APNs, recibe un push token
    • Este token se usa para enrutar notificaciones a un dispositivo específico
    • Técnicamente es distinto del token que se recibe en la API application:didRegisterForRemoteNotificationsWithDeviceToken:
    • El token de esa API tiene alcance por app y se solicita con el bundle ID de la aplicación, pero su propósito es similar
  • Al enviar una push notification a un dispositivo, también se debe especificar el topic del mensaje
    • El topic suele parecerse a un Bundle ID
    • El topic de iMessage es com.apple.madrid
  • Cuando un dispositivo se conecta a APNs, envía un filter message que le indica al servidor qué mensajes quiere recibir
    • El servidor de APNs también se conoce como APNs Courier
    • El filter message puede incluir una lista de topics por estado
    • El estado de un topic puede ser enabled, opertunistic, paused o disabled

Consultas IDS que funcionan sobre APNs

  • APNs no se usa únicamente para la entrega real de mensajes de iMessage
  • A través de una capa pseudo-HTTP sobre APNs, IDS puede enviar consultas y recibir respuestas
  • Para conectarse a APNs se necesita un certificado de cliente emitido por el Albert activation server

IDS y el flujo de autenticación con Apple ID

  • IDS actúa como el servidor de claves de iMessage y también se usa en otros servicios como FaceTime
  • IDS parece ser la sigla de IDentity Services, aunque se indica que no hay confirmación oficial
  • Como iMessage usa cifrado de extremo a extremo, se deben intercambiar de forma segura las claves públicas de cada participante
  • El primer paso del registro en IDS es obtener un token de autenticación
    • Hay que proporcionar a la API el nombre de usuario y la contraseña de Apple ID
  • La 2FA se incorpora a la API de IDS en una forma adaptada posteriormente
    • El método legado agrega el código 2FA directamente a la contraseña
    • El método GrandSlam usa “Anisette data” para demostrar que se trata del mismo dispositivo y evitar tener que volver a ingresar el código 2FA
    • Luego se puede obtener un Password Equivalent Token(PET) y usarlo como si fuera la contraseña y el código 2FA
  • Tras recibir el token de autenticación, se debe intercambiar de inmediato por un certificado de mayor duración
    • Este certificado permite el registro en IDS, pero por sí solo no es suficiente para realizar consultas de claves

Registro en IDS y validation data

  • El paso más importante en la configuración de IDS es el registration
  • En el registration se suben al servidor de claves la clave pública de cifrado y la clave de firma
  • También se suben varios client data sobre las funciones que soporta el dispositivo
  • La solicitud de registration en IDS requiere un blob binario llamado “validation data”
    • Este es el mecanismo de verificación de Apple para impedir que dispositivos que no son de Apple usen iMessage
  • Para generar los validation data se usa información como el serial number, el model y el disk UUID del dispositivo
    • No todos los validation data pueden tratarse de la misma manera
    • De forma similar a un Hackintosh, la antigüedad de la cuenta y el “score” determinan si se puede usar un serial incorrecto o si aparecerá un error de “customer code”
  • El binario que genera los validation data está fuertemente ofuscado
    • pypush evita este problema emulando el binario ofuscado con un custom mach-o loader y Unicorn Engine
    • pypush entrega al binario emulado atributos del dispositivo, como el serial number, en el archivo data.plist

Consulta de claves y session token

  • Tras el registro en IDS se recibe un identity keypair
  • Con este keypair se pueden realizar consultas de claves públicas
  • Al proporcionar la cuenta que se quiere consultar, se recibe una lista de “identities”
    • Cada identity corresponde a un dispositivo registrado en esa cuenta
    • Incluye información importante como public key, push token y session token
  • El session token es necesario para enviar mensajes al dispositivo
    • Sirve como prueba de que se realizó una consulta recientemente
    • El session token expira
    • No se puede compartir, ya que solo puede usarlo la cuenta que realizó la consulta

Mensajes entrantes y formatos de cifrado

  • Para recibir mensajes, basta con filtrar la conexión APNs con com.apple.madrid y enviar un active state packet
  • El formato de cifrado de los mensajes entrantes varía según las capabilities informadas durante el registro en IDS y la versión de iOS del dispositivo emisor
    • El formato antiguo, previo a iOS 13, es pair
    • El formato nuevo es pair-ec
  • El formato pair está más documentado y es más fácil de implementar
  • A diferencia del formato nuevo pair-ec, pair no ofrece forward secrecy mediante “pre-keys”
  • Los mensajes pueden descifrarse según varios papers y la implementación de pypush
  • La verificación de la firma del mensaje es opcional, pero es importante para crear un cliente seguro

Métodos de envío y puntos a tener en cuenta al implementar

  • El envío de mensajes se parece al proceso inverso de la recepción
  • Se puede enviar el mensaje individualmente a cada destinatario
  • También es posible agrupar varios destinatarios y el payload cifrado para cada uno en un único bundle grande
    • En ese caso, APNs lo separa
  • El mensaje se entrega a todos los participantes de la conversación
    • También se entrega a los otros dispositivos de la propia cuenta
  • Un punto que suele pasarse por alto al enviar es que la AES key no es completamente aleatoria
    • La AES key lleva un HMAC adjunto como etiqueta
    • Si se usa una AES key completamente aleatoria, el descifrado del mensaje falla en dispositivos recientes

Implementaciones relacionadas y referencias

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-12-06
Opiniones en Hacker News

  • Parece que Apple empezará a cerrar iMessage con attestation (DeviceCheck).
    El problema es que los dispositivos antiguos necesitarían una actualización de software.

    • En parte ya lo está haciendo.
      Al crear los “validation data” se usa información como el número de serie del dispositivo, el modelo y el UUID del disco; y, como en un Hackintosh, según la antigüedad de la cuenta y el “puntaje”, se decide si se puede usar un número de serie inválido o si aparece un error de “customer code”.
      El error de “customer code” es, en la práctica, el aviso de fallo de attestation de Apple; si te toca, hay que contactar a Apple Support para desbloquear el Apple ID.
      Un cliente legítimo lo supera fácilmente aprobando el inicio de sesión desde un dispositivo válido, pero los usuarios de Hackintosh engañan este proceso con técnicas de bypass.
      https://old.reddit.com/r/hackintosh/comments/gij9rt/getting_...
    • Apple ya ofrece actualizaciones de seguridad para dispositivos iOS de aproximadamente los últimos 5 años, así que probablemente no tomaría mucho tiempo hasta que la actualización llegue a casi todos los dispositivos iOS en uso real.
    • Para dispositivos antiguos, es decir, dispositivos sin TPM, parece que haría falta una actualización de hardware, no de software.
    • Creo que BBM funcionaba de esa manera, aunque no estoy seguro.
      Más que algo que forme parte de la seguridad de todo el sistema operativo, suena como una función que al menos debería estar en el Lockdown Mode de Apple.
    • Puede ser, pero Apple acaba de anunciar también soporte para RCS: https://9to5mac.com/2023/11/16/apple-rcs-coming-to-iphone/
      Tal vez vea este momento como una buena oportunidad para girar hacia una postura más abierta.

  • Es excelente que hayan descifrado el contrato, pero también me da curiosidad el stack de infraestructura de iMessage.
    Es aún más sorprendente que funcione tan bien a semejante escala, mientras que otros servicios web de Apple, como los foros o el portal de desarrolladores, se sienten llenos de bugs e incompletos.

    • La escala realmente sorprendente está en que Apple Push Notification service no transporta solo iMessage.
      También pasan por ahí las notificaciones push de todas las apps de mensajería de terceros, y lo mismo con las apps que no son de mensajería pero tienen notificaciones.
      Eso incluye notificaciones silenciosas internas. Si agregas una reunión al calendario en la Mac, se envía un push al iPhone para avisarle que los datos de iCloud cambiaron y que debe actualizarse; si modificas un archivo de iCloud Drive, se envía un push para sincronizar los demás dispositivos.
      Cuando entra una llamada, también suena en la Mac mediante Continuity, y eso también es una notificación push cifrada, igual que iMessage.
      Me da curiosidad cuántos mensajes por segundo pasan por ese servicio.

  • Este material le queda perfecto a Hack Club. Sería bueno participar: https://hackclub.com/

  • Es un trabajo realmente impresionante.
    También sería bueno escribir brevemente cómo llegaste a meterte en esta área.
    En Reddit hay muchos estudiantes de secundaria y universitarios que se preguntan cómo volverse buenos en tecnología, aprender programación y conseguir trabajos técnicos; esta perspectiva podría serles bastante útil.

    • Más que una receta secreta, parece probable que haya sido una enorme cantidad de práctica constante, una energía casi ilimitada para dedicarle a lo que te gusta cuando eres joven, y padres o modelos a seguir con una mentalidad abierta.
    • En la secundaria tenía tiempo casi todo el día para trabajar en mis propios proyectos.
      Gracias a terminar temprano, los tiempos libres y hacer mis cosas a escondidas cuando en teoría no debía, pude crear y lanzar una app en unos 6 meses, y fui muy productivo.

  • Me da verdadera curiosidad si el tema realmente puede ser opertunistic o si es un typo del autor.
    Son interesantes esos typos como referer que se fosilizan con el paso de las generaciones.

    • Lamentablemente, mi código tiene muchos typos :P
      Pero no sé si este es un typo del lado de Apple, aunque definitivamente es raro. Aquí se debe usar WindowSerial, no WindowsSerial con una s de más.
      https://github.com/JJTech0130/pypush/blob/8b33c0ee5d540d8ac7...
    • Parece que el código no usa ese valor, pero probablemente sea un código entero, así que lo más probable es que sea un error ortográfico del autor.

  • Hay más contenido relacionado: https://news.ycombinator.com/item?id=38531759

  • El proyecto open source pypush, que sirvió de base para las noticias de hoy sobre la ingeniería inversa de iMessage, se distribuye bajo la Server Side Public License de MongoDB, y el propietario es Beeper.
    Según dijo JJTech en Discord, vendió los derechos a Beeper.
    La biblioteca es excelente, pero al ser una licencia copyleft muy fuerte, creo que afectará dónde se puede usar.

    • Ahora toca hacer ingeniería inversa de la ingeniería inversa.

  • Dicen que los “validation data” necesarios para crear una solicitud de registro IDS son el mecanismo con el que Apple verifica que dispositivos que no son de Apple no puedan usar iMessage; me pregunto si eso será una infracción cuando entren en vigor la DSA o la DMA de la UE.

    • La DSA y la DMA no te dan mágicamente el derecho de hacer las solicitudes que quieras a los servidores de Apple, ni obligan a Apple a devolver una respuesta válida específica.
      Cualquiera sea la forma en que Apple cumpla con la DSA y la DMA, no será esta.
    • Sobre todo ahora que iOS va a soportar RCS.
      Un iMessage cross-platform de primera mano es básicamente un sueño imposible de geeks, y personalmente me parece suficiente que sea así.

  • Si se mira el anuncio de Beeper Mini [1], dice claramente que los usuarios pueden registrar su número de teléfono y enviar y recibir iMessages sin un Apple ID.
    También explica que el dispositivo se comunica directamente con Apple.
    Pero este artículo dice que IDS se usa como servidor de claves de iMessage, que el primer paso del registro IDS requiere obtener un token de autenticación con el usuario y la contraseña de Apple ID, y que después del registro se consulta la clave pública usando el identity keypair recibido.
    Entonces me pregunto cómo la app Beeper Mini registra en IDS un número de teléfono arbitrario de Android con una clave pública, y además realiza la consulta de la clave pública del destinatario sin Apple ID.
    La respuesta parece ser un SMS Gateway, algo que casi no se explica ni en el texto original ni en [1], y eso parece ser el ingrediente secreto.
    [1] https://blog.beeper.com/i/139416474/security-and-privacy

    • Instalé Beeper Mini en un teléfono Android y, después de dar un error al intentar enviar un SMS a Apple para registrar el número, apareció una ventana pidiéndome el Apple ID.

  • Es un trabajo realmente increíble.
    Pero me hace ruido la parte donde el artículo dice que el formato pair existente está mejor documentado y es más fácil de implementar, pero que no ofrece forward secrecy mediante “pre-keys” similares a las de Signal como el nuevo formato pair-ec.
    No sé si hay evidencia de que el iMessage moderno, es decir, el que usa ECIES, realmente use pre-keys.
    A mi parecer, simplemente insertaron ECIES en lugar de RSA para el cifrado, y quizá para la firma, pero eso por sí solo no da forward secrecy.
    Si no hay evidencia, podría ser una mala interpretación de la relación entre RSA, curvas elípticas y forward secrecy.
    El artículo de Wikipedia sobre iMessage parece propagar el mismo error, y la referencia citada en realidad no afirma eso.