GPUを用いたSSLリバースプロキシの実装についての論文を読んだ
•
4 j'aime•2,486 vues
GPUを用いたSSLリバースプロキシの実装． RSA, AES, SHA-1などの暗号化アルゴリズムのGPU実装など．
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à GPUを用いたSSLリバースプロキシの実装についての論文を読んだ
Similaire à GPUを用いたSSLリバースプロキシの実装についての論文を読んだ (20)
Dernier
Dernier (10)
GPUを用いたSSLリバースプロキシの実装についての論文を読んだ
- 1. SSLShader: Cheap SSL Acceleration with Commodity Processors Keon Jang, Sangjin Han, Seungyeop Han, Sue Moon, and KyoungSoo Park, 8th USENIX Symposium on Networked Systems Design and Implementation, 2011 輪講資料 @y_uuki_ / id:y_uuki 1
- 2. Introduction 2
- 3. Introduction ‣ SSLとTLSはセキュアなトランスポート層通信のための デファクトスタンダードなプロトコル ‣ エンドポイントにおける認証とコンテンツの暗号化 ‣ しかし現在，SSLはセキュリティクリティカルなドメイ ンやエンタープライズアプリケーションのみで利用され ているだけである ‣ これは主にサーバサイドにおける計算負荷が重いため ‣ 主なボトルネックは 交換フェイズ ‣ 1024bit RSAに対して，最新のCPUで2K SSL transactions/s ‣ 暗号化しないならば，10K transactions/s 以上さばける 2013/4/17 輪講 3
- 4. Introduction ‣ 目的は，全てのプライベートなインターネット通信で SSLを導入するために，汎用プロセッサを用いた実用的 なソリューションを見つけること ‣ 2ステップのアプローチ ‣ 1. 汎用グラフィックプロセッサであるGPUを採用 ‣ 数百個のコアをもちいて，RSA，AESおよびSHA-1などの暗号化 アルゴリズムを並列処理する ‣ 数百msから数秒かけてRSAの性能を最大化するような既存の手法 ではレイテンシが大きすぎる ‣ 低レイテンシでスループットを最大化する手法を提案する ‣ 2. SSLShader: GPUを用いたSSLプロキシの作成 ‣ マルチコアCPUやNUMA，AES-NIに対応 2013/4/17 輪講 4
- 5. Background 5
- 6. SSL (Secure Sockets Layer) ‣ ClientHello, ServerHello: サポートしている暗号化手法 の中から一つを決定．サーバクライアント間の認証など ‣ クライアントはpre-master secretをサーバの公開 を 用いて暗号化 -> サーバに送信 ‣ pre-master keyを用いてサーバ・クライアントの双方 がセッションキーとMACキーを生成 ‣ セッションキーとMAC キーは暗号化に使用 6
- 7. SSLのボトルネック ‣ Web環境では，やりとりされるパケットサイズが小さい ‣ サーバ側でのpre-master secretの解読処理の回数が増 加 -> ボトルネック (RSA) ‣ パケットサイズが大きくなると，主要なオーバヘッドは 以下の2つに移行 ‣ パケットデータそのものの暗号化・解読処理（AES） ‣ MACの計算（MAC） 7
- 8. SSLで使用される暗号化方式 - RSA ‣ RSA ‣ 公開 の暗号化は秘密 の解読より，20∼60倍速い ‣ SSLサーバにとっては，RSAの計算は計算バウンドな負荷 ‣ SSLコネクションごとに，秘密 の解読を行うので，クライ アント数が多いと負荷が高まる C: 暗号文 M: 平文を整数値にしたもの 暗号化 (n,e): 公開鍵, (n,d): 秘密鍵 C,M,d,nの長さ: 1024, 2048, or 4096 bits e: 3, 17, or 65,537 解読 2013/4/17 輪講 8
- 9. SSLで使用される暗号化方式 - AES ‣ AES (Advanced Encryption Standard) ‣ 平文を128bitごとのブロックに分割し，128, 192, 256 bit の を用いて暗号化する ‣ のbit数に依存してそれぞれ10, 12, 14ラウンドの変換 ‣ HMAC (Hash-based Message Authentication Code) ‣ 通信メッセージの完全性の保証と認証 ‣ ハッシュ関数としてSHA-1を使用 H: ハッシュ関数 k: 秘密鍵 m: メッセージ ipad/opad: 予め定義される定数値 2013/4/17 輪講 9
- 10. GPU (Graphics Processing Unit) ‣ 最近のGPUは数百個のコアを持ち，グラフィックレンダ リングだけでなく，汎用計算に使用される ‣ SIMD 演算(同一算術演算子による複数の2項演算を1サ イクルで実行) ‣ GPUコードの実行単位をカーネルと呼ぶ ‣ 大量のコアを活用するために，多くのスレッドを起動 し，カーネルを並列に実行する ②カー CPU ネル実 行命令 GPU 発行 ③カーネル実行 ータ転送 GPU ① 入力デ Host メモリ ータ転送 ④ 出力デ 2013/4/17 メモリ 輪講 10
- 11. Optimizing RSA for GPU 11
- 12. RSAのGPU最適化 ‣ 低いレイテンシを保ったまま，高スループットを達成す ることが課題 ‣ 単純にCPUのコードをGPUに移植しても性能は上がら ず，GPUの計算リソースを無駄にする ‣ 1GPUスレッドの実行速度は1CPUスレッドの1/10か ら1/100程度であるため，レイテンシが増大 ‣ GPUにおけるRSAの解読の性能を最大化する重要なポ イントは並列化である 2013/4/17 輪講 12
- 13. RSAの並列化手法 message message message message ...... m m m m m m m m m m m m m m m th th th th th th th th th th th th th th th th GPU threads ‣ 各messageは独立しているため，並列処理可能 ‣ は中国剰余定理より ‣ 大きな整数値を1ワードに分割し，各ワードを複数のGPUス レッドで処理 ‣ スレッド間でワードごとの命令結果を調整するために，桁上げ・桁 下げ処理などが必要 (詳しくは省略) 13
- 14. RSAマイクロベンチマーク ‣ 並列GPU実装と逐次CPU実装の比較 ‣ メッセージ数1のとき ‣ RSA のbit長が大きいほうが並列性が高いため，GPUのほうが高 スループット ‣ メッセージ数が複数のとき ‣ message数が小さいときは，CPUのほうが高スループット ‣ message数が十分大きいときはGPUのほうが高スループット ‣ GPU実装は，6コアのCPU x 3個 に匹敵する 1 ciphertext messages RSA鍵長 1024bit 14
- 16. AESの高速化 ‣ CBCモードによる暗号化は直前のブロックの結果を次 のブロックで使うため，逐次処理しなければならない ‣ 一方，解読時は直前のブロックの結果を既に知っている ため，並列処理可能 ‣ 最適化手法 ‣ 各スレッドがlookupテーブルを共有メモリにコピー ‣ 共有メモリのほうがグローバルメモリよりも2桁速い ‣ グローバルメモリからの事前に展開された を使う代わり に，各ラウンドでラウンド を得る ‣ 計算負荷は余計にかかるが，高価なメモリアクセスを削減で き，全体のレイテンシを低下させられる 2013/4/17 輪講 16
- 17. HMAC-SHA1の高速化 ‣ HMAC-SHA1の性能はSHA1に依存しているため， SHA1を高速化すればよい ‣ SHA1単体の並列処理が難しい ‣ 入力メッセージを512bitのブロックに分割 ‣ i番目のブロックの結果をi+1番目のブロックの計算に使用 ‣ ブロックを逐次実行しなければならない ‣ GPUによるSHA1の最適化手法 ‣ レジスタにデータを置くことでGPUメモリへのアクセス削減 ‣ GPUのレジスタ数に収まるように必要データ記憶量を削減 ‣ ナイーブな実装と比較して100%の性能向上 2013/4/17 輪講 17
- 18. AES & HMAC-SHA1 ベンチマーク ‣ フローの長さをSSLの最大レコード長である16 KBに固定 ‣ AES-CBC ‣ GPU実装は約8-10Gbpsに対してAES-NI（CPU最適化版）は15Gbps ‣ CPU-GPU間のデータコピーコストを無視すると30-34Gbps ‣ HMAC-SHA1 ‣ GPU実装は最大31Gbps データコピーを無視すると最大124Gbps 128bit AES 解読 HMAC-SHA1 Throughput (Mbps) Throughput (Mbps) 18
- 19. AES & HMAC-SHA1 まとめ ‣ (i) AES-NIはドルあたりの性能が最大 ‣ (ii) CPU-GPU間のデータ転送コストにより約4倍の性能 低下 ‣ (iii) CPUがAES-NIをサポート ‣ 最近のトレンドとしてGPU統合型CPUがあるので，将 来的にはデータ転送コストは無視できる 2013/4/17 輪講 19
- 20. SSLShader 20
- 21. SSLShader ‣ スケーラブルSSLリバースプロキシ ‣ 設計目的 ‣ CPUとGPUのコア数に対して性能 がスケール Clients ... ‣ スループットを高めつつ Webなどのインタラクティブな 環境をサポートするために レイテンシを抑えるべき SSLShader Webサーバ 2013/4/17 輪講 21
- 22. 基本設計 ‣ SSLコネクションを処理するためのイベント駆動のスレッド ‣ コア数スケールのために，1CPUコアあたり1ワーカスレッド ‣ GPUオフロード処理専用にGPU-interfacingスレッドを用意 ‣ 各ワーカスレッドは暗号種別（RSA, AES, HMAC-SHA1）分の Input queueをもつ ‣ 同じ暗号種別のリクエストは，同じキューに挿入され，入力 キューのサイズがある閾値を超えたら，GPU queueに移される ‣ GPU-interfacingスレッドはGPU queueをまとめて処理する 22
- 23. GPUオフロードアルゴリズム ‣ 並列性を最大限高めるために，複数の暗号処理をまとめ てGPUにオフロードするべきである ‣ シンプルなGPUオフロードアルゴリズム ‣ 低負荷時はレイテンシを削減（閾値以下であればCPU使用） ‣ 高負荷時はスループットを最大化 1. ワーカスレッドがinput queueに暗号処理タスクを挿入 2. 全ワーカのキューの中の同じ暗号種別のリクエスト数を確認 3. 閾値を超えているキューがあれば，そのキューをGPU- interfacing queueに移動 ‣ 最小の閾値と最大の閾値を設定 ‣ 最小の閾値は，1CPUコアよりGPUのほうが性能がよいとき ‣ 最大の閾値は，最大スループットが達成できるとき 2013/4/17 輪講 23
- 24. スケジューリング手法 ‣ ワーカスレッドはI/Oイベントを優先し，I/Oイベントが ないときに，暗号処理を行う ‣ ワーカスレッドは暗号処理リクエストをFIFOで処理 ‣ 各リクエストの到着時にタイムスタンプを記録し，最初に到着し たリクエストを見つける ‣ GPUもまた暗号処理をFIFOスケジューリングで行う ‣ GPU-interfacingスレッドはタイムスタンプをみて最も若いリクエ ストの暗号種別をまとめて処理する ‣ GPUオフロードブロッキング防止のため，ワーカスレッドは 敵的にI/Oがないかどうかを確認 ‣ CPUとGPUそれぞれに向いている処理を優先(Reject) ‣ CPUにHMAC-SHA1とAES暗号化を優先し，GPUにRSA とAES解読を優先 ‣ 最大スループットは向上したが，不安定かつレイテンシ増大 2013/4/17 輪講 24
- 25. Evaluation 25
- 26. 評価 ‣ HTTPSで評価 ‣ SSLを使用する最も有名なプロトコル ‣ 高スループットかつ低レイテンシなコネクションのハンドリ ングと大きなファイル転送を達成 ‣ lighttpd with OpenSSL vs SSLShader ‣ 静的コンテンツでWebサーバがボトルネックになることを防 ぐことにフォーカスする ‣ クライアント7台. abコマンドでサーバに負荷をかける CPU Intel Xeon 5650 6コア 2 メモリ 24GB GPU NVIDIA GTX 580 512コア 1.5 GHz 2 NIC driver ixgbe v2.14 Webサーバ lighttpd v1.4.28 OS Ubuntu 10.04 26
- 27. スループット評価 ‣ クライアントからの同時接続数を変化させたときのSSL transactions / s (TPS) を測定 ‣ RSA 1024bitで，SSLShaderがlighttpdの2∼2.5倍速い RSA 2048bitで，約4∼6倍速い ‣ RSA 2048bitで，GPU2台のRSA処理ピークスループット 24.1 K msg/sに対してSSLShaderが21.8KでGPUをほぼ使 いきれている ‣ しかし，RSAの1024bitはピーク スループットは75 K msg/s に対してSSLShaderが29Kで GPUリソースが余っている 27
- 28. レイテンシ評価 ‣ 提案手法では負荷が低いときはレイテンシを最小限に し，負荷が高いときはスループットを最大にする ‣ 負荷が高いケースと低いケースで提案手法の効果確認 ‣ 低負荷時は両方とも，90%程度のコネクションが数ms程度 ‣ 高負荷時はSSLShaderのほうがレイテンシは小さい (meg/s, クライアント数) heavy 28
- 29. Discussion ‣ ハードウェアアクセラレータとの比較 ‣ 現在のハードウェアアクセラレータは7K ∼200K RSA operations/s (提案手法は92Kで価格コストは低い) ‣ GPUは新たな暗号処理アルゴリズムに柔軟に対応可能 ‣ 1ドルあたりの性能 ‣ AESについてはX5650 CPUはAES専用の命令セットをもっ ているため，コストパフォーマンスが高い ‣ GPUは全体的にコストパフォーマンスが高い 29
- 30. Conclusions ‣ インターネットにおけるSSL利用が増加 ‣ SSLパフォーマンスをスケールさせる安価な方法とし て，高性能SSLアクセラレータとしてのGPU利用を提案 ‣ GPUで暗号処理を高速化するためのさまざまな技術を 提示 ‣ SSLShader: 高スループットと低レイテンシを達成する SSLリバースプロキシの作成 ‣ 評価の結果 ‣ 1024bit RSAを単一GPUで92K operations/sまでスケール できる ‣ SSLShaderは29K TPSを処理する 2013/4/17 輪講 30