IETFにおける暗号アルゴリズムを⽤いた
通信プロトコルの現状と今後の展望

菅野 哲
株式会社レピダム
CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

本講演の聞きどころ？！

＜講演タイトル＞
IETFにおける暗号アルゴリズムを⽤いた
通信プロトコルの現状と今後の展望＜本講演で知って・考えてもらいたいこと＞
IETFという標準化団体の存在と役割
n IETFでの暗号技術の採⽤状況とその役割
n CRYPTRECとして何ができるのかn

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

2

本⽇のアジェンダ
n

準備
n

n

IETFとは

本題

IETFと暗号アルゴリズムの関係
n IETFでの暗号が使われている通信プロトコルn 通信プロトコルの現状n

具体例：SSL/TLS
n 暗号技術の側⾯からCRYPTRECとIETFを⽐較
nn

n

今後の展望

我々はどうすべきか

暗号利⽤の⼒学が変わってきているのでは？
n インターネットでの暗号技術の利⽤に追従するには・・
n CRYPTRECに期待すること
nn

まとめ

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

3この⼈、誰？
n名前
nn

所属
nnn

菅野 哲（かんの さとる）
株式会社 レピダム 取締役
ISOC-JP プログラム委員

どんなことやっていた／やっているの？
n

学⽣時代〜
nn

暗号プロトコルの研究、暗号製品を売り歩く（？）

社会⼈〜

暗号ライブラリや情報セキュリティ関連システム開発
n Camelliaに関する標準化活動
nnn

RFCを何本か発⾏n

⼈事部で⼈材開発

n

会社に関することは何でも！？

（ここ最近）CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

4株式会社レピダムって・・・？

エッジの効いた技術でお客様の事業を加速させる燃料技術シード・企業研究所・⼤学・標準化団体

開発力

専門性

HUB力

事業ニーズ
・事業会社
・⾃治体
・新規ビジネス

具体的な技術領域：「標準化⽀援、アイデンティティ、プライバシ、認証・認可、情報セキュリティ」に関する開発、調査・コンサル
CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

5

本⽇のアジェンダn

準備nn

IETFとは

本題

IETFと暗号アルゴリズムの関係
n IETFでの暗号が使われている通信プロトコルn 通信プロトコルの現状n

具体例：SSL/TLS
n 暗号技術の側⾯からCRYPTRECとIETFを⽐較
nnn

今後の展望

我々はどうすべきか

暗号利⽤の⼒学が変わってきているのでは？
n インターネットでの暗号技術の利⽤に追従するには・・n CRYPTRECに期待すること
nn

まとめ

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

6

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

7

IETFとは（1/5）
nInternet Engineering Task Force
nn

理念
nn

インターネットに関する技術の国際標準を策定する組織“We reject kings, presidents and voting. We believe in roughconsensus and running code.” David Clark (1992)

⽣産物
n

RFC （Request for Comments）を発⾏
nn

活動

インターネットを技術的な側⾯を⽀えられている

年3回開催（3⽉、7⽉、11⽉）で１週間
n 参加者数：1000〜1500⼈
n 参加費：700USD
n 参加資格：誰でもOKn

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

8

IETFとは（2/5）
Open Standard

ISOC

IETF
IRTF

その他標準化団体

IEEE＜IETF以外の標準化団体＞
••
•
•
•

ITU-T

ISOC （Internet SOCiety）
W3C
インターネットのオープンな開発・利⽤等を保証する国際組織
・
IRTF （Internet Research Task Force） ：・
インターネットの未来において重要と思われる研究を推進する組織
・
ITU-T :
国際電気通信連合において通信分野の標準化策定を担当する電気通信標準化部⾨IEEE :アメリカに本部を持つ電気電⼦技術学会
W3C :World Wide Webで使⽤される各種技術の標準化の推進を⽬的に設⽴された団体
CRYPTRECシンポジウム２０１７

https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

9補⾜情報1：標準化団体の⽐較

トップダウン

標準化スタイルはISOはトップダウン、IETFはボトムアップ
ISOIETF
Implementation Oriented（まずは実装をする）

Hard Specification（仕様は変わらない）

Soft Specification（仕様は変わっていく）

Quality of Service

Connectivity

Voting

Running Code & RoughConsensus

Membership

Volunteer
CRYPTRECシンポジウム２０１７

https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

ボトムアップSpecification Oriented（まず仕様を決める）

10

補⾜情報2：標準化の種類
標準化ドキュメントには⼤きく分けて２種類が存在
nデジュール標準De jure = 法的に正式
n 国際的な取り決めが必要／正式な会議での議論および決定
n 例：ISO、ITU、JIS etc.
nn

デファクト標準

De facto = 事実上の標準n 製品が広く受け⼊れられ、事実上の標準
n 市場ドリブン
n 例：IETF、W3C etc.
n

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

11

IETFとは（3/5）
https://datatracker.ietf.org/wg/

IETF
ART
WG

WG

INT
WG WG

7 Area122WGs(2017.11現在)

WG

SEC
WG WG

WG

TSV
WG

WG

GEN （General） : 1
ART （Applications and Real-Time） :35
INT （Internet） : 18
OPS （Operations and Management） : 16
RTG （Routing） : 25
SEC （Security） :15
TSV （Transport and Services） : 12
CRYPTRECシンポジウム２０１７

https://lepidum.co.jp/WG

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

12

WG

補⾜情報3：エリアと代表的なWG
IETFだけにインターネットに関連した技術の技術的な検討を中⼼として実施
代表的なWG

エリア

IETF

IRTF

GEN
ART
INT
OPS
RTG
SEC
TSV

mtgvenue
httpbis, uta, dcrup etc.
6man, 6lo, lwig etc.
dnsop, v6ops etc.
ospf, sidr etc.
tls, ipsecme, curdle etc.
quic, tcpinc etc.
cfrg, t2trg etc.
CRYPTRECシンポジウム２０１７

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

13

IETFとは（4/5）

⾃由な雰囲気＆やり過ぎな⾯も？！:)CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

14

IETFとは（5/5）

個⼈が所属や国を超えた活発な議論

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

15

IETFで発⾏されるRFCってなんだろう？
n

気になるポイントどのように発⾏されるの？（プロセス）n どんな種類のドキュメントがあるの？
n＜RFCの具体例＞

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

16

RFCの標準化プロセスn

RFC発⾏までの流れ（概略）ブラッシュアップWGドキュメント、個人投稿のドキュメント
提出

懸念事項

IESG

RFCエディタ

Last Call

コメント、示唆

IETFコミュニティ
レビュCRYPTRECシンポジウム２０１７
https://lepidum.co.jp/Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

RFC発行
17RFCの種類
RFCは⽬的・⽤途によって以下のようなにカテゴリに分類
nStandard Trackn

Best Current Practice(BCP), Proposed Standard(PS), InternetStandard(STD)の３種類
BCP ： 現時点における最良の⽅法
n PS： 良いアィディアであり、問題が報告されていない⽅法
n STD ： 上記に加えて、安定＆インターネットに有益な⽅法
nnInformationalnnnExperimentalnn

業界にとって有益だと考えられる情報であり、情報提供が⽬的ベンダの独⾃仕様や特定分野で既にデファクトとして利⽤されているプロトコルなど研究や実験⽬的の扱いとされる⽅法

Historicaln

過去に標準化されたが既に使⽤されなくなったRFCやその技術がインターネットにとって有害であると判断されたRFC
CRYPTRECシンポジウム２０１７

https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

18

IETFで標準化された通信プロトコルは？
誰もが聞いたことのある通信プロトコルが多数存在しており、我々の⽣活を⽀えているnアプリケーションnn

トランスポートnn

TCP、UDP、SCTP etc.

インターネット
nn

DNS、FTP、HTTP、POP3、TELNET、TLS、SSH etc.

ICMP、IPv4、IPv6、ARP etc.

リンクn

PPP etc.
CRYPTRECシンポジウム２０１７

https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

19ざっくりとIETFをまとめる
n

組織的側⾯

“ラフコンセンサス”と”動作する実装”を武器にインターネットを推進
n IETFだけでなくIRTFという将来的なことを想定した組織体も存在
nn

仕様的側⾯変更することが前提の仕様であるRFCによりインターネットを良い⽅へ先導
n ⽤途に適したドキュメントカテゴリで発⾏
nn

影響的側⾯
n

IETFで標準化された通信プロトコルが⾝の回りで広く利⽤想像しているより現代社会への影響度は⼤CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

20

本⽇のアジェンダ
n準備nn

IETFとは

本題

IETFと暗号アルゴリズムの関係
n IETFでの暗号が使われている通信プロトコルn 通信プロトコルの現状n

具体例：SSL/TLS
n 暗号技術の側⾯からCRYPTRECとIETFを⽐較
nnn

今後の展望

我々はどうすべきか

暗号利⽤の⼒学が変わってきているのでは？
n インターネットでの暗号技術の利⽤に追従するには・・
n CRYPTRECに期待すること
nn

まとめ

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

21

IETFと暗号アルゴリズムの関係

インターネットの拡⼤・成⻑により暗号技術が重要に！
n

過去（黎明期）n

セキュリティは不要
nn

現在n

特定の個⼈との接続だったためセキュリティは必要というか必須n

不特定多数が利⽤するようになったため認証やデータの完全性などを実現するために要素技術として暗号技術の導⼊へ
CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

22

IETFでの暗号が使われている通信プロトコル
暗号技術を利⽤した通信プロトコルは想像以上に多い
IPsec
n Kerberosn APOPn RADIUSn SSL/TLSn DTLSnIKEn CRAM-MD5
n MIKEYn CoAP
nnなど

ある時まで・・・

IETFの黎明期から標準化されているためレガシー化しているものが多く存在
CRYPTRECシンポジウム２０１７https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

23

あの事件を覚えていますか・・・

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

24スノーデン事件・・・

追加

2013年6⽉にエドワード・スノーデン⽒によって暴露された⼀連の出来事
n 情報収集プログラム PRISM（プリズム）nnn

グーグルやアップル、フェイスブック、ヤフーなど⼤⼿ネット企業が持つデータにアクセス？！

事例: 暗号技術への影響
n

乱数⽣成アルゴリズム Dual_EC_DRBG (Dual Elliptic
Curve Deterministic Random Bit Generator)
2006年 SP800-90Aとして規定
n 2013年9⽉ 利⽤しないよう推奨する勧告
n

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

25

Before / After IETF88（1/2）

IETF88 Technical Plenary (Nov, 2013)2013年6⽉に明らかになったPRISMによる「PervasiveSurveillance」に対してどうすべきかを検討！
Surveillanceはインターネットへの攻撃と認識！
どのように技術的に対抗すべきか検討する流れ
CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

26

Before / After IETF88（2/2）
IETF88をきっかけにIETFとしての取り組みに変化が発⽣nBefore IETF88

暗号技術は必要だけど、ちょっと⾯倒くさいn 今のままでも良いんじゃないかな？
nnAfter IETF88n

どうやったら⾝を守れるのか？を真剣に悩むn

End to End 暗号化を導⼊すべき！！

暗号アルゴリズムも与えられたものではなく、⾃分たちで検討したものを選択しよう！
n オープンな仕様以外のモノは信⽤できない
nn

例：HSMって危なくないか？という議論

暗号化熱の度が過ぎちゃっている感も・・・
CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

27

IETFにおける通信プロトコルの現状“After IETF88”から4年以上経過した現在も暗号化熱は冷めやらないn

End to End 暗号化を採⽤
nOpportunistic encryption でも⾃分たちで認めた暗号アルゴリズムを採⽤
n ⼀時的な（Ephemeral）鍵交換アルゴリズムを推奨
n 各レイヤで暗号化通信のためのプロトコルを検討
n

これによる弊害も若⼲出始めているのでは？
CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

28

SSL/TLSでの暗号技術
暗号利⽤に関する考え⽅はRFC7525によって⽅針確定
nTLS 1.2n

RFC7525 で推奨設定を策定
nn

Recommendations for Secure Use of Transport Layer Security (TLS)
and Datagram Transport Layer Security (DTLS)

暗号設定（推奨）

128ビットセキュリティ以上
n 鍵交換：DHE/ECDHE（StaticではなくEphemeral）
n 共通鍵：AES-GCM（AEAD）
nn

TLS 1.3nInternet Draft #21nn

The Transport Layer Security (TLS) Protocol Version 1.3

暗号設定

基本⽅針はRFC7525に準拠
n RSA-PSS（署名）やCurve25519、Curve448（楕円曲線）などが追加
n もちろんChaCha20-Poly1305も追加
nCRYPTRECシンポジウム２０１７
https://lepidum.co.jp/Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

29

“After IETF88” 以降で登場した暗号アルゴリズムn追加

共通鍵暗号（ストリーム暗号）
nChaCha20

2008年 DJBによって発表
n Salsa20の変形版
nn

メッセージ認証コード
nPoly1305

2005年 DJBによって発表
n ChaCha20と組合せてデータの秘匿性、完全性、認証性を同時に実現
nn

署名アルゴリズム
nEdDSA（Edwards-curve Digital Signature Algorithm）
2011年 DJBによって発表
n ツイストしたエドワード曲線に基づくシュノア署名の⼀種
nn

楕円曲線
nCurve25519 & Curve448

2005年 DJBによって発表
n この曲線を使ったECDHEはX25519やX448と表現
nCRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

30暗号技術の側⾯からCRYPTRECとIETFを⽐較

⾔わずと知れた「CRYPTREC暗号リスト」とIETF curdle WGでの活動を⽐較

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

31

CRYPTRECでの暗号技術に関する推奨リスト
n

CRYPTREC暗号リストは、現在の利⽤環境と⽐較するとギャップを感じる（個⼈的に）電⼦政府推奨暗号リスト

推奨候補暗号リスト

運⽤監視暗号リスト

http://www.cryptrec.go.jp/list/cryptrec-ls-0001-2016.pdf

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

32

IETFでの暗号技術の推進に関する動き
nIETFでの推奨暗号技術を推進： curdle WG
nn

https://datatracker.ietf.org/wg/curdle/about/

このWGの⽬的は？

古く危殆化した暗号アルゴリズムの利⽤停⽌
n IRTF cfrgで決めた暗号アルゴリズムへのアップデート
nn

具体的な活動n

利⽤停⽌させる暗号アルゴリズム
nn

MD4、MD5、SHA-1、3DES, RC4 など

推奨するアルゴリズムの対象
認証暗号
n 楕円曲線n 署名
n 鍵共有nAEAD(GCM, CCM), ChaCha20-Poly1305
Curve25519, Curve448
Edwards-Curve Digital Security Algorithm (EdDSA)ECDHE with Curve25519/Curve448(X25519/X448)
CRYPTRECシンポジウム２０１７

https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

33

イメージ的に俯瞰すると・・・
CRYPTREC、IETF/IRTF、OSSの3領域で可視化

CRYPTREC

IETF/IRTF
OSS

ギャップ増⼤働き掛けて実装促進

IETFが活発になっている現時点において実社会とのギャップが年々⼤きくなってきている
CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

34

影響把握
n

IETFでの標準化活動が、我々の⾝の回りにどの程度の影響を与えているのかを探る
調査対象プロトコル：SSL/TLSプロトコル
n 調査対象ソフトウェア：nブラウザ：Chrome、Firefox、Edgen サーバ：OpenSSL
nn

調査⼿段：
n

Qualys SSL Labsn

https://www.ssllabs.com/

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

35参考情報：Qualys SSL Labsn

追加

ホスト名を⼊⼒することでSSL/TLSの設定を把握

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

36参考情報：Qualys SSL Labsn

追加

ホスト名を⼊⼒することでSSL/TLSの設定を把握

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

37参考情報：Qualys SSL Labsn

追加

ホスト名を⼊⼒することでSSL/TLSの設定を把握

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

38

影響把握：ブラウザ（1/3）
nChrome 62.0.3202.94
・ChaCha20-Poly1305対応
・AEADにほぼ対応
・ほぼECDHEに移⾏・楕円曲線 x25519対応→ *ほぼ*IETFの推奨設定

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

39

影響把握：ブラウザ（2/3）
nFirefox 57.0 (64-bit)
・ChaCha20-Poly1305対応
・ほぼECDHE/DHEに移⾏・AEADにほぼ対応
・楕円曲線 x25519対応→ IETFでの推奨状況

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

40

影響把握：ブラウザ（3/3）
nMicrosoft Edge 40.15063.674.0
・ChaCha20-Poly1305未対応
・ほぼECDHEに移⾏・AEADにほぼ対応
・楕円曲線 x25519対応→ IETFでの推奨状況

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

41

影響把握：サーバ（1/2）
nOpenSSL 1.1.0f

・ChaCha20-Poly1305対応
・ほぼECDHE/DHEに移⾏・AEADにほぼ対応$ ./openssl ciphers -V
0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH
Au=ECDSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH
Au=RSA Enc=AESGCM(256) Mac=AEAD
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH
Au=RSA Enc=AESGCM(256) Mac=AEAD
0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH
Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH
Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAA - DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH
Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH
Au=ECDSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH
Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH
Au=RSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH
Au=ECDSA Enc=AES(256) Mac=SHA384
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH
Au=RSA Enc=AES(256) Mac=SHA384
0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH
Au=RSA Enc=AES(256) Mac=SHA256
0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH
Au=ECDSA Enc=AES(128) Mac=SHA256
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH
Au=RSA Enc=AES(128) Mac=SHA2560x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH
Au=RSA Enc=AES(128) Mac=SHA256
0xC0,0x0A - ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH
Au=ECDSA Enc=AES(256) Mac=SHA10xC0,0x14 - ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH
Au=RSA Enc=AES(256) Mac=SHA1
0x00,0x39 - DHE-RSA-AES256-SHA
SSLv3 Kx=DH
Au=RSA Enc=AES(256) Mac=SHA1
0xC0,0x09 - ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH
Au=ECDSA Enc=AES(128) Mac=SHA10xC0,0x13 - ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDHAu=RSA Enc=AES(128) Mac=SHA1
0x00,0x33 - DHE-RSA-AES128-SHASSLv3 Kx=DHAu=RSA Enc=AES(128) Mac=SHA10x00,0xAD - RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(256) Mac=AEAD
0x00,0xAB - DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256) Mac=AEAD
0xCC,0xAE - RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAD - DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAC - ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x00,0x9D - AES256-GCM-SHA384
TLSv1.2 Kx=RSA
Au=RSA Enc=AESGCM(256) Mac=AEAD
0x00,0xA9 - PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK
Au=PSK Enc=AESGCM(256) Mac=AEAD
0xCC,0xAB - PSK-CHACHA20-POLY1305 TLSv1.2 Kx=PSK
Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD→ IETFでの推奨状況

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

42

影響把握：サーバ（2/2） [参考情報, Google]n

世界で⼀番 前のめりなサーバ設定
・Chromeと準拠
・ChaCha20-Poly1305対応
・ほぼECDHE/DHEに移⾏・AEADにほぼ対応
・楕円曲線 x25519対応→ IETFでの推奨状況※ Android7ではChaCha20を優先するサーバ設定

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

43参考情報：NISTの動向
n

IRTF cfrg で検討していたCurve25519およびCurve448の楕円曲線がFIPS186-4に追加へ！

https://csrc.nist.gov/News/2017/Transition-Plans-for-Key-Establishment-Schemes
CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

44

CRYPTRECとIETFの⽐較に関するまとめn

IETFの活動が活発することによる影響
nn

⾃分⾃⾝が意図していない暗号利⽤
nn

実際に利⽤されるソフトウェアと実装されている暗号とCRYPTREC暗号リストにギャップが存在
CRYPTREC暗号リストで推奨されていない暗号アルゴ
リズムを知らないうちに利⽤する懸念

参考情報
nNISTはIETF/IRTFの暗号技術動向に追従する流れ

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

45

通信プロトコルにおける今後の展望

IETFにおける通信プロトコルに関する今後の展望を⽰す
n After IETF88で発⽣した潮流は継続しそう
IETFではIoTで利⽤するプロトコルを検討するWGが7程度あったりと⼒が⼊っている
n 影響範囲は拡⼤する⽅向
nn

OSSコミュニティとも近い関係であるため、「標準化←→実装」の連携がシームレスn

RFCで発⾏されるInternet Draftの段階から、実装のための検討が始まり、RFC発⾏と同時期に有効になる「フォーラム標準」と「OSS活動」の重要性が増加
CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

46

本⽇のアジェンダ
n準備nn

IETFとは

本題

IETFと暗号アルゴリズムの関係
n IETFでの暗号が使われている通信プロトコルn 通信プロトコルの現状n

具体例：SSL/TLS
n 暗号技術の側⾯からCRYPTRECとIETFを⽐較
nnn

今後の展望

我々はどうすべきか

暗号利⽤の⼒学が変わってきているのでは？
n インターネットでの暗号技術の利⽤に追従するには・・
n CRYPTRECに期待すること
nn

まとめ

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

47

暗号利⽤の⼒学が変わってきているのでは？
nn

全てのモノがネットワークに繋がる時代へ

構成要素としての暗号技術が素晴らしくても繋がらなければ、世界で利⽤されない
n

⾔い換えれば、通信プロトコルで世界中で広く使われるためには「繋げるための努⼒」が重要
n「オープンな仕様」＆「動作する実装」の重要性が増⼤

この世界を⾮常に上⼿に泳いでるのは Google
CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

48

インターネットでの暗号技術の利⽤に追従するには・・n

IETFでの新しい暗号技術を採⽤したRFCが発⾏されると、OSSコミュニティで実装し始めるため、新しい暗号アルゴリズムが利⽤できるライブラリ（実⾏環境）が世界中に広がるn

その速度が年々早くなってきている（ように感じる）

今まで以上に「デファクト標準」への関⼼を増す必要があると考えるCRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

49

CRYPTRECに期待すること

すでに対応されているかも知れませんが・・・
小n

CRYPTREC暗号リストに準拠した利⽤環境を⽰すn

利⽤者視点での貢献
nn

大変さ

情報収集が⼿薄になっているフォーラム標準化団体における技術的な動向を捉え、いち早く評価する対象を選定する
nn

例えば、お墨付きのソフトウェアや設定⽅法

実社会とのギャップを最⼩化するための活動”待ち”から”攻め”に転じてデジュール標準と同様にフォーラム標準にも貢献する

大n

世界でのプレゼンス向上に向けて
CRYPTRECシンポジウム２０１７

https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

50

我々、⽇本としてできること
n

インターネットはギークのためのモノではく
⽇常的に利⽤する⽣活基盤へnn安⼼・安全に利⽤できることが⼤前提

暗号技術の観点からIETFでの貢献を⾒ると、⽇本は「タダ乗り」している状況ではないか？
n

要因：研究者は研究成果に繋がらなかったり、企業として売上や利益に繋がらない謎な活動として認識

⽇本の技術・研究レベルの⾼いので彼らの研究成果をインターネットに積極的に還元するというのはどうか？

※ 難しいのは承知で・・・

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

51

本⽇のアジェンダ
n準備nn

IETFとは

本題

IETFと暗号アルゴリズムの関係
n IETFでの暗号が使われている通信プロトコルn 通信プロトコルの現状と今後の展望
nnn

具体例：SSL/TLS

我々はどうすべきか

暗号利⽤の⼒学が変わってきているのでは？
n インターネットでの暗号技術の利⽤に追従するには・・
n CRYPTRECに期待すること
nnまとめCRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

52

まとめn

IETFでの実績が、暗号技術の観点からも我々の⽣活に与える影響が、より⼤きくなってきているn例：cfrgでの選定した暗号アルゴリズム
nn

ChaCha20-Poly1305、Curve25519 など

CRYPTRECも設⽴時に想定していたスコープや速度感を現状に適⽤させるために変化しているが、インターネットを取り巻く環境は更に早いのでもう少しのテコ⼊れを期待
n

暗号技術は「国家の安全保障」にも関連しますし・・・

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

53

何か気になることなどあれば・・・
nE-mailnnkanno@lepidum.co.jp

SNSTwitter(satorukanno)n Facebook(satoru.kanno)n

お気軽にご連絡ください！

CRYPTRECシンポジウム２０１７
https://lepidum.co.jp/

Copyright © 2004-2017 Lepidum Co. Ltd. All rights reserved.

54