EOD TOC Security

How Technician data is protected.

EOD Technicians (Techs) work with highly sensitive data and methods to carry out operations. Handling information for operations must be resilient against cybersecurity threats and exposure. The following explains the security and encryption policies used by EODTOC to protect data stored by the application.

Privacy

Information entered by the Tech is stored locally (on device). Sensitive data, such as Operations, After Action Reports (AARs), and related metadata, are encrypted at rest. The app uses a master key to protect access to encrypted records. All keys are generated locally and never logged nor shared with the developers of EODTOC.

The master key is stored in the Tech's local Keychain and access can be locked behind biometrics (e.g. Face ID) or a device passcode. The app can also export a recovery key for backup.

Personal Tech data, such as name, e-mail, and profile picture, are always optional. App logs are never automatically shared with the developers of EODTOC. Networking capabilities are limited to map rendering with Apple Maps and checking app status through the EODTOC Status page.

Encryption and Data Security

Sensitive data are protected using a quantum-resilient encryption process with algorithms designed to defend against harvest-now, decrypt-later attacks. The following is a general explanation first, followed by some technical details:

When the Tech first starts the EODTOC application, the app generates a key pair: one private key (master key) and one public key. Sensitive information is not directly encrypted using these keys. Instead, each payload (e.g. an AAR) gets a fresh helper key, derived through a secure exchange using the Tech's public key. The helper key is used to encrypt the payload, and the exchange information is stored with the encrypted record.

The helper key is symmetric, meaning it can both encrypt and decrypt data. The Tech's key pair is asymmetric, meaning the private key is required to recreate the helper key. Once the user authenticates (using biometrics, etc.) in the app, the master key allows the app to recreate the helper key and decrypt the payload.

Specifically, the Tech key pair operates a quantum-resilient Key Encapsulation Mechanism (ML-KEM-1024). HKDF-SHA256 derives a 256-bit AES-GCM helper key from the resulting shared secret, and AES-GCM secures the payload.

This envelope design lets the app encrypt and persist records without unlocking the master key. The master key is required when records are read, while derived helper keys are not stored in app state.

Physical Key Option (In Development)

To maximize security in the case of lost or stolen devices, an option will eventually be provided to split private key access between the Tech's device and a writable NFC tag. By splitting the key access, encrypted data can only be unlocked if both the Tech's on-device authentication is verified and the NFC tag is read in, each providing its required half of the key.

The NFC tag can be kept in a physically safe location so that even if the device is obtained by a sophisticated attacker, the data remains inaccessible without the tag.

Intelligence

This section relates only to Apple devices that support Apple Intelligence.

Artificial Intelligence (AI)-backed features are enabled on supported devices. These features use the Foundation Models framework, which operates fully on-device and privately. Techs can give and revoke permission to the framework at any time. Any future AI integrations will be integrated with first-class security and privacy.

Siri-backed AI features are available to quickly save Notes and Active Op Events without opening the EODTOC app (e.g. "Hey Siri, create a note in EODTOC that Tech A and Tech B are en route."). EODTOC will never share any encrypted Ops or AAR information with Siri AI.

References

NIST FIPS 203 / ML-KEM

NIST FIPS 197 / AES

CNSA 2.0 FAQ