うるふブログ

連載:wolfの仲間たち 第三回:安全なリモートコンソールwolfSSH

連載第三回は、wolfの仲間たちのなかでもやや地味目なwolfSSHを紹介しましょう。wolfSSHはその名の通りSSHプロトコルで組込デバイスとコマンドコンソールの間の安全な通信機能を提供します。これまでtelnetのように保護されない通信で実現していたリモートコンソール機能をそのままに、開かれたネットワークであっても安全な通信が確保される環境に移行するというような用途に最適な製品です。

wolfSSHはサーバーまたはクライアント、どちら側としても機能しますが、まずは代表的なサーバー側としての利用場面で説明しましょう。wolfSSHはサーバーとして組込デバイスの上で動作します。コンソールの役割を果たすクライアント側はパソコン上のTera Term、PuTTYと言ったような既存のターミナルエミュレータを利用することができます。この場合wolfSSHは、ターミナル側からのサーバー認証や鍵やパスワードによるユーザー認証、そして確立したSSH接続を使った安全なストリーム通信をアプリケーションに提供します。デバイス側のアプリケーションは、ターミナルからのコマンドなど、ストリームの内容によってデバイスの状態表示や、指示された設定をするなどの役割を担います。


【wolfSSHの構成例】

wolfSSHのクライアント機能は、今の例と逆のパターンで使用することができます。例えば、SSHサーバーの組み込まれた制御装置などを小さな組込デバイスから監視、制御したい場合などにデバイス側にクライアントとしてのwolfSSHを組み込んで使用します。

SSHのプロトコルはインターネットの標準化団体IETFのRFCに準拠したプロトコルを実現しています。このプロトコルはSSL、TLSとは若干違っているので、製品の組み合わせとしては、wolfSSLではなくwolfCryptを組み合わせて使用することになります。おなじSSH系のプロトコルを使用するものとしてファイル転送のSFTPやSCPがありますが、wolfSSH製品の中にはこれらのファイル転送機能も含まれていて必要に応じて利用することができるようになっています。

wolfSSHの製品詳細はこちらでご紹介しています。

連載:wolfの仲間たち
第一回:全員集合
第二回:安全なファームウェア更新を支えるwolfBoot

 

wolfSSHについてさらに詳しい情報は、弊社問い合わせ窓口 info@wolfssl.jp までご連絡ください。

 

 

wolfTips: デバック用オプション

メモリ使用状況が気になりますか?

wolfSSLには、多くのオプションスイッチがあります。その中には、事前に知っておくとその後のデバック効率が向上するものがあります。
今回はデバック時に有効なメモリ使用状況に関するオプションを紹介します。

使用方法は、configure にオプション “–enable-trackmemory” を指定し wolfSSL をビルドします。
$./configure --enable-trackmemory

マクロ定義を使用する場合は、WOLFSSL_TRACK_MEMORY を定義します。

後は、アプリケーション・プログラムの開始時に
InitMemoryTracker()
を呼び出し、メモリ使用状況を確認したい箇所で
ShowMemoryTracker()
を呼び出します。ShowMemoryTracker()は複数個所で呼び出しを行って構いません。メモリ使用状況を逐次確認するということも可能です。追加情報とし、これらの関数の呼び出しは、wolSSL_Init()及びwolfSSL_Cleanup()でそれぞれ自動的に行われます。

出力例は下記の通りです。

current Bytes に注目することでメモリリークの検出にも使用できます。

例として wolfSSL に同封されるtestwolfcrypt プログラムを “–enable-trackmemory” を指定しビルド・実行してみて下さい。

$ ./wolfcrypt/test/testwolfcrypt
error test passed!
base64 test passed!
asn test passed!
MD5 test passed!
……………
mutex test passed!
memcb test passed!
Test complete
total Allocs = 1445
total Deallocs = 1445
total Bytes = 4321945
peak Bytes = 71296
current Bytes = 0

“current Bytes = 0”。もちろんメモリリークしていません。

今回紹介したように wolfSSL ではアプリケーションのデバック作業効率を向上できるオプションがあります。個別環境でのデバック方法、特定の問題に対するデバックなどご質問ありましたらお気軽にsupport@wolfssl.com までお知らせください。

wolfSSHのメモリー使用量

wolfSSLは多くの製品を提供していますが、そのうちの1つがwolfSSHライブラリです。 wolfSSH自体は軽量の組み込みSFTPソリューションを提供します。 SFTPは、ファイルを安全に転送し、通信相手のファイルシステムを管理するために使用できます。 wolfSSHによるSFTPの実装は、OpenSSHがSFTP接続に使用するメモリの3分の1以下で動作させることができます。次の図は、OpenSSHのパフォーマンスと比較したwolfSSHのSFTPソリューションのメモリ使用量の概要を示します。

コンフィグレーション:wolfSSH v1.3.0 にて
” ./configure –enable-static –disable-shared –enable-sftp CFLAGS=”-DDEFAULT_WINDOW_SZ=4096″ “:

 

比較すると、システムのデフォルトのOpenSSH SFTPでは103 KiBのメモリを使用していました。
“ OpenSSH_7.2p2 Ubuntu-4ubuntu2.6、OpenSSL 1.0.2g”:

wolfSSHに関してさらに詳細の情報は、info@wolfssl.jp までお問い合わせください。
また、wolfSSLではTLS1.3をサポートしています。詳細についてはhttps://www.wolfssl.jp/product-wolfssl-tls1-3/をご覧ください。
 

wolfSSL 4.0.0をリリースしました

桜の季節に、wolfSSL組み込みTLSライブラリ新バージョンのリリースが間に合いました。今回、メジャーバージョンアップとなるwolfSSL 4.0.0の最大の変更点は、FIPS 140-2認証に関する次の3点です。

  1. FIPS用wolfCryptがTLS1.3の暗号スイートに対応し、FIPS認証のTLS1.3が実現
  2. FIPS用wolfCryptのソースコードをこの度初めてオープンソース版に
  3. FIPS認証取得に向け、オープンソース版のFIPS用wolfCryptで調査、検討が可能に(FIPSレディー版)

FIPS版の詳細については、https://www.wolfssl.jp/license/fips/を参照してください。

wolfSSLバージョン4.0.0に追加された機能:

  • wolfCrypt FIPS v4.0.0のサポート、証明書#3389
  • FIPSレディー版
  • サーバーサイドの安全なTLS再ネゴシエーションを追加
  • TLS Trusted CA拡張を追加
  • Deos Safety Critical RTOSのサポート
  • TLSハンドシェイクが秘密鍵のPKCS#11使用をサポート
  • HMAC、AES-CBC、ランダムシード/生成のPKCS#11サポート
  • TLS 1.2(RFC 7919)での名前付きFFDHEパラメータのサポート
  • ハードウェア暗号化アクセラレーションを使用したEspressif ESP32 WROOMのサポート
  • サイプレスWICED Studioのサポート
  • ARM CMSIS-RTOS v2のサポート
  • Zephyrプロジェクトへのポーティングを追加
  • 単精度(SP)演算用のCortex-Mのサポート
  • wolfCrypt RSAノンブロッキングタイムをサポート
  • --enable-16bitオプションを使用した16ビットコンパイラサポート

このリリースで 追加されたポーティングとサポートに関しては、今後wolfSSLブログでより詳細な内容を ご紹介していく予定です。

wolfSSL 4.0.0での修正、アップデート、全般的な改善:

  • 特定のVisual Studioビルドで使用するためのsnprintf用の新しいラッパーを追加
  • サポートするPEMヘッダータイプにECC_PUBLICKEY_TYPEを追加
  • ECDSA署名DERエンコーディング長の厳密なチェックを追加
  • client_hello内のsig / algosを USE_ECDSA_KEYSZ_HASH_ALGOでの鍵長に制限するECDSAオプションを追加
  • Chromeとの安全な再ネゴシエーションのための互換性修正
  • TLSレコードフラグメント再構成のためのサイズチェックの改善
  • DTLSのノンブロッキングおよびハンドシェイクメッセージ再試行サポートの改善
  • ECDSA署名者によるOCSPの改善
  • メモリ管理と初期化のためのOCSP修正
  • EVP暗号解読パディングチェックの修正
  • wolfSSL_X509_print部分文字列のnullターミネーターの削除
  • wolfSSL_sk_ASN1_OBJCET_pop関数を wolfSSL_sk_ASN1_OBJECT_popに改名
  • evp.hとobjects.hの互換レイヤーにパスを含めるように調整
  • BERエンコードされたPKCS7コンテンツをデコードするための修正
  • TLS PRFをwolfCryptに移動
  • CMS KARIサポートのアップデート
  • OpenSSL互換レイヤーへの修正と追加
  • Xcodeプロジェクトファイルの更新
  • ATECC508A / ATECC608Aに対する修正
  • 自己署名ルートCAのCAパス長に関する問題修正
  • ソースを直接ビルド するときの単精度(SP)ASMの修正
  • STM32 AES GCMに対する修正
  • 入力が確実に切り捨てられるようハードウェアでのECC署名の修正
  • PKCS7バッファオーバーフローを正しく検出するための修正
  • BERエンコーディングでの証明書縮退PKCS 7を処理するための修正
  • 6144および8192ビット鍵のTLS v1.3での処理の修正
  • SafeRTOSで起こりうるビルドの問題に対する修正
  • Arduinoスケッチの例の改善
  • 暗号コールバック機能の改善
  • TLSベンチマークツールの改善

なおtls_bench.cサンプルテストアプリケーションで指摘されていた問題(CVE-2019-6439)は、このwolfSSL 4.0.0で解決しています。
(ライブラリの暗号化部分やTLS部分とは関係しません。)

wolfSSLの安定版リリースはこちらからダウンロード可能です:https://www.wolfssl.jp/download/
最新のwolfSSLライブラリをダウンロード、表示するには、wolfSSL GitHubリポジトリからクローンいただけます。https://github.com/wolfssl/wolfssl.git

 

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

wolfSSLのESP32ハードウェアアクセラレーションサポート

この度、組み込み向けTLS/SSL ライブラリ wolfSSL は、Espressif ESP32-WROOM-32 ハードウェアアクセラレーションサポートを公開しました。

ESP32-WROOM-32 は、Wi-Fi、Bluetooth、電源管理やその他のシステム機能が備わっています。wolfSSL は移植性が高く、ESP32-WROOM-32は非常に柔軟である為、簡単にwolfSSLをポーティング可能です。

新しい wolfSSL ESP32-WROOM-32 ポーティング機能は、既存の ESP-IDF ポーティングに追加される形で提供されます。ESP32-WROOM-32 ハードウェアアクセラレーション機能は、WOLFSSL_ESPIDF 定義に加え、WOLFSSL_ESPWROOM32 又はWOLFSSL_ESPWROOM32SE 定義を settings.h で有効にすることで利用可能になります。

ベンチマーク結果を含む詳細については、/wolfcrypt/src/port/Espressif/ ディレクトリ内にあるREADME.md をご覧ください。

ESP32上のハードウェアアクセラレーション及び Microchip 社 ATECC608A のサポートはコードサイズ削減と同時にパフォーマンス向上を提供します。ベンチマークと比較グラフは下記のWebページから参照可能です:

https://www.wolfssl.com/docs/espressif/

wolfSSL のマスターブランチはこちらにあります:

https://github.com/wolfSSL/wolfssl

 

ESP-IDFポーティングに関するREADME はこちらから参照ください:

https://github.com/wolfSSL/wolfssl/blob/master/IDE/Espressif/ESP-IDF/README.md

ESP32ハードウェアアクセラレーションに関する README はこちらから参照ください:

https://github.com/wolfSSL/wolfssl/blob/master/wolfcrypt/src/port/Espressif/README.md

ESP32-WROOM-32SE のデモプログラム関する README はこちらから参照ください:

https://github.com/wolfSSL/wolfssl/blob/master/IDE/Espressif/ESP-IDF/README_32se.md

 

ESP32ハードウェアアクセラレーションについてさらに質問などありましたら、support@wolfssl.com まで日本語でご連絡ください。

 

参考資料:

ESP32-WROOM-32 Overview: https://www.espressif.com/en/products/hardware/esp-wroom-32/overview

wolfTips: OpenSSL 互換APIを使いこなす

OpenSSL資産をムダにせず活用できます!

wolfSSLは、インプリメンテーション依存による脆弱性などを最小限にするためにクリーンルームによる独自開発のSSL/TLSライブラリです。一方で OpenSSL 互換の API も提供し既存の OpenSSL ユーザにも簡単にアプリケーションが開発できるように設計されています。ほかにも多くのオープンソースアプリケーションはOpenSSL 互換 API を使用し動作しています。

今回は、この wolfSSL のOpenSSL互換APIの使い方を紹介します。

1.wolfSSLライブラリのビルド

デフォルトで wolfSSL ライブラリのビルドシステムは、OpenSSL 互換 API を無効にしています。OpenSSL互換APIを有効にするには、configure で”–enable-opensslextra”オプションを指定します。

$./configure --enable-opensslextra
“–enable-opensslextra” 以外に、”–enable-opensslall”というオプションが指定可能です。”–enable-opensslall”オプションは、wolfSSL でサポートしている OpenSSL 互換API を使用頻度の低いものも含めて有効化します。

 2.アプリケーションのビルド

OpenSSL APIを使用するアプリケーションをwolfSSL OpenSSL互換APIを用いてビルドするには gcc の場合以下のオプションを指定して行います。

  • ヘッダーファイルパスに wolfSSL ヘッダーファイルのインストール先を指定します。
    gcc の場合:
    -I /path/to/wolfssl/wolfssl -I /path/to/wolfssl
  • wolfssl/openssl/ssl.hをincludeオプションを使用し、直接インクルードします
    -include wolfssl/options.h
  • wolfSSLライブラリをリンクします。
    gcc の場合:
    -lwolfsslを指定します。

次のプログラムはTLSサーバに接続し、”Hello”を送信するだけの簡単なOpenSSL API 使用のサンプルです。ソースコードを変更することなく wolfSSL ライブラリと共に動作させることができます。

/* simplified echoclient wolfSSL and OpenSSL */
#include <openssl/ssl.h>
#include <openssl/err.h>
#include "echoclient.h"

void hello_test()
{
    const char* msg = "Hello SSL!\n";
    SSL_CTX*    ctx = 0;
    SSL*        ssl = 0;
    int ret = 0, err = 0;
    int sendSz;
    char buffer[MAX_ERROR_SZ];
    int sockfd = socket(AF_INET, SOCK_STREAM, 0);
    struct sockaddr_in servaddr;

    /* server information */
    memset(&servaddr, 0, sizeof(servaddr));
    servaddr.sin_family = AF_INET;
    servaddr.sin_port = htons(11111);
    servaddr.sin_addr.s_addr = inet_addr("127.0.0.1");

    /* init library */
    SSL_library_init();
    /* create a new CTX */
    ctx = SSL_CTX_new(SSLv23_client_method());
    /* set default locations for trusted CA certificates */
    if (SSL_CTX_load_verify_locations(ctx, caCertFile, 0) != SSL_SUCCESS)
        printf("can't load ca-ecc file.\n");    
    /* create a new SSL structure for a connection */
    ssl = SSL_new(ctx);
    /* connect socket */
    connect(sockfd, (const struct sockaddr*)&servaddr, sizeof(servaddr));
    /* connect the SSL object with a file descriptor */
    SSL_set_fd(ssl, sockfd);
    /* initiate the TLS/SSL handshake with an TLS/SSL server */
    err = 0; /* Reset error */
    ret = SSL_connect(ssl);
    if (ret != SSL_SUCCESS) {
        err = SSL_get_error(ssl, 0);
        printf("SSL_connect error %d, %s\n", err,
        ERR_error_string(err, buffer));
    }
    /* send message to server */
    sendSz = (int)strlen(msg);
    do {
        err = 0; /* reset error */
        ret = SSL_write(ssl, msg, sendSz);
        if (ret <= 0) {
            err = SSL_get_error(ssl, 0);
        }
    } while (err == _WANT_WRITE);
    /* clean up */
    SSL_shutdown(ssl);
    SSL_free(ssl);
    SSL_CTX_free(ctx);
    /* close descriptor */
    close(sockfd);
}
/* entry */
int main()
{
    hello_test();
    return 0;
}
コンパイル例 (gccの場合):
$gcc -o hello_wolfssl hello.c -I/path/to/wolfssl -I/path/to/wolfssl/wolfssl -include wolfssl/options -lwolfssl

上記のサンプルプログラムのようにOpenSSL互換APIを利用することで、簡単に既存のOpenSSLソースコードを再利用することができます。

3. サポート済み互換APIの確認方法

OpenSSLのAPIは膨大なため、wolfSSL では使用頻度の高いAPIのサブセットを提供しています。必要なOpenSSL APIがサポートされているかは、以下の3ステップを行い判断することができます。

  • /wolfssl/opensslディレクトリ内のヘッダーファイルを確認する。
    /wolfssl/opensslディレクトリ内のヘッダーには OpenSSL 互換レイヤのAPI定義を含む記述があります。 このフォルダ内のssl.hに定義があるかを確認します。
  • NO_WOLFSSL_STUBを定義しアプリケーションのリンクを行ってみる
    APIによっては関数の定義のみで、内部の実装が行われていないものも存在します。そのようなAPIを検出するために次のステップを行います。
  1. configure に NO_WOLFSSL_STUB マクロ定義を指定します。
    $./configure –enable-opensslextra CFLAGS=”-DNO_WOLFSSL_STUB”
    SSL_CTX_get_mode() を例にとって試してみます。
    /wolfssl/openssl/ssl.h を確認します。

    #define SSL_CTX_set_mode                wolfSSL_CTX_set_mode
    #define SSL_CTX_get_mode                wolfSSL_CTX_get_mode
    #define SSL_CTX_set_default_read_ahead  wolfSSL_CTX_set_default_read_ahead
    

    SSL_CTX_get_modeは、wolfSSL_CTX_get_mode に対応付けられています。

  2. 次に、src/ssl.c内にあるwolfSSL_CTX_get_modeの実装を確認してみます。
    #ifndef NO_WOLFSSL_STUB
    long wolfSSL_CTX_get_mode(WOLFSSL_CTX* ctx)
    {
        /* TODO: */
        (void)ctx;
        WOLFSSL_STUB("SSL_CTX_get_mode");
        return 0;
    }
    #endif
    

    未実装で、#ifndef #endif で括られていることが分かります。

  3. NO_WOLFSSL_STUB を指定し、wolfSSL ライブラリをビルドします。
    $./configure –enable-opensslextra CFLAGS=”-DNO_WOLFSSL_STUB”
    $make

    先ほどのアプリケーションにSSL_CTX_get_mode() 呼び出しを追加し、コンパイルしてみます。

    $gcc -o hello_wolfssl hello.c -I/path/to/wolfssl -I/path/to/wolfssl/wolfssl -include wolfssl/options -lwolfssl
    /tmp/cco4upmi.o: 関数 `hello_test' 内:
    echoclient.c:(.text+0xf6): `wolfSSL_CTX_get_mode' に対する定義されていない参照です
    collect2: error: ld returned 1 exit status

    エラーになり、実装されていないことが分かります。

4. 注意事項

サポート済みAPIの有無以外にOpenSSL互換APIを使用する上で注意しておく点があります。

  • 構造体に互換性がない

構造体の互換性を保証しませんので、構造体メンバーを直接参照は避けてください。

  • エラーチェック・エラーコードに互換性がない

API内部の実装が、まったくの同一ではないため、エラーチェックの段階で異なる戻り値を返すことがあります。下記に一例を挙げます。
例:SSL_CTX_load_verify_locations()

エラーの条件wolfSSLOpenSSL
指定した CA ファイルが存在しない-4(WOLFSSL_BAD_FILE)0(失敗)
CA ファイルの有効期限が無効(有効期限前)-150(ASN_BEFORE_DATE_E)1(成功)
成功1(WOLFSSL_SUCCESS)1(成功)

サポート済みAPIの確認方法、及び注意点で言及しましたように気を付けるポイントがいくつかありますが、今回紹介したように wolfSSL ではOpenSSL からのアプリケーションの移行に配慮しています。また、サポート済みAPIの有無、その動作についてや新たなAPIの追加サービスのご希望などありましたらお気軽にsupport@wolfssl.com までお知らせください。

 

連載:wolfの仲間たち 第二回:安全なファームウェア更新を支えるwolfBoot

連載第二回は、wolfの新しいメンバー wolfBootを紹介します。
wolfBootはその名の通りブートローダーの仲間ですが、wolfの暗号技術、セキュリティ技術を使って安全なファームウェアの更新、起動を実現したセキュアなブートローダーです。

従来この領域は、組込まれるハードウェアやシステム構成、要求されるセキュリティレベルなどさまざまな条件に依存してしまうため、なかなか汎用のコンポーネントとして提供することは難しいとされてきました。その一方で、現実に利用されるIoTデバイスや組込システムでは、長期化する製品ライフサイクルの中で、進化させていかなければならないファームウェアをいかに安全に速やかに更新するかが重要な課題になってきています。

そんな中で、wolfBootは

1) 更新内容の一貫性や署名の検証
2) どんなタイミングで障害が発生しても必ず安全で完全なロールバック

など、安全なファームウェア更新のために必要となる機能のみにフォーカスした組込み製品です。他のwolfの製品同様、組込向けを強く意識して小型、軽量であると同時にハードウェア依存部分を最大限に局所化しています。一方で、一貫性や署名の検証のための暗号アルゴリズムエンジンにはwolfCryptが使用されているので、楕円曲線暗号(ECC)はもちろんEd25519による署名検証など、最新の暗号アルゴリズムを使用した妥協のない安全で高速な検証を実現することができます。

さらに、耐タンパー性などハードウェアレベルのセキュリティに対応するためのwolfTPMとの連携、遠隔からの安全な更新のためのwolfMQTTwolfSSLなどの安全な通信チャネルとの連携など、トータルなファームウェアライフサイクル管理ソリューション構築のためのコンポーネントとして重要な役割を担っています。

・wolfBootの製品詳細はこちらでご紹介しています。
・wolfBootマニュアルはこちらにあります。
・連載:wolfの仲間たち第一回:全員集合

さらに詳しい情報は弊社問い合わせ窓口 info@wolfssl.jp までご連絡ください。

wolfTPM 1.5.0リリースのお知らせ

wolfTPM バージョン1.5.0をリリースしました。このバージョンではたくさんの新しい機能がwolfTPMライブラリに追加されています。

まとめ:

  • Microchip ATTPM20 TPM 2.0モジュールをサポート
  • Bareboxブートローダーをサポート
  • HMAC、AESキーローディング用のTPMラッパーを追加
  • RNG、AES、ハッシュ、TLSのベンチマークサポートを追加
  • TLSクライアント/サーバーの例と全体的な性能向上

詳細:

  • クリーンアップで暗号コールバックの登録が解除されない問題を修正
  • Microchip社のATTPM20製品をサポート
  • Barebox(仮バージョン)をサポート
  • CPSおよびKB /秒用のTLSベンチマークを追加
  • 共通鍵AES / HMAC / RNGのTLSクライアント/サーバーをサポート(TLS_BENCH_MODEで有効化)
  • 相互認証用のTLSクライアント/サーバーをサポート(WOLFTPM_USE_SYMMETRICで有効化)
  • 並行プロセスアクセス用のTISロック保護を追加(WOLFTPM_TIS_LOCKで有効化)
  • 共通鍵AES暗号化と復号化のラッパーとその例を追加
  • HMACのラッパーとその例を追加
  • 外部HMACキーとAESキーをロードするためのラッパーとその例を追加
  • 鍵削除ラッパーとその例を追加
  • 一時鍵生成と鍵共有のためのECDHサポートを追加
  • RNG、AES(CTR、CBC、CFB)128/256とSHA-1、SHA-256、SHA-384とSHA-512のベンチマークサポートを追加
  • チップ情報を取得するための新しいwolfTPM2_GetCapabilitiesラッパーAPIを追加
  • ./configure –enable-debug = verboseまたは#define WOLFTPM_DEBUG_VERBOSEを使用したコマンドと応答のログ記録を追加
  • WOLFTPM_DEBUG_IOを使用して生のIOロギングを有効にするオプションを追加
  • NO_TPM_BENCHを使用してTPMベンチマークコードを無効にするオプションを追加
  • 設定方法についてexamples / README.mdを追加
  • サポートされているTPM 2.0チップの最大SPIクロックとパフォーマンスを調整
  • 共通のテストパラメータをexamples / tpm_test.hに移動するためのクリーンアップ
  • README.mdの例のベンチマークとコンソール出力を更新

wolfTPMに関してさらに詳細な情報、wolfSSLライブラリに関しては info@wolfssl.jp宛お問い合わせください。

Posts navigation

1 2 3 4 5 31 32 33