Security threats and requirements
This document enumerates the security threats expected in the ClickStick platform. Each threat is addressed by one or several security requirements and tracked in the Threats and Controls matrix.
Threat Model Overview
Communication & Pairing
- T01 - Eavesdropping — Attacker passively records BLE communication to recover transferred data or observe user activity.
- T02 - Pairing MitM — Adversary interferes with pairing traffic to create BLE bonds with unauthorized devices.
- T03 - BLE replay — Attacker re-sends previously captured BLE packets to trigger repeated actions on the dongle (e.g. re-inject user credentials).
Mobile App
- T04 - Unauthorized App — Unauthorized app on the trusted, bonded smartphone issues commands to the dongle.
- T05 - Puppeteer App — Unauthorized app manipulates the authorized app to send commands without user's permission. (This is similar to the primary use case, except commands are triggered without the user’s intent or consent.)
- T06 - Rogue App — Authentic app is modified by the manufacturer to behave maliciously (e.g. leak user data online, inject malicious payloads)
- T07 - Stolen Phone — Lost mobile device, still bonded to a dongle, issues commands when brought into range.
Host & USB
- T08 - Rogue Host — Host probes dongle memory, overwrites firmware with a malicious version, or infiltrates the mobile via the dongle.
- T09 - Keylogger — Host runs keylogging software, or the dongle is connected via a USB MitM device.
Dongle
- T10 - Stolen Dongle — Stolen or lost dongle exposes sensitive information to a third party.
- T11 - Dongle Swap — Attacker replaces user's dongle with a malicious replica (e.g. to inject malicious payloads or store transferred credentials).
- T12 - Firmware Swap — Attacker covertly modifies firmware of the paired dongle; pairing keys remain in dongle's flash.
- T13 - Firmware Downgrade — Attacker covertly changes firmware to authentic, but older and vulnerable revision.
- T14 - Side Channel — Adversary extracts sensitive data from the dongle via side-channel hardware probing (e.g. RAM contents, glitching, EM analysis).
Usability & Operational
- T15 - Leftover Keys — Factory reset leaves residual credentials or pairing keys on the dongle.
- T16 - Denial of Service — Attacker interferes with dongle's hardware, radio communication, or host software, making it impossible to use the system.
- T17 - Social Engineering — Adversary manipulates the user into approving fake requests, inserting an untrusted dongle, etc.
Supply Chain
- T18 - Factory Backdoor — Supplier injects spyware or remote access into shipped firmware.
- T19 - Factory Key Leak — Attacker exfiltrates a trusted firmware signing key, and thus can sign and install malicious firmware.
- T20 - Open Debug — Authentic firmware leaves debug interfaces open, making it possible to modify firmware behavior in runtime and exposing sensitive keys through debug output.
Security Requirements
SR-LinkEncrypt – BLE pairing and connection settings shall enforce link-layer authentication and encryption.
SR-AppEncrypt — Additional app-level encryption shall wrap all the sensitive messages between the mobile and the dongle. Individual packets shall include counters as an anti-replay measure. Session encryption keys shall be unique for each session and dongle — thus preventing decryption of past communication, should long-term keys get compromised.
SR-DevAuth – Mobile app shall cryptographically verify dongle's authenticity before sending any user data. In particular, this applies both to session initiation and hardware info.
SR-AppAuth – Dongle shall accept commands only from authorized application running on a paired mobile.
SR-SingleBond – Dongle shall maintain at most one active smartphone bond at any time. Pairing and connection requests from other devices shall be ignored. Pairing a different mobile shall require a factory reset performed via dongle's UI (SR-FactoryReset).
SR-AppSource — App source code shall be available for independent audit.
SR-AppConfirm – App shall request user confirmation before accepting data from an untrusted app.
SR-BYOD (Bring Your Own Dongle) — User shall be able to audit, build, sign and flash firmware to their own, independently acquired, hardware.
SR-SignFirmware – Dongle shall verify firmware's digital signature before executing it the firmware. Verification failure shall prevent boot. Firmware update shall burn anti-rollback fuses, permanently preventing installation of earlier firmware revisions. Self-flashed dongles may support user-supplied signing keys or unsigned firmware at user's risk.
SR-HoldToUpdate – Dongle shall accept firmware update only with explicit user interaction, such as holding a button during power-up. This interaction shall also prevent execution of the current firmware (in case it was tampered with). This requirement shall be enforced by a non-modifiable ROM-based boot loader.
SR-SecureStore – Dongle shall use hardware-based encryption for non-volatile storage, with unique hardware-bound keys. Sensitive data shall be bound to microcontroller's internal RAM, to avoid live extraction from an external PSRAM module.
SR-FactoryReset – Dongle shall have a user-initiated factory reset feature that erases all the pairing keys and any other sensitive configuration.
SR-PushOnly – Dongle shall act as a passive BLE-to-HID bridge, sending data only when explicitly commanded. No host-initiated reads shall be permitted.
SR-Cooloff – When session integrity cannot be guaranteed (e.g., intermittent connection, potential MitM or DoS), dongle shall terminate communication and wait before trying to restore it.
SR-RateLimit — Dongle shall have a maximum typing rate setting, user-configurable via dongle's UI (in order to limit the impact of unexpected commands from a compromised app).
SR-SignKeyProtect – All production firmware shall be signed on an air-gapped machine using a hardware-protected, non-extractable signing key (e.g., HSM or secure element).
SR-DebugDetect – If firmware is compiled in debug mode or debug interfaces are detected at runtime, firmware shall visibly warn the user through the display and/or app interface to indicate potential risk of information leakage.
Threats and Controls Matrix
| Threat scenario | Mitigations |
|---|---|
| T01 - Eavesdropping | SR-LinkEncrypt, SR-AppEncrypt, SR-Cooloff |
| T02 - Pairing MitM | SR-DevAuth, SR-AppAuth, SR-SingleBond, SR-Cooloff |
| T03 - BLE Replay | SR-LinkEncrypt, SR-AppEncrypt, SR-Cooloff |
| T04 - Unauthorized App | SR-AppAuth, SR-RateLimit |
| T05 - Puppeteer App | SR-AppConfirm, SR-RateLimit |
| T06 - Rogue App | SR-AppSource, SR-RateLimit |
| T07 - Stolen Phone | SR-FactoryReset, SR-SingleBond, SR-RateLimit |
| T08 - Rogue Host | SR-PushOnly, SR-HoldToUpdate, SR-SignFirmware |
| T09 - Keylogger | Out of scope |
| T10 - Stolen Dongle | SR-SecureStore, SR-SingleBond |
| T11 - Dongle Swap | SR-DevAuth, SR-SignFirmware |
| T12 - Firmware Swap | SR-SignFirmware, SR-HoldToUpdate |
| T13 - Firmware Downgrade | SR-SignFirmware (anti-rollback) |
| T14 - Side Channel | SR-SecureStore, SR-AppEncrypt, otherwise out of scope |
| T15 - Leftover Keys | SR-FactoryReset, SR-SecureStore, SR-AppEncrypt |
| T16 - Denial of Service | Out of scope |
| T17 - Social Engineering | Out of scope |
| T18 - Factory Backdoor | SR-SignFirmware, SR-SignKeyProtect, SR-BYOD |
| T19 - Factory Key Leak | SR-SignKeyProtect |
| T20 - Open Debug | SR-DebugDetect, SR-SignFirmware |
Out-of-scope threats
The following threats are acknowledged but considered outside the scope of this project, with limited or no technical mitigations.
- T09 - Keylogger — ClickStick's goal is to securely deliver HID events to the host machine. However, host's processing of these events is beyond the scope of the project.
- T14 - Side Channel — Side-channel attacks are partially mitigated by SR-SecureStore (flash encryption and on-chip RAM) and SR-AppEncrypt (forward secrecy prevents exposure of past communications). Beyond that, however, side-channel attacks are out of scope.
- T16 - Denial of Service — ClickStick is not intended to work in hostile environments with active radio, software or physical interference.
- T17 - Social Engineering — This is not preventable via technical means alone.