Y ahora, cuando casi agregué la generación de
certificados autofirmados a la estación de trabajo criptográfica basada en tokens cryptoarmpkcs PKCS # 11 y estaba listo para comenzar a escribir el artículo, recibí una carta como esta:
Somos UZNIREK CA, tuvimos dificultades para emitir ES en el formato pkcs # 11 para EGAIS, el portal no entiende el ES en el formato Znamerek CSP, le pedimos ayuda en este problema.
No conocía todas las complejidades de trabajar con EGAIS, pero dado que era PKCS # 11, sugerí usar la utilidad cryptoarmpkcs para
generar una solicitud e instalar un certificado para un token después de recibirlo de la CA. La respuesta que recibí fue algo distractora:
Lamentablemente, el hecho es que grabamos ES en RuToken 2.0 a través de CryptoPro CSP, pero con todas las configuraciones adecuadas, el portal EGAIS no vio el ES en el medio clave, el cliente nos contactó en soporte y descubrimos que el problema no era el certificado clave está escrito en ese formato, aquí está el manual dev.rutoken.ru/display/KB/RU1051
.
Yo (y no solo yo) ya he escrito muchas veces que muchos usan tokens criptográficos con el apoyo de la criptografía rusa como
unidades flash normales . Y este fue solo el caso cuando la clave y el certificado no llegaron al token como objetos PKCS # 11. Es una pena que no hayan tomado el consejo y ni siquiera hayan intentado crear una solicitud. Pero luego decidí dejar todo a un lado y descubrir cómo y qué certificados se emiten para EGAIS Rosalkogolregulirovanie. Y solo consideraremos los tokens criptográficos PKCS # 11. La mayor decepción es el acceso a EGAIS solo a través de Windows y el navegador IE. Por otro lado, la generación de una solicitud de certificado y la instalación del certificado también se puede llevar a cabo en cualquier sistema operativo, si tiene controladores / bibliotecas para el token correspondiente.
Al menos los tokens PKCS # 11 JaCarta, RutokenECP-2.0, el token de software LS11SW2016 e incluso el
token en la
nube tienen soporte en MS Windows, Linux y OS X. Y no solo en estos sistemas operativos.
De hecho, debemos rendir homenaje a los desarrolladores de EGAIS. Propusieron una tecnología interesante que permite el acceso para usar certificados personales (certificado más par de claves) almacenados en tokens criptográficos con soporte para criptografía rusa, y proteger el canal en certificados RSA. Aunque si dijeron A, entonces uno podría decir B, es decir proteger el canal en algoritmos GOST-ov. Lo único triste es que todo esto está diseñado solo para MS Windows (¿o me equivoco?), O más bien, para Internet Explorer. Y las utilidades para generar solicitudes de certificados para EGAIS están vinculadas a un token en particular.
Pero la utilidad cryptoarmpkcs es multiplataforma. Además, puede funcionar con cualquier token criptográfico PKCS # 11 que admita la criptografía rusa.
Entonces, ¿cuál es la peculiaridad de la solicitud de certificado para EGAIS? La característica principal es la presencia obligatoria en el nombre distinguido del titular del certificado (asunto del DN) de un campo adicional no construido Nombre (UN) (oid - 1.2.840.113549.1.9.2). Si el propietario del certificado es un empresario individual, entonces la línea "KPP =" se escribe en este campo, y si el propietario es una entidad legal, se escribe una línea del siguiente tipo en este campo:
PPC = reason_code_of_tax_account_account:
En este sentido, el requisito en la primera página de la pestaña de solicitud de certificado se agregó al botón EGAIS:
Otra característica es que los titulares de certificados para el EGAIS pueden ser licenciatarios del sistema de declaración FSRAP (oid - 1.2.643.3.6.78.4.4). Esto también debe tenerse en cuenta al crear una solicitud:
Después de completar todos los campos de la solicitud de certificado y de haber confirmado la exactitud de los datos, se generará un par de claves y se creará la solicitud:
Si observa la solicitud, puede ver los oid-s (Uso de clave extendida), que son necesarios para EGAIS Rosalkogolregulirovanie:
Aquí debe prestar atención (en la captura de pantalla anterior) a la etiqueta del par de claves. En la terminología PKCS # 11, este es el atributo CKA_LABEL para la clave pública y privada. Es mediante dicho esquema que el generador de consultas EGAIS para JaCarta crea una etiqueta (nombre clave) de CenterInform FSUE:
Tradicionalmente
certificado triple
x clave_pública x clave privada
en el token está conectado a través del
atributo CKA_ID
:
La forma más común de especificar CKA_ID es usar el valor de la función hash del valor de la clave pública. Este es el método utilizado para vincular el triple de objetos en el proyecto NSS (Network Security Services). Al mismo tiempo, el algoritmo SHA1 se usa como una función hash.
Desafortunadamente, tanto CKA_LABEL como CKA_ID se pueden configurar / cambiar en cualquier momento con cualquier valor. Por lo tanto, siempre existe la posibilidad de que el certificado se asocie con la clave privada de otra persona. No es necesario explicar cuáles serán las consecuencias de esto.
En general, ¿existe un algoritmo matemático estricto que le permita conectar el triple CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY en un solo conjunto?
Sí,
existe un algoritmo de este tipo basado en mecanismos criptográficos (CKM_) del token.
Desafortunadamente (aunque se puede entender objetivamente), considera un grupo en un triple a través de CKA_LABEL, formado por el método mencionado anteriormente. Además, para las claves privadas y públicas, SKA_ID se forma de manera similar. Para las llaves, esto es solo un desastre, porque sin embargo, ni CKA_ID ni CKA_LABEL están vinculados de ninguna manera a la clave misma. Esto también se aplica al certificado después de que se instala en el token. Si en la formación tradicional de CKA_ID como un hash de la clave pública, siempre puede verificar si uno coincide con el otro, entonces al configurar CKA_ID y CKA_LABEL de la manera descrita anteriormente, esto no se puede hacer.
Puede surgir una pregunta, pero ¿cómo verificar el cumplimiento de una clave privada? La respuesta es simple: calculando el valor de la clave pública contra la privada. En cuanto al certificado, el valor de su clave pública está, naturalmente, en él. Además, el certificado en sí contiene el valor CKA_ID tanto para el titular del certificado (Identificador de clave del sujeto del certificado) como para el editor del certificado (Identificador de clave de la autoridad de certificación):
Lo más desagradable fue que al instalar el certificado, no se comprueba la presencia de la clave privada, sino que solo la clave pública es suficiente. En este caso, se instalará el certificado, pero no tendrá una clave privada. Otro problema Esta es una búsqueda de clave pública por TIN. Imagine que una persona tiene un TIN y varias claves para varios certificados. ¿A cuál pertenece? Después de eso, queda claro el requisito para que JaCarta tenga
solo un certificado y un par de claves:
Este error puede estar relacionado con la duplicación de certificados. En JaCarta Single Client en modo administrador, en la pestaña GOST Después de ingresar el código PIN, una clave pública, una clave privada y un certificado deben estar visibles. En este caso, la duplicación de claves es visible. Necesitas eliminar los extras. Vuelva a insertar el medio en el conector usb e intente instalar el UTM nuevamente. Si el error persiste, inicialice Jacarta según el enlace 1 y vuelva a realizar el proceso de generación.
Esperemos que esta deficiencia sea eliminada. Puede preguntar cómo la utilidad cryptoarmpkcs para EGAIS instala el certificado. Para una compatibilidad total con JaCarta, hemos mantenido la ideología de que CKA_ID y CKA_LABEL para las claves son las mismas. Pero solo después de instalar el certificado en el token y vincularlo en el par de claves. Hasta entonces, el par de claves CKA_ID se mantiene igual al valor hash de la clave pública.
Después de instalar el certificado, puede usarlo para
firmar documentos .
Puede leer acerca de los certificados autofirmados
aquí :
Las distribuciones están en el mismo lugar.