うるふブログ

wolfSSL 4.7.0 をリリースしました

wolfSSLの新しいバージョン4.7.0をリリースしました。このリリースには一般的な修正と最適化、機能追加、およびいくつかの脆弱性の修正を含んでいます。TLS1.3の問題について報告をいただいたTélécom SudParisのAina Toky Rasoamanana氏とOlivier Levillain氏に感謝します。

機能追加


  • OpenSSL互換レイヤーを拡張し、SSL_get_verify_mode,X509_VERIFY_PARAM, X509_STORE_CTX APIを追加
  • TLSアラートのサブセットを有効にするためのWOLFSSL_PSK_IDENTITY_ALERTマクロの追加
  • TLS1.3セッションチケットを保持したままTLS1.2セッションチケットを無効化するためのwolfSSL_CTX_NoTIcketTLSv12関数を追加
  • RFC 5705:Keying Material Exporters for TLS を実装
  • デバッグ支援としてより決定的なライブラリ出力を得るための”–enable-reporoducible-build” コンフィギュレーションオプションの追加

修正事項


  • 証明書マネジャが解放された際にmutexを開放するように修正
  • OpenSSL互換レイヤーのEVP関数が正しいブロックサイズとタイプを返すように修正
  • DTLSの再ネゴシエーション機能における修正(HelloRequestの複製時のタイムアウトのリセットと再送)
  • バッファ縮小化時と再ネゴシエーション時のエッジケースでの修正
  • curve448とPPC64を使用した際のコンパイルエラーを修正
  • word長の剰余でモンゴメリリダクション演算を行う際の演算ライブラリSP Math Allを修正
  • 演算ライブラリSP Math Allを8ビット長のdigitに対するサポートを改良
  • 演算ライブラリSP integer の平方演算のエッジケースを修正
  • SP実装における ARM64ビルド時で、非ct mod-inv演算にx29レジスターを使用しないように変更
  • SP実装における ECCのz値の生成時のエッジケースを修正
  • PKCS7形式証明書を扱う際、RSAとRNGでのコールバック(devId)の修正
  • RSA署名検証とPublicのみを指定した際のコンパイルエラーを修正
  • PKCS11 APIで鍵のタイプ指定欄が無い場合に公開鍵を正しくエクスポートできない問題を修正
  • 証明書の深さに関する障害でコールバックが呼ばれない件を修正
  • TLSX_CSR_Parse()で範囲外のリードが発生する障害を修正
  • EVPレイヤーで不正なAES-GCMタグが生成される障害を修正
  • 演算ライブラリSP Math Allで範囲外書き込みの発生とsp_mont_normの結果に対してsp_tohexを呼び出してしまうエッジケースを修正
  • sp_rand_primeが長さ0の値が引数として与えられるケースのチェックを強化
  • small stack使用が有効になっているケースでSHA256/SHA512の処理時にmallocが失敗して範囲外書き込みが発生するエッジケースを修正

性能改善/最適化


  • wolfSSLをwolfTPMと共にビルドできるように”–enable-wolftpm” コンフィギュレーションオプションを追加
  • タイムアウト時のみ再送を行う指定のために、DTLS用のマクロ”WOLFSSL_DTLS_RESEND_ONLY_TIMEOUT” を追加
  • kvmalloc とkvfreeを利用するようにlinuxカーネルモジュールを更新
  • AES GCMセッションチケットの暗号化をサポート
  • wolfSSL_RAND_bytes関数で使用されるグローバルRNGに対してスレッド保護を追加
  • FIPSバンドルバージョンに対してFIPSコンフィギュレーションオプションのサニティチェックを追加
  • “–enable-aesgcm=table” オプションは”–enable-linuxkm”オプションとコンパチブルに改善
  • wolfSSL_RAND_bytes関数が扱える出力バッファサイズを増加
  • ディレクトリ外ビルドをが可能に。wolfSSLはwolfsslルートディレクトリ以外でもビルドできるよう改善

脆弱性対応


  • [HIGH] CVE-2021-3336:以前のバージョンのwolfSSLにおいてTLS1.3クライアントとして動作の際に、潜在的な中間者攻撃を受ける脆弱性が存在しました。ネットワーク上の位置に関する権限を有する悪意ある攻撃者はTLSサーバーに成りすまし認証をバイパスすることが可能でした。TLS1.3を有効にされているクライアント側のアプリケーションコードをお持ちのお客様はwolfSSLの最新バージョンへのアップデートを行ってください。TLS1.3を有効にされていない、あるいはサーバー側のアプリケーションコードをお持ちのお客様はこのレポートされている脅威の影響は受けません。コード変更についてはここ(#3676)を参照ください。
  • [LOW]カスタムECC曲線を利用し、カスタムprime値を持ち圧縮されたECC鍵が使われるとその鍵がインポートされた際にハングする潜在的な可能性がありました。wolfSSLをビルドする際に、圧縮されたECC鍵の利用とカスタム曲線ECCの使用を有効にしているアプリケーションのみが影響を受けます。
  • [LOW]TLS1.3の認証付き暗号化を使う暗号化スイートでServerHelloパケットのあるセクションは未初期化の16バイトのデータを含み、接続先の相手に送信することができました。脅威はwolfSSLをTLS1.3のeraly dataを有効にして、認証付き暗号化を使う暗号化スイートを利用する際に影響を受けます。

脆弱性に関する追加情報は以下を参照ください。
https://www.wolfssl.com/docs/security-vulnerabilities/

 

リリースのアイテムの完全なリストは、wolfSSLにバンドルされているChangeLog.mdでご確認ください。

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

wolfSSLのOCSPサポート

wolfSSLは、クライアントとしてOCSP (Online Certificate Status Protocol、オンライン証明書ステータスプロトコル) [https://tools.ietf.org/html/rfc2560]を、また、OCSP Stapling version 1 [https://tools.ietf.org/html/rfc6066#section-8]および2 [https://tools.ietf.org/html/rfc6961]をサポートしています。OCSPは、CRL(Certificate Revocation Lists、証明書失効リスト)の代替となるものです。CRLは、一時的または永続的に信頼すべきではない証明書のリストです。CRLの大きな欠点は、これらのリストが広く伝わるのに時間がかかることです。CRLは認証局(CA)から定期的に発行されるため、最大で1週間かかることがあります[https://tools.ietf.org/html/rfc5280#section-3.3]。OCSPを使用すると、クライアントはOCSPレスポンダーを使用してサーバー証明書の有効性を検証し、証明書を信頼するかどうかをリアルタイムで知ることができます。

OCSPステープリングは、証明書のステータス情報を受信するようにサーバーに指示する、クライアントが送るTLS拡張です。ステープリングは、接続を確立するために必要な帯域幅とラウンドトリップを大幅に削減します。TLSサーバーは、クライアントから証明書ステータス要求拡張機能を受信すると、OCSPレスポンダーに完全なDERエンコードされたOCSP応答を送信します。これにより、クライアントはOCSPレスポンダーに証明書の有効性を問い合わせる必要がなくなり、頻繁にアクセスするサーバーのクライアントから来るOCSPレスポンダーの帯域幅を節約することができます。

OCSPステープリングのバージョン1では、1つの証明書のステータス情報しか送信できないという厳しい制限があります。多くのTLSサーバは、クライアントが中間証明書チェーンを知らない場合に備えて、自身の証明書と一緒に中間証明書を送信することを選択します。OCSPステープリングのバージョン1は、クライアントがサーバの証明書のステータスを確認する手間を省くだけで、中間証明書を確認する手間は省けません。OCSPステープリングのバージョン2では、「サーバー自身の証明書だけでなく、チェーン内の中間証明書のステータス情報を提供する」ことを可能にする新しい拡張機能が定義されています[https://tools.ietf.org/html/rfc6961]。

OCSPをサポートするwolfSSLをコンパイルするには、以下のconfigureオプションを使用します。

OCSP: --enable-ocsp
OCSP stapling: --enable-ocspstapling
OCSP stapling v2: --enable-ocspstapling2

OCSPの利用を可能にするために、wolfSSLでは以下のAPIを用意しています。

int wolfSSL_CTX_EnableOCSP(WOLFSSL_CTX*, int options);
 int wolfSSL_CTX_DisableOCSP(WOLFSSL_CTX*);
 int wolfSSL_CTX_SetOCSP_OverrideURL(WOLFSSL_CTX*, const char*);
 int wolfSSL_CTX_SetOCSP_Cb(WOLFSSL_CTX*,
 CbOCSPIO, CbOCSPRespFree, void*);
 int wolfSSL_CTX_EnableOCSPStapling(WOLFSSL_CTX*);
 int wolfSSL_CTX_DisableOCSPStapling(WOLFSSL_CTX*);
 int wolfSSL_CTX_EnableOCSPMustStaple(WOLFSSL_CTX*);
 int wolfSSL_CTX_DisableOCSPMustStaple(WOLFSSL_CTX*);

wolfSSLでOCSPを使うには、以下のフローで可能です。

wolfSSL_CTX_EnableOCSP(ctx, 0);

OCSPのステープリングを使用するには:

wolfSSL_CTX_EnableOCSPStapling(ctx); 
wolfSSL_UseOCSPStapling(ssl, WOLFSSL_CSR_OCSP, 0);
wolfSSL_CTX_EnableOCSP(ctx, 0);

 

 

OCSPステープリングのバージョン2を使用する場合は:

wolfSSL_CTX_EnableOCSPStapling(ctx); 
wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP*, 0);
wolfSSL_CTX_EnableOCSP(ctx, 0);

 

* 中間証明書のステータス要求情報を提供するには、WOLFSSL_CSR2_OCSP_MULTIを使用します。

サーバーがOCSPステープリング応答を提供することを許可するには:

wolfSSL_CTX_EnableOCSP(ctx, 0);

カスタムOCSPレスポンダーのURLを提供するには:

wolfSSL_CTX_SetOCSP_OverrideURL(ctx, ocspUrl); 
wolfSSL_CTX_EnableOCSP(ctx, WOLFSSL_OCSP_URL_OVERRIDE);

OCSPステープリングバージョン2は、非推奨となっているため、TLS 1.3では使用できません[https://tools.ietf.org/html/rfc8446#section-4.4.2.1]。TLS 1.3はOCSPステープリングバージョン1を使用していますが、証明書のステータスは独立したメッセージではありません。対応する証明書の拡張機能として含まれています。

wolfSSLの機能の詳細については、support@wolfssl.com までメールでお問い合わせください。

 

原文: https://www.wolfssl.com/wolfssl-online-certificate-status-protocol-ocsp-support/

ウェビナー「OpenSSLアプリケーションのスムーズな移行のために」

wolfSSLが主催するウェビナー開催のご案内です。

OpenSSLアプリケーションのスムーズな移行のために

2021年4月21日(水) 14:00~14:30

wolfSSLは、OpenSSLアプリケーションを容易に移行できるようにOpenSSLとの互換APIレイヤーを提供しています。今回は、この互換レイヤーの概要とAPI対応状況、利用方法、移行の際の注意点などについて具体的に説明いたします。

本ウェビナーは日本語で開催します。
約30分の予定です。

参加希望の方はこちらからご登録ください。ご登録後、ウェビナー参加に関する確認メールをお送りします。

ぜひ皆様のご参加をお待ちしています。
ご質問がおありでしたら、info@wolfssl.jp までご連絡ください。

 

そのほかのウェビナー開催予定、オンデマンド版の公開についてはこちらをご覧ください。

RFC5705: TLSのための鍵要素エクスポート

wolfSSL 4.7.0は、RFC5705で定義されているTLSのKeyingMaterialExportersがサポートされるようになりました。 この新しい機能により、アプリケーションは、基盤となる(D)TLS接続を使用して共通のシークレットを確立できます。 エクスポートされたキー情報を利用するよく知られたプロジェクトは、OpenVPN(wolfSSLがサポートしています!)です。 –keying-material-exporterオプションでユーザー指定のラベルを使用して、(D)TLS接続からプラグインで使用するための安全な共有シークレットを生成します。 wolfSSLでキー情報をエクスポートするには、次のAPIを使用します。

int wolfSSL_export_keying_material(WOLFSSL *ssl,  unsigned char *out,     size_t outLen,
    	const char *label, size_t labelLen, const unsigned char *context, size_t contextLen,
    	int use_context);

このAPIは、outLenバイトのデータをoutに出力します。 ラベルとコンテキストは、RFCで定義されているものと一致します。

  • label  : ラベル文字列
  • context : ユーザーによって提供されるアソシエーションごとのコンテキスト値

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

原文:https://www.wolfssl.com/rfc-5705-keying-material-exporters-tls/

 

wolfSSLにおけるDTLSの帯域最適化

wolfSSLはDTLS 1.2に準拠した堅固で安全な実装を提供しています。ハンドシェーク中の次の状況ではデータの再送を行います:

  1. データ受信タイムアウトが発生した場合
  2. 通信相手の現フライト(一連のパケット)の最後のメッセージの到着順序が入れ替わった
  3. 通信相手の現フライトの最初のメッセージが重複して受信された

これらの手順は、高速で信頼性の高い接続プロセスの提供に必要です。残念ながら、後者の2つのケースでは、wolfSSLがハンドシェイクに必要な帯域幅よりも多くの帯域幅を消費する可能性があります。ネットワーク帯域幅が貴重で、待ち時間の心配が少ない場合、wolfSSL4.7.0は新しいマクロWOLFSSL_DTLS_RESEND_ONLY_TIMEOUTを導入しました。

このマクロを使用してwolfSSLをコンパイルするには、configureコマンドに追加するか(たとえば、./ configure –enable-dtls CPPFLAGS = -DWOLFSSL_DTLS_RESEND_ONLY_TIMEOUT)、user_setting.hヘッダーファイルで定義します。このマクロは、ネットワークタイムアウト時にメッセージの最後のフライトのみを再送信するようにwolfSSLに指示します。実際には、ハンドシェイクメッセージを再送信するまでの待機時間が長くなるため、並べ替わったメッセージの処理を行う機会が得られ、重複したメッセージが再送信をトリガーすることはありません。

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

原文:https://www.wolfssl.com/wolfssl-dtls-bandwidth-optimization/

wolfSSLウェビナー「FIPS140-3」

wolfSSLウェビナー開催のご案内です。

FIPS140-3

2021年4月7日(水) 10:00~10:30

スピーカー:
Kaleb Himes
wolfSSL Inc. Software Engineer
 

現在、wolfSSLではFIPS 140-3認証取得に向けて、準備を進めています。
このウェビナーでは、FIPS140-3について、新しくなった内容、FIPS 140-2からの移行、サイバーセキュリティにとっての重要性、およびwolfSSLが製品にどのように実装しているかについて説明します。

本ウェビナーは英語で開催します。
約30分の予定です。

参加希望の方はこちらからご登録ください。ご登録後、ウェビナー参加に関する確認メールをお送りします。

 

ぜひ皆様のご参加をお待ちしています。
ご質問がおありでしたら、info@wolfssl.jp までご連絡ください。

 

そのほかのウェビナー開催予定、オンデマンド版の公開についてはこちらをご覧ください。

製品組み込み向けIDPS、wolfSentryの紹介

wolfSSLには、現在開発中の新製品があります。名前はwolfSentryと言います。ユニバーサルで動的な埋め込み可能な製品組み込み向けIDPS(侵入検知および防止システム)です。wolfSSL、wolfSSHなどと組み合わせることで、お客様の製品に侵入検知、防止機能を追加します。

ネットワークセキュリティの脅威はますます拡大しています。サイバー攻撃のリスクはサーバマシンやPCのようないわゆるIT機器に限らず、オフィス機器、病院の検査装置、工場の制御機器、車載機器などあらゆるネットワーク接続された機器に広がっています。こうしたサイバー環境では、機器のネットワーク通信を強固なセキュリティプロトコルで守るだけでなく、機器がさらされている攻撃をいち早く検知しそれを予防することまで求められています。wolfSentryは既存のネットワーク接続機器にIDPS機能を提供するための製品組み込み向けのIDPSです。 組込み向けセキュリティプロトコルの専門ベンダとして培ったノウハウと知見を活かし、業界に先駆けて製品化するものです。

wolfSentryは動的に構成可能なロジックハブであり、ユーザー定義のイベントをユーザー定義のアクションに任意に関連付け、接続属性によってコンテキスト化し、クライアントサーバー関係の進化をトラッキングします。ローレベルで、wolfSentryはファイアウォールエンジンであり(静的および完全に動的の両方)、既知のホスト/ネットブロックのO(log n)ルックアップを備えています。

wolfSentryはwolfSSLwolfMQTT、およびwolfSSHに完全に統合され、オプションのツリー内コールインとコールバックにより、アプリケーション開発者は実行可能なゼロ構成オプションを使用してネットワークに面するすべてのwolfSSL製品でターンキーIDPSを実行できます。これらの統合は、wolfSSL関連製品の単純な–enable-wolfidps構成オプションを介して利用可能です。

wolfSentryエンジンは、APIを介して、またはエンジンに提供されるテキスト入力ファイルから、プログラムで動的に構成できます。 MQTTまたはsyslogを介したリモートロギング、リモート構成およびステータスクエリなど、すべて暗号化された高度な機能を提供するコールバックおよびクライアントサーバー実装も提供します。

wolfSentryは特に、リソース制約のあるベアメタルおよびリアルタイム環境で適切に機能するようにゼロから設計しており、指定された最大メモリフットプリント内にとどまり、決定論的なスループットを維持するアルゴリズムを備えています。動的ファイアウォールを備えたwolfSentryは、コードフットプリントにわずか64k、揮発性状態のフットプリントに32kを追加し、アプリケーションとwolfSSL社の他のライブラリの既存のロジックと状態を完全に活用できます。

wolfSentryの最初のベータリリースは2021年4月を目指しており、その後ターンキー製品の統合を予定しています。

 

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

原文:https://www.wolfssl.com/introducing-wolfsentry-embedded-idps/

 

TLS1.3とTLS1.2におけるSession Ticket

wolfSSLを利用されている皆さんの中でTLS1.3の利用を選択されている方々の比率がますます増えているのは大変素晴らしいことです。新しいプロトコルを使って、向上したセキュリティの恩恵にあずかる企業が増えているということです。同時に、アプリケーションでセッションチケットを使ってセッション再開を行う必要性に初めて気付かれた方々がいらっしゃいます。最新のwolfSSL 4.7.0ではこれまでより簡単にセッションチケットを扱えるようになりました。

暗号化アルゴリズム

セッションチケットを扱うにはそれらを暗号化および復号するためのコールバックの実装が必要です。wolfssl/test.hにその実装例があります。myTicketEncCb()関数を見てください。以前はChacha20-Poly1305を使って暗号化するために使われていましたが、現在は代わりにAES-GCMを使用するようになっています。皆さんのアプリケーションに適したアルゴリズムを選択してください。

デフォルト暗号化コールバック

wolfSSLでは、デフォルトのコールバックを提供することは価値があると判断しました。 そこでwolfSSL 4.7.0には、デフォルトのセッションチケット暗号化コールバックを含めています。このコールバックの機能を理解すると、デフォルトを使用するか、あるいは独自に作成する必要があるか判断できます。 コールバックは、セッションチケットの暗号化と復号に使われます。次のいずれかを定義することにより、使用する暗号化アルゴリズムを選択できます:

  • WOLFSSL_TICKET_ENC_CHACHA20_POLY1305         — ChaCha20-Poly1305を使用
  • WOLFSSL_TICKET_ENC_AES128_GCM                           — 128ビット長の鍵でAES-GCMを使用
  • WOLFSSL_TICKET_ENC_AES256_GCM                           — 256ビット長の鍵でAES-GCMを使用

それ以外の場合、デフォルトはChaCha20-Poly1305になります。そのアルゴリズムがコンパイルされていない場合は、128ビット長のAES-GCMを使用します。

コールバックで生成される鍵には、プライマリとセカンダリの2つがあります。プライマリキーは、最初の使用時に秘密の乱数ジェネレーターを使用して生成され、その時点で有効期間が与えられます。デフォルトでは、これは1時間です。 WOLFSSL_TICKET_KEY_LIFETIMEを定義することにより、2段階でカスタマイズできます。有効期間は、デフォルトで5分であるセッションチケットの有効期間よりも長くする必要があります。これも、SESSION_TICKET_HINT_DEFAULTを定義することにより、2段階で変更できます。鍵の寿命が長いほど、鍵が危険にさらされた場合の露出時間が長くなります。

には、暗号化用と復号用の2つの有効期間があります。 チケットの暗号化に使用されるは、チケットの存続期間中保持する必要があります。 したがって、暗号化の有効期間は、の合計有効期間、つまり復号の有効期間よりも、チケットの有効期間だけ短くなります。 次の図を参照してください。

プライマリキーが暗号化のために期限切れになっているが復号のためは期限切れになっていない場合、つまり上の影付きの領域にある場合、次の暗号化要求でセカンダリキーが生成されます。

セカンダリキーは、暗号化の有効期限が切れるまで使用され、その後、新しいプライマリキーが生成されます。 セッションチケットが一般的に使用されないシナリオでは、暗号化の新しい呼び出しの前に、プライマリキーが復号のために期限切れになる可能性があることに注意してください。 この場合、新しいプライマリキーが生成されます。 マルチスレッド環境では、グローバルキーの生成はミューテックスによって保護され、上書きされないようにします。

のエクスポートとインポートは:

  • wolfSSL_CTX_get_tlsext_ticket_keys( )
  • wolfSSL_CTX_set_tlsext_ticket_keys( )

を使用して行うこともできます。 これらのAPIは、プロセスまたはサーバーマシン間でを共有するのに役立ち、有効期限はblobに含まれています。 デフォルトのセッションチケット暗号化コールバックは、ほとんどのユースケースをカバーするはずです。しかし、 別の暗号化アルゴリズムを使用する場合、メモリが非常に限られている場合、またはサーバー間で高度な共有戦略が必要な場合は、WOLFSSL_NO_DEF_TICKET_ENC_CBを定義し、独自のコールバックを設定する必要があります。

TLS1.3とTLS1.2におけるセッションチケットの利用

現在TLS 1.3を使用している方々でも、TLS 1.2接続ではセッションチケットを使用していなかったため、引き続きTLS1.2ではセッションチケットが使用されないようにしたいと考える方がいらっしゃるでしょう。 現在、そのような要求をサポートする次の関数を用意しています:

  • wolfSSL_CTX_NoTicketTLSv12( )
  • wolfSSL_NoTicketTLSv12( )

これらの関数を呼び出すと、コンテキストまたはオブジェクトに対してフラグが設定され、ネゴシエートされたプロトコルバージョンがTLS 1.2以下の場合、ハンドシェイクではクライアントとサーバーのセッションチケットを無視します。

 

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

原文:https://www.wolfssl.com/wolfssl-session-tickets-tls-1-3-tls-1-2/

cmakeによるビルドをサポート

wolfSSL 4.7.0からcmakeによるビルドでuser_settings.hをサポートします。この機能を有効にするには、”-DWOLFSSL_USER_SETTINGS=yes” オプションを追加してcmakeコマンドを実行してください。

組み込み機器向けにwolfSSLライブラリをコンフィギュレーションしてビルドする最適な方法は”user_settings.h”ファイルを作成することです。そして、皆さんのアプリケーションでWOLFSSL_USER_SETTINGS定義を行い、<wolfssl/wolfcrypt/settings.h>ヘッダファイルがライブラリにインクルードされる際に同時にuser_settings.hもインクルードされるようにします。アプリケーションは<wolfssl/wolfcrypt/settings.h>ヘッダファイルを他のwolfSSLが提供するどのヘッダファイルよりも先にインクルードする必要があります。組み込み機器プロジェクトを開始する際のuser_settings.hの良い参考例としては、wolfssl-4.7.0/IDE/GCC-ARM/Header/user_settings.hがあります。この例には比較的コメントが多く付いていて組み込み機器の開発プロジェクトの出発点としては参考になると思います。

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

原文:https://www.wolfssl.com/wolfssl-4-7-0-supports-user_settings-h-cmake-builds/

wolfSSLを使用してQtをビルドする

Qt 5.12 または 5.13をビルドする際、デフォルトはOpenSSLバックエンドですが、wolfSSL組み込みSSL / TLSライブラリに変更することが可能です。QtのTLSとしてwolfSSLを使用することで、次のような利点があります。

  • 最新TLSプロトコルのサポート(TLS 1.3まで)
  • フットプリントサイズが小さい(最小でOpenSSLの20分の1)
  • 広範なテスト(wolfSSLは、最もテストされたSSL / TLS実装です)
  • 認定取得(FIPS 140-2 / 140-3DO-178C
  • 高い移植性(30以上のOSをサポート)
  • ハードウェア暗号化のサポート
  • 商用サポート
  • 専門エンジニアによるコンサルティングサービスとトレーニング

Qt用にwolfSSLをコンパイルするために、wolfSSLには--enable-qtという名前のconfigureオプションがあります。wolfSSLを使用してQtをコンパイルするには、最初にwolfSSLからQtパッチファイルを入手し、次のステップを実行します。パッチファイルの入手は info@wolfssl.jp までメールでお問い合わせください。

1. Building Qt Guideに沿って、必要なQt依存ファイルをダウンロードし、Qtリポジトリを初期化します。
2. ディレクトリをqt5ディレクトリに変更し、5.12〜5.13の間のブランチをチェックアウトします。例えば、v5.12.4 をチェックアウトします。

$ cd qt5
$ git checkout [branch_name]

3. wolfSSLQtパッチファイルをqt5に適用します。

$ cd qt5/qtbase
$ patch -p1 < /path/to/wolfssl_qt_src.patch

4. WOLFSSL_LIBS変数を設定して、wolfSSLに直接リンクします。

$ export WOLFSSL_LIBS="-L/path/to/wolf-install/lib -lwolfssl"

5. 「-wolfssl-linked」オプションを使用してQtを構成し、wolfSSLヘッダーディレクトリをインクルードパスに追加します。

$ ./configure -wolfssl-linked -I/path/to/wolf-install/include/wolfssl -I/path/to/wolf-install/include

6. Qtをビルドします。

$ make

7. ビルドをテストします。

$ make test

8. または、テストを個別に実行します:

$ qtbase/tests/auto/network/ssl/qsslcertificate/tst_qsslcertificate
$ qtbase/tests/auto/network/ssl/qasn1element/tst_qasn1element
$ qtbase/tests/auto/network/ssl/qpassworddigestor/tst_qpassworddigestor 
$ qtbase/tests/auto/network/ssl/qsslcipher/tst_qsslcipher
$ qtbase/tests/auto/network/ssl/qssldiffiehellmanparameters/tst_qssldiffiehellmanparameters
$ qtbase/tests/auto/network/ssl/qsslellipticcurve/tst_qsslellipticcurve 
$ qtbase/tests/auto/network/ssl/qsslerror/tst_qsslerror 
$ qtbase/tests/auto/network/ssl/qsslkey/tst_qsslkey 
$ qtbase/tests/auto/network/ssl/qsslsocket/tst_qsslsocket
$ qtbase/tests/auto/network/ssl/qsslsocket_onDemandCertificates_member/tst_qsslsocket_onDemandCertificates_member
$ qtbase/tests/auto/network/ssl/qsslsocket_onDemandCertificates_static/tst_qsslsocket_onDemandCertificates_static

wolfSSLのQtへのポートはメインのソースコードにはまだマージしていなく、現在はパッチ形式で配布しています。wolfSSL Qtパッチファイルへのアクセスをリクエストは、info@wolfssl.jp までメールでご連絡ください。

原文: https://www.wolfssl.com/building-qt-with-wolfssl-support/

暗号機能のテスト大丈夫ですか?

wolfSSLがその技術的投資対象として最重要と位置付けているものは”テスト”です。我々は、皆さんがテストしなくても済むようにテストに多くを費やしています。30以上のOS、10以上のコンパイラ、50以上のチップセット、20以上のハードウエア暗号処理と15以上のセキュアプロセッサーでのテスト環境を開発してテストを実行しています。それらのほとんどをJenkinsベースのCI/CD パッケージに毎日追加しています。ユニットテストは全関数に対して行い、5つのスタティックアナライザー、7つの内部fuzzテスターを走らせています。加えて外部のコンサルタントを雇って追加fuzzテストを実行しています。

内部でのテストだけではありません。我々のコードはコンピューティング業界の全ての主要ベンダーによって実質的に「監査」を受けているようなものです。何故なら、彼らはすべて私たちの顧客であり、彼ら自身のセキュリティとブランディングを確実にするために私たちのコードをレビューする必要があるのです。また、学界の20を超えるセキュリティ研究チームにも同様にレビューを受けています。航空業界のDO-178、自動車業界のMISRAとASPICE、政府機関のFIPS140などの業界固有のテストも実施しました。 もし、皆さんの特定のプラットフォーム上で得たテストや保証をお持ちでしたら、ぜひ我々のものと比較してみてください。

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

原文:https://www.wolfssl.com/whos-testing-cryptography-platform-hardware-encryption-secure-element/

Posts navigation

1 2 3 4 42 43 44