Foreword: If you have been following the tutorial, you may have noticed that the last post was numbered 13. There are therefore 3 missing posts. Like post 13, they should be dedicated to testing techniques (building a test plan, writing tests, etc.). However, writing tests without using proprietary tools is not as easy as I naively thought, so these posts will have to wait a little. So for now, we will go for a few post about communication security.
In most smart card applications, the communication between the card and the terminal needs to be secured. Smart card developers rapidly get used to this, and securing communications becomes a reflex. Nevertheless, let’s spend a little time looking at the reasons behind this security measure.
Secure communication is an answer to a few important questions, that we will detail below.
Who am I speaking to?
When communicating, it is essential to know who we are talking to. When Alice sends a message to Bob, he wants to make sure that the message actually comes from Alice; and when Bob sends an answer, Alice wants to make sure that it comes from him.
This requirement is called mutual authentication. One of its basic implementation is based on a secret shared between the two parties who want to communicate (Alice and Bob). In order to avoid exchanging the actual secrets, most protocols are based on cryptography, and the common secret is the key that is used to cipher and decipher the message.
In practice, most protocols are based on symmetric cryptography, where the shared messages are rather short keys (usually 128-bit keys), used by well-known algorithms, like DES and AES. The idea of these protocols is to let both parties prove that they know the shared key; we will see later how this can be achieved.
Is anybody listening to our exchanges?
Another important requirement is to ensure that any communication that is intended to be secret actually is. When Alice sends a message to Bob, she wants to make sure that Eve doesn’t get the message, just because she can get the bytes that she sends to Bob.
The countermeasure is here quite simple, as it consists in encrypting the messages exchanged by Alice and Bob with their shared key, or with a key derived from this shared key.
Can our messages be modified by anybody?
Another requirement is to ensure that nobody can modify the messages during transmission. When Alice sends a message to Bob asking to transfer 1,000€ from her account to Bob’s account (1234), she wants to be sure that Charlie can’t modify the message
Am I receiving all the messages?
This requirement is quite similar to the previous one, since we can consider that the fact of removing a message is roughly equivalent to modifying a message. A typical use for this attack happens when Alice sends a list of orders to Bob. If Charlie is able to identify a message that Alice uses to warn Bob that Charlie is planning an attack, he will want to ensure that Bob never gets the message.
Here, there are two requirements. First, Bob wants to be sure that he gets all the messages, or more precisely, that he always gets the message in the order that they were sent (if the communication channel is cut, we can’t guarantee that Bob got all the messages). In order to get that guarantee, we need to make sure, for instance, that a message can only be decrypted if it is received in the appropriate order.
Then, Alice wants to be sure that Bob gets all her messages. This means that Bob needs to send some kind of receipt that will prove that he got the message.
All of these questions are often essential in smart card applications. A property that is often sought after by smart card application is non-repudiation; the idea is to ensure that somebody performing a transaction cannot deny that the transaction took place. The properties defined above are essential for non-repudiation.
- Authentication ensures that the transaction has been performed by the right person (or at least by somebody who knows the shared secret).
- Message integrity is important to ensure that the message describing the transaction cannot be modified.
- Making sure that all messages are received is also important in order to ensure that all transactions are accounted for.
These questions are also important in many other properties, in many different contexts where communication needs to satisfy some provable properties. Rather than continue with a full-blown security course, we will try in the next post to actually define a secure channel protocol, designed to protect an application’s communications.