Andre Henriques
a2ca86c82e
All checks were successful
continuous-integration/drone/push Build is passing
116 lines
5.9 KiB
TeX
116 lines
5.9 KiB
TeX
%%% Preamble
|
|
\documentclass[11pt, a4paper]{article}
|
|
|
|
\usepackage[english]{babel} % English language/hyphenation
|
|
\usepackage{url}
|
|
\usepackage{tabularx}
|
|
\usepackage{pdfpages}
|
|
\usepackage{float}
|
|
\usepackage{amsmath, amssymb}
|
|
\usepackage{systeme}
|
|
|
|
\usepackage{graphicx}
|
|
\graphicspath{ {../images for report/} }
|
|
\usepackage[margin=2cm]{geometry}
|
|
|
|
\usepackage{hyperref}
|
|
\hypersetup{
|
|
colorlinks,
|
|
citecolor=black,
|
|
filecolor=black,
|
|
linkcolor=black,
|
|
urlcolor=black
|
|
}
|
|
|
|
\usepackage{cleveref}
|
|
|
|
%%% Custom headers/footers (fancyhdr package)
|
|
\usepackage{fancyhdr}
|
|
\pagestyle{fancyplain}
|
|
\fancyhead{} % No page header
|
|
\fancyfoot[L]{} % Empty
|
|
\fancyfoot[C]{\thepage} % Pagenumbering
|
|
\fancyfoot[R]{} % Empty
|
|
\renewcommand{\headrulewidth}{0pt} % Remove header underlines
|
|
\renewcommand{\footrulewidth}{0pt} % Remove footer underlines
|
|
\setlength{\headheight}{13.6pt}
|
|
|
|
% numeric
|
|
\usepackage[style=ieee,sorting=none,backend=biber]{biblatex}
|
|
\addbibresource{../main.bib}
|
|
|
|
% Write the approved title of your dissertation
|
|
\title{Automated image classification with expandable models}
|
|
|
|
% Write your full name, as in University records
|
|
\author{Andre Henriques, 6644818}
|
|
|
|
\date{}
|
|
|
|
%%% Begin document
|
|
\begin{document}
|
|
\section*{1}
|
|
\subsection*{1.1}
|
|
The file ag01598\_6644818\_1\_1.spdl contains the base model of $\text{protocol}\Pi$.
|
|
|
|
I choose the names of the roles based on their functions since it would make the file more readable so R is Phone, S is Application, N is Network.
|
|
|
|
As the diagram shows the first message is sent from the phone do the network to request the generation of a new session key.
|
|
|
|
The keys where modeled using a custom usertype called ``SessionKey'' and the time to live has modeled using a custom usertype called ``Timestamp''
|
|
|
|
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.
|
|
|
|
\subsection*{1.2}
|
|
The file ag01598\_6644818\_1\_2.spdl contains the base model of $\text{protocol}\Pi$ and the claims.
|
|
|
|
I added non-injective synchronization(nisynch) to the Phone and Network, at least, some roles communicated as described by the protocol.
|
|
I added a secret claim to SesK (Session key) to all roles, as the session key should be private.
|
|
Furthermore, I added Commit and Running claims between some roles to check for agreement between some variables:
|
|
\begin{itemize}
|
|
\item{Agreement between Phone and Network over the time to live and the session key}
|
|
\item{Agreement between Application and Network over the time to live and the session key}
|
|
\item{Agreement between Application and Phone over the message and the message m}
|
|
\end{itemize}
|
|
|
|
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.
|
|
|
|
\subsection*{1.3}
|
|
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.
|
|
|
|
\subsection*{1.4}
|
|
|
|
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.
|
|
|
|
\end{document}
|
|
|
|
|