# 2024 eCTF Design Document
<!-- # Security Requirements (from competition website) -->
## Conventions:
Security requirements may be addressed as `§1` to refer to Security Requirement 1, `§2` to refer to Security Requirement 2, etc, etc.
`vec` **will not** refer to the default Rust type, but rather, a stack-allocated embedded-friendly version.
<!-- ## Security Requirement 1
The Application Processor (AP) should only boot if all expected Components are present and valid.
If the Medical Device is not in a fully functional state, the AP should not turn on. If the AP is able to turn on in an invalid state, patient health and data could be at risk. The Medical Device’s AP should confirm the device’s integrity before booting.
## Security Requirement 2
Components should only boot after being commanded to by a valid AP that has confirmed the integrity of the device.
Any Component present on a Medical Device should only boot if it is part of a valid system. If a Component is able to be used outside of a valid device – including on counterfeit devices – the safety of patients and the reputation of the company could be at risk. Sensitive data on the Components may also be at risk to being leaked if the Component is able to boot. As the AP oversees validating the device integrity, the Components should not boot until told to do so by a valid AP.
## Security Requirement 3
The Attestation PIN and Replacement Token should be kept confidential.
Attestation PINs (see Attest) and Replacement Tokens (see Replace) play an integral role in segmenting access to privileged operations in Medical Devices. Any number of actors could gain access to a functioning device, so it is crucial that they are not able to extract these secrets from it. If someone were able to, they would be able to gain access to sensitive medical data and to introduce counterfeit parts into otherwise legitimate systems.
## Security Requirement 4
Component Attestation Data should be kept confidential.
The attestation data on each Component is essential to determining the validity of the Component. If an attacker is able to access this data without the required privilege, they may be able to recreate or modify the critical Component. A leak of sensitive propriatary information would damage your companies reputation and could potentially lead to counterfeit Components risking patient safety.
## Security Requirement 5
The integrity and authenticity of messages sent and received using the post-boot MISC secure communications functionality should be ensured.
The ICs that your manufacturer creates will end up serving critical roles in Medical Devices. Once the system is active, the communications between the components must be secure from tampering, duplication, or forgery. If not, patient safety could be at risk to malicious attacks or incidental data corruptions.
-->
# Fulfillment of Security Requirements
We plan to fulfill `§1`, `§2`, and `§4` by establishing a chain of trust, starting at the deployment's host secrets which will be considered the "trust oracle". If a microcontroller is "trusted" by the manufacturer then it is permitted to interface with other microcontrollers.
To fulfill `§5`, two interfacing microcontrollers will encrypt their traffic with authenticated encryption with additional data (AEAD).
To fulfill `§3`, we plan on *only* storing password-hashes (from scrypt or similar) of the attestation PIN and the replacement token
## I2C Communications
*Symmetry*
To fulfill `§1`, `§2`, and `§4`, we will verify the identities of the components using the `ed25519` signature scheme. Our identity verification operation is run by the AP on both Components, and both Components run the procedure on the AP.
We define the cryptographic signing functions:
* `signature = sign(data, private_key)`
* `bool is_valid_signature = verify(data, signature, public_key)`
The deployment will dynamically generate a public-private signing keypair for the manufacturer, termed `man_sig_pub` and `man_sig_priv`, respectively. These global secrets will be shared with the AP and Components at compile time.
At compile time, the AP will generate the following values:
* `ap_sig_priv, ap_sig_pub = random_signature_key()`
* `ap_pub_man_sig = sign(ap_sig_pub, man_sig_priv)`
The Component will generate the corresponding values:
* `comp_sig_priv, comp_sig_pub = random_signature_key()`
* `comp_pub_man_sig = sign(comp_sig_pub, man_sig_priv)`
At runtime, the AP will communicate `ap_sig_pub`, `ap_pub_man_sig`, and `ap_nonce` to the Component through an unecrypted connection. The Component will do the same, with its corresponding variables henceforth defined as `comp_sig_pub`, `comp_pub_man_sig`, and `comp_nonce`.
| Variable | Description |
| -------- | -------- |
| `ap_sig_pub` | AP's signature public key |
| `ap_pub_man_sig` | Manufacturer signature on AP's public key |
| `ap_nonce` | A runtime-generated nonce, generated by AP |
| `comp_pub_sig_pub` | Component's signature public key |
| `comp_man_sig` | Manufacturer signature on Component's public key |
| `comp_nonce` | A runtime-generated nonce, generated by Component |
The AP can then verify that the Component has the same public key signed by the manufacturer (`man_sig_pub`) using `com_sig_pub`, `comp_man_sig`, and `man_sig_pub`. The component can do the same with `ap_sig_pub`, `ap_man_sig`, and `man_sig_pub`. If either party finds that `man_sig_pub` is invalid, they will halt communications.
The AP can then compute the Component's nonce signature (`comp_nonce_sig`) by signing `comp_nonce` with `ap_sig_priv`. Once the Component receives `comp_nonce_sig` from the AP, it is able to verify that the received `comp_nonce_sig` is the expected value. The Component now knows that the AP is trusted by the manufacturer because it has a public/private keypair signed by them. The AP can verify the Component's identity in the same way.
The procedure with the nonce is needed to prove that Alice has the private key corresponding to the public key she has. Otherwise, one could simply steal the manufacturer signature of a public key and impersonate like that.
After both the AP and Component have mutually established identity verification, they now establish an encrypted communication channel. To prevent MITM, both the AP and Component will sign their respective Key Exchange information.
For key exchange, we will use the equivalent operations on Curve25519 using the `x25519` scheme. The $base$ and $p$ are established by Curve25519.
The AP chooses its secret, an integer $a$, which is chosen at random from $[0, p]$. It then computes $A = (base) \times a$.
The AP sends $A$ and `sign(A, m_sig_priv)` to the Component.
Now, after the Component has done the same thing, with a value `b` and $B = (base) \times b$, the AP receives `B` and the Component's signature of `B`. If the signature is verified, then the AP computes the shared secret $S = (B) \times a$. The Component will do the homologous operation and will share the secret if the AP's signature is legitimate as well. Note that to successfully a perform man-in-the-middle attack, one must successfully impersonate the AP and the Component, which is computationally hard unless you're kinda insane.
At this point, all devices (AP <--> Component1, AP <--> Component2) know that they are talking to *a* microcontroller made by the manufacturer over an encrypted channel
Now, the AP asks for and verifies the ID from each component (and each ID's associated signature from the manufacturer), confirming that this AP is talking with *both* its provisioned components.
If all the aforementioned checks are passed, the MISC considers itself booted. Otherwise, the AP fails to boot and busy-loops.
## List tools
The AP will store the IDs of attached components. This command will result in IDs being sent *without* mutual ID verification between AP and Components, through unencrypted communications.
## Attestation
The AP carries a Scrypt hash of the attestation PIN (using a constant-time comparison method). Input of the attestation PIN in the appropriate mode will cause the AP to hash the PIN.
## Replacement
On input of the replacement token and the old and new Component IDs, if the hash of the token matches, then the old ID is replaced with a new one by erasing and writing to flash.
# Function Headers
## Universal Function Headers
Functions common to all devices; we want (or need) them on the AP and Component-this includes Crypto, I2C/TRNG drivers, etc.
### Our Function Utilities
Boot this IC and init it properly
```rust
fn boot_self()
```
### Competition-Mandated Functions (DON'T USE MF)
The following two functions are implemented for Post-Boot functionality. Do NOT use them. Instead, use the I2C type.
```rust
fn secure_send(buffer: *const u8, len: u8);
```
```rust
fn secure_recv(buffer: *mut u8, len: u8);
```
### Crypto Utilities
Get 32 bits from TRNG
```rust
fn trng_raw() -> u32
```
Fill array from TRNG
```rust
fn trng_fill_array(arr : &mut [u8])
```
Contains a encryption key, nonce, ChaCha20Poly1305 state, and I2C target
```rust
struct Secure_I2C
```
Decrypt data using ChaCha20Poly1305, and then ratchet the state to update nonce
```rust
fn decrypt(data : vec<u8>, c : &mut Secure_I2C) -> vec<u8>;
```
Encrypt data using ChaCha20Poly1305, and then ratchet the state to update nonce
```rust
fn encrypt(data : vec<u8>, c : &mut Secure_I2C) -> vec<u8>;
```
```rust
impl Secure_I2C
{
fn insecure_send(&mut self : u8, data: vec<u8>);
fn insecure_recv(&mut self) -> vec<u8>;
fn secure_send(&mut self, data : vec<u8>); // Send data to target, but encrypt it in transit
fn secure_recv(&mut self) -> vec<u8>; //Recv encrypted data and decrypt data from target
fn ratchet(&mut self); //Change nonce using hash of key and current nonce (to prevent replay)
}
```
## AP-Specific Function Headers
Validate components as created under the same deployment and being the AP's provisioned Components.
Communicate with I2C address corresponding to component IDs `CID`, confirming that this AP is provisioned for the component whose ID is `CID` and if everything is A-OK *with both components* then write the correct ComSituation into `com1`. True is returned on successful validation.
```rust
fn validate_component(CID : u32, com1 : &mut Secure_I2C) -> bool
```
Try to boot the AP with the components; if this happens successfully, then two static variables with get written to with the appropriate ComSituations.
```rust
fn try_boot()
```
Send `attest` to both processors and take what they return and print it.
```rust
fn try_attest()
```
Send `replace` to both processors and take what they return and print it.
```rust
fn try_replace()
```
List the IDs of connected components, *without* mutual ID verification.
```rust
fn list_components()
```
## Component-Specific Function Headers
If `boot` is sent on a valid data link using a `Secure_I2C` struct, the state of the component will be "booted"
If `attest` is sent on valid data link using a `Secure_I2C` struct, and the device is booted, return attestation data.
```rust
fn process_AP_sig()
```
Send attestation data over valid data link using a `Secure_I2C` struct
```rust
fn process_attestation()
```
Send the component's ID over unencrypted communications
```rust
fn echo_ID()
```
Google Drive
Gist
Clipboard
Sign in with Wallet
