Understanding the DNIe, Part II : Secure Messaging
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.
Confidentiality
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
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.
Next steps
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.
April 15th, 2010 - 10:38
But… I have a conceptual doubt about all this: What is the purpose of encripting and authenticating the communication between a device conected to your computer and your computer? All this is to protect the cable between the reader and the card?
Is this stupid, or are there any possible attack that I have not taken into account??
April 15th, 2010 - 19:57
Hi Alvaro,
Yes, it’s true that you are authenticating a connection between your computer and a device connected to it. In this case I guess the main point for it is the authentication, specially protection against replaying messages.
Also, keep in mind that these devices can be used to sign stuff on other places such as the terminals provided in police stations and potentially other places. Imagine someone introducing a skimming device there and logging the communications at the APDU level.
Now, imagine everything goes in clear and without authentication. The skimmer could record the PIN for the card and later on steal this card if he’s able to trace you (and maybe he was even able to get your address from the ID in the clear!).
Of course you don’t want that, because it enables identity fraud in a quite “easy” way. If you encrypt and protect integrity, together with the sequence counter, you get that:
a) It’s not possible to record your PIN
b) It’s not possible to record APDUs in transit and replay them later bypassing authentication
So obviously when the card is being used on your computer it doesn’t provide too much security since malware could always hook the encryption routines and the secure channel establishment routines to get the clear data. But when you use it somewhere else, where attackers could have tampered with the readers, you want to avoid transmitting in the clear and allowing message replays.
Hope this clarifies it a little 🙂
April 16th, 2010 - 09:25
Ok, I had not thought about public machines. Perhaps because I never would put my DNIe there… An attacker could still replace the whole machine 🙂
In that case, anyway, the protection against message replay attacks seems reasonable.