Chapter 09

署名と検証 — 公開鍵で「誰が」を証明する

この章のゴール.

psa_sign_hash / psa_verify_hash と psa_sign_message / psa_verify_message の違い、 ECDSA・EdDSA・RSA の署名のバイト列形式、 そして「ハッシュ長は署名アルゴリズムのハッシュと一致させる」規則を理解し、 装置の認証や OTA イメージの検証を書けるようになること。

この章で使う既出の用語（定義は各リンク先）. PSA（01 章 1 節）、ビット（02 章 4 節）、algorithm（03 章 11 節）、type（03 章 11 節）、usage（03 章 11 節）、場所（03 章 7 節）、import（04 章 10 節）、ビッグエンディアン（04 章 2 節）、ハッシュ（05 章 1 節）、乱数（05 章 1 節）、MAC（06 章 1 節）、対称暗号（07 章 1 節）

1. 署名とは何か — MAC との違い

デジタル署名は、秘密鍵で作り、公開鍵で検証する認証値である。 MAC（06 章）と違い、検証できる者が作れるとは限らない。 検証側は公開鍵しか持たないので、偽造できない。 だから署名は「誰が作ったか」の証明——認証（authentication）と、後で「作っていない」と言えなくする否認防止（non-repudiation）に使える。

2. アルゴリズムと鍵種別

新規設計では ECDSA P-256 + SHA-256、または Ed25519である。 RSA は署名が 4 倍長く、鍵生成が遅く、マイコンでの検証も遅いが、「サーバ側が RSA しか出せない」ことがまだある。

鍵の属性は、署名側が PSA_KEY_USAGE_SIGN_HASH（または SIGN_MESSAGE）、検証側が PSA_KEY_USAGE_VERIFY_HASH（または VERIFY_MESSAGE）。 03 章の表のとおり、SIGN_HASH は SIGN_MESSAGE を含む（ハッシュに署名できるなら、メッセージをハッシュして署名することもできる）。逆は含まない。

3. hash 版と message 版

署名の関数は 2 組ある。

/* ハッシュ済みのデータに署名する */
psa_status_t psa_sign_hash(psa_key_id_t key, psa_algorithm_t alg,
                           const uint8_t *hash, size_t hash_length,
                           uint8_t *signature, size_t signature_size, size_t *signature_length);
psa_status_t psa_verify_hash(psa_key_id_t key, psa_algorithm_t alg,
                             const uint8_t *hash, size_t hash_length,
                             const uint8_t *signature, size_t signature_length);

/* メッセージそのものを渡す（内部でハッシュする） */
psa_status_t psa_sign_message(psa_key_id_t key, psa_algorithm_t alg,
                              const uint8_t *input, size_t input_length,
                              uint8_t *signature, size_t signature_size, size_t *signature_length);
psa_status_t psa_verify_message(psa_key_id_t key, psa_algorithm_t alg,
                                const uint8_t *input, size_t input_length,
                                const uint8_t *signature, size_t signature_length);

sign_hash に渡すハッシュの長さは、アルゴリズム定数の中のハッシュの出力長と一致していなければならない。 PSA_ALG_ECDSA(PSA_ALG_SHA_256) に 20 バイトの SHA-1 ハッシュを渡すと PSA_ERROR_INVALID_ARGUMENT である。 ECDSA は数学的にはどんな長さでも受け付けるが、PSA は「宣言と違う使い方」を禁止する。

4. ファームウェアイメージの検証 — 典型コード

OTA（無線ファームウェア更新）で受け取ったイメージの署名を検証する、最も典型的な使い方である。 イメージは大きいので、分割ハッシュ + verify_hash で書く。

/* 製造時に書き込んだ、更新サーバの公開鍵（65 バイト 04||X||Y） */
static const uint8_t server_pub[65] = { 0x04, ... };

psa_status_t verify_image(uint32_t addr, size_t len, const uint8_t sig[64])
{
    psa_key_attributes_t attr = PSA_KEY_ATTRIBUTES_INIT;
    psa_key_id_t pub = PSA_KEY_ID_NULL;
    uint8_t hash[32]; size_t hash_len;
    psa_status_t st;

    /* 公開鍵を揮発鍵として取り込む（毎回でよい。安い） */
    psa_set_key_type(&attr, PSA_KEY_TYPE_ECC_PUBLIC_KEY(PSA_ECC_FAMILY_SECP_R1));
    psa_set_key_usage_flags(&attr, PSA_KEY_USAGE_VERIFY_HASH);
    psa_set_key_algorithm(&attr, PSA_ALG_ECDSA(PSA_ALG_SHA_256));
    st = psa_import_key(&attr, server_pub, sizeof server_pub, &pub);
    psa_reset_key_attributes(&attr);
    if (st != PSA_SUCCESS) goto cleanup;

    st = hash_flash_region(addr, len, hash);          /* [05 章](05_乱数とハッシュ.md#psahashclone-途中まで計算した状態を分岐する)の関数 */
    if (st != PSA_SUCCESS) goto cleanup;

    st = psa_verify_hash(pub, PSA_ALG_ECDSA(PSA_ALG_SHA_256), hash, 32, sig, 64);
    /* PSA_SUCCESS: 正当  /  PSA_ERROR_INVALID_SIGNATURE: 不正 */
cleanup:
    psa_destroy_key(pub);
    return st;
}

公開鍵を「揮発鍵として毎回 import する」でよいのか.

公開鍵は秘密ではなく、import は数十 µs で終わる。 永続鍵にする理由は「ID で参照したい」「TF-M のセキュア側に置いて非セキュア側から差し替えられないようにしたい」場合である。 後者は重要である——検証用の公開鍵を攻撃者が差し替えられるなら、署名検証は無意味になる。 ブートローダの公開鍵は書き換え不能な領域（OTP や TF-M の read-only 鍵）に置く（iotsec 編 05 章）。

5. 装置の認証 — チャレンジ応答

サーバが「お前は本当に装置 #1234 か」を確かめる手順である。

1. サーバが乱数（チャレンジ、32 バイト）を送る
2. 装置が秘密鍵でチャレンジに署名して返す
3. サーバが登録済みの公開鍵で検証する

装置側:

uint8_t sig[PSA_SIGN_OUTPUT_SIZE(PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1), 256,
                                 PSA_ALG_ECDSA(PSA_ALG_SHA_256))];   /* 64 */
size_t sig_len;
PSA_CHECK(psa_sign_message(KEY_ID_DEVICE_SIGN, PSA_ALG_ECDSA(PSA_ALG_SHA_256),
                           challenge, 32, sig, sizeof sig, &sig_len));

チャレンジが乱数である理由は、再送攻撃（過去の署名を再利用する）を防ぐためである。 また、サーバが送ってきた任意のデータにそのまま署名してはいけない——署名対象に「これはチャレンジ応答である」という種別バイトや文脈情報を混ぜる（14 章のアテステーションはこの問題を構造的に解決する）。

6. 署名のバイト列形式

署名の形式は、他のライブラリと相互運用するときに必ず躓く点である。

DER 形式の ECDSA 署名を PSA に渡すには、30 len 02 len r 02 len s を解析して r と s を取り出し、それぞれ 32 バイトに 0 詰めして連結する。 r や s の先頭バイトが 0x80 以上のとき DER は 0x00 を前置して 33 バイトにするので、その 0x00 を落とす必要がある。 Mbed TLS では mbedtls_ecdsa_der_to_raw() / mbedtls_ecdsa_raw_to_der() が用意されている（3.6 以降）。

7. 公開鍵暗号（非対称暗号化）

署名と同じ公開鍵の仕組みを「暗号化」に使うのが非対称暗号化である。 公開鍵で暗号化し、秘密鍵でしか復号できない。用途は小さな秘密（対称鍵など）を相手に渡すことに限られる（RSA-2048 で最大 190 バイト程度。速度も遅い）。

psa_status_t psa_asymmetric_encrypt(psa_key_id_t key, psa_algorithm_t alg,
                                    const uint8_t *input, size_t input_length,
                                    const uint8_t *salt, size_t salt_length,
                                    uint8_t *output, size_t output_size, size_t *output_length);
psa_status_t psa_asymmetric_decrypt(psa_key_id_t key, psa_algorithm_t alg, ...同じ引数...);

楕円曲線には「暗号化」の関数がない。楕円曲線で秘密を共有するには鍵合意（11 章）を使う。 実際の設計では、RSA-OAEP よりも ECDH + AEAD（11 章の「ハイブリッド」）を選ぶことが多い。

8. 手を動かす

署名の流れとサイズを見る

9. 仕様書に逃がす

この章のポイント

• 署名は秘密鍵で作り、公開鍵で検証。検証者は偽造できない（MAC との決定的な違い）
• ECDSA P-256 + SHA-256 または Ed25519 を選ぶ。乱数に不安があれば DETERMINISTIC_ECDSA
• sign_hash は自分でハッシュを計算して渡す（大きなデータ向け）。sign_message は内部でハッシュ。Ed25519 は message 版のみ
• ハッシュの長さはアルゴリズム定数のハッシュと一致させる
• ECDSA の署名は r ∥ s の 64 バイト。DER と相互変換が必要な場面が多い
• 検証用の公開鍵は攻撃者に差し替えられない場所に置く