Real Human Verification (RHV): A Hardware-Rooted Cryptographic Standard for Human-Origin Visual Evidence

Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document is not an Internet Standard. It is a work in progress and is subject to change. It may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use this document as reference material or to cite it other than as a “work in progress.”

Introduction Digital visual evidence has historically served as a foundational pillar for legal, institutional, and societal trust. For over a century, photographs and videos have functioned as primary instruments for documenting reality, establishing accountability, and preserving historical truth. The emergence of generative artificial intelligence has fundamentally altered this trust model. Synthetic images and videos can now be generated that are visually indistinguishable from direct human-origin capture, rendering traditional visual verification methods unreliable. As a result, the evidentiary value of digital visual media is undergoing rapid erosion across judicial systems, public institutions, media organizations, and digital platforms. At present, there exists no public, neutral, and cryptographically verifiable constitutional root of trust for establishing whether digital visual content originated from a physically authenticated human capture pipeline. Existing authenticity mechanisms focus primarily on content provenance, metadata, or platform-level attestations, but do not provide a universal, hardware-backed, and publicly auditable guarantee of direct human-origin capture. Real Human Verification (RHV) defines a constitutional cryptographic layer that addresses this structural deficiency. RHV introduces a public, vendor-neutral, and hardware-rooted framework for establishing verifiable human-origin capture, tamper-evident integrity, and publicly auditable provenance chains for digital photos and videos. By anchoring visual evidence in hardware roots of trust and append-only transparency logs, RHV establishes a foundational trust primitive upon which operating systems, hardware manufacturers, browsers, platforms, and legal institutions can build interoperable systems for visual evidence verification in the post-AI era.

Terminology and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 . The following terms are used throughout this specification: RHV (Real Human Verification): The cryptographic standard defined in this document for establishing a human-origin root of trust for visual digital evidence. Human-Origin Capture: A capture process in which photons or sensor signals originate from the physical environment and are acquired by a physically authenticated sensor pipeline backed by a hardware root of trust. CAPTURED Asset: A photo or video that has been directly acquired through a Human-Origin Capture process and for which an RHV Proof has been generated by a hardware-backed secure capture pipeline. DERIVED Asset: Any photo or video that has been transformed, edited, re-encoded, cropped, composited, or otherwise modified from a CAPTURED asset or another DERIVED asset. DERIVED assets are not considered direct human-origin captures, but MAY maintain cryptographically verifiable provenance links to their originating assets. RHV Proof: A cryptographic statement generated by a secure capture pipeline that binds a media hash, capture time, and hardware-backed human-origin attestation into a signed structure. Hardware Root of Trust (HRoT): A tamper-resistant hardware security component (e.g., Secure Enclave, Trusted Execution Environment (TEE), StrongBox, Trusted Platform Module (TPM), Secure Element) capable of generating and protecting cryptographic keys used to attest that media originated from a physically authenticated sensor pipeline. Secure Capture Pipeline: A hardware-backed data path from sensor to signing environment that ensures authenticity, integrity, and temporal correctness of captured visual data. Transparency Log: A publicly verifiable, append-only, cryptographically auditable log used to anchor RHV Proofs and provide public auditability and immutability. Chain of Provenance: A cryptographically verifiable sequence of links connecting a DERIVED asset to its originating CAPTURED asset through signed transformation statements. RHV Anchor ID: The unique identifier assigned to an RHV Proof once it has been anchored into a Transparency Log.

Problem Statement The trustworthiness of digital visual evidence is undergoing a systemic collapse. Advances in generative artificial intelligence have enabled the creation of synthetic images and videos that are visually indistinguishable from direct human-origin capture. As a result, traditional methods for assessing the authenticity of visual media—based on visual inspection, metadata analysis, or platform-level attestations—are no longer reliable indicators of physical reality. Judicial systems, insurers, journalists, scientific institutions, and digital platforms increasingly face the inability to establish whether a given visual asset represents a physically captured event or a synthetic fabrication. This erosion of visual evidentiary trust undermines legal due process, public accountability, and the integrity of historical records. Current provenance and authenticity frameworks primarily focus on recording transformations, authorship, or platform-level content attestations. While these approaches provide valuable context, they do not establish a universal, hardware-backed, publicly auditable root of trust capable of proving that visual content originated from a physically authenticated human capture pipeline. Without such a root of trust, it is cryptographically impossible to distinguish direct human-origin capture from synthetic generation in a universally verifiable manner. This structural deficiency constitutes a fundamental gap in the trust architecture of the modern digital ecosystem. RHV is designed to address this gap by defining a constitutional cryptographic root of trust for human-origin visual evidence.

Design Goals RHV is designed as a constitutional trust layer for digital visual evidence. Its design is guided by the following foundational goals.

Hardware-Anchored Human-Origin Proof RHV MUST anchor human-origin verification in hardware roots of trust. Proof of human-origin capture MUST be derived from physically authenticated sensor pipelines backed by tamper-resistant secure elements.

Public Verifiability RHV MUST enable any third party to independently verify proofs without reliance on proprietary platforms, closed services, or vendor-specific trust anchors.

Chain of Provenance RHV MUST support cryptographically verifiable provenance chains linking DERIVED assets to their originating CAPTURED assets, enabling full auditability of transformations.

Tamper Evidence Any modification to an RHV-protected asset MUST be detectable through cryptographic integrity verification.

Vendor Neutrality RHV MUST NOT depend on any single platform vendor, operating system, or hardware manufacturer. The standard MUST be implementable across heterogeneous ecosystems.

Privacy Preservation RHV MUST minimize the exposure of personal data. Human-origin attestation MUST NOT require user identification, biometric data, or persistent personal identifiers.

Scalability RHV MUST be capable of supporting planetary-scale adoption with minimal storage, bandwidth, and computational overhead.

Forward Compatibility RHV MUST support extensibility to accommodate future cryptographic algorithms, hardware roots of trust, and capture device classes.

System Overview RHV defines a layered, hardware-anchored architecture for establishing and verifying human-origin visual evidence. The system is composed of three primary layers: Secure Capture, Public Anchoring, and Verification.

Secure Capture Layer The Secure Capture Layer operates within devices capable of Human-Origin Capture (e.g., smartphones, cameras, drones, and sensor-based capture hardware). It includes: A Secure Capture Pipeline that authenticates sensor-originated data. A Hardware Root of Trust (HRoT) that generates and protects attestation keys. A signing environment that produces RHV Proofs binding media hashes, capture time, and human-origin attestation. This layer is responsible for producing cryptographically verifiable statements asserting that an asset was directly captured by a physically authenticated sensor pipeline.

Public Anchoring Layer The Public Anchoring Layer provides Transparency Logs that: Are append-only and publicly auditable. Anchor RHV Proofs to produce globally verifiable RHV Anchor IDs. Enable third-party auditability, immutability, and independent verification. Transparency Logs form the public memory of RHV, ensuring that proofs cannot be retroactively altered or suppressed without detection.

Verification Layer The Verification Layer enables any third party to: Validate RHV Proof signatures. Confirm anchoring in Transparency Logs. Reconstruct Chains of Provenance linking DERIVED assets to their originating CAPTURED assets. Assess tamper evidence and transformation history. This layer is intentionally vendor-neutral and does not require trusted platform intermediaries.

Storage and Scalability Model RHV DOES NOT store visual content.
RHV stores only cryptographic proofs and transparency anchors. Each RHV Proof consists exclusively of cryptographic material, including:

Media Hash: 32 bytes
Timestamp: 8 bytes
Hardware Attestation Hash: 32 bytes
Digital Signatures (dual-root): 128 bytes
Log metadata and indexing: approximately 56 bytes

Total (rounded): 256 bytes per proof. Thus, each RHV Proof occupies approximately 256 bytes (0.00025 MB). RHV Proofs bind cryptographic hashes to a specific canonical representation of the captured media. Any modification to the media bitstream, including accidental corruption or non-canonical metadata changes, SHALL invalidate the corresponding RHV Proof unless such modifications are explicitly recorded as a DERIVED asset with a signed derivation statement. RHV does not attempt to preserve proof validity across arbitrary or untracked modifications. This behavior is intentional and ensures strong tamper-evidence, forensic integrity, and unambiguous origin verification. Implementations MAY define canonicalization procedures for media hashing, such as excluding non-semantic metadata or normalizing container-level fields, provided that such procedures are explicitly specified, deterministic, and consistently applied during both proof generation and verification.

Planetary-Scale Feasibility At a global adoption scale:

100 million captures/day → 36.5 billion proofs/year → ~9.3 TB/year
1 billion captures/day → 365 billion proofs/year → ~93 TB/year
10 billion captures/day → 3.65 trillion proofs/year → ~930 TB/year

Using current commodity cloud storage pricing (approximately USD 20 per TB per month), the total annual storage cost for planetary-scale RHV operation remains under: USD 300,000 per year for the entire world. These estimates are order-of-magnitude approximations.

Economic Implication RHV storage requirements are several orders of magnitude smaller than conventional content storage and are economically trivial compared to:

social media video storage
CDN image caches
legal discovery archives
surveillance and logging systems

RHV therefore introduces no material economic barrier to planetary-scale deployment.

Constitutional Implication Because RHV stores only cryptographic proofs and not visual content, RHV:

avoids data hoarding
avoids privacy risk
avoids censorship risk
avoids cost centralization
remains globally replicable

This ensures RHV can function as a permanent constitutional layer of Internet memory.

Core Cryptographic Primitive RHV defines a minimal cryptographic primitive that establishes the foundational proof of human-origin capture and enables public auditability and provenance tracking. For any visual media asset, the following primitive is defined: H = HASH(media) P = SIGN(HASH_ID || SENSOR_CLASS_ID || H || CAPTURE_TIME || HUMAN_ORIGIN_ATTESTATION) ID = ANCHOR(P) Where: HASH_ID is an identifier for the cryptographic hash algorithm used, as defined by the RHV Cryptographic Parameters registry. SENSOR_CLASS_ID identifies the class of capture sensor and secure capture pipeline (e.g., smartphone camera, drone camera, body-worn camera, industrial sensor), as asserted by the Hardware Root of Trust. Including HASH_ID and SENSOR_CLASS_ID in the signed payload cryptographically binds the proof to a specific cryptographic algorithm and physical capture class, preventing downgrade attacks, algorithm substitution, or sensor class ambiguity. The RHV Proof (P) is generated and cryptographically signed prior to anchoring. The RHV Anchor ID is generated exclusively by the Transparency Log as a result of the ANCHOR(P) operation. The Anchor ID is an externally assigned reference used for public lookup and auditability and SHALL NOT be considered part of the signed RHV Proof payload. The resulting Anchor ID uniquely and immutably references the RHV Proof within a publicly auditable Transparency Log, establishing a constitutional cryptographic root of trust for human-origin visual evidence.

Secure Capture Pipeline The Secure Capture Pipeline defines the mandatory requirements for generating RHV Proofs from direct human-origin capture.

Pipeline Requirements Implementations SHALL use a hardware-backed secure capture pipeline that ensures that sensor-originated data cannot be injected, replayed, or modified prior to attestation. A Secure Capture Pipeline MUST: Authenticate sensor-originated data using hardware-enforced mechanisms (e.g., secure MIPI CSI channels, secure ISP validation). Execute cryptographic operations within a Hardware Root of Trust (HRoT). Generate cryptographically verifiable capture timestamps. Prevent post-capture modification prior to RHV Proof generation.

Attestation Generation For each CAPTURED asset, the Secure Capture Pipeline SHALL generate a HUMAN ORIGIN ATTESTATION that asserts: _ _ The asset was captured by a physically authenticated sensor pipeline. The capture occurred within a secure hardware environment. The capture timestamp was generated by a trusted time source. The attestation SHALL be signed using hardware-protected keys that are non-exportable and tamper-resistant.

Non-Spoofability Implementations SHALL reject any media that cannot be cryptographically bound to an authenticated sensor pipeline. Media injected, replayed, or synthesized outside the secure capture pipeline MUST NOT produce valid RHV Proofs.

Physical Signal Integrity and Analog Validation To mitigate sensor injection and replay attacks, RHV-compliant implementations SHOULD employ physical layer authentication mechanisms. Secure Sensor Channel: Raw sensor data MUST be authenticated and/or encrypted at the sensor interface (e.g., MIPI CSI-2 secure modes) prior to transmission to the SoC. Analog Noise and Jitter Analysis: The Secure ISP SHALL perform statistical analysis of sensor-specific physical noise characteristics (including fixed-pattern noise and thermal noise) to detect synthetic or replayed signals. Timing Attestation: The TEE SHALL validate that frame timing and jitter correspond to physical sensor behavior. Signals failing physical consistency validation MUST be rejected.

Secure Capture Pipeline The Secure Capture Pipeline defines the mandatory requirements for generating RHV Proofs from direct human-origin capture.

Pipeline Requirements Implementations SHALL use a hardware-backed secure capture pipeline that ensures sensor-originated data cannot be injected, replayed, or modified prior to attestation. A Secure Capture Pipeline MUST:

Authenticate sensor-originated data using hardware-enforced mechanisms (e.g., secure MIPI CSI channels, secure ISP validation).
Execute cryptographic operations within a Hardware Root of Trust (HRoT).
Generate cryptographically verifiable capture timestamps.
Prevent post-capture modification prior to RHV Proof generation.

Attestation Generation For each CAPTURED asset, the Secure Capture Pipeline SHALL generate a HUMAN_ORIGIN_ATTESTATION asserting that:

The asset was captured by a physically authenticated sensor pipeline.
The capture occurred within a secure hardware execution environment.
The capture timestamp was generated by a trusted time source.

The attestation SHALL be signed using hardware-protected keys that are non-exportable and tamper-resistant.

Physical Signal Integrity and Analog Validation To mitigate sensor injection and replay attacks, RHV-compliant implementations SHOULD employ physical layer authentication mechanisms.

Secure Sensor Channel Raw sensor data MUST be authenticated and/or encrypted at the sensor interface (e.g., MIPI CSI-2 secure modes) prior to transmission to the System on Chip (SoC).

Analog Noise and Jitter Analysis The Secure Image Signal Processor (ISP) SHALL perform statistical analysis of sensor-specific physical noise characteristics, including fixed-pattern noise and thermal noise, to detect synthetic or replayed signals.

Timing Attestation The Trusted Execution Environment (TEE) SHALL validate that frame timing and jitter correspond to physical sensor behavior. Signals failing physical consistency validation MUST be rejected.

Hardware Root of Trust RHV relies on Hardware Roots of Trust (HRoT) to anchor human-origin attestation in tamper-resistant physical hardware.

Root of Trust Requirements An HRoT MUST:

Protect private attestation keys against extraction.
Execute cryptographic operations in an isolated, tamper-resistant environment.
Provide secure key storage and attestation services.
Support secure boot and firmware integrity validation.

Examples of acceptable HRoT implementations include Secure Enclave, Trusted Execution Environments (TEE), StrongBox, Trusted Platform Modules (TPM), and dedicated Secure Elements.

Device Attestation Keys Each compliant device SHALL possess one or more hardware-protected attestation keys used exclusively for RHV Proof generation. These keys:

MUST NOT be exportable.
MUST be generated and stored within the HRoT.
MUST support revocation and rotation mechanisms.

Physical Capture Assertion The HRoT SHALL provide a cryptographic assertion that the signed media originated from a physically authenticated sensor pipeline and was not synthetically generated or externally injected.

Dual Public Root Attestation RHV SHALL employ a dual-root attestation model. Each RHV Proof SHALL be signed by:

A device Hardware Root of Trust attesting physical capture.
A public RHV network root attesting public anchoring.

This dual attestation prevents isolated device forgeries, private log suppression, and unverifiable local-only proofs.

Transparency Log RHV defines a public Transparency Log as a foundational component for anchoring RHV Proofs and enabling independent auditability.

Log Properties A Transparency Log MUST be:

Append-only.
Publicly readable.
Cryptographically verifiable.
Resistant to retroactive modification.
Replicable across independent operators.

The log SHALL support inclusion proofs and consistency proofs to allow third parties to independently audit log integrity.

Anchoring Operation The ANCHOR(P) operation appends a previously generated and signed RHV Proof P into a Transparency Log and returns a globally unique RHV Anchor ID. The RHV Anchor ID is generated exclusively by the Transparency Log upon successful inclusion of the signed proof. The Anchor ID is an externally assigned reference used for public lookup and auditability and SHALL NOT be considered part of the RHV Proof signature or payload.

Public Auditability Any party MAY audit the Transparency Log to verify: That a given RHV Proof has been anchored. That the log has not been modified, truncated, or forked. That inclusion proofs and consistency proofs are valid.

Capture Modes RHV defines two normative capture modes to distinguish direct physical capture from subsequent transformations.

CAPTURED A CAPTURED asset is a photo or video that originates from a Secure Capture Pipeline and has an RHV Proof anchored in a Transparency Log. CAPTURED assets represent the cryptographic root of a provenance chain and are considered direct human-origin captures. Only CAPTURED assets establish new human-origin roots.

DERIVED A DERIVED asset is any asset that results from transformation of a CAPTURED asset or another DERIVED asset, including but not limited to:

Cropping
Editing
Compositing
Re-encoding
Resizing
Color correction
Montage
Synthesis operations

DERIVED assets MUST NOT be treated as direct human-origin captures. However, they MAY maintain cryptographically verifiable provenance links to their originating assets. Each DERIVED asset SHALL produce a signed derivation statement linking it to its parent asset, forming a publicly auditable Chain of Provenance.

Human-Derived Provenance Lineage RHV defines a Lineage Chain (LC) as a sequence of cryptographic assertions anchored to a Root Human Event (RHE).

Root Human Event (RHE) The initial CAPTURED asset signed within a Hardware Root of Trust.

Derived Assertions Any subsequent modification (including but not limited to cropping, color grading, temporal editing, re-encoding, compositing, or synthesis) MUST be recorded as a new derivation statement referencing the parent asset hash. RHV DOES NOT evaluate the semantic intent or legitimacy of transformations. Instead, it provides a cryptographically verifiable traceability path. In judicial or institutional contexts, an auditor SHALL be able to reconstruct the full lineage of an asset. If the lineage chain is broken or contains unauthenticated synthetic generation steps, the asset MUST be classified as UNVERIFIED.

Verification Process RHV defines a public verification process that allows any party to independently validate human-origin capture, integrity, and provenance of a visual asset.

Proof Validation To verify an RHV-protected asset, a verifier SHALL perform the following steps: Validate the RHV Proof structure and digital signatures, including verification of the hardware-backed attestation and the public anchoring signature. Confirm anchoring of the RHV Proof in a Transparency Log using inclusion and consistency proofs. Upon successful validation of the RHV Proof, compute H = HASH(media). Verify that the computed media hash matches the hash bound within the validated RHV Proof.

Provenance Reconstruction For DERIVED assets, a verifier SHALL reconstruct the Chain of Provenance by:

Validating each signed derivation statement.
Confirming that each link references a valid parent asset.
Ensuring that the chain terminates in a CAPTURED asset.

Determination of Origin Class Upon successful verification, an asset SHALL be classified as one of the following: CAPTURED — Direct human-origin capture. DERIVED-N — Nth-order derivation from a CAPTURED asset.

Privacy Considerations RHV is designed to establish verifiable human-origin capture while preserving individual privacy and minimizing personal data exposure.

Data Minimization RHV MUST NOT require the collection, storage, or disclosure of: Personally identifiable information (PII) Biometric identifiers User account identifiers Persistent device identifiers Location data beyond cryptographically necessary timing information RHV Proofs SHALL contain only the minimum cryptographic material required to establish origin, integrity, and provenance.

Pseudonymous Hardware Attestation Hardware-backed attestation keys SHALL be pseudonymous and non-linkable across independent capture events, except where explicitly required for revocation or security maintenance. Implementations SHOULD support key rotation to prevent long-term device correlation.

No Behavioral Tracking RHV MUST NOT introduce behavioral tracking, profiling, or persistent surveillance capabilities. Transparency Logs record cryptographic proofs only and do not store user activity histories, content payloads, or personal metadata.

Selective Disclosure Implementations MAY support selective disclosure mechanisms allowing holders of RHV-protected assets to disclose only those provenance elements necessary for verification in specific legal, institutional, or contractual contexts.

Threat Model RHV defines a comprehensive threat model addressing adversarial attempts to forge, alter, suppress, or misrepresent human-origin visual evidence.

Synthetic Media Injection An adversary may attempt to generate synthetic images or videos and falsely present them as human-origin captures. Mitigation: RHV relies on Hardware Roots of Trust (HRoT) to ensure that only media originating from physically authenticated sensor pipelines can generate valid RHV Proofs. Media generated outside a secure capture pipeline MUST NOT produce valid proofs.

Sensor Injection Attacks An adversary may attempt to inject replayed or synthetic data directly into the sensor data path. Mitigation: Implementations SHALL use secure sensor channels, secure Image Signal Processors (ISPs), and hardware-backed attestation mechanisms to reject unauthenticated sensor-originated data.

Local-Only Proof Forgery An adversary may attempt to create locally valid but publicly unverifiable proofs, bypassing public auditability. Mitigation: RHV SHALL employ a dual-root attestation model. Each RHV Proof SHALL be signed by: A device Hardware Root of Trust attesting physical capture A public RHV Network Root attesting public anchoring This dual attestation model prevents isolated device forgeries and unverifiable local-only proofs.

Log Suppression or Forking An adversary may attempt to suppress, truncate, or fork Transparency Logs. Mitigation: Transparency Logs SHALL support public replication, inclusion proofs, and consistency proofs, enabling independent detection of suppression, truncation, or divergence.

Replay and Substitution Attacks An adversary may attempt to reuse valid RHV Proofs for different media assets. Mitigation: Each RHV Proof cryptographically binds the media hash, capture time, and hardware-backed attestation, preventing substitution, replay, or reassignment to different media.

Security Considerations RHV establishes a constitutional cryptographic root of trust for human-origin visual evidence by combining hardware-backed attestation, public transparency anchoring, and cryptographically verifiable provenance chains.

Hardware Integrity All cryptographic operations used to generate RHV Proofs MUST be executed within a Hardware Root of Trust (HRoT). Private attestation keys MUST NOT be exportable and MUST be protected by tamper-resistant hardware.

Dual-Root Trust Enforcement RHV Proofs MUST include dual-root attestation consisting of: - A hardware root of trust attesting physical capture - A public RHV network root attesting public anchoring Both roots are REQUIRED for an RHV Proof to be considered valid.

Cryptographic Agility Implementations SHALL support algorithm agility to allow migration to successor cryptographic primitives without invalidating existing proofs.

Log Replication and Survivability Transparency Logs SHALL be replicable across independent operators to ensure survivability, censorship resistance, and global auditability.

Revocation RHV SHALL support revocation mechanisms for compromised devices, attestation keys, or Transparency Log operators. Revocation events MUST be publicly auditable. Revocation in RHV applies exclusively to cryptographic attestation keys or trust roots, not to users, personal identities, or persistent device identifiers. RHV does not require globally persistent device identifiers. Revocation is achieved through the invalidation of compromised attestation keys, key epochs, or trust roots, consistent with established public-key infrastructure and hardware attestation models. This approach preserves privacy while enabling effective and publicly auditable revocation.

Governance & Neutrality RHV is maintained by a private neutral steward organization responsible for preserving the integrity, neutrality, and continuity of the RHV specification. The RHV specification is a public, vendor-neutral constitutional standard. No single vendor, platform, government, or commercial entity has privileged control over the RHV protocol. All changes to the RHV specification SHALL be subject to public technical review, cryptographic scrutiny, and documented consensus processes. Implementations of RHV MAY be open-source or proprietary. The RHV specification itself is public and freely implementable by any party without licensing restrictions. The RHV steward organization MAY provide commercial services, infrastructure, verification endpoints, certification programs, and compliance tooling, provided such services do not compromise the neutrality, openness, or auditability of the RHV protocol.

IANA Considerations This document defines an optional registry request. The authors propose the creation of a new IANA registry: Registry Name: RHV Cryptographic Parameters Registration Procedure: Specification Required (RFC 8126) Initial Entries: 0x01 — SHA-256 (Mandatory) 0x02 — BLAKE3 (Optional) 0x03 — Ed25519 (Digital Signature)

References Normative References RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels RFC 6962 — Certificate Transparency FIPS 186-4 — Digital Signature Standard NIST SP 800-53 — Security and Privacy Controls ISO/IEC 27001 — Information Security Management WebAuthn (W3C) C2PA Specification Informative References Secure Enclave Architecture (Apple) Android StrongBox / TEE Architecture MIPI CSI-2 Secure Channel Specification TPM 2.0 Specification Certificate Transparency Logs