デジタル署名と検証の基礎まとめ

はじめに

IoTシステム（特にデバイス側）のセキュリティについて考える機会がありました。
具体的には、単なるデータの暗号化（盗聴防止）だけなく、「誰が送ってきたか（真正性）」と「途中で書き換えられていないか（完全性）」を証明するという「デジタル署名」についてです。
デバイス側の署名検証とサーバ側の署名検証の双方向の話があり、整理しきれていなかったので整理しました。

1. デジタル署名とは？（基本の仕組み）

デジタル署名は、以下の3つの脅威を解決するための仕組みです。

脅威	リスク	対応するセキュリティ要件
改ざん	通信途中で第三者がデータを書き換え、誤作動を引き起こす	完全性（データが元のままであること）
なりすまし	攻撃者が正規の機器やサーバーのふりをされる	真正性（送信者が本人であること）
事後否認	「自分は送っていない」と後から主張される	否認防止（送信の事実の証明）

簡単な流れ

• 送信者
  1. 送りたいデータのハッシュ値を計算する。
  2. 計算したハッシュ値と秘密鍵で署名を作成する。
  3. 送りたいデータと署名を（構成によっては公開鍵も）セットで送付する。
• 受領者
  1. 受け取ったデータのハッシュ値を計算する。
  2. 「自身で計算したハッシュ値」と「受け取った署名」を公開鍵で検証する。
  3. 検証が成功すれば、改ざんされていないし、なりすましもされていないと判断する。

検証とは

デジタル署名で検証が成功するということは、以下が数学的に証明されたことになります。

1. 「受領者が計算したハッシュ値」と「送信者が署名に使ったハッシュ値」が一致すること
   ハッシュ関数の結果は元のデータが1ビットでも変更されれば全く違う値になります。つまり、送りたいデータと受け取ったデータのハッシュ値が一致すれば改ざんされていないと判断できます。
2. 「受領者が検証に使った公開鍵」と「送信者が署名に使った秘密鍵」がペアであること
   公開鍵のペアとなる秘密鍵を持っている本人しか正しい署名を作成できません。つまり、公開鍵で検証に成功すれば「本人が作成したもの」と判断できます。ただし、その公開鍵が正しいことが重要。

署名と暗号化の違い
暗号化 : 誰にも見られないように通信内容を隠すこと。
署　名 : 誰が書いたか、改ざんされていないかを証明すること。

2. 鍵ペアの管理手法

秘密鍵が漏洩すれば署名の仕組みが破綻することは自明ですが、データ受領者が「正しい公開鍵」を使わなければ正しく検証できません。そのため、秘密鍵だけでなく公開鍵の管理も重要になってきます。
（例）悪意ある第三者が、「改ざんしたデータのハッシュ値」を「偽の秘密鍵」を使って署名し「偽の公開鍵」とセットで送信したとします。この時、「偽の公開鍵」を使うと検証に成功してしまいます。つまり、改ざんやなりすましを検知できません。

秘密鍵の守り方

秘密鍵が漏洩すると誰もが正しい署名をできてしまうため、仕組みが破綻します。
単に平文保存するのではなく、セキュアエレメント（耐タンパ性のあるICチップ）やHSM、ハードウェアのセキュア領域などに閉じ込め、外部から読み出せないように実装するのが重要です。

公開鍵の正当性の保証

秘密鍵を安全に守ったうえで、「公開鍵が正しい」とどうやって保証するのかが重要です。
IoTシステムの場合、通信の方向によって難易度が大きく異なります。

【サーバからデバイスへの通信（サーバが署名・デバイスが検証）】

サーバ側が本物か証明するケースで、サーバの公開鍵をデバイスにどのように渡すか、という話です。サーバは基本的に単一（あるいは少数）のため、構成はシンプルです。

• 実現方法
  • サーバの公開鍵（またはルート証明書）を、製造時にデバイス内のセキュアな領域へ保存、もしくはプログラムへ直接ハードコーディングしておく

【デバイスからサーバへの通信（デバイスが署名・サーバが検証）】

デバイス側が本物か証明するケースで、数万〜数百万台に及ぶ「デバイスごとの公開鍵」をサーバ側にどのように渡すか／管理するかという話です。大きく3つの選択肢があります。

• 理想（ベストプラクティス）：PKI（電子証明書）の利用
  デバイスの公開鍵を第三者の認証局に登録しておく。サーバはあらかじめ知っている第三者の署名を検証することで、デバイスの公開鍵を信用する。
  サーバは多数のデバイスの公開鍵を管理する必要がないが、デバイス側の証明書発行の手間は必要。

  鍵の更新
  鍵のローテーションなど鍵を更新したい場合、デバイスの内部で新しい「秘密鍵・公開鍵」のペアを生成し、古い（が、まだ有効な）秘密鍵で作った署名と共に「新しい公開鍵の登録要求」をクラウドへ送ることで更新ができます。
  秘密鍵そのものは一切ネットワークを流れないため、遠隔からでも安全に鍵の更新が可能です。

  鍵の失効
  デバイスの盗難や物理解析の被害にあって失効したい場合、クラウド側の管理画面から「対象デバイスの証明書」を無効化するだけで完了します。
  共通鍵やハードコード手法と違い、他の数万台の正常なデバイスの鍵や設定を一切変更することなく、被害に遭った端末だけを即座にシステムから締め出せます。

• 中間：デバイス固有鍵の事前登録
  製造時にデバイスごとの鍵ペアを作成し、公開鍵をデバイスID等と紐付けてサーバのデータベースに登録しておく。サーバは受信時にDBの登録内容（当該デバイスIDの公開鍵）を信用して用いる。
  サーバのDB管理負荷（数万台分のレコード登録・維持）が発生するが、デバイス側の負担を減らしつつ「特定端末の確実な認証と、1台単位での失効」が実現できる。

• 妥協ライン：共通の秘密鍵のハードコード
  全デバイスに「全く同じ秘密鍵」をばら撒いて組み込む。サーバはペアとなる公開鍵を用いる。
  「1台漏洩すると全滅する」「どの端末が送ったか本当の意味で区別（真正性の担保）ができない」「特定端末だけの締め出し（失効）が不可能」というリスクがあります。

3. まとめ

IoTデバイスのセキュリティを担保するために署名による安全な通信について、通信の方向性ごとに整理してみました。