Saturday, September 19. 2020
New DNIe cards need different data for the secure channel
Sometimes I think that the DNIe situation is just recurring, I feel like Bill Murray in the film Groundhog Day. During the last years the Spanish electronic ID (DNIe) has been working good inside the OpenSC project (since the DNIe v3.0 was integrated around 2017). I personally had not received any report of problems with it. But it happens that my personal card expired in august (the previous renewal was because the chip stopped working and the expiration date was not extended that time). I went to the police station and, after coming back home, my fresh new smartcard was not working with OpenSC. Again. The worst thing was that the official RPM package for linux distributed by the government failed with my card too.
Looking into the issue inside the OpenSC code, the initial problem was that a certificate that is used to establish the secure channel (secure communication with the card, similar to what https is to http) failed when it was validated. The certificate for the intermediate CA is placed in the card itself and, in order to validate that the certificate was not altered, it is verified against a public key (the public key of the CA that is issuing those certificates for the Spanish ID cards). That key (among other things needed for the secure channel like some certificates, other public and private keys, key references inside the card,...) is just hardcoded inside the code. Therefore that verification failure only meant that the Spanish Police Department (DGP) had changed that CA. The first thing I tried was just commenting that verification, but the secure channel creation failed in a later step. So it was crystal clear that all the CA structure that is needed for the secure channel had been replaced. I searched over the internet for the data. Previously that information was published by the Spanish institutions inside the sources of some public projects, like for example jmulticard or inside the FNMT MultiPKCS11 sources (code for the official PKCS11 package, the zip file can be downloaded at the end of page). But nothing, I found absolutely nothing, only the previous data was there, the one that now failed with my new card.
The official code stores the configuration in ASN.1 format inside a fixed global byte array variable. So doing some readelf/objdump magic over the binary library I got the full bytes and started a slow and manual parsing. I detected that there were two configurations there. I was very skeptical about this, in the end the official package was not working for me either, but why were there two configurations? I continued parsing the ASN.1 and obtained the modulus for the public key whose verification was failing from both confs. One was the same value used in the current OpenSC code but the other key was a different array. So I backed up the certificate from the card (the one being validated) and created a simple program to verify it with the new key found in the second configuration. And surprisingly it worked. It was the valid public key whose private counterpart signed the intermediate CA certificate in the card. That convinced me to finish the whole parsing and replace all the data for the secure channel creation with this new one. In two days I could finish the task and OpenSC was working again with my new DNIe. At least changing the data to establish the secure channel was enough, no more changes were needed.
More or less at that point I was notified that there were some issues reported in the OpenSC project about new DNIe cards not working. The main one is the issue 2105 and I started to share what I had at that moment. The final conclusion is that if you have a DNI with IDESP equals or greater than BMP100001 the new CA structure is used and current OpenSC does not work with it. The command dnie-tool -i displays the IDESP information for your card. A PR was sent to the project to manage both configurations (the old data should be maintained for previous cards) and it seems to be working for testers. Let's see if the maintainers accept it promptly.
In summary, if you have a new DNIe card and you want to use OpenSC to access with it some governmental sites, it will not work for you. The situation is the same with the official package. Only windows distribution seems to be working at this moment. If you are in a hurry you can try out the PR and compile it by yourself. As a personal comment I am going to say that maintaining the DNIe inside OpenSC this way is really complicated. The DGP (Spanish institution in charge of the DNIe) continues doing the things in linux utterly in the wrong direction. This time I was lucky and, first, I renewed my DNIe at the perfect time to discover the issue and, second, finding the new data in the binary distribution was just a long shot. In a normal situation this would have meant waiting for the publication of the new data (direct DPG announcement or some code added to the previously mentioned projects) and trying to fix it without a new card, waiting for the community for the testing. As always, remember that I am not related at all with the DGP or the FNMT. I am just a frustrated linux user who needed to use the DNIe some time ago. And I am starting to be really tired with all this.
Regards!
Comments