2018.08.10

第102回IETF報告 IoT関連報告

こんにちは、アーキテクトの永田です。

2018年7月14日(土)から9日間、カナダのモントリオールにて第102回IETFミーティングが開催されました。 IETF(Internet Engineering Task Force)(※1)では様々なインターネットに関連する技術の標準化が行われており、今回はそのうちIoTに関連するいくつかの標準化動向についてご紹介します。

(※1) IETF | Internet Engineering Task Force
https://www.ietf.org/ （外部リンク）

はじめに

IoTの動向

IoT（Internet of Things, モノのインターネット）では、あらゆる「モノ」がインターネットに接続され情報をやり取りすることで、様々なサービスが提供されます。

日本政府の科学技術基本法第5期の基本指針の一つとして「Society 5.0（ソサエティ5.0）」(※2) が提唱されるなど、IoTがますます注目を集めています。 Society 5.0では経済発展と社会的課題の解決の両立により人々の生活を大きく変えることを目指しており、今後様々なシーンで機器がインターネットに接続されることにより、IoT機器の爆発的な増加や、より生活に密接した重要な用途でのIoTの活用が見込まれています。例えば、BEMS（Building Energy Management System、ビルエネルギー管理システム）など、より生活に密接なところでインターネットが活用されるようになってきています。

(※2) ソサエティ5.0 - 政府広報オンライン
https://www.gov-online.go.jp/cam/s5/（外部リンク）

IoTとIETFとの関係

このように、今後IoT機器の増加や重要な用途での活用が見込まれており、IoT普及のためにプロトコルの整備、セキュリティ対策が必要となってきます。

IETFではインターネットに関連する技術の標準化を行っており、IoTを支えるセキュリティやプロトコルの標準化も行われています。 IETFではWG（Working Group）単位で標準化の議論が行われており、WGは一つの領域（Area）に所属しています。

IETFでは、IoTに関係するWGは非常に多岐に渡りますが、IETF102で特に注目されていたWGをピックアップして紹介します。具体的には、Security AreaからSUIT WGおよびTEEP WGを、 Applications and Real-Time AreaからCBOR WGを紹介します。

SUIT WGおよびTEEP WGの詳細については後述しますが、この二つのWGは密接な関係があり「ソフトウェアの更新」という点では似ていますが、SUITがファームウェア更新に焦点を当てているのに対し、TEEPは信頼できる実行環境(TEE)でのアプリケーションの配備に焦点を当てており、住み分けがされています。

IoTセキュリティの標準化動向

IoTセキュリティの動向

近年、Miraiによるボットネット(※3)や、複数の自治体でのネットワークカメラの不正アクセスのように、IoT機器をターゲットした攻撃が多く報告されています。また、CrashOverride(※4)による送電施設への攻撃や、stuxnet(※5)による核施設への攻撃など重要インフラに対してもIoT機器への脅威が高まっています。

総務省によるIoT機器に関する脆弱性調査等(※6)では、生活に密接に関わる重要インフラで利用されるIoT機器でも多くの機器で脆弱性が検出されるなど、サイバー攻撃の脅威への対策が不十分である実態が浮き彫りとなりました。

そのため、年々増加するIoT機器に対するセキュリティ対策が、より重要になってきます。

(※3) IoTデバイスを狙うマルウェア「Mirai」とは何か――その正体と対策：超速解説 Mirai - TechFactory
http://techfactory.itmedia.co.jp/tf/articles/1704/13/news010.html（外部リンク）

(※4) JVNTA#99970831 制御システムを狙う CrashOverride マルウェアの脅威
https://jvn.jp/ta/JVNTA99970831/（外部リンク）

(※5) 核施設を狙ったサイバー攻撃『Stuxnet』の全貌｜WIRED.jp
https://wired.jp/2012/06/04/confirmed-us-israel-created-stuxnet-lost-control-of-it/（外部リンク）

(※6) 総務省｜IoT機器に関する脆弱性調査等の実施結果の公表
http://www.soumu.go.jp/menu_news/s-news/01ryutsu03_02000154.html（外部リンク）

IoTにおける脅威

IoTにおける脅威は様々なものがありますが、OWASP(Open Web Application Security Project)(※7)でInternet of Things Top Ten(※8)が公開されており、特に重要な脅威が10カテゴリーにまとめられています。これらの脅威はIoTデバイス自身だけではなく、IoTシステムを構成するクラウド・モバイルアプリ・ネットワークなど全てが考慮されています。

以下にその10カテゴリーを記載します。（それぞれの詳細はOWASPの資料を見てください。）

Insecure Web Interface（安全ではないWebインタフェース）
- 脆弱な初期パスワード、XSS、SQLインジェクションなど
Insufficient Authentication/Authorization（不十分な認証/認可）
- 脆弱なパスワードの許容、アクセスコントロールの欠如など
Insecure Network Services（安全ではないネットワークサービス）
- 不必要なネットワークサービス、脆弱なネットワークサービスなど
Lack of Transport Encryption（暗号化されていない通信路）
- インターネット経由またはローカル経由通信の暗号化の欠如、脆弱なSSL/TLSなど
Privacy Concerns（プライバシーの問題）
- 不必要な個人情報の収集など
Insecure Cloud Interface（安全ではないクラウドインタフェース）
- アカウントロックアウト機能の欠如、XSS、SQLインジェクションなど
Insecure Mobile Interface（安全ではないモバイルインタフェース）
- アカウントの推測、アカウントロックアウト機能の欠如、アカウント情報の盗聴など
Insufficient Security Configurability（不十分なセキュリティ設定）
- 権限分離の欠如、セキュリティログの欠如など
Insecure Software/Firmware（安全ではないソフトウェア/ファームウェア）
- アップデートファイルの暗号化の欠如、アップデート内容の非検証など
Poor Physical Security（脆弱な物理的セキュリティ）
- USB経由での不正アクセス、保管時のデータの暗号化の欠如など

内容を見てみると、IoTならではというカテゴリーが少ないことが分かるかと思います。これには、IoT機器ではCPUやメモリなどのリソースが少なく、十分なセキュリティ対策を実施しにくいという課題もあります。そのため、IETFではIoTなどリソース制約が厳しい環境向けのプロトコルも標準化しています。

上記のうち、No.9「Insecure Software/Firmware」は、IoTでは特に意識する必要があるカテゴリーとなります。 IoT機器は10年以上の長期間に渡って使用されるため、安全に使い続けるためには脆弱性の修正のための更新など、安全なソフトウェア管理・ファームウェア管理が必要となります。

今回は「Insecure Software/Firmware」に関連したIETFの標準化動向として、SUITとTEEPを紹介します。

(※7) OWASP | Open Web Application Security Project
https://www.owasp.org/（外部リンク）

(※8) Internet of Things Top Ten - owasp
https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf（外部リンク）

IETF標準化動向：SUIT

SUITとは

SUIT(※9)は「Software Updates for Internet of Things」の略であり、 IETF100で最初の会合（Birds of a Feather、略してBoFと呼ばれる）が実施されました。 SUITは、Class1デバイスにも適用可能なファームウェアアップデートについて議論されています。

CPU、メモリ、電力などに制約があるデバイスは”constrained devices”と呼ばれ、 RFC7228(Terminology for Constrained-Node Networks)で処理能力毎にClassが定義されています。ちなみに、制約条件向けのプロトコルなどは”constrained”がつくことが多いです。（例：CoAP：Constrained Application Protocol）

RFC7228ではClassは0〜2までの3つ定義されており、 Class1はRAMが10KiB以下、Flashが100KiB以下と制限が大きく、HTTP/TLSやXMLデータの扱いなどに非常に制約がある環境となります。（Raspberry Pi ZeroでもRAMが512MiBと桁違いに多いので、Class1デバイスの環境は如何に制限がきついか分かるかと思います。）

ファームウェア更新はいくつかのコンポーネントから構成されており、主要なものは以下とSUITでは定義しています。

ファームウェアイメージの転送メカニズム
ファームウェアイメージに関するメタデータを提供するマニフェスト、end-to-endでファームウェアイメージを守るための暗号化情報
ファームウェア情報そのもの

SUIT WGではこのうち1、2について標準化を行なっており、それぞれインターネットドラフト（Internet Drafts, I-Dと呼ばれるRFC前の草稿）として、IETF102時点では1本ずつ投稿されています。

(※9) Software Updates for Internet of Things (suit)
https://datatracker.ietf.org/wg/suit/about/（外部リンク）

SUITの標準化動向

次に、IETF102含めたSUITの標準化動向を紹介します。

IETF102 hackathon
SUIT Architecture
SUIT Information Model

最初のトピックはhackathonです。

SUITは今回のIETF102から初めてhackathonに参加しましたが、リモート参加含めて19名が参加するなど非常に盛況でした。またhackathonのbest projectの投票ではbest projectの一つに選ばれるなど、非常に注目を集めていました。また、SUITのhackathonでは、CBORでエンコードしたマニフェストをCOSEで署名したものを、 ARMのmbed OSのプロトタイプボードで解析・検証する事に取り組んでいました。（CBORについては後述します）プロトタイプボードの写真は、SUITのhackathonレポート(※10)にあるので、興味がある方はレポートを読んでみて下さい。

2つ目のトピックはSUITアーキテクチャです。ファームウェアアップデートのアーキテクチャが「A Firmware Update Architecture for Internet of Things Devices」(※11)としてまとめられています。 IETF102ミーティングでは、-00（第1版）から-01（第2版）への変更点が発表されました。主に用語の追加、動作モードの更新、ファームウェア更新サンプルの追加になります。 SUITアーキテクチャについては、次の章で概要を紹介します。

最後のトピックは、マニフェスト用の情報モデルです。ファームウェアアップデートに対して脅威のモデル化から行い、マニフェストに必要な項目をピックアップしたものが「A Firmware Update Architecture for Internet of Things Devices」(※12)のI-Dとして整理されています。 IETF102ミーティングでは、-00（第1版）から-01（第2版）への変更点が発表されました。マニフェスト用の情報モデルでは、脅威モデルを基にセキュリティ要件のリストアップ、およびユーザーストーリーを基にユーザビリティ要件のリストアップを行っており、これらを整理した結果をマニフェストの項目としてまとめています。

(※10) Hackathon Report (slides-102-suit-hackathon-report-00)
https://datatracker.ietf.org/meeting/102/materials/slides-102-suit-hackathon-report-00（外部リンク）

(※11) draft-ietf-suit-architecture-01, A Firmware Update Architecture for Internet of Things Devices
https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/（外部リンク）

(※12) draft-ietf-suit-information-model-01, Firmware Updates for Internet of Things Devices - An Information Model for Manifests
https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/（外部リンク）

SUITのアーキテクチャ

A Firmware Update Architecture for Internet of Things Devices のI-Dの内容を基に概要を紹介します。

このI-Dでは、制限のあるデバイスにおいて、確実で安全なファームウェア更新メカニズムへの要件などを定義しています。

要件として現状は次の10個が定義されています。

Agnostic to how firmware images are distributed（ファームウェア配布方法への非依存）
- USB, WiFi, BLE, LPWANなど様々な方法でファームウェアイメージは伝達可能
Friendly to broadcast delivery（ブロードキャスト配信への親和性）
- 特定のブロードキャストプロコトルはSUITでは指定しないが、ブロードキャストへの親和性は考慮
Use state-of-the-art security mechanisms（最先端のセキュリティメカニズムの使用）
- ファームウェア作成者（author）とデバイス間のend-to-endセキュリティ
- ハッシュベース署名など、耐量子でセキュア署名（post-quantum secure signature）の検討
Rollback attacks must be prevented（ロールバックアタックの防止）
- 脆弱性のある古いファームウェアに差し替えることで攻撃者がその脆弱性を利用して攻撃することの防止
High reliability（高信頼性）
- アップデート時含め、いつ電源断となっても機器が故障しないこと
Operate with a small bootloader（小さなブートローダーでの操作）
- ブートローダーは最小限でなくてはならず、Flashサポートと暗号プリミティブのみ持ち、オプションで回復メカニズムを持つ
Small Parsers（小さなパーサー）
- パーサーは既知のバグの原因のため、最小でなくてはならない
Minimal impact on existing firmware formats（既存のファームウェアフォーマットへの影響の最小化）
- ファームウェアアップデートメカニズムの設計では、既存のファームウェアフォーマットの変更を要求してはならない
Robust permissions（堅牢なアクセス許可）
- 認可ポリシーは通信アーキテクチャから分離
- デバイス更新前に複雑なポリシー決定が必要な場合も考慮
- 例えば、ファームウェア作成者とデバイスオペレータの両方の署名がなければ更新を拒否
Operating modes（動作モード）
- 更新動作モードは次の3つに分類される
1. Client-initiated Update（クライアントからの更新）
2. Server-initiated Update（サーバからの更新）
3. Hybrid Update（ハイブリッドな更新）

ファームウェアアップデートに関し、情報セキュリティのCIA（機密性（Confidentiality）、完全性（Integrity）、可用性（Availability））の観点で、幅広く要件が挙げられていることが分かるかと思います。

その他、本I-Dには以下の記載もありますので、興味がある方はぜひ読んでみてください。

デバイス更新ステップ毎の実施内容
マニフェストのクレームによるアップデートプロセスへの指示内容
デバイス、ファームウェアサーバなどの、コミュニケーションアーキテクチャ
ファームウェアアップデートの対象となるデバイスアーキテクチャ例（例：Single CPU SoC）
ファームウェアアップデートの処理フロー

IETF標準化動向：TEEP

TEEPとは

次にIoTセキュリティ関連のWGからTEEP(※13)を紹介します。

TEEPは「Trusted Execution Environment Provisioning」の略であり、信頼できる実行環境（Trusted Execution Environment (TEE) ）でのアプリケーションのライフサイクル管理のプロトコルの標準化を目的としています。TEEPは、前章で紹介したSUITとは密接な関係がありますが、SUITがファームウェア更新に焦点を当てているのに対し、TEEPはブート後のTEEでのアプリケーションの配備に焦点を当てています。

また、TEEの具体的な例としては、ARMのTrustZone(※14)とIntelのSGX(※15)が挙げられます。TEEPではこれら様々なTEEで実行される信頼されたアプリケーションに対し、ライフサイクル管理プロトコルの標準化を行なっています。なお、現状のTEEPの仕様ではIntel SGXでできることとの差異があり、IETF102で対応が議論されていました。例えばTEEPのコンセプトの一つであるセキュリティドメインがSGXではありません。その他の差異含め、議論の詳細については該当スライド(※16)を参照してください。

TEEPプロトコルでは次の3つの課題の解決を目指しています。

デバイス管理者またはサービスプロバイダが、TEE環境にアプリケーションを配備する前のデバイスのセキュリティ状態確認方法
TEEからデバイス管理者またはサービスプロバイダがアプリケーション管理権限を持っているかの確認方法
TEEが正しいことの保証

なおTEEPは、IoTのみにフォーカスした標準ではなく、IoTはTEEPで複数定義されているユースケースのうちの一つとなっています。

(※13) Trusted Execution Environment Provisioning (teep)
https://datatracker.ietf.org/wg/teep/about/（外部リンク）

(※14) ARM TrustZone
https://www.arm.com/products/security-on-arm/trustzone（外部リンク）

(※15) Intel Software Guard Extensions
https://software.intel.com/en-us/sgx（外部リンク）

(※16) Recommendations for TEEP Support of Intel SGX Technology
https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-recommendations-for-teep-support-of-intel-sgx-technology-02（外部リンク）

TEEPの標準化動向

次に、IETF102含めたTEEPの標準化動向を紹介します。

TEEPでは、IETF102現在、次の2つがI-Dとして議論されています。

Trusted Execution Environment Provisioning (TEEP) Architecture(※17)
The Open Trust Protocol (OTrP)(※18)

一つ目のTEEPアーキテクチャのI-Dでは、TEEPのユースケース、TEEなどのコンポーネントとコンポーネント間の関連、トラストアンカー（認証の基点）、キーと証明書種別など、TEEPプロトコルの基になるアーキテクチャが定義されています。

二つ目のOpen Trust Protocol(OTrP)では、プロトコルの具体的な内容を定義しています。 OTrPの目的は、様々なデバイスの異なるTEEで動作する信頼されたアプリケーション（Trusted Application、TA）を管理するための相互運用の可能な（interoperable）プロトコルを定義することです。

OTrPではTAM(Trusted Application Manager)とTEE間の信頼されたメッセージプロトコルを定義しており、 end-to-endのセキュリティメカニズムを使用しています。具体的には、JSON Web Encryption (JWE)、JSON Web Signature (JWS)、JSON Web Key (JWK)を使用しています。OTrPではメッセージペイロードのみ定義されており、トランスポートはHTTPSなど一般的なものが想定されています。

また、プロトコルとしては大きく分けて、以下の3つに分かれています。

デバイス情報取得
- TA操作のため、デバイスのTEEの状態を照会するためのコマンド。SD管理やTA管理の前に使用される。
SD管理
- セキュリティドメイン(Security Domain, SD)は、TAのTEE内でのセキュリティ境界に使用される。このSDの作成・更新・削除を行うコマンド。
TA管理
- TAのインストール・更新・削除を行うコマンド。

(※17) Trusted Execution Environment Provisioning (TEEP) Architecture
https://datatracker.ietf.org/doc/draft-ietf-teep-architecture/（外部リンク）

(※18) The Open Trust Protocol (OTrP)
https://datatracker.ietf.org/doc/draft-ietf-teep-opentrustprotocol/（外部リンク）

IoTプロトコルの標準化動向

ここからは、IoTプロトコル関連の紹介をします。

IoT関連のIETF/IRTF WG/RG

IoTは、CPU・RAM・通信・消費電力など様々な制約があります。

そのため、IETF/IRTF(※19)ではこれら制約が厳しい機器向けの標準化も行なっています。いくつか代表的なWG/RGを紹介します。

Applications and Real-Time Area (art)
- cbor (Concise Binary Object Representation)
- core (Constrained RESTful Environments)
Internet Area (int)
- lpwan (IPv6 over Low Power Wide-Area Networks)
- ipwave (IP Wireless Access in Vehicular Environments)
- 6lo (IPv6 over Networks of Resource-constrained Nodes)
- lwig (Light-Weight Implementation Guidance)
- 6tisch (IPv6 over the TSCH mode of IEEE 802.15.4e)
Routing Area (rtg)
- roll (Routing Over Low power and Lossy networks)
Security Area (sec)
- ace (Authentication and Authorization for Constrained Environments)
IRTF(Internet Research Task Force)
- t2trg (Thing-to-Thing Research Group)

制約環境下向けということで、Constrained（制限された）、Low Power（低電力）、Vehicular Environments（車載環境）というキーワードが多いですね。

今回はこのうち、他WGからもよく参照されているcborを紹介します。

(※19) IRTF | Internet Research Task Force
https://irtf.org/（外部リンク）

IETF標準化動向：CBOR

CBORとは

CBORはConcise Binary Object Representationの略であり、 CORE、ACE、SUITなど、IETFの様々なWGで参照されています。

現在はRFC7049(※20)が発行されており、以下の特徴があります。

JSONフォーマットをバイナリで表現し、JSONよりもサイズが小さい
JSONよりもデータ型の種類が多い
CBORパーサーが小さなコードサイズに出来るように設計（解析しやすいフォーマットなど）、CBORデータサイズよりもCBORパーサーのサイズを小さい方が優先度が高い
拡張性のあるデータフォーマット

IoTなどリソース制約の厳しい環境でも使えるようにと、CBORパーサーのサイズが優先度が高いのが大きな特徴となります。次に、JSONと比べて型が多いのが特徴です。CBORの型はMajor Typeと呼ばれ、0から7まで定義されています。

Major type 0: 符号なし整数(unsigned integer)、更にuint8、uint16、uint32、uint64に分類される（big-endian）
Major type 1: マイナス数値(negative integer)、更にuint8、uint16、uint32、uint64に分類される（big-endian）
Major type 2: バイト文字列(byte string)、長さは無制限（文字列バイトの指定 or break文字指定）
Major type 3: テキスト文字列(text string)、UTF-8文字列、長さは無制限（文字列バイトの指定 or break文字指定）
Major type 4: 配列(array)、長さは無制限（項目数の指定 or break指定）
Major type 5: マップ(map, JSONだとobject)、キー・値のペアを列挙、長さは無制限（ペア数の指定 or break指定）
Major type 6: 拡張用のオプション領域、次のものを現状定義：　日時型(Standard date/time, Epoch-based date/time)、多倍長整数(bignum)、固定小数点(Deciaml)、base64、正規表現(Regular expression)、MIME message
Major type 7: 浮動小数点(floating-point numbers)、更にfloat16、float32、float64に分かれる。また、真偽値（Boolean）、Null、Undefinedも定義

JSONは、数値型(int,float含む)、文字列型、真偽値、配列、オブジェクト、Nullしか型ありませんので、かなり細かく分類されていることが分かるかと思います。

CBORのフォーマットは、Major Typeが1byteで定義され、その後0-Nbytesで実際の値が定義されます。この1byteのMajor Typeの表現は「Initial Byte」と呼ばれ、 RFCでは「Appendix B. Jump Table」にまとまっています。このJump Tableを把握するとCBORのバイナリデータが読めるようになります。

具体例を以下に記載します。

10 –> cbor: 0x0a
- Jump Tableでは、Integer 0x00..0x17 (0..23) に該当。23までの整数はInitial Byteで値も兼ねることができる。
100 –> cbor: 0x18 64
- Jump Tableでは、Unsigned integer (one-byte uint8_t follows)に該当。その後の1byteの0x64が値。
1000 –> cbor: 0x19 03 e8
- Jump Tableでは、Unsigned integer (two-byte uint16_t follows)に該当。その後の2byteの0x03 e8が値。
“IETF” –> cbor: 0x64 49 45 54 46
- Jump Tableでは、UTF-8 string (0x00..0x17 bytes follow) に該当。Initial Byteが0x64のため、0x60(UTF-8 stringの基底)引いた0x04が文字列のbyte。それに続く0x49 45 54 46がUTF-8文字列。

CBOR playground(※21)で、JSONをCBORに変換できますので、色々と試してみてください。

(※20) Concise Binary Object Representation (CBOR)
https://tools.ietf.org/html/rfc7049（外部リンク）

(※21) CBOR playground
http://cbor.me/（外部リンク）

CDDLとは

CBORでは、CBORのスキーマ定義を標準化しており、Concise data definition language (CDDL)(※22)と呼ばれます。 CBORを使用するプロトコルなどでよく用いられるため、CBORと合わせてCDDLについても紹介します。

CDDLは以下の目的を持っています。

CBORデータ構造の記述
自由に表現できる柔軟性
必要に応じてフォーマットの制限が可能
CBORの肩を表現できる
人および機械で読み書きができる
データフォーマット準拠チェックの自動化
CBORの将来拡張への拡張性

また、JSONのデータモデルがCBORのデータモデルのサブセットであるため、CDDLはJSONデータ構造の定義にも使うことが出来ます。

CDDLの基本的な構文は、ABNF(※23)に着想を得ており、ABNFに近い記述となります。その他、以下のような記載ルールがあります。

エントリーの出現規則
- オプション(?)、0個以上(*)、一つ以上(+)、個数範囲指定(n * m)
事前定義名
- “uint”: 符号なし整数、”float64”: IEEE754倍精度浮動小数点、”tstr”: 文字列
配列、マップ、構造体、テーブル
値の指定、制限
- byteサイズ、正規表現、論理条件(and/within)、比較演算子（大小等価比較）
総称型（Generics）
値の選択

(※22) draft-ietf-cbor-cddl-03, Concise data definition language (CDDL)
https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/（外部リンク）

(※23) Augmented BNF for Syntax Specifications: ABNF
https://datatracker.ietf.org/doc/rfc5234/（外部リンク）

おわりに

今回はIETFでのIoT向けの標準化動向を紹介しました。 IETFでは、IoTに関連してたセキュリティやプロトコルなど様々な標準化が行われていること、着実に標準化が進んでいるということが、皆様に伝われば幸いです。

レピダムならびにココングループでは、IoTセキュリティに関してリスクアセスメントなどのコンサルタント、IoTシステムの脆弱性診断に取り組んでいます。興味のある方は、ぜひお気軽にお問い合わせください。

お問い合わせはこちら： https://lepidum.co.jp/contact/