The Network then aswers to the Phone and the Application the keys and the time to live and the hashed value of that using a hash function named ``Mac''.
The Phone and the Application verify the Mac and then the phone sends a nonce to the phone and the phone answers back with a new nonce and the original nonce.
The Mac was modeled as a hashing function then encryption this was done this way because scyther does not have a way of creating a mac function with keys so the hashing is done first followed by the encrypted so that an attacker can not modify it.
There are 9 overall claims, where only three do not fail. The secrecy of SesK from the perspective of the Network. And agreement over the SesK and the time to live between the Phone and the Network, and the Application and the Network.
The file ag01598\_6644818\_1\_3.spdl contains the fixed version of $\text{protocol}\Pi$
The first change was to require the refresh keys request was to require the application to send a nounce, this nonce is then sent back to application to verify that the key was generated, was requested to the application and not by the attacker.
The second change was to make the network send the identity of the other party to party that is reciving the message. i.e. Sending the identity of the Phone to the Application encrypted with the key Network,Application. This is done to guarantee that the Party reciving the communication is using a key that was intended for this communication.
The original $\text{protocol}\Pi$ is not an apropiate solution of the the third party problem as it can not guarantee the secresy of the session key, and since an attacker can obtain the session key, $\text{protocol}\Pi$ is not an appropiate solution to the present problem.As scyther showed the are attacks in the Dolev-Yao model. There are also some attacks in outside of Dolev-Yao model.
For example:
With the assumptions that:
\begin{itemize}
\item{Dolev-Yao attacker.}
\item{Strong cryptographic primitives}
\item{The time to live is implemented as a counter not an endate timetamp.}
\item{One of the previous keys where the encrypted version of the key and timestamp were recorded and leaked.}
\end{itemize}
In this senario an attacker can record the messages where the key and the time to live were encrypted. Then when the key gets leaked, the attacker can perform a replay attack.
The attacker resends the previously recorded keys to the application server and the phone, because the time to live is based on a counter and not on a timestamp the phone and the server accept the ``new'' key, and since the attacker already knows this key the protocol failed at guarantee, the secrecy of the session key.
% Other possible attacks are possible, for example a senario where the time to live is large, and the cryptographic primitives are weak for that time frame, i.e. RSA with 100 decimal digits and time to live of 2 days, an attacter with enought computer power would be abble to obtain the key
But it can be improved, as we saw in the answers for the question 1.3 by modifing the protocol slightly we can achive secrecy of the session key in the dolev-yao model. Although it does not resolve issues related with the time to live if the protocol was implemented with counters for time to live instead of timestamp.
The file ag01598\_6644818\_1\_5.spdl contains the a more comunication efficient version of the $\text{protocol}\Pi$
This version trades off computational power for communication efficiency. This version creates bigger encrypted messages and as trade off reduces the number of messages that are sent.
The message that is removed is the message where the network sends the key to the phone. This data in this message is still send but it's send when the application sends the m message.
And the data is sent to the Application inside the encrypted packed that is already sent to the Application when the phone recives the keys from the network.
It sends the session key that was send by the network, to the phone, with the message m.
\section*{2}
\subsection*{2.1}
Using a system like gpg you can generate keys by running the command \begin{verbatim}gpg --gen-key\end{verbatim}.
The public key are then traded.
\subsection*{2.2}
There are multiple ways of securily exaging the keys.
For example if meeting up in person was a possiblity the keys cloud be put onto usb drives and the drives exchanged in person. And this would guarantee 100\% authentication, but meeting in person could not be feasable.
If meeting in person is not feasable an altertive method would be sending the public key via email, and then calling the collegue on the phone. Both parties would then hash key using for example \begin{verbatim}sha512sum key\end{verbatim} and both parties would readout their public keys hash to each other. Since the parties know eachother, and would recoginze the voice this would be a feazable way to exchange the public keys. With this they could verify that the password came from the correct person.
\subsection*{2.3}
Assuming that the peers were able to exchange public keys.
One of the Peer A would generate a random 256 bit key.
Peer A would then encrypt the key using Peer B's public key, and sign it using it's own private key.
Peer A would then send the signed and encrypted semetric key to Peer B in an insecure channel.
Peer B upon reciving the encrypted and signed semetric key, would verify the signature, and decrypt the message and obtain the key.
After this both A and B can comunicate using the semetric key.
A secure communication channel for the purpoposes of this answer is a communication channel that can maitain the secrecy, and integtaty.
A communication channel can be achived by trading 2 semetric keys.
One of the keys would be used to encrypt the messages and the other would be used to MAC the messages this would gurantee that the messages are secret because of the encryption and that they have integraty because of the MAC.
The 2 diferent keys guarantee that the MAC that is generated is significanfly diferent than the encrypted message.
In this system messages should also contain the timestamp of when the messages was send this is usefull to maintain freshness.
\subsection*{2.5}
The system would work under a computational system as the cryptographic primitives that were selected are computationaly hard to break.
The system would also work with a man in the midle attacker as the attacker can not change the messages witout one of the people feeling suspicios and calling for a restart of the system.
This system would not work if the method for exachaging keys was via phone, and the attacker had a method of replicating the voice of one of the participants of the system i.e. using an AI.
%The system can maintain integratity, in the public key exachange phase with the phone call and the hash, in the semetric key exahange phase with the signatures, and in the message exchange phase with the MACs.
%The system can maintain secrecy throughout the entire process by using strong cryptographic functions, and having all messages that are send that contain sentive information encrypted.
%The system can
\subsection*{2.6}
An altertive solution to the problem is if both parties have a third party that they both know and trust. This system would have less comunication and computaional overhead as the public key exchange could have been skiped and the the semetric key could have been exchanged from the begging.
This solution would have a less level of security as the system relies on the trust of a third party, this includes more levels of failures as the third party could get currupted makeing the system less secure.
