tex: add stuff on zero trust

tex/references.bib

@@ -157,4 +157,36 @@
 	note={{Available from: \url{https://www.agwa.name/blog/post/ssh_signatures}. [viewed 2023-05-17]}}
 }
 
+@misc{age,
+	howpublished = {[online]},
+	title = {A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.},
+	author = {Filippo Sotille and Ben Cox and age contributors},
+	year = 2021,
+	note={{Available from: \url{https://github.com/FiloSottile/age}. [viewed 2023-05-17]}}
+}
+
+@misc{x25519rfc7748,
+	series =    {Request for Comments},
+	number =    7748,
+	howpublished =  {RFC 7748},
+	publisher = {RFC Editor},
+	doi =       {10.17487/RFC7748},
+	author =    {Adam Langley and Mike Hamburg and Sean Turner},
+	title =     {{Elliptic Curves for Security}},
+	pagetotal = 22,
+	year =      2016,
+	month =     jan,
+	abstract =  {This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the \textasciitilde{}128-bit and \textasciitilde{}224-bit security level, respectively, and are generated deterministically based on a list of required properties.},
+	note = {{Also available from \url{https://www.rfc-editor.org/info/rfc7748}}},
+}
+
+@misc{lime,
+	author       = {{Digital Forensics \& Computer Security Research}},
+	title        = "{LiME - Linux Memory Extractor}",
+	publisher    = "GitHub",
+	howpublished = {[online]},
+	year         = "2007",
+	note={{Available from: \url{https://github.com/504ensicsLabs/LiME}. [viewed 2023-05-17]}}
+}
+
 % =========================================================================== %

tex/text.tex

@@ -617,21 +617,30 @@ negotiate a key exchange and then encrypt/decrypt the data using the negotiated
 symmetric key.
 
 \n{2}{User isolation}
+
 Users are allowed into certain parts of the application based on the role they
-currently posses. For a start, two basic roles were envisioned:
+currently posses. For the moment, two basic roles were envisioned, while this
+list might get amended in the future, if the need arises:
+
 \begin{itemize}
   \item Administrator
   \item User
 \end{itemize}
 
-Each role is only able to perform actions explicitly assigned to it and while
-there definitely is certain overlap between the capabilities of the two
-outlined roles, each also possesses unique features that the other does not.
+It is paramount that the program protects itself from the insider threats as
+well and therefore each role is only able to perform actions that it is
+explicitly assigned. While there definitely is certain overlap between the
+capabilities of the two outlined roles, each also possesses unique features
+that the other does not.
 
-For example, the administrator role is not able to perform HIBPAPI
+For example, the administrator role is not able to perform searches on the
+breach data directly using their administrator account, for that a separate
+user account has to be devised. Similarly, the regular user is not able to
+manage breach lists and other users, because that is a privileged operation.
+
+In-application administrators are not able to view sensitive (any) user data
+and should therefore only be able to perform the following actions:
 
-In-application administrators are not able to view sensitive (any) user data.
-Administrators are only able to perform the following:
 \begin{itemize}
   \item Create user accounts
   \item View list of users
@@ -642,18 +651,45 @@ Administrators are only able to perform the following:
   \item Delete user accounts
 \end{itemize}
 
-\n{2}{Least-privilege principle}
-Every role only has access to what it absolutely needs for functioning.
+Let us consider a case when a user manages self, while demoting from
+administrator to a regular user is permitted, promoting self to be an
+administrator would constitute a \emph{privilege escalation} and likely be a
+precursor to a at least a \emph{denial of service} of sorts.
 
-\n{2}{Zero trust principle.}
-There will be no way for the application to access the user data since
-it will be encrypted by a key, passphrase to which
-only the user knows.
+
+\n{2}{Zero trust principle}
+
+\textit{Data confidentiality, i.e.\ not trusting the provider}
+
+There is no way for the application (and consequently, the in-application
+administrator) to read user's data. This is possible by virtue of encrypting
+the pertinent data before saving them in the database by a state-of-the-art
+\emph{age} key~\cite{age} (backed by X25519~\cite{x25519rfc7748}), which is in
+turn safely stored encrypted by a passphrase that only the user controls. Of
+course, the user-supplied password is run by a password based key derivation
+function (PBKDF) before letting it encrypt the \emph{age} key.
+
+The \emph{age} key is only generated when the user changes their password for
+the first time to prevent scenarios such as in-application administrator with
+access to physical database being able to both \textbf{recover} the key from
+the database and \textbf{decrypt} it given that they already know the user
+password (because they set it), which would subsequently give them unbounded
+access to any future encrypted data, as long as they would be able to maintain
+their database access. This is why the \emph{age} key generation and protection
+are bound to the first password change. Of course, the evil administrator could
+just perform the change themselves, however, the user would at least be able to
+find those changes in the activity logs and know not to use the application.
+But given the scenario of a total database compromise, the author finds all
+hope is already lost at that point.
 
 Consequently, both the application operators and the in-application
-administrators will never be able to learn the details of what the user is
+administrators should never be able to learn the details of what the user is
 tracking, the same being applicable even to potential attackers with direct
-access to the database.
+access to the database. Thus the author maintains that every scenario that
+could potentially lead to a data breach (apart from a compromised user machine
+and the like) would have to entail some form of operating memory acquisition,
+for instance using \texttt{LiME}~\cite{lime}, or perhaps directly the
+\emph{hypervisor}, if considering a virtualised (``cloud'') environments.
 
 
 \n{1}{Implementation}