組込みデバイスの設計で気になるのは処理スピードだけではありません。メモリー容量についても以前よりは制約は緩くなってきたとはいえ、多くの場合できるかぎりの節減がもとめられるのが実情で、特にRAMエリアの容量には注意が求められるケースが多いかと思います。
wolfSSLの場合、設計ポリシーとして静的に確保されるデータエリアは最小限となるよう設計されていますので、今回は、必要の都度確保されるヒープ領域について、その挙動、サイズについて見ていくことにします。
TLSの通信をヒープエリア利用の観点からみると、次のようなステップを踏むことになります。かっこの中はそれぞれのステップで代表的に使用するwolfSSLのAPI名です。
１）コンテクストの確保 (wolfSSL_CTX_new)
２）鍵、証明書の格納 (wolfSSL_CTX_load_verify_locations)
３）セッション管理エリアの確保 (wolfSSL_new)
４）ハンドシェイク (wolfSSL_connect/accept)
５）アプリケーションデータ転送 (wolfSSL_write/read)
図１は、１）～４）の準備段階でのヒープエリアの使用量の一例を示しています。必要とするヒープエリアは、前のステップで確保し引き続き必要とされるエリア（濃い青の部分）とそのフェーズで使用するエリア（薄い青の部分）があります。図１ではTLSクライアント側での値を示しています。サーバ側では絶対値に多少の違いはあるものの、全体として大きな傾向は変わりません。
１）と２）は特定のTLSコンテクストで使用される共通情報を設定するステップです。このフェーズでは、メモリー容量としては使用される鍵や証明書のサイズが大きなファクターとなります。この例では、サーバ認証用の証明書だけが確保されています。実際の利用状況では、クライアント認証のための鍵、証明書を格納する必要がある場合もあります。
３）は、特定の相手方との通信を行うためのTLSセッションの管理エリアを確保します。この例では、１セッション分のエリアを確保していますが、同時に複数のセッションを扱う場合はその分だけのエリアを確保する必要があります。
４）は通信の相手方とのハンドシェークを実際に行うステップです。このステップではメモリー消費の観点からも公開鍵の大きな処理が行われます。
公開鍵処理の最適化についてはこのシリーズの第一回でも紹介したSingle Precision (特定鍵長)最適化が大きな効果を発揮します。ヒープ領域の使用量についてもこの最適化が大きな効果を示しますので、ここではその最適化を適用した場合の例をお見せしています。現在のwolfSSLのバージョンでは、ECCのP-256, RSAの1024, 2048, 3072ビットの各鍵長をサポートしていますが、それ以外の場合はこの最適化は適用できません。また、SP最適化はトレードオフとしてコードサイズが大きくなる傾向にあるので、ROMエリアに制限がある場合には注意が必要です。
図２はアプリケーションデータ転送時のヒープエリアの使用量の一例を示しています。アプリケーションデータ転送時には、公開鍵のようなヒープを多用する暗号化アルゴリズムは必要とされないため、暗号化処理に関するデータエリアは比較的小さくなります。
一方、データ転送のためのバッファエリアが大きなウェイトを占めることになります。TLSレコードはデフォルトでは最大１６ｋバイトとなるため、wolfSSLでもデフォルトではそのサイズのバッファを確保することになるので、ヒープエリアが潤沢に利用で着ない場合は、このサイズを気にする必要が出てきます。
TLSではこの最大レコードサイズをプロトコル実行時に制限することができ、サーバ側が合意するならば、そのサイズを例えば4096、あるいは8196バイトなどの２のｎ乗バイトで指定することができます。wolfSSLでもこのオプションをサポートしており、利用する場合は ビルド時に –enable-maxfragment （あるいはHAVE_MAX_FRAGMENT）を指定し、実行時にwolfSSL_CTX_UseMaxFragmentまたはwolfSSL_UseMaxFragment にて実際のサイズを指定します。
この記事に関して、ご質問、あるいはご意見、ご希望などありましたら info@wolfssl.jp までお知らせください。
連載「WOLFの実力」を最新版から続けて読む
第一回：SP最適化でハンドシェイク所要時間を大幅削減
第二回：データ転送速度をさぐる
第三回：DTLSの実力（その1 DTLSの動作）
第四回：DTLSの実力（その2 性能編）