• 1:
• 2:
• 3:
• 4:
• 5:
• 6:
• 7:

1 -

Disk encryption

Disk encryption protects the data at rest on a device, so that a lost or stolen device does not expose your configuration or workload data. This page explains what is encrypted, how a device unlocks itself, and how to recover access.

What is encrypted

When encryption is enabled, the two areas that hold your information are encrypted:

• the configuration area (device settings, identity, administrator password, hooks)
• the data area (container images, workload data, logs)

The boot and system-image areas are not encrypted; they contain only the operating system, which is public and identical across devices.

Enabling encryption

Encryption is chosen when you create an install image. You can also set an initial recovery passphrase at that time. Because enabling encryption affects how the disk is laid out, it is selected at image creation rather than toggled on a running device.

How a device unlocks itself

Encrypted devices unlock automatically at boot using the device’s hardware security module (TPM). The encryption keys are bound to the device’s hardware and to the integrity of its boot state, so the disk unlocks only on the same device, booted normally. There is no passphrase to type at the console during a normal boot, which is what allows encrypted devices to run unattended.

Because the keys are tied to the hardware, moving an encrypted disk to different hardware will not unlock it. This is the intended protection.

Recovery passphrase

In addition to automatic hardware unlock, a device can hold a backup recovery passphrase. This is a human-known passphrase you can use to unlock a device if automatic unlock is unavailable — for example after certain hardware changes.

Recommendations:

• Set a recovery passphrase (at least 12 characters) when you enable encryption.
• Store it securely, separately from the device.
• Treat it as a break-glass credential — it can unlock the encrypted areas.

Recovery scenarios

Related

• TPM & device attestation — the hardware module that backs automatic unlock.
• User accounts — administrator password and reset.

2 -

TPM & device attestation

Devices use a hardware security module — a TPM (Trusted Platform Module) — to establish a strong, hardware-rooted identity and to protect sensitive material. This page explains what the TPM is used for and how attestation works during provisioning.

What the TPM is used for

• Device identity. The TPM holds keys that uniquely and verifiably identify the device. These keys cannot be copied off the device.
• Attestation. During provisioning, the device proves its identity and reports its integrity to the platform before it receives credentials.
• Disk unlock. When disk encryption is enabled, the TPM stores the keys that unlock the encrypted areas, bound to the device’s boot state.

Attestation during provisioning

When a device onboards using zero-touch provisioning or a provisioning policy, it presents hardware-backed identity to the platform and responds to a challenge that proves the keys really live in this device’s TPM. Only after this succeeds does the device receive its credentials. This is what makes it safe to ship unconfigured hardware directly to a site: an attacker cannot impersonate a device without its TPM.

For attestation to succeed, the platform must trust the device’s TPM. This is established through the manufacturer’s certificates, which an administrator registers in the platform so that devices from a given manufacturer or product line can be verified.

Attestation configuration and status

You can configure attestation expectations for a device, and the device reports its measured integrity values back to the platform, where you can review them on the device. Use this to confirm that devices booted in the expected state.

Requirements

• The device must have a functioning TPM.
• The device’s clock must be reasonably accurate for the secure exchange to succeed — see Time synchronization.

Related

• Disk encryption — uses the TPM for automatic unlock.
• Secure Boot — complements attestation by verifying the boot chain.

3 -

Secure Boot

Secure Boot is a firmware feature that ensures a device only runs boot software that is cryptographically signed and trusted. SPEKTRA Edge OS supports Secure Boot so that the boot chain — from firmware through to the operating system — is verified before it runs.

Why use Secure Boot

Secure Boot protects against tampering with the boot path. Combined with disk encryption and device attestation, it raises the bar for an attacker with physical access: the device will refuse to boot modified or untrusted boot software.

What you need to do

On most generic x86 hardware, SPEKTRA Edge OS works with Secure Boot enabled using trust that is already present in the firmware, so you can simply leave Secure Boot enabled in the device’s firmware (UEFI) settings.

To enable or disable Secure Boot, enter the device’s firmware setup at boot and change the Secure Boot setting, as you would for any UEFI system. Refer to your hardware vendor’s documentation for how to reach firmware setup.

Locked-down firmware and certificate enrollment

Some hardware is locked down to trust only a specific set of signing certificates. In those environments you may need to enroll the SPEKTRA Edge signing certificate into the firmware’s trusted database so that the device will boot the OS.

If you operate such hardware, contact your SPEKTRA Edge representative for the signing certificate and enrollment guidance for your platform.

If a device will not boot with Secure Boot on

If a device fails to boot only when Secure Boot is enabled:

1. Confirm the firmware is up to date.
2. If the firmware requires explicitly trusted certificates, enroll the SPEKTRA Edge signing certificate (see above).
3. As a diagnostic step, temporarily disable Secure Boot to confirm it is the cause, then re-enable it once trust is established.

4 -

SSH access

A device runs an SSH server so you can reach its console for administration. You control whether SSH is enabled, how users authenticate, and where connections may originate. SSH settings are managed from the dashboard (or the API) and applied to the device automatically.

Enabling or disabling the SSH server

You can turn the SSH server off entirely for devices that should never accept direct shell access. With the server disabled, you can still administer the device through remote access over the platform connection.

Authentication

You can control how users authenticate:

Authorized keys

You can provide one or more authorized public keys. Each key entry supports the usual SSH key options, including:

• marking a key as a certificate authority, so SSH certificates it signs are accepted
• restricting a key to specific source addresses
• forcing a specific command
• applying restrictions and principals

Using a certificate authority is recommended for fleets: you can issue short-lived SSH certificates to operators instead of distributing individual keys to every device.

Restricting where connections come from

You can limit which source addresses may connect:

• an allow list of addresses/ranges permitted to connect
• a deny list of addresses/ranges that are blocked

This is the closest thing to a host firewall for SSH and is the recommended way to limit exposure when SSH must remain reachable on a LAN.

Brute-force protection

The device protects the SSH service against repeated failed login attempts by temporarily banning offending sources. You can tune this behavior through the device configuration, including:

• the ban duration applied to an offending source
• an ignore list of trusted sources that are never banned

Recommendations

• Prefer key or certificate authentication and disable passwords where possible.
• Use source restrictions to limit who can reach SSH.
• Keep an ignore list for your own management hosts so administrative tooling is not banned.

Related

• User accounts — the administrator account used for login.
• Remote access — administer devices without exposing SSH on the LAN.

5 -

User accounts

Each device has a local administrator account used for console and SSH access. This page explains how its password is set and stored, and how to recover access if the password is lost.

The administrator account

The administrator account (admin) has the privileges needed to operate the device locally. For security, devices ship without a usable default password — the administrator password is something you set yourself, so there is no well-known credential to exploit.

Setting the password

You can set the administrator password:

• at image creation, so it applies to every device built from that image, or
• when preparing installation media, on a per-device basis.

The password must be non-empty. It is stored only as a salted hash on the device’s configuration storage — the plaintext password is never written to the device. When the configuration area is encrypted, the stored hash is protected at rest as well.

Resetting a lost password

Because the password is stored on the device’s configuration storage rather than inside the read-only system image, it can be reset:

• by re-applying an administrator password to the device’s installation media, or
• by re-imaging the device if you also want to reset the rest of its configuration.

If the device is reachable through the platform, you can also continue to operate it via remote access while you arrange a local password reset.

Recommendations

• Use a strong, unique administrator password per fleet or per device.
• Enable disk encryption so the stored password hash and all configuration are protected at rest.
• Prefer SSH key or certificate authentication over passwords for routine access.

6 -

USB device control

USB device control lets you restrict which USB peripherals a device will accept, protecting against unauthorized devices being plugged into hardware in the field. It is configured from the dashboard (or the API).

How it works

When USB device control is enabled, the device accepts only USB peripherals that match your allow rules; everything else is rejected. When it is disabled, USB devices are accepted normally.

Allow rules

Each allow rule describes the USB devices it permits. You can match on:

Rules can match a specific value or one of a set of values, so you can, for example, allow a specific approved peripheral on any port, or allow only devices connected to a particular internal port.

Recommendations

• Enable USB device control on devices in physically exposed locations.
• Allow only the specific peripherals your deployment needs (for example, an approved cellular modem or sensor), and reject everything else.
• Account for peripherals that are part of the device itself when writing rules, so enabling control does not disable required internal devices.

7 -

Remote access

You can administer devices remotely through the SPEKTRA Edge platform without exposing any inbound ports on the device. Operator actions are carried over the device’s existing outbound connection to the platform.

What you can do remotely

Through the platform you can:

• open a remote shell on a device
• transfer files to and from a device
• stream system logs and container logs
• start, stop, and restart workloads
• reboot or shut down a device

These work from the dashboard and from the cuttle command-line tool.

No inbound ports required

Because remote access rides on the device’s outbound connection to the platform, you do not need to open inbound ports or expose the device to reach it. This is what lets you administer devices behind NAT or restrictive firewalls. See Connectivity & ports.

Relationship to SSH

SSH access governs direct connections to the device’s SSH server on the local network. Remote access through the platform is separate and works even when SSH is restricted to a LAN or disabled entirely — making “SSH disabled on the device, administer through the platform” a viable hardening posture.

Auditing

Operator access through the platform is associated with the authenticated user who initiated it, so administrative actions can be attributed. Combine remote access with your organization’s account controls to govern who may reach devices.