
Esta publicación de blog trata de explicar en palabras simples el PKCS #7 y CMS Normas y su relevancia para Integración en la nube de SAP (IPC).
Integración en la nube de SAP proporciona funcionalidad para agregar automáticamente características de seguridad a nuestros mensajes (los llamados seguridad a nivel de mensaje).
No necesitamos preocuparnos mucho por los formatos y estándares utilizados para encriptar o firmar los mensajes.
Sin embargo, cuando se trata de especificar las opciones de configuración, empezamos a preguntarnos qué significan.
Afortunadamente, encontramos la firmante y encriptador blogs en la comunidad, que explican la configuración.
Sin embargo, no entrarán en detalles sobre el estándar en sí.
Así que permítanme tratar de explicar el estándar con mis propias palabras simples.
Introduciremos el tema junto con las siguientes secciones:
Cómo me imagino que empezó:
Timmy de Texas quería compartir información secreta con su amigo Taku en Tokio.
Entonces encriptó un mensaje y se lo envió a Taku.
Taku no pudo descifrar ni leer el mensaje.
Así que Timmy viajó a Tokio para disfrutar de una comida y explicar la forma en que encripta y empaqueta sus mensajes.
Algún tiempo después, la misma situación sucedió con su amigo Toto en Togo.
Aunque se dice que la comida es excelente, Timmy decidió no viajar, sino invitar a sus amigos a una conferencia en casa.
Tuvieron comida internacional, discusiones nocturnas y al final acordaron una forma común de enviar mensajes seguros.
Como consecuencia, todos en el mundo pueden enviar mensajes seguros y los destinatarios pueden entender el mensaje, siempre que cumplan con ese acuerdo.
¿Tiene sentido?
Realmente tiene sentido, especialmente la sección sobre la comida internacional (que no se incluyó en la especificación).
¿Qué aprendemos de esta historia?
Las personas que se comunican entre sí deben ponerse de acuerdo sobre algunos principios básicos:
– Cómo se realiza el cifrado, qué pasos y en qué orden
– qué algoritmo se utiliza
– Información del certificado para garantizar la autenticación
– Información sobre el remitente
– Huella dactilar
– Y por último: ¿dónde se almacena esa información?
Si bien esa historia es pura fantasía, estas necesidades fueron capturadas en la realidad por una empresa llamada RSA Seguridad LLC en la década de 1990.
Esta empresa diseñó estándares de seguridad y los recopiló en una serie de estándares llamados PKCSLo que significa Estándares de criptografía de clave pública.
¿Qué es un estándar?
En mis simples palabras: expertos de todo el mundo se reúnen para “acordar” una forma de hacer algo.
El resultado es una guía y firmada como acuerdo por los expertos.
Ese acuerdo sobre una directriz se publica como «Estándar» y puede ser mantenido por una organización, por ejemplo IETF (Grupo de Trabajo de Ingeniería de Internet).
¿Qué es PKCS #7?
El séptimo PKCS estándar se dedicó a describir una forma de transmitir mensajes de forma segura a través de Internet.
Este séptimo se llama Sintaxis de mensajes criptográficos.
La última versión es 1.5 y se puede encontrar aquíel número RFC es 2315.
¿Qué es RFC?
Significa «Solicitud de comentarios» y normalmente es un documento que contiene una especificación.
Generalmente creado por voluntarios internacionales y mantenido por IETF, ha pasado por varios procesos de revisión. Después de un acuerdo, se asigna un número y se publica (y se mantiene) a través del editor rfc, al que apuntan los enlaces.
¿Qué dice el estándar PKCS #7?
La especificación no contiene comandos concretos ni propuestas para el uso de, por ejemplo, un algoritmo específico como AES.
El remitente de un mensaje puede cifrarlo con cualquier algoritmo, pero el estándar especifica dónde se mantiene la información sobre el algoritmo utilizado. Como tal, el destinatario puede buscar qué algoritmo necesita usar para el descifrado.
Así, hay múltiples datos y tipos de datos que deben enviarse junto con el mensaje.
¿Que información?
En primer lugar: ¿Queremos cifrar el mensaje? ¿O queremos firmar el mensaje? O los dos juntos?
Como ejemplo, si queremos enviar un mensaje y firmarlo, nos referiremos a la sección de la especificación llamada “Firmado-datos”.
Aprendemos que el estándar PKCS #7 define diferentes formas de proteger los mensajes y les da un nombre. Estos son los “tipos” o “tipos de contenido”.
Los siguientes tipos de contenido se definen en PKCS #7:
Información breve:
1. El primero es cualquier dato (texto o imagen o lo que sea)
Se especifica, porque los otros tipos se refieren a él.
2. Datos firmados significa que se crea una firma digital en el mensaje.
3. Datos envueltos
El mensaje se cifra con una clave simétrica que se genera sobre la marcha.
Esta clave está cifrada con un par de claves asimétricas.
El contenido y la clave y el certificado y la huella digital, etc.
hay muchas informaciones que necesitan ser enviadas al receptor.
Cada información está estructurada y se refiere a través de un tipo de contenido.
Todo ello guardado en un sobre, de ahí el nombre.
4. Datos firmados y envueltos
Significa que tanto la firma como el cifrado se realizan en un solo paso.
5. Los datos digeridos se refieren solo al hash y al contenido
6. Los datos cifrados se refieren a los datos cifrados
¿Como funciona?
Entonces, si observamos más de cerca, por ejemplo, SignedData, nos preguntaremos:
¿Cómo sabe el receptor que el mensaje recibido está estructurado de forma SignedData?
¿Cómo sabe qué algoritmo elegir para descifrar el resumen?
¿Cómo consigue el certificado necesario para descifrar
¿Cómo sabe que el certificado incluido es correcto y válido?
Una vez descifrado, ¿cómo obtiene el resumen y qué algoritmo usar?
Si quiere validar la hora, cuando se creó la firma, ¿cómo la encuentra?
La respuesta es:
Todo lo que se requiere está contenido en la estructura de datos, que me gusta llamar «paquete» (como un paquete clásico que se envía con FedEx).
Entonces, si enviamos un mensaje de acuerdo con PKCS #7, es como enviar un paquete que contiene múltiples artefactos e información.
Y el estándar PKCS#7 es como un papel que se adjunta al paquete, como una tabla de contenido, de modo que el receptor sabe dónde encontrar la información correspondiente para cada paso de desempaquetado.
¿Cómo encontrar toda la información?
Podemos ver que hay muchos elementos definidos en la especificación y cada elemento debe estar orientado de manera única.
Por lo que es necesario asignar un ID a cada elemento, o mejor: a cada tipo (esto es lenguaje PKCS7).
Esto se hace en forma de OIDs.
¿Qué es un OID?
Esta es la abreviatura de «Identificador de objeto».
¿Qué identificador de objeto?
Este es el intento de darle a todo en el mundo un identificador único, que permita describirlo y referirse exactamente a él.
Los OID están estructurados en una jerarquía de árbol y la notación simplificada es una cadena de números separados por puntos.
Ejemplo: 1.2.840.113549.1.7.1
Si encuentra un OID de este tipo, puede continuar y buscarlo en este repositorio Página web.
Luego, disfrute de la descripción de cada nodo del árbol y vea el rfc que definió el OID, respectivamente, los nodos secundarios.
Entonces, para elegir un ejemplo de arriba:
La hora de la firma es un elemento en una lista de “Atributos Firmados” y tiene el OID 1.2.840.113549.1.9.5que se puede encontrar en la especificación.
¿Cómo es una estructura?
A continuación, incluyo un extracto de la estructura de tipos definida por PKCS#7:
datos firmados
algoritmos de digestión
encapContentInfo
certificados
crls
signerInfos
algoritmo de digestión
Atributos firmados
algoritmo de firma
firma
unsignedAttrs
El elemento “encapContentInfo” contiene el contenido real del mensaje, que permanece encapsulado en el paquete PKCS7. Contiene 2 subelementos: el contenido en sí y el tipo de contenido.
El elemento “crls” representa una lista de CRL (Lista de revocación de certificados) y es opcional.
El siguiente diagrama intenta ilustrar cómo podría verse un mensaje basado en PKCS#7:
Podemos ver un sobre que representa el mensaje.
El mensaje contiene el contenido real, incluida una información sobre su tipo de contenido.
El mensaje también contiene el certificado, así como la información sobre el certificado (número de serie, propietario, etc.).
Además, podemos ver que el Información del firmante es de nuevo un tipo de datos estructurados que contiene artefactos como el firma digital así como metadatos sobre la firma (algoritmo), etc.
Etcétera.
¿Podemos ver un ejemplo de la vida real?
claro, mira abajo una hermosa estructura PKCS#7 de la vida real.
Llegando al término más importante.
¿Qué es CMS?
CMS significa Sintaxis de mensajes criptográficos que es el mismo nombre que el nombre del estándar PKCS #7.
De hecho, es la misma organización, solo diferente.
Como aprendimos anteriormente, PKCS #7 fue definido por una empresa, luego se entregó al IETF en 1999 y se le cambió el nombre a CMS.
Se realizaron algunas mejoras y se publicó la versión actual del estándar CMS como RFC5652 en 2009.
¿Cuál es la diferencia con el PKCS número 7?
Gran diferencia con PKCS#7 v 1.5:
El tipo Datos firmados y envueltos fue eliminado y el tipo Datos autenticados (MAC) fue añadido.
¿Cuál es el aspecto extraño de las especificaciones?
La especificación CMS utiliza ADN 1 Lo que significa Notación de sintaxis abstracta uno.
Es un estándar mantenido por la UIT (Unión Internacional de Telecomunicaciones) y describe un lenguaje para declarar estructuras de datos.
La última pregunta sería:
¿Cómo hacerlo en la práctica?
Los procesos de protección criptográfica de los mensajes y la recopilación y el tratamiento del contenido binario, etc. todo esto no puede ser hecho por humanos.
Los desarrolladores pueden usar bibliotecas de criptografía como Java IAIK, Castillo inflable o OpenSSL (c-libs).
Para los usuarios finales, existen herramientas como Herramientas de línea de comandos de OpenSSL.
Para los usuarios de código bajo, hay Integración en la nube de SAPque admite 3 tipos:
Datos firmados
Datos envueltos
Datos firmados y envueltos
Como sabemos, el último fue definido en PKCS #7 y omitido posteriormente en CMS.
SAP Cloud Integration permite al usuario cifrar, descifrar, firmar y verificar mensajes basados en CMS y PKCS #7.
El usuario solo necesita colocar una forma en el editor gráfico y todo funcionará de inmediato.
Sin embargo, para comprender lo que está sucediendo o para comprender las muchas opciones de configuración posibles, algunas publicaciones de blog son útiles.
Espero.
La estructura de Blow CMS fue creada por OpenSSL, que tiene un parámetro para imprimir la estructura de CMS en la consola o en un archivo.
El ejemplo fue tomado de un mensaje con firma digital y se incluye el contenido más certificado.
Para una mejor legibilidad, he acortado algunas partes.
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha512 (2.16.840.1.101.3.4.2.3)
parameter: NULL
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
001e - 2d 2d 2d 2d 2d 2d 2d 0d-0a 2d 20 53 65 63 72 -------..- Secr
002d - 65 74 20 70 6c 61 69 6e-20 74 65 78 74 20 6d et plain text m
003c - 65 73 73 61 67 65 20 63-6f 6e 74 65 6e 74 20 essage content
0069 - 2d 2d 2d 2d 2d 2d 2d 2d-2d 2d ----------
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 17034094456647405626
signature:
algorithm: sha256WithRSAEncryption (1.2.840.113549.1.1.11)
parameter: NULL
issuer: CN=crdemocert
validity:
notBefore: Jan 26 13:33:04 2023 GMT
notAfter: Feb 25 13:33:04 2023 GMT
subject: CN=crdemocert
key:
algor:
algorithm: rsaEncryption (1.2.840.113549.1.1.1)
parameter: NULL
public_key: (0 unused bits)
0000 - 30 82 01 0a 02 82 01 01-00 fa 59 fb 54 da 0.........Y.T.
00ee - d7 31 4a 4d f4 a9 3a 8b-44 78 af d8 c8 46 .1JM..:.Dx...F
00fc - 3c 41 50 e1 59 a1 6f 06-58 a2 a3 2f 7b 02 <AP.Y.o.X../{.
010a - 03 01 00 01 ....
extensions:
object: X509v3 Subject Key Identifier (2.5.29.14)
critical: BOOL ABSENT
value:
0000 - 04 14 3b c3 14 39 a3 0a-50 26 e5 ba c1 ..;..9..P&...
000d - af 7c af 95 a6 64 c2 d5-60 .|...d..`
object: X509v3 Authority Key Identifier (2.5.29.35)
critical: BOOL ABSENT
value:
0000 - 30 16 80 14 3b c3 14 39-a3 0a 50 26 e5 0...;..9..P&.
000d - ba c1 af 7c af 95 a6 64-c2 d5 60 ...|...d..`
object: X509v3 Basic Constraints (2.5.29.19)
critical: TRUE
value:
0000 - 30 03 01 01 ff 0....
sig_alg:
algorithm: sha256WithRSAEncryption (1.2.840.113549.1.1.11)
signature: (0 unused bits)
0000 - 6e ca 78 b0 db 25 f5 a6-be bc 8d 13 2e 82 43 n.x..%........C
00e1 - 3f b5 78 fa 6d 7c 0b 76-1d 0f 86 a2 15 47 a8 ?.x.m|.v.....G.
00f0 - fa f2 44 2d e8 af ae f4-53 b1 e0 06 40 ac 2d ..D-....S...@.-
00ff - 4e N
crls:
<EMPTY>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: CN=crdemocert
serialNumber: 17034094456647405626
digestAlgorithm:
algorithm: sha512 (2.16.840.1.101.3.4.2.3)
parameter: NULL
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
value.set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
value.set:
UTCTIME:Feb 3 14:31:00 2023 GMT
object: messageDigest (1.2.840.113549.1.9.4)
value.set:
OCTET STRING:
000d - 10 11 58 97 76 77 42 a5-58 0d e6 ec ab ..X.vwB.X....
0034 - cc 32 a4 db 18 a4 4d fa-fd 95 bb 2f .2....M..../
object: undefined (1.2.840.113549.1.9.16.2.47)
value.set:
SEQUENCE:
0:d=0 hl=2 l= 78 cons: SEQUENCE
2:d=1 hl=2 l= 76 cons: SEQUENCE
4:d=2 hl=2 l= 74 cons: SEQUENCE
6:d=3 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:CBD22BAD927ECF56713EAE3393
40:d=3 hl=2 l= 38 cons: SEQUENCE
42:d=4 hl=2 l= 25 cons: SEQUENCE
44:d=5 hl=2 l= 23 cons: cont [ 4 ]
46:d=6 hl=2 l= 21 cons: SEQUENCE
48:d=7 hl=2 l= 19 cons: SET
50:d=8 hl=2 l= 17 cons: SEQUENCE
52:d=9 hl=2 l= 3 prim: OBJECT :commonName
57:d=9 hl=2 l= 10 prim: UTF8STRING :crdemocert
69:d=4 hl=2 l= 9 prim: INTEGER :EC6542A866EB503A
signatureAlgorithm:
algorithm: sha512WithRSAEncryption (1.2.840.113549.1.1.13)
parameter: NULL
signature:
0000 - e2 42 05 a8 22 d9 5e de-90 8e 09 44 73 9c 7f .B..".^....Ds..
000f - 82 7e 62 d7 79 92 ec f1-1c 8d fd 44 d8 c5 16 .~b.y......D...
002d - 26 7a f3 91 fb 70 86 33-94 9a de c6 4b 84 b7 &z...p.3....K..
00f0 - 67 ca ff b1 8c d2 ac 65-38 7d df 28 05 7e 62 g......e8}.(.~b
00ff - 2e .
unsignedAttrs:
<EMPTY>
Básicamente, el estándar PKCS #7/CMS tiene 2 propósitos:
Portal de ayuda de SAP
documento para Encriptador PKCS#7/CMS
documento para Firmante PCKS#7/CMS
documento para Seguridad a nivel de mensaje
CMS
La especificación CMS se puede encontrar aquí o aquí e incluso aquí
Wikipedia: CMSsintaxis de mensajes criptográficos
La especificación para PKCS #7 se puede encontrar aquí.
S/MIME se construye sobre CMS
Extensión CMS para Datos comprimidos tipo
OID:
Wikipedia:OID, Identificador de objeto
Herramienta web para buscar OID
OpenSSL
Lista oficial de binarios no oficiales página de descarga
documento hogar
documento para cms dominio
Entendiendo el PKCS #7 / CMS Firmante
Entendiendo el PKCS #7 / CMS encriptador
Glosario de seguridad Blog
Calle Eloy Gonzalo, 27
Madrid, Madrid.
Código Postal 28010
Paseo de la Reforma 26
Colonia Juárez, Cuauhtémoc
Ciudad de México 06600
Real Cariari
Autopista General Cañas,
San José, SJ 40104
Av. Jorge Basadre 349
San Isidro
Lima, LIM 15073