Electronics Guide

Articles in This Category

The Privacy Challenge

Modern computing concentrates sensitive data in places where its owner does not control the underlying machine. Cloud computing places workloads on shared servers operated by third parties. Machine learning depends on large datasets that frequently contain personal information. Cross-organization collaborations, such as fraud analysis among banks or joint medical studies among hospitals, must combine data while respecting strict confidentiality and regulatory boundaries set by frameworks like the General Data Protection Regulation and the Health Insurance Portability and Accountability Act. In all of these settings, the long-standing protections for data at rest and data in transit leave the processing stage unguarded.

The threat model that motivates these technologies is broad. It includes not only external attackers but also privileged insiders and the infrastructure operator itself. A cloud tenant may need assurance that a malicious or merely curious administrator cannot read the data being computed, and that the code running on the server is genuinely the code that was deployed. Meeting that bar requires moving trust away from the operating system and the operator and anchoring it either in the silicon, through hardware isolation and attestation, or in mathematics, through cryptography that keeps data encrypted even during computation. The practical appeal is that a contractual promise not to look at customer data is replaced by a technical control that makes looking infeasible.

Two distinct risks hide behind the single word "privacy," and confusing them leads to poor designs. The first is unauthorized access: someone reads a value that should have remained secret. Enclaves and encrypted computation address that risk. The second is inference: an adversary reconstructs facts about an individual from results that were themselves legitimately released, such as aggregate statistics or the parameters of a trained model. No amount of isolation prevents this, because the leak travels through the output rather than around the protection. Statistical methods such as differential privacy exist precisely to bound that second risk, and a complete system usually needs measures from both categories.

Hardware-Based Isolation

Trusted execution environments enforce confidentiality and integrity in hardware. The Confidential Computing Consortium, the Linux Foundation project that coordinates this field, defines confidential computing as the protection of data in use by performing computation in a hardware-based, attested trusted execution environment, and it frames the guarantee in terms of three properties: data confidentiality, data integrity, and code integrity. In practice this means unauthorized parties cannot read the protected data, cannot tamper with it, and cannot alter the code that operates on it, even if they control the rest of the system.

Enclaves and Confidential Virtual Machines

Implementations differ in the granularity of what they protect, and that choice determines the size of the trusted computing base. Process-level designs such as Intel Software Guard Extensions (SGX) carve out a small enclave inside a single application. The trusted code can be reduced to a few thousand lines, but the application must be partitioned so that secrets never cross the enclave boundary in the clear, which is intrusive engineering work. Intel deprecated SGX on client platforms and continues to support it on Xeon server processors, where it also hosts the quoting enclave that signs attestation evidence for newer technologies.

Virtual-machine-level designs instead encrypt and isolate an entire guest. AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) extends the earlier generations of SEV, which encrypted guest memory and register state, by adding integrity protection against a malicious hypervisor that remaps or replays memory pages. Intel Trust Domain Extensions (TDX), introduced with the fourth-generation Xeon Scalable processors, places the guest in a trust domain managed by an authenticated firmware module rather than by the host hypervisor. Arm Confidential Compute Architecture (CCA) takes a comparable route in the Arm ecosystem: the Realm Management Extension of Armv9-A adds a fourth security state, so that Normal, Secure, Root, and Realm worlds coexist and confidential workloads run in Realms that the normal-world hypervisor schedules but cannot inspect.

In every case a memory-encryption engine in the memory controller enciphers DRAM contents with keys generated inside the processor and never exposed to software, so that physical attacks on the memory bus or cold-boot recovery of DIMM contents yield ciphertext. Confidential virtual machines accept a larger trusted computing base, since the guest operating system sits inside the protected boundary, in exchange for running existing software with little or no modification. That property is what made them the basis of the confidential VM instances now offered by the major cloud providers, while enclave-style isolation remains attractive where the secret is small and well contained, such as a key-management service or a signing oracle.

Remote Attestation

Remote attestation is what makes these guarantees verifiable rather than merely asserted. Before entrusting data to a protected environment, a relying party requests a hardware-signed measurement, typically a cryptographic hash of the code, firmware, and configuration loaded inside it, together with the security version numbers of the underlying microcode. The party checks that signature against the processor vendor's certificate chain and compares the measurement with a reference value it computed independently. Only when both checks pass does it release secrets, such as decryption keys or model weights, into the environment. This key-release pattern is the standard way to bind confidential data to a specific, verified workload, and it depends on the same primitives described under remote attestation systems and key management systems.

Confidential Accelerators

Protecting the processor alone is insufficient when the valuable computation runs on an accelerator. Machine learning workloads move data across the PCI Express bus to graphics processors, so an isolation boundary that stops at the CPU leaves training and inference exposed. NVIDIA introduced confidential computing in the Hopper generation, giving the H100 a hardware trusted execution environment in which the GPU boots in a mode that encrypts its memory, refuses debug access, and produces its own attestation report that a relying party checks alongside the host attestation. Blackwell-generation parts extend this with support for trusted I/O, allowing encrypted data to move between a confidential virtual machine and the accelerator, and across NVLink between accelerators, without an intervening decryption step. The result is an attested boundary that spans the host and the accelerators rather than stopping at the socket, which matters for the workloads described under artificial intelligence hardware.

Limits of Hardware Trust

The principal limitation of hardware isolation is that the processor vendor, its firmware, and its manufacturing supply chain all become part of the trusted base. A flaw in an attestation key hierarchy or a compromised signing key undermines every deployment at once. Researchers have also repeatedly demonstrated attacks that extract secrets without breaking the isolation directly: transient-execution attacks such as Foreshadow that recover enclave data through speculative side effects, fault-injection attacks such as Plundervolt that corrupt enclave computation by manipulating the processor's voltage regulator, and ciphertext side channels that exploit deterministic memory encryption to observe patterns in encrypted guest memory. Vendors respond with microcode updates, revised security version numbers, and randomized or address-tweaked memory encryption, and attestation exists partly so that a relying party can refuse to trust a platform whose patch level is known to be vulnerable. Defensive circuit and microarchitectural techniques are treated in detail under side-channel attack prevention.

Cryptographic Computation on Protected Data

Where hardware isolation keeps data secret by enclosing it, cryptographic techniques keep data secret by never decrypting it. The guarantees rest on mathematical hardness assumptions rather than on a vendor's silicon, which removes the processor manufacturer from the trusted base. The price is performance: every one of these methods costs far more than the equivalent plaintext computation, and the engineering effort in the field concentrates on closing that gap.

Fully Homomorphic Encryption

Fully homomorphic encryption (FHE) allows arbitrary computation directly on ciphertexts, producing an encrypted result that, once decrypted, matches the result of performing the same operations on the plaintext. Practical schemes are built on lattice problems, and they fall into families suited to different data: BGV and BFV perform exact arithmetic on modular integers, CKKS performs approximate arithmetic on real and complex numbers and therefore suits machine learning, and torus-based schemes in the CGGI family evaluate boolean circuits and look-up tables with fast programmable bootstrapping.

The central obstacle common to all of them is noise. Lattice ciphertexts carry a small random error that grows with every operation, sharply so with multiplication, and once it exceeds a threshold set by the scheme's parameters the ciphertext no longer decrypts correctly. A procedure called bootstrapping refreshes a ciphertext by homomorphically evaluating its own decryption circuit, reducing the noise and permitting unlimited further computation. Bootstrapping is by far the most expensive operation in FHE and is the main reason these schemes remain several orders of magnitude slower than computing on plaintext. Ciphertext expansion compounds the problem. A single encrypted value occupies kilobytes at the small parameter sets used for shallow, leveled computations, and grows to megabytes, or tens of megabytes, at the deep-circuit parameters that bootstrapped workloads require; the evaluation keys that support rotation and relinearization are larger still. Reducing that overhead is the aim of the specialized polynomial and number-theoretic transform units covered under homomorphic encryption hardware, and of the wider study of arithmetic for cryptography.

Secure Multi-Party Computation

Secure multi-party computation (MPC) lets several parties jointly evaluate a function over their combined inputs while each input stays private to its owner. Foundational constructions include garbled circuits, in which one party encrypts a boolean circuit that another evaluates without learning the intermediate wire values, and secret sharing, in which each value is split into shares distributed among the participants so that no share, and no subset below a defined threshold, reveals anything. Oblivious transfer underpins both, allowing a receiver to obtain one of several values without the sender learning which.

The performance profile of MPC differs sharply from that of FHE. Local computation is comparatively cheap, but protocols exchange large volumes of data and often proceed in rounds, so bandwidth and network latency dominate. A protocol that runs briskly among servers on a local network may slow by orders of magnitude across a wide-area link. Practical deployments therefore favor constant-round protocols, preprocess correlated randomness offline so that the online phase is fast, and choose a security model deliberately: protocols secure against semi-honest adversaries, who follow the protocol but try to learn more, cost far less than protocols secure against malicious adversaries, who may deviate arbitrarily. Private set intersection, in which parties learn only the elements they hold in common, is the most widely deployed application and appears in contact discovery, advertising measurement, and watch-list screening. The topic is developed further under secure multi-party computation.

Zero-Knowledge Proofs

Zero-knowledge proofs let a prover convince a verifier that a statement is true while revealing nothing beyond its truth. Succinct non-interactive variants are the ones that matter in practice: zk-SNARKs produce very small proofs that verify in milliseconds, at the cost of a structured reference string that many constructions obtain through a trusted setup ceremony, while zk-STARKs rely only on hash functions, avoid trusted setup, and are believed to resist quantum attack, in exchange for larger proofs. Bulletproofs occupy a middle ground with no trusted setup and short proofs but slower verification.

The defining property is asymmetry. Proof generation is expensive and is bottlenecked by two operations, the number-theoretic transform used for polynomial multiplication and multi-scalar multiplication over elliptic-curve points, both of which operate on field elements of 256 bits or more that map poorly onto general-purpose datapaths. Verification, by contrast, is deliberately cheap and nearly constant time. That asymmetry is what makes the technique useful: a heavyweight prover runs once, and any number of verifiers check the result quickly. Applications extend well beyond the blockchain scaling and privacy work described under decentralized infrastructure, reaching regulatory attestation, credential systems that prove eligibility without disclosing identity, and verifiable outsourced computation. Hardware acceleration and circuit design are covered under zero-knowledge proof systems.

Statistical Privacy and Data Minimization

Isolation and encrypted computation control who may read an input. Neither prevents a legitimate output from betraying its inputs. Aggregate statistics can be differenced to isolate an individual record, and trained models can memorize and later regurgitate rare training examples. Differential privacy addresses this directly by adding calibrated random noise to a computation so that the presence or absence of any single record changes the distribution of outputs only within a bounded factor. The bound is expressed by a privacy loss parameter, and the resulting guarantee composes predictably across repeated queries, which allows a system to budget its total disclosure over time. The United States Census Bureau applied differential privacy to the published statistics of the 2020 decennial census, the largest deployment of the method to date, and the National Institute of Standards and Technology published guidelines for evaluating differential privacy guarantees as Special Publication 800-226 in March 2025.

Federated learning attacks the same problem from the architectural side by keeping raw data on the device that produced it and exchanging only model updates. On its own this is a weak guarantee, since gradients leak information about the examples that produced them, so serious deployments combine it with secure aggregation, an MPC protocol that lets a server learn the sum of many client updates without seeing any individual one, and with differential privacy applied to the aggregate. Synthetic data generation and careful de-identification serve related roles. The general lesson is that these techniques compose: an enclave or an MPC protocol protects the inputs, and a differential privacy mechanism bounds what the sanctioned output reveals.

Choosing Among the Approaches

The approaches are not interchangeable, and the choice among them follows from the trust model and the performance budget rather than from any ranking of cryptographic strength. Hardware isolation offers near-native speed for compute-bound work, with the largest penalties falling on input-output-intensive and memory-bandwidth-bound code, and it runs unmodified software. Its guarantee, however, depends on trusting a specific vendor's implementation against an adversary with physical access and a long history of published side channels. FHE and MPC make no such assumption, resting instead on hardness assumptions that are independent of any manufacturer, but they impose overheads that rule out many workloads outright and demand that algorithms be expressed as arithmetic or boolean circuits.

The number of participants and the shape of the trust relationship matter as much as raw throughput. A single data owner outsourcing computation to an untrusted server is the natural case for FHE or an attested enclave. Several mutually distrustful owners who must compute over their combined data is the natural case for MPC, where the security model can be chosen so that no single party, and no coalition below a threshold, learns anything. A party that must convince others of a fact without disclosing the evidence is the case for zero-knowledge proofs. Hybrid designs are increasingly common, and often outperform any pure approach: an enclave can host an MPC party to reduce the number of rounds, a zero-knowledge proof can certify that an enclave executed the agreed computation, and an FHE evaluation can be paired with a proof that the server applied the correct function. Long-horizon deployments must also account for the migration to quantum-resistant cryptography, which affects the key-exchange and signature layers around these systems even where the core primitives, being lattice- or hash-based, are already believed to be quantum-safe.

Standards, Programs, and Ecosystem

Standardization has moved from academic proposals toward formal specification. The Confidential Computing Consortium maintains the common definitions and hosts much of the open-source software stack that makes attested environments usable, including runtimes, attestation verification services, and software development kits. The National Institute of Standards and Technology runs a privacy-enhancing cryptography project that tracks fully homomorphic encryption, multi-party computation, zero-knowledge proofs, and private set intersection, alongside its differential privacy guidance. In the international standards bodies, ISO/IEC 18033-6:2019 specifies partially homomorphic encryption mechanisms, and the multipart ISO/IEC 28033 series, under development, addresses fully homomorphic encryption with separate parts for general concepts, exact modular arithmetic, approximate arithmetic, and look-up table evaluation.

Public research funding has targeted the performance gap directly. The Defense Advanced Research Projects Agency's Data Protection in Virtual Environments program funded application-specific accelerator designs from teams led by Duality Technologies, Intel, SRI International, and Galois, with the stated aim of reducing homomorphic computation time by several orders of magnitude and bringing encrypted workloads within roughly one order of magnitude of the same computation on plaintext. Whether that target is met in commercial silicon remains an open question, but the program shaped a generation of accelerator architectures. Broader cryptographic specification work is surveyed under cryptographic standards.

Applications and Outlook

These technologies enable applications that confidentiality requirements would otherwise block. Hospitals can pool data for medical research without exposing individual patient records. Banks can detect fraud and money-laundering patterns that only become visible across institutions, without disclosing their customers' transactions to one another. Advertisers and publishers can measure campaign effectiveness through private set intersection rather than by exchanging identifiers. Organizations can fine-tune or query machine learning models on sensitive data while keeping both the data and, in some deployments, the proprietary model weights protected from the infrastructure operator. Each domain tends to favor a different tool: trusted execution environments where near-native performance matters, multi-party computation and homomorphic encryption where the strongest cryptographic guarantees are required, zero-knowledge proofs where one party must prove compliance or correctness without revealing the underlying records, and differential privacy wherever aggregate results are published.

The broader significance is a shift in where trust resides. Cloud customers can obtain cryptographic evidence that their workloads run in a genuine, unmodified secure environment, and collaborating parties can compute together without designating any one of them, or any central authority, as trusted. Significant obstacles remain. Performance still excludes many workloads, the tooling demands cryptographic expertise that few engineering teams have, side-channel resistance is an ongoing arms race rather than a solved problem, and attestation evidence is difficult for a non-specialist to evaluate. Even so, the direction of travel is clear: confidential virtual machines and confidential accelerators are now routine cloud products rather than research demonstrations, and privacy-preserving techniques are increasingly treated not as optional safeguards but as the default foundation for trustworthy data processing.

About This Category

The subcategories above examine each pillar in depth: the hardware isolation and attestation mechanisms of trusted execution environments, the arithmetic accelerators behind homomorphic encryption hardware, the protocols and deployments of secure multi-party computation, and the proving systems and circuits of zero-knowledge proof systems.

Readers approaching from the security-engineering side will find complementary material under security hardware, particularly confidential computing, cryptographic hardware implementation, and encrypted storage devices, which together cover the protection of data at rest and in transit that these technologies extend to data in use.

Related Topics