case03（再識別デモ）: 攻撃の設計 — 4/7¶

再識別デモの流れ

弱点の評価で見た2つの弱点を、どう組み合わせれば再識別できるか——攻撃者の手順を設計します。これは「攻撃を推奨する」ためではなく、安易な匿名化がいかに脆いかを具体的に理解し、正しい対策に結びつけるための教材です。

攻撃の全体像¶

flowchart TD
    A["公開データ（ハッシュ化済み履歴）<br/>運転者ハッシュ＋乗降・料金"] --> B
    K["攻撃者が知っている1件<br/>自分が乗った運転手のID（乗務員証）"] --> B
    B["① 加工方法の特定<br/>sha256(既知ID) が公開データに一致するか"] -->|一致した| C
    B -->|一致しない| X["別の加工方法を疑う<br/>（ソルト・鍵・別アルゴリズム）"]
    C["② 総当りで対応表を構築<br/>公知フォーマット 100-NNN-NNN を全列挙し<br/>ハッシュ→ID の逆引き表を作る"] --> D
    D["③ 公開履歴のハッシュを引き当て<br/>運転者IDを全行に復元"] --> E["再識別された走行履歴<br/>「誰が」いつ・どこを走ったか"]

各ステップの狙い¶

ステップ	やること	効かせる弱点	得られるもの
① 加工方法の特定	既知の運転者ID（自分が乗った運転手）を `SHA-256` にかけ、公開データのハッシュ列に一致があるか確認	② 単純な無ソルト SHA-256	「加工は無ソルト `SHA-256`」という確証
② 対応表の構築	公知フォーマット `100-NNN-NNN` の全候補（約100万通り）を計算し、`ハッシュ→ID` の対応表を作る	① 形式が公知・低エントロピー	逆引き表（レインボーテーブル相当）
③ 全復元	公開履歴の各行の運転者ハッシュを対応表で引き当て、元の運転者IDに置換	①② の合わせ技	運転者IDを復元した走行履歴

なぜ「①方法の特定」が要るの？いきなり総当りでは？

総当り（②）はいつでもできますが、加工方法が分からなければ「何を」総当りすべきか決まりません（ソルト付きか、HMACか、そもそも別アルゴリズムか）。攻撃者は既知の1件（自分が乗った運転手のIDとそのハッシュ）を使って、「素の SHA-256 を全候補にかければ一致する」と先に確かめてから、安心して総当りに進みます。たった1つの既知の平文が、加工方法全体を暴く鍵になる——ここが弱点②の怖さです。

①と②がそろうと何が起きるか

①だけ（方法は分かるが候補が無限）: 総当りは非現実的で復元できない。
②だけ（候補は少ないが方法が不明）: 何を計算すればいいか分からない。
①＋②（本件）: 「素の SHA-256 を、約100万通りの候補に」総当りするだけ。数秒で全運転者IDが復元され、公開履歴が「誰の記録か」丸わかりになる。

この設計が示すこと（対策への布石）¶

攻撃が成立する条件を裏返すと、そのまま対策になります（詳細は結果）。

候補を絞らせない: IDそのものを公開データに出さない／十分に長いランダムな仮IDに置換する。
ハッシュの使い回しを防ぐ: ソルトや秘密鍵つきハッシュ（HMAC）で、同じIDでも出力が再現できないようにする。
そもそも粒度を落とす: 個人単位の識別子を残さず、一般化・集計して連結できないようにする（＝匿名加工の考え方 / case02）。

→ 具体的な処理は攻撃の仕様、実行は ② 実装（Colab）、復元後のスキーマは復元後テーブル。