IETF92報告IoT関連

https://lepidum.co.jp/ Copyright © 2004-2015 Lepidum Co. Ltd. All rights reserved.

IETF92 DallasIoT関連レポート

株式会社レピダム

前田薫 (@mad_p)

IETF92報告会 2015/04/24

IETF92報告会2015/04/24

Copyright © 2004-2015 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/

Agenda

Technical Plenary

WG: core, ace, cose

Thing-to-thing RG

IETF92

Dallas, TX

2015/03/22-27

IETF92報告会2015/04/24


自己紹介

名前前田薫@mad_p

所属株式会社レピダムシニアプログラママネージャ

コミュニティー活動 Lightweight Language

Identity Conference

http2study

業務領域

認証・認可、デジタルアイデンティティー、プライバシー

標準化支援

ソフトウェアセキュリティー、脆弱性

IETFとの関わり

IETF89 Londonより

APP, SECエリア中心

IETF92報告会2015/04/24


サマリ: IoT分野のもり上がり

Internet of Things (IoT) ホットトピック

「IoT」のバズワード化: 明確な定義を求めて

セキュリティー

プライバシー

サイドミーティングも活発 Thing-to-thing RG設立準備会

ace WG

Security discussion about IoT/6LO

IETF92報告会2015/04/24


Architectural Considerationsin Smart Object Networking

Dave Thaler + Hannes Tschofenig https://www.ietf.org/proceedings/92/slides/slides-92-iab-techplenary-2.pdf

IoTと標準化についての非常によいまとめ

以下にいくつか引用します

https://www.ietf.org/proceedings/92/slides/slides-92-iab-techplenary-2.pdf


Smart Objectの特殊性

制約がきつい(コスト、電力、メモリ、帯域)

ユーザーがいない場所で物理世界と作用する

信頼のない人間がアクセス可能な場所にある

信頼のある人間がアクセスしにくい場所に長時間存在する

IETF92報告会2015/04/24


IP接続のトレードオフ

IPを搭載するとより多くのリソースが必要(コード/メモリ/電力) インターネットに対するセキュリティが心配

IPを搭載しないとアプリケーションレイヤゲートウェイ(ALG)が必要 IETFがやったことの再発明に IP関連の知識ベースを利用できない

IETF92報告会2015/04/24


4つの通信パターン

IETF92報告会2015/04/24

Device-to-Device

Device-to-Cloud

Device-to-ALG

Back-end

Data sharing


標準化の不足まとめ

様々なスマートオブジェクトの情報/データモデル通常はIETFのスコープ外(接続性モデルは別) フォーラムが多数ある

アプリレイヤのWifi等設定 WifiアライアンスのWPSはあるがどこでも通用とはいえないデバイス内Webサーバー+ブラウザでOK。標準化ニーズがない

共通メカニズムへの要望はあるがどこで議論するのが適切か?

スマートオブジェクトは市場への時間で競争している標準化プロセスが遅すぎる

IETF92報告会2015/04/24


IoTのセキュリティー

IETF92報告会2015/04/24


IETF Recommendationsの活用

• Key management: RFC 4107

• Pervasive monitoring対策: RFC 7258:

• Crypto Agility: draft-iab-crypto-alg-agility

• Randomness: RFC 4086

• Key length: 112～128 bit [I-D.ietf-uta-tls-bcp]など

• プロトコルごとのrecommendationもあり

• Using TLS in Applications (uta) working group

• DTLS In Constrained Environments (dice) working group

https://tools.ietf.org/html/draft-iab-crypto-alg-agility-01

http://tools.ietf.org/html/draft-ietf-dice-profile-06

https://datatracker.ietf.org/wg/uta/charter/

https://datatracker.ietf.org/wg/dice/charter/


攻撃から学ぶ問題点

ソフトウエア更新

鍵管理がない

アクセス制御が不十分

通信路のセキュリティーがない

物理攻撃に対して弱い

もちろんサーバー側もセキュアに!

IETF92報告会2015/04/24


IoTをセキュアにするには

インターネットのセキュリティー技術を再利用最新水準のキー長を使うよく分析されたセキュリティープロトコルを使う Pervasive monitoringに対抗するため暗号を使う自動キー管理とデバイスごとの鍵を使う

その他のIoT関連セキュリティートピック Crypto agility は判断が難しいが検討が必要ソフトウェア更新および十分な空き領域を用意する乱数生成ハードウエアをつける脅威分析では物理的攻撃も考慮するモダンなOSコンセプトを使い、単一のソフトウェアバグによる全体障害を防ぐ

IETF92報告会2015/04/24


core WG

Constrained RESTful Environments 制限された環境でのRESTfulアクセス

CoAPプロトコルは周辺技術の検討が進み、実用化に向けて部品が整いつつある

patch, http-mapping

congestion control

resource directory, directory discovery

pubsub/REST → t2trgで

alternative transport (TCP等), negotiation


Object Security for CoAP

draft-selander-ace-object-security Client-Server end-to-end security Lightweight than DTLS

CoAPのオプションとしてJWSを定義リクエスト、レスポンスをJWSにして署名

header, options, body

新しいオプションで、BodyがJWS/JWEにカプセル化されていることを示す

→ COSEでやろう

Replay protectionのためにメッセージIDが必要→ Transaction ID JWSにkey idがある。これに加えて連番を定義

IETF92報告会2015/04/24


HTTP Mapping

draft-ietf-core-http-mapping

CoAPではメディアタイプは番号新しいメディアタイプが登録されるごとに採番することになっているマッピングプロキシだけが新しいメディアタイ名を知らない場合に情報が失われる

application/x-coap-<n>

HTTP 405のAllowを入れる場所がCoAPにはないプロキシが知っていれば他の情報、知らなければ

400

IETF92報告会2015/04/24


CoAP Pubsub

draft-koster-core-coap-pubsub

IETF92報告会2015/04/24


ace WG

Authentication and Authorization for Constrained Environments 制限された環境での認証・認可

実のある議論ができる準備が整ったユースケースがWGLC ready

draft-ietf-ace-usecases

Problem Description draft-seitz-ace-problem-description Terminologyの長い議論が結着(OAuthベース)

Actors draft-gerdes-ace-actors

認証・認可 TLS/DTLS delegation, UMA

IETF92報告会2015/04/24


ace actors

http://www.ietf.org/proceedings/92/slides/slides-92-ace-3.pdf

Less constrained levelを置く

IETF92報告会2015/04/24



Delegated CoAP AuthN/AuthR


Less constrained levelで確立したトークンをPSKとする

IETF92報告会2015/04/24



cose WG (to appear)

jose WGと同様のことをCBORベースで行う

jose WG: JSON Web Token JSONオブジェクトを文字列化し、署名・暗号化フォーマットの標準を定める

CBOR: コンパクトなバイナリフォーマット

cf: JSON, EXI, MessagePack

jose WGをrecharterするか新WGか

→ 新WGとしてcharterをドラフト中

IETF92報告会2015/04/24


COSE

JWT: JSON Web Token Header: 署名・暗号化形式、キー情報 Body: データ本体 Signature: 署名 JSONのUTF-8表現をBase64化、ドットで連結

COSE: 入れ物もCBORなのでCBOR流に Base64 → バイナリドットで連結→ 配列署名・暗号化アルゴリズムやヘッダラベルの番号化

2種類の実装が提案されている draft-schaad-cose-00 draft-bormann-jose-cose-00

IETF92報告会2015/04/24


IRTF RG Thing-to-thing設立に向けて

Thing-to-thing RG (t2trg) https://datatracker.ietf.org/doc/charter-irtf-t2trg/

https://github.com/t2trg

土日を通して長いセッション

主なトピック https://github.com/t2trg/2015-ietf92/tree/master/slides

Security Life Cycle

REST beyond HTTP

Managing the IoT

https://datatracker.ietf.org/doc/charter-irtf-t2trg/

https://github.com/t2trg/

https://github.com/t2trg/2015-ietf92/tree/master/slides


まとめ

IoTは大変もりあがっている

バズワードではないIoTに向けて

IoTの何を標準化するのか

セキュリティー

認証・認可

プライバシー

本質を見すえた議論の準備が整った

IETF92報告会2015/04/24


Any Questions? / Please Feedback!

https://lepidum.co.jp/

mailto:[email protected] / twitter: @mad_p

IETF92報告会2015/04/24

https://lepidum.co.jp/