SilverMetal/windows/hardening-spec.md

SilverMetal Enhanced — Windows: Hardening Specification

Status: v1 draft — 2026-06-08. Reference device: GPD Pocket 4 (AMD Ryzen AI 9 HX 370 / Strix Point UMPC). Tier C — configuration-layer hardening only. We do not modify the Windows kernel or boot chain; we turn every dial Microsoft exposes, and we honestly document the dials they do not.

This spec defines the hardened configuration applied to a Windows 11 install to make it a SilverMetal Enhanced — Windows build. It refines the v1 scope in README.md and is bound by ../docs/threat-model.md and ../docs/design-principles.md.

It serves two purposes at once (per the brief): a one-off hardening guide for the immediate reference unit, and the prototype of the productized SKU build that will graduate to an LTSC-based installer. Productization notes are called out inline.

---

1. Why this is a Tier C product (the honest frame)

SilverMetal ships the strongest hardening each platform physically allows. On Windows that ceiling is real and we state it up front (design-principle #2, "honesty over marketing"):

• Closed kernel — no KSPP, no hardened_malloc, no extensible MAC framework (no AppArmor/SELinux equivalent we control).
• No developer-controlled verified boot — we can enrol our own Secure Boot keys, but the firmware root of trust remains the OEM's.
• Telemetry cannot reach zero — we minimise it and publish what remains rather than claim "zero".
• The hardware floor is the Pocket 4's — see §10. Closed AMI-class BIOS, an always-on AMD PSP, no hardware kill switches. None of this is fixable in software.

What Tier C does deliver is a genuinely strong posture against the threats that actually dominate a pocket everyday device: device loss/theft, opportunistic malware, network surveillance, and coerced/borders access — the core of who threat-model.md defends.

2. Threat model for this device (mapped to the program threat model)

This is a pocket-sized everyday carry, so the realistic threat ranking differs from a desk machine. Mapped onto the program tiers in threat-model.md:

Rank	Threat (this device)	Program-threat-model row	Primary controls
1	Loss / theft, powered-off	"Physical seizure, powered off" → Yes, defended	BitLocker XTS-AES-256 + PIN (§E), Secure Boot (§B)
2	Opportunistic malware / remote	"Targeted commercial spyware", "remote exploitation (partial)"	VBS/HVCI, Credential Guard, WDAC, ASR, Defender (§C–D)
3	Network surveillance	"Network observation" → Yes	SilverVPN always-on + kill-switch, encrypted DNS, firewall (§F)
4	Coerced unlock / border / theft powered-on	"Coercion / duress" → Partial	Lock-screen hygiene (§G), SilverDuress panic-wipe (Stack)
5	Evil-maid / targeted physical	"Hardware implant" → Partial	TPM+PIN (defeats faulTPM-class offline attack), DMA-port lockdown (§G)
—	Dedicated state actor / firmware implant	Explicitly NOT defended	Out of scope — acknowledged in §10, not claimed

Decision of record: SilverMetal Enhanced — Windows does not claim the nation-state/firmware tier on the Pocket 4. The closed BIOS, the PSP-resident fTPM, and the absence of hardware kill switches put that tier out of reach of any software configuration. This is stated to the buyer, not buried.

3. Edition baseline

	This unit (prototype)	Shipping SKU (target)
Edition	Windows 11 Enterprise (available now)	Windows 11 IoT Enterprise LTSC (per README.md)
Telemetry floor	Security (level 0) via GP	Security (level 0) — same
Credential Guard / WDAC	Full	Full
Servicing	Annual feature updates	~10-year LTSC, no feature-update churn
Default bloat	Consumer apps present (remove in §A)	Minimal (no Store/Cortana/Edge baked in)

At the hardening layer the two are equivalent — identical GP, Defender, VBS, and WDAC capability. The deltas are bloat surface and servicing channel only. IoT Enterprise GAC is an acceptable intermediate if LTSC licensing is unavailable, at the cost of the LTSC servicing guarantee.

---

Control domains

Each domain lists the controls, the rationale, and a verification check (a command or observable that proves the control is active — evidence before assertions). Apply order is A → H.

A. Provisioning baseline

Goal: start from a clean, de-clouded, debloated install with telemetry at its floor.

• Install from a clean Microsoft ISO (not an OEM image); wipe the GPD factory Windows entirely.
• Local account only — no Microsoft Account sign-in, no OneDrive linkage, no cloud key escrow. (OOBE: bypass MSA via BYPASSNRO / offline-account path.)
• Set diagnostic data to Security (0): Computer\Policies\...\DataCollection\AllowTelemetry = 0 (Enterprise/LTSC only honour level 0).
• Disable: Advertising ID, Activity History / Timeline, Tailored Experiences, Suggested Content, Find-My-Device, Recall (Windows AI), Copilot, Cortana, Customer Experience Improvement Program, Connected User Experiences (DiagTrack, dmwappushservice).
• Remove consumer provisioned apps (Enterprise prototype only; LTSC ships without them).
• Region/keyboard/time without "send my data to improve" toggles.

Verify: Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection' -Name AllowTelemetry returns 0; Get-Service DiagTrack is Stopped/Disabled; no Microsoft Account under Settings → Accounts.

B. Boot & firmware trust

Goal: make the boot chain ours as far as the OEM firmware permits, and lock the firmware's own settings.

• Secure Boot ON. Enrol our own PK/KEK/db so the chain trusts SilverMetal-signed components — but retain Microsoft's UEFI CA keys (option-ROM / GPU / NIC firmware on the Pocket 4 are MS-signed; purging them risks an unbootable device). Honest note: this is additive trust, not a clean-room root — the OEM firmware is still the ultimate root (§10).
• Set a BIOS/UEFI administrator password (blocks casual firmware reconfig / boot-order change at a checkpoint).
• Disable unused boot paths: network/PXE boot, boot from removable unless needed, legacy/CSM.
• fTPM enabled (it is PSP-resident — see §10; we use it but do not over-trust it).
• Firmware-update hygiene: GPD ships BIOS as a Windows .exe in a RAR archive (not a signed capsule, not on LVFS). Treat every BIOS update as a supply-chain event: download only from the verified GPD source, record the version, apply deliberately, and re-verify §B/§E settings survive the update (open question: whether enrolled Secure Boot keys persist across a GPD BIOS flash — must be tested per update).

Verify: Confirm-SecureBootUEFI returns True; Get-SecureBootPolicy / [System.Text.Encoding] dump of db shows our key present; firmware admin password prompts on entry.

C. Data at rest (the crown jewel for this device)

Goal: a stolen powered-off device yields nothing.

• BitLocker, XTS-AES-256, OS volume + any data volume.
• TPM + PIN — never TPM-only. This is the single most important control on this device. The faulTPM research class extracts the BitLocker VMK from an AMD fTPM via ~$200 voltage-fault injection with a few hours' physical access — but that defeats TPM-internal authorisation only; a strong PIN forces an offline brute-force the attacker cannot shortcut. (Demonstrated on Zen 2/3; the Pocket 4's Zen 5 is untested, so we treat the risk as live by analogy.) Use a ≥8-char alphanumeric enhanced PIN.
• No recovery key in the Microsoft cloud. Recovery key is printed/stored offline by the user (or in SilverKeys). OSManageDRA/GP set to forbid cloud escrow.
• Disable automatic device encryption that would silently bind TPM-only before PIN is set.
• Bind to a sane PCR set and disable BitLocker standby/auto-unlock that would re-derive the key on resume without a PIN (ties to §G).

Verify: Get-BitLockerVolume shows ProtectionStatus On, EncryptionMethod XtsAes256, and KeyProtectors include TpmPin (not Tpm alone); manage-bde -protectors -get C: confirms no numerical recovery password is cloud-escrowed.

D. Kernel & credential isolation

Goal: use Microsoft's hardware-backed isolation primitives — the genuinely strong part of hardened Windows.

• VBS (Virtualization-Based Security) ON with HVCI / Memory Integrity enforced.
• Credential Guard ON (VBS-isolated LSA — defeats Mimikatz/pass-the-hash credential theft).
• LSA protection (RunAsPPL) enabled.
• Kernel DMA Protection ON — on AMD this depends on the firmware setting the ACPI IVRS DMA_REMAP bit; if the Pocket 4 firmware does not, fall back to disabling/blocking the Thunderbolt/USB4 DMA path (§G). (Open question: confirm iommu_dma_protection is actually reported.)
• System Guard / DRTM where the platform exposes it (likely absent on the Pocket 4 — document, don't claim).

Verify: msinfo32 → "Virtualization-based security" = Running, services = "Credential Guard, HVCI"; Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard shows SecurityServicesRunning includes 1 (CG) and 2 (HVCI); Settings → Privacy & security → Device security → Core isolation → Memory integrity = On; Kernel DMA Protection shows "On" in System Information.

E. Application control

Goal: only trusted code runs; aggressively reduce exploit surface. Balanced posture: audit first, then enforce.

• WDAC (App Control for Business) as the primary allow-listing engine — kernel-enforced, the modern successor to AppLocker (which is not kernel-enforced and is treated as legacy). Deploy in AUDIT mode first (logs what would be blocked) for a real-usage shakedown period, then promote to ENFORCE. AppLocker remains the documented fallback where WDAC policy authoring is impractical.
  • Productization note: the SKU ships a pre-authored base WDAC policy (Windows + Stack + common dev tools signed/approved); the prototype builds that policy from its own audit logs.
• Defender ASR rules at maximum (block credential theft from LSASS, Office child-process creation, obfuscated scripts, executable content from email/USB, etc.).
• Microsoft Defender real-time + cloud-delivered protection ON for detection, but automatic sample submission OFF (privacy — design-principle #5/#8: we do not exfiltrate user files for "improvement").
• SmartScreen ON; Controlled Folder Access (anti-ransomware) ON with Stack apps allow-listed.
• Exploit Protection (system-wide DEP, ASLR, CFG, SEHOP) at default-hardened.

Verify: Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard shows CodeIntegrityPolicyEnforcementStatus = 2 (enforced) after promotion; Get-MpPreference | Select Attack* lists ASR rules in Block (1) mode; Get-MpPreference SubmitSamplesConsent = 2 (never send).

F. Network & radios (distrust the network — principle #11)

• SilverVPN always-on with kill-switch — if the tunnel drops, traffic stops (no plaintext fallback). Integrated from the existing SilverLABS/SilverVPN MAUI Windows client.
• Encrypted DNS (DoH) system-wide; disable plaintext DNS fallback.
• Windows Firewall: default-deny inbound, outbound restricted to the VPN + essential update/licensing endpoints.
• Disable LAN-leak vectors: LLMNR, NetBIOS-over-TCP/IP, mDNS responder, WPAD, SMB1, link-local multicast name resolution.
• WiFi-only — do not fit the 4G/5G module. The optional Pocket 4 cellular module adds a baseband processor (an unauditable radio with independent firmware and potential independent memory access). Omitting it removes the entire baseband attack/telemetry surface — the cleanest available substitute for the hardware kill switch the device lacks (§10).
• Bluetooth off unless actively used.

Verify: Get-DnsClientDohServerAddress populated + Get-DnsClientGlobalSetting; Get-NetFirewallProfile shows DefaultInboundAction Block; Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol = Disabled; VPN kill-switch tested by pulling the tunnel and confirming no egress; no WWAN adapter present.

G. Physical & lock-screen hygiene (theft is threat #1)

• Short auto-lock (≤2 min idle → lock) and lock on lid-close; require PIN/Windows Hello on every wake (no "stay unlocked" grace).
• Disable BitLocker auto-unlock across sleep/standby so a powered-on-but-locked stolen device cannot resume into an unlocked session without the PIN. Prefer hibernate over sleep (keys not left in RAM as long); document the battery/UX trade.
• USB / DMA port policy: with the Pocket 4's USB4/Thunderbolt-class ports, restrict device installation to an allow-list and block new DMA-capable devices at the lock screen (Disable new DMA devices when this computer is locked). If §D's Kernel DMA Protection isn't firmware-backed, this is the compensating control.
• SilverDuress (Stack, v1.1) — duress PIN / panic-wipe for coerced-unlock and border scenarios (the program's "Partial" answer to the coercion row).
• No hardware kill switches exist on the Pocket 4 — so camera/mic are mitigated in software (disable in Device Manager / privacy settings, per-app camera+mic denial) plus the physical stopgaps (camera shutter/tape). Stated honestly: software disable trusts the firmware not to lie; it is not equivalent to a severed line.

Verify: Get-CimInstance Win32_OperatingSystem lock policy via secpol/GP (InactivityTimeoutSecs ≤120); resume-from-sleep prompts for PIN; lock-screen DMA policy set (HKLM\...\FVE\DisableExternalDMAUnderLock = 1); camera/mic show disabled in Device Manager.

H. Privacy minimisation & update integrity

• Telemetry floor (§A) + scheduled-task and service trim (disable telemetry/feedback/CEIP tasks; keep update, time-sync, and security tasks).
• Do NOT block Microsoft domains in the hosts file. Modern telemetry bypasses hosts (hardcoded IPs/DoH), and hosts-blocking MS endpoints breaks Windows Update — violating design-principle #13 ("Update or die"). Telemetry suppression lives at the GP + service + firewall layers; endpoint blocking is reserved for non-essential, non-update domains only.
• Windows Update stays ON (signed, automatic, with rollback) — patching is the single largest real-world risk reducer. We minimise telemetry, never patching.
• Publish the residual telemetry — run the telemetry-leak test (§ Verification) and document, in full, the minimum-feasible Microsoft contact that remains. We do not claim zero.

Verify: telemetry-leak capture (below); Get-Service wuauserv running; hosts file contains no Microsoft update/licensing domains.

---

4. The SilverLABS Stack on this device

Per design-principle #7 ("the Stack is the spine, not the OS"), the durable privacy value is the Stack, shipped as native Windows builds:

Component	Role on this device	Maps to
SilverBrowser	Default browser; replaces Edge/Chrome	A, H
SilverVPN	Always-on tunnel + kill-switch	F
SilverSync	Replaces OneDrive (client-side encrypted)	A
SilverChat	E2EE messaging (Signal Protocol over VPN)	F
SilverDuress	Duress PIN / panic-wipe	G
SilverKeys	Password + 2FA + offline BitLocker recovery-key store	C, A

The host OS is treated as semi-trusted even hardened (principle #12): Stack apps client-side-encrypt before disk write and do not rely on the Windows credential store for the most sensitive secrets.

5. Residual-risk statement (buyer-facing, honest)

SilverMetal Enhanced — Windows on the GPD Pocket 4 does not protect against:

1. Firmware-tier compromise — the OEM BIOS is closed, delivered as an unsigned-from-documentation Windows installer, with no coreboot/Heads port; we cannot audit or replace it.
2. The AMD PSP — an always-on, pre-x86 security processor that is the true boot root of trust; it cannot be disabled (no AMD equivalent of Intel ME-disable/HAP exists — see ../docs/hardware-skus.md).
3. Evil-maid against the fTPM — mitigated, not eliminated, by BitLocker TPM+PIN (offline brute-force only).
4. Camera/mic/radio at the hardware level — there are no hardware kill switches; software disable trusts the firmware. (Mitigated by not fitting the cellular module and by physical camera cover.)
5. A dedicated, well-resourced state actor targeting this user specifically — undefendable on commodity hardware, per ../docs/threat-model.md.
6. Irreducible Windows telemetry — minimised to the Security floor and published; not zero.

If a buyer's threat model centres on #1, #2, or #5, the correct product is SilverMetal OS — Linux on coreboot/ME-neutralised hardware (../docs/hardware-skus.md), not Enhanced-Windows on a consumer UMPC.

6. Verification gates (must pass before a build is "SilverMetal")

Aligned with README.md and design-principle #4 (verifiable):

1. Telemetry-leak test — capture all egress on a clean hardened build (VPN off, to a controlled resolver/proxy) for a fixed window; classify every Microsoft contact; publish the residual. Pass = no telemetry beyond the documented minimum.
2. BitLocker — Get-BitLockerVolume shows XTS-AES-256 + TpmPin protector; no cloud-escrowed recovery key.
3. VBS/HVCI/Credential Guard — Win32_DeviceGuard shows all three running.
4. WDAC — enforced policy active (CodeIntegrityPolicyEnforcementStatus = 2); audit-log review documented.
5. VPN kill-switch — tunnel-drop test shows zero egress.
6. Secure Boot — Confirm-SecureBootUEFI = True with our db key enrolled.
7. Stack — all six components install and function on the hardened build.
8. Update path intact — wuauserv healthy; a test update applies and rolls back.

A reusable PowerShell Verify-SilverMetalWindows.ps1 (productization) asserts gates 2–6 and 8 and emits a signed attestation report.

7. Productization notes (one-off → SKU)

• Re-base from Enterprise to IoT Enterprise LTSC (no functional hardening change; less bloat, longer servicing).
• Convert the prototype's hand-applied settings into the planned windows/ layout: installer/ (PowerShell/WiX), policies/ (GP/ADMX export), applocker/ → wdac/ (rename to reflect the WDAC primary decision), debloat/, stack-installer/, tests/ (telemetry-leak + baseline).
• Author the base WDAC policy from this unit's audit logs.
• Decide Secure Boot key custody (the program signing key per ../docs/trust-model.md vs a Windows-specific subkey).
• Track the open questions (§8) per BIOS revision.

8. Open questions (carry until resolved on the physical unit)

1. Confirmed UEFI vendor (AMI vs Insyde) — inferred AMI-pattern from the Windows-flash flow; verify on the unit.
2. Do enrolled Secure Boot keys survive a GPD BIOS update? (Test across one update cycle.)
3. Does the firmware set the ACPI IVRS DMA_REMAP bit so Kernel DMA Protection is real, or must §G's lock-screen DMA block carry it alone?
4. Is the faulTPM voltage-fault class reproducible on Zen 5 Strix Point, or did AMD add SVI countermeasures?
5. Does the optional 4G/5G baseband have independent DMA/memory access? (Moot if not fitted — and we don't fit it.)

9. References

• Deep-research assessment (2026-06-08), summarised in operator memory silvermetal-pocket4-security-assessment.
• faulTPM — defeating AMD fTPM via voltage fault injection: https://arxiv.org/abs/2304.14717, https://github.com/PSPReverse/ftpm_attack
• AMD PSP as boot root of trust / fTPM trustlet: https://doc.coreboot.org/soc/amd/psp_integration.html
• Kernel DMA Protection on AMD (IVRS DMA_REMAP): https://patchwork.kernel.org/project/linux-usb/patch/20220315162455.5190-2-mario.limonciello@amd.com/
• GPD Pocket 4 BIOS update method (Windows EXE in RAR): https://gpdstore.net/kb/gpd-pocket-4-support-hub/kb-article/how-to-update-the-gpd-pocket-4-bios/
• Microsoft: VBS/HVCI, Credential Guard, WDAC (App Control for Business), BitLocker enhanced PIN, ASR rules — Microsoft Learn (current docs).
• SilverMetal program: ../docs/threat-model.md, ../docs/design-principles.md, ../docs/hardware-skus.md.