Gestión de llaves para encriptación de datos

Gestión de Llaves y Cifrado de Datos Sensibles

Introducción

Este documento describe el proceso y la arquitectura implementada para la gestión de llaves y el cifrado de información sensible que viaja entre la plataforma (Milio) y sus integraciones (Webhooks, SDK y APIs de pago).

Cada empresa registrada dispone de mecanismos criptográficos y endpoints específicos para habilitar una comunicación segura, garantizando la confidencialidad e integridad de la información sensible mediante cifrado asimétrico y esquemas híbridos.


Descripción General del Sistema

El sistema está diseñado para:

  • Cifrado Asimétrico y Bidireccional: Permitir la comunicación segura usando pares de llaves pública/privada (RSA).
  • Gestión de Llaves: Proveer funcionalidades para la carga, actualización, rotación y revocación de las llaves asignadas a cada empresa.
  • Soporte Híbrido de Alto Rendimiento: Combinar la potencia de RSA con la velocidad de AES-256-GCM para el envío de payloads sin límite práctico de tamaño.
  • Seguridad e Integridad: Garantizar que los datos no puedan ser leídos por terceros ni alterados en tránsito.

Funcionamiento de la Gestión de Llaves

Principio de Encriptación Criptográfica

La comunicación se basa en el uso de criptografía asimétrica y cifrado simétrico:

  • Llave Privada: Se mantiene en secreto y nunca debe ser compartida ni enviada a los servidores de Milio.
  • Llave Pública: Se comparte entre las partes y se utiliza para cifrar datos que solo el propietario de la correspondiente llave privada podrá descifrar.

Flujo de Confianza y Bidireccionalidad

La plataforma y el cliente establecen una relación de confianza bidireccional intercambiando únicamente sus llaves públicas:

  1. Mensajes enviados a Milio: Se cifran con la Llave Pública de Milio. Solo Milio puede descifrarlos usando su llave privada.
  2. Mensajes enviados al Cliente (Webhooks/Respuestas SDK): Se cifran con la Llave Pública del Cliente. Solo el cliente puede descifrarlos con su llave privada.

Generación de Llaves

Se generan dos pares de llaves con configuraciones inversas:

  • Par de Llaves A
    • Llave Privada (Cliente):
    • Llave Pública (Milio):
  • Par de Llaves B
    • Llave Pública (Cliente):
    • Llave Privada (Milio):
  • Reemplazo de Llaves: En el caso de que se detecte una vulnerabilidad o compromiso de alguna de las llaves, el sistema permite:
    • La revocación del par de llaves afectado.
    • La generación y activación automática de un nuevo par de llaves para el cliente afectado.

Requisitos Técnicos de la Llave

Para registrar una llave pública en la plataforma, esta debe cumplir estrictamente con:

  • Algoritmo: RSA
  • Formato: PEM (PKCS1)
  • Tamaño de módulo: Mínimo 8192 bits (llaves con módulos inferiores serán rechazadas automáticamente al registrarse).

Modos de Cifrado (encryptionType)

Cada empresa se configura con un modo de cifrado que decide cómo se procesa y envuelve cada payload antes de ser transmitido:

ModoAlgoritmo y MecanismoLímite de TamañoEstado
RSA_SHA256RSA-OAEP directo sobre el dato, hash SHA-256 en relleno.Pequeño (~unos cientos de bytes).Recomendado solo para cargas muy pequeñas.
HYBRIDAES-256-GCM para el dato + RSA-OAEP-SHA256 para la llave AES.Sin límite práctico.Recomendado por defecto.

Nota sobre SHA-256: SHA-256 por sí solo es una función hash de una sola vía (irreversible) y no cifra información. Se utiliza como componente interno dentro del relleno OAEP de RSA y para la verificación de integridad.



El Sobre Híbrido (HYBRID), Paso a Paso

Dado que RSA por sí solo únicamente puede cifrar mensajes de tamaño reducido, el modo HYBRID resuelve esta limitación combinando cifrado simétrico y asimétrico.

Para cada mensaje enviado, el sistema genera al vuelo una llave simétrica AES y un Vector de Inicialización (IV) totalmente aleatorios y desechables (nunca se reutilizan entre mensajes).


Proceso de Cifrado (Emisión)

  1. Generación de la Llave Efímera: Se crea en memoria una llave aleatoria AES-256 (y su iv).
  2. Cifrado del Payload con AES: El contenido sensible completo (JSON, datos de pago, etc.) se cifra usando esa llave aleatoria con AES-256-GCM, generando el dato cifrado (data) y la etiqueta de autenticación e integridad (tag).
  3. Protección de la Llave con RSA: Como la llave aleatoria AES es muy pequeña, se cifra usando RSA-OAEP-SHA256 con la Llave Pública del destinatario para producir el campo key.
  4. Estructura del Sobre JSON: Todos los elementos se empaquetan en un objeto JSON con encabezado application/json:
{
  "v": 2,
  "key": "S2+E5KfUGapgMSLNJo1Z21vzjPF8OzSGhwAaWsGe...==",  // Llave AES aleatoria cifrada con RSA (Base64)
  "iv":  "2h1rn+R86T7sX1S8",                        // Vector de Inicialización - 12 bytes (Base64)
  "tag": "bkWsWR/olEJ7EJ1TCtHqlQ==",                 // Etiqueta de Autenticación GCM (Base64)
  "data": "X89++4ZfrG91B2CQKUMy5OSOgroufrxMtnnO0us...==" // Payload sensible cifrado con la llave AES (Base64)
}