Security_Engineering___Third_Edition_Chapter.20.pdf

Transcript

1. Security Engineering Third Edition 1 Chapter 20: Advanced Cryptographic Engineering @fhiyo
2. 20.1 Introduction • 暗号化はより複雑な設計を行うために必要な信頼に足るコンポーネントを作 るためによく使用される • そのような設計は3つの異なる背景から生まれている ◦ 政府システム ▪ データダイオードや多段暗号化デバイスなどのメカニズムを用いて、信用する機器を最 小限にする ◦ 銀行 ▪ スマートカードを認証トークンとして、HSMをPINとキーを保護するために使う ◦ 1980, 90年代の暗号研究 ▪ 数学で社会問題を解決する夢を見ていた • 匿名通信、検閲に強い出版、追跡不可能な電子通貨、不正ができない電子選挙な ど • いずれのケースにおいても、現実は予想よりも複雑であることが分かった 2
3. 20.1 Introduction • この章では6つの暗号化エンジニアリングの例について議論していく ◦ フルディスク暗号化 ◦ シグナルプロトコル ◦ Tor ◦ ハードウェアセキュリティモジュール (HSM) ◦ エンクレーブ ◦ ブロックチェーン • 下5つは広範なアプリケーションをサポートするための複雑な方法で暗号化 を使っており、下3つについては決済系のアプリケーションを含む 3
4. 20.1 Introduction • ハードディスク暗号化 ◦ 1980年ごろから出てきた ◦ マシンを使うときにハードディスクを暗号化することで、仮にマシンが盗まれてもデータは 盗まれないことを保証できる • シグナル ◦ 携帯電話間で安全にメッセージを送るためのプロトコル ◦ 複雑さの点で (ハードディスク暗号化と比べて) 一つ上 ◦ 機器の侵害の際になるべく安全にソーシャルネットワークを管理する • Tor ◦ 匿名性の提供 ◦ 話している相手やどのwebサイトに訪問したかなどのトラフィックを観察されないようにす る 4
5. 20.1 Introduction • ハードウェアセキュリティモジュール (HSM) ◦ 1980年以降決済サービスのためのトラストプラットフォームとして提供されてきた ◦ HSM上で実行される暗号化アプリケーションは修正が困難な決済アプリと深く絡み合ってい るのでAPIに対して攻撃を受ける可能性 • エンクレーブ ◦ CPUベンダが汎用暗号プラットフォームを提供する試み ▪ 2004年のArmのTrustZone, 2015年のIntelのSGX ◦ サイドチャネル攻撃などに悩まされている • ビットコイン ◦ 2009年以降、暗号化技術を使って互いに信用できない集団同士が協力して共有台帳を作り、 それに基づいてデジタル通貨を作成する方法が登場 ◦ 暗号と経済的インセンティブの組み合わせのおかげで何とか信頼できるコンピュータが現 れ、攻撃により莫大な金額が奪われる可能性がありながらも存続している 5
6. 20.2 Full-disk encryption • 概念は単純で、ディスクに書き込むときに暗号化し、読み出すときに復号す る ◦ キーはパスワードなどの初期認証ステップに依存しており、マシンがスリープしたりオフに なると認証情報は忘れられる ◦ これによりたとえばラップトップを電車に忘れても、ハードウェアは無くしてもデータを漏 洩はしない ◦ 多くの業界でFDEは規制上の要件になっている ▪ 欧州のプライバシー規制当局はFDEが施されているマシンを紛失しても、罰金対象でも ないしデータ主体への通知義務もないと見ている 6
7. 20.2 Full-disk encryption • 品質には大きなばらつきがある ◦ 1980年代初期のソフトウェアFDE製品はパフォーマンス上のペナルティがあり、ハードウェ ア製品は高価で輸出規制がされていた ◦ 初期認証手順を行うプラットフォームが必要なため、エンジニアリングは簡単ではない ▪ 初期の製品では追加の暗号化ボリュームを提供していたが、OSは保護されておらずマ ルウェアで侵害される可能性があった ▪ ユーザーパスワードでキーを導出する仕組みの場合、窃盗犯はオフラインで無数のパス ワードを試すことができる • TPMチップでパスワードを推測する攻撃は (試行回数が？) 制限され、2007年か らはWindowsではBitLockerが使えるようになった ◦ FDEをプラットフォームに統合することで複雑なやり取りに対して一貫したメカニズムを設 計できるようになった ▪ OSの正規コピーによる信頼されたブート ▪ リカバリーキーの設定と管理 ▪ ソフトウェアアップグレード ▪ デバイス修復 ▪ 工場出荷時設定へのリセットなど 7
8. 20.2 Full-disk encryption • サードパーティー製品の追加機能 ◦ TrueCrypt ▪ パスワードを知らなければディスクボリュームの存在自体が隠されるステガノグラ フィックファイルシステム ◦ EncroChat ▪ 犯罪者用に販売された暗号化電話 ▪ 暗号化チャットとVoIPアプリケーションが隠されたパーティションにある ◦ XTS-AES (FDE用に設計された動作モード) ▪ 各ブロックをセクタ番号のソルト付きで暗号化する手法を取り、ディスクブロックにブ ロック暗号を適用する ▪ MicrosoftのBitLockerやAppleのFileVaultはAESサポートのCPUであればオーバーヘッ ドは数%しかない 8
9. 20.2 Full-disk encryption • 2008年、プリンストン大学のAlex Haldermanらがコールドブート攻撃を考案 ◦ 市場の主要な製品は破られ、現在でも多くのマシンで残っている問題 ◦ 暗号鍵を保存したDRAMの状態を保存し、軽量なOSでリブートしてメモリイメージを獲得し、そこから暗号 鍵を読むことでディスクの復号をする ▪ (DRAMのデータ残留性の問題をついている。リフレッシュをしなくても意外とデータは残っている) • 2015年、ほとんどのAndroidは安全ではないことが分かった ◦ 工場出荷状態に戻す機能がほとんどのOEMによって不適切に設計されていたため、FDEキーを含むクレデン シャルを中古デバイスから復元できる状態になっていた ◦ ほとんどのAndroid製品は一度販売終了になるとパッチは当たらない • 2019年、Carlo MeijerとBernard van Gastelは市場に出ているサードパーティー製の FDE製品の60%を占める3つの製品は安全でなく、OSSの製品の方がマシなことを調べた ◦ BitLockerはそれらの製品がある場合自動でoffになる ▪ が、この発表のおかげで今は修正されている • S3バケットは中のデータを暗号化しているが、S3の問題は大体アクセス権限の管理ミスに よるもの ◦ S3の暗号化は監査用以外で役に立つのか不明 9
10. 20.2 Full-disk encryption • 悪用 ◦ FDEコードが簡単に手に入ることはランサムウェア攻撃のブームを引き起こす一つの要素と なった ▪ ランサムウェア攻撃 • ギャングなどがシステムに侵入してFDEをインストール、復旧が困難になるまで 暗号化してから暗号化キーに対して金銭を要求する • もう一つの要素に暗号通貨があるが、この章の後で説明する • 乱用 ◦ ラップトップを電車に忘れてもFDEされてるからといって報告しない ▪ パスワードが推測できるようなものだったらダメ ▪ FDEを侵害に対しての魔法の保険だと思っている 10
11. 20.3 Signal • signal ◦ 無料のメッセージングアプリで、メッセージのエンドツーエンドの暗号化を行い、標準を確立 ▪ 後に競合のWhatsAppなども採用するようになった ◦ 以前からPGPなどで電子メールを暗号化することはできたが、面倒で普及せず (通信経路は暗号化で きても経路終端のサーバーはメールの内容が読めてしまう) ▪ 新しいプラットフォームの登場で暗号化をユニバーサルなものに ◦ スノーデン事件による暴露で暗号化の一般の需要が高まった ◦ アメリカでは2016年の選挙後ユーザーが大幅増加、欧州委員会では2020年に外交情報が入ったサー バーが侵害された後にSignalを使うように • モバイルメッセージは非常に機密性が高い ◦ 恋人同士の約束からビジネス取引、外交サミットでの政治的陰謀まで ◦ 一方で携帯を無くしたり取られたり、修理のために送られることもあるため、電話内のキーは頻繁に 侵害にされされている ▪ 一つの秘密鍵が長期間置いてあるだけでは十分でない • Signalプロトコルは前方秘匿性と後方秘匿性を提供しており、これらは侵害後のセ キュリティとして公式化されている ◦ 前方秘匿性: 今日のキーが侵害されても将来のトラフィックが露出しない ◦ 後方秘匿性: 今日のキーが侵害されても過去のトラフィックが露出しない 11
12. 20.3 Signal • プロトコルの主要コンポーネント a. 通信相手同士とサーバーのキーを設定するためのExtended Triple Diffie-Hellman (X3DH) プ ロトコル b. 秘密鍵が確立された後にメッセージキーを導出するラチェットプロトコル ▪ double ratchet algorithm: https://knowledge.complexsecurity.io/cryptography/dra/ c. アドレス帳内にいる他人のsignalキーを見つけるためのメカニズム 12
13. 20.3 Signal • Extended Triple Diffie-Hellman (X3DH) プロトコル ◦ 通常のDiffie-Hellmanは、メッセージ送信時に通信相手がオンラインとは限らないので使えない ◦ 共通鍵を作るという点では通常のDH鍵交換と同じ ◦ 以下、AliceがBobにメッセージを送信するとする i. Bobは以下をあらかじめサーバーに送っておく • アイデンティティーキー: IK_b • 署名済み事前鍵: SPK_b • SPK_bに対するIK_bを用いた署名 ii. AliceはサーバーからIK_bとSPK_bを取得する iii. 一時Diffle-Hellmanキー EK_aを生成し、Bobのキーを組み合わせる • DH1=DH(IK_a, SPK_b), DH2=DH(EK_a, IK_b), DH3=DH(EK_a, SPK_b) ◦ DH(PK1, PK2) は楕円曲線Diffie-Hellman関数の出力 • DH1, DH2, DH3を結合してハッシュを取ることで新規のDiffle-HellmanキーSKを得る iv. AliceはBobに、SKで暗号化した検証用メッセージとともにIK_a, EK_a, 使用した事前鍵の情報 を送る v. BobはIK_a, EK_aをもらえば、あとは自分の鍵の情報からSKを生成することができ、検証用 メッセージを復号して生成した鍵が正しいかチェックもできる 13
14. 20.3 Signal • double ratchet algorithm ◦ 初期Diffie-HellmanキーSKから個々のメッセージや通話 用のメッセージキーを導出するためのアルゴリズム ◦ 電話が侵害されても前方/後方秘匿性を保つことが目的 ▪ トラフィック上のメッセージを盗みたければAlice かBobの電話を盗むしかない状態にする ◦ 2つのメカニズムを使用 ▪ 鍵導出関数 (KDF, 共有鍵を更新するための一方向 ハッシュ関数. Symmetric-Key Ratchet) ▪ Diffie-Hellman鍵交換 (Diffie-Hellman Ratchet) ◦ AliceとBobは送信と受信それぞれでKDF chainと Diffie-Hellmanキーを維持する ◦ 送信されるメッセージにはDiffie-Hellman鍵の一部を含ん でおり、これに鍵導出関数を使って新しい共有鍵を作る ◦ 実際はメッセージの順番が前後する場合があるのでもう 少し複雑 14 https://signal.org/docs/specifications/doubleratchet/
15. 20.3 Signal • 最初の認証ステップが注意が必要な部分 ◦ もしCharlieがサーバーを乗っ取り、BobのIKの代わりに自分のものをAliceに送ればすべてが駄目になる ◦ これを実際に行った諜報機関もあった ◦ AppleのiMessageは単一のIKを送るのではなく、アカウントに紐づく全デバイスのkeyringを送るようにして いる ▪ GCHQ (Government Communications Headquarters, 政府通信本部) のIan LevyとCrispin Robinson は英国の捜査権限法案を使用して、令状を取得したユーザーのkeyringに法執行鍵を追加することを検 討している • (この鍵を使ってユーザーの通信を解読する？) ▪ Signalはこのような機能をこっそり入れられることを未然に防ぐためにSignalをOSSにしている • CharlieはBobの電話番号を盗めばSignal上でBobのなりすましもできる ◦ 電話をハッキングする ◦ 共有線信号No.7 (電話網用のシグナリングプロトコル, SS7) の脆弱性を利用してBobのSMSメッセージを盗む ◦ SIM swappingを行う (12.7.4で説明) ▪ Signalでは以前アクティブだった端末とは別端末でサービスのリカバリをする場合は追加のPINが必要 になっている 15
16. 20.3 Signal • 内部告発者にとっての問題: 何人が容疑者になるかの匿名性 ◦ 新聞社に違法な政策を漏らそうと考えている上級公務員がいたとして、その話を知っている 10人のうちSignalを使っているのは一人しかいなければバレてしまう ◦ 逆に何百人も容疑者がいる状況であれば、Signalはプライベートな接触を隠すことができる ので役に立つ • アドレス帳内のSignalユーザーを見つけるための方法 ◦ アドレス帳の内容を企業に送るのではプライバシーの侵害になるので駄目 ◦ Signalのオリジナルバージョンでは電話番号のハッシュを比較して使用者を検出していた ▪ Christof Hagenと同僚は100のアカウントを使ってアメリカの5億個の電話番号を全て 調べ、250万のSignalユーザーを見つけた ▪ 今はプライベートな連絡先検出方法を実装している • 重要な通信を担うアプリのガバナンスはどのようにするべきか ◦ 2020年7月、SignalはアップデートでPINの選択を強制 ▪ 連絡先データの暗号化や復旧方法の確立などを意図していた ▪ ユーザー目線ではメッセージの保持、PINの安全性、中央集権的なデータ管理に疑問が 投げられ、抗議が起こった 16
17. 20.4 Tor • The Onion Router (Tor): オンライン上での匿名性を保つための主要システム ◦ 2020年時点で200万の同時接続ユーザーがいる ◦ 1998年にアメリカ海軍調査研究所 (United States Naval Research Laboratory) が始めた ◦ AliceがEveのwebサイトに自分を識別されないように訪れたい場合、BobのTorリレーサーバにTLS接 続をし、BobのリレーサーバはCarolのサーバに、CarolのサーバはDavidのサーバに接続し、Davidの サーバがEveのサーバに接続する ▪ ENC_b(ENC_c(ENC_d(メッセージ)))のように多重に暗号化 ▪ このDividのサーバを出口ノードという ▪ ref: https://unit42.paloaltonetworks.jp/tor-traffic-enterprise-networks/ ◦ 各リレーサーバはボランティアが運営。2020年でアクティブなものが6000個 • 2003年に通信の匿名性を担保するために公開された ◦ アメリカの諜報機関しか使わなければTorの通信はすべて標的になるので、他の通信に紛れさせたい • 米国非営利団体Tor Projectによって管理されている ◦ TorクライアントのデフォルトTor Browserも管理 ▪ 経路のセットアップや暗号化だけでなく、プライバシーに危険を及ぼすCookieやJavaScriptも 管理 • 似た機能はBraveなど他のブラウザでも実装されている 17
18. 20.4 Tor • 20年間運用され、脅威や悪用に向き合いながら進化してきた ◦ イランやパキスタンのような国で検閲を回避し、Facebookやアメリカ・欧州の新聞記事にア クセス ◦ ドラッグやマルウェアの闇市場へのアクセス ◦ 機密情報のリーク ◦ 児童性的虐待サイトへのアクセス ▪ 警察もTorを使用してアクセスする 18
19. 20.4 Tor • 問題 ◦ 主要な脆弱性はTorが世間に登場する6年前から指摘されていたが、不注意なユーザーがよく 見逃す ◦ Eveのwebサイトが暗号化をしていないか、中間者攻撃ができるような形で暗号化をしている 場合、悪意のある出口ノードがトラフィックを監視できる ▪ 2007年9月、何者かが5つの出口ノードを監視してそのトラフィックを公開 • イラン、インド、日本、ロシアの大使館が使用するwebメールのアカウントのロ グイン、パスワードの情報が含まれていた ◦ トラッキング ▪ 多くのアプリケーションがユーザーを明示的に識別しているか、気づかず識別情報を漏 らしている ▪ Tor Browserが2008年にクッキーとその他フィンガープリンティング機構のトラッキン グ能力を制限するようになった主な理由 19
20. 20.4 Tor • 問題 ◦ トラフィック確認攻撃 ▪ Torに限らず、通信経路を特定するには少数のノードを監視するだけで十分 • とはいえ簡単ではないらしいが ▪ Torは当初からこの攻撃から保護できないことを明確にしていた ▪ 入口と出口のノードを制御下におき、タイミングや量などの特性の相関を見ることで経路を識 別する • 2014年には実際に起こっており、プロトコルのヘッダに細工をして追いやすいようにし ていた • 現在は対策が取られてはいるが、依然として脅威 ◦ IPアドレスブロック ▪ Torは6000個のリレーサーバに依存しているため、それらのIPをブロックすれば使えない ▪ いくつかの企業や国、特に中国がブロックを行っている ▪ ブロッキングの対策のために、Tor Bridgeという公開リストにないサーバーを用意している ▪ 中国ではGreat Firewallの回避方法としてVPNとTorがあるが、いざというときに (VPNサーバ をブロックするなどで？) 制限かけやすいVPNの方が政府としては都合がいいようだ 20
21. 20.4 Tor • 法執行機関はTorネットワーク上でのみ利用可能なTorオニオンサービスを発 見して閉鎖させることに何度も成功している ◦ Torオニオンサービス: 通常のURLではなく、 .onion アドレスを持つwebサイト ◦ 有名なものはSilk Road ▪ 運用上のセキュリティが不十分だったために運用者の逮捕につながった • 新サービスの発表に使ったメールアドレスから特定できた ◦ 他にもサーバーがハックされたり、サプライチェーンから辿られたり ▪ 多くは暗号通貨を使っており、これも様々な方法で追跡ができる ◦ 技術的に問題がなくても、元々匿名性は非常に困難 ▪ 現実のトランザクションは汚いもので、思わぬところから痕跡が生じる 21
22. 20.4 Tor • コンプライアンスと深く関わりがある ◦ さまざまな主体が監視を逃れ、良い法律も悪い法律も回避している • パフォーマンスの問題 ◦ (複雑な通信をしているから？) 速度は遅く、webサイトの読み込みが秒単位 • ガバナンス ◦ 本質的には人権を動機とする国際コミュニティであり続けている ◦ Torを構成しているグループ ▪ エンジニア: 政治的な問題をエンジニアリングで解決しようとしている ▪ 活動家: 反人種差別などの価値観に基づいて戦っている ▪ Torリレー保守の人々: 政治的に中立で、自分たちの活動を "Security as a service" と みなしている • 大規模なセキュリティにはインフラが必要 22
23. 20.5 HSMs • Hardware Security Module: 暗号鍵を保護・管 理するための耐タンパ性を持つ物理デバイス ◦ 筐体の開封や温度変化などのタンパ検知機構や電磁シー ルドでサイドチャネル攻撃などを防ぐ ◦ 銀行のATMや認証局のルート証明書の保護などで使用 • banking and bookkeepingでの章ではHSMがど のように責任の分離を強制するかを学んだ ◦ 銀行ではどの担当者も単独では顧客のカード情報やPIN を入手できないようになっている • 2000年には筆者含めたグループが銀行のHSMの APIが非常に複雑になっていたため脆弱性がある ことを予想し調査、多数の脆弱性を見つけた • この節では銀行、ATMのHSMにある脆弱性につ いて見ていく 23 https://www.mtg.de/en/hardware-security-modules/what-is-a-hsm/
24. 20.5.1 The xor-to-null-key attack • PINの導出鍵を平文で出力できる脆弱性 ◦ 2つの鍵を組み合わせて端末のマスターキーを生成するトランザクションを悪用 ▪ 暗号化された2つの鍵を与えると、それらを復号し、xorしたものを返す • 自分自身とxorしたら当然全bit0になる ◦ 任意の鍵を特定の鍵で暗号化したものを出力できるトランザクションと組み合わせる ▪ 顧客のアカウント番号からPINを導出する鍵を上の全bit0のキーで暗号化 (xor) した ら？ • ドキュメントに必要な情報が書いておらず、デバイス内の様々な鍵が何をす るか分からなかったためこの脆弱性は何年も発見されなかった ◦ 銀行が多くの機能をATMネットワークに要求したため、複雑に、分かりづらくなった • 他にも、顧客の口座番号をMACキーと偽ることで、MACキーをPIN検証キー で暗号化するトランザクションを利用して口座番号をPIN検証キーに作用さ せてPINを入手する脆弱性も見つかっている 24
25. 20.5.2 Attacks using backwards compatibility and time-memory tradeoffs • 3-DESの後方互換性を利用した攻撃 ◦ 3-DESは 鍵をleft, rightの半分に分け、leftで暗号化→rightで復号→leftで暗号化 の手順を 踏み暗号化する ▪ 仕組み上、left == rightとするとsingle DESと同じにできる後方互換性を持っている ▪ 3-DESで暗号化するときに、leftとrightを無関係なものとして選ぶことができるように なっていた • single DESのクラッキングを2回行い、既知となったleftとrightを使って3-DES の鍵を構成することができる ◦ time-memory tradeoff ▪ 攻撃の2002年当時はSingle DESのクラッキングをする計算資源がなかったのでこの脆 弱性が利用された ▪ 当時のHSMは全0のビット列を鍵で暗号化したハッシュ値を「チェック値」として持っ ていた ▪ キーとハッシュの組を大量に作っておき、HSMにハッシュを計算させてチェック値が ヒットするまで頑張る 25
26. 20.5.3 Differential protocol attacks • エラーメッセージを悪用した攻撃 ◦ 12.4.2で銀行カードに顧客の暗号化されたPINを書き込んだ銀行が攻撃を受けた経緯を説明し た ▪ PINが口座に紐づいていないせいで、顧客は口座番号を変更するとその銀行カードを利 用して口座を盗むことができる ▪ この攻撃を防ぐため、VISAは暗号化する前にPINと口座番号のxorを取るPINブロック形 式を導入 • PINブロックと口座番号がHSMに送られると、ブロックを復号して口座番号とxor を取りPINが10進数の形式になるかチェックする • チェックの結果10進数でない場合はエラーを返す ◦ 何十件もの口座番号で試したらエラー情報の有無から今のPINで盗める口座 がバレてしまう ◦ 現在はPIN変換に対するHSM用のルールがあるが、複雑な仕様は新しい攻撃を生み、パッチは さらにそれを複雑にする 26
27. 20.5.3 Differential protocol attacks • PIN生成のパラメータを変更し、暗号化された出力の 変化を見ることでPINを予測する攻撃 ◦ (PIN生成の方法は図12.3とその辺りの説明を参照すること) ◦ 16進数を10進数に変化させる対応表を設定できるようになって いる ▪ 対応表が 0123456789012345 なら、1→1, A→0, F→5 のような対応 ▪ 対応表を 0000000000000000 にするとPINとして 0000が暗号化された状態で出力されることが分かる ▪ 次に対応表を1000000000000000にして出力が変われ ば、DES出力の最初の4桁に0が含まれていたことが分か る。これを何度も繰り返せばPINを推測できる ◦ 現実的な解決策はHSMベンダに追加のお金を払い、対応表が ハードコードされたマシンを購入すること ▪ 銀行をクラウドに移行し、AmazonやAzureにより管理 されているHSMを共有する場合さらに問題になる 27 https://www.cl.cam.ac.uk/archive/rja14/Papers/SEv3-ch12.pdf PAN: Primary Account Number PIN key KP: 暗号鍵 Result of DES {PAN}_KP: 暗号化されたPAN {N}_KP decimalized: ↑を十進数化した PAN Natural PIN: ↑の頭4桁 (これがPIN) 対応表は 0123456789012345
28. 20.5.3 Differential protocol attacks • これら脆弱性は堅牢で安全なマルチパーティ計算を設計することの難しさを 表している ◦ マルチパーティ計算: 当事者からの秘密情報だけ与えられるのではなく、敵対勢力が操作する 可能性がある入力も使用する計算 ◦ 今回の単純なケースでも非常に難しい ▪ IBMのPIN生成方法を破棄するか、調整可能にしない方が良いパラメータを厳密に決め る必要がある • 時間の経過とともにAPIが機能しなくなることを表している ◦ 様々な顧客のニーズに応えるために機能が増えて脆弱性が入り込み、ある日を境に攻撃を受 けるようになる 28
29. 20.5.4 The EMV attack • 今まで出てきた初期のAPIへの攻撃が過ぎた後、HSMの設計者は新しいトラ ンザクションの追加に慎重になったか？ ◦ 実際は銀行業界がまた新しい機能の追加を要求し、新たなセキュリティホールを生んだ • スマートカードと銀行間の安全なメッセージングをサポートするためEMVCo が機能を発注 ◦ 銀行が発行したEMVカードのオンライントランザクションで使われるキーなどのパラメータ を変更するリクエストをサーバーから出せるようにする ▪ キーなどのパラメータは暗号化されて送られる ▪ パラメータと共に送られるテキストメッセージは可変長 ▪ 可変長のメッセージを、ターゲットのキーの1バイトだけ暗号化ブロックの境界を超え るように長さを調節する ▪ あらかじめ作った256個の辞書と比較して1バイトの値を特定、をk回繰り返すことでk バイトの鍵が分かる 29
30. 20.5.5 Hacking the HSMs in CAs and clouds • 最も最近の HSM の突破は2019 年にGemalto HSMに対するJean-Baptiste Bédrune と Gabriel Campana によるもの ◦ アプリケーションが公開鍵暗号用のPKCS#11標準をサポートしていたため、認証局やTLSア クセラレータとして使用できた ▪ PKCS#11は難解で実装が難しいことで有名 ◦ HSMのエミュレーターを含むSDKを手に入れてファジング (異常なデータを与えるテスト) し ていくつかの脆弱性を見つけた ◦ これを使って認証機能にパッチを当て、管理者としてHSMにログイン、鍵を読み取ることに 成功した ◦ 高度な暗号化が不注意なソフトウェアエンジニアリングによって損なわれた多くの例の一つ 30
31. 20.5.6 Managing HSM risks • 市場に出回っているHSMの少なくとも1つのバージョンで攻撃方法が見つ かっていた時期が何度かある ◦ 根本原因は機能過多で、セキュリティエンジニアリングにはありがち ▪ 人間はAPIを壊れるまで複雑にしてしまう • 銀行はPCI (Payment Card Industry) ルールに準拠するためHSMを使う必要 があるが、暗号キーはHSMだけで保護されるのではない ◦ 厳格な構成管理や迅速なセキュリティパッチも必要 ◦ 銀行にはセキュリティやパッチのライフサイクルを理解している人材はいるが、HSMの専門 知識を持っている人は少ない • 将来的にHSMがクラウドに移行していくのかはわからない ◦ HSMに関する社内知識が不要になるというセールスポイント 31
32. 20.6 Enclaves • HSMと似たようなもので、信頼できない相手が操作するマシン上で安全に計 算を行うためのプラットフォームを提供する ◦ 暗号化されたメモリセクション ◦ 初期にはコードを難読化して干渉を困難にするデジタル著作権管理 (Digital Rights Management, DRM) のメカニズムが含まれていた ◦ 2000年代初頭にはCPUが暗号化されたコードを実行し、キーが別のモジュール (Trusted Platform Module, TPM) に保存されるアーキテクチャが提案された • 2004年にはArmがTrustZoneを開発 ◦ TrustZoneはAndroidの心臓部にあるSystem on Chips (SoC) 内に実装されているが、信頼境 界はマザーボード全体 ▪ エンクレーブのデータはバスやDRAM上で平文で流れていることもある 32
33. 20.6 Enclaves • 2015年、IntelはSoftware Guard eXtensions (SGX) をリリース ◦ エンクレーブ内で暗号化されたコードを実行できる ◦ AWS, Azure, Googleなどのクラウドコンピューティングをターゲットにしている ◦ データセンタやシステム管理者などのコストを何千もの顧客に償却できるので安価 ◦ 安全性の疑問は解決されるのか ▪ ハイパーバイザの脆弱性などを介して他のテナントに機密データが漏れないか？ ▪ 国家が令状を使用してデータにアクセスする (ハイパーバイザの法的脆弱性ともいえる) ことに対する保護は？ ◦ 重要な暗号化メカニズムはソフトウェア認証 ▪ ソフトウェアの所有者に対し、信頼できるハードウェア上でソフトウェアが変更される ことなしに実行されていることを証明できる ◦ エンクレーブの初期化、アドレス変換、ページエビクション、例外処理など詳細は複雑 ▪ Intel SGX Explained を参照 ◦ SGXはほとんどが更新可能なマイクロコードで実装されておりシステム全体が変わりうる ◦ サイドチャネル攻撃が存在している ▪ Meltdown, Spectre以来攻撃が増えている ▪ IntelはMembuster attackについては修正しないポリシーを発表した 33
34. 20.6 Enclaves • チップへのキーの提供 ◦ 各CPUチップのヒューズに工場でシールシークレットとプロビジョニングシークレットを書 き込み、永続化する ◦ これらはマスター導出キー (master derivation key, MDK) を生成するために使われる ▪ これらのキーによりCPUはIntelに対してその真正性を証明できる ◦ MDKが侵害されると同じグループ (Enhanced Privacy ID, EPID) 内のすべてのCPUの認証セ キュリティが破られる ▪ 2019年AMDのSGX相当のモジュールで実際に発生した • マイクロコードのバグによってMDKが抽出された ▪ このような侵害が発見された場合、IntelはそれらのCPUをブラックリストに入れる必要 がある • このグループがどのくらい大きいかは認証がIntelによって不透明に行われている のでよく分からない 34
35. 20.6 Enclaves • 実運用されているSGXシステム ◦ Signalのプライベートな連絡先の検出にエンクレーブを用いている ▪ Signalクライアントがアドレス帳をSignalサービスに公開することなく、アドレス帳内 の連絡先がSignalユーザーであるかを判断できる • (連絡先情報とSignal情報をエンクレーブ内で突合することで実現している？) ◦ MicrosoftのCloud Key Vault ▪ これによりAzureのテナントはパスワードなどの秘密情報をコードとは別に管理できる • SGXエンクレーブはウイルス対策は除外されているので、そこにマルウェア を仕込むと検出されなくなる ◦ Malware Guard Extension: abusing Intel SGX to conceal cache attacks 35
36. 20.7 Blockchains • 2008年、ビットコインはサトシナカモトと名乗る人物によってホワイトペー パーと実装とともにリリースされた ◦ 2年くらいで急速に広まり、2011年2月Silk Roadが生まれそこでビットコインで支払いでき るように ◦ Silk Roadで取引されていた間価格は1ドルから100ドルまで上昇し、投資家を惹きつけた ◦ 2017年にはバブルになり、価格は2017年12月に約20,000ドルのピークに達した • ビットコインは暗号と経済学の魅力的な構成 ◦ ソフトウェアを作成する人間以外に信頼できる当事者はいない状態で分散システムで合意を 取る新しい方法を提供 36
37. 20.7 Blockchains ビットコインの基本的なメカニズム 1. ビットコインのブロックチェーンはトランザクションの列からなる追記のみの ファイル 2. ユーザーはブロックチェーン上でアドレス (公開鍵のハッシュ) として表示さ れる 3. (ほとんどの) トランザクションは一つのアドレスから他のアドレスに通貨を転 送することで、以前のトランザクションからUnspent Transaction Output (UTXO) という支払いに使われていないトランザクションのoutputを使うことで 行われる。そのトランザクションはUTXOアドレスに対応する秘密鍵で署名され る 37
38. 20.7 Blockchains 4. 支払いを行うには、トランザクションに署名をして、ピアツーピアネットワー クでトランザクションをブロードキャストする (ブロックに追加される？)。他の ユーザーはブロックの検証とマイニング (ブロックをブロックチェーンに追加) を 行う 5. 各ブロックではブロックの内容とソルトのSHA256ハッシュ値を利用してマイ ニングが行われる。マイニングはハッシュ値の先頭の十分な数が0になるような ソルトを見つける行為 (Proof of Work. このときに前のブロックのハッシュ値を 計算に含めることで改ざんを検知できる)。約10分ごとに新しいブロックがマイ ニングされるように難易度が調整される 38
39. 20.7 Blockchains 6. マイナーはマイニングしたブロックごとにブロック報酬が支払われる。この報 酬は210,000ブロックごとに半分になり、執筆時の2020年5月に 12.5BTC→6.25BTCと半分になった 7. マイナーはトランザクションの手数料も受け取れる。この手数料が高いほど優 先してマイニングがされる。普段は数セントだが、混雑時は数10ドルまで行くこ とも 8. 競合する次のブロックが2つマイニングされた場合、マイナーは最も長い チェーンをマイニングするルールによって解決される。そのためトランザクショ ンは約6ブロックがマイニングされるまで確定されたとみなされない (チェーンに 組み込まれたとみなされない？) 39
40. 20.7 Blockchains 9. 競合が解決されない場合はフォークされる (それぞれ別の暗号通貨として運用 される) こともある 10. トランザクションにはスクリプトを含めることができ、支払いをプログラム することができる (支払いの条件をプログラムで記述できる？) • 暗号通貨で問題になっていることを見るには暗号数学以外も見ていく必要が ある ◦ 粗雑なエンジニアリング、システム思考の欠如、ユーザーに対する配慮のなさが優れた暗号 化のアイデアを台無しにしている 40
41. 20.7.1 Wallets • ビットコインはアカウントという本質的な概念はなく、1つ以上のUTXOのロック を解除する秘密鍵を知っていることでビットコインを所有できる • ウォレットは当初、一つ以上の秘密鍵を保存し、ユーザーがこれらの鍵を使用でき るUTXO (つまり自分のビットコイン) を確認できるインターフェースを提供 ◦ ユーザーが暗記したパスフレーズから決定的に秘密鍵を生成する「ブレインウォレット」 ▪ パスフレーズから生成する秘密鍵をブロックチェーンの公開鍵に当てまくる攻撃を受ける ▪ 推測しやすいパスフレーズのブレインウォレットは24時間以内に中身が空になった • 署名キーをハードディスクに保存してパスフレーズで保護するソフトウェアウォ レットは改善されてはいるもののマルウェアなどに脆弱 • 本格的な運用者はハードウェアのウォレット (コールドウォレット) を使う ◦ 小さなHSMで、オフラインで保存する ◦ 高額なビットコインを所有しているとバレて強盗されるケースも多い • 2013年までに取引所などが代わりに持つホスト型ウォレットが登場 ◦ 強盗の問題は解決しないが、その他詐欺や不正使用の蔓延に繋がっている 41
42. 20.7.2 Miners • マイナーはアイスランドやケベックなど電気代が安い場所で活動している が、大半はロシアや中国など地元当局と取引できる場所で活動している • 2019年の暗号通貨マイニングの総エネルギー消費量は約75TWhで、CO2排 出量は35Mtを超えており、ニュージーランドの二酸化炭素排出量に匹敵す る 42
43. 20.7.2 Miners • マイナーは個人ではなくマイニングプールを組織し、収益を分配している ◦ マイニングプールの計算資源はレンタル可能で、51%攻撃に使われることもある ▪ マイナーの過半数が共謀すれば二重支払いや不正な取引の承認などができる攻撃 ◦ この攻撃は即座に暗号通貨の信頼性に致命的なダメージを与えると考えられたが、現実は もっと複雑 ▪ 2019年1月、イーサリアムクラシックが51%攻撃で100万ドル以上盗まれた • 価格は大きな影響を受けず • 盗まれた額がもっと大きければ価格は暴落して無価値になっていただろう ▪ 2020年8月、さらに2つの攻撃があり、560万ドル盗まれた • 51%攻撃をするための計算資源に192,000ドルかけた ▪ ブロックチェーンについて論じる際には、暗号だけでなくゲーム理論についても考える 必要がある 43
44. 20.7.3 Smart contracts • ビットコインのスクリプトはシンプルだが、後続のイーサリアムはチューリ ング完全なVMがあり、そのバイトコードはSolidityという言語からコンパイ ルされる ◦ イーサリアムは複雑なトランザクションを自動化できるスマートコントラクトの可能性を秘 めているため時価総額で2番目に大きい暗号通貨になった ◦ バブル期にはスマートコントラクトでIoTを活用して分散ストレージのサービスを作るなど話 題だった ▪ この手の分散型自立組織に関する宣伝が多かった ▪ 大手サービス企業からオンラインの世界を切り離そうという「再分散化」運用に関連し ている 44
45. 20.7.3 Smart contracts • スマートコントラクトによる障害 ◦ 人間の介入なしに暗号通貨を交換できる分散型取引所 (Distributed Exchanges, DEX) の非効 率性を利用してアービトラージを行うボットが出現 • 実際のアプリケーションでスマートコントラクトを使う問題 ◦ デンマークの研究で、病気の子どもの世話をするために仕事を休む親に支払うためにスマー トコントラクトを使用する提案があった ▪ 複雑な法的ルールがあるため控訴が起こる ▪ 控訴の文書のハッシュをイーサリアムブロックチェーンに置き、両親と控訴委員会が確 認できるようにすることで決定の執行を自動化、迅速な手続きに繋がることを期待 • 法律が変更されたりバグが発見された際に誰が契約を更新するのか？ • 地方自治体の制御下に置けないため自治体に忌避感があった • Solidityという慣れない言語でプログラムを書くとバグが多くなるという問題 45
46. 20.7.4 Off-chain payment mechanisms • 標準的なビットコイン取引は確定まで6ブロック、つまり1時間かかり、混雑 時は更に長くなる ◦ ビットコイン取引のスループットは5件/secに対してVISAは5万件/sec • レイヤー2プロトコルのようなサイドチェインを用いてこの問題を解決しよ うとしている ◦ レイヤー1であるブロックチェーンに紐づけられ、更にその上のレイヤーで行われるトランザ クション ◦ ブロックチェーンにコインをロックした上で迅速な取引が行える ◦ 核となるアイデアはハッシュタイムロック契約 (hashed time-lock contract, HTLC) を使う ことで互いに暗号通貨をコミットすること ▪ BobがAliceにh(R) (R: 乱数, h: ハッシュ関数) を送り、Aliceは「時間tまでにRを自分に 見せたらコインを渡すよ」という意味のスクリプトを書く。Alice→Bobも同様。 46
47. 20.7.4 Off-chain payment mechanisms • 支払いシステムを機能させるにはさらにエンジニアリングが必要 ◦ AliceとBobがいくら受け取るかの合意ができなかったときの紛争解決メカニズム ◦ AliceがBobを介してCharlieに送金するためのメカニズムと、誰にでも支払えるルーティング メカニズム ◦ 他の人が共謀しても正直な人がお金を失わないプロトコルのセキュリティ ◦ 様々なリスクのケア ▪ ホットウォレットの盗難リスク ▪ ボブが乱数をブロードキャストするときにマイナーがボブを先取りするリスク ▪ ネットワーク障害後の崩壊のリスク • 2020年時点での主要なネットワークはライトニングネットワーク ◦ 1日1000件のトランザクションを処理している ◦ 悪意のあるユーザーはノードの容量を拘束するために多数の支払いを作成し、数時間後に無 料でキャンセルするなどの悪用が可能 47
48. 20.7.5 Exchanges, cryptocrime and regulation • 自分ですべてを採掘するのは大変なので、2010年までに起業家たちはビット コインと従来のお金を交換する取引所を設立した ◦ ほとんどはハッキングされたか、内部者がお金を盗んでハッキングされたと主張して破産し た ◦ 2011年まででトップは日本のMt.Goxで、2011年に1回ハッキングを生き延びたものの、 2014年に4億6000万ドルのハッキングを受けたと主張して破産した 48
49. 20.7.5 Exchanges, cryptocrime and regulation • Mt.Goxのイノベーションとして、2013年に保管取引所になったことが挙げ られる ◦ 顧客のビットコインを別のウォレットで管理する代わりに全てのビットコインを自社で保管 して顧客が持っている分のビットコインをウェブ上で表示するようにした ◦ 18世紀の金融で見られた金商人から銀行への移行と同じ • ビットコインの世界は詐欺で満ちている ◦ 被害者の大半は破産した取引所、ハッキングされた取引所、またはハッキングされたと主張 する取引所によって騙された ◦ 取引所が存在した最初の3年間である2010年から2013年の間に18/40が破産した 49
50. 20.7.5 Exchanges, cryptocrime and regulation • ビットコイン分析会社Chainalysisのレポート ◦ 取引所は2018年にハッカーにより約10億ドルを失い、盗難のほとんどが2つの犯罪組織に よって行われた ▪ そのうちの1つは北朝鮮との関連が判明 ◦ 2018年の麻薬や違法品が売買される地下市場の売上高は6億ドルで、2017年の約2倍 • 市場操作 ◦ John GriffinとAmin Shamsは、2017年のブームの際、ビットコインの価格がインサイダー取 引によって支えられていたという証拠を提示し、多くの暗号通貨の市場価格が違法な操作の 結果であった可能性を示唆 ▪ スポット取引の多くが規制されていない取引所によって行われていることを示すその後 の研究によって裏付けられている 50
51. 20.7.5 Exchanges, cryptocrime and regulation • これまでで最大の暗号通貨詐欺はPlusTokenと呼ばれるポンジスキーム ◦ 主犯が2019年に逮捕されるまでに中国国民から約30億ドルを巻き上げた • ビットコインは他の多くの犯罪にも影響を与えている ◦ ビットコインによって身代金の回収が容易になったため、ランサムウェアは2001年〜2015 年で年間約200～300万ドルから年間800万ドルほどに増加 ▪ 身代金はギフトカードも使われている ◦ 2018年、サイバー犯罪者にサービスを提供する防弾ホスティングサイトは、他の支払い方法 が困難になったため暗号通貨に移行した ◦ 2018年、世界最大のダークネット児童ポルノサイトであるWelcome to Videoは、ブロック チェーン上のビットコインのフローを介して運営者が追跡された後に閉鎖された ▪ 暗号通貨の匿名性には限界がある ◦ 詐欺やその他の乱用は、暗号通貨の取引量の約3％に直接相当 ◦ 存在が知られている暗号通貨取引所に加えて、Over the Counterブローカーが多数おり、そ のうち約100がマネーロンダリングに関与していることが確認 ▪ 通常の取引所もマネーロンダリングに使われる 51
52. 20.7.5 Exchanges, cryptocrime and regulation • 政府は金融規制で問題解決を図っている ◦ 米国財務省の金融犯罪取締ネットワーク (FinCEN) は世界中でマネーロンダリング防止 (anti-money-laundering, AML) と顧客確認 (know-your-customer, KYC) 規制を推進 ▪ EUの第5次マネーロンダリング防止指令などを通じて現地の法律に組み込まれている ▪ たとえばドイツの規制当局であるBaFinは、既存の金融規制を使用してすべての取引所 がライセンスを取得することを要求している • localbitcoins.comはライセンス未申請のためブロックされた ◦ 最も大きな推進力となっているのは2019年のFinCEN勧告によるもの ▪ 仮想通貨取引所に「トラベルルール」の導入を義務付けている ▪ このルールでは、1万ドルを超える取引を扱う人は送金者と受取人の両方を特定し、該 当する場合は活動報告書の提出義務がある 52
53. 20.7.5 Exchanges, cryptocrime and regulation • 暗号通貨の世界での消費者保護はこれからの課題 ◦ 銀行が顧客の携帯電話に対するSIMスワップ攻撃をブロックする方法に多大な関心を示してい る一方、ほとんどの暗号通貨取引所はまったく関心を示していない ◦ 筆者とその同僚が行った、取引所の運営と盗まれたビットコインの追跡の仕組みに関する分 析では、銀行と同等の消費者保護を取引所の顧客に提供する決済サービス指令の適用を推奨 した 53
54. 20.7.6 Permissioned blockchains • 仮想通貨ブロックチェーンの抱える課題 (環境負荷、違法コンテンツ、不正 行為者) を避けつつ、ビジネスに有用なブロックチェーンを構築する試み ◦ HyperledgerやEnterprise Ethereum Allianceなどが、サポーターとさまざまなブロック チェーン ツールや標準を開発した ▪ その多くは、Proof of Workではなくビザンチン障害耐性を持つ許可型ブロックチェー ン構造を使用しており、スマート コントラクトもサポートできる ◦ JPモルガンは2015年から、参加銀行がブロックチェーン上で住宅ローンを入力できるように するシステムに取り組んでいる ▪ 低レイテンシーとセキュリティ、取引に関してそのビジネスロジックや個々の参加者の 名前を非公開にする方法など、いくつかの設計上のトレードオフを検討している ◦ 大部分のアプリケーションではブロックチェーンは必要なく、前方保護された機密性のログ で十分ということが分かった 54
55. 20.7.6 Permissioned blockchains • 失敗例 ◦ アルゼンチンはブロックチェーン上で官報を発行し、法的に有効であると宣言したが、ハッ キングされてコロナウイルスに関する偽のニュースが公開された ◦ Facebookが提案したLibra ▪ 複数の通貨に価値を連動させた決済システム ▪ 複数の国の中央銀行からの強い反対に遭い、Visa、MasterCard、PayPalなど主要な金 融機関がプロジェクトから撤退した 55
56. 20.8 Crypto dreams that failed • ブロックチェーンに基づく電子投票システム ◦ 多くの人が提案している ◦ 匿名性と証明可能な正確性を同時に実現するために、電子選挙で暗号を使用する30年以上の研究に基づいて いる ◦ ロシアとアメリカで導入実績があるが、結果は微妙 ▪ 2018年、モスクワの3つの区で投票集計にイーサリアムブロックチェーンが使用された • 選挙直前に暗号の脆弱性が2つ修正されたため、投票集計とブロックチェーンのリンクが切断さ れ、ブロックチェーンが選挙直後に消滅 ▪ 2018年、ウェストバージニア州が米国で初めて、一部の有権者が携帯電話アプリを使用して投票する ことを許可 • MITの研究者がこのアプリをリバースエンジニアリングし、攻撃者が投票を公開したり変更でき る脆弱性をいくつか発見した • ブロックチェーン自体は脆弱性とは無関係だった • 攻撃者は汚染された証跡を作成し、 (透明性や説明責任などのブロックチェーンのセールスポイ ントにもかかわらず、) 信頼できる監査を不可能にする可能性がある • セキュリティの専門家はブロックチェーンが選挙の問題を解決できるとは思っていない ◦ 政権を握っている政党は有権者登録から選挙資金や広告ルール、メディアの検閲、有権者の脅迫、操作可能な 投票スキームに至るまであらゆる箇所でテクノロジーを破壊 ◦ ブロックチェーンはこれらの問題に対処するものではない 56
57. 20.9 Summary • 1980年ごろは暗号技術によって経済問題や社会問題を解決できると考えられ ていた ◦ 当時のCryptoおよびEurocryptカンファレンスの研究論文にはそのようなアイデアが溢れて いる ▪ 匿名通信による検閲防止 ▪ 匿名デジタルキャッシュによるプライバシー保護 ▪ デジタル投票による選挙不正の困難化 ▪ 閾値署名による内部統制システムの堅牢化 ▪ 電子オークションによる汚職防止 ◦ 現在は状況を見直す時期に来ているのかもしれない 57
58. 20.9 Summary • 暗号化の技術面での教訓 ◦ 暗号化は魔法ではない ▪ 他の技術と同様、バグが混入してパッチを当てる必要がある ▪ FDEのような単純なアプリケーションでも製品が成熟するにつれ複雑になり、品質はバ ラつきがある ▪ HSMのように脆弱になるまで機能が追加される ▪ SGXはサイドチャネル攻撃に対して脆弱になるほど複雑なプロセッサ上で実行される • そのうちいくつかはIntelは脅威モデルの範囲から外してさえいる ▪ 最も複雑なエコシステムであるブロックチェーンでも同様 • 暗号通貨はスマートコントラクトのような機能を獲得し続け脆弱になっていく 58
59. 20.9 Summary • 暗号化の社会面での教訓 ◦ 導入されている高度な暗号メカニズムはすべて、かなりのコストがかかる ▪ HSMはサーバーよりコストがかかる ▪ SGXはメモリの制限があり、コンテキストスイッチ時にオーバーヘッドが発生 ▪ ビットコインマイナーはニュージランド並にCO2を排出する ◦ コストに見合う価値があるかを見極めるには細かい計算が必要 ▪ 時間が経つにつれ技術的負債が増えメンテナンスコストは増大する • 暗号化の政策面での教訓 ◦ 高度な暗号化メカニズムはすべて責任と絡み合っている ▪ 高度な暗号技術の導入や維持の決定は、責任の所在、規制への対応（順守または回 避）、意図しない外部への影響といった複雑な要素と深く絡み合う • 銀行が詐欺の責任を追わないためHSMを導入 • ビットコインで証券法やマネーロンダリング防止規制を回避 • 暗号の40年の歴史の要約 ◦ 「ただで得られるものはない」(there ain’t no such thing as a free lunch, TANSTAAFL) 59