Repo re-org

proposal/project_proposal.tex

@@ -0,0 +1,154 @@
+\documentclass[12pt,a4paper,notitlepage]{article}
+\usepackage[utf8]{inputenc}
+\usepackage[a4paper,textwidth=17cm, top=2cm, bottom=3.5cm]{geometry}
+\usepackage[T1]{fontenc}
+\usepackage[
+    backend=biber,
+    style=numeric,
+    natbib=true,
+    url=true, 
+    doi=true,
+    eprint=false
+    ]{biblatex}
+\addbibresource{directions.bib}
+\usepackage{amssymb,amsmath}
+\usepackage{listings}
+\usepackage{eurosym}
+\usepackage{wasysym}
+\usepackage{amsthm}
+\usepackage{tabularx}
+\usepackage{multirow}
+\usepackage{multicol}
+\usepackage{tikz}
+
+\usetikzlibrary{arrows}
+\usetikzlibrary{backgrounds}
+\usetikzlibrary{calc}
+\usetikzlibrary{decorations.markings}
+\usetikzlibrary{decorations.pathreplacing}
+\usetikzlibrary{fit}
+\usetikzlibrary{patterns}  
+\usetikzlibrary{positioning}
+\usetikzlibrary{shapes}
+
+\usepackage{hyperref}
+\usepackage{tabularx}
+\usepackage{commath}
+\usepackage{graphicx,color}
+\usepackage{subcaption}
+\usepackage{float}
+\usepackage{footmisc}
+\usepackage{array}
+\usepackage[underline=false]{pgf-umlsd}
+\usetikzlibrary{calc}
+%\usepackage[pdftex]{graphicx,color}
+%\usepackage{epstopdf}
+
+\newcommand{\foonote}[1]{\footnote{#1}}
+\newcommand{\degree}{\ensuremath{^\circ}}
+\newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}}
+
+\author{Sebastian Götte {\texttt<srsrst@jaseg.net>} @HIIG Berlin}
+\title{Future-Proof Security Architecture for Smart Electricity Meters}
+\date{October 14 2019}
+\begin{document}
+\maketitle
+
+\section{Problem Statement}
+After much excitement in both academia and industry, the rollout of ``smart'' electricity meters is well underway today.
+From online materials we observe that these systems tend to be country-specific systems which are rolled out at massive
+scale. Often, this results a near-monoculture. All of these systems contain highly complex communications interfaces
+such as powerline communications (PLC), DSL or cellular. Many of these "metering" systems additionally include a load
+switch to disconnect non paying subscribers.  Since smart meters are fairly expensive at O(\euro 100) for the device in
+addition to high installation costs, their expected lifetime is measured in decades.
+
+To a security researcher, these circumstances pose a conundrum. What one has is an IP-connected device that can turn off
+someone's electricity, that is produced by a small to medium-sized business and that is supposed to run for decades
+without being hacked.
+
+Experience shows that even large megacorporations have difficulty maintaining software for just a couple of years. At
+the same time, flawless software does not exist. Even with utmost care and ulimited resources, and in
+comparatively simple firmware, serious security flaws cannot be ruled out. As a case in point, Apple recently had to
+see itself confronted with a very embarassing bug inside the first ROM bootloader stage of the secure boot chain used in
+most iPhones currently in use. This bug allows a full compromise of the system on boot. When even Apple with all its
+resources cannot manage to secure such a fairly unsophisticated component underpinning the security of the entire iPhone
+ecosystem, what is the Mittelstand to do trying to secure hundreds of kilobytes of code? If Apple cannot afford or
+manage to secure a few hundred bytes worth of highly critical firmware, how should anyone else?
+
+From a security point of view the systems employed in this ``smart'' grid infrastructure are too complex for their
+makers to handle by several orders of magnitude.  Their (in internet terms) extremely long life spans make them likely
+to outlast their manufacturers.  The potential for mayhem caused through their load switches makes them an attractive
+target for state-sponsored attackers.
+
+From a security expert's point of view given the circumstances outlined above taken over tens of years a large-scale
+compromise of smart grid infrastructure in at least one of the 24 countries participating in the synchronous grid of
+Continental Europe is likely as long as there is someone trying. 
+
+\section{Our Solution}
+Given the inevitability of serious compromise outlined above, and assuming industry and government inertia in continuing
+the rollout of the current generation of smart meter architecture, the only thing we can still do is damage control.
+How can we regain control after a large-scale smart grid compromise?
+
+In this project we propose a hardware measure that can be integraded with any smart meter regardless of manufacturer and
+technology that allows a grid operator to restore large numbers of compromised meters to a known-good firmware image.
+The grid operator transmits a cryptographically secured reset signal through a modulation of mains frequency that is
+picked up by the hardware reset controller. The hardware reset controller then resets and re-programs the meter's main
+application microcontroller with a known-good factory image. This could be either the meter's original factory firmware
+or a more minimal bootloader designed to allow the electricity companies to re-gain control of the meter outside their
+usual software update channels.
+
+\section{Project Scope and Open Questions}
+
+This project consists of three major steps in addition to a nice specification of attacker model and attack scenarios.
+
+\setlength{\fboxsep}{1.5em}
+\begin{center}
+    \fbox{\parbox[c]{12cm}{{\textbf Q1\quad}\emph{
+        How would realistic attackers and attack scenarios look like?
+        }}}
+\end{center}
+
+\subsection{Figuring out signal transmission}
+
+First, we need to assess feasibility and parameters of our proposed signal transmission method.
+
+\begin{center}
+    \fbox{\parbox[c]{12cm}{{\textbf Q2\quad}\emph{
+        What control do grid operators have over variables such as mains frequency and phase? How does this compare
+        against normal variations?
+        }}}
+\end{center}
+
+With this knowledge, we will calculate the parameters of our communication channel. Given these channel parameters, we
+will define details such as modulation scheme and error correction. To aid in validation, we will test a mockup of this
+system on a simulated channel.
+
+\begin{center}
+    \fbox{\parbox[c]{12cm}{{\textbf Q3\quad}\emph{
+        How robust would this system be against an advanced active attacker, in particular one that has already pwned a
+        couple million smart meters with load switches?
+        }}}
+\end{center}
+
+\subsection{Specifying the transmission protocol}
+
+After specifying modulation and FEC parameters we need to specify communication protocol and cryptographic details. We
+will likely have a highly constrained bitrate, so our overall protocol and cryptographic implementation must be highly
+efficient in transmission size. All interfaces (modulation, protocol and cryptography included) must be carefully
+specified and validated to reduce the likelihood of errors at this step. The cryptographic protocol should ideally be
+formally proven. The overall system of modulation, FEC and cryptographic protocol should be analyzed w.r.t.\ bit error
+rate and the resulting expected failure rate.
+
+\subsection{Building a hardware prototype}
+
+To demonstrate overall viability, a hardware prototype will be constructed. This will be based on a smart meter
+reference design of a major semiconductor manufacturers.
+
+\begin{center}
+    \fbox{\parbox[c]{12cm}{{\textbf Q4\quad}\emph{
+        How can we simulate the electric grid, as well as our proposed modulation thereof in this demo setup? Gasoline
+        generator? DDS signal generator plus car audio amplifier plus toroidal halogen transformer?
+        }}}
+\end{center}
+
+\end{document}