From 50998fcfb916ae251309bd4b464f2c122e8cb30d Mon Sep 17 00:00:00 2001 From: jaseg Date: Fri, 9 Apr 2021 18:38:02 +0200 Subject: Repo re-org --- proposal/bom.ods | Bin 0 -> 12713 bytes proposal/project_proposal.pdf | Bin 0 -> 122382 bytes proposal/project_proposal.tex | 154 ++++++++++++++++++++++++++++++++++ proposal/smart_reset_bom_v01.ods | Bin 0 -> 12713 bytes proposal/smart_reset_overview_v01.pdf | Bin 0 -> 123428 bytes proposal/smart_reset_overview_v02.pdf | Bin 0 -> 122382 bytes 6 files changed, 154 insertions(+) create mode 100644 proposal/bom.ods create mode 100644 proposal/project_proposal.pdf create mode 100644 proposal/project_proposal.tex create mode 100644 proposal/smart_reset_bom_v01.ods create mode 100644 proposal/smart_reset_overview_v01.pdf create mode 100644 proposal/smart_reset_overview_v02.pdf (limited to 'proposal') diff --git a/proposal/bom.ods b/proposal/bom.ods new file mode 100644 index 0000000..501ad0d Binary files /dev/null and b/proposal/bom.ods differ diff --git a/proposal/project_proposal.pdf b/proposal/project_proposal.pdf new file mode 100644 index 0000000..d272e9b Binary files /dev/null and b/proposal/project_proposal.pdf 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} @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 Binary files /dev/null and b/proposal/smart_reset_bom_v01.ods differ diff --git a/proposal/smart_reset_overview_v01.pdf b/proposal/smart_reset_overview_v01.pdf new file mode 100644 index 0000000..cb2ba14 Binary files /dev/null and b/proposal/smart_reset_overview_v01.pdf differ diff --git a/proposal/smart_reset_overview_v02.pdf b/proposal/smart_reset_overview_v02.pdf new file mode 100644 index 0000000..d272e9b Binary files /dev/null and b/proposal/smart_reset_overview_v02.pdf differ -- cgit