replace.tex

\subsection{Replace Protocol}

The replace protocol reprograms the AP with a new Component, overwriting a previously provisioned Component. The caller provides a private Replacement Token \rtok, the ID of the component to replace $\cid_\textsf{out}$, and the ID of the new component $\cid_\textsf{in}$.  Our boot protocol can be outlined as follows: %For an extra layer of security, AP and the component will each run a challenge-response session where one can verify oneself to the other, before actually replacing the old CID $\cid_{\textsf{out}}$ to the new one $\cid_{\textsf{in}}$. The algorithm below describes the entire process in detail. 

%\jw{No obvious flaw with "cert pinning" with two-way digital signatures instead of challenge-response, except that signatures are replayable so need to ensure freshness.}

\begin{pcimage}
\pcb{$\replace(\rtok, \cid_{\textsf{in}}, \cid_{\textsf{out}})$}{
\textbf{Application Processor} %\> \text{(I2C channel)} \hspace{1.2cm} \> \textbf{Component } i
\\[0.1\baselineskip][\hline] \\[-0.5\baselineskip]
%\text{start} \gets \text{getTime}() \> \> \\
\pcif \text{Verify } H(\rtok) = H(\rtok_{\actual}) \> \> \\
\qquad \text{ and } \cid_{\textsf{out}} \in \provcid \> \> \\
\qquad \text{ and } \cid_{\textsf{in}} \notin \provcid \> \> \\
\pcthen \\
%\pcif \text{False} \pcthen \> \> \\
%\t \text{end} \gets \text{getTime}() \> \> \\
%\t \text{sleep}(5s - (\text{end} - \text{start})) \> \> \\
%\t \pcreturn 0 \> \> \\
%\pcelse \pcdo \> \> \\
%\t r_A \sample \textsf{CSPRNG}() \> \> \\
%\t c_A \gets \Enc_{\csk}(r_A) \> \> \\
%\> \sendmessageright*{c_A} \> \\
%\> \> r_A' \gets \Dec_{\csk}(c_A) \\
%\> \> \text{Verify } r_A' \not\in \noncelist \\
%\> \> \noncelist \mathrel{+}= r_A' \\
%\> \> c_A' \gets \Enc_{\csk}(r_A' + 1) \\
%\> \> r_B \sample \textsf{CSPRNG}() \\
%\> \> c_B \gets \Enc_{\csk}(r_B) \\
%\> \sendmessageleft*{c_A', c_B} \> \\
%\t \text{Verify } \Dec_{\csk}(c_A') = r_A + 1 \> \> \\
%\t \pcif \text{False} \pcthen \> \> \\
%\t \t \text{end} \gets \text{getTime}()  \> \> \\
%\t \t \text{sleep}(5s - (\text{end} - \text{start})) \> \> \\
%\t \t \pcreturn 0 \> \> \\
%\t r_B' \sample \Dec_{\csk}(c_B') \\
%\t \text{Verify } r_B' \not\in \noncelist \\
%\t \noncelist \mathrel{+}= r_B' \\
%\t c_B' \gets \Enc_{\csk}(r_B' + 1) \\
%\> \sendmessageright*{c_B'} \> \\
%\> \> \text{Verify } \Dec_{\csk}(c_B') = r_B + 1 \\
%\> \> \sigma \gets \Sign_{\msk_i}(\cid_i \| \buildid_i) \\
%\> \> \pcif \text{False} \pcthen \\
%\> \> \t \text{print ``suspicious activity detected''}  \\
%\> \> \t \text{break}() \\
%\> \sendmessageleft*{\cid_i, \buildid_i, \sigma} \> \\
%\t \buildid_i' \gets \provcid[\cid] \> \> \\
%\t \mvk_i \gets \overline{\mvk}[\buildid_i] \> \> \\
%\t \text{Verify } \Ver_{\mvk_i}(\cid_i \| \buildid_i, \sigma) = 1 \> \> \\
%\t \qquad \text{and } \cid_{\textsf{in}} = \cid_i \> \> \\
\t \provcid[\cid_{\textsf{out}}] \gets \textsf{null} \\
\t \provcid[\cid_{\textsf{in}}] \gets \textsf{open} %\buildid_i
%\t \text{end} \gets \text{getTime}() \> \> \\
%\t \text{sleep}(5s - (\text{end} - \text{start})) \> \> \\
%\t \pcreturn \provcid \> \> 
}
\end{pcimage}



%\jw{TODO (FIX): Currently any Component who has SK (i.e., all components because it's a symmetric key) are able to authenticate themselves using Replace C-R protocol. This would let ANY validly built component (but perhaps not $\cid_{\textsf{in}}$!) get replaced in, leading to any consistencies. Also, there's no checking to make sure $\cid_{\textsf{out}}$ is dead.} \jw{Self-resolved first point with PKI pinning (i.e., can't just make up own signing keypair after C-R, need to use one in \mvklist). What about checking $\cid_{\textsf{out}}$ is dead? I don't think it matters.} \jw{We can't do this anyway without communication in replace; resolved.}

\paragraph{Functionality.}  Only the AP can run $\mathsf{Replace}$. It must take at most 5 seconds to complete $\mathsf{Replace}$, which is enforced by carefully tuning the password-hash $H(\rtok)$. If an attack is detected (here, $H(\rtok)$ check failing) we are allowed to delay for an additional 5 seconds. The liveness of the new Component $\cid_{\textsf{in}}$ are not checked until a downstream protocol (i.e., $\mathsf{Boot}$). The list of provisioned Component IDs \provcid will be retained across power cycles.

\paragraph{Security.} This protocol does not allow for communication between the AP and Components $\cid_{\mathsf{in}}$, $\cid_{\mathsf{out}}$, so authentication and liveness checks in the newly-provisioned Component $\cid_{\mathsf{in}}$ most occur in downstream protocols (i.e., $\mathsf{Boot}$). If the AP detects an incorrect input (i.e. bad \rtok; see above), we delay for 5 seconds to mitigate brute-force attacks. \iflong Since the 128-bit input space for randomly generated \rtok is already considerably larger than the 6-digit Attestation PIN input space, including a private salt would not provide any additional security, however.\fi

% This satisfies the 5 second maximum timing requirements for $\replace$, assuming a time-out function is also employed. Similar to the attestation protocol, we are keeping the protocol sleep for a certain amount of time so the total runtime remains the same for every execution, to prevent any possible timing attacks. Also, if we store the \provcid list in persistent memory, this list of provisioned Component IDs will not change across power cycles as required. Lastly, while there are no security requirements directly related to the \replace protocol, a challenge-response protocol such as this allows the AP to verify that the Component being replaced is live and using the correct ID/address, and also \jw{(perhaps redundantly)} gives the Component a chance to check that it is being installed in a valid AP as well as consistent with \cite{eCTFOfficial}. Indeed, this same 2-way challenge-response to validate knowledge of the key \sk is similar to what will be used during the boot process as well. \jw{Is this true?}