diff --git a/Documentation/Reference Diagram 2nd iteration.graphml b/Design Files/Reference Diagram 2nd iteration.graphml
similarity index 100%
rename from Documentation/Reference Diagram 2nd iteration.graphml
rename to Design Files/Reference Diagram 2nd iteration.graphml
diff --git a/Documentation/Reference Diagram.graphml b/Design Files/Reference Diagram.graphml
similarity index 100%
rename from Documentation/Reference Diagram.graphml
rename to Design Files/Reference Diagram.graphml
diff --git a/Documentation/Initial Gantt Chart.xlsx b/Documentation/Initial Gantt Chart.xlsx
deleted file mode 100644
index 3231e38fcde8a0a31e0e74de8c5a0e9a3eb9ec06..0000000000000000000000000000000000000000
Binary files a/Documentation/Initial Gantt Chart.xlsx and /dev/null differ
diff --git a/Documentation/Table_of_Contents.pdf b/Documentation/Table_of_Contents.pdf
deleted file mode 100644
index ff17517fbe56cc6a5fdc927a3ed17df06d53540c..0000000000000000000000000000000000000000
Binary files a/Documentation/Table_of_Contents.pdf and /dev/null differ
diff --git a/Latex Files/.gitkeep b/Latex Files/.gitkeep
deleted file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..0000000000000000000000000000000000000000
diff --git a/Latex Files/Final_Report (52).pdf b/Latex Files/Final_Report (52).pdf
deleted file mode 100644
index 70e3a8f49aefffb6521637c12fdd55ae7b0c9668..0000000000000000000000000000000000000000
Binary files a/Latex Files/Final_Report (52).pdf and /dev/null differ
diff --git a/Latex Files/latex 20th.txt b/Latex Files/latex 20th.txt
deleted file mode 100644
index 02560a08c11178790ccea3de968b296633d686a2..0000000000000000000000000000000000000000
--- a/Latex Files/latex 20th.txt
+++ /dev/null
@@ -1,731 +0,0 @@
-\documentclass[twoside]{article}
-\usepackage[utf8]{inputenc}
-\usepackage{cite}
-\usepackage{graphicx}
-\usepackage[inner=24mm,outer=24mm,bottom=24mm,top=24mm]{geometry}
-\usepackage[parfill]{parskip}
-\usepackage[labelfont=bf]{caption}
-\usepackage[super]{nth}
-\usepackage{multirow}
-\usepackage{array}
-\usepackage{listings}
-\usepackage{color}
-\usepackage[acronym]{glossaries}
-\usepackage{enumitem}
-
-\definecolor{dkgreen}{rgb}{0,0.6,0}
-\definecolor{gray}{rgb}{0.5,0.5,0.5}
-\definecolor{mauve}{rgb}{0.58,0,0.82}
-
-\lstset{frame=tb,
- language=Java,
- aboveskip=3mm,
- belowskip=3mm,
- showstringspaces=false,
- columns=flexible,
- basicstyle={\small\ttfamily},
- numbers=none,
- numberstyle=\tiny\color{gray},
- keywordstyle=\color{blue},
- commentstyle=\color{dkgreen},
- stringstyle=\color{mauve},
- breaklines=true,
- breakatwhitespace=true,
- tabsize=3
-}
-\renewcommand{\arraystretch}{1.65}
-
-
-\author{Matthew Hutchings}
-\date{October 2019}
-\title{Recommending and modelling optimal security practices for smart grid connected IoT devices}
-
-\makeglossaries
-
-\newglossaryentry{Nonce}
-{
- name=Nonce,
- description={Mathematics is what mathematicians do}
-}
-
-\begin{document}
-
-\begin{centering}
-\large {
-
- Electronics and Computer Science \\
- Faculty of Physical Sciences and Engineering \\
- University of Southampton \\
- \vspace{1cm}
- \textbf{Matthew Hutchings} \\
- \nth{12} of May 2020 \\
- \vspace{2cm}
- }
-
-\noindent\rule{13cm}{0.4pt}
-
-\vspace{0.4cm}
-
-\LARGE{ \textbf{Recommending and modelling optimal security practices for smart grid connected IoT devices}}
-
-\noindent\rule{13cm}{0.4pt}
-
-\vspace{0.4cm}
-
-\large{
-\textbf{Project Supervisor:} Dr Nawfal Fadhel \\
-\textbf{\nth{2} Examiner:} Dr Xu Fang
- \vspace{1.5cm}
-
-A report submitted for the award of \\
-MCOMP Information Technology in Organisations
-
- }
-\end{centering}
-
-\newpage
-
-\newgeometry{inner=35mm,outer=24mm,bottom=24mm,top=24mm}
-
-\tableofcontents
-
-
-\newpage
-
-\textbf{Statement of Originality}
-\begin{itemize}
- \item I have read and understood the ECS Academic Integrity information and the University’s \\Academic Integrity Guidance for Students.
- \item I am aware that failure to act in accordance with the Regulations Governing Academic Integrity may lead to the imposition of penalties which, for the most serious cases, may include termination of programme.
- \item I consent to the University copying and distributing any or all of my work in any form and using third parties (who may be based outside the EU/EEA) to verify whether my work contains plagiarised material, and for quality assurance purposes.
-\end{itemize}
-
-\textbf{I have acknowledged all sources, and identified any content taken from elsewhere.}
-
-\textbf{I have not used any resources produced by anyone else.}
-
-\textbf{I did all the work myself, or with my allocated group, and have not helped anyone else.}
-
-\textbf{The material in the report is genuine, and I have included all my data/code/designs. }
-
-\textbf{I have not submitted any part of this work for another assessment.}
-
-\textbf{My work did not involve human participants, their cells or data, or animals.}
-
-
-\newpage
-
-
-\section{Project Description}
-
-
-IoT devices present many exciting applications for both industrial and consumer use. However, increased dependence on these devices opens up new consequences and attack vectors that an adversary can use to attack a target. This is of particular importance in the case of IoT devices connected to smart grid infrastructure as cyberattacks could be used to disrupt critical national infrastructure. \\
-
-The scenario for my project is a IoT based smart grid with a focus on the IoT devices in the system and their interactions with the cloud layer.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.82]{ReferenceDiagram.PNG}
- \caption{Reference diagram of my smart grid scenario}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-\newpage
-
-\subsection{Project Aims and Objectives}
-
-This project aims to produce, model and verify a collection of policies and protocols that are suitable for mitigating the threats that a IoT enabled smart grid may face. I wish to focus on the following goals within this project:
-
-\begin{itemize}
-
-\item Investigate and conduct a risk assessment on the main vulnerabilities and threats faced by IoT devices within smart grid environment.
-
-\item Recommend security policies that can mitigate these threats, justifying these policies by taking into account secondary factors including the cost to implement and any loss to productivity these policies might incur.
-
-\item Implement and verify that these communication protocols mitigate the identified vulnerabilities using Scyther, a formal method based protocol verification tool.
-
-\item Clearly explain the impact of each of my policies by comparing the possible attack vectors with and without each policy using Scyther.
-
-\item Create a purpose built, portable Scyther virtual machine environment allowing myself and others to quickly set up and start using Scyther on a new device.
-
-
-\end{itemize}
-
-
-
-\subsection{Project Scope}
-
-The scope of this project will be investigating, modelling and verifying the best policies and practices for IoT devices and their communications in my smart grid scenario. The project will focus mainly on IoT communication protocols and their configuration rather examine flaws in the hardware or firmware ran by these devices.
-
-\section{Glossary of terms}
-
-\begin{itemize}[label={}]
- \item \textbf{Nonce} A randomly generated value that is used only a single time in a cryptographic protocol. Often used as a timestamp to prevent the reuse of old message credentials.
- \item \textbf{Adversary} A term used to describe a party attempting to disrupt the security of a system.
-\end{itemize}
-
-\newpage
-
-\section{Literature Review}
-
-My literature review explores the IoT and smart grid landscape before looking into the cybersecurity issues that a smart grid implementation may face. Finally, the review discuss the verification of cryptographic protocols in the context of my scenario
-
-\subsection{Internet of Things (IoT) Devices}
-
-IoT as a general concept can be described as physical objects also being network identifiable devices that are able to communicate without the need for human interaction\cite{patel2016internet}. These devices can be used in a home or industrial context to automate processes or afford additional functionality. IoT devices can do this as they are able to leverage information by collecting/receiving it across a network. As an example of an IoT implementation in a chemical production plant, IoT monitoring devices could be used to monitor the temperature of a reaction. If the temperature fell outside of the requirement, the device could communicate with another IoT device that controls the coolant flow through the reaction and correct it without the need for any human interaction. \\
-
-These IoT networks can offer benefits for existing processes such as improved efficiency, fewer employees required to manage it and data which can be used to improve the process. However, it is important to consider from a cybersecurity perspective that the introduction of networked devices to a process opens it up to the possibility of cyberattacks.
-
-\subsection{Smart Grids}
-
-The term smart grid refers to the integration of technology into electrical grid systems allowing them to dynamically change to meet the current needs of consumers \cite{yu2011new}. Whilst the implementation of smart grids can vary significantly, several elements generally remain constant:
-
-\begin{itemize}
- \item \textbf{Smart Meters and Monitors -} These IoT devices are used to measure and analyse the energy usage within a single home. Typically smart meters simply collect energy readings from a room and send this information to the smart monitor. This monitor relays energy information to a collection server and receives information on current energy prices. \cite{kuslitskiy_2019}
-
- \item \textbf{Smart Hub -} This device allows the homeowner to track their electricity usage as well as view the current electricity price to help time their electricity usage to get the best price resulting in a better distribution of power demand across the power grid.
-
- \item \textbf{Cloud Layer -} This layer communicates with the Smart Meter to receive electricity usage information and send electricity pricing information. This information can then be used by the rest of the smart grid system to adjust the routing and production of electricity based on current demand.
-
-\end{itemize}
-
-
-
-\subsection{IoT Smart Grid, the Threats, Attitudes and Best Practices}
-
-A key finding from my research, summarised by Robles \cite{robles2009assessment} is that one of the key differences between securing a traditional system compared with a national infrastructure system, such as smart grid, is the reduction in the effectiveness of standard security measures such as patches, password management and access control. Stating that this is due to the size and diverse combination of hardware and software that comprises this class of system. Whilst traditional controls do have their place in smart grid security Sajid \cite{7445139} identifies the need for specific security measures that directly mitigate the threats smart grids face. This point is further explored by Bere \cite{bere2015initial} which states that large industrial control systems are often the target of state-funded Advanced Persistent Threat(APT) groups whose capabilities and resources far outmatch the typical threat actors a system faces. \cite{bere2015initial} Bere goes onto recommend that the security protocols and controls implemented should be layered, providing a 'defence in depth' security approach which Virvilis \cite{Virvilis2013TrustedCV} states as a key countermeasure against APT groups as these groups have the ability to execute zero-day exploits. Zero-day exploits offer very little chance of mitigating an attack against part of a system as the vulnerability is only known to the adversary at the time of execution \cite{Bilge:2012:BWK:2382196.2382284}. However, a layered system means that in the event of such an attack, the entire system will not be compromised due to the presence of other security measures and protocols.
-\\
-
-Another area of difficulty when it comes to securing these systems is the perspective and attitudes of governments and other organisations when it comes to securing these systems. Wang \cite{wang2012sscada} states that many organisations do not see investing in the protection of these systems as economically viable. Virvilis \cite{Virvilis2013TrustedCV} adds that disruption to productivity and user experience due to the increase in latency or removal of features that hardened security protocols may necessitate is another factor in the lack of implemented protocols on these systems. Mcqueen \cite{mcqueen2006quantitative} suggests that it is difficult to quantify cyber risk using traditional risk assessment methods. This may further contribute to the reluctant attitude towards cybersecurity investment as it is difficult to quantify the reduction in risk to management.\\
-
-\subsection{Verification of Security Policies and Protocols}
-
-Creamers \cite{cremers2008scyther} states that it is very difficult for humans to analyse and find flaws in cryptographic protocols, as evidenced by the number of protocols that are found to have security flaws after their release. An example of this is the Needham-Schroeder key distribution protocol which even after extensive analysis and verification by hand was found to have a security flaw which allowed an adversary to pass off an old session key as a new and valid one \cite{meadows1994formal}. Meadows \cite{meadows1994formal} goes on to suggest that formal methods are a good choice for analysing these cryptographic protocols as they are enclosed enough to make modelling and verification feasible whilst also having the potential for subtle and counter-intuitive flaws that an informal analysis may miss. \\
-
-In order to verify a protocol using automated formal methods, it must first be modelled so that it can be interpreted by a protocol verification tool. In my research, I have found two tools that are the most suitable for this purpose; Pro-Verif and Scyther. In their comparative analysis of these two tools Dalal et al. \cite{dalal2010comparative} identifies that whilst the two tools share several similarities, there are several differences that make Scyther more suitable than Pro-Verif for my scenario and skillset.
-
-\begin{itemize}
- \item \textbf{Modelling Language -} Scyther uses 'security protocol description language' (SPDL) described as "a mix between java and C" by creator Cas Creamers \cite{cremers2008scyther} to model protocols. Whereas Pro-Verif protocols are represented using horn clauses or pi calculus \cite{dalal2010comparative}. The SPDL used by Scyther is closer to pseudo-code than Pro-Verif making it more suitable for illustrating the implementation of protocols as well as being more fitting to my skillset.
-
- \item \textbf{Attack Graphs -} Scyther automatically generates attack graphs when a flaw is found in verification, generating a visual flow diagram of the attack. Pro-Verif does not support this feature.
-
-\end{itemize}
-
-Based on these factors, the project will use Scyther for the modelling and verification of protocols.
-
-
-
-\newpage
-
-\section{Research and Design}
-
-When it comes to implementing a best practice cybersecurity strategy, NIST \cite{arnold2010nist} recommends a five step process for analysing and securing smart grid systems:
-
-\begin{itemize}
- \item \textbf{1. Defining use cases -} The use cases of the system should be defined. This project defines use cases through the reference diagram.
-
- \item \textbf{2. Risk Assessment -} The vulnerabilities, threats and the impact these threats can cause should be evaluated for the system. This project performs a risk assessment through the threat model and threat descriptions.
-
- \item \textbf{3. Specification of Security Requirements -} The security requirements for the system should be stated and specified. This project specifies requirements through the list of policies that should be implemented for this scenario.
-
- \item \textbf{4. Design and Development of a Security Architecture -} A security architecture to protect the smart grid system should be designed and implemented. Taking into account the use cases and security requirements outlined in the previous steps. This project aims to design and show implementations of policies and protocols in Scyther which meet the outlined security requirements.
-
- \item \textbf{5. Assessment of implementation -} The architecture should be assessed against the defined security requirements to test if it is fit for purpose. This project will use Scyther's protocol verification tools to test the protocols against the requirements defined \cite{arnold2010nist}.
-
-\end{itemize}
-
-\newpage
-
-\subsection{Threat Model}
-
-The threat model below shows some of the attack vectors and vulnerabilities an adversary could exploit within my scenario:
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.85]{ThreatModel.PNG}
- \caption{Threat Model of my smart grid scenario}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-A detailed breakdown of each threat and how they can be mitigated through the application of security protocols can be found in the preceding sections.
-
-\newpage
-
-\subsubsection{Weak/Default Password Fuzzing Attack}
-
-OWASP \cite{owasp} states than the most common vulnerability exploited in IoT devices is the use of weak or default passwords. These attacks are usually performed by automated scripts commonly referred to as bots that scan the internet for connected devices and run a list of common passwords. As an example of this, the Mirai botnet was able to infect and recruit over 500,000 IoT devices using a list of just 60 common passwords.
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.9]{PasswordManagement.PNG}
- \caption{Adversary using a common password to compromise the network}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-In this scenario an adversary could exploit an internet connected smart hub with a weak or guessable password to recruit the device into a botnet or potentially use the compromised device as an attack vector to mount further attacks on the rest of the network.
-
-\subsubsection{Man In The Middle (MITM) Attack}
-
-Man in the middle attacks occur when an adversary is able to act as an intermediary or proxy between communication parties without their knowledge. This allows the adversary to view the contents of the messages sent between parties as well as silently modify the contents of messages.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.63]{MITM.PNG}
- \caption{Adversary relaying and modifying smart monitor data}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-An Adversary could perform a MITM attack by secretly relaying and modifying the electricity usage information sent to the data model. A large scale attack of this kind effecting many monitor to model connections could cause false data injection attack on the smart grid system where false data could cause the system to make an incorrect decision when routing power.
-
-\newpage
-
-\subsubsection{Passive Eavesdropping}
-
-Low power IoT devices commonly use weak or no cryptography in their communications protocols, this means an adversary could use devices such as a wireless packet sniffer to intercept traffic sent between devices and read the contents of the communications sent. OWASP\cite{owasp} lists these insecure protocols as the \nth{2} most common IoT vulnerability.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.55]{Eavesdropping.PNG}
- \caption{Adversary reading an insecure communication}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-This attack could occur anywhere in the scenario where devices communicate with each other without the use of an encrypted communication protocol. For example, the adversary could sniff packets between the smart meter and monitor to know if a home is occupied based on their current electricity usage or to gather information on the network for further attacks.
-
-\subsubsection{Replay Attack}
-
-Replay attacks occur when an adversary is able to identify and collect authentication credentials from a legitimate communication and use those credentials in a later communication to bypass authentication. This commonly occurs when communication partners do not make use of a unique identifier for each communication such as a session key.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.65]{Replay.PNG}
- \caption{Adversary sniffing and reusing hashed authentication credentials}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-The adversary could sniff an encrypted communication between router and server used for the transmission of energy usage data. With this they could use the hashed authenticator code to send messages to the server posing as that home network without needing to know the actual authenticator code.
-
-
-\newpage
-
-\subsubsection{Impersonation Attack}
-
-An Impersonation attack occurs when an Adversary is able to pose as the identify of a legitimate party in a communication protocol allowing them to bypass authorisation or act on the legitimate user's behalf \cite{Adams2005}. Protocols that do not use unique tokens for each communication are particularly susceptible to this form of attack.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.65]{Impersonation.PNG}
- \caption{Adversary posing as a legitimate smart meter}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-An adversary could use this attack to pose as a monitor communicating data model and may use this to report false energy readings reducing trust in the system or use this access to perform further attacks against the infrastructure.
-
-\subsubsection{Open Port Scanning}
-
-An open port refers to a device accepting packets from a certain port number. If ports are not configured correctly, adversaries can use a insecure port that has not been blocked as an attack vector. Botnet recruitment malwares such as Mirai scan these ports to identify IoT devices that can be compromised. \cite{yang2017survey}
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.65]{Openport.PNG}
- \caption{Adversary using an open port to attack a device}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-This attack can occur in the scenario where any devices are configured to allow network traffic in from unnecessary communication protocols such as telnet (port 23) and SSH (port 22).
-\newpage
-
-\subsection{Recommendation of policies and practices}
-
-
-
-\subsubsection{Policy List}
-
-Based on the threat analysis of my scenario and my research I am recommending the following initial policies. These policies will be modelled in Scyther and the protocols that I create will be evaluated against them.
-\begin{centering}
-\begin{table}[h]
-\begin{tabular}{|c|m{3cm}|m{5cm}|m{5cm}|}
-
-\hline
-\textbf{Number} & \textbf{Policy} & \multicolumn{1}{c|}{\textbf{Description}} & \multicolumn{1}{c|}{\textbf{Reason for Inclusion}} \\ \hline
-1 & Suitable Password Management & 1. Default passwords must be changed
-
-2. Passwords should be a minimum of 8 characters and not feature common phrases & Will Mitigate the threat of default/weak password fuzzing attacks \\ \hline
-2 & Network Segregation & Smart Grid IoT devices should be segregated from the consumers home Wi-Fi network & Isolates system from the consumers potentially insecure home network \\ \hline
-3 & Patch Management & Security patches for devices and software in the system should be applied and tested in a timely fashion & Reduces exposure to known and patched vulnerabilities \\ \hline
-4 & Minimum design & The hardware design should include the minimum features required for operation of the hardware. Unnecessary ports should be closed & Unnecessary features and ports being enabled create additional attack vectors for adversaries \\ \hline
-5 & \multicolumn{3}{c|}{Communication between parties should be secure under the following sub standards} \\ \hline
-5.1 & Mutual Authentication & Mutual Authentication should be achieved by both communication parties & Increases the difficulty of an adversary posing as a communication party \\ \hline
-5.2 & Message Encryption & Information contained in communications should be encrypted & Encryption prevents an adversary sniffing information over an insecure network \\ \hline
-5.3 & Implicit key authentication & No entity other than the one specifically identified can gain access to the cryptographic key & Necessary for encryption to be robust \\ \hline
-5.4 & Unique Session Keys & Communication Parties should establish a unique session key valid for a single communication & Unique session keys prevent the re-use of authentication credentials \\ \hline
-\end{tabular}
-\caption{The initial policies recommended for the project.}
-\label{tbl:Policies}
-\end{table}
-\end{centering}
-
-\newpage
-
-\newpage
-
-\section{Design and implementation of a Scyther development environment}
-
-
-\section{Implementation and specification of non-communication IoT policies}
-
-\subsection{Smart Hub password management}
-
-In a study examining user behaviour toward password policies, Inglesant\cite{10.1145/1753326.1753384} found that excessively restrictive password policies with too much of a focus on password complexity caused users to adopt insecure workarounds such has writing down passwords or using the same password across multiple accounts. Therefore, a good password management policy should aim to balance the need for users to choose a password that is unique and complex enough to not fall victim to common password list and brute force attacks whilst also not being too restrictive or complicated that the user has to resort to insecure methods of remembering it.
-
-Based on this, the following key points are recommended for the implementation of an effective IoT password management policy:
-
-\begin{itemize}
- \item Passwords must be at least 8 characters long
- \item Before hashing, passwords should be checked against OWASP's top 10,000 password list\cite{TopPasswords}
- \item Created passwords must only be used for the Smart Hub
-\end{itemize}
-
-\newpage
-
-\section{Implementation and modelling of communication protocol policies }
-
-
-\subsection{Message Encryption}
-
-The first policy to be implemented is message encryption. As this policy is designed to mitigate the threat of passive eavesdropping, I am defining the implementation successful if an adversary is unable to decrypt and read either the key or freshly generated message using a passive Eavesdropping attack.
-
-\subsubsection{Design}
-
-The design is a symmetric encryption/decryption protocol. The symmetric key design was chosen as it requires less computational power than asymmetric options and potential issues with key distribution are mitigated as communication parties remain constant therefore keys only have to be distributed once which can be in a controlled environment.
-
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.88]{01Graph.PNG}
- \caption{Message encryption protocol design }
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-\newpage
-
-\subsubsection{Implementation}
-
-The implementation of the design in Scyther is a two-way communication where the Meter sends information to the Monitor and the Monitor sends back a confirmation of having received the message.
-
-\begin{figure}[h]
-\begin{lstlisting}[numbers=left,firstnumber=0,stepnumber=1]
-protocol smartExchange(Meter,Monitor)
-
- {
-
- role Meter {
-
- fresh Message: Nonce;
- var Confirm;
-
- send_1(Meter,Monitor,{Message}k(k));
- recv_2(Monitor,Meter,{Confirm}k(k));
-
- claim_Meter1(Meter, Secret, (k));
- claim_Meter2(Meter, Secret, Message);
-
- }
-
- role Monitor {
-
- var Message;
- fresh Confirm: Nonce;
-
- recv_1(Meter,Monitor,{Message}k(k));
- send_2(Monitor,Meter,{Confirm}k(k));
-
- claim_Monitor1(Monitor, Secret, (k));
- claim_Monitor2(Monitor, Secret, Message);
-
- }
-
-}
-
-\end{lstlisting}
-\caption{Message encryption protocol design}
-\label{fig:my_label}
-\end{figure}
-
-
-
-\newpage
-
-\subsubsection{Review}
-
-To model the requirements of both the freshly generated value and the key not being disclosed, Scyther's Secret claim was made on the message which models an adversary attempting to eavesdrop on the message during communication.
-
-Without the implementation of the symmetric key encryption, running the secret claim generates a successful eavesdropping attack.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.6]{01Comparison.PNG}
- \caption{Message encryption protocol test results }
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-The figure above shows by eavesdropping the message, demonstrated in this case by DataIntruder1 the adversary can read the contents of the message therefore disproving the secret claim.
-
-The first iteration of the protocol passed these tests successfully with Scyther showing that no attacks of this type are possible within the bounds of the protocol. Results using a wider range of claims however show that threats such as man-in-the-middle attacks can easily break this protocol demonstrating the need to iterate upon it and implement the remaining policies
-
-
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.9]{01Test.PNG}
- \caption{Message encryption protocol test results }
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-\newpage
-
-\subsection{Implicit key authentication}
-
-Later policies will require the use of secret keys to create asymmetric encryption protocols, implicit key authentication must be enforced when these keys are distributed to prevent an adversary posing as a legitimate communication party using an intercepted secret key. To implement this policy a secure key distribution protocol is required.
-
-\subsubsection{Design}
-
-When looking to design this protocol, a decision had to be made on which style of key distribution was most suitable. These two styles being considered are best represented by the two popular key distribution protocols signed Diffie-Hellman and Needham-Schroeder.
-
-Needham-Schroeder makes use of a trusted 3rd party to securely establish authentication which can be used to exchange symmetric secret keys over an insecure network as shown in the figure below.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.9]{Needham.PNG}
- \caption{Illustration of the Needham Schroeder authentication process \cite{10.1007/3-540-61770-1_46}}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-In comparison, Diffie-Hellman does not require the use of a third party and instead relies on the concept of never actually sending a shared key over an insecure network but instead exchanging information that along with secret information both parties possess, allows the parties to generate the same key which becomes the shared secret key to be used in future communications.
-
-For the given IoT scenario a Diffie-Hellman style solution is the most appropriate based mainly on the fact that it does not require an additional third party. This makes the protocol less computational complex for the IoT devices as they only need to communicate with each other as well as negating the need infrastructure in the form of a server.
-
-
-\newpage
-
-\subsection{Unique Session Keys}
-
-Implementing session keys is one of the policies aimed at mitigating the threat of authentication based attacks such as impersonation and man in the middle attacks.
-
-
-\subsubsection{Design}
-
-
-
-
-
-
-\subsubsection{Implementation}
-
-The Scyther implementation uses the SessionKey usertype to model the session keys. Once both parties have sent each other an encrypted communication containing their session keys, the Meter sends the Monitor the message.
-
-
-\begin{lstlisting}[numbers=left,firstnumber=0,stepnumber=1]
-
-usertype SessionKey;
-usertype Message;
-
-protocol EncrpytedExchange(Meter,Monitor)
-
- {
-
- role Meter {
-
- fresh M: Message;
- fresh TokenA: SessionKey;
- var TokenB;
-
- send_1(Meter,Monitor,{TokenA}k(k));
- recv_2(Monitor,Meter,{TokenB}k(k));
- claim(Meter,Running,Monitor,M);
- send_3(Meter,Monitor,{M}k(k));
-
- claim_Meter1(Meter, Secret, (k));
- claim_Meter2(Meter, Secret, M);
- claim_Meter3(Meter,Niagree);
- claim_Meter4(Meter,Nisynch);
-
- }
-
- role Monitor {
-
- var M;
- var TokenA;
- fresh TokenB: SessionKey;
-
- recv_1(Meter,Monitor,{TokenA}k(k));
- send_2(Monitor,Meter,{TokenB}k(k));
- recv_3(Meter,Monitor,{M}k(k));
-
- claim_Monitor1(Monitor, Secret, (k));
- claim_Monitor2(Monitor, Secret, M);
- claim_Meter3(Monitor,Niagree);
- claim_Meter4(Monitor,Nisynch);
-
- }
-}
-
-\end{lstlisting}
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.8]{02Code.PNG}
- \caption{Session Keys protocol in Scyther }
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-
-\newpage
-
-\subsubsection{Review}
-
-By using the Niagree and Nisynch claims, Scyther can verify if the roles within a protocol are able to authenticate the identity of a message sender. The Ni prefix denotes that the attack scope is limited to non-injective attacks, these are attacks that do not assume the adversary has knowledge from a previous run of the protocol.\cite{cas}
-
-As shown in the figure below, without the implementation of session keys it is trivial for an adversary to a pose as a meter which would allow them to send false readings in a message or potentially use the message as an attack vector for malware.
-
-
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.7]{02ComparisionBefore.PNG}
- \caption{Niagree verification results before session key implementation}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-
-\newpage
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.6]{02ComparisonAfter.PNG}
- \caption{Niagree verification results after session key implementation}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-\subsection{Mutual Authentication}
-
-
-
-
-
-
-
-
-\section{Plan for remaining work}
-
-When referring back to NIST's \cite{arnold2010nist} guidelines for the analysis and security implementation of a smart grid system, the first 3 phases defining use cases, risk assessment and specification of security requirements are reviewed in this report. Whilst the specification of security requirements will be further developed, the main focus of my remaining work is on the design and development of a security architecture and the assessment of the implementation of this architecture. This is reflected in my Gantt chart (fig:\ref{fig:Gantt}) which shows how I plan to break down this work into tasks and my expected timings for each of these tasks.
-
-
-\subsection{Risk Analysis}
-
-
-I have identified 5 risks as key risks which could impact on my delivery of the rest of the work. The grid below shows my plan to mitigate these risks and my assessment of any residual impact that may linger.
-
-
-
-\begin{table}[h]
-\begin{tabular}{|m{4cm}|c|m{6cm}|c|}
-
-\hline
-
-\multicolumn{1}{|c|}{\textbf{Risk}} & \textbf{Baseline} & \multicolumn{1}{c|}{\textbf{Mitigation}} & \textbf{Residual} \\
-
-\hline
-
-Scyther stops being supported on modern operating systems and I lose my access to the software & \begin{tabular}[c]{@{}c@{}}Impact: 5\\ Likelihood: 2\\ Score: 10\end{tabular} & I am using vagrant to set-up a box with Scyther and all the software required to run it installed so I always have it available, the vagrant box has a cloud backup & \begin{tabular}[c]{@{}c@{}}Impact: 5\\ Likelihood: 0\\ Score: 0\end{tabular} \\ \hline
-I fail to manage time correctly on the project and do not finish parts & \begin{tabular}[c]{@{}c@{}}Impact: 4\\ Likelihood: 3\\ Score: 10\end{tabular} & My Gantt chart will help when identifying if I am falling behind schedule on certain parts. Meeting weekly with my supervisor where I share my progress will also help me hold myself accountable for work. & \begin{tabular}[c]{@{}c@{}}Impact: 4\\ Likelihood: 1\\ Score: 4\end{tabular} \\ \hline
-My laptop is lost, stolen, or damaged causing me to lose all the content on the hard drive & \begin{tabular}[c]{@{}c@{}}Impact: 4\\ Likelihood: 2\\ Score: 8\end{tabular} & My project files are uploaded to Git and frequently pushed to the remote branch when I make changes. I can continue to work on my desktop and the university computers. & \begin{tabular}[c]{@{}c@{}}Impact: 3\\ Likelihood: 1\\ Score: 3\end{tabular} \\ \hline
-My remaining work is larger or more difficult than I anticipated meaning I fail to complete parts of it & \begin{tabular}[c]{@{}c@{}}Impact: 4\\ Likelihood: 3\\ Score: 12\end{tabular} & My background research and experience of learning Scyther in the last month has helped me estimate the difficulty of each task. & \begin{tabular}[c]{@{}c@{}}Impact: 3\\ Likelihood: 2\\ Score: 6\end{tabular} \\ \hline
-Personal/family issue & \begin{tabular}[c]{@{}c@{}}Impact: 3\\ Likelihood: 3\\ Score: 9\end{tabular} & Use the university support service when needed. Keep my supervisor informed & \begin{tabular}[c]{@{}c@{}}Impact: 2\\ Likelihood: 3\\ Score: 6\end{tabular} \\ \hline
-
-\end{tabular}
-
-\caption{Qualitative risk analysis and mitigation plan for the key risks}
-\label{tbl:Risk}
-
-\end{table}
-
-\newpage
-\subsection{Gantt Chart}
-
-My Gantt chart details my time management plan for the progress report and future plan for the rest of the project. \\
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.49, angle=270]{Gantt.PNG}
- \caption{Gantt chart for the project}
- \label{fig:Gantt}
- \end{figure}
-\end{centering}
-
-
-
-\newpage
-
-
-
-
-\newpage
-
-\bibliographystyle{unsrt}
-\bibliography{references.bib}
-
-
-\newpage
-
-
-
-
-
-
-
-\end{document}
diff --git a/Latex Files/latex 3rd.txt b/Latex Files/latex 3rd.txt
deleted file mode 100644
index 912569f10ec8e3947264e88637c4cb8937243daf..0000000000000000000000000000000000000000
--- a/Latex Files/latex 3rd.txt
+++ /dev/null
@@ -1,941 +0,0 @@
-\documentclass[twoside]{article}
-\usepackage[utf8]{inputenc}
-\usepackage{cite}
-\usepackage{graphicx}
-\usepackage[inner=24mm,outer=24mm,bottom=24mm,top=24mm]{geometry}
-\usepackage[parfill]{parskip}
-\usepackage[labelfont=bf]{caption}
-\usepackage[super]{nth}
-\usepackage{multirow}
-\usepackage{array}
-\usepackage{listings}
-\usepackage{color}
-\usepackage[acronym]{glossaries}
-\usepackage{enumitem}
-\usepackage{booktabs}
-
-
-\definecolor{dkgreen}{rgb}{0,0.6,0}
-\definecolor{gray}{rgb}{0.5,0.5,0.5}
-\definecolor{mauve}{rgb}{0.58,0,0.82}
-
-\lstset{frame=tb,
- language=Java,
- aboveskip=3mm,
- belowskip=3mm,
- showstringspaces=false,
- columns=flexible,
- basicstyle={\small\ttfamily},
- numbers=none,
- numberstyle=\tiny\color{gray},
- keywordstyle=\color{blue},
- commentstyle=\color{dkgreen},
- stringstyle=\color{mauve},
- breaklines=true,
- breakatwhitespace=true,
- tabsize=3
-}
-\renewcommand{\arraystretch}{1.65}
-
-
-\author{Matthew Hutchings}
-\date{October 2019}
-\title{Recommending and modelling optimal security practices for smart grid connected IoT devices}
-
-\makeglossaries
-
-\newglossaryentry{Nonce}
-{
- name=Nonce,
- description={Mathematics is what mathematicians do}
-}
-
-\begin{document}
-
-\begin{centering}
-\large {
-
- Electronics and Computer Science \\
- Faculty of Physical Sciences and Engineering \\
- University of Southampton \\
- \vspace{1cm}
- \textbf{Matthew Hutchings} \\
- \nth{12} of May 2020 \\
- \vspace{2cm}
- }
-
-\noindent\rule{13cm}{0.4pt}
-
-\vspace{0.4cm}
-
-\LARGE{ \textbf{Recommending and modelling optimal security practices for smart grid connected IoT devices}}
-
-\noindent\rule{13cm}{0.4pt}
-
-\vspace{0.4cm}
-
-\large{
-\textbf{Project Supervisor:} Dr Nawfal Fadhel \\
-\textbf{\nth{2} Examiner:} Dr Xu Fang
- \vspace{1.5cm}
-
-A report submitted for the award of \\
-MCOMP Information Technology in Organisations
-
- }
-\end{centering}
-
-\newpage
-
-\newgeometry{inner=35mm,outer=24mm,bottom=24mm,top=24mm}
-
-\tableofcontents
-
-
-\newpage
-
-\textbf{Statement of Originality}
-\begin{itemize}
- \item I have read and understood the ECS Academic Integrity information and the University’s \\Academic Integrity Guidance for Students.
- \item I am aware that failure to act in accordance with the Regulations Governing Academic Integrity may lead to the imposition of penalties which, for the most serious cases, may include termination of programme.
- \item I consent to the University copying and distributing any or all of my work in any form and using third parties (who may be based outside the EU/EEA) to verify whether my work contains plagiarised material, and for quality assurance purposes.
-\end{itemize}
-
-\textbf{I have acknowledged all sources, and identified any content taken from elsewhere.}
-
-\textbf{I have not used any resources produced by anyone else.}
-
-\textbf{I did all the work myself, or with my allocated group, and have not helped anyone else.}
-
-\textbf{The material in the report is genuine, and I have included all my data/code/designs. }
-
-\textbf{I have not submitted any part of this work for another assessment.}
-
-\textbf{My work did not involve human participants, their cells or data, or animals.}
-
-
-\newpage
-
-
-\section{Project Description}
-
-
-IoT devices present many exciting applications for both industrial and consumer use. However, increased dependence on these devices opens up new consequences and attack vectors that an adversary can use to attack a target. This is of particular importance in the case of IoT devices connected to smart grid infrastructure as cyberattacks could be used to disrupt critical national infrastructure. \\
-
-The scenario for my project is a IoT based smart grid with a focus on the IoT devices in the system and their interactions with the cloud layer.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.82]{ReferenceDiagram.PNG}
- \caption{Reference diagram of my smart grid scenario}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-\newpage
-
-\subsection{Project Aims and Objectives}
-
-This project aims to produce, model and verify a collection of policies and protocols that are suitable for mitigating the threats that a IoT enabled smart grid may face. I wish to focus on the following goals within this project:
-
-\begin{itemize}
-
-\item Investigate and conduct a risk assessment on the main vulnerabilities and threats faced by IoT devices within smart grid environment.
-
-\item Recommend security policies that can mitigate these threats, justifying these policies by taking into account secondary factors including the cost to implement and any loss to productivity these policies might incur.
-
-\item Implement and verify that these communication protocols mitigate the identified vulnerabilities using Scyther, a formal method based protocol verification tool.
-
-\item Clearly explain the impact of each of my policies by comparing the possible attack vectors with and without each policy using Scyther.
-
-\item Create a purpose built, portable Scyther virtual machine environment allowing myself and others to quickly set up and start using Scyther on a new device. Therefore allowing others to verify and extend upon the results of the project.
-
-
-\end{itemize}
-
-
-
-\subsection{Project Scope}
-
-The scope of this project will be investigating, modelling and verifying the best policies and practices for IoT devices and their communications in my smart grid scenario. The project will focus mainly on IoT communication protocols and their configuration rather examine flaws in the hardware or firmware ran by these devices.
-
-\section{Glossary of terms}
-
-\begin{itemize}[label={}]
- \item \textbf{Nonce} A randomly generated value that is used only a single time in a cryptographic protocol. Often used as a timestamp to prevent the reuse of old message credentials.
- \item \textbf{Adversary} A term used to describe a party attempting to disrupt the security of a system.
- \item \textbf{Hypervisor} A piece of software that creates an instance of a virtual machine from a virtual machine file.
- \item \textbf{Communication party} An intended sender/recipient of a communication.
-\end{itemize}
-
-\newpage
-
-\section{Literature Review}
-
-My literature review explores the IoT and smart grid landscape before looking into the cybersecurity issues that a smart grid implementation may face. Finally, the review discuss the verification of cryptographic protocols in the context of my scenario
-
-\subsection{Internet of Things (IoT) Devices}
-
-IoT as a general concept can be described as physical objects also being network identifiable devices that are able to communicate without the need for human interaction\cite{patel2016internet}. These devices can be used in a home or industrial context to automate processes or afford additional functionality. IoT devices can do this as they are able to leverage information by collecting/receiving it across a network. As an example of an IoT implementation in a chemical production plant, IoT monitoring devices could be used to monitor the temperature of a reaction. If the temperature fell outside of the requirement, the device could communicate with another IoT device that controls the coolant flow through the reaction and correct it without the need for any human interaction. \\
-
-These IoT networks can offer benefits for existing processes such as improved efficiency, fewer employees required to manage it and data which can be used to improve the process. However, it is important to consider from a cybersecurity perspective that the introduction of networked devices to a process opens it up to the possibility of cyberattacks.
-
-\subsection{Smart Grids}
-
-The term smart grid refers to the integration of technology into electrical grid systems allowing them to dynamically change to meet the current needs of consumers \cite{yu2011new}. Whilst the implementation of smart grids can vary significantly, several elements generally remain constant:
-
-\begin{itemize}
- \item \textbf{Smart Meters and Monitors -} These IoT devices are used to measure and analyse the energy usage within a single home. Typically smart meters simply collect energy readings from a room and send this information to the smart monitor. This monitor relays energy information to a collection server and receives information on current energy prices. \cite{kuslitskiy_2019}
-
- \item \textbf{Smart Hub -} This device allows the homeowner to track their electricity usage as well as view the current electricity price to help time their electricity usage to get the best price resulting in a better distribution of power demand across the power grid.
-
- \item \textbf{Cloud Layer -} This layer communicates with the Smart Meter to receive electricity usage information and send electricity pricing information. This information can then be used by the rest of the smart grid system to adjust the routing and production of electricity based on current demand.
-
-\end{itemize}
-
-
-
-\subsection{IoT Smart Grid, the Threats, Attitudes and Best Practices}
-
-A key finding from my research, summarised by Robles \cite{robles2009assessment} is that one of the key differences between securing a traditional system compared with a national infrastructure system, such as smart grid, is the reduction in the effectiveness of standard security measures such as patches, password management and access control. Stating that this is due to the size and diverse combination of hardware and software that comprises this class of system. Whilst traditional controls do have their place in smart grid security Sajid \cite{7445139} identifies the need for specific security measures that directly mitigate the threats smart grids face. This point is further explored by Bere \cite{bere2015initial} which states that large industrial control systems are often the target of state-funded Advanced Persistent Threat(APT) groups whose capabilities and resources far outmatch the typical threat actors a system faces. \cite{bere2015initial} Bere goes onto recommend that the security protocols and controls implemented should be layered, providing a 'defence in depth' security approach which Virvilis \cite{Virvilis2013TrustedCV} states as a key countermeasure against APT groups as these groups have the ability to execute zero-day exploits. Zero-day exploits offer very little chance of mitigating an attack against part of a system as the vulnerability is only known to the adversary at the time of execution \cite{Bilge:2012:BWK:2382196.2382284}. However, a layered system means that in the event of such an attack, the entire system will not be compromised due to the presence of other security measures and protocols.
-\\
-
-Another area of difficulty when it comes to securing these systems is the perspective and attitudes of governments and other organisations when it comes to securing these systems. Wang \cite{wang2012sscada} states that many organisations do not see investing in the protection of these systems as economically viable. Virvilis \cite{Virvilis2013TrustedCV} adds that disruption to productivity and user experience due to the increase in latency or removal of features that hardened security protocols may necessitate is another factor in the lack of implemented protocols on these systems. Mcqueen \cite{mcqueen2006quantitative} suggests that it is difficult to quantify cyber risk using traditional risk assessment methods. This may further contribute to the reluctant attitude towards cybersecurity investment as it is difficult to quantify the reduction in risk to management.\\
-
-\subsection{Verification of Security Policies and Protocols}
-
-Creamers \cite{cremers2008scyther} states that it is very difficult for humans to analyse and find flaws in cryptographic protocols, as evidenced by the number of protocols that are found to have security flaws after their release. An example of this is the Needham-Schroeder key distribution protocol which even after extensive analysis and verification by hand was found to have a security flaw which allowed an adversary to pass off an old session key as a new and valid one \cite{meadows1994formal}. Meadows \cite{meadows1994formal} goes on to suggest that formal methods are a good choice for analysing these cryptographic protocols as they are enclosed enough to make modelling and verification feasible whilst also having the potential for subtle and counter-intuitive flaws that an informal analysis may miss. \\
-
-In order to verify a protocol using automated formal methods, it must first be modelled so that it can be interpreted by a protocol verification tool. In my research, I have found two tools that are the most suitable for this purpose; Pro-Verif and Scyther. In their comparative analysis of these two tools Dalal et al. \cite{dalal2010comparative} identifies that whilst the two tools share several similarities, there are several differences that make Scyther more suitable than Pro-Verif for my scenario and skillset.
-
-\begin{itemize}
- \item \textbf{Modelling Language -} Scyther uses 'security protocol description language' (SPDL) described as "a mix between java and C" by creator Cas Creamers \cite{cremers2008scyther} to model protocols. Whereas Pro-Verif protocols are represented using horn clauses or pi calculus \cite{dalal2010comparative}. The SPDL used by Scyther is closer to pseudo-code than Pro-Verif making it more suitable for illustrating the implementation of protocols as well as being more fitting to my skillset.
-
- \item \textbf{Attack Graphs -} Scyther automatically generates attack graphs when a flaw is found in verification, generating a visual flow diagram of the attack. Pro-Verif does not support this feature.
-
-\end{itemize}
-
-Based on these factors, the project will use Scyther for the modelling and verification of protocols.
-
-
-
-\newpage
-
-\section{Research and Design}
-
-When it comes to implementing a best practice cybersecurity strategy, NIST \cite{arnold2010nist} recommends a five step process for analysing and securing smart grid systems. This process is defined below along with how the project will implement each of the points outlined.
-
-\begin{itemize}[label={}]
- \item \textbf{1. Defining use cases - \textit{The use cases of the system should be defined.}}
-
- Though the use of a reference diagram, the scope and elements comprising the project's IoT system are clearly defined.
-
- \item \textbf{2. Risk Assessment - \textit{ The vulnerabilities, threats and the impact these threats can cause should be evaluated for the system.}}
-
- A threat model based on the reference diagram will be used to illustrate where vulnerabilities in the system are present. The vulnerabilities will be further described in isolation with emphasis placed on the threats of this vulnerability and the impact of these threats in the context of the project's scenario
-
- \item \textbf{3. Specification of Security Requirements - \textit{The security requirements for the system should be stated and specified.}}
-
- Taking into account the threats outlined in the previous step, A list of policies will be produced outlining the security requirements of the system.
-
- \item \textbf{4. Design and Development of a Security Architecture - \textit{ A security architecture to protect the smart grid system should be designed and implemented.}}
-
- Protocols will be designed and then implemented in Scyther that satisfy the policies defined in the previous step.
-
- \item \textbf{5. Assessment of implementation - \textit{ The architecture should be assessed against the defined security requirements to test if it is fit for purpose.}}
-
- The project will use Scyther's protocol verification tools to test the protocols against the requirements defined.
-
-\end{itemize}
-
-
-
-
-
-\subsection{Scyther development environment}
-
-One of the key goals of the project was to create a portable environment for Scyther development. When researching what the most suitable tools to create this would be, particular emphasis was placed on the following criteria:
-
-\begin{itemize}
- \item \textbf{Self-contained -} Once installed, the virtual machine should contain all the components and dependencies required to develop using Scyther
-
- \item \textbf{Portable -} The machine must be simple to install and ideally small enough that it can be hosted using common software distribution tools such as GitHub.
-
- \item \textbf{Configurable -} Users should be able to make changes to the environment to suit their individual preferences and needs. This includes elements such as the flavour of Linux used and the resources assigned to the machine.
-
- \item \textbf{Versionable -} Changes made to the machine configuration should be versionable ideally being compatible with git, the most common version control method. This allows for future adaptations and iterations upon the machine to be easily tracked as well as making it easy for users to revert changes made to the machine if issues occur.
-
- \item \textbf{Compatible -} The machine should be formatted so it does not require the use of proprietary software to run.
-\end{itemize}
-
-During research, two virtual machine formats stood out as being suitable for the project; the Open Virtualisation Format (OVF) and Vagrant. Both of these formats are non-proprietary and easily compatible with common hypervisors like VirtualBox. Either format would also allow for the packing of all the required software to develop using vagrant.
-
-One of the key advantages Vagrant possess over OVF is the vagrant file. Vagrant environments are packaged in formats known as boxes, vagrant files allow a user to customise and specialise a box to suit their needs. As Vagrant files are written in the Ruby programming language, they are versionable and compatible with git, this makes the process of collaborating with others and extending vagrant files simple. However, Vagrant virtual boxes are slightly more complex to install as they require the vagrant software to be installed on the host machine, OVF files can just be imported into the chosen hypervisor. Despite this, the configurability and git compatibility that vagrant files provide offer great value in this use case making them the best choice for the project's Scyther environment.
-
-\subsubsection{Requirements and development methodology}
-
-Based on the criteria outlined in the section above, a list of requirements for the Scytherbox have been developed. To prioritize these development requirements, the MoSCoW method has been used:
-\\
-\begin{table}[h]
-\begin{tabular}{c|c}
-\textbf{Must Have} & \textbf{Should Have} \\ \hline
-Scyther v1.13 installation from VagrantFile & Linux flavour options \\
-Scyther dependencies installed from VagrantFile & Shared folder between host and Scytherbox \\
-Versionable using git & Installation Instructions \\
- & Example Protocols within the box \\
-\multicolumn{1}{l|}{} & Scytherbox documentation
-\end{tabular}
-\end{table}
-\begin{table}[h]
-\begin{tabular}{c|c}
-\textbf{Could Have} & \textbf{Won't Have Now} \\ \hline
- \hspace{32} Git configuration within the box \hspace{32} & \hspace{32} Windows version of scytherbox \hspace{32} \\
-Scyther user guide & \\
- & \\
- & \\
-\multicolumn{1}{l|}{} & \multicolumn{1}{l}{}
-\end{tabular}
-\caption{Table showing the prioritisation of the scytherbox requirements}
-\end{table}
-\\
- Despite a lack of clearly defined stakeholders for this part of the project, elements of the AGILE methodology will be used to plan and manage the development of the Scytherbox. The main reason for this is that a basic version of the box that can run Scyther is required to complete the modelling and verification of the suggested protocols making a initial working release a high priority.
-
-
-
-\newpage
-
-To estimate the development time each requirement will take to implement, t-shirt sizing has been used. The table below shows a description of each requirement and it's estimated size.
-\\
-\begin{centering}
-\begin{table}[h]
-\begin{tabular}{|c|m{7cm}|c|}
-\hline
-\textbf{Requirement Title} & \textbf{Description} & \textbf{Estimated Size} \\ \hline
-Scyther v1.13 installation & The latest version of Scyther should be imported into the box using the VagrantFile & Medium \\ \hline
-Scyther dependencies installed & Python 2.7, as well as the GraphViz and wxPython libraries, should be installed on the box using the VagrantFile & Medium \\ \hline
-Versionable using git & Changes to the box configuration should be visible in git so they can be versioned. & Small \\ \hline
-Linux flavour options & Allow changing of Linux flavour during box configuration & Small \\ \hline
-Git configuration & Implement functionality allowing git repositories to be cloned and configured on the box during configuration & Large \\ \hline
-Shared folder & Implement a synced folder on the host machine and Scytherbox allowing for the easy transfer of files between the two & Small \\ \hline
-Installation instructions & A set of instructions explaining how to install Scytherbox & Medium \\ \hline
-Example protocols & A folder on the host machine attached to the box allowing sample protocols to be included in an installation of the box. & Medium \\ \hline
-Scytherbox documentation & A documentation of the VagrantFile and shell scripts used to create the Scytherbox, making it easier for others to iterate on in the future & Large \\ \hline
-Scyther user guide & A guide installed on the box explaining the basics of Scyther and the scyther protocol description language (SDPL) & Medium \\ \hline
-Windows version & A version of the Scytherbox that uses Windows as the box's operating system & Extra Large \\ \hline
-\end{tabular}
-\caption{Table describing and estimating the size of each Scytherbox requirement}
-\end{table}
-\end{centering}
-
-\textbf{Key:}
-
-\begin{itemize}[label={}]
- \item \textbf{Small - } 1 Hour
- \item \textbf{Medium - } 2 Hours
- \item \textbf{Large - } 4 Hours
- \item \textbf{Extra Large - } 10 Hours
-\end{itemize}
-
-\newpage
-
-\subsubsection{Development plan}
-
-The development of the Scytherbox environment is scheduled to take place over a 3 week period with 1 week allotted for each sprint. The modelling and verification of the project's policies is scheduled to take place 1 week into this period hence the core features required to develop using Scyther being assigned to the first sprit.
-
-
-\begin{table}[h]
-\begin{tabular}{ccc}
-\multicolumn{1}{c|}{\textbf{Sprint 1}} & \multicolumn{1}{c|}{\textbf{Sprint 2}} & \textbf{Sprint 3} \\ \hline
-\multicolumn{1}{c|}{Scyther Installation} & \multicolumn{1}{c|}{Git configuration within the box} & Scyther user guide \\
-\multicolumn{1}{c|}{Scyther dependencies installed} & \multicolumn{1}{c|}{Linux flavour options} & Example Protocols within the box \\
-\multicolumn{1}{c|}{Versionable using git} & \multicolumn{1}{c|}{Scytherbox documentation} & Installation Instructions \\
-\multicolumn{1}{c|}{Shared folder} & \multicolumn{1}{c|}{} & \\
-\textbf{Sprint Hours: 8} & \textbf{Sprint Hours: 9} & \textbf{Sprint Hours: 6}
-\end{tabular}
-\caption{Scytherbox sprint plan}
-\end{table}
-
-\newpage
-
-\subsection{Threat Model}
-
-The threat model below shows some of the attack vectors and vulnerabilities an adversary could exploit within my scenario:
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.85]{ThreatModel.PNG}
- \caption{Threat Model of my smart grid scenario}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-A detailed breakdown of each threat and how they can be mitigated through the application of security protocols can be found in the preceding sections.
-
-\newpage
-
-\subsubsection{Weak/Default Password Fuzzing Attack}
-
-OWASP \cite{owasp} states than the most common vulnerability exploited in IoT devices is the use of weak or default passwords. These attacks are usually performed by automated scripts commonly referred to as bots that scan the internet for connected devices and run a list of common passwords. As an example of this, the Mirai botnet was able to infect and recruit over 500,000 IoT devices using a list of just 60 common passwords.
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.9]{PasswordManagement.PNG}
- \caption{Adversary using a common password to compromise the network}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-In this scenario an adversary could exploit an internet connected smart hub with a weak or guessable password to recruit the device into a botnet or potentially use the compromised device as an attack vector to mount further attacks on the rest of the network.
-
-\subsubsection{Man In The Middle (MITM) Attack}
-
-Man in the middle attacks occur when an adversary is able to act as an intermediary or proxy between communication parties without their knowledge. This allows the adversary to view the contents of the messages sent between parties as well as silently modify the contents of messages.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.63]{MITM.PNG}
- \caption{Adversary relaying and modifying smart monitor data}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-An Adversary could perform a MITM attack by secretly relaying and modifying the electricity usage information sent to the data model. A large scale attack of this kind effecting many monitor to model connections could cause false data injection attack on the smart grid system where false data could cause the system to make an incorrect decision when routing power.
-
-\newpage
-
-\subsubsection{Passive Eavesdropping}
-
-Low power IoT devices commonly use weak or no cryptography in their communications protocols, this means an adversary could use devices such as a wireless packet sniffer to intercept traffic sent between devices and read the contents of the communications sent. OWASP\cite{owasp} lists these insecure protocols as the \nth{2} most common IoT vulnerability.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.55]{Eavesdropping.PNG}
- \caption{Adversary reading an insecure communication}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-This attack could occur anywhere in the scenario where devices communicate with each other without the use of an encrypted communication protocol. For example, the adversary could sniff packets between the smart meter and monitor to know if a home is occupied based on their current electricity usage or to gather information on the network for further attacks.
-
-\subsubsection{Replay Attack}
-
-Replay attacks occur when an adversary is able to identify and collect authentication credentials from a legitimate communication and use those credentials in a later communication to bypass authentication. This commonly occurs when communication partners do not make use of a unique identifier for each communication such as a session key.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.65]{Replay.PNG}
- \caption{Adversary sniffing and reusing hashed authentication credentials}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-The adversary could sniff an encrypted communication between router and server used for the transmission of energy usage data. With this they could use the hashed authenticator code to send messages to the server posing as that home network without needing to know the actual authenticator code.
-
-
-\newpage
-
-\subsubsection{Impersonation Attack}
-
-An Impersonation attack occurs when an Adversary is able to pose as the identify of a legitimate party in a communication protocol allowing them to bypass authorisation or act on the legitimate user's behalf \cite{Adams2005}. Protocols that do not use unique tokens for each communication are particularly susceptible to this form of attack.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.65]{Impersonation.PNG}
- \caption{Adversary posing as a legitimate smart meter}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-An adversary could use this attack to pose as a monitor communicating data model and may use this to report false energy readings reducing trust in the system or use this access to perform further attacks against the infrastructure.
-
-\subsubsection{Open Port Scanning}
-
-An open port is a port number that a device accepts packets from. If ports are not configured correctly, adversaries can use a insecure port that has not been blocked as an attack vector. Botnet recruitment malwares such as Mirai scan these ports to identify IoT devices that can be compromised. \cite{yang2017survey}
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.65]{Openport.PNG}
- \caption{Adversary using an open port to attack a device}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-This attack can occur in the scenario where any devices are configured to allow network traffic in from unnecessary communication protocols such as telnet (port 23) and SSH (port 22).
-\newpage
-
-\section{Recommendation of policies and practices}
-
-Based on the threats identified above and research into the security needs of smart grid systems, a set of policies have been defined. These policies are split into two groups, communication policies which define the standards communications between devices in the scenario must meet to ensure they are cryptographically secure. As well as best practices which define non-communication policies to protect the devices in the scenario against other forms of attack.
-
-
-
-
-
-\subsection{Communication Policies}
-
-These are the policies which are to be modelled and verified using Scyther. A brief description of each policy is defined below explaining why they have been included, as well as any potential drawbacks that implementing each policy may cause.
-
-\begin{itemize}
- \item \textbf{Message Encryption}
-
- This policy is the most fundamental aspect of a cryptographic protocol and is designed to mitigate the threat of passive eavesdropping. Message encryption defines that the contents of all communications between parties should be encoded in such a way that only those with access to the decryption key can decode and read the message.
-
-In a 2018 investigation into the impact of the popular encryption standard AES on IoT communications, Hung CW and Hsu WT\cite{hung2018power} found that Hardware AES increased power consumption of the average communication by 31\%. Despite this increased power draw, encryption is an essential component of a cryptographic protocol as without it an adversary an simply eavesdrop on messages in transit and view their contents as shown in \textbf{section 4.2.3}.
-
- \item \textbf{Implicit Key Authentication}
-
- Implicit key authentication is a policy that will be implemented during the key distribution process. This process is where communication parties share the secrets keys allowing them to generate session keys for the messages they send between each other. The policy defines that only the authorised parties should be able to access these keys. Without this policy, an adversary could perform a man in the middle \textbf{(section 4.2.2)} or impersonation \textbf{(section 4.2.5)} attack.
-
-The reason for implementing a key distribution process is because symmetric encryption protocols require a shared secret key between communication parties in order to function. Whilst it is the case that asymmetric encryption algorithms do not require this step, asymmetric encryption is also more computationally intensive as it takes more CPU cycles to encrypt and decrypt messages. This factor becomes significant when considering the low computational power possessed by the IoT devices with the scenario and the need to communicate energy readings frequently.
-
- \item \textbf{Session Keys}
-
- Session keys are a randomly generated keys that parties agree on to encrypt and decrypt a single communication. These keys are generated and shared with the assistance of the secret keys that the parties already shared in the key distribution process. Unique session keys are being implemented to mitigate the threat of replay attacks \textbf{(section 4.2.4)} as they prevent the use of intercepted credentials. This is because the session key intercepted from a previous communication will never be reused as the session keys are regenerated for each new communication.
- \item \textbf{Mutual Authentication}
-
- Mutual Authentication requires that both parties are able to authenticate and trust the identity of each other. This policy is being implemented to prevent impersonation attacks \textbf{(section 4.2.5)}. Particularly impersonation attacks that involve the the mass creation of fake meters which send false information to the cloud server as well as the prevention of false cloud server identities causing meters to send their information to an adversary's server instead of the smart grid cloud server.
-
-\end{itemize}
-
-
-
-
-
-\subsection{Best Practices}
-
-Policies defined in this section are designed to mitigate non-communication attacks...
-
-
-\subsubsection{Password Management}
-
-
-
-
-\subsubsection{Network Segregation}
-
-
-
-\subsubsection{Patch Management}
-
-
-
-\subsubsection{Minimum Design}
-
-
-
-
-\newpage
-
-
-
-
-
-
-
-
-\section{Implementation and specification of non-communication IoT policies}
-
-\subsection{Smart Hub password management}
-
-In a study examining user behaviour toward password policies, Inglesant\cite{10.1145/1753326.1753384} found that excessively restrictive password policies with too much of a focus on password complexity caused users to adopt insecure workarounds such has writing down passwords or using the same password across multiple accounts. Therefore, a good password management policy should aim to balance the need for users to choose a password that is unique and complex enough to not fall victim to common password list and brute force attacks whilst also not being too restrictive or complicated that the user has to resort to insecure methods of remembering it.
-
-Based on this, the following key points are recommended for the implementation of an effective IoT password management policy:
-
-\begin{itemize}
- \item Passwords must be at least 8 characters long
- \item Before hashing, passwords should be checked against OWASP's top 10,000 password list\cite{TopPasswords}
- \item Created passwords must only be used for the Smart Hub
-\end{itemize}
-
-\newpage
-
-\section{Implementation and modelling of communication protocol policies }
-
-
-\subsection{Message Encryption}
-
-The first policy to be implemented is message encryption. As this policy is designed to mitigate the threat of passive eavesdropping, I am defining the implementation successful if an adversary is unable to decrypt and read either the key or freshly generated message using a passive Eavesdropping attack.
-
-\subsubsection{Design}
-
-
-
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.88]{01Graph.PNG}
- \caption{Message encryption protocol design }
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-\newpage
-
-\subsubsection{Implementation}
-
-The implementation of the design in Scyther is a two-way communication where the Meter sends information to the Monitor and the Monitor sends back a confirmation of having received the message.
-
-\begin{figure}[h]
-\begin{lstlisting}[numbers=left,firstnumber=0,stepnumber=1]
-protocol smartExchange(Meter,Monitor)
-
- {
-
- role Meter {
-
- fresh Message: Nonce;
- var Confirm;
-
- send_1(Meter,Monitor,{Message}k(k));
-
- recv_2(Monitor,Meter,{Confirm}k(k));
-
- claim_Meter1(Meter, Secret, (k));
- claim_Meter2(Meter, Secret, Message);
-
- }
-
- role Monitor {
-
- var Message;
- fresh Confirm: Nonce;
-
- recv_1(Meter,Monitor,{Message}k(k));
-
- send_2(Monitor,Meter,{Confirm}k(k));
-
- claim_Monitor1(Monitor, Secret, (k));
- claim_Monitor2(Monitor, Secret, Message);
-
- }
-
-}
-
-\end{lstlisting}
-\caption{Message encryption protocol design}
-\label{fig:my_label}
-\end{figure}
-
-
-
-\newpage
-
-\subsubsection{Review}
-
-To model the requirements of both the freshly generated value and the key not being disclosed, Scyther's Secret claim was made on the message which models an adversary attempting to eavesdrop on the message during communication.
-
-Without the implementation of the symmetric key encryption, running the secret claim generates a successful eavesdropping attack.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.6]{01Comparison.PNG}
- \caption{Message encryption protocol test results }
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-The figure above shows by eavesdropping the message, demonstrated in this case by DataIntruder1 the adversary can read the contents of the message therefore disproving the secret claim.
-
-The first iteration of the protocol passed these tests successfully with Scyther showing that no attacks of this type are possible within the bounds of the protocol. Results using a wider range of claims however show that threats such as man-in-the-middle attacks can easily break this protocol demonstrating the need to iterate upon it and implement the remaining policies
-\\
-% Please add the following required packages to your document preamble:
-% \usepackage{booktabs}
-% Please add the following required packages to your document preamble:
-% \usepackage{booktabs}
-
-\begin{table}[h]
-\begin{centering}
-\begin{tabular}{@{}lll@{}}
-\toprule
-\textbf{Role} & \textbf{Claim} & \textbf{Result} \\ \midrule
-\textbf{Meter} & Secret Message & Pass \\
- & Secret key(k) & Pass \\
-\textbf{Monitor} & Secret Message & Pass \\
- & Secret key(k) & Pass \\ \bottomrule
-\end{tabular}
-\caption{Log of claims made against the message encryption protocol and their results}
-\end{centering}
-\end{table}
-
-\newpage
-
-\subsection{Implicit key authentication}
-
-Later policies will require the use of secret keys to create symmetric encryption protocols, implicit key authentication must be enforced when these keys are distributed to prevent an adversary posing as a legitimate communication party using an intercepted secret key. To implement this policy a secure key distribution protocol is required.
-
-\subsubsection{Design}
-
-When looking to design this protocol, a decision had to be made on which style of key distribution was most suitable. These two styles being considered are best represented by the two popular key distribution protocols signed Diffie-Hellman and Needham-Schroeder.
-
-Needham-Schroeder makes use of a trusted 3rd party to securely establish authentication which can be used to exchange symmetric secret keys over an insecure network as shown in the figure below.
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.9]{Needham.PNG}
- \caption{Illustration of the Needham Schroeder authentication process \cite{10.1007/3-540-61770-1_46}}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-In comparison, Diffie-Hellman does not require the use of a third party and instead relies on the concept of never actually sending a shared key over an insecure network but instead exchanging information that along with secret information both parties possess, allows the parties to generate the same key which becomes the shared secret key to be used in future communications.
-
- For the given IoT scenario a Diffie-Hellman style solution is the most appropriate based mainly on the fact that it does not require an additional third party. This makes the protocol less computationally complex for the IoT devices as they only need to communicate with each other as well as negating the need infrastructure in the form of a server.
-
-The design for this policy in the project scenario, as illustrated below, works by having the two communication parties each come up with a fresh value. The aim of the protocol is then to allow the two parties to exchange their values whilst ensuring that an adversary cannot either eavesdrop on the message or pose as one of the parties to gain both of the values.
-
- \begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.8]{keyexchangedraft.PNG}
- \caption{Illustration of the planned key exchange \cite{10.1007/3-540-61770-1_46}}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-Once each party exchanges it's generated value with the other, they are then combined together using a predetermined hash function. This means that the two values are inputted into a function that is computationally expensive to reverse engineer, because of this an adversary cannot work out what the two inputs were from the resulting output. This output is then used as the shared secret key that all session keys for future communications will use as the base.
-
-\subsubsection{Implementation}
-
-
-\begin{lstlisting}[numbers=left,firstnumber=0,stepnumber=1]
-
-hashfunction hashed;
-usertype Message;
-
-protocol KeyExchange(Monitor,CloudServer)
-{
- role Monitor
-
- {
-
- fresh MonitorValue : Nonce;
- fresh Confirm: Message;
- var CloudServerValue : Nonce;
-
- send_1(Monitor,CloudServer,{Monitor,MonitorValue}pk(CloudServer));
-
- recv_2(CloudServer,Monitor, {CloudServerValue,hashed(MonitorValue),
- CloudServer}pk(Monitor));
-
- send_3(Monitor,CloudServer, hashed(CloudServerValue, Confirm));
-
- claim_Monitor1(Monitor,Niagree);
- claim_Monitor2(Monitor,Nisynch);
- claim_Monitor3(Monitor, Secret, MonitorValue);
- claim_Monitor4(Monitor, Secret, CloudServerValue);
-
- }
-
- role CloudServer
-
- {
-
- var MonitorValue: Nonce;
- var Confirm: Message;
- fresh CloudServerValue: Nonce;
-
- recv_1(Monitor,CloudServer,{Monitor,MonitorValue}pk(CloudServer));
-
- send_2(CloudServer,Monitor, {CloudServerValue,hashed(MonitorValue),
- CloudServer}pk(Monitor));
-
- recv_3(Monitor,CloudServer, hashed(CloudServerValue, Confirm));
-
- claim_CloudServer1(CloudServer,Niagree);
- claim_CloudServer2(CloudServer,Nisynch);
- claim_CloudServer3(CloudServer, Secret, MonitorValue);
- claim_CloudServer4(CloudServer, Secret, CloudServerValue);
-
- }
-}
-\end{lstlisting}
-
-\subsubsection{Review}
-
-\newpage
-
-\subsection{Unique Session Keys}
-
-Implementing session keys
-
-
-\subsubsection{Design}
-
-
-
-
-
-
-\subsubsection{Implementation}
-
-The Scyther implementation uses the SessionKey usertype to model the session keys. Once both parties have sent each other an encrypted communication containing the session key, the Meter sends the Monitor the message.
-
-
-\begin{lstlisting}[numbers=left,firstnumber=0,stepnumber=1]
-
-usertype SessionKey;
-usertype Message;
-
-protocol EncrpytedExchange(Meter,Monitor)
-
- {
-
- role Meter {
-
- fresh M: Message;
- fresh TokenA: SessionKey;
- var TokenB;
-
- send_1(Meter,Monitor,{TokenA}k(k));
- recv_2(Monitor,Meter,{TokenB}k(k));
- claim(Meter,Running,Monitor,M);
- send_3(Meter,Monitor,{M}k(k));
-
- claim_Meter1(Meter, Secret, (k));
- claim_Meter2(Meter, Secret, M);
- claim_Meter3(Meter,Niagree);
- claim_Meter4(Meter,Nisynch);
-
- }
-
- role Monitor {
-
- var M;
- var TokenA;
- fresh TokenB: SessionKey;
-
- recv_1(Meter,Monitor,{TokenA}k(k));
- send_2(Monitor,Meter,{TokenB}k(k));
- recv_3(Meter,Monitor,{M}k(k));
-
- claim_Monitor1(Monitor, Secret, (k));
- claim_Monitor2(Monitor, Secret, M);
- claim_Meter3(Monitor,Niagree);
- claim_Meter4(Monitor,Nisynch);
-
- }
-}
-
-\end{lstlisting}
-
-
-\newpage
-
-\subsubsection{Review}
-
-By using the Niagree and Nisynch claims, Scyther can verify if the roles within a protocol are able to authenticate the identity of a message sender. The Ni prefix denotes that the attack scope is limited to non-injective attacks, these are attacks that do not assume the adversary has knowledge from a previous run of the protocol.\cite{cas}
-
-As shown in the figure below, without the implementation of session keys it is trivial for an adversary to a pose as a meter which would allow them to send false readings in a message or potentially use the message as an attack vector for malware.
-
-
-\begin{centering}
- \begin{figure}[!h]
- \includegraphics[scale = 0.6]{02ComparisionBefore.PNG}
- \caption{Niagree verification results before session key implementation}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-The results after the implementation show that whilst the simple impersonation attack
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.6]{02ComparisonAfter.PNG}
- \caption{Niagree verification results after session key implementation}
- \label{fig:my_label}
- \end{figure}
-\end{centering}
-
-
-
-
-\subsection{Mutual Authentication}
-
-
-
-
-
-
-
-
-\section{Plan for remaining work}
-
-When referring back to NIST's \cite{arnold2010nist} guidelines for the analysis and security implementation of a smart grid system, the first 3 phases defining use cases, risk assessment and specification of security requirements are reviewed in this report. Whilst the specification of security requirements will be further developed, the main focus of my remaining work is on the design and development of a security architecture and the assessment of the implementation of this architecture. This is reflected in my Gantt chart (fig:\ref{fig:Gantt}) which shows how I plan to break down this work into tasks and my expected timings for each of these tasks.
-
-
-\subsection{Risk Analysis}
-
-
-I have identified 5 risks as key risks which could impact on my delivery of the rest of the work. The grid below shows my plan to mitigate these risks and my assessment of any residual impact that may linger.
-
-
-
-\begin{table}[h]
-\begin{tabular}{|m{4cm}|c|m{6cm}|c|}
-
-\hline
-
-\multicolumn{1}{|c|}{\textbf{Risk}} & \textbf{Baseline} & \multicolumn{1}{c|}{\textbf{Mitigation}} & \textbf{Residual} \\
-
-\hline
-
-Scyther stops being supported on modern operating systems and I lose my access to the software & \begin{tabular}[c]{@{}c@{}}Impact: 5\\ Likelihood: 2\\ Score: 10\end{tabular} & I am using vagrant to set-up a box with Scyther and all the software required to run it installed so I always have it available, the vagrant box has a cloud backup & \begin{tabular}[c]{@{}c@{}}Impact: 5\\ Likelihood: 0\\ Score: 0\end{tabular} \\ \hline
-I fail to manage time correctly on the project and do not finish parts & \begin{tabular}[c]{@{}c@{}}Impact: 4\\ Likelihood: 3\\ Score: 10\end{tabular} & My Gantt chart will help when identifying if I am falling behind schedule on certain parts. Meeting weekly with my supervisor where I share my progress will also help me hold myself accountable for work. & \begin{tabular}[c]{@{}c@{}}Impact: 4\\ Likelihood: 1\\ Score: 4\end{tabular} \\ \hline
-My laptop is lost, stolen, or damaged causing me to lose all the content on the hard drive & \begin{tabular}[c]{@{}c@{}}Impact: 4\\ Likelihood: 2\\ Score: 8\end{tabular} & My project files are uploaded to Git and frequently pushed to the remote branch when I make changes. I can continue to work on my desktop and the university computers. & \begin{tabular}[c]{@{}c@{}}Impact: 3\\ Likelihood: 1\\ Score: 3\end{tabular} \\ \hline
-My remaining work is larger or more difficult than I anticipated meaning I fail to complete parts of it & \begin{tabular}[c]{@{}c@{}}Impact: 4\\ Likelihood: 3\\ Score: 12\end{tabular} & My background research and experience of learning Scyther in the last month has helped me estimate the difficulty of each task. & \begin{tabular}[c]{@{}c@{}}Impact: 3\\ Likelihood: 2\\ Score: 6\end{tabular} \\ \hline
-Personal/family issue & \begin{tabular}[c]{@{}c@{}}Impact: 3\\ Likelihood: 3\\ Score: 9\end{tabular} & Use the university support service when needed. Keep my supervisor informed & \begin{tabular}[c]{@{}c@{}}Impact: 2\\ Likelihood: 3\\ Score: 6\end{tabular} \\ \hline
-
-\end{tabular}
-
-\caption{Qualitative risk analysis and mitigation plan for the key risks}
-\label{tbl:Risk}
-
-\end{table}
-
-\newpage
-\subsection{Gantt Chart}
-
-My Gantt chart details my time management plan for the progress report and future plan for the rest of the project. \\
-
-\begin{centering}
- \begin{figure}[h]
- \centering
- \includegraphics[scale = 0.46, angle=270]{ganttnew.PNG}
- \caption{Gantt chart for the project}
- \label{fig:Gantt}
- \end{figure}
-\end{centering}
-
-
-
-\newpage
-
-
-
-
-\newpage
-
-\bibliographystyle{unsrt}
-\bibliography{references.bib}
-
-
-\newpage
-
-
-
-
-
-
-
-\end{document}