Browse Source

Renaming and added crypto concept

master
Dustin Frisch 5 years ago
parent
commit
34226ce063
No known key found for this signature in database GPG Key ID: B4C3BF012D9B26BE
  1. 6
      4-requirements.tex
  2. 0
      5-concept.tex
  3. 0
      6-1-update_mechanism.tex
  4. 0
      6-2-multidevice_build_structure.tex
  5. 0
      6-3-automatic-deployment.tex
  6. 6
      6-implementation.tex
  7. 0
      7-conclusion.tex
  8. 6
      esper-ota.tex

6
4-requirements.tex

@ -14,9 +14,9 @@ Even if the installation of an update fails in the middle of reprogramming the d
\subsubsection{}\label{req3}Firmware downloads should be performed over the same WiFi connection as used during normal operation.
Fetching the firmware should be done side-by-side with operational traffic.
\subsubsection{}\label{req4}The update process can happen over any untrusted wireless network or Internet connection without being vulnerable to attackers.
\subsubsection{}\label{req4}The update process can happen over any untrusted wireless network or Internet connection and therefor must not being vulnerable to attackers.
To prevent possible attackers from injecting malicious software into the embedded devices, a cryptographic signature mechanism must be implemented.
New firmware only gets accepted by the device, if the cryptographic signature of the downloaded firmware image can be verified.
New firmware only gets accepted by the device, iff the cryptographic signature of the downloaded firmware image can be verified.
\subsubsection{}\label{req5}To reduce network load and aim for the maximum possible uptime of the device, the update process should only be done if a new firmware version is available.
In contrast, on the release of new firmware, the roll-out to all devices should be performed as fast as possible.
@ -30,4 +30,4 @@ As the device type is hardly coupled to the hardware and the software interacts
\makeatletter
\renewcommand{\@IEEEsectpunct}{:\ \,}
\makeatother
\makeatother

0
foo.tex → 5-concept.tex

0
5-1-update_mechanism.tex → 6-1-update_mechanism.tex

0
5-2-multidevice_build_structure.tex → 6-2-multidevice_build_structure.tex

0
5-3-automatic-deployment.tex → 6-3-automatic-deployment.tex

6
5-implementation.tex → 6-implementation.tex

@ -7,6 +7,6 @@ It is responsible for checking and downloading the updates and installing them.
Second, the build system is in charge of building the firmware from source and publishing the built binary images.
Finally, the deployment provides infrastructure for downloading the binary firmware images and triggering the update on all devices.
\input{5-1-update_mechanism}
\input{5-2-multidevice_build_structure}
\input{5-3-automatic-deployment}
\input{6-1-update_mechanism}
\input{6-2-multidevice_build_structure}
\input{6-3-automatic-deployment}

0
6-conclusion.tex → 7-conclusion.tex

6
esper-ota.tex

@ -465,9 +465,9 @@ Secure Updates, Over the Air, ESP8266.
\input{2-related-work}
\input{3-environment}
\input{4-requirements}
\input{foo}
\input{5-implementation}
\input{6-conclusion}
\input{5-concept}
\input{6-implementation}
\input{7-conclusion}
% ************************************

Loading…
Cancel
Save