うるふブログ

wolfTPM v2.0 をリリースしました

2020年末にメジャーリリースしたwolfTPMは、wolfSSLのwebサイトからダウンロード可能となりました。このリリースでは次の様な多くの新機能が追加されています:

  • Microsoft Windowsが動作するPC上のTPM2.0H/Wチップをネイティブサポート
  • wolfTPMとMacOSユーザに、より簡単な開発を提供するTPMシミュレーターのサポート
  • TPN2.0パラメータ暗号化を使用した、MITM(中間者)攻撃からの保護。wolfTPMはMITM攻撃の保護の為のTPM2.オプションとして、XOR暗号化とAES-CFB暗号化の両方をサポートしています。
  • 通信相手の信頼性と整合性を検証するためのHMACセッションをサポート

また新しいサンプルコードも追加しています。TPM鍵をディスクに保存するオプションと、MITM攻撃からの保護の為にパラメータ暗号化を使用するオプションを備えたTPM鍵生成と鍵ローディングのサンプルが加わっています。外部で生成された秘密鍵をインポートをサポートし簡単にリロードできるようになりました。TPMの内部クロックを参照用に利用するユーザー向けに、TPMクロックの増分を取得するサンプルも追加しました。

TPM2.0ライブラリの拡張機能の中にはHMACセッションの利用と、TPMセッションとTPMオブジェクトの認証操作が容易になる新たなwolfTPMラッパーの利用が含まれています。

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

原文:https://www.wolfssl.com/wolftpm-v2-0-release/

TLS v1.3におけるトラフィックのスニッフィング

wolfSSLライブラリには、TLSトラフィックをスニッフィングするための便利なツールが含まれています。これは、少なくとも1つのキーがわかっている場合に、ライブまたは記録されたPCAPトレースをキャプチャして復号するために使用できます。通常、静的RSA暗号スイートが使用されますが、TLS v1.3では、Perfect Forward Secrecy(PFS)暗号のみが許可されます。 TLS v1.3の場合、すべての暗号スイートは、新しいセッションごとに新しいエフェメラルキーを使用します。 これを解決するために、共有シークレットの導出に使用される既知のキーを設定できる「静的エフェメラル」機能を追加しました。キーは定期的にロールされ、スニファツールと同期してトラフィックを復号できます。この機能はデフォルトで無効になっており、内部環境またはテスト環境でのみ推奨されます。 概念実証として、このサポートをApache httpdに追加して、Webトラフィックのリアルタイムの復号を実証しました。また、キーのローリングと同期を支援するキーマネージャーにも取り組んでいます。 興味深いユースケースは、監査を必要とする社内Webサーバーです。 TLSv1.3スニファのサポートはPR3044で追加され、v4.6.0で正式にサポートされました。 スニファとFIPS対応をサポートするApachehttpdブランチはこちらです。

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

原文:https://www.wolfssl.com/sniffing-traffic-tls-v1-3/

 

PKCS#12のRC2-ECB/CBC サポート

wolfSSL4.6.0リリースに含まれる機能の1つである、RC2-ECB / CBCのサポートとそのwolfSSLのPKCS#12機能への統合をご紹介します。 RC2-ECB / CBCは、下位互換性の必要性があり古い既存のアプリケーションまたはデバイスと相互運用の可能性があるユーザー向けにwolfCryptに追加されました。 この機能はデフォルトで無効になっており、”–enable-rc2″ オプションをコンフィギュレーション時に指定することで有効にできます。

RC2の追加によって、wolfSSLはpbeWithSHA1And40BitRC2-CBC暗号化を使用して生成されたPKCS#12バンドルの解析とデコードをサポートするようになりました。 デフォルトでは、OpenSSLのpkcs12コマンドはpbeWithSHA1And40BitRC2-CBC暗号化を使用して.p12バンドルを生成します。 今回の変更により、wolfSSLはOpenSSLで生成された.p12バンドルをデコードできるようになりました。

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

原文:https://www.wolfssl.com/wolfssl-pkcs12-support-rc2-ecbcbc/

wolfSSL 4.6.0をリリースしました

wolfSSLの新しいバージョンが利用可能になりました! バージョン4.6.0を入手するにはwolfSSLウェブサイトのダウンロードページあるいは、GitHubリポジトリのリリースセクションにアクセスしてください。このリリースでは、多くの技術的な追加が行われました。今後のブログのいくつかは新機能に触れていく予定です。このリリースには、Linuxカーネルモジュールのサポート、Apache httpd TLS 1.3のサポート、NXP DCP(i.MX RT1060 / 1062)暗号コプロセッサーのハードウェアアクセラレーションの追加、SiliconLabsハードウェアのサポートを始めとして多くの新機能が追加されています。

リリースアイテムの完全なリストは、バンドルされているREADME.mdにありますが、注目すべき変更点は次のとおりです。

  • Linuxカーネルモジュール! wolfSSLは、FIPS認証版のLinuxカーネルモジュールのサポートを有効になりました。これは、暗号機能に要望をお持ちのLinuxカーネルモジュール開発者にとってのビッグニュースです! wolfCryptとwolfSSLがLinuxカーネルのモジュールとしてロード可能になり、libwolfsslAPI全体を他のカーネルモジュールにネイティブに提供します。 Linuxで初めて、カーネル内ハンドシェイクが可能とする完全にカーネルに常駐するTLS / DTLSエンドポイントとして、TLSプロトコルスタック全体をモジュールとしてロードできるようになりました。 (–enable-linuxkm、–enable-linuxkm-defaults、–with-linux-source)。詳細については、ブログをご覧ください。
  • 新しいAppleA12Zベンチマーク! AppleのA12Zチップセットで使用するためのビルドテストの追加とインストラクションの更新。詳細を読み、ブログでベンチマークを確認してください。
  • wolfSSL数学ライブラリ! wolfSSL Single Precision Mathライブラリの拡張と、新しい–enable-sp-math-allビルドオプションの追加(より広範なアセンブリサポートが含まれ、より高速になりました)。
  • TLS 1.3の修正と追加!いくつかの追加は、SnifferサポートとApache httpd TLS1.3サポートの追加です。私たちはTLS1.3スニフィングで先導しています。これは、例えば幼い子供たちがコンピューターラボで見ることができるものを保護したい学校などの少数のユーザーにとって重要です。
  • 新しいハードウェアアクセラレーション! NXP DCP(i.MX RT1060 / 1062)暗号コプロセッサーのサポートが追加され、SL SEManagerを使用したSiliconLabsハードウェアアクセラレーションが追加されました。

修正事項


  • Mathライブラリ
    • mp_to_unsigned_bin_lenによる、最大MPより長いバッファーからの範囲外読み出しを修正
    •  fp_read_radix_16の範囲外読み出しを修正
    • H/W によるECCアクセラレーションで、新しいタイミング耐性のあるwc_ecc_mulmod_ex2関数のラッパーを追加するための修正
    • RSA-PSSエンコーディングされたメッセージをハッシュする際のエッジケースを処理
  • OpenSSL互換レイヤー
    • シリアルナンバーを設定するwolfSSL_X509_set_serialNumber関数の修正
    • WOLFSSL_X509 定義下で”これ以前は無効/これ以降は無効”のASN1時刻の設定を修正
    • X509_signにおける発行者名内のコンポーネントの順序の修正
    • DH_compute_keyの修正
    • AES GCMモードの暗号化・復号時の誤ったブロックサイズとAADのバッファリングを修正
    • EVP_KEYの作成時にRNGで失敗した際のミューテックス解放を修正
    • TLS接続の互換性レイヤーBIOでのノンブロッキング使用方法の修正
  • ビルド・コンフィギュレーション
    • WOLFSSL_USER_MALLOCが定義されたカスタムビルドの修正
    • Intel32ビットシステムでのED448コンパイラの警告を修正
    • Curve448を使用する32ビットシステムでCURVE448_SMALLを指定したビルドを行う際の修正
    • IARでSP_Mathを指定してビルドする際の修正
    • Macに対してのみranlib引数を設定するようにCMakeを修正,及び”->”のtypoを修正
    • –enable-wpas = smallを指定してのビルドを修正
    • openssl extraを使用してFIPS Readyのビルドを修正
    • マイクロチップを使用したビルドの修正(min/maxおよび未定義のSHA_BLOCK_SIZE)
    • WindowsでのNO_FILESYSTEMビルドの修正
    • IMX-RT1060におけるSHA-256サポートを修正
    • NO_TFM_64BITを使用したECCキー生成を修正
  • sniffer
    • 静的ECCキーを使用する場合のスニファの修正。 TLS v1.2静的ECCキーフォールバック検出を追加し、タイミングレジスタンスの為に新しいECC RNG要件を修正
    • SNIが有効の場合のProcessClientHello関数で、WOLFSSL_SUCCESSエラーコードを適切に処理するるように修正
    • “certificate”タイプのメッセージにHAVE_MAX_FRAGMENTを使用する際の修正
    • WOLFSSL_SNIFFER_WATCHでビルドする際の未使用の”ret”ビルドエラーを修正
    • myWatchCbおよびWOLFSSL_SNIFFER_WATCHで証明書/キーが見つからないことをエラーとして扱わないように修正
    • TCPの’out-of-range sequence number’ をハンドリングするように修正
    • ECDHを使用する場合のSSLv3の扱いを修正
  • PKCS
    • 復号化/署名または派生用のECCキーを生成するためのPKCS#11の修正
    • 不正な形式のPKCS#7バンドルをPKCS7_VerifySignedData関数で解析するときに内部変数をリセットするための修正
    • 抽出された公開鍵をwc_PKCS7_InitWithCert関数で確認する修正
    • PKCS#7で解凍を使用する場合の内部バッファーサイズの修正
  • その他
    • ガベージコレクションを防ぐために、C#検証コールバック関数を固定
    • ハンドシェイク後に公開鍵が所有され、解放された場合のDH修正
    • TLS1.3初期データパケットの修正
    • 一部のCube HALバージョン関するSTM32の問題とサンプルタイムアウトの修正
    • 二重ロックを防ぐためにmmCAUおよびLTCハードウェアミューテックスロックを修正
    • CRLモニターで潜在的な競合状態を発生する障害を修正
    • 3DESが負の長さを引き起こす可能性のある不正な形式の暗号化キーの修正
    • AES-NIでAES-CTRのパフォーマンス改善

性能改善/最適化


  • 単一精度、大きな整数演算
    • 0が先行する際のmp_radix_size調整
    • SPビルドで暗黙のキャスト警告を解決
    • 結果が固定長のdpに収まらない場合にエラーを返すように、mp_sqrを変更
    • clang使用時のARM64アセンブリの改善(clangがインラインアセンブリコードでの–x29を使用しないようにsp_2048_sqr_8を作り直し)
    • SP mod expが異なる長さの指数をサポートするように変更
    • TFM div:qのサイズの初期値を修正して、クランプがOOB読み取りを行わないように変更
    • –enable-smallstack指定時に多数のスタック深度の改善
    • Base64操作でキャッシュレジスタンスを改善
  • TLS 1.3
    • wolfSSL_peekに読み取りサイズを返す
    • P-521アルゴリズムのマッチングを修正
  • PKCS
    • PKCS#11キールックアップの改善とリファクタリング
    • 秘密鍵からRSA公開鍵に署名してロードするためのPKCS#11の変更
    • PKCS#7 SignedDataを使用前に秘密鍵の有効性を確認するよう変更
    • PKCS#7 VerifySignedDataにおいてコンテンツの長さをバンドルの合計サイズと照合して、大きなmallocを回避
  • OpenSSL互換レイヤー
    • wolfSSL_EVP_CIPHER_block_size関数でより多くの暗号のブロックサイズを追加
    • wolfSSL_OBJ_obj2txt関数で短い名前の代わりに長い名前を返す
    • サポートされているApachehttpdのバージョンを更新するために、OpenSSL互換性関数を追加
    • OpenSSL互換の場合、cipher_names「CCM-8」暗号に「CCM8」バリアントを追加
  • ビルド
    • IAR6.70に対するCortex-MSPASMのサポート追加
    • STMキューブパックのサポート(IDE / STM32Cube)
    • 4ビットテーブルを使用するAES-GCM GMULTにビルドオプション–enable-aesgcm = 4bitが追加
    • XTIMEオーバーライドを可能にするXilinx IDEのアップデート, Xilinx README.md 内のスペルミス修正、Xilinx SDK printf のサポート
    • 全オプションにED448を追加し、ED448チェックキーのnull引数のサニティチェックを追加
    • 全オプションにARC4、3DES、nullcipher、BLAKE2、BLAKE2s、XChaCha、MD2、およびMD4を追加
    • 特定の–disable-オプションを使用して–enable-allおよび–enable-all-cryptoから機能を選択的に削除する機能を追加
    • Windows上でRDSEED と RDRANDにIntel intrinsicsを使用
    • WOLFSSL_NO_CLIENT_AUTHでビルドするオプションを追加
    • wolfSSHの使用に関するビルド要件を更新し、制限を緩和
    • v1.4.56のlighttpdサポートアップデート
    • ファイルをESP-IDFフォルダーにコピーするバッチファイルを追加し、v4.0ESP-IDF使用時の警告を解決
    • –enable-stacksize = verboseの追加で、wolfCryptテストアプリ(testwolfcrypt)の各サブテストのスタック最高水準点を可視化
  • ECC
    • 非一定時間化のSP modinvを使用し、ECC検証のみのパフォーマンスの向上
    • ECC検証中に、使用する前にrとsの検証を追加
    • ECCでは常にsafe addとdblを使用
    • Joye’s double-add ladderを使用し、タイミングレジスタンスのスカラー乗算を変更
    • mp_jacobi関数を更新して、スタックを減らし、ベースECCビルドのパフォーマンスを向上
    • wc_EccPrivateKeyDecode関数でヒープメモリの使用を減らし、wc_ecc_sig_to_rsとwc_ecc_rs_raw_to_sigを改善して、メモリの使用を削減
    • StoreECC_DSA_Sig境界チェックを改善
  • OCSP
    • singleResponseで拡張機能を処理するためのOCSPの改善
    • 複数の証明書に対するOCSP要求/応答のサポート
    • OCSPステープリング応答を要求するために追加されたOCSPマストステープルオプション
    • id-pkix-ocsp-nocheck拡張機能のサポートを追加
  • Misc
    • ECCおよびRSA、PKCS#7、3DES、EVP、およびBlake2b操作用にコードカバレッジを追加
    • DTLS で書き込み時にMTUを確認
    • ハッシュ署名の選択をリファクタリングし、マクロWOLFSSL_STRONGEST_HASH_SIG(最強のハッシュを選択)とWOLFSSL_ECDSA_MATCH_HASH(ECC曲線に一致するハッシュを選択)を追加
    • クライアントから許可された厳密な証明書バージョン、TLS 1.2 / 1.3は、バージョン3より前のクライアント証明書を受け入れることができません
    • wolfSSL_get_ciphers_compat()、再ネゴシエーション表示やクォンタムセーフハイブリッドなどの偽のインジケーター暗号をスキップ
    • セッションチケットを解析するときは、TLSバージョンをチェックして、バージョン互換かどうかを確認
    • 整数型の無効なASN1パディングの追加のサニティチェック
    • MacおよびIntelアセンブリビルドでChaCha20ストリーミング機能を追加
    • –enable-oldtlsオプションをオンにしたスニファビルド

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

原文:https://www.wolfssl.com/wolfssl-4-6-0-now-available/

 

wolfSSLライブラリの最新テスト事情

(wolfSSL注釈:本記事はDeutsche Telekom Security社Robert Hörr氏によるブログ投稿を翻訳して掲載しています。)

Robert Hörr (e-mail: robert.hoerr@t-systems.com)
(Deutsche Telekom Security GmbH セキュリティ評価者)


私はRobert Hörrです。Deutsche Telekom Security GmbHでペネトレーションテスターとして働いています。ペネトレーションテスト(pentesting)というのは、wolfSSL のようなセキュリティソフトウエアを対象にOpenSSLで見つかったハートブリードのような脅威を発見するためのテストのことです。私はこれまでに私が開発したTLS-FAST(Fast Automated Software Testing) フレームワークを使ってwolfSSLの問題点をいくつか発見してきました(それらについては https://www.wolfssl.com/docs/security-vulnerabilities を参照)。私の次の目標はお客様のソフトウエアをテストするFASTサービスを提供することです。

何故TLSライブラリをテストするの?

TLSはインターネット上で最も普及したセキュリティプロトコルの一つです。インタネットユーザに広く利用されるように標準的なインタネットサーバはデフォルトの設定ではクライアント認証なしになっています。そのためTLSプロコル実装の脆弱性は容易に攻撃が可能です。たくさんのTLSの脆弱性がパブリックなCVEリストに登録されていて、その数はますます増えています。

どのようなテストが行われているの?

wolfSSLライブラリは絶えず成長しているプロジェクトであり、時間の経過と共に多くの拡張機能、サポートするTLSバージョンの追加も顧客に提供します。このような姿勢がwolfSSLの顧客に最大限の柔軟性を提供しているのです。このような成長過程でソースコードはより複雑となり全てのコードパスを目視ではレビューできなくなってきます。従って、動的でかつ自動実行されるテストが用いられます。この種のテストを効果的にに実行する為にはコードカバレッジファジング手法が使われます。このファジング手法の亜種は全コードパスを検出します。検出速度は利用できる計算機リソースに依存します。検出されたコードパスに対してメモリーリーク、バッファオーバーフロー、論理的不正などがシステマチックにチェックされます。

TLSテストにはどのようなツールが使われているの?

ファジング手法(予測不可能な入力データを与えて例外を発生させ挙動を観察する手法)に基づいた、いくつかのオープンソースのファジングツールが公開されていて利用可能です。最も人気のあるのは、AFL、 LbFuzzer と HonggFuzzでしょう。コミュニティはそれらのいずれにも多くのバグを発見しました。また、いずれも特定の領域に各々の強みを持っています。例えば、HonggFuzzは単位時間当たりの実行数が他より大きいです。私がTLSライブラリ向けテストフレームワークとして開発したFAST(Fast Automated Software Testing)はいくつかのFussing ツールの長所を束ねて、同時に恩恵をうけられるようにしました。時を経るに従い以下の機能とアプローチがフレームワークに追加されました:

1.決定論的実行:

  テストプロセス全体が決定論的であるため、発見された問題を簡単に再現できます 。

2.独立性:

  テストプロセスは環境から独立しています。例えば、 プロセスはすべてのオペレーティングシステムで実行できます。

3.現実的な使用:

  TLSライブラリは、現場で発生している問題を発見するために現実的に使用されます。従って、ソースコードとコードパスはテストによって変更されるべきではありません。

4.検出:

あらゆる種類の実装の問題点は、テストプロセスによって発見できます。バッファオーバーフローやメモリリークの例は、AddressSanitizerによって検出されます。 論理的な問題または脆弱性は、特定のTLSテストによって発見されます。

5.スケーラビリティ:

  テストプロセスは、計算リソースとストレージを追加することでリニアに拡張できます。

6.カバレッジ:

  コードカバレッジは、すべてのコードパスを検出するために使用されます。該当するすべてのコードパスが特定されたら、 実際のテストが開始されます。

7.自動化:

  完全なテストプロセスは、マシン上で自動的に実行されるので、手作業はもう必要ありません。

8.柔軟性:

  フレームワークは、別のテスト済みソフトウェアに適用させることができます。この適用には数時間または数日かかります。

wolfSSL ライブラリはどのようにテストされているの?

wolfSSLライブラリはいくつかのTLSバージョンのサポート、機能、拡張要素と暗号化オプションを含んでいます。テストは主にTLS(v1.2とv1.3)のハンドシェークと機能と拡張要素に対して行われます。その理由としては、TLSハンドシェークの実装には多くのTLS脆弱性(CVE)が知られていますし、他のTLSバージョンはもはや使用を推奨されないということです。

現在、私はTLS-FASTフレームワークを、GitHubマスターブランチで公開されているwolfSSLのwolfSSL_accept(..)、wolfSSL_connect(..)関数をテストするのに使っています。このマスターブランチはwolfSSLの最新のコードが取得できますから、新たに追加された障害を検出してテストされるべきです。新たな障害がステーブルバージョンに追加されるのを防ぐ必要があるのです。

私がこれまで検出した障害(https://www.wolfssl.com/docs/security-vulnerabilities)はTLSメッセージであるclient_hello とserver_helloをパースする処理に含まれていました。それらの障害はバッファーオーバーフローか未初期化メモリでしたから、サニティチェックやメモリ初期化処理を追加すれば簡単に解決できる類のものでした。完全を期す為に、wolfSSLライブラリは521,655行(コメントを空白を含まない)ものコードから成り立っているということを申し添えます。つまり、ファジングなしでは障害を回避することは簡単ではありません。

ファジングの将来は?

現時点では私がテストしている対象はwolfSSLライブラリだけです。しかし、(会社としての)wolfSSLは他にもライブラリ(例えばwolfCrypt)を提供しています。これらのライブラリは互いに協力しあいながら機能を提供しています。例えば、wolfSSLライブラリはwolfCryptライブラリの機能を使っています。つまり、これらのライブラリもまたテストされなければならないわけです。この目的の為に、将来、私は新たなFASTフレームワークを開発する予定です。新FASTフレームワークには既存のTLS-FASTフレームワークと同じ機能と手法を持たせます。FASTフレームワークは時と共に新機能が追加されることでしょう。

私の将来の目標はお客様にソフトウエアをテストするサービスとしてFASTフレームワークを提供することです。このサービスはすべての障害を迅速に検出することでしょう。

 

原文:https://www.wolfssl.com/modern-testing-wolfssl-tls-library/

Apache httpd 2.4.46 をサポートします

wolfSSLがApche httpd の最新バージョン(2.4.46)をサポートすることをお知らせします。
このサポートはwolfSSLとwolfSSL FIPS版の両方で提供します。
ご利用になる際には -–enable-apachehttpdに加えて–-enable-postauthオプションを指定してwolfSSLを構築してください。

このサポートに際して以下が提供されています:

  • OpenSSL互換APIの追加
  • Apache httpd に関するドキュメント
  • Apache httpd 用にパッチコード

ドキュメント及びパッチに興味をお持ちの方、あるいご質問がございましたら、info@wolfssl.jp にご連絡ください。

原文: https://www.wolfssl.com/support-apache-httpd-2-4-46/

SSLとTLSで何が違うの?

SSLもTLSもインターネット上での通信を安全にする目的で策定されたプロトコルを指す用語です。それぞれ、Secure Socket LayerとTransport Layer Securityの略です。

歴史的経緯

 

SSLはネットスケープコミュニケーションズ社が設計し同社のブラウザーに実装しました。SSLについてはいくつか脆弱性が発見され、バージョンを上げて安全面での改定を続けましたがPOODLE攻撃による脆弱性発見に伴い、最後の仕様であるSSL3.0も2015年にInternet Engineering Task Force(IETF)によって廃止されました。これ以降、SSLは使うべきでないとされています。
SSLが廃止されるより前の1996年に、IETFによりTLSの仕様策定が開始されました。TLSも次々に発見された新たな攻撃方法に対する対策を入れた改定が続き、現在広く使われているTLS1.2は2008年に制定されました。現時点の最新規格はTLS1.3であり、2018年8月に公開されました。
SSLとTLSは名前は異なりますが目的と役割は同一であり、両者はしばしば同一の意味としてつかわれることがあります。wolfSSLも社名と製品名に”SSL”を今も使っています。

仕様面での違い

 

SSLもTLSも通信経路上(通常TCP/IP)のデータを暗号化してやり取りする手段を提供するものですが、大きく
  • 通信相手を認証する
  • 通信データを暗号化する方法と鍵を取り決める
  • 通信データを暗号化・複合化する
の3つの処理を行っています。この機能に関してはTLSの最初のバージョンTLS1.0とSSLの最後のバージョンSSL3.0の仕様の差は僅かだったといわれています。したがってこの境界を知るよりも現在のTLS1.3は仕様上どのように変更されているのかを知ることの方が意義があります。

TLS1.3はそれまでと何が違うの?

 

以下の様な仕様上の変更が加えられました:

  • 暗号化アルゴリズムの整理と暗号化スイート表記法の変更
  • ハンドシェークの整理によるパケット往復数の削減・高速化
  • ハンドシェーク途中からの暗号化
暗号化スイートはそれまで何百という定義が存在しました。この中から使われなくなったアルゴリズムを取り除いたり、必須なアルゴリズムに限定するなどの整理と暗号化スイート表記法の整理を行い、5種類に削減されました。鍵交換アルゴリズムは一時鍵ディフィー・ヘルマンだけが残りました。ハンドシェーク時のパケット往復は最短1往復で済みます。またハンドシェークの途中から暗号化が行われます。その他にもセッション再開などが仕様として追加されています。TLS1.3では安全面の向上と通信の高速化を両立させる仕様になっています。

結論

 

SSLとTLSの両者はクライアントとサーバーで行われるハンドシェークを指す言葉としては今だ同じ意味として使われ続けています。しかし、仕様を指す言葉としてのSSLは今や過去の仕様であり実際の製品では使われることはありません。2020年現在ではTLS1.1を使うサーバーですら代表的なブラウザーからセキュリティ警告を受けるようになりました。SSLとTLSの違いは、やがて歴史を振り返る時にしか問われることはなくなるでしょう。皆さんは、TLS1.3と今の主流であるTLS1.2の違いを気にかけるようにして下さい。

関連ページ:

 

TLS1.2とTLS1.3の違いは何?

wolfSSL – TLS1.3

 

 

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

wolfSSL の Renesas TSIP サポート

組み込み向けwolfSSL SSL/TLSライブラリはRenesas Trusted Secure IP Driver(TSIP)をサポートし、Renesas RX65N プラットフォーム上でのテストを行っています。TSIPドライバーを使うことにより、wolfSSLが担っていた暗号化処理とTLS処理の一部をハードウエア処理に任せることができるのでパフォーマンス向上が図れます。

サポートするTSIPの機能

wolfSSLは下記のTSIP機能を統合しています:

  • TSIPドライバーのopen/close
  • 乱数発生機能(SP 800-22でテスト)
  •  SHA-1とSHA2565ハッシュ機能
  • AES-128-CBCとAES-256-CBCアルゴリズムでの暗号/復号化処理
  • 以下のTLS機能:
    • Root CA証明書の検証機能
    • 中間証明書を含むクライアントおよびサーバー証明書の検証機能
    • TLS暗号化スイート(4種類):
      • TLS_RSA_WITH_AES_128_CBC_SHA
      • TLS_RSA_WITH_AES_128_CBC_SHA256
      • TLS_RSA_WITH_AES_256_CBC_SHA
      • TLS_RSA_WITH_AES_256_CBC_SHA256

使用しているTSIPドライバー関数一覧

 

(注)Renesas TSIPドライバーはwolfSSLダウンロードパッケージには含まれていませんので、Renesas社から別途入手が必要です。

wolfSSLをビルドしてRX65N上でTSIPサポートを有効にする

Renesas RX65NとTSIPドライバーを有効にする為には以下の2つの定義が必要です:

WOLFSSL_RENESAS_TSIP          – Renesas TSIPドライバー利用を有効にします
WOLFSSL_RENESAS_RX65N  – Renesas RX65Nのサポートを有効にします

wolfSSL ベンチマーク

下記のベンチマーク結果は暗号化機能がTSIPドライバーを利用した際のパフォーマンス向上を示すものです。

 

 

 

 

 

我々のテストによりTSIPドライバーを使ったH/W暗号化は処理速度を平均2334%向上させ、結果として処理時間を92%短縮させることを示しています。

wolfSSLによるTSIPサポートの制限

wolfSSLがRenesas TSIPドライバーを使用するにあたり下記の制限があります:

  • TSIPドライバーが提供するTLS機能は次の暗号化スイートを使用する場合に限り利用可能です:
    • TLS_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_128_CBC_SHA256
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TSIPドライバーが提供するTLS機能は「TLSマスターシークレット」の生成をサポートしていますが、「TLS拡張マスターシークレット」の生成はサポートしていません。TLS拡張マスターシークレットが利用される場合には、TSIPのTLS機能は利用できません。
  • TSIPドライバーが提供する証明書検証機能は証明書が”RSA 2048 PSS with SHA-256″で署名されている場合にのみ利用できます。
  • TSIPドライバーが提供するTLS機能と暗号化機能はクライアントとして動作する場合にのみ利用可能です。サーバーとしての動作は現時点でTSIPドライバーではサポートされていません。
  • TSIPドライバーは実行時には単一のRoot CA証明書(RSA-2048-PSSーSHA256で署名されたもの)に限り利用可能です。異なるroot CA証明書を使ってTLS機能を利用する場合には、アプリケーションはwolfCrypt_Init()関数を呼び出してTSIPドライバーをリセットした後にTSIPドライバーに、tsip_inform_cert_sign()関数とtsip_inform_user_keys()関数を使って署名、鍵等を設定する必要があります。

参考資料

・TSIP (Trusted Secure IP) Module Firmware Integration Technology APPLICATION NOTE Rev. 1.06
ルネサス社のTrusted Secure IPドライバのページ
wolfSSL: ルネサスサポート

 

原文: https://www.wolfssl.com/renesas-tsip-support/

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

FIPS140-3で何が変わる?

今回は、FIPS140-2とFIPS140-3の違いについてです。 wolfSSLは組み込みシステム向けFIPS認証のリーディングカンパニーとして、ユーザーの皆様に常に最新の標準規格で最新の状態を提供したいと考えています。

さまざまな仕様の更新のなかでもFIPS 140-3標準の一番大きな変更点は、ハードウェアモジュール、ファームウェアモジュール、ソフトウェアモジュール、ハイブリッドソフトウェアモジュール、およびハイブリッドファームウェアモジュールが規定されるようになった点でしょう。新しい標準での検証では、ハイブリッドモジュールに適用するレベルに制約はありません。これは、レベル1よりも高いレベルでの検証を検討しているハイブリッドモジュールを使用しているベンダーにとっていいニュースです。FIPS140-2標準は、元々はすべてのモジュールをハードウェアとして定義され、その他のモジュール後になって追加されたという経緯がありました。

FIPS140-2とFIPS140-3のどちらも、4つの論理インターフェイス:データ入力、データ出力、制御入力、およびステータス出力が含まれています。 FIPS 140-3では5番目のインターフェイスとして、制御出力と呼ばれるインタフェイスが導入されました。 これは動作状態を示すために信号や制御データを含むコマンドの出力のためのインターフェイスです。FIPS 140-2の「信頼できるパス」に代わりに、FIPS 140-3では「信頼できるチャネル」が導入されました。これは保護されていないCSP( critical security parameter)を保護するために、データを送受信するエンドポイントデバイスと暗号化モジュールとの間の安全な通信リンクです。FIPS 140-3では、信頼できるチャネルを使用するレベル4モジュールは、信頼できるチャネルを使用するすべてのサービスに対して多要素IDベースの認証を使用しなければなりません。

モジュールサポートとしてクリプトオフィサーとユーザーロール、またオプションとしてメンテナンスロールを使用する必要がありましたが、FIPS140-3ではクリプトオフィサーロールのみが必須となりました。 FIPS 140-3では、「自己起動型暗号化出力機能( Self-Initiated Cryptographic Output Capability)」と呼ばれる新しい機能があり、モジュールは、オペレーターの介入なしに暗号化操作またはその他の承認されたセキュリティ機能を実行できます。

FIPS 140-3の新機能に関するブログ投稿はこちらにあります: https://www.wolfssl.jp/wolfblog/2020/11/30/fips140-3-whats-new/

wolfSSLでは、以下のようにFIPS140-3の最初の実装を提供する準備ができています。

  • パワーオンセルフテストが変更されて、2つのテストが必要となりました。POST(Pre-operational Self-Test )とCAST(Conditional Algorithm Self-Test)です。
  • これまでテストの一部として使用されていた従来のKAT(Known Answer Tests)は、起動時に実行する必要がなくなりました。これらは、アルゴリズムを使用する直前までに実行する必要がある条件付きテストになりました。アルゴリズムを使用しない場合は、テストする必要はありません。テストは、アルゴリズムのAPIを呼び出すと自動的に実行されます。
  • POSTは、純粋にメモリ内の実行可能ファイルの完全性を確認するテストのみになりました。まず最初に、このテストに使用するアルゴリズムをテストする必要があります。そのためにHMAC-SHA-256のCASTが自動的に実行され、次にPOSTが実行されます。 POSTは、コード内のwolfCryptのデフォルトのエントリポイントとして自動的に実行されます。
  • すべてのテストは、実行時に定期的に実行でき(may be)、必ず実行される必要があります(shall be)。必要に応じてテストを実行するためのAPIを提供します。組み込みアプリケーションでは、一部のCASTには時間がかかるため、アルゴリズムが使用される前の早いタイミングで実行できるようになっています。

原文: https://www.wolfssl.com/difference-fips-140-2-fips-140-3/

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

FIPS140-3はどこが新しくなったか?

FIPS140-3にはいくつかの重要な変更があります。何年にもわたって多くの仕様更新があり、いくつかの点で少し矛盾が生じてきておりそれらが解消されています。 wolfSSLは、他社に先駆けてFIPS 140-3の最良の実装を提供する準備ができています。新しくなった点としては次があります。

  • パワーオンセルフテストが変更されて、2つのテストが必要となりました。POST(Pre-operational Self-Test )とCAST(Conditional Algorithm Self-Test)です。
  • これまでテストの一部として使用されていた従来のKAT(Known Answer Tests)は、起動時に実行する必要がなくなりました。これらは、アルゴリズムを使用する直前までに実行する必要がある条件付きテストになりました。アルゴリズムを使用しない場合は、テストする必要はありません。テストは、アルゴリズムのAPIを呼び出すと自動的に実行されます。
  • POSTは、純粋にメモリ内の実行可能ファイルの完全性を確認するテストだけになりました。まず最初に、このテストに使用するアルゴリズムをテストする必要があります。そのためにHMAC-SHA-256のCASTが自動的に実行され、次にPOSTが実行されます。 POSTは、コード内のwolfCryptのデフォルトのエントリポイントとして自動的に実行されます。
  • すべてのテストは、実行時に定期的に実行でき(may be)、必ず実行される必要があります(shall be)。必要に応じてテストを実行するためのAPIを提供します。組み込みアプリケーションでは、一部のCASTには時間がかかるため、アルゴリズムが使用される前の早いタイミングで実行できるようになっています。

wolfSSLは、wolfCrypt FIPS 140-2レベル1証明書#2425から始まり、現在の証明書#3389まで、FIPS140-2での長い経験があります。wolfSSLは、NISTが証明書#2425を来年終了するのにあわせ、お客様の証明書#2425からの移行を支援しています。影響を受ける方は、新しい証明書の取得について私達までお問い合わせください!

wolfSSLは現在、組み込みFIPS証明書のリーディングカンパニーです。 FIPS 140-3で最高のサポートを提供いたします。このトピックに関する今後のウェビナーにぜひご参加ください。詳細はブログでお知らせいたします。

原文: https://www.wolfssl.com/whats-new-fips-140-3/

FIPSの詳細について、またはFIPS要件についてご質問のある方はinfo@wolfSSL.jpまでお問い合わせください。

Posts navigation

1 2 3 4 5 6 7 43 44 45