Skip to content

Expand Spanish DNIe background and versions, mention NFC interface - #35

Open
AlexTMjugador wants to merge 3 commits into
OpenSC:masterfrom
AlexTMjugador:dnie-docs-update
Open

Expand Spanish DNIe background and versions, mention NFC interface#35
AlexTMjugador wants to merge 3 commits into
OpenSC:masterfrom
AlexTMjugador:dnie-docs-update

Conversation

@AlexTMjugador

@AlexTMjugador AlexTMjugador commented Aug 5, 2026

Copy link
Copy Markdown

Despite OpenSC working with DNIe 3.0 and 4.0 ID cards when used through their contact interface, the documentation for those versions has not been kept up to date, still referencing first-generation DNIe / DNI 2.0 cards that have not been issued to citizens for more than 10 years.

These changes expand the DNIe documentation to mention the newer DNIe 3.0 and 4.0 iterations, which are largely similar in their wire protocol to older DNIe cards, while incorporating a secondary NFC interface that is not functional in OpenSC at the moment and has been quite sparsely documented. These additions summarize the background I've came to know after hands-on testing of a DNIe 4.0 card issued 2 years ago, which I tried to use through its NFC interface with OpenSC to no avail.

While at it, I've elevated the support category of the Spanish eID card above unsupported, because I consider that OpenSC's support for its contact interface on its different versions goes beyond "incomplete, broken, or largely useless" and is mostly on par with e.g. that of the Italian eID. In fact, after reverse-engineering the official PKCS#11 DNIe module for contact interface support, I found it matches the almost the same ATRs, with a single extra ATR not covered by OpenSC that doesn't seem relevant in practice to me, and might match the missing uninitialized case mentioned in the DNIe card driver code comments. Moreover, the lack of contactless interface support does not seem to be a reason against this reclassification to me given that the supported hardware list begins with a disclaimer about OpenSC only working with contact interfaces unless otherwise noted. But I'd welcome discussion about whether this reclassification is indeed appropriate.

Despite OpenSC working with DNIe 3.0 and 4.0 ID cards when used through
their contact interface, the documentation for those versions has not
been kept up to date, still referencing first-generation DNIe / DNI 2.0
cards that have not been issued to citizens for more than 10 years.

These changes expand the DNIe documentation to mention the newer DNIe
3.0 and 4.0 iterations, which are largely similar in their wire protocol
to older DNIe cards, while incorporating a secondary NFC interface that
is not functional in OpenSC at the moment and has been quite sparsely
documented. These additions summarize the background I've came to know
after hands-on testing of a DNIe 4.0 card issued 2 years ago, which I
tried to use through its NFC interface with OpenSC to no avail.

While at it, I've elevated the support category of the Spanish eID card
above unsupported, because I consider that OpenSC's support for its
contact interface on its different versions goes beyond "incomplete,
broken, or largely useless" and is mostly on par with e.g. that of the
Italian eID. In fact, after reverse-engineering the official PKCS#11
DNIe module for contact interface support, I found it matches the almost
the same ATRs, with a single extra ATR not covered by OpenSC that
doesn't seem relevant in practice to me, and might match the missing
uninitialized case mentioned in the DNIe card driver code comments.
Moreover, the lack of contactless interface support does not seem to
be a reason against this reclassification given that the supported
hardware list begins with a disclaimer about OpenSC only working with
contact interfaces unless otherwise noted.

@frankmorgner frankmorgner left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you clarify the wiki page on what there currently exists (with links), what has been existing and is now not available anymore and what is currently impmenented and supported by OpenSC?

@AlexTMjugador

Copy link
Copy Markdown
Author

could you clarify the wiki page on what there currently exists (with links), what has been existing and is now not available anymore and what is currently impmenented and supported by OpenSC?

I'd like to provide more concrete evidence here, but unfortunately I don't have a dedicated smart card reader, so I can't inspect my newer DNIe 4.0 card through its contact interface to verify the claims, experiences, and standards conformance statements I've seen online. As a result, I wouldn't feel confident providing an exhaustive description of the technical differences introduced with DNIe 3.0.

That said, based on those reports and my birds-eye review of the decompiled PKCS#11 module provided by the DGP, my impression is that the contact interface of DNIe 3.0 is largely similar to that of the previous DNIe / DNI 2.0 generation. As such, most documentation for the first-generation DNIe is probably still relevant, though it could benefit from better framing to explain how the ID card has evolved over time in a largely backwards-compatible manner.

I also believe OpenSC implements, at least on paper, the functionality required for operating the DNIe 3.0 contact interface for its intended uses. According to DGP's documentation, the only additional piece of data that OpenSC's dnie driver might be interested in accessing is fingerprint information. However, comments in the current driver claim that this information is only accessible through special devices used by the police, which aligns with the statement in this official document that "the change of PIN, making use of the fingerprint (unlocking), is only allowed in devices authorized by the DGP and cannot be done, under any circumstance, in any other devices". The same document also indicates that fingerprint authentication is provided through a "Match-on-Card" interface that does not need to disclose the fingerprint data itself to work, likely according to the definitions in ISO/IEC 24787 and the third part of ISO/IEC 17839. If so, it may not be feasible for OpenSC to ever support accessing such information.

Would you be interested in making it more explicit in the wiki that newer DNIe versions are thought to be mostly backwards compatible from OpenSC's perspective, and that no significant functionality is thought to be missing either?

On a side note, I found vsmartcard's Remote Smart Card Reader very promising and, aside from OpenSC currently lacking support for the NFC interface of DNIe 3.0 (the emulated ATR of my card's NFC interface is 3B 88 80 01 E1 F3 5E 11 77 81 E1 10 53, and bypassing the DNIe type checks in dnie-tool didn't make it work either), I found it to be a higher-quality solution for Linux than the official DNIeRemote app (in fact, I even had to decompile and patch the latter to work around a null pointer dereference in its PKCS#11 C_Initialize implementation when passed a null parameter, which as far as I can tell is valid according to the the PKCS#11 v2.x specifications the module targets...). Because of that, I've considered contributing DNIe 3.0 NFC interface support to OpenSC instead, and started by documenting some of my initial findings here. I'm curious whether there are any useful pointers for that effort beyond reading the relevant standards, making educated guesses based on similar NFC cards, and having plenty of free time and patience. 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants