自分もおとなになったら腕が太くなるんだろうか、なんて思っていましたが、結局ガリガリな遺伝子のもとに生まれたようで、いまでも時計は一番細くなるようなベルト位置になりますね。でも最近の活動量計なんかはユニセックスにデザインされてるから、割と自分よりも細いベルト位置まで設定ができるパティーンがあって、いがいと一番短くなるまでベルトを締めないパティーンも出てきた感じがします。

やっぱりサイバークロスつけてたような子供は大人にあると、ガジェット時計つけるんやな。おわり

Permalink | 記事への反応(0) | 00:46

2021-12-31

■anond:20211231112736

VDI 導入、コロナ禍におけるビデオ会議の課題と改善、

そして中長期の PC 環境の構想へ

リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。

今回は、VDI 導入を振り返り、中長期の PC 環境の構想をお伝えする。

石光直樹，リクルート（2021 年 05 月 24 日）

23 →目次に戻る

　“ ネットワーク状況によっては使えないシーンがある点 ” は、VDI なら避けられない問題です。特に外出中は、ス

マートフォンによるテザリングで VDI に接続する際に、エリアや移動状況によっては通信環境が安定せず、通信が

切断されたり、通信速度が遅くなったりするなど、VDI がスムーズに動作しないシーンがありました。この課題に

対しては、スマートフォンのテザリング容量の観点なども含めて検討し、対処してきましたが、完全には解決でき

ませんでした。そこで、VDI では業務遂行がどうしても困難なユーザーに限定し、さらに高セキュリティ業務以外

での利用において通常の PC（FAT PC）を配布するようにしました。

もう一つの課題 “ ビデオ会議実施時の不具合 ” については、もともと VDI とビデオ会議の親和性は良くない点

が前提にあります。ビデオ会議の場合、クラウドサービスを使うことが多いと思いますが、通常の PC なら、クラ

ウドサービスと PC 上のビデオ会議ソフトウェアが直接つながり、ユーザーは快適にビデオ会議ができます。一方、

VDI の場合、クラウドサービスと VDI 上のビデオ会議ソフトウェアがまず接続され、その後 VDI から VDI 専用端

末（シンクライアント端末）に音声と動画が転送される形になります。音声も動画もいわば二重でデータ転送さ

れる仕組みなので、劣化してしまうのは避けられません。具体的には、音声が途切れ途切れになったり、動画が

カクカクしてスムーズに動作しなかったりすることになります。

また、システム管理の観点でもデメリットがあります。通常の PC では、ビデオ会議ソフトウェアの機能でクラウ

ドサービスとのネットワーク接続状況をチェックしてくれて、最適に通信する仕組みなのに対し、VDI ではそのよう

な機能は使えません。ビデオ会議ソフトウェアにその機能が搭載されていても、VDI から VDI 専用端末に通信す

る段階でそれらの機能が無効化されてしまうのです。その結果、VDI 上でのビデオ会議は通常よりも多くの通信

量が発生してしまい、外出時などテザリングの容量を圧迫することになっていました。

しかし、最近ではビデオ会議のこうした課題の回避策として、クラウドサービス各社が VDI 用のソフトウェアを

リリースしてくれるようになってきました。VDI 用のビデオ会議ソフトウェアを VDI にインストールして、一部のソ

フトウェアコンポーネントを VDI 専用端末にもインストールします。そうすることで、VDI と VDI 専用端末が協調

してビデオ会議端末として動作し、クラウドサービスと VDI 専用端末とが直接つながる構成になり、従来に比べる

と音声や動画の劣化が大幅に避けられるようになってきています。

24 →目次に戻る

中長期の PC 環境を構想する――“ 中長期 ” という新たな観点の導入

　以上をまとめると、いまの VDI 環境では当初想定したメリットは得られたものの、ネットワークとビデオ会議に

おいてそれぞれの課題があります。ネットワークの課題は、一部ユーザーに FAT PC を配布することで、ビデオ会

議の課題については VDI 用のビデオ会議ソフトウェアをインストールすることで解決できます。いまの VDI 環境

を評価するマトリクスを作って検討してみると、VDI 用のビデオ会議ソフトウェアがうまく動作すれば、VDI 環境

をそのまま継続するのが妥当なように見えました。とはいえ、そのような “ カイゼン策 ” を施しながら、VDI をい

まの形のまま続けるべきなのでしょうか。そして、そのような思考プロセスに本当に問題はないのでしょうか――。

われわれは検討時に、新たな視点を導入することにしました。それは “ 中長期 ” 視点です。2015 年においては、

3 つの課題という、“ いま、ここ ” における課題に対する解決策として VDI を採用したものの、今後長きにわたっ

て会社を支えていくPC 環境を構想するに当たり、それだけでは不十分ではないかと考えました。リクルートは創

業から 60 年以上がたちました。今後も長きにわたり、カスタマーやクライアントの皆さんのためにより良いサービ

スを提供し続けることになるでしょう。それには短期的な視点だけではなく、中長期でのあるべき PC 環境を描い

て、それに向かっていまどうすべきかを考えなければならないと思ったのです。

そのためには、まず働き方が将来的にどうなるかを想定しなければなりません。次期 PC 環境を検討していたの

はコロナ禍前でしたが、ゆくゆくは「完全に場所を選ばない働き方」になるだろうと予想していました。キーワード

で示すならば、「Anytime/Anywhere/Securely/Work Digitally」という表現になるでしょうか。そのような働き方

を実現する PC 環境については、既にいわれて久しいですが、クラウド中心の方向性は変わらないでしょう。加えて、

今後は多種多様なデバイスが出現すると想定しました。いまは PC や VDI が中心であり、補助的にスマートフォンが

使われているというのがビジネスにおける PC 環境の実情だと考えます。では、今後はどうなるのか――。

スマートフォン中心になるという見方もありますが、学校では情報教育が進みノート型の端末が支給されており、

家庭においてはスマートスピーカーが広まり、AR/VR（拡張現実／仮想現実）もゲームなどを中心に広がってき

ています。また、企業では製造業などで AR/VR が使われる事例も出てきており、IoT デバイスもいろいろなユー

スケースが生まれてきました。

そう考えると、ユーザーが使う端末は、どれかの端末に収束していくのではなく、2in1 あるいはクラムシェル型

などの PC、スマートフォン／タブレット、AR/VR デバイス、スマートスピーカー、IoT などいろいろなデバイスを

使いこなしていく世界になるのではないかと考えます。業務のさまざまな場面で、いろいろなデバイスの中から最

適なものを選び、さまざまなクラウドサービスを使いこなし業務をしているイメージです。それらを使うことで、場

所を選ばず、どこにいても対面同様のコラボレーションができるでしょう。さらには、AI（人工知能）技術などを

活用しながらユーザーの業務を支援するなどして、高い生産性を生み出すことができる環境になっていくのではな

いか、と予測します。

25 →目次に戻る

中長期視点で考え、いま行動する――「クラウド＆マルチデバイス環境」へ

われわれは、このような環境を「クラウド＆マルチデバイス環境」と呼ぶことにしました。中長期的には「クラ

ウド＆マルチデバイス環境」になるとして、VDI の EOSL 契機に対応しなければならないわれわれの次の PC 環

境はどのように整えたらいいのでしょうか。

　大事なのは、「中長期視点で考え、いま行動する」ことです。中長期視点だけを考えれば、一気に「クラウド＆

マルチデバイス環境」にすべきでしょう。ところが、われわれの環境内にはまだレガシーシステムが残っており、一

気にクラウドだけを利用する業務形態に変えるのは困難でした。また、検討した結果、現時点では VDI に勝るよ

うなセキュリティ確保の仕組みは見当たりませんでした。そのため、情報資産の囲い込みができるという点で、高

セキュリティ環境に対しては継続して VDI を活用することにしました。

セキュアな環境以外の用途においては、“ いま ” のことだけを考えれば、ビデオ会議の部分のみを改善して VDI

環境のまま、次期 PC 環境を作る方向もあり得ました。しかし、それでは今後の PC 環境が VDI に固定化されて

しまうことになります。VDI 環境をいままでと同様にオンプレミスで作るには、初期に大きな設備投資が必要とな

り、また一度構築してしまうと使い捨てるわけにもいかず、それをしばらく運用し続ける必要があります。今後い

ろいろなクラウドサービスやデバイスが出現すると、活用したいと思う方も多いでしょうが、既に VDI を使ってい

る場合、VDI の代わりに別のものをすぐに使うということはなかなかできません。そういう意味で、PC 環境が固

定化されてしまうことになるのです。

　中長期の環境に一気に切り替える方針でもなければ、現在のことだけ考える方針でもなく、「中長期視点で考え、

いま行動する」方針で検討した結果、次期 PC 環境は「クラウド＆マルチデバイス環境」を目指すための第一歩

と位置付け、「VDI と FAT PC のマルチ環境」を構築することに決定しました。先述した通り、レガシーシステム

が存在し VDI 以上に情報の囲い込みができるソリューションがない中で、VDI から離れ、一気に中長期的な将来

像を目指すのは困難です。とはいえ「将来像に向けた環境をいま作るべき」と考え、VDI と FAT を業務特性に応

じてユーザーに配布するマルチ環境に刷新することにしました。つまり、高セキュリティ業務ユーザー向けにはセ

キュリティを確保した「セキュア VDI」、それ以外の一般ユーザー向けには FAT PC を配布することにしたのです。

将来的にはマルチデバイスといっても、いまだ PC がメインなので、まずは PC を配布し、その上で今後 AR/VR

デバイスといった他のデバイスも検討していきたいと考えています。

なお、VDI 環境としてはもう一つ、機能更新がない固定的な OS を必要とするレガシーアプリ向けの環境も VDI

で用意することにしました。用途が限定されていることから、社内では「特定用途 VDI」と呼んでいます。

26 →目次に戻る

VDI 用のビデオ会議ソフトウェア導入による 2 つの課題

　以上をまとめますと、働き方は中長期的に「完全に場所を選ばない働き方」へと変わり、それに応じて PC 環

境は「クラウド＆マルチデバイス環境」になっていくでしょう。われわれも VDI の EOSL のタイミングで変わって

いかなければならず、将来に向けた第一歩として、次期 PC 環境は「VDI と FAT PC のマルチ環境」を実現する

ことにした、ということになります。

なお、コロナ禍において、われわれは現在の VDI 環境下でビデオ会議の改善を試みました。先述した VDI 用

のビデオ会議ソフトウェアの導入を検討し、一部導入したのです。その結果、ビデオ会議の音声と動画の品質が

極めて改善されることになったものの、2 つの課題が新たに見つかったのです。

1 つ目は、普通のビデオ会議ソフトウェアと VDI 用のソフトウェアとの間に機能差があった点です。この課題は

今後解消されるかもしれませんが、われわれが導入した段階では VDI 用のソフトウェアが機能面で劣っていました。

2 つ目は、導入／管理コストです。1 つのビデオ会議システムしか使っていない場合は問題ないかもしれません

が、複数使っていたり、今後新しいシステムの導入を考えようとしたりすると、ソフトウェアの導入、管理に都度

工数がかかってしまうという難点が明らかになりました。

　以上 2 点については、いま検討されている方のご参考になれば幸いです。次回は、リクルートがいままさに取り

組んでいる「VDI と FAT PC のマルチ環境」についてお話しします。

Permalink | 記事への反応(0) | 11:28

■「ゼロ トラスト ネットワーク」を見据えた抜本的な刷新「VDI と FAT PC の

リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。

最終回は、現在取り組んでいる VDI と FAT PC のマルチ環境についてお伝えする。

石光直樹，リクルート（2021 年 06 月 04 日）

28 →目次に戻る

ただし、そうしたユーザーに対して環境が変わることについてきちんと説明しないと、混乱につながってしまいま

す。そこで、「なぜこのような環境に切り替えることに至ったのか」や、目的、狙いについてプロジェクト内で改め

て議論しました。ユーザーに対して納得感ある形で社内説明資料などをまとめて、各部署の主要なユーザーに向

けて情報を発信していきました。

　今後の移行時には、さらに分かりやすい資料の共有や移行マニュアルの整備などを行い、社内広報の体制も整

えていきたいと考えています。

VDI と FAT PC のマルチ環境の実現に向けた検討

マルチ環境の実現は簡単なことではありません。特に FAT PC の環境をどう作るのかについては、時間をかけ

て検討しました。まずは、VDI 導入により大幅に解消された “3 つの課題 ”、すなわち「セキュリティの向上」「PC

管理コストの削減」「働き方変革への貢献」の対応策を FAT PC でどのように実現するか。これが次の課題です。

　「セキュリティの向上」については、高セキュリティ業務にはセキュア VDI を提供し続け、FAT PC に対しては従

来よりもセキュリティを強固にすることにして、この課題をクリアしました。

　続いて「PC 管理コストの削減」では先述の通り、VDI 化によって大きなメリットを得られた部分でした。例え

ば、夜間にパッチを当てたりできるのは、システム管理担当者からすると非常にメリットになります。ところが、FAT

PC に切り替えると、このメリットは享受できなくなってしまうことから、VDI 導入時に刷新した PC 管理システム

を FAT PC にも導入することで一定の解決を図るのに至りました。VDI の導入前に使っていた “ お手製 ” の PC

管理システムでは、パッチ当てや OS 更新などが大変でしたが、最新の PC 管理システムを導入することで、かな

り容易になっていたからです。とはいえ、VDI の管理性には劣ります。この点は、中長期視点でのより良い環境を

目指すために、優先度を下げた部分といえます。

そして「働き方変革への貢献」については、先述の通り、昨今の状況を踏まえると、ビデオ会議をより活用で

きる FAT PC の方がメリットを引き出せるのではないかと考えました。ただし、FAT PC に切り替えることで、い

ままでとはネットワークの流れ方が変わってきます。VDI では、データセンターと端末の間でやりとりされるのは

VDI 画面のデータが中心でしたが、FAT PC ではさまざまな実データがやりとりされることになります。また、社

外などから社内に VPN 接続をする必要があり、その部分がボトルネックになりがちです。その問題に対しては、

ネットワークを再検討することで解決を図ることにしました。われわれの社内ネットワークは VDI に最適化されて

いたので、FAT PC の増加に合わせて拠点のネットワークを増強したり、VPN を増強したりすることを検討しま

した。これにより、働き方変革で求められていたテレワークの要件に対しても十分応えることができると考えてい

たのです。

29 →目次に戻る

しかしながら、この方針は大きく変更を余儀なくされることになります。その理由は 2 つあります。1 つ目はコ

ロナ禍の影響、2 つ目はネットワーク技術動向の影響です。

　社内ネットワークの再検討はコロナ禍の影響を強く受けることになりました。在宅勤務の方針が示されたこと

で、社内からの接続が減る一方、リモート接続が増え、社内のネットワークトラフィックの在り方が大きく変わって

しまったからです。コロナ禍が続く中で、そしてアフターコロナでそういった状況がどうなるのかについては予測が

難しく悩みました。単純に拠点のネットワーク、特に WAN を増強したとして、使われなくなるなら投資が無駄に

なってしまいます。また、ネットワークにおいては今後のトレンドとして「ゼロトラストネットワーク」が注目されて

きています。おそらく、われわれの目指す「クラウド＆マルチデバイス環境」を支えるネットワークは「ゼロトラス

トネットワーク」になることでしょう。

では、いま「ゼロトラストネットワーク」のようなネットワークを入れるべきなのか。それともいまは暫定構成に

して将来的に「ゼロトラストネットワーク」に移行できるようにするのか――。

コロナ禍で勤務の環境が急速に変わってきていることも踏まえて、この点を検討しなければならなくなりました。

いまもまさに検討しているところで、いまだに完全な結論は出ていませんが、現時点では PC 環境と同じく、将来

的には「ゼロトラストネットワーク」に移行できるように、いまのネットワーク構成を考えるべきと思っています。

変化に対応して、かつ自ら変化を引き起こす

さらに、FAT PC 導入においては大きな変化があります。それは「SAC」（Semi-Annual Channel、半期チャ

ネル）の導入です。

VDI 環境においても「Windows 10」の導入は完了していましたが、「LTSB」（Long Term Servicing Branch※）

を導入していました。頻繁な更新を望まないユーザー向けに作られた、機能更新がない固定的な Windows 10 のモ

デルです。これに永続ライセンス版の「Microsoft Office」を組み合わせて利用していました。

※現在の名称は、「LTSC」（Long Term Servicing Channel、長期サービスチャネル）

これは、「レガシーアプリが存在するので、機能更新がない OS の方がいい」と思っての選択でした。しかし、機

能が更新されないので、OS や Office の最新機能が利用できないなど、将来的には「Microsoft 365」への接続

も制限されるような状況でした。

30 →目次に戻る

　他方、SAC なら OS や Office が常に最新の状態になります。そのため、半期あるいは 1 年に 1 回程度のペー

スで機能が大きく更新されます。IT 部門としては、機能更新時に社内アプリケーションの動作確認などをする必

要があり、PC 管理タスクが増えてしまうことになります。PC 運用コストの増大につながり得るので、VDI から

FAT PC に切り替える際の検討ポイントの一つでもありました。しかし、ここでもわれわれは中長期視点を大事に

しました。

　今後の「クラウド＆マルチデバイス環境」においては、環境が常に最新になる世界が普通になるでしょう。いま

のスマートフォンを見てもそうですが、OS はどんどん更新されて、次々と新たな機能やサービスが利用可能にな

るのがむしろ普通であり、その波が PC の世界にも到来しているのです。PC 運用コストが上がったとしても、わ

れわれもこの波に乗って、ユーザーに対しても新機能やサービスを次々に提供していき、より良く業務を行っても

らえるようになればすてきだなと思いました。

そこで、VDI から FAT PC への切り替えに際して、OS のモデルも LTSB（LTSC）から SAC に変更すること

にしました。PC が最新に変わっていくSAC のような世の中の変化に対応しながら、われわれの環境においても

変化を引き起こして業務を変えることができればと思い、現在、導入を進めています。

VDI 基盤の抜本的な刷新

ここまでは大多数のユーザーが利用することになる FAT PC のことを中心に述べてきましたが、セキュア VDI と

特定用途 VDI として利用する VDI 基盤のリプレースも大きな仕事です。

VDI 基盤リプレースにおいてもいままでの構成を踏襲せず、一からあるべき姿を検討することにしました。まず

検討したのはクラウドの導入です。将来「クラウド＆マルチデバイス環境」になれば、VDI 自体もクラウドのサー

ビスの一つという位置付けになるだろうと考え、クラウドでの VDI 利用を検討しました。

しかし、残念ながら今回クラウド VDI の採用には至りませんでした。われわれの試算ではオンプレミスに比べて

コストが見合わなかった点と、管理機能がまだまだのように思えた点が見送りの理由でした。クラウドはますます

発展する領域なので、今後は状況が変わるかもしれません。われわれも引き続き状況を観察し、一部の環境には

クラウドをトライアル的に導入してみることも視野に入れて、現在、検討しています。

　当面の方針としてオンプレミスの VDI を構築することにしましたが、いままでの構成をそのまま踏襲するような

ことはしませんでした。必要としたのは、運用性やコスト、拡張性に優れたアーキテクチャでした。

31 →目次に戻る

　議論、検討を重ね、さらに比較、検討した上で、われわれは HCI（Hyper Converged Infrastructure）構成

を選びました。HCI はサーバ中心のアーキテクチャで、SAN（Storage Area Network）スイッチやストレージ

を省くことができ、構成がシンプルになり、運用性やコストにメリットがある他、リソース拡張はサーバを追加する

だけでよいので、拡張性にも優れています。われわれが望んでいた点を満たすアーキテクチャと評価しました。

いままでは「サーバ＋ネットワーク＋ストレージ」のいわゆる「3Tier」構成で安定運用できていたので、これを

変えるのは大きなチャレンジでした。とはいえ、チャレンジしないことには運用性もコストも拡張性も勝ち取れませ

ん。「新たなことに挑戦するのが、われわれのエンジニアリングの方針だ」と考え、HCI 構成を選びました。

　加えて、VDI 基盤のデータセンターのネットワークを SDN（Software Defined Network）に切り替える決断

もしました。従来の構成と比較し、運用性や管理性を鑑みて、より優れているという結論に達したからです。また

中長期視点でも、「ネットワークにおける Software Defined の方向性は変わらない」とみています。

Permalink | 記事への反応(1) | 11:27

2020-10-11

■エンドツーエンド暗号化(通称: E2E)について解説する

[B! セキュリティ] フェイスブックの暗号化、日米英などが見直し要求へ　（写真=AP）日本経済新聞

エンドツーエンド暗号化という技術がある。

平文に一定のアルゴリズムに従って暗号鍵から生成したノイズデータを掛け合わせ、意味が読み取れない暗号文を作るのが暗号化である。逆に意味が取れない暗号文から平文を求める操作を復号と呼ぶ。アルゴリズムがよく知られていながら暗号鍵が無ければ復号できないものがよい暗号と言われる。一般には256bitAESでも使っておけばまずパッと見ても聞いても数学的にもほぼ乱数と区別できなくなる。

ノイズデータの生成方法には色々あり、事前に送り付けた乱数表を使い使用後は破棄するもの、事前に送り付けた共通鍵や公開鍵を使うもの、都度生成するものなどがある。掛け合わせる方法も色々あり、乱数表に書いてある数字と暗号文を足し合わせると平文になるもの、共通鍵を暗号文に使うと平文になるもの、公開鍵を使うと平文になるものなどがある。

共通鍵を平文に使うと暗号文になり、共通鍵を暗号文に使うと平文になるものを、対称暗号とか共通鍵暗号と呼ぶ。

公開鍵を平文に使うと暗号文になり、暗号文に秘密鍵を使うと平文になるものを公開鍵暗号と呼ぶ。非対称暗号ともいう。

ノーマルモードとコモンモードみたいで意味不明だが耐えろ。

共通鍵暗号でも公開鍵暗号でも「平文が、暗号文になり、平文に戻る」というところは同じだが、

共通鍵では「平文→　　　鍵→暗号文→鍵　　　→平文」と同じ鍵を使い、

公開鍵では「平文→　公開鍵→暗号文→秘密鍵　→平文」と二種類の鍵を順に使う。

なお、この二種類の鍵は順に使えば順序はどっちでも良い。先に秘密鍵で処理して公開鍵で処理することも可能だ。とにかく2種類両方を使えば良い。

共通鍵暗号は分かりやすい。zipのパスみたいなもんだ。Wi-Fiのパスワードも同じだ。だが公開鍵暗号については、二種類の鍵を順番に使うと何が良いのかと思う人も多いだろう。どうせ暗号で読めないのだからいいじゃないかと思うだろう。実は名前の通り鍵を公開しても全くノーダメージというところがメリットなのだ。書かなかったが公開鍵から秘密鍵を数学的に求めることは不可能である。逆も不可能である。そして処理する順番もどっちでもいい。つまり適当な暗号文と鍵の片割れを公開しておくことで、もう片割れの所有を証明できるのである。これが公開鍵暗号の醍醐味である。

この技術はHTTPSの証明書に使われている。というかすべての公開鍵基盤で使われている。.pemとか.cerとかid_rsa.pubはこの片割れであり、ウェブブラウザの「証明書の検証」とは、ネットを見てる時にサーバが送ってくる「適当な暗号文」として"*.hatena.ne.jp"のハッシュを知らん鍵で暗号化したもののハッシュを知らん鍵で暗号化したもののハッシュを暗号化したものに対して、事前にWindowsをインストールした時に付いてきたHatena-Masuda Ultra Global Root CAとかいったけったいな鍵の片割れを使ってみてちゃんと復号出来てるかチェックしているのである。

ここまでが暗号技術のおさらいである。

暗号化 通信とは

暗号化通信を行うには、暗号鍵でデータを暗号化すればいい。暗号化には共通鍵暗号を使うのが高速で便利だ。公開鍵暗号は原理的に計算量が多く低速である。しかし、どうやって共通鍵を事前に知らせればいい? 公開鍵暗号で共通鍵を暗号化すれば、受け取り手は自分の秘密鍵で復号できるだろう。しかし、秘密鍵は本当に秘密か? 暗号文と秘密鍵が手に入れば、公開鍵暗号でも解読できてしまうのではないか? HTTPS化しているウェブサービスでも、TLSをロードバランサで終端してデータセンタ内は平文だったりするのではないか? そこで鍵交換、セッション鍵生成の議論が登場する。

Diffie-Hellman-Merkle鍵交換方式

Diffie-Hellman-Merkle(Diffie-Hellman)鍵交換方式とは、ディッフィー君とヘルマン君が下宿で階段をドタドタやってる時に天啓のように降ってきたと言われる、ネット上に数字そのものを公開することなく、2者間で同じ1つの乱数を得る方法である。

送信者と受信者の間で共通の1つの乱数を得ることができ、その乱数を第三者に知られることがない。

上で何度か「公開鍵暗号の秘密鍵と公開鍵は、平文に対して両方使えば平文に戻り、順序は関係ない」と書いたのを覚えているだろうか。Diffie-Hellmanはこれに似た方式だ。まず、AさんとBさんは送信者がお互い本人であることを証明できるようにする(公開鍵基盤を使う)。そして、それぞれ手元で乱数AとBを生成する。次に、鍵用の乱数Aを適当な乱数で暗号化した鍵Aと、鍵用の乱数Bを適当な乱数で暗号化した鍵Bを計算し、お互いに送り付ける。この暗号Aと暗号Bは盗聴されているものとする。

Aさんの手元には乱数A、適当、暗号Bがある。

Bさんの手元には乱数B、適当、暗号Aがある。

AさんとBさんはそれぞれ鍵Bと鍵Aに対して暗号化を行う。すると鍵BAと鍵ABが生まれる。このとき数学的な都合により鍵BA == 鍵ABである。

では、暗号A、暗号B、適当A、適当Bのみから鍵ABや乱数Aを求めることはできないのか? 可能だが式変形などで「解く」ことができず、総当たりになるため計算量が膨大になる。従って実質的にはできない。

或は、暗号A、暗号Bを掛け合わせれば、鍵ABになるのではないか? これもできない。暗号AまたはBと掛け合わせるのは生の乱数AまたはBでなければ意味がない。第三者が乱数Cを作って暗号AやBと掛け合わせても、鍵ACや鍵BCになってしまい、鍵ABと一致しない。

これにより、手元で生成した乱数以外のすべての情報が公開で既知で盗聴されているにもかかわらず、2者間で秘密の暗号鍵用乱数を得ることができる。

原始的なDiffie-Hellman鍵交換の実際の計算は非常に簡単であり、この「暗号化」は事前に決めた別の方法で生成する既知の2つの整数X, Yと乱数A, Bに対して、

暗号A = XをA乗してYで割った余り、

暗号B = XをB乗してYで割った余り、

鍵AB = 暗号BをA乗してYで割った余り、

鍵BA = 暗号AをB乗してYで割った余り

である。

なお、くれぐれも簡単と聞いてPython 2.7とかで実装しようとしないように。算数の上手い人が作ったライブラリを使え。暗号処理の自作は絶対バグらせて割られるのがオチだ。ちなみにDiffie-Hellman-Merkleの三人目のマークル氏というのは両名と何のゆかりもないので普通は名前に入れないのだが、Merkle氏の先行研究が直接の元ネタなので入れるべきだと主張する派閥もある。俺はどっちでもいいと思うが折角なので入れておく。

End-to-End(E2E) 暗号化

ここでやっとE2E暗号化が登場する。上のセクションでしれっと書いたが、DH鍵交換が完了した時に送信者と受信者が得る共通の乱数は、各々ローカルで都度生成する乱数を元にしている。身許保証は公開鍵によるが、鍵は公開鍵に縛られないのだ。つまり、SNSやメールサーバその他、身許を保証する機能と文章をやり取りする機能があるツールと、そのツールで間違いなく本人にDH鍵交換の暗号を送れるクライアントアプリがあれば、その経路で本人同士の間だけで共通の乱数を生成し、それを「セッション鍵」として共通鍵暗号方式による通信経路が設定できる。

この「公開鍵認証基盤で本人確認し、DH鍵交換でセッション鍵を設定し、鍵を端末に出し入れすることなく、受信側端末のメモリに入るまで暗号化を解くこともないまま、共通鍵暗号で通信する」のがいわゆる「End-to-End 暗号化」である。

E2E暗号化を行うと、鍵はDH鍵交換で生成され、端末の外に出ないし書き出す必要もなく、通信の中で割り出す事もできず、通信が終われば破棄してもよい。好きなだけ定期再生成してもよい。認証に使う公開鍵と数学的な関係もない。一度設定してしまえば、SNS 運営にチャットログを出させても鍵交換した意味不明な履歴と意味不明な暗号文が出てくるのみで、盗聴者をなりすまさせて鍵を再設定させても前の鍵と何も関係のない新しい鍵が出てくるだけで、意味不明な暗号文の解読の助けにはならない。ちょっと量子コンピュータめいているが、端末となりすましの両方で鍵を一致させることもできない。

ざっくり言えば送信側端末と受信側端末に残っている平文か鍵をバレる前にぶっこ抜く以外に解読方法がない。

これは盗聴関係者にとって非常に大きな問題で、米国のFBIなどは盗聴能力を維持するには法規制以外に策がないと考えている。DH鍵交換のアルゴリズムは上に書いた剰余以外にも楕円曲線を用いた数学的に更に複雑なものもあり、ソースはネットにいくらでも転がっているし、電子計算機アルゴリズムの常でやたら強力な癖に計算量的には全然負担にならない。NSAなどは数学者を揃えて最高のアルゴリズムを提供する振りをして、規格書で事前に決めた一定の数学的特徴を備えているべき定数に備えていないものを指定するとか、実装でミスが出やすい関数を選ぶなど小細工を入れているが俺は二次関数も分からんので詳しいことは知らん。しばしば政府の陰謀にキレた若い IT キッズが小細工を抜いて差し替えた再実装を公開したりして揉めている。

実際にSNSなどでE2E暗号化を実装する上での問題点は、本人確認、機種変とマルチデバイス、嫌がらせ対応がある。まず本人確認がコケればMITMは可能だ。E2Eでは鍵を外に出さないのがメリットなので複数端末ログインができず(鍵が変わって別端末で書いたメッセージは解読できなくなる)、運営で常時メッセージを監視できない(したら意味がない)ので嫌がらせ対応が多少困難になる。またMITBというか、改造偽アプリで抜かれる可能性は、まあ、ある。