summaryrefslogtreecommitdiff
path: root/proposal
diff options
context:
space:
mode:
authorjaseg <git-bigdata-wsl-arch@jaseg.de>2021-04-09 18:38:02 +0200
committerjaseg <git-bigdata-wsl-arch@jaseg.de>2021-04-09 18:38:57 +0200
commit50998fcfb916ae251309bd4b464f2c122e8cb30d (patch)
tree4ecf7a7443b75ab51c4dc0c0fc9289342dc7d6a0 /proposal
parent312fee491cfab436d52db4b6265107e20f3e1293 (diff)
downloadmaster-thesis-50998fcfb916ae251309bd4b464f2c122e8cb30d.tar.gz
master-thesis-50998fcfb916ae251309bd4b464f2c122e8cb30d.tar.bz2
master-thesis-50998fcfb916ae251309bd4b464f2c122e8cb30d.zip
Repo re-org
Diffstat (limited to 'proposal')
-rw-r--r--proposal/bom.odsbin0 -> 12713 bytes
-rw-r--r--proposal/project_proposal.pdfbin0 -> 122382 bytes
-rw-r--r--proposal/project_proposal.tex154
-rw-r--r--proposal/smart_reset_bom_v01.odsbin0 -> 12713 bytes
-rw-r--r--proposal/smart_reset_overview_v01.pdfbin0 -> 123428 bytes
-rw-r--r--proposal/smart_reset_overview_v02.pdfbin0 -> 122382 bytes
6 files changed, 154 insertions, 0 deletions
diff --git a/proposal/bom.ods b/proposal/bom.ods
new file mode 100644
index 0000000..501ad0d
--- /dev/null
+++ b/proposal/bom.ods
Binary files differ
diff --git a/proposal/project_proposal.pdf b/proposal/project_proposal.pdf
new file mode 100644
index 0000000..d272e9b
--- /dev/null
+++ b/proposal/project_proposal.pdf
Binary files differ
diff --git a/proposal/project_proposal.tex b/proposal/project_proposal.tex
new file mode 100644
index 0000000..eec56bf
--- /dev/null
+++ b/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}
diff --git a/proposal/smart_reset_bom_v01.ods b/proposal/smart_reset_bom_v01.ods
new file mode 100644
index 0000000..501ad0d
--- /dev/null
+++ b/proposal/smart_reset_bom_v01.ods
Binary files differ
diff --git a/proposal/smart_reset_overview_v01.pdf b/proposal/smart_reset_overview_v01.pdf
new file mode 100644
index 0000000..cb2ba14
--- /dev/null
+++ b/proposal/smart_reset_overview_v01.pdf
Binary files differ
diff --git a/proposal/smart_reset_overview_v02.pdf b/proposal/smart_reset_overview_v02.pdf
new file mode 100644
index 0000000..d272e9b
--- /dev/null
+++ b/proposal/smart_reset_overview_v02.pdf
Binary files differ