━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1923【臨時号】2022.6.6 ◆
  _/ＮＩＣ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
---------- PR --------------------------------------------------------
┏━━━━━━━━━━━━━━━━━━━━━━┓
┃Internet Week ショーケース 徳島・オンライン ┃2022/6/23(木)～24(金)
┗┳━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━┓
  ┃今回はハイブリッド開催です！https://www.nic.ad.jp/sc-tokushima/ ┃
  ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1923 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2022年3月下旬にオンラインで開催された第113回IETFミーティングのレポー
トを、vol.1919より連載にてお届けしています。第2弾となる本号では、IoT
デバイスのマネジメントに関連した動向をご紹介します。

なお、本号の内容は、JPNICブログでもご覧いただけます。発表資料などへの
リンクも辿りやすくなっておりますので、ぜひブログでご覧ください。

  第113回IETF報告 [第2弾]  ～IoTデバイスマネジメント関連～
  https://blog.nic.ad.jp/2022/7621/

また、第1弾についても、下記のURLよりご覧いただけます。

  第113回IETF報告 [第1弾]  ～IETF 113で行われたHotRFCやBOF～
  https://blog.nic.ad.jp/2022/7518/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第113回IETF報告 [第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として標
準文書を発行済みであり、現在はマニフェストのバイナリ記述方法や、高度
なソフトウェア更新機能、ソフトウェア更新の結果報告機能が議論されていま
す。

(*1) JPNIC News & Views vol.1680
     第104回IETF報告 [第2弾]  IoT関連報告
     ～IoT機器の安全なライフサイクル管理～
     https://www.nic.ad.jp/ja/mailmagazine/backnumber/2019/vol1680.html

○マニフェストのバイナリ記述方法(*2)

  マニフェストは、改ざんなどの攻撃への対策として、署名を含めることが
  できます。今回のIETF 113では、この署名アルゴリズムとしてHSS-LMS方式
  の耐量子計算機暗号アルゴリズムを追加し、実装を必須化すべきという提
  案がなされました。IoT機器は数十年単位で運用されることも多く、長期間
  安全性を確保するために必要という狙いで提案がなされましたが、リソー
  ス制約が大きいIoT機器に対して実装を強制することは可能なのかという指
  摘があったほか、耐量子計算機暗号アルゴリズムはHSS-LMS以外の方式の提
  案や標準化が行われており、これらの比較なども踏まえて議論すべきとの
  指摘がありました。またこれに関連し、暗号化アルゴリズムに関する規定
  は、バイナリ記述方法の文書から分離すべきという意見も出されました。

  (*2) A Concise Binary Object Representation (CBOR)-based 
       Serialization Format for the Software Updates for Internet of 
       Things (SUIT) Manifest
       https://datatracker.ietf.org/doc/draft-ietf-suit-manifest/

○高度なソフトウェア更新機能

  高度なソフトウェア更新機能として議論されている対象には、暗号化され
  たファームウェアを用いた更新(Firmware Encryption)(*3)、ならびにソフ
  トウェア間の依存関係を表現できるマニフェストの拡張(Multiple Trust
  Domains)(*4)があります。IETF 113では、暗号化されたファームウェア更
  新機能について、ARM社のHannes Tschofenig氏がハッカソンを実施し、同
  氏が提案する更新手法についての報告、ならびにドラフトのアップデート
  を行いました。後者はマニフェストの拡張として、今回のIETF 113からWG
  アイテムとして追加されました。こちらは提案者から、実装によるフィー
  ドバックが欲しいとのコメントが寄せられています。

(*3) Firmware Encryption with SUIT Manifests
     https://datatracker.ietf.org/doc/draft-ietf-suit-firmware-encryption/

(*4) SUIT Manifest Extensions for Multiple Trust Domains
     https://datatracker.ietf.org/doc/draft-ietf-suit-trust-domains/


■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の同居構成も現行可能にしている点などから、いずれも新規対応は
行わない方向となりました。

(*5) Attestation Results Framing
     https://datatracker.ietf.org/meeting/113/materials/slides-113-rats-attestation-results-framing-00


■ 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デバイスを用
いた検証やフィードバックは、個人個人の活動にとどまっており、今後対面
会議が再開された際には、ハッカソンなどの開催も期待される状況です。

(*6) TEEP Architecture draft-ietf-teep-architecture-16
     https://datatracker.ietf.org/meeting/113/materials/slides-113-teep-teep-architecture-00.pdf

(*7) IETF113 TEEP Hackathon
     https://datatracker.ietf.org/meeting/113/materials/slides-113-teep-hackathon-report-02


■ 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を引き続き開催し、検討を継続する形になりました。

(*8) Trustworthy Digital Supply Chain Transparency Services
     https://datatracker.ietf.org/meeting/113/materials/slides-113-secdispatch-trustworthy-digital-supply-chain-transparency-services-00


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
      わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
                  ◇              ◇              ◇
            メールマガジン以外でも、情報を発信しています！
             JPNICブログ  https://blog.nic.ad.jp/
                 Twitter  https://twitter.com/JPNIC_info

          YouTubeでは初心者向けセミナー資料を公開しています
       https://www.youtube.com/channel/UC7BboGLuldn77sxQmI5VoPw
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃ https://feedback.nic.ad.jp/1915/b086344793c4a3f72226cad9453cfe48 ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃ https://feedback.nic.ad.jp/1915/d0912de28fba8a5e9f3ba86c58c45386 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ━━ JPNICへのご連絡/お問い合わせは極力電子メールでお願いします ━━
┏━◇【COVID-19に対応したJPNICの業務について】 ◇━━━━━━━━━┓
        https://www.nic.ad.jp/ja/profile/covid-19.html
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
 ■ 各種お問い合わせ先：https://www.nic.ad.jp/ja/profile/info.html ■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 JPNIC News & Views vol.1923 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田2-12-6 内神田OSビル4階
 ＠ 問い合わせ先 jpnic-news@nic.ad.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
   ◇ JPNIC Webにも掲載していますので、情報共有にご活用ください ◇
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■     News & ViewsはRSS経由でも配信しています！    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  https://www.nic.ad.jp/
■■

Copyright(C), 2022 Japan Network Information Center