AIでつくる人のセキュリティ 第1章を読む →
トップ›世界水準編›第25章
世界水準編第25章

暗号の基礎：ハッシュ・署名・TLS・パスワード保存

読む目安：約50分自分で作らず、定評ある部品を正しく使う。4つの道具と保存の正解

暗号は、非エンジニアが最も「分からないから触らない」領域です。それで正解です。暗号を「作る側」になる必要はありません。しかし「使う側」として、4つの道具が何をしてくれるのか、パスワードをどう保存するのが正解なのか、何をしてはいけないのかは知っておく必要があります。論文では「暗号化の不備」が112件（9.44%）あり、その多くは難しい数学の誤りではなく、使い方の誤りでした。

この章の学習目標

  • ハッシュ、共通鍵暗号、公開鍵暗号と電子署名、TLSの4つの道具が「何を守るか」を、経理の比喩で説明できるようになる
  • パスワード保存の正解（ソルト付きの専用関数）と、OWASPが示す現行の推奨パラメータを言え、自分のアプリの保存方法を確かめられるようになる
  • 自作暗号、固定鍵のハードコード、鍵とデータの同居、HTTPのまま、という4つの「やってはいけないこと」を自分のアプリで点検できるようになる

使う側の原則：自分で作らない

OWASPのCryptographic Storage Cheat Sheetは、「独自のアルゴリズム」という節にたった一言、「Don't do this.（やらないこと）」と書いています。暗号の部品は、世界中の専門家が何年もかけて攻撃を試し、生き残ったものだけが標準になります。個人やAIがその場で考えた仕組みが、同じ水準に達することはありません。

これはNIST SSDFのPW.4「自作せず、実績ある安全な部品を再利用する」（第22章）そのものです。経理に置き換えれば、「金庫は自作せず、認証を受けた製品を買う」ということです。「使う側」がやるべきことは、正しい部品を選び、正しい設定で使い、鍵を正しく置くことだけです。

4つの道具

ハッシュ 一方向の指紋 文書 指紋 同じ文書 → 同じ指紋 1字違えば → 別の指紋 指紋から文書には戻せない 改ざん検知・パスワード保存 （専用関数＋ソルト） 共通鍵暗号 同じ鍵で施錠と開錠 平文 暗号文 鍵 K で暗号化、同じ K で復号 速い。鍵の受け渡しが課題 保存データの暗号化 （AES、認証付きモード） 公開鍵と電子署名 代表印と印鑑証明 秘密鍵（代表印）：本人だけが持つ 公開鍵（印鑑証明）：誰でも持てる 署名 検証 秘密鍵で署名、公開鍵で確かめる 来歴証明・証明書 （第24章のSigstore） TLS 通信路の封筒 ブラウザ サーバー 途中で読まれない・書き換えられない 相手が本物かを証明書で確かめる https:// のこと （TLS 1.2 / 1.3）
図25-1　4つの道具。上の3つを組み合わせて作られた「通信路の封筒」がTLSです。

ハッシュ：一方向の指紋

ハッシュ関数は、どんな長さの文書からも固定長の「指紋」を作ります。同じ文書からは必ず同じ指紋ができ、1文字でも違えば別の指紋になり、指紋から元の文書には戻せません。SBOM（第24章）に「部品のハッシュ値」を入れるのは、改ざんされていないことを指紋で確かめるためです。ASVS 5.0の 11.4.1 は、MD5のような古いハッシュ関数を暗号の用途に使ってはならないと定めています。

共通鍵暗号：同じ鍵で施錠と開錠

金庫と同じで、閉めるときと開けるときに同じ鍵を使います。速く、大量のデータに向きます。課題は「鍵をどう相手に渡すか」と「鍵をどこに置くか」です。OWASPのCheat Sheetは、AESを128ビット以上（できれば256ビット）の鍵で、GCMなどの認証付きモードで使うことを推奨し、ECBモードは使わないよう求めています。ASVS 5.0の 11.3.1 と 11.3.2 も同じ内容です。

公開鍵暗号と電子署名：代表印と印鑑証明

鍵が2本で1組になっています。秘密鍵は本人だけが持ち、公開鍵は誰でも持てます。秘密鍵で付けた署名は、公開鍵で「確かに本人が付けた」と確かめられます。経理の人には、秘密鍵が代表印、公開鍵が印鑑証明書、と言えば通じるはずです。第24章のSigstoreやnpm provenanceは、この仕組みで来歴に署名しています。TLSの証明書も、「このサーバーは本物だ」を公開鍵で証明するものです。

TLS：通信路の封筒

TLS（Transport Layer Security）は、上の3つを組み合わせて、ブラウザとサーバーの間の通信を「途中で読めず、書き換えられず、相手が本物だと分かる」状態にします。URLの https:// がそれです。OWASPのTLS Cheat Sheetは、TLS 1.3を既定とし互換性のためにTLS 1.2を残してよいこと、TLS 1.0と1.1はRFC 8996（2021年3月）で廃止されたので無効にすべきこと、「ログイン画面だけでなく、すべてのページ」をTLSにすべきことを示しています。ASVS 5.0の 12.1.1 と 12.2.1 に当たります。Vercelで公開していれば、証明書とTLSの設定は自動です（第12章）。

パスワード保存の正解

第10章で「平文保存は論外」と言いました。ここで、何が正解かを原典で確かめます。OWASPのPassword Storage Cheat Sheetは、次の順で推奨しています。本稿執筆時点（2026年10月）のページから転記したもので、数値は改訂されることがあります。

優先順関数推奨パラメータ（最小）備考
1Argon2idメモリ19 MiB、反復2回、並列度1第一選択。メモリと反復の組み合わせは複数示されている（例：46 MiB・1回、12 MiB・3回）
2scryptN=2の17乗（128 MiB）、r=8、p=1Argon2idが使えないとき
3bcryptwork factor 10以上既存システム向け。入力は72バイトまでなので、長いパスワードを切り詰めないよう上限を設ける
4PBKDF2-HMAC-SHA256600,000回FIPS-140準拠が必要なとき。SHA512なら220,000回

共通するのは3点です。第一に、SHA-256のような「速い」ハッシュ関数は使わない。Cheat Sheetは「速いハッシュはパスワード保存に適さない」と明記しています。速いということは、攻撃者が1秒に何億回も推測を試せるということだからです。上の4つは、わざと時間とメモリを食うように設計された「パスワード専用」の関数です。第二に、ソルト（利用者ごとに異なる乱数）を必ず付ける。同じパスワードでも別の値になり、事前計算した表が使えなくなります。たいていのライブラリは自動で付けます。第三に、ペッパー（全利用者共通の秘密）を加えるなら、ハッシュと同じ場所に置かない。

ASVS 5.0では、11.4.2（L2）が「承認された計算コストの高い鍵導出関数で、現行の指針に基づくパラメータで保存する」ことを求めています。L1には保存方式の要件がなく、「パスワードを自分で保存する時点でL2の話」という読み方もできます。

今すぐやること：保存を認証基盤に任せる 個人開発の現実解は、パスワードの保存を自分でやらないことです。Supabase Authの公式ドキュメントは、パスワードをbcryptでハッシュ化し、ハッシュごとに個別のソルトを付けて保存すると説明しています。さらに、HaveIBeenPwnedの漏えいパスワード一覧と照合して既知の漏えいパスワードを拒否する機能もあります（有料プランが必要です）。あなたのテーブルにパスワードの列が無く、認証がSupabase Authに任されているなら、この章の「正解」はすでに実装されています。確かめるべきは「本当に自前で保存していないか」の一点です。

やってはいけないこと

  • 自作の暗号化。「文字をずらす」「独自の変換をかける」といったものは、暗号ではありません。AIに「暗号化して」とだけ頼むと、こうしたものを書くことがあります。定評あるライブラリを使い、AESなら認証付きモードを指定します。
  • 固定鍵のハードコード。コードの中に SECRET_KEY = "..." と書いてある状態です。論文の「デモ志向の設計」174件（14.7%）には、この種のものが含まれます。Cheat Sheetも「鍵をソースコードにハードコードしない」と明記しています。鍵は第9章の通り、環境変数などコードの外に置きます。
  • 鍵とデータの同居。暗号化したデータと、その鍵が同じ場所（同じデータベース、同じバックアップ）にある状態です。Cheat Sheetは「可能な限り、鍵は暗号化データとは別の場所に保管する」としています。金庫の鍵を金庫の上に置くのと同じです。
  • HTTPのまま。通信が封筒に入っていない状態です。ログイン情報も入力内容も、途中で読めます。「ログイン画面だけHTTPS」は不十分で、全ページをHTTPSにします。
  • 古い部品。MD5やSHA-1を暗号の用途に使う、ECBモードを使う、TLS 1.0や1.1を許す。いずれもASVS 5.0のL1要件（11.3.1、11.4.1、12.1.1）に反します。

耐量子暗号：L3の話題として知っておく

将来の量子計算機は、現在の公開鍵暗号（RSAや楕円曲線暗号）を破ると見込まれています。これに備える暗号を耐量子暗号（PQC、Post-Quantum Cryptography）と呼びます。ASVS 5.0のV11は、この移行を「重要」と位置づけ、11.1.4（L3）で「暗号の棚卸しを維持し、耐量子暗号などの新しい標準への移行計画を文書化する」ことを求めています。あわせて 11.2.2 は、アルゴリズムや鍵長をいつでも差し替えられる「暗号の俊敏性」を求めています。ASVSの付録Cは、PQCの実装がNISTのFIPS 203、204、205に従うべきだとしています。

個人開発でいますぐ何かをする話ではありません。しかし「自分のアプリで使っている暗号の一覧（棚卸し）」を持つことは、L3を待たずに価値があります。TLSはVercel任せ、パスワードはSupabase Auth任せ。そう書けるなら、移行のときに変える場所も明らかです。

ハッシュ
文書から固定長の指紋を作る一方向の関数。改ざん検知に使う。パスワードには「速い」ハッシュではなく専用関数を使う。
ソルト
パスワードをハッシュ化する前に加える、利用者ごとの乱数。同じパスワードでも別のハッシュ値になる。
ペッパー
全利用者に共通の秘密値。ハッシュとは別の場所に保管する。データベースだけが漏れたときの多層防御。
共通鍵暗号
同じ鍵で暗号化と復号をする方式。AESが代表。認証付きモード（GCMなど）で使う。
公開鍵暗号
秘密鍵と公開鍵の対で動く方式。秘密鍵で署名し公開鍵で検証する（電子署名）。代表印と印鑑証明の関係。
TLS
通信路を守る仕組み。https。TLS 1.2と1.3を使い、1.0と1.1は無効にする。
耐量子暗号（PQC）
量子計算機でも破られないよう設計された暗号。ASVS 5.0ではL3で移行計画の文書化を求める。
AIへの頼み方（パスワード保存と暗号の使い方の確認）
このリポジトリの暗号の使い方をレビューしてください。報告だけで、修正はまだしないでください。
秘密情報の値そのものは絶対に出力しないでください。

1. パスワードの保存
   - このアプリは、パスワードを自前で保存していますか。保存しているなら、どのファイルの、どの処理で、どの関数（Argon2id／scrypt／bcrypt／PBKDF2／それ以外）を使い、パラメータはいくつですか
   - 認証サービス（Supabase Auth など）に任せている場合は、自前のテーブルにパスワードやその派生物を保存している箇所が無いことを確認してください
2. 暗号化
   - 独自に実装した「暗号化」らしき処理（文字の置換、独自の変換）が無いかを探してください
   - AESなどを使っている箇所があれば、モード（GCM／CBC／ECB など）と鍵長を報告してください
3. 鍵の置き場所
   - 暗号鍵、署名鍵、APIキーがコード内に文字列として書かれていないか。環境変数から読んでいるか
   - 暗号化したデータと鍵が同じ保存先にないか
4. 通信
   - 外部サービスへの通信に http:// のURLが無いか
   - ハッシュにMD5やSHA-1を暗号の用途で使っていないか
5. OWASP ASVS 5.0 の 11.3.1、11.3.2、11.4.1、11.4.2、12.1.1、12.2.1 のそれぞれについて、満たす／満たさない／該当なし／判断できない を根拠付きで報告してください

演習：自分のアプリの暗号の使い方を点検する

所要時間：約30分
  1. 第8章の全体図で、鍵のマークが付いた場所と、データベースの箱を見直します。「パスワード」「暗号化」「署名」に関わる処理がどこにあるかを書き出します。
  2. 認証をSupabase Authに任せているなら、Table Editorで自分のテーブルに password のような列が無いことを確かめます。あれば、その中身が元の文字のままでないか（第10章）を確かめ、自前保存をやめる方針を立てます。
  3. 上の定型文でAIにレビューさせ、結果を点検ノートに写します。「独自に実装した暗号化らしき処理」が見つかったら、それは最優先の修正対象です。
  4. 自分のアプリと、呼び出している外部サービスのURLがすべて https:// であることを確かめます。ブラウザで自分のアプリの任意のページを開き、アドレス欄の鍵マークを確認します。
  5. 「暗号の棚卸し」として、「用途／使っている部品／誰が管理しているか（Vercel・Supabase・自分）」の3列の表を作ります。TLS、パスワード、セッション、署名の4行で十分です。
  6. 結果を点検ノートに日付入りで残し、第20章の採点表のV11・V12の行を更新します。
注意：確認は自分のアプリに限る この章の確認（鍵マークの目視、テーブルの列の確認、AIによるコードレビュー）は、自分が作り、自分が管理するアプリとリポジトリに対してのみ行ってください。他人のサービスの暗号の強さやTLSの設定を「診断」する行為は、相手の許可がない限り行わないでください。

まとめ

  • 暗号は「作らず、使う」。OWASPは独自アルゴリズムについて「やらないこと」と一言で断じている。4つの道具は、ハッシュ（一方向の指紋）、共通鍵暗号（同じ鍵で施錠・開錠、AESの認証付きモード）、公開鍵暗号と電子署名（代表印と印鑑証明）、TLS（通信路の封筒、TLS 1.2／1.3、全ページで）。
  • パスワードは平文でも速いハッシュでもなく、ソルト付きの専用関数で保存する。OWASPの推奨順はArgon2id（19 MiB・2回・並列1）、scrypt、bcrypt（work factor 10以上、72バイト制限）、PBKDF2-HMAC-SHA256（600,000回）。個人開発の現実解は、Supabase Authなどの認証基盤に任せ、自前のテーブルにパスワードを持たないこと。
  • やってはいけないのは、自作暗号、固定鍵のハードコード、鍵とデータの同居、HTTPのまま、古い部品（MD5、ECB、TLS 1.0／1.1）。耐量子暗号への移行計画はASVS 5.0のL3要件（11.1.4）。今は「暗号の棚卸し表」を持っていれば十分。

出典