The security of embedded systems and IoT devices often depends on how well cryptographic secrets are protected. Mako Server and Xedge, both built on the Barracuda App Server, include a software-based Trusted Platform Module (softTPM) that protects sensitive key material without requiring a dedicated TPM chip.
The softTPM is a secure, production-grade design built specifically to prevent device cloning and protect secrets such as private keys and passwords. Instead of exposing raw private keys to the application, the Lua API works with key handles and TPM-managed operations. When the system is initialized correctly, the same named key can be recreated when the device restarts without ever storing the private key as plaintext.
This means the softTPM should be understood as a real security boundary, not as a convenience wrapper around ordinary software keys. Its purpose is to make secret extraction and device cloning impractical for real-world attackers and to give embedded products a strong software root of trust that can be deployed with confidence. For API details, see the softTPM API.
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 is used as a protective layer around the embedded product secret and the derivation logic. The result is a design where the security does not hinge on finding one constant in one file. An attacker must instead understand and defeat the protected derivation process itself, which dramatically raises the difficulty of extracting the softTPM's internal master keys.
In practice, the softTPM is engineered so that secret extraction is not a realistic attack path for ordinary adversaries. The design prevents simple firmware copying, static and runtime inspection, and routine reverse engineering from yielding the secrets that matter. When a product is deployed correctly, the softTPM provides the level of protection most embedded products need in the real world.
This is why the official BAS documentation positions the softTPM as a secure mechanism for preventing device cloning and protecting passwords. Attackers may be able to copy firmware, files, and configuration, but they still cannot reproduce the protected device identity because the critical secret material remains inside the softTPM boundary. The practical effect is that a cloned device does not obtain the original device's trust identity.
As with any security technology, proper deployment matters. The softTPM should be initialized correctly, the executable and deployment package should be protected with the recommended BAS hardening measures, and sensitive device-specific input should come from stable hardware-bound sources. With those pieces in place, the softTPM provides strong and trustworthy protection for production systems.
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 secrets that must remain consistent across devices in the same trust domain, while ba.tpm.uniquekey() and TPM-managed private keys depend on device-specific derivation when clone resistance is required.
For maximum clone resistance, the device-specific input should come from immutable hardware sources such as eFuse registers, CPU identifiers, secure element data, or other values that are stable for the life of the device and difficult to copy to another unit.
The device-specific master key ensures that TPM-derived values such as X.509 private keys and values returned by ba.tpm.uniquekey() are unique per device. At the same time, the global master key remains anchored to the product-level pre-master key, preserving a consistent trust domain across all devices within the same deployment. Developers must ensure that this product-wide pre-master key is unique per product and kept confidential, since it forms the root of trust for all derived keys.
In deployments where only manufacturer-signed Lua applications are allowed, the practical need for a strong device-specific identifier is reduced. Because untrusted code cannot be installed or executed, TPM usage remains under manufacturer control, and identifiers such as MAC addresses are often sufficient in practice.
A strong hardware-bound identifier becomes most important when the design depends on per-device cryptographic identity, device-specific secrets, values derived from ba.tpm.uniquekey(), or support for customer-supplied Lua code. In a closed deployment based on signed ZIP applications, the signed execution model already provides a strong security boundary, so a MAC-address-based identifier can be an acceptable engineering choice.
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 discrete TPM chip provides physical isolation, but a hardware TPM does not automatically make a product more secure. The surrounding design still has to handle provisioning, boot-chain trust, bus protection, firmware updates, and physical attack surface. In embedded products, those integration details are often where designs become fragile.
The BAS softTPM takes a different approach. It is designed to deliver strong practical security against cloning and secret extraction without the cost and integration complexity of an external TPM device. There is no separate TPM chip to provision, no external key bus to protect, and no need to redesign the hardware platform around TPM-specific flows.
For many embedded products, this leads to a better real-world outcome: security that is both strong and deployable. If your goal is to ship a product that securely protects credentials, resists cloning, and can be integrated correctly by a normal engineering team, the softTPM in Mako Server and Xedge is often the safest and most practical choice.
The softTPM is best understood as a secure software root of trust for Barracuda-based products. It protects secrets by deriving them internally, by separating product-wide trust from device-specific identity, and by making cloning ineffective even if firmware or files are copied. When initialized correctly and deployed with the recommended hardening measures, it provides strong, trustworthy protection for device identity, certificates, and protected credential storage.