Trusted Execution Environment (TEE)

A TEE creates a strict physical separation between the secure world and the normal world. The CPU enforces this boundary at the hardware level, ensuring that processes running in the untrusted operating system cannot read or write to the TEE's protected memory region. This isolation is critical for protecting cryptographic keys and sensitive code from malware or a compromised OS.

• Secure World: Runs the Trusted Application (TA) and a lightweight Trusted OS.
• Normal World: Runs the standard Rich OS (e.g., Linux, Android).
• Mechanism: Bus-level access controls and memory firewalls prevent unauthorized access.

Remote attestation is the cryptographic process that proves a TEE's identity and integrity to a remote party. The TEE generates a verifiable attestation report signed by a hardware-derived key, containing a hash of the code and data loaded inside the enclave. This allows a client to verify that the TEE is running unmodified, trusted software on genuine hardware before sending secrets.

• Goal: Establish trust in a remote, untrusted machine.
• Key Component: A hardware root of trust that anchors the signature chain.
• Use Case: A bank verifies a fraud detection enclave is running the correct model before uploading sensitive transaction data.

TEEs automatically encrypt and integrity-protect data while it resides in off-chip memory (e.g., DRAM). This prevents physical attacks like cold-boot attacks or bus snooping. The memory encryption engine is transparent to the application inside the TEE but ensures that any data evicted from the CPU cache is ciphertext to an external observer.

• Confidentiality: Data in RAM is encrypted with a hardware-managed key.
• Integrity: Cryptographic hashes detect tampering or replay attacks on memory.
• Performance: Modern CPUs optimize this with dedicated AES-XTS engines to minimize latency.

Sealed storage allows a TEE to encrypt data and bind it to a specific enclave's identity and the platform's hardware state. The data can only be decrypted by the exact same enclave code on the exact same device. This protects data at rest even if the storage medium is stolen or the OS is compromised.

• Sealing Policy: Binds data to the enclave's measurement (MRENCLAVE) or the signing authority (MRSIGNER).
• Anti-Rollback: Integrates with hardware monotonic counters to prevent restoring old, vulnerable data.
• Example: A fraud model's proprietary weights are sealed to the TEE, making them unreadable outside the secure enclave.

A TEE dramatically reduces the Trusted Computing Base compared to a full operating system. The TCB includes only the TEE's hardware, the thin Trusted OS, and the specific Trusted Application. The massive, bug-prone rich OS and hypervisor are excluded from the trust boundary, shrinking the attack surface to kilobytes of auditable code.

• Contrast: A Linux kernel has millions of lines of code; a TEE's secure kernel may have tens of thousands.
• Verification: A small TCB enables formal mathematical verification of security properties.
• Impact: A vulnerability in the host OS does not compromise the TEE's secrets.

Modern TEEs include hardware and software defenses against microarchitectural side-channel attacks (e.g., Spectre, Meltdown, cache-timing). While not perfectly impervious, TEEs are designed to eliminate high-bandwidth leakage channels by partitioning cache resources, disabling simultaneous multithreading for secure cores, and using constant-time cryptographic algorithms.

• Threat: An attacker in the normal world probes shared CPU caches to infer TEE data.
• Defense: Cache partitioning (e.g., Intel CAT) and transactional memory integrity.
• Evolution: Continuous microcode updates and hardware revisions harden against newly discovered speculative execution vulnerabilities.

A decentralized machine learning paradigm where a shared global model is trained across multiple institutions without centralizing raw data. In financial fraud detection, banks collaboratively train a model on their local transaction ledgers, sharing only encrypted model updates (gradients) with a central server. This allows the consortium to detect cross-institutional fraud patterns while ensuring that individual customer transactions never leave the originating bank's secure perimeter.

A cryptographic scheme that enables computation directly on ciphertexts, producing an encrypted result that decrypts to the correct plaintext output. In fraud analytics, a model can perform inference on a fully encrypted transaction payload without ever seeing the raw data. Fully Homomorphic Encryption (FHE) supports arbitrary computations but incurs significant computational overhead, while Partially Homomorphic Encryption (PHE) supports only specific operations (e.g., addition) with practical latency for real-time scoring.

A cryptographic protocol allowing multiple parties to jointly compute a function over their private inputs without revealing those inputs to one another. For anti-money laundering, competing banks can run SMPC-based graph analytics to detect circular transaction flows and layering schemes across institutions without exposing individual customer relationships. Protocols like SPDZ and ABY3 provide malicious security, ensuring correctness even if a subset of parties actively deviates from the protocol.

A mathematical framework that quantifies the privacy guarantee of an algorithm by bounding the influence of any single record on the output. In fraud model training, differentially private stochastic gradient descent (DP-SGD) clips and adds calibrated noise to gradients, ensuring that an adversary cannot determine whether a specific individual's transaction was in the training set. The privacy budget, denoted by epsilon (ε), controls the trade-off between model accuracy and the formal privacy guarantee.

A protocol in federated learning that computes the sum of model updates from multiple clients without revealing any individual contribution to the coordinating server. This prevents gradient leakage attacks, where an honest-but-curious server reconstructs private training data from raw updates. Implementations use Shamir secret sharing and pairwise masking to tolerate client dropouts while ensuring that the server only sees the final aggregated model, not individual bank-specific fraud patterns.

A cryptographic method enabling one party to prove a statement's truth without revealing any information beyond that fact. In financial compliance, a bank can generate a zk-SNARK to prove that a transaction complies with sanctions screening rules without exposing the underlying customer data or screening logic to a regulator. zk-STARKs offer post-quantum security and eliminate the trusted setup requirement, making them suitable for long-term audit trails.