うるふブログ

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

wolfSSL 5.0.0をリリースしダウンロード可能になったことをお知らせします。本リリースには機能追加、不具合修正、改善/最適化と脆弱性の修正を含んでいます。このリリースはFIPS140-3への対応に同期してメジャーバージョンを5としています。

追加された新機能

新製品

  • FIPS 140-3  現在、ラボテスト、コードレビュー、最終CMVP検証が進行中です。
    • 連邦情報処理標準(FIPS)140-3は、連邦システム内の機密データまたは貴重なデータを保護するための必須の標準です。 FIPS 140-3は、FIPS 140-2の段階的な進歩であり、ISO 19790:2012およびISO 24759:2017仕様で標準化されています。

ポスト量子化

  • TLS 1.3グループとしてのNISTラウンド3 KEMのOQS(liboqsバージョン0.7.0)実装のサポート –with-liboqs
  • NIST ECCグループとOQSグループのハイブリッド化
  • レガシーNTRUとQSHを削除
  • 量子力学的に安全なグループが互換性レイヤーで利用可能に

Linux カーネルモジュール

  • FIPS 140-3の完全サポート、カーネル内パワーオンセルフテスト(POST)および条件付きアルゴリズムセルフテスト(CAST)
  • FIPS用の位置に依存しないカーネル内wolfCryptコンテナ –enable-linuxkm-pie
  • PKアルゴリズム(RSA、ECC、DH、DSA)およびAES / AES-GCMでのベクトル化されたx86アクセラレーション
  • 割り込みハンドラーでのベクトル化されたx86アクセラレーション
  • Linuxネイティブモジュールの署名
  • SSL/TLSとCrypto APIが他のカーネルモジュールから呼び出し可能に
  • LTSカーネル行@のサポート: 3.16, 4.4, 4.9, 5.4, 5.10
  • KCAPI: 暗号化のためのlibkcapiの利用をサポート

OpenSSL互換レイヤーの追加

  • ポーティング
    – Add support for libssh2
    – Add support for pyOpenSSL
    – Add support for libimobiledevice
    – Add support for rsyslog
    – Add support for OpenSSH 8.5p1
    – Add support for Python 3.8.5

 

  • API/構造体

– ERR_lib_error_string
– EVP_blake2
– wolfSSL_set_client_CA_list
– wolfSSL_EVP_sha512_224
– wolfSSL_EVP_sha512_256
– wc_Sha512_224/2256Hash
– wc_Sha512_224/256Hash
– wc_InitSha512_224/256
– wc_InitSha512_224/256_ex
– wc_Sha512_224/256Update
– wc_Sha512_224/256FinalRaw
– wc_Sha512_224/256Final
– wc_Sha512_224/256Free
– wc_Sha512_224/256GetHash
– wc_Sha512_224/256Copy
– wc_Sha512_224/256SetFlags
– wc_Sha512_224/256GetFlags
– wc_Sha512_224/256Transform
– EVP_MD_do_all and OBJ_NAME_do_all
– EVP_shake128
– EVP_shake256
– SSL_CTX_set_num_tickets
– SSL_CTX_get_num_tickets
– SSL_CIPHER_get_auth_nid
– SSL_CIPHER_get_cipher_nid
– SSL_CIPHER_get_digest_nid
– SSL_CIPHER_get_kx_nid
– SSL_CIPHER_is_aead
– SSL_CTX_set_msg_callback
– a2i_IPADDRESS
– GENERAL_NAME_print
– X509_VERIFY_PARAM_set1_ip
– EVP_CIPHER_CTX_set_iv_length
– PEM_read_bio_RSA_PUBKEY
– i2t_ASN1_OBJECT
– DH_set_length
– Set_tlsext_max_fragment_length
– AUTHORITY_iNFO_ACCESS_free
– EVP_PBE_scrypt
– ASN1_R_HEADER_TOO_LONG
– ERR_LIB
– X509_get_default_cert_file/file_env/dir/dir_env() stubs
– SSL_get_read_ahead/SSL_set_read_ahead()
– SSL_SESSION_has_ticket()
– SSL_SESSION_get_ticket_lifetime_hint()
– DIST_POINT_new
– DIST_POINT_free
– DIST_POINTS_free
– CRL_DIST_POINTS_free
– sk_DIST_POINT_push
– sk_DIST_POINT_value
– sk_DIST_POINT_num
– sk_DIST_POINT_pop_free
– sk_DIST_POINT_free
– X509_get_extension_flags
– X509_get_key_usage
– X509_get_extended_key_usage
– ASN1_TIME_to_tm
– ASN1_TIME_diff
– PEM_read_X509_REQ
– ERR_load_ERR_strings
– BIO_ssl_shutdown
– BIO_get_ssl
– BIO_new_ssl_connect
– BIO_set_conn_hostname
– NID_pkcs9_contentType

脆弱性対応

本リリースには2つの脆弱性対応を含んでいます。

  • [重要度:低]悪意を持って作成された鍵で特定のq値が使用された場合、DSA署名の作成でハングする – DSA鍵が無効なq値である1または0でデコードされ署名の作成に使用された場合、wolfSSLがハングします。 DSAで署名を作成していて、外部ソースから提供された鍵を使用しているユーザーが影響を受けます。
  •  [重要度:低]証明書に名前の制約があり、複数のサブジェクトの別名を持つ場合の誤った証明書検証 – 証明書に複数のサブジェクト代替名が使用されている場合、以前のバージョンのwolfSSLは証明書を誤って検証する可能性がありました。 複数の代替名と名前の制約を持つ証明書を検証するユーザーは、証明書検証コールバックを使用してこのケースをチェックするか、wolfSSLをこのバージョン5.0.0に更新することを推奨します。Luiz Angelo Daros de Luca氏の報告に感謝します。

その他

  • KCAPI:暗号化にlibkcapiを使用するためのサポートを追加(Linuxカーネル)
  • –with-max-rsa-bits= および –with-max-ecc-bits=  の構成オプション
  • keilのためのSP ARMM Thumのサポートとパフォーマンス改善
  • WOLFSSL_VERIFY_POST_HANSSHAKE検証モードのサポートを追加
  • PKCS#11: PKCS #11ライブラリとの静的リンクをサポート –enable-pkcs11=static  LIBS=-1
  • wolfCLU製品で使用するビルドオプション –enable-wolfcluを追加
  • X9.42ヘッダーをサポート 例:”BEGIN X9.42 DH PARAMETERS”
  • 代替証明書チェーン機能を有効にしてwolfSSLを構成するための –enable-altcertchainを追加
  • ASN.1ヘッダーなしでRSA公開鍵を取得できるようパブリックAPI wc_RsaKeyToPublicDer_exを追加(seq + n + eのみをかえすことが可能)
  • CMakeビルドにSNI及びTLSxオプションを追加

 

変更点の完全なリストについては、wolfSSLにバンドルされているChangeLog.mdを確認するか、GitHubのページ(https://github.com/wolfSSL/wolfssl)を参照してください。

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

 

wolfSSLにおけるソフトウェア開発プロセス

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における品質保証

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/

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

wolfMQTT v1.10.0をリリースしました。

リリースのトピック

このリリースでは以下に示す、いくつかのバグ修正と処理の最適化を含んでいます:

  • XC32向けFALL_THROUGH マクロを改良(PR#227)
  • デバッグ出力を許可している場合にMqttSocket_connectでNULL出力される潜在的なバグの修正(PR#229)
  • ノンブロッキングでチャンクデータ転送におけるバグ修正(PR#230)
  • QoSレスポンスの修正(PR#231, 240)
  • MQTTv5 プロパティハンドリングのバグ修正(PR#232, 233, 234, 236, 238, 241)
  • ファジングテストでの障害修正(PR#242)

機能追加と修正事項のリストはダウンロードに含まれているチェンジログを参照してください。

wolfMQTTの提供機能

wolfMQTTが提供している機能や準拠している仕様について紹介します。wolfMQTTライブラリはC言語で書いたMQTTクライアント実装です。wolfSSLライブラリを下層に使用しており、SSL/TLSを組み込み機器用に提供しているライブラリです。ベアメタルからマルチプラットフォームへも対応可能で、省メモリであり、拡張性も備えています。

準拠している仕様

  • MQTT  v3.1.1
  • MQTT v5.0
  • MQTT-SN(Sensor Network) v1.2

アプリケーションアーキテクチャ

  • ベアメタルアプリケーションにおけるノンブロッキングAPI
  • OS/RTOS使用下でのマルチスレッディング対応

コールバック

  • パブリッシュされたメッセージの受信をトリガーにして登録してある関数を呼び出す機能
  • 容易な再接続を可能とするブローカからの切断イベントコールバックの提供
  • どのようなネットワークI/Oに対しても簡単に統合可能にするコールバック
  • MQTTv5プロパティは登録されたコールバック関数によって処理可能

サポートされるビルド環境

  • Makefile を使ったMac/Linux/Unix でのビルド
  • Visual Studio solution
  • Arduino
  • MinGW
  • あらゆるターゲット向けのクロスコンパイル環境

 

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

ハードウェアセキュリティフォーラム2021「wolfCryptの暗号ライブラリ最適化手法について」

ハードウェアセキュリティ研究会(HWS)主催の「ハードウェアセキュリティフォーラム2021」で、弊社古城が1セッションを担当いたします。

このフォーラムは12月10日(金)終日、オンラインとの現地参加のハイブリッド開催の予定で、IoT機器のセキュリティを支える技術の1つとして、暗号ライブラリ最適化手法について説明いたします。

 

2021年12月10日(金)15:50-16:30

wolfCryptの暗号ライブラリ最適化手法について

wolfSSL Japan 合同会社
技術統括
古城 隆

参加費、参加申し込みなどはこちらをご覧ください。

 

TLS1.3トラフィックをスニッフィングする

wolfSSLライブラリには、TLSトラフィックをスニッフィングするための便利なツールが含まれています。このツールは、少なくとも1つの鍵が既知の場合に限って、ライブまたは記録されたPCAPトレースをキャプチャして復号するために使用できます。通常、静的RSA暗号スイートが使用されます。しかし、TLS v1.3では、Perfect Forward Secrecy(PFS)暗号のみが使用されます。 TLS v1.3の場合、すべての暗号スイートは、新しいセッションごとに新しいエフェメラル鍵を使用します。つまり、TLS1.3ではTLSトラフィックをスニッフィングするツールがそのままでは使用できないことになってしまいました。

この制限を解決するために、wolfSSLには共有シークレットの導出に使用される既知のキーを設定できる「静的エフェメラル」機能を追加しました。キーは定期的にロールされ、スニファーツールと同期してトラフィックを復号できます。この機能はデフォルトで無効になっており、内部環境またはテスト環境でのみ推奨されます。

概念実証として、この機能をApache httpdに追加して、Webトラフィックのリアルタイムの復号を実証しました。また、キーのローリングと同期を支援するキーマネージャーにも取り組んでいます。

興味深いユースケースは、監査を必要とする社内Webサーバーです。 TLSv1.3スニファのサポートはPR3044で追加され、wolfSSL v4.8.1で正式にサポートされました。 スニファとFIPS対応をサポートするApachehttpdブランチはこちらです。

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

ECIES-SEC.1 と ISO/IEC 18033

wolfSSLライブラリは、ECIES(Elliptic Curve Integrated Encryption Scheme)の実装でECCを使用した暗号化と復号を長い間サポートしてきました。最近、ECIESコードが更新され、SEC.1およびISO / IEC18033バリアントがサポートされるようになりました。

ECIESは、RSA暗号化アルゴリズムと同等の楕円曲線であり、キーカプセル化メカニズム(KEM)として役立ちます。 KEMは、これまで通信したことのない2者間で共有鍵を確立するために使用されます。たとえば、対称鍵をEC公開鍵で保護することにより、EC秘密鍵の所有者のみがそれを導出できます。

RSA暗号化とは異なり、ECIESは、秘密鍵の所有者にメッセージを安全に送信するためにも使用できます(つまり、データカプセル化メカニズム(DEM))。 ECIESアルゴリズムに対称暗号を統合すると、任意の量のデータを暗号化できます。

現実の世界では、ECIESは高度道路交通システム(ETSI TS 103 097)などの標準で使用されており、AndroidPayとAppleのiMessageおよびFind My でも使われています。

wolfSSLライブラリでは、デフォルトのアルゴリズムはSEC.1で説明されているとおりになりました。元のwolfSSLアルゴリズムが必要な場合は、-enable-ecies = oldで構成するか、WOLFSSL_ECIES_OLDを定義します。または、ISO / IEC 18033アルゴリズムが必要な場合は、-enable-ecies = iso18033で構成するか、WOLFSSL_ECIES_ISO18033を定義します。

 

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

NTP(Network Time Protocol)への統合

wolfCryptライブラリの高い移植性が、新しいポーティングを可能にしています。 今後、最新のオープンソースプロジェクトポートのいくつかを紹介しますのでご期待ください。

今回は、wolfSSLをNTP(Network Time Protocol)プロジェクトと統合した例を紹介します。 このポートを使用すると、FIPSで検証された暗号ライブラリであるwolfCryptでNTPを使用できます。 NTPは、パケット交換された可変遅延データネットワークを介してコンピューターのクロックを同期するように設計されています。 NTPの詳細については、プロジェクトのWebサイトntp.orgにアクセスすることもできます。 NTPがOpenSSL互換性レイヤーを介してwolfSSLを呼び出すことができるようにしました。 ここからGitHubページにアクセスできます。

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

wolfSSL はIoT SAFE規格に準拠しています

現在、数多くのベンダーからさまざまなテクノロジーを使用したハードウェアセキュアデバイスが提供されています。wolfSSL組み込みSSL / TLSライブラリは、それらハードウエアセキュアデバイスの多くをサポートしています。

ハードウェアセキュアデバイスには、ハードウェアで実現された「ルートオブトラスト」、非同期暗号化機能と鍵倉庫(key vault)を提供する、IoTデバイスでエンドツーエンドのセキュリティを実現するよう特別に設計されているのものがあります。

GSMAは、モバイル通信業界に焦点を当てたモバイルオペレーター、メーカー、企業を代表するアライアンスです。GSMAは、信頼のルートメカニズムであるIoT-SAFEとしても知られる安全なエンドツーエンド通信用のIoTSIMアプレットを実装するためのガイドラインを公開しました。このテクノロジーは、モバイルネットワークを介して接続された組み込みシステムで実行されるアプリケーションとサービスを保護するためのルートオブトラストとしてのSIMカードの使用を促進します。 IoT-SAFEは、キープロビジョニングの新しい可能性を開きます。

wolfSSLは、モバイル業界のパートナーと協力して、最近、wolfSSL組み込みTLSライブラリ用のIoT-SAFEモジュールを開発しました。コードはポータブルで、LTEモデムとIoT-SAFE対応のSIMカードを備えた組み込みボードで使用することを想定して設計されていますが、どのようなIoT-SAFE対応のSIMカードを使った環境であっても対応できる柔軟性も備えています。

IoT-SAFE APIを使用してTLSセッションを確立するサンプルプログラムを用意しています。このサンプルには、テストECC証明書と鍵が事前にプロビジョニングされたSIMカードを使用する例を用意しました。 TLS1.3と1.2の両方がサポートされています。

堅牢なエンドツーエンド戦略でデバイスからクラウドへの通信を保護することは、wolfSSLの最優先事項であることは言うまでもありません。さまざまなアプリケーションやユースケースでwolfSSL IoT-SAFEサポートがお役に立てることを楽しみにしています。

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

Posts navigation

1 2 3 4 46 47 48