Internet Infrastructure Review（IIR）Vol.29
2015年11月25日

経路制御の仕組み

IPアドレスはインターネットで通信する際に通信機器を識別し、通信先を指し示すために使われています。無論、IPアドレスが重複するとうまく通信できなくなってしまうので、その一意性を担保するためにインターネットでは階層的管理構造を持つインターネットレジストリ（IR）がIPアドレスの分配を担っています。日本では多くの場合、アジア太平洋地域の地域別IR（RIR）であるAPNICか、日本の国別IR（NIR）であるJPNICに申請してIPアドレスの分配を受けています。

APNICやJPNICはIPアドレスの分配とそれに付随する登記情報の管理までは担いますが、そのIPアドレスを利用した際の到達性などは、分配を受けた側が担うことになります。インターネットで到達性を確保するためには、利用するIPアドレスブロックの情報を他のネットワークに通知する必要があります。現在は、BGPという経路制御プロトコルがネットワーク間の経路制御で標準的に利用されているため、各ネットワークはBGPを用いてそれぞれで利用しているIPアドレスブロックの情報を生成し、他のネットワークに通知しています。これを経路広告と呼びます。この経路広告を受けた他のネットワークでは、そのIPアドレスブロック宛のIPパケットを経路広告したネットワークに向けて転送するようになります。実際にはそれぞれのネットワークでBGPの経路制御ポリシーがあり、異なる経路で同一宛先からの経路広告を受信した場合、ルータで優先度などから最適経路として選択された経路のみがパケット転送に利用されています。BGPの経路広告自体はとても簡単な作業で、ルータに数行のコマンドを追加するだけで完了しますし、その仕様上、誰でもどんな経路でも広報できます。また、一旦広告された経路情報は経路広告したネットワークで取り消されるまで有効な経路情報として利用されます。つまり、間違って経路広告された情報は瞬時に世界に流通し、明示的に設定を取り除くまでは残り続けてしまうのです。このため、新たに経路広告する際は設定ミスや確認ミスがないように細心の注意が必要です。しかし、インターネットの広がりと共に世界の様々なネットワークがBGPで経路交換しているため、どうしてもどこかで間違いは発生する可能性があります。また、BGPで経路交換しているルータが悪意ある人間に乗っ取られた場合、勝手に経路広告される可能性もあります。各ネットワークで運用しているルータはアクセス制御や監視、定期的な設定の監査を通じて、適切に運用されてることを確認しておくことが重要です。

経路のセキュリティ

設定ミスを削減、また不正な経路広報の影響を軽減するために幾つかの手段があります。まず、経路広告する際には、そのIPアドレスブロックを経路広告する正当性を確認します。APNICやJPNICなどのIRは分配したIPアドレスの登記情報をwhoisで公開しているため、これを参照して分配を受けた組織とIPアドレスブロックに間違いがないか確認できます。また、不正な経路情報の流通を防ぐため、経路フィルタをネットワークの相互接続箇所に導入することも有効です。特に、トランジットと呼ばれる経路情報の中継を提供しているネットワークで受信経路に厳密な経路フィルタを適用することで、不正な経路情報の影響範囲を局所化することができます。このため、トランジットを提供する組織では、顧客が広報する予定のIPアドレスブロックの情報を事前に通知してもらい、それに応じて経路フィルタを更新するような運用をしている場合が多いです。それでも現実には不正な経路広告の発生が絶えません。これらの事象は「経路ハイジャック」と呼ばれることもありますが、報告される多くの事象は広報直後に訂正したと思われる経路広報が多く、意図しない設定ミスによるものがほとんどと推測されており、全般の実情を表すなら「権威なき経路広告」程度の表現が妥当だと考えています。

これら権威なき経路広告も到達性に影響を及ぼすことがあるので、発生次第検知する必要があります。検出に関しては世界で様々な取り組みが行われており、日本国内ではTelecom-ISAC JapanとJPNICが協力して経路ハイジャック検知システム「経路奉行」を運営しています。経路奉行はJPNICが運営するインターネットルーティングレジストリ（IRR）であるJPIRRに登録されたrouteオブジェクトを正常な経路状態として判断基準に採用し、これと日本国内のISPからシステムに提供されているBGP経路情報とを逐次比較して異常経路を判別するシステムです。routeオブジェクトで登録された広報元と異なる広報元から経路が広報された場合に異常と判別しており、設定ミスによる異常経路を検出するには有用なシステムです。また日本国内のISPから経路情報を得ていることから、日本国内での影響をある程度推測することもできます。IIJも当初からこのシステムの運用に加わっており、より良い検出に向けて活動を続けています。また、IIJ自身の経路を監視するために利用者としてもシステムを利用しており、実際過去にIIJが広報している経路を他ネットワークから広報された際には経路奉行からの警報を受信して対応を行っています。

検出システムで不正な経路広告を分類することは難しい作業です。例えば、経路奉行ではrouteオブジェクトの登録ミスなどによっても異常として検出しますが、これは、外部からはIPアドレスブロックの管理者が、どこでどんな利用を意図しているか分からないことから、この設定が正常かどうかの確認が困難なため、経路ハイジャックの"疑われる"事例としています。また、不正な経路広告の発生源から原因の報告を受けることも稀です。Telecom-ISAC Japanで共有されている事例でも、検出に基づいて経路広告元のネットワークに問い合わせをしても「修正しました」との回答だけで、発生理由については現場の設定ミスによるものだったのか、他の理由があったのか分からないままにされている場合が多くあります。今回、IIJが対応した事例は、原因の追求過程で行為者の悪意を明確にできた「経路ハイジャック」の貴重な事例だと考えています。

経路ハイジャック事件の概要

2015年2月4日、日本・ネットワーク・オペレーターズ・グループ（JANOG）のメーリングリストに一通のメールが投稿されました。IIJで管理しているIPv4アドレスのある/16のブロックが他のネットワークから広報されており、SpamHausのブロックリストに掲載されているという内容でした。これを受けて即座に対応を開始しました。確かに当該ブロックは米国のISPから経路広告されていたことから、経路の奪還と広告元からの経路停止を最初の目標にしました。IPの経路制御では細かい経路情報の方が優先されるため、一時的に細かい経路情報を広告して他のネットワークでIIJからの経路広告を優先するようにしました。並行して米国の当該ISPの連絡先を調べて連絡を取りました。ISPには営業の問い合わせやサービスごとのサポート窓口など様々なコンタクト先がありますが、適切な窓口に連絡しないと対応に時間がかかったり窓口に無関係な問い合わせとして放置されてしまう可能性もあります。今回のような経路制御の問題は該当組織のネットワーク運用部門（NOC）を見つける必要があり、whoisやISPのWebなどを調べて、最もそれらしい窓口を探して連絡しました。

当該ISPにメールで詳細を送った後、すぐに電話でも連絡し、メールの受領確認と対応の依頼をしました。米国のISPでは、チケットシステムを導入して作業の進捗管理をしている場合が多いため、チケット番号の発行も依頼しました。チケット番号はメールにて返送しておくとのことだったので返信を待ちましたが、24時間以上待っても返信がなかったため、再度電話にて連絡し、その場でチケットの発行と対応を依頼しました。こうしてようやくチケット番号が割り当てられ、進捗が確認できるようになりました。電話口に出たのが前回と異なる担当者だったため、その場で再度whoisの情報などを確認してもらって、我々の連絡が正当性を持つものだと認識してもらいました。そのISPからの情報によると、問題のIPv4アドレスブロックは顧客からの依頼に基づいて広告開始したそうで、念のためその顧客に連絡してみて、特に返事がなくても24時間以内には経路広告を停止することにしてもらえました。こうして、2015年2月4日午後に連絡を取り始め、3日後の2015年2月7日未明には該当の経路広告が停止しました。このIPv4アドレスブロックはSpamHausのブロックリストにも掲載されていたため、不正な経路広告停止後に削除を申請し、翌日にはリストから削除されました。

IIJで保持している経路情報の履歴を見ると、この不正な経路情報は2015年1月5日に広告開始されていましたが、IIJではJANOGに情報が投稿されるまで気がつくことができませんでした。実はこのIPアドレスブロックはIPv4アドレス移転手続きに基づいてIIJが管理することになったIPアドレスブロックで、当時は特に経路広告せずに将来の利用に備えて在庫として保持している状態でした。当然JPNICに登録したwhoisの情報などは最新の情報になっていましたが、経路広告していなかったこともあり、JPIRRなどの経路データベースには登録しておらず、先に挙げた経路奉行の監視対象になっていませんでした。このため、不正な経路広告が発生しても認識できていなかったのです。この事例を受けて管理下にあるすべてのIPアドレスブロックを見直して、JPIRRなどのIRRへの登録と経路広告を開始しました。これにより、現在はIIJ管理下にあるIPアドレスブロックはすべて経路奉行の監視対象となっています。

事件の教訓と経路ハイジャック対策

今回の事例では、当該ISPが書類審査をきちんと行っていれば不正な経路広報は防げていたはずです。LoAが到着した時点でJPNICのwhois情報はIIJの連絡先に書き換わっており、書面との相違があります。一方でwhoisの検索には多少の知識と技術も必要です。IPアドレスの登記情報を管理するIRは階層構造を成しているため、これを辿るように検索する必要があります。whoisクライアントの中にはある程度自動でこれに追従するものもありますが、国別のNIRが存在する地域は少なく、ほとんどのクライアントは地域別のRIRのwhois、つまりアジア太平洋地域ではAPNICのwhoisのレベルで検索して結果を表示するようです。JPNICに登録された情報は英語表記部分がAPNICのwhoisにも転記されて表示されるようになっていますが、これを正しく読み解くには何の情報がどう反映されているかを知っておく必要があります。インターネット黎明期に登録されたブロックはERXプロジェクトで登録者の属する地域のRIRに移管されていますし、最近では地域をまたいだIPv4移転も行えるようになってきているので、これらも適切に追従してwhois検索しないと正しい情報を得ることができません。whoisよりももう少しコンピュータで利用しやすい登記情報の形式ということで、Resource Public Key Infrastructure（RPKI）が標準化されて、利用できる状態になっています。これはIPアドレスなどの番号資源の割り振りや割り当てを電子証明書を利用して表現するものです。IRの登記情報に基づき、リソース証明書と呼ばれる電子証明書を発行することが可能で、これを検証することでIPアドレスの割り振りや割り当てを確認することができます。電子証明書を利用するため、文章への電子署名を追加することも可能です。例えばLoAにリソース証明書による電子署名を付加して、受領側で検証することで、正しいIPアドレスブロックの管理者からの文章であることが確認できます。また、経路制御にも利用可能で、現時点では経路生成元のAS番号を検証するOriginValidationという技術が標準化されて、ルータへの実装が進んでいます。運用者がPKIなどの一般的な公開鍵暗号技術を学ぶ必要がありますが、うまく運用すれば大変強固な認証基盤になるはずです。利用の普及にはまだ時間がかかると考えられますが、IIJでも検証や運用を通じてRPKIの普及に協力できればと考えています。IPアドレスの割り振りや割り当てを受けている場合、現時点でどのような対策を講じられるでしょうか。今回の事例を通じて、ターゲットとして狙われにくくし、経路広告を依頼されたISPで異常に気がつけるようにするためには、次の2つのポイントが鍵になりそうだと分かりました。

• whoisの連絡先を整備する
• 経路広告する

1.のwhoisに関しては組織名や住所、電話番号、メールアドレスなど、できる限りの連絡先を正確に記載して、参照があった際に判別に利用できるようにしておくのがお勧めです。また苦情の連絡先を探す際にwhoisを参照する場合もあるので、これらの窓口では苦情の処理を担う可能性があること、公開窓口となるため、日常的にspamを受信することになるかもしれないことを認識しておく必要があります。苦情メールにはspamが添付されていることもあり、単純な学習型やキーワードマッチ型のspamフィルタを適用すると、苦情自体もspam判定してしまい、受信できなくなる場合があるため運用に注意が必要です。

2.の経路広告に関しては、インターネットへの到達性が必要ない場合でも、念のために経路広告しておいた方が適切に運用していることを示せて安全です。ただ、経路広告すると、そのIPアドレスブロック宛のIPパケットを吸い込むことになるため、脆弱性や稼働しているサービスを探索するためのIPパケットなどが到着するようになります。無用なリスクを増やさずに現状とほぼ同じ環境を維持するには、そのIPアドレスブロック宛のパケットをすべて破棄しつつ、経路のみ広告するのがお勧めです。既に何らかのインターネット接続サービスを利用している場合には、そのISPに相談すると対応してくれる場合もありますし、必要であればIIJにご相談いただければと考えています。経路広告に際しては、経路情報のデータベースであるJPIRRに適切にrouteオブジェクトを登録することで経路奉行の監視サービスを受けることができ、万が一、不正に経路広告された場合でも早期に検出できる可能性が高まるため、併せて検討をお勧めします。

インターネットでは今後も今回の事例のような経路ハイジャックが試みられる可能性があります。大きく2つの理由が想定できます。1つ目に様々な組織がspam送信やmalwareのホスティングなどを調査してIPアドレス単位のレピュテーションデータベースを構築しており、何にでも悪用できる新たなIPアドレスブロックへの要望があること、2つ目にIPv4アドレス在庫が世界的に枯渇してきており、徐々に既存のサービスを通じて必要な量のIPv4アドレスを確保することが困難になってきていること。これらの状況から、今後も経路ハイジャックのリスクはあると考えられます。また、前述したように日本ではインターネット黎明期に割り当てられた、whoisの情報がきちんと更新されていないIPアドレスブロックが多数あり、とてもターゲットになりやすい状況にあります。経路ハイジャックによって、管理するIPアドレスブロックを悪用された場合、知らない所でブロックリストに追加されたり、レピュテーションデータベースでの評価に影響する場合が考えられ、将来の通信に影響を及ぼす可能性があります。また、見知らぬ苦情対応に巻き込まれる可能性もあるため、相応の対策を講じておくことをお勧めします。

まとめ

経路ハイジャック対策でも他のセキュリティ対策と同様に、攻撃者側のコストを高める視点が重要です。つまり経路ハイジャックされにくい環境の整備、また経路ハイジャックされても早期に検出して対応できる体制の整備などを整えることが必要だと考えています。この実現のためには、IRの登記情報の信頼度向上やRPKIの活用を通じた持ち込みIPアドレスの検証方法の見直し、厳密な経路フィルタの運用やRPKIによる経路認証など不正な経路広報の流通を防ぐ方策の導入、経路奉行やその他の異常経路検出機構による不正経路の検出技術向上、ネットワーク間で必要な情報交換と協力した対応が取れる信頼のおける協調関係の構築など様々な技術的あるいは運用上の取り組みを検討する必要があります。また法執行機関などとも相談しながら、経路ハイジャックを再発させない環境づくりを構築したいと考えています。これらの取り組みはIIJのみならず、インターネットの経路制御に関わる多くの方々と協調しながら進めていくものであるため、広くIIJの知見を共有しながら、今後も検証や議論、改善を続けていければと考えています。

SSL/TLSの経緯

Netscape Communicationsから1995年にInternet draft"draft-hickman-netscape-ssl"が公開された時期と同じくして、当時のブラウザNetscape NavigatorにSSL2.0が実装されました。その後、いくつかの拡張と問題点が修正されたSSL3.0はつい最近まで利用されていましたが、昨年10月に発表されたPOODLE攻撃はSSL3.0における根本的な問題を露呈することになり、SSLの利用は安全ではないと認識されるようになりました。現在ではSSL2.0及びSSL3.0はそれぞれ利用しないことが推奨されています（※46）。SSLの後継でありIETFで策定されたTLSは、1.0/1.1/1.2が1999/2006/2008年にそれぞれRFCとして公開されています（※47）。それぞれのバージョンにおける主な変更点は、暗号技術評価プロジェクトCRYPTRECで作成されたガイドライン（※48）にて詳しく紹介されています。概要を抜粋すると、TLS1.0にはBEAST攻撃などにおいて広く露呈したCBCモード利用時の問題が指摘されており、TLS1.1でその問題を解消しています。更にTLS1.2では、認証暗号モードに分類されるGCM、CCMやSHA-2ファミリーなど、比較的新しい暗号アルゴリズムの利用が可能になっています。

表-1は、それぞれのバージョンにおけるワークアラウンドについてまとめたものです（※49）。TLS1.0は、サーバ設定・クライアントの実装でいくつかの仕様上の問題点をカバーすることで安全に利用でき、現在最も多く利用されているバージョンです。更に、新しいTLSライブラリや暗号モジュールを利用することでTLS1.1もしくはTLS1.2に対応することが可能であり、ブラウザ側も最新バージョンにアップデートすることで、ユーザは特に意識することなく、安全なバージョンを利用できる環境にあります。しかし、根本的な解決方法がない課題も残されていることが分かります。TLS1.3では、SSL/TLSに対する様々な種類の脆弱性に対し、根本的な解決を望む声を受け、執筆時現在も改訂・議論が繰り返されています。TLS1.3ドラフトの技術的な解説は後述します。

拡大する

表-1 SSL/TLSバージョンの違いによるステータスの違い

SSL/TLSの概要とその役割

SSL/TLSは、（1）通信の暗号化、（2）データ完全性の確保、（3）サーバ認証（場合によりクライアント認証）の機能を提供します。セッション層に位置することで、アプリケーション層ごとにセキュリティ確保のための仕組みを実装する必要がなく、HTTP・SMTP・POPなど、様々なプロトコルの下位に位置して上記のセキュリティ機能を提供することができます。アプリケーション層の各種プロトコルに依存する必要がないメリットを持つため、幅広く実装される結果となりました。

図-15は、TLS1.2におけるメッセージフローを示したものです。アプリケーションデータを暗号化するまでにはHandshakeメッセージと呼ばれる事前処理が存在しており、4-wayのフローで構成されていることが分かります。以下、Handshakeメッセージに関して簡単に役割を示します。（1）クライアント（ブラウザ）から、理解可能な暗号アルゴリズムリストであるCipherSuiteの束をサーバに送付します。（2）サーバは、その中から最も良いと考える1つのCipherSuiteを選択してServerHelloを通じて通知すると共に、サーバ認証に必要なX.509証明書や鍵交換のために必要な公開鍵などの情報をクライアントに返却します。（3）クライアントは、サーバ公開鍵を受領したことから、サーバにしか復号できない情報を送信することができます。これをサーバが受領し復号した時点で、各種鍵データの元となるMaster Secretを共有します。最後に「これから暗号化します」という意味を持つCCS（ChangeCipherSpec）を送った後、暗号化データFinishedを送付します。サーバはこれを復号し、内包されているMACデータ（メッセージ完全性を保証するデータ）をチェックし、これまでに送受信したメッセージが改ざんされていないことを確認します。（4）最後に、サーバからもCCS及び暗号化データFinishedを送付し、それを受け取ったクライアントはサーバ側の挙動と同様に復号処理とMACデータをチェックして、アプリケーションデータを安全に送受信する体制が整えることができます。

データ暗号化に用いる鍵は、公開鍵暗号方式を用いることでクライアントとサーバにしか分からないように生成することから、暗号化機能を提供しています。また、MACデータの保証範囲はFinishedよりも前の平文データすべてであるため、もし仮に途中の経路で改ざんされたとしてもそれを検知する仕組みを持っています。更に、X.509証明書を相手ノードに提示すると共に、証明書内の公開鍵に呼応する秘密鍵を保持していることを確認することで、サーバ認証・クライアント認証を行うことができます。

TLS1.3

TLS1.3（※50）は、執筆時現在も改訂・議論が繰り返されています。最終的な仕様との比較ではないですが、TLS1.2までと比べると、以下に列挙したようなかなりドラスティックな変更が行われる見込みです。

• 危殆化したアルゴリズム及び暗号モードの排除
• メッセージフローの簡素化とHandshakeメッセージの暗号化
• 擬似乱数関数の整理、Master Secretの計算方法や各種鍵生成方式の変更

上記は変更点のすべてではないですが、多くの改善を試みていることが分かり、エンジニアもその動向について注目しています。日本でもCELLOS（暗号プロトコル評価技術コンソーシアム）の呼びかけのもと、最新ドラフトの読み合わせ会が開催されているほか、それらのレビュー結果をTLS WGにフィードバックするなどの試みがなされました（※51）。上記で挙げた変更点に関して、以下、技術的な側面について簡単に解説します。

（1）危殆化したアルゴリズム及び暗号モードの排除

脆弱であると認識されている暗号アルゴリズムDES、MD5、RC4などが排除されます（※52）。特に、RC4はTLS1.3策定とは独立して排除しようという動きが見られ、主要ブラウザベンダーからも2016年の早い時期にRC4を無効化するアナウンスが既になされています（※53）。SHA-1及びSHA-2シリーズのうちSHA-224についても署名における利用が排除されています。しかし、サーバ証明書を検証するために辿る証明書チェーンの中には完全にSHA-1を用いた証明書を排除できていないため、この点をどう扱うかに関しては現在も議論が進められています。また、BEAST攻撃やPOODLE攻撃などを誘引したCBC暗号モードが排除され、共通鍵暗号としてはAEAD（Authenticated Encryption with Associated Data）のみの利用に統一されます。AEADのコンペティションCAESAR（※54）が2013年より開催されており、現在Round-2のフェーズにあり、2017年末をめどにWinner（s）が決定する予定です。TLS1.3では、CAESARの結果が反映されるのかについて不明瞭ですが、現在のドラフトバージョンでは、AEADの1つであるChaCha20-Poly1305（※55）がAES-GCM、AES-CCM（※56）と並んで実装必須（Mandatory Algorithms）として記載されています。他の共通鍵暗号アルゴリズムとしては、韓国のARIAと日本製のCamelliaが記載されています（※57）。今後、他のアルゴリズム記載の要請が殺到することが予想されるため、どのようなプロセスで最終決定されるのかについては、詳細に詰められていくものと考えられます。

公開鍵暗号としては、離散対数問題の難しさが安全性を担保するDSAが排除されました。DSAは現時点で脆弱な暗号アルゴリズムではありませんが、楕円曲線上の演算を使うことで暗号処理を軽減したECDSAの利用にシフトしています（署名としてはECDSAだけではなく、暗号化もデジタル署名もRSAを利用するCipherSuitesが残されています）。一方で、鍵交換に使われるDHは排除されることなくECDHと共に残っています。また、DH、ECDHを利用する際には、Forward secrecy（※58）を満たすように毎回異なる鍵（Ephemeral keys）を生成するDHE、ECDHEのみがCipherSuitesリストに記載されています。また楕円曲線としては、近年のIETFでのPervasive Monitoring（※59）の議論を受け、NISTが策定したsecp256r1（Curve P-256）などのCurve（※60）だけでなく、D. J. Bernsteinにより、PKC2006にて発表されたCurve25519（※61）も実装することが推奨（SHOULD）されています。Curveに関する議論は、横浜で開催されたIETF-94や今年12月に日本で開催されるSSR2015（The 2nd InternationalConference on Research in Security Standardisation）でも最新の話題として取り上げられる見込みです（※62）。

（2）メッセージフローの簡素化とHandshakeメッセージの暗号化

TLS1.2までのHandshakeにおいては、クライアントからCipherSuitesリストをサーバに送付してサーバが1つ選択する方式を採っています。一方TLS1.3では、この律儀な挙動を削減して、クライアントから1つのCipherSuiteを決め打ちで送付することから開始します。これにより、暗号化及びデータ完全性を保証するための鍵共有を、図-16のように4-wayから3-wayに削減することができます。更に、TLS1.2まではFinishedメッセージから暗号化していますが、TLS1.3ではMaster Secretを共有する前から、事前鍵を用意してHandshakeメッセージの一部を暗号化するように変更されています。

（3）擬似乱数関数の整理、Master Secretの計算方法や各種鍵生成方式の変更

Handshakeメッセージを暗号化する際には、RFC 5869で規定されているHMACを用いた鍵導出関数を用いて鍵共有が行われています。この変更に伴い、Master Secretの導出方法も大きく見直されており、各フェーズにおいて独立した暗号鍵が用いられています。現在のところMaster Secret以外にもStatic SecretとEphemeral Secretと呼ばれる事前鍵が生成され、これらを用いてHandshakeメッセージの暗号化が段階的に行われる見込みです。また、これら2つの事前鍵からMaster Secretが生成されるように設計されています。なお、これら3つの鍵データから共通鍵暗号に用いられる実際の鍵が派生されますが、AEADは暗号化とMAC付与（メッセージ認証）を同時に行う方式のため、鍵派生においてはMAC用鍵を生成する方法が削除されています。

このように様々な試みが検討されており、TLS1.3が本当に安全なプロトコルであるのかについて透明性を持って議論が継続されています。もう1つの方向性としては、ProVerifなどの形式検証ツールを用いて当該プロトコルが安全であるかどうかを検証しようとする試みです（※63）。新しい暗号アルゴリズム提案時に、証明可能安全性を保証することが必須であるように、セキュアプロトコルについても同じような共通認識が生まれる可能性もあるでしょう。

実装の問題を誘発する要因を排除したい

暗号アルゴリズムや擬似乱数生成モジュールの利用に対して、設計者は当然と考えていることが、実は実装者には周知されていないという問題があります。意図せず秘密鍵を共有していた公開鍵使い回し問題や、データ暗号化鍵がハードコーディングされ、毎回同じ鍵で暗号化されている実装などがそれにあたります（※64）。お互いにコンセンサスがないために実装時にぶれが生じてしまうだけでなく、脆弱性を誘発してしまうことが大きな要因と考えられています。更にRFCなどの仕様文書が自然言語で表現されていることから曖昧さが残り、実装者によって解釈が異なるという問題も残されています。TLS1.3ドラフトにおいても、文書・文章の在り方を再認識する必要があるでしょう。そのため、プロトコル自身も無駄な箇所を排除していくだけでなく、文章の曖昧さも削ぎ落としていく試みも必要ではないかと考えます。

1. （※46）これまでのSSL/TLS策定の歴史的背景については、Rolf Oppliger著、"SSL and TLS：Theory and Practice"に詳しい。また、SSLの利用が推奨されない理由については、以下の2つのRFCにまとまっている。"RFC 6176：Prohibiting Secure Sockets Layer（SSL） Version 2.0"（https://tools.ietf.org/html/rfc6176）、"RFC 7568：Deprecating Secure Sockets Layer Version 3.0"（https://tools.ietf.org/html/7568）。
2. （※47）"RFC 2246：The TLS Protocol Version 1.0"（https://tools.ietf.org/html/2246）、"RFC 4346：The Transport Layer Security（TLS）Protocol Version 1.1"（https://tools.ietf.org/html/4346）、"RFC5246：The Transport Layer Security（TLS）Protocol Version 1.2"（https://tools.ietf.org/html/5246）。
3. （※48）IPA、「SSL/TLS 暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～」（https://www.ipa.go.jp/security/vuln/ssl_crypt_config.html）。
4. （※49）前述したSSL/TLS暗号設定ガイドラインやMozillaプロジェクトによる"Security/Server Side TLS"（https://wiki.mozilla.org/Security/Server_Side_TLS）、"RFC 7525：Recommendations for Secure Use of T ransport Layer Security（TLS） and Datagram Transport Layer Security（DTLS）"（http://tools.ietf.org/html/rfc7525）などで推奨設定が参照できる。また、"RFC 7457：Summarizing Known Attacks on T ransport Layer Security（TLS） and Datagram TLS（DTLS）"（https://tools.ietf.org/html/rfc7457）が公開されおり、これまでの攻撃について概要を掴むことができる。
5. （※50）"The Transport Layer Security（TLS） Protocol Version 1.3"（https://tlswg.github.io/tls13-spec/）、または"The Transport Layer Security（TLS） Protocol Version 1.3"（https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/）で参照可能である。執筆時のドラフト最新版は、バージョン10であった。
6. （※51）6月から9月にかけて4回に渡って行われた勉強会では、ドラフトversion-08に対するコメントをまとめ、公開している（https://www.cellos-consortium.org/studygroup/tls_1_3-draft_08_issues_rev1.pdf）。このコメントは、TLS-WG MLにも展開され（http://www.ietf.org/mail-archive/web/tls/current/msg17904.html）、それらの現在の対応状況については、GitHubにて参照可能である（https://github.com/tlswg/tls13-spec/search?q=CELLOS&type=Issues&utf8=%E2%9C%93）。
7. （※52）DESは、TLS1.2で既に排除済みである。MD5排除の背景は、"RFC 6151：Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms"（https://tools.ietf.org/html/6151）を参照のこと。同様に、RC4についても"RFC 7465：Prohibiting RC4 Cipher Suites"（https://tools.ietf.org/html/7465）で参照できる。
8. （※53）The RC4 NOMORE Attack（https://www.rc4nomore.com/）が今夏のUSENIX security'15で公開されるなど、RC4排除に向けて追い討ちをかける結果となった。主要ブラウザベンダーの動きについては、以下のとおり、"Ending support for the RC4 cipher in Microsoft Edge and Internet Explorer 11"（http://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11/）、"Deprecating the RC4 Cipher"（https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/）、"Intent to deprecate：RC4"（https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ）。
9. （※54）Cryptographic competitions、"CAESAR：Competition for Authenticated Encryption：Security, Applicability, and Robustness"（http://competitions.cr.yp.to/caesar.html）。
10. （※55）"RFC 7539：ChaCha20 and Poly1305 for IETF Protocols"（https://tools.ietf.org/html/rfc7539）。
11. （※56）"RFC 5288：AES Galois Counter Mode （GCM） Cipher Suites for TLS"（https://tools.ietf.org/html/rfc5288）、"RFC 6655：AES-CCM Cipher Suitesfor Transport Layer Security（TLS）"（https://tools.ietf.org/html/rfc6655）。
12. （※57）"RFC 6209：Addition of the ARIA Cipher Suites to Transport Layer Security（TLS）"（https://tools.ietf.org/html/rfc6209）、"RFC 6367：Addition of the Camellia Cipher Suites to Transport Layer Security（TLS）"（https://tools.ietf.org/html/rfc6367）。
13. （※58）IIJ IIR vol.22、1.4.2 Forward Secrecy（http://www.iij.ad.jp/dev/report/iir/022.html）。
14. （※59）"RFC 7258：Pervasive Monitoring Is an Attack"（https://tools.ietf.org/html/rfc7258）。
15. （※60）National Institute of Standards and Technology、"FIPS PUB 186-4、Digital Signature Standard（DSS）"（http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf）。
16. （※61）"A state-of-the-art Diffie-Hellman function"（http://cr.yp.to/ecdh.html）。
17. （※62）翌月東京で開催されるSSR2015（http://ssr2015.com/）では、招待講演またはパネルディスカッションのいずれかでCurvesを含む暗号アルゴリズム選定に関する話題が取り上げられる見込みである。IETF-94では楕円曲線に関するCipherSuitesを規定するRFC4492（https://tools.ietf.org/html/rfc4492）の改訂に関する議題も取り上げられている（https://www.ietf.org/proceedings/94/slides/slides-94-tls-0.pdf）。同会議ではRSA署名のフォーマットの移行に関しても触れられた。具体的にはRSASSA-PKCS1-v1_5（PKCS#1 version1.5で定義）をRSASSA-PSS（https://tools.ietf.org/html/rfc3447）に移行するトピックであった（https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf）。
18. （※63）荒井、渡辺、櫻田、ProVerifによるTLS1.3ハンドシェイクプロトコルの形式検証、3C2-1、コンピュータセキュリティシンポジウム2015（http://www.iwsec.org/css/2015/program.htm#i3C2）。他にも、別の検証ツールを用いたTLS1.3への攻撃の報告も行われている（https://www.ietf.org/mail-archive/web/tls/current/msg18215.html）。
19. （※64）PKI Day 2012発表資料（http://www.jnsa.org/seminar/pki-day/2012/data/PM02_suga.pdf）やCRYPTREC シンポジウム2015資料（http://cryptrec.go.jp/topics/cryptrec_20150424_symposium2015_presentation.html）などを参考のこと。また、ランダムデータのミスユースについて考慮されている方式も存在する（https://tools.ietf.org/html/rfc6979）。DSAやECDSAでは署名する度にランダムなデータが必要になるが、これを署名対象データに応じて決定的（Deterministic）にすることで、実装のミスを減らそうとする試みである。

1.インフラストラクチャセキュリティ

• 1.1 はじめに
• 1.2 インシデントサマリ
• 1.3 インシデントサーベイ
• 1.4 フォーカスリサーチ
• 1.5 おわりに