Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

GPUを用いたSSLリバースプロキシの実装についての論文を読んだ

GPUを用いたSSLリバースプロキシの実装.
RSA, AES, SHA-1などの暗号化アルゴリズムのGPU実装など.

  • Be the first to comment

GPUを用いたSSLリバースプロキシの実装についての論文を読んだ

  1. 1. SSLShader: Cheap SSL Accelerationwith 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. 2. Introduction 2
  3. 3. Introduction‣ SSLとTLSはセキュアなトランスポート層通信のための デファクトスタンダードなプロトコル‣ エンドポイントにおける認証とコンテンツの暗号化‣ しかし現在,SSLはセキュリティクリティカルなドメイ ンやエンタープライズアプリケーションのみで利用され ているだけである‣ これは主にサーバサイドにおける計算負荷が重いため ‣ 主なボトルネックは 交換フェイズ ‣ 1024bit RSAに対して,最新のCPUで2K SSL transactions/s ‣ 暗号化しないならば,10K transactions/s 以上さばける2013/4/17                      輪講 3
  4. 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. 5. Background 5
  6. 6. SSL (Secure Sockets Layer)‣ ClientHello, ServerHello: サポートしている暗号化手法 の中から一つを決定.サーバクライアント間の認証など‣ クライアントはpre-master secretをサーバの公開 を 用いて暗号化 -> サーバに送信‣ pre-master keyを用いてサーバ・クライアントの双方 がセッションキーとMACキーを生成‣ セッションキーとMAC              キーは暗号化に使用 6
  7. 7. SSLのボトルネック‣ Web環境では,やりとりされるパケットサイズが小さい‣ サーバ側でのpre-master secretの解読処理の回数が増 加 -> ボトルネック (RSA)‣ パケットサイズが大きくなると,主要なオーバヘッドは 以下の2つに移行 ‣ パケットデータそのものの暗号化・解読処理(AES) ‣ MACの計算(MAC) 7
  8. 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. 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. 10. GPU (Graphics Processing Unit)‣ 最近のGPUは数百個のコアを持ち,グラフィックレンダ リングだけでなく,汎用計算に使用される‣ SIMD 演算(同一算術演算子による複数の2項演算を1サ イクルで実行)‣ GPUコードの実行単位をカーネルと呼ぶ‣ 大量のコアを活用するために,多くのスレッドを起動 し,カーネルを並列に実行する ②カー CPU ネル実 行命令 GPU 発行 ③カーネル実行 ータ転送 GPU ① 入力デ Host メモリ ータ転送 ④ 出力デ2013/4/17 メモリ                      輪講 10
  11. 11. Optimizing RSA for GPU 11
  12. 12. RSAのGPU最適化‣ 低いレイテンシを保ったまま,高スループットを達成す ることが課題‣ 単純にCPUのコードをGPUに移植しても性能は上がら ず,GPUの計算リソースを無駄にする‣ 1GPUスレッドの実行速度は1CPUスレッドの1/10か ら1/100程度であるため,レイテンシが増大‣ GPUにおけるRSAの解読の性能を最大化する重要なポ イントは並列化である2013/4/17                      輪講 12
  13. 13. RSAの並列化手法message message message message ......m m m m m m m m m m m m m m mth th th th th th th th th th th th th th th th GPU threads‣ 各messageは独立しているため,並列処理可能‣ は中国剰余定理より‣ 大きな整数値を1ワードに分割し,各ワードを複数のGPUス レッドで処理 ‣ スレッド間でワードごとの命令結果を調整するために,桁上げ・桁 下げ処理などが必要 (詳しくは省略) 13
  14. 14. RSAマイクロベンチマーク‣ 並列GPU実装と逐次CPU実装の比較‣ メッセージ数1のとき ‣ RSA のbit長が大きいほうが並列性が高いため,GPUのほうが高 スループット‣ メッセージ数が複数のとき ‣ message数が小さいときは,CPUのほうが高スループット ‣ message数が十分大きいときはGPUのほうが高スループット‣ GPU実装は,6コアのCPU x 3個 に匹敵する 1 ciphertext messages RSA鍵長 1024bit 14
  15. 15. AcceleratingAES and HMAC-SHA1 15
  16. 16. AESの高速化‣ CBCモードによる暗号化は直前のブロックの結果を次 のブロックで使うため,逐次処理しなければならない‣ 一方,解読時は直前のブロックの結果を既に知っている ため,並列処理可能‣ 最適化手法 ‣ 各スレッドがlookupテーブルを共有メモリにコピー ‣ 共有メモリのほうがグローバルメモリよりも2桁速い ‣ グローバルメモリからの事前に展開された を使う代わり に,各ラウンドでラウンド を得る ‣ 計算負荷は余計にかかるが,高価なメモリアクセスを削減で き,全体のレイテンシを低下させられる2013/4/17                      輪講 16
  17. 17. HMAC-SHA1の高速化‣ HMAC-SHA1の性能はSHA1に依存しているため, SHA1を高速化すればよい‣ SHA1単体の並列処理が難しい ‣ 入力メッセージを512bitのブロックに分割 ‣ i番目のブロックの結果をi+1番目のブロックの計算に使用 ‣ ブロックを逐次実行しなければならない‣ GPUによるSHA1の最適化手法 ‣ レジスタにデータを置くことでGPUメモリへのアクセス削減 ‣ GPUのレジスタ数に収まるように必要データ記憶量を削減 ‣ ナイーブな実装と比較して100%の性能向上2013/4/17                      輪講 17
  18. 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-SHA1Throughput (Mbps) Throughput (Mbps) 18
  19. 19. AES & HMAC-SHA1 まとめ‣ (i) AES-NIはドルあたりの性能が最大‣ (ii) CPU-GPU間のデータ転送コストにより約4倍の性能 低下‣ (iii) CPUがAES-NIをサポート‣ 最近のトレンドとしてGPU統合型CPUがあるので,将 来的にはデータ転送コストは無視できる2013/4/17                      輪講 19
  20. 20. SSLShader 20
  21. 21. SSLShader‣ スケーラブルSSLリバースプロキシ‣ 設計目的 ‣ CPUとGPUのコア数に対して性能            がスケール Clients ... ‣ スループットを高めつつ                Webなどのインタラクティブな              環境をサポートするために                レイテンシを抑えるべき SSLShader Webサーバ2013/4/17                      輪講 21
  22. 22. 基本設計‣ SSLコネクションを処理するためのイベント駆動のスレッド‣ コア数スケールのために,1CPUコアあたり1ワーカスレッド‣ GPUオフロード処理専用にGPU-interfacingスレッドを用意‣ 各ワーカスレッドは暗号種別(RSA, AES, HMAC-SHA1)分の Input queueをもつ‣ 同じ暗号種別のリクエストは,同じキューに挿入され,入力 キューのサイズがある閾値を超えたら,GPU queueに移される‣ GPU-interfacingスレッドはGPU queueをまとめて処理する 22
  23. 23. GPUオフロードアルゴリズム‣ 並列性を最大限高めるために,複数の暗号処理をまとめ てGPUにオフロードするべきである‣ シンプルなGPUオフロードアルゴリズム ‣ 低負荷時はレイテンシを削減(閾値以下であればCPU使用) ‣ 高負荷時はスループットを最大化 1. ワーカスレッドがinput queueに暗号処理タスクを挿入 2. 全ワーカのキューの中の同じ暗号種別のリクエスト数を確認 3. 閾値を超えているキューがあれば,そのキューをGPU- interfacing queueに移動 ‣ 最小の閾値と最大の閾値を設定 ‣ 最小の閾値は,1CPUコアよりGPUのほうが性能がよいとき ‣ 最大の閾値は,最大スループットが達成できるとき2013/4/17                      輪講 23
  24. 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. 25. Evaluation 25
  26. 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. 27. スループット評価‣ クライアントからの同時接続数を変化させたときのSSLtransactions / 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. 28. レイテンシ評価‣ 提案手法では負荷が低いときはレイテンシを最小限にし,負荷が高いときはスループットを最大にする‣ 負荷が高いケースと低いケースで提案手法の効果確認‣ 低負荷時は両方とも,90%程度のコネクションが数ms程度‣ 高負荷時はSSLShaderのほうがレイテンシは小さい (meg/s, クライアント数) heavy 28
  29. 29. Discussion‣ ハードウェアアクセラレータとの比較‣ 現在のハードウェアアクセラレータは7K ∼200K RSA operations/s (提案手法は92Kで価格コストは低い)‣ GPUは新たな暗号処理アルゴリズムに柔軟に対応可能‣ 1ドルあたりの性能‣ AESについてはX5650 CPUはAES専用の命令セットをもっ ているため,コストパフォーマンスが高い‣ GPUは全体的にコストパフォーマンスが高い 29
  30. 30. Conclusions‣ インターネットにおけるSSL利用が増加‣ SSLパフォーマンスをスケールさせる安価な方法とし て,高性能SSLアクセラレータとしてのGPU利用を提案‣ GPUで暗号処理を高速化するためのさまざまな技術を 提示‣ SSLShader: 高スループットと低レイテンシを達成する SSLリバースプロキシの作成‣ 評価の結果 ‣ 1024bit RSAを単一GPUで92K operations/sまでスケール できる ‣ SSLShaderは29K TPSを処理する2013/4/17                      輪講 30

×