Gate Provider
OEM- or OS-signed component that starts from a privileged lifecycle hook. It owns the decision to release the protected environment; presentation code cannot grant access by itself.
Production reference · OEM / OS integration
ImageLockDX runs after device login and before protected work begins.
The ImageLockDX security boundary is a privileged native gate, not a browser route, PWA, startup item, or screen overlay. A successful gate releases a short-lived, device-bound authorization to the protected launcher, shell, workspace, or application broker. No release, no protected work.
Boundary statement.
The PWA, account portal, and Demo Console are sales and interoperability demonstrations. They can show the cognitive challenge and one-way verifier format. They cannot prevent a user from closing a browser, opening another app, editing local UI code, or reaching the operating-system shell. They are not production protection.
1. Enforcement model
Boot / OS sign-in / device-login factor
↓
Privileged ImageLockDX Gate Provider starts before launcher, shell, or protected workspace
↓
Trusted native presentation + image challenge + passphrase entry
↓
Hardware-backed verifier evaluates the response and durable policy state
↓
PASS → issue short-lived, device-bound Gate Grant → start protected shell/apps
FAIL → retain gate → apply retry/lockout policy outside UI → audit / recovery path
Verifier enclave
Stores an opaque one-way verifier and retry state in StrongBox/TEE, TPM, Secure Enclave, or equivalent. It never retains a plaintext or decryptable passphrase.
Application broker
Launcher, shell, or protected-app policy checks a live Gate Grant before creating a user workspace or process. Direct launches without a grant are denied.
Recovery authority
Separate from the user-facing gate. Signed recovery approval, enrolled-admin authorization, and audit records are required to replace a credential or release a lockout.
2. Credential and policy rules
| Rule | Production requirement | Why |
|---|---|---|
| Passphrase material | Persist only a one-way verifier bound to the trigger-image hash and random salt. The verifier is opaque to normal applications. | There is no stored plaintext or encrypted passphrase to decrypt or export. |
| Image relationship | Enrollment must require the response to be uncorrelated with the image; the image is a cognitive trigger, not cryptographic key material. | An image does not reveal the response. |
| Retry state | Counter, backoff, and locked status are owned by the privileged verifier/policy service and committed before returning control to the UI. | Killing, reinstalling, or modifying a UI cannot reset attempts. |
| Tamper state | Measured boot, code-signing, secure-storage integrity, and policy version checks quarantine the gate on failure. | A compromised gate must fail closed before protected apps start. |
| Update state | Only signed, version-pinned gate packages; anti-rollback is anchored in the platform secure store or firmware counter. | An attacker cannot restore a weaker verifier or bypass build. |
| Recovery state | Admin/OEM-approved recovery operates through a separate signed channel and generates a visible audit event. | “Forgot passphrase” cannot become a bypass button on the gate screen. |
3. Platform paths
| Platform | Post-login, pre-application gate | Hardware / OS requirement |
|---|---|---|
| Android | After the Android sign-in factor and before the standard Launcher or managed workspace becomes available, an OEM/system app or Android Enterprise device-owner Gate Provider presents ImageLockDX. The provider releases a managed launcher/work-profile grant only after verification. | OEM signing or managed device-owner privileges; Android Keystore backed by StrongBox/TEE where available; DevicePolicyManager/managed launcher controls; verified boot and signed updates. |
| Windows | ImageLockDX is part of the sign-in chain through a signed Credential Provider, or—where the first Windows factor has already completed—blocks the assigned shell and protected-app broker until its gate service issues a grant. The Windows desktop is not released by a startup app. | Microsoft/OEM-approved Credential Provider or shell policy; signed Windows service; TPM/CNG-protected material; WDAC/AppLocker or managed protected-app policy; BitLocker/measured boot attestation. |
| macOS | For managed/OEM deployments, the gate is tied to the authorized login/managed-workspace lifecycle and the protected-app policy checks the service grant before launch. A Login Item or standard macOS app is not sufficient. | Apple-authorized system extension or OS/OEM partnership; Secure Enclave binding; MDM-managed app restrictions; signed and notarized components; platform security and update policy. |
| Dell / OEM workstation | Dell firmware and the signed Windows image establish the chain: measured boot → Windows identity factor → ImageLockDX Gate Service/Credential Provider → policy-controlled shell and applications. Dell management can attest gate health before releasing managed workloads. | Dell BIOS/UEFI and firmware collaboration; TPM 2.0 binding; signed Windows image and Credential Provider/service; enterprise management and recovery channel; optional firmware counter for anti-rollback. |
4. Retry, lockout, recovery, update, and tamper behavior
Retry
Each failure is atomically recorded in protected state before the gate redraws. The interface receives a display-only remaining-attempt value.
Lockout
At the policy threshold, the Gate Provider denies grants, records an auditable reason, and invokes configured response actions. Restarting the UI does not change this state.
Recovery
Recovery requires a separately authenticated operator or OEM service flow. It replaces the sealed verifier and clears state only after a signed authorization is validated.
Update & tamper
Rollback-protected, signed updates are verified before activation. Failed measurements, malformed credentials, or integrity failures enter quarantine; protected apps stay unavailable.
5. What the current reference artifacts do—and do not—prove
| Artifact | Valid use | Not a claim of |
|---|---|---|
| ImageLockDX PWA | Browser-based cognitive challenge and portable verifier demonstration. | Device, desktop, application, retry, or tamper enforcement. |
| ImageLockDX Android reference app | Native app-level gate, OS secure-storage integration, and protected reference screens. | Device-wide interception of the Android Launcher or every third-party application. |
| Demo Console | Sales visualization of sequencing, attack narrative, and OEM licensing discussion. | A live Secure Enclave, TEE, TPM, firmware, or OS security implementation. |
| Account Portal | License management and reference credential generation. | Authority to install an OS-level gate or recover a locked production device. |
6. Dell decision checklist
- Confirm the enforcement target: Windows sign-in chain, managed shell, named protected applications, or a Dell firmware-assisted workspace path.
- Confirm which Dell-managed hardware exposes a TPM-backed, non-exportable storage and attestation interface for the Gate Provider.
- Agree code-signing, update, rollback, and image-servicing ownership before any customer deployment.
- Define an auditable enterprise recovery authority; do not place recovery in the user-facing challenge UI.
- Red-team the entire path: boot, sign-in, service start, launcher/shell release, direct process launch, offline disk access, update rollback, and recovery.