Assets

The relevant assets are device control, pairing grants and phone identities, device identities and keys, local face/profile data, cloud account data, short-lived relay tickets, route leases, transfer contents, and update artifacts. Secrets and private deployment identifiers are deliberately not published here.

Actors and boundaries

• A local user owns or physically approves a device and may operate the Android companion.
• An unapproved nearby BLE peer may observe an advertisement and attempt the commissioning handshake.
• An authenticated phone is a granted controller, not automatically a trusted cloud operator.
• A cloud user, backend, relay, Redis service, MQTT broker, and Supabase installation are separate optional cloud-extension actors.
• An attacker may send malformed, replayed, or modified frames, steal a local phone, compromise a configured service, or obtain a cloud session.

The local boundary is the phone/device BLE session. The cloud boundary is the frontend/API origin, backend services, relay, broker, and device route. Local operation does not cross the cloud boundary.

Local BLE and session security

The device uses an explicit pairing window, phone public-key identity, device approval, signed session frames, session IDs, monotonically increasing sequences, and replay rejection. BLE is the transport; the cited firmware does not require an unrelated operating-system bond before its explicit approval flow. Frames are bounded and fragmented with an ordered envelope, and the device grants the application route only after authorization.

The device stores granted phone identities and can revoke the active phone. The protocol includes signed local-pairing acceptance, route proofs, session capabilities, and transfer acknowledgements.

Cloud-enabled security

The web client sends cookies with requests and adds the readable CSRF cookie to the X-CSRF-Token header for mutating methods. The backend uses origin allowlisting, credentialed CORS, cookie-based auth, CSRF checks, short-lived relay tickets, expiring route leases, device-key verification, bounded mobile frames, and replay keys. MQTT and Redis remain private service dependencies in this model; they are not made public by this documentation.

Assumptions and mitigations

Assumption	Mitigation in the cited sources	Remaining limitation
The user can inspect and approve the intended phone	Explicit pairing window and confirmation flow	Social engineering and a compromised phone remain in scope
Device identity keys remain protected	Signed device proofs and controller grants	Physical extraction and insecure provisioning are not solved here
Cloud services are correctly configured	Origin checks, CSRF, auth middleware, expiring tickets, route ownership, and replay checks	Deployment, key rotation, broker ACLs, and service hardening are not verified by source alone
Payloads remain within protocol limits	Maximum frame/transfer bounds and ordered fragments	Availability and resource exhaustion require operational controls
Update artifacts are the intended artifacts	Signed OTA descriptors and staged update paths exist	No public claim is made for all recovery, rollback, or hardware combinations

Known limitations

This is a source-informed threat model, not an audit or security guarantee. It does not claim resistance to a compromised phone, malicious local owner, stolen cloud credentials, compromised configured dependencies, denial of service, unsafe device storage, or deployment mistakes. No live topology, private key, credential, or operator recovery location is part of the public corpus. Report suspected issues using the security reporting guidance.