変更要約: 初版
1.4暗号化の方式と適用
同じ鍵で速い対称鍵暗号と、鍵配送を解く非対称鍵暗号の違い、暗号化ではなく完全性を守る一方向のハッシュ、公開鍵の真正性を保証する証明書とPKI、強い/弱いアルゴリズム、そして転送中/保存時/使用中というデータの状態に応じた守り方を、「このデータ状態にどの暗号化か」を選ぶ基礎として学びます。
暗号化は「見られても読まれない」を実現する中心的な道具ですが、その使いどころを誤ると、守ったつもりで守れていないという事故が起きます。速いが鍵の配り方が難しい方式、鍵配送は解けるが遅い方式、そもそも暗号化ではなく「改ざんの検知」に使う仕組みなど、それぞれ役割が違うからです。この節では、対称鍵暗号と非対称鍵暗号の違い、暗号化と混同されやすいハッシュ、公開鍵の正しさを保証する証明書とPKI、強い/弱いアルゴリズム、そして転送中・保存時・使用中というデータの状態ごとの守り方を、暗記ではなく状況に応じて正しい道具を選ぶ視点で学びます。
1.4.1対称鍵・非対称鍵・ハッシュ
- 対称鍵暗号＝暗号化と復号に同じ鍵を使う方式（例：AES）。高速で大量データ向きだが、相手に鍵を安全に渡す鍵配送が課題。共有した鍵が漏れれば通信は解読される。
- 非対称鍵暗号（公開鍵暗号）＝公開鍵と秘密鍵のペアを使う方式（例：RSA/ECC）。公開鍵で暗号化したものは対の秘密鍵でしか復号できないため、鍵を安全に配りやすい。対称より低速なので、実務では「非対称で対称鍵を安全に共有し、本体は対称で高速に暗号化する」組み合わせがよく使われる。
- ハッシュ＝任意のデータを固定長の値に変換する一方向の関数（例：SHA-256）。元に戻せず、暗号化とは別物。改ざんの検知＝完全性の確認やパスワードの保管に使う（同じ入力なら常に同じ値、少しの変更で値が大きく変わる）。ハッシュは暗号化ではない点が最重要。
1.4.2証明書・PKI・強弱・データの状態
- 証明書（デジタル証明書）＝「この公開鍵は確かにこの相手のものだ」を保証する電子的な身分証。信頼された第三者である認証局（CA）が発行・署名する。これらの発行・失効・信頼の仕組み全体をPKI（公開鍵基盤）と呼ぶ。HTTPSの鍵マークは、正しい証明書で相手の真正性が確認できた状態。
- 強いアルゴリズム＝現在も安全とされる方式（AES-256、SHA-256、RSA-2048以上など）。弱いアルゴリズム＝解読手法が確立し使うべきでないもの（DES、RC4、MD5、SHA-1など）。強度は年々見直されるため、古い既定値をそのまま使わないことが大切。
- データの状態は3つで、守り方が違う：転送中（in transit）＝ネットワークを流れる間（TLS/IPsecで保護）、保存時（at rest）＝ディスクに置かれた状態（ディスク暗号化・BitLockerなどで保護）、使用中（in use）＝メモリ上で処理される間（アクセス制御や専用のメモリ保護で守る、最も難しい状態）。
「対称＝同じ鍵で高速だが鍵配送が課題（AES）／非対称＝公開・秘密の鍵ペアで鍵配送を解くが低速（RSA/ECC）」「ハッシュ＝一方向・完全性の確認で暗号化ではない（SHA-256）」「証明書/CAで公開鍵の真正性、全体がPKI」「強＝AES-256/SHA-256、弱＝DES/RC4/MD5」「データの状態＝転送中(TLS)/保存時(ディスク暗号)/使用中(メモリ)」が頻出です。データ状態に合う暗号化を選べるように。
あなたが「顧客情報を扱う社内Webシステムの安全性を点検してほしい」と依頼されたとします。ここで「パスワードをハッシュ化しているから暗号化は万全だ」と早合点するのは危険です。ハッシュは一方向で改ざん検知やパスワード保管には有効ですが、それは暗号化ではなく完全性のための道具で、通信や保存データの秘匿を担うものではないからです。正しくは、データの状態ごとに守り方を分けて確認します。まず転送中——利用者のブラウザとサーバの間の通信はTLS（HTTPS）で暗号化されているか、鍵マークと証明書は正当か（信頼されたCAが発行し、期限切れや不一致がないか）を見ます。TLSの内部では、遅い非対称鍵暗号で対称鍵を安全に共有し、本体の通信は高速な対称鍵暗号（AES）で暗号化する、という組み合わせが働いています。次に保存時——サーバやノートPCのディスク上の顧客データはディスク暗号化（BitLocker等）で保護されているか。盗難や紛失時に読み取られないためです。最後に使用中——メモリ上で処理される瞬間のデータは最も守りにくく、アクセス制御や不要なメモリダンプの抑止で補います。加えて、使われている方式が強いアルゴリズムか（AES-256/SHA-256なら良好、DES/RC4/MD5/SHA-1のような弱いアルゴリズムが残っていないか）を点検します。ここで大切なのは、「暗号化しているか」ではなく「どの状態のデータを、どの道具（TLS／ディスク暗号／ハッシュ）で、十分に強いアルゴリズムで守っているか」を状態ごとに切り分けて確認するという考え方です。入門段階では、この「状態×道具×強度」の物差しを持つことが、守ったつもりの穴を見つける近道になります。
| 道具/状態 | 役割 | 代表例 |
|---|---|---|
| 対称鍵暗号 | 同じ鍵で高速に暗号化（鍵配送が課題） | AES |
| 非対称鍵暗号 | 鍵ペアで鍵配送を解く（低速） | RSA / ECC |
| ハッシュ | 一方向・完全性の確認（暗号化ではない） | SHA-256 |
| 転送中の保護 | ネットワークを流れる間の暗号化 | TLS / IPsec |
| 保存時の保護 | ディスク上のデータの暗号化 | BitLocker / ディスク暗号 |
ひっかけ： 「ハッシュ化していれば元のデータを暗号化して秘匿できている」は誤りです——ハッシュは一方向で完全性の確認やパスワード保管に使う道具であり、暗号化ではありません（元に戻して読ませる用途ではない）。また「通信をTLSで暗号化すれば、保存されたデータも自動的に暗号化される」も誤り＝転送中（TLS）と保存時（ディスク暗号）は別の状態で、それぞれ別に対策が必要です。
1.4.3この節のまとめ
- 対称鍵暗号（AES）は同じ鍵で高速だが鍵配送が課題、非対称鍵暗号（RSA/ECC）は鍵ペアで配送を解くが低速。ハッシュ（SHA-256）は一方向で完全性用＝暗号化ではない
- 証明書とCAで公開鍵の真正性を保証し全体がPKI。強＝AES-256/SHA-256、弱＝DES/RC4/MD5を使い分ける
- データの状態で守り方が違う：転送中＝TLS/IPsec、保存時＝ディスク暗号、使用中＝メモリ保護。状態ごとに切り分けて確認する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 社内Webシステムの点検で「パスワードをSHA-256でハッシュ化しているので、通信も保存データも暗号化されており安全だ」と報告があった。この主張の評価として最も適切なものはどれか。
Q2. 大量のデータを高速に暗号化したいが、通信相手へ鍵を安全に渡す方法が課題になる暗号方式はどれか。また実務での一般的な組み合わせとして正しいものはどれか。
Q3. ノートPCが盗難に遭ってもディスク内の顧客データが読み取られないようにしたい。この「保存時（at rest）」のデータを守るのに最も適した対策はどれか。