summaryrefslogtreecommitdiff
path: root/ma/safety_reset.tex
diff options
context:
space:
mode:
Diffstat (limited to 'ma/safety_reset.tex')
-rw-r--r--ma/safety_reset.tex99
1 files changed, 96 insertions, 3 deletions
diff --git a/ma/safety_reset.tex b/ma/safety_reset.tex
index dea5ceb..28dfa39 100644
--- a/ma/safety_reset.tex
+++ b/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}