|
|
@@ -98,16 +98,20 @@ These modifications consist mostly of optional callbacks are were made by modify
|
|
|
|
|
|
\subsubsection{Tag generation}
|
|
|
|
|
|
-The tag is generated by computing a 21-byte ECDH private key $s$ for the client (along with the corresponding 21-byte public key, $g^s$. We used the curve NIST-P224 to generate public keys that fit in 21 bytes of the ClientHello random nonce. The client's public key is concatenated with a 7-byte value, $H_1(g^{rs} || \chi)$ where $g^{rs}$ is computed by raising the relay station's public key $g^r$ to the client's private key $s$. The context string $\chi$ is just the 4-byte server IP address (in network byte order). The hash function, $H_1$, is the first 7 bytes of SHA256 output, while $H_2$ is the last 16 bytes. The shared secret key between the client and the relay station is computed as $k_{sh} = H_2(g^{rs}||\chi)$.
|
|
|
+The tag is generated by computing a 21-byte ECDH private key $s$ for the client (along with the corresponding 21-byte public key, $g^s$. We used a custom curve to generate public keys that fit in 21 bytes of the ClientHello random nonce. First, the client randomly chooses between the curve and its twist, in order to maximize the sampling of points that fill the first 21 bytes of the tag. The relay station will check the tag for both the orignal curve and the twist when verifying the tag.
|
|
|
+
|
|
|
+The client's public key is concatenated with a 7-byte value, $H_1(g^{rs} || \chi)$ where $g^{rs}$ is computed by raising the relay station's public key $g^r$ to the client's private key $s$. The context string $\chi$ is just the 4-byte server IP address concatenated with the first 4 bytes of the ClientHello random nonce (in network byte order). The hash function, $H_1$, is the first 7 bytes of SHA256 output, while $H_2$ is the last 16 bytes. The shared secret key between the client and the relay station is computed as $k_{sh} = H_2(g^{rs}||\chi)$.
|
|
|
|
|
|
\subsubsection{DH parameter generation}
|
|
|
|
|
|
-To derive the TLS client key exchange parameters, the client computes their secret key as the output of $$PRF_{k_{sh}}(``\texttt{SLITHEEN\_KEYGEN}")$$ (Note: the Telex paper refers to his set as using $k_{sh}$ to seed a secure PRG).
|
|
|
+To derive the TLS client key exchange parameters, the client computes their secret key as the output of $$PRF_{k_{sh}}(``\texttt{SLITHEEN\_KEYGEN}")$$.
|
|
|
|
|
|
-The PRF function here is as defined in the TLSv1.2 RFC\footnote{https://tools.ietf.org/html/rfc5246}, where the hash function used is determined by the selected ciphersuite.
|
|
|
+The PRF function here is as defined in the TLSv1.2 RFC\footnote{https://tools.ietf.org/html/rfc5246}, where the hash function used is SHA256 for all cipher suites.
|
|
|
|
|
|
-\subsubsection{Modified Finished MAC}
|
|
|
+\subsubsection{Modified Finished message}
|
|
|
|
|
|
+We change the context of the downstream Finished message, sent from the server to the client. The relay station computes a new Finished message, replacing the previous hash with a MAC keyed with the client-relay shared secret $k_{sh}$:
|
|
|
+$$MAC_{k_{sh}}(\texttt{Finished\_hash} || \chi) $$
|
|
|
|
|
|
|
|
|
\subsection{Data Replacement}
|
