The security of an embedded system often depends on how it stores and derives cryptographic secrets. Mako Server and Xedge, both built on the Barracuda App Server, include a software-based Trusted Platform Module (softTPM). It provides named key derivation and key-handle APIs without requiring a separate TPM chip.
Instead of storing an exportable private-key file, an application can refer to a named key and ask the softTPM to recreate the corresponding key material after restart. This can reduce accidental exposure and make copied application files insufficient by themselves to reproduce a device identity. For API details, see the softTPM API.
Security boundary: The softTPM is software running in the same device environment as the application. Its protection depends on the confidentiality of the product secret, the quality of the device-specific input, firmware integrity, access controls, and the attacker's capabilities. It is not a substitute for hardware-backed isolation when the threat model includes invasive physical attacks, arbitrary privileged code execution, or complete extraction and analysis of the running system.
The softTPM does not depend on a single static secret stored directly in the binary. Instead, it derives its internal trust anchors at startup from multiple inputs. One input is product-wide and shared by all devices in the same product line or deployment. The other input can be device-specific, making the resulting secrets unique per device.
White-box cryptography can be used as a protective layer around the embedded product secret and derivation logic. This is intended to make static extraction more difficult than reading an unprotected constant from a file or firmware image. The amount of protection depends on the complete product design and must be assessed against the product's threat model.
The softTPM is designed to address accidental disclosure, copied application data, and straightforward firmware cloning. It can bind derived values to device-specific input so copying the same files to a different device does not necessarily reproduce the same keys.
It does not by itself provide secure boot, firmware integrity, process isolation, anti-debugging, or resistance to every physical or runtime attack. Use the platform's secure boot, signed update, privilege separation, debug-port control, and storage protections when those controls are available.
Before deployment, document the expected attacker access, the source and stability of the device identifier, how the product-wide secret is installed, and how compromised devices or product secrets will be handled. Products subject to regulatory requirements or high-value physical attacks should receive a product-specific security review.
After initialization, the softTPM derives two internal master keys:
This distinction is important because the two key classes serve different purposes. Functions such as ba.tpm.globalkey() are intended for values that must remain consistent across devices initialized with the same product secret. The same API section documents ba.tpm.uniquekey(), which incorporates device-specific derivation.
When the design requires device-bound values, use stable input from a source that matches the threat model, such as eFuse data, a hardware unique key, or a secure-element identity. A public or easily copied identifier may distinguish devices operationally but should not be treated as a secret.
When initialization supplies suitable device-specific input, TPM-derived values such as X.509 private keys and values returned by ba.tpm.uniquekey() differ between devices. The global master key remains anchored to the product-level pre-master secret. Keep that secret confidential and use a different value for each product trust domain.
Signed application packages can reduce the risk of unauthorized application code, but they do not make a public identifier secret or hardware-bound. A MAC address may be acceptable when the value is used only as a stable device label and the threat model permits cloning. Do not rely on it alone when the derived key is expected to prove that it belongs to one physical device.
To learn more about signing applications, see Signed and Encrypted ZIP files.
The softTPM is initialized in C code during system startup. Your startup code must combine a confidential product-wide pre-master secret with a stable device-specific value before Lua code starts using the TPM API. The product-wide secret establishes the shared trust domain for the product, while the device-specific value ensures that device-bound secrets differ from one unit to another.
Once initialization is complete, Lua code can create or recreate TPM-managed keys by name. The application refers to these keys through handles such as those used by ba.tpm.createkey(), while the softTPM derives the actual key material internally. This is what allows the same key handle to resolve to the same private key after a restart without storing the private key itself as an exportable file.
In practice, correct initialization comes down to four rules:
See the product-specific initialization examples for complete C startup guidance:
A hardware TPM or secure element can isolate private keys from the main application processor and may provide tamper resistance, protected counters, attestation, or certified security properties. It also adds provisioning, driver, hardware, and lifecycle requirements.
The BAS softTPM avoids the extra component and uses the existing device software environment. It is suitable when software-based derivation matches the product's threat model and when the platform can adequately protect the firmware, product secret, and device-specific input.
Choose hardware-backed protection when private keys must remain unavailable even to privileged application software, when physical extraction is in scope, or when a customer or certification scheme requires hardware isolation. Choose the softTPM when its stated assumptions and limitations are acceptable for the product.
The softTPM derives named keys from product-wide and optional device-specific inputs, which avoids storing those derived keys as ordinary plaintext files. Its effectiveness depends on initialization, platform protections, and the deployment threat model. Treat it as one part of the product's security design, not as a replacement for secure boot, TLS, access control, or hardware-backed key storage when those controls are required.