ma: add some additional citations on crypto

2 files changed, 96 insertions, 14 deletions

diff --git a/ma/safety_reset.bib b/ma/safety_reset.bib
index c6e3df4..79496c7 100644
--- a/ma/safety_reset.bib
+++ b/ma/safety_reset.bib
@@ -1642,4 +1642,76 @@
   url    = {http://www.ti.com/lit/ug/snaa103/snaa103.pdf?ts=1591194443306},

 }

 

+@InProceedings{georgiev01,

+  author       = {Martin Georgiev and Subodh Iyengar and Suman Jana and Rishita Anubhai and Dan Boneh and Vitaly Shmatikov},

+  booktitle    = {ACM Conference on Computer and Communications Security},

+  date         = {2012},

+  title        = {The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software},

+  pages        = {38-49},

+  journaltitle = {CCS’12},

+}

+

+@Article{anderson04,

+  author       = {Ross Anderson and Francesco Bergadano and Bruno Crispo and Jong-Hyeon Lee and Charalampos Manifavas and Roger Needham},

+  date         = {1998},

+  journaltitle = {ACM SIGOPS Operating Systems Review},

+  title        = {A New Family of Authentication Protocols},

+  doi          = {https://doi.org/10.1145/302350.302353},

+}

+

+@InProceedings{haller01,

+  author    = {Neil M. Haller},

+  booktitle = {Symposium on Network and Distributed System Security},

+  date      = {1994},

+  title     = {The S/KEY One-Time Password System},

+  pages     = {151-157},

+}

+

+@TechReport{rfc1760,

+  author       = {Neil M. Haller},

+  date         = {1995},

+  institution  = {RFC Editor},

+  title        = {The S/KEY One-Time Password System},

+  doi          = {https://dx.doi.org/10.17487/RFC1760},

+  number       = {1760},

+  type         = {RFC},

+  url          = {https://tools.ietf.org/html/rfc1760},

+  urldate      = {2020-06-08},

+  howpublished = {Internet Requests for Comments},

+  publisher    = {RFC Editor},

+  year         = {1995},

+}

+

+@InProceedings{perrig01,

+  author    = {Adrian Perrig and Ran Canetti and J. D. Tygar and Dawn Song},

+  booktitle = {Proceeding 2000 IEEE Symposium on Security and Privacy. S{\&}P 2000},

+  date      = {2000},

+  title     = {Efficient Authentication and Signing of Multicast Streams over Lossy Channels},

+  doi       = {https://doi.org/10.1109/SECPRI.2000.848446},

+  isbn      = {0-7695-0665-8},

+  publisher = {IEEE},

+}

+

+@Article{diffie01,

+  author       = {Diffie, Whitfield and Hellman, Martin},

+  date         = {2976},

+  journaltitle = {IEEE transactions on Information Theory},

+  title        = {New directions in cryptography},

+  number       = {6},

+  pages        = {644--654},

+  volume       = {22},

+  journal      = {IEEE transactions on Information Theory},

+  publisher    = {IEEE},

+  year         = {1976},

+}

+

+@Online{ec05,

+  author  = {Ignacio Fernández Hernández},

+  editor  = {European Commission},

+  date    = {2019},

+  title   = {Increasing Digital Tachograph Resilience: Galileo Open Service Navigation Message Authentication},

+  url     = {https://ec.europa.eu/transparency/regexpert/?do=groupDetail.groupMeetingDoc&docid=36951},

+  urldate = {2020-06-08},

+}

+

 @Comment{jabref-meta: databaseType:biblatex;}

diff --git a/ma/safety_reset.tex b/ma/safety_reset.tex
index dc5bbad..0e6ed6e 100644
--- a/ma/safety_reset.tex
+++ b/ma/safety_reset.tex
@@ -2,6 +2,8 @@
 \usepackage[ngerman, english]{babel}
 \usepackage[utf8]{inputenc}
 \usepackage[a4paper, top=2cm, bottom=3.5cm, left=3cm, right=4cm]{geometry}
+% Matti remarkable tablet special size
+%\usepackage[paperwidth=15cm, paperheight=244mm, top=1cm, bottom=1cm, left=5mm, right=5mm]{geometry}
 \usepackage[T1]{fontenc}
 \usepackage[
     backend=biber,
@@ -850,7 +852,9 @@ firmware\cite{rosenberg01}. For an overview of ARM TrustZone including a survey
 vulnerabilities of TrustZone-based firmware see \cite{pinto01}.
 
 For their mass-market phones these companies have R\&D budgets that dwarf some countries' national budgets.  If even
-they have trouble securing their secure embedded software stacks, what is a smart meter manufacturer to do? 
+they have trouble securing their secure embedded software stacks, what is a smart meter manufacturer to do? If a
+standard as in case of the German one requires IP gateways to speak TLS, a protocol that is notoriously tricky to
+implement correctly\cite{georgiev01}, the manufacturer is short on options to secure their product.
 
 Since thorough formal verification of code is not yet within reach for either large-scale software development or code
 heavy in side-effects such as embedded firmware or industrial control software\cite{pariente01} the two most effective
@@ -1592,13 +1596,13 @@ can reduce the storage overhead of this ``database''.
 
 Along with the indistinguishability property the access requirement implies that we need a cryptographic
 signature\cite{lamport01}.  However, we have relaxed constraints on this signature compared to standard cryptographic
-practice.  While cryptographic signatures need to work over arbitrary inputs, all we want to ``sign'' here is the
-instruction to perform a safety reset. This is the only message we might ever want to transmit so our message space has
-only one element. The information content of our message thus is 0 bit! All the information we want to transmit is
-already encoded \emph{in the fact that we are transmitting} and we do not require a further payload to be transmitted:
-We can omit the entirety of the message and just transmit whatever ``signature'' we produce. This is useful to conserve
-transmission bits so our transmission does not take an exceedingly long time over our extremely slow communication
-channel.
+practice\cite{anderson04}.  While cryptographic signatures need to work over arbitrary inputs, all we want to ``sign''
+here is the instruction to perform a safety reset. This is the only message we might ever want to transmit so our
+message space has only one element. The information content of our message thus is 0 bit! All the information we want to
+transmit is already encoded \emph{in the fact that we are transmitting} and we do not require a further payload to be
+transmitted: We can omit the entirety of the message and just transmit whatever ``signature'' we
+produce\cite{haller01,rfc1760}. This is useful to conserve transmission bits so our transmission does not take an
+exceedingly long time over our extremely slow communication channel.
 
 We can modify this construction to allow for a small number of bits of information content in our message (say two or
 three instead of zero) at no transmission overhead by transmitting the cryptographic signature as usual but simply
@@ -1634,9 +1638,14 @@ length and by proxy system latency would be determined by the length of the sign
 modulus length (i.e. larger than \SI{1000}{bit} for very basic contemporary security). For elliptic curve-based systems
 curve length is approximately twice the security level and signature size is twice the curve length because two curve
 points need to be encoded\cite{anderson02}.  For contemporary security this results in more than 300 bit transmission
-length. We can exploit our unique setting's low message entropy to improve on this.
-
-% FIXME add some intro/background blurb here
+length. We can exploit our unique setting's low message entropy to improve on this by basing our scheme on a
+cryptographic hash function used as a one-way pseudo-random function (PRF). Hash-based signature schemes date back to
+the very beginnings of cryptographic signatures\cite{anderson04,diffie01,lamport02}. Today, in general applications
+schemes based on asymmetric cryptography are preferred but hash-based signature systems have their applications in
+certain use cases. One example of such a scheme is the TESLA scheme\cite{perrig01} that is the basis for navigation
+message authentication in the European Galileo global navigation satellite system. Here, a system based purely on
+asymmetric primitives would result in too much computation and communication overhead\cite{ec05}.  In the following
+sections we will introduce the foundations of hash-based signatures before deriving our authentication scheme.
 
 \subsubsection{Lamport signatures}
 
@@ -1710,7 +1719,9 @@ signature this receiver recorded or $p$ in case there is none.
 
 This scheme provides replay protection since the receiver memorizes the last signature they acted on. Public key length
 is equal to the length of the hash function $H$ used. Even for our embedded systems use case $n$ can realistically be up
-to $\mathcal O\left(10^3\right)$, which is enough for our purposes.
+to $\mathcal O\left(10^3\right)$, which is enough for our purposes. This use of a hash chain for event authentication is
+identical to the one in the S/KEY one-time password system\cite{anderson04,haller01,rfc1760}.
+% 1990ies crypto yeah!
 
 The ``disarm'' message we discussed above for replay protection can be integrated into this scheme by encoding the
 ``enable'' bit into the least significant bit of $n$ in our $H^n$ construction. In the chain of valid signatures every
@@ -1732,7 +1743,6 @@ transmitter key management is shown in Figure \ref{fig:tx_scope_key_illu}. This
 our prototype in Section \ref{sec-prototype} and may even be useful in a practical implementation. During
 standardization of a safety reset system the key management system would most likely have to be customized to the
 particular application's requirements. Developing an universal solution is outside the scope of this work.
-% FIXME revisit this section - 2020-05-26
 
 \begin{figure}
     \centering
@@ -1753,7 +1763,7 @@ particular application's requirements. Developing an universal solution is outsi
 
 \begin{figure}
     \centering
-    \includegraphics{resources/transmitter_scope_key_illustration}
+    \includegraphics[width=\textwidth]{resources/transmitter_scope_key_illustration}
     \caption{
         An illustration of a key management system using a common master key. First, the transmitter derives one secret
         key for each addressable group from the master key. Then public device keys are generated like in Figure