some attacker model work

ma/safety_reset.bib

@@ -617,3 +617,34 @@
 	year = {2002}
 }
 
+@article{kim01,
+	author = {Jinsub Kim and Lang Tong},
+	doi = {10.1109/JSAC.2013.130712},
+	journaltitle = {IEEE Journal on Selected Areas in Communications},
+	month = jul,
+	number = {7},
+	publisher = {IEEE},
+	title = {On Topology Attack of a Smart Grid: Undetectable Attacks and Countermeasures},
+	volume = {31},
+	year = {2013}
+}
+
+@proceedings{fraunholz01,
+	author = {Daniel Fraunholz and Simon {Duque Anton} and Hans Dieter Schotten},
+	journaltitle = {2017 25th International Conference on Software, Telecommunications and Computer Networks (SoftCOM)},
+	month = nov,
+	publisher = {IEEE},
+	title = {Introducing GAMfIS: A Generic Attacker Model for Information Security},
+	url = {https://doi.org/10.23919/SOFTCOM.2017.8115550},
+	year = {2017}
+}
+
+@online{nytimes01,
+	author = {Andrew E. Kramer},
+	date = {Dec 30 2016},
+	journaltitle = {The New York Times New York edition, Section A, Page 1},
+	publisher = {The New York Times},
+	title = {How the Kremlin Recruited an Army of Specialists for Cyberwar},
+	year = {2016}
+}
+

ma/safety_reset.tex

@@ -358,18 +358,111 @@ protection. Code secrecy should be of no concern\cite{schneier01} here but besid
 preferences about this due to fear of copyright infringement.
 
 \section{The theory of endpoint safety}
+\label{sec_criteria}
 In order to gain anything by adding our reset controller to the smart meter's already complex design we must satisfy two
-conditions.
+interrelated conditions.
 \begin{enumerate}
-\item \textbf{security} means our reset controller itself does not have any exploitable flaws
-\item \textbf{safety} menas our reset controller will perform its job as intended
+\item \textsc{security} means our reset controller itself does not have any remotely exploitable flaws
+\item \textsc{safety} menas our reset controller will perform its job as intended
 \end{enumerate}
 
+Note that our \textsc{security} property includes only remote exploitation, and excludes any form of hardware attack.
+Even though most smart meters provide some level of physical security, we do not wish to make any assumptions on this.
+In the following section we will elaborate our attacker model and it will become apparent that sufficient physical
+security to defend against all attackers in our model would be infeasible, and thus we will design our overall system
+to remain secure even assuming some number of physically compromised devices.
 % FIXME expand
 
 \subsection{Attack characteristics}
+The attacker model these two conditions must hold under is as follows. We assume three angles of attack: Attacks by the
+customer themselves, attacks by an insider within the metering systems controlling utility company and lastly attacks
+from third parties. Examples for these third parties are hobbyist hackers or outside cyber-criminals on the one hand,
+but also other companies participating in the smart grid infrastructure besides the utility company such as intermediary
+providers of meter-reading services.
+
+Due to the critical nature of the electrical grid, we have to include hostile state actors in our attacker model. When
+acting directly, these would be classified as third-party attackers by the above schema, but they can reasonably be
+expected to be able to assume either of the other two roles as well e.g. through infiltration or bribery.
+\textcite{fraunholz01} in their elaboration of their generalized attacker model give some classification of attackers
+and provide a nice taxonomy of attacker properties. In their threat/capability rating, criminals are still considered
+to have higher threat rating than state-sponsored attackers. The New York Times reported in 2016 that some states
+recruit their hacking personnel in part from cyber-criminals. If this report is true, in a worst-case scenario we have
+to assume a state-sponsored attacker to be the worst of both types. Comparing this against the other attacker types in
+\textcite{fraunholz01}, this state-sponsored attacker is strictly worse than any other type in both variables. We are
+left with a highly-skilled, very well-funded, highly intentional and motivated attacker.
+
+Based on the above classification of attack angles and our observations on state-sponsored attacks, we can adapt
+\textcite{fraunholz01} to our problem, yielding the following new attacker types:
+
+\begin{enumerate}
+    \item \textbf{Utility company insiders controlled by a state actor}
+        We can ignore the other internal threats described in \textcite{fraunholz01} since an insider cooperating with a
+        state actor is strictly worse in every respect.
+    \item \textbf{State-sponsored external attackers}
+        A state actor can obviously directly attack the system through the internet.
+    \item \textbf{Customers controlled by a state actor}
+        A state actor can very well compromise some customers for their purposes. They might either physically
+        infiltrate the system posing as legitimate customers, or they might simply deceive or bribe existing customers
+        into cooperation.
+    \item \textbf{Regular customers}
+        Though a hostile state actor might gain control of some number of customers through means such as voluntary
+        cooperation, bribery, infiltration, they are limited in attack scale since they do not want to arouse premature
+        attention. Though regular customers may not have the motivation, skill or resources of a state-sponsored
+        attacker, potentially large numbers of them may try to attack a system out of financial incentives. To allow for
+        this possibility, we consider regular customers separate from state actors posing as customers in some way.
+\end{enumerate}
+
+\subsection{Overall structural system security}
+Considering overall security, we first introduce the \emph{reset authority}, a trusted party acting as the single
+authority for issuing reset commands in our system. In practice this trusted party may be part of the utility company,
+part of an external regulatory body or a hybrid setup requiring both to cooperate. We assume this party will be designed
+to be secure against all of the above attacker types. The precise design of this trusted party is out of scope for this
+work but we will list some practical suggestions on how to achieve security below. % FIXME do the list
+% FIXME put up a large box on this limitation
+
+Using an asymmetric cryptographic design centered around the \emph{reset authority}, we rule out all attacks except for
+denial-of-service attacks on our system by any of the four attacker types. All reset commands in our system originate
+from the \emph{reset authority} and are cryptographically secured to provide authentication and tamper detection.
+Under this model, attacks on the electrical grid components between the \emph{reset authority} and the customer device
+degrade into man-in-the-middle attacks. To ensure the \textsc{safety} criterion from \ref{sec_criteria} holds we must
+% FIXME check whether this \ref displays as intended
+make sure our cryptography is secure against man-in-the-middle attacks and we must try to harden the system against
+denial-of-service attacks by the attacker types listed above. Given our attacker model we cannot fully guard against
+this sort of attack but we can at least choose a commmunication channel that is resilient against denial of service
+attacks under the above model.
+
+Finally, we have to consider the issue of hardware security. We will solve the problem of physical attacks on some small
+number of devices by simply not programming any secret information into these devices. This also simplifies hardware
+production. From consideration in this work we explicitly rule out any form of supply-chain attack as
+out-of-scope.
+% FIXME include considerations on production testing somewhere (is the device working? is the right key programmed?)
+
 \subsection{Complex microcontroller firmware}
+The \textsc{security} property from \ref{sec_criteria} is in a large part reliant on the security of our reset
+controller firmware. The best method to increase firmware security is to reduce attack surface by limiting external
+interfaces as much as possible and by reducing code complexity as much as possible.
+% FIXME formalize this as something like "Design Goal DG-023-42-1" ?
+If we avoid the complexity of most modern microcontroller firmware we gain another benefit beyond implicitly reduced
+attack surface: If the resulting design is small enough we may attempt formal verification of our security property.
+Though formal verification tools are not yet suitable for highly complex tasks they are already barely adequate for
+small amounds of code and simple interfaces.
+
 \subsection{Modern microcontroller hardware}
+Microcontrollers have gained enormously in both performance/efficiency as well as in peripheral support. Alas, these
+gains have largely been driven by insatiable customer demand for faster, more powerful chips and for a long time
+security has not been considered important outside of some specific niches such as smartcards. Traditionally a
+microcontroller would spend its entire lifetime without ever being exposed to any networks. Though this trend has been
+reversing with the increasing adoption of internet-of-things things % FIXME is this pun ok?
+and more advanced security features have started appearing in general-purpose microcontrollers, most still lack even
+basic functionality as far as computer security is concerned.
+
+One of the components lacking from most microcontrollers is strong memory protection or even a memory mapping unit as
+it is found in all modern computer processors and SoCs for applications such as smartphones. Without an MPU/MPU some
+mitigations for memory safety violations cannot be implemented. Thus it is very important to ensure memory safety in
+microcontroller firmware through tools such as defensive coding, extensive testing and formal verification.
+
+%FIXME stopped writing here, continue
+
 \subsection{Regulatory and economical constraints}
 \subsection{Safety vs. Security: Opting for restoration instead of prevention}
 \subsection{Technical outline of a safety reset}