Seguridad y cifrado

El envío de notificaciones nativas de Mailwake cifra las notificaciones en su puesto y las descifra en el iPhone emparejado. Este artículo describe las claves, el flujo de cifrado y los límites de los datos en Mailwake 1.0, para que pueda comprender qué controla y qué pasa a través de los servicios oficiales. El procesamiento y la retención de datos están cubiertos por la política de privacidad.

Tres rutas de datos

Las notificaciones, la lectura del contenido del correo electrónico y la identidad del servicio utilizan rutas independientes:

Su puesto puede leer el correo al que está autorizado a acceder. El cifrado de extremo a extremo aquí cubre contenido de notificación nativa entre el puesto y el dispositivo emparejado. El proveedor del buzón de correo, el servidor del puesto y el dispositivo de descifrado permanecen cada uno dentro de un límite donde se puede acceder al texto sin formato.

¿Quién conserva las claves?

La clave de identidad del puesto firma el contenido. El puesto genera una clave de firma P-256 localmente y la cifra con su clave de configuración local. Los dispositivos emparejados y el servicio de envío de notificaciones reciben su clave pública para verificar la fuente. La identidad permanece en el directorio de datos durante los reinicios.

El dispositivo utiliza dos claves P-256 independientes: una clave de firma demuestra la identidad del dispositivo y el consentimiento de emparejamiento, mientras que una clave privada de acuerdo de clave descifra las notificaciones. La aplicación crea claves en Secure Enclave cuando está disponible y utiliza claves de software en otros entornos de ejecución. Shared Keychain pone los registros de claves a disposición de la aplicación y sus extensiones, utilizando la protección AfterFirstUnlockThisDeviceOnly con la sincronización de iCloud Keychain deshabilitada. El acceso a la clave en segundo plano requiere el primer desbloqueo del dispositivo después de reiniciar.

El puesto y el servicio de envío de notificaciones almacenan las claves públicas del dispositivo. El dispositivo posee su clave privada de descifrado; Los servicios oficiales y los APNs no poseen esa clave privada.

El puesto también utiliza secret.key en su directorio de datos para cifrar la configuración confidencial, incluidas las credenciales del buzón, con AES-256-GCM. La base de datos y la clave local juntas forman datos recuperables: haz una copia de ambos y protege el acceso al host y las copias de seguridad. Alguien que tenga tanto la base de datos como la clave local puede descifrar esta configuración.

Cómo el emparejamiento establece la confianza

Un código QR de emparejamiento push contiene la clave pública del puesto, la dirección y el entorno del servicio de envío de notificaciones, el identificador de emparejamiento y una credencial de un solo uso válida durante cinco minutos. La aplicación muestra la huella criptográfica del puesto para comparar. Utilice una invitación confiable del propietario del puesto y verifique su información de conexión antes de confirmar.

El dispositivo firma su consentimiento, vinculándolo al puesto, la clave de cifrado del dispositivo, la credencial única y la caducidad. El puesto verifica esa prueba y bloquea la identidad del dispositivo y las claves públicas antes de completar el registro con el servicio de envío de notificaciones. Las notificaciones posteriores utilizan esta relación confirmada para seleccionar claves de cifrado y verificación.

Una invitación de administración puede incluir emparejamiento push, pero la autorización permanece separada: el push nativo, la administración de configuración y la lectura de contenido de correo electrónico tienen cada uno su propio alcance de permiso. Para la configuración, consulte Conecte la aplicación.

Cómo se cifra una notificación

Para cada operación de cifrado, el puesto genera un par de claves P-256 efímeras, un salt aleatorio de 32 bytes y un nonce aleatorio de 12 bytes. Entonces:

1. Realiza el acuerdo de clave ECDH P-256 utilizando la clave privada efímera y la clave pública del dispositivo de destino para obtener un secreto compartido.
2. Deriva una clave de contenido de 256 bits con HKDF-SHA256. El contexto de derivación vincula la audiencia del servicio de envío de notificaciones, el ID de emparejamiento y el ID de evento.
3. Cifra JSON de notificación con AES-256-GCM, utilizando el mismo contexto que los datos autenticados adicionales y produciendo texto cifrado con una etiqueta de autenticación de 128 bits.
4. Firma el sobre cifrado y el contexto utilizando la clave de firma del puesto P-256 con SHA-256 y luego lo envía al servicio de envío de notificaciones a través de HTTPS.
5. El servicio de envío de notificaciones verifica la firma y el formato del sobre y pasa texto cifrado a las APNs. El dispositivo primero verifica la firma utilizando la clave pública del puesto confirmada durante el emparejamiento, luego deriva la clave de contenido con su propia clave privada, verifica la etiqueta de autenticación y descifra.

El identificador del algoritmo es P256-HKDF-SHA256-A256GCM. Los reintentos de la misma entrega reutilizan su sobre almacenado y su identificador de evento; Las nuevas operaciones de cifrado generan nuevas claves efímeras y valores aleatorios. La extensión del servicio de notificaciones maneja notificaciones ordinarias. La extensión del widget maneja actividades en vivo con código de verificación, que también transportan texto cifrado firmado y vinculan los campos de identidad de actividad y ciclo de vida en el contexto de cifrado.

Las notificaciones cifradas contienen la etiqueta del buzón, la carpeta, el remitente, el asunto y la hora de recepción, con un código de verificación opcional y una referencia del mensaje. El contenido completo de los mensajes utiliza el camino separado a continuación. Si falla la verificación o el descifrado de la firma, el dispositivo conserva un marcador de posición seguro; El texto sin formato del correo se muestra solo después de una verificación exitosa.

El contenido de los mensajes se obtiene directamente a través de HTTPS

Al abrir el contenido del correo electrónico se envía una solicitud a la dirección HTTPS del puesto confirmada. El puesto verifica la credencial del dispositivo, el permiso de contenido explícito del propietario y el alcance del recurso en la referencia del mensaje firmado antes de recuperar el contenido del correo electrónico y las imágenes en línea referenciadas del buzón. Leer el contenido del correo electrónico es gratis; El emparejamiento push por sí solo no otorga acceso al contenido del mensaje.

El puesto desinfecta HTML y proporciona un respaldo de texto legible. La aplicación controla la carga remota de imágenes, que puede contactar con el servidor del remitente, a través de sus opciones de carga de imágenes. Los archivos adjuntos comunes están fuera de este flujo de lectura de contenido de correo electrónico.

El puesto procesa los cuerpos de los mensajes en la memoria de la solicitud. Las respuestas utilizan Cache-Control: no-store; la aplicación desactiva la caché HTTP y rechaza redirecciones. Tras una lectura correcta, guarda por separado el cuerpo y el permiso de imágenes de cada mensaje en este iPhone para leer sin conexión, incluso después de reiniciar la aplicación. Los archivos usan la protección de archivos de iOS y se excluyen de las copias de seguridad. Al eliminar o caducar una notificación, se eliminan su cuerpo guardado y su permiso de imágenes. Eliminar un puesto también borra sus cuerpos guardados, conservando los resúmenes de notificaciones. Las imágenes remotas son temporales y pueden requerir otra conexión. Los cuerpos llegan directamente del puesto a la aplicación, sin pasar por servicios oficiales, y quedan excluidos de diagnósticos y registros.

Qué datos pueden ver los servicios oficiales

El remitente, el asunto y el código de verificación están dentro del texto cifrado de notificación nativo. Los intermediarios que manejan texto cifrado aún pueden observar las relaciones de entrega, los tiempos y los tamaños de la carga útil. Los diagnósticos de entrega operativa utilizan identificadores, estados, códigos de error y marcas de tiempo; El contenido del correo conserva el límite de cifrado anterior. Los servicios también procesan información de red necesaria para sus funciones, como se describe en la política de privacidad.

Registros locales, revocación y límites de seguridad

Las entregas pendientes y el historial del administrador en el puesto tienen reglas de almacenamiento independientes; La historia local puede contener resúmenes de buzones y temas. La aplicación almacena el historial de notificaciones descifradas en su grupo de aplicaciones local con protección de datos de archivos del sistema, retención configurable y una acción para borrar el historial. Los cuerpos de los mensajes usan la caché protegida independiente descrita anteriormente.

La desvinculación detiene la entrega adicional a través de esa relación. Revocar una credencial de contenido o gestión finaliza el acceso correspondiente. El contenido ya entregado y descifrado debe borrarse del dispositivo; La revocación no puede recuperar a distancia el contenido que alguien ya ha visto.

Este diseño depende de la seguridad del host del puesto, la invitación de emparejamiento y el dispositivo. Protege el contenido de las notificaciones en tránsito, mientras que un puesto comprometido o un dispositivo desbloqueado puede exponer texto sin formato. El protocolo utiliza una clave privada de acuerdo de clave de dispositivo de larga duración: si esa clave se ve comprometida, alguien que tenga texto cifrado histórico puede descifrar notificaciones antiguas. Por lo tanto, este diseño no hace ningún reclamo de confidencialidad futura contra el compromiso de la clave privada a largo plazo del destinatario.

Los canales Bark, Pushover y webhook envían sus respectivas cargas útiles al servicio que usted configure. El protocolo de cifrado nativo anterior se aplica al canal nativo de Mailwake. Consulte Canales de notificación para campos de datos de terceros y opciones de vista previa.

Markdown · AGPL-3.0-only · Colaboradores de Mailwake