Modelo de Seguridad Payouts

En este artículo revisaremos en detalle las propiedades de seguridad del modelo de Shinkansen Payouts. Si buscas una introducción mas amable al servicio de Payouts te recomendamos esta otra guía.

📘

Un mini-glosario antes de continuar:

• Participant(e): Una fintech/startup que está conectada a la red Shinkansen.
• Debtor: En el contexto de Payout, el originador del movimiento.
• Creditor: En el contexto de Payout, el destinatario del movimiento.
• PO: Operador de Dispersión, partner de Shinkansen, que ejecuta la dispersión de fondos (ej: un banco)
• PSC: Proveedor de servicios de certificación/confianza.

Si bien un PO podría otorgarle crédito a los Participantes de la red, este documento asumirá que las transferencias usan fondos existentes que el Participante mantiene en una cuenta en el PO. Esto sin pérdida de generalidad, pues las consideraciones de seguridad son fundamentalmente las mismas: evitar que sea posible ejecutar un movimiento de fondos que no ha sido genuinamente originado en el Participante.

Dado que existe una relación contractual entre el PO y el Participante (que le permite a este último contar con una cuenta en el PO), podemos asumir también que el PO cuenta con medios para comunicarse directamente con el Participante y su(s) apoderado(s) legal(es).

Finalmente, para la seguridad del sistema operaremos con certificados emitidos por una tercera entidad (el PSC), quienes ya operan en las distintas jurisdicciones la infraestructura necesaria para identificar personas (jurídicas o naturales) y emitir certificados que les permiten a estas personas firmar digitalmente información que puede ser verificada o descifrada por otros.

En consecuencia, las relaciones entre los actores del sistema son:

flowchart LR
    Shinkansen <-->|partnership con| PO
    Participante <-->|conectado a| Shinkansen
    Participante <--> |tiene cuenta en| PO
    Participante <--> |obtiene/valida certificados via| PSC
    Shinkansen <--> |obtiene/valida certificados via| PSC
    PO <--> |obtiene/valida certificados via| PSC

editar

Técnicamente el modelo funciona igualmente con múltiples PSC pero para efectos ilustrativos asumiremos que todas las partes generan y validan certificados con el mismo PSC.

Entonces, existirán tres flujos que involucran firmas y certificados:

• Obtener un certificado
• Dar de alta/baja/rotar certificados en la red Shinkansen
• Enviar mensajes (ej: instrucciones de payouts) firmados en la red Shinkansen

Diagramaremos el proceso desde la perspectiva de un Participante que envía su certificado a Shinkansen y al PO, pero el proceso es equivalente para la distribución de certificados de un PO hacia Shinkansen y los Participantes con cuenta en ese PO.

Obtener un certificado

El proceso de obtención del certificado es un proceso bastante estándar. Al hacer zoom distinguiremos entre el Participante y su Apoderado (pues el certificado identificará al Apoderado).

sequenceDiagram
    participant Apoderado
    participant Participante
    participant Shinkansen
    participant PO
    participant PSC
    autonumber
    Apoderado ->> PSC: Demuestra su identidad
    PSC ->> Apoderado: Entrega certificado 🔖 (🔑 pública + identificador, firmada por PSC)
    Apoderado ->> Participante: Entrega a Encargado de Seguridad 🔖 y 🔑 privada
    Participante ->> Participante: Almacena 🔖 y 🔑 privada
    Note right of Participante: Ej: via gestión segura de secretos o un servicio de key management, etc

La única diferencia dependerá del PSC a usar:

• Algunos requerirán que el Apoderado previamente genere una 🔑 privada y la use para generar un certificate request.

• Otros PSC se encargarán de la generación de la 🔑 privada pero después de entregarla al Apoderado dicha 🔑 privada desaparecerá de sus sistemas.

Sea cual sea el flujo, el Participante lo finaliza en posesión de:

• Un certificado 🔖 (que contiene una 🔑 privada + su identificación + la firma del PSC). Este deberá ser distribuido a la red Shinkansen.
• Una 🔑 privada que el Participante debe custodiar bajo los mayores estándares de seguridad de la información, y jamás entregar a ningún ente externo (ni tampoco a actores internos no autorizados).

Dar de alta/baja/rotar certificados

Comencemos con el flujo más obvio: Sumar el primer certificado a usar en la red. Para eso, el flujo es el siguiente

sequenceDiagram
    participant Apoderado
    participant Participante
    participant Shinkansen
    participant PO
    participant PSC
    autonumber
    Participante ->> Shinkansen: Envía cadena de 🔖  + glosa "primer certificado"
    Shinkansen ->> Shinkansen: Valida 🔖 (expiración, cadena de firmas hasta root de PSC)
    Shinkansen -->> PSC: Comprueba que 🔖 no ha sido revocado
    Shinkansen -->> Participante: Notifica al Encargado de Seguridad del enrolamiento
    Shinkansen -->> Participante: En caso que Shinkansen lo determine necesario, pide confirmación al Encargado de Seguridad
    Shinkansen ->> Shinkansen: Almacena cadena de 🔖
    Shinkansen ->> PO: Envia cadena 🔖 + glosa "primer certificado"
    PO ->> PO: Valida 🔖 (expiración, cadena de firmas hasta root de PSC)
    PO ->> PSC: Comprueba que 🔖 no ha sido revocado
    PO ->> PO: Almacena cadena de 🔖
    PO ->> Shinkansen: Responde con status (aceptado, rechazado, pendiente de confirmacion)
    rect rgb(191, 223, 255)
    note over PO: Flujo Recomendado: Confirmar uso de certificado
    PO ->> Apoderado: ¿Confirma uso de certificado 🔖 con emitido por PSC en la fecha DD/MM/AAA?
    Apoderado ->> PO: Confirmo (con clave + idealmente 2FA)
    PO ->> PO: Marca 🔖 como confirmado para operar
    PO ->> Shinkansen: Notifica status (aceptado, rechazado)
    end
    Shinkansen ->> Participante: status (aceptado, rechazado)

Notar que toda la comunicación y operación se puede realizar automatizada, mediante APIs (con excepción del recuadro con fondo azul que requiere intervención manual del Apoderado y la potencial confirmación del Encargado de Seguridad).

Shinkansen recibe directamente el certificado desde el participante (autenticado con API Keys) y el certificado está además firmado por el PSC, lo que le da a Shinkansen un grado de seguridad razonable de que el certificado proviene del Participante.

El PO podría confiar en Shinkansen + PSC, pero recomendamos considerar un flujo adicional donde el PO (que al contar con una relación contractual con el Participante y Apoderado tiene la información de contacto relevante) pida al Apoderado confirmar el uso del certificado.

❗️

Mitigación de Phishing Como veremos más adelante, esta confirmación adicional permite mitigar escenarios de phishing (improbables, pero posibles) y asegurar aún más el modelo completo.

Entonces, un Participante ya tiene un certificado operando en Shinkansen. ¿Pero qué pasa si desea rotar el certificado y llaves cada 3 meses como una buena práctica de seguridad? ¿O qué ocurre si sospecha que la llave pudo estar comprometida y quiere cambiar todo como una emergencia?

Para resolver eso, un API similar a la del paso 1 del diagrama permite subir un certificado permite también dar de baja certificados previos. Los parámetros de estas transacciones son:

• Para un nuevo certificado:

  • Razón (ej: "primer certificado", "rotación trimestral de certificado", ...).
  • Nuevo certificado.
  • Recomendado: firma del mensaje con otro certificado activo.

• Para dar de baja un certificado:

  • Certificado a dar de baja lo antes posile
  • Razón (ej: "precaución por incidente de seguridad", "rotación trimestral", ...).
  • Recomendado: firma del mensaje con el mismo certificado u otro activo.

📘

Recomendamos a todos los participantes contar con 2 certificados activos a la vez, de manera de poder ejecutar rotaciones sin downtime. Shinkansen no establece un límite superior al número de certificados activos, pero no recomendamos más de 2. Porque basta que por accidente o ataque se filtre la llave de un sólo certificado para potencialmente mover fondos del Participante. Un número excesivo de llaves puede implicar un riesgo mayor de fuga.

En cuanto a flujo, es idéntico al descrito para enrolar el primer certificado: Shinkansen re-enviará al PO todos los parámeteros anteriormente descritos. En el caso de dar de baja un certificado, es posible (pero no mandatorio) que el PO no requerirá una confirmación del Apoderado con clave+2FA si el mensaje está firmado con el certificado que se está dando de baja.

Las glosas/razones son relevantes como traza de las razones de los participantes para introducir o dar de baja certificados en el sistema. Ausencia de información en ese campo puede provocar que Shinkansen no acepte la instrucción.

Enviar mensajes de payouts firmados

Gracias a ese setup, los mensajes de payouts pueden ser eficientes (sin necesidad de incluir la cadena completa de certificados en cada petición) y seguros:

sequenceDiagram
    participant Participante
    participant Shinkansen
    participant PO
    participant PSC
    autonumber
    Participante ->> Shinkansen: Envía mensaje de payout 💸 firmado, junto a 🔖.
    Shinkansen ->> Shinkansen: Verifica que 🔖 estaba previamente autorizado, carga cadena de 🔖 almacenada.
    Shinkansen ->> Shinkansen: Valida 🔖 (expiración, cadena de firmas hasta root de PSC)
    Note over Shinkansen: (Certificados pueden estar pre-validados en memoria como optimización)
    Shinkansen -->> PSC: Comprueba que 🔖 no ha sido revocado
    Note over Shinkansen , PSC: (Comprobación puede ser async/batch por mayor eficiencia)
    Shinkansen ->> Shinkansen: Valida que la firma corresponde dada la 🔑 pública del 🔖  y que corresponde a quien envía el payout en el mensaje.
    Shinkansen ->> PO: Re-envía 💸 + firma + 🔖 original, añadiendo meta-datos y firma + 🔖 Shinkansen.
    PO ->> PO: Verifica que 🔖 estaba previamente autorizado, carga cadena de 🔖 almacenada.
    PO ->> PO: Valida 🔖s (expiración, cadena de firmas hasta root de PSC)
    Note over PO: (Certificados pueden estar pre-validados en memoria como optimización)
    PO -->> PSC: Comprueba que 🔖s no han sido revocados
    Note over PO , PSC: (Comprobación puede ser async/batch por mayor eficiencia)
    PO ->> PO: Valida que las firmas de Participante y Shinkansen corresponden dada las 🔑 públicas de los 🔖
    PO ->> PO: Valida que el certificado corresponde a quien envía el payout en el mensaje
    PO ->> PO: Ejecuta 💸
    PO -->> Shinkansen: Envía respuesta (async) a Shinkansen (firmada)
    Shinkansen -->> Participante: Envía respuesta (async) a Participante (con firma de Shinkansen)

Por simplicidad y claridad no se ha detallado la verificación de firmas en las respuestas. Shinkansen y el Participante harán un proceso análogo para verificar la firma del PO, y el certificado del PO habrá sido recibido por el Participante de manera análoga a lo descrito en este documento, con excepción de la verificación con clave+2FA que suele ser impráctica (el apoderado del PO no suele tener una relación directa ni un sistema 2FA activo los sistemas del Participante, a diferencia de lo que ocurre en sentido inverso)

Notar que a diferencia del alta o rotación de certificados, en el mensaje de payout sólo se incluye el certificado de las partes que firman y no la cadena completa de certificados desde el certificado de quien firma hasta la raíz del PSC. Es decir, en caso que exista la siguiente cadena de certificados:

graph LR
    R[Certificado Raíz PSC] -->|firma| I(Certificado Intermedio PSC)
    I -->|firma| C(Certificado Apoderado Participante)

Entonces, en el proceso de alta de certificados se enviará la cadena completa (3 certificados). Pero en cada mensaje de payout sólo se enviará el "Certificado Apoderado Participante".

Modelo de Amenazas

La siguiente tabla resume amenazas críticas identificadas en los flujos descritos anteriormente (columnas) junto a sus mitigantes (filas).

Las siguientes secciones describen en detalle cada amenaza y la relación con los mitigantes.

A1: Alteración de mensajes via MITM

Recursos y capacidades del atacante:

• Capacidad de interceptar mensajes y enviar mensajes suplantando a un actor en la conexión TLS entre Participante y Shinkansen, o entre Shinkansen y PO (MITM attack).

Probabilidad: Muy Baja. Atacante requeriría (a) interceptar tráfico de red entre dos entidades con buenas prácticas de seguridad y (b) haber obtenido previamente las llaves privadas de certificados TLS de Shinkansen y/o PO.

Evaluación de impacto: Aún con esos recursos y capacidades, sin la llave privada del Participante (y la de Shinkansen), los mensajes no serán aceptados por Shinkansen (ni por PO). Pero existen riesgos de filtrado de información al vulnerarse el canal TLS en la capa HTTPS.

Riesgos de movimiento de dinero no autorizado:

• Ninguno identificado.

Riesgos de denegación de servicio:

• Si atacante ha conseguido interceptar el tráfico de red, podría evitar que las peticiones lleguen a destino.

Riesgos de escalamiento:

• Atacante podría obtener API Keys del Participante o de Shinkansen.

Mitigaciones:

• M1. Rotación frecuente de API Keys (ej: mensual) → Limita la ventana para potenciales escalamientos.

• M2. Múltiples factores de autenticación en API: Firmas + API Keys + TLS en HTTPS. Operaciones críticas son autenticadas con otros factores además de API Keys → Evita que las API Keys por sí solas sean la base de otro ataque.

• M3. Infraestructura segura de red. Se recomienda a todos los actores el uso de proveedores que cumplen las mejores prácticas de seguridad de la industria (ej: proveedores cloud reconocidos, datacenters propios operados bajo estándares de seguridad reconocidos) → Minimiza posibilidad de intercepción de tráfico de red.

A2: Sustracción de una llave privada

Recursos y capacidades del atacante:

• El atacante consiguió obtener una llave privada de un actor de la red, por ejemplo interceptando el proceso por el cual fue creada o transmitida internamente (o debido a una exposición accidental)

• Sin embargo, el atacante no tiene acceso a otras credenciales.

Probabilidad: Baja. Los actores tienen incentivos contractuales y financieros para mantener sus llaves apropiadamente custodiadas. Pero dado suficiente tiempo y actores eventualmente podrá ocurrir un accidente o robo de una llave.

Evaluación de impacto: El atacante podrá intentar firmar mensajes pero en ausencia de otras credenciales complementarias (ej: API Keys) no será suficiente para introducir un mensaje. Pero puede tener un impacto equivalente a A3 si se da en combinación con A1 o cualquier otro ataque que comprometa las API Keys del mismo actor.

Riesgos de movimiento de dinero no autorizado:

• Podría ocurrir, en combinación con otros ataques.

Riesgos de denegación de servicio:

• Si la parte involucrada decide anular el certificado asociado a la llave comprometida y no tenía otro certificado registrado cuya llave no haya sido vulnerada, el actor no podrá enviar mensajes en la red Shinkansen por el tiempo que demore la alta de un nuevo certificado.

Riesgos de escalamiento:

• Contar con la llave privada de un actor permite intentar otros ataques cuya mitigación se centra principalmente en firmas que solo pueden ser generadas con dicha llave.

Mitigaciones:

• M2. Múltiples factores de autenticación en API: Firmas + API Keys + TLS en HTTPS. Las API Keys son requeridas en conjunto con la firma para realizar operaciones → El atacante no puede conseguir que otros actores de la red acepten sus mensajes firmados.

• M4. Baja inmediata de certificado en red Shinkansen. Ante cualquier sospecha o riesgo de que una llave haya sido comprometida, los actores deben dar de baja el certificado asociado a través de la red Shinkansen firmando el mensaje con esa misma llave → Permite deshabilitar casi instantáneamente cualquier movimiento de dinero o escalamiento del ataque que el atacante pudiera intentar.

• M5. Segregación de llaves. De contar con más de una llave y certificado, es recomendable que su acceso esté segregado de manera que la vulneración de una de ellas no implique la vulneración de todas → Disminuye los escenarios de downtime para el actor afectado.

• M6. Revocación de certificado en PSC. Ante cualquier sospecha o riesgo de que una llave haya sido comprometida, los actores de la red deben notificar al PSC para que el certificado sea revocado → Permite deshabilitar (en los tiempos provistos por el PSC).

• M7. Verificación contra listas de revocación en PSC. Shinkansen verifica periódicamente con el PSC que los certificados no haya sido revocado y se recomienda lo mismo a los PO del sistema → Permite que ese segundo camino para detener a un atacante (via el PSC en lugar que via Shinkansen) sea efectivo.

A3: Sustracción de una llave privada y API Keys de un Participante

Recursos y capacidades del atacante:

• El atacante consiguió obtener todas las credenciales de un Participante del sistema a través de una intromisión en los sistemas de ese actor o mediante un ataque interno a la organización.

• El atacante conoce los números de cuenta de un Participante en su PO.

Probabilidad: Muy Baja - Baja. Los actores tienen incentivos contractuales y financieros para mantener sus llaves apropiadamente custodiadas. Un ataque así de profundo a sus sistemas revelaría una falla de ciberseguridad gravísima. Pero eventualmente dado suficiente tiempo y actores en la red, es posible que ocurra.

Evaluación de impacto: El atacante podrá suplantar al Participante en la red Shinkansen, enviando instrucciones en su nombre.

Riesgos de movimiento de dinero no autorizado:

• El atacante podría instruir movimientos de fondo a través de Payouts.

Riesgos de denegación de servicio:

• Ante un ataque de este tipo, es posible (y en algunos escenarios deseable) que el Participante deje de estar disponible en la red.

Riesgos de escalamiento:

• El atacante podría intentar dar de alta nuevas llaves privadas.

Mitigaciones:

• M1. Rotación frecuente de API Keys (ej: mensual) → Limita la ventana para un ataque una vez ha sido sustraída una API Key.

• M4. Baja inmediata de certificado en red Shinkansen. Ante cualquier sospecha o riesgo de que una llave haya sido comprometida, los actores deben dar de baja el certificado asociado a través de la red Shinkansen firmando el mensaje con esa misma llave → Permite deshabilitar casi instantáneamente cualquier movimiento de dinero o escalamiento del ataque que el atacante pudiera intentar.

• M5. Segregación de llaves. De contar con más de una llave y certificado, es recomendable que su acceso esté segregado de manera que la vulneración de una de ellas no implique la vulneración de todas → Disminuye los escenarios de downtime para el actor afectado.

• M6. Revocación de certificado en PSC. Ante cualquier sospecha o riesgo de que una llave haya sido comprometida, los actores de la red deben notificar al PSC para que el certificado sea revocado → Permite deshabilitar (en los tiempos provistos por el PSC).

• M7. Verificación contra listas de revocación en PSC. Shinkansen verifica periódicamente con el PSC que los certificados no haya sido revocado y se recomienda lo mismo a los PO del sistema → Permite que ese segundo camino para detener a un atacante (via el PSC en lugar que via Shinkansen) sea efectivo.

• M8. Mecanismo de Emergencia. Shinkansen y los PO contarán con un mecanismo de emergencia activado por el Encargado de Seguridad y Apoderado del Participante afectado → Permite acortar la ventana de tiempo en que el atacante puede mover fondos aún en situaciones de impacto extremo en que el Participante pierde acceso a sus propios sistemas.

• M9. Destinatarios de movimientos individualizados. La mensajería de movimientos de fondos siempre individualiza al destinatario → Queda una traza para recuperar los fondos y/o buscar a los responsables del ataque.

• M10. Límites por destinatario. Existirán límites a los montos que se pueden mover desde un mismo Participante hacia un mismo destinatario → Se contiene el impacto de movimiento de dinero no autorizado.

• M11. Límites por Participante. Existirán límites a los montos que se pueden mover desde un mismo Participante en un mismo día → Se contiene el impacto de movimiento de dinero no autorizado.

• M12. Certificados emitidos por un PSC externo. El enrolamiento de llaves requiere la participación de un PSC → El atacante no puede "plantar" nuevas llaves en el sistema sin involucrar un proceso de autenticación.

• M13. Flujo de alta de certificado explícito → Un atacante aún si posee un certificado obtenido fraudulentamente debe superar el flujo de alta del certificado.

• M14. Alta de certificados requiere confirmación de un Encargado de Seguridad. El enrolamiento de llaves requiere confirmación por parte del Encargado de Seguridad (requerido por Shinkansen) → El atacante no puede "plantar" nuevas llaves en el sistema aún si ha vulnerado a un PSC u obtenido un certificado válido de manera fraudulenta.

• M15. Se recomienda que alta de certificados requiera confirmación de Apoderado de Participante contra el PO (idealmente con 2FA).→ El atacante no puede "plantar" nuevas llaves en el sistema aún si ha vulnerado a un PSC u obtenido un certificado válido de manera fraudulenta.

• M16. Los actores del sistema no aceptan certificados que no hayan sido parte del flujo de alta de certificados → El atacante no puede bypasear el proceso de alta explícito.

A4: Obtención de un certificado por vía fraudulenta

Recursos y capacidades del atacante:

• El atacante consiguió atacar a un PSC y obtener un certificado que identifica a otra persona (ej: un Apoderado), junto a su llave privada.

• Alternativamente, mediante phishing o ingeniería social a un Apoderado el atacante consiguió suficiente información para burlar los controles de autenticación de un PSC y obtener un certificado que identifica a otra persona (ej: un Apoderado), junto a su llave privada.

• Otra posibilidad es que el atacante consiguió vulnerar sistemas que custodian ese tipo de certificados (ej: ERPs, Sistemas de facturación electrónica) y obtener un certificado previamente emitido que identifica a un tercero (ej: un Apoderado), junto a su llave privada.

Probabilidad: Baja - Media. Es extremadamente improbable una vulneración de un PSC (constantemente auditados y cuya existencia depende de la robustez de su seguridad). Sin embargo, escenarios de phishing no pueden ser descartados y la proliferación de servicios que almacenan certificados junto con una llave privada también hace posible la existencia de certificados válidos que identifican a un Apoderado y que han sido obtenidos fraudulentamente por terceros.

Evaluación de impacto: El atacante podría en principio firmar a nombre del Apoderado titular del certificado obtenido fraudulentamente, pero por si mismo no es suficiente para suplantar al Participante en la red.

Riesgos de movimiento de dinero no autorizado:

• Podría ocurrir en combinación con otros ataques.

Riesgos de denegación de servicio:

• Ninguno identificado.

Riesgos de escalamiento:

• El atacante podría combinar el certificado con otro ataque que le permita conseguir las API Keys para intentar suplantar a un actor en la red.

Mitigaciones:

• M2. Múltiples factores de autenticación en API: Firmas + API Keys + TLS en HTTPS. Se requieren API Keys de manera complementaria a certificados → Un certificado obtenido de manera fraudulenta por sí solo no es suficiente para suplantar a un actor de la red.

• M13. Flujo de alta de certificado explícito → Un atacante antes de usar un certificado fraudulento debe intentar darlo de alta en la red usando API Keys.

• M14. Alta de certificados requiere confirmación de un Encargado de Seguridad. → Incluso en posesión de API Keys un atacante tiene bajísimas probabilidades de conseguir plantar un certificado obtenido fraudulentamente.

• M15. Se recomienda que alta de certificados requiera confirmación de Apoderado de Participante contra el PO (idealmente con 2FA). → Incluso en combinación con API Keys un atacante tiene bajísimas probabilidades de conseguir plantar un certificado obtenido fraudulentamente.

• M16. Los actores del sistema no aceptan certificados que no hayan sido parte del flujo de alta de certificados → El atacante no puede usar el certificado sin pasar por el flujo de alta de certificados de la red.

A5: Repudio de participantes sobre mensajes enviados en la red

Recursos y capacidades del atacante:

• El atacante es un participante o PO que desconoce que haya enviado un mensaje que otro actor de la red reclama haber recibido (ej: una instrucción de payout).

Probabilidad: Baja - Media. En el largo plazo y con un número creciente de participantes y transacciones eventualmente algún actor podría tener incentivo para desconocer alguna operación accidental.

Evaluación de impacto: Litigación o pérdida de confianza entre actores de la red Shinkansen.

Riesgos de movimiento de dinero no autorizado:

• Ninguno identificado.

Riesgos de denegación de servicio:

• Las partes involucradas podrían decidir dejar de recibir mensajes de su contraparte al dejar de confiar en el mecanismo de autenticación usado en la red.

Riesgos de escalamiento:

• Ninguno identificado.

Mitigaciones:

• M12. Certificados emitidos por un PSC externo. El enrolamiento de llaves requiere la participación de un PSC → No es trivial que un tercero haya obtenido un certificado válido a nombre del Apoderado. Existe trazabilidad sobre la obtención del certificado, lo que hace improbable su repudio a menos que efectivamente haya sido obtenido por un tercero de manera fraudulenta.

• M13. Flujo de alta de certificado explícito. El alta de certificados requiere un enrolamiento explícito, con una glosa explicando el motivo y confirmación por parte de encargado de seguridad respectivo → Desconocer un certificado requiere explicar cómo fue obtenido un certificado de manera fraudulenta y luego explícitamente enviado a la red utilizando los API Keys del Participante.

• M14. Alta de certificados requiere confirmación de un Encargado de Seguridad. → Desconocer un certificado requiere explicar cómo fue explícitamente enviado a la red, notificado al Encargado de Seguridad, y aprobado por este.

• M15. Se recomienda que alta de certificados requiera confirmación de Apoderado de Participante contra el PO (idealmente con 2FA). → Desconocer un certificado por parte de un Participante que envió un mensaje al PO requiere explicar cómo fue explícitamente enviado a la red, notificado, y aprobado por el apoderado titular de dicho certificado.

Resumen y Conclusiones

En términos generales, para vulnerar el sistema y permitir que el dinero de un Participante en una cuenta de un PO sea transferida sin que el Participante realmente haya instruido dicha transferencia y aún así los mensajes registrados sean válidos se requiere:

A. Atacar directamente al Participante, mediante:

• Sustraer las API Keys de dicho Participante,
• Además sustraer una llave privada correspondiente a un certificado activo en la red Shinkansen para ese Participante,
• Y también actuar antes que el Participante consiga dar de baja el certificado en la red Shinkansen o en el PSC (o activar el protocolo de emergencia)

B. Alternativamente, vulnerar otros actores del sistema para impedir que se activen los controles descritos. Esto implica:

• Vulnerar los sistemas de PO,
• Además vulnerar los sistemas de Shinkansen,
• Y también obtener un certificado de un Apoderado del Participante por vía fraudulenta (o alternativamente vulnerar al PSC)

Aún en esos improbables escenarios, el posible impacto está limitado por los límites de transferencias diarios acordados (totales y al mismo destinatario) y quedará traza de las transacciones del atacante así como la individualización de los destinatarios de las transferencias realizadas como resultado del ataque.

Bonus Track: Recomendaciones para PO (Operadores de Payouts)

Estados de certificados

Recomendamos a los POs almacenar los certificados recibidos en el flujo de alta de certificados, junto a información relativa a su estado. En términos conceptuales los estados recomendados a manejar son de dos tipos:

• Estado del certificado:

  • válido (certificado con cadena de firmas correcta, no expirado, identifica a Apoderado)

  • inválido (certificado con algún problema en su cadena de firmas o no corresponde a Apoderado)

  • expirado (certificado expiró)

  • revocado (certificado fue revocado por el PSC)

    mermaid

    stateDiagram-v2
      [*] --> válido: todo OK
      [*] --> inválido: sin firma PSC o no identifica a un apoderado
      [*] --> expirado: estaba expirado
      [*] --> revocado: en lista de revocación del PSC
      válido --> expirado: supera la fecha de expiración
      válido --> revocado: revocado por el PSC
      expirado --> [*]
      revocado --> [*]
      inválido --> [*]
    

    

• Estado en la red Shinkansen:

  • pendiente (certificado recibido pero le faltan confirmación)

  • rechazado (certificado rechazado por el Apoderado o el Encargado de Seguridad)

  • activo (certificado confirmado)

  • desactivado (certificado desactivado por el participante o por emergencia)

    mermaid

    stateDiagram-v2
      [*] --> pendiente: certificado recibido y su estado es `válido`
      [*] --> rechazado: certificado recibido pero su estado NO es `válido`
      pendiente --> rechazado: Apoderado lo rechaza
      pendiente --> rechazado: Apoderado no responde en tiempo máximo determinado
      pendiente --> activo: Apoderado confirma
      activo --> desactivado: Certificado desactivado por el participante
      activo --> desactivado: Estado del certificado ya no es `válido`
      activo --> desactivado: Suspensión de emergencia
      desactivado --> [*]
      rechazado --> [*]
    

    

• El conjunto de certificados válidos para firmas de mensajes en Shinkansen incluye únicamente los que están en estado activo, los que necesariamente deberán ser también válidos

• Sin embargo, al cargar en memoria un certificado activo se debe verificar la cadena de firmas del certificado (para evitar potenciales ataques en la base de datos del PO) y su fecha de expiración (para transicionarlo a expirado y desactivado si se ha superado la fecha).

• Periódicamente se deberá consultar listas de revocación (vía OCSP y/o CRLs) para transcionar certificados a revocado y desactivado si ha ocurrido una revocación (notar que es posible que el certificado ya haya sido desactivado en la red previo a su revocación)

Chequeo cadena de firmas

• Es clave guardar los certificados raíz de los PSC en un almacén de certificados diseñado para tal efecto y con las medidas de seguridad respectivas. A diferencia de los certificados de otros actores y sus estados descritos anteriormente, donde una intromisión interna tiene efectos limitados (pues los certificados son validados de todas formas al leerlos de allí), los certificados raíz en caso de ser alterados en el PO pueden generar desde una denegación de servicio hasta procesar mensajes con firmas creadas con certificados no emitidos por el PSC.

• Cada vez que un certificado sea usado debe ser previamente validado contra dichos certificados raíz y contra la fecha de expiración respectiva.

• Cada vez que un certificado sea cargado en memoria debe ser previamente validado contra dichos certificados raíz. También debe controlarsela la fecha de expiración respectiva.

• Para ejecutar esta validación es importante almacenar no sólo los certificados de los Participantes sino también cualquier certificado intermedio de la cadena.

Chequeo de revocación de certificados

• También recomendamos verificar su posible revocación contra CRLs o OCSP según lo indique el certificado.

  • Verificar el mismo número de serie de certificado en cada petición será probablemente ineficiente, además de estar fuera de los parámetros de carga que el PSP espera en su endpoint de CRLs. En el caso de OCSP se recomienda respetar el intervalo de validez entre "This Update" y "Next Update" que en casos reales puede indicar que el siguiente refresco ocurrirá en varias horas, o días.

  • Por lo tanto recomendamos que el proceso de chequeo de revocación no sea parte del flujo transaccional, sino que sea realizado periódicamente contra todos los certificados en estados diferentes de revocado y diferentes de revocado-y-desactivado.