A wallet in the phone's own hardware

StrongBox is reachable through the standard Android Keystore API. No Knox SDK, no partner programme, no paperwork — and the proof a bank needs comes from key attestation rather than from a vendor relationship.

The short answer. Ask the system for a key with setIsStrongBoxBacked(true). If the handset has the hardware, the key is generated inside it and cannot be extracted. If it does not, the call throws and you fall back to the TEE — which is still hardware-backed, just a different grade. Either way you get a certificate chain that says which grade you got, and that chain is what the bank verifies.

1 · Generating the key

KeyGenParameterSpec.Builder(ALIAS, PURPOSE_SIGN or PURPOSE_VERIFY)
    .setAlgorithmParameterSpec(ECGenParameterSpec("secp256r1"))
    .setDigests(DIGEST_SHA256)
    .setIsStrongBoxBacked(true)            // StrongBox where present
    .setAttestationChallenge(nonce)        // ← this is what makes it provable
    .build()

Two details in that block do most of the work, and the second is the one usually left out:

setIsStrongBoxBacked(true) moves the key into the dedicated security chip. Catch StrongBoxUnavailableException and retry without it — plenty of handsets have no StrongBox, and a wallet that refuses to run there is a wallet most people cannot use.
setAttestationChallenge(nonce) embeds the server's nonce into the key's certificate. Without it the certificate says only "some key, somewhere"; with it the chain is bound to that enrolment and cannot be replayed from another device.

2 · What the chain proves

The certificate returned for the key carries an attestation extension (1.3.6.1.4.1.11129.2.1.17). Reading it tells the server, in a form Google signs:

attestationChallenge   == the nonce we issued          ← this enrolment, not a replay
attestationSecurityLevel                                  2 = StrongBox, 1 = TEE, 0 = software
verifiedBootState / deviceLocked                           was the device intact
keyOrigin                                              generated here, not imported
origin / purpose / digest / curve                      the key is what we asked for

The verification is: check the chain to the Google root, check the challenge matches, check securityLevel is at least what your policy requires, and only then accept the public key. This is the paperwork-free replacement for a vendor attestation programme — the device signs its own statement, in silicon, and the issuer checks the signature.

What StrongBox cannot do, and why that shapes the wallet. It holds keys, not data. A token record can be kept on the phone, but only as ciphertext under a StrongBox key — which is a genuine protection, and not the same thing as holding value. The root stays on a bank chip; the phone holds authority copies, encrypted, and the key that spends them.

Operations are slow — tens of milliseconds per signature, and a limited number per second. Fine for a payment, wrong for a loop.
Key slots are few and small — a device holds a handful, not hundreds.
Not every handset has it — the fallback is not optional.

3 · What the wallet holds, given those limits

In the phone	At the issuer
A P-256 key in StrongBox or the TEE, unextractable	The instruments, their denominations, their states and their holders
An enrolment record: public key, attestation chain, label	A device record bound to the account, revocable like a card
A session token, cached; no secrets that matter if it leaks	Every spend, authorised by a signature over the amount and the instrument

A damaged phone is then a revocation, not a loss: the instruments never lived on it. That is the property that makes a phone wallet acceptable to a bank — and it is the same property the plastic card has, arrived at differently.

4 · Holding tokens on the phone

Keystore stores keys, not data, so "the tokens are in the Keystore" is achieved the only way it can be: the token records sit in the app's storage encrypted under a key that lives in StrongBox. The property is the one people actually want — the ciphertext is useless off the device, because the key cannot be extracted.

StrongBox   AES-256-GCM key, purpose ENCRYPT/DECRYPT, user authentication required
App storage ciphertext per token: id, denomination, contract, issuer signature
Unlock      biometric / PIN releases the key for one operation
Spend       decrypt, sign the instruction with the P-256 key, re-encrypt the remainder

That is a real wallet: a stolen, powered-off phone yields ciphertext and a key that will not leave the chip. It is not the same guarantee as a card — a phone can be unlocked under duress, and an app can be compromised while running — which is why a value ceiling per device belongs in the design rather than in the terms.

5 · Two ways out of the phone

	Online	Offline
What moves	The ownership record in the issuer's database	The token image, written to the merchant's card
What the phone does	Signs the spend; the record changes atomically	Presents the image to a reader; the merchant card stores it
When it is final	Immediately	On reconciliation, when the card is read
What the merchant trusts	The issuer	The chip it just wrote to

Both paths lead to the same place — value on a bank chip, ownership in the record — they just take different routes. Online, the phone is a terminal that instructs the record. Offline, the phone is a terminal that writes a token image onto a card, and the record catches up later.

The reserve question, which decides how many phone tokens can exist. Every token in the system occupies a slot on a bank chip, so tokens on phones must map to chips somewhere. Two ways:

One slot per token — exact and auditable, but capacity is chips × slots and every phone token costs a vault position.
A pooled reserve with a cap — the bank holds a float on a few chips and issues phone tokens against it up to a stated multiple. Cheaper, and it is a credit exposure rather than a storage one, so the multiple has to be a decision the bank makes deliberately.

Either way the rule stays: a token that cannot be pointed at a chip slot, directly or through a declared pool, is not value — it is a promise that nobody has funded.

4 · Paying a real till

Phone  selects the instrument, shows the amount, asks for the biometric or PIN
       signs   COINCARD-PAY-V1|tokenId|amountCents|tillId|nonce     with the StrongBox key
Till   verifies the signature against the attested public key on file
       asks the issuer to retire the instrument and credit the shop (online)
       or takes it offline within a cap, and reconciles later

The transport can be anything that carries a signed instruction: an NFC host-card-emulation exchange, a QR code, or a network call. HCE is part of Android itself — an app declares an HostApduService and answers APDUs — so tapping a phone at a CoinCard till needs no vendor licence either.

6 · What exists here today

Key generation with StrongBox preference and TEE fallback — built in the Keystore app; it reports which grade it obtained.
Enrolment and proof of possession — built: the phone registers its public key against the account and signs a single-use challenge, which the issuer verifies.
Attestation challenge — not set in the current build, so the chain is not yet bound to an enrolment. The fix is the one line above, plus server-side verification of the extension.
Spending with the phone key — designed: the sign-off text and the till verification are specified, but no payment path uses the device key yet.
HCE tap — not built. Everything needed is standard Android.

7 · The honest comparison with the card

	CoinCard (secure element)	Phone wallet (StrongBox)
Works with no battery	yes	no
Works on any handset	yes, with a reader	no — some lack StrongBox
Holds value offline	yes, in slots	no — keys only
Revocable when lost	yes, re-issue	yes, revoke the key
Upgrade path	new card	app update

They are complements, not rivals: the card is the cash in the pocket, the phone is the wallet that carries the authority to spend it. A shopper who wants both carries both, and the issuer sees one account.

Sandbox deployment, USD, English. Test values, not money. StrongBox and key attestation are described as the platform provides them; what the platform does not provide — storage for value — is stated above rather than assumed.