Gato por liebre: DNIe 3.0 de RENIEC

RENIEC anunció con bombos y platillos un DNIe 3.0 con 64 niveles de seguridad, mediciones técnicas revelan apenas 13 activos. A ello se suma una alerta de “compatibilización” que, bajo argumentos técnicos poco sólidos, amarra al país durante tres años al sistema operativo y applets de un único proveedor: IDEMIA. Se invoca la continuidad del servicio para justificar lo que en realidad es un direccionamiento de compras, disfrazado de necesidad técnica. América Sistemas desnuda las falacias de la operación encubierta y alerta: la estandarización debería garantizar interoperabilidad y libre competencia, no cerrar el mercado ni comprometer la seguridad ciudadana.

“DNIe 3.0: la compatibilización y estandarización que si es necesaria ?”

Alardes de decenas de “llaves de seguridad” en el DNIe 3.0, mientras que mediciones técnicas hallan apenas trece activas. En paralelo, esfuerzos técnicos por “compatibilización” que amarría, por tres años, a un único sistema operativo y a los applets de un proveedor. Vea las falacias técnicas que nuestros colaboradores expertos identificaron y lo que sí debería estandarizarse.

1) El dato que no cuadra: 64 “llaves” anunciadas vs. 13 detectadas
RENIEC promociona el DNIe 3.0 con 64 “llaves” o elementos de seguridad en su web y redes oficiales. La propia entidad —y su jefatura— han repetido esa cifra al presentar el nuevo documento. (Reniec, X (formerly Twitter), Gobierno del Perú)

Sin embargo, América Sistemas evidencia que, en tarjetas emitidas, solo se reconocen 13 mecanismos activos, una caída drástica frente a lo prometido.

2) El corazón del “enganche”: un informe que confunde compatibilizar con estandarizar por marca
La información que llegó a nuestra redacción muestra que ciertas características técnicas del CHIP solo las presenta el fabricante IDEMIA y recomienda que se estandarice hasta en “sus versiones posteriores”), esto como condición para “garantizar” la segura y eficiente  emisión del DNIe, por un período de tres (03) años. Eso, en los hechos, estandariza una marca vía compatibilización.

Para justificarlo, se afirma que cambiar de SO o applets “no permitiría” que funcione el software de personalización, interrumpiendo la emisión del DNIe. También apela al daño reputacional y a costos adicionales como barreras.

¿Qué dice la norma sobre compatibilización?
La Ley 32069 y su Reglamento (DS 009-2025-EF) permiten compatibilizar solo cuando se trata de accesorios o complementos imprescindibles para equipos preexistentes; y la Directiva 001-2025-EF/54.01 ordena sustentarla con criterios técnicos y objetivos. No autoriza cerrar el mercado ni congelar una marca por años.

Falacia 1 — Falso dilema (o IDEMIA o el caos):
Se presupone que otro SO de chip “no permitiría” funcionar. En realidad, se reconoce que el flujo de personalización conversa con el chip vía comandos APDU y scripts conforme a GlobalPlatform Scripting (ambos estándares). Si hoy está “amarrado”, es por acoplamiento de software, no por imposibilidad técnica de migrar/bifurcar.

Falacia 2 — Petición de principio (círculo vicioso):
Se concluye que “se necesita IDEMIA” porque el software fue hecho para IDEMIA. Eso no prueba necesidad técnica; describe una decisión previa (diseño propietario) y la convierte en “requisito legal”.

Falacia 3 — Apelación al miedo operativo:
Se invoca la “desconfianza ciudadana” y potencial “paralización” para descartar análisis de migración o convocatorias con interoperabilidad. Ese argumento es persuasivo, no técnico.

Falacia 4 — Equívoco entre “compatibilizar” y “estandarizar”:
Compatibilizar es ajustar lo nuevo a lo que ya existe; estandarizar por marca (y encima por 3 años) crea exclusividad de facto. El propio informe pide aprobar “las versiones posteriores que el fabricante publique”, algo incompatible con competencia futura.

3) Lo que sí debería estandarizarse (para no casarnos con nadie)
Interfaces y perfiles, no marcas: mantener APDU, perfiles de aplicaciones (ICAO, PKI, MOC, ID) y scripts de personalización basados en especificaciones públicas (p. ej., GlobalPlatform Scripting), de modo que múltiples SO de tarjeta puedan certificarse contra el mismo “perfil RENIEC”.

Plan de migración gradual: lotes piloto con dos proveedores y middleware o card manager que abstraiga diferencias, evitando hard-coding a applets propietarios. (El propio flujo del informe admite esa capa de scripts).

Pruebas de conformidad y benchmarks de seguridad: publicar matrices de verificación para cada “llave” o mecanismo de seguridad (físico, lógico y criptográfico) y evidenciar cuántos pasan en tarjetas entregadas (auditoría independiente).

4) Puntos finos que un ojo técnico si detecta
“Cada tarjeta tiene su propio SO y applets”: correcto; por eso el estándar debe estar por encima del SO. El informe, en cambio, baja el estándar al nivel de una marca específica.

Dependencia del software de personalización: se admite que todo el proceso está hoy acoplado a los applets IDEMIA. Eso explica la fricción, no la justifica como imposibilidad.

Alcance temporal excesivo: fijar 3 años de vigencia y aprobar por adelantado “versiones posteriores” cierra la puerta a competencia e innovación en un mercado que evoluciona rápido.

5) Preguntas que RENIEC debe responder (y documentar) ya
¿Dónde está la matriz de las “64 llaves” con su definición técnica y evidencia de verificación en tarjetas emitidas? (La Parte I halló 13 activas).

¿Qué plan de interoperabilidad (perfiles APDU, scripts, conformance tests) permitirá alternar tarjetas de más de un proveedor sin reescribir todo?

¿Por qué compatibilizar con “versiones posteriores” de un único fabricante, si la Directiva exige criterios técnicos y objetivos ligados a equipamiento preexistente, no a una marca?

6) En claro
RENIEC anuncia 64 elementos de seguridad en el DNIe 3.0; en campo se ven 13. Eso exige auditoría pública y corrección inmediata. (Reniec, X (formerly Twitter))

El informe de compatibilización utiliza argumentos circulares y de miedo operativo para blindar por 3 años a un proveedor y su SO, cuando la norma permite compatibilizar sin cerrar la competencia si se definen perfiles e interfaces estándar adecuados.

América Sistemas seguirá transparentando la parte técnica —donde suele esconderse el “truco”— para que la ciudadanía y los órganos de control puedan exigir seguridad real e interoperabilidad, no slogans. Como siempre, agradecemos a los técnicos lectores de AS que hacen posible estos “descubrimientos” que no hacen más que dañar los grandes objetivos tecnológicos nacionales.