jaseg/master-thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

ma: add figures, add some blurb on demonstrator

Browse source
This commit is contained in:
jaseg 2020-05-07 12:46:27 +02:00
parent 678078bf1d
commit 0908130e6f
2 changed files with 238 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

22
ma/safety_reset.bib
View file

@ -952,4 +952,26 @@
url = {https://www.bmwi.de/Redaktion/DE/Publikationen/Studien/digitalisierung-der-energiewende-thema-1.pdf?__blob=publicationFile&v=4},
}
@Misc{easymeter01,
author = {{EasyMeter GmbH}},
date = {2020},
title = {Datenblatt Moderne Messeinrichtung Q3A Drehstromzähler},
}
@Misc{honeywell01,
author = {{Honeywell Smart Energy}},
date = {2017},
title = {Datasheet Honeywell REX2 smart meter},
url = {https://www.elstersolutions.com/assets/products/products_elster_files/SEADSNAEN001017REX2.pdf},
}
@WWW{ifixit01,
author = {Miro Djuric},
date = {2011},
title = {Elster REX2 Smart Meter Teardown},
url = {https://www.ifixit.com/News/14306/elster-rex2-smart-meter-teardown},
organization = {iFixit},
urldate = {2020-05-06},
}
@Comment{jabref-meta: databaseType:biblatex;}

235
ma/safety_reset.tex
View file

@ -55,7 +55,6 @@
\usepackage[draft=false,babel,tracking=true,kerning=true,spacing=true]{microtype} % optischer Randausgleich etc.
% For german quotation marks
\newcommand{\foonote}[1]{\footnote{#1}}
\newcommand{\degree}{\ensuremath{^\circ}}
\newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}}
@ -759,6 +758,7 @@ Error correcting codes are a very broad field with many options for specializati
more than a prototype in this thesis we chose to not expend resources on optimization too much and settled for a
comparatively simple low-density parity check code. The state of the art has advanced considerably since the discovery
of general LDPC codes. %FIXME cite
% FIXME LDPC is old, new is Reed-Solomon!
The main areas of improvement are overhead and decoding speed. Since transmission length % FIXME have we defined this yet?
in our system limits system response time but we do not have a fixed target there we can tolerate some degree of
sub-optimal overhead. % FIXME get actual pröper numbers on our stuff vs. some state of the art citations.
@ -770,6 +770,7 @@ or C++ implementation that we can adapt to embedded firmware. LDPC codes are a p
error-correcting codes and we had no particular difficulty finding either.
\subsection{Cryptographic security}
\label{sec-crypto}
Informally the system we are looking for can be modelled as consisting of three parties: The trusted
\textsc{Transmitter}, one of a large number of untrusted \textsc{Receivers}, and an \textsc{Attacker}. These three play
@ -1247,13 +1248,8 @@ applying it to the test waveforms from \textcite{wright01}. In this test we got
\label{freq_meas_rocof_reference}
\end{figure}
% Easymeter teardown fixmes:
% FIXME include board composite img
% FIXME include xray composite
% FIXME include channel xray
% FIXME include power supply xray
\section{Channel simulation and parameter validation}
\label{sec-ch-sim}
To validate all layers of our communication stack from modulation scheme to cryptography we built a prototype
implementation in python. Implementing all components in a high-level language builds up familiartiy with the concepts
@ -1342,15 +1338,13 @@ indicates SER is related fairly monotonically to the signal-to-noise margins ins
\end{figure}
\begin{figure}
\begin{subfigure}{\textwidth}
\centering
\includegraphics{../lab-windows/fig_out/dsss_thf_amplitude_5678}
\label{dsss_thf_amplitude_5678}
\caption{
\footnotesize SER vs.\ amplitude graph similar to fig.\ \ref{dsss_gold_nbits_overview} with dependence on
threshold factor color-coded. Each graph shows traces for a single DSSS symbol length.
}
\end{subfigure}
\centering
\includegraphics{../lab-windows/fig_out/dsss_thf_amplitude_5678}
\caption{
SER vs.\ amplitude graph similar to fig.\ \ref{dsss_gold_nbits_overview} with dependence on threshold factor
color-coded. Each graph shows traces for a single DSSS symbol length.
}
\label{dsss_thf_amplitude_5678}
\end{figure}
\begin{figure}
\ContinuedFloat
@ -1446,13 +1440,209 @@ indicates SER is related fairly monotonically to the signal-to-noise margins ins
\section{Implementation of a demonstrator unit}
%FIXME
To demonstrate the viability of our reset architecture we decided to implement a demonstrator system. In this
demonstrator we use JTAG to reset part of a commodity smart meter from an externally-connected reset controller. The
reset controller receives its commands over the grid frequency modulation system we outlined in this thesis. To keep
implementation cost low the reset controller is fed a simulation of a modulated grid frequency signal through a standard
\SI{3.5}{\milli\meter} audio jack\footnote{
By generously cutting two PCB traces the meter we chose to use can be easily modified to provide strong galvanic
separation between grid and main application microcontroller. With this modification we have to supply power to its
main application MCU externally along with the JTAG interface.
}.
\subsection{Selecting a smart meter for demonstration purposes}
For our demonstrator to make sense we wanted to select a realistic reset target. In Germany where this thesis was
written a standards-compliant setup would consist of a fairly dumb smart meter and a smart meter gateway (SMGW)
containing all of the complex bidirectional protocol logic such as wireless or landline IP connectivity. The realistic
target for a setup in this architecture would be the components of an SMGW such as its communications modem or main
application processor. In the German architecture the smart meter does not even have to have a bi-directional data link
to the SMGW effectively mitigating any attack vector for remote compormise.
Despite these considerations we still chose to reset the application MCU inside smart meter for two reasons. One is that
SMGWs are much harder to come by on the second-hand market. The other is that SMGWs are a particular feature of the
German standardization landscape and in many other countries the functions of an SMGW are integrated into the meter
itself. % FIXME citation
In the end we settled on an Q3DA1002 three-phase 60A meter made by German manufacturer EasyMeter. This meter is typical
of what would be found in an average German household and can be acquired very inexpensively as new old stock on online
marketplaces.
The meter consists of a plastic enclosure with a transparent polycarbonate top part and a grey ABS bottom part that are
ultrasonically welded shut. In the bottom part of the case a PCB we call the \emph{measurement} board is potted in
epoxide resin (see fig.\ \ref{easymeter_composites}). This PCB contains three separate energy measurement ASICs for the
three phases (see fig.\ \ref{easymeter_detail_xrays}). It also contains a capacitive dropper power supply for the meter
circuitry and external modules such as a SMGW. The measurement board through three infrared links (one per phase)
communicates with a smaller unpotted PCB we call the \emph{display} board in the top of the case. This PCB handles
measurement logging and aggregation, controls a small segment LCD displaying totals and handles the externally
accessible \si{\kilo\watt\hour} impulse LED and serial IR links.
The measurement board does not contain any logging or outside communication interfaces. All of that is handled on the
display board by a Texas Instruments MSP430F2350 application MCU. This is a 16-bit RISC MCU with \SI{16}{\kilo\byte}
flash and \SI{2}{\kilo\byte} SRAM\footnote{
The microcontroller might seem a bit overkill for such a simple application, but most of its \SI{16}{\kilo\byte}
program flash is in fact used. A casual glance with Ghidra shows that a large part of program flash is expended on
keeping multiple redundant copies of energy consumption aggregates including error recovery in case of data
corruption and some effort has even been made to guard against data corruption using simple non-cryptographic
checksums. Another large part of the MCU's firmware handles data transmission over the meter's externally accessible
IR link through Smart Message Language\cite{bsi-tr-03109-1-IVb}.
}. There is an I2C EEPROM that is used in conjunction with the microcontroller's internal \SI{256}{\byte} data flash to
keep redundant copies of energy consumption aggregates. On the side of the base board is a 14-pin header containing both
a standard TI MSP430 JTAG pinout and an UART serial link for debugging. Conveniently the JTAG port was left enabled by
fuse in our particular production unit.
We chose to use this MSP430 series application MCU as our reset target. Though in this particular unit compromise is
impossible due to a lack of bi-directional communication links some of its sister models do contain bidirectional
communication links\cite{easymeter01} making compromise through communication interfaces at least a theoretical
possibility. In other countries meters with a similar architecture to the Q3DA1002 commonly include complex protocol
logic as part of the meter itself\cite{honeywell01,ifixit01}. As an example, the Honeywell REX2 uses a Maxim Integrated
71M6541 main application microcontroller along with a Texas Instruments CC1000 series radio transceiver and is
advertised to support both over-the-air firmware upgrades and a remotely accessible ``service control switch''.
\begin{figure}
\centering
\begin{subfigure}{\textwidth}
\centering
\includegraphics[width=0.6\textwidth]{resources/easymeter_board_composite.jpg}
\label{easymeter_display_board_composite}
\caption{
\footnotesize
Optical composite image of the display and data logging board in the top of the case. The six pins at the
top are the SPI chip-on-glass segment LCD. Of the eight pads on the left six are unused and two carry the
auxiliary power supply from the measurement board below. The bottom right section contains the
\si{\kilo\watt\hour} impulse LED and the angled IR communication LED. The flying wires
connect to the 14-pin JTAG and serial debug header.
}
\end{subfigure}
\begin{subfigure}{\textwidth}
\vspace{1cm}
\centering
\includegraphics[width=0.8\textwidth]{resources/easymeter_baseboard_composite.jpg}
\label{easymeter_measurement_board_composite}
\caption{
\footnotesize
Composite microfocus x-ray image of the potted measurement module in the bottom of the case. The ovals on
the top left and right are power supply and data jumper connections for external modules such as SMGW
interfaces. The bright parts at the bottom are the massive screw terminals with integrated current shunts.
The circuitry right of the three independent measurement channels is the power supply circuit for the
display board.
}
\end{subfigure}
\caption{
Composite images of the circuit boards inside the EasyMeter Q3DA1002 "smart" electricity meter used in our
demonstration.
}
\label{easymeter_composites}
\end{figure}
\begin{figure}
\centering
\begin{subfigure}{0.45\textwidth}
\centering
\includegraphics[width=\textwidth]{resources/easymeter_baseboard_channel.jpg}
\label{easymeter_channel_xray}
\caption{Microfocus x-ray of one channel's data acquisition circuit}
\end{subfigure}\hspace*{5mm}
\begin{subfigure}{0.45\textwidth}
\centering
\includegraphics[width=\textwidth]{resources/easymeter_baseboard_powersupply.jpg}
\label{easymeter_powersupply_xray}
\caption{Microfocus x-ray of the auxiliary power supply}
\end{subfigure}
\caption{
Microfocus x-rays of major sections of the EasyMeter Q3DA1002 measurement board
}
\label{easymeter_detail_xrays}
\end{figure}
\subsection{Firmware implementation}
We based our safety reset demonstrator firmware on the grid frequency sensor firmware we developed in sec.\
\ref{sec-fsensor}. We implemented DSSS demodulation by translating the python prototype code we developed in sec.\
\ref{sec-ch-sim} to embedded C code. After validating the C translation in extensive simulations we integrated our code
with a reed-solomon implementation and a libsodium-based implementation of the cryptographic protocol we designed in
sec.\ \ref{sec-crypto}. % FIXME WIP
To reprogram the target MSP430 microcontroller we ported over the low-level bitbang JTAG driver of
mspdebug\footnote{\url{https://github.com/dlbeer/mspdebug}}.
For all computation-heavy high-level modules of our firmware such as the DSSS demodulator or the grid frequency
estimator we wrote test fixtures that allow the same code that runs on the microcontroller to be executed on the host
for testing. These test fixtures are very simple C programs that load input data from a file or the command line, run
the algorithm and print results on standard output.
\section{Grid frequency modulation emulation}
To emulate a modulated grid frequency signal we superimposed a DSSS-modulated signal at the proper amplitude with
synthetic grid frequency noise generated according to the measurements we took in sec. \ref{sec-fsensor}. In this
primitive simulation we do not simulate the precise impulse response of the grid to a DSSS-modulated stimulus signal.
Our results still serve to illustrate the possibility of data transmission in this manner this impulse response can be
compensated for at the transmitter by selecting appropriate modulation parameters (e.g. chip rate and amplitude) and at
the receiver by equalization with a matched filter.
\section{Experimental results}
%FIXME
% FIXME
\section{Lessons learned}
%FIXME
Before settling on the commercial smart meter we first tried to use an EVM430-F6779 smart meter evaluation kit made by
Texas Instruments. This evaluation kit did not turn out well for two main reasons. One, it shipped with half the case
missing and no cover for the terminal blocks. Because of this some work was required to maintain electrical safety.
Even after mounting it in an electrically safe manner since the main MCU is not isolated from the grid and the JTAG port
is also galvanically coupled the safety reset controller prototype would also have to be galvanically isolated to not
pose an electrical safety risk. The second issue we ran into was that the EVM430-F6779 is based around an MSP430F6779
microcontroller. This microcontroller is a rather large part within the MSP430 series and uses a particularly new
revision of the CPU core and associated JTAG peripheral that are incompatible with all MSP430 programmers we tried to
use on it. mspdebug does not have support for it and porting TI's own JTAG programmer reference sources did not yield
any results either. Finally we tried an USB-based programmer made by TI themselves that turned out to either have broken
firmware or a hardware defect, leading to it frequently re-enumerating on the USB.
Overall our initial assumption that a development kit would certainly be easier to program than a commercial meter did
not prove to be true. Contrary to our expectations the commercial meter had JTAG enabled allowing us to easily read out
its stock firmware without needing to reverse-engineer vendor firmware update files or circumventing code protection
measures. The fact that its firmware was only available in its compiled binary form was not much of a hindrance as it
proved not to be too complex and all we wanted to know could be found out with just a few hours of digging in Ghidra.
In the firmware development phase our approach of testing every module individually (e.g. DSSS demodulator, Reed-Solomon
decoder, grid frequency estimation) proved to be very useful. In particular debugging benefited greatly from being able
to run a couple thousand tests within seconds. In case of our DSSS demodulator this modular testing and simulation
architecture allowed us to simulate many thousand runs of our implementation on test data and directly compare it to our
Jupyter/Python prototype (see fig.\ \ref{fw_proto_comparison}). Since we spent more time polishing our embedded C
implementation it turned out to perform much better than our initial python prototype. At the same time it shows
fundamentally similar response to its parameters. One significant bug we fixed in the embedded C version is the python
version's tendency towards incorrect decodings at even very large amplitudes.
\begin{figure}
\centering
\begin{subfigure}{\textwidth}
\centering
\includegraphics[trim={0 4cm 0 0},clip]{../lab-windows/fig_out/dsss_thf_amplitude_56_jupyter_impl}
\caption{Python prototype}
\end{subfigure}
\begin{subfigure}{\textwidth}
\centering
\includegraphics[trim={0 4cm 0 0},clip]{../lab-windows/fig_out/dsss_thf_amplitude_56_fw_impl}
\caption{Embedded C implementation}
\end{subfigure}
\caption{
Symbol error rate plots versus threshold factor for both our python prototype (above) and our firmware
implementation of our demodulation algorithm. Note the slightly different threshold factor color scales. Cf.\
fig.\ \ref{dsss_thf_amplitude_5678}.
}
\label{fw_proto_comparison}
\end{figure}
In accordance with our initial estimations we did not run into any code space nor computation bottlenecks for chosing
floating-point emulation instead of porting over our algorithms to fixed-point calculations. The extremely slow sampling
rate of our systems makes even heavyweight processing such as FFT or our rather brute-force dynamic programming approach
to DSSS demodulation possible well within performance constraints.
Compiled code size of our firmware implementation is slightly larger than we would like at around \SI{64}{\kilo\byte}
for our firmware image including everything except the target microcontroller firmware image. See appendix
\ref{symbol_size_chart} for a graph illustrating the contribution of various parts of the signal processing toolchain to
this total. Overall the most heavy-weight operations by far are the SHA512 implementation from libsodium and the FFT
from ARM's CMSIS signal processing library.
\chapter{Future work}
\section{Technical standardization}
@ -1553,12 +1743,19 @@ correctly configure than it is to simply use separate hardware and secure the in
%\includenotebook{Frequency sensor clock stability analysis}{gps_clock_jitter_analysis}
%\includenotebook{DSSS modulation experiments}{dsss_experiments-ber}
\chapter{Demonstrator schematics and code}
\chapter{Demonstrator Resources}
\section{schematics and code}
% FIXME
\chapter{Demonstrator Firmware Symbol Sizes}
\label{symbol_size_chart}
\includepdf[fitpaper]{resources/safetyreset-symbol-sizes.pdf}
\chapter{Economic viability of countermeasures}
\section{Attack cost}
\section{Countermeasure cost}
% FIXME maybe include a standard for the technical side of a safety reset system here, e.g. in the style of an IETF draft?
\end{document}