skip to content

A field tablet keeps its refresh credential in the platform's managed key store — what does that buy, and what does it not?

level: middleimportance: should knowfreq 45%

answer

  1. protects at rest, not in use
  2. per-application isolation from the platform
  3. the read gate can be conditional
  4. extraction is hard, not useless
  5. a device store cannot identify a human

basics

~20 s

A platform-managed key store isolates a credential per application, keeps it encrypted at rest and can gate reads behind a device unlock. It does not protect the credential in use: anything running as that application can still ask for it.

solid answer

~50 s

The store is the third custody option the browser argument usually omits, and it is genuinely stronger than anything a page can do. The platform holds the bytes outside the application's own files, encrypted under a key the application never sees and often held in a dedicated security component, isolated so no other installed application can read it, and optionally released only after a device unlock. What it protects is the credential **at rest**. The moment the tablet's application asks for it, the value is ordinary process memory, and code running as that application — a malicious library inside it, a debugger attached on a device whose platform protections have been removed — has it. Extraction is made hard, not made useless: an extracted refresh credential still works from anywhere. And a store keyed to a device cannot tell two technicians apart at shift handover.

go deeper

for a junior

Know that a device platform offers a proper place to keep a long-lived credential, and that it is better than a file the application wrote itself. The phrase to remember is "at rest, not in use".

for a middle

Explain the mechanism: bytes held outside the application's files, wrapped under a key the application never sees, isolated per application, released through a gate you choose. Then name what falls outside that boundary.

for a senior

Say what happens on a device whose platform protections have been removed, and design the shared-tablet handover explicitly rather than letting the store appear to cover it. Choose a read gate the field conditions can actually satisfy.

for a principal

Decide the standard across the device fleet: which credential class goes in the store, what the gate is, what the backup policy does with it, and what happens when a tablet is lost — and say which of those you can enforce centrally.

## What a platform-managed key store actually is Every mainstream mobile and desktop platform ships a service whose job is to hold small secrets on behalf of an application. The shape is the same everywhere: the application hands over bytes under a label, the platform encrypts them under a key the application is never given, stores them outside the application's own readable files, and hands them back later — sometimes only after some gate is satisfied. On modern hardware the wrapping key lives in a dedicated security component that will not export it at all, so a full copy of the file system does not yield the secret. For the turbine scheduler's field tablet this is the right place for a long-lived **refresh credential** — the one the application uses to obtain fresh access tokens so a technician does not have to sign in again at the base of every tower, in gloves, on a poor connection. It is the one credential on the device worth stealing. ## What it buys - **Per-application isolation.** Another installed application cannot read it, which is the difference between this and a file in the application's own storage area. - **Encryption at rest under a key you do not hold.** Copying the device's storage does not produce the credential, and on hardware-backed platforms the key cannot be exported at all. - **A gate on the read.** The platform can require a device unlock, a passcode or a biometric before it releases the value, so a tablet left unlocked in a van is less useful than one whose credential comes out on demand. - **A lifecycle that matches the application.** Removing the application removes the entry, and platform backup rules can be told not to carry it to a new device. ## What it does not buy | protects against | does not protect against | |---|---| | another application on the device | code running *as* your application | | a file-system dump or a stolen backup | a debugger on a device whose protections are removed | | a casual finder of a locked tablet | someone holding the unlocked tablet with the app open | | the credential sitting readable on disk | the credential being used from elsewhere once extracted | The dividing line is **at rest versus in use**. Once the application asks for the credential, the platform has done its whole job and the bytes are in ordinary process memory. A malicious dependency compiled into the application reads them. So does an attacker with a debugger attached on a device whose platform protections have been stripped. This is the same boundary as the browser case, just drawn much further out: a browser page cannot get a store like this at all, because anything the page can send, the page's injected script can read. The second half of the table matters just as much. A key store makes **extraction** hard. It does not make an **extracted** credential worthless — a bearer credential lifted off one device still works from any other, because nothing in it says which device it came from. ## A shared device is not a storage problem The tablet at the base of the tower is handed over at shift change. The key store is keyed to the *device*, not to the human, so whoever holds the unlocked tablet with the application open is, as far as every one of your servers is concerned, the technician who signed in this morning. No storage choice fixes that. What fixes it is a short foreground session and an explicit handover, which is a session-lifetime decision rather than a custody one — but you should say so out loud rather than let the key store take credit it has not earned. ## The glove There is an operational trap specific to this setting. If the read gate is a biometric or a passcode, it fires at exactly the moment a technician has gloves on, forty metres up, in weather. The application then fails to obtain a token in the one place it is needed. Teams respond by turning the gate off entirely, or by sharing a device passcode across a crew, and both of those are worse than the design you started with. **A control that gets worked around has negative value**, so choose a gate the working conditions can actually satisfy — a long foreground validity with a re-gate on privileged actions, rather than a gate on every read. ## The mistake that looks like this but is not Encrypting the credential into a file inside the application's own storage, with a key compiled into the application, is not a substitute. Anyone who can read the file can read the application, so the key is right there beside the ciphertext. It is the platform holding a key you cannot reach that does the work, not the act of encryption. ## What to say when you are asked State the boundary in one sentence — *at rest, not in use* — then give one thing on each side of it, then name the shared-device case as the thing the store cannot help with at all. That last move is what separates a candidate who has read the platform documentation from one who has shipped a field application.

  • A tablet is shared between technicians at shift handover. What can the key store do about that?
    Nothing. The entry is keyed to the device and gated, at best, on a device unlock, so it identifies the tablet rather than the person holding it. Whoever has the unlocked device with the application open is the signed-in technician. The answer lives in session lifetime and an explicit handover, not in where the bytes are stored, and it is worth saying that boundary out loud.
  • Does a browser page have an equivalent of the platform key store?
    Not for a bearer credential. The nearest analogue is a non-extractable key handle the platform's cryptography interface will use on the page's behalf but never reveal — and that protects a *key*, not a bearer string. Any credential the page can put on a request is a credential the page's injected script can read, which is why browser custody is a fundamentally different argument.
  • The key store gates reads behind a device unlock and technicians work in gloves. What goes wrong?
    The gate fires when hands cannot satisfy it, so the credential read fails precisely where the work happens. Crews respond by disabling the gate or sharing a passcode, which leaves you worse off than the ungated design. Pick a gate the conditions can satisfy: a long foreground validity, re-gated only on the handful of privileged actions that genuinely warrant it.

saying these in an interview costs you the question

  • Calling a platform key store tamper-proof against the application that owns it
  • Assuming a key store makes an extracted credential unusable elsewhere
  • Treating a shared, already-signed-in tablet as a storage problem
  • Encrypting a credential file with a key shipped inside the same application
  • Claiming the store still protects the credential while the application is using it