Remote Attestation Systems
Remote attestation enables one computing platform to prove its trustworthiness to another entity over a network by providing cryptographically verifiable evidence of its software and configuration state. Built on Trusted Platform Module (TPM) capabilities, remote attestation creates the foundation for distributed trust in modern computing environments where physical inspection of systems is impractical or impossible.
As enterprises migrate to cloud computing, adopt zero-trust architectures, and deploy Internet of Things devices at scale, the ability to verify platform integrity remotely becomes critical. Remote attestation systems allow administrators to detect compromised systems, enforce compliance policies, and make access control decisions based on verified platform state rather than static credentials alone. Understanding the cryptographic protocols, privacy mechanisms, and implementation considerations of attestation systems is essential for architects designing secure distributed applications and infrastructure.
Attestation Fundamentals
At its core, remote attestation involves three parties: the attestor (the platform proving its state), the verifier (the entity checking the attestation), and optionally a privacy authority that helps protect the attestor's privacy. The attestation process begins during boot when the platform's firmware and software components are measured—their cryptographic hashes are computed and extended into TPM Platform Configuration Registers (PCRs). These measurements create a tamper-evident log of exactly what code executed on the platform.
When attestation is requested, the TPM generates a quote—a digitally signed statement of the current PCR values along with a nonce provided by the verifier. The signature uses a key that chains back to the TPM's endorsement key, proving the quote came from a genuine TPM rather than software emulation. The verifier receives this quote along with the event log that details each individual measurement, allowing the verifier to both validate the cryptographic signatures and interpret what the PCR values represent. If the measurements match expected values for a trustworthy configuration, the verifier can grant the attestor access to resources or networks.
Quote Generation and Structure
TPM quote generation transforms the abstract concept of platform measurements into concrete cryptographic evidence. When an application requests a quote, it provides a qualifying data field (typically containing a nonce from the verifier) and specifies which PCRs to include. The TPM creates a data structure containing the PCR values, the qualifying data, and metadata such as firmware version and signature algorithm identifiers. This structure is then signed using an attestation key—either the endorsement key itself or, more commonly, an attestation identity key (AIK) to protect privacy.
The resulting quote is typically formatted according to the TPM 2.0 specification's TPMS_ATTEST structure, which includes a magic number identifying it as a TPM-generated attestation, clock information showing when the quote was generated, and the signature covering all fields. The signature algorithm can vary—RSA, ECDSA, or other schemes supported by the TPM—allowing systems to choose algorithms appropriate for their security requirements and performance constraints. Modern attestation protocols increasingly favor elliptic curve signatures for their combination of security and compact size, particularly important when attestation occurs over bandwidth-constrained networks.
Measurement Logs and Event Interpretation
While the TPM quote provides cryptographic proof of what measurements were taken, the event log provides the semantic meaning of those measurements. Each entry in the log records a measurement event: what was measured (typically identified by a hash and description), which PCR was extended, and metadata about the measurement context. For a boot measurement, this might include the name of the firmware module, its version, and the hash value that was extended into the PCR.
Verifiers must process the event log to understand what the final PCR values represent. This involves replaying the extend operations in order—starting from the PCR's initialized state (typically all zeros) and extending each measurement from the log to compute what the final value should be. If this computed value matches the value in the signed quote, the verifier knows the log accurately represents the measurement sequence. The verifier then evaluates whether the measured components are authorized versions, checking each hash against a database of known-good values or policies that define acceptable configurations.
Event log formats have evolved from the simple SHA-1-only logs of TPM 1.2 to the crypto-agile TCG_PCR_EVENT2 format in TPM 2.0, which supports multiple hash algorithms simultaneously. This flexibility allows systems to transition to stronger hash functions as computational capabilities advance and cryptanalysis progresses. However, it also increases complexity for verifiers, which must correctly parse multiple log formats and handle vendor-specific extensions while maintaining security-critical validation logic.
Direct Anonymous Attestation
Direct Anonymous Attestation (DAA) solves a fundamental privacy problem with basic attestation: proving a platform has a genuine TPM without revealing which specific TPM. Traditional attestation requires the attestation key to chain back to the unique endorsement key, creating a persistent identifier that could track a device across sessions and contexts. DAA uses advanced cryptographic techniques—originally based on group signatures—to prove TPM authenticity while preventing correlation.
In the DAA protocol, a trusted issuer (the TPM manufacturer or a delegated authority) provides the TPM with cryptographic credentials during a joining phase. When the TPM later generates an attestation, it produces a zero-knowledge proof that it possesses valid credentials without revealing which specific credentials. The verifier can confirm the proof demonstrates TPM authenticity but cannot link multiple attestations from the same TPM unless the TPM chooses to include a basename parameter that allows linkability within a specific context.
TPM 2.0 implements an enhanced DAA scheme using elliptic curve cryptography, significantly improving performance compared to TPM 1.2's RSA-based approach. The protocol involves complex multi-party computation during the joining phase, with the TPM, issuer, and platform working together to create credentials without any party learning the TPM's private key. This sophistication comes with implementation challenges—DAA requires careful parameter selection, robust protection against side-channel attacks during credential operations, and secure handling of the split responsibilities between TPM hardware and platform software.
Privacy CA Protocols
Privacy Certificate Authority (Privacy CA) approaches provide an alternative to DAA for privacy-preserving attestation. In this model, a trusted third party issues attestation identity key (AIK) certificates that the platform can use for attestation without exposing the endorsement key. The platform generates an AIK pair within the TPM, then proves to the Privacy CA that this key is bound to a genuine TPM by using the endorsement key to certify the AIK. The Privacy CA validates this proof, confirms the TPM is legitimate, and issues an AIK certificate.
During attestation, the platform uses this AIK to sign quotes rather than the endorsement key. The verifier validates the AIK certificate from the Privacy CA and the signature over the quote, establishing trust without learning the endorsement key. Multiple AIKs can be created for different contexts—one for corporate network access, another for cloud services, another for IoT management—preventing cross-context correlation. The Privacy CA never learns what the platform attests to, only that it's a genuine TPM requesting an identity certificate.
Privacy CA implementations must address several operational challenges. The CA requires access to manufacturer public keys to validate endorsement key certificates, necessitating a distribution mechanism for manufacturer credentials. Certificate revocation becomes complex when devices should remain private—traditional certificate revocation lists or OCSP responses could reveal which certificates (and thus which devices) are being used. Modern Privacy CA deployments often use short-lived certificates or proof-of-possession protocols to limit the window of vulnerability from compromised AIKs while maintaining privacy properties.
Attestation Services and Infrastructure
Enterprise-scale attestation requires supporting infrastructure beyond the basic TPM and verifier. Attestation services act as centralized verifiers that understand reference measurements for authorized software, maintain revocation lists for compromised endorsement keys, and provide APIs for relying parties to check attestation results. Microsoft Azure Attestation and Google Cloud Confidential Computing Attestation exemplify cloud-based attestation services that handle the complexity of verification so applications can make simple allow/deny decisions.
These services maintain databases of known-good measurements updated as software versions change, automatically handling the challenge of firmware and OS updates that alter expected PCR values. They implement policy engines that can express complex attestation requirements: "boot loader must be version X.Y or later, with secure boot enabled, running one of these approved OS versions, with specified security features active." Rather than every relying party implementing this logic, the attestation service provides a single well-tested implementation.
Supporting infrastructure also includes measurement provisioning systems that distribute reference values, monitoring tools that track attestation failures across a device fleet, and analytics platforms that identify patterns suggesting supply chain compromise or coordinated attacks. In IoT contexts, attestation services must scale to millions of devices while maintaining subsecond response times. This demands careful architectural decisions around caching, geographically distributed verifiers, and efficient protocols that minimize both computation and bandwidth consumption.
Verifier Implementation
Implementing a robust verifier requires addressing numerous technical challenges beyond basic signature validation. The verifier must support multiple TPM versions (1.2 and 2.0), handle various cryptographic algorithms, parse different event log formats, and correctly interpret vendor-specific measurements. Signature validation involves checking the full certificate chain from the attestation key through any intermediate certificates to a trusted root, typically the manufacturer's endorsement key certificate.
Event log replay must precisely implement the TCG-specified extend operation—computing SHA-1, SHA-256, or other hash algorithms depending on the PCR bank being verified. The verifier concatenates the current PCR value with the measurement value and hashes the result, updating the computed PCR. Off-by-one errors, incorrect padding, or byte-order mistakes can cause legitimate attestations to fail validation. Reference implementations from projects like go-attestation and keylime provide tested code, but verifiers must still carefully integrate this functionality.
Security-critical verifier design requires defending against numerous attack vectors. Time-of-check-to-time-of-use vulnerabilities could allow an attacker to pass attestation with a good configuration, then reboot into a compromised state. Verifiers typically address this by requiring periodic re-attestation and maintaining state about which platforms are currently attested. Replay attack prevention demands verifying that the nonce in the quote matches what was sent and has not been used before. Denial-of-service resilience requires rate limiting attestation requests and efficiently handling malformed quotes without exhausting resources.
Trust Establishment and Bootstrapping
Before the first attestation can occur, trust must be established in the TPM's endorsement key and the attestation infrastructure. This bootstrapping process typically begins during manufacturing when the TPM vendor generates the endorsement key pair, stores the private portion in the TPM, and publishes the public key with a certificate signed by the vendor's root key. Verifiers obtain vendor root certificates through out-of-band mechanisms—embedded in operating systems, distributed via industry consortiums, or provisioned by administrators.
For Privacy CA approaches, additional bootstrapping establishes trust in the CA itself. Organizations may operate their own Privacy CA, trusting it because it's under their administrative control, or rely on a third-party CA whose root certificate is widely distributed. The Privacy CA must bootstrap its knowledge of legitimate TPM endorsement key certificates, typically by obtaining vendor signing keys through the same mechanisms verifiers use.
In zero-trust architectures, trust establishment becomes recursive—the attestation service itself must be attested to ensure the verifier hasn't been compromised. This leads to hierarchical attestation designs where root verifiers run on hardware with stronger physical security guarantees (such as hardware security modules), attesting intermediate verifiers that in turn attest end-user platforms. Breaking this chain at any point compromises all downstream attestations, making the root of trust critical infrastructure that demands exceptional protection and monitoring.
Certificate Validation and Chain of Trust
Attestation depends on validating complex certificate chains that establish the authenticity of attestation keys. For Privacy CA approaches, validation begins with the AIK certificate issued by the Privacy CA, checking its signature, validity period, and revocation status. The verifier then validates the Privacy CA's certificate against a trusted root, ensuring the CA itself is authorized. This creates a chain: root CA → Privacy CA → AIK → quote signature, where failure at any link invalidates the attestation.
For direct TPM-based attestation, the chain runs from the TPM manufacturer's root certificate through the endorsement key certificate to the attestation key (which may be the endorsement key or derived from it via TPM2_Certify). Each certificate in the chain must be validated for proper signatures, appropriate key usage extensions, and temporal validity. Certificate transparency logs and cross-signing arrangements between manufacturers provide additional assurance against compromise of manufacturer signing keys.
Implementation challenges include handling certificate renewal when validity periods expire, managing trust store updates as new manufacturers enter the market, and dealing with certificate path validation complexities like name constraints and policy mapping. Cryptographic agility requires supporting various signature algorithms across the chain—a SHA-256 attestation might chain through SHA-384 manufacturer certificates to a SHA-512 root. Validation code must correctly handle algorithm transitions while rejecting unsafe combinations that could enable downgrade attacks.
Revocation Mechanisms
Revocation handles the inevitable reality that some TPMs will be compromised, some Privacy CAs will be breached, and some manufacturer keys will need to be distrusted. Certificate Revocation Lists (CRLs) provide the traditional mechanism—a verifier downloads a signed list of revoked certificates and checks whether the attestation key's certificate appears before accepting the attestation. However, CRLs create privacy concerns: requesting a CRL can reveal which devices are performing attestation, and CRL distribution to millions of devices creates significant infrastructure load.
Online Certificate Status Protocol (OCSP) allows verifiers to check revocation status in real-time by querying an OCSP responder about a specific certificate. While this provides fresher revocation information than periodic CRL downloads, it introduces latency into the attestation process and creates a dependency on network connectivity to the OCSP responder. OCSP stapling addresses some concerns by having the attestor obtain a signed OCSP response and include it with the attestation, but this still reveals attestation timing to the OCSP responder.
Modern approaches explore alternatives that better balance security and privacy. Short-lived certificates eliminate the need for revocation checking during their brief validity period, though they require more frequent re-issuance. Privacy-preserving revocation schemes use cryptographic accumulators or Bloom filters to allow checking revocation status without revealing which certificate is being checked. For TPM endorsement keys, revocation typically occurs at the manufacturer root level rather than for individual TPMs, reducing the size of revocation lists but making revocation decisions more consequential.
Privacy Considerations
Privacy concerns pervade remote attestation design because attestation fundamentally links device identity to usage patterns. Even with DAA or Privacy CA protocols protecting the endorsement key, other information leakage vectors exist. The event log reveals detailed information about the platform's firmware version, BIOS settings, boot loader, operating system, and loaded drivers—creating a fingerprint that might uniquely identify a device or user even without knowing the endorsement key.
Network-level correlation can link attestation attempts even when cryptographic protocols prevent correlation. If a device always attests from the same IP address or at predictable times, this side-channel information enables tracking. The verifier's nonce prevents replay attacks but also potentially serves as a tracking mechanism if the verifier uses predictable patterns. Privacy-conscious attestation protocols must address all these vectors, not just the cryptographic linkability of attestation keys.
Regulatory frameworks like GDPR complicate attestation deployments, as the detailed platform information in event logs might constitute personal data requiring consent and enabling data subject access rights. Organizations must balance the security benefits of fine-grained attestation against privacy obligations, sometimes choosing to attest only higher-level properties rather than detailed component measurements. Privacy-by-design approaches build privacy protection into the attestation architecture from the beginning, defaulting to minimal information disclosure and requiring explicit justification for more invasive measurements.
Attestation in Cloud Environments
Cloud computing presents unique attestation challenges and opportunities. Cloud service providers need to attest the hypervisor and physical hardware, while tenants need to attest their virtual machines and containerized workloads. Nested attestation architectures emerge where each layer attests the layer above: physical TPM attests hypervisor, virtual TPM (vTPM) attests VM, and container attestation mechanisms verify containerized applications.
Virtual TPMs enable cloud tenants to leverage attestation without dedicated hardware, with the cloud provider managing a vTPM for each VM. The vTPM's state is bound to a physical TPM in the server, creating a chain of trust from hardware to virtual instance. Microsoft Azure's vTPM implementation and Google's Virtual Trusted Platform Module demonstrate this approach, allowing cloud workloads to use attestation for key protection and integrity verification while maintaining isolation between tenants.
Confidential computing platforms like Intel SGX, AMD SEV-SNP, and ARM TrustZone CCA extend attestation to application enclaves that remain protected even from the hypervisor and operating system. These technologies provide their own attestation mechanisms—often called "enclave attestation" or "confidential computing attestation"—that prove both the code running in the enclave and the hardware security properties. Integration between TPM-based platform attestation and confidential computing attestation creates comprehensive trust establishments where cloud users can verify the full software and hardware stack.
IoT and Embedded Attestation
Internet of Things devices often lack the resources for full TPM implementations, leading to lightweight attestation approaches. DICE (Device Identifier Composition Engine) provides a simplified attestation mechanism where a small immutable ROM measures and certifies the first mutable firmware stage, which in turn measures and certifies the next stage. Each stage adds a layer to the certificate chain, creating attestation evidence without requiring a full TPM.
Resource constraints demand efficient attestation protocols that minimize computation, storage, and communication overhead. Aggregate attestation techniques allow a gateway device to produce a single attestation covering multiple IoT endpoints, reducing network traffic in dense deployments. Delayed attestation permits devices to generate attestation evidence while offline, later providing it when connectivity is available. These optimizations must preserve security properties—an attacker should not be able to exploit batching or delays to evade detection.
Embedded attestation faces additional challenges from limited update capabilities and long deployment lifetimes. Over-the-air firmware updates must preserve attestation capabilities while updating the measured code, often requiring sophisticated multi-bank firmware architectures. Cryptographic agility becomes essential as algorithms deployed today must remain usable for decades in devices that cannot be physically accessed for replacement. Energy constraints in battery-powered devices limit how frequently attestation can occur, requiring risk-based policies that balance security assurance against power consumption.
Attestation Protocols and Standards
The Trusted Computing Group's Remote Attestation Protocol (RAP) defines a standard interaction pattern for attestation, but numerous implementations and extensions exist. The protocol typically follows a challenge-response pattern: verifier sends nonce, attestor returns quote and event log, verifier validates and makes policy decision. However, optimizations and variations abound—some protocols bundle multiple quotes, others include pre-computed signatures to reduce latency.
Industry-specific standards adapt general attestation principles to domain requirements. The IETF's Remote ATtestation procedureS (RATS) architecture defines terminology and reference models for different attestation topologies: passport model (attestor includes verification result from a verifier), background check model (relying party independently verifies), and peer-to-peer model (direct attestation between parties). These patterns accommodate different trust assumptions and operational constraints.
Emerging standards like Project Veraison aim to create interoperable attestation infrastructures that work across different root-of-trust technologies (TPM, SGX, ARM TrustZone) and deployment environments (on-premise, cloud, edge). Standardization efforts must balance flexibility to accommodate diverse use cases against the need for well-specified behavior that enables security analysis. Protocol extensibility mechanisms allow vendor-specific enhancements while maintaining baseline interoperability, but poorly designed extensions can create fragmentation that undermines the benefits of standardization.
Attestation Freshness and Liveness
Proving a platform was in a good state when it generated an attestation doesn't guarantee it remains trustworthy afterward. Freshness mechanisms ensure attestation evidence is current, not a replay of an old attestation from before compromise. The verifier's nonce serves this purpose—by requiring the attestor to include a fresh random value in the signed quote, replay attacks using old attestations are prevented. However, nonce-based freshness has limitations: it doesn't prevent an attacker from compromising a system, waiting for an attestation request, temporarily restoring the system to a good state, generating a valid attestation, then returning to the compromised state.
Liveness checks address this by requiring continuous or frequent attestation. A verifier might require re-attestation every few minutes, limiting the window during which a compromised system could present valid credentials. This approach trades convenience and resource consumption for stronger assurance, making sense for high-security applications but potentially impractical for resource-constrained IoT devices. Adaptive attestation policies adjust frequency based on risk—increasing attestation frequency when anomalies are detected or for access to particularly sensitive resources.
Some advanced attestation systems incorporate runtime integrity measurements that extend PCRs during operation, not just during boot. Applications can measure configuration changes, policy updates, or critical file modifications, extending PCRs to create an audit trail. Verifiers can require attestation of these runtime measurements before authorizing operations, creating continuous assurance rather than point-in-time boot attestation. However, runtime measurement significantly increases implementation complexity and must be carefully designed to avoid performance degradation or inadvertent information disclosure.
Attestation Policy Engines
As attestation deployments scale, expressing and enforcing complex policies becomes essential. Policy engines evaluate attestation evidence against rules that define acceptable configurations, making allow/deny decisions or assigning trust levels. Policies might require specific boot loader versions, mandate secure boot be enabled, prohibit certain kernel modules, or enforce that particular security features are active. The policy language must be expressive enough to capture real requirements while remaining understandable to administrators and auditable for compliance.
Modern policy engines support multiple policy languages and evaluation frameworks. Open Policy Agent (OPA) has gained adoption for its declarative Rego language and integration with cloud-native ecosystems. TCG's IF-MAP protocol enables dynamic policy updates as threat intelligence evolves. Policy composition allows building complex rules from simpler components—a "trusted workstation" policy might compose "approved boot loader" AND "compliant OS version" AND "full disk encryption enabled" sub-policies.
Policy enforcement points must handle edge cases and failure modes securely. What happens when an attestation partially matches policy—some measurements acceptable, others not? Should the system default to deny, grant limited access, or trigger human review? How should policies evolve as software updates change expected measurements? Policy versioning and migration tools help organizations update policies without disrupting operations, while audit logs track policy changes and enforcement decisions for compliance and forensic analysis.
Deployment Challenges
Deploying remote attestation in production environments reveals numerous practical challenges. Firmware and OS updates change measured values, requiring coordinated updates to verifier reference measurements. Organizations often maintain multiple approved software versions during transition periods, with policies accepting either old or new measurements. Automation is essential at scale—manual policy updates for each firmware revision across thousands of devices is infeasible, demanding integration with software distribution and inventory systems.
Network architecture must accommodate attestation traffic, particularly when centralizing verification. Firewalls must allow communication between attestors and verifiers, which might span organizational boundaries if using third-party attestation services. Latency becomes critical when attestation blocks access—users won't tolerate multi-second delays at login, requiring careful optimization of the attestation protocol and infrastructure. High availability demands redundant verifiers with synchronized policy and reference measurement databases.
User experience and operational considerations often determine success or failure. Support teams need tools to diagnose attestation failures—why did a legitimate device fail attestation? Is it outdated firmware, a misconfigured TPM, or a genuine security issue? Provisioning workflows must incorporate attestation setup, ensuring TPMs are properly initialized and endorsement key certificates are available. Recovery mechanisms must handle cases where legitimate devices cannot attest, perhaps due to TPM failure or data corruption, without creating security bypasses that attackers could exploit.
Security Analysis and Attacks
Remote attestation systems face diverse attack vectors that defenders must understand. Reset attacks attempt to reboot a compromised platform, load legitimate software during attestation, then reboot again into the compromised state—highlighting the importance of freshness and continuous attestation. Binding attacks exploit the time gap between attestation and access, gaining attestation credentials on a good platform then transferring them to a compromised system. Careful protocol design and cryptographic binding between attestation and subsequent communications help prevent this.
Privacy attacks aim to track users or devices despite cryptographic privacy protections. Fingerprinting the event log, correlating network connections, or exploiting timing patterns can undermine privacy even when protocols like DAA prevent direct linkability. Verifier compromise represents a critical risk—a malicious verifier could accept fraudulent attestations or use its position to track attestors. Decentralizing trust through multiple verifiers or transparency logs helps detect verifier misbehavior.
Physical attacks against TPMs themselves range from probing to extract keys to sophisticated fault injection that causes the TPM to misbehave. While discrete TPMs are relatively resistant to physical attack, integrated firmware TPMs share attack surface with the main processor and may be vulnerable to privilege escalation or memory extraction. Side-channel attacks during cryptographic operations could leak key material or allow forging of attestation quotes. Continued analysis and countermeasure development remains essential as attack techniques evolve.
Integration with Zero Trust Architectures
Zero trust security models align naturally with remote attestation's philosophy of continuous verification rather than perimeter-based trust. In zero trust environments, every access request triggers policy evaluation, with device health and platform integrity as key inputs. Attestation provides cryptographic proof of platform state, enabling policy decisions based on verified facts rather than assumptions. A zero trust architecture might require current attestation before granting access to sensitive data, with the attestation validating not just user identity but also that the accessing device runs approved software and has security features enabled.
Integration requires connecting attestation services with identity and access management (IAM) systems, security information and event management (SIEM) platforms, and endpoint detection and response (EDR) solutions. Attestation results feed into risk scoring algorithms that determine access levels—a fully attested corporate laptop receives different permissions than a partially attested personal device. Conditional access policies can require re-attestation when risk levels change, perhaps triggered by threat intelligence indicating new vulnerabilities in previously trusted software versions.
Deployment at scale demands automation and orchestration. Infrastructure-as-code approaches define attestation policies alongside other security configurations, ensuring consistency across environments. CI/CD pipelines can incorporate attestation checks, refusing to deploy code to systems that cannot demonstrate proper platform integrity. Service meshes and network policies can use attestation to make connection authorization decisions at the network layer, creating defense in depth where both application and network enforce attestation requirements.
Future Directions
Remote attestation technology continues evolving to address emerging requirements and threat models. Post-quantum cryptography will eventually replace current signature and encryption algorithms in attestation protocols as quantum computers threaten existing public-key systems. The transition requires careful coordination—attestation chains involve many parties (manufacturer, Privacy CA, verifier) that must synchronize algorithm updates while maintaining interoperability during the transition period.
Machine learning applications in attestation show promise for anomaly detection—training models to recognize unusual patterns in event logs that might indicate novel attacks not covered by signature-based policies. However, adversarial machine learning research demonstrates that ML-based defenses can themselves be evaded, requiring careful design and validation. Formal verification methods increasingly apply to attestation protocols and implementations, using mathematical proof techniques to demonstrate security properties hold under specified assumptions.
Standardization efforts continue expanding interoperability across different root-of-trust technologies and vendor implementations. Cross-platform attestation frameworks aim to provide unified interfaces whether the underlying trust anchor is a TPM, a secure enclave, or a DICE-based lightweight mechanism. As attestation becomes ubiquitous in security architectures, the focus shifts from whether to deploy attestation to how to optimize its performance, usability, and privacy properties while maintaining the strong security guarantees that make it valuable.