Finished Computer Security
All checks were successful
continuous-integration/drone/push Build is passing
All checks were successful
continuous-integration/drone/push Build is passing
This commit is contained in:
parent
f798fd98a2
commit
b01f672c15
@ -65,6 +65,8 @@
|
|||||||
|
|
||||||
The Mac was modelled 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 cannot modify it.
|
The Mac was modelled 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 cannot modify it.
|
||||||
|
|
||||||
|
Scyther does not have a way to model the refresh/time to live parts, so that was not modelled.
|
||||||
|
|
||||||
\subsection*{1.2}
|
\subsection*{1.2}
|
||||||
The file ag01598\_6644818\_1\_2.spdl contains the base model of $\text{protocol}\Pi$ and the claims.
|
The file ag01598\_6644818\_1\_2.spdl contains the base model of $\text{protocol}\Pi$ and the claims.
|
||||||
|
|
||||||
@ -77,6 +79,8 @@
|
|||||||
\item{Agreement between Application and Phone over the message and the message m}
|
\item{Agreement between Application and Phone over the message and the message m}
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
|
These claims were chosen because they check agreement on message m between the Application Function and the Phone; The secrecy of SesK; And the synchronization and agreement between the Application Function, Phone, and Network.
|
||||||
|
|
||||||
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.
|
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 protocol as it stands does not guarantee secrecy and agreement.
|
The protocol as it stands does not guarantee secrecy and agreement.
|
||||||
@ -90,7 +94,7 @@
|
|||||||
|
|
||||||
\subsection*{1.4}
|
\subsection*{1.4}
|
||||||
|
|
||||||
The original $\text{protocol}\Pi$ is not an appropriate solution to the third-party problem as it cannot guarantee the secrecy of the session key, and since an attacker can obtain the session key, $\text{protocol}\Pi$ is not an appropriate solution to the present problem. As Scyther, showed that there are attacks on the Dolev-Yao model. There are also some attacks outside the Dolev-Yao model.
|
The original $\text{protocol}\Pi$ is not an appropriate solution to the third-party problem as it cannot guarantee the secrecy of the session key, and since an attacker can obtain the session key, $\text{protocol}\Pi$ is not an appropriate solution to the presented problem. As Scyther, showed that there are attacks on the Dolev-Yao model. There are also some attacks outside the Dolev-Yao model.
|
||||||
|
|
||||||
For example:
|
For example:
|
||||||
|
|
||||||
@ -125,13 +129,11 @@
|
|||||||
\subsection*{2.1}
|
\subsection*{2.1}
|
||||||
Using a system like GPG, you can generate keys by running the command \begin{verbatim}gpg --gen-key\end{verbatim}.
|
Using a system like GPG, you can generate keys by running the command \begin{verbatim}gpg --gen-key\end{verbatim}.
|
||||||
|
|
||||||
The public keys are then traded.
|
|
||||||
|
|
||||||
\subsection*{2.2}
|
\subsection*{2.2}
|
||||||
There are multiple ways of securely exchanging the keys.
|
There are multiple ways of securely exchanging the keys.
|
||||||
For example, if meeting in person was a possibility, 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 feasible.
|
For example, if meeting in person was a possibility, 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 feasible.
|
||||||
|
|
||||||
If meeting in person is not feasible, an alterative method would be sending the public key via email, and then calling the colleague on the phone. Both parties would then hash key using for example \begin{verbatim}sha512sum key\end{verbatim} and both parties would read out their public keys hash to each other. Since the parties know each other, and would recognize the voice, this would be a feasible way to exchange the public keys. With this, they could verify that the password came from the correct person.
|
If meeting in person is not feasible, an alterative method would be sending the public key via email, and then calling the colleague on the phone. Both parties would then hash key using for example \begin{verbatim}sha512sum key\end{verbatim} and both parties would read out their public keys hash to each other. Since the parties know each other, and would recognize the voice, this would be a feasible way to exchange the public keys. With this, they could verify that the key came from the correct person.
|
||||||
|
|
||||||
\subsection*{2.3}
|
\subsection*{2.3}
|
||||||
|
|
||||||
@ -189,7 +191,7 @@
|
|||||||
|
|
||||||
The 2 different keys guarantee that the MAC that is generated is significantly different from the encrypted message.
|
The 2 different keys guarantee that the MAC that is generated is significantly different from the encrypted message.
|
||||||
|
|
||||||
In this system, messages should also contain the timestamp of when the messages were sent. This is useful to maintain freshness.
|
In this system, messages should also contain the timestamp of when the messages were sent. This is useful to maintain freshness, it's also useful to provide different messages every time.
|
||||||
|
|
||||||
\subsection*{2.5}
|
\subsection*{2.5}
|
||||||
|
|
||||||
@ -199,11 +201,9 @@
|
|||||||
|
|
||||||
This system would not work if the method for exchanging 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.
|
This system would not work if the method for exchanging 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 integrality, in the public key exchange phase with the phone call and the hash, in the symmetric key exchange phase with the signatures, and in the message exchange phase with the MAC.
|
||||||
|
|
||||||
%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 maintain secrecy throughout the entire process by using strong cryptographic functions, and having all messages that are sent that contain sensitive information encrypted.
|
||||||
|
|
||||||
%The system can
|
|
||||||
|
|
||||||
\subsection*{2.6}
|
\subsection*{2.6}
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user