2 Commits

Include renames

Author	SHA1	Message	Date
jaap-jan	573f5d5668	Keep the device key in the TPM, behind a consent Windows enforces ... The last of ADR 0007's three pieces, and it does not implement what that ADR originally decided — because writing it exposed a flaw in the decision. The ADR said "a Windows Hello gesture gating a protected blob". That does not deliver what the rest of the document claims for it: a gate inside the process is not a gate. A store that showed a prompt and then read a DPAPI blob would be bypassed by malware that skipped the prompt, read the file and called CryptUnprotectData itself — which is exactly the attacker the whole decision was made against, and exactly the reason DPAPI alone was rejected. The presence requirement has to be a condition of using the key, enforced below the application, or it is decoration. So the device key is encrypted to an RSA key created in the Microsoft Platform Crypto Provider — the TPM — under CngUIProtectionLevels.ProtectKey. Windows requires consent to use that key, so the prompt is not something this code can be talked out of showing. Malware can ask for the key; it cannot answer the dialog. That is strictly stronger than the ADR described, and most of what option D was being saved for: the wrapping key genuinely never leaves hardware. The X25519 device key still lands in memory to open the wrap, because DSH1 fixes that wrap at a curve the TPM cannot do — the remaining gap, and now a smaller step than it was. CngKey is in-box, so this needed no WinRT projection and no Windows target framework. Which is worth stating plainly because the opposite was planned: the piece was scoped as "where the Windows TFM lands", and it turned out a platform guard on one class was enough. Client.App and its two test projects stay on net10.0. Two things were measured on real hardware rather than assumed, and the second changed the shape of the work. The platform provider works here and holds an RSA key — confirmed by creating and deleting one before writing anything that depended on it. And ProtectKey prompts at key *creation*, not only at use. The comment in the first draft of this file said the opposite, with a confident explanation: sealing uses only the public half, so it should be silent. It is not. CngKey.Create blocks on a dialog, because the policy means "protect this key with a PIN" and Windows asks the user to set that up there and then. Found by writing tests around save and forget and watching the suite hang for ten minutes waiting for somebody to type one. That has two consequences worth knowing before touching this file. SaveAsync is user-facing code — it belongs on a UI thread, behind a button somebody pressed, never on a background pass. And almost nothing in the store can be covered automatically: two tests remain, availability and the empty-blob case, both of which provably reach no dialog. Disabling the UI policy to make the rest testable would remove the one property worth having. The interface offers two things and hides both where they cannot work. "Use Windows Hello" appears on the unlock screen only when this machine has a cached wrap and a keystore still willing to release the key; "Use Windows Hello here" appears in the account bar only when the machine can keep a key and has not already registered one, so it is spent once used. Absent rather than disabled, in both cases: a greyed-out button on a machine that never had a TPM reads as something broken, and the passphrase box beside it is not a fallback — it is the ordinary way in. Both unlock paths now share AdoptAsync rather than each opening the known-host store, building the vault and starting auto-sync. The ordering in there is load-bearing and a second copy would be a second chance to get it wrong. The shell's tests drive a fake keystore. Not for speed: the real one prompts on every save and load, so a suite using it would block forever. What the shell has to get right is which buttons appear and what happens when one is pressed, and a fake answers exactly that. It is shared from Client.Session.Tests by source link rather than reimplemented. 882 tests green, 6 of them new. Zero warnings, dotnet format clean. Not verified, and not verifiable here: the dialogs. Whether the consent prompt appears at the right moments, reads sensibly, and returns to a usable window when declined needs the application run by a person on a machine with a TPM. That is the remaining half of outstanding item #7, and it is now the only thing between this feature and being finished.	2026-07-30 15:17:30 +02:00
jaap-jan	1faea42b94	Unlock with this machine's device key, without a passphrase or a network ... The second of ADR 0007's three pieces: the seam a keystore plugs into, the wrap cached where an offline unlock can reach it, and the unlock path itself. What is still missing is the keystore — UnavailableDeviceKeyStore is what the application composes for now, so behaviour is unchanged until piece three lands. IDeviceKeyStore holds exactly 32 bytes, and only because the cache key moved first. It would have had to hold the local cache key alongside the X25519 scalar — a second live secret at rest, going stale on every passphrase change — had 7016ce3 not re-keyed that to the identity bundle. ADeviceUnlock_ReadsTheSameCache ThePassphraseWrote is the test that ties the two commits together: under the old derivation this session would have opened the identity and then found its own cache unreadable. The wrap is cached at registration rather than fetched at unlock, which is the whole point. The one unlock path that exists to save the user typing must not be the one that only works online; a laptop on a plane is precisely where a gesture should help. Every way this fails returns a status rather than throwing, because none of them are exceptional — a cancelled fingerprint prompt is the most ordinary thing in this file. Three statuses rather than one, because the caller says a different sentence for each: no device registered (the normal state of a machine nobody opted in on), the machine would not release the key (declined gesture, or a Hello key invalidated by a PIN reset — deliberately indistinguishable, since the remedy does not differ), and the key was released and did not open the wrap (a rotated identity, which will never succeed again and needs re-registering). A keystore returning the wrong number of bytes lands in the third rather than crashing the unlock screen. The subtle defect this could have shipped is in UnlockStore.Apply. That method runs on every sign-in from a /me response, which knows nothing about this machine's keystore — so assigning the device columns unconditionally would delete the wrap on the next launch, and the user's fingerprint would stop working for no visible reason and no error anywhere. The columns are therefore written only when the incoming material carries them, with AttachDeviceAsync and DetachDeviceAsync as the only paths that set them deliberately. Mutation tested: removing the guard fails RefreshingTheProfile_DoesNotDiscardTheDeviceWrap and nothing else. RegisterDeviceAsync lives on VaultSession because sealing the bundle is the one step only an open session can do, and the session is the bundle's custodian. Everything else arrives as a parameter, exactly as SyncAsync takes its transport, so the session still knows nothing about how either the wire or the keystore is implemented. Its steps are ordered so a failure cannot leave a lie behind: the key is generated, saved locally, and only then registered with the server. A server row whose private half was never stored is a device that can never unlock and that the account claims can — worse than not offering the feature at all — so the write that could produce it happens after the one that prevents it. ForgetDeviceAsync is deliberately half a job, and says so. It stops this machine unlocking without a passphrase, which is what a user turning the feature off means, but the server's wrap row survives and the account will go on listing a device that cannot unlock. Deleting it needs an endpoint that does not exist yet. Half with the gap recorded beats a method whose name promises the other half. The client cache gained two nullable columns and a migration, generated rather than hand-written this time. 876 tests green, 10 of them new. Zero warnings, dotnet format clean. Remaining: the Windows Hello store and the unlock-screen UI. That is where the Windows target framework lands, and where automated testing stops — a gesture needs hardware and a person, so the last piece is the one that has to be looked at rather than asserted.	2026-07-30 13:37:35 +02:00