wolfSSL 2019年のご報告

wolfSSLのお客様、またエンドユーザー様に、弊社の2019年の実績を報告いたします。

wolfSSLの2019年は、おかげさまで前年に続き大きく成長した飛躍の一年となりました。弊社の製品が持つ技術的優位性と、テストおよび品質への継続的な投資を土台に事業を大幅に拡大させました。

市場に先駆けたTLS 1.3への準拠、自動車市場に向けたMISRA-C対応、米国政府機関への納入に向けたFIPS認証、航空電子機器向けのDO-178サポートなどを行ってきました。また、ファジングリソースに含まれる社内外の追加ソースが示すように、wolfSSLは市場で最もテストされた製品を提供し続けています。弊社製品をお使いの多くのユーザによるコード監査も多数受けてきています。そして、世界最高レベルのコード監査人とテスターと称される方々にも、wolfSSLの製品のコードをレビューしてもらいました。多くのテストと多くの目によるチェックにより、今日の最もテストされたTLSおよび暗号化コードの品質を達成しています。wolfSSLに興味を持っていただきありがとうございます。私たちは2020年に素晴らしいスタートを切ることができ、本年の残りの期間も皆様の期待に応えられるよう努力してまいります。

(注目: TLS、暗号化エンジンを選んでいただく際、暗号化エンジンのプロバイダがファジングを実施していることはセキュリティ上大変重要な要素です。)

 

wolfSSL技術進歩

wolfSSL組込みTLSライブラリは、2019年に合計4つのバージョンをリリースしました。各バージョンで不具合修正、拡張、および新機能の追加を実施しています。主な変更点は次のとおりです。

1.ハードウェアとOSの新たなサポート

2.ソフトウェアの新たなサポート

  • Apache Webサーバー(–enable-apache-httpd、WOLFSSL_APACHE_HTTPD)
  • OpenVSwitch
  • Google WebRTC
  • 198の新しいOpenSSL互換性API
  • Qt(–enable-qt、–enable-qt-test、WOLFSSL_QT)
  • OpenVPN

3.既存のポートの更新

  • Arduino (デフォルト設定の更新/リファクタリング、スケッチサンプルコードの改善)
  • ザイリンクス (Xilinx FreeRTOS ビルドに対する更新)
  • Nginx (1.15.0 パッチ更新、1.16.1 と 1.17.5 のサポート)

4. オペレーティングシステムの更新

  • Micrium uC/OS-III (ポートの更新、静的マクロとインラインマクロの調整)
  • Windows (カスタム ECC曲線、ディレクトリ機能の修正)
  • NetBSD (デフォルトビルドとmutexの使用)
  • SafeRTOS (ビルド問題の修正)
  • VxWorks (ポート更新)
  • Yocto Linux (使いやすさの向上、アップデート、ビルド手順)

5.コンパイラとIDEの更新

  • IAR-EWARM(Cortex-Mの変更、コンパイラ警告の修正)
  • Renesas CS+(ユーザー設定サポートの改善、サンプルの更新)
  • XCode(プロジェクトファイルの更新、i386 上の iPhone シミュレータのビルドの修正)
  • Visual Studio(ビルド警告の修正、snprintfのラッパー)
  • Cygwin(可視性タグの修正)

6.TLS 1.3のアップデート

  • 相互運用性の向上
    • 相互運用性の修正とバージョンネゴシエーションの改善
  • 移植性の向上
    • 移植性改善(時間要件の簡素化、XTIME_MS)
  • テストの強化
    • ファジングの追加
    • 一部の組み込みターゲットの自動テスト
    • 既知のユースケースと構成を対象とした顧客テストの改善
  • その他の暗号スイート
    • NULL暗号スイートの追加(TLS_SHA256_SHA256、TLS_SHA384_SHA384)

7.新しいハードウェア暗号サポート

  • nRF52840のARM CryptoCell-310
  • RX65NのRenesas TSIP
  • HMAC、AES-CBCおよびRNGのPKCS#11サポート
  • Intel QuickAssist v1.7ドライバのサポート
  • Intel QuickAssist RSA鍵生成とSHA-3サポート
  • STM32WB PKA ECC署名検証

8.既存のハードウェア暗号サポートの改善

  • STM32(AES-GCM性能改善)
  • STSAFE(wolfSSL暗号化コールバックサポート、エラーコード処理の改善)
  • TI(既存のハードウェア暗号のアップデート)
  • NXP mmCAU性能改善(35-78%の向上)
  • 暗号コールバック(3DESのサポート、機能改善)
  • Microchip ATECC508/608A、AES-NI、AVX2、ARMv8、devcrypto/afalg、ST CubeMXへの修正

9.新しいアルゴリズムと更新されたアルゴリズム

  • Ed25519ctxとEd25519phの追加(署名/検証-RFC 8032)
  • Blake2sの追加(32ビットBlake2サポート)
  • CMS / PKCS#7の改善

10.アルゴリズムの性能最適化

  • ARMアーキテクチャ
    • SIMD NEON拡張を使用したChaCha20
    • SIMD NEON拡張を使用したPoly1305
    • Curve25519 / Ed25519
    • SIMD NEON拡張を使用したSHA-384 / 512

11.新規および更新されたビルドオプション

  • “-enable-ecccustcurves=all” – すべての曲線タイプを有効化
  • “-enable-16bit” – 16 ビットコンパイラのサポートを有効化
  • “-enable-rsavfy” – RSA検証のみのビルド
  • “-enable-rsapub” – RSA 公開鍵のみのビルド
  • “-enable-armasm” – autotools で使いやすくするために更新
  • “-enable-fallback-scsv” – サーバー側のフォールバックSCSV
  • “-enable-titancache” – 新しいセッションキャッシュサイズ、200万以上のセッションを保持可能

12.TLS拡張サポートの追加と更新

  • TLS Trusted CA拡張機能を追加
  • TLS 1.2以下にEncrypt-then-MACを追加
  • 署名アルゴリズム拡張を無効にする機能
  • SNI拡張の解析効率の向上
  • ALPNの解析時にエラーチェックを追加

13.Single Precisionの更新

  • Cortex-Mサポート
  • 素数判定のサポート
  • 基数が2の場合のmod expの特殊な実装
  • 4096ビットRSAおよびDH操作のサポート

14.FIPS 140-2検証の追加

  • wolfCrypt v4.0.0 FIPS認証を取得(証明書#3389)
  • 新しくFIPS Ready版をリリース
  • configure.acにwolfRandビルドオプションを追加
  • FIPS 140-2 運用環境の追加
    • プロセッサアルゴリズムアクセラレータ(以後PAA)あり/なしのARM Cortex-A72のHP PN 3PZ95-60002上で動作するHP Imaging&Printing Linux 4.9
      • PPAありでのARMv8 / NEONアセンブリ最適化を含む
    • Intel®Core™i5-5300U CPU @ 2.30GHz x 4を搭載したIntel Ultrabook 2 in 1で動作するLinux 4.4(Ubuntu 16.04 LTS)(PAAあり/なし)
      • PAAありのIntel AESNIとRDSEEDサポートを含む
    • STMicroelectronics STM32L4Rx(PAAなし)を搭載したSTMicroelectronics STM32L4R9I-DISCO(ディスカバリーキット)で動作するOpenRTOS v10.1.1
    • PAAあり/なしのIntel®Core™i7-7820 @ 2.9GHz x 4を備えたRadar FCL Package Utilityで実行されるWindows 10 Enterprise
      • PAA ありのIntel AESNIおよびRDSEEDサポートを含む
    • PAAあり/なしのIntel®Core™i5-5300U CPU @ 2.30GHz x 4を搭載したIntel Ultrabook 2 in 1で実行されるWindows 10
    • PAA ありのIntel AESNIおよびRDSEEDサポートを含む

15.テスト

  • Coverity、scan-build、およびcppcheckレポートの修正
  • 増加したコードカバレッジ向けのテストケースの強化
  • プルリクエストとナイトリーテストの追加
  • APIのサブセットに対するABIコンプライアンステスト

16.サンプルコード

  • 新しいColdfire MCF5441X NetBurnerのサンプルコード
  • Microsoft Azure Sphereデバイス用の新しいVisual Studioソリューション
  • 新しいNXP Kinetis Design Studio(KDS)サンプルプロジェクト

17.その他の製品の機能強化

  • wolfMQTT(2リリース)
    • マルチスレッドサポート (-enable-mt)
    • ポートのアップデート
      • Visual Studio
      • NXP MQX / RTCS
      • Microchip Harmony
    • サンプルコード
      • 新しいマルチスレッドのサンプルコード
      • Azure認証の更新
      • サンプルコードにデフォルトのブローカー
      • 新しいシンプルなクライアントのサンプル
      • 新しいノンブロッキングのサンプル
  • wolfSSH(3リリース)
    • クライアント側の公開鍵認証のサポート
    • 送信された公開鍵をチェックするコールバック関数
    • Windows CE、Micrium 3、MQX 4.2のSFTPクライアントとサーバーのサポート
    • NucleusとWindowsのポートの更新
    • ウィンドウサイズの最適化
    • 自動化テストとファジングの改善
    • ノンブロッキングサポートの更新
    • その他のサンプルコード:Renesas CS +、SFTP
    • AES-CTR接続のサポートを追加
    • 相互運用性と信頼性の向上
    • TCPポート転送
    • グローバルなリクエストメッセージのサポート
    • クライアント側の疑似端末サポート
  • wolfTPM(3リリース)
    • Microchip ATTPM20のサポート
    • Bareboxのサポート
    • 複数の並行プロセスのサポート
    • チップ検出、互換性、起動性能の改善
    • 新しいAPIユニットテストフレームワークによるより良いテスト
    • 認証付きのNVのサポート
    • HMAC / AES、ECDHE、PCRの新しいラッパーとサンプルコード
    • TLSクライアント/サーバーのサンプルコードを追加
    • スタック使用量の削減
    • 拡張されたベンチマークサポート
    • FIPSモードとSymmetricオプションの暗号化コールバックフラグ
    • ST33 TPM2_SetModeコマンドのサポート(省電力)
  • wolfBoot(3リリース)
    • Cortex-M0用のコンパイルオプション
    • RV32 RISC-Vアーキテクチャのサポート
    • STM32F76x / 77xハードウェア支援デュアルバンクサポート
    • 新しいHAL対応
      • Atmel SAMR21
      • TI CC26X2
      • NXP / Freescale Kinetis SDK
      • RV32 FE310(SiFive HiFive-1)
      • STM32L0
      • STM32G0
      • STM32F7
      • STM32H7
      • STM32WB55
    • ECC-256 DSAのサポート
    • 更新/スワップ用の外部フラッシュのサポート
    • アンチロールバック保護
    • 鍵生成と署名のための新しいPythonツール
    • フラッシュ書き込み機能をRAMに移動する機能
    • ブートローダーが自身を更新する機能
    • TPM2.0対応
      • wolfTPMとの統合
      • デュアルTPM / FLASH通信をサポートする拡張STM32 SPIドライバー
      • インフィニオン9670とSTM32でテスト済み
      • RSA 2048ビットデジタル署名検証
  • cURL
    • 商用サポート開始
  • wolfSSL-py(2リリース)
    • Python3の修正
    • ネイティブ機能検出
  • wolfCrypt-py(1リリース)
    • Ed25519暗号を追加
    • ECC鍵処理のメソッドを追加
    • Ed25519の未加工の署名/検証の新しいメソッド
    • RSAの新しいメソッド:make_key()encode_key()
    • wolfSSLビルドに基づくネイティブ機能の検出

wolfSSLトップ10ブログポスト/技術発表(グローバル)

2019開催のウェビナー(グローバル)

  1. TLS 1.3を使用する利点
  2. wolfSSL:TLS 1.3、OpenSSLの比較
  3. セキュアブートの概要
  4. OpenSSLからwolfSSLへの移行
  5. アビオニクスのセキュリティ

wolfSSL組織の成長

  • wolfSSLは、TLS/暗号の単一の実装のみに特化したチームとして世界最大級のチームです。グローバルチームで活躍するエンジニアを募集しています。
  • wolfSSLは顧客基盤を大幅に拡大し、現在で1,000社以上のお客様の製品で採用され、30以上のベンダーとパートナー関係を持ち、世界中で20億を超える接続をセキュアにしています。
  • wolfSSLは、2019年にヨーロッパでの体勢を強化し新メンバーが2人加わりました。
  • wolfSSLは62のイベント、展示会に参加しました(下記参照)。世界中のネットワークセキュリティをお探しの方々にwolfSSLをご紹介し、信頼できる暗号化とTLSの実装をお勧めしています。

wolfSSLイベントと展示会

2019年は合計で62のイベント、展示会に参加しました。2018年の50回から増加しています(2017年は30回)。参加したイベント、展示会の開催地は10か国、18のアメリカの州、44の都市に及びました。昨年参加したイベントは次のとおりです。

  1. CES(ラスベガス、ネバダ州)
  2. スマートファクトリーエキスポ(東京)
  3. Japan IT Week West(大阪)
  4. Embedded Tech India Expo(インド、ニューデリー)
  5. FOSDEM(ブリュッセル、ベルギー)
  6. DistribuTECH(ニューオーリンズ、LA)
  7. Embedded Technology Nagoya(名古屋)
  8. Embedded World 2019(ドイツ、ニュルンベルク)
  9. RSA(カリフォルニア州サンフランシスコ)
  10. Medtec Japan 2019(東京)
  11. MtoM Embedded Systems(フランス、パリ)
  12. Black Hat Asia 2019(マリーナベイサンズ、シンガポール)
  13. cURL UP(プラハ、チェコ共和国)
  14. NXP Tech Days Chicago(シカゴIL)
  15. SIdO(フランス、リヨン)
  16. Japan IT Week Spring(東京)
  17. NXP Tech Days MInneapolis(ミネアポリス、ミネソタ州)
  18. IoT Tech Expo Global(ロンドン、イギリス)
  19. LinuxFest(ワシントン州ベリンガム)
  20. Satellite 2019(ワシントンDC)
  21. NXP Tech Days Seattle(ベルビュー、ワシントン州)
  22. ICMC(バンクーバー、BC)
  23. Internet of Things World(カリフォルニア州サンタクララ)
  24. ESC Boston(ボストン、マサチューセッツ)
  25. Wireless IoT(東京)
  26. RTCA(クリスタルシティ、バージニア州)
  27. TU Automotive(チューリッヒ、スイス)
  28. Risc-Vサミット(ドイツ、チューリッヒ)
  29. NXPコネクト(カリフォルニア州サンタクララ)
  30. Embedded Technology West(大阪)
  31. IoT TechExpo Europe(アムステルダム、オランダ)
  32. Sensors Expo West(カリフォルニア州サンノゼ)
  33. IoT Security Forum(東京)
  34. Microchip Master 2019(フェニックス、アリゾナ州)
  35. Black Hat 2019(ラスベガス、ネバダ)
  36. NXP Tech Days(カリフォルニア州アーバイン)
  37. Billington International Cyber​​ Security Summit(ワシントンDC)
  38. RIOTサミット(フィンランド、ヘルシンキ)
  39. NXP Tech Days Boston(ボストン、マサチューセッツ)
  40. IoT World Asia 2019(シンガポール)
  41. ST Dev Con(カリフォルニア州サンタクララ)
  42. FACEコンソーシアム(オハイオ州デイトン)
  43. Federal Identityフォーラム(フロリダ州タンパ)
  44. ST Tech Tour(バンクーバー、BC)
  45. ArmTech Con(サンノゼ、カリフォルニア州)
  46. NXP Tech Days Detroit(デトロイト、MI)
  47. Japan IT Week Autumn(千葉幕張メッセ)
  48. ST Techツアー(ミネソタ州ミネアポリス)
  49. ザイリンクスXSWG(ロングモント、CO)
  50. Embedded Conference Scandinavia(ストークホルム、スウェーデン)
  51. ETSI / IQC量子安全暗号ワークショップ(ワシントン州シアトル)
  52. ST Techツアー(マサチューセッツ州ボストン)
  53. NXP Tech Days Toronto(トロント、カナダ)
  54. ザイリンクスXWSG(バージニア州ハーンドン)
  55. IoT Tech Expo North America(カリフォルニア州スタンタクララ)
  56. Embedded Technology / IoT Technology(パシフィコ横浜)
  57. オープンソースカンファレンス(東京)
  58. Embedded Software Engineering Kongress(ドイツ、ジンデルフィンゲン)
  59. ザイリンクスXWSG(ドイツ、ミュンヘン)
  60. ARM Tech Symposium(東京)
  61. RSC-Vサミット(カリフォルニア州サンノゼ)
  62. トロンショー(東京)

まとめると2019年は晴らしい年でした。2020年には、これまで以上に安全で機能的なソフトウェアをお客様とコミュニティに提供できるよう努めてまいります。

wolfSSLではみなさまからのフィードバックをお待ちしております。 info@wolfssl.jp までお寄せください。

wolfSSLウェビナー「IoTのためのセキュアブートとリモートファームウェア更新」のご案内

wolfSSLウェビナー開催のご案内です。
2020722日(水) 16:00~16:30

 

スピーカー:
wolfSSL Inc. シニアエンジニア
Daniele Lacamera(ダニエレ・ラカメラ)

 

300億台にも達すると言われる今日のIoTデバイス。そのセキュリティはどのように強化していけばいいのか — 長期間使用されるデバイスが将来にわたり安全に進化し、かつ製品競争力を強化し続けていくために、安全なファームウェア更新が注目されています。IETFドラフト”A Firmware Update Architecture for Internet of Things Devices(IoTデバイス向けファームウェア更新のアーキテクチャ)”とは、そこで示されるファームウェア更新の要件とは、またwolfSSLが提供するwolfBootセキュアブートローダの特徴とアーキテクチャなどを説明します。

本ウェビナーは英語での開催となります。

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

 

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

 

連載「wolfの実力」 第五回:ヒープメモリーを深堀りしてみる

組込みデバイスの設計で気になるのは処理スピードだけではありません。メモリー容量についても以前よりは制約は緩くなってきたとはいえ、多くの場合できるかぎりの節減がもとめられるのが実情で、特にRAMエリアの容量には注意が求められるケースが多いかと思います。

 

wolfSSLの場合、設計ポリシーとして静的に確保されるデータエリアは最小限となるよう設計されていますので、今回は、必要の都度確保されるヒープ領域について、その挙動、サイズについて見ていくことにします。

 

TLSの通信をヒープエリア利用の観点からみると、次のようなステップを踏むことになります。かっこの中はそれぞれのステップで代表的に使用するwolfSSLのAPI名です。

 

1)コンテクストの確保 (wolfSSL_CTX_new)

2)鍵、証明書の格納 (wolfSSL_CTX_load_verify_locations)

3)セッション管理エリアの確保 (wolfSSL_new)

4)ハンドシェイク (wolfSSL_connect/accept)

5)アプリケーションデータ転送 (wolfSSL_write/read)

 

図1は、1)~4)の準備段階でのヒープエリアの使用量の一例を示しています。必要とするヒープエリアは、前のステップで確保し引き続き必要とされるエリア(濃い青の部分)とそのフェーズで使用するエリア(薄い青の部分)があります。図1ではTLSクライアント側での値を示しています。サーバ側では絶対値に多少の違いはあるものの、全体として大きな傾向は変わりません。

 

1)と2)は特定のTLSコンテクストで使用される共通情報を設定するステップです。このフェーズでは、メモリー容量としては使用される鍵や証明書のサイズが大きなファクターとなります。この例では、サーバ認証用の証明書だけが確保されています。実際の利用状況では、クライアント認証のための鍵、証明書を格納する必要がある場合もあります。

 

3)は、特定の相手方との通信を行うためのTLSセッションの管理エリアを確保します。この例では、1セッション分のエリアを確保していますが、同時に複数のセッションを扱う場合はその分だけのエリアを確保する必要があります。

 

4)は通信の相手方とのハンドシェークを実際に行うステップです。このステップではメモリー消費の観点からも公開鍵の大きな処理が行われます。

 

公開鍵処理の最適化についてはこのシリーズの第一回でも紹介したSingle Precision (特定鍵長)最適化が大きな効果を発揮します。ヒープ領域の使用量についてもこの最適化が大きな効果を示しますので、ここではその最適化を適用した場合の例をお見せしています。現在のwolfSSLのバージョンでは、ECCのP-256, RSAの1024, 2048, 3072ビットの各鍵長をサポートしていますが、それ以外の場合はこの最適化は適用できません。また、SP最適化はトレードオフとしてコードサイズが大きくなる傾向にあるので、ROMエリアに制限がある場合には注意が必要です。

 

 

 

図2はアプリケーションデータ転送時のヒープエリアの使用量の一例を示しています。アプリケーションデータ転送時には、公開鍵のようなヒープを多用する暗号化アルゴリズムは必要とされないため、暗号化処理に関するデータエリアは比較的小さくなります。

 

一方、データ転送のためのバッファエリアが大きなウェイトを占めることになります。TLSレコードはデフォルトでは最大16kバイトとなるため、wolfSSLでもデフォルトではそのサイズのバッファを確保することになるので、ヒープエリアが潤沢に利用で着ない場合は、このサイズを気にする必要が出てきます。

 

TLSではこの最大レコードサイズをプロトコル実行時に制限することができ、サーバ側が合意するならば、そのサイズを例えば4096、あるいは8196バイトなどの2のn乗バイトで指定することができます。wolfSSLでもこのオプションをサポートしており、利用する場合は ビルド時に –enable-maxfragment (あるいはHAVE_MAX_FRAGMENT)を指定し、実行時にwolfSSL_CTX_UseMaxFragmentまたはwolfSSL_UseMaxFragment にて実際のサイズを指定します。

 

この記事に関して、ご質問、あるいはご意見、ご希望などありましたら info@wolfssl.jp までお知らせください。

 

連載「WOLFの実力」を最新版から続けて読む
第一回:SP最適化でハンドシェイク所要時間を大幅削減
第二回:データ転送速度をさぐる
第三回:DTLSの実力(その1 DTLSの動作)
第四回:DTLSの実力(その2 性能編)

ルネサスセミナーオンデマンド「GR-Rose/RX65NでSSL/TLSのクイックスタート」

2020年5月26日に弊社が担当したルネサス社オンラインセミナーの録画版が公開されています。

    コンパイル環境にルネサス e2 studioを使い、wolfSSLとその簡単なサンプルプログラムのソースコードをコンパイル、ルネサスRX65Nを搭載した評価ボードGR-Roseの上で動作させました。自社製品にSSL/TLSあるいは暗号化機能の搭載を検討しているエンジニアの方々に、仕組みと使い方を約40分で紹介しています。

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

 

ルネサス社webinarで使用したGR-ROSEのデバッガ接続方法

先月担当したルネサス社のwebinarでは、実際にwolfSSLをコンパイルし、ルネサスRX65Nの載ったGR-ROSE上で動かしてみました。その際、時間の関係で触れられなかったデバッガの接続方法ががじぇるねで詳しく紹介されています。

 

GR-ROSE特設:デバッガを接続しよう
https://www.renesas.com/jp/ja/products/gadget-renesas/boards/gr-rose/project-connect-debugger.html

 

まとめ:セキュアブートに関する資料

セキュアブートに関する資料をまとめました。

 

 

    • wolfBootチュートリアル
      wolfBootを使ったセキュアブートとTLS 1.3ファームウェア更新 ―NXP社Freedom-K64F, FreeRTOSを例に-

 

 

ルネサス半導体オンラインセミナー「GR-Rose/RX65NでSSL/TLSのクイックスタート」

wolfSSLでは、5月26日(火)にルネサス エレクトロニクス社主催の半導体オンラインセミナーを担当いたします。

コンパイル環境にe2 studioを使い、wolfSSLとその簡単なサンプルプログラムのソースコードをコンパイル、RX65Nを搭載した評価ボードGR-Roseの上で動作させてみます。自社製品にSSL/TLSあるいは暗号化機能の搭載を検討しているエンジニアの方々に、仕組みと使い方を40分で紹介いたします。

日時: 2020年5月26日(火) 13:15 〜 14:00
参加費:無料(事前登録制)

詳細、お申し込みは、こちらをご覧ください。

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

 

連載「wolfの実力」 第四回:DTLSの実力(その2 性能編)

先月はDTLSの動作について紹介したので、今月はいよいよその性能について見ていきたいと思いますが、その前に先月紹介した動作に関して若干の復習です。ご存じの通り、UDPはその名の通りコネクションの概念のない、単発の手軽なパケットの送受信プロトコルです。DTLSはそのUDPに安全性を提供するわけなのですが、例えば、その安全性の重要な要素、なりすましを防止しようと思ったらどうしても通信相手の認証は避けて通れません。そんなこんなを考えると、結局DTLSも安全なセッションを確立するためにTLSとにたようなハンドシェークがあったり、TCPで実現しているのに近いようなパケットロスや順序性の確保といった処理が必要になってしまう、というようなお話を前回しました。

 

そういうわけで、DTLSの性能を見ていくと残念ながらUDPのような軽量さは失われてしまっていることがわります。我々ベンダの立場からは、安全性を損なわない範囲でどこまで軽量さを追求できるかが勝負所になります。

 

さて、前置きはそのくらいにして本題の性能について、wolfSSLの提供するDTLS1.2について、その処理時間に関する基本性能を見てみましょう。処理時間は、通信の冒頭で安全なセッション確立のために行われるハンドシェーク部分と実際にアプリケーションのデータを転送するペイロード転送部分の二つにわかれます。

ハンドシェークは、ペイロードのデータサイズにかかわらずほぼ一定の時間がかかります。

上のグラフはハンドシェークの処理時間をARM Cortex A7で実際にベンチマークし相対値に示したものです。本来ハンドシェークの実行時間にはUDP/IP以下の層のネットワークプロトコルの処理時間も含まれますが、このベンチマークでは同一のプロセッサ上にクライアント、サーバを置き通信させています。そのため、UDP/IP以下の層の処理時間はほぼゼロに近い処理時間となり、実質的にDTLSレイヤーの処理時間だけが抽出された形になります。

 

ハンドシェーク処理時間としては鍵交換(鍵合意)と通信相手の認証(署名検証)の時間が大半を占めます。グラフでは、鍵交換アルゴリズムとして従来型の有限体DH(FFDH)と楕円曲線DH(ECDH)、署名検証アルゴリズムとしてRSAとECDSAの二組の要素を三通りの組み合わせで比較しています。

 

処理時間には鍵長が大きく影響してきますが、このベンチマークでは現在通常用途にはおおむね十分な強度が得られるとされている鍵長、DH、RSA鍵には2048ビット、ECCには256ビットを使用しています。これらの比較では、従来型より楕円曲線によるアルゴリズムのほうがかなり高速に処理できることがわかります。

 

wolfSSLでは、これらの公開鍵処理のベースとなる整数演算部分にSP(Single Precision)最適化と呼ばれる最適化技術を導入しています。DTLSやTLSに使用される鍵長には種類はありますがいくつかに標準化されています。この鍵処理は特定の鍵長に着目すると大幅に処理時間を短縮することができます。その点に着目して代表的長さの鍵について最適化するのがSP最適化です。wolfSSLでは、現在(Version 4.4.0)RSA2048,3072,4096ビット、ECC256ビットについてSP最適化を提供しています。グラフの各アルゴリズムの左側が従来の処理、右側がSP最適化有りの場合を示しています。ご覧のようにSP最適化によって大幅に処理時間が改善されていることがわかります。

 

さて、次はペイロードの転送時間です。こちらのベンチマークもハンドシェークと同様に同一プロセッサでの転送時間を相対値で示しています。UDP/IP以下の層の処理時間は実質ゼロで、実質的にDTLSでの処理時間となります。ペイロードの処理時間は、概ね伝送データのサイズに比例しますので、ここでは1Mバイトあたりの処理時間をミリ秒で表示しています。

 

この部分の共通鍵暗号アルゴリズムとしては従来AES-CBCが広く利用されてきました。しかし、最近はこの暗号アルゴリズムとレコード単位のMAC値によるチェックを組み合わせただけでは改ざんのリスクがある点が指摘されており、AEAD(authenticated encryption with associated data)アルゴリズムの利用が推奨されています。しかし、一般的にはAEAD型の方は処理時間が増加してしまう欠点があります。グラフの右側のChacha20-Poly1305の組み合わせはAEADでありながらご覧のように従来の一般的なアルゴリズムよりも短い時間で処理できることを示しています。

 

以上、今回はDTLSの処理性能について紹介しました。この記事で紹介したベンチマークはwolfSSL製品やオープンソース版の中にも含まれていて、お客さま自身のターゲット環境でベンチマークを実行することができるようになっています。wolfSSLの通常のビルドが完了したら、下記のように、./examples/benchmarkディレクトリーのtls_benchプログラムを” -u”(DTLS指定)で実行してみてください。

 

./examples/benchmark/tls_bench -u

 

この記事に関して、ご質問、あるいはご意見、ご希望などありましたら info@wolfssl.jp までお知らせください。

 

連載「WOLFの実力」を最新版から続けて読む
第一回:SP最適化でハンドシェイク所要時間を大幅削減
第二回:データ転送速度をさぐる
第三回:DTLSの実力(その1 DTLSの動作)

セキュアブートについて知ってほしい10のこと

wolfSSLでは、長年にわたりお客様と共にセキュアブートソリューションを開発してきましたが、昨年、組み込みシステム向けに設計したセキュアブートローダであるwolfBootを製品としてリリースしました。

wolfBootは、最も一般的なアーキテクチャ(ARM Cortex-M、ARM Cortex-A、RISC-V RV32)をサポートし、様々なデバイス上でのリモートファームウェア更新に信頼性の高いサポートを提供します。

wolfBootはあらゆるタイプのRTOSと組み込みOSをサポートしており、FreeRTOS、Contiki、RIOT-OS、ChibiOS、ThreadX、VxWorks、QNX、TRON/ITRON/μITRON、MicriumのuC/OS、FreeRTOS、SafeRTOS、Freescale MQX、Nucleus、TinyOS、TI-RTOS、uTasker、embOS、INtime、MbedOS、Linuxなどのブートに使用することができます。

ここに、セキュアブートについて知っていただきたい10の事実を紹介します。

 

10. 信頼できるファームウェア更新は、既にIoTプロジェクトの必須要件に

IoTデバイスはサイバー攻撃を免れるわけではなく、誤った設定のシステムは容易に攻撃対象となると多くの実例で証明されており、時にはソフトウェアコンポーネントのたった一つの脆弱性から分散型システム全体を侵害される事さえあります。

残念ながら、脆弱性は起こるものです。ソフトウェアが完全に最初から書かれたものであっても、サードパーティのコンポーネントに依存しているものであっても、プロジェクトの最悪のタイミングで実装の欠陥が表面化する可能性があり、重要なシステムでは脆弱性のあるバージョンを実行し続ける猶予はありません。

wolfSSLは、セキュリティソフトウェアの開発者が決して安眠できないことを知っています。新しい脆弱性が発見されるとすぐに、チーム全体で修正プログラムの提供に集中し、すべてのテストを起動し、新しいバージョンのソフトウェアをリリースします。

ITサービスでは、ソフトウェアコンポーネントが更新され新バージョンが配信された直後に実行できる、継続的デプロイメントのメカニズムのメリットをすでに受けているケースが多く存在します。これは、古いソフトウェアを本番環境で実行することに関連するリスクを軽減する良い方法です。

なぜ、組み込みシステムで同様のメカニズムを広く利用できないのでしょうか?この質問はいくつかの側面があるため複雑です。市場で利用可能なマイクロコントローラの多様性は、組み込みシステムの開発者に非常に多くの課題を与えています。すべてのシナリオ、ユースケース、プラットフォーム固有のハードウェア、そして時には独自の通信インターフェースやプロトコルに適合するよう、統合メカニズムになっているためです。さらに、組み込みソフトウェアは、一般的にボード上の不揮発性メモリの物理コンテンツと1:1で対応する一枚岩の巨大なバイナリファイルでインストールされます。1つのコンポーネントだけを更新することは、特定のパーティション分割メカニズムで適切に配置されていない限り、単純にはできません。

安全なセキュアファームウェア更新メカニズムのガイドラインを定義する取り組みは、IETF内ではSUITワーキンググループが主導しており、問題を研究し標準ドラフトであるdraft-ietf-suit-architecture-08を作成しています。この文書では、要件をリストアップし、IoTデバイスに適したファームウェア更新メカニズムのアーキテクチャを説明しています。

 

9. 公開鍵署名認証を使用して更新を検証

SUIT の定義に従った安全なブートローダが持つ特徴は、現在のファームウェアとリモートソースからの更新の真正性を保証するために、最新の暗号技術を使用する点です。公開鍵ベースの認証を使用することで、実行する前にボード上のすべてのソフトウェアを検証することが可能です。

メカニズムは非常に単純で、デバイスの所有者が鍵ペアを作成します。秘密鍵は秘密であり、決して公開されたり、デバイス自体に保存されることはありません。秘密鍵は、スクリプトまたはプログラムによってマニフェストヘッダに署名するために使用され、新しいソフトウェアのバイナリイメージと一緒に送信されます。マニフェストヘッダには、ファームウェアイメージに関連するすべてのメタデータが含まれています。

ブートローダは公開鍵のコピーにアクセスすることができます。公開鍵のコピーはボード上の不揮発性メモリや、特定のハードウェアの安全な保管庫に保存されています。公開鍵は秘密ではありませんので、公開されてもセキュアブートプロセスにリスクはありません。

ブートローダは更新パッケージを受け取ると、公開鍵を使って検証を開始します。検証可能な署名を含む有効なメタデータがあるソフトウェアのみがターゲットデバイス上での実行を許可されます。

 

8. 小さなブートローダでの運用

セキュアブートローダは、多くの場合、組み込みシステムの唯一の不変部分です。SUIT の仕様では、信頼性にリスクをもたらす可能性があるため、一般にブートローダ自体はアップデートされないことを前提としています。このため、セキュアブートローダを実装するための要件の 1 つは、ブートローダは小さく保ち、システム内の他のコンポーネントをファームウェアイメージの転送と更新の実行に割り当てることです。

これは、必要なレベルの信頼性を保証し、攻撃対象領域を最小限に抑えるために、ブートローダーではコードの安全性が大変重要であることも意味しています。パーサが不具合を出しやすい場所とされているため、SUIT では特に、パーサは小さくと義務付けています。

この方向性をさらに一歩進めると、ブートローダのコードでの動的メモリ割り当ては完全に回避ということになります。コンパイル時にメモリ使用量を測定し、すべてのデータ構造に静的バッファを割り当てることで、不適切なメモリマッピングが設定されている場合に、セクションの重複やヒープスタックの衝突などのメモリ管理の不具合が発生する可能性を大幅に減らすことができます。

セキュアブートローダの実装では、リソースと安全関連の要件の両方を無視できません。そうしないと、より大きな問題を起こしてしまう危険があるからです。

 

7. ロールバック攻撃

継続的な脆弱性管理の観点から、新しいアップデートは頻繁にリリースされ、利用可能になるべきです。ファームウェアイメージがTLSなどの安全なチャネルを使用して転送されない限り、古いアップデートが攻撃者、またはファームウェアを利用するデバイスへのトラフィックを盗聴している誰かによって傍受されるリスクは常にあります。

これは、例えば、ファームウェアイメージがセキュアソケット通信をサポートしていないローカルメッシュネットワークを通して配布されている場合など、ブロードキャストに適した環境では特に当てはまります。

攻撃者が以前のバージョンの脆弱性を知っていた場合、ネットワーク上の盗聴によって以前に記録されたファームウェアイメージの送信を繰り返すことにより、ターゲットデバイスのファームウェアを特定のバージョンにダウングレードしようとする可能性があります。

セキュアブートメカニズムは、ファームウェアバージョンに関する情報を、マニフェストヘッダー内の他のすべての情報とともに保持する必要があります。

バージョン番号は、残りのメタデータと同様に、署名プロセス中にファームウェアイメージと一緒にエンベロープに入ります。つまり、攻撃者は更新パッケージの署名の有効性を損なうことなくバージョン番号を改ざんすることはできません。ブートローダは、現在システム上で実行されているバージョンよりも古いバージョンのパッケージをインストールすることを許可しません。

ロールバック攻撃は非常に簡単に実行でき、これを防ぐことはセキュアブートローダの重要な仕事です。

 

6. 停電と高信頼性

マーフィーの法則によれば、「失敗する可能性のあるものは、失敗する」のだそうです。リモートアップデートのインストールの場合、電源が落ちたり、システムがリセットされるようなハードウェアの不具合が発生する最悪のケースは、ファームウェア更新のインストール中に不揮発性メモリの内容が変更された場合です。FLASH セクタのコピー操作の途中で電源が切れると、次の起動時にコピー先のセクタの状態が予測できなくなります。

wolfBoot で実装しているように、常に同じセクターのコピーを二つ持つようにしておき、各ステップが完了したことをフラグで確認する仕組みを使うことで、このような事態を防ぐことができます。再起動時には、最後に成功した操作から操作を再開することができるので、システムが回復不可能な状態になるリスクはありません。

 

5. セキュアブートと安全なアップデート転送

新しいバージョンのダウンロードは、組み込みアプリケーションのタスク、またはRTOS上で実行されるスレッドです。SUITで示されているように、ブートローダーコードにファームウェアイメージを転送する任務を含めると、プロトコルスタックの実装とプラットフォーム固有のデバイスドライバーに外部依存する、より大きく複雑なセキュアブートローダになってしまいます。実際、組み込みシステムは、利用可能なさまざまな接続技術からネットワークにアクセスすることができます。これらのテクノロジーのすべてが同じプロトコルファミリやトランスポートメカニズムを共有しているわけではありません。LPWANのような低消費電力通信プロトコルの中には、帯域幅やネットワークの可用性に関する要件がさらに厳しくなっている場合もあります。

wolfSSLは、組み込みシステム向けの組み込みSSL/TLSライブラリです。トランスポート層に依存しないため、あらゆる種類のデータ転送テクノロジーやオペレーティングシステム、ベアメタルアプリケーションの上で安全なソケット通信を提供することができます。

接続の安全性を確保するために最新のTLS 1.3を使うことは、現在までに標準で利用可能な最高の暗号技術を利用し、デバイス同士で通信したり、エンドツーエンドの安全なチャネルでバックエンドと通信できることを意味します。

TLS を使用して移動中のすべてのデータを保護することの利点には、2 つのエンドポイント間で転送されるすべてのデータを暗号化することはもちろんのこと、データ、サービス、またはリモートファームウェア更新にアクセスするクライアントのために、オプションとしてサーバー側の識別があります。

TLS ソケット通信を含むスタック全体がデプロイされているシステムでは、ファームウェアイメージの転送は同じチャネル上で行えるため、更新パッケージはファームウェアの利用者まで安全にネットワークを移動することが可能です。

利用可能なリソースが非常に限られたデバイスのサブセットにとっては、TLSは選択肢にならないかもしれないので、そのようなデバイスでは少なくとも暗号化を検討する必要があります。

wolfCryptは、組み込み、RTOS、リソース制約の厳しい環境を​​対象とする暗号化エンジンで、wolfSSLのコアコンポーネントですが、単独のライブラリとして使用して、ほとんどすべての一般的なアルゴリズムや暗号実装を使うことができます。

 

4. 鍵管理とトラストアンカー

リモートファームウェアアップデートのために設計された分散システムアーキテクチャでは、 鍵管理は重要なタスクです。バックエンドシステムは、秘密鍵を安全に保ち、新しいバージョンが利用可能になったときに、ファームウェアの利用者に配布するための署名付きパッケージを生成する役割を担っています。

wolfBoot はこれらのタスクを容易にするために、サーバ側に簡単に統合できる鍵管理スクリプトやユーティリティのツールボックスとともに提供されています。

最も単純なケースでは、更新パッケージに含まれる署名は、デバイスの所有者がアクセス可能な秘密鍵を使って取得されます。

より複雑なキープロビジョニングシステムが使われているケースもあります。別個のソフトウェアまたはハードウェアコンポーネントが署名ステップを実行している場合、パッケージ作成プロセスを分割して、DSA ステップを別のコンポーネントにリダイレクトおよび委任することができます。

リモートのファームウェア更新の有効性に対する信頼は、デジタル認証に使用される公開鍵の完全性に依存するため、組み込みシステムの内部に格納されている公開鍵は「トラストアンカー」とみなされます。

トラストアンカーの管理は、ハードウェアプラットフォームに依存するため、一般的にはブートローダの範囲外です。しかし、デバイスに保存され、ファームウェアの真正性を検証するために使用する公開鍵が危殆化するリスクに対して、適切な防御を施すことはブートローダにとって極めて重要です。

トラストアンカーの保管場所は、ハードウェアで利用可能な対策を用いて、書き込みアクセスから保護する必要があります。

 

3. セキュアエレメントとトラストアンカーの格納

トラストアンカーやその他の暗号化マテリアルを保護する最善の方法は、この目的のために設計された ハードウェアコンポーネントを使用することです。ハードウェアセキュリティモジュール(HSM、CAAMなど)は通常、同じモジュール内で鍵ストレージと暗号演算の高速化の両方を担います。wolfBootを動かす当社の暗号エンジンであるwolfCryptは、この機能にアクセスできる全スキームをサポートしています。その中にはメーカー固有の様々なAPIがあり、Microchip ATECC608AARM CryptoCellNXP CAU/mmCAU/LTCSTMicroelectronic PKAなどを含みます。

最近、セキュリティ暗号化プロセッサへのアクセスに使用されるプロトコルを作る取り組みとして、ISO / IECがTPM(Trusted Platform Module)形式を標準化しました。TPMは現在ほとんどすべてのPCやノートブックで使用されています。

TPM 2.0互換のセキュアエレメントにアクセスするためのAPIを提供するライブラリであるwolfTPMにより、同じテクノロジーが組み込みシステムでも利用できるようになりました。wolfTPMがサポートする一般的なTPMデバイスには、ST33やInfineon 9670などがあります。

wolfBootは、オプションでwolfTPMと一緒にコンパイルして、これらのデバイスが提供するセキュアな鍵ストレージや暗号化アクセラレーションを利用することもできます。

 

2. ブートローダの更新

ブートローダはそれ自身を更新するための信頼できる方法を実装することが本質的に複雑であるため、SUIT が提案している標準では、この小型のブートローダ部分は不変であることを推奨しています。ただし、ブートローダのコード自体を更新できる可能性があると便利なケースもあります。

公開鍵がブートローダのコードに組み込まれていて、鍵のプロビジョニングは単一の秘密鍵に依存していて、この秘密鍵がバックエンドで危険にさらされている状況がそのケースです。

もう1つのケースは、長寿命の製品で、ブートローダのコードで現在使用されているアルゴリズムや鍵長が、長年の研究によって古くなっていたり、危殆化が判明している場合です。

数年後には、新しい要件に合わせてブートローダのコードを更新する必要が生じるかもしれません。このような理由から、ブートローダコードを更新できるようにすることは重要だと考えています。wolfBootはこのオプションをサポートするようコンパイルすることができます。wolfboot self-update とマークされた特別な更新パッケージは、パッケージ自体の検証が成功した後、ブートローダ自身のコードを上書きします。

ブートローダ自身の更新プロセスは、固有のハードウェアの制約によるため完全にフェイルセーフではありませんが、上記のような緊急の場合に使用するには十分に頼りになります。

 

1. 開発工数の見積もり

セキュアブートとリモート更新を考える際、この単一のタスクがプロジェクト全体の開発サイクルに与える影響を過小評価してしまうことがよくあります。デバイスがデプロイされたときに起こりうるすべてのケースでシステムの信頼性を保証するには、多大な労力が費やされます。

ブートローダは、おそらくシステムの中で最もクリティカルな部分です。リモートで更新する方法が残っている限り、アプリケーションの他のすべてが壊される可能性があります。特定のプロジェクトのために1からセキュアブートローダを実装するのは、場合によってはシステム内の残りのソフトウェアコンポーネントと同じくらいの開発とテストを必要とする大変な作業です。

弊社のお客様がセキュアブートやリモート更新を構築することをサポートしてきた経験を活かし、私たちはwolfBootを設計しました。wolfBootは、あらゆるセキュアブートのアーキテクチャ要件を満たす基本的なビルディングブロックとして利用できる強固なプラットフォームを提供します。

私共は、リモート更新のためのセキュアブートソリューションに対し、wolfSSLグローバルチームによる商用サポートを提供しています。セキュアブートへの365日年中無休のサポートを提供する唯一の会社です。

wolfSSL Japan合同会社の技術サポートセンタでは、様々な組み込みシステムとの統合を実現すべく、日本人専任スタッフによるサポートサービス、カスタマイズサービスなどを提供しています。お問い合わせ、ご質問は info@wolfssl.jpまでご連絡ください。

原文: https://www.wolfssl.com/top-ten-things-know-secure-boot/

Posts navigation

1 2 3 4 33 34 35