2417695_ja-JP

Yes

HSE-B SHA-512 / Ed25519 の S32K344 における検証タイミング - これらの数値は想定どおりですか？

こんにちは、ルーカス（ @lukaszadrapa ）

解決済み:ED25519およびSHA-512(S32K394)に対するHSEサポートに関する明確化 - NXPコミュニティ

SHA-384/512がHSE-Bのソフトウェアでエミュレートされるという説明ありがとうございます。S32K344ブートローダーでまさにこの問題に遭遇したのですが、私たちの測定結果が代表的なものかどうかを知りたいと思っています。

設定

S32K344、CORE_CLK 160 MHz、HSE_CLK 80 MHz（CORE_CLK/2、Clock_Ipで設定）
パッケージ0.2.55.0のHSEホストインターフェース/ヘッダー、HSE FW 0.2.40.0 がインストールされています(弊社は SBAF 0.10.0 を使用しています)。したがって、まだ0.2.55.0に移行することはできません)
メッセージ:PFLASHのアプリケーションイメージ、2,965,376バイト(0x00500000–0x007D3F7F)、アドレスで渡されます(RAMコピーなし)
ワンパスリクエスト、MU0チャネル1、同期ポーリング;非キャッシュ可能なSRAM内のディスクリプタおよび出力バッファ
M7でPIT（40MHz）を使用してHSE_Send()付近で計測したタイミング

測定コード

c

static uint8_t  digest[64]  __attribute__((aligned(32), section(".mcal_bss_no_cacheable")));
static uint32_t digest_len  __attribute__((aligned(32), section(".mcal_bss_no_cacheable")));

static uint32_t hash_time_ms(hseHashAlgo_t algo, const uint8_t *msg, uint32_t len, uint32_t *rsp)
{
    hseSrvDescriptor_t *desc = &gHseSrvDesc[0][1];
    hseHashSrv_t *hsh = &desc->hseSrv.hashReq;

    digest_len = sizeof(digest);
    memset(desc, 0, sizeof(*desc));
    desc->srvId      = HSE_SRV_ID_HASH;
    hsh->accessMode  = HSE_ACCESS_MODE_ONE_PASS;
    hsh->hashAlgo    = algo;
    hsh->sgtOption   = HSE_SGT_OPTION_NONE;
    hsh->inputLength = len;
    hsh->pInput      = HSE_PTR_TO_HOST_ADDR(msg);        /* PFLASH */
    hsh->pHashLength = HSE_PTR_TO_HOST_ADDR(&digest_len);
    hsh->pHash       = HSE_PTR_TO_HOST_ADDR(digest);

    uint32_t t0 = ~IP_PIT_0->TIMER[1].CVAL;              /* 40 MHz up-counter */
    *rsp = HSE_Send(0, 1, gSyncTxOption, desc);
    return ((~IP_PIT_0->TIMER[1].CVAL) - t0) / 40000u;   /* ms */
}

t256 = hash_time_ms(HSE_HASH_ALGO_SHA2_256, (const uint8_t *)0x00500000, 0x2D3F80, &rsp256);
t512 = hash_time_ms(HSE_HASH_ALGO_SHA2_512, (const uint8_t *)0x00500000, 0x2D3F80, &rsp512);

EdDSA検証は、HSE_SIGN_EDDSA、bHashEddsa = FALSE（純粋なEd25519）、bInputIsHashed = FALSE、および同じメッセージポインタと長さを指定した、1パスのHSE_SRV_ID_SIGNリクエストです。鍵となるのは、RAMスロットにインポートされたED25519公開鍵です。

結果（すべてのリクエストがHSE_SRV_RSP_OKを返しました）

処理時間：2,965,376バイト

SHA-256	HSE-B（HW）	38ミリ秒
SHA-512	HSE-B（ソフトウェアエミュレーション）	26,010ミリ秒
Ed25519 検証 (純粋)	HSE-B	26,019ミリ秒
Ed25519 検証 (純粋)	Cortex-M7ソフトウェア、160MHz、-O2、Dキャッシュオン	952ミリ秒

つまり、HSEの検証はM7ソフトウェアの実装より約27倍遅いです。ほとんどの場合、メッセージに対するSHA-512: 検証マイナスSHA-512は約9ミリ秒です。

質問

約114 KB/秒（80 MHzで約700 HSEサイクル/バイト）は、HSE-BにおけるSHA-512の想定スループットでしょうか、それとも弊社側の設定上の問題（例えば、HSEからのフラッシュ読み取りパスなど）を示しているのでしょうか？
FW 0.2.40.0はSHA-512/EdDSAのパフォーマンスにおいて0.2.55.0と異なる挙動を示す可能性はありますか?HASHおよびSIGNサービスで、FW 0.2.40.0に対して0.2.55.0インターフェースヘッダーを実行させることはサポートされていますか?
HSE-Bで高速画像認証を行う場合、推奨される方法はECDSA P-256とSHA-256ですか?それともハードウェアアクセラレーションダイジェストでEd25519を使用するサポート方法はありますか?

シリコンに関する注意事項
当社の部品はSBAF 0.10.0の初期シリコン製なので、HSE FW 0.2.55.0をインストールできず、0.2.40.0に制限されています。この古いSBAF/FWの組み合わせが、現在の部品よりもSHA-512ソフトウェアエミュレーションを遅くする可能性があるかどうか知りたいです。とはいえ、私たちの理解では、新しいFWを使っても、HSEコアで80MHzでエミュレートしたSHA-512は、Cortex-M7の160MHz(完全なEd25519検証で952ms、HSEで約26秒)に近づくことはできません。私たちの設定に問題がなければ、M7ではEd25519の認証を維持し、ハードウェアアクセラレーション(AES、SHA-256)でのみHSEを使用する予定です。この結論が間違っている場合は、ご指摘ください。

よろしくお願いいたします。

ファビオ

Re: HSE-B SHA-512 / Ed25519 verify timings on S32K344 – are these figures expected?

こんにちは、 @FabioGさん

測定結果は妥当なようだ。Ed25519の長い検証時間は、ほぼ完全にSHA-512による~2.97のプロセッシングによって引き起こされます。MBメッセージ。

あなたの結果と一致するベンチマークデータを持っています。HSE_CLK = 120MHzの場合、24KBのデータに対するハッシュ演算は約140msかかります。これを80MHz、メッセージサイズ約2.97MBにスケーリングすると、約26.5秒となり、これは測定値と非常に近い値です。

上記HSEファームウェアのバージョン間には、パフォーマンス上の違いはありません。軽微なアップデートといくつかのバグ修正が含まれています。これは完全にソフトウェアエミュレーションが原因です。

画像認証性能が重要な場合、ECDSA P-256とSHA-256の組み合わせはHSE-B上でより高速な選択肢となります。SHA-256はハードウェアアクセラレーションに対応しています。私が持っているベンチマークデータに基づくと、同じもののECDSA P-256/SHA-256検証は約2.97です。80 MHzでのMB画像は約0.3秒と推定でき、Ed25519は約26秒かかります。これは単純なスケーリングであり、ハードウェアでの確認はしていませんのでご注意ください。

よろしくお願いいたします。

ルーカス