第113回IETF報告 [第2弾] ～IoTデバイスマネジメント関連～
tech_team IETF インターネットの技術 他組織のイベント
先日公開した「第113回IETF報告 [第1弾] ～IETF 113で行われたHotRFCやBOF～」に続いて、第2弾としてIoTデバイスマネジメント関連のトピックをご紹介します。今回のレポートは、磯部光平氏（セコム株式会社 IS研究所）にご執筆いただきました。
ネットワーク接続機能を有したデバイスを活用するIoTでは、大量のデバイス群による、ビッグデータの創出や多様なサービス提供が期待される反面、膨大な数のデバイス展開や、ライフサイクル管理が課題とされます。IETFではsecエリアを中心に、このようなIoTデバイスのネットワークを介した管理に寄与する、標準の策定が並行して進んでいます。
今回は、その中で三つのWGの活動とIETF 113における議論のほか、ソフトウェアのサプライチェーンに着目した提案である、SCITT（Supply Chain Integrity, Transparency, and Trust）も紹介します。
SUIT WG（Software Updates for IoT）
SUIT WGでは、IoTデバイスのソフトウェア更新をスコープに活動しています。具体的にはマニフェストと呼ばれる、ソフトウェアの配布URIや更新時に実行するコマンドを記したフォーマットを規定しており、IoTデバイスはマニフェストのパーサーを動作させることで、ソフトウェアの更新を実行することができます（*1）。
既に、マニフェストを中心としたソフトウェア更新モデル、ならびにマニフェストに記載する情報のモデリングは、いずれもRFC 9019、RFC 9124として標準文書を発行済みであり、現在はマニフェストのバイナリ記述方法や、高度なソフトウェア更新機能、ソフトウェア更新の結果報告機能が議論されていま
す。
マニフェストのバイナリ記述方法（*2）
マニフェストは、改ざんなどの攻撃への対策として、署名を含めることができます。今回のIETF 113では、この署名アルゴリズムとしてHSS-LMS方式の耐量子計算機暗号アルゴリズムを追加し、実装を必須化すべきという提案がなされました。IoT機器は数十年単位で運用されることも多く、長期間安全性を確保するために必要という狙いで提案がなされましたが、リソース制約が大きいIoT機器に対して実装を強制することは可能なのかという指摘があったほか、耐量子計算機暗号アルゴリズムはHSS-LMS以外の方式の提案や標準化が行われており、これらの比較なども踏まえて議論すべきとの指摘がありました。またこれに関連し、暗号化アルゴリズムに関する規定は、バイナリ記述方法の文書から分離すべきという意見も出されました。
高度なソフトウェア更新機能
高度なソフトウェア更新機能として議論されている対象には、暗号化されたファームウェアを用いた更新（Firmware Encryption）（*3）、ならびにソフトウェア間の依存関係を表現できるマニフェストの拡張（Multiple Trust Domains）（*4）があります。IETF 113では、暗号化されたファームウェア更新機能について、ARM社のHannes Tschofenig氏がハッカソンを実施し、同氏が提案する更新手法についての報告、ならびにドラフトのアップデートを行いました。後者はマニフェストの拡張として、今回のIETF 113からWGアイテムとして追加されました。こちらは提案者から、実装によるフィードバックが欲しいとのコメントが寄せられています。
RATS WG（Remote ATtestation procedureS WG）
RATS WGは、リモートアテステーションと呼ばれる、ネットワークを介して遠隔でデバイスの正常性を検証する技術をスコープとしたWGです。
RATS WGが標準化を進めるリモートアテステーションでは、検証対象とされるAttester、Attesterから収集したEvidenceと呼ばれる値群を基に検証・評価を行うVerifier、Verifierの検証結果（Attestation Result）を利用するRelying Partyが規定されており、3者間でやり取りされる情報のフォーマット（EAT: Entity Attestation Token）の規定も行っています。
IETF 113のRATS WGのミーティングでは、WGの活動スコープを改定するRecharterが行われました。これまでの議論に加え、
- Evidenceに加え、Attestation Resultの伝送プロトコル
- Endorsement、Reference Valueのフォーマット
の2点も、RATS WGで取り扱う対象に拡張されました。前者は、既存の伝送プロトコルの採用を前提としています。後者はVerifierに対し、検証の参考や基準となる情報のフォーマットを、新たにRATS WGで規定することが可能になりました。
このほか、Attestation Resultの取り扱いに関する提案（Attestation Result Framing）も行われました（*5）。提案内容は、Attestation Resultをシステムの安全性を示す尺度として意味を持たせる、クロスプラットフォームに対応した絶対的なデバイスの識別子の規定、Relying Partyでの機械学習などの利用を目的としたEvidence情報のResultへの全コピーなどがあったものの、RATS WGの方針として安全性の判断はプロトコル利用者のポリシーに依拠する点、既存の各業界で標準となっているデバイス識別子への対応や、プロトコル利用者によって拡張可能な識別子を規定している点、Relying PartyとVerifierの同居構成も現行可能にしている点などから、いずれも新規対応は行わない方向となりました。
TEEP WG（Trusted Execution Environment Provisioning）
TEEP WGが対象とするTEEとは、ARM TrustZoneやIntel SGXに代表される、ハードウェアベースの実行環境隔離機構を指します。この機構では、ソフトウェアの実行環境をTEEとREE（Rich Execution Environment）の2種類に分け、TEEはREEからの侵害を受けない構成になっています。暗号化や認証など重要な処理をTEE上に実装することで安全性を確保できますが、このTEE領域に対するアプリケーションやデータの配信・管理を行うプロトコルがTEEPです。
TEEPでは、アプリケーションの配信に関わるアーキテクチャを規定したTEEP Architectureと、配信サーバ・デバイス間のメッセージフォーマットを規定するTEEP Protocolの二つが、現在の主な活動アイテムです。
IETF 113では、TEEP Architectureのエリアディレクターのレビューと、その対応が報告されました（*6）。ディレクターからのコメントには、End Userの権利やTrust Modelに対する懸念が寄せられました。TEEPでは、TEE領域で動くアプリケーションは配信サーバが管理し、デバイスの所有者は介入することはできません。したがって、デバイスの所有者であっても、どのようなアプリケーションが動作するかを把握したり、制御したりすることが困難になると言えます。議論においては、End Userに対する透明性の確保や、アテステーションなどにより対応ができるのではないか、というコメントが寄せられました。
TEEP Protocolは、国立研究開発法人産業技術総合研究所の塚本明さんや私などから、前述したRATSにおけるEATの埋め込み方法や、メッセージの保護に使う暗号化スイートを宣言するフィールドの改善などを提案した（*7）ほか、TEEPにおけるRATSの使用法についても提案が行われました。
IoTデバイス関連のWGは、同時並行で標準化が進められていますが、それぞれの標準を相互に組み込んで使う前提で議論が進められています。例えば、TEEPでは配信するアプリケーションのメタデータの伝送はSUIT、配信先のデバイスのチェックにはRATSを使います。
紹介した三つのWGは、COVID-19の影響下においても、議論はリモートで活発に続けられています。一方で、これらWGがターゲットとするIoTデバイスを用いた検証やフィードバックは、個人個人の活動にとどまっており、今後対面会議が再開された際には、ハッカソンなどの開催も期待される状況です。
SCITT（Supply Chain Integrity, Transparency, and Trust）
IoTデバイスに限らず、昨今のソフトウェアやオンラインサービスは、多数のライブラリやパッケージに依存して開発されることが常態化しています。反面、この複雑性を逆手に取った、サプライチェーン攻撃が顕在化しています。
secdispatch WGではこの背景を踏まえ、SCITT（Supply Chain Integrity, Transparency, and Trust）と題する提案が行われました（*8）。SCITTは、既に標準化され用いられている、認証局の証明書発行ログ公開（Certificate Transparency; RFC 9162）の考え方をベースに、ソフトウェアなどのデータとその発行者の紐付けを公開のログに記録し、検証可能にするモデルです。ソフトウェア開発者は、ソフトウェアの公開時にClaimsという、開発者の署名が付いたデータを生成します。SCITTでは、このClaimsを公開されたLedgerに登録し、その際にLedgerへの登録証明として、Ledgerへの登録者によるカウンター署名が行われたTransparent Claimsを入手します。LedgerにはClaimsの情報がReceiptとして登録され、Transparent ClaimsにもReceiptの情報が含まれます。ソフトウェアを配布する際には、Transparent Claimsをセットで配布し、受領者はLedgerの情報と合わせて検証することができます。
この提案は、多くの参加者に好意的に受け止められたものの、対象とする課題が大きく、スコープの絞り込みが不可欠との指摘が寄せられました。提案者らはBoFを引き続き開催し、検討を継続する形になりました。
（*1） JPNIC News & Views vol.1680 第104回IETF報告 [第2弾] IoT関連報告 ～IoT機器の安全なライフサイクル管理～
（*2） A Concise Binary Object Representation（CBOR）-based Serialization Format for the Software Updates for Internet of hings（SUIT） Manifest
（*3） Firmware Encryption with SUIT Manifests
（*4） SUIT Manifest Extensions for Multiple Trust Domains
（*5） Attestation Results Framing
（*6） TEEP Architecture draft-ietf-teep-architecture-16
（*7） IETF113 TEEP Hackathon
（*8） Trustworthy Digital Supply Chain Transparency Services