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

ma: add some additional citations on crypto

Browse source
This commit is contained in:
jaseg 2020-06-08 14:39:37 +02:00
parent f37bfb6cbb
commit 07a354e969
2 changed files with 96 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

72
ma/safety_reset.bib
View file

@ -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;}

38
ma/safety_reset.tex
View file

@ -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