うるふブログ

wolfSSH 1.4.6をリリースしました

wolfSSH 1.4.6をリリースしました。こちらからダウンロードいただけます。

主な変更点は、OSS-Fuzzを使用したファズテストの追加、リソースに制約のある環境を支援するためのビルドのモジュール性の向上、MQXで使用するためのアップデート、およびサンプルコードの拡張から生じた問題の修正です。変更点の完全なリストは、wolfSSHにバンドルされているChangeLog.mdファイルで確認できます。

wolfSSH製品ページ: https://www.wolfssl.jp/products/wolfssh/

 

さらに詳しい情報は support@wolfssl.com までご連絡ください。
原文: https://www.wolfssl.com/wolfssh-version-1-4-6-available/

wolfSSLウェビナー「wolfSSLのITRON OSサポート」

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

wolfSSLのITRON OSサポート

2021年3月24日(水) 14:00~14:30

スピーカー:
古城 隆
wolfSSL Japan合同会社 技術統括
 

IoTの機能の開発に忙しいソフトウェアエンジニアは、TLSの実装はできれば時間をかけずに信頼できるものを使いたいと考える方も多いのではないでしょうか。

今回は組み込みデバイスで多く使われているITRON OSに特化し、ITRON OSと親和性の高いwolfSSLの利用を検討中のエンジニアの方を対象としたウェビナーです。
wolfSSLは以前よりITRON OSをサポートしてきており、国内でも多数の採用があります。導入評価の第一歩として必要となるwolfSSLのサンプルプログラムのビルド&実行の手順を一通り説明します。

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

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

 

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

 

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

wolfSSLウェビナー「ポスト量子暗号に対するwolfSSLの取り組み」

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

ポスト量子暗号に対するwolfSSLの取り組み

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

スピーカー:
Chris Conlon
wolfSSL Inc. Engineering Manager

 

このウェビナーでは、wolfSSLのポスト量子暗号に対する現在の取り組みの最新情報を紹介します。組み込みシステム向け軽量wolfSSL SSL/TLSライブラリの概要、ポスト量子アルゴリズムの現在のサポート、またNISTのポスト量子暗号標準化プロセスの現状のサマリーについても触れます。

本ウェビナーは英語で開催します。
約30分の予定です。
参加希望の方はこちらからご登録ください。ご登録後、ウェビナー参加に関する確認メールをお送りします。

 

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

 

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

wolfMQTT v1.8.0をリリースしました

wolfMQTT v1.8.0をリリースしました。このリリースでは以下の不具合修正と最適化を含んでいます:

  • WIN32環境におけるノンブロッキング処理とペイロードが大きい場合の障害を修正(PR#202)
  • TLS IOコールバック関数を公開(PR#201)
  • 不具合修正(PR#186,188,189,193,196,199,200)
  • デフォルトのテストブローカーを更新(PR#194)
  • MQTT-SNにおいて、マルチスレッド動作時の障害修正とトピック名を登録するよう修正(PR#185,190)
  • マルチスレッド対応においてpthread mutexを状態変数と共に使用するように修正(PR#183)
  • WIN thread createマクロを修正(PR#182)
  • Arduinoビルド時にoptions.hを使用するように変更(PR#181)
  • サンプルプログラム中で、MqttClient_Pingに代えてMqttClient_Ping_exを使うように変更(PR#179)
  • MinGW環境でのビルド時の障害を修正(PR#178)
  • MQTT-SNをマルチスレッド対応(PR#176)
  • サンプル中のClient側プログラムでTLS相互認証を行うように変更(PR#173)
  • 実行時メッセージのオプションをクライアント側に追加(PR#171)

本リリースに関する機能や修正点は以下の変更履歴を参照ください。

https://github.com/wolfSSL/wolfMQTT/blob/master/ChangeLog.md

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

原文:https://www.wolfssl.com/wolfmqtt-release-v1-8-0/

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 SP Math All 実装と OpenSSL

この一連のブログでは、wolfSSLの新しいSP Math All 演算ライブラリについての詳細な情報をお伝えしています。これまでの3回で、SP Math All 実装の導入、従来のInteger実装とTFM実装との比較について紹介してきました。そして今回はOpenSSLとの比較を行ってみました。SP Math All実装はOpenSSLライブラリより優れているのでしょうか?

OpenSSLは、デフォルトビルドでは速度優先最適化、コードサイズ大となります。それと比べて、wolfSSLの新しいバージョンではデフォルトでSingle Precision最適化コードが組み込まれるようになっていて、同等またはそれ以上の性能が得られます。OpenSSLでアセンブラコードを使わない場合もwolfSSLのほうが良い結果となります。

以下は、OpenSSLとwolfSSLの両者ともアセンブラコードを使わず、かつwolfSSLは’–enable-sp-math-all=small’ オプションの指定で作成したSP Math All 実装を使っての比較結果です。

アーキテクチャ: x64速度比(wolfSSL vs OpenSSL)
RSA 2048 署名8.27%
RSA 2048 署名検証29.75%
ECC P-256 鍵合意20.56%
ECC P-256 署名25.31%
ECC P-256 署名検証24.13%

全てでwolfSSLの方が勝っています!ではコードサイズでどうでしょうか?カスタムアプリを書かない限りOpenSSLのコードサイズを正確に得るのは難しいのですが、B N関係の構造体のサイズでみるとOpenSSLはwolfSSLの倍のサイズであるといえます。

皆さんが、メモリ制限のある組み込み機器開発やモバイルアプリ開発を行われているかによらず、新しいSP Math All実装はそれらの全ての要求に完全に適します。また、Single Precision実装はRSAとECCアルゴリズムを特定のサイズで実装し、モバイル、デスクトップ、サーバーアプリを目もくらむ程高速に実行し、SP Math All実装と共存できることを忘れないで下さい。

シリーズ第一回:wolfSSLの新たな Multi-Precision 演算ライブラリ

シリーズ第二回目:wolfSSL SP Math All実装とInteger実装

シリーズ第三回目:wolfSSL SP Math All実装とTFM実装

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

原文:https://www.wolfssl.com/wolfssl-sp-math-openssl/

wolfSSL SP Math All実装とTFM実装

これまでのブログでは従来実装である演算ライブラリとwolfCryptに新規に導入されたSP Math All実装をご紹介してきました。 前回のブログでは、従来実装であるInteger実装との改善比較を行いました。この比較結果は皆さんにとって、新SP Math All実装に乗り換えるのに十分な説得材料となったはずです。

加えて、今回は新たなSP Math All実装が従来のTFM実装に比べてどれ程高速になるのかを見ていきます。(SP Math Allライブラリは”–enable-sp-math-all=huge”コンフィギュアオプション指定で生成し、TFM実装は”–ensable-fasthugemath”オプションを指定して生成しました)

CPUアーキテクチャx64Aarch64
RSA 2048 署名32.05%44.69%
RSA 2048 署名検証21.30%31.01%
DH 2048 鍵生成10.90%16.31%
DH 2048 鍵合意6.56%16.27%
ECC P-256 鍵生成57.92%56.95%
ECC P-256 鍵合意54.38%55.90%
ECC P-256 署名53.95%49.95%
ECC P-256 署名検証41.35%47.73%

楕円曲線アルゴリズムでは常にCPUアーキテクチャによらず(x64でおおよそ50%、Aarch64でおおよそ100%の速度向上)高速です。RSAとDHではバラつきがみられますが、RSA署名では顕著に高速です。これは改良されたアセンブリコードを使った乗算とべき乗演算を使った結果です。

次はコードサイズの比較です。

x64アーキテクチャでのコードサイズ(バイト数)TFM
(#1)
SP Math All
(#2)
コードサイズ減少比率
(#2-#1)/#1 * 100
+RSA +DH +ECC490866136842-72.12%
+RSA +DH -ECC485785126410-73.98%
-RSA -DH +ECC485210136266-71.92%

TFMヒュージビルドは多倍長乗算にCombaの方法を取り入れていますが、一方SP Math Allは顕著に小さいカラツバ法の実装を取り入れています。これにより、コードサイズを抑えながら速度を向上できました。

SP Math All実装はTFM実装の全ての面で優れていることは明白です!

次回のブログではSP Math All実装とOpenSSLのパフォーマンス比較について紹介します。

シリーズ第一回:wolfSSLの新たな Multi-Precision 演算ライブラリ

シリーズ第二回目:wolfSSL SP Math All実装とInteger実装

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

原文:https://www.wolfssl.com/wolfssl-sp-math-tfm-implementations/

wolfSSL SP Math All実装とInteger実装

前回のブログでは、wolfCryptにおけるSP Math All実装の機能比較をご紹介しました。今回は新たなSP Math All実装と従来のInteger実装のパフォーマンス比較を行ってみます。

SP Math AllライブラリはWOLFSSL_SP_SMALLマクロあるいは”–enable-sp-math-all=small”コンフィギュアオプション指定でビルドすることにより生成できます。サイズは小さくてやや低パフォーマンスを示しますが、組み込み機器用には適したライブラリとなります。一方、”–disable-fastmath”オプションを指定して生成するInteger実装は高速でコードサイズも小さいライブラリになります。

では、SP Math All実装が従来のInteger実装に比べてどのくらい速いか見てみましょう。(注:SP Math All実装は”–enable-sp-math-all=small  –disable-asm C_EXTRA_FLAGS=-DWC_NO_HARDEN”で、Integer実装は”–disable-fastmath”のコンフィギュアオプション指定でビルドしています)

CPUアーキテクチャx64Aarch64
RSA 2048 署名81.43%50.46%
RSA 2048 署名検証993.81%522.14%
DH 2048 鍵生成48.55%1.82%
DH 2048 鍵合意65.16%12.71%
ECC P-256 鍵生成45.22%112.74%
ECC P-256 鍵合意43.74%111.60%
ECC P-256 署名55.01%118.90%
ECC P-256 署名検証62.54%127.31%

楕円曲線アルゴリズムでは常にCPUアーキテクチャによらず(x64でおおよそ50%、Aarch64でおおよそ100%の速度向上)高速です。RSAとDHではバラつきがみられますが、RSA署名では顕著に高速です。これは最適化されたべき乗演算の実装によってもたらされました。

コードサイズは速度に比べてそれ以上ではないですが同じくらい重要な比較要素です。ではARM Cortex M4を例にとって比較してみましょう。

ARM Cortex-M4
アーキテクチャでのコードサイズ(バイト数)
Integer
(#1)
SP Math All
(#2)
コードサイズ減少比率
(#2-#1)/#1 * 100
+RSA +DH +ECC2362518672-20.97%
+RSA +DH -ECC2249216836-25.15%
-RSA -DH +ECC2114918232-13.79%

すべてのビルドで最大25%のコードサイズ削減となっており、それに高速です!同様の傾向が他のCPUでも見られました。次回はsp_int.cとtfm.cのパフォーマンス比較を紹介します。

シリーズ第一回:wolfSSLの新たな Multi-Precision 演算ライブラリ

 

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

原文:https://www.wolfssl.com/wolfssl-sp-math-integer-implementations/

wolfSSLの新たな Multi-Precision 演算ライブラリ

wolfSSLはあらゆる点で改善された、マルチプレシジョン演算ライブラリを導入しました。この実装はsp_int.cにありWOLFSSL_SP_MATH_ALLの定義あるいはコンフィギュレーション時オプション”–enable-sp-math-all”の指定で利用可能になります。以前はinteger.cかもしくはtfm.cの実装のいずれかを選択していました。

従来のInteger実装

従来のsmallあるいはInteger実装と呼んでいる実装は、”–disable-fastmath”オプションを指定して有効にします。この実装は、単純でコードサイズを小さく使用メモリ量も少なくなるように記述されています。そしてそれは本当に素晴らしい仕事をしてくれます!シンプルで小さなアルゴリズムを使用し、数値を保持するメモリサイズを動的に変更することで組み込み機器用のコードとして完璧になります。特定の業界では、動的メモリアロケーションを持たないというコーディング標準のため、静的メモリアロケーションなしでは、この実装が適さない場合があることも事実です。また、この実装ではサイドチャネル攻撃への耐性が高くありませんが、外部から計測可能な暗号化操作を行わない組み込み機器では問題とはなりません。

従来のTFM実装

従来のfastあるいはTFM実装と呼んでいる実装は、”–enable-fastmath”オプションかUSE_FAST_MATHマクロ、”–enable-fasthugemath”オプションかUSE_FAST_MATH,TFM_SMALL_SET,TFM_HUGE_SETマクロによって有効にできます。この実装はTomsFastMathと呼ばれるパブリックドメインのラージインテジャ算術ライブラリを基にしています。この実装は高速ですが、複雑でコード量が多く、特定のケースに特化した実装になっています。コードはサイドチャネル攻撃耐性を強化し(TFM_TIMING_RESISTANTマクロで有効化)、より広い用途で使えます。この実装は比較的多くのメモリを搭載した組み込み機器アプリあるいはモバイルアプリ向けに最適です。半面、外部のコードを基にした実装であるため欠点もあります。我々のコードを更新する都度、オリジナルのコードから乖離し、それらの更新を取り込むのに長い時間がかかるといった点です。

 

既に、この様な2つの実装を備えているのに、なぜ新し実装が必要になるのでしょうか?新実装では両者の良いとこどり-小さくて速い-ができているのです。また、この実装はスクラッチから我々の手で記述しています。つまり、我々が必要としているもの全てが一ヶ所にあるのです。おっと、integer.cあるいはtfm.cより小さくかつ高速になるようにコンパイルできると言ってましたっけ?

新しいSP Math All 実装

この新たなSP Math All実装は”小さくて高速”か”非常に高速だが巨大”を選択してコンパイル可能です。TFM実装と同様に、数値を格納するためのデータサイズは固定で、動的メモリ(リ)アロケーションは使いません。小さいコードサイズ用にコンパイルすると基本的な操作用に単純なアルゴリズムのみが含まれますが犠牲になるスピードははるかに少なくなります。1024ビット以上のようなより大きな数のために特別にコードを含む巨大なオプションに含まれている高速な実装もあります。 コードをできるだけ速く実行するために、アセンブリコードのスニペットが使用されます。 x64、x86、Aarch64、ARM32、Cortex-M4、PPC64、PPC、MIPS64、MIPS、RISCV64、RISCV32、S390Xなどの幅広いプラットフォームがサポートされています。 SP Mathすべてのコードは、デフォルトでサイドチャネルに対して強化された実装を使用します。

各実装の差異を示します:

 Integer 実装TFM実装SP Math All実装
数値データアロケーション動的固定固定
メモリ使用量スモールラージ/ヒュージスモール/ラージ/ヒュージ
スピードスローファスト/ベリーファストスロー/ファスト/ベリーファスト
アセンブリコード提供なし限定したプラットフォームのみ多くのプラットフォーム
攻撃への耐性なしありあり

次回のブログではSP Math All実装とInteger実装のパフォーマンス比較を行います。

 

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

原文:https://www.wolfssl.com/wolfssl-new-multi-precision-math-library/

wolfSSLをLinuxカーネルにロードする

暗号機能に要望を持つLinuxカーネルモジュール開発者にとってのビッグニュースです! wolfCryptとwolfSSLはLinuxカーネルのモジュールとしてロード可能になり、libwolfssl API全体を他のカーネルモジュールにネイティブに提供します。 Linuxで初めて、TLSプロトコルスタック全体がモジュールとしてロードできるようになり、カーネル内のハンドシェイクで完全にカーネルに常駐するTLS / DTLSエンドポイントが利用可能になります。

コンフィギュレーションとビルドは、新しく追加された”–enable-linuxkm”オプションを指定するだけで行え、更にオプションで、ロード時の暗号化セルフテスト(POST)用に構成することも可能です。ライブラリビルドと同様に、カーネルモジュールは、ターゲットの機能と制限内にとどまりながら、アプリケーションの要件を満たすように詳細に構成できます。特に、開発者は、低レベルの暗号化アルゴリズムのwolfCryptスイートのみにリンクすることを選択するか、TLS1.3をサポートする完全なTLSプロトコルスタックを含めることができます。 AES-NIアクセラレーション用に構成されている場合、モジュールは1サイクルあたり1バイトを超える速度でAES256-GCM暗号化/復号機能を提供します。

カーネルモジュールの構成は、最先端のパフォーマンスとサイドチャネル攻撃に対する耐性を備えた、新しい機能を備えた完全な「single precision」bignum実装を活用しています。このブログに注目しておいてください。新しいbignum実装の多くの利点についてさらに詳しく説明していく予定です。

概念実証として、Linux WireGuardカーネルモジュールを再ターゲットして、すべての暗号化に完全な相互運用性を備えたwolfCryptを使用するようにしました。まもなく、これらの結果についてさらに共有する予定です。 libwolfsslのカーネルモジュールビルドはwolfSSLリリース4.6でサポートされ、メインラインのgithubリポジトリですぐに利用でき、x86-64で3.x、4.x、および5.xLinuxバージョンラインをサポートします。

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

原文:https://www.wolfssl.com/loading-wolfssl-into-the-linux-kernel/

 

Posts navigation

1 2 3 4 5 6 43 44 45