The signed driver pack

Every camera, switch, and controller in your enclave gets its identity from a vendor driver that knows how to talk to that specific device. Skans keeps all of that vendor code out of the trusted core: it lives in the Driver Pack — a separately versioned, cryptographically signed artifact that loads out-of-process in a host holding no CA key and no secrets. New vendor support ships as a new pack, not a new appliance, and a bad pack can never issue a bad identity.

Why the pack is a separate artifact #

The pack ships and versions independently of the control plane, on the same model as a Milestone device pack. The pack moves 4–6 times a year as vendors change; the control plane moves about once every year or two. Adding or fixing a vendor means shipping a new pack — no control-plane rebuild, no redeploy.

That separation is enforced in the build, not just by convention. Skans.ControlPlane no longer references the drivers assembly at all: the old per-vendor driver map is gone, and the published control-plane binary contains zero driver types. On boot the control plane logs mounted 123 driver(s) from the versioned store — the drivers are loaded at runtime, never compiled in.

What’s in the pack — and what’s actually proven #

The pack carries 123 vendor drivers across 16 device categories. Be clear-eyed about validation depth:

Of the 118, 69 also rotate the device’s admin password (drivers tagged for credential rotation). Coverage by category:

Transports vary honestly per vendor and are recorded per-driver — Axis uses a REST cert API plus a separate SOAP bind; Bosch uses RCP+ over CGI; UniFi has no cert API, so its driver writes files over SSH and restarts unifi-core. Drivers whose approach is unproven carry an explicit confidence: LOW note in-source.

Some device classes cannot take a certificate #

28 vendors were assessed as not cert-deployable — no per-device TLS-cert API (cloud-managed, IDE/serial, BACnet, proprietary controllers). A driver for such a device throws a clear error instead of faking success. The right posture there is to secure the conduit — put a certificate and access control on the switch or firewall in front of the device — and monitor the device itself. PLCs, for example, stay monitored read-only through the collector rather than being falsely reported as hardened.

The trust spine: verified before every load #

The pack is data the appliance runs, so it is verified on every mount, not just at install. Three gates, all must pass:

1. Signature — a detached CMS / PKCS#7 signature over the pack, chained to a Skans release anchor (an isolated custom root; revocation is NoCheck for air-gap operation).
2. Inventory integrity — every file in the pack is hashed and checked against the signed manifest, so a single tampered byte is caught.
3. ABI compatibility — the manifest declares the contract version it was built against; the host loads it only if the major version matches and the host is new enough. The contract is additive-only, so older packs keep loading against a newer host.

A pack that is missing, tampered, unsigned, or ABI-incompatible is refused.

The host: least-privilege, and no CA key #

Vendor driver code is third-party attack surface, so it never runs in the trusted core. Skans.DriverHost is a separate process under a constrained SkansDriverHost identity. It loads the pack in a collectible assembly context and exposes drivers back to the core over a named pipe, supervised by the core. Host and core share only a zero-dependency abstractions contract — nothing else.

The critical boundary: the CA key stays in the core. Only the two device-touching calls — deploy a cert, set a password — marshal out to the host. The certificate itself is issued in-process in the core; the CA private key never crosses the pipe. The host holds:

• no CA key
• no domain-admin credentials
• no stored device passwords — device credentials are passed per-operation from the credential vault and are never written into the pack

That is the whole point of the isolation: a compromised or buggy driver can misbehave inside a low-privilege sandbox, but it cannot reach the crown jewels. (The vault the host draws from uses envelope encryption under a hardware-protected key — see Manage credentials.)

What a deploy actually does #

When you approve enrollment, the resolved driver’s deploy path runs end-to-end and verifies its own work on the wire:

TEXTCopy
1. Core issues an X.509 cert from the Skans CA (in-process — CA key stays in core)
2. DriverHost installs the cert on the device via its native mgmt API
3. Driver binds the device's HTTPS management interface to the new cert
4. Deployer re-reads the served certificate and confirms the serial matches
   ✓ proven on the wire, not assumed

This was proven live: a real Axis camera at 192.168.102.41 enrolled end-to-end through the signed runtime pack — CA issued in-core, the deploy marshalled over the named pipe to the pack-loaded Axis driver, and the TLS probe confirmed the camera was serving the new serial under the Skans root CA.

A bad pack fails safe #

The pack’s failure behavior is split deliberately:

• Boot fails open. A missing, invalid, incompatible, or unsigned pack never crashes the control plane. It sets DriversAvailable = false with a reason and keeps running — the console stays up. (Proven: removing the active-version pointer left the control plane running.)
• Enroll fails closed. With no valid pack, per-device enrollment fails closed — it returns an error, never a fake success. Restoring the pointer remounted all 123 drivers and enrollment resumed.

Hot-reload without a restart #

Applying a new pack does not restart the control plane. The host performs an atomic hot-swap: it builds a new host, starts it, swaps the live handle, then drains in-flight operations from the old one before disposing it. Proven live — a console .skb upload was adopted by the running control plane with its PID unchanged, while the out-of-process host PID changed.

Under the hood, the versioned store lives at C:\Skans\drivers\packs\<id>\<ver>\ with a current.json pointer naming the active version. An out-of-band update arrives as a signed .skb bundle, verified and applied idempotently, behind a load-probe gate — a pack that is signature-valid but exposes no drivers is refused before it can become current.

Two packs, one idea — don’t conflate them #

The word “pack” is used for two different artifacts that are isolated for the same reason (vendor churn shouldn’t touch the core), but they are separate and ship independently:

This page is only about the signed cert-driver code pack. The SNMP profiles are a different, unsigned read-path artifact and are out of scope here.

Where you manage it #

The operator surface is the console at /system/driver-pack — upload and apply a signed .skb, and compare the running pack version against the software version. The first pack is seeded automatically during installation.

The skans pack ... command-line tooling (new-signer, manifest, sign, verify) is the developer / release path for building and signing a pack off the appliance — not part of normal operation.

Next #

• Enroll a device → — the write path in action
• Device identity → — what the issued certificate buys you
• Manage credentials → — the vault the host draws from per-operation