1990年代にはインターネット上での追跡及び監視が可能であることがわかったことを受けて、アメリカ海軍研究所（NRL）は 誰と誰とが通信しているか分からない 通信方式を確立する必要が生まれました。そこでNRLの研究員は1995年に、玉葱の皮のように何重にも通信を暗号化することで匿名化する 「オニオンルーティング」 のコンセプトと初期プロトタイプを開発しました。 1997年にはアメリカ国防高等研究計画局（DARPA）*1 によって更に開発が進みます。

2002年9月20日に、Torはそのコードが無料のオープンソフトウェアライセンスで公開され、2004年には米国とドイツに合わせて12のボランティアノードを持つ分散ネットワークとなります。

2004年にはTorは電子フロンティア財団（EFF）に資金提供を受けることで開発は継続され、 2006年には501(c)3非営利団体 *2 として Tor Project, Inc. が立ち上がります。

2008年には誰も簡単に利用できるようにTorを組み込んだTorブラウザの開発が始まり、過去から現在に至るまでにMozilla, Google, DARPAといった政府機関や教育機関、個人から支援を受け開発は続いています。（執筆当時のTorブラウザの最新バージョンは9.0.2）

なぜTorが必要なの

ダークウェブを支える技術としてのTorは、実際にダークウェブ上非合法な活動が観測されて、その面が強調されることから、悪用されるソフトウェアであるために必要ないのでは、と思う人もいるかも知れません。

しかし次のようなことがあり、Torはなくてはならないものと言えるでしょう。

表現の自由を守る（検閲の回避）

日本にいるとうーん🤔となってしまうかもしれませんが、世界には政府が通信に対して検閲を行っている国がいくつかあります。例えば隣国である中国では、金盾やグレート・ファイアウォール等といった名称で知られているように様々な手段で検閲がかけられています。天○○○件というワードは徹底的に排除されるということはご存知かもしれません。

こういった検閲がかけられている国々において、発信元の匿名性を保ちながら通信内容を秘匿できるTorは、 検閲を回避し自身の安全を守るために大切なものとなります。

ただこういった国では政府による反Torの施策が打ち出されるようになります。

中国: 2009年にリレーのIPアドレスのリストを用いてブロックするように。2010年には一部のTorへのブリッジ接続もブロック。
トルコ: 2016年にTorと10のVPNサービスをブロック。
イラン: 2011年にパケットの検査によってTorをブロック。
ベネズエラ: 2018年にTorをブリッジとともにブロック。
他にもエジプト、リビア、シリア等で反Torの動きあり。

検閲のある国だからこそTorが求められ、検閲をすり抜けるからこそTorをブロックする国が存在するのです。

通信の傍受が嫌だ

エドワード・スノーデンが「PRISM」――NSAが主導して行った通信の傍受プログラム――を告発したのは2013年のことです。このPRISMにはMicrosoft, Google, Apple, Facebookなどが協力していた*3こともあり衝撃的でした。

実際に監視活動が存在する以上、何らかの形で私達の通信も監視されている可能性を否定しきれません。そういった監視活動に対して、通信を暗号化するTorは一つの対策として、全部の監視を回避できるわけではないものの有効な手段と言えるでしょう。

Torの統計

Torのユーザー数

f:id:y0m0g1:20191216162257p:plain — the estimated number of directly-connecting clients

2013年8月にリレーユーザー数は80万から500万に増加しています。これは、バックドアを設置する不正プログラム「MEVADE」のボットネットの通信にTorを使用したことによります。 2014年4月にはこの接続をSSHに切り替えることによりその数は落ち着いてます。

2017年12月から2018年3月にかけてドイツでのTorユーザー者は50万から150万に増えました。 2018年3月5日から8日にその数は65万に急減します。これはTorクライアントがDoS攻撃に利用されていて、このDoS攻撃への緩和策が適用されたアップデートの時期に減少したという見方がされています。

2019年5月から6月にかけては、イランでブリッジを介さずに直接Torネットワークに接続できるようになったため、イランでのユーザー数は150万に増えましたが、再度ブロックされたため数は落ち着きます。

Torネットワークのノード数

f:id:y0m0g1:20191216172700p:plain — the number of running relays and bridges in the network

Torでウェブサイトにアクセスする際に、Torは世界中にあるTorネットワークを構成するサーバーから複数選択して利用します。この利用されるサーバーをノードと言います。 ノードの数が多ければ多いほど、どのノードを利用したかわかりにくくなり、より匿名性が高くなります。

サーバーに利用されるプラットフォームはLinuxが一番多く、BSD系、Windows系と続きます。

Torネットワークの速度

f:id:y0m0g1:20191216173958p:plain — overall performance when downloading static files(5MB) over Tor

f:id:y0m0g1:20191216173556p:plain — 2009-2010

f:id:y0m0g1:20191216173828p:plain — 2019

これはTorネットワークを介して5MB*4のファイルをダウンロードする際にかかる時間をグラフにしたものです。 1枚目は2009年から現在に至るまで、2枚目は2009年から2010年末まで、3枚目は2019年いっぱいを切り抜いたものです。ちょっと分かりづらいですが、若干早くなっています。心の目で感じ取ってください。接続帯域も広がっています。

いかがでしたか？

~~調べてみましたがよくわかりませんでした！~~ じゃないよ。

オニオンルーティング

この節ではTorの基本コンセプトであるオニオンルーティングについて触れていきます。

オニオンルーティングでは、クライアントとそのクライアントが通信したいホストとの間に、3つのノードを中継します。 3重に暗号化し、それぞれのノードで一つずつ復号します。

Diffie-Hellman鍵共有

まずオニオンルーティングに入る前にディフィー・ヘルマン鍵共有（DH鍵共有）について簡単に説明します。

AliceとBobが鍵を共有するというシチュで話します。二人は大きな素数pと生成元gを共有しておきます。*5 そしてAliceとBobはそれぞれ{2,3, ... , p-2}からランダムにa,bを選択します。

\begin{align} Alice: A &= g^{a} \mod p &\left(a \in \left\{2,3, \dots , p-2 \right\} \right) \\ Bob: B &= g^{b} \mod p &\left(b \in \left\{2,3, \dots , p-2 \right\} \right) \end{align}

上式において生成されたA,Bを互いに交換し、次の処理をします

\begin{align} Alice: K_{a} &= B^{a} \mod p \\ Bob: K_{b} &= A^{b} \mod p \end{align}

ここで、

\begin{align} K = K_{a} = K_{b} = g^{ab} \mod p \end{align}

となって、生成されたKを共通鍵として使用できるようになります。これは、A(B), p, gから多項式時間でa(b)を求めるアルゴリズムが見つかっていないことに依って成り立っている鍵交換方式になります。

プリミティブなDH鍵共有を実装すると中間者攻撃可能な脆弱性があるので、オニオンルーティングではサーバー認証付きDH鍵共有を使用します。

オニオンルーティングにおける鍵共有

オニオンルーティングでは3つのノードを選択し、それら*6をホップして目的のホストに接続します。これらのノードの情報は、クライアントにはコンセンサスファイルとして配布されるみたいです。

ともかく、3つのノードの内、1つ目のノードをEntry Guard*7、2つ目のノードをMiddle Relay*8、3つ目のノードをExit Relay*9と呼びます。以降では適宜EG,MR,XRと略していきます。またクライアントをCL、接続先サーバーをSVと略します。

CLとEGの鍵交換

素直にクライアントととEntry Guard間でセッション鍵 K_eg を共有します。

f:id:y0m0g1:20191220014428j:plain

CLとMRの鍵交換

クライアントとMiddle Relay間でのセッション鍵共有のために、先程暗号化したCL-EG間の通信路を用います。鍵交換ペイロードをKE、セッション鍵Kを用いた暗号化をE_K( )として、次のような通信を行います。

\begin{align} CL \rightarrow EG &: E_{K_{eg}} \left( \rightarrow MR: KE_{CL \rightarrow MR} \right) &\cdots (1) \\ EG \rightarrow MR &: KE_{CL \rightarrow MR} &\cdots (2)\\ MR \rightarrow EG &: KE_{MR \rightarrow CL} &\cdots (3)\\ EG \rightarrow CL &: E_{K_{eg}} \left(MR \rightarrow : KE_{MR \rightarrow CL} \right) &\cdots (4) \end{align}

ここでMRはCLから鍵交換ペイロードを受け取り、また送りますが、EGを介して行うためCLのアドレスを知らないままとなります。この鍵交換により、CL-MR間でセッション鍵K_mrを共有します。

f:id:y0m0g1:20191220014501j:plain

CLとXRの鍵交換

クライアントとExit Relay間でのセッション鍵共有のために、先程暗号化したCL-EG-MR間の通信路を用います。

\begin{align} CL \rightarrow EG &: E_{K_{eg}} \left( \rightarrow MR: E_{K_{mr}} \left( \rightarrow XR: KE_{CL \rightarrow XR} \right) \right) &\cdots (1) \\ EG \rightarrow MR &: E_{K_{mr}} \left( \rightarrow XR: KE_{CL \rightarrow XR} \right) &\cdots (2) \\ MR \rightarrow XR &: KE_{CL \rightarrow XR} &\cdots (3) \\ XR \rightarrow MR &: KE_{XR \rightarrow CL} &\cdots (4) \\ MR \rightarrow EG &: E_{K_{mr}} \left( XR \rightarrow : KE_{XR \rightarrow CL} \right) &\cdots (5) \\ EG \rightarrow CL &: E_{K_{eg}} \left( MR \rightarrow : E_{K_{mr}} \left( XR \rightarrow : KE_{XR \rightarrow CL} \right) \right) &\cdots (6) \end{align}

ここでXRはCLから鍵交換ペイロードを受け取り、また送りますが、MRを介して行うため、CL及びEGのアドレスを知らないままとなります。この鍵交換により、CL-XR間でセッション鍵K_xrを共有します。

f:id:y0m0g1:20191220014518j:plain

鍵交換後

各ノードがどのホストのアドレスを知り、どの鍵を持っているかは次の表のようになります。

ホスト＼アドレス・鍵	CL	EG	MR	XR	K_eg	K_mr	K_xr
Client	○	○	○	○	○	○	○
Entry Guard	○	○	○	×	○	×	×
Middle Relay	×	○	○	○	×	○	×
Exit Relay	×	×	○	○	×	×	○

アドレスに関して、CL,EG,MR,XRの4つすべてを知るホストはクライアントに限られます。つまり各ノードは通信路の全貌を把握しません。

セッション鍵について、K_eg,K_mr,K_xrの3つすべてを知るホストはクライアントに限られます。つまり、この3つを用いて暗号化された通信内容を各ノードが単体で復号することはできません。

f:id:y0m0g1:20191220014537j:plain

メッセージ送信

セッション鍵K_eg,K_mr,K_xrの3つを用いてメッセージ[Message]を暗号化して送信します。クライアントCLから接続先サーバーSVに向けて発信されるメッセージは次のようになります。

\begin{align} CL \rightarrow EG : E_{K_{eg}} \left( \rightarrow MR: E_{K_{mr}} \left( \rightarrow XR: E_{K_{xr}} \left( \rightarrow SV: [Message] \right) \right) \right) \end{align}

これはEG,MR,XRの各ノードにおいて、セッション鍵を用いて復号されます。次の通りになります。

\begin{align} EG \rightarrow MR&: E_{K_{mr}} \left( \rightarrow XR: E_{K_{xr}} \left( \rightarrow SV: [Message] \right) \right) &\cdots @EG\\ MR \rightarrow XR&: E_{K_{xr}} \left( \rightarrow SV: [Message] \right) &\cdots @MR\\ XR \rightarrow SV&: [Message] &\cdots @XR \end{align}

このようにしてクライアントからサーバーにメッセージが届けられます。

f:id:y0m0g1:20191220014644j:plain

逆に、サーバーからクライアントへの応答[Response]は次のように各ノードで暗号化されていきます。

\begin{align} SV \rightarrow XR&: [Response] &\cdots @SV\\ XR \rightarrow MR&: E_{K_{xr}} \left( SV \rightarrow: [Response] \right)&\cdots @XR\\ MR \rightarrow EG&: E_{K_{mr}} \left( XR \rightarrow : E_{K_{xr}} \left( SV \rightarrow: [Response] \right) \right) &\cdots @MR\\ EG \rightarrow CL&: E_{K_{eg}} \left( MR \rightarrow : E_{K_{mr}} \left( XR \rightarrow: E_{K_{xr}} \left( SV \rightarrow: [Response] \right) \right) \right) &\cdots @EG \end{align}

こうしてクライアントに届いたサーバーの応答は、クライアントが持つ3つのセッション鍵を用いて復号されます。

f:id:y0m0g1:20191220014621j:plain

ここで気をつけなければならないのは、XR-SV間の通信はTorで暗号化されていないことです。この間の通信を盗聴されてしまうと、攻撃者に通信内容が筒抜けになります。できれば、Torそのものを用いるときには、SSL/TLSを用いるなどにより通信内容そのものの暗号化をするべきでしょう。

また、TorはTCP専用でありUDPには対応していません。 DNS問い合わせでは一般的にUDPを用いてしまうのでTorで暗号化されず、クライアントがどのサーバーに接続するかがわかってしまい、 対策をしないと匿名性が損なわれます。

なお、これらは以降で述べるHidden Servicesでは問題にならない（はず）です

Hidden Services^*11

Torが提供する機能の一つに、サーバーのIPアドレスを知られることなく、ウェブサイトを公開したりウェブサービスを提供できるHidden Servicesというものがあります。 Hidden Servicesでは.onionという特殊な識別子を持つ疑似アドレスを用いることにより、IPアドレスを結びつけることなく、 Torを利用しているノード同士を接続できるようにします。

Hidden Servicesでランデブーポイント（RP）と呼ばれるTor上のノードを介して通信を行われます。このランデブーポイントを利用するランデブープロトコルについて説明します。

説明には電子フロンティア財団の画像を用いたりします。てかこちらのサイトの翻訳記事みたいな感じになります。

2019.www.torproject.org

ランデブープロトコルの準備

Hidden Services上で公開したいサービス（例えばウェブサイト）を、秘匿サービス（onion service）と呼びます。秘匿サービスはまず、Torネットワーク上にその存在を広告する必要があります。

そのため、秘匿サービスはいくつかのリレーを選択し、「導入ポイント」とします。導入ポイントに対してはTorサーキット*12を構築し、秘匿サービスの生成した公開鍵を広告します。 Torサーキットを用いることで、導入ポイントから秘匿サービスをホストするサーバー（のIPアドレス）を知ることを難しくします。

f:id:y0m0g1:20191219175148p:plain

図ではクライアントがAlice、秘匿サービスがBobになります。また緑の線はTorサーキットであり、リレーにより中継されていると考えていいでしょう。

秘匿サービスは、公開鍵と秘密鍵で署名した導入ポイントの概略*13を、データベースに登録します。この署名は、クライアントが XYZ.onion のような疑似アドレスで要求したときに返ってくるものです。この XYZ の部分は秘匿サービス公開鍵から派生したもので、16文字の英数字となっています。 *14 *15

f:id:y0m0g1:20191219180740p:plain

ランデブープロトコル

クライアントは秘匿サービスのonionアドレス XYZ.onion を何らかの形で知り、このアドレスに接続します。すると、データベースは XYZ.onion の要求に応じて、登録された情報を返します。同時に、クライアントはランダムにリレーを選んで*16、それを「ランデブーポイント」として決め、ワンタイムシークレットを教えます。

f:id:y0m0g1:20191219181826p:plain

ランデブーポイントの準備ができたら、RPのアドレスとワンタイムシークレットを秘匿サービスの公開鍵で暗号化した「導入」メッセージを用意します。クライアントはこのメッセージを導入ポイントの一つに送りつけ、秘匿サービスに取り次いでもらうように要求します。この通信もTorサーキットを通じて行い、導入メッセージからクライアントのIPアドレスを知ることを難しくしています。

f:id:y0m0g1:20191219234008p:plain

秘匿サービスは、クライアントの導入メッセージを導入ポイントから受け取り、これを秘密鍵で復号します。 RPのアドレスとワンタイムシークレットを入手できるので、これを元に秘匿サービスはRPに向かってTorサーキットを作り、ワンタイムシークレットを送り返します。

f:id:y0m0g1:20191219234416p:plain

最後に、RPはクライアントに向かって、接続確立の通知を送ります。この後に、クライアントと秘匿サービスはランデブーポイントを中継して、End to Endで暗号化された通信ができるようになります。クライアントは秘匿サービスのIPアドレスを知らない一方で、署名の検証により目的の秘匿サービスに接続できるようになるのです。

f:id:y0m0g1:20191219234740p:plain

導入ポイントとは別にランデブーポイントとする理由に、どのリレーも特定の秘匿サービスを担当していると見られてはいけないからです。 *17

一般的に、クライアントと秘匿サービス間の通信は6つのリレーからなります。はじめの3つ（クライアント-ランデブーポイント間）はクライアントが選択し、あとの3つ（ランデブーポイント-秘匿サービス間）は秘匿サービスが選択します。

秘匿サービスの例

以下はサーフェスウェブでもサービスが提供されていますが、秘匿サービスが用意されていてダークウェブでもサービスを受けられる例です。

BBCニュース: bbcnewsv2vjtpsuy.onion
Facebook: facebookcorewwwi.onion

終わりに

遅くなってすみませんでした

オニオンルーティングの所はわかりやすいかなと思って図を作ってみましたが、思ったよりごちゃごちゃしてしまいました。

本当はいくつか具体的なHidden Servicesに触れられればよかったのですが…… Silk RoadとかDream Marketとか？他の詳しい人のブログなどを見てください

wired.jp

www.itmedia.co.jp

気が向いたら追記するかもしれないです。

ちなみに、学内の回線ではTor Projectのホームページに接続できません。

_{これは間違いなく言論弾圧だ。断固反対する。}

f:id:y0m0g1:20191214221322p:plain — 社畜ちゃん台詞メーカーより

参考

http://www.data-house.info/book/12414.html

匿名通信「Tor」はどういう仕組みなのか分かりやすく解説 - GIGAZINE

匿名通信システム「Tor」を使うのに知っておくべき7つのこと - GIGAZINE

Welcome to Tor Metrics

布教。大空スバルはいいぞ。

面白くてとてもいい子でかわいくて見ていると笑顔になれる、ホロライブ所属のVTuberです。よかったら切り抜き動画やライブ配信を見て、チャンネル登録してみてください。

www.youtube.com

舞スバ*18は最高だし、ういママ*19もいいし、あやスバ*20てぇてぇ*21し、スバおか*22もてぇてぇぞ。

おすすめ動画↓

*1:インターネットの前身と言われるARPANETの資金提供をしたことでも知られる

*2:アメリカ合衆国の内国歳入法第501条C項3号の規定により課税を免除される非営利団体

*3:させられていた？

*4:正確には5MiB, 1MiBは2の20乗バイト。でも普通はMBもMiBもかわらない

*5:この値は公開されて第3者に知られてもOK

*6:これをTor RelayもしくはRelayと呼ぶ

*7:入口番人

*8:中間中継者

*9:出口中継者

*10:3つで十分。4つ以上だとより遅くなってしまう

*11:秘匿サービス

*12:ここではTorネットワーク上の接続経路のこと

*13:正確には、を含むonion service descriptor

*14:onion service v3では56桁になっています

*15:Zooko予想では分散型・安全・理解可能のうち2つまでが達成可能であり、.onionアドレスは分散型と安全をとったとしている

*16:導入ポイントは除かれる

*17:恐らく、Aというノードを通じた通信はBという秘匿サービスに向けられているとわかってしまうと、匿名性が損なわれるため

*18:にじさんじ所属のVTuber舞元啓介とのコラボ名。いつも地獄のような配信をしている。一方は農家のおじさんで、一方は女子高生という珍しい組み合わせだけども、盟友・ライバルみたいな感じ。舞元啓介はいいやつ。舞元啓介のYouTubeチャンネル

*19:イラストレーターのしぐれうい先生。大空スバルの絵を担当。声がめちゃくちゃきれいで可愛いけど、火炎放射器な性格。大空スバルが好きすぎる。イラストも可愛い。ちなみにVTuberの世界では、イラストレーターやモデラーをママやパパと呼びます。しぐれうい先生のTwitter

*20:ホロライブ所属のVTuber百鬼あやめとのカップリング。仲良くなりすぎてしまったせいで、最近は衣装可愛いねとか、お歌上手だったよと言えない、というのが最近の悩み。何時間も無言で作業通話を繋げてしまうけど、気まずくならないらしいし、もはや熟年夫婦。百鬼あやめはオンリーワンな可愛さある余。百鬼あやめのYouTubeチャンネル

*21:関係性が尊くて見ていてしあわせな気持ちになることの表現

*22:ホロライブ所属のVtuber猫又おかゆとのカップリング。バチバチやってるけど、猫又おかゆのほうが一枚上手で、大空スバルが痛い目にあうことが多い。最近の放送曰く、（大空スバルは）まじでおかゆのこと好きらしい。猫又おかゆはマイペース全開の感じだよ。猫又おかゆのYouTubeチャンネル

よもぎのメモ帳

備忘録的な感じで技術的なことをストックしていきます。

ゼロからのTorのお話

はじめに

まえがき

Torって何

Torの歴史