\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}