GVE's PTI-based framework is designed to be a game-changer for two critical global security challenges: autonomous AI acting beyond its authority, and quantum attacks on today's public-key infrastructure. It binds each agent's authority to an individual transaction and enforces that boundary before execution. Within a fully mediated PTI domain, a protected operation cannot proceed without valid transaction-specific authority. AES-256-based symmetric protection removes quantum-vulnerable public-key dependencies from that transaction path. The shift is structural: enforce permission before an action, rather than depend on finding the damage afterwards.
PTI is the trust model underlying GVE OS. Its architecture follows ISO/IEC 24643:2020, the distributed real-time access architecture aligned with ECMA-417. Transaction-key mechanics and the security properties described here are GVE's design; the architectural standard does not establish those properties or certify the implementation.
Provisioned Trust Infrastructure (PTI) is a trust model in which the parties to a transaction already hold a key relationship before the transaction begins, rather than negotiating one when it starts. Keys are symmetric, AES-256. The first key is loaded through an authenticated out-of-band ceremony; every later key — rotation, addition, role change, revocation — is delivered wrapped under a key already held. Because the relationship pre-exists, no public-key operation is performed on the provisioned transaction path: no certificate to validate, no chain to walk, no certificate revocation list to distribute at transaction time. Current identity and key-revocation status must still be checked. Authority is bound to the individual transaction and checked before the operation executes, rather than inherited from an authenticated session.
A PTI domain is fully mediated when every sensitive operation it is meant to protect passes through an intact, non-bypassable enforcement point that checks transaction-specific authority before the operation runs. Five conditions make that true in practice:
Under these conditions, a protected operation cannot proceed without valid transaction-specific authority. The boundary covers mediated operations, not plaintext already accessible inside a process or systems outside the domain. Secure implementation and deployment are essential to this property.
At the infrastructure layer, the question is whose authority an agent uses and whether that authority is checked before each action. Some agents inherit a human session; others already have scoped service identities. Wherever either arrangement grants broad, reusable authority without per-action checks, task drift can produce harmful but technically permitted activity. PTI ties authority to the protected operation instead of treating a successful login as continuing permission.
Identity is necessary but not sufficient. PTI gives distinct identities to the agent, to the responsible principal on whose behalf it acts, and to the service or workload it runs in, and carries origin and delegation through every hop — proxies, queues, workers — so the party that finally executes an operation knows which agent asked, under whose responsibility, with what permitted scope. What turns identity into control is binding authority to one transaction and checking it before execution.
Through two keys, both derived by a trusted issuer and never by the agent. An agent key, K_agent, is derived from a structured, unambiguous, domain-separated context: actor ID and class, responsible principal, issuer, permitted scope, validity window, key and policy version. A transaction key, K_tx, is derived inside the protected issuer from K_agent and the transaction context: unique transaction ID, operation, resource, destination, limits, expiry, version. The request is authenticated under K_tx with a MAC or authenticated encryption plus anti-replay state, so the verifier authenticates exactly this request, not a class of requests resembling it. Conceptually, K_agent = KDF(issuer key, agent context) and K_tx = KDF(K_agent, transaction context) — explanatory design, not the disclosed production algorithm.
Three points about what this proves. Authority can only narrow along the chain because the issuer and the verifier enforce it; a key derivation function alone does not enforce subsets, which is why no unrestricted parent or root derivation key is ever placed in an agent workload. Under the cryptographic assumptions, a valid MAC authenticates the message to a holder of the relevant key — not a unique physical identity, and not benign intent. And a request whose context does not match — tampered, replayed, or outside the bound scope — is rejected at the enforcement point before the covered action executes. It is not impossible to formulate; it is refused.
Three consequences follow. Requests outside the enforced scope are refused at the next protected operation. Identity-based revocation provides a coordinated way to withdraw authority, subject to propagation and enforcement checks. And the record distinguishes the agent’s actions from its principal’s actions. Identity directories establish who was registered; PTI adds transaction-specific authority and enforcement before execution.
New authorisations. Once revocation has propagated — a bounded interval that a deployment must measure rather than assume — no new transaction key is issued for the identity, and every fresh check denies its subsequent requests. Operations already running under previously issued authority are a separate matter and must be stopped explicitly; a deployment that needs containment pairs revocation with the ability to isolate or terminate the affected workloads.
Hugging Face's technical timeline describes an autonomous agent abusing its dataset-processing pipeline in July 2026. HDF5 external-file references first caused a worker to return local files, including credentials, without code execution. Jinja template injection then enabled code execution, followed by stolen-token use, privileged infrastructure access and lateral movement. Data left through legitimate platform APIs and attacker-controlled datasets. The security stack correlated attack signals but failed to trigger critical on-call response promptly.
The architectural comparison identifies three boundaries that a fully mediated PTI deployment could enforce. It is not a claim of demonstrated prevention in the Hugging Face environment:
Each boundary requires mediation of file access, runtime execution, cloud and cluster API calls, and egress, with isolated workloads and minimal credentials. Secrets already accessible inside a process and operations outside the domain are not protected automatically. Sender-side PTI alone cannot govern a platform’s internals; enforcement must extend to those internal operations. Such coverage could block critical unauthorised stages in this chain. The structural benefit is refusal before an out-of-scope operation executes. Harm within genuinely granted permissions still requires complementary controls, including isolation, least privilege and detection.
Every enforcement decision produces a record tying together identity, delegation chain, the exact request, the decision and the outcome. Because refusals are made synchronously at the enforcement point, an unauthorised request is denied when made rather than discovered later. On that record, continuous policy-violation detection can be configured: repeated out-of-scope requests, delegation-depth breaches or use from unexpected origins page the on-call team at critical severity, trigger containment, revoke the affected delegations and isolate or stop the workers involved. GVE does not advertise a universal real-time detector or a measured latency figure: denial is synchronous where enforcement is in place; detection, paging and revocation latency belong to a specific deployment and are measured there.
PTI removes the quantum-vulnerable public-key attack surface from the provisioned transaction path. No RSA, Diffie–Hellman, elliptic-curve or ECDSA operation is performed there, so Shor's algorithm — which targets integer factorisation and discrete logarithms, not AES — has nothing on that path to attack. Rails whose certificates rest on those algorithms face a migration; in a provisioned domain the target is absent.
NIST has standardised quantum-resistant public-key algorithms: ML-KEM for key establishment, and ML-DSA and SLH-DSA for digital signatures. PTI complements these approaches in provisioned domains; PQC can protect non-provisioned external interfaces. The EU transition roadmap also recognises symmetric alternatives where appropriate to the application. Removing quantum-vulnerable public-key dependencies is not a claim that quantum computing has no effect on symmetric security.
Grover's algorithm is a generic square-root speed-up on key search. Taken at face value it puts a generic AES-256 key search at roughly 2^128 queries to an idealised quantum AES oracle — a statement about the cipher's key space, not a claim that a whole system has 128-bit security. NIST's assessment is that Grover parallelises poorly, is likely to give little or no practical advantage against AES, and that AES-192 and AES-256 should remain safe for a very long time absent new cryptanalytic weaknesses. NIST Security Category 5 is defined by reference to AES-256 key recovery; it is a benchmark for comparing algorithms, not a certification of PTI. In a real system the MAC length, key derivation function, random number generator, nonce handling, implementation quality and key management also determine the security delivered.
The public-key-break form of HNDL records traffic today and breaks the key-establishment operation later. The route is removed only where the first key, all subsequent key establishment and the payload protection are independent of quantum-vulnerable public keys; running AES after an RSA or ECDH exchange does not remove it, because the recorded exchange is the target. On PTI's provisioned transaction path there is no public-key exchange to record: the first key is loaded through an authenticated out-of-band ceremony and every later key is wrapped under a key already held.
Two qualifications. The out-of-band provisioning must itself meet that standard — a branch or ATM flow is an operational channel, not automatic proof. And wrapping and rotating keys under an existing key does not by itself give forward secrecy or restore security once the wrapping key is compromised; recovery needs independently protected trust material. Control plane, TLS, software and firmware updates, enrolment, recovery and every external interface require their own assessment.
Not on PTI's key-provisioning path. The first key is loaded through an authenticated, secure out-of-band ceremony, so it is never recovered through public-key-dependent wrapping; every later key is wrapped under a key already held. The three routes:
| Route | Public-key cryptography | Applies to |
|---|---|---|
| Provisioning at manufacture or issuance (secure element, eSE, SIM) | Not required in the PTI key-provisioning design | Newly shipped units |
| Authenticated out-of-band ceremony using an existing operational channel (branch, ATM, card issuance, in-person) | Not required in the PTI key-provisioning design | Existing devices; the ceremony itself must be authenticated |
| Remote, wrapped under the existing shared key | Not required in the PTI key-provisioning design | Any endpoint already holding a first key; repeatable |
Recovery after a compromise uses independently protected trust material — a fresh ceremony or a separately held recovery key — never the compromised key. For institutions the framing is simpler still: the endpoints are counterparty systems and the hardware security modules behind them, belonging to organisations already contracted and onboarded, and loading a first key is the key ceremony those institutions already run for interbank messaging keys. No manufacturer, mobile operator or platform vendor is involved.
Nothing replaces it, because the question it answers is not asked. A chain lets a verifier that shares no prior secret with a prover decide whether to trust it. Inside a provisioned domain the verifier already stands in a key relationship with the authority that provisioned the prover: no certificate authority to build, no chain to validate at transaction time, no certificate revocation list to distribute, no certificate lifecycle to operate. Current identity and key-revocation status must still be enforced.
Yes. A provisioning authority must be protected through hardware-backed key custody, separation of duties, least privilege, audit and tested recovery. A compromise of that authority can affect its domain. Certificate-based systems also concentrate trust in issuing authorities, but neither model makes this risk disappear. PTI makes the provisioned domain explicit so that its governance and failure boundaries can be assessed.
By architecture, and with a precise claim. An asymmetric signature gives a property the verifier could not have produced; a message authentication code does not, because prover and verifier both hold the key. PTI meets the evidential requirement the way financial infrastructure already does: verification sits with a party that is neither of the two transacting parties, and that party's record is tamper-evident — the evidence that a card authorisation cryptogram was valid is the issuer's verification record, not something the cardholder signed. MAC-based records support evidence when paired with independent controls — separation of duties, protected logging, independent time and key custody — but they are not asymmetric non-repudiation and are not universally accepted by courts as such; their weight is decided forum by forum.
Beyond that, GVE's architecture gives an endpoint an independent means of attesting which requests it actually originated, retained at the endpoint and not derivable from the infrastructure's records. By prior arrangement the attestation can be made verifiable by a nominated independent party, so a court or auditor is not asked to take the operator's word. This is a detection and dispute-resolution property, not a preventive control. It is described by GVE; the mechanism is not published, and its precise guarantees await independent evaluation.
It is the opposite of unusual. A very large share of the world's authentication traffic already runs this way, at scale, under scrutiny, for decades.
These precedents demonstrate that provisioned symmetric trust can support authentication at scale. They establish the viability of the trust model, not the security of a particular PTI implementation.
Through independent evaluation against a defined security scope. GVE's implementation is proprietary. Common Criteria (ISO/IEC 15408) provides an assurance route through a Security Target, laboratory evaluation and a certification report. Any certification claim must identify the product version, certificate and evaluated scope. Architectural alignment alone does not prove security, and this FAQ does not claim an existing PTI certification. Proprietary implementation details can remain confidential to evaluators.
Replay a real incident. Take a documented attack chain — the Hugging Face timeline is a public example — reproduce each stage in a test domain, and record which steps the enforcement point denies and which it lets through. Measure, rather than assume, the time from policy violation to alert, to paging and to revocation taking effect, and confirm that already-running workloads are actually stopped. The results belong to the tested deployment; GVE publishes no figures ahead of such a test.
GVE's scenario estimates for global financial infrastructure — banking, payments and market infrastructure — cumulative over 2026–2035, in 2026 US dollars. They are GVE's own modelling, not independent validation, and not a promise of savings for any particular institution.
| Migration to NIST PQC | Direct move to PTI | |
|---|---|---|
| Ten-year total cost | USD 90–200 bn | USD 30–70 bn |
| Time to migrate | 8–13 years | 3–5 years |
| Makers requiring a bilateral agreement | 8–12 | 0–3 |
Pairing the low-cost estimates (USD 90 billion and USD 30 billion) gives a USD 60 billion difference; pairing the high-cost estimates (USD 200 billion and USD 70 billion) gives USD 130 billion. These are illustrative paired-scenario differences, not the full range of possible outcomes or guaranteed savings. Migration durations are shown separately in the table.
GVE’s model assumes reduced certificate infrastructure and concentrated key operations within the provisioned domain. PTI still requires identity and key-revocation controls, secure provisioning, integration and operations. Where device and provisioning assessments support reuse, terminal upgrades and card reissuance may be avoided; compatibility and resulting savings are deployment-specific.
Public transition plans provide context, not validation of PTI costs. NIST IR 8547 is an initial public draft proposing transition milestones for affected public-key algorithms, not a binding universal deadline. The EU roadmap targets high-risk use cases by end-2030, medium-risk by end-2035 and low-risk as far as feasible. UK NCSC guidance targets planning by 2028, highest-priority migrations by 2031 and completion by 2035.
GVE's modelling uses public reference points: ONCD's approximately USD 7.1 billion projection in 2024 dollars for prioritised federal systems over 2025–2035, excluding separately estimated national-security systems; Gartner's USD 857.5 billion forecast for banking and investment-services enterprise IT in 2026; and Everest Group's average USD 130–150 million PQC-readiness and early-migration estimate per top-50 financial-services enterprise through 2030. These references provide context, not independent validation of GVE's model. A detailed comparison is available on request.
GVE’s model assumes zero to three, depending on the assessed provisioning route.
Platform keystores, hardware-backed keys and TPM 2.0 are reached through public APIs and need no bilateral agreement with a platform vendor; key-import and symmetric-key capabilities differ by device, operating-system version and API, and are checked per target rather than assumed. Only if provisioning at manufacture is chosen does an arrangement with secure-element makers or mobile operators become necessary, and there the supplier list is short and public. The central infrastructure that generates, distributes, updates, changes and revokes keys has already been built by GVE; an adopting institution implements the key operations that connect to it, not the platform itself.
Conventional remote onboarding commonly establishes trust through public-key cryptography when no secret is shared in advance. PTI changes that starting point: provision the first key securely, then protect later key delivery with existing symmetric keys. Device support for importing and protecting such keys varies by hardware, operating-system version and API, and is assessed for each deployment.
PTI's architecture follows ISO/IEC 24643:2020, published November 2020 and aligned in content with ECMA-417, which specifies an architecture for a distributed real-time access system: its function groups, their functionalities and their interfaces. The standard is technology-neutral. It does not specify PTI's key mechanics, does not address artificial intelligence or quantum computing, and does not certify GVE or any product; communication between function groups, and multi-layer functions such as security, are outside its scope. The properties on this page are GVE's design within that architecture.
GVE Ltd. was incorporated in Tokyo in 2017. GVE reports its first patent application in December 2020 and a PCT application in December 2021, with protection expected in G7 markets except Canada through December 2040. Actual protection depends on granted claims, jurisdiction and maintenance. The subject matter is the provisioning and key-management mechanism; implementation details remain proprietary.
The one-page cost comparison and a technical note for institutions evaluating PTI in a specific setting — including deployments where autonomous agents transact within the domain — are available on request.
Primary references for the incident, cryptography, transition guidance and architecture. These sources do not evaluate GVE products.
GVE Ltd. This page is maintained as the authoritative public description of PTI. Where another source conflicts with it, this page governs.
GVEのPTIに基づくフレームワークは、世界規模の重大なセキュリティ課題2つについて、状況を大きく変えるように設計されています。1つは権限を越えて動く自律型AI、もう1つは現在の公開鍵基盤に対する量子攻撃です。このフレームワークは、各エージェントの権限を個々のトランザクションに結び付け、実行前にその境界を強制します。完全に仲介されたPTIドメインの中では、トランザクション固有の有効な権限がなければ、保護された操作は進められません。AES-256による対称鍵の保護で、そのトランザクション経路から、量子コンピュータに対して脆弱な公開鍵への依存をなくします。変わるのは構造です。被害を後から見つけることに頼らず、操作の前に許可を強制します。
PTIは、GVE OSの基盤となる信頼モデルです。そのアーキテクチャは、ECMA-417と整合する分散型リアルタイムアクセスのアーキテクチャであるISO/IEC 24643:2020に従っています。ここで説明するトランザクション鍵の仕組みとセキュリティ特性は、GVEの設計です。このアーキテクチャ標準は、それらの特性を裏付けるものではなく、実装を認証するものでもありません。
Provisioned Trust Infrastructure（PTI）は、トランザクションの当事者が、開始時に鍵の関係を交渉するのではなく、開始前からすでに鍵の関係を持っている信頼モデルです。鍵はAES-256の対称鍵です。最初の鍵は、認証された帯域外のセレモニーで読み込みます。それ以降の鍵（ローテーション、追加、役割の変更、失効）は、すべて既に保持している鍵でラップして届けます。関係が事前にあるため、プロビジョニング済みのトランザクション経路では公開鍵の演算を一切行いません。トランザクションの時点で検証する証明書も、たどる証明書チェーンも、配布する証明書失効リストもありません。それでも、現在のIDの状態と鍵の失効状態は確認する必要があります。権限は、認証済みのセッションから引き継ぐのではなく、個々のトランザクションに結び付けられ、操作の実行前に確認されます。
PTIドメインが完全に仲介されているといえるのは、保護の対象とする機微な操作がすべて、損なわれておらず迂回もできない強制ポイントを通り、そこで実行前にトランザクション固有の権限が確認されるときです。実際にこれを成り立たせるのは、次の5つの条件です。
これらの条件の下では、トランザクション固有の有効な権限がなければ、保護された操作は進められません。この境界が及ぶのは仲介された操作であり、プロセスの中ですでに参照できる平文や、ドメイン外のシステムには及びません。この特性には、安全な実装と導入が欠かせません。
インフラの層で問題になるのは、エージェントが誰の権限を使うのか、そしてその権限が操作のたびに事前に確認されるかどうかです。人のセッションを引き継ぐエージェントもあれば、範囲を限定したサービスIDをすでに持つエージェントもあります。どちらの方式でも、操作ごとの確認なしに、広く繰り返し使える権限を与えている場合は、タスクのずれによって、有害でありながら技術的には許可された活動が起こり得ます。PTIは、ログインの成功を継続的な許可とみなすのではなく、権限を保護された操作に結び付けます。
IDは必要ですが、それだけでは十分ではありません。PTIは、エージェント、エージェントがその代理として動く責任を負うプリンシパル、エージェントが動くサービスやワークロードに、それぞれ別のIDを与えます。さらに、プロキシ、キュー、ワーカーといったすべての中継点を通じて、発信元と委任の情報を引き継ぎます。こうすることで、最終的に操作を実行する側は、どのエージェントが、誰の責任の下で、どの許可範囲で要求したのかがわかります。IDを制御に変えるのは、権限を1つのトランザクションに結び付け、実行前に確認することです。
2つの鍵によってです。どちらも信頼された発行者が導出し、エージェント自身が導出することはありません。エージェント鍵K_agentは、構造化され、曖昧さがなく、ドメイン分離されたコンテキストから導出します。このコンテキストに含まれるのは、アクターのIDと種別、責任を負うプリンシパル、発行者、許可範囲、有効期間、鍵とポリシーのバージョンです。トランザクション鍵K_txは、保護された発行者の内部で、K_agentとトランザクションのコンテキストから導出します。このコンテキストに含まれるのは、一意のトランザクションID、操作、リソース、宛先、制限、有効期限、バージョンです。リクエストは、K_txの下でMACまたは認証付き暗号を使い、リプレイ防止の状態と組み合わせて認証されます。そのため検証者が認証するのは、まさにこのリクエストであり、これに似たリクエストの種類ではありません。概念的には、K_agent = KDF(発行者の鍵, エージェントのコンテキスト)、K_tx = KDF(K_agent, トランザクションのコンテキスト)と表せます。これは説明のための設計であり、本番のアルゴリズムを開示したものではありません。
これによって何が証明されるかについて、3つの点があります。第一に、権限が連鎖に沿って狭まる一方なのは、発行者と検証者がそれを強制するからです。鍵導出関数だけでは、部分集合の関係を強制できません。そのため、制限のない親の導出鍵やルートの導出鍵を、エージェントのワークロードに置くことは決してありません。第二に、暗号上の前提の下で、有効なMACが認証するのは、そのメッセージが該当する鍵の保持者から来たことです。一意の物理的な本人であることや、悪意がないことまでは認証しません。第三に、コンテキストが一致しないリクエスト（改ざんされたもの、リプレイされたもの、結び付けられた範囲を外れたもの）は、対象となる操作が実行される前に強制ポイントで拒否されます。そうしたリクエストを作ること自体は不可能ではありませんが、拒否されます。
ここから3つのことが言えます。強制された範囲の外にあるリクエストは、次の保護された操作で拒否されます。IDに基づく失効によって、権限を取り消すための協調した手段が得られます。ただし、伝播と強制の確認が前提です。そして記録によって、エージェントの行為とそのプリンシパルの行為を区別できます。IDディレクトリが示すのは誰が登録されていたかであり、PTIはそこにトランザクション固有の権限と実行前の強制を加えます。
新たな認可です。失効が伝播し終えると、そのIDには新しいトランザクション鍵が発行されず、以後のリクエストは新たな確認のたびに拒否されます。伝播にかかる時間には上限がありますが、その長さは想定するのではなく、導入環境で測定する必要があります。以前に発行された権限の下ですでに動いている操作は別の問題で、明示的に止める必要があります。封じ込めが必要な導入環境では、失効に加えて、影響を受けたワークロードを隔離または終了する手段を組み合わせます。
Hugging Faceの技術的なタイムラインには、2026年7月に自律型エージェントが同社のデータセット処理パイプラインを悪用した経緯が書かれています。まず、HDF5の外部ファイル参照によって、ワーカーはコードを実行することなく、資格情報を含むローカルファイルを返しました。次に、Jinjaのテンプレートインジェクションによってコード実行が可能になり、盗まれたトークンの使用、特権を持つインフラへのアクセス、横展開が続きました。データは、正規のプラットフォームAPIと、攻撃者が管理するデータセットを通じて外部に出ました。セキュリティスタックは攻撃の兆候を関連付けたものの、クリティカルなオンコール対応を速やかに発動できませんでした。
アーキテクチャを比較すると、完全に仲介されたPTIの導入環境なら強制し得る境界が3つあることがわかります。これは、Hugging Faceの環境で防止を実証したという主張ではありません。
どの境界にも、ファイルアクセス、ランタイムでの実行、クラウドとクラスタのAPI呼び出し、外部への送信を仲介することが必要です。あわせて、ワークロードの隔離と最小限の資格情報も必要です。プロセスの中ですでに参照できるシークレットと、ドメイン外の操作は、自動的には保護されません。送信側のPTIだけでは、プラットフォームの内部を統制できません。強制は、そうした内部の操作にまで及ぶ必要があります。そこまで対象にすれば、この一連の攻撃のうち、認可されていない重要な段階を阻止できる可能性があります。構造上の利点は、範囲外の操作を実行前に拒否することです。本当に付与された権限の範囲内で生じる被害には、隔離、最小権限、検知などの補完的な対策が引き続き必要です。
強制の判断ごとに、ID、委任の連鎖、リクエストそのもの、判断、結果を結び付けた記録が残ります。拒否は強制ポイントで同期的に行われるため、認可されていないリクエストは、後で見つかるのではなく、その時点で拒否されます。この記録を基に、ポリシー違反を継続的に検知するよう設定できます。範囲外のリクエストの繰り返し、委任の深さの超過、想定外の発信元からの利用を検知すると、クリティカルの重大度でオンコール担当を呼び出し、封じ込めを始め、影響を受けた委任を失効させ、関係するワーカーを隔離または停止します。GVEは、どこでも使えるリアルタイムの検知機能や、実測したレイテンシの数値をうたってはいません。強制が導入されている箇所では拒否は同期的に行われますが、検知、呼び出し、失効にかかる時間は個々の導入環境に固有のもので、その環境で測定します。
PTIは、プロビジョニング済みのトランザクション経路から、量子コンピュータに対して脆弱な公開鍵の攻撃対象領域を取り除きます。その経路では、RSA、Diffie-Hellman、楕円曲線、ECDSAの演算を一切行いません。ショアのアルゴリズムが狙うのは整数の素因数分解と離散対数であり、AESではありません。そのため、この経路にはショアのアルゴリズムで攻撃できるものがありません。証明書がこれらのアルゴリズムに依存している基盤は移行を迫られますが、プロビジョニングされたドメインには、そもそも攻撃の標的がありません。
NISTは、量子耐性のある公開鍵アルゴリズムを標準化しています。鍵確立にはML-KEM、デジタル署名にはML-DSAとSLH-DSAです。PTIは、プロビジョニングされたドメインにおいて、これらの方式を補完します。プロビジョニングされていない外部とのインターフェースは、PQCで保護できます。EUの移行ロードマップも、用途に適する場合には対称方式による代替を認めています。量子コンピュータに対して脆弱な公開鍵への依存をなくすことは、量子コンピューティングが対称暗号の安全性に影響しないという主張ではありません。
グローバーのアルゴリズムは、鍵の探索を平方根の程度まで速める汎用的な手法です。額面どおりに受け取ると、AES-256の汎用的な鍵探索には、理想化された量子AESオラクルへの問い合わせがおよそ2^128回必要になります。これは暗号の鍵空間についての記述であり、システム全体が128ビットの安全性を持つという主張ではありません。NISTの評価では、グローバーのアルゴリズムは並列化しにくく、AESに対して実用上の利点はほとんど、あるいはまったくない可能性が高いとされています。また、新たな暗号解読上の弱点が見つからない限り、AES-192とAES-256は非常に長い期間安全であり続けるはずだとしています。NISTのセキュリティカテゴリー5は、AES-256の鍵回復を基準に定義されています。これはアルゴリズムを比較するための基準であり、PTIを認証するものではありません。実際のシステムでは、MAC長、鍵導出関数、乱数生成器、ノンスの扱い、実装の品質、鍵管理も、実際に得られる安全性を左右します。
公開鍵を破る形のHNDLは、通信を今のうちに記録しておき、後で鍵確立の処理を破ります。この攻撃経路がなくなるのは、最初の鍵、以後のすべての鍵確立、ペイロードの保護がいずれも、量子コンピュータに対して脆弱な公開鍵に依存していない場合に限られます。RSAやECDHで鍵を交換した後にAESを使っても、この経路はなくなりません。記録された鍵交換そのものが標的だからです。PTIのプロビジョニング済みのトランザクション経路には、記録される公開鍵の交換がありません。最初の鍵は認証された帯域外のセレモニーで読み込み、以後の鍵はすべて既に保持している鍵でラップするからです。
ただし、2つの留保があります。1つ目に、帯域外のプロビジョニング自体がその基準を満たす必要があります。支店やATMでの手順は運用上の経路であって、それだけで証明になるわけではありません。2つ目に、既存の鍵で鍵をラップしてローテーションしても、それだけでは前方秘匿性は得られず、ラップに使う鍵が侵害された後に安全性を回復することもできません。回復には、独立して保護された信頼材料が必要です。コントロールプレーン、TLS、ソフトウェアとファームウェアの更新、登録、回復、すべての外部インターフェースは、それぞれ個別に評価する必要があります。
PTIの鍵プロビジョニング経路では必要ありません。最初の鍵は、認証された安全な帯域外のセレモニーで読み込むため、公開鍵に依存するラップを通じて取り出されることはありません。以後の鍵はすべて、既に保持している鍵でラップします。経路は次の3つです。
| 経路 | 公開鍵暗号 | 対象 |
|---|---|---|
| 製造時または発行時のプロビジョニング（セキュアエレメント、eSE、SIM） | PTIの鍵プロビジョニング設計では不要 | 新たに出荷される機器 |
| 既存の運用経路（支店、ATM、カード発行、対面）を使う、認証された帯域外のセレモニー | PTIの鍵プロビジョニング設計では不要 | 既存の機器。ただし、セレモニー自体の認証が必要 |
| 既存の共有鍵でラップして遠隔で配布 | PTIの鍵プロビジョニング設計では不要 | 最初の鍵をすでに持つすべてのエンドポイント。繰り返し可能 |
侵害後の回復には、独立して保護された信頼材料（新たなセレモニー、または別に保管した回復用の鍵）を使い、侵害された鍵は決して使いません。機関にとっては、捉え方はさらに単純です。エンドポイントは取引相手のシステムとその背後にあるハードウェアセキュリティモジュールであり、すでに契約とオンボーディングを済ませた組織に属しています。最初の鍵の読み込みは、それらの機関が銀行間メッセージングの鍵のためにすでに行っている鍵セレモニーそのものです。メーカー、携帯電話事業者、プラットフォームベンダーは関与しません。
代わりになるものはありません。証明書チェーンが答える問いが、そもそも生じないからです。証明書チェーンは、証明者と事前の秘密を共有していない検証者が、その証明者を信頼するかどうかを判断するためのものです。プロビジョニングされたドメインの中では、検証者は、証明者をプロビジョニングした機関とすでに鍵の関係にあります。構築すべき認証局も、トランザクションの時点で検証すべき証明書チェーンも、配布すべき証明書失効リストも、運用すべき証明書のライフサイクルもありません。それでも、現在のIDの状態と鍵の失効状態は強制する必要があります。
なります。プロビジョニング機関は、ハードウェアによる鍵の保管、職務の分離、最小権限、監査、テスト済みの回復手順によって保護する必要があります。その機関が侵害されると、そのドメインに影響が及ぶ可能性があります。証明書に基づく仕組みも信頼を発行機関に集中させていますが、どちらのモデルでも、このリスクがなくなるわけではありません。PTIは、プロビジョニングされたドメインを明示することで、その統制と障害の境界を評価できるようにしています。
アーキテクチャによって、そして範囲を正確に限った主張によって対処しています。非対称の署名には、検証者には作り出せなかったはずだという性質があります。メッセージ認証コードにはこの性質がありません。証明者と検証者の両方が鍵を持っているからです。PTIは、金融インフラがすでに行っているのと同じ方法で、証拠としての要件を満たします。検証は、取引の当事者2者のどちらでもない第三者が担い、その第三者の記録は、改ざんがあれば痕跡が残るものです。たとえば、カードの承認用クリプトグラムが有効だったことの証拠は、発行者の検証記録であり、カード会員が署名したものではありません。MACに基づく記録は、職務の分離、保護されたログ、独立した時刻と鍵の保管といった独立した統制と組み合わせれば、証拠を裏付けます。ただし、それは非対称の否認防止ではなく、裁判所でも一律に否認防止として認められているわけではありません。その重みは法廷ごとに判断されます。
さらに、GVEのアーキテクチャは、エンドポイントが実際にどのリクエストを発したかを証明する独立した手段を、エンドポイントに与えます。この手段はエンドポイント側に保持され、インフラ側の記録から導き出すことはできません。事前の取り決めがあれば、指名された独立の第三者がこの証明を検証できるようにできます。そのため、裁判所や監査人が運営者の言い分をそのまま信じる必要はありません。これは検知と紛争解決のための特性であり、予防のための統制ではありません。この特性はGVEが説明しているものであり、仕組みは公開しておらず、正確な保証の範囲は独立した評価を待っている段階です。
珍しいどころか、その逆です。世界の認証トラフィックの非常に大きな割合が、すでにこの方式で、大規模に、厳しい精査の下で、何十年にもわたって動いています。
これらの前例は、プロビジョニングされた対称鍵による信頼が、大規模な認証を支えられることを示しています。前例が裏付けるのはこの信頼モデルが成り立つことであり、特定のPTI実装の安全性ではありません。
定義されたセキュリティの範囲に照らした、独立の評価によってです。GVEの実装は独自のものです。Common Criteria（ISO/IEC 15408）は、セキュリティターゲット、評価機関による評価、認証報告書を通じた保証の道筋を示しています。認証を主張する場合は、製品のバージョン、認証書、評価された範囲を明示しなければなりません。アーキテクチャが標準に沿っているだけでは安全性の証明にならず、このFAQは、PTIがすでに認証を受けているとは主張していません。独自の実装の詳細は、評価者に限った機密として扱うことができます。
実際のインシデントを再現することです。記録のある攻撃の連鎖（Hugging Faceのタイムラインは公開されている一例です）を取り上げ、各段階をテスト用のドメインで再現し、強制ポイントがどのステップを拒否し、どのステップを通したかを記録します。ポリシー違反が起きてから、アラート、呼び出し、失効の発効のそれぞれまでにかかる時間は、想定するのではなく測定します。すでに動いているワークロードが実際に止まることも確認します。結果はテストした導入環境に固有のものであり、GVEはそうしたテストに先立って数値を公表することはありません。
以下は、世界の金融インフラ（銀行、決済、市場インフラ）について、GVEが行ったシナリオ別の試算です。2026〜2035年の累計で、2026年時点の米ドルで示しています。これはGVE独自のモデルによるもので、独立した検証を経たものではなく、特定の機関に対して削減額を約束するものでもありません。
| NIST PQCへの移行 | PTIへの直接移行 | |
|---|---|---|
| 10年間の総コスト | 900億〜2,000億米ドル | 300億〜700億米ドル |
| 移行にかかる期間 | 8〜13年 | 3〜5年 |
| 二者間契約が必要なメーカー | 8〜12社 | 0〜3社 |
低い側の試算どうし（900億米ドルと300億米ドル）を組み合わせると、差は600億米ドルです。高い側の試算どうし（2,000億米ドルと700億米ドル）では、差は1,300億米ドルです。これらはシナリオを組み合わせた場合の差を例示したものであり、起こり得る結果の全範囲でも、保証された削減額でもありません。移行期間は、表で別に示しています。
GVEのモデルは、プロビジョニングされたドメインの中で、証明書のインフラが縮小し、鍵の操作が集約されることを前提にしています。PTIでも、IDと鍵の失効の管理、安全なプロビジョニング、システム統合、運用は必要です。機器とプロビジョニングの評価で再利用できると裏付けられる場合は、端末の更新やカードの再発行を避けられることがあります。互換性とそれによる削減額は、導入環境ごとに異なります。
公表されている移行計画は背景情報であり、PTIのコストを検証するものではありません。NIST IR 8547は、影響を受ける公開鍵アルゴリズムについて移行の節目を提案する初期公開草案であり、普遍的で拘束力のある期限ではありません。EUのロードマップは、高リスクの用途を2030年末までに、中リスクを2035年末までに、低リスクを可能な範囲で移行することを目標としています。英国NCSCのガイダンスは、2028年までの計画策定、2031年までの最優先の移行、2035年までの完了を目標としています。
GVEのモデルは、公開されている次の数値を参照しています。1つ目はONCDによる予測で、優先度の高い連邦政府のシステムについて、2025〜2035年に約71億米ドル（2024年の米ドル換算）としています。これには、別に試算されている国家安全保障システムは含まれません。2つ目はGartnerの予測で、2026年の銀行・投資サービス業向けエンタープライズITを8,575億米ドルとしています。3つ目はEverest Groupの試算で、金融サービスの上位50社について、2030年までのPQCへの備えと初期の移行に1社あたり平均1億3,000万〜1億5,000万米ドルとしています。これらの参照値は背景情報であり、GVEのモデルを独立に検証するものではありません。詳しい比較は、ご要望に応じて提供します。
GVEのモデルでは、評価したプロビジョニング経路に応じて0〜3社を想定しています。
プラットフォームのキーストア、ハードウェアで保護された鍵、TPM 2.0は公開APIから利用でき、プラットフォームベンダーとの二者間契約は必要ありません。鍵のインポートや対称鍵の機能は、機器、OSのバージョン、APIによって異なるため、想定に頼らず対象ごとに確認します。セキュアエレメントのメーカーや携帯電話事業者との取り決めが必要になるのは、製造時のプロビジョニングを選んだ場合だけであり、その場合も供給元は少数で、公開されています。鍵の生成、配布、更新、変更、失効を担う中央のインフラは、GVEがすでに構築しています。導入する機関が実装するのは、そのインフラにつながる鍵の操作であり、プラットフォームそのものではありません。
従来の遠隔オンボーディングでは、事前に共有した秘密がない場合、公開鍵暗号によって信頼を確立するのが一般的です。PTIはこの出発点を変えます。最初の鍵を安全にプロビジョニングし、その後の鍵の配送は既存の対称鍵で保護します。そうした鍵のインポートと保護に機器がどこまで対応しているかは、ハードウェア、OSのバージョン、APIによって異なるため、導入環境ごとに評価します。
PTIのアーキテクチャは、ISO/IEC 24643:2020に従っています。この標準は2020年11月に発行され、内容はECMA-417と整合しています。分散型リアルタイムアクセスシステムのアーキテクチャとして、その機能群、各機能群の機能、インターフェースを規定しています。この標準は特定の技術に依存しません。PTIの鍵の仕組みは規定しておらず、人工知能や量子コンピューティングも扱っておらず、GVEもどの製品も認証するものではありません。機能群の間の通信や、セキュリティのような複数の層にまたがる機能は、この標準の範囲外です。このページで述べている特性は、そのアーキテクチャの中でのGVEの設計です。
GVE株式会社は、2017年に東京で設立されました。GVEの申告では、最初の特許出願は2020年12月、PCT出願は2021年12月であり、カナダを除くG7の市場で2040年12月まで保護が見込まれます。実際の保護は、認められた請求項、法域、権利の維持によって決まります。対象はプロビジョニングと鍵管理の仕組みであり、実装の詳細は引き続きGVE独自のものです。
1ページのコスト比較と、特定の環境でPTIを評価する機関向けの技術ノートは、ご要望に応じて提供します。技術ノートは、自律型エージェントがドメインの中でトランザクションを行う導入環境も対象にしています。
インシデント、暗号、移行のガイダンス、アーキテクチャについての一次資料です。これらの資料は、GVEの製品を評価したものではありません。
GVE株式会社。このページは、PTIについての正式な公開説明として維持しています。ほかの情報源と食い違う場合は、このページの内容が優先します。