summaryrefslogtreecommitdiff
path: root/ma/safety_reset.tex
diff options
context:
space:
mode:
authorjaseg <git-bigdata-wsl-arch@jaseg.de>2020-05-07 12:46:27 +0200
committerjaseg <git-bigdata-wsl-arch@jaseg.de>2020-05-07 12:46:27 +0200
commit0908130e6fc412a0586357cd35aad24144d0b96c (patch)
treef3f127d4c0be37be93a70aa9b7b4a543ce007679 /ma/safety_reset.tex
parent678078bf1d708223dff0bb812337137278819f28 (diff)
downloadmaster-thesis-0908130e6fc412a0586357cd35aad24144d0b96c.tar.gz
master-thesis-0908130e6fc412a0586357cd35aad24144d0b96c.tar.bz2
master-thesis-0908130e6fc412a0586357cd35aad24144d0b96c.zip
ma: add figures, add some blurb on demonstrator
Diffstat (limited to 'ma/safety_reset.tex')
-rw-r--r--ma/safety_reset.tex235
1 files changed, 216 insertions, 19 deletions
diff --git a/ma/safety_reset.tex b/ma/safety_reset.tex
index 56dc541..8f8c956 100644
--- a/ma/safety_reset.tex
+++ b/ma/safety_reset.tex
@@ -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}