Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
QUICの安全性解析と証明
Search
iseki
September 09, 2015
Technology
0
22
QUICの安全性解析と証明
http://fais.jsiam.org/2015-fall-jsiam.html
日本応用数理学会2015年度年会FAISオーガナイズド・セッションで発表した資料です。
iseki
September 09, 2015
Tweet
Share
More Decks by iseki
See All by iseki
TypeScriptで統一したアーキテクチャ
masayaiseki
0
1.2k
TypeScriptで統一したアーキテクチャ
masayaiseki
1
77
WebRTCの安全性証明をしたい
masayaiseki
0
24
Precise study on a SOA-PSA based optical signal regenerator with numerical analysis
masayaiseki
0
26
Other Decks in Technology
See All in Technology
ユーザーの声とAI検証で進める、プロダクトディスカバリー
sansantech
PRO
1
130
生成AIとM5Stack / M5 Japan Tour 2025 Autumn 東京
you
PRO
0
250
10年の共創が示す、これからの開発者と企業の関係 ~ Crossroad
soracom
PRO
1
730
AWS Top Engineer、浮いてませんか? / As an AWS Top Engineer, Are You Out of Place?
yuj1osm
2
210
「AI駆動PO」を考えてみる - 作る速さから価値のスループットへ:検査・適応で未来を開発 / AI-driven product owner. scrummat2025
yosuke_nagai
3
830
「れきちず」のこれまでとこれから - 誰にでもわかりやすい歴史地図を目指して / FOSS4G 2025 Japan
hjmkth
1
300
Adapty_東京AI祭ハッカソン2025ピッチスライド
shinoyamada
0
280
【Kaigi on Rails 事後勉強会LT】MeはどうしてGirlsに? 私とRubyを繋いだRail(s)
joyfrommasara
0
230
Performance Insights 廃止から Database Insights 利用へ/transition-from-performance-insights-to-database-insights
emiki
0
240
大規模サーバーレスAPIの堅牢性・信頼性設計 〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜
maimyyym
9
4.4k
ガバメントクラウド(AWS)へのデータ移行戦略の立て方【虎の巻】 / 20251011 Mitsutosi Matsuo
shift_evolve
PRO
2
190
能登半島災害現場エンジニアクロストーク 【JAWS FESTA 2025 in 金沢】
ditccsugii
0
560
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
32
2.3k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
4 Signs Your Business is Dying
shpigford
185
22k
Writing Fast Ruby
sferik
629
62k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Embracing the Ebb and Flow
colly
88
4.8k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Transcript
QUICの安全性解析と証明 東京工業大学 藤崎研究室 井関 正也
本研究の成果 1. QUICに適した安全性モデルの構築と証明 2. QUICに対する攻撃の発見 3. より効率的なプロトコルの設計
研究背景 より高速で安全なプロトコルの開発が急務 インターネットトラフィック 増加 電子商取引数増加 高速 安全 TLS(Transport Layer Security)が最も普及している
いくつかの問題がある
TLSの問題点 最も普及しているセキュア通信を実現するためのプロトコル 機能 Ø Encryption Ø Authentication Ø Certification 問題点
Ø TCPを用いているので通信が遅い Ø プロトコル全体では安全性が証明されていない Ø ユーザの設定によっては脆弱になる
QUICの登場 パケットがロストしても 問題がない状況がある TCPの代わりにUDPを使用 弱い暗号の組み合わせ は排除 ひとつの組み合わせを使用 プロトコル全体の安全性は証明されていない 高速化 安全性向上
Quick UDP Internet Connections
研究目的 目的 Ø QUICの安全性の解析と証明 内容 Ø 安全性モデルの構築 Ø 安全性の証明
QUICとTLSの違い Øサポートアルゴリズム Ø通信レイヤ Øハンドシェイク ØResumption
QUICとTLSの違い Øサポートアルゴリズム Ø通信レイヤ Øハンドシェイク ØResumption
QUICとTLSの違い RSA DH 鍵交換 RSA DSA 署名 AES RC4 暗号化
× × ECDH ECDSA AES × × TLS QUIC
QUICとTLSの違い Øサポートアルゴリズム Ø通信レイヤ Øハンドシェイク ØResumption
QUICとTLSの違い TCP + TLS QUIC
QUICとTLSの違い sync CHLO TCP + TLS QUIC
QUICとTLSの違い sync sync+ack CHLO TCP + TLS QUIC REJ
QUICとTLSの違い sync sync+ack ack CHLO TCP + TLS QUIC REJ
CHLO
QUICとTLSの違い sync sync+ack ack Hello CHLO TCP + TLS QUIC
REJ CHLO SHLO
QUICとTLSの違い sync sync+ack ack Hello Hello CHLO TCP + TLS
QUIC REJ CHLO SHLO
QUICとTLSの違い sync sync+ack ack Hello Hello Finish CHLO TCP +
TLS QUIC REJ CHLO SHLO
QUICとTLSの違い sync sync+ack ack Hello Hello Finish Finish CHLO TCP
+ TLS QUIC REJ CHLO SHLO
QUICとTLSの違い Øサポートアルゴリズム Ø通信レイヤ Øハンドシェイク ØResumption
TLSのハンドシェイク
TLSのハンドシェイク rc rc : random
TLSのハンドシェイク rc rc : random Ts : public ts :
secret Ts, ts
TLSのハンドシェイク rc rc : random (rs ,Ts ,σs ) Ts
: public ts : secret rs : random σs : Signature ts
TLSのハンドシェイク rc rc : random Tc : public tc :
secret (rs ,Ts ,σs ) ts Tc, tc Ts : public ts : secret rs : random σs : Signature
TLSのハンドシェイク rc (rs ,Ts ,σs ) ts Tc rc :
random Tc : public tc : secret Ts : public ts : secret rs : random σs : Signature
TLSのハンドシェイク rc rc : random Tc : public tc :
secret finc : finish msg σc : Signature (rs ,Ts ,σs ) (Tc ,σc ,finc ) ts Ts : public ts : secret rs : random σs : Signature
TLSのハンドシェイク rc (rs ,Ts ,σs ) Ts : public ts
: secret rs : random σs : Signature (Tc ,σc ,finc ) rc : random Tc : public tc : secret finc : finish msg σc : Signature
TLSのハンドシェイク rc (rs ,Ts ,σs ) Ts : public ts
: secret rs : random σs : Signature fins : finish msg fins (Tc ,σc ,finc ) rc : random Tc : public tc : secret finc : finish msg σc : Signature
QUICのハンドシェイク
QUICのハンドシェイク
QUICのハンドシェイク Ts, ts Ts : public ts : secret
QUICのハンドシェイク (ID,Ts ,σs ) Ts : public ts : secret
ID :client ID σs :Signature ts
QUICのハンドシェイク (ID,Ts ,σs ) Ts : public ts : secret
ID :client ID σs :Signature ts Tc, tc Tc : public tc : secret
QUICのハンドシェイク (ID,Ts ,σs ) Ts : public ts : secret
ID :client ID σs :Signature ts Tc Tc : public tc : secret
QUICのハンドシェイク (ID,Ts ,σs ) Ts : public ts : secret
ID :client ID σs :Signature ts Tc : public tc : secret rc : random (ID,rc ,Tc )
QUICのハンドシェイク (ID,Ts ,σs ) Ts : public ts : secret
ID :client ID σs :Signature Tc : public tc : secret rc : random (ID,rc ,Tc )
QUICのハンドシェイク (ID,Ts ,σs ) Ts : public ts : secret
ID :client ID σs :Signature Tc : public tc : secret rc : random (ID,rc ,Tc ) T* s , t* s
QUICのハンドシェイク (ID,Ts ,σs ) Ts : public ts : secret
ID :client ID σs :Signature Tc : public tc : secret rc : random (ID,rc ,Tc ) T* s
QUICのハンドシェイク (ID,Ts ,σs ) Ts : public ts : secret
ID :client ID σs :Signature Tc : public tc : secret rc : random (ID,rc ,Tc ) T* s cs = Enc( , T* s )
QUICのハンドシェイク (ID,Ts ,σs ) Ts : public ts : secret
ID :client ID σs :Signature Tc : public tc : secret rc : random (ID,rc ,Tc ) T* s cs = Enc( , T* s ) T* s , tc
QUICのハンドシェイク (ID,Ts ,σs ) Ts : public ts : secret
ID :client ID σs :Signature Tc : public tc : secret rc : random (ID,rc ,Tc ) T* s cs = Enc( , T* s )
QUICとTLSの違い rc (rs ,Ts ,σs ) fins (ID,Ts ,σs )
(ID,rc ,Tc ) cs = Enc( , T* s ) TLSのハンドシェイク QUICのハンドシェイク (Tc ,σc ,finc )
QUICとTLSの違い Ø認証 ØTLS:両側認証可能 ØQUIC:片側認証のみ Ø鍵交換 ØTLS:1つの鍵 ØQUIC:2つの鍵
QUICとTLSの違い Ø認証 ØTLS:両側認証可能 ØQUIC:片側認証のみ Ø鍵交換 ØTLS:1つの鍵 ØQUIC:2つの鍵
QUICとTLSの違い rc (rs ,Ts ,σs ) fins (ID,Ts ,σs )
(ID,rc ,Tc ) cs = Enc( , T* s ) TLSのハンドシェイク QUICのハンドシェイク (Tc ,σc ,finc )
QUICとTLSの違い Ø認証 ØTLS:両側認証可能 ØQUIC:片側認証のみ Ø鍵交換 ØTLS:1つの鍵 ØQUIC:2つの鍵
QUICとTLSの違い rc (rs ,Ts ,σs ) fins (ID,Ts ,σs )
(ID,rc ,Tc ) cs = Enc( , T* s ) TLSのハンドシェイク QUICのハンドシェイク (Tc ,σc ,finc )
QUICとTLSの違い Øサポートアルゴリズム Ø通信レイヤ Øハンドシェイク ØResumption
TLSのResumption
TLSのResumption rc rc : random
TLSのResumption rc rc : random (rs ,fins ) rs :
random fins : finish msg
TLSのResumption rc rc : random finc : finish msg (rs
,fins ) rs : random fins : finish msg finc
QUICのResumption T* s : public t* s : secret t*
s T* s
QUICのResumption T* s : public t* s : secret t*
s T* s Tc, tc Tc : public tc : secret
QUICのResumption T* s : public t* s : secret t*
s Tc Tc : public tc : secret
QUICのResumption T* s : public t* s : secret t*
s Tc : public tc : secret rc : random ID :client ID (ID,rc ,Tc )
QUICのResumption T* s : public t* s : secret Tc
: public tc : secret rc : random ID :client ID (ID,rc ,Tc )
QUICのResumption T* s : public t* s : secret Tc
: public tc : secret rc : random ID :client ID (ID,rc ,Tc ) T* s , t* s
QUICのResumption T* s : public t* s : secret Tc
: public tc : secret rc : random ID :client ID (ID,rc ,Tc ) T* s
QUICのResumption T* s : public t* s : secret Tc
: public tc : secret rc : random ID :client ID (ID,rc ,Tc ) cs = Enc( , T* s )
QUICのResumption T* s : public t* s : secret Tc
: public tc : secret rc : random ID :client ID (ID,rc ,Tc ) cs = Enc( , T* s ) T* s , tc
QUICのResumption T* s : public t* s : secret Tc
: public tc : secret rc : random ID :client ID (ID,rc ,Tc ) cs = Enc( , T* s )
QUICとTLSの違い rc (rs , fins ) TLSのResumption QUICのResumption finc (ID,rc
,Tc ) cs = Enc( , T* s ) T* s t* s
既存研究の安全性モデル ACCE[1] ØMutual authentication 攻撃者はClientとServer両方になりすましできない ØChannel security 攻撃者は通信内容を知ることができない [1] T.
Jager et al., “On the security of the TLS-DHE in the Standard Model”, CRYPTO 2012
既存研究の安全性モデル SACCE[1] ØServer authentication 攻撃者はServerになりすましできない ØChannel security 攻撃者は通信内容を知ることができない [1] H.Krawczyk
et al., “On the security of the TLS protocol: A systematic analysis”, CRYPTO 2013
既存研究の安全性モデル SACCE[1] ØServer authentication 攻撃者はServerになりすましできない ØChannel security 攻撃者は通信内容を知ることができない [1] H.Krawczyk
et al., “On the security of the TLS protocol: A systematic analysis”, CRYPTO 2013
既存研究のモデル
既存研究のモデル
既存研究のモデル
既存研究のモデル
既存研究のモデル
既存研究の安全性モデル SACCE[1] ØServer authentication 攻撃者はServerになりすましできない ØChannel security 攻撃者は通信内容を知ることができない [1] H.Krawczyk
et al., “On the security of the TLS protocol: A systematic analysis”, CRYPTO 2013
既存研究のモデル
既存研究のモデル
既存研究のモデル
既存研究のモデル
既存研究の安全性モデル SACCE[1] ØServer authentication 攻撃者はServerになりすましできない ØChannel security 攻撃者は通信内容を知ることができない [1] H.Krawczyk
et al., “On the security of the TLS protocol: A systematic analysis”, CRYPTO 2013 Resumptionに対応していない
本研究の安全性モデル RSACCE ØServer authentication 攻撃者はServerになりすましできない ØChannel confidentiality 攻撃者は通信内容を知ることができない ØChannel Binding
攻撃者は通信を乗っ取ることはできない
本研究の安全性モデル RSACCE ØServer authentication 攻撃者はServerになりすましできない ØChannel confidentiality 攻撃者は通信内容を知ることができない ØChannel Binding
攻撃者は通信を乗っ取ることはできない
本研究の安全性モデル Resumption
本研究の安全性モデル RSACCE ØServer authentication 攻撃者はServerになりすましできない ØChannel confidentiality 攻撃者は通信内容を知ることができない ØChannel Binding
攻撃者は通信を乗っ取ることはできない
本研究の安全性モデル Resumption
本研究の安全性モデル Resumption
本研究の安全性モデル RSACCE ØServer authentication 攻撃者はServerになりすましできない ØChannel confidentiality 攻撃者は通信内容を知ることができない ØChannel Binding
攻撃者は通信を乗っ取ることはできない
本研究の安全性モデル Resumption
本研究の安全性モデル Resumption
本研究の安全性モデル Resumption
本研究の安全性モデル RSACCE ØServer authentication 攻撃者はServerになりすましできない ØChannel confidentiality 攻撃者は通信内容を知ることができない ØChannel Binding
攻撃者は通信を乗っ取ることはできない QUICでは満たせない
QUICへの攻撃 (ID,rc ,Tc ) cs = Enc( , T* s
)
QUICへの攻撃 (ID,rc ,Tc ) cs = Enc( , T* s
) (ID,r’c ,T’c )
QUICへの攻撃 (ID,rc ,Tc ) cs = Enc( , T* s
) (ID,r’c ,T’c )
QUICへの攻撃 (ID,rc ,Tc ) cs = Enc( , T* s
) (ID,r’c ,T’c ) 秘密情報が一致しないため鍵の交換ができない
本研究の安全性モデル RSACCE secure ØServer authentication 攻撃者はServerになりすましできない ØChannel confidentiality 攻撃者は通信内容を知ることができない ØChannel
Binding 攻撃者は通信を乗っ取ることはできない RSACCE secure strong RSACCE secure
QUICの安全性 ØQUIC-CETV ØPKIを用いないClient認証機能
QUICの安全性 ØQUIC-CETV ØPKIを用いないClient認証機能 (pk,sk) <- KeyGen(1k) σc <- Sign(sk, ID|rc
|Tc ) cc <- Enc( ,σc ) Resumption
QUICの安全性 ØQUIC-CETV ØPKIを用いないClient認証機能 (ID,rc ,Tc ,pk, cc ) (pk,sk) <-
KeyGen(1k) σc <- Sign(sk, ID|rc |Tc ) cc <- Enc( ,σc ) Resumption
QUICの安全性 ØQUIC-CETV ØPKIを用いないClient認証機能 (ID,rc ,Tc ,pk cc ) (pk,sk) <-
KeyGen(1k) σc <- Sign(sk, ID|rc |Tc ) cc <- Enc( ,σc ) 攻撃者はCc を作成できない Resumption
QUICの安全性 ØQUIC-CETV ØPKIを用いないClient認証機能 (ID,rc ,Tc ,pk, cc ) (pk,sk) <-
KeyGen(1k) σc <- Sign(sk, ID|rc |Tc ) cc <- Enc( ,σc ) 攻撃者はCc を作成できない Resumption strong RSACCEを満たす
Concurrent Work QACCE[1] ØServer Impersonation 攻撃者はServerになりすましできない ØChannel Corruption 攻撃者は通信内容を知ることができない ØIP
spoofing 攻撃者は途中から監視している通信を乗っ取ることはで きない [1]R. Lychev et al., “How Secure and Quick is QUIC ? Provable Security and Performance Analyses”, IEEE S&P 2015
Concurrent Work QACCE[1] ØServer Impersonation 攻撃者はServerになりすましできない ØChannel Corruption 攻撃者は通信内容を知ることができない ØIP
spoofing 攻撃者は途中から監視している通信を乗っ取ることはで きない [1]R. Lychev et al., “How Secure and Quick is QUIC ? Provable Security and Performance Analyses”, IEEE S&P 2015 Resumptionでの攻撃を防げない
QUICの問題点 ØQUIC-CETVの署名は無駄 Øインタラクションの回数が多い より効率的なスキームを設計
提案法のハンドシェイク Tc, tc
提案法のハンドシェイク tc (rc ,Tc )
提案法のハンドシェイク tc (rc ,Tc ) Ts, ts
提案法のハンドシェイク tc (rc ,Tc ) Ts
提案法のハンドシェイク tc (rc ,Tc ) Ts T* s, t* s
提案法のハンドシェイク tc (rc ,Tc ) Ts T* s
提案法のハンドシェイク tc (rc ,Tc ) (Ts ,σs ,ID, cs )
cs = Enc( , T* s )
提案法のハンドシェイク tc (rc ,Tc ) (Ts ,σs ,ID, cs )
cs = Enc( , T* s )
提案法のハンドシェイク tc (rc ,Tc ) (Ts ,σs ,ID, cs )
cs = Enc( , T* s ) T* s
提案法のハンドシェイク tc (rc ,Tc ) (Ts ,σs ,ID, cs )
cs = Enc( , T* s )
提案法のResumption t* s T* s Tc, tc
提案法のResumption t* s Tc, tc
提案法のResumption t* s tc (rc ,Tc ,ID,MAC) MAC = PRF(
, T* s | Tc | ID | rc )
提案法のResumption tc (rc ,Tc ,ID,MAC) MAC = PRF( , T*
s | Tc | ID | rc )
提案法のResumption tc (rc ,Tc ,ID,MAC) MAC = PRF( , T*
s | Tc | ID | rc ) T* s, t* s
提案法のResumption tc (rc ,Tc ,ID,MAC) MAC = PRF( , T*
s | Tc | ID | rc ) T* s
提案法のResumption tc (rc ,Tc ,ID,MAC) MAC = PRF( , T*
s | Tc | ID | rc ) cs = Enc( , T* s )
提案法のResumption tc (rc ,Tc ,ID,MAC) MAC = PRF( , T*
s | Tc | ID | rc ) cs = Enc( , T* s ) T* s
提案法のResumption tc (rc ,Tc ,ID,MAC) MAC = PRF( , T*
s | Tc | ID | rc ) cs = Enc( , T* s )
提案スキーム QUIC 提案法 安全性 RSACCE sRSACCE インタラクション数 (Full handshake) 4
2 インタラクショ ン数 (Resumption) 2 2
まとめ ØRSACCE安全性モデルを提案した ØQUICがRSACCEを満たすことを証明した ØQUIC-CETVがstrong RSACCEを満たすことを証 明した Øより安全で効率的なプロトコルを提案した
ご清聴ありがとうございました