うるふブログ

wolfMQTTプロジェクトではOTA（Over the Air)アップデートと呼ばれる安全なファームウエアアップデートのサンプルプログラムを提供しています。このOTAアップデートは、大まかに言えばwolfSSLライブラリを使用してバイナリイメージをハッシュ/署名し、MQTTプロトコルを使ってブローカーに送信します。バイナリイメージを受け取った側はこのイメージを検証した後に使用する流れになります。

このサンプルプログラムでは具体的には2つのアプリケーションが登場します。最初のアプリケーションはfwpushと呼ばれる、新しいファームウエアイメージをMQTTブローカーにパブリッシュする役目のアプリケーションです。ファームウエアイメージをハッシュ/署名した後、TLSプロトコルを使ってMQTTブローカーに送ります。

２つ目のアプリケーションはfwclientと呼ばれる、ファームウエア更新トピックをサブスクライブし、ファームウエアイメージを受信してその署名を検証するアプリケーションです。

このサンプルプログラムはwolfMQTTパッケージのexamples/firmwareに用意してあります。

最新のwolfMQTTリリースは次の場所からダウンロードできます：

https://www.wolfssl.jp/download/

wolfMQTTのドキュメントはここにあります：

https://www.wolfssl.com/docs/wolfmqtt-manual/

最新のソースコードは、GitHubリポジトリの次の場所にあります。

https://github.com/wolfSSL/wolfMQTT

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。
原文:https://www.wolfssl.com/mqtt-secure-firmware-update-example-2/

wolfSSL JSSEおよびJNIの最新バージョン(version1.8.0)をリリースします。 wolfSSLはTLS1.3とFIPS140-2 / 140-3のサポートを含む、広く使用されている組み込みSSL / TLSライブラリです。wolfSSL JSSEプロバイダーとJNIラッパー を使って、皆さんのJavaアプリケーションからwolfSSLがご利用いただけます。今回のwolfSSL JSSEプロバイダーとJNIラッパー は、FIPS 140-3の互換性、バグ修正、および次のような新機能を含んでいます:

• wolfCrypt FIPS 140-3 準拠ならびに FIPS Ready互換性
• ソケット関数の追加、JSSEと共に使用される内部ソケットの振る舞いの修正
• FIPS仕様でとして要求されているコア検証用のハッシュ値を取得するラッパー関数を追加
• いくつかのclone()メソッドに潜在していたNullPointerException例外の発生を修正
• SSLSessionContext の実装をリファクタリング
• 外部ソケットがラップされた場合のWolfSSLSocket.getSoTimeout()メソッドの振る舞いを修正
• 小数を含むタイムアウト時間を正しく扱うようにsocketSelectメソッドを修正
• wolfJSSEでカスタムX509TrustManagerが使用された際のメモリリークを修正
• 複数のX509TrustManager オブジェクトをセッションを超えて使用できるよう改良
• ライブラリで使用したリソースを早期に解放する為にWolfSSL.cleanup() をファイナライザで呼び出すように変更
• WolfSSLSocket がクローズされたらネイティブのWOLFSSLを直ぐに解放
• ネイティブ WolfSSLCertificate オブジェクトの管理と解放を改善
• ライブラリが解放された時点でネイティブのロギングコールバックを解放
• ライブラリが解放された時点でネイティブの wolfCrypt FIPS コールバックを解放
• CTXが解放された時点でCTX-level Java ベリファイコールバックを解放
• CTXが解放された時点でCTX-level Java CRLコールバックを解放
• エラー状態でのグローバル参照のクリーンアップを改善
• 非FIPSビルド時の未使用変数に対するウオーニングを改善
• 全てのWolfSSLProviderオブジェクトに対して単一のスタティックWolfSSLオブジェクトを使用
• WolfSSLSession.read() 内でメソッドからの戻り時にローカルJNI配列を解放
• マルチスレッドJSSE プロバイダークライアントとサーバーのサンプルプログラムを追加
• 必要ならばブランクファイルを作成するようにAndroid AOSP インストールスクリプトを改善
• Android AOSP でビルドの際に’SIZEOF_LONG’ と ‘SIZEOF_LONG_LONG’の定義を追加
• Android Studio用のサンプルプログラムを更新
• JSSE WolfSSLContext オブジェクトにおけるデフォルトの暗号化スイートリストの優先順を修正
• ‘WC_RNG_SEED_CB’ に関してFIPS Ready版での互換性をとるための修正
• Android AOSP Android.mk ファイルにwolfCrypt kdf.c ファイルをビルド対象として追加

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。
原文:https://www.wolfssl.com/wolfssl-jni-and-jsse-provider-1-7-0-now-available/

Boschのpq-wolfssl開発チームは、優れた実験的なポスト量子統合を行いました。私たちは彼らの努力に拍手を送るとともに、彼らが論文で発表した興味深い点について要約し、ここで共有したいと思います。最初に彼らのシナリオについて、次に彼らの結論について書きます。

チームの目的は、ポスト量子署名方式の2段階の移行戦略の可能性を調査することでした。彼らのシナリオでは、最初は長期間有効なルート証明書のみがステートフルハッシュベースの署名アルゴリズムに関連付けられた公開鍵を使用し、中間エンティティとエンドエンティティの証明書は引き続きECDSAなどの従来のアルゴリズムに関連付けられた公開鍵を持ちます。ここで重要なのは（この論文にもあるように）、ステートフルハッシュベースの署名アルゴリズムはすでにIETF RFCとして指定されており、その構成要素は信頼性の高いハッシュアルゴリズムとハッシュツリーであり、新しい、またはエキゾチックな 数学構成には依存しないため、一般的に安全であると認められています。

最終的には、他のポスト量子アルゴリズムが標準化され、信頼が構築されるため、それらに関連付けられた公開鍵を使用して中間証明書を発行できます。このステップで、エンドエンティティ証明書は、新しいポスト量子アルゴリズムに関連付けられた公開鍵を使用して発行されます。これで移行プロセスは終了です。

ここで、なぜ最初からチェーン全体にわたってステートフルハッシュベースの署名アルゴリズムを使用しないのか、という疑問が出てきます。その答えはステートにあります。エンドエンティティ証明書は、TLS1.3接続のハンドシェイクフェーズ中に使用される秘密鍵に関連付けられた公開鍵を保持します。オンライン署名操作中のこのステートの管理は、このブログ投稿の範囲外の理由でお勧めできません。より詳細な説明は、NISTのWebサイトにあります。

チームは、移行の最初のステップが実際に実行でき、接続確立パラメーターにほとんど影響を与えないことを発見しました。証明書チェーン全体とキーの確立がすべてポスト量子アルゴリズムの下にある最終的な移行ステップで、RAMの使用を除くすべての点で最良のシナリオが実行可能であることがわかりました。しかし、残念ながらRAMの使用量が大幅に増大することも事実でした。 論文の中で、チームは「だからこそ、PQCの統合には、組み込みシステムに適し、かつTLS 1.3をサポートしているオープンソースTLSライブラリwolfSSL（v4.7.0）を選択しました」と述べています。

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。
原文:https://www.wolfssl.com/post-quantum-research-results-pq-wolfssl-team/

wolfSSLによるポスト量子KEMグループとハイブリッドグループのサポートをお知らせしておりましたが、今回は PQC NISTラウンド3の最終候補に残った署名方式FALCONのサポートをお知らせします。wolfSSLを使って「量子安全」なTLS1.3ハンドシェイクを試すことができるようになりました。

総じて言えば、全てのTLS 1.3接続にとって、認証と機密性が接続を保護する最重要な要素です。認証は、ECDSAなどの署名方式で担保され、機密性は、ECDHEなどの鍵合意アルゴリズムによって担保されます。合意された鍵をAESなどの対称暗号化アルゴリズムで使用して通信ストリームを暗号化します。つまりTLS1.3プロトコルのセキュリティを次の3種類の暗号化アルゴリズムに分解できます：

• 認証アルゴリズム
• 鍵合意アルゴリズム
• 対称暗号アルゴリズム

暗号に関連する量子コンピューターが最終的に開発されると、Shorのアルゴリズムは最新の認証および鍵合意アルゴリズムのセキュリティを完全に破り、Groverのアルゴリズムは最新の対称暗号アルゴリズムのセキュリティを半分に減らしてしまいます。したがって、通信のセキュリティを維持するには、最新の認証および鍵確立アルゴリズムを量子安全アルゴリズムに置き換え、対称暗号アルゴリズムの強度を2倍にする必要があります。

wolfSSLはFALCONの統合により、認証アルゴリズムとして使用できます。新しいKEMのいずれかを使用でき、万が一の場合に備えて、NIST承認のECDSAグループとハイブリッド化できます。そして最後に、AES-128の強度は一般に十分であると認められているのですがさらにAES-256を使用（例えばAES_256_GCM_SHA384 TLS1.3暗号スイートを使用）して強度を2倍にすることができます。このようなTLSハンドシェイクを行う為には、次のコマンドを実行します：

$ examples/server/server -v 4 -l TLS_AES_256_GCM_SHA384 \ 
 -A certs/falcon_level5_root_cert.pem \ 
 -c certs/falcon_level5_server_cert.pem \ 
 -k certs/falcon_level5_server_key.pem \ 
 --oqs P521_KYBER_LEVEL5 
 
 $ examples/client/client -v 4 -l TLS_AES_256_GCM_SHA384 \ 
 -A certs/falcon_level5_root_cert.pem \ 
 -c certs/falcon_level5_cleint_cert.pem \ 
 -k certs/falcon_level5_client_key.pem \ 
 --oqs P521_KYBER_LEVEL5 

このハンドシェークを解析できるように変更したWiresharkを使うと、このTLSコネクションで実際にネットワーク上で何が行われているかを次の図の様に確認できます。

Wiresharkの変更のマージリクエストは次の場所にあります。

https://gitlab.com/wireshark/wireshark/-/merge_requests/4924/

Wiresharkを変更してDockerイメージを作成する手順のプルリクエストは、次の場所にあります。

https://github.com/open-quantum-safe/oqs-demos/pull/104

FALCONのサポートはwolfSSLマスターブランチに組み込まれ、wolfSSLの次のリリースで提供の予定です。

脅威モデルとポスト量子認証を早く検討したほうが良い理由を最後に付け加えさせてください。アプリケーションパラメータまたはユースケースにより、ソフトウェアコンポーネントを更新することは、費用対効果が悪い、もしくは不可能でさえある可能性もあります。 このような場合、製品の寿命を注意深く評価する必要があります。 製品の存続期間内に、暗号に関連する量子コンピューターが登場してくると予測しているのに製品を更新できないならば、今からポスト量子アルゴリズムに移行するための戦略について考え始める必要があります。

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。
原文:https://www.wolfssl.com/integration-falcon-signature-scheme-wolfssl/

wolfTPMv2.3のリリースを発表します。 このリリースには、PCRとGPIOのいくつかのマイナーな修正と機能追加が含まれています。 ビッグエンディアンプラットフォームを使用している方は、TISレイヤーでのバイトスワッピングの問題を解決するためにこのバージョンへの更新を検討することをお勧めします。 STM ST33またはNuvoton NPCT750 TPM2.0モジュールのをターゲットとしていずれかで使用する際のGPIO構成サンプルをリファクタリングしました。 PCRの例には、スタンドアロンの読み取りのサンプルが含まれています。

リリースの詳細：

• GPIOサポートのリファクタリング（単一のgpio_config）（PR＃194）
• Linux HAL IOの修正再試行タイムアウトロジック（PR＃194）
• TISレイヤーのビッグエンディアンの修正（PR＃191）
• RSAESパディングの修正（RSA_Encrypt）（PR＃187）
• CreateLoadedのコマンドコードエラーを許可するようにテストを修正（ハードウェアではサポートされていません）（PR＃184）
• make_credential.cで読み取られたファイルに対するコンパイラ警告の修正（PR＃182）
• Windowsビルドの修正（PR＃181）
• エッジケースビルドでのRSARNGの修正（wolfBootビルドエラーの修正）（PR＃180）
• PCR読み取りのサンプルを追加（PR＃185）

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。
原文:https://www.wolfssl.com/wolftpm-v2-3-release-announcement/

wolfSSLがプロトコルスタック全体をLinuxで初めてカーネルモジュールとしてロード可能にしたTLSライブラリであることをお知らせしてはや1年が経ちました。完全にカーネルに常駐し、カーネル内でTLS/DTLSのハンドシェークを行うエンドポイントとして機能します。その発表後もwolfSSLのLinuxカーネルモジュールとしてのサポートは飛躍的に成長しており、公開鍵暗号化アクセラレーション、FIPS 140-3準拠、IRQハンドラーでの暗号化のアクセラレーション、および移植性と機能の完全性の向上を達成しています。

Linux カーネルモジュールとしてのwolfSSLはlibwolfsslで提供しているAPI全体を他のカーネルモジュールにネイティブに提供し、カーネル内でのハンドシェークで常駐するTLS/DTLSエンドポイントとして機能します。コンフィグレーションとビルドは”–enable-linuxkm“オプションを付けでビルドするだけです。さらにオプションとしてFIPS 140-3コアハッシュ整合性検証とセルフテストを含む、ロード時の暗号化セルフテスト(POST)を含めるように構成可能です。

ライブラリビルドと同様に、カーネルモジュールは、ターゲットの機能と制限内を満たしながら、アプリケーションの要件を満たすように構成をカスタマイズできます。例えば、低レベルの暗号化アルゴリズムのwolfCryptスイートのみをアプリにリンクする選択や、TLS1.3をサポートする完全なTLSプロトコルスタックを含めるかを選択できます。

PKオペレーションの場合、カーネルモジュールは、最先端のパフォーマンスとサイドチャネル攻撃に対する耐性を備えた、SP bignumの新実装を活用します。 AVX2およびAES-NIアクセラレーションはx86で利用可能であり、通常のカーネルスレッドと割り込みハンドラーコンテキストの両方から使用できます。 AES-NIアクセラレーション用に構成されている場合、モジュールは1サイクルあたり1バイトを超える速度でAES256-GCM暗号化/復号化を提供します。

libwolfsslのカーネルモジュールビルドは、wolfSSLリリース4.6以降でサポートされており、メインラインのgithubリポジトリで利用できます。x86-64で3.x、4.x、および5.x Linuxバージョンラインをサポートしますが、ARMとMIPSのサポートは制限されています。 x86-64での完全なFIPS140-3サポートは、wolfSSLバージョン5.0リリースで利用可能になりました。

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。
原文:https://www.wolfssl.com/loading-wolfssl-linux-kernel-update/

wolfSSL製品には、それぞれ特定の目標と目的を持ついくつかのソフトウェアモジュールとコンポーネントが存在します。すべてのソフトウェア製品は、開発プロセスにおいて、要求される品質基準を使用し設計されていることを確認しています。ソフトウェアのライフタイム内の各ステップでは、コードの欠陥とリグレッションを非常に早期に検出できるよう、厳格なルールとテスト基準（厳格なファズベースのテストを含む）が課されています。

ソフトウェア開発プロセスの概要

ソフトウェアエンジニアリングの観点から、wolfSSLソフトウェアコンポーネントの設計と開発のライフサイクルは、次の3つのステップで構成されています：

• ソフトウェア要件と仕様の特定と分析
• API指向のソフトウェア設計
• ソフトウェアモジュールの開発

次に、各ステップは、次のような特定の品質管理手順のセットを通じて検証されます。

• ユニットテストと定期的なカバレッジ分析
• API整合性テスト
• 複数のアーキテクチャ/コンパイラでの統合テストと、コンパイル時の構成オプションのユースケース/組み合わせ
• 他の実装に対する相互運用性テスト
• 正式なアルゴリズムとモジュールの検証
• ファジングテスト

コードの安全性を向上させ、潜在的な欠陥や誤動作を検出するために、追加の品質管理をソフトウェアモジュールに定期的に適用しています。特に、静的アナライザー、動的メモリ診断ツール、ファザーなどのツールは常に追加しています。

GPLライセンスでソースコードを配布し、開発プロセス全体をGitHubプラットフォームで公開することで、プロジェクトに関心のある何百人ものユーザー、寄稿者、およびプロジェクトに関心をよせる人々は、コードのすべての変更と、コードレビュー中に生成される会話を常に認識できます。企業のセキュリティ組織、サイバーセキュリティパートナー、および学術研究者は、新しい脆弱性を絶えず調査し、コードの作成中に特定するのが難しい、可能性のある潜在的な攻撃対象領域を注意深く調査することにより非常に貴重な貢献をしています。 wolfSSL Inc.は脆弱性管理を真剣に受け止めており、緊急修正や迅速なリリースの場合に実行する正確で詳細なチェックリストを備えています。

仕様は絶えず変化するため、ソフトウェア設計プロセスは、アルゴリズムの実装、使用上の推奨事項、および安全なプロトコルとメカニズムを実装するためのガイドラインの更新に対応できる柔軟性を備えている必要があります。

NISTは、「Special Publications」（SP）を通じて仕様とガイドラインを配布しています。 NISTの一部として、業界団体、政府機関、学術機関の協力により、National Cyber​​security Center of Excellence（NCCoE）が設立されました。 IETFと同様に、NISTは、ガイドラインを最新の状態に保つために、以前の出版物に対する頻繁な更新と修正をリリースするアプローチをとっています。 NIST内のガイドラインを更新するプロセスは、「NIST暗号化標準およびガイドライン開発プロセス」（NIST.IR.7977）によって規制されています。 wolfCryptの暗号化関数は、アルゴリズムとその実装プロセスに関するNISTの最新の仕様に従います。後で説明するように、NISTの出版物とソフトウェアツール群は、アルゴリズムとモジュールの検証フェーズで重要な役割を果たします。

wolfMQTTは、OASISによって提供された仕様に基づいて実装され、最初は2015年12月に承認されたMQTTバージョン3.1.1を対象としています。その後、wolfMQTTは、2019年3月に最新のMQTT標準として承認されたOASISMQTTバージョン5.0の仕様をサポートするように進化しました。

ソフトウエア要求仕様と機能仕様

暗号化、安全な通信プロトコル、および安全なファームウェア更新メカニズムの実装に関するガイドラインは、オープンスタンダードとして記述されています。 これらの標準は、いくつかの組織によって維持および文書化されています。 wolfSSLソフトウェアプロジェクトは、次の3つの主要な組織から仕様書をインポートしています：

• IETF（インターネット技術特別調査委員会）は、インターネットプロトコルスタックのドキュメントの公開と更新を担当するエンジニアの大規模なオープン国際コミュニティです。現在では、暗号スイートで使用される安全な通信プロトコルとアルゴリズムも含まれています。
• NIST（米国国立標準技術研究所）は、プロセス、モジュール、およびアルゴリズムのガイドラインを提供し、暗号化のベストプラクティスとして世界的に認められています。
• OASIS（構造化情報標準の進歩のための組織）は、IoTとデータ交換のためのオープンスタンダードの開発に取り組んでいる、グローバルな非営利コンソーシアムです。

IETFは、「Request for Comments」（RFC）の形式で新しい仕様をリリースします。これらは個別に番号が付けられた出版物であり、ピアレビュープロセスの後に発行されます。これには多くの場合、複数のドラフトフェーズが必要です。 RFCに一意の番号が割り当てられると、RFCが再度変更されることはありません。 RFCで公開されている標準トラックを更新するために、以前に公開された既存のRFCの修正、訂正、または置換を含む可能性のある新しいRFCを発行することができます。新しいRFCは、古いRFCを廃止または非推奨にすることで、古いRFCに取って代わることができます。 RFCは、TLSプロトコル標準（RFC8446）、DTLS（RFC6347）、TLS拡張（RFC6066）など、wolfSSL通信モジュールの大部分の仕様をカバーしています。 wolfCryptライブラリは、RSA公開鍵暗号化（RFC8017）、またはAEAD用のChaCha20 / Poly1305（RFC8439）など、サポートされているアルゴリズムに基づく暗号化プリミティブの実装に関する推奨事項に従います。 wolfSSHは、RFC4250-RFC4254シリーズの仕様に基づいて設計および開発しており、提案されたインターネット標準としてSSH-2を文書化しています。 wolfBootは当初、draft-ietf-suit-architectureのガイドラインに従って設計および開発しました。このガイドラインは後にRFC9019になりました。

ソフトウエアデザイン

wolfSSLが開発したソフトウェアコンポーネントのほとんどは、API指向の設計に基づいた構造化ライブラリです。関数がAPIの一部になると、関数のシグネチャ、目的、または戻り値の意味が変更されることはありません。これにより、ライブラリのさまざまなバージョン間での互換性が保証されます。機能が追加になると、新しいAPI関数が作成されます。この関数は、違う引数を受け入れるか、特定のインターフェイスを拡張します。 API関数呼び出しは、モジュールのユーザーマニュアルに正式に記載されています。

設計段階で覚えておくべき最も重要な側面の1つは、APIのさまざまなレイヤーにわたるエラーコードの正しい意味、伝播、および検証です。各エラーコードには、マニュアルで説明されている固有の明確な意味があります。これにより、ライブラリを使用するアプリケーションの実行時エラーの識別が容易になります。

暗号化と安全なプロトコルに関する仕様は動的に変化するのが常なので、設計プロセスもそれに応じて適応する必要があります。新しい仕様が分析され、既存のモジュールアーキテクチャに統合されます。これにより、既存のAPI関数シグネチャが時間内に不変に保たれるため、既存の機能が損なわれることはありません。

ソフトウエア開発とトレーサビリティ

wolfSSLのすべてのソフトウェアは、一元化されたgitメインラインリポジトリを介して、継続的インテグレーションの実践に従って開発および保守しています。

すべてのソースコードは公開しており、GPLライセンスで、開発中いつでもアクセスできます。 wolfSSL製品のソフトウェアコンポーネントのライフサイクルは、一般的なオープンソース開発プロセスとは異なり、変更された条件決定カバレッジ（MC / DC）プロセスに準拠するように設計されています。 wolfSSLはコードベース全体を所有および維持します。つまり、メインラインの変更と更新に関して厳格なルールがあります。リポジトリへの変更は、変更がマスターブランチにマージされる前に厳格なピアレビューポリシーに準拠する必要があり、wolfSSLエンジニアによってのみ許可されます。

wolfSSLリポジトリに寄稿するには、開発者はGitHubを介して「プルリクエスト」を送信する必要があります。次に、リクエストは1人以上のwolfSSLエンジニアがレビューします（パッチのサイズ、影響、および性質によって異なります）。これにより、多くの場合、コードのマージが受け入れられる前に、設計ドキュメントの目的との整合性、コードの変更、再適応、および改善が要求されます。承認された寄稿者のみが、レビューのためにコードを送信できるようになっています。wolfSSLエンジニアリングチーム外の寄稿者は、寄稿コードの追加検討に入る前に、事前にその承認が取れている必要があります。

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。
原文:https://www.wolfssl.com/wolfssl-software-development-process/

wolfSSL製品には、それぞれ特定の目標と目的を持ついくつかのソフトウェアモジュールとコンポーネントが存在します。すべてのソフトウェア製品は、開発プロセスにおいて、要求される品質基準を使用し設計されていることを確認しています。ソフトウェアのライフタイム内の各ステップでは、コードの欠陥とリグレッションを非常に早期に検出できるよう、厳格なルールとテスト基準（厳格なファズベースのテストを含む）が課されています。

品質保証

コードの機能の最初の検証は、開発者の開発PCでローカルに実行します。 Gitのコミットフックとプッシュフックは、コードが機能とユニットテストの最初のセットに合格した場合にのみコードをリポジトリに送信できるようにしています。 プルリクエストが公開されると、非回帰テストと統合テストのフルラウンドが自動的に開始され、プルリクエストのステータスがテスト結果で更新されます。 プルリクエストが受け入れられるためには、ピアレビューと非回帰テストおよび統合テストに合格する必要があります。 プルリクエストのコードが変更されるたびに、レビュープロセス中にテストが自動的に再トリガーされます。

品質管理の自動化

wolfSSLでは、Jenkinsを使用してノード間のワークロードを調整し、定期的に品質管理を適用するハイブリッド（オンサイト+クラウドベース）インフラストラクチャを展開しました。これには、コード変更をコミットする都度メインラインへの取り込み可否評価のためにソフトウェアテストを実行することや、定期的に（たとえば、毎晩、毎週）適用される他のタイプの品質管理が含まれます。 ハイブリッドアプローチの背後にある理由は、wolfSSLソフトウェア製品の移植性という特徴によるものです。ソフトウェアは、いくつかの異なるハードウェアアーキテクチャで実行され、ハードウェア暗号化モジュールやTPMなどの特定のハードウェアコンポーネントと相互運用する必要があります。一部のjenkinsノードで物理マシンを使用すると、自動的に構成およびプログラムできるマイクロコントローラーボードなど、特定のハードウェアターゲットを構成および制御するメカニズムが提供されます。 一部のテストは、実行に長い時間がかかります。継続的インテグレーションツールは、品質管理ジョブのアプリケーションを長期間にわたって分割して、すべてのテストが定期的に実行されるようにするために非常に役立ちます。

第三者機関によるアルゴリズムとモジュールの検証

実装がスタンダードへ正確に準拠しているかを検証する目的で、NISTが推奨するツールと手順を使用してwolfSSLソフトウェアコンポーネントをテストしています。これには、一連の既知の入力値（テストベクター）と期待される結果を使用した機能テストの完全なセットが含まれます。多くの暗号化アルゴリズムの正しさは、計算の中間結果を調べることによっても検証できます。 NISTは、連邦政府の部門や機関が使用する暗号化モジュールの要件と標準を調整する一連の出版物（FIPS 140）も発行しています。米国とカナダにある認定された専門の第三者機関の取り組みにより、FIPS140規制への準拠を証明するための2つの検証プログラムが利用可能になりました。 wolfCryptはFIPS140-2認定を取得しており、最近承認されたFIPS140-3認定も既に申請しています。 FIPS認定では、暗号化モジュールが次の2つのプログラムの検証を通じて正常に送信される必要があります：

• 暗号化アルゴリズム検証プログラム（CAVP）は、実装された承認済み暗号化アルゴリズムの検証テストを提供します。
• 暗号化モジュール検証プログラム（CMVP）は、機密データおよび情報を保護するために政府および規制対象の業界が使用するモジュールを認定します。

CAVP / CMVPで使用されている同じタイプのテストをメインラインで自動的に繰り返し実行することで、コードの変更がFIPS140で指定されているアルゴリズムとモジュールの整合性に影響を与えないことを確認しています。

相互接続性テスト

プロトコルの動作が継続的インテグレーション全体で同じままであることを確認する非常に効果的な方法の1つとして、同じ標準の異なる実装で相互運用性テストを実行することが挙げられます。 wolfSSL品質管理インフラは、通信のリモートエンドポイントとして異なる実装を使用し、一般的なベクトルから開始する暗号化操作の結果を比較する、多数のスケジュールされたテストを提供しています。

ユニットテスト

ユニットテストはすべてのコアモジュールに必須であり、新しいコミット時に開発者のマシンで実行されます。 ユニットテストのカバレッジは毎週測定され、コードに新しい機能を追加するときにカバレッジの回帰がないことを確認します。wolfSSLの開発者は、継続的インテグレーションのためにJenkinsインフラによって提供される自動化のおかげで、毎週完全なコードカバレッジレポートをメールで受け取ります。

API一貫性検証

ある特定のテストセットは、実装の変更がアプリケーション開発の観点からAPIの使用法を変更しないことを確認します。 これらのテストは、APIに新しい関数を追加することを除いて、更新されることはありません。 APIはアプリケーションとライブラリ間のコントラクトであるため、バージョン間で一貫性を保つ必要があります。 これらすべての側面を検証することは、要件への準拠を検証するために毎晩実行されるテストのサブセットの目標です。

統合テスト

wolfSSLの移植性のため、カスタム構成を含めることによってテストドメインを拡張する必要があります。カスタム構成では、さまざまなアーキテクチャ用にソフトウェアをコンパイルし、コンパイル時の構成オプションとテストアプリケーションを組み合わせる必要があります。 テストスイートを実行するためのターゲットとして、実マシンと仮想マシンの両方が使用されます。 さまざまなアーキテクチャ（x86、ARM、PowerPC、RISC-V、MIPSなど）でテストを自動化することで、アーキテクチャ固有のリグレッションまたはバグをプロセスの早い段階で検出および識別でき、期待される動作はすべての場合で一貫しています。 継続的インテグレーションインフラストラクチャのハイブリッドモデルのおかげで、いくつかのターゲットがJenkinsノードに接続され、さまざまな特定のハードウェアおよびソフトウェア構成とユースケースを通じてソフトウェアテストの実行を担当します。

安全性審査：舞台裏のしくみ

継続的インテグレーションインフラストラクチャは、いくつかの分析ツールの実行も自動化します。

静的分析ツールは、コンパイル時オプションのさまざまな組み合わせを全て調べ、さまざまなコードパスをたどって、コード内の不整合を探します。これらのツールは、ソースコードレベルで厳密なチェックを適用することにより、コンパイラでカバーされない可能性のあるプログラミングミス、潜在的なエラー、および未定義の動作を検出できます。 wolfSSLが使用しているCIで自動化されたツールには、cppcheck、clang静的アナライザー（スキャンビルド）、Facebook推論などがあります。

メモリ分析は、メモリ処理に関連するバグを探すために定期的に実行されます。 wolfSSLは、valgrind memcheckツール、clangサニタイザー、およびその他の動的分析を使用してコードを実行します。これらのツールは、初期化されていない、または以前に解放されたメモリへのアクセス、未定義または初期化されていない値の使用、メモリリークなどのメモリエラーを検出します。 ファザーは、予期しない状況に対するコードの堅牢性を向上させるための非常に重要なリソースです。これらのツールの目的は、多数のランダムな入力をすばやく連続して挿入することにより、コードの誤動作を引き起こそうとすることです。

ファジングは、長い間見過ごされがちなコードのバグや脆弱性を検出するための非常に効果的な方法です。 wolfSSLでは、API関数とトランスポートバックエンドにフィードするために常にファザーを実行し、出力値の変更を調整するPRNGのすべての可能なシード値を定期的にローテーションします。ミューテーションファジングでは、特定のシード値でトリガーされたバグを、同じシード値で同じテストを手動で再起動することで再現できるため、機器やデバッガーによる再現性と分析が容易になります。これらの種類のツールは、アプリケーションドメイン、プロトコル構造、およびデータの特性を認識している必要があるため、wolfSSLは、この目的のために作成された2つの主要なファザーを使用します。 wolfFuzzはメモリバッファ上で動作し、内部暗号化操作をファジー化します。このメカニズムにより、非常に高速なファジングが可能になり、4兆個のPRNGシードの全範囲が3か月でテストされます。 2番目のツールであるwolfSSLNetwork Fuzzerは、TCP / IP上で実行されます。このため、移動中のデータのセキュリティを有効にするコードをテストするのははるかに遅くなりますが、より柔軟になります。

脆弱性管理

wolfSSLでは、脆弱性を非常に深刻に受け止めており、開示から36時間以内にソフトウェアの新しいバージョンをリリースすることをコミットしています。これにより、責任ある開示の場合、脆弱性の詳細または再現する概念実証が公開される前に、脆弱性が修正されます。

脆弱性のクレームは、問題の解決と新しいバージョンのリリースをスピードアップするために完了する必要がある標準操作手順（S.O.P.）で構成される緊急手順をトリガーします。脆弱性のクレームは最初の120分以内に確認します。このフェーズでは、問題と問題の再現方法を記したドキュメントを作成してエンジニアリングチームに内部的に配布します。これにより、問題が完全に解決できているかを判断するために、エラーを確認して修正案を評価することを可能にします。問題の複雑さにもよりますが、修正には数分から最大24時間かかる場合があります。修正の準備ができたら内部パッチ、または修正によってwolfSSL Gitリポジトリを監視する攻撃者になる可能性のある人に重要な情報が漏洩しないことが確認された場合はパブリックプルリクエストのいずれかの形式で送信されます。コードの変更は手動のコードレビューとテスト手順の両方で検証されるため、パスまたはパブリックPRは複数のエンジニアによってレビューされます。レビュープロセスループを数回繰り返した後、自動統合サーバーは、必要なすべてのプレリリーステストを実行して修正を検証します。検証の最後に、すべてのテストに合格すると、新しいリリースが発行され、利用可能なすべての通信チャネルを通じてすべてのユーザーと顧客に通知されます。

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。
原文:https://www.wolfssl.com/wolfssl-quality-assurance/