同じお客様からの2番目のチケットとそこに記載されているSWバージョンに関して
https://community.nxp.com/t5/AP-Software-Support/S32K3-Crypto-driver-KeyElementCopy/mp/2180545#M5384
お客様は、AUTOSAR 仕様への準拠について別の疑問を抱いています。
チケットの内容をそのまま全文シェアします。彼が言及しているプレゼンテーションを添付します。ご協力いただきありがとうございます
「Crypto_43_HSE ドライバ (v 6.0.0) を使用しています。」
私たちのプロジェクトでは、OEM は次の機能を実装することを望んでいます。特定の CryptoKey に属する各 CryptoKeyElement のハッシュを実行することによって、特定の CryptoKey のハッシュを実行できるようにする必要があります。個々のキー要素のハッシュが完了したら、この結果を再度ハッシュする必要があります。
SO、ジョブ入力/出力リダイレクトが使用されます。
基本的なアイデアは、入力リダイレクトを使用して、入力キー要素をハッシュの「ソース」として使用し、ハッシュ結果を HashKey1 の出力キー要素にリダイレクトすることです。その後、この出力キー要素は、KeyElementCopy (部分的) を介して、別の CryptoKey (HashKey2) に属する別のキー要素に「追加」されます。
CryptoKey のすべてのキー要素を続行すると、最後のキー要素に到達します。HashKey2 のキー要素には、入力 CryptoKey の各キー要素のハッシュが含まれるようになります。
この時点で、ハッシュ ジョブを使用し、HashKey2 からの入力リダイレクトを実行して最終的なハッシュを実行します。
いずれにせよ、私の意見では、Crypto Driver UM には次のように明確に記載されているため、これは不可能です。
このサービスは、キー マテリアルではないキー要素に対してサポートされているため、CryptoKeyElementId は 1、9、または 10 とは異なる必要があります。
このCASE、ハッシュを計算する必要がある入力 CryptoKey にも、id=1 のキー要素 ID が存在します。
さらに。すでに開いている別のチケットを参照すると、KeyElementCopy 操作は Crypto ドライバおよび/または HSE によって完全にはサポートされていないようです。
私たちのプロジェクトの提供フェーズで、NXP から、SW スタックが OEM の要件と互換性があるというプレゼンテーションをいくつか受け取りましたが、私が提示した問題は非互換性であるようです。
AUTOSAR の要件に従ってジョブ リダイレクトの適切な動作を統合/実装し、CryptoKeyElementId にキー マテリアルを識別する値があるCASEもサポートする予定はありますか。
こんにちは@davidtosenovjan
私はこの質問について Crypto チームにリクエストを提出しました。（ https://jira.sw.nxp.com/browse/FWCRYPTO-295 ）
彼らから返信があったらいつでも使えるように更新します
@davidtosenovjan
この懸念とフィードバックについては、Cryptoチームにすぐに確認します。
@davidtosenovjan
開発チームは私の質問を、2026年1月19日に開始されるスピントPI 26.1に投稿しました。