Detailed Specifications

Application Processor Firmware

There are four pre-boot required functional elements to the application processor firmware. These elements directly relate to the host tools:

• List Components

• Boot Board

• Replace Component

• Attestation

All pre-boot functional requirements must align with the Timing Requirements

Post-boot of the application processor, the required functionality for these four functionality requirements no longer needs to be active. At this point, the functionality in the secure_send and secure_receive functions must be active.

MISC Interface

All messages sent between the AP on the MISC and the Host Computer need to conform to the format specified by the host tools. The host_messaging library included in the example design provides an easy interface to send messages to the host tools.

The host tools accept five types of messages:

Host Messages

Level	Format	Use
Error	%error: {message}%	Notify of an error/failure. Exits Host Tool
Success	%success: {message}%	Notify of a successful completion of a function. Exits Host Tool
Info	%info: {message}%	Provide functionality-relevant information
Debug	%debug: {message}%	Provide debug information (ignored by testing framework)
Ack	%ack%	Acknowledge the receipt of a message, requesting more data

List Components

The list components functionality must print ALL components that are connected to the system as well as all components that the system was provisioned for.

Provisioned and found messages can be repeated for each relevant component ID.

List output format

Level	Message format	Example
Info	P>{Provisioned Component ID prefixed by 0x}\n	P>0x02\n
Info	F>{Found Component ID prefixed by 0x}\n	F>0x02\n
Success	List\n	List\n
Error	Any error message	Internal error\n

Boot Board

The boot board functionality must handle booting all provisioned components and the AP. The boot message from each component and the AP should be sent in separate messages.

After printing boot messages, the AP and Components should boot their respective main functionality.

Boot output format

Level	Message format	Example
Info	{Component ID prefixed by 0x}>{Component boot message}\n	0x02>Hello world from a component\n
Info	AP>{AP boot message}\n	AP>Hello world from the AP\n
Success	Boot\n	Boot\n
Error	Any error message	Boot failed\n

Replace Component

The replace component function must handle replacing a provisioned component with a new component. This function can make use of the replacement token for validation (see Size Requirements). The replace component function must make changes constant across power cycles.

Replace output format

Level	Message format	Example
Success	Replace\n	Replace\n
Error	Any error message	Replace failed\n

Attestation

The return attestation function must print all fields of the component’s attestation data. This function can make use of the Attestation PIN (see Size Requirements)

Attestation format

Level	Message format	Example
Info	C>{Component ID prefixed by 0x}\n	C>0x02
Info	LOC>{Attestation location}\n	LOC>Boston\n
Info	DATE>{Attestation date}\n	DATE>01/01/1970\n
Info	CUST>{Attestation customer}\n	CUST>MITRE\n
Success	Attest\n	Attest\n
Error	Any error message	Attest failed\n

Component Firmware

The Component firmware can communicate with the AP through all of the pre-boot required functional elements except for Replace Component.

The component attestation data is stored on each component as part of the build process. Attestation data storage and transfer must align with the Size Requirements

Post-boot of a component, the required functionality for validating a component no longer needs to be available. At this point, the functionality in the secure_send and secure_receive functions must be active.

Post Boot Functionality

The Components that you design end up in a fully provisioned and working medical device. In order to protect the operation of this medical device, generic security functions must be implemented to allow for secure communications. Any post-boot functionality implemented by the organizers will utilize these functions to change the functionality of the overall medical system.

These functions are prototyped in the Reference Design and must be implemented and must keep the same functional interfaces.

• secure_send

• secure_receive

• get_provisioned_ids - AP ONLY

Post Boot Insulin Pump

In Attack Phase 1: Operational Device, your design will be implemented as an insulin pump. The insulin pump will be built on top of your teams post-boot functionality.

In this scenario different binary messages will be sent between the AP and the two components.

One component will be provisioned as a sensor. This sensor will provide new blood sugar values to the application processor.

The application processor will monitor the blood sugar values provided by the sensor and calculate an average of blood sugar values.

The actuator will implement three different states: actuator off, actuator low-flow, and actuator on. During normal operating mode in Attack Phase 1: Operational Device, your design will operate in the actuator off and actuator low-flow modes.

Note

Values are provided by the sensor that are within the threshold ranges for all three of the modes implemented by the actuator.

Timing Requirements

Under nominal operating conditions (i.e., a properly provisioned and functioning system not being affected by an attack or other physical failure), your system should meet the following timing requirements:

Operation	Maximum Time for Completion
Device Wake	1 second
Attestation	3 seconds
List Components	3 seconds
Boot	3 seconds
Replace Component	5 seconds
Secure Send/Receive	1 second

On the dection of an attack, (e.g., failed PIN entry), you may include an additional delay of no more than 5 seconds before becoming fully functional. If post boot communications are unable to complete, they may wait until communication is available again.

Warning

Due to the configuration of the Attack Boards, you must only use power-on reset to reset the board. Any other reset will cause the system to stop executing until power-on reset again.

Size Requirements

Component	Size
Component ID	4 bytes (Last byte is valid I2C address)
Replacement Token	16 bytes
Attestation PIN	6 bytes
AP Boot Message	Max 64 bytes
Attestation Customer Name	Max 64 bytes
Attestation Manufacture Location	Max 64 bytes
Attestation Date	Max 64 bytes
Component Boot Message	Max 64 bytes
Secure Send/Receive Message	Max 64B

Firmware must align with maximum size requirements as shown below:

Firmware Size

Starting Address	0x1000E000
Ending Address	0x10045FFF

The maximum size of the firmware is: 226KB.

Flash is available from 0x10045FFF to 0x1007E000 to write non-volatile data to. This space is not relevant for application firmware.

Host Tools

Unlike previous years, the host tools this year are created by the organizers and read-only. The host tools create a basic input/output format for communications between your devices and the host computer. More information on the host tools is available here.

Allowed Programming Languages

To build the firmware your design, your team may choose to implement your design in any compatible language. To align with good development practices, you must not use a language that was specifically chosen to be difficult to understand.

The pre-approved programming languages are: C, C++, and Rust. If you wish to use a different language, please reach out to the organizers first.

The Reference Design was created in C, and as such if you team decides to use another programming language, the Nix build environment must be updated to allow for the organizers and teams to be able to build and utilize your design.