SPB
Las APIs del módulo SPB están diseñadas para codificar y decodificar mensajes en el estándar SPB (Sistema Brasileño de Pagos), de acuerdo con el Manual de Seguridad de la RSFN (Red Nacional del Sistema Financiero) publicado por el BACEN (Banco Central de Brasil).
Información
La aplicación actual se ajusta a la versión 5.0 del Manual de Seguridad RSFN publicado por el BACEN en junio de 2021.
El Sistema Brasileño de Pagos (SPB) funciona con un sistema de intercambio de mensajes entre instituciones financieras en una red privada denominada RSFN. Las normas son definidas y publicadas por el Banco Central. Todos los mensajes intercambiados son encriptados y firmados digitalmente utilizando un esquema de sobre digital. El módulo SPB se encarga de gestionar la seguridad de los mensajes.
Información
El uso del módulo SPB en un escenario con varios HSMs debe realizarse con el mecanismo de replicación de HSMs configurado y operativo, de forma que la base de certificados en los HSMs esté siempre sincronizada y completa, independientemente de qué HSM haya utilizado la aplicación en cada operación.
El módulo SPB realiza básicamente tres funciones: Codificación y Decodificación en mensajes SPB, y gestión de certificados SPB.
La codificación se realiza sobre los mensajes que van a la cola de salida y consiste en:
- Firmar el contenido (hash) del mensaje con la clave privada correspondiente al certificado propio de la institución (origen);
- Generar una clave de sesión simétrica;
- Cifra el mensaje con la clave simétrica;
- Cifre la clave simétrica con la clave pública del certificado de la institución que recibe el mensaje;
- Configure la cabecera de seguridad;
- Entrega la cabecera de resultados+mensaje cifrado a la aplicación, que lo pondrá todo en una cola de salida;
La descodificación realiza el proceso inverso, actuando sobre los mensajes que llegan a la cola de entrada;
- Recibe el mensaje cifrado y la cabecera SPB;
- Descifra la clave simétrica con la clave privada de la propia institución (destino)
- Descifra el mensaje con la clave simétrica;
- Verifica la firma digital con la clave pública del certificado de la institución remitente (origen)
- Envía el mensaje abierto a la aplicación;
Toda operación con claves públicas y privadas está ligada al uso de certificados X.509, por lo que además de Codificar y Decodificar el módulo SPB también necesita disponer de alguna gestión de certificados.
Cada institución se identifica en el SPB por su código ISPB (8 dígitos) y puede intercambiar mensajes en los llamados dominios de mensajes, cada uno de los cuales requiere un certificado diferente. Cada institución sólo puede tener un certificado activo a la vez en un dominio.
En el módulo SPB, las instituciones (y sus certificados equivalentes) sólo pueden identificarse mediante el código ISPB.
El módulo SPB se encarga de encriptar los mensajes de acuerdo con las definiciones del BACEN, y la estructura de comunicación SPB puede ser utilizada por otros sistemas entre instituciones financieras motivados, por ejemplo, por la aparición de nuevas aplicaciones dentro del BACEN:
- SPB gestiona el STR - Sistema de Transferencia de Recursos (STR01)
- MES opera Sisbacen (MES01, MES02)
- El CIP gestiona el SCG - Sistema de Control de Garantías y el C3 - Sistema Central de Asignación de Créditos.
Cada uno de estos sistemas puede tener una clave/certificado y se tratará como un dominio en la aplicación de control de mensajería. Si la organización opera más de un BIP, cada uno de ellos deberá acceder a una partición de clave independiente dentro del HSM. Hay casos en los que una institución puede operar MES/SPB con la misma clave/certificado.
En HSM, la gestión de certificados se realiza mediante Mapas, que son objetos de señalización y referencia. Todas las referencias en el módulo SPB son a Mapas, no a claves y certificados.
En cuanto a la nomenclatura interna que se describe a continuación, la idea es que las claves, certificados y mapas sean gestionados por las funciones SPB especializadas de la biblioteca cliente HSM, de forma que estas reglas de nomenclatura sean totalmente transparentes para la aplicación, que sólo tiene que buscar el código ISBP.
Conservación de certificados
Si las funciones de codificación y descodificación sólo tuvieran que gestionar mensajes con certificados activos, bastaría con mantener estos certificados en la base, pero hay casos, como un proceso de auditoría, en los que la aplicación necesita abrir o verificar la firma de un mensaje antiguo que se generó con un certificado que ya ha sido desactivado (o que seguirá activado en el futuro). Por eso, el HSM necesita guardar y acumular todos los certificados de la base, tanto propios como de terceros, a medida que se importan, activan y desactivan.
Formato UTF-16 BE en XML
El manual BACEN especifica que los mensajes XML deben representarse en formato Unicode UTF-16 BE. No importa para HSM, ya que el contenido que se firmará y cifrará en Encode será exactamente el enviado por el usuario.
Atención
HSM no convierte automáticamente los formatos, ni en la entrada de codificación ni en la salida de descodificación.
Banderas de tratamiento especial
El manual menciona mensajes y punteros de archivos que pueden incluirse en el contenido de un mensaje SPB. La diferencia es que los mensajes XML deben representarse en formato UTF16-BE, mientras que los archivos no tienen este requisito.
Esta distinción entre mensaje y archivo es importante para la persona que llama, ya que decidirá si necesita convertir el formato o no antes de enviarlo al HSM.
En el caso de los mensajes que indican contenido comprimido, la premisa de la aplicación es que el remitente dispone de la infraestructura de compresión necesaria, por lo que el HSM firma y cifra lo que la aplicación pasa en Encode, mientras que en el caso del destinatario la premisa es que puede no disponer de la infraestructura de descompresión, por lo que el HSM descomprime el contenido en Decode y entrega el contenido descomprimido, lo que incluye la detección automática de si el estándar utilizado es gzip o pkzip.
Todos los mensajes enviados están firmados, y algunos pueden ser de uso público, sin destinatario especificado.
| C04 | Mensaje | Archivo | Firmado | Cifrado | Con cremallera | Destinatario | Codificar | Descodifique |
|---|---|---|---|---|---|---|---|---|
| 0 | x | x | x | |||||
| 1 | x | x | x | use cert not yet activated | use cert not yet activated | |||
| 2 | x | x | público | acepta el destino en blanco | acepta el destino en blanco | |||
| 3 | x | x | ||||||
| 4 | x | x | ||||||
| 6 | x | x | público | acepta el destino en blanco | acepta el destino en blanco | |||
| 8 | x | x | x | x | ya debería recibirlo comprimido | se descomprime automáticamente | ||
| 10 | x | x | x | público | ya debería recibirlo comprimido | se descomprime automáticamente |
Intercambio automático de certificados
Según la definición de Bacen, los intercambios y activaciones de certificados SPB se realizan dentro del sistema mediante mensajes específicos.
El HSM puede detectar este tipo de mensaje en Decode y promover el intercambio del certificado en la base del HSM automáticamente, sin que la aplicación tenga que llamar explícitamente a la API de activación de certificados.
Se trata de una opción de parametrización de la llamada Decode.
El HSM se encargará de la descodificación de GEN0007 (aviso de actualización de certificado mediante difusión BACEN) y de la respuesta a un GEN0008 (una consulta al certificado digital, cuya respuesta es un GEN0008R1), así como de GEN0018 (certificado BACEN). En el caso de HSM, GEN0007 y la respuesta a GEN0008 son equivalentes. En el caso de GEN0018, el certificado en el mensaje se importa, pero no se activa automáticamente, porque el manual especifica que BACEN envía los mensajes al menos 03 días antes de la activación; por lo que la aplicación es responsable de controlar el tiempo entre la recepción y la activación; y para activarlo basta con informar a CA y NS, porque el certificado ya estará importado en la base de HSM.
El mensaje GEN0006 es utilizado por las instituciones para informar al BACEN de la activación o actualización del estado de un certificado. En el HSM este mensaje (y también la respuesta GEN0006R1) no recibe un tratamiento especial, ya que no requiere cambios en la base local.
El flujo normal de operaciones para activar un nuevo certificado implica un mensaje GEN0006 de la institución al BACEN, que a su vez envía un mensaje de difusión GEN0007 informando a todos los participantes de que el certificado de la institución debe cambiarse. Como la propia institución también recibe este GEN0007, es en este punto (durante la descodificación) cuando la aplicación puede ordenar al HSM que active automáticamente el nuevo certificado en su base local.
Formato del certificado
Internamente, HSM sólo opera, importa y exporta certificados en formato DER (binario), pero en la biblioteca las operaciones de importación de certificados admiten tanto el formato DER como el PEM (base64), con detección automática.
Nomenclatura
El módulo SPB del HSM permite realizar operaciones de codificación y descodificación de mensajes SPB utilizando claves y certificados dentro del HSM.
Esto significa que toda la base de certificados y claves privadas de la propia entidad y de las entidades con las que el banco se comunica estará almacenada y centralizada en el HSM, sin necesidad de control externo.
La identificación de las claves y certificados a utilizar se realiza utilizando el código BIPP de las instituciones de forma natural para las aplicaciones convocantes, en lugar del modelo común de utilizar los identificadores nativos de las claves y certificados.
Para establecer esta relación entre los BIPP y las claves y certificados, se utilizó un objeto del HSM denominado map, que simplemente vincula un BIPP a una clave privada y/o un certificado. Esto permite pasar únicamente el BISP a una llamada de codificación SPB en lugar de un nombre de clave.
Nomenclatura clave interna
Para facilitar su uso, se define una ley de formación para los nombres de estos objetos.
- Nombres clave:
k_<ISPB>_<dom>_<yyyymmddhhmmss> k: 01 carácter, literal<ISBP>: 08 caracteres, código ISPB<dom>hasta 05 caracteres, dominio<yyyymmddhhmmss>: 14 caracteres, GMT-0 timestamp en el momento de la generación de la clave.
Total: hasta 31 caracteres, por ejemplo k_12345678_str01_20131029110223
- Nombres de los certificados:
c_<ISPB>_<dom>_<yyyymmddhhmmss> c: 01 carácter, literal<ISBP>: 08 caracteres, código ISPB<dom>hasta 05 caracteres, dominio<yyyymmddhhmmss>: 14 caracteres, timestamp GMT-0 desde el momento en que se importó el certificado.
Total: hasta 31 caracteres, por ejemplo c_12345678_spb_20131101120334
La misma ley de formación se aplica a los certificados de terceros.
Mapa
O mapa es simplemente un objeto interno de HSM que almacena el Ids de otros dos objetos. En el caso del módulo SPB, el módulo Id del certificado y el Id de la clave privada. Cada Id ocupa una posición dentro del mapa denominada ranura.
Nomenclatura del mapa interno de SPB
Dado que cada mensaje implica el procesamiento de certificados, el módulo SPB necesita una forma de identificar de forma única cada certificado para cada institución en cada dominio. Según el estándar Bacen, cada certificado tiene un número de serie (SN) de hasta 32 bytes, definido por la autoridad de certificación (CA) que lo emite, pero no hay garantía de que los números de serie sean globalmente únicos, por lo que la identificación del certificado debe incluir información de la CA (cada CA en el SPB tiene un byte de identificación) y el SN, que supera el límite de 32 caracteres para los identificadores HSM; el RFC 3280 también hace esta distinción para identificar de forma única un certificado. Los Ids de los mapas de certificados utilizados en el módulo SPB utilizan un esquema de compresión de nombres.
La solución adoptada es un hash MD5, que tiene exactamente 16 bytes (32 caracteres) y no produce colisiones para este caso de uso. La definición de lo que entrará en la composición del hash es (CA+NS)donde CA e SN están formados por caracteres hexadecimales en mayúsculas.
- CA tiene un tamaño de 2, que representa un byte.
- SN tiene un tamaño de 32 y debe completarse con un relleno cero a la izquierda (según el manual de seguridad 3.2 del SPB) cuando el tamaño SN del certificado sea inferior a 32.
- La concatenación CA+SN debe realizarse sin contar los terminadores NULL.
Los mapas de certificados activos se identificarán como <ISPB>_<dom> en la base HSM, y la aplicación se referirá a ellos como ISPB@dom. O @ se adopta para mejorar la nomenclatura en el cliente, internamente en el firmware @ se traduce en _.
El uso de @dom por parte de la aplicación de llamada es opcional; la institución puede no utilizar dominios de aplicación.
Desde el punto de vista de la aplicación que llama, puede referirse a los mapas como ISPB@dom o CA@NSpara utilizar la misma API de codificación/decodificación. La biblioteca HSM lo detecta automáticamente.
Los mapas permiten que las ranuras apunten a un FQN, lo que significa que el certificado y la clave pueden estar en particiones diferentes. En cualquier caso, el mapa debe existir siempre en la partición del usuario logueado, aunque los ids apuntados en las ranuras estén en otra partición. En principio, la mejor forma de utilizarlo es mantener todos los certificados y claves de un BIP en la misma partición, sin referencias a particiones remotas.
Para facilitar la identificación de objetos y la búsqueda de BISP, los certificados activos y los pares certificado+clave privada disponen de un MAPA con el identificador BISP.
Todos los certificados y pares certificados+claves privadasindependientemente de si están activos o no tienen un MAP con id MD5(CA+SN) para la identificación y la historia, donde CA es el identificador de la Autoridad de Certificación y SN es el número de serie del certificado.
El nombre del objeto mapa es el identificador de la institución, que puede ser de 2 tipos:
CA@SN- CA (Autoridad de certificación) y NS (Número de serie) del certificado.
- Se hace un hash MD5 de estos datos y el resultado es el nombre del MAP.
-
Este mapa se genera automáticamente para todos los certificados y pares certificado + clave privada cuando se importan a través de las API de SPB (p. ej:
DSPBImportCertificate(), ...). Ejemplo:03@00000000000000000000000087654321 -
BISP@Dominio - Se genera un nombre específico para el mapa utilizando ISPB y DOMINIO.
- El dominio no es obligatorio. Los identificadores solo pueden crearse con BISP.
- Este tipo de mapa sólo se genera para certificados activos y pares certificado+clave.
- La eliminación de este mapa hace que el certificado correspondiente quede inactivo.
Ejemplo:
12345678@MES01
La documentación de la API indica si se aceptan ambos tipos de identificador o sólo uno de ellos.
Particiones múltiples
Si desea utilizar objetos en las particiones de otros usuarios, debe especificar el id de la partición en el identificador.
La indicación se realiza añadiendo el nombre de la partición donde se encuentran los objetos al principio del identificador, separado por /.
Por ejemplo: usuario/12345678@MES01
Codificar
La secuencia de API DSPBEncodeInit(), DSPBEncodeCont() e DSPBEncodeEnd() realizar una operación de codificación de mensajes SPB.
La estructura de llamada con secuencia init/cont/end permite a la aplicación llamante utilizar la API con cualquier tamaño de mensaje, incluidos archivos de gran tamaño.
El uso de parámetros con identificadores ISBP de origen y destino en las API pretende aumentar el nivel de comprobación entre lo que la aplicación tiene realmente (el mensaje SPB) y lo que cree que tiene (los parámetros API).
La operación de cifrado no modifica el formato de representación del mensaje, por lo que la aplicación debe enviar el mensaje tal y como lo defina el Banco Central (por ejemplo, UTF-16BE). El mensaje se cifrará y firmará a medida que se reciba.
Descodifique
La secuencia de API DSPBDecodeInit(), DSPBDecodeCont() e DSPBDecodeEnd() realizar una operación de descodificación de mensajes SPB.
La estructura de llamada con secuencia init/cont/end permite a la aplicación llamante utilizar la API con cualquier tamaño de mensaje.
El uso de parámetros ISBP de origen y destino en las API pretende aumentar el nivel de comprobación entre lo que la aplicación tiene realmente (el mensaje SPB) y lo que cree que tiene (los parámetros API).
Durante la descodificación, el firmware del HSM es capaz de detectar que el mensaje se refiere a un cambio de certificado y realizar esta actualización y activación automáticamente (sin necesidad de que la aplicación realice ninguna otra acción). bAutoUpdateCert debe estar encendido.
La operación de descifrado no cambia el formato de representación del mensaje. El mensaje se pasará a la aplicación tal y como fue descifrado.
Consola gráfica
Para facilitar la gestión y abstraer los detalles más complejos del módulo SPB, el fabricante del HSM proporciona una consola gráfica (SPBSec Console). A través de ella, se pueden realizar fácilmente todas las operaciones relativas a la carga y activación de certificados, generación de claves y solicitudes de certificados, creación y visualización de dominios, autorización de particiones y muchas otras.
Consulte el tema Descargas sobre cómo obtener la consola gráfica del módulo SPB (SPBSec Console).
A continuación se muestran algunas capturas de pantalla.
