Untrusted Client Devices

## The design A gas utility ships an Android app to field technicians. Each morning it downloads the day's route — customer names, addresses, appointment windows, meter history — and caches it so the technician can work in basements and rural areas with no signal. To reach the routing partner's service, the app carries an integration API key compiled into the package. Handsets get lost, sold, rooted and handed between contractors. ## The single modeling move The handset is outside your trust boundary. That is not a statement about how careful the technicians are; it is a statement about who can ultimately execute code on the device and read its storage. From that one placement, every threat below follows mechanically. The corollary that engineers resist is that **shipping a secret to the far side of a trust boundary discloses it**. An API key inside an application package is not stored, it is published — to a slow-moving audience, but published. Model it as a public string. ## Threat one: the fleet-wide credential Extracting the key gives an attacker the ability to call the integration API as your application. In STRIDE terms this is **Spoofing** (they authenticate as something they are not, violating authentication) and usually **Elevation of Privilege** as well (violating authorization), because integration keys are habitually issued with far broader reach than any single technician needs — often the whole customer database rather than one route. The property that actually hurts is that it is *one* credential for the entire fleet: - You cannot revoke the lost handset without revoking every handset. - Rotation means shipping a new build and waiting for install rates, so in practice the key is never rotated. - Logs cannot attribute a call to a technician, which is a **Repudiation** problem: after an incident you cannot reconstruct who did what. The model therefore argues for per-device credentials issued during enrolment, bound to an authenticated technician session, scoped down to the data that one person's route requires, short-lived, and individually revocable from your side the moment a handset is reported gone. Note the shape of the fix: it does not try to make the device trustworthy, it makes the credential worth less and the loss containable. ## Threat two: the data already on the device The cached route is **Information Disclosure** against personal data — names, addresses and appointment times that tell someone when a house is empty. It is a privacy harm to people who are not your users in any meaningful sense and never consented to their address sitting on a contractor's phone. The threat has an unusual property: it survives the compromise. Revoking a credential stops future API calls, but the addresses cached yesterday are already in the attacker's hands. Controls have to act *before* the loss, which points at data minimisation as the primary mitigation rather than an afterthought: - cache one day's route rather than a rolling history, - store the minimum field set (does the technician need the customer's full name and phone number, or a meter identifier and an address?), - expire the cache on a clock the device enforces locally, so an unopened handset ages out on its own, - tie access to a session that ends, so a found handset is not a logged-in handset. ## What about protected storage on the platform? Modern mobile platforms offer storage that is harder to extract, and using it is worth doing — it raises attacker cost and defeats casual extraction. It does not change the model's assumption. The device is still outside the boundary, the running app can still use whatever it can decrypt, and a rooted handset erodes the guarantee. Treat platform storage as a cost multiplier layered on top of the real controls, never as the reason a fleet-wide secret becomes safe to ship. The mechanics of key storage belong to a cryptography discussion; the threat-modeling conclusion is simply that it moves the cost, not the boundary. ## Assembling the model Written out, the finished model for this design reads: attacker — whoever ends up holding a lost, resold or rooted handset, including a contractor with legitimate access today and none tomorrow; assets — an integration credential and third-party personal data; boundary — the device edge, with the app package and its storage on the untrusted side; dominant threats — Spoofing and Elevation via the shared key, Information Disclosure of cached personal data, Repudiation from unattributable calls; controls — per-device short-lived credentials, server-side scoping to one technician's route, minimised and expiring cache, prompt revocation on a report of loss; residual — data already cached before the loss, which is bounded by how little you chose to cache. ## The interview failure mode Weak answers stop at "don't hardcode secrets in the app" and reach for obfuscation or an encrypted config file whose key also ships. The strong answer is that no amount of hiding fixes a secret you hand to an untrusted party — you change the credential's shape until losing it costs little and you can take it back.