Unsigned safety parameter integrity on a medical workstation

Sanitized finding from Client B. Safety parameter names, registry paths and binaries are generalized.

Context

A Windows helper applied device configuration values from a privileged process. The values influenced safety-relevant operating limits and were stored as raw binary data.

Finding

The helper accepted and wrote the configuration without a digital signature, keyed MAC or equivalent integrity verification. The same values were present across the assessed devices, and the write path did not provide a reliable allowlist or tamper check.

This created a trust gap: the application treated locally writable configuration as authoritative even though the data was security- and safety-sensitive.

Technical workflow

The reverse-engineering pass traced the parameter from the writable store to the privileged helper and compared the observed bytes with the device-side behavior. The following are read-only examples for an authorized Windows lab:

Get-ItemProperty 'HKLM:\SOFTWARE\AuthorizedProduct\Parameters'
Get-FileHash '.\fixtures\RegistryKeysSetter.exe' -Algorithm SHA256

A minimal integrity check should happen before deserialization or application of the value. The key must be held by a protected service or hardware-backed trust anchor, never embedded in the client:

import hmac
import hashlib

def verify_blob(blob: bytes, signature: bytes, verification_key: bytes) -> bool:
    expected = hmac.new(verification_key, blob, hashlib.sha256).digest()
    return hmac.compare_digest(expected, signature)

def validate_limit(value: int, minimum: int, maximum: int) -> int:
    if not minimum <= value <= maximum:
        raise ValueError("safety parameter outside approved range")
    return value

For production, asymmetric signatures and key rotation are preferable when multiple devices consume the same configuration. The security boundary must verify identity, freshness and range before the control path receives the value.

Impact

A local administrator or a process that reached the privileged helper could alter device behavior and persist modified limits. The issue increases the risk of unsafe configuration, fleet-wide drift and difficult incident attribution.

Remediation

• Sign or MAC safety-relevant parameters and verify them in the lowest trusted component available.
• Restrict write access to the configuration store and validate ranges and identities before applying values.
• Remove hard-coded fleet-wide safety constants from writable application logic.
• Log authorized changes with an integrity-protected audit trail.

Validation

Attempt modification with an invalid signature, an out-of-range value and an unauthorized caller. Each case should be rejected before the parameter reaches the device-control path.

Record the rejection reason, caller identity and immutable audit event. A successful write with a changed hash, stale version or invalid signature is a failed retest.