Chamber 🏰of Tech Secrets #52: Edge Device Onboarding

Living on the Edge Part II

The Chamber 🏰 of Tech Secrets is open!

---

Secure Edge Onboarding

Welcome to Living on the Edge Part II, where the goal is to go from zero to production with an edge computing environment.

First things first… we need to design an architecture where we can securely onboard devices into our lab environment… and this requires a significant lift! 🏋️‍♀️

---

📦 Plug it in and let’s go!

When a new edge device shows up in a box, it’s time to open it up, plug it in, and get excited!

We’ll need to use an approach often referred to as zero touch provisioning, meaning that we do not expect a skilled IT technician to be present to complete setup… we simply plug and play and the rest of the things take care of themselves.

Before we go too far down that road, what should we have already done?

• Secure Supply Chain: did the devices come from a trusted vendor? In my case, they came from my trusted friends at SimplyNUC. ✅

• Do you know where you are on the risk spectrum?: How risky is this environment and what security controls do we need to have in place? In my case, this is a home lab environment running non-critical applications and I will not allow for inbound web traffic (a best practice), so our risk profile is very low. That said, my purpose here is to explore the challenges of a true enterprise environment, so we’ll “over-engineer” a little for the sake of learning. If this device was going to a Google datacenter or a tactical application, it would need more rigor, perhaps even a custom TPM (what Google does). ✅

• Architecture & System Requirement: What is the environment’s architecture, including the network topology, hardware profile, and security requirements? My requirements are simply to learn and brute force through challenges with the help of AI, so ✅ 😀.

• Attestation Server & Certificate Authority: We will need an attestation server and CA that we can depend on. To learn more about how this works, check out Chamber 🏰 of Tech Secrets #50.

For a more complete and thorough analysis on the above topic, check out the recent blog post on Secure Device Onboarding from me and my friends at Edge Monsters.

---

A quick note: the flow we will describe is essentially the same that you would use in a full datacenter or cloud environment if you were a major provider like AWS or Google. The datacenter paradigm is essentially the same at the edge when it comes to establishing a secure and trusted environment, which is cool.

First Boot

Let’s get started!

On first-boot, our device will be configured to PXE boot into a minimal mode with the base code for facilitating the process of establishing trust, which we’ll dive into below. If all steps pass, the device will boot a complete, first-class image that allows it to participate in the “datacenter” environment it is present in.

What are those steps that must pass to establish trust? Enter the TPM.

What is a TPM?

Each of my edge devices is equipped with a special chip called a Trusted Platform Module (TPM). A TPM is a small hardware chip on a computer's motherboard that provides hardware-based security functions such as securely storing encryption keys, passwords, and certificates.

TPM Chip being placed on motherboard. Source Open Computing Project

TPMs help us establish what we call a “hardware root of trust”. What are the benefits of a TPM, you ask?

• Secure Physical Design: TPM chips are built to make physical attacks really hard. They're packaged in ways that protect against drilling, cutting, or probing. Some even have special coatings or sensors that detect if someone tries to open the chip — and if tampering is detected, the chip can zero out sensitive data.

• Internal Encryption: Sensitive data inside a TPM is encrypted within the chip itself. The keys never leave the TPM unencrypted, so even if someone somehow intercepts communications with the TPM, they can't grab the secrets it possesses.

• Limited Interfaces: TPMs have very strict, minimal ways you can interact with them. You can't just send random commands or dump memory.

• Independent, Isolated Execution: The TPM operates separately from the main CPU and memory, providing a highly secure environment for select operations such as creating key pairs or writing digital signatures.

Now that we understand what a TPM is and what value it adds, let’s get into the technical weeds on how to go about working with one.

Establishing Trust

Our goal is to establish trust. To do that, we need to start by ensuring the can trust our TPM chip itself, since it is at the root of everything that follows. If we trust something in the chain that has been compromised, we lose.

We then want to assert an identity (often called remote attestation) to the server in our environment that is responsible for new device onboarding and configuration. That trust process requires that we:

1. Prove that the TPM is trustworthy and has not been tampered with.

2. Prove that the device is trustworthy by having the TPM sign its configuration.

3. Prove that the device is in the intended boot state and has not been tampered with.

Only when these conditions area met will we consider an edge node to be trustworthy and allow it to run production workloads. Let’s dig into how these trust proofs work technically!

Endorsement Key

TPM’s are typically shipped with an embedded asymmetric key pair called an Endorsement Key (EK) pair. The private key in this pair lives inside the TPM and is never released or shared. 🔐 Typically, the device manufacturer will digitally sign the EK public key with their own certificate authority, producing an EK Certificate, which can be used to validate the “identity” of the TPM.

If we are able to validate the manufacturer’s signature wrapping our EK public key, we can be highly confident that the TPM is trustworthy for subsequent operations, given that we trust the manufacturer. This establishes our baseline level of trust.

The EK is extremely sensitive material and is at the root of our trust topology, so we will use it for the fewest operations possible to minimize risk.

Attestation Key

Next, we’ll generate a new asymmetric key pair in the TPM on the device called an Attestation Key (AK), which we use to assert the identity and state of our device in subsequent boots. The private key for the AK pair will stay locked away in the TPM forever 🔐. We can retrieve our AK public key from the TPM and use it in our next step.

Certificate Signing Request

On the edge device, we’ll also generate a Certificate Signing Request (CSR) for the Attestation Key (AK) pair. This operation will be orchestrated by our initialization software running in the minimal boot OS on the node, but the digital signature will take place within the TPM. Remember that the private keys generated in the TPM stay in the TPM.

Something like this…

When the attestation server (also acting as a Certificate Authority—whether cloud or local) validates the CSR, it confirms that the device controls the private key—stored inside the TPM and therefore safe—that was used to sign the request and can thus be trusted in subsequent operations.

A certificate request might look like something like this.

-----BEGIN CERTIFICATE REQUEST-----\nMIICVzCCAT8CAQAwYTELMAkGA1UEBhMCVVMxEzARBgNVBAoMCk15Q29tcGFueTEZMBcGA1UECwwQVHJ1c3RlZERldmljZXMxFzAVBgNVBAMMDlRQTURldmljZS1TRjEwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+JFiqqE0B5ZojHnKURD4AaScs5f4nPAV6/0KL7ldN3ojYK0ZIf5d6H5M5TK+lb7QKPr8mg+WECiSMgxxAnb9MZPVZReKpc6hivDWX4knsydJq1lB3nQ6TLh+EvRzSvupcDWBMI8Z7nNpiL6U5fRkQ1EMt+z9IM2f63D+nk7ePwiwIDAQABoAAwDQYJKoZIhvcNAQELBQADgYEAG1MTQJg2ct9tivlguXNRljIl6pRPYe5zEwFElU32v9s4rRWc5PXx4+/5N0ByNHX5l7z90a/bAFT9gnHKZ0ZhUkUIor4DLcycQ3HOj6LiwbI3xMklGMOMXnF9RUy5hYz5AdA12Pf8DklZW0tivBLrGbT3Wh7sbU5TZVa5upLfY8=\n-----END CERTIFICATE REQUEST-----

That’s a lot! Let’s do a quick recap. At this stage of the process, we have our Endorsement Key (EK) Pair and Endorsement Certificate. The EK Private Key is safely locked away in the TPM. We also have an Attestation Key (AK) Pair. The AK Private Key is also locked away in the TPM. Finally, we have our hands on a Certificate Signing Request for the AK so that we can prove this is a trusted device.

Measured Boot + PCR

Before the attestation server is willing to trust this device, it will need to make sure it is booting in the manner expected, once again ensuring there has been no tampering. This is where Measured Boot and Platform Configuration Registers (PCRs) come into play.

A device could have malware installed before shipping, so verifying boot integrity is critical for a secure edge environment.

What is Measured Boot?

In a “Measured Boot”, each component—BIOS, firmware, bootloader, kernel, etc.—measures itself (i.e., hashes its code) and stores the hash inside TPM registers called PCRs (Platform Configuration Registers).

Measured boots can be used to prohibit the release of material from the TPM in a process called credential sealing, which we’ll discuss in a future post.

Measured Boot can also be used by the attestation server verify that the device booted into a known, trusted state by checking a hash of the chain of PCR values against a previously established “golden” state stored on the server side.

Platform Configuration Registers (PCRs)

TPM chips have a small number of PCRs (typically 24). As the system boots, hash measurements from each stage are extended into specific PCRs. Each extension is cryptographic hash (likely SHA-256 or similar) of the previous values and the new value concatenated together, creating a tamper-evident chain.

Example PCRs:

• PCR 0–7: firmware and BIOS stages

• PCR 8–15: OS loader and OS measurements

• PCR 16+: Application measurements (not often used)

It is important to note that Measurement != Enforcement. In measured boot, we record what happened but do not block progress (that's called Secure Boot). These measurements give us a verifiable history of what code executed from power-on up to OS start.

Contacting the Attestation Server

Now we are ready to contact the attestation server and begin the process of onboarding the device.

The first request to the attestation server will be a simple nonce. For our purposes, we’ll send the device’s serial number in the request and the attestation server will send us a reply containing a random nonce. We do this to protect the server-side system from potential replay attacks.

HTTP Request: POST /nonce
Body: {"serialNumber":"SN9753124680"}

HTTP Response: 
Body: {
  "nonce": "f8a9d3b2e1c447d29f7be7a4e9623f75",
  "nonce_validity_seconds": 300,
  "attestation_server_time": "2025-04-26T20:00:00Z",
  "device_serial_number": "SN9753124680",
  "request_id": "9d4b03a1-0e29-4d7a-b6ea-c94b13eaf65f"
}

It is also important to ensure that the edge device is communicating with a legitimate attestation server before sending any sensitive onboarding data or taking configuration instructions.

Upon initial connection, the server will present its certificate, which the device can validate against the trusted Root CA certificate. We can provide this to the device at initial image time or in the minimal OS PXE-boot. This enables us to verify the identity of the attestation server and establish secure communications with TLS/HTTPS.

Finally, a secure (or perhaps measured if lower risk) boot on the edge device can validate that the PXE boot—discovered via DHCP—put the device in an expected state that is trustworthy.

Next, our edge device can request that the TPM create a quote, which includes a digest of select PCR values combined with our aforementioned Nonce, which is signed with the AK Private Key (trusted by the attestation server).

Next, we can send a bundled request to the attestation server including the following components:

• EK Certificate (EK Cert)

• AK Certificate Signing Request (CSR)

• PCR Quote (includes nonce)

• Device metadata

An HTTP request to the attestation server will look something like this…

HTTP REQUEST: POST /v1/attest
BODY
{
  "device_serial_number": "SN9753124680",
  "nonce": "f8a9d3b2e1c447d29f7be7a4e9623f75",
  "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMI....",
  "pcrQuote": "<<Base64-encoded TPM Quote Structure>>",
  "ek_certificate": "-----BEGIN CERTIFICATE-----\nM.....
}

Certificate Issuance

Our attestation server will field this request and validate the components of the payload…

• EK Certificate: Assess the EK Certificate to see who signed it (the manufacturer we hope). The server will validate the digital signature using the full certificate chain from the manufacturers root CA to confirm hardware provenance and trust. This certificate chain will need to be acquired from the manufacturer(s) out-of-band or on-the-fly at request time within the attestation server implementation.

• PCR Quote: Check the PCR values against the “golden” state values (computed previously out-of-band) to ensure there was no tampering, plus validate the Nonce that was issued to ensure the quote is appropriately recent.

• Device Metadata: Check device metadata against an out-of-band registry or store the device record in a database for future asset management purposes.

• CSR: Unpack the public key from the CSR and validate the digital signature. Additionally, we can validate other CSR fields such as serial number or MAC Address against a registry if desired.

The combination of these values tells the server that the TPM is trusted, that the AK private key is safe in the TPM, and that the device has booted into a trusted state. Under these circumstances, we consider the device trustworthy and can proceed with fulfilling the CSR by issuing an X.509 AK Certificate, which will represent the device’s identity ongoing.

Our attestation server will store the following device identity attributes in a database:

• Device serial number

• AK Certificate serial number

• AK Public Key fingerprint (useful for lookups, etc.)

• Certificate validity (not before, not after)

• Certificate PEM (optional)

• Device Status (active/revoked)

The edge device will store the issued AK Certificate on the file system (not inside the TPM).

Note that we can reissue new certificates for the device over time by repeating the attestation process. Device metadata can help deduplicate records across future attestations. This process may occur hourly, daily, or monthly—or perhaps every boot—depending on your security needs.

The AK certificate typically contains:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0x0d2341be3
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Local TPM Attestation CA, O=MyCompany, C=US
        Validity
            Not Before: Apr 26 12:00:00 2025 GMT
            Not After : Apr 27 12:00:00 2025 GMT
        Subject: CN=device-01234, O=MyCompany, OU=TrustedDevices, C=US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation
            X509v3 Extended Key Usage:
                1.3.6.1.5.5.7.3.9 (Custom for TPM attestation)
            1.3.6.1.4.1.45724.2.1.1 (TPM Manufacturer Info Extension - Optional)
    Signature Algorithm: sha256WithRSAEncryption
         <CA Signature bytes>

---

Additional Considerations

• Time matters ⏰: Before initial attestation, devices should sync with the local NTP server to ensure their time is accurate. If they have drifted meaningfully or been misconfigured, the nonce check is likely to fail.

• Human-in-the-loop 🧔: Do you want or need to know that a trusted person is present in the attestation sequence? If this is important for the environment, a protocol like FIDO with a YubiKey is a great solution. In this case, we can add an extra layer of cryptography to the equation prior to the initial release of the Attestation Key Certificate (AK Cert). This adds an extra level of trust, ensuring the device is in the presence of a trusted human.

A YubiKey in case you are not familiar

In my lab environment, I’ll implement the FIDO + YubiKey flow because… why not? Another opportunity to learn! I’ll use a simple NTP configuration since I do not have possession of highly accurate atomic clocks.

Conclusion

By completing all of these steps, we can ensure that an edge (or datacenter) server is completely trustworthy 🔐, has not been tampered with 🦹, and is running the configuration we desire (vs. something compromised) ✅ upon arrival.

We also learned how the incoming device can ensure it is talking to a legitimate attestation server.

Massively simplified process

We are now one step closer to being ready for the next steps of device configuration and enterprise application workloads. 🚀

This was a lot, so we’ll circle back next time to discuss TPM-based Credential Sealing with Measured Boot. Leave a comment if this is helpful and if you would like to see the code and the command by command breakdown for how this works. Cheers!