From 9631d1f9d985e4436d2b138f5f83e7a7e9602be8 Mon Sep 17 00:00:00 2001 From: axtloss Date: Mon, 26 Feb 2024 21:23:40 +0100 Subject: Add assignment paper --- .../idee/gewaehlte_implementation.tex | 15 +++++++++++++++ doc/class-assignment/idee/hashquellen.tex | 21 +++++++++++++++++++++ doc/class-assignment/idee/idee.tex | 14 ++++++++++++++ doc/class-assignment/idee/implementierungen.tex | 17 +++++++++++++++++ 4 files changed, 67 insertions(+) create mode 100644 doc/class-assignment/idee/gewaehlte_implementation.tex create mode 100644 doc/class-assignment/idee/hashquellen.tex create mode 100644 doc/class-assignment/idee/idee.tex create mode 100644 doc/class-assignment/idee/implementierungen.tex (limited to 'doc/class-assignment/idee') diff --git a/doc/class-assignment/idee/gewaehlte_implementation.tex b/doc/class-assignment/idee/gewaehlte_implementation.tex new file mode 100644 index 0000000..38f5b5c --- /dev/null +++ b/doc/class-assignment/idee/gewaehlte_implementation.tex @@ -0,0 +1,15 @@ +\subsection{Gewählte Implementation} +Im anbetracht existierender Dateiverifizierungsprogrammen wie Androids dm-verity und mein vorheriges, ähnliches Projekt \href{https://github.com/linux-immutability-tools/FsGuard}{FsGuard}. +\\ +Für die Implementation habe ich die Blockverifizierung ausgewählt, da sie durch Multithreading sehr schnell sein kann, aber auch neue Datein bemerkt, welches die Per-Datei Verifizierung nicht gewährleistet. +\\ +Um die Hashes zu Speichern wird ein eigenes Partitionsschema benutzt, welches alle Metadaten und die Datenbank beinhaltet. Der minisign öffentliche Schlüssel kann durch mehrere Methoden gespeichert werden, wie einer Textdatei oder einem gerät welches über USB-Serial den Schlüssel übergibt. +\\ +Weitere Eintscheidungen für die Implementation sind: +\begin{itemize} +\item Programmiersprache: go\\ + go ist mir vertraut und memory safe, welches für die Sicherheit des Programmes eine große Rolle spielt. +\item Datenbank: bbolt\\ + bbolt ist eine Datenbank welche direkt in go geschrieben wurde und somit ein Robusteren API als sqlite hat, zudem ist bbolt unter einer richtigen lizens lizensiert und wirkt moderner. +\end{itemize} + diff --git a/doc/class-assignment/idee/hashquellen.tex b/doc/class-assignment/idee/hashquellen.tex new file mode 100644 index 0000000..f101d8b --- /dev/null +++ b/doc/class-assignment/idee/hashquellen.tex @@ -0,0 +1,21 @@ +\subsection{Hash Quellen} +Wie bereits gesagt, braucht das Verifizierungsprogramm eine vertraute Quelle für die korrekten Hashes. +Hier gibt es auch verschiedene Lösungsansätze, was jedoch alle gemeinsam haben ist, dass sie eine Quelle und eine sichere Methode um diese Quelle zu verifizieren brauchen. +\\ +Für die Quellen gibt es viele verschieden möglichkeiten, bei der Entwicklung von fsverify hatte ich die Wahl auf zwei möglichkeiten begrenzt, da beide sehr einfach zu implementieren sind, und dadurch die Verifizierung der Quellen auch einfach ist. +\begin{itemize} +\item Externe Partition\\ + Hier wird eine Datenbank an Hashes zusammen mit allen Metadaten in eine extra Partition geschrieben, diese Partition kann auf ein Externes medium geschrieben werden, und nur dann angeschlossen sein, wenn das System die Verizifizierung durchführt. + Jedoch braucht dies entweder eine seperate Partition auf der Festplatte, wodurch die nutzbare Speicherkapazität sich verringert, oder ein externes Medium, welches nicht immer vorhanden ist. +\item Einfache Datei\\ + Hier wird die Datenbank einfach in einem Ort gespeichert, auf die das Program während der Verifizierung zugreifen kann. Dies ist sehr einfach zu implementieren und benötigt keine externen Partitionen oder Speichermedien. Das Problem ist es jedoch, die Datei an einem ort zu speichern, bei der man nicht unverifizierte Dateisysteme anhängen muss oder ungeschützt ohne schreibschutz offen ist. +\end{itemize} +\\ +Um die Quelle zu schützen beziehungsweise zu Verifizieren, gibt es zwei Methoden: +\begin{itemize} +\item Kryptographische Verifizierung\\ + Die Entwickler des Betriebssystems müssen hierbei bei dem aufsetzen des Verifizierungsprogramms die Hash Quelle Kryptographisch mit ihren privaten Schlüsseln signieren (zum Beispiel mit GnuPG oder Minisgin), das Verifizierungsprogramm erhält den öffentlischen Schlüssel der Entwickler, die Signatur und die Quelle, wodurch es anhand der Signatur verifizieren kann, dass die Quelle von den Entwicklern stammt und nicht modifiziert wurde.\\ + Hierbei ist das größte Problem, dass der öffentliche Schlüssel gut geschützt werden muss, damit die Signatur und Schlüssel nicht mit der eines Attackers ersetzt werden kann. +\item Verschlüsselung\\ + Die Quelle ist mit einem zufällig generierten Schlüssel verschlüsselt, welcher in dem Quellcode des Verifizierungsprogrammes geschrieben wird, um somit den Schlüssel direkt im Programm zu speichern. Dadurch können keine Schlüssel ersetzt werden, jedoch ist es immer möglich, den Schlüssel aus dem Programm zu extrahieren, ohne überhaupt auf das System zugreifen zu müssen, da man das Betriebssystem selber installieren kann. Sobald der Schlüssel bekannt ist, kann die Datei einfach verschlüsselt und ohne Probleme modifiziert werden. +\end{itemize} diff --git a/doc/class-assignment/idee/idee.tex b/doc/class-assignment/idee/idee.tex new file mode 100644 index 0000000..0da7a1f --- /dev/null +++ b/doc/class-assignment/idee/idee.tex @@ -0,0 +1,14 @@ +Die Idee einer Dateisystem verifizierung ist nichts neues, oft wird sie in embedded geräten oder handys implementiert, wo die sicherheit und integrität des systems von großer bedeutung ist. +Jedoch ist sie bei Desktop betriebssystemen wie Windows, MacOS oder Linux Distributionen nicht sehr herkömmlich. Dies liegt meißt daran, dass eine effektive verifizierung des Dateisystems sich darauf verlässt, dass das Dateisystem sich nicht über zeit verändert, welches man bei Desktop-Betriebssystemen nicht gewährleisten kann, da Programme oft direkt in den Root des Betriebssystems schreiben (/usr in *nix, C:\\Program Files in windows). + +Mittlerweile gibt es jedoch in der Linux-welt eine neue art von Distribution, die sogenannten 'Immutable' Distributionen, welche sich darin unterscheiden, dass der Root schreibgeschützt ist, oder wie bei NixOS oder Gnu GUIX garnicht erst richtig existiert. Dadurch können Programme nur direkt in den Homeordner des Nutzers installiert werden, und das eigentliche System bleibt original bestanden. + +Hierdurch wird Dateisystem-verifizierung möglich, da der originale zustand sich nie ändern wird, kann ein Programm ohne probleme verizieren, dass sich nichts verändert hat. + +\input{idee/implementierungen} +\input{idee/hashquellen} +\input{idee/gewaehlte_implementation} +%%% Local Variables: +%%% mode: LaTeX +%%% TeX-master: "../fsverify" +%%% End: diff --git a/doc/class-assignment/idee/implementierungen.tex b/doc/class-assignment/idee/implementierungen.tex new file mode 100644 index 0000000..af3b652 --- /dev/null +++ b/doc/class-assignment/idee/implementierungen.tex @@ -0,0 +1,17 @@ +\subsection{Implementierungen} +Für die Verifizierung eines Dateisystems gibt es verschiedene Methoden: +\begin{itemize} +\item Per-Datei verifizierung\\ + Bei der Per-Datei Verifizierung wird der Hash von jeder Datei die verifiziert werden soll mit einem vorbestimmten, vertrauten, Hash verglichen, falls der Hash übereinstimmt ist Datei unmodifiziert, wenn sie jedoch abweichen, ist die Datei modifiziert und kann nicht vertraut werden. +\item Festplattenverifizierung\\ + Hier wird ein Hash von der ganzen Festplatte oder Partition mit einem vorgegebenen Wert verglichen. Im vergleich zu der Per-Datei verifizierung werden hier auch neue Dateien erkannt, welche eine Per-Datei verifizierung ignoriert hätte. Jedoch kann dies auch erheblich langsamer sein, da die ganze Partition, welche sehr groß werden kann, in einem Thread gehasht wird. +\item Blockverifizierung\\ + Dies ist ähnlich zu der Festplattenverifizierung, jedoch werden hier nur einzelne Blöcke gehasht und verifiziert, dies ermöglicht es, die Verifizierung durch Multithreading zu beschleunigen, während man weiterhin die ganze Festplatte/Partition verifiziert. +\end{itemize} +\\ +Alle drei arten der Verifizierung haben eine Sache gemeinsam, sie brauchen eine vertraute quelle von der sie den korrekten Hash für eine Datei/Partition/Block lesen können. + +%%% Local Variables: +%%% mode: LaTeX +%%% TeX-master: "../fsverify.tex" +%%% End: -- cgit v1.2.3