diff --git a/Design Files/Latex/01Comparison.PNG b/Design Files/Latex/01Comparison.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..cfae163dbf5d7142027b5c4181a67645a18d6079
Binary files /dev/null and b/Design Files/Latex/01Comparison.PNG differ
diff --git a/Design Files/Latex/02ComparisionBefore.PNG b/Design Files/Latex/02ComparisionBefore.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..3a54e98145ab4929fd467cd95f645579ddf66c99
Binary files /dev/null and b/Design Files/Latex/02ComparisionBefore.PNG differ
diff --git a/Design Files/Latex/Eavesdropping.PNG b/Design Files/Latex/Eavesdropping.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..05a8b3be47ef2d2c743412f3558bd3165146a15f
Binary files /dev/null and b/Design Files/Latex/Eavesdropping.PNG differ
diff --git a/Design Files/Latex/GanttActual.PNG b/Design Files/Latex/GanttActual.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..bdac246abbaad384d7a6c1d44306d2ed84d005bf
Binary files /dev/null and b/Design Files/Latex/GanttActual.PNG differ
diff --git a/Design Files/Latex/GanttPlanned.PNG b/Design Files/Latex/GanttPlanned.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..5e1bde71e29a5385f14e4ce0dd649636aca0ce16
Binary files /dev/null and b/Design Files/Latex/GanttPlanned.PNG differ
diff --git a/Design Files/Latex/Impersonation.PNG b/Design Files/Latex/Impersonation.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..3ebe8216e7ccf57537bdca817d4c014ee07ab3b3
Binary files /dev/null and b/Design Files/Latex/Impersonation.PNG differ
diff --git a/Design Files/Latex/KeyExhange.png b/Design Files/Latex/KeyExhange.png
new file mode 100644
index 0000000000000000000000000000000000000000..ff93c6a90739af41ac82cfc98534f5bb210a93ba
Binary files /dev/null and b/Design Files/Latex/KeyExhange.png differ
diff --git a/Design Files/Latex/MITM.PNG b/Design Files/Latex/MITM.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..4324d324f67abb7a595d2ae09571bdbb193c4ef2
Binary files /dev/null and b/Design Files/Latex/MITM.PNG differ
diff --git a/Design Files/Latex/Mutual Authentication.png b/Design Files/Latex/Mutual Authentication.png
new file mode 100644
index 0000000000000000000000000000000000000000..b0161b7a2bb441d033eb0a952fc567478117fad1
Binary files /dev/null and b/Design Files/Latex/Mutual Authentication.png differ
diff --git a/Design Files/Latex/Needham Schroeder.png b/Design Files/Latex/Needham Schroeder.png
new file mode 100644
index 0000000000000000000000000000000000000000..525b20006797051498e4183843aa69abd8f37235
Binary files /dev/null and b/Design Files/Latex/Needham Schroeder.png differ
diff --git a/Design Files/Latex/Networktraversal.PNG b/Design Files/Latex/Networktraversal.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..d3f23f1c80d55385f31941e4d28d8b2efb0f279f
Binary files /dev/null and b/Design Files/Latex/Networktraversal.PNG differ
diff --git a/Design Files/Latex/Openport.PNG b/Design Files/Latex/Openport.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..a15a1c057d7112583ab741ad651fcfd4ccdb55e2
Binary files /dev/null and b/Design Files/Latex/Openport.PNG differ
diff --git a/Design Files/Latex/PasswordManagement.PNG b/Design Files/Latex/PasswordManagement.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..dc13089bcc4b09212de5a1f8ccf066996aa324b8
Binary files /dev/null and b/Design Files/Latex/PasswordManagement.PNG differ
diff --git a/Design Files/Latex/Replay.PNG b/Design Files/Latex/Replay.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..bd85d093d1d5599f886e55fd69d93dc93b64a5f2
Binary files /dev/null and b/Design Files/Latex/Replay.PNG differ
diff --git a/Design Files/Latex/Session Keys.png b/Design Files/Latex/Session Keys.png
new file mode 100644
index 0000000000000000000000000000000000000000..e0e0bd4ce9d1d5868a2dee2a88367ae895f894f9
Binary files /dev/null and b/Design Files/Latex/Session Keys.png differ
diff --git a/Design Files/Latex/Software.PNG b/Design Files/Latex/Software.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..11e6534c2e903e95bdcbff3a9ff40980c8d30e63
Binary files /dev/null and b/Design Files/Latex/Software.PNG differ
diff --git a/Design Files/Latex/crest.jpg b/Design Files/Latex/crest.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..914234f6e15c5de9017dc1077062cc84df98bd32
Binary files /dev/null and b/Design Files/Latex/crest.jpg differ
diff --git a/Design Files/Latex/encrypt.png b/Design Files/Latex/encrypt.png
new file mode 100644
index 0000000000000000000000000000000000000000..bfdea948671b42ea32637bd5de31ac22dffa42f2
Binary files /dev/null and b/Design Files/Latex/encrypt.png differ
diff --git a/Design Files/Latex/main.tex b/Design Files/Latex/main.tex
new file mode 100644
index 0000000000000000000000000000000000000000..9ca3ad3017c1f6c633f013027e6ab04109d01135
--- /dev/null
+++ b/Design Files/Latex/main.tex
@@ -0,0 +1,1467 @@
+\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}
+\usepackage{pgfgantt}
+\usepackage{forest}
+\usepackage{appendix}
+
+
+\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
+
+\begin{document}
+
+\begin{centering}
+\large {
+
+ Electronics and Computer Science \\
+ Faculty of Physical Sciences and Engineering \\
+ University of Southampton \\
+ \vspace{1cm}
+
+ }
+
+\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{Matthew Hutchings} \\
+\nth{12} of May 2020 \\
+
+}
+
+ \vspace{1cm}
+
+
+ \begin{centering}
+ \begin{figure}[!h]
+ \centering
+ \includegraphics[scale = 0.44]{crest.jpg}
+ \end{figure}
+\end{centering}
+
+
+\large{
+\textbf{Project Supervisor:} Dr Nawfal Fadhel \\
+\textbf{\nth{2} Examiner:} Dr Xu Fang
+ \vspace{1cm}
+
+A report submitted for the award of \\
+MCOMP Information Technology in Organisations
+
+ }
+\end{centering}
+
+\thispagestyle{empty}
+
+\newpage
+
+\newgeometry{inner=40mm,outer=40mm,bottom=24mm,top=34mm}
+\begin{Large}
+
+\begin{centering}
+\textbf{Abstract} \\
+\end{centering}
+
+\end{Large}
+
+
+
+
+
+\vspace{0.8cm}
+
+ Critical national infrastructure such as smart grids are becoming an increasingly popular target for cyberattacks from nation states and other adversaries. One of the key reasons for this are the often inadequate security measures present in the IoT devices these systems rely on. In order to protect such a system, the unique threat landscape faced by smart grids as well as the constraints of a large, distributed network of IoT devices must be considered. \\
+
+ The primary objective of this project is to firstly identify the main threats that IoT devices in a smart grid system face and then recommend security policies that could mitigate these threats. To test that the outlined policies are fit for purpose, they were modelled and verified using Scyther, a tool for the automated verification of cryptographic protocols.
+
+
+
+\thispagestyle{empty}
+
+\newpage
+
+\begin{Large}
+
+\begin{centering}
+\textbf{Acknowledgements } \\
+\end{centering}
+
+\end{Large}
+
+
+
+
+
+\vspace{0.8cm}
+
+Firstly, I would like to especially thank my supervisor Dr Nawfal Fadhel not just for their knowledge and guidance but for their personal support as well over the course of this project.
+
+I would also like to thank my friends and lastly but importantly my family for their support and always believing in me.
+
+
+\thispagestyle{empty}
+
+
+
+\newgeometry{inner=35mm,outer=24mm,bottom=24mm,top=24mm}
+
+
+\thispagestyle{empty}
+
+\tableofcontents
+
+\thispagestyle{empty}
+
+\newpage
+
+\thispagestyle{empty}
+
+\section*{Nomenclature}
+
+\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.
+ \item \textbf{Malware} Malicious software designed to attack the security of a computer/computer network.
+\end{itemize}
+
+\thispagestyle{empty}
+
+\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.}
+
+\thispagestyle{empty}
+
+\newpage
+\pagenumbering{arabic}
+
+\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. For example, in 2015 the Ukrainian power grid's industrial control system was attacked causing 225,000 people to lose power for several hours\cite{case2016analysis}. \\
+
+
+\begin{centering}
+ \begin{figure}[!h]
+ \centering
+ \includegraphics[scale = 0.432]{ref.png}
+ \caption{Reference diagram of my smart grid scenario}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+\newpage
+
+The scenario for my project is an IoT based smart grid with a focus on the communications between IoT devices and their interactions with the cloud layer. The reference diagram above details the devices present in the system. The devices within the home network are installed in each household and interact with their local cloud server which manages all the households in an area.
+
+This project focuses mainly on IoT communication protocols and their configuration rather examine flaws in the hardware or firmware ran by these devices.
+
+
+\subsection{Project Aims and Objectives}
+
+This project aims to produce, model and verify a collection of policies that are suitable for mitigating the threats that an IoT enabled smart grid may face. I wish to focus on the following goals within this project:
+
+\begin{itemize}
+
+\item Conduct a risk assessment on the main vulnerabilities and threats faced by IoT devices within a smart grid environment.
+
+\item Recommend security policies that can mitigate these threats, justifying these policies by clearly linking them to specific threats.
+
+\item Implement and verify that these communication protocols mitigate the identified vulnerabilities using Scyther, a formal method based protocol verification tool.
+
+\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}
+
+\newpage
+
+\section{Literature Review}
+
+My literature review explores the IoT and smart grid landscape before looking into the cybersecurity issues that a smart grid 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 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 then 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.
+\\
+
+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 benefits of a 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 key some key differences as shown below:
+
+\begin{itemize}
+ \item \textbf{Modelling Language -} Scyther uses 'security protocol description language' (SPDL) 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 the easier to understand modelling language and attack graph feature identified in Dalal's comparison, the project will used scyther for the modelling and verification of security protocol
+\newpage
+
+\subsection{Discussion}
+
+My research into the literature surrounding smart grid security brings up the issue that a smart grid system faces additional cybersecurity obstacles compared with a traditional industrial network. This is partially due to the nature of the system itself as smart grids comprise of mainly low power devices being distributed across a large area, resulting in additional factors that must be considered when applying common cybersecurity controls. Another reason for these additional obstacles is the cyber threat landscape that smart grids face. As smart grids form part of a nation's critical national infrastructure, they can become a target for state-funded advanced persistent threat groups capable of more advanced attacks than a typical cyber threat actor.
+
+
+\subsection{Conclusion}
+
+My literature review has highlighted that smart grids require a bespoke security plan due to the unique challenges they face. To respond to this, the project will investigate and produce a list of vulnerabilities based specifically on the smart grid scenario outlined in the project description section. My research has also shown that when verifying a protocol by hand, it is near impossible to find every attack scenario and therefore a method of verifying protocols automatically using formal methods is required. The project will use Scyther for this based on the advantages outlined in the comparative review of Scyther and Pro-Verif.
+
+
+\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 posed by each 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 the most suitable tools to create this, 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 using git. 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]
+\caption{Table showing the prioritisation of the Scytherbox requirements}
+\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|}{}
+\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}
+\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 an 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]
+\caption{Table describing and estimating the size of each Scytherbox requirement}
+\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 & 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 & Medium \\ \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
+Scyther user guide & A guide installed on the box explaining the basics of Scyther & Medium \\ \hline
+Windows version & A version of the Scytherbox that uses Windows as the box's operating system & Extra Large \\ \hline
+\end{tabular}
+\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 sprint.
+
+\begin{table}[h]
+\caption{Scytherbox sprint plan}
+\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|}{} & Installation Instructions \\
+\multicolumn{1}{c|}{Shared folder} & \multicolumn{1}{c|}{} & \\
+\textbf{Sprint Hours: 6} & \textbf{Sprint Hours: 5} & \textbf{Sprint Hours: 6}
+\end{tabular}
+\end{table}
+
+\subsubsection{Implementation of development plan}
+
+The first sprint featured the essential elements required to develop using Scyther, development for this sprint went largely as expected and after overcoming an issue in the first two days of the sprint relating to creation of the initial base box, the remaining tasks fell away quickly.
+
+\begin{centering}
+ \begin{figure}[!h]
+ \centering
+ \includegraphics[scale = 0.53]{sprint1.PNG}
+ \caption{Breakdown of the work completed in the first sprint}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+
+One 'Could Have' requirement from Sprint 2 was not completed which was to allow the user to set up a Git configuration within the environment using the VagrantFile. After researching the methods that could be used to do this, I came to the conclusion that a VagrantFile git setup would be more time intensive to set up than I anticipated and it would be difficult to design in a way that is easy to use.
+
+\begin{centering}
+ \begin{figure}[!h]
+ \centering
+ \includegraphics[scale = 0.53]{sprint2.PNG}
+ \caption{Breakdown of the work completed in the second sprint}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+\newpage
+
+Sprint 3 featured the requirements that would improve the experience for others using the Scyther environment in the future and was completed according to plan.
+
+\begin{centering}
+ \begin{figure}[!h]
+ \centering
+ \includegraphics[scale = 0.53]{sprint3.PNG}
+ \caption{Breakdown of the work completed in the third sprint}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+
+
+\newpage
+
+\subsection{Threat Model}
+
+The threat model below shows the key attack vectors and vulnerabilities an adversary could exploit within the scenario:
+
+\begin{centering}
+ \begin{figure}[!h]
+ \centering
+ \includegraphics[scale = 0.48]{ref.png}
+ \caption{Threat Model of my smart grid scenario}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+
+
+
+\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 almost 500,000 IoT devices using short list of common passwords \cite{kambourakis2017mirai}.
+\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 their contents.
+
+\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 a 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 reusing 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 authentication credentials to send messages to the server posing as that home network without needing to know the actual encryption key used.
+
+
+\newpage
+
+\subsubsection{Impersonation Attack}
+
+An Impersonation attack occurs when an Adversary is able to pose as the identity 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 malware such as the Mirai botnet scan for insecure open 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. Whilst any unnecessary open ports increase risk exposure, communication ports such as Telnet (port 23) are particularly dangerous as they lack any in-built security measures.
+\newpage
+
+\subsubsection{Network Traversal}
+
+Network traversal can allow malware on a compromised network to spread to other networks connected to it. Malware's such as ransomware and worms often employ this technique to spread to as many users as possible. This is a serious issue for high security systems that have to interface with home networks as the home network is likely to have much poorer security controls.
+
+
+\begin{centering}
+ \begin{figure}[h]
+ \centering
+ \includegraphics[scale = 0.6]{Networktraversal.PNG}
+ \caption{Malware traversing from an infected home network to industrial network}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+This attack could occur in the IoT scenario as the smart hub is connected to the homeowner's network and communicates with the smart monitor. If a malware on a user's home network is able to compromise the smart monitor, an adversary could gain remote control over the device and use it to make further attacks on the system.
+
+
+\subsubsection{Software Vulnerability}
+
+As time passes, it's likely that vulnerabilities will be found in any given piece of software, patches are usually released quickly to fix these vulnerabilities. However, some of the most devastating cyberattacks of recent years relied on already patched exploits to work. A clear example of this is WannaCry ransomware, the Windows vulnerability that the malware exploited had been patched over a month before it appeared\cite{mattei2017privacy}. Despite this, thousands of organisations were hit that did not patch this vulnerability including critical national infrastructure such as the National Health Service.
+
+\begin{centering}
+ \begin{figure}[h]
+ \centering
+ \includegraphics[scale = 0.6]{Software.PNG}
+ \caption{Adversary exploiting an unpatched IoT device}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+Software vulnerabilities could occur on software used by any of the devices within the smart grid system. Patches must be applied in a timely and sensible fashion to minimise the risk exposure one of these vulnerabilities being exploited.
+
+
+
+\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 that communications between devices must follow. 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{description}
+
+\item[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}.
+
+
+\end{description}
+
+\begin{description}
+
+\item[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 secret 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.
+
+\end{description}
+
+\begin{description}
+
+\item[Session Keys]
+
+
+Session keys are freshly 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 already shared in the key distribution process. This policy is 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 run will never be reused as they are regenerated for each new communication.
+
+\end{description}
+
+\begin{description}
+
+\item[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{description}
+
+
+
+\newpage
+
+
+\subsection{Description and specification of IoT Best Practices}
+
+The policies defined in this section are designed to mitigate the non-communication based threats a smart grid faces. The sections below justify the need to implement each practice and provide information on how each practice can be implemented into a smart grid scenario.
+
+
+\subsubsection{Password Management}
+
+The password management policy is designed to prevent the success of popular automated password fuzzing attacks which often target IoT devices \textbf{(section 4.2.2)}.
+
+In a study examining user behaviour toward password policies, Inglesant\cite{10.1145/1753326.1753384} found that excessively restrictive password policies 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 lists 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 Default passwords should be a 15 character string of random characters, this serves two purposes by making the default password less susceptible to fuzzing attacks whilst also encouraging the user to change their password from the default due to the inconvenience of entering the default password.
+
+ \item Passwords must be at least 8 characters long. This is the minimum length recommended by NIST for memory based authentication methods as of 2017 \cite{grassi2017nist}. Whilst even longer passwords do provide more security, a minimum of 8 allows the password to be easier for the user to remember, reducing the chance of insecure workarounds being used.
+
+ \item Before hashing, passwords should be checked against OWASP's top 10,000 password list\cite{TopPasswords}. This is because password fuzzing attacks look to try the most common passwords before using brute force methods.
+
+ \item User created passwords must not be reused across other platforms. User credentials stolen in large commercial data breaches are usually sold online, this often occurs without the user knowing that their password has been leaked.
+
+\end{itemize}
+
+One notable exception from this list common in other password policies is a requirement to change the password every set period. Whilst in circumstances where the expectation on the user is higher for managing their passwords such as a organisational account with access to confidential information. It was not deemed necessary here as the advantage of having a password change every few months is outweighed by the frustration this will cause users likely leading to the use of low effort passwords.
+
+\subsubsection{Network Segregation}
+
+Whilst the IoT smart grid system as a whole is an industrial system, meters and monitors are installed in peoples homes. Because of this, the implementation of a network segregation policy is necessary to prevent vulnerabilities in other networks manifesting in the IoT system \textbf{(section 4.2.7)}. The main challenge when considering the given scenario is the smart hub. The smart hub connects to the homeowner's WiFi network and visually displays information about their electricity usage to them. The concern is that without proper controls, a poorly secured home network could provide a route for malware to enter the industrial system.
+
+To effectively segregate a network from another, two criteria are required. The first criteria is to reduce the points of contact between the two networks as much as possible, networks that are deeply intertwined make the sanitisation of network traffic between them much harder. In the given IoT scenario this has been reduced to a single point of contact between the smart monitor and smart hub. As the smart hub has no direct contact to either the cloud server or the smart meters in the household. The number of attack vectors for network traversal is decreased and therefore securing the points of contact is less complex.
+
+The second criteria is using a well configured firewall at points of contact between the two networks. Firewalls are a security control used to monitor and block communications between parties based on a set of defined rules. In the case of the IoT scenario, rules should be defined to only allow outgoing traffic from the smart monitor to the smart hub, this can be implemented as the smart hub's function is to display information to the homeowner that the smart monitor sends it therefore a one way communication is sufficient to do this.
+
+\subsubsection{Patch Management}
+
+This policy is designed to mitigate the threat of software vulnerabilities \textbf{(section 4.2.8)}. When a vulnerability is discovered in software used by a system there are two options for mitigation. The first is to isolate the system from any outside connections and employ restrictive policies to limit how the system can be accessed. This is not an option in a smart grid scenario as the IoT devices need to communicate with each other to perform their core functionalities, the distributed layout of a smart grid also makes isolation much more challenging as devices are spread across different networks and physical locations. The second option is apply a security patch fixing the vulnerability. Large, always on and distributed systems such as smart grids face difficult challenges when managing the application of patches as applying a security update across the system is a much more time intensive process compared to a traditional network. This becomes an important factor when considering that a smart grid system does not have inactive hours where software updates can be installed overnight.
+
+Patch bundling is a technique which can be used to reduce the number of security patches required over a period of time by bundling all required updates into a single patch which is applied every 3 months. However, this comes with significant drawbacks as it introduces a delay between the time a patch is released and the time it applied, this increases the time that the system is vulnerable and therefore the chance that an adversary will exploit it. NIST recommends that patches be prioritised based on the threat that a vulnerability poses to a system. With severe vulnerabilities that are being actively exploited, patches should be applied as soon as possible whereas the patching of vulnerabilities which pose a lower threat can be delayed until the next patch bundle\cite{souppaya2013guide}. CVSS(Common Vulnerability Scoring System) is a method of rating the threat that a vulnerability poses on a 0-10 scale, it takes into account the severity of vulnerability if it were to be exploited, how easy it is to exploit and how much access an adversary needs to exploit it. By using this score, a patch management policy can be created for each level of threat.
+
+\begin{table}[h!]
+\caption{Patch Management policy based on the CVSS score of a vulnerability}
+\begin{tabular}{|c|m{12cm}|}
+\hline
+\textbf{CVSS score} & \textbf{Patching Policy} \\ \hline
+\textbf{0-4} & Updates for these vulnerabilities pose a reduced threat to the system and should only be implemented as part of the next planned patch. \\ \hline
+\textbf{4-6} & Updates for vulnerabilities in this category should be evaluated on a case by case basis and either implemented as part of the next planned patch or applied after a week to give time for testing \\ \hline
+\textbf{6-8} & Updates for these vulnerabilities should be applied in the week that they are released. \\ \hline
+\textbf{8-10} & Vulnerabilities in this category must be patched as soon as possible, if an update is not yet available the possibility of workarounds or reducing functionality to mitigate the threat should be considered. \\ \hline
+\end{tabular}
+\end{table}
+
+
+
+
+
+\subsubsection{Minimum Design}
+
+Minimum design refers to the practice of limiting the configuration of a device to the absolute minimum required for the device to function within it's role. A well implemented minimum design policy reduces a device's risk exposure to cyberattacks whilst not compromising it's functionality. One of the key threats the minimum design policy counters is open port scanning \textbf{(section 4.2.7)}. By default the IoT devices used in the smart grid system will have been configured to accept packets from a large range of network services. However, the vast majority of these ports are not necessary for their functionality within the smart grid system.
+
+To limit these network services there are two opposing filtering techniques that can be used, blacklisting and whitelisting. Blacklisting refers to creating a list of in this case network services that are to be filtered out whereas whitelisting refers to filtering out everything except for a specific list of services. In this scenario whitelisting is the most sensible option as the smart devices have explicit communication roles and all other communication ports are not required.
+
+
+
+
+
+\newpage
+
+\section{Implementation and modelling of communication protocol policies }
+
+
+\subsection{Message Encryption}
+
+The first policy to be implemented is message encryption. The aim of this policy is to mitigate the threat of passive eavesdropping. Whilst the implementation of this policy alone forms a very basic protocol, it makes up the backbone that the more advanced protocols will be based on.
+
+\textbf{Policy Criteria}
+
+\begin{itemize}
+
+\item Message contents must be secure against an adversary passively eavesdropping on the communication.
+\item The monitor must be able to decrypt and read the message contents from the meter.
+
+\end{itemize}
+
+\subsubsection{Design}
+
+The protocol's design is a basic symmetric key encryption protocol where the Meter sends the Monitor a message containing electricity usage information. Once the message is received, the Monitor sends back a confirmation message.
+
+
+\begin{centering}
+ \begin{figure}[h]
+ \centering
+ \includegraphics[scale = 0.9]{encrypt.png}
+ \caption{Message encryption protocol design }
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+\newpage
+
+\subsubsection{Implementation}
+
+To model the symmetric encryption method used for this protocol, the key (k) is used to represent a symmetric key. As this protocol does not feature a key distribution element, the key is a default key loaded onto each device as part of their initial configuration for use in the smart grid system.
+
+\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 criteria of the message contents not being readable to an eavesdropping adversary, Scyther's Secret claim was made on the message which models an adversary attempting to eavesdrop on the message during communication. By modelling this claim on both the Monitor and Meter it can also be used to check that the monitor has received the message thereby fulfilling the second policy criteria.
+
+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.7]{01Comparison.PNG}
+ \caption{Attack on a protocol without encryption }
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+The figure above shows that by eavesdropping the un-encrypted commutation, the adversary can read the contents of the message therefore disproving the secret claim.
+
+The first iteration of the protocol passed the defined tests with Scyther showing that no attacks of this type are possible. 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]
+\centering
+\caption{Log of claims made against the message encryption protocol and their results}
+\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}
+\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.
+
+\textbf{Policy Criteria}
+
+\begin{itemize}
+
+\item The secret key must not be interceptable by an eavesdropping adversary
+\item Parties must be able to identify the sender of each step of the protocol to prevent an adversary impersonating a party.
+\item Parties must both have the same secret key at the end of the protocol.
+
+\end{itemize}
+
+\subsubsection{Design}
+
+When designing 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.
+
+\begin{centering}
+ \begin{figure}[h]
+ \centering
+ \includegraphics[scale = 0.7]{Needham Schroeder.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 never actually sends a shared key over an insecure network but instead exchanges information that along with secret information both parties posses, 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 an additional server.
+
+The design for this policy in the project scenario 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.78]{KeyExhange.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.
+
+
+\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}
+ \newpage
+\subsubsection{Review}
+
+To test the criteria that the secret key is not interceptable through eavesdropping, Scyther's Secret claim will be used on both the cloud server and monitor value. If these secret claims hold, the criteria will be verified as an adversary would need to eavesdrop on at least one of the values to intercept the key.
+
+
+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. If these claims hold, then an impersonation attack is not possible and the \nth{2} criteria which specifies security against this form of attack will be verified.
+
+The 3rd Criteria, which states that both parties must be able to agree on a shared secret key can be verified by ensuring that both parties posses both the cloud server and monitor value at the end of the protocol. This can again be verified using the Secret claim as it will only pass if the role specified does have access to the object the secrecy claim is being made on.
+
+
+\begin{table}[h]
+\centering
+\caption{Log of claims made against the key distribution protocol and their results}
+\begin{tabular}{@{}lll@{}}
+\toprule
+\textbf{Role} & \textbf{Claim} & \textbf{Result} \\ \midrule
+\textbf{Monitor} & Niagree & Pass \\
+ & Nisynch & Pass \\
+ & Secret, MonitorValue & Pass \\
+ & Secret, CloudServerValue & Pass \\
+\textbf{Cloud Server} & Niagree & Pass \\
+ & Nisynch & Pass \\
+ & Secret, MonitorValue & Pass \\
+ & Secret, CloudServerValue & Pass \\ \bottomrule
+\end{tabular}
+\end{table}
+
+
+
+
+
+\newpage
+
+\subsection{Unique Session Keys}
+
+Implementing fresh session keys between parties for each communication is a policy aimed at preventing replay attacks when the monitor sends energy usage information to the cloud server. Communication parties have established a shared secret key using the key distribution policy in the section above. A protocol is now required that generates session keys using this secret key and defines how messages are to be encrypted with them.
+
+\textbf{Policy Criteria}
+
+\begin{itemize}
+
+\item The session key used for each communication must be unique
+\item The cloud server must be able to authenticate that the monitor it sends information to is legitimate
+
+\end{itemize}
+
+
+\subsubsection{Design}
+
+By deriving session keys from the shared secret key now present between both communication parties, it is possible to design a simple protocol that meets the policy criteria. Simplicity is an important factor for this protocol as the communication between the monitor and cloud server where current electricity usage is sent is very frequent and therefore should be as lightweight as possible.
+
+ \begin{centering}
+ \begin{figure}[h]
+ \centering
+ \includegraphics[scale = 0.75]{Session Keys.png}
+ \caption{Illustration of a one-way communication utilising session keys \cite{10.1007/3-540-61770-1_46}}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+\subsubsection{Implementation}
+
+In Scyther, the SessionKey usertype can be used to model a session key. The fresh prefix during the initialisation of the key (line 14 and line 24) denotes that a new key is generated for each communication. To model the information exchange between the two parties after the session key is established, a Message user type has been defined. \\
+
+\begin{lstlisting}[numbers=left,firstnumber=0,stepnumber=1]
+hashfunction hashed;
+hashfunction sharedkey;
+usertype Message;
+usertype SessionKey;
+
+protocol SessionKeys(Monitor,CloudServer) {
+
+ role Monitor {
+
+ fresh MonitorValue : Nonce;
+ var CloudServerValue : Nonce;
+
+ fresh info : Message;
+ var info: Message;
+ fresh sharedkey: SessionKey;
+
+ send_1(Monitor,CloudServer,{Monitor,MonitorValue}pk(CloudServer));
+
+ recv_2(CloudServer,Monitor, {CloudServerValue,hashed(MonitorValue),
+ CloudServer}pk(Monitor));
+
+ send_3(Monitor,CloudServer, {info} sharedkey);
+
+ claim_Monitor1(Monitor,Alive);
+ claim_Monitor2(Monitor,Secret, info);
+ }
+
+ role CloudServer {
+
+ var MonitorValue: Nonce;
+ fresh CloudServerValue: Nonce;
+
+ var info: Message;
+ fresh info: Message;
+ fresh sharedkey: SessionKey;
+
+ recv_1(Monitor,CloudServer,{Monitor,MonitorValue}pk(CloudServer));
+
+ send_2(CloudServer,Monitor, {CloudServerValue,hashed(MonitorValue),
+ CloudServer}pk(Monitor));
+
+ recv_3(Monitor,CloudServer, {info} sharedkey);
+
+ claim_CloudServer1(CloudServer,Niagree);
+ claim_CloudServer2(CloudServer,Nisynch);
+ claim_CloudServer3(CloudServer,Alive);
+ claim_CloudServer4(CloudServer,Secret, info);
+ }
+}
+
+
+\end{lstlisting}
+
+\subsubsection{Review}
+
+To model the policy criteria in Scyther, the Alive and Niagree/Nisynch claims will be used to verify that the cloud server is able to authenticate the monitor, for this protocol only one way authentication is required as the communication is one-way. Alive verifies that the protocol has completed all the protocol's steps in the specified order. This ensures that the session key is agreed upon before communications occur and is how the unique session key requirement for this protocol will be verified.
+
+
+As shown in the figure below, without the implementation of session keys it is trivial for an adversary to reuse credentials from previous communications.
+
+
+ \begin{centering}
+ \begin{figure}[h]
+ \centering
+ \includegraphics[scale = 0.55]{02ComparisionBefore.PNG}
+ \caption{Replay attack before the implementation of session keys}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+After the implementation of session keys this replay attack is no longer possible and the protocol is able to meet all of the specified criteria as shown by the results table below .
+
+\begin{table}[h]
+\centering
+\caption{Log of claims made against the session key protocol and their results}
+\begin{tabular}{@{}lll@{}}
+\toprule
+\textbf{Role} & \textbf{Claim} & \textbf{Result} \\ \midrule
+\textbf{Monitor}
+ & Monitor, Alive & Pass \\
+ & Secret, info & Pass \\
+\textbf{Cloud Server} & Niagree & Pass \\
+ & Nisynch & Pass \\
+ & Cloud Server,Alive & Pass \\
+ & Secret, info & Pass \\ \bottomrule
+\end{tabular}
+\end{table}
+
+
+
+\newpage
+
+
+
+\subsection{Mutual Authentication}
+
+Whilst the session keys protocol is effective at establishing a secure connection between monitor and cloud server as well as allowing the cloud server to authenticate the identity of the monitor sending information. It's possible for an adversary to pose as a cloud server and establish a communication channel with the monitor.
+
+\textbf{Policy Criteria}
+
+\begin{itemize}
+
+\item The session key used for each communication must be unique
+\item Both parties must be able to authenticate the identity of the other.
+
+
+\end{itemize}
+
+\subsubsection{Design}
+
+The design for this protocol is based of the design of the preceding session keys protocol. Due to the increased number of messages sent in a single round of this protocol and the need for additional authentication, this protocol will not be as lightweight as the session keys protocol.
+
+ \begin{centering}
+ \begin{figure}[h]
+ \centering
+ \includegraphics[scale = 0.74]{Mutual Authentication.png}
+ \caption{Illustration of a two-way mutually authenticated protocol \cite{10.1007/3-540-61770-1_46}}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+However, the two-way communication where the Cloud Server sends electricity pricing information to the smart monitor as well as receiving electricity usage does not occur as frequently as the one-way sending of electricity usage meaning the complexity of this protocol is not as much of a concern.
+
+\newpage
+
+\subsubsection{Implementation}
+
+\begin{lstlisting}[numbers=left,firstnumber=0,stepnumber=1]
+hashfunction hashed;
+hashfunction sharedkey;
+usertype Message;
+usertype SessionKey;
+
+protocol MutualAuthentication(Monitor,CloudServer)
+{
+ role Monitor {
+
+ fresh MonitorValue : Nonce;
+ var CloudServerValue : Nonce;
+
+ fresh MonitorInformation : Message;
+ var CloudServerInformation: Message;
+ fresh sharedkey: SessionKey;
+
+
+ send_1(Monitor,CloudServer,{Monitor,MonitorValue}pk(CloudServer));
+
+ recv_2(CloudServer,Monitor, {CloudServerValue,hashed(MonitorValue),
+ CloudServer}pk(Monitor));
+
+ send_3(Monitor,CloudServer,{CloudServerValue, MonitorInformation} sharedkey );
+
+ recv_4(CloudServer,Monitor,{MonitorValue,CloudServerInformation} sharedkey);
+
+ claim_Monitor1(Monitor,Niagree);
+ claim_Monitor2(Monitor,Nisynch);
+ claim_Monitor3(Monitor, Secret, CloudServerInformation);
+ claim_Monitor4(Monitor,Alive);
+
+ }
+
+ role CloudServer {
+
+ var MonitorValue: Nonce;
+ fresh CloudServerValue: Nonce;
+
+ fresh CloudServerInformation: Message;
+ var MonitorInformation: Message;
+ var sharedkey: SessionKey;
+
+ recv_1(Monitor,CloudServer,{Monitor,MonitorValue}pk(CloudServer));
+ send_2(CloudServer,Monitor, {CloudServerValue,hashed(MonitorValue),
+ CloudServer}pk(Monitor));
+
+ recv_3(Monitor,CloudServer, {CloudServerValue, MonitorInformation} sharedkey );
+
+ send_4(CloudServer,Monitor,{MonitorValue,CloudServerInformation} sharedkey);
+
+ claim_CloudServer1(CloudServer,Niagree);
+ claim_CloudServer2(CloudServer,Nisynch);
+ claim_CloudServer3(CloudServer, Secret, MonitorInformation);
+ claim_CloudServer4(CloudServer,Alive);
+
+ }
+}
+\end{lstlisting}
+
+\subsubsection{Review}
+
+To model the mutual authentication policy criteria that both parties must be able to authenticate the identity of each other, Niagree/Nisynch as well as the alive claim will be verified for both the cloud server and monitor, this provides assurance that both parties in the communication are able to authenticate each other. Secret claims on the monitor and cloud server information will be used to verify that the message contents cannot be intercepted through eavesdropping. To verify that the session key is unique, the Alive claim will be used as it was in the session key protocol.
+
+\begin{table}[h]
+\centering
+\caption{Log of claims made against the mutual authentication protocol and their results}
+\begin{tabular}{@{}lll@{}}
+\toprule
+\textbf{Role} & \textbf{Claim} & \textbf{Result} \\ \midrule
+\textbf{Monitor} & Niagree & Pass \\
+ & Nisynch & Pass \\
+ & Secret, CloudServerInformation & Pass \\
+ & Alive, Monitor & Pass \\
+\textbf{Cloud Server} & Niagree & Pass \\
+ & Nisynch & Pass \\
+ & Secret, MonitorInformation & Pass \\
+ & Alive, CloudServer & Pass \\ \bottomrule
+\end{tabular}
+
+\end{table}
+
+As shown by the Scyther results, this protocol has been verified to meet all of the policy criteria. This protocol implements all of the preceding policies as well and therefore is cryptographically secure against all the identified communication based threats in the threat model \textbf{(section 4.2)}.
+
+\newpage
+
+\section{Project Management}
+
+All deliverables for this project were completed within the required deadlines, this section details the measures that were taken to manage the project and ensure that this was the case
+
+The main tool used for macro project management was the Gantt chart. The chart below details how I planned to complete the required tasks for this project.
+
+\begin{centering}
+ \begin{figure}[!h]
+ \centering
+ \includegraphics[scale = 0.42]{GanttPlanned.PNG}
+ \caption{Gantt chart detailing planned project scheduling}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+The majority of the project plan featured time spent on either learning or developing using the Scyther tool. This was a good decision in hindsight as coming into Scyther for the first time was a challenging experience and it took time to learn how the software worked before I could produce anything of value.
+
+
+
+
+\newpage
+
+
+\subsection{Coronavirus Mitigation}
+
+The threat that access to Scyther and university computers could be lost was identified on my risk matrix and was one of the reasons the creation of a portable Scyther development environment is part of this project. As a result of this, the effect that coronavirus had on my ability to complete my project goals was negligible. Despite this, the virus had a large impact on the scheduling of the project as shown by the gantt chart below detailing how project work was actually completed.
+
+\begin{centering}
+ \begin{figure}[!h]
+ \centering
+ \includegraphics[scale = 0.42]{GanttActual.PNG}
+ \caption{Gantt chart detailing how work on the project was actually completed}
+ \label{fig:my_label}
+ \end{figure}
+\end{centering}
+
+
+
+
+
+Tasks in progress around the \nth{23} of March such as the modelling of policies in Scyther took longer than anticipated due to relocating home, preparing for and settling into the quarantine however the 2 week deadline extension given negated this.
+
+
+
+To stay in contact with my supervisor and ensure I still benefited from their feedback without physical meetings, Microsoft Teams was used to schedule online meetings. The project is hosted on the University GitLab and issue boards were used to track my progress through each task as well as keep my supervisor informed about what I was working on at a given time.
+
+\newpage
+
+\subsection{Risk Management}
+
+To catalogue and plan mitigation against risks which could pose issues for the project, a risk management matrix was created outlining the key risks the project faces. To measure the threat level each risk posed a scoring system was used, each risk was rated out of 5 based on how likely the risk was to occur and the magnitude of impact if it did, these values were then multiplied together to give a risk score out of 25. Each risk was assigned a baseline score which represents the level of risk before any mitigation was put in place and a residual risk score showing the level of risk after the mitigation plan is put in place.
+
+\begin{table}[h]
+\caption{Qualitative risk analysis and mitigation plan for key project risks}
+\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/allowed on the university computers 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. This allows for the easy transfer of work over to personal devices & \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
+Sections of work are larger or more difficult than anticipated meaning I fail to complete parts of the project & \begin{tabular}[c]{@{}c@{}}Impact: 4\\ Likelihood: 3\\ Score: 12\end{tabular} & My background research and experience of learning Scyther has helped me estimate the difficulty of each task. The scheduling of tasks in the project will assign extra time in each task for potential delays that may occur due to unexpected difficulties. & \begin{tabular}[c]{@{}c@{}}Impact: 3\\ Likelihood: 2\\ Score: 6\end{tabular} \\ \hline
+Personal/family issue occurs & \begin{tabular}[c]{@{}c@{}}Impact: 4\\ Likelihood: 3\\ Score: 12\end{tabular} & Whilst this risk is difficult to mitigate, the university support service will be used if needed and I will keep my supervisor informed of any issues. & \begin{tabular}[c]{@{}c@{}}Impact: 3\\ Likelihood: 3\\ Score: 9\end{tabular} \\ \hline
+
+\end{tabular}
+\label{tbl:Risk}
+\end{table}
+
+\newpage
+
+\subsection{Reflection on Scytherbox Development Plan}
+
+Overall, the structure of the Scytherbox development plan worked well in ensuring that the required features were implemented on time. Implementing all must have requirements in the first sprint allowed me to work on modelling policies as soon as this sprint was completed which was inline with my initial project plan. When examining the completion of requirements, two functional requirements were either not completed or adapted.
+
+The first of these was allowing the user to integrate a git repository using the Vagrant file. This requirement was changed as I found that creating a section within the shared folder for Git repositories was a more elegant solution and much easier to use. This means that changes made to the repository in the development environment are automatically reflected in the host machine side of the shared folder. Changes can then be pushed to the remote git branch using the user's choice of git client from the host machine.
+
+The second was that the Scyther user guide differs from the original design as the official Scyther manual was found to explain the basics of Scyther development well. Instead of writing a general Scyther guide, this manual was included in the virtual machine
+
+
+
+
+\newpage
+
+
+\section{Project Evaluation}
+
+This section examines the success of the project and details the future plans for this work.
+
+
+\subsection{Achievement against project goals}
+
+To evaluate the project's success, the achievements made during the course of the project will be compared against against the initial project goals
+
+
+\textbf{1. Conduct a risk assessment on the main vulnerabilities and threats faced by IoT devices within a smart grid environment.}
+
+After extensive research, a threat model showing the key vulnerabilities faced by a smart grid system was produced. Each vulnerability was described, and the specific threat it posed to the smart grid system documented.
+
+\textbf{2. Recommend security policies that can mitigate these threats, justifying these policies by clearly linking them to specific threats.}
+
+A set of policies based on industry standards was created to specifically mitigate the vulnerabilities identified during the threat analysis. Design choices for these policies were justified with supporting literature and where necessary the potential disadvantages of each policy were discussed.
+
+\textbf{3. Implement and verify that these communication protocols mitigate the identified vulnerabilities using Scyther, a formal method based protocol verification tool.}
+
+Communication policies and their criteria were modelled in Scyther, the review section for each policy explained how each criteria was converted into Scyther claims. The final versions of all policies passed their verification in Scyther confirming that they are fit for purpose.
+
+\textbf{4. 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.}
+
+The Scyther environment was successfully created and utilised in the modelling and verification of the project's policies. The versionable nature of VagrantFiles make it easy for others to set up and add to the virtual machine to suit their needs.
+
+\newpage
+
+\subsection{Conclusion}
+
+Though the course of this project, a set of security policies have been designed,implemented and verified to mitigate the threats that IoT devices within a smart grid system face, as summarised in the table below.
+
+\begin{table}[h!]
+\centering
+\caption{List of threats identified for the smart grid scenario and the policies that mitigate them}
+\begin{tabular}{|c|c|}
+\hline
+\textbf{Threat} & \textbf{Mitigating Policies} \\ \hline
+Password Fuzzing & Password Management \\ \hline
+Man In The Middle Attack & Mutual Authentication \\ \hline
+Passive Eavesdropping & Message Encryption, Implicit Key Authentication \\ \hline
+Replay Attack & Session Keys, Implicit Key Authentication \\ \hline
+Impersonation Attack & Mutual Authentication \\ \hline
+Open Port Scanning & Minimum Design \\ \hline
+Network Traversal & Network Segregation \\ \hline
+Software Vulnerability & Patch Management \\ \hline
+\end{tabular}
+\end{table}
+
+The project shows that whilst the introduction of smart grids to a country's power grid does introduce the possibility of cyberattacks against critical national infrastructure, with proper security controls these threats can be identified and mitigated. The project also explored the use of Scyther for the modelling and verification of security protocols, demonstrating it's ability to find flaws based on the security requirements defined for each protocol.
+
+\subsection{Future Plans}
+
+An aim for the future is to submit this project to the 2020 International Verification and Security Workshop. This will allow for the sharing of this project's results with the wider cybersecurity community as well as gaining the perspective of industry leaders as to how this project could be developed on and improved in the future.
+
+One of the key difficulties of learning Scyther for this project was the lack of internet resources available for those new to cryptographic protocol verification. This project has the capability to provide a starting point for others that wish to verify security policies using Scyther. Through my time on this project, my supervisor has found and I have made contact with a PhD student at the university who is interested in using Scyther as part of their research project. The research and protocols developed in this project will be made available to them. With the longer project schedule and higher level of academic experience the student could take the cryptographic protocol modelling demonstrated in this report to a higher level. The Scyther development environment created for this project will also be made publicly available for others to use.
+
+This project provides a high level overview of the cyber threat landscape faced by smart grids. Further work could focus on a single threat in far greater detail than was possible in this project. For example, a project focusing on session keys alone would allow for an analysis into the specific algorithm used to derive keys and a more detailed analysis of how replay attacks occur.
+
+\vspace{0.3cm}
+
+\begin{centering}
+
+ Word count: 9,996 \\
+ using Foxit PDF reader
+
+\end{centering}
+
+
+
+
+
+
+
+\newpage
+
+\bibliographystyle{unsrt}
+\bibliography{references.bib}
+
+\newpage
+
+\begin{appendices}
+
+\section{Project Archive File Tree}
+
+\begin{forest}
+ for tree={
+ font=\ttfamily,
+ grow'=0,
+ child anchor=west,
+ parent anchor=south,
+ anchor=west,
+ calign=first,
+ edge path={
+ \noexpand\path [draw, \forestoption{edge}]
+ (!u.south west) +(7.5pt,0) |- node[fill,inner sep=1.25pt] {} (.child anchor)\forestoption{edge label};
+ },
+ before typesetting nodes={
+ if n=1
+ {insert before={[,phantom]}}
+ {}
+ },
+ fit=band,
+ before computing xy={l=15pt},
+ }
+[DesignArchive // Contains all files required to run the Scytherbox
+ [Protocols // The four protocols verified using Scyther in this project
+ [ImplicitKeyAuthentication.spdl]
+ [MessageEncyption.spdl]
+ [MutualAuthentication.spdl]
+ [SessionKeys.spdl]
+ ]
+ [VagrantScytherboxFiles
+ [files // These files are placed on the desktop inside the Scytherbox
+ [scyther // Contains the files required to run Scyther]
+ [guide // User guide for starting up Scyther and using the Scytherbox]
+ [scyther-manual // Official Scyther manual]
+
+ ]
+ [Shared // Files in this folder are synced between host and virtual machine
+ [GitLink // Git repositories go here]
+ ]
+
+ [InstallationInstructions]
+ [scyther.sh // Installs the Scyther dependencies and configures environment]
+ [scytherpermissions.sh // Adds the required permissions for Scyther to run]
+ [VagrantFile // Virtual Machine is initialised from the specifications in this file]
+
+ ]
+]
+\end{forest}
+
+\end{appendices}
+
+\end{document}
diff --git a/Design Files/Latex/ref.png b/Design Files/Latex/ref.png
new file mode 100644
index 0000000000000000000000000000000000000000..c7f1a15508b31e614940e1e249ed569934eff75d
Binary files /dev/null and b/Design Files/Latex/ref.png differ
diff --git a/Design Files/Latex/references.bib b/Design Files/Latex/references.bib
new file mode 100644
index 0000000000000000000000000000000000000000..7da2a27c27dbe98d8e0f96a4ad7ab416b2803084
--- /dev/null
+++ b/Design Files/Latex/references.bib
@@ -0,0 +1,281 @@
+@misc{ Nobody06,
+ author = "Nobody Jr",
+ title = "My Article",
+ year = "2006" }
+
+@article{robles2009assessment,
+ title={Assessment of the vulnerabilities of SCADA, control systems and critical infrastructure systems},
+ author={Robles, Rosslin John and Choi, Min-kyu},
+ journal={Assessment},
+ volume={2},
+ number={2},
+ pages={27--34},
+ year={2009},
+ publisher={Citeseer}
+}
+
+@ARTICLE{7445139,
+author={A. {Sajid} and H. {Abbas} and K. {Saleem}},
+journal={IEEE Access},
+title={Cloud-Assisted IoT-Based SCADA Systems Security: A Review of the State of the Art and Future Challenges},
+year={2016},
+volume={4},
+number={},
+pages={1375-1384},
+keywords={cloud computing;critical infrastructures;cyber-physical systems;fault tolerance;industrial control;Internet;Internet of Things;SCADA systems;security of data;wireless sensor networks;cloud-assisted IoT-based SCADA system security;industrial systems;fault tolerance;cyber physical system integration;CPS integration;Internet of Things;cloud computing services;smart industrial systems;industrial CPS;supervisory control and data acquisition systems;critical infrastructure;WebSCADA;industrial SCADA systems;IoT-cloud environment;future Internet;mobile wireless sensor networks;Cloud computing;Security;SCADA systems;Power system stability;Fault tolerant systems;Wireless sensor networks;Internet of things;Stability analysis;APT;Industrial Control System;Internet of Things (IoT);NIST;PRECYSE;Supervisory Control and Data Acquisition;SOA;APT;industrial control system;Internet of Things (IoT);NIST;PRECYSE;supervisory control and data acquisition system;SOA},
+doi={10.1109/ACCESS.2016.2549047},
+ISSN={2169-3536},
+month={},}
+
+@misc{owasp, title={OWASP Internet of Things Project}, url={https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project}, journal={OWASP}, year={2018}}
+
+@inproceedings{bere2015initial,
+ title={Initial investigation of industrial control system (ICS) security using artificial immune system (AIS)},
+ author={Bere, Mercy and Muyingi, Hippolyte},
+ booktitle={2015 International Conference on Emerging Trends in Networks and Computer Communications (ETNCC)},
+ pages={79--84},
+ year={2015},
+ organization={IEEE}
+}
+
+@article{Virvilis2013TrustedCV,
+ title={Trusted Computing vs. Advanced Persistent Threats: Can a Defender Win This Game?},
+ author={Nikos Virvilis and Dimitris Gritzalis and Theodoros K. Apostolopoulos},
+ journal={2013 IEEE 10th International Conference on Ubiquitous Intelligence and Computing and 2013 IEEE 10th International Conference on Autonomic and Trusted Computing},
+ year={2013},
+ pages={396-403}
+}
+
+@inproceedings{Bilge:2012:BWK:2382196.2382284,
+ author = {Bilge, Leyla and Dumitra\c{s}, Tudor},
+ title = {Before We Knew It: An Empirical Study of Zero-day Attacks in the Real World},
+ booktitle = {Proceedings of the 2012 ACM Conference on Computer and Communications Security},
+ series = {CCS '12},
+ year = {2012},
+ isbn = {978-1-4503-1651-4},
+ location = {Raleigh, North Carolina, USA},
+ pages = {833--844},
+ numpages = {12},
+ url = {http://doi.acm.org/10.1145/2382196.2382284},
+ doi = {10.1145/2382196.2382284},
+ acmid = {2382284},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {full disclosure, vulnerabilities, zero-day attacks},
+}
+
+@article{wang2012sscada,
+ title={sSCADA: securing SCADA infrastructure communications},
+ author={Wang, Yongge},
+ journal={arXiv preprint arXiv:1207.5434},
+ year={2012}
+}
+
+@Inbook{Adams2005,
+author="Adams, Carlisle",
+editor="van Tilborg, Henk C. A.",
+title="Impersonation Attack",
+bookTitle="Encyclopedia of Cryptography and Security",
+year="2005",
+publisher="Springer US",
+address="Boston, MA",
+pages="286--286",
+isbn="978-0-387-23483-0",
+doi="10.1007/0-387-23483-7_196",
+url="https://doi.org/10.1007/0-387-23483-7_196"
+}
+
+@article{patel2016internet,
+ title={Internet of things-IOT: definition, characteristics, architecture, enabling technologies, application \& future challenges},
+ author={Patel, Keyur K and Patel, Sunil M and others},
+ journal={International journal of engineering science and computing},
+ volume={6},
+ number={5},
+ year={2016}
+}
+
+@article{yu2011new,
+ title={The new frontier of smart grids},
+ author={Yu, Xinghuo and Cecati, Carlo and Dillon, Tharam and Simoes, M Godoy},
+ journal={IEEE Industrial Electronics Magazine},
+ volume={5},
+ number={3},
+ pages={49--63},
+ year={2011},
+ publisher={IEEE}
+}
+
+@misc{kuslitskiy_2019,
+title={Smart Grid Features - ANSI Blog}, url={https://blog.ansi.org/2011/11/smart-grid-features/},
+journal={The ANSI Blog},
+publisher={ANSI},
+author={Kuslitskiy, Boris},
+year={2019},
+month={Jul}}
+
+@inproceedings{mcqueen2006quantitative,
+ title={Quantitative cyber risk reduction estimation methodology for a small SCADA control system},
+ author={McQueen, Miles A and Boyer, Wayne F and Flynn, Mark A and Beitel, George A},
+ booktitle={Proceedings of the 39th Annual Hawaii International Conference on System Sciences (HICSS'06)},
+ volume={9},
+ pages={226--226},
+ year={2006},
+ organization={IEEE}
+}
+
+@article{yang2017survey,
+ title={A survey on security and privacy issues in Internet-of-Things},
+ author={Yang, Yuchen and Wu, Longfei and Yin, Guisheng and Li, Lijie and Zhao, Hongbin},
+ journal={IEEE Internet of Things Journal},
+ volume={4},
+ number={5},
+ pages={1250--1258},
+ year={2017},
+ publisher={IEEE}
+}
+
+@techreport{arnold2010nist,
+ title={NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0},
+ author={Arnold, George W and Wollman, David A and FitzPatrick, Gerald J and Prochaska, Dean and Holmberg, David G and Su, David H and Hefner Jr, Allen R and Golmie, Nada T and Brewer, Tanya L and Bello, Mark and others},
+ year={2010}
+}
+
+@inproceedings{cremers2008scyther,
+ title={The Scyther Tool: Verification, falsification, and analysis of security protocols},
+ author={Cremers, Cas JF},
+ booktitle={International Conference on Computer Aided Verification},
+ pages={414--418},
+ year={2008},
+ organization={Springer}
+}
+
+@inproceedings{meadows1994formal,
+ title={Formal verification of cryptographic protocols: A survey},
+ author={Meadows, Catherine A},
+ booktitle={International Conference on the Theory and Application of Cryptology},
+ pages={133--150},
+ year={1994},
+ organization={Springer}
+}
+
+@article{dalal2010comparative,
+ title={A comparative analysis of tools for verification of security protocols},
+ author={Dalal, Nitish and Shah, Jenny and Hisaria, Khushboo and Jinwala, Devesh},
+ journal={International Journal of Communications, Network and System Sciences},
+ volume={3},
+ number={10},
+ pages={779},
+ year={2010},
+ publisher={Scientific Research Publishing}
+}
+
+@article{yang2016verifying,
+ title={Verifying Group Authentication Protocols by Scyther.},
+ author={Yang, Huihui and Oleshchuk, Vladimir A and Prinz, Andreas}
+}
+
+@inproceedings{10.1145/1753326.1753384,
+author = {Inglesant, Philip G. and Sasse, M. Angela},
+title = {The True Cost of Unusable Password Policies: Password Use in the Wild},
+year = {2010},
+isbn = {9781605589299},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/1753326.1753384},
+doi = {10.1145/1753326.1753384},
+booktitle = {Proceedings of the SIGCHI Conference on Human Factors in Computing Systems},
+pages = {383–392},
+numpages = {10},
+keywords = {passwords, usable security, password policy},
+location = {Atlanta, Georgia, USA},
+series = {CHI ’10}
+}
+
+@misc{TopPasswords,
+author = {OWASP},
+title = {Most common password list},
+url = {https://github.com/OWASP/passfault/blob/master/wordlists/wordlists/10k-worst-passwords.txt}
+}
+
+@phdthesis{cas,
+title = "Scyther : semantics and verification of security protocols",
+abstract = "Recent technologies have cleared the way for large scale application of electronic communication. The open and distributed nature of these communications implies that the communication medium is no longer completely controlled by the communicating parties. As a result, there has been an increasing demand for research in establishing secure communications over insecure networks, by means of security protocols. In this thesis, a formal model for the description and analysis of security protocols at the process level is developed. At this level, under the assumption of perfect cryptography, the analysis focusses on detecting aws and vulnerabilities of the security protocol. Starting from ??rst principles, operational semantics are developed to describe security protocols and their behaviour. The resulting model is parameterized, and can e.g. capture various intruder models, ranging from a secure network with no intruder, to the strongest intruder model known in literature. Within the security protocol model various security properties are de??ned, such as secrecy and various forms of authentication. A number of new results about these properties are formulated and proven correct. Based on the model, an automated veri??cation procedure is developed, which signi ??cantly improves over existing methods. The procedure is implemented in a prototype, which outperforms other tools. Both the theory and tool are applied in two novel case studies. Using the tool prototype, new results are established in the area of protocol composition, leading to the discovery of a class of previously undetected attacks. Furthermore, a new protocol in the area of multiparty authentication is developed. The resulting protocol is proven correct within the framework.",
+author = "C.J.F. Cremers",
+year = "2006",
+doi = "10.6100/IR614943",
+language = "English",
+isbn = "90-386-0804-7",
+publisher = "Technische Universiteit Eindhoven",
+school = "Department of Mathematics and Computer Science",
+}
+
+@InProceedings{10.1007/3-540-61770-1_46,
+author="Meadows, Catherine A.",
+editor="Bertino, Elisa
+and Kurth, Helmut
+and Martella, Giancarlo
+and Montolivo, Emilio",
+title="Analyzing the Needham-Schroeder public key protocol: A comparison of two approaches",
+booktitle="Computer Security --- ESORICS 96",
+year="1996",
+publisher="Springer Berlin Heidelberg",
+address="Berlin, Heidelberg",
+pages="351--364",
+abstract="In this paper we contrast the use of the NRL Protocol Analyzer and Gavin Lowe's use of the model checker FDR [8] to analyze the Needham-Schroeder public key protocol. This is used as a basis for comparing and contrasting the two systems and to point out possible future directions for research.",
+isbn="978-3-540-70675-5"
+}
+
+@article{hung2018power,
+ title={Power consumption and calculation requirement analysis of AES for WSN IoT},
+ author={Hung, Chung-Wen and Hsu, Wen-Ting},
+ journal={Sensors},
+ volume={18},
+ number={6},
+ pages={1675},
+ year={2018},
+ publisher={Multidisciplinary Digital Publishing Institute}
+}
+
+@article{grassi2017nist,
+ title={NIST 800-63B digital identity guidelines: Authentication and lifecycle management},
+ author={Grassi, Paul A and Newton, EM and Perlner, RA and Regenscheid, AR and Burr, WE and Richer, JP},
+ journal={McLean, VA, Tech. Rep},
+ year={2017}
+}
+@article{souppaya2013guide,
+ title={Guide to enterprise patch management technologies},
+ author={Souppaya, Murugiah and Scarfone, Karen},
+ journal={NIST Special Publication},
+ volume={800},
+ pages={40},
+ year={2013}
+}
+
+@article{mattei2017privacy,
+ title={Privacy, confidentiality, and security of health care information: Lessons from the recent Wannacry cyberattack},
+ author={Mattei, Tobias A},
+ journal={World neurosurgery},
+ volume={104},
+ pages={972--974},
+ year={2017},
+ publisher={Elsevier}
+}
+
+@misc{kaspersky_2019, title={Phishing Prevention Tips}, url={https://www.kaspersky.com/resource-center/threats/ransomware-wannacry}, journal={www.kaspersky.com}, author={Kaspersky}, year={2019}, month={Nov}}
+
+@article{case2016analysis,
+ title={Analysis of the cyber attack on the Ukrainian power grid},
+ author={Case, Defense Use},
+ journal={Electricity Information Sharing and Analysis Center (E-ISAC)},
+ volume={388},
+ year={2016}
+}
+
+@inproceedings{kambourakis2017mirai,
+ title={The mirai botnet and the iot zombie armies},
+ author={Kambourakis, Georgios and Kolias, Constantinos and Stavrou, Angelos},
+ booktitle={MILCOM 2017-2017 IEEE Military Communications Conference (MILCOM)},
+ pages={267--272},
+ year={2017},
+ organization={IEEE}
+}
\ No newline at end of file
diff --git a/Design Files/Latex/session.svg b/Design Files/Latex/session.svg
new file mode 100644
index 0000000000000000000000000000000000000000..d530c0e0bf722c29d03e1f3c5f2ac3673b7c04b2
--- /dev/null
+++ b/Design Files/Latex/session.svg
@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:lucid="lucid" width="740.67" height="1080"><g transform="translate(-779.3333333333333 -100)" lucid:page-tab-id="0_0"><path d="M0 0h1870.4v1323.2H0z" fill="#fff"/><path d="M849.33 128c0-4.42 3.6-8 8-8h144c4.42 0 8 3.58 8 8v44c0 4.42-3.58 8-8 8h-144c-4.4 0-8-3.58-8-8z" stroke="#333" fill="#fff"/><use xlink:href="#a" transform="matrix(1,0,0,1,849.3333333333333,120) translate(42.198847656249995 36.896484375)"/><path d="M1290 128c0-4.42 3.58-8 8-8h144c4.42 0 8 3.58 8 8v44c0 4.42-3.58 8-8 8h-144c-4.42 0-8-3.58-8-8z" stroke="#333" fill="#fff"/><use xlink:href="#b" transform="matrix(1,0,0,1,1290,120) translate(15.194453125000004 36.896484375)"/><use xlink:href="#c" transform="matrix(1,0,0,1,1290,120) translate(80.00500000000001 36.896484375)"/><path d="M799.33 285.33c0-4.4 3.6-8 8-8h244c4.42 0 8 3.6 8 8V352c0 4.42-3.58 8-8 8h-244c-4.4 0-8-3.58-8-8z" fill="#fff"/><use xlink:href="#d" transform="matrix(1,0,0,1,799.3333333333333,277.33333333333337) translate(16.586542968750003 29.958984375)"/><use xlink:href="#e" transform="matrix(1,0,0,1,799.3333333333333,277.33333333333337) translate(124.60412109375001 29.958984375)"/><use xlink:href="#f" transform="matrix(1,0,0,1,799.3333333333333,277.33333333333337) translate(211.01818359375 29.958984375)"/><use xlink:href="#g" transform="matrix(1,0,0,1,799.3333333333333,277.33333333333337) translate(11.185664062500004 47.958984375)"/><use xlink:href="#h" transform="matrix(1,0,0,1,799.3333333333333,277.33333333333337) translate(54.3926953125 47.958984375)"/><use xlink:href="#i" transform="matrix(1,0,0,1,799.3333333333333,277.33333333333337) translate(205.6173046875 47.958984375)"/><use xlink:href="#j" transform="matrix(1,0,0,1,799.3333333333333,277.33333333333337) translate(38.19005859375 65.958984375)"/><use xlink:href="#k" transform="matrix(1,0,0,1,799.3333333333333,277.33333333333337) translate(113.80236328125001 65.958984375)"/><use xlink:href="#l" transform="matrix(1,0,0,1,799.3333333333333,277.33333333333337) translate(189.41466796875 65.958984375)"/><path d="M929.33 181v95.83" stroke="#333" fill="none"/><path d="M929.83 181h-1v-.5h1zM929.83 277.33h-1v-.5h1z" fill="#333"/><path d="M865.33 1080c-8.83 0-16 7.16-16 16v48c0 8.84 7.17 16 16 16h128c8.84 0 16-7.16 16-16v-48c0-8.84-7.16-16-16-16z" stroke="#333" fill="#fff"/><use xlink:href="#m" transform="matrix(1,0,0,1,857.3333333333333,1088) translate(55.79736328125 36.266666666666666)"/><path d="M1306 1080c-8.84 0-16 7.16-16 16v48c0 8.84 7.16 16 16 16h128c8.84 0 16-7.16 16-16v-48c0-8.84-7.16-16-16-16z" stroke="#333" fill="#fff"/><use xlink:href="#m" transform="matrix(1,0,0,1,1298,1088) translate(55.79736328125 36.266666666666666)"/><path d="M1240 297.87c0-4.42 3.58-8 8-8h244c4.42 0 8 3.58 8 8V352c0 4.42-3.58 8-8 8h-244c-4.42 0-8-3.58-8-8z" fill="#fff"/><use xlink:href="#d" transform="matrix(1,0,0,1,1240,289.865) translate(16.586542968750003 23.271484375)"/><use xlink:href="#e" transform="matrix(1,0,0,1,1240,289.865) translate(124.60412109375001 23.271484375)"/><use xlink:href="#f" transform="matrix(1,0,0,1,1240,289.865) translate(211.01818359375 23.271484375)"/><use xlink:href="#g" transform="matrix(1,0,0,1,1240,289.865) translate(11.185664062500004 41.271484375)"/><use xlink:href="#h" transform="matrix(1,0,0,1,1240,289.865) translate(54.3926953125 41.271484375)"/><use xlink:href="#i" transform="matrix(1,0,0,1,1240,289.865) translate(205.6173046875 41.271484375)"/><use xlink:href="#j" transform="matrix(1,0,0,1,1240,289.865) translate(38.19005859375 59.271484375)"/><use xlink:href="#k" transform="matrix(1,0,0,1,1240,289.865) translate(113.80236328125001 59.271484375)"/><use xlink:href="#l" transform="matrix(1,0,0,1,1240,289.865) translate(189.41466796875 59.271484375)"/><path d="M1370 181v108.37" stroke="#000" fill="none"/><path d="M1370.5 181h-1v-.5h1zM1370.5 289.87h-1v-.52h1z"/><path d="M799.33 465.33c0-4.4 3.6-8 8-8h244c4.42 0 8 3.6 8 8v84c0 4.42-3.58 8-8 8h-244c-4.4 0-8-3.58-8-8z" fill="#fff"/><use xlink:href="#n" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(5.784785156250004 26.896484375)"/><use xlink:href="#o" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(70.59533203125001 26.896484375)"/><use xlink:href="#p" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(200.21642578125 26.896484375)"/><use xlink:href="#q" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(32.7891796875 44.896484375)"/><use xlink:href="#r" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(162.4102734375 44.896484375)"/><use xlink:href="#s" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(194.815546875 44.896484375)"/><use xlink:href="#t" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(11.185664062500004 62.896484375)"/><use xlink:href="#u" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(75.99621093750001 62.896484375)"/><use xlink:href="#v" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(151.608515625 62.896484375)"/><use xlink:href="#w" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(16.586542968750003 80.896484375)"/><use xlink:href="#x" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(81.39708984375001 80.896484375)"/><use xlink:href="#e" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(124.60412109375001 80.896484375)"/><use xlink:href="#l" transform="matrix(1,0,0,1,799.3333333333333,457.33333333333337) translate(211.01818359375 80.896484375)"/><path d="M1240 588c0-4.42 3.58-8 8-8h244c4.42 0 8 3.58 8 8v84c0 4.42-3.58 8-8 8h-244c-4.42 0-8-3.58-8-8z" fill="#fff"/><use xlink:href="#y" transform="matrix(1,0,0,1,1240,580) translate(11.185664062500004 45.646484375)"/><use xlink:href="#z" transform="matrix(1,0,0,1,1240,580) translate(108.40148437500001 45.646484375)"/><use xlink:href="#A" transform="matrix(1,0,0,1,1240,580) translate(194.815546875 45.646484375)"/><use xlink:href="#e" transform="matrix(1,0,0,1,1240,580) translate(70.59533203125001 63.646484375)"/><use xlink:href="#f" transform="matrix(1,0,0,1,1240,580) translate(157.00939453125 63.646484375)"/><path d="M1240 768c0-4.42 3.58-8 8-8h244c4.42 0 8 3.58 8 8v84c0 4.42-3.58 8-8 8h-244c-4.42 0-8-3.58-8-8z" fill="#fff"/><g><use xlink:href="#n" transform="matrix(1,0,0,1,1240,760) translate(59.79357421875 26.896484375)"/><use xlink:href="#B" transform="matrix(1,0,0,1,1240,760) translate(124.60412109375001 26.896484375)"/><use xlink:href="#o" transform="matrix(1,0,0,1,1240,760) translate(21.987421875000003 44.896484375)"/><use xlink:href="#C" transform="matrix(1,0,0,1,1240,760) translate(151.608515625 44.896484375)"/><use xlink:href="#D" transform="matrix(1,0,0,1,1240,760) translate(216.4190625 44.896484375)"/><use xlink:href="#E" transform="matrix(1,0,0,1,1240,760) translate(5.784785156250004 62.896484375)"/><use xlink:href="#F" transform="matrix(1,0,0,1,1240,760) translate(70.59533203125001 62.896484375)"/><use xlink:href="#G" transform="matrix(1,0,0,1,1240,760) translate(157.00939453125 62.896484375)"/><use xlink:href="#H" transform="matrix(1,0,0,1,1240,760) translate(21.987421875000003 80.896484375)"/><use xlink:href="#x" transform="matrix(1,0,0,1,1240,760) translate(75.9962109375 80.896484375)"/><use xlink:href="#e" transform="matrix(1,0,0,1,1240,760) translate(119.2032421875 80.896484375)"/><use xlink:href="#f" transform="matrix(1,0,0,1,1240,760) translate(205.6173046875 80.896484375)"/></g><path d="M799.33 888c0-4.42 3.6-8 8-8h244c4.42 0 8 3.58 8 8v84c0 4.42-3.58 8-8 8h-244c-4.4 0-8-3.58-8-8z" fill="#fff"/><g><use xlink:href="#y" transform="matrix(1,0,0,1,799.3333333333333,880) translate(11.185664062500004 45.646484375)"/><use xlink:href="#z" transform="matrix(1,0,0,1,799.3333333333333,880) translate(108.40148437500001 45.646484375)"/><use xlink:href="#A" transform="matrix(1,0,0,1,799.3333333333333,880) translate(194.815546875 45.646484375)"/><use xlink:href="#e" transform="matrix(1,0,0,1,799.3333333333333,880) translate(70.59533203125001 63.646484375)"/><use xlink:href="#f" transform="matrix(1,0,0,1,799.3333333333333,880) translate(157.00939453125 63.646484375)"/></g><path d="M929.33 360.5v96.33" stroke="#000" fill="none"/><path d="M929.83 360.5h-1v-.5h1zM929.83 457.33h-1v-.5h1z"/><path d="M929.33 557.83V879.5" stroke="#000" fill="none"/><path d="M929.83 557.85h-1v-.52h1zM929.83 880h-1v-.5h1z"/><path d="M1370 360.5v219" stroke="#000" fill="none"/><path d="M1370.5 360.5h-1v-.5h1zM1370.5 580h-1v-.5h1z"/><path d="M1370 680.5v79" stroke="#000" fill="none"/><path d="M1370.5 680.5h-1v-.5h1zM1370.5 760h-1v-.5h1z"/><path d="M1370 860.5V1079" stroke="#000" fill="none"/><path d="M1370.5 860.5h-1v-.5h1zM1370.5 1079.5h-1v-.5h1z"/><path d="M929.33 980.5v98.5" stroke="#000" fill="none"/><path d="M929.83 980.5h-1v-.5h1zM929.83 1079.5h-1v-.5h1z"/><path d="M1059.84 507.34l3.55.08 3.83.24 3.65.38 3.5.52 3.36.64 3.26.76 3.17.9 3.1 1 3.05 1.13 3 1.26 3.02 1.4 3 1.58 3.04 1.75 3.08 1.95 3.16 2.2 3.27 2.48 3.42 2.84 3.66 3.3 4 3.92 4.53 4.82 5.52 6.4 8.28 10.5 25 33 5.52 6.4 4.54 4.82 4 3.92 3.65 3.3 3.45 2.84 3.27 2.5 3.16 2.18 3.08 1.96 3.03 1.75 3 1.56 3 1.42 3.02 1.26 3.04 1.14 3.1 1 3.17.9 3.26.75 3.35.65 3.5.5 3.65.4 3.84.24 3.56.07" stroke="#000" fill="none"/><path d="M1059.86 506.84l-.02 1h-.5v-1zM1240 629.5v1h-.5v-1z"/><path d="M1239.5 810l-3.65.1-3.9.23-3.74.4-3.55.52-3.42.65-3.3.78-3.22.9-3.14 1.02-3.1 1.15-3.05 1.28-3.04 1.44-3.04 1.6-3.08 1.77-3.12 1.98-3.2 2.23-3.34 2.53-3.5 2.9-3.73 3.36-4.12 4.04-4.72 5.03-5.9 6.87-10.58 13.46-19.3 25-5.9 6.86-4.72 5.02-4.1 4.04-3.76 3.37-3.5 2.9-3.32 2.52-3.2 2.23-3.13 1.98-3.08 1.78-3.05 1.6-3.04 1.43-3.06 1.28-3.1 1.15-3.14 1.03-3.22.9-3.3.77-3.42.65-3.56.53-3.72.4-3.92.23-3.65.1" stroke="#000" fill="none"/><path d="M1240 810.5h-.5l-.03-1h.53zM1059.85 930.5h-.52v-1h.52z"/><defs><path d="M285-1169c8 382 2 780 4 1169H129v-1349h237c86 239 188 461 253 720 69-258 169-481 255-720h225V0H937c2-390-5-788 6-1169-75 255-170 488-259 729H547c-90-240-185-475-262-729" id="I"/><path d="M615-1102c343 0 484 203 482 560-1 347-147 562-488 562-336 0-475-219-479-562-4-349 156-560 485-560zm-8 989c240 0 301-180 301-429 0-245-55-427-290-427-236 0-299 181-299 427 0 243 61 429 288 429" id="J"/><path d="M706-1102c241 0 344 136 343 381V0H868v-695c1-168-57-273-220-268-190 6-283 138-283 336V0H185c-3-360 6-732-6-1082h170c4 54 7 126 8 185h3c63-121 164-204 346-205" id="K"/><path d="M745-142h380V0H143v-142h422v-798H246v-142h499v940zM545-1292v-192h200v192H545" id="L"/><path d="M682 16c-209 0-323-80-324-285v-671H190v-142h170l58-282h120v282h432v142H538v652c2 114 60 155 182 155 106 0 209-16 297-34v137C921-4 806 16 682 16" id="M"/><path d="M839-1102c70 0 148 7 206 17v167c-112-18-268-36-363 15-129 69-208 203-208 395V0H294c-10-367 32-789-52-1082h171c21 75 41 161 48 250h5c67-152 152-270 373-270" id="N"/><g id="a"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#I"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#J"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#K"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#L"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#M"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#J"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#N"/></g><path d="M650-1214c-281 0-336 244-336 533 0 295 60 546 347 546 188 0 263-142 322-282l159 65C1058-155 935 20 659 20c-401 0-546-295-546-701 0-407 135-689 536-689 264 0 391 146 466 335l-168 65c-47-129-127-244-297-244" id="O"/><path d="M736-142h380V0H134v-142h422v-1200H267v-142h469v1342" id="P"/><path d="M528 20c-247 0-343-132-343-381v-721h180v686c-4 177 45 284 224 277 194-8 279-136 279-336v-627h181c3 360-6 732 6 1082H885c-4-54-7-126-8-185h-3C809-64 714 20 528 20" id="Q"/><path d="M865-914c-3-187-2-380-2-570h180v1261c0 76 1 155 6 223H877c-8-49-9-116-10-174h-5C801-44 708 26 530 26c-135 0-234-46-297-139s-95-232-95-419c0-377 131-566 392-566 176 0 271 63 335 184zm-286-51c-222 0-255 197-255 427 0 229 31 425 253 425 237 0 286-195 286-441 0-238-52-411-284-411" id="R"/><g id="b"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#O"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#P"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#J"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#Q"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#R"/></g><path d="M614-1226c-167 1-283 53-283 213 0 183 186 193 334 234 230 63 463 120 463 409 0 286-219 387-518 390C309 23 131-98 79-338l185-37c34 165 149 248 351 246 184-2 324-58 324-238 0-203-207-221-372-266-210-57-422-111-422-377 0-267 201-356 470-360 279-5 430 101 480 324l-188 33c-28-141-121-215-293-213" id="S"/><path d="M617-1102c355 0 481 238 477 599H322c5 222 84 388 301 388 144 0 244-59 284-166l158 45C1002-72 854 20 623 20c-342 0-490-220-490-568 0-346 151-554 484-554zm291 461c-18-192-90-328-289-328-194 0-287 128-295 328h584" id="T"/><path d="M715 0H502L69-1082h202c94 253 197 500 285 758 19 57 36 126 52 183 96-335 234-626 350-941h201" id="U"/><g id="c"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#S"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#T"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#N"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#U"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#T"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#N"/></g><path fill="#333" d="M655-135c108 0 195-33 260-74v-336H622v-160h479v572C981-54 839 20 639 20c-388 0-526-306-526-701 0-406 129-689 529-689 261 0 392 137 461 331l-171 56c-47-131-122-231-288-231-281 0-330 245-330 533 0 179 28 314 84 407s142 139 257 139" id="V"/><path fill="#333" d="M617-1102c355 0 481 238 477 599H322c5 222 84 388 301 388 144 0 244-59 284-166l158 45C1002-72 854 20 623 20c-342 0-490-220-490-568 0-346 151-554 484-554zm291 461c-18-192-90-328-289-328-194 0-287 128-295 328h584" id="W"/><path fill="#333" d="M706-1102c241 0 344 136 343 381V0H868v-695c1-168-57-273-220-268-190 6-283 138-283 336V0H185c-3-360 6-732-6-1082h170c4 54 7 126 8 185h3c63-121 164-204 346-205" id="X"/><path fill="#333" d="M839-1102c70 0 148 7 206 17v167c-112-18-268-36-363 15-129 69-208 203-208 395V0H294c-10-367 32-789-52-1082h171c21 75 41 161 48 250h5c67-152 152-270 373-270" id="Y"/><path fill="#333" d="M1000-272c3 95 12 159 101 161 21 0 41-3 59-7V-6c-44 10-86 16-139 16-141 2-191-84-197-217h-6C748-76 648 20 446 20c-207 0-318-120-318-322 0-266 194-348 454-354l236-4c12-191-40-305-222-305-140 0-220 47-232 172l-188-17c33-204 181-292 423-292 255 0 401 118 401 364v466zm-683-27c0 109 63 184 175 182 166-3 259-96 306-217 24-65 20-120 20-200-232 7-501-28-501 235" id="Z"/><path fill="#333" d="M682 16c-209 0-323-80-324-285v-671H190v-142h170l58-282h120v282h432v142H538v652c2 114 60 155 182 155 106 0 209-16 297-34v137C921-4 806 16 682 16" id="aa"/><path fill="#333" d="M873-819c-18-114-119-146-250-146-163 0-245 50-245 151 0 151 170 148 294 185 182 54 388 94 388 320 0 240-189 325-439 329-245 4-410-69-454-268l159-31c24 133 136 168 295 165 144-2 270-31 270-171 0-164-195-160-331-202-167-52-350-87-350-299 0-218 173-315 413-313 220 2 373 77 412 260" id="ab"/><g id="d"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#V"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#X"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#Z"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,75.6123046875,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,86.4140625,0)" xlink:href="#ab"/></g><path fill="#333" d="M745-142h380V0H143v-142h422v-798H246v-142h499v940zM545-1292v-192h200v192H545" id="ac"/><path fill="#333" d="M615-1102c343 0 484 203 482 560-1 347-147 562-488 562-336 0-475-219-479-562-4-349 156-560 485-560zm-8 989c240 0 301-180 301-429 0-245-55-427-290-427-236 0-299 181-299 427 0 243 61 429 288 429" id="ad"/><g id="e"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#ad"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#X"/></g><path fill="#333" d="M914 0L548-499l-132 98V0H236v-1484h180v927l475-525h211L663-617 1125 0H914" id="ae"/><path fill="#333" d="M168 279c222 39 310-114 368-290L66-1082h192c120 299 249 590 362 896 115-301 235-597 351-896h190L705 0c-65 164-130 320-275 396-67 36-177 35-262 18V279" id="af"/><g id="f"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ae"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#af"/></g><path fill="#333" d="M839-1335c-182-6-269 67-259 253h491v142H580V0H400v-940H138v-142h262c-15-293 132-408 418-402 94 2 200 7 281 21v145c-75-10-177-14-260-17" id="ag"/><g id="g"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ag"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ad"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#Y"/></g><path fill="#333" d="M631 20c-350 0-501-215-501-562 0-355 162-560 502-560 250 0 399 118 446 323l-192 14c-23-124-109-196-262-196-242 0-305 171-305 415 1 245 61 427 304 427 151 0 248-77 267-215l190 12C1039-107 883 20 631 20" id="ah"/><path fill="#333" d="M904-1102c199 0 220 177 220 381V0H956v-686c-3-114 0-215-60-264-70-33-125-4-158 71-26 56-39 140-39 252V0H531v-686c-3-114-1-215-61-264-78-41-136 24-157 84-24 69-39 159-39 259V0H105c-3-360 6-732-6-1082h149c6 50 3 123 8 175 36-100 83-195 216-195 135 0 166 79 196 196 42-105 93-196 236-196" id="ai"/><path fill="#333" d="M528 20c-247 0-343-132-343-381v-721h180v686c-4 177 45 284 224 277 194-8 279-136 279-336v-627h181c3 360-6 732 6 1082H885c-4-54-7-126-8-185h-3C809-64 714 20 528 20" id="aj"/><g id="h"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ah"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ad"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ai"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#ai"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#aj"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#X"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,75.6123046875,0)" xlink:href="#ah"/><use transform="matrix(0.0087890625,0,0,0.0087890625,86.4140625,0)" xlink:href="#Z"/><use transform="matrix(0.0087890625,0,0,0.0087890625,97.2158203125,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,108.017578125,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,118.8193359375,0)" xlink:href="#ad"/><use transform="matrix(0.0087890625,0,0,0.0087890625,129.62109375,0)" xlink:href="#X"/></g><g id="i"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ag"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ad"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#ai"/></g><path fill="#333" d="M648-963c-190 6-283 138-283 336V0H185v-1484h181c-2 197 6 404-9 587h3c62-120 159-205 339-205 242 0 351 135 350 381V0H868v-695c1-168-57-273-220-268" id="ak"/><path fill="#333" d="M865-914c-3-187-2-380-2-570h180v1261c0 76 1 155 6 223H877c-8-49-9-116-10-174h-5C801-44 708 26 530 26c-135 0-234-46-297-139s-95-232-95-419c0-377 131-566 392-566 176 0 271 63 335 184zm-286-51c-222 0-255 197-255 427 0 229 31 425 253 425 237 0 286-195 286-441 0-238-52-411-284-411" id="al"/><g id="j"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ak"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#Z"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#al"/></g><g id="k"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ah"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#aa"/></g><g id="l"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ae"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#af"/></g><path fill="#333" d="M162 0v-1349h919v156H353v422h668v154H353v461h769V0H162" id="am"/><path fill="#333" d="M912-211c-10-84-18-177-18-274v-864h172V0H836L316-1130c7 79 16 167 16 254V0H162v-1349h222" id="an"/><path fill="#333" d="M473-1349c438-1 655 221 652 661C1122-268 945-8 532 0H162v-1349h311zm42 1193c308-4 416-205 418-532 2-330-131-509-459-505H353v1037h162" id="ao"/><g id="m"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#am"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#an"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ao"/></g><path fill="#333" d="M614-1226c-167 1-283 53-283 213 0 183 186 193 334 234 230 63 463 120 463 409 0 286-219 387-518 390C309 23 131-98 79-338l185-37c34 165 149 248 351 246 184-2 324-58 324-238 0-203-207-221-372-266-210-57-422-111-422-377 0-267 201-356 470-360 279-5 430 101 480 324l-188 33c-28-141-121-215-293-213" id="ap"/><g id="n"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ap"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#X"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#al"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#ab"/></g><path fill="#333" d="M736-142h380V0H134v-142h422v-1200H267v-142h469v1342" id="aq"/><g id="o"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#aq"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#ah"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,75.6123046875,0)" xlink:href="#ah"/><use transform="matrix(0.0087890625,0,0,0.0087890625,86.4140625,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,97.2158203125,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,108.017578125,0)" xlink:href="#af"/></g><path fill="#333" d="M1048-32c-2 300-135 456-433 456-222-1-358-88-400-267l184-25c22 99 100 157 222 156 184-2 248-125 248-315 0-64 3-133-2-194C807-100 706-13 524-12c-306 0-381-228-381-537 0-318 85-550 400-550 164 0 271 83 325 202h3c1-60 3-134 12-185h171c-13 339-4 702-6 1050zM585-145c210-8 284-178 284-406 0-192-52-331-177-392-33-16-69-22-104-22-223 2-259 184-259 414 0 229 31 415 256 406" id="ar"/><g id="p"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#aj"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#Z"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#ar"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#W"/></g><g id="q"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#X"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ag"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#ad"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#ai"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#Z"/><use transform="matrix(0.0087890625,0,0,0.0087890625,75.6123046875,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,86.4140625,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,97.2158203125,0)" xlink:href="#ad"/><use transform="matrix(0.0087890625,0,0,0.0087890625,108.017578125,0)" xlink:href="#X"/></g><g id="r"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ad"/></g><g id="s"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ak"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#W"/></g><g id="t"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ah"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#aq"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ad"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#aj"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#al"/></g><path fill="#333" d="M715 0H502L69-1082h202c94 253 197 500 285 758 19 57 36 126 52 183 96-335 234-626 350-941h201" id="as"/><g id="u"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#as"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#Y"/></g><path fill="#333" d="M698-1104c312 3 392 244 392 558 0 315-82 566-392 566-169 0-277-65-331-184h-5c8 188 2 394 4 589H185V-858c0-76-1-156-6-224h175c6 52 9 120 10 178h4c58-122 150-202 330-200zm-49 991c225 0 255-203 255-433 0-225-32-419-253-419-236 0-285 192-285 441 0 237 53 411 283 411" id="at"/><g id="v"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#X"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ah"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#at"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#af"/><use transform="matrix(0.0087890625,0,0,0.0087890625,75.6123046875,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,86.4140625,0)" xlink:href="#al"/></g><g id="w"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#aj"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#X"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#ar"/></g><g id="x"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ak"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#W"/></g><g id="y"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ao"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ah"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#af"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#at"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,75.6123046875,0)" xlink:href="#ab"/></g><g id="z"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ai"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#Z"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#ar"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#W"/></g><g id="A"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#aj"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#X"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#ar"/></g><g id="B"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ah"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#aj"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#X"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#aa"/></g><g id="C"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#at"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#ah"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#W"/></g><g id="D"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ad"/></g><g id="E"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ab"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ai"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#Z"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#aa"/></g><g id="F"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#ai"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ad"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#X"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#ad"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#Y"/></g><g id="G"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#X"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#ah"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#Y"/><use transform="matrix(0.0087890625,0,0,0.0087890625,43.20703125,0)" xlink:href="#af"/><use transform="matrix(0.0087890625,0,0,0.0087890625,54.0087890625,0)" xlink:href="#at"/><use transform="matrix(0.0087890625,0,0,0.0087890625,64.810546875,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,75.6123046875,0)" xlink:href="#W"/><use transform="matrix(0.0087890625,0,0,0.0087890625,86.4140625,0)" xlink:href="#al"/></g><path fill="#333" d="M1018 0H814c-67-224-138-444-200-673C552-442 476-224 407 0H204L21-1082h178c43 310 105 601 126 933 54-225 128-425 193-638h193c63 212 134 415 185 638 22-336 90-622 136-933h176" id="au"/><g id="H"><use transform="matrix(0.0087890625,0,0,0.0087890625,0,0)" xlink:href="#au"/><use transform="matrix(0.0087890625,0,0,0.0087890625,10.8017578125,0)" xlink:href="#ac"/><use transform="matrix(0.0087890625,0,0,0.0087890625,21.603515625,0)" xlink:href="#aa"/><use transform="matrix(0.0087890625,0,0,0.0087890625,32.4052734375,0)" xlink:href="#ak"/></g></defs></g></svg>
\ No newline at end of file
diff --git a/Design Files/Latex/sprint1.PNG b/Design Files/Latex/sprint1.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..e9d2a89ed5ec899d025cbf57f3342f5a375e5fce
Binary files /dev/null and b/Design Files/Latex/sprint1.PNG differ
diff --git a/Design Files/Latex/sprint2.PNG b/Design Files/Latex/sprint2.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..cff207b9bdc2223c224e9ffa8bd640334f603f69
Binary files /dev/null and b/Design Files/Latex/sprint2.PNG differ
diff --git a/Design Files/Latex/sprint3.PNG b/Design Files/Latex/sprint3.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..30bc5ec6cdec3591c7b18ec722e0af237742fd2e
Binary files /dev/null and b/Design Files/Latex/sprint3.PNG differ