Pin Messenger - Libro Blanco de Arquitectura de Seguridad y Cifrado (Pin-SMP)

01. Arquitectura Criptográfica

Protocolo de Mensajería Pin-SMP (Especificación de Primitivas)

Pin-SMP (*Pin Secure Messaging Protocol*) combina primitivas criptográficas estandarizadas de alta confianza para garantizar confidencialidad e integridad sin introducir complejidad innecesaria.

Acuerdo de Claves X25519 (Curve25519)

Establecimiento de claves asimétrico mediante X25519 basado en la Curva Elíptica 25519. Diseñado para ofrecer alto rendimiento en procesadores móviles y reducir la exposición a ataques de canal lateral (*side-channel attacks*).

Cifrado Autenticado AES-256-GCM (AEAD)

El payload del mensaje se cifra mediante AES-256 en modo Galois/Counter (GCM). Cada paquete incluye una etiqueta de autenticación (MAC) de 128 bits que garantiza la autenticidad e integridad del payload en tránsito.

Protección de Respaldos con PBKDF2

Para el cifrado y protección local de respaldos de clave privada, utilizamos la función de derivación de claves PBKDF2 con HMAC-SHA256 y salting aleatorio único por usuario.

Vectores de Inicialización (Nonce 96-bit)

Cada mensaje cifrado incorpora un vector de inicialización aleatorio único de 96 bits generado mediante generadores pseudoaleatorios criptográficamente seguros (CSPRNG), evitando la reutilización de keystreams.

// Implementación Criptográfica Nativa (PinMessenger EncryptionService Engine)
Future<String> encryptMessage(String plainText, String recipientPubKeyBase64) async {
  final recipientPubKey = SimplePublicKey(base64Decode(recipientPubKeyBase64), type: KeyPairType.x25519);
  
  // 1. Acuerdo de llaves Diffie-Hellman en X25519
  final sharedSecretKeyPair = await _algorithm.sharedSecretKey(keyPair: _cachedKeyPair!, remotePublicKey: recipientPubKey);
  final secretKey = SecretKey(await sharedSecretKeyPair.extractBytes());
  
  // 2. Cifrado simétrico AES-256-GCM con Nonce único de 96-bit
  final aes = AesGcm.with256bits();
  final nonce = aes.newNonce();
  final secretBox = await aes.encrypt(utf8.encode(plainText), secretKey: secretKey, nonce: nonce);
  
  return jsonEncode({ 'nonce': base64Encode(secretBox.nonce), 'cipher': base64Encode(secretBox.cipherText), 'mac': base64Encode(secretBox.mac.bytes) });
}

          Nota: El fragmento anterior ilustra la capa criptográfica de transporte directa del mensaje (Transport Encryption Layer) ejecutada nativamente en el cliente.
        

02. Modelo de Infraestructura

Arquitectura de Servidor Ciego y Conocimiento Mínimo

En lugar de recurrir a claims publicitarios desmedidos, definimos con precisión nuestro modelo técnico: el servidor central de Pin Messenger funciona como un relé ciego de paquetes (Server-Blind Relay) orientado a minimizar el conocimiento almacenado.

🔑 Identidad Autónoma por PIN

No requerimos número de teléfono ni libreta de contactos. Tu identidad es un **PIN alfanumérico único**, eliminando riesgos de SIM Swapping o filtraciones de agenda telefónica.

📦 Transparencia en la Entrega

Los servidores reciben únicamente el payload cifrado (cipher + nonce + mac), lo entregan al destinatario y no procesan el contenido en texto claro en ninguna etapa del trayecto.

03. Transparencia de Datos

Desglose de Datos y Metadatos de Transporte

Detallamos de forma transparente dónde reside cada tipo de dato entre el dispositivo local, los servidores de Pin Messenger y los servicios de notificación push.

Elemento de Datos	En Dispositivo Local	Servidores Pin	Firebase / Push (FCM)
Texto e Imágenes del Mensaje	✓ Cifrado Local (SQLCipher)	✗ Cero Acceso (Solo Ciphertext)	✗ Cero Acceso
Claves Privadas Criptográficas	✓ Protegido en Hardware Enclave	✗ Jamás viajan al servidor	✗ Jamás viajan
Identificador de Usuario (PIN ID)	✓ Local	✓ Necesario para ruteo	✗ No compartido
Libreta / Agenda de Contactos	✓ Solo contactos guardados	✗ Cero lectura de agenda	✗ Cero lectura
Token de Notificación Push	✓ Almacenado	✓ Ruteo de alerta de llegada	✓ Solo badge de conteo de mensaje

04. Llamadas P2P Cifradas

Llamadas de Voz y Video en Tiempo Real (WebRTC DTLS-SRTP)

Las llamadas multimedia en tiempo real se transmiten directamente entre participantes mediante canales **Peer-to-Peer (P2P)** utilizando el protocolo estándar **WebRTC**.

🔐 Acuerdos de Claves DTLS 1.2 / 1.3

Antes del intercambio de audio o video, los dispositivos autentican la sesión multimedia negociando claves efímeras vía **DTLS (Datagram Transport Layer Security)**.

🎥 Flujo Multimedia SRTP (AES-GCM)

El flujo de audio y video en tiempo real está protegido por el protocolo **SRTP** con cifrado simétrico AES en modo GCM. Los servidores STUN/TURN únicamente ayudan a atravesar configuraciones NAT sin poder acceder a los streams de audio/video.

05. Almacenamiento y Llaves

Cifrado de Base de Datos Local (SQLCipher AES-256)

La base de datos del cliente móvil está protegida mediante **SQLCipher con cifrado AES-256 en reposo**.

📱 Keystore de Android & Keychain de iOS

Las llaves criptográficas locales se resguardan en el enclave de seguridad aislado del chip de hardware (Android Keystore / iOS Keychain), garantizando que las llaves no residan en texto plano en la memoria del sistema operativo.

🗑️ Gestión de Eliminación de Contenido

Al borrar mensajes o utilizar la función de tiempo efímero, Pin elimina las referencias y claves asociadas al contenido de la base de datos cifrada local.

06. Comparativa de Modelos

Comparativa de Modelos de Privacidad y Recolección de Datos

Análisis comparativo de características técnicas y modelos de recolección de metadatos.

Criterio Técnico	Pin Messenger	WhatsApp	Telegram	Signal
Cifrado E2EE por defecto	✓ Sí (Pin-SMP)	✓ Sí	✗ No (Solo chats secretos)	✓ Sí
Motor Nativo Autónomo	✓ Sí (Implementación propia)	✗ No (Librería externa)	✗ No (Propio sin E2EE)	✓ Sí
Identidad anónima por PIN (Sin teléfono)	✓ Sí (100% Anónimo)	✗ Exige Número Tel.	✗ Exige Número Tel.	✗ Exige Número Tel.
Cero lectura/subida de contactos	✓ Privacidad total	✗ Sube agenda completa	✗ Sube agenda completa	✗ Sube agenda hash
Llamadas P2P WebRTC (DTLS-SRTP AES-GCM)	✓ Sí	✓ Sí	✓ Sí	✓ Sí
Base de Datos Local Cifrada (SQLCipher AES-256)	✓ Sí (Keystore Hardware)	Depende del SO	Sin cifrar local	✓ Sí

07. Hoja de Ruta Tecnológica

Evolución de la Hoja de Ruta Criptográfica

En Pin Messenger la seguridad es un proceso en constante evolución. Esta es la hoja de ruta planificada para las próximas versiones de nuestro protocolo:

⚡ Integración de Trinquete KDF Multietapa (HKDF)

Evolución hacia cadenas de derivación HKDF (Root Key, Chain Key & Message Key) para ratcheting continuo y manejo de mensajes fuera de orden.

⚛️ Criptografía Post-Cuántica (PQXDH)

Investigación e integración de esquemas de cifrado híbrido resistentes a computación cuántica (Kyber / ML-KEM).

08. Simulador Criptográfico

Simulador de Llaves X25519 & AES-256-GCM Nonces

Simulador interactivo del cálculo de puntos en la Curva Elíptica 25519 y la generación de vectores de inicialización (IV/Nonce) de 96 bits.

Cálculo de Punto en Curva Elíptica X25519

Curva de Montgomery: y² = x³ + 486662x² + x (mod 2²⁵⁵ - 19)

Llave Pública Calculada (Public Key 256-bit):

pub_x25519_8f9a4b2c1d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a

Vector de Inicialización Único (96-bit AES-GCM Nonce):

nonce_96bit_a1b2c3d4e5f60718293a4b5c

Libro Blanco de Seguridad y Cifrado E2EE

Implementación Propia Basada en Estándares Abiertos y Probadoss