Let's go a little further in our way to understand the way the DNIe works. In my previous post I talked about the device authentication procedure and today I'll talk about what happens next, how Secure Messaging protects all the subsequent communication.
By the way, I updated the previous post with information on how to get the card's serial number.
Device authentication, quick reminder
As I said in the previous blog, the device authentication phase consists of the following steps:
- Certificate exchange: The terminal (IFD) requests a X.509 certificate from the card and sends its own certificate and an intermediate CA's certificate to the card
- Internal authenticate: The IFD sends a random challenge to the card and requests it to authenticate itself. This is done with an RSA signature, which is then encrypted for the IFD, and includes a 32 byte random number known as Kicc.
- External authenticate: The terminal authenticates itself, requesting a challenge from the card and sending a signed and encrypted message to the card. Again, this message includes a 32 byte random number known as Kifd.
- Key generation: both ends generate a key for encryption and a key for authentication. This is done by XORing first the two random numbers, and computing then the SHA-1 hash of the result with a constant 1 appended for the encryption key and a constant 2 for the authentication (MAC) key.
So basically at the end of this process, both ends share a pair of keys that can be used for protecting the confidentiality and the integrity of subsequent messages.
Let's see how this is done.
3DES in CBC mode is used for confidentiality of the messages. When the data needs to be encrypted, the message is first padded with a 0x80 byte and as many zero bytes as needed to have a complete number of blocks (i.e. a message length multiple of 8 bytes).
Then 3DES in CBC mode with a null initialization vector is used to encrypt the data. After this, the message is inserted in what is called a Data Object in the ISO 7816-4 standard. Concretely, the cryptogram DO used in the E-SIGN specs has a tag equal to 0x87. DOs are a TLV structure, which means they have a Tag identifying the kind of information they carry, a Length byte indicating how many bytes of content they carry, and a Value field with the indicated number of bytes.
In this case, DO 0x87 carries the a Padding Indicator (PI) equal to 0x01 (this indicates the padding described above, starting with 0x80 and continuing with bytes set to 0x00) followed by the cryptogram.
Authentication of messages is performed using a MAC based on the DES/3DES algorithm. After encrypting the required content, a MAC is computed over the APDU (or TPDU) header and the Data field. It should be noted that the Data field may contain not only DO 0x87 but also other DOs including plain text information, status word information in the case of response APDUs and others.
Before computing any MAC, the Send Sequence Counter is created by concatenating the 4 least significant bytes of RND.ICC and the 4 least significant bytes of RND.IFD. These are the 8 byte challenges created during the authentication process as explained above and in the previous post.
This SSC is used as an initialization vector for the MAC computation, which encrypts the data to be authenticated using DES in CBC mode, except for the last block which is encrypted using 3DES. The output of this last encryption is then used as the MAC. As before, the message is padded with a 0x80 byte and as many zero bytes as needed before applying the encryption process.
Actually, only the 4 most significant bytes of this value are included in the message and they are included in a DO 0x8E. Again, this is a TLV structure, with tag 0x8E, length 0x04 and Value equal to those 4 most significant bytes of the computed MAC.
Finally, the SSC value is incremented for each authenticated message. Therefore, both ends should keep track of the changes to this value in order to provide authenticated messages to the other end and to verify the authentication of incoming messages.
The inclusion of the sequence counter based on the random challenges used in the authentication process allows for protecting the communication against reply attacks even within the same session.
Again, my goal is to understand how to request an electronic signature to my DNIe. Therefore, the next thing I need to do is implementing this secure messaging layer and authenticate myself to the card using my PIN code. Further, I need to send a signature request with a SHA-1 hash to be signed.
Therefore, in the coming post(s) I'll describe how this process works once Secure Messaging is set up and is used for protecting the communication.