ここ数週間、ハードドライブにローカルに保存されたデータを、物理的にアクセス可能な人物や潜在的なリモート攻撃から保護する方法について書いてきました。しかし、データはエンドポイント間やサーバーを経由して転送される際に、より脆弱になります。
この問題は、インスタントメッセージ（IM）においてはiMessageによって効果的に解決されています。iMessageは強力なエンドツーエンド暗号化を採用しており、Appleによれば、Appleでさえメッセージを解読できないように設計されています。これは、Apple側ではリバースエンジニアリングできないプロセスでローカル暗号鍵を作成することによって実現されています。iMessageはインターネット上の中継点を通過しますが、メッセージ内のプレーンテキスト、画像、音声を第三者が盗み見ることはできません。（FaceTimeの音声とビデオも同様です。）
しかし、iOSやOS Xのメールアプリであれ、サードパーティ製のメールソフトウェアであれ、メールは依然として混乱状態です。問題はメールプロトコルがあまりにもうまく機能しすぎていることにあります。Appleのメールアプリはどちらのプラットフォームでも使いづらいので、そのように聞こえるかもしれません。しかし、ネイティブアプリとWebアプリの間で選択できる選択肢の多様性は、メールの動作をコントロールする企業や組織が存在しないことに起因しています。iMessageは完全にAppleのエコシステムであり、これはFacebookのWhatsAppやMicrosoftのSkypeのメッセージングコンポーネントなど、ほとんどのメッセージングシステムに当てはまります。対照的に、ネイティブメールプログラムはあらゆるプラットフォームと時代を超えて何千種類も存在し、そのうち数百種類は今も広く使われ続けています。
電子メールの問題
電子メールプロトコルは、メールの取得と同期を担うPOP3（古くからあるが現在も使われている）とIMAPで構成され、送信はSMTPが担う。インターネット黎明期に登場したため、奇妙な痕跡を残しながら、断続的に進化してきた。電子メールは、妥協と、誰も主要コンポーネントを破ったりサポートを拒否したりできないという暗黙の了解によって、今もなお機能し続けている。これは、変更を強制できるほど大きな部分を誰も管理していないことも一因となっている。
AppleのMail.appにおける過去そして現在における最大の問題の一つは、実のところ、GoogleのIMAPサービスの設定が奇妙であり、Appleがそれを全面的に受け入れようとしないことにあります。GoogleはIMAPを完全に廃止することはできません。そうなれば、Outlookなどのソフトウェアを使ってGmailのメッセージを受け取っている何百万人ものユーザーが孤立し、乗り換えてしまう可能性が高まるからです。（Androidには3つのメールアプリがあり、2つはGmailと異なる方法で連携し、3つ目は「通常の」メールアカウント用です。）同様に、Appleはメール送信のための新しい、より優れた方法を発明することができません。なぜなら、世界中のすべてのメールサーバーをアップデートして受信する必要があるからです。
ここ数年で十分な標準化とアップグレードが進み、メールクライアントとメールサーバー間の接続は十分に保護されるようになりました。メールはクライアントからISP、企業、またはメールホストが運営するサーバーへと流れ、そこから通常は受信者のメールサーバーへと直接送信されます。Appleのメールクライアントや他社のメールクライアントは、デフォルトで新しいアカウントを設定してSSL/TLSを使用しようとします。SSL/TLSは、安全なWebインタラクションに使用されるセッションベースの暗号化技術と同じです。
しかし、SSL/TLSが保護するのは、メールクライアントとメールサーバー間のリンクのみです。データはそのセッション中は転送中に暗号化され、サーバーで復号化された後、パッケージ化されて次のサーバーに送信されます。現在では、実際には、そのリンクさえもより安全になっています。ほとんどのメールサーバー（大手企業が運営するものはすべて）はデータセンター内にあります。そして、エドワード・スノーデンの暴露を受けて、Googleをはじめとする企業は自社のデータセンター間のリンクのセキュリティを強化しました。
メールが復号された後も、弱点は依然として残ります。サーバー上で数マイクロ秒後にラップされて暗号化リンク経由で別のサーバーに送信される場合でも、あるいはサーバーが別のメールサーバーと安全でない通信を行う（よくあることですが）場合であっても、その弱点ははるかに長く残ります。これらの弱点を突いて、犯罪者や政府機関がアクセスする可能性があります。
セキュリティの鍵は…鍵
iMessageは強力なエンドツーエンド暗号化を採用しているため、これらの弱点は一切ありません。では、メールで同じことを実現するにはどうすればいいのでしょうか？公開鍵（PK）暗号を用いることで実現できます。PK暗号は、1991年から何らかの形で文書やメールの暗号化に利用されてきました。10年前、私はMacworldでPGP（元々はPretty Good Privacyの略）の改良版で、洗練されたデザインの商用版をレビューし、これが暗号化メールの新たな時代を切り開くことを期待しました。私はかなり楽観的な人間なのかもしれません。
それでも、希望は尽きることはありません。PKが、コマンドラインスキルを持つ人だけでなく、誰でも簡単かつ安全に使えるものになる日がもうすぐ来ると思っています。まずは公開鍵暗号について簡単に説明しましょう。次回のコラムでは、実際にどのように使うか、少なくともMac上での使い方を説明します。
公開鍵暗号は、2つの相補鍵（公開鍵と秘密鍵）を導出するための数値セットを生成するアルゴリズムに基づいています。公開鍵は自由に配布できますが、実際には広く配布され、個人のアイデンティティと関連付けられるべきです。（これについてはパート2でも詳しく説明します。）秘密鍵は厳重に保管する必要があります。なぜなら、秘密鍵を所持することで、相手が本人であることを「証明」できるからです。現在、公開鍵を持っている場合、秘密鍵を導出する既知の方法や実用的な方法は存在せず、また近い将来においても、その方法はおそらく存在しないでしょう。
他人の公開鍵を使えば、その人だけが対応する秘密鍵で復号できるメッセージを暗号化できます。また、メッセージに「署名」することで、あなたの公開鍵を持つ人なら誰でも、メッセージが改ざんされておらず、あなただけが署名できたことを確認できる暗号文を生成することもできます。
PKは長いメッセージを暗号化するのには実用的ではありません。PGPの発明者であるフィル・ジマーマンの天才的な発想は、公開鍵部分を強力な対称セッション鍵（文書固有の暗号化鍵で、データの暗号化と復号化の両方に使用されます）の暗号化にのみ使用し、適切な秘密鍵でのみ抽出できるというものでした。（メッセージを複数の相手に送信する場合、セッション鍵は各送信者の公開鍵で個別に暗号化されます。）
PGPアプローチの強みは、GPG（GNU Privacy Guard）という名称でフリーソフトウェアとして具体化されている点にあります。強力な暗号鍵を漏洩されることなく共有する方法という問題を解決します。なぜなら、セッション鍵は誰でもメッセージを復号化したり、単独では検証できない新しいメッセージを暗号化したりできるためです。PK部分により、ドキュメントの鍵を安全に共有できます。
しかし、問題はすぐに分かります。そして、私が楽観的な評価をしてから10年経った今でも、PGPとその派生製品があまり使われていない理由も分かります。PGPを使用するには、すべての受信者が公開鍵の検索と使用を管理し、公開鍵が所有者のものであることを確認するためのツールを持っている必要があります。また、ローカルの秘密鍵と他者の公開鍵の保管庫とやり取りして暗号化と復号化を管理するメールプラグインにアクセスできる必要があります。
パート 2 では、何が変わったのか、そしてそれをどのように実践するのかについて説明します。
