list.tex

\subsection{List Protocol}


The List protocol lists all connected and provisioned Components on the Medical Device, and works as follows:
\iflong
\begin{enumerate}
    \item If AP initiates, it first obtains all provisioned Component IDs (CIDs) from memory, extracting the I2C address from the last byte before printing \texttt{P>\{Provisioned Component ID prefixed by 0x\}\textbackslash n}, one per line.
    \begin{enumerate}
        \item If the AP cannot obtain the provisioned IDs, it should print \texttt{E!Internal Error!\textbackslash n}.%\texttt{E!Error reading provisioned IDs!\textbackslash n}.
    \end{enumerate}
    \item The initiating firmware then polls each I2C address in the range $\mathsf{addr} \in [\texttt{0x00}, \texttt{0xFF}]$\footnote{Some I2C addresses might be blacklisted due to the board design -- see Reference Design for more details.}:
    \begin{enumerate}
        %\item If the initiating firmware encounters its own I2C address, \hl{it skips and tries the next.}
        \item Else, initiating firmware sends a message such as \texttt{LIST\_HELLO} to I2C address $\mathsf{addr}$.
        \item If a Component or AP listening on $\mathsf{addr}$ hears \texttt{LIST\_HELLO}, it responds with \texttt{LIST\_ACK}. If AP, it also prints all provisioned IDs; see Step 1 above.
        \item If the initiating firmware receives \texttt{LIST\_ACK}, it prints \texttt{F>\{Found Component ID prefixed by 0x\}\textbackslash n} corresponding to the I2C address it successfully polled.
        \item Any unexpected sending/receive errors should be printed as \texttt{E!Internal Error!\textbackslash n}.%\texttt{E!Error reading provisioned IDs!\textbackslash n}.
    \end{enumerate}
    \item The initiating firmware prints \texttt{List\textbackslash n} and exits successfully.
\end{enumerate}

For example, suppose that an AP has provisioned two Component IDs in memory, \texttt{0xDEADBEEF} and \texttt{0x8BADF00D}, and there are two Components currently connected to the AP through I2C addresses \texttt{0xEF} and \texttt{0xFE}, respectively. Assuming the AP is honest, an AP who executes the protocol over address \texttt{0x00} might produce the following output after completion:

\texttt{%
P>0xEF\\
P>0x0D\\
%LIST\_HELLO\\
%\dots\\
%LIST\_HELLO\\
%LIST\_ACK\\
F>0xEF\\
%LIST\_HELLO\\
%\dots\\
%LIST\_HELLO\\
%LIST\_ACK\\
F>0xFE\\
%LIST\_HELLO\\
%\dots\\
%LIST\_HELLO\\
List
}
\fi
\begin{pcimage}
\pcb{$\listfunction()$}{
\text{print all } \provcid\text{'s} \\
\pcfor \text{Component I2C addr} \pcdo \\
\t \text{get } \cid \text{ from the component} \\
\t \text{print } \cid \text{ only}
}
\end{pcimage}

\paragraph{Functionality.} To allow any device to initiate the List protocol, both the AP's and Component's firmware should be able to initiate (\texttt{LIST\_HELLO}) and acknowledge (\texttt{LIST\_ACK}) List requests. It must take at most 3 seconds to complete the List protocol.

\paragraph{Security.} The List protocol is \textbf{public and non-authenticated}, and must NOT be considered valid in other protocols. It is not related to any security requirements (\Cref{sec:SR}).
%To prevent timing attacks and/or brute force, any protocol that exists early must delay until the full 3 seconds have elapsed before returning execution.
%Lastly, to avoid potential ``oracle'' attacks on the provisioned IDs, every error that is printed must return the same message.