diff --git a/wolfSSL-Porting/src-ja/section01.md b/wolfSSL-Porting/src-ja/section01.md index bd314781..5fc57ca5 100644 --- a/wolfSSL-Porting/src-ja/section01.md +++ b/wolfSSL-Porting/src-ja/section01.md @@ -1,31 +1,25 @@ # 1 はじめに -組み込みプラットフォーム上でwolfSSLを実行するには、いくつかのステップが必要です。これらのステップのいくつかは、wolfSSL Manual（非標準環境でのビルド）のセクション2.4で概説されています。 - -wolfSSLマニュアルの第2章の手順とは別に、特定のプラットフォームに対応するために移植や修正が必要なコードがいくつかあります。 wolfSSLは、これらの分野の多くを抽象化して、wolfSSLを新しいプラットフォームに移植するのはできるだけ簡単にしようとしています。 - +このガイドは、軽量 SSL/TLS ライブラリwolfSSLを新しい組み込みプラットフォーム、オペレーティングシステム、トランスポートメディア(TCP/IP、Bluetoothなど)に移植するエンジニア向けのリファレンスを提供します。wolfSSLを移植する際に通常変更が必要となるwolfSSLコードベースの領域を説明しています。本稿はあくまで「ガイド」で、技術の進化に伴い変更が必要になることもあります。不足していると感じる箇所があれば、気兼ねなくお知らせください。 ## 想定する読者 -このガイドは、デフォルトでサポートされていない新しいプラットフォームまたは環境に wolfSSL および wolfCrypt を移植する開発者またはエンジニアを対象としています。 +このガイドは、wolfSSLおよびwolfCryptを、現在サポートされていない新しいプラットフォームまたは環境に移植するエンジニアを対象としています。 ## 概要 -組み込みプラットフォームで wolfSSL を実行するには、いくつかの手順を繰り返す必要があります。 これらの手順のいくつかは、wolfSSL マニュアルのセクション 2.4 で概説されています。 - -wolfSSL マニュアルの第 2 章の手順とは別に、特定のプラットフォームに対応するために移植または変更が必要なコードの領域があります。 wolfSSL はこれらの領域の多くを抽象化し、wolfSSL を新しいプラットフォームにできるだけ簡単に移植できるようにします。 +組み込みプラットフォームでwolfSSLを実行するには、いくつかの手順を繰り返す必要があります。これらの手順の一部は、[2.4章](chapter02.md#building-in-a-non-standard-environment) で概説しています。 -./wolfssl/wolfcrypt/settings.h ファイルには、さまざまなオペレーティング システム、TCP/IP スタック、およびチップセット (つまり、MBED、FREESCALE\_MQX、MICROCHIP\_PIC32、MICRIUM、EBSNET など) に固有の定義がいくつかあります。 wolfSSL をコンパイルして新しいプラットフォームに移植するときに \#defines を配置する主な場所は次の 2 つです。 +wolfSSLドキュメント第2章に示した手順に加えて、特定のプラットフォームに対応するために移植または変更が必要なコード領域があります。wolfSSLはこれらの領域の多くを抽象化して、新しいプラットフォームへできるだけ簡単に移植できるようにしています。 -まず、オペレーティング システムまたは TCP/IP スタック ポートの新しい定義は、通常、wolfSSL の新しいポートが完了すると、settings.h ファイルに追加されます。 これにより、機能をオン/オフしたり、そのビルドのデフォルトにする必要があるビルド設定をカスタマイズしたりする簡単な方法が提供されます。 wolfSSL を新しいプラットフォームに移植する際に、このファイルに新しいカスタム定義を追加できます。 ユーザーは、GitHub のマスター オープン ソース コード ブランチに wolfSSL のポートを提供することをお勧めします。 これにより、wolfSSL を最新の状態に保つことができ、wolfSSL プロジェクトが改善され前進するにつれて、さまざまなポートを最新の状態に保つことができます。 +`./wolfssl/wolfcrypt/settings.h` ファイルには、さまざまなオペレーティングシステム、TCP/IPスタック、およびチップセット (例: MBED、FREESCALE_MQX、MICROCHIP_PIC32、MICRIUM、EBSNET など) に固有の定義がいくつかあります。wolfSSLをコンパイルして新しいプラットフォームに移植するときに、`#defines` を配置する主な場所は2つあります。 -自分の変更を wolfSSLproper に戻したくないユーザー、または追加のプリプロセッサー定義で wolfSSL ビルドをカスタマイズしたいユーザーの場合、wolfSSL はカスタムの「user\_settings.h」ヘッダー ファイルの使用を推奨します。 +1. オペレーティングシステムまたはTCP/IPスタックに対応するための新たなマクロ定義は、通常、wolfSSLのポーティングが完了すると、`settings.h` ファイルに追加しています。これにより、機能のオン/オフを簡単に切り替えたり、そのビルドの「デフォルト」となるビルド設定をカスタマイズしたりできます。wolfSSLを新しいプラットフォームに移植する際にも、このファイルに新しいカスタム定義を追加することでお使いいただけます。新しいプラットフォームへの移植が完了した際，もし差し支えなければ，wolfSSLの [Gitリポジトリ](https://www.github.com/wolfssl/wolfssl) にPull Requestを送信していただけると嬉しく思います。これにより、より多くの環境でwolfSSLを使用しやすくなります。 -wolfSSL ソース ファイルのコンパイル時に WOLFSSL\_USER\_SETTINGS が定義されている場合、wolfSSL は「user\_settings.h」と呼ばれるカスタム ヘッダー ファイルを自動的にインクルードします。このヘッダーはユーザーが作成し、インクルードパスに配置する必要があります。 これにより、ユーザーは自分の wolfSSLbuild 用に 1 つのファイルを維持でき、新しいバージョンの wolfSSL への更新がはるかに簡単になります。 - -wolfSSL は、直接の電子メール (info@wolfssl.com) または GitHub プル リクエストを通じて、パッチとコードの変更を提出することを奨励しています。 +2. wolfSSL自体に変更を加えたくない場合、または追加のプリプロセッサ定義を使用して wolfSSLビルドをカスタマイズしたい場合、wolfSSLはカスタムヘッダーファイル`user_settings.h`の使用を推奨します。 wolfSSLソースファイルをコンパイルするときに `WOLFSSL_USER_SETTINGS` が定義されている場合、wolfSSLはカスタムヘッダーファイル `user_settings.h` を自動的にインクルードします。このヘッダーはユーザーが作成し、インクルードパスに配置する必要があります。これにより、ユーザーはwolfSSLビルド用に1つのファイルのみを管理すればよく、wolfSSLの新しいバージョンへの更新がはるかに簡単になります。 +wolfSSLでは、直接のメール ([info@wolfssl.jp](mailto:infopwolfssl.jp)) または [GitHub Pull Request](https://github.com/wolfssl/wolfssl) を通じてパッチとコード変更をご送信いただくことを推奨しています。 図１はwolfSSLライブラリが依存する主なプラットフォームコンポーネントを示しています。ポーティング作業ではこれらの依存コンポーネントについて、ユーザが実際に使用するものと整合をとる必要があります。以下に、主なコンポーネントについて概要をまとめます。詳細については、このユーザガイドの各項を参照してください。 @@ -33,7 +27,6 @@ wolfSSL は、直接の電子メール (info@wolfssl.com) または GitHub プ ![プラットフォーム依存性の概要](./platformDependency.png "プラットフォーム依存性の概要") - - ネットワーク送受信 wolfSSLライブラリはTCP層のメッセージ送受信のためのAPIを使用します。デフォルトではBSDソケットが使用されます。いくつかの代表的なTCP層APIのためには直接リンクできるためのビルドオプションが用意されています。それ以外のメッセージングAPIを使用する場合はWOLFSSL_USER_IOオプションを指定して、ユーザが用意したメッセージ送受信のコールバック関数を登録します。 diff --git a/wolfSSL-Porting/src-ja/section02.md b/wolfSSL-Porting/src-ja/section02.md index 76617f14..8de41d91 100644 --- a/wolfSSL-Porting/src-ja/section02.md +++ b/wolfSSL-Porting/src-ja/section02.md @@ -1,154 +1,163 @@ # 2 wolfSSLのポーティング + ## データ型 -Q：このセクションが必要なのはどういう場合？
-A: ポーティング対象のプラットフォームの正しいデータ型のサイズを設定するのは常に重要です。 +**Q: どんな場合にこの章の内容が役立ちますか?** -wolfSSLは、64ビットタイプが利用可能の場合、スピードに恩恵を受けます。プラットフォーム上のsizeof（long）とsizeof（long long）の結果と一致するようにSIZEOF_LONGまたはSIZEOF_LONG_LONGを設定します。これは、settings.hファイルのカスタム定義に追加することができます。たとえば、MY_NEW_PLATFORMのサンプル定義のsettings.hで次のように指定します。 +A: プラットフォームに適したデータ型のサイズを設定することは常に重要です。 +wolfSSL は、64ビット型を利用できることで速度面でメリットを得ています。プラットフォームの `sizeof(long)` と `sizeof(long long)` の結果と一致するように `SIZEOF_LONG` と `SIZEOF_LONG_LONG` を定義します。これは、`settings.h` または `user_settings.h` のカスタム定義に追加できます。たとえば、`MY_NEW_PLATFORM` のサンプル定義の下の `settings.h` では次のように示します。 -``` +```c #ifdef MY_NEW_PLATFORM - #define SIZEOF_LONG 4 - #define SIZEOF_LONG_LONG 8 - ... + #define SIZEOF_LONG 4 + #define SIZEOF_LONG_LONG 8 +... #endif ``` -「word32」と「word16」と呼ばれる、wolfSSL と wolfCrypt で使用される二つの追加のデータ型があります。 これらのデフォルトのタイプ マッピングは次のとおりです: -``` +wolfSSLとwolfCryptでは、`word32` と `word16` という2つの追加データ型を使用します。これらのデフォルトの型マッピングは次のとおりです。 + + +```c #ifndef WOLFSSL_TYPES #ifndef byte -typedef unsigned char byte; + typedef unsigned char byte #endif - typedef unsigned short word16; -typedef unsigned int word32; -typedef byte word24[3]; + typedef unsigned short word16; + typedef unsigned int word32; + typedef byte word24[3]; #endif ``` -「word32」はコンパイラの 32 ビット型に、「word16」はコンパイラの 16 ビット型にマップする必要があります。 これらのデフォルトのマッピングがプラットフォームに対して正しくない場合は、settings.h または user_settings.h で WOLFSSL_TYPES を定義し、word32 および word16 に独自のカスタム typedef を割り当てる必要があります。 -wolfSSL の fastmath ライブラリは、「fp_digit」および「fp_word」タイプを使用します。 デフォルトでは、これらはビルド構成に応じて にマップされます。 +`word32` はコンパイラの32ビット型にマッピングされ、`word16` はコンパイラの16ビット型にマッピングされます。これらのデフォルトのマッピングがプラットフォームに適していない場合は、`settings.h` または `user_settings.h` で `WOLFSSL_TYPES` を定義し、word32およびword16に独自のカスタムtypedefを割り当てる必要があります。 -「fp_word」は「fp_digit」の 2 倍のサイズにする必要があります。 デフォルトのケースがプラットフォームに当てはまらない場合は、settings.h または user_settings.h で WOLFSSL_BIGINT_TYPES を定義し、fp_word および fp_digit に独自のカスタム typedef を割り当てる必要があります。 +wolfSSLのfastmathライブラリは、`fp_digit` および `fp_word` 型を使用します。デフォルトでは、これらはビルド構成に応じて `` にマッピングされます。 -一部の操作で利用可能な場合、wolfSSL は 64 ビット型を使用します。 wolfSSL ビルドは、SIZEOF_LONG と SIZEOF_LONG_LONG の設定に基づいて、word64 の正しい基本データ型を検出して設定しようとします。 2 つの 32 ビット型が一緒に使用される、真の 64 ビット型を持たない一部のプラットフォームでは、パフォーマンスが低下する可能性があります。 64 ビット型を使用しないでコンパイルするには、NO_64BIT を定義します。 +`fp_word` は `fp_digit` の2倍のサイズである必要があります。デフォルトのケースがプラットフォームに当てはまらない場合は、`settings.h` または `user_settings.h` で `WOLFSSL_BIGINT_TYPES` を定義し、`fp_word` および `fp_digit` に独自のカスタムtypedefを割り当てる必要があります。 -## エンディアン +wolfSSLは、一部の操作において使用可能な場合は64ビット型を使用します。ビルド時には、`SIZEOF_LONG` および `SIZEOF_LONG_LONG` の設定に基づいて、`word64` の正しいデータ型を検出して設定しようとします。 真の64ビット型を持たない一部のプラットフォームでは、2つの32ビット型を合わせて使用するため、パフォーマンスが低下する可能性があります。コンパイル時に`NO_64BIT`を定義することで，64ビット型を使用しないこともできます。 -Q：このセクションが必要なのはどういう場合？
-A: プラットフォームがビッグエンディアンの場合です +## エンディアン -あなたのプラットフォームはビッグエンディアン、リトルエンディアン、どちらですか？
- wolfSSLはデフォルトではリトルエンディアンシステムです。システムがビッグエンディアンの場合は、wolfSSLをビルドするときにBIG_ENDIAN_ORDERを定義してください。これをsettings.hで設定する例： +**Q: どんな場合にこの章の内容が役立ちますか?** +A: あなたのプラットフォームがビッグエンディアンの場合です。 -``` +お使いのプラットフォームはビッグエンディアンとリトルエンディアン，どちらでしょうか．wolfSSLはデフォルトでリトルエンディアンを使用しています。システムがビッグエンディアンの場合は、wolfSSL をビルドする際に `BIG_ENDIAN_ORDER` を定義します。例えば，`settings.h` で次のように設定できます． + +```c #ifdef MY_NEW_PLATFORM - ... - #define BIG_ENDIAN_ORDER - ... + ... + #define BIG_ENDIAN_ORDER + ... #endif ``` + ## writev -Q：このセクションが必要なのはどういう場合？
-A: が提供されていない場合です +**Q: どんな場合にこの章の内容が役立ちますか?** + +A: `` を利用できない場合です。 + +デフォルトでは、wolfSSL APIは、`writev()` セマンティクスをシミュレートする `wolfSSL_writev()` をアプリケーションに提供します。 `` ヘッダーが利用できないシステムでは、`NO_WRITEV` を定義してこの機能を除外します。 -デフォルトでは、wolfSSL APIはアプリケーションに対してwritev関数のセマンティクスをシミュレートするwolfSSL_writev（）を提供します。使用可能なヘッダーを持たないシステムでは、この機能を除外するためにNO_WRITEVを定義してください。 +## ネットワークI/O -## (ネットワーク) 入出力 +**Q: どんな場合にこの章の内容が役立ちますか?** -Q：どういう場合このセクションが必要ですか？
-A：BSDスタイルのソケットAPIが使用できない場合。また、特別なポート層またはTCP/IPスタックを使用したい場合、静的バッファーのみを使用したい場合です。 +A: BSD スタイルのソケットAPIを利用できない、あるいはカスタムトランスポート層またはTCP/IPスタックを使用している、または静的バッファーのみを使用したい場合です。 -wolfSSLはデフォルトではBSDスタイルのソケットインターフェイスを使用します。トランスポート層がBSDソケットインタフェースを提供する場合、カスタムヘッダが必要な場合を除いて、wolfSSLはそのままの状態で統合する必要があります。 +wolfSSLはデフォルトでBSDスタイルのソケットインターフェイスを使用します。トランスポート層がBSDソケットインターフェイスを提供する場合、カスタムヘッダーが必要でない限り、wolfSSLはそのまま統合する必要があります。 -wolfSSLは、ユーザーがシステムにwolfSSLのI / O機能を合わせることが可能となるようにカスタムI / O抽象レイヤーを提供しています。詳細は、wolfSSLマニュアルのセクション5.1.2にあります。 +wolfSSLはカスタムI/O抽象化レイヤーを提供し、ユーザーはwolfSSLのI/O機能をシステムに合わせて調整できます。詳細については、[5.1.2節](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter05.html#_2) をご参照ください。 -単に、ビルド時オプションにWOLFSSL_USER_IOを指定して、独自のI / Oコールバック関数を、テンプレートとしてwolfSSLのデフォルトEmbedSend（）とEmbedReceive（）を参照して記述してください。これら2つの関数は./src/io.cにあります。 +具体的には `WOLFSSL_USER_IO` を定義し、wolfSSLデフォルトの `EmbedSend()` と `EmbedReceive()` をテンプレートとして使用し，独自のI/Oコールバック関数を記述します。これら2つの関数は `./src/io.c` にあります。 -wolfSSLは、入出力時に動的バッファを使用します。デフォルトは0バイトです。バッファよりサイズが大きい入力レコードが受信された場合は、動的バッファを使用して要求を処理してから解放します。 +wolfSSLは、入力と出力に動的バッファを使用します。このバッファのデフォルトは0バイトです。バッファよりも大きいサイズの入力レコードを受信した場合、動的バッファが一時的にリクエストの処理に使用され、その後解放されます。 -ダイナミックメモリを使用せず、大きな16kBスタティックバッファを使用したい場合は、LARGE_STATIC_BUFFERSオプションを指定します。 +動的メモリを必要としない16kBの大きな静的バッファを使用する場合は、`LARGE_STATIC_BUFFERS` を定義することでこのオプションを使用できます。 -ダイナミックバッファが使用されている時は、ユーザがバッファサイズより大きいwolfSSL_write（）を要求すると、最大MAX_RECORD_SIZEまでの動的ブロックがデータを送信するために使用されます。 RECORD_SIZEで定義されているように、バッファー・サイズのデータを最大でのみ送信したい場合は、STATIC_CHUNKS_ONLYを定義します。この定義を使用する場合、RECORD_SIZEのデフォルトは128バイトです。 +動的バッファが使用され、ユーザーがバッファサイズよりも大きい `wolfSSL_write()` を要求した場合、最大 `MAX_RECORD_SIZE` までの動的ブロックを使用してデータを送信します。`RECORD_SIZE` で定義されている現在のバッファサイズの最大のチャンクでのみデータを送信したいユーザーは、`STATIC_CHUNKS_ONLY` を定義することでこれを実現できます。この定義を使用する場合、`RECORD_SIZE` はデフォルトで 128 バイトになります。 ## ファイルシステム -Q：どういう場合このセクションが必要ですか？
-A： 使用可能なファイルシステムがない場合、標準のファイルシステム機能が使用できない場合、または、カスタムファイルシステムを使用する場合です。 +**Q: どんな場合にこの章の内容が役立ちますか?** -wolfSSLは鍵と証明書をSSLセッションまたはコンテキストにロードするためにファイルシステムを使用します。 wolfSSLでは、これらをメモリバッファからロードすることもできます。メモリバッファだけを使用する場合、ファイルシステムは必要ありません。 +A: ファイルシステムを利用できない、あるいは標準のファイルシステム機能を利用できない、または独自のファイルシステムを使用している場合です。 -ライブラリをビルドするときにNO_FILESYSTEMを定義することにより、ファイルシステムの使用を無効にすることができます。この場合、ファイルではなくメモリバッファから証明書と鍵をロードする必要があります。これをsettings.hで設定する例： +wolfSSLは、TLSセッションまたはコンテキストに鍵と証明書をロードするためにファイルシステムを使用します。wolfSSLでは、これらをメモリバッファからロードすることもできます。メモリバッファのみを使用する場合、ファイルシステムは必要ありません。 +ライブラリをビルドするときに `NO_FILESYSTEM` を定義することで、wolfSSLによるファイルシステムの使用を無効にできます。つまり、証明書と鍵はファイルではなくメモリバッファからロードする必要があります。`settings.h` で，以下のように設定できます． -``` +```c #ifdef MY_NEW_PLATFORM - ... - #define NO_FILESYSTEM - ... + ... + #define NO_FILESYSTEM + ... #endif ``` -テスト用の鍵と証明書バッファーは、./wolfssl/certs_test.hヘッダーファイルにあります。これらは、これらの証明書と./certsディレクトリにある証明書と同じものです。 - -certs_test.hヘッダーファイルは、必要に応じて./gencertbuf.plスクリプトを使用して更新できます。 gencertbuf.plには、fileList_1024とfileList_2048という2つの配列があります。鍵のサイズに応じて、それぞれの配列に追加の証明書または鍵を追加することができ、DER形式でなければなりません。上記の配列は、目的のバッファ名を持つ証明書/鍵ファイルの場所にマップされます。 gencertbuf.plを変更した後、wolfSSLルートディレクトリからそれを実行すると、./wolfssl/certs_test.hの証明書と鍵バッファが更新されます： +テスト用の鍵と証明書バッファーは、`./wolfssl/certs_test.h` ヘッダーファイルにあります。これらは、`./certs` ディレクトリにある対応する証明書や鍵と一致します。 +`certs_test.h` ヘッダーファイルは、必要に応じて `./gencertbuf.pl` スクリプトを使用して更新できます。`gencertbuf.pl` 内には、`fileList_1024` と `fileList_2048` の2つの配列があります。鍵サイズに応じて、追加の証明書またはキーをそれぞれの配列に追加できます。なお，DER形式である必要があります。上記の配列は、証明書・鍵ファイルの場所を目的のバッファー名にマップします。`gencertbuf.pl` を変更した後、wolfSSLルートディレクトリから実行すると、`./wolfssl/certs_test.h` の証明書・鍵のバッファーが更新されます。 +```sh ./gencertbuf.pl - -デフォルト以外のファイルシステムを使用したい場合、ファイルシステム抽象化レイヤーは./src/ssl.cにあります。ここでは、EBSNET、FREESCALE_MQX、MICRIUMなどのさまざまなプラットフォームのファイルシステムが表示されています。 XFILE、XFOPEN、XFSEEKなどでファイルシステム関数を定義できるように、必要に応じてプラットフォームにカスタム定義を追加できます。たとえば、MicriumのμC/ OS（MICRIUM）のssl.cのファイルシステム層は次のとおりです。 - ``` -#elif defined(MICRIUM) -#include -#define XFILE FS_FILE* -#define XFOPEN fs_fopen -#define XFSEEK fs_fseek -#define XFTELL fs_ftell -#define XREWIND fs_rewind -#define XFREAD fs_fread -#define XFCLOSE fs_fclose -#define XSEEK_END FS_SEEK_END -#define XBADFILE NULL + +デフォルト以外のファイルシステムを使用する場合、ファイルシステム抽象化レイヤーは `./wolfssl/wolfcrypt/wc_port.h` にあります。ここには、EBSNET、FREESCALE_MQX、MICRIUM などのさまざまなプラットフォームのファイルシステムポートがあります。必要に応じて、プラットフォームのカスタム定義を追加できます。これにより、`XFILE`、`XFOPEN`、`XFSEEK` などを使用してファイルシステム関数を定義できます。たとえば、Micrium の µC/OS (MICRIUM) の `wc_port.h` のファイルシステムレイヤーは次のとおりです。 + +```c +#elif defined(MICRIUM) +#include +#define XFILE FS_FILE* +#define XFOPEN fs_fopen +#define XFSEEK fs_fseek +#define XFTELL fs_ftell +#define XREWIND fs_rewind +#define XFREAD fs_fread +#define XFCLOSE fs_fclose +#define XSEEK_END FS_SEEK_END +#define XBADFILE NULL ``` -## スレッド -Q：どういう場合このセクションが必要ですか？
-A：マルチスレッド環境でwolfSSLを使用したい場合、またはシングルスレッドモードでコンパイルしたい場合です。 +## スレッド化 + +**Q: どんな場合にこの章の内容が役立ちますか?** -wolfSSLがシングルスレッド環境でのみ使用される場合、wolfSSLをコンパイルするときにSINGLE_THREADEDを定義してwolfSSLの排他制御を無効にすることができます。これにより、wolfSSL 排他制御層を移植する必要がなくなります。 +A: マルチスレッド環境でwolfSSLを使用したい、またはシングルスレッドモードでコンパイルしたい場合です。 -wolfSSLをマルチスレッド環境で使用する必要がある場合は、wolfSSL排他制御層を新しい環境に移植する必要があります。排他制御層は、./wolfssl/ctaocrypt/wc_port.hと./ctaocrypt/src/wc_port.cにあります。 wolfSSL_Mutexは、wc_port.cのport.hの新しいシステムと排他制御関数（InitMutex、FreeMutexなど）に定義する必要があります。 wc_port.hおよびwc_port.cで、いくつかの既存のプラットフォーム（EBSNET、FREESCALE_MQXなど）を例として検索します。 +wolfSSLをシングルスレッド環境でのみ使用する場合、wolfSSLをコンパイルするときに `SINGLE_THREADED` を定義することでwolfSSLミューテックスレイヤーを無効にできます。これにより、wolfSSLミューテックスレイヤーを移植する必要がなくなります。 +wolfSSLをマルチスレッド環境で使用する場合、wolfSSLミューテックスレイヤーを新しい環境に移植する必要があります。ミューテックスレイヤーは `./wolfssl/wolfcrypt/wc_port.h` および `./wolfcrypt/src/wc_port.c` にあります。新しいシステムでは、`wc_port.h` に `wolfSSL_Mutex` を定義し、`wc_port.c` にミューテックス関数 (`wc_InitMutex`、`wc_FreeMutex`、`wc_LockMutex`、`wc_UnLockMutex`) を定義する必要があります。`wc_port.h` と `wc_port.c` を検索すると、既存のプラットフォームポートレイヤー (EBSNET、FREESCALE_MQX など) の例を参照できます。 -## 乱数シード -Q：どういう場合このセクションが必要ですか？
-A：/dev/randomまたは/dev/urandomのいずれかが利用できないか、RNGハードウェアを統合したい場合です。 +## ランダムシード -デフォルトでは、wolfSSLは/dev/urandomまたは/dev/randomを使用してRNGシードを生成します。 NO_DEV_RANDOMの定義は、デフォルトのwc_GenerateSeed（）関数を無効にするときにビルド時に指定します。これが指定されている場合は、ターゲットプラットフォームに固有の./wolfcrypt/src/random.cにカスタムwc_GenerateSeed（）関数を記述する必要があります。これにより、ハードウェアベースのランダムエントロピーソースがあれば、wolfSSLのPRNGにシードすることができます。 +**Q: どんな場合にこの章の内容が役立ちますか?** -wc_GenerateSeed関数をどのように記述する必要があるかの例については、wolfSSLの既存のwc_GenerateSeed関数の実装を./wolfcrypt/src/random.cで参照してください。 +A: `/dev/random` や `/dev/urandom` を利用できない、あるいはハードウェアRNGに統合する必要がある場合です。 +デフォルトでは、wolfSSLは `/dev/urandom` または `/dev/random` を使用して RNG シードを生成します。wolfSSLをビルドするときに `NO_DEV_RANDOM` 定義を使用して、デフォルトの `GenerateSeed()` 関数を無効にすることができます。これが定義されている場合は、ターゲットプラットフォームに固有の `./wolfcrypt/src/random.c` にカスタム `GenerateSeed()` 関数を記述する必要があります。これにより、ハードウェアベースのランダムエントロピーソースが利用可能な場合は、wolfSSLのPRNGにシードを設定できます。 + +`GenerateSeed()` の記述方法の例については、`./wolfcrypt/src/random.c` にある wolfSSL の既存の `GenerateSeed()` 実装を参照してください。 ## メモリー -Q：どういう場合このセクションが必要ですか？
-A：標準のメモリ関数を使用できない場合、またはオプションの数学ライブラリ間のメモリ使用量の違いに関心があるような場合です。 +**Q: どんな場合にこの章の内容が役立ちますか?** + +A: 標準のメモリ関数が利用できない、あるいはオプションの数学ライブラリ間のメモリ使用量の違いに関心がある場合です。 -wolfSSLは、デフォルトではmalloc（）とfree（）を使用しています。 -旧来使用されてきた第1世代の整数演算ライブラリ(Normal Math)を使用する場合、wolfCryptはrealloc（）も使用します。 +wolfSSL本体はデフォルトで `malloc()` と `free()` の両方を使用します。旧来使用されてきた第1世代の整数演算ライブラリ(Normal Math)を使用する場合、wolfCryptは `realloc()` も使用します。 現在、整数演算ライブラリとして最初期に開発された第1世代のNormal Mathライブラリ、パブリックドメインのTFM(Tom's Fast Math)をベースに開発した第2世代のFast Mathライブラリ、SP(Single Precision)最適化を適用した第3世代のSP Mathライブラリが存在します。 このうち、第2世代以降のFast Math, SP Mathライブラリでは、暗号操作において動的メモリを使用しません。 @@ -161,79 +170,91 @@ wolfSSL 5.4.0以降ではデフォルトで採用しており、第1世代のNor - [wolfSSL Math Library Comparison Matrix](https://www.wolfssl.com/wolfssl-math-library-comparison-matrix/) - [レガシー数学ライブラリを廃止します](https://wolfssl.jp/wolfblog/2023/03/13/deprecation-of-wolfssl-normal-math-library/) -wolfSSLのSSL層はそのほかにもいくつかの処理で動的メモリを使用しているため、malloc（）とfree（）は依然として必要です。 +wolfSSLのTLSレイヤーは依然としていくらかの動的メモリを使用するため、`malloc()` と `free()` は依然として必要です。 -標準のmalloc（）、free（）を、およびreallocの（）関数が利用できない場合、XMALLOC_USERを定義します。これによりターゲット環境依存のカスタムフックを　 ./wolfssl/wolfcrypt/types.h内に定義することができます。 +通常の `malloc()`、`free()`、および場合によっては `realloc()` 関数が使用できない場合は、`XMALLOC_USER` を定義し、ターゲット環境に固有の `./wolfssl/wolfcrypt/types.h` でカスタムメモリ関数フックを提供します。 -XMALLOC_USERの使用方法の詳細については、wolfSSLマニュアルの[5.1.1.1節](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter05.html#_3)を参照してください。 +`XMALLOC_USER` の使用の詳細については、wolfSSLマニュアルの[5.1.1.1節](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter05.html#_3) をご参照ください。 -## 時計　　　　　　 -Q：どういう場合にこのセクションが必要ですか？
-A：標準時間関数（time（）、gmtime（））が利用できない場合、またはカスタムクロックティック関数を指定する必要がある場合です。 +## 時間 -デフォルトでは、wolfSSLは./wolfcrypt/src/asn.cで指定されているように、time（）、gmtime（）、およびValidateDate（）を使用します。これらは、XTIME、XGMTIME、XVALIDATE_DATEに抽象化されています。標準時刻関数、およびtime.hが使用できない場合、ユーザーはUSER_TIMEを定義できます。 USER_TIMEを定義した後、ユーザーは独自のXTIME、XGMTIME、およびXVALIDATE_DATE関数を定義できます。 +**Q: どんな場合にこの章の内容が役立ちますか?** -wolfSSLは、クロックティック機能のデフォルトでtime（0）を使用します。これは、LowResTimer（）関数の内部の./src/internal.cにあります。 +A: 標準の時間関数 (`time()`、`gmtime()`) を利用できない、あるいはカスタムのクロックティック関数を指定する必要がある場合です。 -time（0）が望ましくない場合には、USER_TICKSを定義することでユーザー独自のclock tick関数を定義することができます。カスタム関数は秒の精度が必要ですが、EPOCHと相関させる必要はありません。 ./src/internal.cのLowResTimer（）関数を参照してください。 +デフォルトでは、wolfSSLは `./wolfcrypt/src/asn.c` で指定されているように、`time()`、`gmtime()`、および `ValidateDate()` を使用します。これらは、`XTIME`、`XGMTIME`、および `XVALIDATE_DATE` に抽象化されています。標準の時間関数と `time.h` を利用できない場合は、ユーザーは `USER_TIME` を定義できます。`USER_TIME` を定義した後、ユーザーは独自の `XTIME`、`XGMTIME`、および `XVALIDATE_DATE` 関数を定義できます。 + +wolfSSLは、クロックティック関数にデフォルトで `time(0)` を使用します。これは、`LowResTimer()` 関数内の `./src/internal.c` にあります。 + +`USER_TICKS` を定義すると、`time(0)` が必要ない場合にユーザーが独自のクロックティック関数を定義できるようになります。カスタム関数には秒単位の精度が必要ですが、エポックと相関させる必要はありません。参考として、`./src/internal.c` の `LowResTimer()` 関数を参照してください。 ## C標準ライブラリ -Q：どういう場合このセクションが必要ですか？
-A：C標準ライブラリがない場合、またはカスタムライブラリを使用する場合です。 -wolfSSLは、C標準ライブラリを使用しなくても、開発者がより高いレベルの移植性と柔軟性を得ることができます。そのようなとき、ユーザーはC標準のものの代わりに使用したい機能をマップする必要があります。 +**Q: どんな場合にこの章の内容が役立ちますか?** + +A: C標準ライブラリを使用できない、あるいは独自のライブラリがある場合です． + +wolfSSLは、開発者に高いレベルの移植性と柔軟性を提供するために、C標準ライブラリなしで構築できるようにしています。その場合、ユーザーはC標準の関数の代わりに使用したい関数をマップする必要があります。 -上の2.8節では、メモリ機能について説明しました。メモリ関数の抽象化に加えて、wolfSSLは文字列関数と数学関数も抽象化します。それぞれの関数は抽象化される関数の名前に対応してXの形で定義されます。 +第7章では、メモリ関数について説明しました。メモリ関数の抽象化に加えて、wolfSSLは文字列関数と数学関数も抽象化します。特定の関数は通常、`X` 形式の定義に抽象化されます。`` は抽象化される関数の名前です。 詳細については、wolfSSLマニュアルの[5.1節](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter05.html#_2)をお読みください。 ## ロギング -Q：どういう場合このセクションが必要ですか？
-A：デバッグメッセージを有効にしたいが、stderrは使用できません。 -デフォルトでは、wolfSSLはstderrを介してデバッグ出力を提供します。デバッグメッセージを有効にするには、wolfSSLをDEBUG_WOLFSSLでコンパイルし、wolfSSL_Debugging_ON（）をアプリケーションコードから呼び出す必要があります。 wolfSSL_Debugging_OFF（）は、アプリケーション層がwolfSSLデバッグメッセージをオフにするために使用できます。 +**Q: どんな場合にこの章の内容が役立ちますか?** -stdderが利用できない環境や、デバッグメッセージを別の出力ストリームや別の形式で出力したい場合、wolfSSLではアプリケーションはロギングコールバックに登録できます。 +A: デバッグメッセージを有効にしたいが、stderr を使用できない場合です。 + +デフォルトでは、wolfSSLはstderrを介してデバッグ出力を提供します。デバッグメッセージを有効にするには、wolfSSLを `DEBUG_WOLFSSL` を定義してコンパイルし、アプリケーションコードから `wolfSSL_Debugging_ON()` を呼び出す必要があります。同様に，アプリケーションから`wolfSSL_Debugging_OFF()` を呼び出すことで、wolfSSLデバッグメッセージをオフにすることもできます。 + +stderrを使用できない，あるいは別の出力ストリームや別の形式でデバッグメッセージを出力したい環境には、独自のコールバック関数を使用できるようにしています． 詳細については、wolfSSLマニュアルの[8.1節](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter08.html#_2)をお読みください。 + ## 公開鍵演算 -Q：どういう場合このセクションが必要ですか？
+**Q: どんな場合にこの章の内容が役立ちますか?** -A：wolfSSLで独自の公開鍵実装を使用したいとします。 +A: wolfSSLで独自の公開鍵実装を使用したい場合です。 -wolfSSLを使用すると、SSL / TLS層が公開鍵操作を行う必要があるときに呼び出される独自の公開鍵コールバックをユーザーが書くことができます。ユーザーはオプションで6つの関数を定義できます。 +wolfSSLでは、SSL/TLSレイヤーが公開鍵操作を行う必要があるときに呼び出される，独自の公開鍵コールバックをユーザーが作成できます。 ユーザーはオプションで6つの機能を定義できます。 -- ECC復号コールバック -- ECC検証コールバック -- RSA署名コールバック -- RSA検証コールバック -- RSA暗号化コールバック -- RSA復号化コールバック +1. ECC 署名 コールバック +2. ECC 検証 コールバック +3. RSA 署名 コールバック +4. RSA 検証 コールバック +5. RSA 暗号化コールバック +6. RSA 復号 コールバック 詳細は、wolfSSLマニュアルの[6.4節](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter06.html#_5)を参照してください。 -## アトミックレコード層処理 -Q：どういう場合このセクションが必要ですか？
-A：TLSレコード層の独自の処理、特にMAC /暗号化と解読/検証操作を行いたい場合です。 +## アトミックレコードレイヤーの処理 + +**Q: どんな場合にこの章の内容が役立ちますか?** -デフォルトでは、wolfSSLは、暗号化ライブラリwolfCryptを使用して、ユーザーのTLSレコード層処理を処理します。 wolfSSLは、MAC /暗号化をより詳細に制御し、SSL / TLS接続を復号/検証したい場合、アトミックレコード処理コールバックを使用します。 +A: レコードレイヤーの処理、特にMAC/暗号化および復号/検証操作を独自に実行したい場合です。 -ユーザーは2つの関数を定義する必要があります： +デフォルトでは、wolfSSLは暗号ライブラリwolfCryptを使用し、ユーザーに代わってレコードレイヤーの処理を行います。wolfSSLは、SSL/TLS接続中に MAC/暗号化および復号/検証機能をより細かく制御したいユーザーのために、アトミックレコード処理コールバックを提供します。 -MAC /暗号化コールバック関数 -コールバック関数の復号化/検証 +ユーザーは2つの関数を定義できます． + +1. MAC/暗号化コールバック関数 +2. 復号/検証コールバック関数 詳細は、wolfSSLマニュアルの[6.3節](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter06.html#_4)を参照してください。 + ## 機能 -Q：どういう場合このセクションが必要ですか？
-A：機能を無効にする場合。 +**Q: どんな場合にこの章の内容が役立ちますか?** + +A: 特定の機能を無効にしたい場合です。 -適切な定義を使用してwolfSSLをビルドするとき、機能を無効にすることができます。利用可能な定義のリストについては、wolfSSLマニュアルの[2章](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter02.html)を参照してください。 \ No newline at end of file +wolfSSLをビルドする際，マクロ定義を使用して特定の機能を無効化できます。 +使用可能なマクロ定義については、wolfSSLマニュアルの[2章](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter02.html)をご覧ください。 \ No newline at end of file diff --git a/wolfSSL-Porting/src-ja/section03.md b/wolfSSL-Porting/src-ja/section03.md index 4545c852..060d3a5a 100644 --- a/wolfSSL-Porting/src-ja/section03.md +++ b/wolfSSL-Porting/src-ja/section03.md @@ -1,11 +1,11 @@ # 次のステップ -## wolfCryptテストアプリケーション -wolfSSLをターゲットプラットフォーム上に適切に構築した後、wolfCryptテストアプリケーションには良い次のステップがあります。このアプリケーションをターゲットシステムで実行すると、NISTテストベクタを使用して、すべての暗号アルゴリズムが正しく動作していることが確認されます。 +## wolfCryptテストアプリケーション -この手順をスキップしてSSL接続の確立に直接進むと、基になる暗号化操作が失敗したために発生した問題をデバッグするのがより困難になります。 +wolfSSLをターゲットプラットフォームで適切にビルドできるようになったら、次のステップとして wolfCryptテストアプリケーションを移植するのがよいでしょう。このアプリケーションをターゲットシステムで実行すると、NISTテストベクタを使用して、すべての暗号アルゴリズムが正しく動作しているかどうか検証されます。 -wolfCryptテストアプリケーションは、./wolfcrypt/test/test.cにあります。埋め込みアプリケーションに独自のmain（）関数がある場合、./wolfcrypt/test/test.cをコンパイルするときにNO_MAIN_DRIVERを定義することができます。これにより、アプリケーションのmain（）はそれぞれの暗号/アルゴリズムテストを個別に呼び出すことができます。 +このステップを省略してSSL/TLS接続に進むと、基盤となる暗号操作の失敗によって発生する問題のデバッグが難しくなる可能性があります。 -組み込みデバイスにwolfCryptテストアプリケーション全体を実行するのに十分なリソースがない場合、個々のテストをtest.cから抜き出して個別にコンパイルすることができます。 test.cから隔離された暗号テストを抽出する際に、ビルドに含まれる特定のテストケースに必要な正しいヘッダファイルがあることを確認してください。 +wolfCryptテストアプリケーションは `./wolfcrypt/test/test.c` にあります。組み込みアプリケーションに独自の `main()` 関数がある場合は、`./wolfcrypt/test/test.c` をコンパイルするときに `NO_MAIN_DRIVER` を定義する必要があります。これにより、アプリケーションの `main()` が各暗号/アルゴリズム テストを個別に呼び出すことができます。 +組み込みデバイスにwolfCryptテストアプリケーション全体を実行するのに十分なリソースがない場合は、個々のテストを `test.c` から切り離して個別にコンパイルできます。 `test.c` から分離された暗号テストを抽出するときは、特定のテストケースに必要な正しいヘッダーファイルがビルドに含まれていることを確認してください。 diff --git a/wolfSSL-Porting/src-ja/section04.md b/wolfSSL-Porting/src-ja/section04.md index e50cd978..f6e28b4e 100644 --- a/wolfSSL-Porting/src-ja/section04.md +++ b/wolfSSL-Porting/src-ja/section04.md @@ -25,3 +25,4 @@ wolfSSLは、お客様が新しい環境にwolfSSLを移植できるためのサ |1.9|03/02/2016|Chris Conlon|Expand data types, add Consulting Services| |1.9j|10/01/2018|Takashi Kojo|Japanese version| |1.10|12/30/2022|John Safranek|Initial markdown revision| +|1.10j|11/26/2024|Masaki Iwai|Japanese version| \ No newline at end of file