Investigacion: Cifrado End-to-End Zero Knowledge para MedTime
Resumen Ejecutivo
- Conclusion Principal
1. Descripcion del Modelo Propuesto
- 1.1 Arquitectura Zero Knowledge
- 1.2 Flujo de Comparticion
2. Analisis Legal y Regulatorio
3. Analisis Tecnico
4. Analisis de Usabilidad
5. Modelo Hibrido Recomendado
6. Recomendaciones Finales
7. Referencias
- Fuentes de Investigacion
- Documentos MedTime Relacionados

Investigacion: Cifrado End-to-End Zero Knowledge para MedTime¶

Identificador: MTS-INV-001 Version: 1.0.0 Fecha: 2025-12-01 Autor: SpecQueen Solicitado en: ACL7-001 (Round 7) Estado: Completado

Resumen Ejecutivo¶

Esta investigacion analiza las implicaciones de implementar cifrado end-to-end (E2E) donde solo el paciente puede descifrar sus datos PHI, sin que MedTime tenga capacidad de recuperacion. Se evaluan aspectos legales, tecnicos, de usabilidad y regulatorios.

Conclusion Principal¶

El cifrado E2E Zero Knowledge es viable pero requiere consideraciones criticas:

Aspecto	Evaluacion	Riesgo
Privacidad	Excelente	Bajo
Cumplimiento LGPD	Favorable	Bajo
Cumplimiento HIPAA	Parcial	Medio
Recuperacion de datos	Critico	Alto
Usabilidad	Desafiante	Medio-Alto
Soporte tecnico	Limitado	Alto

1. Descripcion del Modelo Propuesto¶

1.1 Arquitectura Zero Knowledge¶

+------------------+      +------------------+      +------------------+
|    PACIENTE      |      |    MEDTIME       |      |   RECEPTOR       |
|                  |      |    (Servidor)    |      |   (Medico/       |
|  Clave Privada   |      |                  |      |   Cuidador)      |
|  Clave Publica   |      |  Datos Cifrados  |      |                  |
+--------+---------+      |  (No puede       |      |  Clave Publica   |
         |                |   descifrar)     |      +--------+---------+
         |                +--------+---------+               |
         |                         |                         |
         v                         v                         v
    [Cifrar con                [Almacenar               [Descifrar con
     clave propia]              blob opaco]              clave propia]

1.2 Flujo de Comparticion¶

sequenceDiagram
    participant P as Paciente
    participant S as Servidor MedTime
    participant R as Receptor (Medico)

    P->>P: Genera par de claves (publica/privada)
    P->>S: Registra clave publica
    P->>P: Cifra datos con su clave privada
    P->>S: Sube datos cifrados

    Note over S: Servidor almacena blob<br/>sin capacidad de leer

    P->>R: Solicita clave publica del receptor
    R->>P: Envia clave publica
    P->>P: Re-cifra datos con clave publica del receptor
    P->>R: Envia paquete cifrado
    R->>R: Descifra con su clave privada

2. Analisis Legal y Regulatorio¶

2.1 HIPAA (Estados Unidos)¶

Requisito	Estado	Notas
Cifrado de datos en reposo	Cumple	E2E supera requisito minimo
Cifrado en transito	Cumple	TLS 1.3 + E2E
Logs de auditoria	Parcial	Solo metadata, no contenido
Control de acceso	Cumple	Solo paciente tiene acceso
Integridad de datos	Parcial	No verificable por proveedor
BAA con subcontratistas	N/A	No hay acceso a PHI

Consideraciones HIPAA: - HIPAA considera datos cifrados correctamente como "safe harbor" en caso de brecha - Los logs de auditoria pueden registrar eventos (quien accedio, cuando) sin ver contenido - Riesgo: Si el paciente pierde la clave, HIPAA aun requiere retencion de 6 anos

2.2 LGPD (Brasil)¶

Requisito	Estado	Notas
Consentimiento explicito	Cumple	Paciente tiene control total
Derecho de acceso	Cumple	Solo el paciente puede acceder
Derecho de eliminacion	Cumple	Paciente puede eliminar su clave
Portabilidad	Cumple	Export cifrado descifrable por paciente
Medidas de seguridad	Excelente	Cifrado de maxima seguridad

Ventaja LGPD: El modelo E2E se alinea perfectamente con el principio de control del titular sobre sus datos personales sensibles (Art. 11, 18).

2.3 Ley Federal de Proteccion de Datos (Mexico)¶

Requisito	Estado	Notas
Consentimiento	Cumple	Control total del paciente
Derechos ARCO	Cumple	Acceso, Rectificacion, Cancelacion, Oposicion
Medidas de seguridad	Cumple	Cifrado robusto
Aviso de privacidad	Cumple	Debe especificar modelo E2E

2.4 Implicaciones de Responsabilidad¶

ESCENARIO: Paciente pierde acceso a sus datos

SIN E2E:
  Paciente -> Contacta soporte -> MedTime recupera datos -> Datos restaurados
  Responsabilidad: MedTime

CON E2E:
  Paciente -> Contacta soporte -> MedTime NO puede ayudar -> Datos perdidos
  Responsabilidad: Paciente (con advertencias previas)

Recomendacion Legal: - Consentimiento informado explicito sobre riesgos de perdida de clave - Aviso claro: "Si pierdes tu clave de recuperacion, tus datos seran irrecuperables" - Multiples advertencias durante onboarding

3. Analisis Tecnico¶

3.1 Arquitectura Criptografica Propuesta¶

CAPA 1: Cifrado de Datos en Reposo
+------------------------------------------+
| Algoritmo: AES-256-GCM                    |
| Derivacion de clave: PBKDF2 (100K iter)   |
| Salt: Unico por usuario (256 bits)        |
+------------------------------------------+

CAPA 2: Cifrado Asimetrico para Compartir
+------------------------------------------+
| Algoritmo: RSA-4096 o Curve25519          |
| Intercambio: Diffie-Hellman efimero       |
| Forward Secrecy: Si                       |
+------------------------------------------+

CAPA 3: Gestion de Claves
+------------------------------------------+
| Clave maestra: Derivada de contrasena     |
| Recovery Key: 24 palabras (BIP39)         |
| Almacenamiento local: Keychain/Keystore   |
+------------------------------------------+

3.2 Flujo de Generacion de Claves¶

flowchart TD
    A[Usuario crea cuenta] --> B[Genera entropy aleatoria]
    B --> C[Deriva clave maestra de contrasena]
    C --> D[Genera par de claves asimetricas]
    D --> E[Genera Recovery Key 24 palabras]
    E --> F[Usuario DEBE guardar Recovery Key]
    F --> G{Usuario confirmo backup?}
    G -->|Si| H[Cuenta activa]
    G -->|No| I[Bloquear hasta confirmar]

3.3 Estructura de Datos Cifrados¶

{
  "metadata": {
    "version": "1.0",
    "algorithm": "AES-256-GCM",
    "created_at": "2025-12-01T10:00:00Z",
    "key_id": "hash_of_public_key"
  },
  "encrypted_payload": "base64_encoded_ciphertext",
  "nonce": "unique_nonce_per_encryption",
  "auth_tag": "gcm_authentication_tag"
}

3.4 Desafios Tecnicos¶

Desafio	Severidad	Mitigacion
Perdida de clave	Critica	Recovery Key obligatoria
Performance de cifrado	Media	Cifrado en background, cache local
Sincronizacion multi-dispositivo	Alta	Protocolo de sincronizacion de claves
Busqueda en datos cifrados	Alta	Indices cifrados o busqueda client-side
Backup automatico	Media	Backup cifrado con clave del usuario
Compartir con multiples receptores	Media	Re-cifrado por receptor

3.5 Limitaciones Tecnicas¶

FUNCIONALIDADES AFECTADAS:

1. Busqueda server-side
   - Antes: SELECT * FROM medications WHERE name LIKE '%metformin%'
   - Despues: No posible en servidor

2. Analytics y reportes agregados
   - Antes: Estadisticas de adherencia globales
   - Despues: Solo con datos anonimizados por paciente

3. Soporte tecnico
   - Antes: "Veo que tienes 5 medicamentos configurados..."
   - Despues: "No puedo ver tus datos, describe tu problema"

4. Deteccion de fraude/abuso
   - Antes: Analisis de patrones sospechosos
   - Despues: Solo metadata de acceso

5. Machine Learning
   - Antes: Modelos entrenados con datos reales
   - Despues: Federated Learning o datos sinteticos

4. Analisis de Usabilidad¶

4.1 Impacto en Experiencia de Usuario¶

Flujo	Sin E2E	Con E2E	Delta UX
Registro	3 pasos	5+ pasos (incluye backup key)	-40%
Recuperar cuenta	Email + codigo	Recovery Key o perder todo	-80%
Compartir con medico	2 taps	5+ taps (intercambio claves)	-60%
Nuevo dispositivo	Login normal	Login + sincronizar claves	-30%
Soporte tecnico	Ver datos del usuario	Solo ver metadata	-70%

4.2 Onboarding Modificado¶

ONBOARDING ACTUAL (Sin E2E):
1. Ingresar email
2. Crear contrasena
3. Verificar email
4. Listo!

ONBOARDING CON E2E:
1. Ingresar email
2. Crear contrasena FUERTE (minimo 12 caracteres)
3. Verificar email
4. Generar claves (espera 5-10 segundos)
5. Mostrar Recovery Key (24 palabras)
6. OBLIGAR a escribir Recovery Key en papel
7. Confirmar Recovery Key (ingresar palabras 3, 7, 12)
8. Advertencia legal sobre perdida de datos
9. Aceptar terminos E2E
10. Listo!

4.3 Escenarios de Usuario Criticos¶

Escenario A: Olvido de Contrasena¶

SIN E2E:
Usuario -> Olvidar contrasena -> Email de recuperacion -> Nueva contrasena -> OK

CON E2E:
Usuario -> Olvidar contrasena -> Tiene Recovery Key?
  -> SI: Ingresar 24 palabras -> Restaurar -> OK
  -> NO: DATOS PERDIDOS PERMANENTEMENTE

Escenario B: Dispositivo Perdido/Robado¶

SIN E2E:
Usuario -> Reportar perdida -> Bloquear sesion -> Login en nuevo dispositivo -> OK

CON E2E:
Usuario -> Reportar perdida -> Bloquear sesion -> Login en nuevo ->
  -> Tiene Recovery Key?: Restaurar claves -> OK
  -> No tiene?: Solo datos sincronizados en otros dispositivos

Escenario C: Usuario Fallece¶

SIN E2E:
Familiar -> Solicitud legal -> MedTime entrega datos -> Familiar recibe historial

CON E2E:
Familiar -> Solicitud legal -> MedTime entrega datos CIFRADOS ->
  -> Tiene Recovery Key del fallecido?: Descifrar -> OK
  -> No tiene?: Datos irrecuperables

4.4 Perfil de Usuarios en Riesgo¶

Perfil	Riesgo de Perdida	Mitigacion
Adultos mayores	Alto	Cuidador como backup, instrucciones fisicas
Usuarios no tecnicos	Alto	UX simplificada, multiples recordatorios
Usuarios con una sola cuenta	Medio	Forzar backup en multiples ubicaciones
Usuarios con cuidadores	Bajo	Cuidador puede tener copia de Recovery Key

5. Modelo Hibrido Recomendado¶

Dado el analisis, se propone un modelo hibrido que balancea privacidad con usabilidad:

5.1 Arquitectura Hibrida¶

+------------------------------------------+
|           DATOS DEL PACIENTE              |
+------------------------------------------+
|                                          |
|  NIVEL 1: Datos Super-Sensibles (E2E)    |
|  - Notas personales sobre medicamentos   |
|  - Fotos de recetas con datos visibles   |
|  - Mensajes con medicos                  |
|  -> Cifrado E2E, solo paciente descifra  |
|                                          |
|  NIVEL 2: Datos Sensibles (Cifrado std)  |
|  - Lista de medicamentos                 |
|  - Historial de tomas                    |
|  - Mediciones de salud                   |
|  -> Cifrado AES-256, MedTime puede       |
|     acceder con autorizacion             |
|                                          |
|  NIVEL 3: Metadata (Sin cifrar)          |
|  - Timestamps de acceso                  |
|  - Eventos de sincronizacion             |
|  - Logs de auditoria                     |
|  -> Necesarios para cumplimiento         |
|                                          |
+------------------------------------------+

5.2 Opcion de Usuario¶

+------------------------------------------+
| CONFIGURACION DE PRIVACIDAD               |
+------------------------------------------+
|                                          |
| Nivel de cifrado:                        |
|                                          |
| ( ) Estandar                             |
|     MedTime puede ayudarte si pierdes    |
|     acceso. Datos cifrados en reposo.    |
|                                          |
| (o) Maximo (E2E Zero Knowledge)          |
|     Solo tu puedes ver tus datos.        |
|     Si pierdes tu Recovery Key,          |
|     tus datos seran IRRECUPERABLES.      |
|                                          |
|     [!] Requiere guardar 24 palabras     |
|                                          |
| [Continuar]                              |
+------------------------------------------+

5.3 Compartir Datos con E2E¶

sequenceDiagram
    participant P as Paciente
    participant M as MedTime
    participant D as Doctor

    P->>M: Quiero compartir con Dr. Garcia
    M->>P: Dr. Garcia tiene cuenta?

    alt Doctor tiene cuenta MedTime
        M->>D: Notificacion de solicitud
        D->>M: Acepta y envia clave publica
        M->>P: Clave publica del doctor
        P->>P: Cifra seleccion con clave doctor
        P->>D: Envia paquete cifrado
        D->>D: Descifra con clave privada
    else Doctor no tiene cuenta
        P->>P: Genera clave temporal
        P->>P: Cifra con clave temporal
        P->>M: Genera link de acceso
        M->>D: Link + instrucciones
        P->>D: Envia clave temporal (otro canal)
        D->>M: Accede con link
        D->>D: Descifra con clave temporal
    end

6. Recomendaciones Finales¶

6.1 Para v1.0 de MedTime¶

Recomendacion	Prioridad	Justificacion
Implementar cifrado AES-256 estandar	Critica	Cumple regulaciones, usable
Ofrecer E2E como opcion Pro/Perfect	Alta	Usuarios avanzados lo valoran
Recovery Key obligatoria para E2E	Critica	Previene perdida de datos
Multiples advertencias sobre riesgos	Critica	Proteccion legal
Backup de Recovery Key en iCloud/Google	Media	Conveniencia vs seguridad

6.2 Checklist de Implementacion E2E¶

Generacion segura de claves (CSPRNG)
Recovery Key con BIP39 (24 palabras)
Onboarding con verificacion de backup
Sincronizacion de claves multi-dispositivo
Protocolo de comparticion asimetrica
UI clara para estado de cifrado
Advertencias legales y consentimiento
Documentacion de usuario sobre riesgos
Pruebas de recuperacion de desastres

6.3 Decision Final Sugerida¶

+------------------------------------------+
| DECISION ACL7-001: CIFRADO E2E            |
+------------------------------------------+
|                                          |
| OPCION RECOMENDADA: Modelo Hibrido       |
|                                          |
| 1. Cifrado estandar (AES-256) por defecto|
|    - Cumple HIPAA/LGPD                   |
|    - Permite soporte y recuperacion      |
|    - UX amigable                         |
|                                          |
| 2. E2E opcional para usuarios Pro/Perfect|
|    - Maxima privacidad                   |
|    - Recovery Key obligatoria            |
|    - Advertencias explicitas             |
|                                          |
| 3. E2E obligatorio para compartir        |
|    - Paquetes cifrados punto a punto     |
|    - Solo receptor puede descifrar       |
|                                          |
+------------------------------------------+

7. Referencias¶

Fuentes de Investigacion¶

Documentos MedTime Relacionados¶

MTS-AUTH-001: Autenticacion y Seguridad
MTS-PRI-001: Privacidad y Consentimiento
MTS-BCK-001: Backup y Restauracion
MTS-OFF-001: Modo Offline
06-reglas-de-negocio.md: Reglas RN-PRI-*

Documento generado por SpecQueen - "La resistencia es futil. Tu especificacion sera perfecta... o no sera."