Uno de los objetos centrales de la Infraestructura de clave pública (PKI / PKI) junto con el par de claves es un certificado, que hoy es en realidad un análogo de un pasaporte civil.
Con un certificado en sus manos, un ciudadano puede obtener acceso al portal de Servicios del Estado, pagar impuestos, proteger su
correo electrónico , firmar y cifrar documentos y mucho más.
Un certificado, como un
pasaporte , se emite sobre la base de una solicitud y la provisión de una serie de documentos. La lista de documentos para obtener un certificado se encuentra en cualquier centro de certificación
acreditado por el Ministerio de Comunicaciones (el nuevo nombre es Ministerio de Desarrollo Digital, Telecomunicaciones y Comunicaciones en Masa). La solicitud de pasaporte tiene la firma manuscrita del solicitante. Al recibir el pasaporte, el solicitante pondrá su firma en el pasaporte, que será certificado por el empleado de la oficina de pasaportes y el sello oficial. La foto y la capacidad del propietario para reproducir su firma y permitirle ser identificado como el propietario de un pasaporte específico.
Se utiliza un esquema similar para obtener un certificado de una clave de verificación de firma electrónica (SKEPEP). Primero, un ciudadano que quiere recibir un certificado debe adquirir la "habilidad" para colocar su propia firma. Esta "habilidad" se realiza mediante la recepción por parte del solicitante de un par de claves que contiene la clave pública o la clave de verificación de firma electrónica (KEPP) y la clave privada o clave de firma electrónica, que, de hecho, le permite generar una firma electrónica y firmar un documento electrónico. La identificación de una firma electrónica bajo un documento se lleva a cabo de acuerdo con el siguiente algoritmo. A partir del certificado se determina qué clave (GOST R 34.10-2001, GOST R 34.10-2012 con una longitud de clave de 64 o 128 bytes) se firmó el documento. El tipo de clave determina el algoritmo de hash que se utilizó al firmar el documento. Puede ser GOST R 34.11-94 o GOST R 34.11-2012 con una longitud de hash de 256 o 512 bits. Según el algoritmo seleccionado, se considera el hash del documento fuente. Y por el valor del hash calculado del documento fuente, la clave pública (KEPP) y sus parámetros (todo esto se toma del certificado SKEPEP), se verifica la autenticidad de la firma electrónica bajo el documento.
Para crear un par de claves, se utilizan diversos medios de protección de la información criptográfica (CPSI) que admiten los algoritmos criptográficos GOST R 34.10-2001 y GOST R 34.10-2012. ¡Debe recordarse que el uso del esquema de firma GOST R 34.10-2001 para generar una firma después del 31 de diciembre de 2018 no está permitido! Las herramientas de protección de información criptográfica que implementan varios algoritmos y protocolos criptográficos pueden ser tanto software como hardware. El acceso a la protección de la información criptográfica se realiza a través de interfaces criptográficas. La gran mayoría de los sistemas certificados de protección de información criptográfica con criptografía rusa admite la interfaz criptográfica universal
PKCS # 11 , que es compatible con todas las plataformas, o la interfaz Microsoft CSP y CryptoAPI en plataformas MS Windows (en lo sucesivo, MS CSP). Estas dos interfaces criptográficas son compatibles, por ejemplo, con el portal de
servicios estatales . Estos dos tipos de protección de información criptográfica se considerarán más a fondo:
Debe tenerse en cuenta que si existe el deseo o la necesidad de trabajar con una firma electrónica no solo en la plataforma de Windows, sino también en otras plataformas (Linux, macOS, etc.), se deben elegir los tokens PKCS # 11 con soporte para la criptografía rusa.
Además de la función principal relacionada con la generación de una solicitud, la utilidad proporciona funciones para trabajar con tokens y certificados:
Campo combinado (cuadro combinado) "Seleccionar un token:" en la ventana principal contiene una lista de herramientas de protección de información criptográfica disponibles para generar un par de claves. Si la utilidad de generación de solicitudes se ejecuta en la plataforma Windows y se instalan proveedores criptográficos CSP con soporte para criptografía rusa, entonces el token virtual MS_CSP se definirá en la lista de herramientas de protección de información criptográfica disponibles ("Seleccione un token:"). Por lo tanto, si desea utilizar el proveedor criptográfico MS CSP, debe instalarse en el sistema antes de iniciar la utilidad.
Para agregar soporte para el nuevo token PKCS # 11, simplemente seleccione el elemento de menú "Administración de tokens-> Agregar token". Agregar soporte para el nuevo token consiste en elegir la biblioteca PKCS # 11 para el tipo de complemento de tokens / tarjetas inteligentes y establecer un nombre conveniente (apodo). Al agregar soporte para un nuevo tipo de tokens (así como al iniciar la utilidad, si el soporte de tokens se agregó previamente) con un token conectado (insertado), se requerirá un código PIN para acceder a él:
Pero esto sucederá solo si el token no solo está conectado, sino también en condiciones de funcionamiento, es decir, inicializado Verifique el token y, si es necesario, inicialícelo, cambie el código PIN para acceder, etc. convenientemente con la utilidad
p11conf :
Al seleccionar el elemento "Token Management-> Token Mechanisms", puede ver los mecanismos criptográficos de un token en particular, por ejemplo, ¿hay soporte para el algoritmo GOST R 34.10-2012? Para el token virtual MS_CSP, se enumeran todos los proveedores de CSP con soporte para algoritmos GOST y los mecanismos soportados por ellos:
Si el token seleccionado no admite el tipo de par de claves seleccionado, se mostrará un mensaje correspondiente:
Antes de proceder directamente a completar los campos de solicitud, es necesario decidir para qué propósito se necesita un certificado, es decir especifique el "Rol del certificado". Hoy, tales roles han acumulado más de una docena:
Y cada rol está asociado con muchos OID diferentes incluidos en el certificado. Entonces, por ejemplo, para acceder al portal de servicios públicos se necesitan los siguientes oids:
{} {clientAuth, emailProtection, 1.3.6.1.4.1.311.20.2.2, 1.2.643.100.2.1, 1.2.643.2.2.34.6, 1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4, 1.2.643.5.1.24.2.1.3, 1.2.643.6.14, 1.2.643.3.215.4, 1.2.643.3.215.5, 1.2.643.3.215.6, 1.2.643.3.215.7, 1.2.643.3.215.8, 1.2.643.3.215.9, 1.2.643.3.215.11, 1.2.643.3.215.12, 1.2.643.3.215.13, 1.3.6.1.4.1.40870.1.1.1, 1.2.643.2.64.1.1.1, 1.2.643.3.5.10.2.12, 1.2.643.6.3.2, 1.2.643.5.1.24.2.46, 1.2.643.6.45.1.1.1, 1.2.643.5.1.24.2.30, 1.2.643.5.1.28.2, 1.2.643.5.1.28.3, 1.2.643.3.202.1.8}
Los OID para otros roles (por ejemplo, "Sitio de Gazprombank", "Consumidor de alcohol", etc.) se pueden encontrar en el código fuente de la utilidad (variable oid_roles_bad, operador:
set oid_roses_bad {. . .}
)
La presencia de tantos oids es difícil de entender. Estamos hablando de certificados calificados, en los que hay oid TIN, PSRN, SNILS, etc., que identifican de manera única tanto a una persona individual como a una entidad legal y, al parecer, esto sería suficiente para acceder al portal de servicios estatales y otros también Pero, Dura lex, sed lex: la ley es dura, pero es una ley.
En el campo "Nombre de CIPF", es necesario indicar el nombre de CIPF (token / tarjeta inteligente, CSP), que está escrito en el certificado de conformidad (que no debe confundirse con el certificado X509) del Servicio Federal de Seguridad de Rusia u otro documento similar, una copia de la cual debe proporcionarse en el momento de la compra del CIPF. Posteriormente, el valor de este campo se incluirá en el certificado.
Entonces, habiendo decidido el sistema de protección de información criptográfica y el par de claves, puede proceder a completar la solicitud / solicitud electrónica para el certificado de la clave de verificación de firma electrónica (SKEPEP):
El primer campo que se debe completar es el "Nombre común", en el que se ingresa el nombre completo del futuro titular del certificado. Para un individuo, este es el nombre completo como en el pasaporte. Para una entidad jurídica, este es el nombre de la empresa del registro. Esta información para una entidad jurídica se duplicará automáticamente en el campo "Nombre de la organización" ("O"):
Al completar el formulario, se verifica la corrección del llenado de los campos TIN, BIN, SNILS (cuando ingresa un número, el campo se vuelve rojo, los campos correctamente llenos se vuelven verdosos), direcciones de correo electrónico:
Después de completar todos los campos de solicitud y hacer clic en el botón "Finalizar", se recibirá una solicitud de certificado al final:
En el proceso de creación de una solicitud, se generará un par de claves en el token seleccionado. Al mismo tiempo, si se selecciona el token virtual "MS_CSP" como token, que, a su vez, admite varios medios para almacenar el par de claves, se propondrá elegir un medio específico:
Recuerde que un par de claves contiene dos claves: privada y pública. La clave pública, también llamada clave de verificación de firma electrónica, se envía a la solicitud de certificado. Para ver la solicitud generada, que contiene la clave pública, utilice el menú "Certificados-> Ver solicitud":
La clave privada permanece con el solicitante en su token, cuyo código PIN (contraseña) debe almacenarse como la niña de su ojo. Y dado que existe una
correspondencia inequívoca entre las claves públicas y privadas, siempre puede verificar quién es el propietario de la solicitud del certificado, y luego el certificado en sí, la firma en el documento, etc.
Ahora con todos los documentos necesarios, con la solicitud generada en una unidad flash, puede ir al centro de certificación más cercano y recibir un certificado. Entonces, la solicitud llega a emitir un certificado en una de las AC, creado teniendo en cuenta la Ley Federal del 6 de abril de 2011. No. 63- "En firma electrónica":
La solicitud a la CA pasará por las etapas de importación, revisión, aprobación y emisión de un certificado para esta solicitud:
El certificado emitido se publicará en uno de los servicios de CA, desde donde se puede descargar. Y ahora es suficiente para que el certificado emitido se exporte a la unidad flash del solicitante:
Y ahora, cuando se recibe el certificado, queda por colocarlo en el CIPF (PKCS # 11, MS CSP) (Certificados-> Importar x509):
Para verificar que el certificado se encuentra en el token, puede ver el contenido del token / tarjeta inteligente (Certificados-> Ver x509 en el token):
Bueno, para que fuera "armadura" (¡Dame un PAPEL! Documento final, Armadura. (Dog Heart c / f)), conecta el token al navegador
Firefox con soporte para la criptografía rusa y encuentra el certificado emitido en certificados personales (incluidos dichos certificados, para el cual el token tiene una clave privada):
La utilidad CreateCSRCAFL63 desarrollada en
Tcl / Tk . Para acceder a las funciones criptográficas de los tokens MS CSP y PKCS # 11, se ha desarrollado el paquete cwapi que implementa los requisitos para las bibliotecas C por Tcl. No es
difícil implementar estos requisitos, pero a veces lleva mucho tiempo debido a su rutina. Y aquí el servicio público
SWIG viene al rescate
. , que le permite crear módulos de interfaz entre bibliotecas C / C ++ y otros lenguajes. Esto no es solo Tcl, sino también Java y otros. El proyecto está muy bien documentado y tiene excelentes ejemplos. Usarlo no es difícil. En nuestro caso, para obtener el módulo de interfaz, se escribió un archivo fuente simple cwapi.i para la utilidad swig:
%module cwapi %inline %{ #include "cwapi.h" %} %include "cwapi_SWIG.h"
El archivo cwapi.h contiene descripciones de funciones del proyecto principal cwapi:
#ifdef __cplusplus extern "C" { #endif int CW_Initialize (char *configdir); int CW_Finalize (); int addp11mod (char *nickname, char *library); int remp11mod (char *nickname); char * lmod (); char * ltok (); char * lcert (char *token, int priv_cert); char* createreq (char *token, char *subject, char *keyusage, int keyparams, int pem, char *skzi, char* role); char* viewx509 (char *nickname, int CertOrReq); char* x509pem (char *nickname); char* x509fromfile(char *token, char *infile, char *trusts); int delcert (char *nickname, int priv_cert); int p12tofile (char *token, char *nickname, char *outfile); char* p12fromfile(char *token, char *infile); char* lmech(char* token); char* tinfo(char* token); #ifdef __cplusplus } #endif
Al ejecutar el comando:
$export SWIG_LIB=/usr/local/swig-3.0.12/Lib $/usr/local/swig-3.0.12/swig -tcl8 -o cwapi_wrap.c cwapi_.i $
en el archivo cwapi_wrap.c obtenemos un módulo de interfaz listo para usar. Agréguelo al proyecto cwapi, vuelva a generarlo y obtenga un nuevo paquete, que se utiliza en esta utilidad.
Para obtener el kit de distribución, es muy conveniente utilizar la utilidad
freewrap , mientras que la biblioteca cwapi también se incluye directamente en el paquete de distribución. Las utilidades y distribuciones de código fuente están disponibles para las plataformas Windows y Linux.
Me gustaría mencionar otra utilidad, a saber,
tcl2c . Esta utilidad "envuelve" el código tcl / tk en el código C.
Para obtener el código ejecutable, simplemente ejecute el comando:
$cc -o create_csr_ create_csr.c -ltcl -ltk $
Las distribuciones para la plataforma Linux también incluyen una distribución en C con una conexión estática del paquete cwapi.