Trusted execution environments are only as trustworthy as their hardware boundary
Security architects and platform engineers at cloud providers, semiconductor IP vendors, and regulated-industry operators face a structural gap in confidential compute: existing trusted execution environments rely on CPU microcode and firmware that remain vulnerable to side-channel attacks, supply-chain compromises, and hypervisor-level breaches.
Software-only confidential compute stacks cannot cryptographically attest the physical hardware boundary. When the attestation service itself runs on writeable, patchable firmware, any attacker who can modify that firmware can forge attestation claims — exactly the failure mode that exposed key material in the supply-chain incident that motivated Bastionchip's founding.
The core problem is not algorithmic weakness — AES-256-GCM and ECDSA P-384 are sound. The problem is that the code implementing those algorithms runs on processors with writeable memory paths, shared register files accessible to speculative execution, and firmware update mechanisms that accept third-party signed images. None of those properties can be eliminated in software.
Bastionchip's approach is to move key derivation and all cryptographic execution inside a tamper-evident on-chip enclave where no software path — including firmware updates, debug interfaces, or hypervisor calls — can read key material or substitute the chip identity.
From key handle to sealed ciphertext in silicon
Bastionchip integrates as a PCIe x4 or M.2 co-processor alongside the host CPU. All cryptographic state stays inside the on-chip boundary.
SDK connection and key handle delivery
The integrating application connects via the Bastionchip SDK (C/C++ or Rust bindings) over a PCIe x4 or M.2 interface. The application passes plaintext workload metadata and sealed key handles to the chip. The SDK handles bus communication, attestation refresh, and key-handle lifecycle management; application code interacts through standard PKCS#11 or OpenSSL engine interfaces without modification.
On-chip cryptographic execution inside the tamper-evident enclave
The on-chip secure enclave performs hardware-rooted key derivation using a masked PUF seeded at wafer fabrication. The PUF response is never stored — it is reconstructed on demand by the on-chip fuzzy extractor each time a key derivation is requested. All cryptographic operations (AES-256-GCM, ECDSA P-384, SHA3-512) execute within the tamper-evident boundary using hardware accelerators written in synthesizable RTL with no shared-register paths to general-purpose CPU logic. Remote attestation packets are signed by an immutable ROM key fused at manufacturing time — a key that never traverses a bus or lands in writeable storage.
Sealed ciphertext bundles with embedded attestation receipts
The chip returns sealed ciphertext bundles with embedded attestation receipts. These outputs are cryptographically bound to the specific chip identity via the PUF-derived key — a sealed package can only be decrypted by a chip whose attestation passes the caller-defined policy. Bulk AES-256-GCM throughput exceeds 2 GB/s; ECDSA P-384 signing completes in 18 microseconds, constant-time regardless of key material. The output is immediately usable by cloud-native confidential containers or on-prem secure enclaves without additional transformation.
Six hardware-enforced security primitives
Each capability derives from on-chip hardware. None rely on software policy, firmware state, or external service availability.
Masked PUF Root of Trust
Chip identity derived from wafer-level silicon entropy — unforgeable by design. Every Bastionchip ASIC carries a physically unclonable function (PUF) generated from intrinsic manufacturing variation during wafer fabrication. The PUF response is never stored — it is reconstructed on demand by the on-chip fuzzy extractor. No two chips share an identity, and no adversary with physical access to the board can extract or clone the key material. This eliminates the battery-backup and tamper-detection complexity of traditional FIPS 140-3 Level 4 HSMs.
Remote Attestation with ROM Anchor
Cryptographic proof of chip authenticity, delivered in under 500 microseconds. The Bastionchip attestation flow signs a freshness nonce and chip-state digest with an ECDSA P-384 key fused into read-only ROM at manufacturing time. Relying parties can verify the attestation certificate chain back to Bastionchip's offline root CA without trusting the host operating system, hypervisor, or cloud control plane. Attestation latency is under 500 microseconds — below the threshold of user-perceptible delay in connection establishment protocols.
18 µs ECDSA P-384, constant-time
Crypto-Accelerated Secure Enclave
2 GB/s bulk encryption with constant-time ECDSA — no leakage surface. All symmetric and asymmetric cryptographic operations execute inside the tamper-evident on-chip enclave using hardware accelerators written in synthesizable RTL with no shared-register paths to general-purpose CPU logic. AES-256-GCM bulk throughput exceeds 2 GB/s at 4W TDP. ECDSA P-384 signing completes in 18 microseconds, constant-time regardless of key material, eliminating the Spectre/Meltdown-class timing-oracle surface present in software TEE implementations.
PKCS#11 & OpenSSL Engine SDK
Drop-in integration for existing PKI and secrets-management infrastructure. Bastionchip ships a production-grade PKCS#11 provider and an OpenSSL engine that allow existing applications — TLS termination, code-signing pipelines, HSM-backed certificate authorities — to offload key operations to the chip without rewriting application code. Developers interact through standard cryptographic interfaces; the SDK handles bus communication, attestation refresh, and key-handle lifecycle management transparently.
Sealed Workload Packaging
Encrypt and bind container images or ML model weights to a specific chip identity. The Bastionchip sealing API encrypts arbitrary blobs — container filesystems, ONNX model weights, database snapshots — under a key derived from the chip's PUF response combined with a caller-defined policy digest. The ciphertext can only be decrypted by a chip whose attestation passes the policy, preventing data exfiltration even if a sealed package is stolen, copied to another machine, or submitted to a cloud provider's forensics pipeline.
Cloud-Native Confidential VM Integration
First-class AMD SEV-SNP and Intel TDX co-processor mode — validated on major clouds. Bastionchip operates as a hardware co-processor alongside AMD SEV-SNP and Intel TDX confidential VMs, extending the hardware trust boundary to persistent key storage and bulk crypto offload. The chip communicates over PCIe with the confidential VM's virtual IOMMU protected DMA domain. Tested and validated on AWS EC2 c7g Nitro enclaves and Azure DCsv3 confidential VMs; reference architecture guides available for each platform.
Tested integrations
Bastionchip has validated interoperability with the following confidential compute platforms and secrets management systems.
Designed for a specific buyer — not for everyone
Bastionchip is a specialized component for infrastructure teams with defined hardware security requirements. If you don't need hardware-enforced key isolation, a software-only TEE is probably the right choice.
Cloud infrastructure companies
Senior security architects and platform engineering leads at cloud-native infrastructure companies building confidential compute services, HSM-backed certificate authorities, or hardware-attested key management systems.
Regulated financial and government operators
Mid-size regional financial institutions managing HSM fleets and defense or government contractors with FIPS 140-3 Level 3+ requirements who need cryptographic attestation of the physical hardware boundary.
Semiconductor IP licensors
Series A through Series C infrastructure companies and semiconductor IP vendors integrating hardware security into their platform products for downstream customers requiring verifiable hardware identity.
Ready to evaluate the ASIC?
Engineering samples are available for qualified design partners. Contact us to discuss your confidential compute requirements and integration timeline.