You find two session key establishment protocols below. Your task is to analyze these protocols, to find as many attacks against them as you can, and then to fix the protocols such that attacks are eliminated! Both protocols can be attacked in more than one ways. Identifying weaknesses without finding a specific attack is also a valuable contribution. When fixing the protocols, you may consider the protocol design principles that we have learned. Even if you don't find all possible attacks, applying the principles correctly should eliminate both the discovered and the undiscovered attacks. It may be useful to read the recommended readings.
You should hand in a short (4-5 pages) write-up that contains the description of the attacks you found, and the description of the fixed protocols! Please, send the write-ups in PDF format to the e-mail address: buttyan@crysys.hu
Deadline: March 18, 2016.
Consider the following key establishment protocol:
| A → B: | A |
| B → A: | N |
| A → B: | E_Kas(N|K) |
| B → S: | E_Kbs(A|E_Kas(N|K)) |
| S → B: | E_Kbs(N|K) |
Notations:
A and B are the two main parties of the protocol
S is a trusted server
N is a nonce generated by B
K is a new session key generated by A
Kas and Kbs are long-term keys shared between A and S, and between B and S, resp.
E_K(.) denotes encryption with key K
| denotes concatenation.
The goal of the protocol is to setup a new shared session key between A and B. Party A generates the key and the protocol uses the already existing long-term keys between the parties and the server to transfer the key securely from A to B via the server S. Freshness of the key for B is ensured by using a nonce N, which is generated by B, sent to A, and received back later by B. Freshness of the key for A is trivially ensured by the fact that A generates the key.
In details, the protocol works as follows: A starts the protocol by identifying herself to B. B generates a new nonce N and sends it to A. A generates a new key K, and sends it together with the nonce N to B encrypted with key Kas. B cannot decrypt this message. He encrypts it with Kbs and sends the result to the server. The server decrypts everything, checks that the identifiers match the long-term keys used for decryption, and then encrypts the key and the nonce with B's long-term key. B can now decrypt this message, check the fresness by verifying the nonce, and accepts the key K.
Consider the following key establishment protocol:
| A → B: | A|Na |
| B → S: | B|Nb|E_Kbs(A|Na) |
| S → A: | Nb|E_Kas(B|K|Na)|E_Kbs(A|K|Nb) |
| A → B: | E_Kbs(A|K|Nb)|E_K(Nb) |
Notations:
A and B are the two main protocol participants
S is a trusted server
Na és Nb are nonces generated by A and B, resp.
K is a new session key for A and B generated by S
Kas and Kbs are elong-term keys shared between A and S, and between B and S, resp.
E_K(.) denotes encryption with key K
| denotes concatenation.
The goal of the protocol is to establish a new shared session key between A and B. The session key K is generated by S and sent to A and B. The session key K is protected during transit by encryption with keys Kas (for A) and Kbs (for B). Freshness of the session key K is provided by nonces Na and Nb generated by A and B, respectively. Encrypted messages that carry the session key also contain the ID of the protocol parties explicitly.
In more details, the protocol works as follows: Party A starts the protocol by generating a new nonce Na and sending her ID A and nonce Na to B. Party B generates his own nonce Nb, and sends his ID B and nonce Nb together with A's ID and nonce encrypted with Kbs to S. Server S knows from the cleartext ID of B that it should decrypt the message with Kbs. After decryption, it learns that the other party is A and her nonce is Na. Then, S generates the session key K, and encrypts it together with Na and ID B with Kas for party A, and with Nb and ID A with Kbs for party B. Thus, when receiving this encrpytion, each party can decrypt and verify if he/she received back his/her nonce and the ID of the other party in the message matches the ID of the other party in the protocol. After successful verification, the parties accept the key K. In addition, A receives Nb from S, and she uses the session key K to encrypt Nb in order to confirm knowledge of K to B.