• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
GPUを用いたSSLリバースプロキシの実装についての論文を読んだ
 

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

on

  • 836 views

GPUを用いたSSLリバースプロキシの実装.

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

Statistics

Views

Total Views
836
Views on SlideShare
836
Embed Views
0

Actions

Likes
1
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

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