thesis: expand introduction

1 files changed, 117 insertions, 4 deletions

diff --git a/ma/safety_reset.tex b/ma/safety_reset.tex
index 41b511b..dea5ceb 100644
--- a/ma/safety_reset.tex
+++ b/ma/safety_reset.tex
@@ -89,6 +89,14 @@
 
 \subsubsection{Smart metering}
 
+\section{Smart meter technology}
+\subsubsection{Common components}
+
+Smart meters usually are built around a standard microcontroller. \label{sm-cpu}
+\subsubsection{Cryptographic coprocessors}
+\subsubsection{Physical structure}
+\subsubsection{Physical installation}
+
 \section{Regulatory frameworks around the world}
 \subsection{International standards}
 \subsection{Regulations in Europe}
@@ -117,6 +125,22 @@ grid need to be built to a much higher standard of security than most consumer d
 well-funded attackers even decades down the road. This requirement intensifies the challenges of embedded security and
 distributed systems security among others that are inherent in any modern complex technological system.
 
+A point we will not consider in much depth is theft of electricity. A large part of the motivation of the introduction
+of smart meters seems to be % TODO weak statement 
+to reduce the level of fraud by consumers. Academic papers tend to either focus on other benefits such as generation
+efficiency gains through better forecasting or try to rationalize the funamentally anti-consumer nature of smart
+metering with strenuous claims of ``enormous social benefits''\cite{mcdaniel01}. We will entirely focus on grid
+stability and discard electricity theft in the context of this paper for two reasons: One, billing inaccuracies of
+electricity companies are of very low urgency compared to grid stability, and the one is a precondition for the other.
+Two, utility companies can already put strong bounds on the amount of theft by simply cross-refrencing meter readings
+against trusted readings from upstream sections of the grid.  This capability works even without smart meters and only
+gains speed from smart meters, just as the old exploit of bypassing the meter with a section of wire can't be prevented
+like this.
+
+Due to these bounds on its volume, electricity theft using smart meter hacking would not scale. Hackers would simply be
+rooted up one by one with no damage to consumers and very limmited damage to utility companies. Damage in these
+scenarios would be a far cry from the efficiency of an exponentially growing botnet.
+
 \subsection{Smart grid components as embedded devices}
 A fundamental challenge in smart grid implementations is the central role smart electricity meters play. Smart meters
 are used both for highly-granular load measurement and (in some countries) load switching\cite{zheng01}.
@@ -128,8 +152,9 @@ against attacks and simplify updates. Combined with the small market sizes in sm
 \footnote{
     Most vendors of smart electricity meters only serve a handful of markets. For the most part, smart meter development
     cost lies in the meter's software % TODO cite?
-    and most countries use their own home-grown standards, creating a large development burden for new market entrants
-    \cite{cenelec01}.
+    There exist multiple competing standards applicable to various parts of a smart electricity meter. In addition,
+    most countries have their own certification regimen\cite{cenelec01}. This complexity creates a large development
+    burden for new market entrants.
 }
 this produces a high cost pressure on the software development process for smart electricity meters.
 
@@ -194,6 +219,12 @@ service attack. Thus, in addition to cryptographic security safety under DoS con
 continued system performance under attacks. This safety property is identical with the safety required to withstand
 random outages of components, such as communications link outages due to physical damage from storms, flooding etc.
 % FIXME cite papers on attack impact, on coutermeasures and on attack realization
+In general, attacks at the meter level may be hard to weaponize % may be -> weak statement?
+since meters are used mostly for billing and forecasting purposes % FIXME cite
+and for more critical grid control purposes there exist several additional layers of sensors above smart meters that
+limit how much an attacker can falsify smart meter readings without the manipulation being obvious. In order for an
+attack to have more far-reaching consequences the attacker would need to compromise additional grid
+infrastructure\cite{kim01,kosut01}.
 
 \subsubsection{Exploiting centralized control systems}
 The type of smart grid attack most often cited in popular discourse, and to the author's knowledge % FIXME verify, cite
@@ -245,8 +276,8 @@ access to thousands of devices hidden inaccessible in private homes.
 By compromising smart electricity meters, an attacker can trivially forge the distributed energy measurements these
 devices perform. In a best-case scenario, this might only affect billing and lead to customers being under- or
 over-charged if the attack is not noticed in time. However, in a less ideal scenario the energy measurements taken by
-these devices migth be used to inform the grid centralized control systems % FIXME cite (straightforward)
-and a falsification of these measurements might lead to inefficiency or even instability.
+these devices migth be used to inform the grid centralized control systems % FIXME cite
+and a falsification of these measurements might lead to inefficiency.
 
 In some countries and for some customers, these smart meters have one additional function that is highly useful to an
 attacker: They contain high-current load switches to disconnect the entire household or business in case electricity
@@ -266,9 +297,76 @@ that was mentioned above, this scenario poses a serious danger to grid stability
 \subsection{Practical attacks}
 \subsection{Practical threats}
 \subsection{Conclusion, or why we are doomed}
+We can conclude that a compromise of a large number of smart electricity meters cannot be ruled out. The complexity of
+network-connected smart meter firmware makes it exceedingly unlikely that it is in fact flawless. Large-scale
+deployments of these devices under some circumstances such as where they are used with load disconnect relays make them
+an attractive target for attackers interested in causing grid instability. The attacker model for these devices very
+definitely includes enemy states, who have considerable resources at their disposal.
+
+For a reasonable guarantee that no large-scale compromises of hard- and software built today will happen over a span of
+some decades, we would have to radically simplify its design and limit attack surface. Unfortunately, the complexity of
+smart electricity meter implementations mostly stems from the large list of requirements these devices have to conform
+with. Additionally, standards have already been written and changes that reduce scope or functionality have become
+exceedingly unlikely at this point.
+
+A general observation with smart grid systems of any kind is that they comprise a zealous departure of the decentralized
+control structure of yesterday's dumb grid and the advent of centralization at an enormous scale. This modern,
+centralized infrastructure has been carefully designed to defend against malicious actors%FIXME cite
+and all involved parties have an interest in keeping it secure. Still, like in any other system this centralization also
+makes a very attractive target for attackers since an attacker can likewise employ this centralized control to their
+goals. Fundamentally, decentralized systems tend to make attacks of any kind a lot more costly and one might question
+whether security has truly been gained during smart grid rollout. % FIXME hot take maybe
 
 \chapter{Restoring endpoint safety in an age of smart devices}
+If as layed out in the previous paragraph we cannot rule out a large-scale compromise of smart energy meters, we have to
+rephrase our claim to security. If we cannot rule out exploitation, we have to limit its impact. If we assume that we
+cannot strip any functionality from smart meters since it may be required by standards or for enormous social
+benefits\cite{mcdaniel01} % FIXME is sarcasm ok here?
+all we can do is to flush out an attacker once they are in.
+
+In a worst-case scenario an attacker would gain unconstrained code execution e.g. by exploiting a flaw in a network
+protocol implentation. Since smart meters use standard microcontrollers that do not have advanced memory protection
+functions (see pg. \ref{sm-cpu}), at this point we can assume the attacker has full control over the main
+microcontroller. With this control they can actuate the load switch if present, transmit data through the device's
+communication interfaces or use the user interface components such as LEDs and the LCD. Using the self-programming
+capabilities of modern flash microcontrollers, an attacker may even gain persistency without much trouble. Note that in
+systems separating cryptographic functions into some form of cryptographic module such as systems used in Germany
+    % TODO list other countries as well? FIXME cite BSI standard requiring this
+we can be optimistic and assume the attacker has not in fact compromised this cryptographic co-processor yet and does
+not have access to any cryptographic secrets yet.
+
+Given that the attacker has complete control over the meter's core microcontroller and given that due to cost
+constraints we are bound to use whatever microcontroller the meter OEM has chosen for their design, we cannot rely on
+software running on the core mircocontroller to restore system integrity.
+
+Our solution to this problem is to add another, very small microcontroller to the smart meter design. This
+microcontroller will contain a small piece of software to receive cryptographically authenticated commands from utility
+companies and on demand reset the meter's core microcontroller to a known-good state. We have to assume the code in the
+core controller's flash memory has been compromised, so our only option to flush out an attacker is to re-program the
+core microcontroller in its entirety. We propose using JTAG to re-program the core microcontroller
+    % TODO get terminology consistent. Is "core microcontroller" a good term here?
+with a known-good firmware image read from a sufficiently large SPI flash connected to the reset controller. JTAG is
+supported by most microcontrollers complex enough to end up in a smart meter design % TODO colloquialism
+and given adequate documentation JTAG programming functionality can be ported to new microcontrollers with relatively
+little work.
+
+On the microcontroller side our solution requires the JTAG interface to be activated (i.e. not fused-shut) and for our
+solution to work core microcontroller firmware must not be able to permanently disable the JTAG interface from within.
+In microcontrollers that do not yet provide this functionality this is a minor change that could be added to a custom
+microcontroller variant at low cost. On most microcontrollers keeping JTAG open should not interfere with code readout
+protection. Code secrecy should be of no concern\cite{schneier01} here but besides security manufacturers have strong
+preferences about this due to fear of copyright infringement.
+
 \section{The theory of endpoint safety}
+In order to gain anything by adding our reset controller to the smart meter's already complex design we must satisfy two
+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
+\end{enumerate}
+
+% FIXME expand
+
 \subsection{Attack characteristics}
 \subsection{Complex microcontroller firmware}
 \subsection{Modern microcontroller hardware}
@@ -313,6 +411,21 @@ that was mentioned above, this scenario poses a serious danger to grid stability
 \section{Technical standardization}
 \section{Regulatory adoption}
 \section{Practical implementation}
+\section{Zones of trust}
+In our design, we opted for a safety reset controller 
+    % FIXME is "safety reset" the proper name here? We need some sort of branding, but is this here really about "safety"?
+in form of a separate micocontroller entirely separate from whatever application microcontroller the smart meter design
+is already using.
+
+This design nicely separates the meter into an untrusted application (the core microcontroller) and the trusted reset
+controller. Since the interface between the two is simple and logically one-way, it can be validated to a high standard
+of security.
+
+Despite these security benefits, the cost of such a separate hardware device might prove high in a mass-market rollout.
+In this case, one might attempt to integrate the reset controller into the core microcontroller in some way. Primarily,
+there would be two ways to accomplish this.
+% separate die/submodule
+% trustzone
 
 \newpage
 \appendix