Security

• 1: Disk encryption
• 2: TPM & device attestation
• 3: Secure Boot
• 4: SSH access
• 5: User accounts
• 6: USB device control
• 7: Remote access

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.
• Create an install image — enabling encryption and setting a recovery passphrase at image time.

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.

What you need

• 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.

Related

• TPM & device attestation — proving a device is what it claims to be.
• Disk encryption — protecting data at rest.
• Security — the rest of this section.

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. It is the account you use on the console, and over SSH if you enable password authentication.

Where the initial password comes from

This depends on how the device was installed, and the difference matters: one of these paths gives you a device that is reachable with a credential you did not choose.

SPEKTRA Edge appliances

An appliance arrives with the OS already installed, so it needs a credential you can use on first boot. That credential is the hardware serial number. It works only while no administrator password has been set: once you set one, the serial number stops being accepted.

sudo change-password

Images downloaded from the dashboard

When you download an install image from the dashboard you supply the administrator password at that point, and it applies to every device built from that image.

Vanilla image files

A vanilla image file downloaded directly has no administrator password in it. You configure one with cuttle while customizing the image, before writing the installation media:

sudo -E cuttle os edit \
  --image-file spektra-edge_generic-amd64_$VERSION.raw \
  --password $PASSWORD

The device then has the password you supplied, and there is no default credential at any point. See Create an install image for the surrounding workflow.

Devices running the droplet agent from a .deb

Installing the agent onto a machine you already run does not create or manage local accounts, and does not change how that machine authenticates logins. Its existing users, passwords, and SSH configuration continue to apply, and nothing on this page does. See Install the droplet agent.

How the password is stored

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.

Changing the password on a running device

On a device you can still sign in to, change the password from its console:

sudo change-password

It prompts for the current password before accepting a new one, so it changes a password; it does not recover a lost one. The only exception is a device that has no password set yet, such as a new appliance, where it asks only for the new password.

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 without reinstalling. Every route needs physical access to the storage, though: a lost password cannot be reset over the network.

Point cuttle at the disk holding the configuration partition to write a new password to it directly:

sudo cuttle os change-password $PASSWORD --out-device /dev/sdX

Re-imaging the device is the other option, and the one to choose if you also want to reset the rest of its configuration.

On a SPEKTRA Edge appliance the configuration partition is inside the unit, so resetting a lost password means either removing the disk to run the command above against it or re-imaging. Neither the serial number nor the platform can recover it: the serial number is refused once any password is set, and there is no remote password reset.

If the device is still reachable through the platform, you can continue to operate it via remote access while you arrange physical access — managing a device does not depend on its local administrator password.

Recommendations

• On an appliance, set an administrator password before anything else. Until you do, the serial number is a working credential.
• 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. If you do enable SSH password authentication, make sure every device in scope has a password you chose first.

Related

• SSH access — preferred over password login.
• Device setup & provisioning — where the administrator password is first set.
• Security — the rest of this section.
• Create an install image — setting the initial administrator password.

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.

Related

• Remote access — reaching a device without physical access.
• Security — the rest of this section.

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.

Related

• SSH access — how shell access is authenticated and restricted.
• Device overview — opening a terminal from the dashboard.
• Security — the rest of this section.