% CREATED BY MAGNUS GUSTAVER, 2020
\chapter{Slutsats och diskussion}
Efter att vi implementerade kodmodulerna och testade på hårdvaran i den mån möjlig med tanke på 
hur komplett systemet var. Med de resultat funna i föregående kapitel kan vissa slutsatser dras och potentiella
förbättringar diskuteras.

\section{MD407 som larmsystem}
Efter implementationsprocessen fann vi att MD407 fungerar bra som utvecklingsplattform tack vare dess stöd för olika
kommunikationsstandarder och kodbibliotek. Utan STM32F4xx biblioteket skulle projektet vara mycket svårt att genomföra
med vår tidigare kunskap och erfarenhet i baktanke. Med det sagt har vi kommentarer och råd för framtida implementationsexperiment:
\begin{itemize}
    \item Felsökning är svårt att genomföra då hårdvaran endast har en svag koppling till C-koden vi utvecklade mer än kommentarer. Vi rekommenderar starkt att utveckla ett avlusningsbibliotek, exempelvis ett bibliotek som tillåter att meddelanden bli utskrivna till en USART-terminal.
    \item Simulatorn saknar vissa väsentliga aspekter av den riktiga hårdvaran, vilket leder till att kod utvecklas som inte fungerar på hårdvara. Vi avråder starkt från att använda simulatorn.
\end{itemize}
Utöver dessa problem vi fann under utvecklingsprocessen upplevde vi MD407 som en något överkvalificerad plattform
för denna typ av system. I den färdiga produkten är stora delar av MD407s portar och funktionalitet helt orörd, vilket
ensamt inte är dåligt för en prototypplattform men för ett komplett larmsystem kan en simplare och billigare
mikrokontroller användas. 

\section{Återuppspelningsskydd} 
En potentiell svaghet i ett nätverksprotokoll är huruvida en s.k. återuppspelningsattack kan påverka, förvirra 
och kringgå nätverksskydd. En återuppspelningsattack fungerar genom att först spela in en ram från ett nätverk
och sedan sända ut det en gång till i ett försök att få systemet anslutet till nätverket att agera inkorrekt.
Med avseende på projektets arbetsområde skulle en återuppspelningsattack innebära att t.ex. en dörr avlarmas
utan att centralenheten sänt kommandot själv. I detta fall skulle en återuppspelningsenhet vara ansluten till
CAN-bussen och tyst läsa av ramar som passerar genom bussen och sända tillbaka kopior av ramar den spelat in 
vid olika tillfällen.

Problematiken som uppstår p.g.a. en återuppspelningsattack löses i projektet med hjälp av lösenord i 
nätverkslagret (\ref{sec:nätverksprotokoll}). De fundamentala problem som tillåter för återuppspelningsattacker är:
\begin{itemize}
    \item En ram är inte kopplad till tiden som den sändes.
    \item Enheterna på systemet är inte synkroniserade tidsmässigt.
    \item Det går inte att urskilja en ram som sänts från en autentisk källa från en imitatör.
\end{itemize}
Lösenord hanterar alla tre problem genom att:
\begin{enumerate}
    \item Ett ramutbyte har endast ett lösenordspar associerat med sig.
    \item Enheterna på systemet är synkroniserade genom lösenordsalgoritmen med initialvärdet.
    \item Autentiska ramar har unika lösenord för varje ram. 
\end{enumerate} 
Den slutgiltiga effekten av lösenorden är att en inspelad ram är kasserad vid inspelningstillfället då ramutbytet
gått vidare till ett nytt lösenord alternativt lösenordspar. Detta förhindrar en okunnig aktör från att förleda
systemet till felaktigt agerande.

Om konstruktören av återuppspelningsmodulen har god kunskap om nätverkslagret kan viss problematik uppstå.
Denna problematik är inte grundad i normal kommunikation genom rambyten, utan vid initialiseringsprocessen (\ref{sec:automatiskInitialisering})   
då detta är det enda tillfället kommunikation sker utan lösenord. Enligt nätverksprotokollets implementation har 
ingen hänsyn tagits till en återuppspelningsattack vid initialiseringsprocessen av en periferienhet. Ett sätt som
en illmenad aktör kan förvirra centralenheten är att:
\begin{enumerate}
    \item Spela in ett meddelande av typ \texttt{REQUEST\_INIT} från en periferienhet.
    \item Sänd ut samma paket fler gånger än maximalantalet periferienheter. 
\end{enumerate}
Detta kommer att fylla upp centralenhetens interna lista av initialiserade periferienheter, och orsaka larm
när centralenheten sänder \texttt{PING}-meddelanden utan gensvar från ''spökperiferienheterna''.
För att lösa detta behöver initialiseringsprocessen modifieras på så vis att centralenheten inväntar \texttt{ACK}-ramen
för varje initialisering innan periferienhets-ID:t reserveras och tolkas som upptaget. 