要約

  • measured componentは安定した名前、任意のversion、raw値またはalgorithm付きdigestを持ち、componentを権威的に識別・署名する主体のIDも載せられる。そのIDは外側EATを署名したattesterを示さない。
  • authority配列の位置と順序、64bitのprofile flagsは適用profileが意味を与える。consumerがprofileを知らず、これらのfieldがあればEATを拒否しなければならない。
  • 実務receiptはcomponent、測定境界、値、component signer、profile、outer signer、freshness、reference values、verifier policy、result、relying partyのauthorizationを分けて結ぶ。

「署名は有効だった」という報告を受けたとき、最初に確認すべきなのはalgorithmではなく主語である。

firmwareの署名か。測定Evidenceを包むEATの署名か。verifierが発行したAttestation Resultの署名か。同じdeviceについて三つが存在し、三つとも有効でありながら別の組織に属することがある。

2026年7月にStandards Trackで公開されたRFC 10013は、このうちcomponentの表現を定義する。著者はSimon Frost、Thomas Fossati、Hannes Tschofenig、Henk Birkholzの四人である。IETF profileはTschofenigの長いsecurity標準活動と同RFCを記録し、Universität der Bundeswehr Münchenは2026年3月からSecure Networks教授と記す。これはcurrent contributionの根拠であり、共同標準を個人の所有物にする根拠ではない。

measured componentは判定より手前にある

対象はflash上のfirmware、boot loader、load済みsoftware、file、configuration blob、CPU registerなどでよい。RFC 10013は、その状態をsamplingした結果をJSONまたはCBORのEAT世界へ運べる形にする。

必須なのはcomponent nameとmeasurementである。versionは任意。measurementはraw bytes、またはalgorithmとdigest valueの組になる。authoritiesと8-byteのflagsも任意である。

nameがあることは正しい対象を測った証明ではない。digest一致はsampling codeが攻撃されていない証明でも、今回のsessionのfreshnessでもない。reference valueの発行者や適用policyもdigestには含まれない。

RFC 9711も、EATがclaim semanticsを定義する一方、attester実装のsecurity levelまでは保証しないとする。強いenvelopeで弱いsensorの出力を署名することは可能である。syntax validationをtrust decisionへ昇格させてはいけない。

authority IDが指すのはcomponent側の署名

RFC 10013のauthorityは、digital signatureによってcomponentを権威的に識別できるentityである。署名はinstallation時や、boot firmware、OS、application launcherが実行する時に検証される。IDはX.509 certificate、raw public key、thumbprintなどで表現できる。

しかし、そのsignatureはEAT-formatted Evidenceに対するattester signatureとは関係がない。authority identifierだけからenclosing EAT signerを知ることはできない、と仕様は明記する。

component authorはartifactについて発言する。fleet ownerがdeployment approvalを追加することもある。third-party auditorが署名することもある。その後attesting environmentがtargetを観測し、別のkeyでEvidenceを署名する。役割は一つのdata itemに同居しても、mandateを共有しない。

RFC 9019でも、firmware authorのauthenticationはauthorizationへのinputにすぎない。critical deviceではauthorとoperatorの両方の署名を要求できる。keyが正しいことと、そのkeyが当該installationを決められることは別である。

profileがなければ配列は意味を失う

複数authorityのpurposeはdeploymentに依存し、配列順にも意味を持たせられる。flagsの64bitもprofile固有である。同じbitが別のfleetで別の状態を表しても、binary parserは区別できない。

そこでprofileは、authoritiesを使うか、各entryが何を表すか、値をどう解釈するかを定義しなければならない。flagsにも同じ義務がある。

consumerがprofileを知らず、authoritiesまたはflagsを含むmeasured componentを受け取った場合、EATはrejectである。未知fieldを捨てる、他製品の順序を当てはめる、outer signatureが正しいから通す、というfallbackは認められない。

これはinteroperabilityを狭めるのではなく、意味のない成功を防ぐ。Minimum Initial Specificationは共通data shapeと「ここから先は推測しない」という境界を提供する。local roleを中央仕様が奪わず、local deploymentも独自の意味を普遍化しない。

運用ではrollout順序が重要になる。producerがprofile配布より先に新fieldを出せばconformant verifierは拒否する。silent acceptはavailability上は穏やかでも、後から何を認めたか説明できない。

EAT検証とresource authorizationの間

attesterはclaims setをEvidenceとして生成し、通常はattestation keyで保護する。nonceなどがfreshnessを与える。verifierはkey provenance、targetとのassociation、attesting environmentの強度を確認し、reference valuesとappraisal policyを適用する。

その出力がAttestation Resultである。RFC 9334では、relying partyが自分のpolicyでresource actionを決める。manufacturer baselineに合う健康なlaptopでも、別企業の所有ならnetwork accessを拒否できる。approved componentでも、要求されたdata classへの権限は別である。

よってcomponent authority、attester、verifier、relying partyは別のprincipalである。前のsignatureが後のdecisionを代理しない。このagency boundaryをUIとlogにも残す必要がある。

安定nameは運用資産でありprivacy signalでもある

component nameをrelease間で一定にすると、同じcomponentの変化を追いやすい。反面、RFCはname/versionがsoftwareやconfigurationを漏らし、安定nameがtrackingを可能にすると警告する。

同じauthority key IDを広範囲に送ればcorrelationはさらに強くなる。詳細measurementを必要とするverifierと、限定resultだけ必要なrelying partyを分離できる場合、profileは開示範囲を狭めるべきである。

privacyのためにaudit evidenceを消すのではない。内部で再検証可能なreceiptを保存しつつ、外部consumerへ永続device identifierを不用意に配らない設計が必要になる。

再現できるreceiptの構造

EAT本体またはcontent-addressed object、media type、encoding、profile ID/versionを保存する。outer algorithm、attester key、verification-key provenance、nonce、collection/receipt time、verifier versionを記録する。

componentごとにname、version convention、target、sampling boundary、raw/digest区分、algorithm/valueを残す。authority配列は順序を保持し、roleを与えたprofile definition、component signature、verification resultへlinkする。flagsはraw 8 bytesとdecoded meaningの両方を残す。

appraisal receiptはreference-value provider、set/version、各comparison、missing measurement、verifier policy/version、正確なAttestation Resultを含む。最後にrelying party、resource、operation、policy、allow/deny、restriction、expiry、remediationを追加する。

これでunknown profile、unapproved component signer、bad outer signature、stale Evidence、digest mismatch、compliant but unauthorizedを別々に扱える。単一の「attestation error」では、修理すべきownerすら分からない。

Running-Code Primacyが要求するのは、実装が何をしたかの観測である。inputsとpolicyを失ったpass/failは、その観測を可能にしない。

参照資料