PARSEC Integration for Hardware-Backed Device Identity at the Edge

[Vad1mo]

Harbor Satellite operates on edge devices that are often physically accessible and deployed in untrusted environments. Currently, device identity and config encryption rely entirely on software-based mechanisms — credentials stored in config files, software-derived device fingerprints, and in-memory or disk-based key storage (see #254, #288).

This is insufficient for zero-trust edge deployments because:

• Software keys can be extracted. An attacker with physical access to an edge device can read credentials from disk or memory.
• Device identity is not hardware-attested. There is no cryptographic proof that a satellite is running on a specific, authorized device. Software-based fingerprints can be spoofed.
• Config encryption has no hardware binding. Encrypted configs can be copied to a different device and decrypted, since the encryption keys are not sealed to specific hardware.
• Ground Control cannot verify device authenticity. Without hardware attestation, Ground Control must trust software-reported identity, which is vulnerable to impersonation.

This is different from Cloud HSM (#254), which targets cloud-hosted key storage. Edge devices need on-device hardware security via TPMs, secure enclaves, or similar — abstracted through a platform-agnostic API.

Proposed Solution

Integrate CNCF PARSEC (Platform AbstRaction for SECurity) to provide hardware-backed device identity. PARSEC offers a uniform API across different hardware security backends (TPM 2.0, ARM TrustZone/CryptoCell, Intel SGX, PKCS#11 HSMs) without coupling Satellite to any specific platform.

Scope

1. Hardware-backed device attestation — Use PARSEC to generate and store device identity keys in hardware. The private key never leaves the secure element.

2. Hardware-sealed config encryption — Bind config encryption to the hardware identity so configs are only decryptable on the authorized device. Graceful fallback to software-based encryption when hardware is unavailable (VMs, dev environments).

3. X.509 device certificates — Issue device certificates backed by hardware-stored keys. Ground Control can cryptographically verify that a satellite's certificate is bound to a specific physical device.

4. SPIFFE/SPIRE integration — Extend the existing SPIFFE/SPIRE authentication (Embedded SPIRE: Use Persistent KeyManager Instead of In-Memory #288, Short-lived Satellite Credentials With Heartbeat-based Refresh #285) so that SVIDs can be backed by hardware key storage via PARSEC, adding hardware root-of-trust to the existing workload identity model.

5. Zero-touch provisioning (ZTP) — Enable new satellites to securely self-register using hardware attestation, without requiring manual credential distribution.

Design Constraints

• Must work alongside existing software-only mode (not all deployments have hardware security)
• PARSEC backend selection should be configurable (TPM, PKCS#11, etc.)
• Should not require changes to the OCI artifact sync protocol
• Must support air-gapped enrollment scenarios

Related Issues

• Cloud HSM Integration for Key Storage #254 — Cloud HSM Integration for Key Storage (cloud-side, complementary)
• Embedded SPIRE: Use Persistent KeyManager Instead of In-Memory #288 — Embedded SPIRE: Use Persistent KeyManager Instead of In-Memory
• Short-lived Satellite Credentials With Heartbeat-based Refresh #285 — Short-lived Satellite Credentials With Heartbeat-based Refresh
• mTLS Between Satellite and Ground Control #251 — mTLS Between Satellite and Ground Control
• FIPS/GDPR Compliance Audit and Hardening #253 — FIPS/GDPR Compliance Audit and Hardening

[maishivamhoo123]

@Vad1mo Sir while solving this issue https://github.com/container-registry/harbor-satellite/issues/288I noticed that the KeyManager was initially configured to store keys in memory.

 KeyManager "memory" {
        plugin_data {}

I made it to store at to keep it at disk

 KeyManager "disk" {
        plugin_data {
            keys_path = "%s/keys.json"
        }
    }

but still it is not optimal because it will be stored in any file
and i went through the docs of CNCF PARSEC

Sir I got two question.
1 . PARSEC not a library which we can use it in our code and compile it will run. it is a type of server(Deamnon) which is running(In Background). so will it not create deployment problem? How do we plan to package this? Do we bundle the parsec-service binary inside the Satellite Docker image, or do we expect the Host OS to strictly provide the running Parsec socket?
2>Standard Go TLS expects keys to be loaded from files or to implement the crypto.Signer interface... we cannot use standard functions like tls.LoadX509KeyPair.
this function

func LoadCertificate(certFile, keyFile string) (*tls.Certificate, error) {
	if _, err := os.Stat(certFile); os.IsNotExist(err) {
		return nil, ErrCertNotFound
	}
	if _, err := os.Stat(keyFile); os.IsNotExist(err) {
		return nil, ErrKeyNotFound
	}

	cert, err := tls.LoadX509KeyPair(certFile, keyFile)
	if err != nil {
		return nil, fmt.Errorf("%w: %v", ErrCertInvalid, err)
	}

	return &cert, nil
}

we need to refract this to make it compatible?