Digital signing source code software for µFR Series NFC RFID contactless readers
La firma digital es el futuro de los negocios en línea, ya sea que estemos hablando de la simple firma de documentos, código y correo electrónico o de una implementación criptográfica más avanzada como vemos hoy en día en criptomonedas y blockchains.
Digital Logic Ltd. es una de las primeras empresas del mundo en implementar soluciones de firma digital con tarjetas RFID sin contacto.
Esperamos que los sistemas antiguos que todavía usan tarjetas de contacto pronto se conviertan en cosa del pasado.
El software μFR Signer admite algoritmos criptográficos RSA y ECDSA para firmar archivos digitalmente.
El software está diseñado para ser utilizado con nuestra serie μFR de dispositivos NFC: Nano, Classic, Classic CS y Advance.
μFR Signer funciona con todas las tarjetas compatibles con RSA y ECDSA. En nuestro video de demostración, utilizamos la tarjeta JCOP J3D081.
Las tarjetas DL Signer proporcionan la firma digital de datos y documentos en las propias tarjetas utilizando algoritmos criptográficos asimétricos RSA o ECDSA. La infraestructura PKI es compatible y en las tarjetas DL Signer, es posible almacenar certificados X.509 que están relacionados con pares de claves criptográficas generadas en las propias tarjetas. Se admite para almacenar todos los certificados X.509 que componen la cadena de confianza desde el certificado raíz hasta el certificado de entidad final.
La clave pública que se genera en las tarjetas DL Signer se coloca en el cuerpo de la solicitud mientras se crea el requisito de firma del certificado (en adelante, CSR). La solicitud se firma en la propia tarjeta con una clave privada adecuada que nunca sale de la propia tarjeta y de ninguna manera se puede leer después de generar pares de claves. Además, la CSR se envía al organismo de certificación para crear y firmar el certificado X.509 basado en él. Este certificado de entidad final se coloca en la tarjeta DL Signer con otros certificados de la cadena de confianza y está listo para firmar digitalmente datos y documentos. El usuario puede enviar CSR a cualquier organismo de certificación cuyos servicios desee utilizar. Digital Logic ha proporcionado un mecanismo para emitir certificados de entidad final para probar el sistema. Una de las características básicas del certificado de entidad final es que la clave privada, que está emparejada con la clave pública que contienen dichos certificados, no debe usarse para firmar otros certificados.
Las herramientas de software de Windows que inician la generación de pares de claves criptográficas, generan CSR, administran los códigos PIN y PUK de las tarjetas DL Signer, manipulan el contenido de los certificados X.509 y firman los datos y archivos, se distribuyen como "ufr-signer".
"Signature-verifier" es una aplicación de Windows que valida firmas digitales RSA y ECDSA.
La firma digital y la validación de firmas también se pueden realizar desde la aplicación Adobe Acrobat Reader DC utilizando el módulo ufr-pkcs11 que desarrollamos para este propósito. Nuestro módulo PKCS #11 también se puede utilizar con el popular cliente de correo electrónico y navegador web de Mozilla, así como con otras herramientas de software que son compatibles con la especificación PKCS#11.
También proporcionamos servicios web para la verificación en línea de certificados X.509 y archivos pdf firmados.
Firmante de uFR
"uFR Signer" es una herramienta de software que inicia la generación de pares de claves criptográficas, genera solicitudes CSR, sirve para gestionar los códigos PIN y PUK de las tarjetas DL Signer, manipula el contenido de los certificados X.509 y firma los datos y archivos.
La aplicación se divide en varias unidades lógicas utilizando un componente visual de control de ficha. Las pestañas están etiquetadas por los nombres de estas unidades:
"RsA Keys" y "EC Keys" se utilizan para crear y manipular pares de claves RSA o ECC.
RSA (Rivest, Shamir, & Adleman) y ECC (Elliptic Curve Cryptography) representan algoritmos criptográficos asimétricos contemporáneos. Las tarjetas DL Signer admiten el almacenamiento de 3 claves RSA y 3 ECC por separado. Cada una de las claves criptográficas puede ser de diferentes longitudes y características y está indicada por un algoritmo criptográfico y un índice de claves.
La pestaña "Códigos PIN" se refiere a la administración y el registro del código PIN del usuario en la tarjeta DL Signer ubicada en el campo del lector uFR. El PIN es una abreviatura de "Número de Identificación Personal". Además de los códigos PIN, en esta pestaña, también puede desbloquear tarjetas eventualmente bloqueadas usando códigos PUK. PUK significa "Llave de desbloqueo pin".
La pestaña "Objetos de tarjeta" se utiliza para administrar certificados de CA y certificados de entidad final que están asociados con sus respectivas claves criptográficas a través de sus índices. Los certificados deben estar bajo la versión 3 de X.509. Las credenciales de la entidad final deben contener una clave pública generada originalmente en la tarjeta DL Signer en pares con la clave privada asociada. El propósito principal del certificado es para su uso con preparación para la firma a través del módulo PKCS # 11. La presencia de los certificados X.509 no es obligatoria para el uso de dl signer Card con las aplicaciones propietarias.
En la pestaña "Firma" hay opciones para crear firmas digitales. Es posible firmar una matriz de bytes, una entrada de texto o un archivo. Estas firmas se pueden verificar utilizando la aplicación "firm-verifier".
Para abordar los problemas de rendimiento de manera eficiente, las tarjetas de firmante DL están diseñadas para firmar bloques de datos de la manera más concisa posible. Por lo tanto, es una práctica firmar digitalmente los datos con un algoritmo RSA según lo definido por el esquema PKCS # 1 v1.5. Para el algoritmo ECDSA, el procedimiento de generación de firma digital, el relleno y los mecanismos de alineación se definen en RFC 6979.
La última versión de la aplicación uFRSigner es 1.5.3.0 y es necesario utilizar la versión 5.0.1 o superior de la biblioteca uFCoder y la versión de firmware uFR 5.0.7 o superior.
Códigos PIN
El código PIN es una abreviatura de "Número de identificación personal". La tarjeta DE FIRMANTE DL contiene 2 códigos PIN diferentes. Estos son el PIN SO (Oficial de Seguridad) y el código PIN de usuario. El llamado "Oficial de seguridad" es un usuario que tiene privilegios administrativos para acceder a objetos de seguridad en la tarjeta de firmante DL. El código PIN SO debe ser diferente del código PIN del usuario.
Se requiere que el "Oficial de Seguridad" esté conectado para acceder a la tarjeta en los casos en que sea necesario cambiar los códigos PIN y PUK y cambiar el contenido del almacenamiento de las claves y certificados. Iniciar sesión con un código PIN de usuario es necesario para obtener la firma digital de una cadena de datos hash.
Los códigos PIN en las tarjetas de firmante DL pueden tener un mínimo de 4 caracteres y un máximo de 8 caracteres. Aquí, debajo del carácter, hay cualquier carácter alfanumérico (distingue entre mayúsculas y minúsculas) o cualquier carácter imprimible. Los caracteres imprimibles se refieren principalmente a los signos de puntuación en los teclados estándar. Al cambiar los códigos PIN, no se recomienda el uso de caracteres específicos que solo se pueden encontrar en teclados localizados individuales, sino solo caracteres que están en el estándar ASCII y que existen en los teclados estándar en inglés de EE. UU.
En todas las tarjetas de firmante DL, los códigos PIN y PIN de usuario predeterminados se establecen inicialmente, que constan de ocho caracteres numéricos consecutivos '0' (cero) o "00000000".
El número máximo de códigos PIN consecutivos incorrectos introducidos es 5. Si se supera el número de intentos sucesivos incorrectos de introducir el código PIN, ese código PIN se bloquea. Si bien el código PIN no está bloqueado, al ingresar el código PIN correcto se restablece el contador de códigos PIN ingresado incorrectamente.
La única forma de desbloquear su PIN es ingresar el código PUK correcto. PUK es la abreviatura de "PIN Unlock Key". El código SO PUK sirve exclusivamente para desbloquear el código PIN SO y el usuario PUK para desbloquear el código PIN del usuario. En el caso de 10 códigos PUK consecutivos ingresados incorrectamente, el código PUK se vuelve inutilizable y la funcionalidad de la tarjeta en la que se relaciona el código PIN bloqueado permanece bloqueada para siempre.
Claves RSA
En la pestaña "Claves RSA" hay opciones para crear y administrar claves RSA. Antes de trabajar con claves RSA, la tarjeta de firmante DL debe estar en el campo lector uFR que está conectado al equipo que ejecuta la aplicación ufr-signer. Además, sostén (oficial de seguridad) debe estar conectado.
Claves EC
En la pestaña "Claves EC" hay opciones para crear y administrar la clave EC. Antes de trabajar con las claves EC, la tarjeta de firmante DL debe estar en el campo lector uFR que está conectado al equipo que ejecuta la aplicación ufr-signer. Además, sostén (oficial de seguridad) debe estar conectado.
Las tarjetas de señalización DL admiten las siguientes curvas ECC estándar:
Generación de solicitud de firma de certificado (CSR)
Está definido por el estándar PKCS#10 y representa un registro estandarizado que, entre otras cosas, contiene información básica sobre el usuario del certificado en el nombre distinguido. Basado en el nombre característico, el llamado Sujeto (campo sujeto) se forma en el certificado final X.509. Además, los registros CSR también pueden contener extensiones especificadas por el estándar X.509 que la Autoridad de Certificación (CA) puede considerar o descartar, dependiendo de su política de certificación. La parte básica de la RSC es sin duda una clave pública y sus parámetros. Todos estos datos, empaquetados en la forma definida por el estándar PKCS#10, finalmente se pasan a través del algoritmo de resumen criptográfico apropiado y el resultado se firma en la tarjeta con la clave privada adecuada. La firma digital así adquirida se convierte en una parte integral de la RSE.
La CSR se envía al emisor deseado del certificado, que representa a la llamada Autoridad de Certificación (CA). El emisor del certificado generará su certificado de entidad final X.509, que está firmado por su respectiva clave privada, ahora asociada con la clave pública contenida en el certificado de CA intermedia o raíz apropiado. De esta manera, su certificado de entidad final pasa a formar parte de la cadena de confianza garantizada por la Autoridad de Certificación (CA).
El cuadro de diálogo "Solicitud de firma de certificado (CSR)" es un grupo separado para la entrada de "Nombre distinguido (DN)", "Extensiones" y en la parte superior derecha de los grupos de cuadros combinados, para controlar el algoritmo hash y la definición de la clave criptográfica. A continuación a la derecha hay un grupo de botones para elegir actividades relacionadas con la generación de RSE.
Un nombre distinguido, denominado DN, consiste en un grupo de nombres distinguidos relativos (RDN) que representa el grupo de atributos. Al definir un DN, el orden del campo RDN es muy importante. Es importante tener en cuenta que es posible repetir un solo campo RDN varias veces dentro del DN. Hay que recordar que la Autoridad de Certificación (CA) no está obligada a emitir un certificado con el mismo DN definido en la RSC, sino que el DN puede formarse en base a sus propias reglas y datos obtenidos durante la verificación previamente implementada de la identidad del usuario.
La formación del DN se realiza seleccionando el RDN apropiado en el cuadro combinado y escribiendo el valor deseado en el cuadro de texto. Al presionar el botón "Poner", el RDN declarado se colocará en la lista (Cuadro de lista) que define DN. Si se ha seleccionado uno de los campos RDN en la lista, el nuevo RDN se insertará entre el campo seleccionado y el anterior. Si no se selecciona nada en la lista DN, se inserta un nuevo campo RDN al final de la lista. Para cancelar la selección en la lista, presione el botón "Anular selección". El RDN incorrecto se puede eliminar de la lista presionando "Eliminar". El orden del campo RDN se puede cambiar utilizando los botones "Subir" y "Bajar" que afectan a la redundancia del RDN seleccionado en la lista.
Las extensiones son una parte opcional de la CSR y la Autoridad de Certificación (CA) puede considerarlas o rechazarlas, dependiendo de su política de certificación. Es posible asignar más atributos, y es deseable definir una dirección de correo electrónico dentro del asunto alternativo del sujeto (nombre alternativo del sujeto, abreviado subjectAltName) porque este es el emisor de certificados más común en el lugar habitual para este propósito. Para las extensiones, el orden de los atributos individuales no es importante. Se prevé que aún se pueda definir el propósito deseado de las claves, el propósito ampliado de las claves y las declaraciones relacionadas con los certificados calificados. Una vez más, debe enfatizarse que los emisores del certificado pueden ignorar las extensiones, y solo algunos de ellos pueden emitir los llamados certificados electrónicos calificados. En cualquier caso, dentro de las extensiones, el usuario puede indicar los elementos deseados del futuro certificado, pero, una vez más, la eliminación final del certificado X.509 depende exclusivamente de su emisor y que todos los detalles deben estar completamente familiarizados con sus políticas antes de la conclusión del contrato emisor.
La elección del algoritmo hash se realiza desde el cuadro combinado marcado con el "algoritmo de resumen del firmante". La opción predeterminada es SHA-256, que se relaciona con el algoritmo SHA2 que tiene 256 bits en la salida o 32 bytes y se recomienda usar para CSR. SHA1 ya no se recomienda, y SHA2 con un mayor número de bytes en la salida (384 y 512), y el algoritmo SHA3 está planeado para un uso más frecuente en el futuro.
Las claves y sus parámetros ("algoritmo de cifrado del firmante" e "índice de clave del firmante (tarjeta)") no se pueden cambiar aquí y ya están definidos en la pestaña desde la que ha abierto este cuadro de diálogo ("Claves RSA" o "Claves EC") y su propósito aquí es solo informativo. Si las "Claves RSA" o "Claves EC" desde las que abrió el cuadro de diálogo CSR, no había ninguna clave pública correspondiente, previamente leída de la tarjeta, en la etiqueta que indica el tamaño de la clave RSA, la curva ECDSA se indicará como "Clave pública no establecida". Cuando no se establece una clave pública, no es posible ejecutar "Sign and Save CSR", pero sí es posible cargar DN y extensiones desde una CSR existente o la llamada CSR TBS.
TBS CSR es nuestro formato de registro interno llamado solicitud "To Be Signed" que puede servir como plantilla para crear solicitudes de CSR con múltiples características comunes. TBS CSR no contiene claves criptográficas, sino que solo almacena DN y extensiones.
Al presionar el botón "Borrar entradas", se eliminan todos los elementos del DN y la extensión para que el cuadro de diálogo esté preparado para la nueva entrada.
Al presionar la tecla "Firmar y guardar CSR", se realiza la firma de csr en la tarjeta y almacenarla en el archivo seleccionado. Si la tarjeta no está en el campo del lector uFR conectado o ingresó el código PIN de usuario incorrecto, recibirá un mensaje de error con la descripción adecuada.
Lo último que debe hacer después de generar la CSR es enviarla al emisor del certificado para recibir el certificado X.509. Puede elegir cualquiera de los emisores de certificados comerciales o no comerciales o presionando el botón "Obtener certificado en línea" puede enviar la CSR a nuestro servicio web para obtener una demostración, certificado de prueba emitido por "Digital Logic Ltd." Certificados de prueba. La demostración, un certificado de prueba está destinado solo para uso de prueba y su período de validez es de 3 meses. Los certificados de CA raíz e intermedios que acompañan se pueden descargar desde http://ca.d-logic.com.
Si hace clic en el botón "Obtener certificado en línea", se le pedirá un archivo CSR previamente guardado con una extensión ".pem" que se enviará al servidor HTTP. En relación con un servidor en el https://certificates.d-logic.com se realiza correctamente y se emite el certificado X.509, se le pedirá el nombre de archivo para guardar el certificado. De lo contrario, recibirá un mensaje de error apropiado.
X.509 Objetos
Esta ficha está destinada a administrar los objetos X.509, relacionados con los certificados de las tarjetas de firmante DL. Para leer objetos X.509 de una tarjeta, no es necesario iniciar sesión con ninguno de los códigos PIN. Para cambiar el contenido del almacenamiento de los objetos X.509 en la tarjeta, debe iniciar sesión con el código PIN SO en la página "Códigos PIN".
En la pestaña "Objetos X.509", la aplicación intenta leer inmediatamente la tarjeta que está presente en el campo del lector uFR. Si no hay ninguna tarjeta de firmante DL en el campo, aparecerá un mensaje de error, como se muestra en la imagen a continuación:
Si el almacenamiento de objetos X.509 se lee correctamente desde la tarjeta, las listas de visualización de certificados se rellenarán con ese contenido. Puede actualizar estas listas en cualquier momento colocando la tarjeta deseada en el campo del lector y presionando el botón "Actualizar objetos de la tarjeta".
La selección del archivo de certificado X.509 se realiza presionando la tecla "abrir archivo de certificado". También es posible leer certificados de archivos en formato PEM (codificados en Base64), que suelen tener la extensión ".pem" o de los archivos binarios escritos en el estándar ASN.1 (deR-encoded), que pueden tener extensiones ".crt", ".cer", o ".der". Si se selecciona un archivo válido, se mostrará un cuadro de diálogo del sistema que muestra el contenido del certificado X.509 seleccionado. Después de verificar los elementos del certificado, es suficiente confirmarlo presionando el botón "OK".
Para almacenar el certificado seleccionado en una tarjeta, debe introducir el ID de objeto deseado (cadena de caracteres alfanuméricos arbitraria) que debe ser único con respecto a otros certificados almacenados en la tarjeta. El ID de objeto se introduce en el cuadro de texto denominado "ID de objetos:". La propuesta es que los certificados que contengan claves públicas RSA se marquen con un ID de, por ejemplo. "0001" a "0003" y aquellos que contengan claves públicas ECDSA se marcarán con un ID de, por ejemplo. "1001" a "1003". Los certificados de CA también deben tener una etiqueta de identificación única en la tarjeta, por lo que es una sugerencia etiquetarlos con, por ejemplo, "5001" a "5012". Todavía es necesario seleccionar un tipo de clave. Para los tipos RSA y ECDSA, el índice de clave privada de la tarjeta está enlazado a ese certificado, y estos índices deben ser coherentes. Para la Autoridad de Certificación de CA, el orden del índice no es relevante, pero debido a la transparencia por recomendación, deben ingresarse en orden, uno tras otro en pares, por ejemplo, de raíz a intermedio. Las aplicaciones que admiten el módulo PKCS#11 y utilizan certificados X.509, funcionan leyendo todos los objetos públicos de la tarjeta y luego comprobando la cadena de confianza en función del contenido de los propios certificados. Al final, debe presionar el botón con un nombre descriptivo "Poner certificado de un archivo en la tarjeta con una identificación designada, tipo de objeto e índice".
Mencionamos los pares raíz e intermedio de certificados de CA y puede ser necesario aclarar aún más esto. Aquí hemos asumido que el certificado de entidad final en la cadena de confianza se establece a través del certificado de CA intermedio a raíz. Esta es la forma habitual de formar una cadena de confianza por parte de los emisores oficiales del certificado. Sin embargo, esta no es una regla estricta y otras configuraciones son posibles para alterar los certificados de CA que forman una cadena de confianza. Es importante destacar que siempre hay dos certificados finales, al principio de la cadena, el llamado certificado de CA raíz (raíz) y al final de la cadena certificado de entidad final (certificado hoja)
Firma
En la pestaña "Firma" hay comandos para obtener firmas digitales de la tarjeta. Se puede firmar un conjunto de datos de la línea de entrada etiquetada "M:" (mensaje) o un archivo cuya ruta se puede establecer haciendo clic en el botón de opción "Establecer archivo para firmar". Los datos se pueden introducir en formato hexadecimal (HEX), codificado en Base64 o diseño de código ASCII.
El formato hexadecimal (HEX) incluye pares de dígitos hexadecimales que se pueden separar por espacios. El formato Base64 se utiliza a menudo en criptografía y registros PEM de los certificados X.509. Aquí no trataremos el formato Base64 en detalle. El diseño de código ASCII es un estándar comúnmente utilizado para registrar conjuntos de datos textuales que incluyen todos los caracteres alfanuméricos, así como todos los signos de puntuación estándar. En principio, todo lo que se puede ingresar a través del teclado estándar en inglés de los Estados Unidos está cubierto por el diseño de código ASCII. Si por casualidad, se ingresan caracteres que no forman parte del diseño del código ASCII y se selecciona esta opción, estos caracteres se reemplazarán internamente por el carácter '?'. Los caracteres que no forman parte de la distribución del código ASCII se pueden introducir a través de algunos teclados localizados o seleccionando la opción "pegar" en el menú contextual del cuadro de texto "M:".
Cuando se ingresan algunos datos en la línea de entrada, la conversión a otro tipo de registro se realiza simplemente seleccionando el formato de registro deseado (opciones HEX / Base64 / ASCII) excepto cuando hay un error de entrada.
Al hacer clic en el botón de opción "Establecer archivo para firmar", se abre un cuadro de diálogo de selección de archivos que es estándar para el sistema operativo Windows. Cuando se selecciona el archivo, su ruta se establece en el cuadro de texto "M:".
Al presionar el botón "Guardar mensaje en archivo binario", se habilita para almacenar una matriz de bytes ingresados en el cuadro de texto "M:" al archivo binario.
Al seleccionar el "Get signature", los datos que se van a firmar pasan por el algoritmo hash seleccionado (Message digest algorithm) cuyo resultado se envía a la tarjeta. A continuación, la tarjeta genera una firma basada en el algoritmo criptográfico seleccionado desde el cuadro combinado "Algoritmo de cifrado" (RSA o ECDSA) y el índice de claves en la tarjeta (cuadro combinado "Índice de clave en tarjeta"). Para firmar la tarjeta, es necesario haber iniciado sesión con el código PIN del usuario de antemano.
Después de firmar correctamente, el valor de la firma digital se muestra en el cuadro de texto "Firma" en formato HEX o Base64, dependiendo de la opción seleccionada. Al cambiar la selección HEX / Base64, es posible convertir la pantalla de firma. La firma se puede guardar en el archivo binario presionando el botón "Guardar firma en archivo binario".
También se ha implementado el cálculo opcional del valor hash de la firma digital. La elección de algoritmos hash para este propósito también incluye el obsoleto algoritmo MD5 por razones históricas, ya que algunos sistemas criptográficos antiguos todavía dependen de este mecanismo. El valor hash de una firma digital se puede almacenar en un archivo binario presionando el botón "Guardar hash en archivo".
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
