IXP425における暗号処理の効率的なオフロード方式の実装と評価

全文

(1)情報処理学会論文誌. Vol. 51. No. 9. 1530–1541 (Sep. 2010). 1. はじめに. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. 昨今，マルチコア技術の発展にともない，様々なタイプのアーキテクチャを持つプロセッサが開発されてきている．そのような背景の中，ネットワークに関する処理をより高速に行うため，プロセッサ内に IP パケットの処理をもっぱら行うモジュールを持つ Network. 齋藤孝道†1 羅鏡栄†1. 大杉. 釜正裕†1 浦寛†1. Processor（以降，NP と呼ぶ）が登場した．さらに，ネットワーク機器や組み込み機器などにおいて，暗号処理を行うことも増えたため，IXP4xx シリーズ（インテル社製）や MPC82xx シリーズ（モトローラ社製）のようにコア内に暗号処理をもっぱら行うモジュール（以降，暗号モジュールと呼ぶ）を持つ NP も開発され普及してきた．そのような暗号モジュールを持. 昨今の CPU アーキテクチャの多様化の中で，コア内に暗号処理をもっぱら行うモジュール（以降，暗号モジュールと呼ぶ）を持つプロセッサがいくつか登場した．この種のプロセッサでは，暗号処理以外の処理は汎用モジュールで行い，処理速度の要求される暗号処理は暗号モジュールで行うことにより，プロセッサ全体で処理速度の向上を狙っている．しかしながら，既存のソフトウェアの多くは，この種のプロセッサ向けに設計されておらず，一般的に，暗号モジュールを活用するためにはソフトウェアを改修するなどの処置が必要となる．本論文では，コアの中に暗号モジュールを 1 つ持つプロセッサ IXP425 を搭載する評価ボードにおいて，OpenSSL の処理の一部を透過的に暗号モジュールへオフロードし暗号処理を行う仕組みを提案し，その実装と評価を行う．. An Effective Off-loading of Cryptographical Operations on IXP425 and its Evaluation Takamichi Saito,†1 Masahiro Ohgama,†1 Keang-Weng Lo†1 and Kan Sugiura†1 Recently, as there are many types of CPUs in a market, we have some CPUs which have cryptographical modules. In the type of CPUs, a cryptographical module can be used to off-load a part of cryptographical operation. However, since an established cryptographic library such as OpenSSL can not be applied to it, we need a solution for it. In this paper, we implement a scheduler in a cryptographic middleware to solve it, and evaluate its off-loading performance.. つ NP では，IPSec，SSL（Secure Socket Layer）7) や TLS（Transport Layer Security）8) などにともなう高度な暗号処理の一部を，暗号モジュールにオフロードすることにより，プロセッサ全体の高速化を期待することができる11) ．しかしながら，オペレーティングシステムを含む既存のソフトウェアは，暗号モジュールを持つ NP のアーキテクチャを前提に作られていないため，その性能を狙いどおり引き出すためには，その対処をする必要がある．すなわち，NP メーカが提供するドライバを用いて，暗号処理を適切に暗号モジュールへオフロードするように，既存のソフトウェアを改変する必要がある．他方，様々な暗号処理をともなうソフトウェアの開発では，OpenSSL 1),4) のように，広く利用され，実績のある暗号ライブラリを利用するのが望ましいとされている．OpenSSL は，様々な暗号処理アクセラレータ（AEP，Chil，Cswift など）などに対応しているが，今回利用した IXP425 6) を含む NP には対応していない．基本的に OpenSSL は，UserLand のアプリケーションであり，様々な CPU アーキテクチャへの対応は限定的となる．また，実現手段の観点から考えてみると，OpenSSL 自体に脆弱性の発見があれば，. OpenSSL 自体の大々的な変更もありうる．よって，アプリケーションとハードウェアを一体として扱うことは不都合も多い．そこで，本論文では，OpenSSL 自体を改変せずに，コア内に暗号モジュールを持つ IXP425 上で，OpenSSL とハードウェアとの間をつなぐミドルウェア OCF（OpenBSD Crypto-. graphic Framework）2) を利用し，IXP425 の性能を引き出すことを目指す．特に，OCF は，カーネルモジュール形式のミドルウェアであるため，その利用により，アプリケーションと. †1 明治大学 Meiji University. 1530. c 2010 Information Processing Society of Japan .

(2) 1531. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. ハードウェアを切り離すことができ，適切なドライバを用意すれば，様々なアーキテクチャに適用できることもメリットといえる．本論文では，複数のプロセスが暗号モジュールというハードウェアリソースをどのように利用するかという議論を扱っている．一般的に，ハードウェアなどのリソース利用の競合を避ける手段としては，「スピンロック」，「sleep させる方法」と「（Solaris OS などで採用されている）適応型相互排他ロック（adaptive lock）」があるが，本論文では，この種の手段については既知とした．今回，暗号処理を演算処理の対象しており，暗号化のブロックサイズが大きくなれば，CPU（暗号モジュール）bound な処理になるため，暗号モジュールを競合するリソースと見立てた場合，「スピンロック」や「適応型相互排他ロック」は不向き図 1 IXP425 のアーキテクチャ概要 Fig. 1 Hardware architecture of IXP425.. である．よって，「sleep させる方法」を，今回適用することとした．マルチコアにおけるアプリケーションプロセスのスケジューリングの議論は CPU のアーキテクチャに依存するため，抽象論になりやすい．ここでは，アーキテクチャの対象を IXP425 に限定することで，ソースコードレベルでの議論に限定し，以下についてを実験により確認. 2.1 IXP425 の概要. できた．. 本論文で使用した IXP425 6) は，XScale コアを 1 基，IP パケット処理専用モジュールであ. (1) ハードウェアリソースである暗号モジュールの利用において競合が発生し，Kernel 内. る NPE（Network Processor Engine）1 基，Queue Manager 33/66 MHz PCI（Peripheral. 部でスピンロックすると，暗号処理のオフロードにおいて，そのことが原因で遅延が発. Components Interconnect）コントローラ 1 基などから構成されている．IXP425 のハード. 生するケースがある．. ウェアアーキテクチャは，図 1 のとおりである．XScale コアは汎用 CPU で，OS の実行. (2) 上述の遅延を解消するため，本論文では，暗号モジュールを利用待ちするアプリケーションプロセスは，「スリープさせる方法」を採用したが，それは有効である．. Oracle 社が提供する Solaris Cryptographic Framework の PKCS#11 v2.20（libp12). kcs11.so）という類似の目的を持つ技術. があるが，ソースコードおよび内部の詳細な. 構造は，現在，非公開であり，本論文で扱った議論ができないため，オープンソースである. OCF を用いて議論し，上述の知見を得ることができたといえる．以降，IXP425，OpenSSL や OCF など前提に関する記述が多くなるが，既存技術の分析. や NPE などの周辺装置の制御などを行う．また，NPE は，ether フレームもしくは IP パケット処理用に 2 つあり（それらは NPE A と NPE B とそれぞれ呼ばれる），これらに加え，WAN や VOIP 向けに，UTOPIA（Universal Test & Operations PHY Interface for. ATM）や HSS（High Speed Serial）などのインタフェースを持つ NPE があり，合計 3 つの NPE がある．また，NPE B は暗号モジュールを内蔵し，共通鍵暗号化方式として DES，. 3DES と AES をサポートし，その暗号利用モードとして，CBC（Cipher Block Chaining）と ECB（Electronic Code Book）がある．ハッシュアルゴリズムとして SHA-1 と MD5. と考察により，提案方式の実現を目指すこととしたい．特に，本論文では，暗号モジュール. をサポートしている．Queue Manager は，XScale コアと NPE との間の通信に利用する. を利用するプロセス数 N に対して，暗号モジュールが 1 つである場合，つまり，N 対 1. ハードウェアキューの制御を行う．. のケースにおけるより良い方式を検討したうえでそれを実装し，実証実験によりその有効性. AccessLibrary の IxCryptoAcc API 6) を用いて，NPE B の暗号モジュールによって，暗. 2. 開発環境. 号処理を行うことが可能である．IxCryptoAcc は，共通鍵暗号化方式として DES，3DES，. ここでは，本論文で開発のために用いたハードウェアとソフトウェアについての概説する．. 情報処理学会論文誌. IXP425 では，Intel 社が提供する IXP4xx シリーズ向け API である AccessLibrary を用いて，NPE，コプロセッサ，周辺装置などのデバイスを利用することができる．特に，. を示す．. Vol. 51. No. 9. 1530–1541 (Sep. 2010). AES と ARC4，ハッシュアルゴリズムとして SHA-1 と MD5 をサポートしている．. c 2010 Information Processing Society of Japan .

(3) 1532. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. 2.3 µCLinux 本論文では，評価ボード NTNP425C に対応した OS のうち，µCLinux 5) を採用した．カーネルのバージョンは 2.4.24 である．µCLinux は，embedded Linux/microcontroller. project が，2009 年現在，開発している組み込み向けの Linux OS で，MMU（Memory Management Unit）がないプロセッサ上でも動作し，カーネルサイズを 512 kB 未満に収めることが可能であるなどの特徴を持つ．また，一般的な Linux と同様のシステムコールを提供し，LKM（Loadable Kernel Module）をサポートしている．図 2 NTNP425C のアーキテクチャ概要 Fig. 2 Hardware architecture of NTNP425C.. 2.4 OpenSSL OpenSSL 1) は，セキュリティプロトコルである SSL/TLS だけでなく，X509v3 公開鍵証明書の発行といった PKI（Public Key Infrastructure）関連の機能や様々な暗号処理な. 表 1 評価ボード NTNP425C の基本仕様 Table 1 Hardware specification of NTNP425C.. CPU プログラムメモリメインメモリ NIC USB シリアル I/F. USB Debug コネクタ外部 I/O. IXP425 533 MHz Flash ROM 16 Mbyte SDRAM 64 Mbyte（133 MHz） 10BASE-T/100BASE-TX （LAN と WAN 用に 1 基ずつ） USB2.0 HOST 2 ポート RS-232C 2 チャンネル USB2.0 HOST 2 ポート JTAG ポート Mini PCI スロット 1 ポート，ユーザファンクション I/F. どを容易なインタフェースで利用可能とする API ライブラリを含むソフトウェア群である．. OpenSSL が提供するライブラリには，libssl と libcrypto があり，前者は SSL/TLS 通信に関する機能を，後者は暗号処理に関する機能をそれぞれ提供する共有ライブラリである．共通鍵暗号化方式として DES，3DES や AES など，公開鍵暗号化方式として RSA や DH など，ハッシュアルゴリズムとして SHA-1，SHA-2 や MD5 など，主要な暗号アルゴリズムが利用可能であり，特に，共通鍵暗号化方式とハッシュアルゴリズムなどについては，共通のインタフェースでの利用を可能とする EVP API を提供している4) ．また，OpenSSL は，AEP，Chil，Cswift をはじめとした各メーカが提供するハードウェアアクセラレータに対応しており，アプリケーションからそれらを利用するために ENGINE API 9) を提供している（図 3 参照）．しかしながら，IXP425 の暗号モジュールには対応していない1 ．. 2.5 OCF しかしながら，この API は主に，デバイスドライバの開発用の API であるため，暗号モ. OCF 2) とは，OpenBSD Cryptographic Framework の名が示すとおり，OpenBSD 上. ジュールを利用する際には，アプリケーション側で，デバイスドライバを呼び出す仕組みを. で，暗号処理機能を利用するためのインタフェースを統一的に利用するために作られた API. 実装する必要がある．. で，カーネルモジュールとして機能する．. 2.2 IXP425 評価ボード. 本論文では，OpenBSD で実装されているオリジナル版でなく，OCF を Linux に移植し. 本論文では，IXP425 を搭載した評価ボードであるノバテック社製 NTNP425C 10) を用. た OCF-Linux 3) を用いるが，本論文での表記は，特に区別するときを除き OCF とする．. いた．NTNP425C のハードウェアアーキテクチャを図 2 に，基本仕様を表 1 にそれぞれ. 最新版の OCF-Linux は，IXP425 を含む様々なハードウェア IXP4xx シリーズ（Intel 社），. 示す．NTNP425C は，IXP425，（プログラムメモリである）Flash ROM，（メインメモリで. Hifn 79xx シリーズ（Hifn 社），SafeXcel シリーズ（SafeNet 社）などに対応している．ま. ある）SDRAM と 2 つの NIC などから構成されている．Flash ROM にはブート対象の実. た，アプリケーションとしては，OpenSSL，OpenSSH や OpenSwan などに対応している．. 行プログラムと，ブートプログラムが格納されており，実行プログラムは，装置の立ち上がり時に Flash ROM からメインメモリ（SDRAM）に転送され，その上で実行される．. 情報処理学会論文誌. Vol. 51. No. 9. 1530–1541 (Sep. 2010). 1 OpenSSL-0.9.8d では未対応である．. c 2010 Information Processing Society of Japan .

(4) 1533. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. 図 3 OpenSSL におけるハードウェア利用の概念 Fig. 3 Conceptual image of OpenSSL calling devices.. OpenSSL を利用するアプリケーションプログラム（以降，OpenSSL アプリと呼ぶ）は，. 図 4 Engine を利用したコードの例（抜粋） Fig. 4 A part of code utilizing engine object.. バイスを用いて暗号処理を行う際の標準的なサンプルプログラムである．. ユーザ空間で実行されるアプリケーションプログラムであるため，OCF を経由すること. 3.1.1 暗号処理の初期化. で，暗号モジュールを利用する（図 3 参照）．図 3 のプロセス B（図中では process B と表. 図 4 の (A) では暗号モジュール NPE B の初期化を行う．OCF で定義されている識別. 記）は，ハードウェアアクセラレータの利用に加え，OpenSSL の提供する Engine インタ. 子 cryptodev を引数として，ENGINE_by_id 関数を呼び出すことで，NPE B に対応した. フェースにより，OCF の提供するデバイスノード（/dev/crypto）経由で，IXP425 の暗. ENGINE オブジェクト1 を得る（4 行目）．また，受け取った ENGINE オブジェクトとフラ. 号モジュールを利用する概念を示している．. グを引数として ENGINE_set_default 関数を呼び出すことにより，NPE B において利用. 3. 暗号モジュール利用の分析・考察ここでは，OpenSSL から OCF を経由して，IXP425 の暗号モジュールを利用する際の一連の処理を分析し，その考察を行う．. 可能な暗号処理を設定している（6 行目）．この際，ENGINE_METHOD_ALL フラグを指定することで，NPE B で利用可能なすべての暗号処理を NPE B 上で処理させることが可能となる．ここで，NPE B がハードウェアとして提供できない暗号処理がリクエストされた場合，. XScale コアにて OCF がエミュレートする．. 3.1 OpenSSL から OCF の呼び出し. 3.1.2 暗号処理の実行. OpenSSL アプリでは，暗号モジュールを利用するために，ENGINE 型のオブジェクト. 図 4 の (B) では，11 行目で指定された暗号処理を行う．DES を CBC モードで利用する. （以降，ENGINE オブジェクトと呼ぶ）と ENGINE API を利用する4),9) ．ただし，前述の. ことを指定し，別途定義された鍵と IV を引数として与えたうえで，EVP_CIPHER_CTX コン. とおり OpenSSL は IXP425 をサポートしていないため直接呼び出せず，暗号モジュールを. テキスト2 （以降，コンテキストと呼ぶ）である ctx で，コンテキストを特定し，初期化. 利用する際には，あらかじめ OCF 自体をデバイスとして OpenSSL へ登録する（図 3）．ま. している（11 行目）．今，入力される平文を intext とし，同じく ctx でコンテキストを. た，OCF が呼び出された際，暗号処理を IXP425 の NPE B へオフロードするように，あ. 特定し，EVP_EncryptUpdate 関数を呼び出すと，outbuf に，NPE B の処理結果として出. らかじめ OCF で設定する．以下では，図 4 の OpenSSL アプリを例として，IXP425 の暗号モジュールの利用について説明する．図 4 で示した OpenSSL アプリは，ハードウェアアクセラレータなどの外部デ. 情報処理学会論文誌. Vol. 51. No. 9. 1530–1541 (Sep. 2010). 1 ENGINE オブジェクトを用いて，その ID・名前や暗号関数群へのポインタなどを特定することができる． 2 コンテキストにより，OpenSSL 内部で設定された暗号アルゴリズム，暗号鍵や IV などを特定する．. c 2010 Information Processing Society of Japan .

(5) 1534. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. 図 5 OCF の動作チャート（プロセスは 1 つ） Fig. 5 Timechart of OCF execution in case of one process.. 図 6 複数のプロセスが OCF を利用する概念図 Fig. 6 Conceptual image of four processes calling a device.. 力される暗号文が得られる（13 行目）．ここで，EVP_EncryptUpdate 関数は，平文を分割して暗号化する際，0 回以上複数回呼び出される．また，15 行目の EVP_EncryptFinal 関数は，同様に暗号化を行うが，最後にパディングを加える必要があるときがある際にその処理を行う．ユーザは暗号処理を EVP_EncryptFinal 関数で終える必要がある．. 3.1.3 暗号処理の終了処理. フェーズと呼ぶ．ここで，User Land で実行される OpenSSL アプリが，Kernel Land の OCF を呼び出しており，図 5 の OCF は，その下の層のハードウェアごとに切り替えるモジュールである. ixp4xx.o と対となり利用される．. 図 4 の (C) の 18，19 行目で，コンテキストと ENGINE オブジェクトをクリーンナップ. 3.2.2 Process フェーズ図 4 の (B) の点線枠内にある EVP_EncryptUpdate 関数が呼び出されると，New Session. する．. 3.2 OCF 経由での暗号モジュールの処理. フェーズと同じく OpenSSL の内部関数が呼び出され，暗号処理が行われる（この例だと，. 次に，図 4 で示した OpenSSL アプリから OCF を通して NPE B にアクセスし暗号処. OCF 内部の DES 用の処理を行う関数が呼び出される）．その際，当該関数では，（OCF 側. 理を行う一連の処理を説明する．これは，下記の 3 つのフェーズからなり，順番に，New. で定義されている）CIOCCRYPT という識別子を用いて，システムコールを発行する．これに. Session，Process，Free Session である（図 5 参照）．. より，当該セッションで指定されている暗号アルゴリズム，ブロック暗号の利用モードと暗. 3.2.1 New Session フェーズ. 号鍵を用いて，NPE B で処理が行われる．以上を，模式的に示したのが，図 5 の Process. 図 4 の (B) の点線枠内にある EVP_EncryptInit 関数が呼び出されると，OpenSSL. である．これを Process フェーズと呼ぶ．. 内部の関数が呼び出される．次に，当該関数では，あらかじめ準備しておいたデバイス. 3.2.3 Free Session フェーズ. （OCF 側で定義されている）CIOCGSESSION （/dev/crypto）に対して，ioctl() を用いて，. 図 4 の (C) の点線枠内にある EVP_CIPHER_CTX_CLEANUP 関数が呼び出されると，同様に. という識別子により特定されるシステムコールを発行する．この際，あわせて，暗号アル. OpenSSL の内部関数が呼び出され，終了処理が行われる．その際，当該関数では，（OCF 側. ゴリズム，暗号利用モードと暗号鍵を指定し，これらのパラメータを内部的に保持するた. で定義されている）CIOCFSESSION という識別子を用いて，システムコールを発行する．こ. め，OpenSSL と OCF との間で，セッション（以降，OCF セッションと呼ぶ）が生成さ. れにより，OCF セッションを解放し，関連するすべてをクリーンナップする．以上を，模. れ，セッションごとに割り当てられた識別子（OCF セッション識別子と呼ぶ）が付与され. 式的に示したのが，図 5 の Free Session である．これを Free Session フェーズと呼ぶ．. る．以降，OCF が呼び出されたとき，OCF セッション識別子を用いて OCF セッションを. 3.3 OCF に関する考察. 特定する．以上を，模式的に示したのが，図 5 の New Session である．これを New Session. 図 6 は，複数のプロセスが OCF を通して暗号モジュールを利用する様子を簡略に模式. 情報処理学会論文誌. Vol. 51. No. 9. 1530–1541 (Sep. 2010). c 2010 Information Processing Society of Japan .

(6) 1535. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. 化したものである．時系列に従い説明すると，ここで，プロセス A（Process A と表記）が，暗号モジュールを利用しているしている期間（Time A と表記）に，プロセス B と C （Process B と Process C とそれぞれ表記）が暗号モジュールを利用しようしている．また，. 4. 提案システムの設計と実装 4.1 基本設計. プロセス D （Process D と表記）が，暗号モジュールを利用しないプロセスとして実行さ. 提案システムにおいて導入する OCF スケジューラは，OCF と同様にカーネルモジュー. れる．それらに引き続き，Process A が処理を終え，Process B が暗号モジュールを利用す. ルとして動作し，複数のアプリプロセスからの暗号処理リクエストをスケジューリングし，. るとする．. 暗号モジュールへ処理をオフロードする．実現手段としては，OCF スケジューラで，1 方. 図 6 の (X) では，Process B と Process C が，暗号モジュールが利用できないにもかか. 向リスト（以降，sched リストと呼ぶ）を導入し，アプリプロセスのスケジューリングを. わらず，OCF を通して，Process フェーズに入り暗号モジュールを利用しようとしている. 行っている．sched リストでは，暗号処理のリクエストを発行したアプリプロセスのプロセ. ことを示している．OCF では，暗号モジュールを利用する OpenSSL アプリを実行する複. ス ID とウェイトキューを共有する．本論文では，スケジューリングの戦略として FIFO を. 数のプロセス（以降，アプリプロセスと呼ぶ）が一時に暗号処理を行おうとする場合，前. 採用し，スケジューラの軽量化を目指した．. 述のとおり，アプリプロセスから暗号処理のリクエストを受け取った順に，New Session，. 提案システムにおいて，アプリプロセス A は，OCF セッションの生成時，暗号モジュー. Process と Free Session の一連の処理を行う．しかし，New Session の実行後，IXP425 に. ルが他のアプリプロセス B に利用されている場合，sched リストにつながれ，アプリプロ. は暗号モジュールが 1 つなので，オリジナルの OCF では，Process の途中で処理をビジー. セス A は強制的に sleep させられる．アプリプロセス B による暗号モジュールでの利用が. ウェイトさせている．このことは，CPU への無用の負荷をかけることになる．. 終了後，アプリプロセス A が起こされる．また，OCF セッションの生成時，暗号モジュー. また，図 6 の (Y) は，Process A の処理終了後，次に暗号モジュールを利用すべきプロ. ルが他のアプリプロセスに利用されていない場合，速やかに処理が実行される．. セスが実行可能状態になるまでに時間がかかることを示している．すなわち，Process A が. 4.2 実. 暗号モジュールの利用を終えた直後，暗号モジュールの利用を次に待つ Process B が実行. 4.2.1 sched リストのデータ構造. されない場合，その間は暗号モジュールが遊んでしまう．たとえば，図 6 の Process A の. 提案システムでは，アプリプロセスを sched リストで格納するため，下記のとおりの 3 つ. 暗号モジュールでの処理が終わった後，次に暗号モジュールを利用したいプロセス Process. B が，優先的に実行可能状態になるようになることが理想である．さらに，両方のケースに共通することとして，実際には，何も処理をすることができないアプリプロセスも実行可能状態になり，不要なコンテキストスイッチが起こる．このため，暗号処理以外のプロセスへの影響も大きいことが予想される．以上のことに鑑みて，提案システムでの基本戦略としては，下記の 2 点を実現することを. 装. のメンバを持つ構造体を用意する． struct sched_entry { struct list_head list; wait_queue_head_t se_waitq; pid_t pid; };. ここで，各メンバの役割は以下のとおりである：. 目指す：. • list −上記で記述したリストを連結するためのリスト構造体. (1). 複数のアプリプロセスによる暗号モジュールの利用開始を適切にスケジューリング. • se_wait −暗号モジュールを使用できない場合に sleep 状態にするためのウエイトキュー. する．. • pid −アプリプロセスのプロセス ID を記憶するための変数. (2). 暗号モジュールの処理終了後，アプリプロセスを適切にスケジューリングする．. これらを実現するため，提案システムでは，OCF 上で暗号処理を行うアプリプロセスのスケジューラ（以降，OCF スケジューラと呼ぶ）を導入する．. 本論文では，この構造体を用いて，sched リストを sched_list としている．ただし，. sched_list は共有メモリ空間に配置するため，いずれのアプリプロセスからも参照できる． 4.2.2 提案システムの動作提案システムでは，図 4 (B) にあるように，New Session へのきっかけとなる. 情報処理学会論文誌. Vol. 51. No. 9. 1530–1541 (Sep. 2010). c 2010 Information Processing Society of Japan .

(7) 1536. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. EVP_EncryptInit が呼び出されると，OCF スケジューラで以下の手続きが行われる． (1). New Session における初期化の処理を行う．. (2). sched_list が空かどうかを確認する．空のときは ( 4 ) の処理に進む．. (3). wait_event_interruptible により，当該アプリプロセスは sleep 状態に遷移させられ，ウェイトキューに登録される．. (4). sched_entry 構造体の pid メンバに当該アプリプロセスのプロセス ID を代入し，当該リストを sched_list に追加する．. (5). EVP_EncryptInit の処理を終了する．. この後，図 4 にあるように，Process へのきっかけとなる EVP_EncryptUpdate が，0 回以上実行され，EVP_EncryptFinal が実行される．このとき，EVP_EncryptUpdate と. EVP_EncryptFinal を実行するアプリプロセスはただ 1 つであることと，sched_list は 1. 図 7 提案システムの実行例 Fig. 7 A execution of proposed system.. つ以上の複数個のリストであることに注意されたい．その後，図 4 (C) の EVP_CIPHER_CTX_cleanup が呼び出されると，OCF スケジューラ録する．. で以下の手続きが行われる．. (1). Free Session における処理を行う．. (4) Process X は，EVP_EncryptUpdate を実行する．. (2). 終了後，sched_list から自身のリストを削除する．. (5) Process X は，EVP_EncryptFinal を実行する．. (3). sched_list の先頭からプロセス ID を 1 つ取り出す．. (6) Process X は，EVP_CIPHER_CTX_cleanup を実行する．処理の終了後，OCF スケジュー. (4). その ID を持つアプリプロセスを，OCF スケジューラにより wake_up_interruptible. ラは，sched_list から自身のリストを削除し，先頭のリストにあるプロセス ID を持つアプリプロセス，つまり Process Y を wake_up_interruptible を用いて起床させる．. を用いて起床させる．. 4.3 提案システムの実行例. (7) Process Y は，EVP_EncryptUpdate を実行する．. ここでは，図 7 を用いて 3 つのアプリプロセス（以降，Process X，Process Y と Process. (8) Process Y は，EVP_EncryptFinal を実行する．. Z とそれぞれ呼ぶ）が暗号モジュールを利用するケースを例として説明する．ここで，アプリプロセスは，X，Y，Z の順で生成されるとする．以下，Process X が実行状態となった時点からの動作例を図 7 と対応させて示す．. (1) Process X は，EVP_EncryptInit を実行する．sched_list が空であることを確認し，当該プロセス ID を sched_list に登録する．. (2) Process Y は，EVP_EncryptInit を実行する．sched_list が空でないため，OCF スケジューラは当該アプリプロセスを sleep させ，当該プロセス ID を sched_list に登. 5. 評. 価. ここでは，オリジナルの OCF と提案システム（以下，sched と呼ぶ）の 2 つのシステムのパフォーマンス計測とその比較により，sched の評価を行う．パフォーマンス計測法として，本論文では IXP425 に対して過負荷をかけ，性能の上限を推し量ることにより，提案方式の有効性を検証する．ただし，負荷をかけるための処理は，3DES（CBC モード）の演算とする．また，DES と AES の結果は，付録に示す．. 5.1 計測方法. 録する．. (3) Process Z は，EVP_EncryptInit を実行する．sched_list が空でないため，OCF ス. OCF と sched の性能評価として，M 個のアプリプロセスで複数回の暗号化を一時に行. ケジューラは当該アプリプロセスを sleep させ，当該プロセス ID を sched_list に登. う．ただし，各アプリプロセスは L バイトの平文データの暗号化処理を N 回ずつ行う．本. 情報処理学会論文誌. Vol. 51. No. 9. 1530–1541 (Sep. 2010). c 2010 Information Processing Society of Japan .

(8) 1537. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. 図 10 OCF と sched の比較（3DES）：プロセス数 20 Fig. 10 Comparison between OCF and sched: 20 processes, 3DES.. 図 8 OCF と sched の比較（3DES）：プロセス数 4 Fig. 8 Comparison between OCF and sched: 4 processes, 3DES.. 図 11 CPU 使用率の比較（3DES） Fig. 11 Comparison of CPU load: 3DES. 図 9 OCF と sched の比較（3DES）：プロセス数 12 Fig. 9 Comparison between OCF and sched: 12 processes, 3DES.. と図 10 にそれぞれ示す．ここで，縦軸は t を示し，単位はマイクロ秒である．また，横軸は N を示す．. 論文では，M を 4，12，20 とし，N を 10 から 1000 までとし 10 刻みにとった．また，L. 実験結果より，M が 4，12 と 20 のいずれケースも，暗号化回数が約 200 回を超えるあ. を 256，512，768，1024，4096 とした．このとき，1 個めのアプリプロセスを生成する直. たりから sched の処理速度の優位が顕著化している．すなわち，アプリプロセス 1 つあた. 前から，生成したすべてのアプリプロセスの暗号化が終わるまでの時間 t を計測した．た. りの暗号化回数の増加にともない，sched の処理時間がオリジナルの OCF の処理時間に比. だし，それぞれ処理時間を 10 回計測し，その平均値を結果として示した．. べて速くなっていることが分かる．よって，提案システムである sched の処理速度の向上が. 5.2 計測結果. 確認でき，OCF スケジューラが有効であるとの結果を得られた．. 5.2.1 処理時間について. 5.2.2 CPU 使用率について. アプリプロセス数 M が 4，12 と 20 のときの OCF と sched を比較した結果を図 8，図 9. OCF と sched の 2 つのシステムにおいて，CPU 使用率を計測した結果（3DES）を，. 情報処理学会論文誌. Vol. 51. No. 9. 1530–1541 (Sep. 2010). c 2010 Information Processing Society of Japan .

(9) 1538. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. 図 11 に示す．ここで，縦軸は CPU 利用率，横軸は平文サイズ L であり，ここでは，8192 まで計測した．オリジナルの OCF では，CPU 利用率はすべてのブロックサイズで 100%であるのに対して，sched ではブロックサイズが大きくなるほど CPU の利用率が下がるという結果が得られた．これは，sched において，暗号処理を暗号モジュール（NPE B）にオフロードしているしている間は，IXP425 の汎用モジュール（XScale コア）を他の処理に利用できるという意味で有意な結果である．したがって，5.2.1 項の結果とあわせて，提案システムである sched の処理速度の向上が確認でき，かつ，オフロードが効果的であることにより，OCF スケジューラが有効であるとの結論を得られた．. 6. まとめ本論文では，Intel 社の Network Processor である IXP425 を搭載する評価ボード（ノバテック社製 NTNP425C）において，OpenSSL のアプリケーションプロセスをスケジューリングする方式の導入により，暗号処理を効率的にオフロードするシステムを提案し，その実装と評価を行った．複数のプロセスが一時に，1 つの暗号モジュール上に暗号処理をオフロードするケースの評価を行った結果，オリジナルの OCF より性能が良くなることを示. 2003). 3) http://ocf-linux.sourceforge.net/ 4) Viega, J. Messier, M. and Chandra, P.: OpenSSL―暗号・PKI・SSL/TLS ライブラリの詳細，オーム社 (Aug. 2004). 5) http://www.uclinux.org/ 6) Barry, P. and Hartnett, G.: Designing Embedded Networking Applications, Intel Press (Mar. 2005). 7) Freier, A.O., Kocher, P. and Kaltorn, P.C.: The SSL Protocol Version 3.0 draft, March 1996, http://home.netscape.com/eng/ssl3/draft302.txt 8) Dierks, T. and Allen, C.: RFC2246: The TLS Protocol Version 1.0 (Jan. 1999). 9) http://www.openssl.org/docs/crypto/engine.html 10) http://www.novatec.co.jp/ 11) Tolly Group, Intel Corp.: IXP425 Network Processors, Performance Analysis of VPN Devices, No.204132 (July 2004). 12) Hughes, J., Morton, G., Pechanec, J., Schuba, C., Spracklen, L. and Yenduri, B.: Transparent Multi-core Cryptographic Support on Niagara CMT Processors, Proc. IWMSE’09 (2009).. 付. 録. し，提案方式の優位性を確認することができた．このことは，IXP425 に限らず，プロセス. ここでは，5 章と同じ条件で，DES における比較と AES における比較を示す．. 数 N に対して暗号モジュール 1 つのケースにおいて，提案方式はオフロードの効率を高め. A.1 DES における比較. ることに有効であると考えられる．. 5 章で示した，3DES の結果と同じように，DES を用いた実験結果においても，M が 4，. 今後は，様々なデータサイズの暗号処理を効率的に行う方式を実現することを目指したい．また，複数の暗号モジュールを持つプロセッサ（例，Oracle 社 SparcT2 および SparcT2plus）への適用を行いたい．謝辞本研究の成果の一部は，科学研究費補助金（課題番号 19700070）の助成を受けたものである．また，本研究の初期において貢献のあった研究室の元メンバの黒羽氏に記して感謝する．最後に，本論文の査読過程において，有益なコメントをいただいた匿名の査読者と編集委員にも記して感謝する．. 参. 考. 文. 献. 1) http://www.openssl.org/ 2) Keromytis, A.D., Wright, J.L. and de Raadt, T.: The Design of the OpenBSD Cryptographic Framework, Proc. USENIX Annual Technical Conference (June. 情報処理学会論文誌. Vol. 51. No. 9. 1530–1541 (Sep. 2010). 図 12 OCF と sched の比較（DES）：プロセス数 4 Fig. 12 Comparison between OCF and sched: 4 processes, DES.. c 2010 Information Processing Society of Japan .

(10) 1539. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. 図 13 OCF と sched の比較（DES）：プロセス数 12 Fig. 13 Comparison between OCF and sched: 12 processes, DES.. 図 15 CPU 使用率の比較（DES） Fig. 15 Comparison of CPU load: DES.. 図 16 OCF と sched の比較（AES）：プロセス数 4 Fig. 16 Comparison between OCF and sched: 4 processes, AES.. 図 14 OCF と sched の比較（DES）：プロセス数 20 Fig. 14 Comparison between OCF and sched: 20 processes, DES.. 12，20 のケースで，暗号化回数が約 200 回を超えるあたりから sched の処理速度の優位が. A.2 AES における比較. 顕著化しており，OCF スケジューラが有効であるとの結果を得られた（図 12，図 13 およ. A.2.1 処理時間について 5 章で示した，3DES の結果と同じように，AES を用いた実験結果においても，M が 4，. び図 14）．. A.1.1 処理時間について. 12，20 のケースで，暗号化回数が約 200 回を超えるあたりから sched の処理速度の優位が. A.1.2 CPU 使用率について. 顕著化しており，OCF スケジューラが有効であるとの結果を得られた（図 16，図 17 およ. OCF と sched の 2 つのシステムにおいて，CPU 使用率を計測した結果（DES）を，図 15. び図 18）．. に示す．これは，sched において，オフロードが有効である有意な結果である．. 情報処理学会論文誌. Vol. 51. No. 9. 1530–1541 (Sep. 2010). c 2010 Information Processing Society of Japan .

(11) 1540. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. 図 17 OCF と sched の比較（AES）：プロセス数 12 Fig. 17 Comparison between OCF and sched: 12 processes, AES.. 図 19 CPU 使用率の比較（AES） Fig. 19 Comparison of CPU load: AES.. (平成 21 年 11 月 30 日受付) (平成 22 年 6 月 3 日採録) 齋藤孝道（正会員）明治大学理工学部情報科学科准教授．博士（工学）．. 図 18 OCF と sched の比較（AES）：プロセス数 20 Fig. 18 Comparison between OCF and sched: 20 processes, AES.. 大釜正裕. 2008 年明治大学理工学部卒業．2010 年明治大学大学院理工学研究科博 A.2.2 CPU 使用率について. 士前期課程修了．2010 年みずほ情報総研株式会社入社．. OCF と sched の 2 つのシステムにおいて，CPU 使用率を計測した結果（AES）を，図 19 に示す．これは，sched において，オフロードが有効である有意な結果である．. 情報処理学会論文誌. Vol. 51. No. 9. 1530–1541 (Sep. 2010). c 2010 Information Processing Society of Japan .

(12) 1541. IXP425 における暗号処理の効率的なオフロード方式の実装と評価. 羅. 鏡栄. 杉浦. 2005 年澳門科技大学理工学部卒業．2010 年明治大学大学院理工学研究科博士前期課程修了．2010 年新八百伴会社入社．. 情報処理学会論文誌. Vol. 51. No. 9. 1530–1541 (Sep. 2010). 寛. 2008 年明治大学理工学部卒業．2010 年明治大学大学院理工学研究科博士前期課程修了．2010 年新日鉄ソリューションズ株式会社入社．. c 2010 Information Processing Society of Japan .

(13)