Los estándares criptográficos tienen dos objetivos importantes: lograr la interoperabilidad entre diferentes implementaciones y evitar diversos errores conocidos en los esquemas típicos. En este blog, analizamos el Estándar de Criptografía de Clave Pública (PKCS), que ha tenido un impacto significativo en el uso de la clave pública. cifrado En la práctica. El estándar PKCS es un conjunto de estándares denominados PKCS 1 a 15.

Estas normas cubren RSA Cifrado, firma RSA, cifrado basado en contraseña, sintaxis de mensajes cifrados, sintaxis de información de clave privada, categoría de objeto y tipo de atributo seleccionados, sintaxis de solicitud de autenticación, interfaz de token de cifrado, sintaxis de intercambio de información personal y gramática de información de token cifrado. RSA Laboratories publica el estándar PKCS.

Aunque RSA Laboratories solicita comentarios y sugerencias del público sobre el estándar PKCS, se reserva la facultad exclusiva de decidir sobre todos los aspectos del mismo. PKCS se ha convertido en la base de muchos otros estándares, como S/MIME.

Criptografía de clave pública se basa en un criptográfico asimétrico Algoritmo que utiliza dos claves relacionadas: una pública y una privada. La naturaleza de estas dos claves es que, dada la clave pública, se deriva la clave privada. Es computacionalmente inviable. Los usuarios publican sus claves públicas en directorios públicos, como los directorios LDAP, y conservan sus claves privadas.

Dependiendo del propósito del algoritmo, existen cifrados de clave pública y desencriptación Algoritmos y algoritmos de firma. Los algoritmos de cifrado permiten cifrar datos mediante una clave pública (por ejemplo, una clave simétrica), de modo que solo el destinatario con la clave privada correspondiente pueda descifrarlos.

Los algoritmos típicos de cifrado de clave pública son RSA y ECIES (Esquema de Cifrado Integrado de Curva Elíptica, véase SECG 2000). El algoritmo de firma se combina con el algoritmo de resumen de mensajes, que puede convertir mensajes de cualquier longitud utilizando la clave privada en una firma. De esta manera, sin conocer la clave privada, no se puede obtener computacionalmente la misma firma.

Se puede encontrar el mensaje con la firma predeterminada o ver la firma de un mensaje específico. Cualquier persona con la clave pública correspondiente puede verificar la validez de la firma. Los algoritmos típicos de firma digital de clave pública son RSA, DSA y ECDSA.

Especificaciones PKCS

No.	Título PKCS	Comentarios
1	Estándar de criptografía RSA
2		incorporado en PKCS #1
3	Norma de acuerdo de clave Diffie-Hellman	reemplazado por IEEE 1363a, etc.
4	Estándar de criptografía basado en contraseñas
5	Estándar de sintaxis de certificado extendido	nunca adoptado
6	Estándar de sintaxis de mensajes criptográficos	reemplazado por RFC 3369 (CMS)
7	Estándar de sintaxis de información de clave privada
8	Clases de objetos y tipos de atributos seleccionados
9	Estándar de sintaxis de solicitud de certificación
10	Estándar de interfaz de token criptográfico	conocido como CRYPTOKI
11	Estándar de sintaxis de intercambio de información personal
12	(reservado para ECC)	nunca se ha publicado
13	(reservado para la generación de números pseudoaleatorios)	nunca se ha publicado
14	Estándar de sintaxis de información de tokens criptográficos

Estándares PKCS

PKCS #1: Estándar de criptografía RSA

PKCS #1 v2.1 proporciona estándares para la implementación de esquemas de cifrado criptográfico de clave pública basados en el algoritmo RSA y esquemas de firma digital, con apéndice. También define la sintaxis ASN.1 correspondiente para la representación de claves y la identificación de las técnicas.

Se cree que la seguridad del algoritmo RSA se basa en la dificultad de factorizar el producto de números primos grandes. En PKCS #1 v2.1, se introduce un esquema RSA multiprimo. RSA multiprimo significa que el módulo no es el producto de dos primos, sino de más de dos primos. Esto se utiliza para mejorar el rendimiento de las primitivas criptográficas RSA.

PKCS #3 (obsoleto): Estándar de acuerdo de clave Diffie-Hellman

PKCS #3 v1.4 describe un método para implementar el acuerdo de claves Diffie-Hellman, mediante el cual dos partes pueden acordar una clave secreta que solo ellas conocen. PKCS #3 ha sido reemplazado por el tratamiento moderno de los esquemas de establecimiento de claves especificados en IEEE 1363a (2003), ANSI 9.42, ANSI X9.44, ANSI X9.63, etc.

PKCS #5: Estándar de criptografía basado en contraseñas

En muchas aplicaciones de criptografía de clave pública, la seguridad del usuario depende en última instancia de uno o más valores de texto secretos o contraseñas. Por ejemplo, la clave privada de un usuario suele cifrarse con una contraseña, que se guarda en dispositivos de almacenamiento. Sin embargo, existen dos problemas fundamentales con la aplicación de contraseñas:

Una contraseña no es directamente aplicable como clave a ningún criptosistema convencional.
Las contraseñas a menudo se eligen de un espacio relativamente pequeño.

Por lo tanto, se requiere especial cuidado para defenderse de los ataques de búsqueda. PKCS #5 proporciona un mecanismo general para lograr una mayor seguridad para las primitivas criptográficas basadas en contraseñas, que abarca las funciones de derivación de claves, los esquemas de cifrado, los esquemas de autenticación de mensajes y la sintaxis ASN.1 que identifica las técnicas.

PKCS #6 (Histórico): Estándar de sintaxis de certificado extendido

Cuando se redactó PKCS #6, X.509 estaba en la versión 1.0 y no se definía ningún componente de extensiones en el certificado. Un certificado X.509 v3 puede contener información sobre una entidad determinada en el componente de extensiones. Desde la introducción de X.509 v3, el estado de PKCS #6 es histórico.

PKCS #7 y RFC 3369: Sintaxis de mensajes criptográficos o CMS

PKCS #7 ha sido reemplazado por IETF RFC 3369 (Housley 2002): sintaxis de mensajes criptográficos (CMS), que constituye la base de la especificación S/MIME. CMS define la sintaxis utilizada para firmar digitalmente, digerir, autenticar o cifrar contenido arbitrario de mensajes. En particular, CMS describe una sintaxis de encapsulación para la protección de datos. Esta sintaxis permite múltiples encapsulaciones; una envoltura de encapsulación puede anidarse dentro de otra.

Asimismo, una parte puede firmar digitalmente datos previamente encapsulados. En la sintaxis de CMS, se pueden firmar atributos arbitrarios, como la hora de firma, junto con el contenido del mensaje, y otros detalles, como las contrafirmas, se pueden asociar a una firma. CMS admite diversas arquitecturas para la gestión de claves basada en certificados (p. ej., la definida por el grupo de trabajo PKIX del IETF).

PKCS #8: Estándar de sintaxis de información de clave privada

La seguridad del criptosistema de clave pública depende completamente de la protección de las claves privadas. Generalmente, estas se cifran con una contraseña y se almacenan en un medio de almacenamiento. Es fundamental contar con un estándar para almacenar las claves privadas y transferirlas de un sistema a otro sin problemas.

PKCS #8 v1.2 describe una sintaxis para la información de clave privada, que incluye una clave privada para algunos algoritmos de clave pública, un conjunto de atributos y una sintaxis para la información de clave privada cifrada. Se podría utilizar un algoritmo de cifrado basado en contraseña (por ejemplo, uno de los descritos en PKCS #5) para cifrar la información de clave privada.

PKCS #9: Clases de objetos y tipos de atributos seleccionados

Para admitir atributos definidos por PKCS (p. ej., para almacenar atributos PKCS en un servicio de directorio) en sistemas de directorio basados en LDAP y los protocolos de la familia X.500, PKCS #9 v2.0 define dos clases de objeto auxiliares: pkcsEntity y naturalPerson. Los atributos PKCS pueden empaquetarse en estas dos clases de objeto y exportarse a otros entornos, como los sistemas de directorio LDAP.

PKCS #9 v2.0 también define nuevos tipos de atributos y reglas de coincidencia que podrían usarse en diferentes estándares PKCS. Por ejemplo, define los tipos de atributos challengePassword y extensionRequest para el campo de atributo PKCS #10, y describe algunos tipos de atributos para los campos signedAttrs, unsignedAttrs, unprotectedAttrs, authAttrs y unauthAttrs de PKCS #7 (CMS).

PKCS #10: Estándar de sintaxis de solicitud de certificación

PKCS #10 v1.7 especifica la sintaxis para la solicitud de certificado. Cuando una entidad desea obtener un certificado de clave pública, crea una solicitud de certificado. La envía a un autoridad de certificación, que transforma la solicitud en un certificado de clave pública X.509.

Una autoridad de certificación cumple la solicitud autenticando a la entidad solicitante y verificando la firma de la entidad y, si la solicitud es válida, construyendo un certificado X.509 a partir del nombre distinguido y la clave pública, el nombre del emisor y la elección de la autoridad de certificación de un número de serie, un período de validez y un algoritmo de firma.

Supongamos que la solicitud de certificación contiene atributos PKCS #9. En ese caso, la autoridad de certificación también puede usar los valores de estos atributos y otra información que conozca para construir extensiones de certificado X.509. PKCS #10 no especifica las formas en que la autoridad de certificación devuelve el nuevo certificado.

PKCS #11: Estándar de interfaz de token criptográfico

PKCS #11 v2.20 especifica una interfaz de programación de aplicaciones (API), denominada "Cryptoki", para dispositivos que almacenan información criptográfica y realizan funciones criptográficas. Cryptoki, que se pronuncia "crypto-key" y es la abreviatura de "interfaz de token criptográfico", sigue un enfoque simple basado en objetos, que aborda los objetivos de independencia tecnológica (cualquier dispositivo) y compartición de recursos (múltiples aplicaciones que acceden a múltiples dispositivos), presentando a las aplicaciones una vista lógica y estándar del dispositivo denominada "token criptográfico".

Cryptoki se concibió desde un principio como una interfaz entre aplicaciones y todo tipo de dispositivos criptográficos portátiles, como los basados en tarjetas inteligentes, tarjetas PCMCIA y disquetes inteligentes. El objetivo principal de Cryptoki era una interfaz de programación de bajo nivel que abstrajera los detalles de los dispositivos y presentara a la aplicación un modelo estándar del dispositivo criptográfico, denominado «token criptográfico».

PKCS #12: Estándar de sintaxis de intercambio de información personal

PKCS #12 v1.0 describe una sintaxis de transferencia para información de identidad personal, incluyendo claves privadas, certificados, secretos varios y extensiones. Las máquinas, aplicaciones, navegadores, quioscos de internet, etc., que admiten este estándar permitirán a los usuarios importar, exportar y gestionar un único conjunto de información de identidad personal. PKCS #12 puede considerarse una versión mejorada de PKCS #8 al incluir información de identidad esencial pero complementaria y claves privadas, e implementar una mayor seguridad mediante modos de privacidad e integridad de clave pública.

PKCS #15: Estándar de sintaxis de información de tokens criptográficos

Los tokens criptográficos, como las tarjetas de circuito integrado (o tarjetas IC), son plataformas informáticas intrínsecamente seguras, ideales para proporcionar mayor seguridad y privacidad a las aplicaciones. Pueden gestionar información de autenticación como... Certificados digitales y capacidades, autorizaciones y claves criptográficas.

Además, pueden proporcionar almacenamiento seguro e instalaciones computacionales para información confidencial, como claves privadas y fragmentos de clave. Al mismo tiempo, muchos de estos tokens proporcionan una instalación de procesamiento aislada capaz de utilizar esta información sin exponerla dentro del entorno host, donde podría estar expuesta a código malicioso (virus, troyanos, etc.). Desafortunadamente, el uso de estos tokens para fines de autenticación y autorización se ha visto obstaculizado por la falta de interoperabilidad.

En primer lugar, la industria carece de estándares para almacenar un formato común de credenciales digitales (claves, certificados, etc.). Esto ha dificultado la creación de aplicaciones compatibles con credenciales de diversos proveedores de tecnología. En segundo lugar, los mecanismos que permiten que múltiples aplicaciones compartan credenciales digitales de forma eficaz aún no han alcanzado su madurez.