Cómo funciona la firma digital por dentro: la clave privada, la huella del documento, el certificado y la cadena de confianza
Imaginemos a Marco, que administra una constructora en Piura (el caso es inventado). Un proveedor le manda un PDF firmado digitalmente, Marco lo sube al validador del Estado y aparece «firma válida». Hay una penalidad en juego y quiere saber qué acaba de comprobar el programa. ¿Que el proveedor aceptó el texto? ¿Que el archivo no cambió? ¿Que el nombre del certificado es el de una persona real? Son tres preguntas distintas, y cada una la responde una pieza distinta del mecanismo.
Este artículo abre esas piezas una por una y pone al lado de cada una la norma que la exige. Leímos la Ley 27269, su reglamento, la guía de acreditación de entidades de certificación de INDECOPI y la declaración de prácticas de RENIEC el 22 de octubre de 2026, y ese día ejecutamos los comandos de OpenSSL, con la salida pegada tal como salió. Donde la norma calla y concluimos algo nosotros, lo marcamos como «nuestra lectura».
Cuatro piezas y la frase del reglamento que las ordena
El artículo 3 de la Ley 27269 (28 de mayo de 2000) define la firma digital como una firma electrónica que usa criptografía asimétrica, con una clave privada y una clave pública relacionadas matemáticamente. Eso dice con qué se firma. Qué se firma y cómo se sabe de quién es lo desarrolla el reglamento (D.S. 052-2008-PCM, 19 de julio de 2008). Su artículo 7 enumera las características mínimas de la firma digital, y la primera es que:
«Se genera al cifrar el código de verificación de un documento electrónico, usando la clave privada del titular del certificado.»
Cuatro piezas en una frase: la clave privada, que firma; el código de verificación, o hash, que es lo que se firma; el certificado, que dice de quién es la clave pública; y la entidad que lo emitió, de donde cuelga la confianza.
Una precisión sobre los textos. El D.S. 029-2021-PCM (19 de febrero de 2021) reescribió varios artículos del reglamento, entre ellos el 6, el 8 y el 10, pero no el 7 ni el 11, que citamos en su redacción de 2008. Tampoco tocó las definiciones de clave privada, clave pública, hash y certificado: de todo el glosario alcanza a un solo término, «Autoridad Administrativa Competente».
La clave privada y la clave pública
El glosario define la clave privada como la que «es mantenida en reserva por el titular de la firma digital»; la pública la puede conocer cualquiera y sirve al destinatario para verificar. Sobre la relación entre ambas, la Ley dice que no se puede derivar la privada desde la pública, y el glosario es más cauto: la posibilidad de acceder a la privada a partir de la pública es, dice, «técnicamente ínfima». Nuestra lectura: se promete una inviabilidad práctica con una longitud suficiente, no una propiedad matemática absoluta.
Quién guarda la privada lo dice el artículo 10 del reglamento en su texto de 2021: el suscriptor debe «mantener el control y la reserva de la clave privada bajo su responsabilidad», y puede autorizar su generación a distancia por un prestador de firma remota acreditado. Lo que cambia cuando la clave privada vive en un equipo ajeno está en firma remota y HSM.
La guía de INDECOPI añade dos exigencias. Una: «No se permite el empleo de los depósitos de claves privadas de backup (Key Escrow) para las claves de firma digital». Nuestra lectura: nadie conserva una copia de respaldo de tu clave de firma. Otra, en la tabla de niveles de la versión 4.1 (28 de agosto de 2019), columna del nivel medio: «Los certificados no deberán ser almacenados en formatos .pfx o .p12.» Si te entregaron el certificado como un .pfx por correo, pregunta cómo se cumple esa línea. Más en firmar con token USB y por qué no hay .pfx.
La huella: lo que se firma de verdad
La clave privada no firma el documento. Firma una huella suya. El reglamento la define como una «secuencia de bits de longitud fija obtenida como resultado de procesar un documento electrónico con un algoritmo», con tres propiedades: el mismo documento da siempre el mismo código, es improbable reconstruir el documento desde el código, y es improbable encontrar dos documentos con el mismo código. No la confundas con el «Código de Verificación Digital» del artículo 36 del D.S. 029-2021-PCM, que sirve para cotejar una copia impresa con su original.
La consecuencia práctica es que cambiar una cifra cambia la huella entera. Con dos contratos de una línea que solo difieren en la renta, OpenSSL 3.5.8 devuelve esto:
$ openssl dgst -sha256 contrato.txt contrato-alterado.txt
SHA2-256(contrato.txt)= 67324b8ecffce71ae9aa25694bf6d0c15b764c8e1f48831b712bdfc954d19065
SHA2-256(contrato-alterado.txt)= 0751df540dc225a3f9df75c5ba9b58880d9b5dfa20d86e35b1390eb05f837886
El primero dice «S/ 1500» y el segundo «S/ 2500». Las dos huellas no se parecen en nada.
Firmar y comprobar con OpenSSL
Usamos un par RSA de 2048 bits de prueba, creado con openssl genpkey, y su parte pública en firmante.pub. Para firmar, OpenSSL calcula la huella con SHA-256 y la procesa con la privada. Para verificar, solo hace falta la pública:
$ openssl dgst -sha256 -sign firmante.key -out contrato.sig contrato.txt
256 bytes contrato.sig
$ openssl dgst -sha256 -verify firmante.pub -signature contrato.sig contrato.txt
Verified OK
$ openssl dgst -sha256 -verify firmante.pub -signature contrato.sig contrato-alterado.txt
00A3E3A20A7F0000:error:02000068:rsa routines:ossl_rsa_verify:bad signature:crypto/rsa/rsa_sign.c:441:
00A3E3A20A7F0000:error:1C880004:Provider routines:rsa_verify_directly:RSA lib:providers/implementations/signature/rsa_sig.c:1086:
Verification failure
La misma firma que valida el contrato original falla con el alterado. El verificador no averigua qué cambió: calcula la huella del archivo que tiene delante y no coincide con la que viene dentro de la firma. Es lo que pide el literal e) del artículo 7, que exige poder «detectar si la firma digital o el documento electrónico fue alterado».
Y se puede mirar dentro. Abrir la firma con la pública devuelve lo que se firmó:
$ openssl pkeyutl -verifyrecover -pubin -inkey firmante.pub -in contrato.sig | openssl asn1parse -inform DER
0:d=0 hl=2 l= 49 cons: SEQUENCE
2:d=1 hl=2 l= 13 cons: SEQUENCE
4:d=2 hl=2 l= 9 prim: OBJECT :sha256
15:d=2 hl=2 l= 0 prim: NULL
17:d=1 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:67324B8ECFFCE71AE9AA25694BF6D0C15B764C8E1F48831B712BDFC954D19065
Dentro están el nombre del algoritmo (sha256) y 32 bytes idénticos a la huella que calculamos aparte para contrato.txt. Nuestra lectura: el «cifrar» del artículo 7 es la forma de 2008 de describir esta operación; las bibliotecas actuales la llaman firmar.
Lo que el ejercicio prueba: quien produjo la firma tenía la privada que corresponde a firmante.pub, y los bytes no cambiaron. Lo que no prueba: de quién es firmante.pub. Cualquiera genera un par en dos segundos. Para eso está el certificado.
El certificado: lo que une una clave pública con una persona
La Ley lo define en su artículo 6 como documento «generado y firmado digitalmente por una entidad de certificación», que vincula el par criptográfico con una persona determinada y confirma su identidad. Quien vincula es la entidad de certificación con su firma. Quien confirma la identidad antes es la entidad de registro (artículo 13), y por qué ese paso decide si el certificado vale algo está en quién comprueba que eres tú.
El artículo 7 de la Ley fija qué lleva todo certificado, y el artículo 16 del reglamento (texto de 2021) añade lo suyo:
| Qué lleva | Dónde lo exige |
|---|---|
| Datos del suscriptor y de la entidad de certificación | Ley, art. 7, n.º 1 y 2; reglamento, art. 16 |
| La clave pública, el número de serie y la vigencia | Ley, art. 7, n.º 3, 5 y 6 |
| La firma digital de la entidad | Ley, art. 7, n.º 7 |
| Dónde consultar el estado, dónde está el certificado de la entidad emisora, la política de certificación | Reglamento, art. 16 |
La fila de la firma de la entidad cierra el círculo. El RFC 5280 (mayo de 2008), que describe el formato X.509, dice en su apartado 4.1.1.3 que la entidad firma el cuerpo del certificado, el tbsCertificate, y con ello «certifies the binding between the public key material and the subject of the certificate». Es el mecanismo de antes aplicado otra vez: huella del certificado, procesada con la privada de la entidad.
Tu certificado se abre con dos comandos, en abre tu certificado digital y léelo. Del certificado de prueba que montamos para este artículo, estas son las líneas que importan:
subject=C=PE, O=Demo, CN=Rosa Quispe (prueba), serialNumber=DNI 00000000
issuer=C=PE, O=Demo, CN=EC de prueba
notBefore=Oct 22 13:43:15 2026 GMT
notAfter=Oct 22 13:43:15 2027 GMT
Signature Algorithm: sha256WithRSAEncryption
Public-Key: (2048 bit)
X509v3 Key Usage: critical
Digital Signature, Non Repudiation
La cadena de confianza
La entidad que firma tu certificado tiene a su vez un certificado, firmado por otra, hasta una raíz que se firma a sí misma. La declaración de prácticas de ECEP-RENIEC (versión 5.1, 4 de junio de 2026) lo cuenta para el Estado peruano: la ECERNEP administra los certificados raíz, y «el certificado digital raíz de la ECERNEP es autofirmado y es el inicio de la cadena de confianza de todos los participantes de las infraestructuras PKI». Debajo, la ECEP-RENIEC tiene un certificado de nivel 2 sin conexión (offline) y certificados de nivel 3, llamados clases, que operan en línea y emiten a titulares y suscriptores.
La guía de INDECOPI pide a esas entidades módulos criptográficos con «FIPS 140-2 Nivel de Seguridad 3 o Common Criteria EAL4+ como mínimo», cuenta entre sus lineamientos «por lo menos controles duales» para operar la clave privada de la entidad, y establece que «dos o más EC no pueden compartir la misma jerarquía PKI».
Con OpenSSL se ve qué pasa cuando falta un eslabón. Montamos una raíz, una intermedia y un certificado final:
$ openssl verify -no-CApath -CAfile raiz.pem -untrusted inter.pem hoja.pem
hoja.pem: OK
$ openssl verify -no-CApath -no-CAfile -untrusted inter.pem hoja.pem
C=PE, O=Demo, CN=EC de prueba
error 20 at 1 depth lookup: unable to get local issuer certificate
error hoja.pem: verification failed
$ openssl verify -no-CApath -CAfile raiz.pem hoja.pem
C=PE, O=Demo, CN=Rosa Quispe (prueba), serialNumber=DNI 00000000
error 20 at 0 depth lookup: unable to get local issuer certificate
error hoja.pem: verification failed
El primero pasa. El segundo tiene el certificado final y la intermedia pero no la raíz; el tercero, la raíz pero no la intermedia. En los dos fallos la firma está bien y falta una pieza. El artículo 16 del reglamento exige que el certificado lleve la «Dirección electrónica del certificado de la entidad de certificación emisora»; nuestra lectura es que está ahí para que un verificador recupere la pieza que falta.
Fíjate también en que el primero dio OK con una raíz de mentira, porque se la dimos. La matemática funciona con cualquier raíz; que pertenezca a la Infraestructura Oficial de Firma Electrónica lo dice la lista de INDECOPI.
La guía describe el Registro Oficial de Prestadores de Servicios de Certificación Digital como «una lista “blanca” que contiene la relación de los PSC acreditados», firmada por INDECOPI. Su versión pública es la TSL. La que consultamos (secuencia 25, emitida el 10 de agosto de 2026, próxima actualización el 10 de febrero de 2027; idéntica el 17 y el 22 de octubre) tiene 33 prestadores y 74 servicios (conteo nuestro sobre el XML). No es una cadena: cada servicio trae un nombre, un tipo, un estado y el certificado con el que opera. Y la lista va firmada; estas son las líneas que importan del certificado firmante que sacamos del XML:
subject=C=PE, emailAddress=iofe@indecopi.gob.pe, serialNumber=20133840533, O=INDECOPI, OU=DGI, CN=TSL Suscriptor
issuer=C=PERU, OU=CFE, O=INDECOPI, CN=INDECOPI AAC RAIZ
notAfter=Aug 23 14:19:00 2027 GMT
Public-Key: (2048 bit)
Signature Algorithm: sha256WithRSAEncryption
El método de firma declarado en el XML es rsa-sha256: el mismo mecanismo de arriba. Nuestra lectura: la cadena responde si un certificado desciende de una raíz, y la TSL responde si esa raíz y esa entidad están acreditadas. Una validación completa necesita las dos. Cómo lo hace el validador del Estado está en qué comprueba de verdad, y cómo contrastar tu entidad con la lista, en comprobar que un certificado está acreditado.
Qué comprueba quien valida
Un validador responde cuatro preguntas, y el reglamento respalda cada una:
- ¿Cambió el documento? Recalcula la huella y la compara con la de la firma (artículo 7 e).
- ¿La firma corresponde a esta clave pública? Es el literal c): la firma es «susceptible de ser verificada usando la clave pública del suscriptor».
- ¿El certificado desciende de una raíz acreditada? El artículo 6 condiciona la equivalencia con la firma manuscrita a que la genere un prestador acreditado dentro de la IOFE.
- ¿Estaba vigente y sin cancelar al firmar? Las fechas están en el certificado; la cancelación, en la lista de revocación (artículos 9 y 10 de la Ley). Ver revocación, sellado de tiempo y conservar un documento firmado.
Cuando las cuatro salen bien, el artículo 8 aplica sus presunciones. En su texto vigente, la primera es «que el suscriptor del certificado digital tiene el control de la clave privada asociada, con un elevado grado de confianza»; la de 2008 decía «control exclusivo». Las otras dos, que se firmó con esa clave privada y que el documento no se alteró, las leemos en el texto de 2008. La voluntad de firmar no la prueba la criptografía: el reglamento dice que el suscriptor «no podrá repudiar o desconocer un documento electrónico que ha sido firmado digitalmente usando su clave privada», siempre que no medie algún vicio de la voluntad. El reparto de esa prueba está en firma digital, electrónica y avanzada.
Longitud de la clave privada y algoritmo: lo que exige INDECOPI
Las cifras de 1024 y 2048 bits que circulan a propósito de los anexos de INDECOPI salen de tres documentos distintos (el detalle, con la salida de OpenSSL sobre certificados reales, está en la longitud de la clave privada y el algoritmo):
| Documento | Fecha | Nivel | Longitud mínima de la clave privada | Renovación máxima |
|---|---|---|---|---|
| Guía de EC v. 4.1, tabla de niveles | 28 ago 2019 | Medio / Medio alto / Alto | 2048 bits en los tres | 3 / 2 / 1 año |
| Anexo 8 de esa guía, art. 10 b) y 12 b) | Rev. 2018 | Medio / Medio alto | 2048 bits en ambos | 3 / 2 años |
| Anexo 7 de la guía de ER, art. 9 b) y 11 b) | Rev. 03/23-02-2007 | Medio / Medio alto | 1024 / 2048 bits | 1 / 2 años |
Ese anexo 7 es el de la guía de entidades de registro; el equivalente en la guía de certificación es el 8. La tabla de la propia guía de ER (versión 4.0, 2018) ya pide 2048 en el nivel medio, así que dentro de ese paquete el anexo y la guía no coinciden. Nuestra lectura: el piso actual para el usuario final es de 2048 bits, y el 1024 parece un resto de un anexo sin actualizar.
En la guía de EC y en los anexos 1, 5, 7 y 8 que descargamos, el único rastro es la sigla SHA («Secure Hash Algorithm») en la lista de acrónimos de la guía: ninguna función hash ni algoritmo de firma se exige por nombre (buscamos SHA, RSA, MD5, DSA y ECDSA). La guía pide «algoritmos criptográficos de reconocimiento internacional de tamaño y seguridad criptográfica suficiente» y que sean seguros «durante el tiempo de duración del certificado». El suelo de longitud está escrito; el algoritmo lo elige cada entidad. La de ECEP-RENIEC 5.1 lo declara en su tabla 8: niveles offline y online con sha512WithRSAEncryption y 4096 bits, entidades finales con sha256WithRSAEncryption y 2048 bits. Sus entidades de registro deben rechazar la solicitud «Si la longitud de la llave es menor a 2048 bits.»
Un detalle que evita sustos: los identificadores de la clave pública en esos certificados se calculan con SHA-1 (160 bits), uno de los dos métodos comunes que describe el RFC 5280 en su apartado 4.2.1.2. Sirven para identificar la clave pública, no para firmar. Para ver el algoritmo y la longitud del tuyo:
openssl x509 -in certificado.pem -noout -text | grep -E "Signature Algorithm|Public-Key"
Cifrar no es firmar
El certificado dice para qué se puede usar su clave pública, en la extensión Key Usage. El RFC 5280 (apartado 4.2.1.3) separa los usos que verifican firmas (digitalSignature, nonRepudiation) del de gestión de claves privadas o secretas (keyEncipherment). El reglamento lo vuelve exigible: el artículo 11 a) declara que una firma digital «carece de validez» cuando «es utilizada en fines distintos para los que fue extendido el certificado».
Para el nivel medio, el anexo 8 de la guía (artículo 10 c) dice que los certificados de usuario final «deben ser generados de manera individual y separados para las siguientes funciones: cifrado y firma (no repudio) o autenticación», es decir, el de cifrado aparte y la firma con la autenticación en un mismo certificado si se quiere. Para el medio alto (artículo 12 c), el mismo anexo pide los tres separados: «cifrado, firma (no repudio) y autenticación». La tabla de la guía v4.1 deja esa separación en tres solo para el nivel alto. Otra discrepancia entre textos de INDECOPI.
Lo que sale mal
- El PDF se «optimizó» después de firmarse. Cambió un byte, cambió la huella, la verificación falla. Es correcto que falle.
- La cadena queda coja:
unable to get local issuer certificate, como arriba. - Todo sale verde con una raíz que nadie acreditó. La matemática no distingue una raíz del Estado de una de prueba; hay que mirar la TSL.
- Se firmó con un certificado de otro uso, de cifrado o de servidor web. Falla el artículo 11 a), no la criptografía.
Nuestra opinión
Antes de pagar, pídele a tu entidad el apartado de su declaración de prácticas donde constan el tamaño de las llaves y el algoritmo. RENIEC responde con un numeral (6.1.5) y una tabla. El glosario del reglamento define esa declaración como el documento «oficialmente presentado por una Entidad de Certificación a la Autoridad Administrativa Competente», así que existe. Y cuando algo «no valida», empieza por la cadena: depende de lo que tiene instalado el programa, no del documento, y es lo más fácil de descartar.
Lo que este artículo no afirma
- Qué algoritmo y hash acepta SUNAT en la firma del XML. No lo comprobamos en una fuente de SUNAT para esta página.
- Que 2048 bits alcance, ni cuándo habría que cambiar de algoritmo. No encontramos plazo ni regla de transición, y no citamos estimaciones externas.
- Que los artículos 7 y 11 del reglamento sigan como en 2008. Leímos las modificaciones de 2011, 2012, 2021, 2023 y 2025, no el D.S. 026-2016-PCM ni el D.S. 155-2022-PCM. Tampoco que la Ley 27269 no cambiara después de la Ley 27310, que modifica su artículo 11.
- Que otras entidades hagan lo que RENIEC, ni qué raíces trae de fábrica Adobe, Windows u otro programa. Solo leímos la declaración de ECEP-RENIEC y no medimos programas.
- Si la ECERNEP necesita acreditación para que sus certificados valgan. Una nota al pie de la declaración de RENIEC dice que el D.S. 155-2022-PCM amplió el plazo para prestar servicios «sin encontrarse acreditada ante el INDECOPI». No estudiamos ese decreto.
- El nivel de seguridad con que está acreditada cada entidad, que la TSL no muestra, ni cuántos certificados de 1024 bits siguen vigentes.
Los artículos de esta serie
Esta página es el pilar. Los siguientes desarrollan cada pieza:
- La longitud de la clave privada y el algoritmo de tu certificado digital: qué exige INDECOPI y cómo ves el tuyo.
- La huella del documento: qué función hash usa tu firma digital, SHA-1 frente a SHA-256 y qué acepta SUNAT en el XML.
- La cadena de confianza: de la raíz del Estado a tu certificado, y qué raíces trae cada programa de fábrica (próximamente).
- Cifrar no es firmar: para qué se puede usar tu certificado y los certificados separados que pide la guía (próximamente).
- Qué dice la norma cuando un algoritmo deja de servir: qué pasa con tus certificados vigentes y con lo ya firmado (próximamente).
Fuentes
Consultadas entre el 17 y el 22 de octubre de 2026. Copias locales en reports/redaccion-diaria/, carpetas 2026-10-17-notas/fuentes/mfd-ec y mfd-correo, 2026-10-19-notas/fuentes/mfd-dnie, 2026-10-21-notas/fuentes/mfd-autenticar y 2026-10-22-notas/fuentes/mfd-pilar11.
- Ley 27269, El Peruano, 28 de mayo de 2000, artículos 3, 6, 7, 9, 10 y 13, con la Ley 27310 (artículo 11). Copia:
mfd-autenticar/ley27269-mod27310.txt. - D.S. 052-2008-PCM, El Peruano, 19 de julio de 2008, artículos 4, 7, 11 y glosario. Copia:
mfd-dnie/ds052-2008.txt. - D.S. 029-2021-PCM, El Peruano, 19 de febrero de 2021, segunda disposición complementaria modificatoria (artículos 6, 8, 10 y 16) y artículo 36. Copia:
mfd-dnie/ds029.txt. D.S. 070-2011-PCM y 105-2012-PCM, solo para ver qué artículos tocaron:mfd-ec/ds070.pdf,mfd-ec/elperuano-2012-10-21.txt. - INDECOPI, Guía de Acreditación de Entidades de Certificación v. 4.1 (28 de agosto de 2019; la página de gob.pe que la aloja lleva la fecha 13 de mayo de 2026) y su anexo 8. Copias:
mfd-ec/guia-ec.txt,mfd-pilar11/ec-anexo8.txt. - INDECOPI, Guía de Acreditación de Entidades de Registro v. 4.0 (2018) y su anexo 7. Copias:
mfd-ec/guia-er-v4.txt,mfd-ec/anexo7.txt. - INDECOPI, lista de confianza TSL, secuencia 25, consultada el 17 y el 22 de octubre de 2026. Copias:
mfd-correo/tsl-pe.xml,mfd-pilar11/tsl-pe-22oct.xml. - RENIEC, Declaración de Prácticas de Certificación ECEP-RENIEC v. 5.1 (4 de junio de 2026), numerales 1.3.1, 1.3.2 y 6.1.5. Copia:
mfd-dnie/cps-ecep-v5.1.txt. - IETF, RFC 5280 (mayo de 2008), apartados 4.1.1.3, 4.2.1.2 y 4.2.1.3, solo para la estructura del certificado. Copia:
mfd-pilar11/rfc5280.txt. - Salida de los comandos (OpenSSL 3.5.8, 22 de octubre de 2026):
mfd-pilar11/demo1-salida.txt,demo2-salida.txtytsl-firmante-salida.txt.
Si lo que necesitas es un certificado con el que firmar, en mifirmadigital.pe vendemos certificados digitales emitidos dentro de la Infraestructura Oficial de Firma Electrónica, y todo lo que se explica arriba lo puedes comprobar tú mismo sobre el tuyo.
Última revisión: 22 de octubre de 2026.