うるふブログ

wolfSSL 4.4.0をリリースしました

wolfSSLの新バージョン、v4.4.0をリリースしました。このリリースには多くの新機能、最適化、不具合修正を含んでいます。

wolfSSL組み込みSSL / TLSライブラリに追加した新機能の一部を紹介します:

  • Qualcomm Hexagon SDKのサポート
  • ECC検証操作をオフロードするDSPビルド
  • 証明書マネージャーのコールバックサポート
  • ChaCha20 / Poly1305 AEADの更新を実行するための新しいAPI
  • Apache Webサーバーでの使用をサポート
  • IBM s390xのサポート
  • ED25519のPKCS8サポート
  • OpenVPNのサポート
  • Single PrecisionでP384曲線をサポート
  • BIOおよびEVP APIの追加
  • AES-OFBモードの追加
  • AES-CFBモードの追加
  • Curve448、X448、およびEd448の追加
  • Renesas Synergy S7G2ビルドとハードウェアアクセラレーションの追加

完全なリストについては、ダウンロードREADMEを確認ください。

ご質問は support@wolfssl.com までご連絡ください。

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

 

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

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

 

 

    • 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/

wolfTPM 1.8.0をリリースしました

wolfTPM 1.8.0をリリースしました。こちらからダウンロードいただけます。

このリリースには、ザイリンクス社Zynq UltraScale+ MPSoCの新しいプラットフォームサポートとLinuxユーザー向けの新しいオペレーティング環境サポートを含んでいます。Nuvoton NPCT650とNationsTech Z32H330の2つのTPMモジュールでテストを実施しました。

Linuxでの新しいアプリケーションに必要な時間を短縮するために、Linux TISカーネルドライバー (“/dev/tpm#”)のサポートを追加しました。これにより、LinuxでwolfTPMを使用するアプリケーションがLinux TPMツールと共存できるようになります。また、追加のシステム構成を必要とせずに、ユーザーが既存のLinux TPMモジュールとLPCバスサポートを活用しやすくなります。

デフォルトのビルド動作では、HAL IOコールバックを介して“/dev/spidev#.#”を直接使用します。“/dev/tpm#”サポートを有効にするには、“./configure –enable-devtpm” ビルドオプションを使用します。

またこのリリースでは、TLSの暗号コールバックサポートに関するいくつかのビルドの問題も解決し、ECCプライマリストレージルートキーの使用例を追加しています。

さらに詳しい情報は弊社問い合わせ窓口 info@wolfssl.jp までご連絡ください。
原文: https://www.wolfssl.com/wolftpm-v1-8-release/

wolfBoot 1.5をリリースしました

wolfBootバージョン1.5をリリースしました。こちらからダウンロードいただけます。

このリリースには次の新機能を含んでいます。

・ファームウェアイメージのSHA-3ダイジェストのサポート
・RSA-4096署名認証のサポート
・新しいアーキテクチャ(ARMv8 64ビット)のサポート
・新しいデバイスとプラットフォームのサポート(LPC54xx、raspberry pi、Xilinx Zynq)
・MS Windows環境での開発エクスペリエンスの向上
・UART経由の仮想ストレージ

 
wolfBootは、ARM Cortex-A CPUに基づく組み込みLinuxシステムの起動プロセスをセキュアにできるようになりました。お使いのプラットフォームにwolfBoot を統合することで、信頼できるファームウェアアップデートのサポートが追加できます。新しいブートプロシージャでは、ブートステージ間で特権を分離するためにARM TrustZoneを使用しているシステムのすべての実行レベルをサポートしています。

wolfBoot 1.5では、UARTを使用してアクセスできる隣接システムに仮想アップデートパーティションを設定できるようになりました。この機能を説明するためのサンプルコードもこの度追加しています。

IAR を正式にサポートし、コンパイルと鍵管理ツールの統合を容易にする Visual Studio ソリューションを統合することで、Windows 環境での開発者エクスペリエンスを改善させています。組み込みシステムへのセキュアブートの統合は、このリリースでさらに簡単になります。

詳細については、リリースノートをご確認ください。

さらに詳しい情報は弊社問い合わせ窓口 info@wolfssl.jp までご連絡ください。
原文: https://www.wolfssl.com/wolfboot-1-5-release/

wolfSSH 1.4.4をリリースしました

wolfSSH 1.4.4をリリースしました。こちらからダウンロードいただけます。

デバイス、IoT、クラウド向けの組み込みSSHライブラリであるwolfSSHの最新版リリースには、次の内容を含んでいます。

wolfSCPクライアント – SCPクライアントツールのサンプルとしてwolfSCPを加えました。2つのエンドポイント間で単一のファイルまたはディレクトリをコピーするために使用できます。

VxWorksのサポート – wolfSSHをコンパイルして、Wind River Systems社のRTOS、VxWorks で実行できるようになりました。 特別な設定は必要ありません。コンパイルして実行するだけです。

最新版リリースはこちらからダウンロード可能です:  https://www.wolfssl.jp/download/

wolfSSH製品ページ: https://www.wolfssl.jp/products/wolfssh/

さらに詳しい情報は弊社問い合わせ窓口 info@wolfssl.jp までご連絡ください。
原文: https://www.wolfssl.com/wolfssh-1-4-4-now-available/

wolfSSL FIPS Ready 4.4.0をリリースしました

wolfSSL FIPS Ready 4.4.0をリリースしました。こちらからダウンロードいただけます。

現在計画中、開発中の御社製品が、米国政府機関、またはFIPS認証を必要とする機関に利用される可能性はおありですか?
可能性はあるが時期や必要性まではわからない場合にお勧めの製品として、wolfSSL FIPS Ready版を用意しております。

wolfSSL FIPS Ready版とは:
wolfSSL FIPS Ready版は、wolfSSLソースツリーに含まれるwolfCrypt FIPS対応の暗号化レイヤーのコードです。 wolfSSL FIPS Ready版を使用するとFIPSモジュールに付属する強化されたすべてのセキュリティ機能を利用できますが、FIPSを要求されるお客様がいると確信できるまで、証明書を取得する必要はありません。

wolfSSL FIPS Ready版には、どのような制限がありますか?
wolfSSL FIPS Ready版を使用するだけではFIPS認証は取得できませんが、御社のお客様から要望があった際、すぐに認証を受ける準備ができます。 FIPS ReadyとはビルドにFIPSコードが含まれていることを意味し、初めからFIPSの必要要件に沿って開発をしていることになり、暗号モジュールのコード整合性チェックが入り、セルフテストにより適切な暗号化機能を確保していることになります。FIPS認証の取得は、必要になったタイミングで、御社でお使いの特定の運用環境でのテストと検証のプロセスに進むことが可能です。すべてのコーディングは事前に完了しているため、検証プロセスは大幅に高速化できます。

今日から導入できますか?
はい。wolfSSLのソフトウェアは、オープンソースと標準的な商用ライセンスの二つのライセンスモデルで提供しております。御社製品での適用に当たるご評価には、wolfSSL FIPS Readyオープンソース版(GPLv3ライセンス)が本日よりご利用いただけます。オープンソース版には標準商用版の内容がすべて含まれていますので、ご契約以前に十分調査、検討をいただいた上で商用ライセンス契約をいただくことができます。オープンソース版ご評価中のご不明な点、お困りの点など技術サポートについても遠慮なく弊社窓口にお問い合わせください。基本的な評価が完了して御社製品でご利用をご計画の際には、商用版のご契約をお願いします。

wolfssl-4.4.0-gplv3-fips-ready.zipのコピーは、wolfSSL Webサイトのダウンロードページからダウンロードいただけます。

さらに詳しい情報は弊社問い合わせ窓口 info@wolfssl.jp までご連絡ください。
原文: https://www.wolfssl.com/wolfssl-fips-ready-4-4-0-now-available/

wolfMQTT 1.6.0をリリースしました

wolfMQTT 1.6.0をリリースしました。こちらからダウンロードいただけます。

このリリースは、ユーザエクスペリエンスの改善と不具合の修正にフォーカスしています。マルチスレッド機能は徹底的にテストを行い、報告されたいくつかの同期問題を修正しています。また、単純に単独で機能するMQTTクライアントのサンプルを追加し、IoTデバイスがブローカーサービスと通信できるようにするために必要な最小限のAPIを示しました。

変更ログはこちらをご覧ください:https://github.com/wolfSSL/wolfMQTT/blob/master/ChangeLog.md

最新版リリースはこちらからダウンロード可能です:  https://www.wolfssl.jp/download/

wolfMQTT製品ページ: https://www.wolfssl.jp/products/wolfmqtt/

さらに詳しい情報は弊社問い合わせ窓口 info@wolfssl.jp までご連絡ください。
原文: https://www.wolfssl.com/wolfmqtt-release-v1-6-0/

Posts navigation

1 2 3 4 36 37 38