122 lines
11 KiB
TeX
122 lines
11 KiB
TeX
\documentclass[a4paper,12pt]{article}
|
|
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage[margin=1in]{geometry}
|
|
\usepackage{amssymb}
|
|
\usepackage{amsmath}
|
|
\usepackage{enumitem}
|
|
\usepackage{csquotes}
|
|
\usepackage{apacite}
|
|
\usepackage[colorlinks=true, citecolor=black, filecolor=black, linkcolor=black, urlcolor=black]{hyperref}
|
|
|
|
\title{Applied Cryptography -- Assignment 5}
|
|
\author{Dennis Gabeler (s1085830)\\Tobias Eidelpes (s1090746)}
|
|
\date{June 8, 2022}
|
|
|
|
\begin{document}
|
|
|
|
\maketitle
|
|
|
|
\section*{Exercise 1}
|
|
|
|
\begin{enumerate}[label=(\alph*)]
|
|
\item \emph{Forward secrecy} states that even if an adversary would get ahold of long-term secrets, they would not be able to decrypt past communication. This is commonly achieved using session keys.
|
|
|
|
\emph{Backward secrecy}, on the other hand, is the opposite of forward secrecy. If long-term secrets are compromised, future communication should still be secret. This property is sometimes termed as \emph{self-healing} because a protocol is able to recover quickly from a compromise.
|
|
|
|
\item In order for Diff-Hellman to provide forward secrecy, the generated keys must be ephemeral as opposed to static.
|
|
|
|
\item Yes, it does provide forward secrecy because a new message key is generated from the previous chain key via \textsf{KDF}. If one message key gets leaked, the adversary is able to decrypt the ciphertext which was encrypted with that specific message key but not the other ciphertexts. If the adversary also gains access to the long-term secret $K$, the scheme is broken because all message and chain keys can be recomputed from the secret $K$.
|
|
|
|
Backward secrecy is also satisfied if only one $MK_i$ is leaked. Since the attacker does not have access to the chain keys, they are unable to compute the next message key.
|
|
|
|
\item If an attacker gets ahold of a chain key $CK_i$ at some point in time, all future communication is compromised because all subsequent chain and message keys depend on the leaked one.
|
|
|
|
\item Bob sends two messages back to Alice in the image from the assignment. If the third message ($N=3$) arrives \emph{before} the second message ($N=2$), Alice has to compute the key derivation twice to decrypt the third message. She now has to hold the key material for the second message in store until the message arrives. Alternatively, she could delete the keys for the second message after a certain amount of time has elapsed. Either way, this scenario is not desirable at all because the key material is sensitive and would allow an attacker to compromise all future communication if it were leaked.
|
|
|
|
\item Alice performs the following steps to decrypt $c_2$:
|
|
\begin{enumerate}[label=\arabic*.]
|
|
\item $SS_1\leftarrow B_{1}^{a_0}\pmod p$
|
|
\item $RK_1, CK_0^s\leftarrow\mathsf{KDF}(RK_0, SS_1)$
|
|
\item $CK_1^s, MK_1\leftarrow\mathsf{KDF}(CK_0^s)$
|
|
\item $m_2\leftarrow\mathsf{Dec}(MK_1,c_2)$
|
|
\end{enumerate}
|
|
She performs similar steps for $c_3$:
|
|
\begin{enumerate}[label=\arabic*.]
|
|
\item $CK_2^s, MK_2\leftarrow\mathsf{KDF}(CK_1^s)$
|
|
\item $m_3\leftarrow\mathsf{Dec}(MK_2,c_3)$
|
|
\end{enumerate}
|
|
$RK_i$ serves as the root chain in the Diffie-Hellman ratchet. The root keys are inputs to the next sending/receiving chain keys. $CK_i$ are chain keys which allow participants to derive individual message keys. The chain keys themselves are derived from the outputs of the Diffie-Hellman key exchange. Finally, $MK_i$ are the message keys used to encrypt individual messages.
|
|
|
|
\item In order for Alice to send a message back, she has to derive a new key pair from Bob's public key $B_1$. The new key pair allows her to generate a new sending/receiving chain from which a new message key will be generated. The new public key is again advertised to Bob with the increased nonce $N$ and the encrypted message.
|
|
|
|
\item If an attacker gets access to $RK_i$, they can encrypt and decrypt messages for as long as they want.
|
|
|
|
If an attacker gets access to $CK_i$, they can encrypt and decrypt messages as long as the root key has not been `forwarded' to the next one. Communication between the two parties would be compromised until one of the two responds to a message and the receiver updates the key pair.
|
|
|
|
If an attacker gets access to $MK_i$, they will only be able to decrypt one single message. Previous or future communication is not compromised.
|
|
|
|
\item The first ratchet (symmetric-key ratchet) happens when a new message key is derived from the chain key. Unfortunately, the naive protocol does not have a second ratchet because the chain keys are not updated with fresh Diffie-Hellman outputs.
|
|
|
|
\item Yes, this version is less secure. If the attacker gets ahold of one $MK_i$, they can derive all subsequent message keys and all future communication is compromised.
|
|
\end{enumerate}
|
|
|
|
\section*{Exercise 2}
|
|
|
|
\begin{enumerate}[label=(\alph*)]
|
|
\item The official nonce size for AES-GCM is 96 bits.
|
|
|
|
\item The effective nonce size for AES-GCM in Noise is 64 bits because the first 32 bits are encoded zeros.
|
|
|
|
\item A lower sized nonce has a higher probability producing the same value when combined with the counter, which could lead to an attack.
|
|
|
|
\item Wireguard uses BLAKE2s for hashing.
|
|
|
|
\item The output size for HMAC as used in Wireguard is 256 bits. The maximal key size is technically unlimited, but the key has to be hashed into the HMAC construction. Otherwise, the key is limited to the block size which is 256 bits.
|
|
|
|
\item BLAKE2s is already a keyed hash and it is unnecessary to use it in combination with HMAC if it is not used in HKDF. Therefore, just using BLAKE2s is sufficient.
|
|
|
|
\item In an HMAC construction, if the key is just one byte longer than the block size, the key and the hashed key produce the same digest for the same message. Therefore, to avoid this possibility, it might be advisable to directly use the keyed variant of BLAKE2s instead of the HMAC-BLAKE2s construction.
|
|
\end{enumerate}
|
|
|
|
\section*{Exercise 3}
|
|
\begin{enumerate}[label=(\alph*)]
|
|
\item When the standard (RFC 2313, 8.1) is used for encryption, then the message block is generated as follows:
|
|
|| 00 || 02 || padding string || 00 || data block ||\\
|
|
Let $n, e$ be an RSA public key and let $p, q, d$ be the corresponding private key.\\
|
|
The padding string are non-zero pseudo-random generated bytes with length\\
|
|
$k - 3 - |D|$, where $k$ is the byte length of $n$ and $|D|$ the byte length of data $D$.
|
|
The padding string is at least 8 bytes long.
|
|
\item The paper mentions that from previous research, that when the least significant bit of the plaintext can be predicted using an algorithm, then another algorithm exists that can decrypt the whole ciphertext. The attacker is able to ask the oracle if their chosen ciphertext is PKCS compliant. The method described in the paper tries to narrow down the range of which RPCS conforming messages exist, and then further narrow down the range of which the decrypted message exists. When the ranges overlap with only one value, the plaintext is acquired.
|
|
\item The blinding step means that the ciphertext is multiplied by by a encrypted random integer. RSA has the property that from decrypted data, the attack can retrieve the original message. In this attack, if the ciphertext already is PKCS conforming, then $s_0 = 1$.
|
|
\item After a positive answer from the oracle that it is PKCS conforming, a new interval is found for $m_0$, $s_i$ and $r$ where (mod $n$) $\equiv rn$. This is then used to further reduce the interval for finding the plaintext.
|
|
\item According to the paper, the probability that the first two bytes are 00 and 02 is $2^{-16} < \text{Pr}(A) < 2^{-8}$. Another property of PKCS is that the padding string must contain at least 8 non-zero bytes followed by a zero byte. The paper says that this probability is $0.18 < \text{Pr}(P|A) < 0.97$, hence we have $0.18 \cdot 2^{-16} < \text{Pr}(P|A) < 0.97 \cdot 2^{-8}$.
|
|
\item The latest version of TLS, 1.3 does not support RSA for key exchange so the following only holds for version 1.2 or lower.\\
|
|
Older versions of TLS use PKCS version 1.5 to encrypt RSA messages for the key exchange. It is possible to downgrade the used TLS version by modifing the version agreement through a MitM attack. Before agreeing on the final secret, the client generates 46 random bytes that acts as the premaster secret (PMS). The premaster secret is encrypted using the PKCS v1.5 padding.\\
|
|
The Bleichenbacher attack can take place whem the MitM attacker intercepts the encrypted PMS, which is the ciphertext. The attacker can then blind this ciphertext by generating the random integer and following the rest of the attack.
|
|
\begin{center}
|
|
\begin{tabular}{l c l c l}
|
|
Client & & Attacker (MitM) & & Server \\ \hline
|
|
ClientHello & $\longrightarrow$ & TLS downgrade & $\longrightarrow$ & ClientHello (downgraded) \\
|
|
RSA Key (server) & $\longleftarrow$ & & $\longleftarrow$ & RSA Key (server) \\
|
|
PMS $\xleftarrow{\$} \mathbb{Z}/N\mathbb{Z}$ & & & & \\
|
|
c = E(PMS, key$_{server}$) & $\longrightarrow$ & $(s_i)^e \cdot c$ & $\longrightarrow$ & verify($(s_i)^e \cdot c$) \\ \hline \hline
|
|
& & Continue attack & $\xleftarrow{SUCCESS}$ & \\ \hline \hline
|
|
& & Continue attack & $\xleftarrow{ERROR}$ & \\ \hline
|
|
Finished (changed) & $\longleftarrow$ & Match downgraded data & $\longleftarrow$ & Finished \\
|
|
\end{tabular}
|
|
\end{center}
|
|
\item
|
|
\begin{itemize}
|
|
\item DROWN \cite{drown2016} : This is an attack method used on TLS 1.2. This method works when servers also support an older version like SSLv2, which has more vulnerabilities. In many instances, the same shared key is used in both new and older versions of the protocol, so when the attacker retrieves this key, the packets of the old protocol can be recreated to the newer version using the same shared key, thus breaking newer versions of the protocol.
|
|
\item Morpheus \cite{morpheus2021}: This article goes deeper in the practical aspects of the classic attack. Because of the 30 second network timeout, the man in the middle attack must be performed fast. This article discusses how the process can be parallelized by attack servers with the same key certificate.
|
|
\item Fault Attacks on qDSA Signatures \cite{takahashi2018}: This method uses fault injections to do a full secret key recovery on ECDSA and Schnorr signatures. It uses partially revealed nonces for range reduction and then recovers the key using the Bleichenbacher attack.
|
|
\end{itemize}
|
|
\end{enumerate}
|
|
|
|
\bibliographystyle{apalike}
|
|
\bibliography{refs}
|
|
|
|
\end{document}
|