2 files changed, 238 insertions, 19 deletions
diff --git a/ma/safety_reset.bib b/ma/safety_reset.bib
index f4496e0..b2358cd 100644
--- a/ma/safety_reset.bib
+++ b/ma/safety_reset.bib
@@ -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;}
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}