DodoSSH

DodoTech-Public/DodoSSH

Public Access

Fork 0

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
jaap-jan	f86791e817	Finish revoking a device, instead of half of it ForgetDeviceAsync stopped this machine unlocking without a passphrase and left the server's row exactly where it was, so the account went on listing a device nobody could account for. ADR 0007 recorded that as a deliberate gap needing an endpoint. This is the endpoint, and the two things that turned up behind it. DELETE /api/v1/me/devices/{id}. The device row is not the dangerous half: a kind=device wrap is the user's identity bundle sealed to a key somebody may be holding, and that is what has to go. It goes on the foreign key's cascade rather than a second statement, and RevokeDevice_TakesItsWrapWithIt asserts the cascade rather than trusting the configuration to keep saying so. Scoped to the caller's own account, which is the only authorisation check there is. The id is an unguessable v7 GUID, but unguessable is not a permission — without the scope one user could withdraw another's device key by pasting an id they saw once, and the victim's next launch would ask for a passphrase with no explanation. 404 rather than 403 for somebody else's device, so a stranger does not learn the id exists. Never refused for being the last device. ADR 0001 makes an enrolled device a recovery path, so removing the last one does cost the user something — but the machine being revoked is most likely the one they have just lost, and a server that argued about it would be refusing the one request that has to work immediately. The passphrase wrap is untouched either way, which RevokeDevice_LeavesThePassphraseWrapAlone pins. --- Two things found on the way --- Registering twice from one machine left two devices on the account. The server is idempotent on the public key, but the client generates a fresh key pair every call and the keystore holds one — so the second registration orphaned a wrap whose private half had just been overwritten, which is precisely the leftover this change exists to remove. Registering now withdraws the previous device. Found by a test that asserted the property and failed. And the fakes were lying about it. FakeAccountServer's comment claimed the real service's idempotence while handing back a fresh Guid on every call, which is invisible until something revokes by id — at which point a test would be revoking an id the server never issued, and passing. Both fakes now issue one id per public key and drop the wrap with the device, as the cascade does. --- Reachable at all --- ForgetDeviceAsync had exactly one caller and it was a test, so "Stop unlocking here" now sits in the account bar where "Use Windows Hello here" was. Its own flag rather than the negation of that one: a machine with no TPM and a machine that is already registered are both "cannot register", and only the second has anything to take back. No confirmation prompt, deliberately. The cost of pressing it by accident is one passphrase and one re-registration; the cost of a dialog is a moment's hesitation at the point somebody has realised a machine is in the wrong hands. Offline it does the local half and says so rather than refusing. Whether this machine may unlock itself is decided entirely by the local cache and the local keystore — the unlock path never asks the server — so forgetting here is what actually revokes, and "you are offline, so this machine will go on unlocking itself" would be the worst available answer. DeviceRevocation.LocalOnly is what the interface reports and the status line explains what is left to do. The local half runs first for the same reason, and the keystore call is the first thing in the method that can yield: on Windows it raises a consent dialog, and a dialog wants the thread it was called from. That ordering is currently load-bearing and shakier than it looks — see the open device-unlock hang. Four mutations, all caught: dropping the user scope from the server query (1 test), skipping the stale-device revoke on re-registration (2), skipping the server call in ForgetDeviceAsync (2), and the earlier version of the client that never called it at all. 930 tests green across 16 projects, 13 of them new. Zero warnings, format clean.	2026-07-30 17:33:31 +02:00
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

jaap-jan

f86791e817

Finish revoking a device, instead of half of it

ForgetDeviceAsync stopped this machine unlocking without a passphrase and left
the server's row exactly where it was, so the account went on listing a device
nobody could account for. ADR 0007 recorded that as a deliberate gap needing an
endpoint. This is the endpoint, and the two things that turned up behind it.

DELETE /api/v1/me/devices/{id}. The device row is not the dangerous half: a
kind=device wrap is the user's identity bundle sealed to a key somebody may be
holding, and that is what has to go. It goes on the foreign key's cascade rather
than a second statement, and RevokeDevice_TakesItsWrapWithIt asserts the cascade
rather than trusting the configuration to keep saying so.

Scoped to the caller's own account, which is the only authorisation check there
is. The id is an unguessable v7 GUID, but unguessable is not a permission —
without the scope one user could withdraw another's device key by pasting an id
they saw once, and the victim's next launch would ask for a passphrase with no
explanation. 404 rather than 403 for somebody else's device, so a stranger does
not learn the id exists.

Never refused for being the last device. ADR 0001 makes an enrolled device a
recovery path, so removing the last one does cost the user something — but the
machine being revoked is most likely the one they have just lost, and a server
that argued about it would be refusing the one request that has to work
immediately. The passphrase wrap is untouched either way, which
RevokeDevice_LeavesThePassphraseWrapAlone pins.

--- Two things found on the way ---

Registering twice from one machine left two devices on the account. The server
is idempotent on the public key, but the client generates a fresh key pair every
call and the keystore holds one — so the second registration orphaned a wrap
whose private half had just been overwritten, which is precisely the leftover
this change exists to remove. Registering now withdraws the previous device.
Found by a test that asserted the property and failed.

And the fakes were lying about it. FakeAccountServer's comment claimed the real
service's idempotence while handing back a fresh Guid on every call, which is
invisible until something revokes by id — at which point a test would be
revoking an id the server never issued, and passing. Both fakes now issue one id
per public key and drop the wrap with the device, as the cascade does.

--- Reachable at all ---

ForgetDeviceAsync had exactly one caller and it was a test, so "Stop unlocking
here" now sits in the account bar where "Use Windows Hello here" was. Its own
flag rather than the negation of that one: a machine with no TPM and a machine
that is already registered are both "cannot register", and only the second has
anything to take back.

No confirmation prompt, deliberately. The cost of pressing it by accident is one
passphrase and one re-registration; the cost of a dialog is a moment's
hesitation at the point somebody has realised a machine is in the wrong hands.

Offline it does the local half and says so rather than refusing. Whether this
machine may unlock itself is decided entirely by the local cache and the local
keystore — the unlock path never asks the server — so forgetting here is what
actually revokes, and "you are offline, so this machine will go on unlocking
itself" would be the worst available answer. DeviceRevocation.LocalOnly is what
the interface reports and the status line explains what is left to do.

The local half runs first for the same reason, and the keystore call is the
first thing in the method that can yield: on Windows it raises a consent dialog,
and a dialog wants the thread it was called from. That ordering is currently
load-bearing and shakier than it looks — see the open device-unlock hang.

Four mutations, all caught: dropping the user scope from the server query
(1 test), skipping the stale-device revoke on re-registration (2), skipping the
server call in ForgetDeviceAsync (2), and the earlier version of the client that
never called it at all.

930 tests green across 16 projects, 13 of them new. Zero warnings, format clean.

2026-07-30 17:33:31 +02:00

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