- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I want to translate KBA235464 into Japanese, please confirm to my work.
Thanks
Solved! Go to Solution.
- Labels:
-
Community translation
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bindu-san,
The following shows the translated version in Japanese for targeted KBA.
Please conform and double check.
Please confirm.
- I could not move from the [Solution Reference Manual] link in the original data.
Therefore, in my work, I replaced the link on the following page.
- Also, [GitHub] link below was incorrect.
"In order to generate manifest according to [CBOR], you can use the tool present in GitHub."
In my work, I replaced the link on the following page.
https://github.com/Infineon/optiga-trust-m/tree/develop/examples/tools/protected_update_data_set/bin
----------------------------------------------------------------------------------------
OPTIGA(TM) Trust M: 保護された更新 - KBA235464
バージョン: **
オブジェクトのライフサイクルステートオブジェクト (LcsO) が動作状態または終了状態でない場合、オブジェクトのメタデータを変更できます。オブジェクトが運用状態にある場合は、メタデータの更新に必要なアクセス条件で保護された更新を使用します。
Protected Update 機能を使用すると、OPTIGA™ Trust M V1 上の任意のデータ オブジェクト (キー オブジェクトではない) の完全性を保護した更新を行うことができます。OPTIGA™ Trust M V3 により、キー オブジェクトを含むあらゆるデータ オブジェクトの完全性と機密性が保護された更新が可能になります。次のオブジェクトは、完全性保護更新から除外されます。
- ライフ サイクル ステータス (グローバルまたはアプリケーション)
- セキュリティ ステータス(グローバルまたはアプリケーション)
- コプロセッサーの UID
- スリープモード起動遅延
- 電流制限
- セキュリティイベントカウンター
- 最後のエラー コード
- 最大通信バッファ サイズ
図 1 は、マニフェストおよび接続されたバイナリ データと共に、データまたはキー オブジェクトの更新されたデータ セットの高レベルの構造を示しています。
図 1 マニフェストの構造
構造のコーディングは [CBOR] に従う。 マニフェストと署名構造の [CDDL] 形式は、パッケージで提供されます。
マニフェストは、他のすべての構造を結び付ける最上位の構造であり、OPTIGA™ にインストールされたトラスト アンカーによって ID が表される承認されたエンティティによって署名されます。 トラスト アンカーは、マニフェストのメタデータに含まれる一意のオブジェクト識別子 (OID) によってアドレス指定されます。
マニフェストは、プレーン テキストのメタデータ、ペイロードまたはフラグメント バインディング、およびメタデータとペイロード バインディングに対する署名で構成されます。 更新されるデータは、フラグメントの形式で編成されます。 各フラグメントは、最後のフラグメントを除く次のフラグメントのデータとハッシュで構成されます。 ペイロード バインディングは、最初のフラグメントのハッシュです。
オブジェクト データの完全性保護は、メタデータおよびフラグメント バインディング ハッシュ値に対する署名の検証の成功に基づいています。
機密性保護は、OPTIGA™ にインストールされた共有秘密に基づいています。 キーの導出、暗号化、および復号化に関する詳細については、ソリューション リファレンス マニュアル のセクション 6.7.1 を参照してください。
[CBOR] に従ってマニフェストを生成するには、GitHub にあるツールを使用できます。
CBOR ツールを使用したマニフェストの生成には、トラスト アンカー OID (検証用の公開キー)、ターゲット OID、マニフェストに署名するための秘密キー、ペイロード タイプ (データまたはキーまたはメタデータ) などの入力が必要です。これらは GitHub で説明されています。サンプル更新データセットについては、GitHub を参照してください。
アップデートに必要なアクセス条件:
- メタデータ更新の場合、それぞれのトラスト アンカー OID を持つメタデータ更新記述子タグ (0xD8) がターゲット OID メタデータに存在する必要があります。
- 機密性が保護された更新の場合、保護された更新記述子タグ (0x23) は、共有秘密 OID のデータ オブジェクト タイプである必要があります。
- オブジェクトのメタデータ更新の場合、データ オブジェクトに何が起こるかを決定するリセット タイプ タグ (0xF0) が存在する必要があります。
- マニフェストの検証に使用されるトラスト アンカーには、それぞれのタグ タイプのデータ オブジェクト タイプ タグが含まれている必要があります。たとえば、検証用のトラスト アンカーとして 0xE0E3 を使用している場合、データ オブジェクト タイプ タグは公開鍵証明書タイプである必要があります。
メタデータ更新プロセス:
以下は、OID が 0xE0E2 (公開鍵証明書) で、LcsO ステータスが動作中のオブジェクトのメタデータを更新する例です。
1. 必要な条件:
- 図 2 に示すように、メタデータ更新記述子タグ (0xD8) とリセット タイプ タグ (0xF0) が続くデータは、ターゲット OID のメタデータに存在するため、メタデータを更新できます。
図 2 ターゲット OID のメタデータ
- 図 3 では、0xE0E8 のメタデータには、値が 0x11 (トラスト アンカー タイプ) のデータ オブジェクト タイプ タグ (0xE8) があり、保存されている公開鍵証明書を署名の検証に使用します。
図 3 トラスト アンカー OID のメタデータ
2. マニフェストの生成:
- マニフェストは、プレーン テキストのメタデータ、ペイロード バインディング、およびメタデータとペイロード バインディングに対する署名を含む構造です。
- マニフェストは、次のように CBOR ツールを使用して生成されます。
- priv_key: 署名に使用される秘密鍵ファイル (pem 形式) のパスを指定します。
- trust_anchor_oid: これには、上で指定した対応する秘密鍵の公開鍵証明書が含まれている必要があります。 trust_anchor_oid に保存されているこの証明書は、署名の検証に使用されます。 ここでは、0xE0E8 を trust_anchor_oid として使用します。
- sign_algo: 署名に使用するアルゴリズムを指定します。
- payload_type: これは、更新のタイプを指定します。 メタデータの更新を行っているため、メタデータとして指定します。
- metadata: 更新する必要があるメタデータを含むメタデータ ファイル (テキスト形式) のパスを指定します。
- content_reset: これは、メタデータが変更された場合にオブジェクト内のデータに何が起こるかを指定します。 ここでは、更新されたメタデータのリセット タイプ フラグに従って変更するように指定します。
- データまたはキーの更新の場合、マニフェストの生成は GitHub で説明されているさまざまなオプションを使用して行われます。
図 4 マニフェストの生成
- 図 4 に示すように、実行が成功するとマニフェストとデータ フラグメントが生成されます。
- 特定のオブジェクトのメタデータを更新するたびに、ペイロード バージョンを増やす必要があります。 たとえば、ペイロード バージョンが 3 のオブジェクトのメタデータを更新した場合、次に同じオブジェクトのメタデータを更新するときは、ペイロード バージョンを 3 より大きくする必要があります。
図 5 生成されたマニフェスト
- 生成されたマニフェストとフラグメントは、図 5 に示すように、オブジェクトの更新を開始するために、保護された更新 API にパラメーターとして渡されます。
3. 保護された更新操作:
- 保護された更新については、図 6 に示す一連の操作に従います。
図 6 保護された更新プロセス
- さらに、更新プロセスは optiga_util (保護された更新 API) によって行われます。
- optiga_util_protected_update_start(optiga_util_instance、manifest_version、manifest、manifest_length):
- この操作は、OPTIGA™ でデータまたはキー オブジェクトの保護された更新を開始します。
- 提供されたマニフェストは、OPTIGA™ によって検証されます。
- 検証が成功すると、オブジェクトのアクセス条件が保護された更新を許可するかどうかをチェックします。
- アクセス条件が満たされた場合、以下の関数を使用して、データ フラグメントがオブジェクトに送信されます。
-optiga_util_protected_update_continue(optiga_util_instance,fragment , fragment_length): This operation sends the fragments to OPTIGA™. If number of fragments is n, the first (n-1) fragments are sent.
-optiga_util_protected_update_final(optiga_util_instance,fragment , fragment_length): This operation sends the final fragment to OPTIGA™ and finalizes the protected update of OPTIGA™ object.
Labels: OPTIGA™ Trust M
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kenji Takahashi-San,
Confirm to work on this KBA.
Thanks,
Bindu
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bindu-san,
The following shows the translated version in Japanese for targeted KBA.
Please conform and double check.
Please confirm.
- I could not move from the [Solution Reference Manual] link in the original data.
Therefore, in my work, I replaced the link on the following page.
- Also, [GitHub] link below was incorrect.
"In order to generate manifest according to [CBOR], you can use the tool present in GitHub."
In my work, I replaced the link on the following page.
https://github.com/Infineon/optiga-trust-m/tree/develop/examples/tools/protected_update_data_set/bin
----------------------------------------------------------------------------------------
OPTIGA(TM) Trust M: 保護された更新 - KBA235464
バージョン: **
オブジェクトのライフサイクルステートオブジェクト (LcsO) が動作状態または終了状態でない場合、オブジェクトのメタデータを変更できます。オブジェクトが運用状態にある場合は、メタデータの更新に必要なアクセス条件で保護された更新を使用します。
Protected Update 機能を使用すると、OPTIGA™ Trust M V1 上の任意のデータ オブジェクト (キー オブジェクトではない) の完全性を保護した更新を行うことができます。OPTIGA™ Trust M V3 により、キー オブジェクトを含むあらゆるデータ オブジェクトの完全性と機密性が保護された更新が可能になります。次のオブジェクトは、完全性保護更新から除外されます。
- ライフ サイクル ステータス (グローバルまたはアプリケーション)
- セキュリティ ステータス(グローバルまたはアプリケーション)
- コプロセッサーの UID
- スリープモード起動遅延
- 電流制限
- セキュリティイベントカウンター
- 最後のエラー コード
- 最大通信バッファ サイズ
図 1 は、マニフェストおよび接続されたバイナリ データと共に、データまたはキー オブジェクトの更新されたデータ セットの高レベルの構造を示しています。
図 1 マニフェストの構造
構造のコーディングは [CBOR] に従う。 マニフェストと署名構造の [CDDL] 形式は、パッケージで提供されます。
マニフェストは、他のすべての構造を結び付ける最上位の構造であり、OPTIGA™ にインストールされたトラスト アンカーによって ID が表される承認されたエンティティによって署名されます。 トラスト アンカーは、マニフェストのメタデータに含まれる一意のオブジェクト識別子 (OID) によってアドレス指定されます。
マニフェストは、プレーン テキストのメタデータ、ペイロードまたはフラグメント バインディング、およびメタデータとペイロード バインディングに対する署名で構成されます。 更新されるデータは、フラグメントの形式で編成されます。 各フラグメントは、最後のフラグメントを除く次のフラグメントのデータとハッシュで構成されます。 ペイロード バインディングは、最初のフラグメントのハッシュです。
オブジェクト データの完全性保護は、メタデータおよびフラグメント バインディング ハッシュ値に対する署名の検証の成功に基づいています。
機密性保護は、OPTIGA™ にインストールされた共有秘密に基づいています。 キーの導出、暗号化、および復号化に関する詳細については、ソリューション リファレンス マニュアル のセクション 6.7.1 を参照してください。
[CBOR] に従ってマニフェストを生成するには、GitHub にあるツールを使用できます。
CBOR ツールを使用したマニフェストの生成には、トラスト アンカー OID (検証用の公開キー)、ターゲット OID、マニフェストに署名するための秘密キー、ペイロード タイプ (データまたはキーまたはメタデータ) などの入力が必要です。これらは GitHub で説明されています。サンプル更新データセットについては、GitHub を参照してください。
アップデートに必要なアクセス条件:
- メタデータ更新の場合、それぞれのトラスト アンカー OID を持つメタデータ更新記述子タグ (0xD8) がターゲット OID メタデータに存在する必要があります。
- 機密性が保護された更新の場合、保護された更新記述子タグ (0x23) は、共有秘密 OID のデータ オブジェクト タイプである必要があります。
- オブジェクトのメタデータ更新の場合、データ オブジェクトに何が起こるかを決定するリセット タイプ タグ (0xF0) が存在する必要があります。
- マニフェストの検証に使用されるトラスト アンカーには、それぞれのタグ タイプのデータ オブジェクト タイプ タグが含まれている必要があります。たとえば、検証用のトラスト アンカーとして 0xE0E3 を使用している場合、データ オブジェクト タイプ タグは公開鍵証明書タイプである必要があります。
メタデータ更新プロセス:
以下は、OID が 0xE0E2 (公開鍵証明書) で、LcsO ステータスが動作中のオブジェクトのメタデータを更新する例です。
1. 必要な条件:
- 図 2 に示すように、メタデータ更新記述子タグ (0xD8) とリセット タイプ タグ (0xF0) が続くデータは、ターゲット OID のメタデータに存在するため、メタデータを更新できます。
図 2 ターゲット OID のメタデータ
- 図 3 では、0xE0E8 のメタデータには、値が 0x11 (トラスト アンカー タイプ) のデータ オブジェクト タイプ タグ (0xE8) があり、保存されている公開鍵証明書を署名の検証に使用します。
図 3 トラスト アンカー OID のメタデータ
2. マニフェストの生成:
- マニフェストは、プレーン テキストのメタデータ、ペイロード バインディング、およびメタデータとペイロード バインディングに対する署名を含む構造です。
- マニフェストは、次のように CBOR ツールを使用して生成されます。
- priv_key: 署名に使用される秘密鍵ファイル (pem 形式) のパスを指定します。
- trust_anchor_oid: これには、上で指定した対応する秘密鍵の公開鍵証明書が含まれている必要があります。 trust_anchor_oid に保存されているこの証明書は、署名の検証に使用されます。 ここでは、0xE0E8 を trust_anchor_oid として使用します。
- sign_algo: 署名に使用するアルゴリズムを指定します。
- payload_type: これは、更新のタイプを指定します。 メタデータの更新を行っているため、メタデータとして指定します。
- metadata: 更新する必要があるメタデータを含むメタデータ ファイル (テキスト形式) のパスを指定します。
- content_reset: これは、メタデータが変更された場合にオブジェクト内のデータに何が起こるかを指定します。 ここでは、更新されたメタデータのリセット タイプ フラグに従って変更するように指定します。
- データまたはキーの更新の場合、マニフェストの生成は GitHub で説明されているさまざまなオプションを使用して行われます。
図 4 マニフェストの生成
- 図 4 に示すように、実行が成功するとマニフェストとデータ フラグメントが生成されます。
- 特定のオブジェクトのメタデータを更新するたびに、ペイロード バージョンを増やす必要があります。 たとえば、ペイロード バージョンが 3 のオブジェクトのメタデータを更新した場合、次に同じオブジェクトのメタデータを更新するときは、ペイロード バージョンを 3 より大きくする必要があります。
図 5 生成されたマニフェスト
- 生成されたマニフェストとフラグメントは、図 5 に示すように、オブジェクトの更新を開始するために、保護された更新 API にパラメーターとして渡されます。
3. 保護された更新操作:
- 保護された更新については、図 6 に示す一連の操作に従います。
図 6 保護された更新プロセス
- さらに、更新プロセスは optiga_util (保護された更新 API) によって行われます。
- optiga_util_protected_update_start(optiga_util_instance、manifest_version、manifest、manifest_length):
- この操作は、OPTIGA™ でデータまたはキー オブジェクトの保護された更新を開始します。
- 提供されたマニフェストは、OPTIGA™ によって検証されます。
- 検証が成功すると、オブジェクトのアクセス条件が保護された更新を許可するかどうかをチェックします。
- アクセス条件が満たされた場合、以下の関数を使用して、データ フラグメントがオブジェクトに送信されます。
-optiga_util_protected_update_continue(optiga_util_instance,fragment , fragment_length): This operation sends the fragments to OPTIGA™. If number of fragments is n, the first (n-1) fragments are sent.
-optiga_util_protected_update_final(optiga_util_instance,fragment , fragment_length): This operation sends the final fragment to OPTIGA™ and finalizes the protected update of OPTIGA™ object.
Labels: OPTIGA™ Trust M
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kenji Takahashi San,
confirmed to receive this KBA.
Thank you for your contribution.
Thanks,
Bindu