docs(windows): Enhanced-Windows hardening spec (GPD Pocket 4 reference) #2

Merged
SilverLABS merged 2 commits from docs/enhanced-windows-hardening-spec into main 2026-06-08 14:45:15 +00:00
2 changed files with 230 additions and 7 deletions
Showing only changes of commit ea2de4339d - Show all commits

View File

@@ -11,11 +11,12 @@ Tier C — config-layer hardening only. Honest positioning: we cannot modify the
LTSC IoT-based installer that transforms a vanilla Windows install into a SilverMetal-hardened build:
- Windows 11 IoT Enterprise LTSC base (no Cortana, no Store, no Edge baked in, ~10-year support)
- Group Policy hardening (telemetry off, services disabled, sane defaults)
- Group Policy hardening (telemetry at `Security` floor, services disabled, sane defaults)
- VBS + HVCI + Credential Guard + Kernel DMA Protection (Microsoft's hardware-backed isolation)
- Defender ASR rules at maximum
- AppLocker allow-list mode
- BitLocker enforced (TPM-bound)
- Telemetry blocked at hosts file + service + GP layers
- WDAC (App Control for Business) allow-list — kernel-enforced, audit-first then enforce (AppLocker is the documented fallback, not the primary)
- BitLocker enforced **TPM + PIN** (never TPM-only; PIN defeats the faulTPM-class offline attack on the AMD fTPM)
- Telemetry suppressed at GP + service + firewall layers (**not** hosts-file blocking of Microsoft domains — that breaks Windows Update); residual published, not claimed zero
- Edge / Chrome replaced with SilverBrowser default
- Full SilverLABS Stack preinstalled (native Windows builds)
- SilverVPN MAUI Windows client integrated from existing [`SilverLABS/SilverVPN`](https://git.silverlabs.uk/SilverLABS/SilverVPN)
@@ -34,7 +35,7 @@ To be populated in Phase 3W. Initial structure planned:
windows/
├── installer/ # PowerShell / WiX-based installer
├── policies/ # Group Policy templates, ADMX
├── applocker/ # AppLocker rules
├── wdac/ # WDAC (App Control) policies (AppLocker fallback rules if needed)
├── debloat/ # Removal scripts (Edge, Cortana residue, telemetry)
├── stack-installer/ # Native SilverLABS Stack package builders
└── tests/ # Telemetry-leak test, hardening-baseline test
@@ -43,10 +44,15 @@ windows/
## Verification gates
- Telemetry-leak test on hardened install — minimum-feasible Microsoft contact, *documented in full* (we cannot reach zero on Windows; we publish what remains)
- BitLocker enabled with TPM binding verified
- AppLocker allow-list functional and documented
- BitLocker enabled with **TPM + PIN** binding verified (TPM-only is rejected)
- VBS / HVCI / Credential Guard verified running
- WDAC allow-list functional (enforced) and documented
- Stack apps install and function
## Full hardening specification
The detailed control spec — eight control domains, verification commands, residual-risk statement, and productization notes — lives in [`hardening-spec.md`](hardening-spec.md). Reference device: GPD Pocket 4 (AMD Strix Point).
## Upstream we depend on
- **Windows 11 IoT Enterprise LTSC** — base OS (licensed)

217
windows/hardening-spec.md Normal file
View File

@@ -0,0 +1,217 @@
# 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`](README.md) and is bound by [`../docs/threat-model.md`](../docs/threat-model.md) and [`../docs/design-principles.md`](../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`](../docs/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`](../docs/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 (§CD) |
| 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`](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`](https://git.silverlabs.uk/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`](../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`](../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`](../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`](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 26 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/`](README.md) 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`](../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/threat-model.md), [`../docs/design-principles.md`](../docs/design-principles.md), [`../docs/hardware-skus.md`](../docs/hardware-skus.md).