セキュリティ●●○○○

暗号化

データを鍵なしには読めない形に変換する技術。通信と保存の安全の基礎。

概要

暗号化とは、そのままでは誰にでも読めるデータ(平文)を、鍵を持つ者だけが元に戻せる形(暗号文)へ変換する技術です。変換のルール自体はアルゴリズムとして公開されており、秘密なのは「鍵」だけ。暗号文を手に入れても、正しい鍵がなければ元のデータを読むことは事実上不可能です。そして鍵を使って暗号文を平文に戻す操作を「復号」と呼びます。

私たちは意識しないだけで、毎日大量の暗号化のうえで生活しています。ブラウザで HTTPS のサイトを開くとき、スマートフォンでメッセージを送るとき、Wi-Fiにつなぐとき、そのすべてで通信が暗号化されています。スマートフォンやノートPCのストレージも、多くは端末ごと暗号化されており、盗まれても中身が読まれない仕組みになっています。

暗号化を考えるときの基本の問いは「誰から何を守るのか」です。通信経路の盗聴者から守るのか、サーバのディスクを盗んだ攻撃者から守るのか。この問いによって、使う技術も設計もまったく変わってきます。

なぜ生まれたか

「読まれたくない情報を、読まれない形で送りたい」という欲求は、コンピュータよりはるかに古いものです。文字をずらすだけのシーザー暗号は紀元前から使われていましたし、第二次世界大戦のエニグマ暗号機とその解読は歴史を動かしました。長い間、暗号は軍事と外交のための技術でした。

状況を変えたのがインターネットです。ネットワーク上を流れるデータは、経路上の機器を通過するたびに覗き見される可能性があります。クレジットカード番号やパスワードを平文のまま流せば、途中の誰かに読まれてしまう。商取引や個人情報のやり取りをネットワークに載せるには、「経路を信用しなくても中身は守られる」仕組みが不可欠でした。1970年代にDES、2000年代にAESといった標準暗号が整備され、さらに公開鍵暗号の発明によって「事前に鍵を共有していない相手」とも安全に通信できるようになったことで、暗号化は軍事技術から社会インフラへと変わりました。

詳細

共通鍵暗号 — 高速だが鍵配送が課題

暗号化の基本形は共通鍵暗号(対称鍵暗号)です。暗号化と復号に同じ鍵を使う方式で、代表的なアルゴリズムが AES(Advanced Encryption Standard)です。処理が非常に高速で、ハードウェア支援も普及しているため、大量のデータを暗号化する場面では事実上こちら一択です。

送信者と受信者が同じ秘密鍵をあらかじめ共有する送信者: 平文を秘密鍵で暗号化して暗号文にする暗号文をネットワーク経由で送る(途中で盗聴されても読めない)受信者: 同じ秘密鍵で暗号文を復号し、平文を取り出す
共通鍵暗号の基本フロー

ただし共通鍵暗号には「その鍵をどうやって相手に渡すのか」という根本的な問題(鍵配送問題)があります。鍵自体をネットワークで送れば盗聴されるかもしれない。この問題を解決したのが公開鍵暗号で、TLS では公開鍵暗号の仕組みで共通鍵を安全に取り決め、その後の実データは高速な共通鍵暗号で守る、というハイブリッド構成が使われています。2つの方式の使い分けを整理すると、次のようになります。

事前に安全な方法で鍵を共有できるかできるできない共通鍵暗号高速で大量データ向き例:AES公開鍵暗号低速だが事前の鍵共有が不要例:RSA・楕円曲線暗号ハイブリッド方式(TLS で採用)公開鍵暗号で共通鍵を安全に取り決め、実データは高速な共通鍵暗号で守る
共通鍵暗号と公開鍵暗号の使い分けと、両者の長所を組み合わせるハイブリッド方式

通信の暗号化と保存の暗号化

実務で暗号化を設計するとき、まず区別すべきは「通信中のデータ(in transit)」と「保存されたデータ(at rest)」です。前者はネットワーク経路上の盗聴・改ざんから守るもので、HTTPTLS を重ねた HTTPS が代表です。後者はディスクやバックアップテープが盗まれたり、クラウドのストレージに不正アクセスされたりしたときの備えで、データベースの透過的暗号化(TDE)やディスク全体の暗号化がこれにあたります。

この2つは守っている脅威が違うため、片方だけでは不十分です。通信を暗号化していても、サーバのディスクが平文なら内部犯や物理盗難には無力ですし、逆にディスクを暗号化していても通信が平文なら経路上で漏れます。クラウド時代の設計では「in transit も at rest も両方暗号化する」が基本線になっています。

ハッシュ化との違い — 「戻せるか」がすべて

暗号化と混同されやすいのがハッシュ化です。決定的な違いは、暗号化は鍵があれば元に戻せる(可逆)のに対し、ハッシュ化は原理的に元に戻せない(不可逆)ことです。この違いはパスワードの保存で重大な意味を持ちます。パスワードを暗号化して保存すると、鍵が漏れた瞬間に全ユーザーのパスワードが平文に戻せてしまう。だからパスワードは暗号化ではなくハッシュ化して保存するのが鉄則です。「戻す必要があるデータは暗号化、照合できれば十分なデータはハッシュ化」と覚えると整理しやすいでしょう。

実務での落とし穴

暗号化まわりで最も多い失敗は、アルゴリズムの弱さではなく運用の穴です。第一に鍵管理。鍵をソースコードにハードコードしたり、暗号化したデータと同じ場所に鍵を置いたりすれば、暗号化の意味がなくなります。クラウドでは KMS(鍵管理サービス)に鍵を預け、アプリケーションからは権限経由で使うのが定石です。

第二に「自作暗号」の危険です。暗号アルゴリズムの安全性は世界中の研究者による攻撃に耐えて初めて信頼されるもので、独自方式は例外なく弱いと考えるべきです。実装も自分で書かず、実績のあるライブラリを使います。第三に、古いアルゴリズムの残存です。DES や RC4、MD5 ベースの構成など、すでに破られた・弱いとされる方式が古いシステムに残っていることは珍しくありません。暗号は「一度設定したら終わり」ではなく、時間とともに危殆化(安全性が低下)する前提で、定期的に見直す運用が必要です。