うるふブログ

wolfSSL v5.4.0をリリースしました

wolfSSL5.4.0をリリースしました。今回のリリースで提供している新機能の1つは、DTLS1.3の最初のリリースです。この新しいプロトコルの実装は、以前の1.2 / 1.0バージョンのDTLSを改善し、wolfSSLのTLS1.3の実装を非常にうまく補完します。

このリリースで注目すべきもう1つの大きな変更は、SP演算ライブラリをデフォルト実装とした点です。SP演算ライブラリは特定鍵長むけ整数演算ライブラリを意味し、特定の鍵長に関係した整数演算を最適化してあります。処理速度の向上に加えメモリサイズの増大をこれまでの実装と同等に抑えることが可能となったためデフォルト実装となりました。今回のリリースからは、基本構成の実行時に、特定の演算ライブラリ実装を指定しない場合、SP演算ライブラリが使用されます。多くのハードウェアポートとRTOSポートも更新しました。一例としては、QNXを使用する際のNXPのCAAMのサポートの拡張があります。

リリース5.4.0では、3つの脆弱性が発見されました。それらは修正済みとしてリストされています。2つは比較的新しいレポートですが、1つはDTLS1.0/ 1.2のサービス拒否攻撃に関するもので、もう1つはECC/DH操作に対する暗号文攻撃に関するものです。​三つ目​の脆弱性は、AMDデバイスに対する以前の攻撃​に関するもので、wolfSSLバージョン5.1.0​にて​修正された​問題の公開で​す​。攻撃の開示に関しては複数のセキュリティライブラリに影響を与えるため、研究者と調整のもとに攻撃の詳細が公開されるのを待って​から今回​行いました。

変更点のすべてが記載されたチェンジログはwolfSSL ChangeLog で参照できます。

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

原文: https://www.wolfssl.com/wolfssl-5-4-0-release/

TLS1.3とNoiseプロトコル

wolfSSL では TLS 1.3 を推進していますが、DTLS、QUIC、SSH、MQTT、Noise などの他のプロトコルがあることも知っています。この投稿では、TLS 1.3 とNoiseを比較対照し、FIPS-140 とポスト量子暗号についていくつかのコメントを提供しようと思います。

Noise自体はプロトコルではありません。Noiseはプロトコル フレームワークです (ここに TLS 1.3 と Noise の最大の違いがあります)。 TLS 1.3 を使用することで、接続は認証され、機密性が高く、整合性が保証されます。これらの特性をTLS1.3で実現するのは非常に簡単で効率的です。 TLS 1.3 を実行する wolfSSL のサンプル サーバーおよびクライアント アプリケーションのすべてはわずか数百行のコードで、最も単純なものはすぐに 100 行以下になります (参照)。これを、必要なセキュリティ 属性に応じて独自のNoiseベースのプロトコルを設計する必要があるという要件と比較すると、Noiseは TLS 1.3 よりも少し難しいように見えます。実際専門知識が必要とされます。使用できる基本的なパターンについては、こちらのドキュメントのセクション 7.5 を参照してください。

次に大きな違いは認証です。 TLS では通常、クライアントがサーバーの身元を確認できるために、サーバーに X.509 証明書が必要です。サーバーの身元は、証明書を介して公開鍵にバインドされ、秘密鍵の所有をクライアントに証明することによって検証されます。 Noise Framework は ID 検証をサポートしていません。それはアプリケーションに任せます。ただし、静的な暗号鍵を使用することはできます。これにより、両者が過去に通信していたのと同じ相手と通信していることが保証されます。繰り返しになりますが、これを達成するには正しいパターンを設計または使用してから、ID 検証をアプリケーションに設計する必要があります。

TLS 1.3 は暗号化アルゴリズムを標準化し、NIST はそこで使用するアルゴリズムに関するガイダンスを提供します。その結果、私たちは簡単にFIPS-140 に準拠することができます。たとえば、私たちのFIPS 認定製品の上でwolfSSL のデフォルトを使用するだけでOKです。一方、Noiseについては、NIST はガイダンスを提供していないため、プロトコルを設計したり、パターンを選択したりするときは、自分で行う必要があります。

wolfSSLはTLS 1.3 でポスト量子暗号を実行できますか? はい!Supported Group拡張と署名アルゴリズムの拡張には、カスタム用のコード ポイントがあります。ただし、ポスト量子アルゴリズムが標準化されると、標準のコードポイントと OID が制定されるはずです。ポスト量子署名スキームと KEM (キー カプセル化メカニズム) のメカニズムと暗号化アーティファクトは、TLS 1.3 ハンドシェークと X.509 証明書 PKI に非常にうまく適合します。詳細についてはwolfSSL のポスト量子 TLS 1.3 に関するドキュメントを参照してください。

一方、Noiseフレームワークはどうでしょうか?答えはノーです。プロトコル フレームワークは、Diffie-Hellman 鍵交換プロトコルの「非対話性」に依存しており、KEM は対話型です!この記事の執筆時点では、ポスト量子向けの非対話型鍵交換アルゴリズムは知られていません。ただし、さまざまな可能性に関する研究が進行中であり、Noise プロトコルフレームワークは最終的にポスト量子アルゴリズムをサポートするように進化する可能性があります。たとえば、こちらを参照してください。

wolfBoot v1.12 リリース

wolfBootv1.12をリリースしました。 このバージョンでは、新しい署名検証アルゴリズム、RSA3072、新しいテストケース、検証を高速化するための新しいシミュレートされたアーキテクチャ、およびより多くのユースケースをサポートするためのいくつかの新機能を導入しています。 これら新機能のいくつかについて簡単に説明します。

暗号化デルタ更新機能

wolfBootが提供する、ファームウエアの「デルタ更新機能」は、データ転送時間を短縮することを意図して設計しています。 簡単に言うと、既存のバージョンにバイナリパッチを適用して新しいバージョンに更新する機能です。ファームウェアを、現在のバージョンと新しいバージョンの差分をマッピングする特別な更新イメージである「デルタ」更新パッケージを使って更新します。 この機能は、対称鍵による事前共有鍵暗号化メカニズムと組み合わせることができるようになり、暗号化されたデルタ更新が可能になりました。

署名付きバイナリと数値識別子

署名を付けたファームウエアイメージに識別子を割り当てることができます。署名ツールでは、新しいコマンドライン引数(-id N)を受け取って、署名付与したペイロードにカスタムIDを割り当てます。

ID「1」がデフォルトであり、通常、検証後にwolfBootによってステージングされるアプリケーションまたはOSカーネルのイメージに使用します。

ID「0」はwolfBootの自己更新用に予約されています。

ID 2〜15を使用して、カスタムの読み取り専用パーティション、追加のイメージ、およびバイナリ拡張に割り当てができます。それぞれが異なるフラッシュメモリパーティションに存在するか、メモリ内の異なるゾーンにマップされます。

複数の公開鍵のサポート

wolfBoot v1.12は、「keystore」と呼ばれる新しいデータ構造に複数の公開鍵を一緒に格納できるようにしました。 キーストアには、以前のバージョンのようにkeygenツールを使用して生成された鍵、またはサードパーティのプロビジョニングメカニズムからインポートされた鍵を含めることができます。 各鍵には異なる権限を与えることができます。つまり、1つ以上の特定の識別子に関連付けられたバイナリイメージのみを認証するように制御できます。

wolfBootは、安全なブートとファームウェアの更新を提供するためにwolfCryptに依存する安全なブートローダーです。 非常にリソースが制限されたマイクロコントローラーから、より強力なマイクロプロセッサーベースのプラットフォーム、さらにはx86_64 PCベースのアーキテクチャまで、あらゆる組み込みシステムでブートプロセスを保護するために使用できます。 設計上安全であり、安全なブートローダーを統合する必要があるセーフティクリティカルシステムでの理想的な選択肢です。

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

原文:https://www.wolfssl.com/wolfboot-v1-12-released/

ウェビナー「医療デバイスのセキュリティについて、知ってほしいこと。」

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

医療デバイスのセキュリティについて、知ってほしいこと。

2022年8月25日 10:00~10:45

暗号ライブラリ、SSL/TLSについてお調べですか? – wolfSSLがご質問にお答えできるかもしれません。

組み込みシステム向けSSL/TLSライブラリのwolfSSLは、1,000社を超えるOEMカスタマーに採用され、医療分野のさまざまな機器でも多く使われてきました。

このウェビナーでは、メディカルデバイスに求められるセキュリティのトレンド、業界の規制、それらに対応するwolfSSLの製品、FIPS140認証などについて説明します。

また内視鏡手術装置、人工呼吸器、透析装置、インスリンポンプ、院内の医療統合システムなど、グローバル採用事例についても説明いたします。

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

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

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

ぜひ皆様のご参加をお待ちしています。
ご質問がおありでしたら、info@wolfssl.jp までご連絡ください。
そのほかのウェビナー開催予定、オンデマンド版の公開についてはこちらをご覧ください。

ポスト量子暗号アルゴリズムは標準化へ

インターネット上では、ポスト量子暗号の次の4つのアルゴリズムがコンペ段階から標準化ステップに移行するとのNISTによる発表で賑わっています:

  • KYBERキーカプセル化メカニズム
  • DILITHIUM署名スキーム
  • FALCON署名スキーム
  • SPHINCS+ 署名スキーム

NISTによる、上記アルゴリズム選定プロセスに関する非常に詳細なレポートと説明は以下で参照できます。https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413.pdf

KYBERとFALCONの両方が標準化対象のアルゴリズムの中に含まれているのはwolfSSLにとってうれしい限りです。というのも、wolfSSLはliboqとの統合により、両アルゴリズムを既に組み込んでいるのです。では、wolfSSLは次に何を計画していると思いますか?

私たちは、次の2つのアプローチをとる計画をしています。

直近の計画としては、liboqとの統合を活かして、DILITHIUMとSPHINCS+のサポートをwolfSSLに取り込んでいきます。 同時に、標準化される新しいアルゴリズムをwolfSSL独自の実装で進めていきます。「今すぐ収穫し、後で解読する」脅威モデルに対応することが最優先事項であるため、我々の実装では、KYBERから始め、次に、DILITHIUM、FALCON、SPHINCS+の順に着手していきます。

これらのアルゴリズムについてもっと知りたいですか?アルゴリズムを別の順序で実装する必要があると思いますか? ご意見はinfo@wolfssl.jpまでお寄せください。BlackHat2022カンファレンスのブース1084でもお伺いしています。

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

原文:https://www.wolfssl.com/nist-announces-post-quantum-algorithm-standardization/

Black Hat USA 2022出展のご案内

Black Hat参加の登録:
https://blackhat.informatech.com/2022/?_mc=sem_bhas_sem_bhas_le_tspr_BhasiaGbr_2022&

wolfSSLブース番号: 1084

会場ではwolfSSLエンジニアが、セキュリティ全般に関するご質問にお答えします。wolfSSLを使ってみたい方へ使用開始の準備もご案内します。次の内容をも紹介いたします。

  • TLS1.3の利点
  • wolfCryptが認証プロセス中のFIPS140-3
  • wolfSentry – 組み込み向けIDPSエンジン(侵入検知および防止システム)
  • wolfBoot – 組み込み向けセキュアブートローダー
  • wolfEngine(OpenSSL用のwolfCrypt FIPSエンジン)
  • cURLの商用サポート
  • 航空機搭載システム/機器用のDO-178
  • NXP CAAMドライバーのサポート

ブースへお越しいただける予定の方は、info@wolfssl.jp まで事前にお知らせください。日本のスタッフとご興味の分野に詳しいエンジニアがご都合の来場時間にお会いできるよう、スケジュールを調整いたします。

会場でお会いできることを楽しみにしています!

ご質問がおありでしたら、info@wolfssl.jp までご連絡ください。

TLS 暗号化処理のグリッチ耐性強化

このところ、グリッチによる暗号化障害の発生を検出して、これに何等かの対抗手段を講じる方法がないか取り組んできました。ESP32 AES H/Wアクセラレーションに関する最近のレポートによると、時限グリッチを発生させて、暗号化操作をスキップさせる攻撃が可能であると報じられています。 この攻撃を仕掛けるには、ハードウェアへの物理的なアクセスが必要となります。 しかし攻撃が成功すると、H/Wを使った暗号化操作がスキップされ、データがTLSトランスポートを介して暗号化されずに送信されます。

この報告を踏まえて、wolfSSLでは新しいビルドオプションWOLFSSL_CIPHER_TEXT_CHECKを追加して、暗号化をチェックし、データが正しく変更されたことを確認するようにしました(つまり、暗号化前後のデータが同じでないことを確認します)。 デフォルトではバッファの64ビットをチェックしますが、これはWOLFSSL_CIPHER_CHECK_SZマクロをオーバーライドすることで拡大できます。 この機能は、「最大強度」ビルドオプション `–enable-maxstrength`を使用することでもデフォルトで有効となります。

詳細については、PR: https://github.com/wolfSSL/wolfssl/pull/5231「グリッチを防ぐためにTLS暗号化に健全性チェックを追加」を参照してください。

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

原文:https://www.wolfssl.com/tls-glitch-resistance-encrypt/

DTLS1.3をサポート開始!

wolfSSLはDTLS1.3の実装を搭載しています。まだ商用での利用可能な段階ではありませんが、フル機能を搭載しベータテストできる状態にあります。コードは我々のGitHub レポジトリダウンロードサイトから取得できます。

DTLSはその最初のバージョンから、下層トランスポートの信頼性と送信順序の保証無しにTLSと同等のセキュリティを提供することを目指しています。つまり、通信遅延に影響を受けやすくて、TCPや同類のプロトコルが持つオーバーヘッドに耐えられないアプリケーションにこそ向いていると言えます。DTLSv1.3の仕様は4月にRFC9147 として公開されました。DTLSv1.3は TLSv1.3の持つ改良点:早く安全なハンドシェーク、0-RTTセッション再開、最新の暗号化アルゴリズム、ダウングレード防御等、を備えています。wolfSSLは動作するDTLSv1.3実装の最初の提供ベンダーとなりました。もし、皆さんがDTLSをお使いでご質問がありましたらメールでお問い合わせください。お待ちしています!

DTLS1.3関係の過去の記事:

最終段階に入ったDTLS1.3

DTLSの実力(その1DTLSの動作)

DTLSの実力(その2性能編)

原文:https://www.wolfssl.com/new-announcement-wolfssl-now-supports-dtlsv1-3/

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

組み込み向けMCUのポスト量子暗号をベンチマーク

以前、このブログでSTM32向けにTLS1.3にポスト量子KEM(Key Encapsulation Mechanism)を導入することをお知らせしていましたが、それに加えて、PQM4(ARM Cortex-M4用ポスト量子暗号ライブラリ)のKYBERレベル1KEMをwolfSSLのベンチマークに追加しました。 最適化フラグのバグ修正が完了するまでは、最適化を使用してPQM4をビルドしないように注意してください。問題の進行状況は ここでご覧ください。

この修正が完了したら、従来のアルゴリズムと一緒にベンチマークを実行して結果を比較できるように再度このブログでお見せします。

[NUCLEO-F446ZE 168MHz SP Math アセンブリコードを使用して測定]

Running wolfCrypt Benchmarks…
wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
RNG                  1 MB took 1.004 seconds,    1.070 MB/s
AES-128-CBC-enc      1 MB took 1.000 seconds,    1.172 MB/s
AES-128-CBC-dec      1 MB took 1.008 seconds,    1.187 MB/s
AES-192-CBC-enc      1 MB took 1.000 seconds,    1.001 MB/s
AES-192-CBC-dec      1 MB took 1.004 seconds,    0.997 MB/s
AES-256-CBC-enc    900 KB took 1.007 seconds,  893.744 KB/s
AES-256-CBC-dec    900 KB took 1.004 seconds,  896.414 KB/s
AES-128-GCM-enc     75 KB took 1.094 seconds,   68.556 KB/s
AES-128-GCM-dec     75 KB took 1.094 seconds,   68.556 KB/s
AES-192-GCM-enc     75 KB took 1.118 seconds,   67.084 KB/s
AES-192-GCM-dec     75 KB took 1.117 seconds,   67.144 KB/s
AES-256-GCM-enc     75 KB took 1.134 seconds,   66.138 KB/s
AES-256-GCM-dec     75 KB took 1.130 seconds,   66.372 KB/s
GMAC Small          75 KB took 1.008 seconds,   74.405 KB/s
CHACHA               4 MB took 1.004 seconds,    4.426 MB/s
CHA-POLY             3 MB took 1.000 seconds,    2.905 MB/s
POLY1305            12 MB took 1.000 seconds,   12.183 MB/s
SHA-256              3 MB took 1.000 seconds,    2.832 MB/s
HMAC-SHA256          3 MB took 1.000 seconds,    2.808 MB/s
RSA     2048 public         78 ops took 1.016 sec, avg 13.026 ms, 76.772 ops/sec
RSA     2048 private         4 ops took 1.836 sec, avg 459.000 ms, 2.179 ops/sec
DH      2048 key gen         5 ops took 1.196 sec, avg 239.200 ms, 4.181 ops/sec
DH      2048 agree           6 ops took 1.439 sec, avg 239.833 ms, 4.170 ops/sec
ECC   [      SECP256R1]   256 key gen       113 ops took 1.000 sec, avg 8.850 ms, 113.000 ops/sec
ECDHE [      SECP256R1]   256 agree          54 ops took 1.008 sec, avg 18.667 ms, 53.571 ops/sec
ECDSA [      SECP256R1]   256 sign           78 ops took 1.019 sec, avg 13.064 ms, 76.546 ops/sec
ECDSA [      SECP256R1]   256 verify         38 ops took 1.012 sec, avg 26.632 ms, 37.549 ops/sec
kyber_level1-kg         62 ops took 1.004 sec, avg 16.194 ms, 61.753 ops/sec
kyber_level1-ed         28 ops took 1.043 sec, avg 37.250 ms, 26.846 ops/sec
Benchmark complete

ポスト量子暗号の過去の記事はこちら:

wolfSSL 5.1.1のポスト量子化暗号:FALCON

組み込み向けMCUのポスト量子暗号

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

原文:https://www.wolfssl.com/kyber-level1-benchmarks-stm32/

組み込み向けMCUのポスト量子暗号

wolfSSLでは、Linux x86_64マシンとARM Cortex M4 チップ搭載のSTM32 NUCLEO-F446ZEボード間で鍵合意にKYBER_LEVEL1グループを使用してのTLS1.3接続に成功しました!

接続には一般的なUART TTL-USBケーブルを使いました。Linuxマシン側ではケーブルをUSBポートに接続し、ボード側はUARTピンヘッダーに接続しました。いずれの側もサーバーあるいはクライアントにすることができます。

liboqsはSTM32向けビルドをサポートしていませんから、どのようにしてwolfSSLに統合したのか疑問に思う方もいらっしゃるかもしれません。wolfSSLはOQSチームの姉妹プロジェクトであるMUPQチームのpqm4プロジェクトと統合しているからです。アルゴリズムアーティファクトはliboqsとpqm4と間で相互運用されており、かつwolfSSLは両側にあるため完全な相互運用が実現できています。OQSチームのOpenSSLフォークとも相互運用できることは重要です。

これは本当に重要でしょうか?私たち重要だと思っています。ポスト量子アルゴリズムがインターネットに与える影響を示す多くの素晴らしい作業が行われています。いくつかの学術論文と大規模な実験があり、いくつかの非常に興味深い結果があり、一般的に言えば、インターネットがポスト量子アルゴリズムの準備ができていることを示しています。しかし、制約のある低リソースのデバイスについてはどうでしょうか。 IoTはどうですか?暗号化アーティファクトのサイズが大きく、一部の操作ではプロセッサパワーの必要性が高いため、これらのアルゴリズムは、制約のある低リソースのデバイスに大きな影響を与える可能性があります。

このようなリソース制限のある機器のドメインでは組み込みプラットフォーム用のポスト量子暗号アルゴリズムの実装とそれを統合しているTLSスタックがないために実験があまり行われてこなかったかもしれません。しかし、今からは変わります。TLS1.3を使ってポスト量子暗号のアルゴリズムを実験し、組み込み機器プロジェクトでの影響を検討することができます。

今後数週間で、STM32 CubeIDEプロジェクトでのサンプルプログラムと、STM32デバイスでTLS1.3を介したポスト量子暗号の確立を開始する方法についてのウェビナーをご報告できる予定です。

現在、KYBER_LEVEL1のみがサポートされています。他のアルゴリズムやバリアントが必要ですか?ハイブリッドが欲しいですか?サンプルプロジェクトとウェビナーがいつリリースされるか知りたいですか?ぜひメールでご連絡ください。

ポスト量子暗号の過去の記事はこちら:

wolfSSL 5.1.1のポスト量子化暗号:FALCON

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

原文:https://www.wolfssl.com/post-quantum-tls-1-3-key-establishment-comes-stm32-cortex-m4/

Posts navigation

1 2 3 4 48 49 50