＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1498【臨時号】2017.5.9 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1498 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2017年3月26日(日)～31日(金)にかけて、米国のシカゴにて開催された第98回
IETFミーティングの報告を、vol.1492より3号続けてお届けしています。

  □第98回IETF報告

    ○[第1弾] 全体会議報告 (vol.1492)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2017/vol1492.html

    ○[第2弾] トランスポートエリア関連報告 (vol.1493)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2017/vol1493.html

    ○[第3弾] IPv6関連WG報告  (vol.1495)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2017/vol1495.html

本号ではその最終回として、セキュリティエリアでの新しい動きをまとめて
もらいました。

なおこの第98回IETFに関する報告会を、今週金曜日の5月12日13時から、JPNIC
の会議室で開催する予定です。今回のメールマガジンでは含まれなかった最新
動向も数多く取り上げられますので、ご興味があればぜひご参加ください。

    ○IETF報告会(98thシカゴ)開催のご案内
    https://www.nic.ad.jp/ja/topics/2017/20170418-01.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第98回IETF報告 [第4弾]  セキュリティエリア関連報告
                           ～セキュリティエリアでの新しい動きの灯～
                                               株式会社レピダム 菅野哲
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

IETF 98は、2017年3月25日(土)から31日(金)にかけて、米国・シカゴで開催
されました。時期的なものもあり、街中を冷たい風が吹き抜けていました。
物理的に寒い環境だったIETF 98ですが、この会議でのセキュリティエリア
で、エリアディレクターとして2011年から活動していたStephen Farrell氏が
退任して、TLS 1.3の中心的な著者であるEric Rescorla氏が就任しました。
彼が就任することで、セキュリティエリアで検討されるプロトコルが、アプ
リケーションとして利用される観点からも、示唆に富んだ判断が行われるよ
うになることが予想されます。今後、標準化されるであろうInternet-Draft
(I-D)に、大きく影響があると予想されるので要チェックです。

今回のIETF会合において、Working Group (WG) / Birds of a Feather (BoF)
が16(全体会合：1、WG：14、BoF：1)開催され、セッション数としては17とい
う結果となりました。

さて、私が執筆すると、セキュリティエリアでの動向としてTLS 1.3に関する
報告を行うものと思われるかもしれませんが、この報告では趣向を変えて、
普段だとあまり注目されていない、非WGに関する動向にフォーカスして取り
上げたいと思います。


■ 期間中に提案されたBoFの状況

IETF 98で開催を目論んでいたBoF(*1)として、Protocol for Dynamic Trusted
Execution Environment Enablement (TEEP)、Firmware Update Description
(FUD)およびInternet-level consistency (ILC)の三つがありましたが、承認
されたものはTEEPだけでした。

(*1) Birds of a Feather Meetings
     https://trac.tools.ietf.org/bof/trac/#TimeframeIETF98Chicago


■ 唯一開催されたセキュリティエリアでのBoF：TEEP

TEEP BoFは、3月28日(火)14:50から90分間のスロットで開催されました。TEEP
の目標は、動的な信頼できる実行環境を実現するための、プロトコル標準化
です。産業界では、アプリケーション層のセキュリティプロトコルの開発を
進めてきています。このプロトコルを利用することで、いつでも信頼できる
実行環境(Trusted Execution Environment；TEE)上で動作する、セキュリティ
クレデンシャル(認証情報)と、ソフトウェアの設定が許可されます。現在の
TEEとしては、家庭用ルータ、セットトップボックス、スマートフォン、タブ
レット、ウェアラブル端末などがありますが、これらの環境では独自プロト
コルが利用されています。このBoFでは、このようにTEEごとに検討されてい
る、プロトコルの標準化をめざしています。具体的なプロトコルとしては、
The Open Trust Protocol (OTrP)(*2)がI-Dとして投稿されています。

(*2) https://tools.ietf.org/html/draft-pei-opentrustprotocol

ここでは、詳細な議論を追うのではなく、どのような流れでセッションが進
んだのかについて概要を整理します。このセッションは、大別して三つの話
題が取り扱われました。一つ目として、TEEPが何を想定しているのか？とい
う概観に関する共有。二つ目は、異なる二つの信頼できる実行環境プラット
フォームとしてARM社とIntel社の製品紹介。三つ目は、TEEPで実現できるユー
スケースです。モバイルで注目を集めているPaymentやBYOD (Bring Your
Own Device)により、企業内で利用された機器に対するインストール、アップ
デートなど、OEM先に依存しない信頼されたソフトウェア管理方法およびアー
キテクチャとして、OTrPに関する紹介が行われました。BoFの最後に問題設定
について理解したか、WGを発足する必要性について、ハミングによって確認
が行われました。その結果、20人前後の賛同者がありましたが、引き続きメー
リングリスト上での議論を継続することが、セキュリティエリアディレクター
から告げられました。

今回はWG化されませんでしたが、開かれたインターネットという環境下にお
いて、さまざまなサービスとの連携が必要となってくる実社会で利用される
サービスを検討する上で、重要なポイントとなると考えられます。興味のあ
る方は、TEEPに関する情報を示しますのでご参照ください。

・TEEP BoF Overview
  https://www.ietf.org/proceedings/98/slides/slides-98-teep-teep-overview-00.pdf

・TEEP BoF Minutes
  https://www.ietf.org/proceedings/98/minutes/minutes-98-teep-00.txt


■ 期間中に開催されたBar BoFの状況

IETF 98でBoFとしての開催をめざしたものの、承認されなかった二つのBoFが
ありました。とはいえ、それぞれ文字通りBarでお酒を飲みながら、興味のあ
る技術者たちが集まって議論をするBar BoFという形式で開催されましたの
で、本報告の中で取り上げたいと思います。

○FUD (Firmware Update Description)

インターネットの技術コミュニティ全体の方向性や、インターネット全体の
アーキテクチャについて議論を行う集団である、Internet Architecture
Board (IAB)によって、2016年にInternet of Things Software Update
(IoTSU)ワークショップが開催されました。これはInternet of Things (IoT)
デバイスのための、ファームウェア更新に関するメカニズムのさまざまな課
題やギャップを議論するためのワークショップです。そこでのトピックスで
ある、ファームウェア更新メカニズムを標準化するために開催が目論まれま
したが、正式なBoFとして承認されなかったため、Bar BoFとして3月30日(木)
19時から開催されました。

参加者たちによって議論された内容を大まかに整理すると、次の通りとなり
ます。対象となるデバイスを大別すると、組み込みLinuxやAndroidなどの一
般的なオペレーティングシステムを実行するものと、メモリ管理ユニットの
サポートが不足していてしばしば二次記憶装置が100KB未満のフラッシュメモ
リという、より制約のあるシステムがあります。これらの二つのデバイスを
念頭に置いた製品の、セキュリティ機能を検討する際に気をつける必要があ
ることについて議論されました。最初に注目するトピックスとして、ファー
ムウェアの完全な書き換え、その次のステップとして、ファームウェアイメー
ジに対してどのようなメタデータセットを提供するべきか定義することを考
えました。現在、RFC4108 "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages"として規定されていますが、100KB未満のフラッ
シュでは、より制約のあるシステムでの適用が考慮されていないため、アッ
プデートが必要であるという結論になりました。この技術領域を実現するた
めには、制約のあるデバイスにおける信頼の起点を、どのように実現するの
かがポイントとなります。署名されたファームウェアを検証する仕組みを、
どのように実現するのかが非常にチャレンジングであり、面白いところだと
思います。また、興味のある方は、FUDに関する情報を示しますのでご参照く
ださい。

・メーリングリスト
  https://www.ietf.org/mailman/listinfo/fud

○ILC (Internet-level consistency)

ILCで取り扱う技術的側面としては、わかりやすい例を挙げると、分散台帳を
実現するブロックチェーンのような仕組みがあります。そのために必要とな
る、

・追加のみのログの保護
・改ざん防止されたタイムスタンプの提供
・事前の信頼関係確立なしでの相互に行われるトランザクションを安全にす
  るための、インターネット全体でのコンセンサスを取るための方法

を実現するものです。IETF Public Notary Transparency (TRANS) WGがあり
ますが、このWGはサーバ証明書の安全なロギングと監査を提供するためのデー
タ構造と運用手段を規定しているだけで、ログ間のコンセンサスやリソース
について、ログに記録するかどうかのコンセンサスがなく、ILCで検討する世
界観が実現されることで恩恵を受けられると示されていました。

Bar BoFでは、ILCが適用可能なアプリケーションについて議論を行い、強化
版のCertificate Transparency (CT)、匿名評判システムやソフトウェア／
パッケージに関する透明性が挙がり、その中でも最も魅力的だった応用例が、
IoTデバイスのためのファームウェアアップデートのバイナリ透明性でした。
強力な何らかの組織が、大規模なIoTデバイスのファームウェアを危殆化しよ
うと試みるような状況においては、例えば製造元が侵害されている場合、そ
のバイナリデータに署名を行ったとしても不十分な可能性があるという議論
が行われました。しかし対照的に、ILCを用いたとしても、世界中のログサー
バによっていくつかのデータ構造内のすべての更新を記録することは、むし
ろ製造者によるはるかに高いレベルの共謀者を必要とし、かえって非常に凶
悪なファームウェアを公開させる可能性を高めてしまうという議論も行われ
ました。また、ファームウェア更新を認証する標準としては、最初の起点と、
ある時点から透明性に関する仕組みを含めるのが最善であり、既存ファーム
ウェアのアップデートに対して透明性に関する仕組みを追加する場合、まる
で透明性が更新に関する標準のようになり、幅広く採用される可能性は低く
なるという議論も行われました。ステータスとしてはいくつかの応用例が出
てきた段階ですが、コア技術としては現在注目を浴びているブロックチェー
ン関連の技術であるため、引き続き議論が行われるかもしれません。また、
興味のある方は、ILCに関する情報を示しますので、過去にどのような議論が
行われたのかご確認ください。

・メーリングリスト
  https://www.ietf.org/mailman/listinfo/ilc

このBar BoFとして開催されたテーマは、IETFとして取り扱うべきか意見が分
かれる題材である可能性が高いものです。とはいえ今後、複雑化する社会を
踏まえると、これらのような実社会に隣接するテーマを取り扱い、安全なイ
ンターネット社会の実現に向けた取り組みを強化していく必要があると感じ
ました。今回、取り上げたような新しい取り組みについては、セキュリティ
エリア以外にも多く行われているため、自分自身が興味のあるエリアでどの
ような動きがあるのかを注目することも悪くありません。今までIETFで検討
されていることは、レイヤが低すぎて自分たちのビジネスに関係があまりな
いと感じていた方たちも、新鮮な目でどのような活動が行われているかを確
認していただけると幸いです。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃  http://feedback.nic.ad.jp/1498/e3add1ea36b8fe6e3fce7bdb105dd82c ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃  http://feedback.nic.ad.jp/1498/1e4dea67c0cf6de2962a5246a970499a ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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 News & Views vol.1498 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先  jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   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), 2017 Japan Network Information Center