added more tables and description to tests

thesis/05_outlook.tex

@@ -124,34 +124,123 @@ Similarly, the cryptographic part of ECDAA is reliable enough for this prototype
 During the following tests, all software and hardware parts worked as expected.
 
 Analyzing disk and memory usage is only meaningful for the member.
-The implemented protoype of the issuer does only negotiate the membership key.
+The implemented protoype of the issuer does only negotiate the membership key and revocation lists and group management are not implemented yet.
-Revocation lists and group management is not implemented yet.
 Similarly, the DAA verifier only checks the signature.
 In productive state it must hold the revocation list and perform further checks with respect to received attestation message.
 
+\begin{table}
+  \renewcommand{\arraystretch}{1.2}
+  \centering
+  \caption{Memory usage measured with Valgrind} \label{tab:memoryusage}
+  %\rowcolors{2}{lightgray}{white}
+  \begin{tabular}{rr}
+    \toprule
+    \textit{Memory Usage} &\textit{[Bytes]} \\
+    \midrule
+    \textbf{DAA TPM key generation} &10160 \\
+    \textbf{DAA TPM join} &23864 \\
+    \textbf{DAA join without TPM} &19296 \\
+    \textbf{Image capturing}   &	 \\
+    \textbf{Image processing}	&209617927\\
+    \textbf{Compiling DAA message} &   \\
+    \textbf{Sending DAA message}   & \\
+    \bottomrule
+  \end{tabular}
+\end{table}
+
+During these memory tests, valgrind showed a large number of possible memory leaks in the python binary itself.
+The following example is executed:
+\begin{lstlisting}[numbers=none]
+  root@amd1:~/jetson-nano-facerecognition# valgrind python3 img2emb.py data/test-images/test2.jpg
+\end{lstlisting}
+Valgrind ends with the report as follows:
+\begin{lstlisting}[numbers=none]
+  ==41612== HEAP SUMMARY:
+  ==41612==     in use at exit: 28,959,222 bytes in 224,623 blocks
+  ==41612==   total heap usage: 714,004 allocs, 489,381 frees, 209,617,927 bytes allocated
+  ==41612==
+  ==41612== LEAK SUMMARY:
+  ==41612==    definitely lost: 2,976 bytes in 25 blocks
+  ==41612==    indirectly lost: 0 bytes in 1 blocks
+  ==41612==      possibly lost: 514,141 bytes in 12,827 blocks
+  ==41612==    still reachable: 28,442,105 bytes in 211,770 blocks
+  ==41612==                       of which reachable via heuristic:
+  ==41612==                         stdstring          : 543,526 bytes in 12,048 blocks
+  ==41612==                         newarray           : 8,920 bytes in 5 blocks
+  ==41612==         suppressed: 0 bytes in 0 blocks
+  ==41612== Rerun with --leak-check=full to see details of leaked memory
+  ==41612==
+  ==41612== Use --track-origins=yes to see where uninitialised values come from
+  ==41612== For lists of detected and suppressed errors, rerun with: -s
+  ==41612== ERROR SUMMARY: 29126 errors from 678 contexts (suppressed: 4 from 1)
+\end{lstlisting}
+This report shows that the Python binary (here Python 3.8 from Ubuntu 20.04) is not memory safe, which is a significant drawback for the system and software integrity.
+Any binary which is directly involved in the DAA protocol frees every allocated block.
+Furthrmore any binary in the TPM2 software stack is memory safe according to valgrind.
+The used shell commands may not free every allocated block, however valgrind still finds no errors in these programs.
 
 
-When IMA is in fixing or enforcing mode, the corresponding log will be filled according to \autoref{tab:imalogsize}.
 \begin{table}
   \renewcommand{\arraystretch}{1.2}
   \centering
-  \caption{Nuber of entries and IMA log size} \label{tab:imalogsize}
+  \caption{Performance results of joining a DAA group and sending a Digidow message} \label{tab:wholeperformance}
-  %\rowcolors{2}{lightgray}{white}
+  \begin{tabular}{rrrrrrr}
-  \begin{tabular}{rll}
+    \toprule
+    \textit{Performance} &\multicolumn{3}{c}{\textit{Join~[s]}} &\multicolumn{3}{c}{\textit{Digidow start~[s]}} \\
+    &min &avg &max &min &avg &max\\
+    \midrule
+    \textbf{Sys1 IMA off} &&&& \\
+    \textbf{Sys1 IMA fix} &&&& \\
+    \textbf{Sys1 IMA enf} &&&& \\
+    \textbf{Sys3 IMA off} &&&& \\
+    \textbf{Sys3 IMA fix}	&&&& \\
+    \textbf{Sys3 IMA enf} &&&& \\
+    \bottomrule
+  \end{tabular}
+\end{table}
+
+\begin{table}
+  \renewcommand{\arraystretch}{1.2}
+  \centering
+  \caption{Performance results of each step when sending a Digidow message} \label{tab:stepperformance}
+  \begin{small}
+    \begin{tabular}{rrrrrrrrrrrrr}
+      \toprule
+      \textit{Performance} &\multicolumn{3}{c}{\textit{Capture~[s]}} &\multicolumn{3}{c}{\textit{Process~[s]}} &\multicolumn{3}{c}{\textit{Collect~[s]}} &\multicolumn{3}{c}{\textit{Send~[s]}} \\
+      &min &avg &max &min &avg &max &min &avg &max &min &avg &max\\
+      \midrule
+      \textbf{Sys1 IMA off} &&&& \\
+      \textbf{Sys1 IMA fix} &&&& \\
+      \textbf{Sys1 IMA enf} &&&& \\
+      \textbf{Sys3 IMA off} &&&& \\
+      \textbf{Sys3 IMA fix}	&&&& \\
+      \textbf{Sys3 IMA enf} &&&& \\
+      \bottomrule
+    \end{tabular}
+  \end{small}
+\end{table}
+
+
+
+When IMA is in fixing or enforcing mode, the corresponding log will be filled according to \autoref{tab:imalogentries}.
+\begin{table}
+  \renewcommand{\arraystretch}{1.2}
+  \centering
+  \caption{Number of additional entries in the IMA log} \label{tab:imalogentries}
+
+  \begin{tabular}{rl}
     \toprule
-    &\textit{Log entries}&\textit{Log size} \\
+    &\textit{Additional log entries} \\
     \midrule
-    \textbf{Boot}	&\textasciitilde\,27\,s &\\
+    \textbf{Boot}	&\textasciitilde 2000\\
-    \textbf{DAA TPM enrollment} &\textasciitilde\,44\,s & \\
+    \textbf{DAA TPM enrollment} &\\
-    \textbf{Image capturing}   &	&    \\
+    \textbf{Image capturing}   &	 \\
-    \textbf{Image processing}	&\textasciitilde\,28\,s	&\\
+    \textbf{Image processing}	&\\
-    \textbf{Collecting DAA message} &\textasciitilde\,47\,s   &  \\
+    \textbf{Compiling DAA message} & \\
-    \textbf{Sending DAA message}   &  &   \\
+    \textbf{Sending DAA message}   & \\
-    \textbf{Sending 2nd message}   &  &   \\
     \bottomrule
   \end{tabular}
 \end{table}
-This
 
 This means---given that the (very slow) hardware TPM had to extend PCR 10 for every line in the log---the slowdown is mainly caused by the interaction with the TPM itself.