Ricky's Hodgepodge

I was advised by Albert Mestre, with a comment in one of my previous entries, that the DNIe is not working for the last version of chrome. I usually do not use that browser so I was not aware of it (last time I checked it worked, but previously I had a debian box and the chromium browser was an old version). This weekend I spent some time trying to know what was happening.

First I installed the library like I explained in a previous entry and (at command level) it is working ok. The module is in place and the certificates can be read.

• The module is installed in the database:

  modutil -dbdir sql:.pki/nssdb/ -list
  
  Listing of PKCS #11 Modules
  -----------------------------------------------------------
    1. NSS Internal PKCS #11 Module
  	 slots: 2 slots attached
  	status: loaded
  
  	 slot: NSS Internal Cryptographic Services
  	token: NSS Generic Crypto Services
  
  	 slot: NSS User Private Key and Certificate Services
  	token: NSS Certificate DB
  
    2. opensc
  	library name: /home/rmartinc/apps/opensc/lib/opensc-pkcs11.so
  	 slots: 1 slot attached
  	status: loaded
  
  	 slot: Gemalto PC Twin Reader 00 00
  	token: PIN1 (DNI electrónico)
  -----------------------------------------------------------
  

• The certificates can be listed:

  certutil -d sql:$HOME/.pki/nssdb -L -h "PIN1 (DNI electrónico)"
  
  Certificate Nickname                                         Trust Attributes
                                                               SSL,S/MIME,JAR/XPI
  
  Enter Password or Pin for "PIN1 (DNI electrónico)":
  PIN1 (DNI electrónico):CertAutenticacion                    u,u,u
  PIN1 (DNI electrónico):CertCAIntermediaDGP                  ,,   
  PIN1 (DNI electrónico):CertFirmaDigital                     u,u,u
  

• And any of them (for example the authentication one) can be parsed:

  certutil -d sql:$HOME/.pki/nssdb -L -h "PIN1 (DNI electrónico)" -n "PIN1 (DNI electrónico):CertAutenticacion"
  Enter Password or Pin for "PIN1 (DNI electrónico)":
  Certificate:
      Data:
          Version: 3 (0x2)
          Serial Number:
              XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
          Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
          Issuer: "CN=AC DNIE 001,OU=DNIE,O=DIRECCION GENERAL DE LA POLICIA,C=ES"
          Validity:
              Not Before: Mon Oct 10 06:58:43 2016
              Not After : Wed Aug 19 22:00:00 2020
          ...
  

So, in general, the library is working at command level. But when you start the browser and try to use the card a coredump is generated. The trace is something like this:

(gdb) bt
#0  0x00007f794760dda9 in BN_num_bits () at /usr/lib64/chromium-browser/./libboringssl.so
#1  0x00007f794760dde9 in BN_num_bytes () at /usr/lib64/chromium-browser/./libboringssl.so
#2  0x00007f794765480d in rsa_default_size () at /usr/lib64/chromium-browser/./libboringssl.so
#3  0x00007f7947652605 in RSA_size () at /usr/lib64/chromium-browser/./libboringssl.so
#4  0x00007f79476401cf in pkey_rsa_verify () at /usr/lib64/chromium-browser/./libboringssl.so
#5  0x00007f794763d012 in EVP_DigestVerifyFinal () at /usr/lib64/chromium-browser/./libboringssl.so
#6  0x00007f7947659d45 in ASN1_item_verify () at /usr/lib64/chromium-browser/./libboringssl.so
#7  0x00007f78f670b02b in cwa_verify_icc_certificates (icc_cert=0x1b5a5b4e40f0, sub_ca_cert=0x1b5a5b605a50, provider=
    0x1b5a5a3cac40, card=0x1b5a5a213000) at cwa14890.c:354
#8  0x00007f78f670b02b in cwa_create_secure_channel (card=card@entry=0x1b5a5a213000, provider=0x1b5a5a3cac40, flag=flag@entry=1)
    at cwa14890.c:1114
#9  0x00007f78f6709bb3 in dnie_pin_verify (card=card@entry=0x1b5a5a213000, data=data@entry=0x7f791560b2f0, tries_left=tries_left@entry=0x1b5a5a8368e4) at card-dnie.c:2181
...

It seems that chrome has forked the openssl and now they have their own implementation called boringssl. And it crashes with the DNIe. In some part of the implementation the driver checks that the certificates returned by the card are valid and it uses openssl API for that (method X509_verify). As chrome loads its own libraries the pkcs#11 also has to use them and everything finishes in big core dump. I tried to pre-load the openssl libraries but then it is the chromium itself the one that does not work. So openssl and boringssl seem to be incompatible. The same day I decided to re-test the module against openssl and libressl (another fork done by the BSD guys) and the DNIe works well with both of them.

I am not going to spend more time on this. It seems that something weird happens with the boringssl implementation (besides the problem appears just checking the validity of the intermediate CA certificate, which is read from the card). My tests were done with the chromium 57 that comes with fedora 25, Albert reported the issue with version 58. I do not like that google decided to use its own implementation of such an important library if they are going to make them incompatible. In summary, for the moment DNIe driver for OpenSC is not working with chrome (and I do not think the situation is going to change for the moment). I do not know if other OpenSC drivers (several of them uses openssl) are also affected.

Sorry for the bad news!

EDIT: It works in my old debian laptop with chromium 57 and 58 (after updating to last current package). Debian decided to link boringssl statically and then the issue is avoided. So I think is more a bug in fedora than a general problem. But if you see that the boringssl so file is in your system you have to worry. At the end it is not a very big problem, I am going to change the title.

The previous week I was working with CRLs files and a very big PEM CRL bundle was taking several minutes to being parsed using Java. The complete file was several megabytes in size but the fact did not justify such a long time. A Certificate Revocation List (CRL) is a bunch of certificates issued by a Certificate Authority (CA) that have been revoked (the certificate is not valid anymore). Usually a CRL is kilobytes in size, when a revoked certificate expires it is usually removed from the CRL (it is invalid anyway), and this practice makes the CRL size be moderate. The revocation info is just the certificate serial number and the date, so thousand and thousands of them are needed to have such a big file.

Looking at the code the method to parse the CRLs is generateCRLs. In my case the file was a list of PEM encoded CRLs (PEM is base64 DER format and enclosed between a header -----BEGIN X509 CRL----- and a footer -----END X509 CRL-----, DER format is a binary format using ASN1). The X509Certificate implementation accepted both formats (DER and PEM) but it seems to do something very weird to deal with the PEM format (you can see the code in OpenJDK). The DER format is read directly, but PEM is first moved into a memory buffer, the base64 data is decoded and the resulting DER is parsed. The buffer is initially 2KB in size and it grows by chunks of 1K (the Arrays.copyOf method is used, so a new array is allocated and the data copied again and again). This is not a bad idea if the CRL is several kylobytes in size but, if it has several megas, the process is extremely slow.

Obviously our decision was transforming our CRL file from PEM to DER format. The load took just a few seconds instead of the several minutes it was taking before. Nevertheless I spent some time trying to improve the performance of the java method. Now java8 has standard Base64 encoder and decoder and, more important, it has a method to directly read from an InputStream. This way the extra buffer can be avoided and it always read from the file directly. I tried my idea and it works. I opened a bug against the java bug database and it is public now. My patch is there if you need it.

With the modification an enormous CRL file of 30MB (around one million revocations) gives the following times:

• DER: 2 seconds.
• PEM (patched): 14 seconds
• PEM (before): 379 seconds

So, the DER file is always faster (there is no Base64 decoding) but, at least, now the PEM process time is in the same scale. If you need to manage CRLs files in java, please, never use the PEM format, always manage DER native format. I do not know if my patch will be finally included but, it does not matter, it just improves the situation, DER will always be faster and with a smaller footprint.

Regards!

I have moved to another job again (I know, I can not stand still) and in my new company the old IRC is used. Besides all the people inform their status changing their nicks (for example if you go to lunch, your nick username would be modified to username|lunch or something similar). I have to say that it is a mess but... When in Rome do as the Romans do. Pidgin is my favorite program for chatting. It is a very mature program and it saved my ass once in the past so I configured it to join to the different rooms I have to be present. Some plugins were indeed interesting and I also configured them to make my job easier. Nevertheless I did not find anyone to change my nick when I change my general pidgin status.

The ircaway plugin does a similar job, it changes your nick to usernameAway when the IRC status is changed to away. Indeed it would have been enough, but it is not exactly what I wanted. I had defined several statuses in pidgin (for example cofee, lunch, brb, afk, meeting,...) and, when my status is changed to one of them, my nick should be changed accordingly. Looking to some plugins source code it should not be very difficult, so I started to develop one and here it is the result: ircstatus.

The plugin does exactly what I want:

1. It should be configured with one IRC account (I thought in configuring more than one but I changed my mind, it is not necessary). That account is the one that will receive the nick changes. You can also configure the separator string (by default is "|" but you can configure another one, "_" for example).

   

2. The plugin listens for status changes (signal savedstatus-changed) and performs the change of the nick in the IRC account specified in the preferences. Obviously the plugin checks that the IRC account exists and is connected. The new nick is constructed by the concatenation of the initial username, the separator and the title of the status. The title is sanitized (non-alphanumeric characters are replaced by an underscore "_").

And that is all. The plugin is very simple but it works exactly like I want. Besides I can combine it with another plugin away-on-lock which changes automatically your status if the screen-saver is activated. This way my nick is always modified even when I forget to change my status manually, which is quite often because of my bad memory (away-on-lock changes the status to one of the away status, you can configure which one, and in turn my ircstatus changes the nick accordingly). I suppose that such a bothering plugin will not be needed by a lot of people, but you can clone or download it from my github anyway.

Cherio!