added initial security

This commit is contained in:
Jake Hillion 2020-11-28 20:20:21 +00:00
parent cddccd3dfd
commit 6a5c9e68d7
7 changed files with 83 additions and 26 deletions

View File

@ -235,11 +235,11 @@ Not implemented yet.
\subsection{IPv4/IPv6 Support}
The project only supports IPv4.
The project is only tested with IPv4.
\subsection{UDP Proxy Datagrams}
The project only supports TCP flows for carrying the proxied data.
TODO
\subsection{IP Proxy Packets}

View File

@ -1,5 +1,3 @@
local ip_dissector = Dissector.get("ip")
mpbl3p_udp = Proto("mpbl3p_udp", "Multi Path Proxy Custom UDP")
ack_F = ProtoField.uint32("mpbl3p_udp.ack", "Acknowledgement")

View File

@ -11,25 +11,6 @@
\fi
% ------------------------------- Security --------------------------------- %
\section{Security}
For the security implementation, I paid careful attention to the work of Wireguard (Donenfeld, “WireGuard.” \cite{donenfeld_wireguard_2017}). Wireguard is a modern, well respected method of securely transferring Layer 3 packets across the Internet.
However, as Wireguard is a VPN, it provides certain security benefits that are not within the remit of my threat model (section \ref{section:threat-model}). The primary example of this is privacy. When Wireguard, and most VPNs, send a packet, they first encrypt the contents such that the contents of the datagram are only visible to the intended recipient. For this project, encryption will not be necessary, as that would provide privacy above using the modem without this solution. If a user wishes to also have the benefits of an encrypted Internet connection, the transparency of this solution allows existing VPNs to run underneath and provide that. This follows the philosophy of do one thing and do it well.
The security in this solution will be achieved by using public and private keypairs to perform a key exchange at the beginning of connections, and then using that key to produce a message authentication code for each packet sent across the connection. To prevent replay of earlier messages, a timestamp will be included within the authenticated section of the message. This timestamp can be used to discard messages sent a certain time earlier than now, reducing the usefulness of replay attacks.
As far as is possible, the security of the application relies on external libraries. Although an interesting exercise, implementing security algorithms directly from papers is far more likely to result in errors and thus security flaws. Due to this, I will be using trusted and open source libraries for the scheme I have chosen.
\subsection{Key Exchange}
TODO
\subsection{Message Authentication Codes}
TODO
% --------------------------------- TCP ------------------------------------ %
\section{TCP}
@ -46,7 +27,7 @@ TODO
\bytefieldsetup{bitheight=5em}\bitbox{4}{Data offset} & \bitbox{3}{\begin{turn}{-60}Reserved\end{turn}} & \bitbox{1}{N S} & \bitbox{1}{C R W} & \bitbox{1}{E C E} & \bitbox{1}{U R G} & \bitbox{1}{A C K} & \bitbox{1}{P S H} & \bitbox{1}{R S T} & \bitbox{1}{S Y N} & \bitbox{1}{F I N} & \bitbox{16}{Window Size} \\
\bitbox{16}{Checksum} & \bitbox{16}{Urgent Pointer}
\end{rightwordgroup} \\
\wordbox[tlr]{1}{IP Packet Content} \\
\wordbox[tlr]{1}{Proxied IP packet} \\
\skippedwords \\
\wordbox[blr]{1}{} \\
\begin{rightwordgroup}{Security\\Footer}
@ -83,7 +64,7 @@ The packet structure was decided to allow for effective congestion control and n
\bitbox{32}{Negative acknowledgement number} \\
\bitbox{32}{Sequence number}
\end{rightwordgroup} \\
\wordbox[tlr]{1}{IP packet content} \\
\wordbox[tlr]{1}{Proxied IP packet} \\
\skippedwords \\
\wordbox[blr]{1}{} \\
\begin{rightwordgroup}{Security\\Footer}
@ -175,3 +156,30 @@ To allow for flexibility in congestion control, I started by building an interfa
The first congestion control protocol I implemented is based on TCP New Reno. It is a well understood and powerful congestion control protocol.
% ------------------------------- Security --------------------------------- %
\section{Security}
For the security implementation, I paid careful attention to the work of Wireguard (Donenfeld, “WireGuard.” \cite{donenfeld_wireguard_2017}). Wireguard is a modern, well respected method of securely transferring Layer 3 packets across the Internet.
However, as Wireguard is a VPN, it provides certain security benefits that are not within the remit of my threat model (section \ref{section:threat-model}). The primary example of this is privacy. When Wireguard, and most VPNs, send a packet, they first encrypt the contents such that the contents of the datagram are only visible to the intended recipient. For this project, encryption will not be necessary, as that would provide privacy above using the modem without this solution. If a user wishes to also have the benefits of an encrypted Internet connection, the transparency of this solution allows existing VPNs to run underneath and provide that. This follows the philosophy of do one thing and do it well.
The security in this solution will be achieved by using public and private key-pairs to perform a key exchange at the beginning of connections, and then using that key to produce a message authentication code for each packet sent across the connection. To prevent replay of earlier messages, a timestamp will be included within the authenticated section of the message. This timestamp can be used to discard messages sent a certain time earlier than received, reducing the usefulness of replay attacks.
As far as is possible, the security of the application relies on external libraries. Although an interesting exercise, implementing security algorithms directly from papers is far more likely to result in errors and thus security flaws. Due to this, I will be using trusted and open source libraries for the scheme I have chosen.
\subsection{Interface}
As with congestion control, an interface is provided for MAC Generators and Verifiers to implement. This can be seen in figure \ref{fig:message-authenticator-interface}. As with all interfaces, the goal here was to create a flexible but minimal interface.
\begin{figure}
\inputminted{go}{Implementation/Samples/mac.go}
\caption{Message authenticator interface}
\label{fig:message-authenticator-interface}
\end{figure}
\subsection{Shared Key Cryptography}
\subsubsection{BLAKE2s}
The shared key algorithm I chose to implement is BLAKE2s\cite{hutchison_blake2_2013}. It is extremely fast (comparable to MD5) while remaining cryptographically secure.

View File

@ -79,3 +79,51 @@
pages = {14},
file = {Wischik et al. - Design, implementation and evaluation of congestio.pdf:/home/jake/Zotero/storage/5EIJG455/Wischik et al. - Design, implementation and evaluation of congestio.pdf:application/pdf},
}
@misc{postel_transmission_nodate,
title = {Transmission {Control} {Protocol}},
url = {https://tools.ietf.org/html/rfc793},
language = {en},
urldate = {2020-11-28},
author = {Postel, J.},
file = {Snapshot:/home/jake/Zotero/storage/UYLHNHTA/rfc793.html:text/html},
}
@article{peng_multipath_2016,
title = {Multipath {TCP}: {Analysis}, {Design}, and {Implementation}},
volume = {24},
issn = {1558-2566},
shorttitle = {Multipath {TCP}},
doi = {10.1109/TNET.2014.2379698},
abstract = {Multipath TCP (MP-TCP) has the potential to greatly improve application performance by using multiple paths transparently. We propose a fluid model for a large class of MP-TCP algorithms and identify design criteria that guarantee the existence, uniqueness, and stability of system equilibrium. We clarify how algorithm parameters impact TCP-friendliness, responsiveness, and window oscillation and demonstrate an inevitable tradeoff among these properties. We discuss the implications of these properties on the behavior of existing algorithms and motivate our algorithm Balia (balanced linked adaptation), which generalizes existing algorithms and strikes a good balance among TCP-friendliness, responsiveness, and window oscillation. We have implemented Balia in the Linux kernel. We use our prototype to compare the new algorithm to existing MP-TCP algorithms.},
number = {1},
journal = {IEEE/ACM Transactions on Networking},
author = {Peng, Q. and Walid, A. and Hwang, J. and Low, S. H.},
month = feb,
year = {2016},
note = {Conference Name: IEEE/ACM Transactions on Networking},
keywords = {Aggregates, Algorithm design and analysis, Asymptotic stability, balanced linked adaptation, Balia algorithm, Computer networks, convergence, Heuristic algorithms, Linux kernel, MP-TCP algorithms, multipath TCP, nonlinear dynamical systems, Oscillators, Stability analysis, TCPIP, transport protocols, Vectors, window oscillation},
pages = {596--609},
file = {IEEE Xplore Full Text PDF:/home/jake/Zotero/storage/9QTMKA3G/Peng et al. - 2016 - Multipath TCP Analysis, Design, and Implementatio.pdf:application/pdf;IEEE Xplore Abstract Record:/home/jake/Zotero/storage/S2L269MS/7000573.html:text/html},
}
@incollection{hutchison_blake2_2013,
address = {Berlin, Heidelberg},
title = {{BLAKE2}: {Simpler}, {Smaller}, {Fast} as {MD5}},
volume = {7954},
isbn = {978-3-642-38979-5 978-3-642-38980-1},
shorttitle = {{BLAKE2}},
url = {http://link.springer.com/10.1007/978-3-642-38980-1_8},
abstract = {We present the hash function BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed in software. Target applications include cloud storage, intrusion detection, or version control systems. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms, and BLAKE2s for smaller architectures. On 64bit platforms, BLAKE2 is often faster than MD5, yet provides security similar to that of SHA-3: up to 256-bit collision resistance, immunity to length extension, indifferentiability from a random oracle, etc. We specify parallel versions BLAKE2bp and BLAKE2sp that are up to 4 and 8 times faster, by taking advantage of SIMD and/or multiple cores. BLAKE2 reduces the RAM requirements of BLAKE down to 168 bytes, making it smaller than any of the five SHA-3 finalists, and 32\% smaller than BLAKE. Finally, BLAKE2 provides a comprehensive support for tree-hashing as well as keyed hashing (be it in sequential or tree mode).},
language = {en},
urldate = {2020-11-28},
booktitle = {Applied {Cryptography} and {Network} {Security}},
publisher = {Springer Berlin Heidelberg},
author = {Aumasson, Jean-Philippe and Neves, Samuel and Wilcox-OHearn, Zooko and Winnerlein, Christian},
editor = {Hutchison, David and Kanade, Takeo and Kittler, Josef and Kleinberg, Jon M. and Mattern, Friedemann and Mitchell, John C. and Naor, Moni and Nierstrasz, Oscar and Pandu Rangan, C. and Steffen, Bernhard and Sudan, Madhu and Terzopoulos, Demetri and Tygar, Doug and Vardi, Moshe Y. and Weikum, Gerhard and Jacobson, Michael and Locasto, Michael and Mohassel, Payman and Safavi-Naini, Reihaneh},
year = {2013},
doi = {10.1007/978-3-642-38980-1_8},
note = {Series Title: Lecture Notes in Computer Science},
pages = {119--135},
file = {Aumasson et al. - 2013 - BLAKE2 Simpler, Smaller, Fast as MD5.pdf:/home/jake/Zotero/storage/ZG25MG4B/Aumasson et al. - 2013 - BLAKE2 Simpler, Smaller, Fast as MD5.pdf:application/pdf},
}

View File

@ -7,4 +7,5 @@ rm /home/jake/repos/dissertation/4-dissertation/Implementation/Samples/* || true
# Copy code samples for implementation
cp /home/jake/repos/dissertation/2-code/udp/congestion.go /home/jake/repos/dissertation/4-dissertation/Implementation/Samples/
cp /home/jake/repos/dissertation/2-code/udp/wireshark_dissector.lua /home/jake/repos/dissertation/4-dissertation/Implementation/Samples/
cp /home/jake/repos/dissertation/2-code/proxy/mac.go /home/jake/repos/dissertation/4-dissertation/Implementation/Samples/

Binary file not shown.

View File

@ -125,7 +125,7 @@
\listoffigures
\listoftables
% \listoftables
% \printnomenclature[space] space can be set as 2em between symbol and description
%\printnomenclature[3em]
@ -172,6 +172,7 @@
% ********************************** Appendices ********************************
%TC:ignore
\begin{appendices} % Using appendices environment for more functunality
\include{GraphGeneration/graphgeneration}
@ -185,4 +186,5 @@
% ************************************** Proposal ******************************
\include{Proposal/proposal}
%TC:endignore
\end{document}