機能

wolfSSL (以前の CyaSSL) は、主要なインターフェースとして C プログラミング言語をサポートしていますが、Java、PHP、Perl、Python など、他のいくつかのホスト言語もサポートしています (SWIG インターフェースを介して)。現在サポートされていない別のプログラミング言語で wolfSSL をホストすることに関心がある場合は、お問い合わせください。

この章では、ストリーム暗号、AES-NI、IPv6サポート、SSL検査(SNIFFER)サポートなど、wolfSSLのいくつかの機能について、より詳しく説明しています。

機能の概要

wolfSSL機能の概要については、wolfSSL製品Webページを参照してください：https://www.wolfssl.com/products/wolfssl

プロトコルサポート

wolfsslは SSL 3.0 、 tls ( 1.0 、 1.1 、 1.2、1.3 )、および dtls ( 1.0 および1.2 )。以下の機能のいずれかを使用して、使用するプロトコルを簡単に選択できます(クライアントまたはサーバーのいずれかに示すように)。wolfSSLは、SSL 2.0をサポートしていません。OpenSSL互換性レイヤーを使用すると場合、クライアントとサーバーの機能はわずかに異なります。OpenSSL互換機能については、OpenSSL互換性を参照してください。

サーバー機能

wolfDTLSv1_server_method() -DTLS 1.0
wolfDTLSv1_2_server_method() -DTLS 1.2
wolfSSLv3_server_method() -SSL 3.0
wolfTLSv1_server_method() - TLS 1.0
wolfTLSv1_1_server_method() -TLS 1.1
wolfTLSv1_2_server_method() - TLS 1.2
wolfTLSv1_3_server_method() -TLS 1.3
wolfSSLv23_server_method() - SSLv3 - TLS 1.2から最高のバージョンを使用する

wolfSSLは、wolfSSLv23_server_method()関数で堅牢なサーバーダウングレードをサポートしています。詳細については、堅牢なクライアントとサーバーのダウングレードを参照してください。

クライアント機能

wolfDTLSv1_client_method() -DTLS 1.0
wolfDTLSv1_2_client_method_ex() -DTLS 1.2
wolfSSLv3_client_method() -SSL 3.0
wolfTLSv1_client_method() - TLS 1.0
wolfTLSv1_1_client_method() -TLS 1.1
wolfTLSv1_2_client_method() - TLS 1.2
wolfTLSv1_3_client_method() -TLS 1.3
wolfSSLv23_client_method() - SSLv3 - TLS 1.2から最高のバージョンを使用する

wolfSSLは、wolfSSLv23_client_method()関数でロバストクライアントのダウングレードをサポートしています。詳細については、堅牢なクライアントとサーバーのダウングレードを参照してください。

これらの機能の使用方法の詳細については、入門の章を参照してください。SSL 3.0、TLS 1.0、1.1、1.2、およびDTLSの比較については、付録Aを参照してください。

堅牢なクライアントとサーバーのダウングレード

wolfSSLクライアントとサーバーの両方に、堅牢なバージョンのダウングレード機能があります。どちらの側で特定のプロトコルバージョンメソッドが使用されている場合、そのバージョンのみがネゴシエートされるか、エラーが返されます。たとえば、TLS 1.0を使用してSSL 3.0のみのサーバーに接続しようとするクライアントは、接続が失敗し、同様にTLS 1.1に接続すると同様に失敗します。

この問題を解決するために、wolfSSLv23_client_method()関数を使用するクライアントは、必要に応じてダウングレードすることによりサーバーがサポートする最高のプロトコルバージョンをサポートします。この場合、クライアントはTLS 1.0 -TLS 1.3を実行しているサーバーに接続できます(または、wolfSSLで構成されているプロトコルバージョンに応じてSSL 3.0を含むサブセットまたはスーパーセット)。接続できない唯一のバージョンは、長年にわたって不安定であるSSL 2.0と、デフォルトで無効になっているSSL 3.0です。

同様に、wolfSSLv23_server_method()関数を使用するサーバーは、TLS 1.0 -TLS 1.2のプロトコルバージョンをサポートするクライアントを処理できます。wolfSSLサーバーは、セキュリティが提供されていないため、SSLV2からの接続を受け入れることができません。

IPv6サポート

IPv6 を採用していて、組み込み SSL 実装を使用したい場合、wolfSSL が IPv6 をサポートしているかどうか疑問に思っているかもしれません。答えはイエスです。IPv6の上で実行されているwolfSSLをサポートしています。

wolfSSLはIP ニュートラルとして設計されており、IPv4とIPv6の両方で動作しますが、現在のテストアプリケーションはIPv4にデフォルトになります(より広い範囲のシステムに適用されます)。テストアプリケーションをIPv6に変更するには、wolfSSLのコンフィグれションに --enable-IPv6 オプションを使用します。

IPv6に関する詳細情報はここにあります。

https://en.wikipedia.org/wiki/IPv6。

DTLS

wolfSSLは、クライアントとサーバーの両方のDTLS( "データグラム" TLS)をサポートしています。現在のサポートされているバージョンはDTLS 1.0です。

TLSプロトコルは、信頼性の高い媒体(TCPなど)に安全なトランスポートチャネルを提供するように設計されています。アプリケーション層プロトコルが UDP トランスポート (SIP やさまざまな電子ゲームプロトコルなど) を使用して開発され始めたため、遅延に敏感なアプリケーションに通信セキュリティを提供する方法が必要になりました。この必要性は、DTLSプロトコルの作成につながります。

多くの人々がTLSとDTLSの違いがTCPとUDPと同じであると考えています。これは正しくありません。UDP には、(TCP と比較して) 何かが失われた場合に、ハンドシェイク、ティアダウン、および途中での遅延がないという利点があります。一方、DTLSは、拡張SSLハンドシェイクと引き裂きを持ち、ハンドシェイクのTCPのような動作を実装する必要があります。本質的に、DTLSは安全な接続と引き換えにUDPによって提供される利点を逆にします。

DTLは、--enable-dtlsビルドオプションを使用してwolfSSLをビルドするときに有効にできます。

LWIP(軽量インターネットプロトコル)

wolfSSLは、軽量のインターネットプロトコルの実装をすぐに使えるようにサポートしています。このプロトコルを使用するには、DEFINE WOLFSSL_LWIP、またはsettings.hファイルに移動して以下の行のコメントアウトを外してください。

/*#define WOLFSSL_LWIP*/

LWIPの焦点は、完全なTCPスタックを提供しながら、RAMの使用量を減らすことです。その焦点は、wolfSSLがSSL/TLSニーズに理想的なマッチであるエリアであるEmbedded Systemsでの使用に最適です。

TLSエクステンション

wolfSSLによってサポートされているTLS拡張機能のリストと、指定された拡張子に対してRFCを参照することができます。

RFC	拡張	wolfsslタイプ
6066	サーバー名表示	`TLSX_SERVER_NAME`
6066	最大フラグメント長ネゴシエーション	`TLSX_MAX_FRAGMENT_LENGTH`
6066	切り捨てられたhmac	`TLSX_TRUNCATED_HMAC`
6066	ステータスリクエスト	`TLSX_STATUS_REQUEST`
7919	サポートされているグループ	`TLSX_SUPPORTED_GROUPS`
5246	署名アルゴリズム	`TLSX_SIGNATURE_ALGORITHMS`
7301	アプリケーション層プロトコルネゴシエーション	`TLSX_APPLICATION_LAYER_PROTOCOL`
6961	証明書ステータスリクエスト	`TLSX_STATUS_REQUEST_V2`
5077	セッションチケット	`TLSX_SESSION_TICKET`
5746	再ネゴシエーションの提示	`TLSX_RENEGOTIATION_INFO`
8446	鍵共有	`TLSX_KEY_SHARE`
8446	事前共有鍵	`TLSX_PRE_SHARED_KEY`
8446	PSK交換モード	`TLSX_PSK_KEY_EXCHANGE_MODES`
8446	アーリーデータ	`TLSX_EARLY_DATA`
8446	クッキー	`TLSX_COOKIE`
8446	サポートバージョン	`TLSX_SUPPORTED_VERSIONS`
8446	ハンドシェーク承認	`TLSX_POST_HANDSHAKE_AUTH`

暗号サポート

暗号スイート強度と適切な鍵サイズの選択

どの暗号が現在使用されているかを確認するには、メソッドを呼び出すことができます.wolfSSL_get_ciphers()。

この関数は、現在有効な暗号スイートを返します。

暗号スイートにはさまざまな強みがあります。それらはいくつかの異なるタイプのアルゴリズム(認証、暗号化、およびメッセージ認証コード(MAC))で構成されているため、それぞれの強度は選択された鍵サイズによって異なります。

暗号スイートの強度を評価する多くの方法があります。使用される特定の方法は、プロジェクトや企業によって異なると思われ、対称および公開鍵アルゴリズムの鍵サイズ、アルゴリズムの種類、パフォーマンス、既知の弱点などを含めることができます。

nist (米国立標準技術研究所)は、それぞれのさまざまな鍵サイズに同等のアルゴリズム強度を提供することにより、許容可能な暗号スイートを選択することを推奨します。暗号化アルゴリズムの強度は、アルゴリズムと使用される鍵サイズに依存します。NIST Special Publication、SP800-57は、2つのアルゴリズムが次のように同等の強度であると見なされると述べています。

2つのアルゴリズムは、「アルゴリズムを壊す」または鍵を決定するか(与えられた鍵サイズで)鍵を使用してほぼ同じである場合、2つのアルゴリズムが与えられた鍵サイズ(xとy)に対して匹敵する強さと考えられています。資源。特定の鍵サイズのアルゴリズムのセキュリティ強度は、ショートカット攻撃を有していない「X」の鍵サイズを持つすべての鍵を試してみるのにかかる作業量に関して説明しています(すなわち、最も効率的なもの)。攻撃はすべての可能な鍵を試すことです)。

次の2つの表は、NIST SP 800-57の表2(pg。56)と表4(pg。59)の両方に基づいており、アルゴリズム間の同等のセキュリティ強度と強度測定(NIST が推奨するアルゴリズムのセキュリティライフタイムに基づいており、セキュリティの一部を使用しています)。

注：次の表「L」は有限フィールド暗号化(FFC)の公開鍵のサイズであり、「n」はFFCの秘密鍵のサイズで、「K」は重要なサイズと見なされます。整数因数分解暗号化(IFC)、および「F」は、楕円曲線暗号の重要なサイズと見なされます。

セキュリティのビット	対称鍵アルゴリズム	FFC鍵サイズ(DSA、DHなど)	ifc鍵サイズ(RSAなど)	ECC鍵サイズ(ECDSAなど)	説明
80	2tdeaなど	L=1024、n=160	K=1024	F=160-223	セキュリティは2010年まで有効
128	AES-128など	L=3072、n=256	K=3072	F=256-383	セキュリティは2030年まで有効
192	AES-192など	L=7680、n=384	K=7680	f=384-511	長期保護
256	AES-256など	L=15360、n=512	K=15360	f=512+	予見可能な将来のために安全

このテーブルをガイドとして使用して、暗号スイートを分類し始めるために、対称暗号化アルゴリズムの強度に基づいて分類します。これを行う際には、セキュリティのビットに基づいて各暗号スイートを分類することを考案することができます(対称鍵サイズを考慮してください)。

低 - 128ビット未満のセキュリティのビット
中 - セキュリティのビット128ビット
高 - 128ビットより大きいセキュリティのビット

対称暗号化アルゴリズムの強度以外では、暗号スイートの強度は、鍵交換および認証アルゴリズム鍵の鍵サイズに大きく依存します。強度は、暗号スイートの最も弱いリンクと同程度です。

上記の等級付け方法に従って (対称暗号化アルゴリズムの強度のみに基づいて)、wolfSSL 2.0.0 は現在、以下に示すように、低強度の暗号スイート 0 個、中強度の暗号スイート 12 個、高強度の暗号スイート 8 個をサポートしています。以下の強度の分類は、関与する他のアルゴリズムの選択された鍵サイズによって変わる可能性があります。ハッシュ関数セキュリティ強度については、NIST SP 800-57の表3(56)を参照のこと。

場合によっては、"EXPORT"の暗号として参照されている暗号が表示されます。これらの暗号は、米国から強い暗号のソフトウェアを輸出することが違法であったときの米国履歴の期間(1992年に遅く)に由来しました。強い暗号は、米国政府によって(核兵器、戦車、弾道ミサイルなど)によって「弾薬」として分類されました。この制限のため、エクスポートされているソフトウェアは「弱められた」暗号(主により小さな鍵サイズ)を含んでいます。現在、この制限は解除されているため、EXPORT 暗号は必須ではなくなりました。

サポートされている暗号スイート

次の暗号スイートは、wolfSSLによってサポートされています。暗号スイートは、TLSまたはSSLハンドシェイク中に使用される認証、暗号化、およびメッセージ認証コード(MAC)アルゴリズムの組み合わせで、接続のセキュリティ設定をネゴシエートします。

各暗号スイートは、キー交換アルゴリズム、一括暗号化アルゴリズム、およびメッセージ認証コードアルゴリズム (MAC) を定義します。 キー交換アルゴリズム (RSA、DSS、DH、EDH) は、ハンドシェイクプロセス中にクライアントとサーバーが認証する方法を決定します。メッセージストリームの暗号化には、ブロック暗号とストリーム暗号を含む 一括暗号化アルゴリズム (DES、3DES、AES、ARC4) が使用されます。 メッセージ認証コード (MAC) アルゴリズム (MD2、MD5、SHA-1、SHA-256、SHA-512、RIPEMD) は、メッセージダイジェストの作成に使用されるハッシュ関数です。

以下の表は、<wolfssl_root>/wolfssl/internal.h(約706行から始まる)にある暗号スイート(およびカテゴリ)と一致しています。次のリストにない暗号スイートをお探しの場合は、wolfSSLに追加することについてお問い合わせください。

ECC暗号スイート：

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_NULL_SHA
TLS_PSK_WITH_AES_256_CBC_SHA
TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_NULL_SHA256
TLS_PSK_WITH_NULL_SHA384
TLS_PSK_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_PSK_WITH_NULL_SHA256
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_NULL_SHA

静的ECC暗号スイート：

TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384

blake2b暗号スイート：

TLS_RSA_WITH_AES_128_CBC_B2B256
TLS_RSA_WITH_AES_256_CBC_B2B256

SHA-256暗号スイート：

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_NULL_SHA256
TLS_DHE_PSK_WITH_AES_128_CBC_SHA256
TLS_DHE_PSK_WITH_NULL_SHA256

SHA-384暗号スイート：

TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
TLS_DHE_PSK_WITH_NULL_SHA384

AES-GCM暗号スイート：

TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
TLS_DHE_PSK_WITH_AES_256_GCM_SHA384

ECC AES-GCM暗号スイート：

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384

AES-CCM暗号スイート：

TLS_RSA_WITH_AES_128_CCM_8
TLS_RSA_WITH_AES_256_CCM_8
TLS_ECDHE_ECDSA_WITH_AES_128_CCM
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
TLS_PSK_WITH_AES_128_CCM
TLS_PSK_WITH_AES_256_CCM
TLS_PSK_WITH_AES_128_CCM_8
TLS_PSK_WITH_AES_256_CCM_8
TLS_DHE_PSK_WITH_AES_128_CCM
TLS_DHE_PSK_WITH_AES_256_CCM

Camellia Cipher Suites：

TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256

ChaCha暗号スイート：

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
TLS_PSK_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_OLD_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_OLD_POLY1305_SHA256
TLS_DHE_RSA_WITH_CHACHA20_OLD_POLY1305_SHA256

再ネゴシエーション提示拡張特別スイート：

TLS_EMPTY_RENEGOTIATION_INFO_SCSV

AEADスイート

wolfSSLは、AES-GCM、AES-CCM、Chacha-Poly1305などのAEADスイーツをサポートしています。これらのAEADスイートと他のスイートの大きな違いは、追加のクリアテキストデータを使用して暗号化されたデータを認証することです。これは、データを改ざんすることになる中間者攻撃を緩和するのに役立ちます。AEADスイートは、キー付きハッシュアルゴリズムによって生成されたタグと組み合わせたブロック暗号(または最近でもストリーム暗号)アルゴリズムの組み合わせを使用します。これらの2つのアルゴリズムを組み合わせることで、これら 2 つのアルゴリズムの組み合わせは、ユーザーにとって簡単な wolfSSL 暗号化および復号化プロセスによって処理されます。特定のAEADスイートを使用するために必要なのは、サポートされているスイートで使用されるアルゴリズムを単純に有効にすることです。

ブロックとストリーム暗号

wolfSSLはAES、DES、3DES、Camelliaブロック暗号とRC4、およびChacha20ストリーム暗号をサポートしています。AES、DES、3DES、RC4はデフォルトで有効になっています。Camellia、およびChacha20は、(--enable-camellia、および--disable-chachaビルドオプションで)wolfSSLをビルドするときに有効にすることができます。AESのデフォルトモードはCBCモードです。AESを使用してGCMまたはCCMモードを有効にするには、--enable-aesgcmと--enable-aesccmビルドオプションを使用します。特定の使用状況については、使用例とwolfCryptの使用法の例をご覧ください。

SSLはRC4をデフォルトのストリーム暗号として使用しますが、脆弱性のために廃止されています。最近、wolfSSLはChacha20を追加しました。RC4はChachaよりも約11％パフォーマンスが高いですが、RC4は一般にChachaよりも安全性が低いと考えられています。Chachaは、トレードオフとしてセキュリティを追加することで一時代を作り出すと考えられます。

暗号性能の比較を見るには、ここにあるwolfSSLベンチマークWebページを参照してください。。

違いは何ですか？

ブロック暗号は、暗号のブロックサイズであるチャンク単位で暗号化する必要があります。たとえば、AESには16バイトのブロックサイズがあります。そのため、2 バイトまたは 3 バイトの小さなチャンクを何度も暗号化している場合、データの 80% 以上が無駄なパディングであり、暗号化/復号化プロセスの速度が低下し、起動するためにネットワーク帯域幅が不必要に浪費されます。基本的にブロック暗号は、大きなデータのチャンク用に設計されており、パディングを必要とするブロックサイズを有し、固定されていない変換を使用します。

ストリーム暗号は、大量または小さなデータに適しています。ブロックサイズが不要なため、データサイズが小さい場合に適しています。速度が懸念される場合、ストリーム暗号はあなたの答えです。なぜなら、それらは通常、Xorのキーストリームを含むよりシンプルな変換を使用するからです。したがって、メディアをストリーミングする必要がある場合、小さなデータを含むさまざまなデータサイズを暗号化する、または高速暗号が必要な場合は、暗号をストリーミングすることが最善の策です。

ハッシュ機能

wolfSSLはMD2,MD4,MD5,SHA-1,SHA2(SHA-224,SHA-256,SHA-384,SHA-512), SHA-3(BLAKE2)、およびRIPEMD-160などのハッシュ機能をサポートしています。これらの機能の詳細な使用法は、wolfCryptの使用法、ハッシュ関数にあります。

公開鍵オプション

wolfSSLはRSA、ECC、DSA/DSSとDH公開鍵オプションをサポートしています。これらの機能の詳細な使用法は、wolfCryptの使用法、公開鍵暗号にあります。

ECCサポート

wolfSSLは、ECDH-ECDSA、ECDHE-ECDSA、ECDH-RSA、ECDHE-PSK、ECDHE-RSAを含むがこれらに限定されない楕円曲線暗号化(ECC)をサポートしています。

wolfSSLのECC実装は、<wolfssl_root>/wolfssl/wolfcrypt/ecc.hヘッダーファイルと<wolfssl_root>/wolfcrypt/src/ecc.cソースファイルにあります。

サポートされている暗号スイートは、上の表に示されています。ECCは、x86_64以外のビルドでデフォルトで無効になりますが、HAVE_ECCを使用してwolfSSLをビルドするときまたはautoconfシステムを使用してオンにすることができます。

./configure --enable-ecc
make
make check

make checkが実行される場合は、wolfSSLがチェックする多数の暗号スイートに注意してください(チェックがCipher Suitesのリストが作成されていない場合、それ自体で./testsuite/testsuite.testを実行します)。これらの暗号スイートのいずれかを個別にテストすることができます。たとえば、AES256-SHAでECDH-ECDSAを試すために、wolfSSLサーバーの例は次のように開始できます。

./examples/server/server -d -l ECDHE-ECDSA-AES256-SHA -c ./certs/server-ecc.pem -k ./certs/ecc-key.pem

(-d)クライアントの証明書チェックを無効にし、(-l)は暗号スイートリストを指定します。(-c)は使用する証明書であり、(-k)は、使用する対応する秘密鍵です。クライアントを接続するには、次のことを試してください。

./examples/client/client -A ./certs/server-ecc.pem

ここで、(-A)は、サーバーの検証に使用するCA証明書です。

PKCSサポート

PKCS(公開鍵暗号化スタンダード)は、RSA Security、Inc.によって作成および公開された標準のグループを指します。wolfSSLはPKCS＃1、PKCS＃3、PKCS＃5、PKCS＃7、PKCS＃8、PKCS＃9、PKCS＃10、PKCS＃11およびPKCS＃12をサポートしています。

さらに、wolfSSLは、PKCS＃1の一部として標準化されているRSA-Probabilistic Signature Scheme(PSS)のサポートも提供しています。

PKCS #5, PBKDF1, PBKDF2, PKCS #12

PKCS＃5は、パスワード、ソルト、および繰り返し回数を合成してパスワードベースのキーを生成するパスワードベースの鍵導出方法です。wolfSSLはPBKDF1とPBKDF2鍵導出機能の両方をサポートしています。鍵導出関数は、基本鍵および他のパラメータ(上述のようにソルトおよび反復回数など)から派生鍵を生成する。PBKDF1は、派生鍵長がハッシュ関数出力の長さによって囲まれている鍵を導出するためにハッシュ関数(MD5、SHA1など)を適用します。PBKDF2では、鍵を導出するために疑似ランダム関数(HMAC-SHA-1など)が適用されます。PBKDF2の場合、派生鍵の長さは無制限です。

wolfSSLは、PBKDF1およびPBKDF2に加えて、PKCS＃12のPBKDF関数もサポートしています。関数プロトタイプは次のようになります：

int PBKDF2(byte* output, const byte* passwd, int pLen,
           const byte* salt,int sLen, int iterations,
           int kLen, int hashType);

int PKCS12_PBKDF(byte* output, const byte* passwd, int pLen,
                 const byte* salt, int sLen, int iterations,
                 int kLen, int hashType, int purpose);

outputには派生鍵が含まれ、passwdは長さpLenのユーザーパスワードを保持しますpLen、saltは長さsLen、iterationsのソルト入力を保持します。md5、sha1、またはsha2にすることができます。

./configureを使用してwolfSSLをビルドしている場合、この機能を有効にする方法は、オプション--enable-pwdbasedを使用することです

完全な例は<wolfSSL Root>/wolfcrypt/test.cにあります。詳細については、次の仕様からPKCS＃5、PBKDF1、およびPBKDF2にあります。

PKCS＃5、PBKDF1、PBKDF2：https://tools.ietf.org/html/rfc2898

PKCS #8

PKCS＃8は、秘密鍵情報を格納するために使用されている秘密鍵情報構文標準として設計されています。

PKCS #8 標準には、暗号化された秘密鍵と暗号化されていない鍵の両方を格納するための構文を説明する 2 つのバージョンがあります。wolfSSLは、暗号化されていないPKCS＃8の両方をサポートしています。サポートされている形式には、PKCS＃5バージョン1-バージョン2、およびPKCS＃12が含まれます。利用可能な暗号化の種類には、DES、3DES、RC4、およびAESが含まれます。

PKCS＃8：https://tools.ietf.org/html/rfc5208

PKCS #7

PKCS #7 は、エンベロープ証明書であれ、暗号化されていないが署名されたデータ文字列であれ、データのバンドルを転送するように設計されています。この機能は、有効化オプション (--enable-pkcs7) を使用するか、マクロ HAVE_PKCS7 を使用してオンにします。署名者の空のセットを持つ RFC に従って、デフォルトで縮退ケースが許可されることに注意してください。関数 wc_PKCS7_AllowDegenerate() を呼び出して、縮退ケースのオンとオフを切り替えることができます。

サポートされている機能は次のとおりです。

縮退した束
Kari、Kekri、Pwri、Ori、Ktriバンドル
切り離された署名
圧縮およびファームウェアパッケージバンドル
カスタムコールバックサポート
限られたストリーミング機能

PKCS＃7コールバック

ユーザーがPKCS7バンドルが解析された後にユーザーが自分の鍵を選択できるように追加のコールバックおよびサポート機能が追加されました。CEK をアンラップするには、関数 wc_PKCS7_SetWrapCEKCb() を呼び出すことができます。この関数によって設定されたコールバックは、KARIとKEKRIバンドルの場合に呼び出されます。キー ID または SKID は、KARI の場合はオリジネータキーとともに wolfSSL からユーザーに渡されます。ユーザーが自分の KEK で CEK をアンラップした後、使用する復号化されたキーを wolfSSL に戻す必要があります。この例は、ファイルsignedData-EncryptionFirmwareCB.cのwolfSSL-examplesリポジトリにあります。

PKCS7バンドルの復号のために追加のコールバックが追加されました。復号コールバック関数を設定するには、API wc_PKCS7_SetDecodeEncryptedCb()を使用できます。ユーザー定義のコンテキストを設定するには、API wc_PKCS7_SetDecodeEncryptedCtx()を使用する必要があります。このコールバックは、wc_PKCS7_DecodeEncryptedData()の呼び出しで実行されます。

PKCS＃7ストリーミング

PKCS7 デコード用のストリーム指向 API により、入力を一度に渡すのではなく、小さなチャンクで渡すオプションが提供されます。デフォルトでは、PKCS7 によるストリーミング機能はオンになっています。ストリーミングPKCS7 APIのサポートをオフにするには、マクロNO_PKCS7_STREAMを定義できます。Autotoolsでこれを行う例は./configure --enable-pkcs7 CFLAGS=-DNO_PKCS7_STREAMです。

バンドルのデコード/検証時のストリーミングでは、次の関数がサポートされています。

wc_PKCS7_DecodeEncryptedData()
wc_PKCS7_VerifySignedData()
wc_PKCS7_VerifySignedData_ex()
wc_PKCS7_DecodeEnvelopedData()
wc_PKCS7_DecodeAuthEnvelopedData()

NOTE ：wc_PKCS7_VerifySignedData_exを呼び出したとき、引数pkimsgfootがフルバッファであることが予想されます。内部構造は、この場合にpkiMsgHeadになる1つのバッファのストリーミングのみをサポートします。

特定の暗号スイート強制使用

デフォルトでは、wolfSSLは、接続の両側がサポートできる「最高の」(最高のセキュリティ)暗号スイートを選択します。128ビットAESなどの特定の暗号を強制するには、次のようなものを追加します。

wolfSSL_CTX_set_cipher_list(ctx, "AES128-SHA");

wolfSSL_CTX_new()への呼び出しの後に：

ctx=wolfSSL_CTX_new(method);
wolfSSL_CTX_set_cipher_list(ctx, "AES128-SHA");

OpenQuantumsafeのliboqs統合

詳細については、このドキュメントの「Quantum-Safe Cryptographyの実験」を参照してください。

ハードウェアを使っての暗号の高速化

wolfSSLは、さまざまなプロセッサやチップの中のいくつかのハードウェアが加速された(または「支援」)暗号機能を利用することができます。次のセクションでは、wolfSSLがどのテクノロジをサポートしているかについて説明します。

AES-NI

AESは、wolfSSLが常にサポートしてきた世界中の政府が使用する重要な暗号化基準です。Intel は、AES をより高速に実装する新しい命令セットをリリースしました。 wolfSSLは、生産環境向けの新しい命令セットを完全にサポートする最初のSSLライブラリです。

基本的に、IntelとAMDは、AESアルゴリズムの計算集約型部分を実行するCHIPレベルでAES命令を追加し、パフォーマンスを向上させました。現在AES-NIをサポートしているIntelのチップのリストについては、こちらをご覧ください。

https://ark.intel.com/search/advanced/?s=t&AESTech=true

ソフトウェアでアルゴリズムを実行する代わりに、wolfSSLに機能を追加して、チップから命令を直接呼び出すことができます。これは、AES-NIをサポートするチップセットでwolfSSLを実行している場合、AES Cryptoを5〜10倍速く実行できることを意味します。

AES-NIサポートされたチップセットで実行されている場合は、--enable-aesni build optionでAES-NIを有効にします。AES-NIでwolfSSLをビルドするには、GCC 4.4.3以降はアセンブリコードを使用する必要があります。wolfSSLは、同じビルドオプションを使用してAMDプロセッサのASM命令をサポートしています。

AES-NI に関する参考文献と参考資料を、一般的なものから特定のものまで、以下に示します。AES-NIによるパフォーマンス向上の詳細については、Intel Software Networkページへの3番目のリンクを参照してください。

AES-NIは、次のAES暗号モードを加速します：AES-CBC、AES-GCM、AES-CCM-8、AES-CCM、およびAES-CTR。AES-GCMは、Ghash認証のためにIntelチップに追加された128ビットの多数関数を使用することにより、さらに加速されます。

STM32F2

wolfSSLは、STM32F2標準周辺ライブラリを介してSTM32F2ハードウェアベースの暗号化と乱数ジェネレーターを使用できます。

必要な定義については、WOLFSSL_STM32F2をsettings.hに定義してください。WOLFSSL_STM32F2定義は、デフォルトでSTM32F2ハードウェアクリプトとRNGサポートを有効にします。これらを個別に有効にするための定義は、STM32F2_CRYPTO(ハードウェア暗号サポート用)およびSTM32F2_RNG(ハードウェアRNGサポート用)です。

STM32F2標準周辺ライブラリのドキュメントは、次の文書にあります。https://www.stech.com/internet/com/technical_resources/technical_literature/user_manual/dm00023896.pdf

Cavium Nitrox

wolfSSL は Marvell (以前の Cavium) NITROX (https://www.marvell.com/products/security-solutions.html) をサポートしています。 wolfSSL のビルド時に Marvell NITROX サポートを有効にするには、次の構成オプションを使用します。

./configure --with-cavium=/home/user/cavium/software

--with-cavium=**オプションは、ライセンスされたCavium/Softwareディレクトリを指しています。Caviumがライブラリをビルドしないため、wolfSSLはcavium_common.oファイルを引っ張ります。また、githubソースツリーを使用している場合は、キャビウムヘッダーがこの警告に準拠していないため、生成されたメイクファイルから-Wredundant-decls警告を削除する必要があります。

現在、wolfSSLはCavium RNG、AES、3DES、RC4、HMAC、およびRSAを暗号層で直接サポートしています。SSLレベルでのサポートは部分的であり、現在、AES、3DES、およびRC4を実行しています。RSAとHMACは、非ブロッキングモードでキャビウムの呼び出しが利用できるまで遅くなります。クライアントのサンプルプログラムは、暗号テストとベンチマークと同様に、Caviumサポートをオンにします。HAVE_CAVIUM定義を参照してください。

ESP32-WROOM-32

wolfSSLは、ESP32-WROOM-32ハードウェアベースの暗号化を使用できます。

必要な定義については、WOLFSSL_ESPWROOM32をsettings.hに定義してください。WOLFSSL_ESPWROOM32の定義は、デフォルトでESP32-WROOM-32ハードウェアクリプトとRNGサポートを有効にします。現在、wolfSSLは、Crypt層でRNG、AES、SHA、RSAプリミティブをサポートしています。TLSサーバー/クライアント、WolfCryptテスト、ベンチマークを含むプロジェクトの例は、ファイルを展開した後、ESP-IDFの/Examples/Protocols Directoryで見つけることができます。

ESP8266

ESP32 とは異なり、ESP8266 で使用できるハードウェアベースの暗号化はありません。「user_settings.h」の「WOLFSSL_ESP8266」定義を参照してください。または ./configure CFLAGS="-DWOLFSSL_ESP8266" を使用して、組み込み ESP8266 ターゲット用にコンパイルします。

SSL検査(Sniffer)

wolfSSL 1.5.0のリリースから始めて、wolfSSLには、SSL Sniffer(SSL検査)機能を持つようにビルドできるビルドオプションが含まれています。これは、SSLトラフィックパケットを収集し、正しいキーファイルを使用して、それらを復号化できることを意味します。SSLトラフィックを「検査」する機能は、いくつかの理由で役立ちます。その一部には以下が含まれます。

ネットワークの問題の分析
内部および外部ユーザーによるネットワークの誤用を検出します
動きのネットワークの使用とデータの監視
クライアント/サーバー通信のデバッグ

Snifferサポートを有効にするには、*nixで--enable-snifferオプションを使用してwolfSSLをビルドするか、Windowsでvcprojファイルを使用します。*nixまたはwinpcapにpcapをWindowsにインストールする必要があります。sniffer.hで見つけることができるメインスニファー機能は、それぞれの簡単な説明とともに以下にリストされています。

ssl_SetPrivateKey - 特定のサーバーとポートの秘密鍵を設定します。
ssl_SetNamedPrivateKey - 特定のサーバー、ポート、ドメイン名の秘密鍵を設定します。
ssl_DecodePacket-デコードのためにTCP/IPパケットで通過します。
ssl_Trace - デバッグトレースをTraceFileに有効/無効にします。
ssl_InitSniffer - 全体的なスニファーを初期化します。
ssl_FreeSniffer - 全体的なスニファーを解放します。
ssl_EnableRecovery-失われたパケットの場合、SSLトラフィックのデコードを取得しようとするオプションを有効にします。
ssl_GetSessionStats - スニファセッションのメモリ使用量を取得します。

wolfSSLのSnifferのサポートを確認し、完全な例を参照するには、wolfSSLダウンロードのsslSniffer/sslSnifferTestフォルダーのsnifftestアプリを参照してください。

暗号化キーはSSLハンドシェイクにセットアップされているため、その後のアプリケーションデータをデコードするためには、スニファーによってハンドシェークをデコードする必要があることに注意してください。たとえば、wolfSSLのechoserverとechoclientで「snifftest」を使用している場合、サーバーとクライアントの間でハンドシェークが始まる前にSnifftestアプリケーションを開始する必要があります。

スニファは、AES-CBC、DES3-CBC、ARC4、およびCamellia-CBCで暗号化されたストリームのみをデコードできます。ECDHEまたはDHEキー合意が使用されている場合、ストリームは監視できません。RSAまたはECDH鍵交換のみがサポートされています。

wolfSSL Snifferを使用したCallbacksをWOLFSSL_SNIFFER_WATCHでオンにすることができます。SnifferWatch機能をコンパイルした状態で、関数ssl_SetWatchKeyCallback()を使用してカスタムコールバックを設定できます。コールバックは、ピアから送信された証明書チェーン、エラー値、および証明書のダイジェストの検査に使用されます。コールバックから非0値が返される場合、ピアの証明書を処理するときにエラー状態が設定されます。ウォッチコールバックの追加のサポート機能は次のとおりです。

ssl_SetWatchKeyCtx：ウォッチコールバックに渡されるカスタムユーザコンテキストを設定します。
ssl_SetWatchKey_buffer：新しいDER形式キーをサーバーセッションにロードします。
ssl_SetWatchKey_file：ssl_SetWatchKey_bufferのファイルバージョン。

スニファを収集する統計は、マクロWOLFSSL_SNIFFER_STATSを定義することでコンパイルできます。統計はSSLSTATS構造体に保持され、ssl_ReadStatisticsへの呼び出しによってアプリケーションSSLSTATS構造にコピーされます.Sniffer Statisticsで使用する追加のAPIはssl_ResetStatisticsです(統計の収集をリセットします)とssl_ReadResetStatistics(現在の統計値を読み込み、内部状態をリセットします)。以下は、オンになっているときに保存されている現在の統計です。

sslStandardConns
sslClientAuthConns
sslResumedConns
sslEphemeralMisses
sslResumeMisses
sslCiphersUnsupported
sslKeysUnmatched
sslKeyFails
sslDecodeFails
sslAlerts
sslDecryptedBytes
sslEncryptedBytes
sslEncryptedPackets
sslDecryptedPackets
sslKeyMatches
sslEncryptedConns

圧縮

wolfSSLは、zlibライブラリとのデータ圧縮をサポートしています。./configureビルドシステムはこのライブラリの存在を検出しますが、他の方法でビルドしている場合は、定数HAVE_LIBZを定義し、Zlib.hへのパスを含めます。

特定の暗号ではデフォルトで圧縮がオフになっています。オンにするには、SSLが接続または受け入れる前に、関数wolfSSL_set_compression()を使用します。クライアントとサーバーの両方が、圧縮を使用するために圧縮をオンにする必要があります。

送信する前にデータを圧縮すると、送信されて受信されるメッセージの実際のサイズが減少しますが、圧縮によって保存されたデータの量は通常、最も遅いネットワークを除くすべてのもので生で送信するよりも分析に時間がかかることに注意してください。

事前共有鍵

wolfSSLは、静的事前共有キーを使用してこれらの暗号をサポートしています。

TLS_PSK_WITH_AES_256_CBC_SHA
TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_NULL_SHA256
TLS_PSK_WITH_NULL_SHA384
TLS_PSK_WITH_NULL_SHA
TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_CCM
TLS_PSK_WITH_AES_256_CCM
TLS_PSK_WITH_AES_128_CCM_8
TLS_PSK_WITH_AES_256_CCM_8
TLS_PSK_WITH_CHACHA20_POLY1305

これらのスイートは、WOLFSSL_STATIC_PSKオンのwolfSSLに組み込まれています。すべてのPSKスイートは、一定のNO_PSKでビルド時にオフにできます。これらの暗号を実行時にのみ使用するには、wolfSSL_CTX_set_cipher_list() を目的の暗号スイートとともに使用します。

wolfSSLは、Ephemeral Key PSKスイートをサポートしています。

ECDHE-PSK-AES128-CBC-SHA256
ECDHE-PSK-NULL-SHA256
ECDHE-PSK-CHACHA20-POLY1305
DHE-PSK-CHACHA20-POLY1305
DHE-PSK-AES256-GCM-SHA384
DHE-PSK-AES128-GCM-SHA256
DHE-PSK-AES256-CBC-SHA384
DHE-PSK-AES128-CBC-SHA256
DHE-PSK-AES128-CBC-SHA256

クライアントでは、関数wolfSSL_CTX_set_psk_client_callback()を使用してコールバックをセットアップします。<wolfSSL_Home>/examples/client/client.cのクライアントの例は、クライアントのIDとキーをセットアップするための使用例を示していますが、実際のコールバックはwolfssl/test.hに実装されています。

サーバー側では、2つの追加のコールが必要です。

サーバーは、「wolfSSL Server」のサーバーの例で、2回目の呼び出しを使用してクライアントを支援するためにIDヒントを格納します。Server PSKコールバックの例は、wolfssl/test.hでmy_psk_server_cb()にあります。

wolfSSL は、最大 128 オクテットの ID とヒント、および最大 64 オクテットの事前共有鍵をサポートします。

クライアント認証

クライアント認証は、クライアントが接続時に認証のためにサーバーに証明書を送信するように要求することによって、サーバーがクライアントを認証できるようにする機能です。クライアント認証には、CA からの X.509 クライアント証明書 (または、あなたまたは CA 以外の誰かによって生成された場合は自己署名) が必要です。

デフォルトでは、wolfSSLは受信したすべての証明書を検証します - これにはクライアントとサーバーの両方が含まれます。クライアント認証をセットアップするには、サーバーは、クライアント証明書を次のように確認するために使用される信頼できるCA証明書のリストをロードする必要があります。

wolfSSL_CTX_load_verify_locations(ctx, caCert, 0);

クライアントの検証をオンにし、その動作を制御するために、wolfSSL_CTX_set_verify()機能が使用されます。次の例では、SSL_VERIFY_PEERがサーバーからクライアントへの証明書リクエストをオンにします。SSL_VERIFY_FAIL_IF_NO_PEER_CERTは、クライアントがサーバー側で検証する証明書を提示しない場合、サーバーに失敗するように指示します。wolfSSL_CTX_set_verify()のその他のオプションには、SSL_VERIFY_NONEおよびSSL_VERIFY_CLIENT_ONCEが含まれます。

wolfSSL_CTX_set_verify(ctx,SSL_VERIFY_PEER | ((usePskPlus)?
                       SSL_VERIFY_FAIL_EXCEPT_PSK :
                       SSL_VERIFY_FAIL_IF_NO_PEER_CERT),0);

クライアント認証の例は、wolfsslダウンロード(/examples/server/server.c)に含まれるサンプルサーバー(server.c)にあります。

サーバー名の提示

SNIは、サーバーが単一の基礎となるネットワークアドレスで複数の「仮想」サーバーをホストする場合に役立ちます。クライアントが連絡しているサーバーの名前を提供することが望ましい場合があります。WolfsSLでSNIを有効にするには、簡単に実行できます。

./configure --enable-sni

クライアント側にSNIを使用するには、追加の関数呼び出しが必要です。これは、次の機能の1つである必要があります。

クライアントが同じサーバーに複数回連絡すると、wolfSSL_CTX_UseSNI()が最も推奨されます。コンテキストレベルでのSNI拡張子を設定すると、呼び出しの瞬間から同じコンテキストから作成されたすべてのSSLオブジェクトのSNI使用法が可能になります。

wolfSSL_UseSNI()は1つのSSLオブジェクトのみのSNI使用を有効にするため、サーバー名がセッション間で変更されたときにこの関数を使用することをお勧めします。

サーバー側では、同じ関数呼び出しの1つが必要です。wolfSSL Serverは複数の「仮想」サーバーをホストしていないため、SNIの不一致の場合に接続の終了が必要な場合にSNIの使用が役立ちます。このシナリオでは、wolfSSL_CTX_UseSNI()がより効率的になります。サーバーは、同じコンテキストからSNIを使用して後続のすべてのSSLオブジェクトを作成するコンテキストごとに1回しか設定しないためです。

ハンドシェイクの変更

ハンドシェイクメッセージのグループ化

wolfSSLには、ユーザーが望む場合、ハンドシェイクメッセージをグループ化する機能があります。これは、wolfSSL_CTX_set_group_messages(ctx);のコンテキストレベルで、またはwolfSSL_set_group_messages(ssl);のSSLオブジェクトレベルで実行できます。

短縮されたHMAC.

現在定義されているTLS暗号スイートは、HMACを使用してレコード層通信を認証します。TLSでは、ハッシュ関数の出力全体がMacタグとして使用されます。ただし、MACタグを形成するときにハッシュ関数の出力を80ビットに切り捨てることにより、帯域幅を節約することは、制約付き環境で望ましい場合があります。wolfSSLで切り捨てられたHMACの使用を可能にするには、簡単にできることを説明できます。

./configure --enable-truncatedhmac

クライアント側に切り捨てられたHMACを使用するには、追加の関数呼び出しが必要です。これは、次の機能の1つである必要があります。

クライアントがすべてのセッションに対して切り捨てられたHMACを有効にしたい場合に最も推奨されます。コンテキストレベルでの切り捨てられたHMAC拡張子を設定すると、呼び出しの瞬間と同じコンテキストから作成されたすべてのSSLオブジェクトでそれを有効にします。

wolfSSL_UseTruncatedHMAC()は1つのSSLオブジェクトのみを有効にします。そのため、すべてのセッションでTruncated HMACを必要としない場合はこの機能を使用することをお勧めします。

サーバー側では、通話は不要です。サーバーは、クライアントの切り捨てられたHMACの要求に自動的に注意を払っています。

すべてのTLS拡張機能を有効にすることもできます。

./configure --enable-tlsx

ユーザー暗号モジュール

ユーザーCryptoモジュールを使用すると、ユーザーがサポートされている操作中に使用したいカスタム暗号をプラグインできます(現在RSA操作がサポートされています)。モジュールの例は、IPPライブラリを使用してディレクトリroot_wolfssl/wolfcrypt/user-crypto/にあります。Cryptoモジュールを使用するためにwolfSSLをビルドするときの構成オプションの例は次のとおりです。

./configure --with-user-crypto

また

./configure --with-user-crypto=/dir/to

RSA操作を実行するユーザー暗号モジュールを作成するときは、user_rsa.hと呼ばれるRSA用のヘッダーファイルがあることが必須です。すべてのユーザー暗号操作では、ユーザーライブラリがlibusercryptoと呼ばれます。これらはwolfSSL AutoConfツールの名前です。ユーザー暗号モジュールをリンクして使用するときに探してください。wolfSSLを備えた例では、ヘッダファイルuser_rsa.hはディレクトリwolfcrypt/user-crypto/include/にあり、作成されたライブラリはディレクトリwolfcrypt/user-crypto/lib/にあります。提供されているヘッダーファイルを参照してください。

例を作成するには、IPPライブラリをインストールした後、ルートwolfSSLディレクトリから次のコマンドを実行する必要があります。

cd wolfcrypt/user-crypto/
./autogen.sh
./configure
make
sudo make install

wolfSSLの添付の例では、プロジェクトをビルドする前にインストールする必要があるIPPの使用が必要です。ただし、例をビルドするためのIPPライブラリを持っていなくても、ファイル名選択とAPIインターフェイスの例をユーザーに提供することを目的としています。ライブラリlibusercryptoとヘッダーファイルの両方を作成してインストールしたら、wolfSSLを使用すると、Cryptoモジュールは追加のステップを必要としません。Configure Flag --with-user-cryptoを使用するだけで、一般的なwolfSSL暗号からのすべての関数呼び出しをユーザー暗号モジュールにマッピングします。

メモリの割り当ては、wolfSSLのXMALLOCを使用している場合は、DYNAMIC_TYPE_USER_CRYPTOでタグ付けする必要があります。モジュールで使用されるメモリ割り当てを分析できます。

ユーザーの暗号モジュールは、wolfsslの設定オプションの速いRSAおよび/またはFIPSと組み合わせて使用することはできません。FIPSには、特定の認証コードを使用し、FAST-RSAを使用してRSA操作を実行するために例ユーザー暗号モジュールを使用します。

Wolfsslのタイミング耐性

wolfSSLは、潜在的にリークタイミング情報を漏らす可能性のある比較操作を行うときに一定の時間を保証する関数"ConstantCompare"を提供します。このAPIは、タイミングベースのサイドチャネル攻撃を阻止するために、wolfSSLのTLSレベルと暗号レベルの両方で使用されます。

wolfSSL ECC実装には、ECCアルゴリズムのタイミング耐性を有効にするために、ECC_TIMING_RESISTANTを定義しています。同様に、定義TFM_TIMING_RESISTANTは、RSAアルゴリズムのタイミング耐性のFast Mathライブラリに提供されます。関数exptmodは、タイミング耐性のモンゴメリーラダーを使用します。

参照：--disable-harden

処理時間一定化とキャッシュ抵抗は、--enable-hardenで有効になっています。

WOLFSSL_SP_CACHE_RESISTANT：使用するアドレスをマスクするロジックを有効にします。
WC_RSA_BLINDING：タイミング攻撃を防ぐために、ブラインドモードを有効にします。
ECC_TIMING_RESISTANT：ECC固有の処理時間一定化。
TFM_TIMING_RESISTANT：Fast Math固有の処理時間一定化。

固定化されたABI

wolfSSLは、アプリケーションプログラミングインターフェイス(API)のサブセットに固定アプリケーションバイナリインターフェイス(ABI)を提供します。次の機能は、wolfSSL v4.3.0以降、wolfSSLの将来のすべてのリリースにわたって互換性があります。