¡Hola, Habr!
Hoy hablaré de lo que mis compañeros y yo hemos estado haciendo desde hace varios meses: notificaciones push para mensajería instantánea móvil. Como ya dije, en nuestra aplicación el énfasis principal está en la seguridad. Por lo tanto, descubrimos si las notificaciones push tienen “puntos débiles” y, de ser así, cómo podemos nivelarlos para agregar esta útil opción a nuestro servicio.
Estoy publicando una traducción de nuestro
Examinamos el material.
En el modelo clásico, las notificaciones push hacen que los mensajeros sean vulnerables a ataques MITM (Man-in-the-middle). Por ejemplo, con Google, Microsoft y la versión anterior de iMessage, la aplicación envía claves de cifrado a los servidores de Apple: en el servidor, los usuarios se autentican y el encabezado del mensaje (o su contenido) se descifra.
Como resultado, existe la posibilidad de leer la correspondencia obteniendo acceso al servidor de notificaciones push. Esto significa que cualquier cifrado de la correspondencia es inútil: las notificaciones push seguirán dejando la posibilidad de ser leídas por terceros. Los autores del artículo discutieron esta posibilidad con más detalle.
Si cree que los servidores de Apple y Google son 100% seguros contra la filtración de claves de cifrado de usuarios, considere el hecho de que sus empleados tienen acceso a ellos. Y los empleados son personas.
A pesar de todas las vulnerabilidades de las notificaciones push, muchas aplicaciones de mensajería instantánea "seguras", incluidos Signal y Telegram, las utilizan. De lo contrario, los usuarios tendrán que monitorear “manualmente” los mensajes nuevos iniciando sesión constantemente en la aplicación. Lo cual es muy inconveniente y los mensajeros de la competencia obtendrán una ventaja.
Paranoia y sentido común
En nuestro proyecto abordamos este tema de cerca hace varios meses. Necesitábamos agregar una opción de notificación automática para ser competitivos. Pero al mismo tiempo, no abras un agujero de seguridad, porque cualquier filtración de datos socavará la confianza en el proyecto.
Sin embargo, ya tenemos una ventaja importante: nuestro mensajero está descentralizado (los datos se almacenan en la cadena de bloques) y los empleados no tienen acceso a las cuentas. Sólo los usuarios tienen claves de cifrado y las claves públicas de los interlocutores están disponibles en la cadena de bloques para protegerse contra ataques MITM.
En la primera versión de las notificaciones push, decidimos ir lo más seguro posible y no transmitir el texto del mensaje en absoluto. El servicio push no recibió el texto del mensaje del nodo, sino solo una señal sobre su recepción. Por lo tanto, el usuario vio la notificación “Ha llegado un nuevo mensaje”. Sólo era posible leerlo en el Messenger.
Después de eso, supimos que la última versión de notificaciones de Apple tiene nuevas funciones de seguridad. Ellos
Ahora hemos desarrollado la segunda versión de notificaciones push para iOS, que permite mostrar el texto del mensaje sin riesgo de seguridad. En el nuevo concepto, la lógica se ve así:
- El servicio push envía una notificación push con el número de transacción (el mensaje cifrado puede ser muy grande y el tamaño de las notificaciones es muy limitado)
- Cuando el dispositivo recibe una notificación, inicia nuestra NotificationServiceExtension, una microaplicación que solicita una transacción del nodo por identificación, la descifra utilizando la frase de contraseña guardada y envía una nueva notificación al sistema. La frase de contraseña se almacena en un almacenamiento seguro.
- El sistema muestra una notificación con un mensaje descifrado o una traducción.
- Las claves no van a ninguna parte, al igual que el mensaje de texto sin formato. El servicio push no tiene forma de descifrar el mensaje.
Aceptamos que esta versión funciona y la implementamos en la última actualización de la aplicación iOS.
Aquellos interesados en el aspecto técnico pueden ver el código fuente:
Fuente: habr.com