ウェビナー「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(侵入検知および防止システム)です。

ネットワークセキュリティの脅威はますます拡大しています。サイバー攻撃のリスクはサーバマシンや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/

TPM 2.0 ライブラリ比較(コードサイズとメモリ使用量)

皆さんからwolfTPMポータブルライブラリのサイズとメモリ使用量について、よく問い合わせをお受けします。この記事ではwolfTPMと他の著名なTPM2.0ライブラリであるIBM製の”ibmtss2″とインテル社のコードがベースとなっている”tpm2-tss”との比較を紹介します。

wolfTPMは、組み込み機器やリソース制限のある環境向けに最適となるようにスクラッチから記述しています。その為、フットプリントは小さいながらも要望簿高い機能を提供することができています。

このブログの執筆時における各TPM2.0ライブラリのバージョンは次の通りです:

  • wolfTMP メジャーバージョン 2.0.0
  • ibmtss2 バージョン 1.5.0
  • tss2-tpm バージョン 3.0.3

テスト環境はx86_64 マシン上でUbuntu 20.04.01 LTSを動作させ、gcc コンパイラバージョン9.0.3(公式Ubuntu

9.3.0-17ubuntu1~20.04 package)を使用しています。

各モジュールのメモリフットプリントを示します(GNU Size toolを使って計測):

 ibmtss keygenTpm2-tss keygenwolfTPM keygen
Code(text)26586492730620119980
Memory(data)1861201767361040
bss1861203388824
Total(dec)28799052941244121044

比較結果

3ライブラリの比較結果として以下が明らかになりました。

  1. wolfTPMはRAM使用量は最小
  2. wolfTPMはビルドしたコードサイズも最小
  3. wolfTPMはヒープを使わない
  4. wolfTPMは外部依存しない

 

なお、各ライブラリの生成は以下の条件で行いました:

tpm2-tss


./configure –enable-shared=no –enable-nodl –disable-fapi -disable-tcti-mssim -disable-tcti-swtpm

これらのオプションは以下を意味しています。

  • シェアードライブラリビルドを抑制(スタティックリンクライブラリを生成)
  • 動的ライブラリローディングを抑制
  • feature apiの使用を抑制
  • Microsoft TPM シミュレーターの使用を抑制
  • IBM TPM シミュレーターの使用を抑制

tpm2-tss のテストアプリケーション: https://github.com/tomoveu/tpm2-tss/tree/size-9

Ibmtss


./configure –disable-tpm-1.2 –disable-rmtpm –disable-shared

これらのオプションは以下を意味しています。

  • 旧仕様のTPM1.2のサポートを抑制
  • リソースマネジャのサポートを抑制
  • シェアードライブラリビルドを抑制(スタティックリンクライブラリを生成)

ibmtssのテストアプリケーション:https://github.com/tomoveu/ibmtss/tree/ibm-size-3

wolfTPM


./configure –enable-devtpm –enable-wolfcrypt –disable-shared

これらのオプションは以下を意味しています。

  • Linuxにおける/dev/tpmX インターフェイスを有効化
  • パラメータ暗号化の為にwolfCryptを有効化
  • シェアードライブラリビルドを抑制(スタティックリンクライブラリを生成)

wolfTPMのテストアプリケーション:https://github.com/tomoveu/wolfTPM/tree/size-6

 

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

原文:https://www.wolfssl.com/tpm-2-0-library-comparison/

Posts navigation

1 2 3 4 38 39 40