LayerX Newsletter for Tech (2020/08/17-08/23)
Issue #72
今週の注目トピック
Tomoaki Kitaokaより
今週はまず、USENIX Security’20において採択されたAndroidアプリのPCI DSS準拠を検証するツールCardplianceに関する論文をピックアップしました。PCI DSSはクレジット番号や決済取引に関する情報を扱うためのセキュリティ基準であり、論文ではいくつか脆弱性のあるアプリケーションがあったことを報告すると共に開発のベストプラクティスを提案しています。
次に、NEARが発表したEthereumとのトラストレスなインターオペラビリティプロトコルRainbow Bridgeのリリース記事をピックアップしました。記事ではトラストレスなインターオペラビリティの実現方法、直面した課題及びそれらへの対処方法を説明しています。
最後に、Eth2のMedallaテストネットで発生したインシデントの概要と教訓、またPhase 0の今後をまとめた記事をピックアップしましたた。記事では今回のインシデントに対処をした開発者の生の声が語られています。
List編とあわせて、ご覧ください。
Section1: PickUp
●USENIX Security’20に、AndroidアプリのPCI DSS準拠を検証するツールCardplianceに関する論文が採択
USENIX Security '20からノースカロライナ州立大学Mahmud氏らによる「Cardpliance: PCI DSS Compliance of Android Applications」を紹介する。タイトルにもあるようにAndroidアプリがPCI DSSに準拠しているか検査するツールCardplianceを開発、評価を行った内容だ。
PCI DSSは、クレジットカード番号（以下PAN）や決済取引に関する情報を扱うためのセキュリティ基準で、PCI SSCによって策定されている。日本においても、「クレジットカード・セキュリティガイドライン」（実行計画の後継文書）でも加盟店等、各主体のPCI DSS準拠を求めている。また8月19日のLayer X Newsletterで取り上げた日本銀行の「スマートフォン等での決済サービス業務にかかるリスクマネジメント：本人認証のあり方に注目して」においても、決済業務から生じるデータ取得の文脈で言及されている。
Mahmud氏らは、PCI DSSのうちモバイルアプリに関連する6つの要件をCardplianceに組み込んでいる。6つの要件の概要は以下の通り。データ保持はビジネス、法律、規制に必要な期間とする「Limit CHD storage and retention time」、承認後の機密認証データ保存を禁じる「Restrict SAD strage」、PAN表示は最大桁数を定める「Mask PAN when displaying」、PANを保存する場合はハッシュ化等の保護を求める「Protect PAN when Storing」、決済情報をサーバー等とやり取りではセキュアな経路を用いる「Use secure communication」、メールやSMSでPANを送ることを禁じる「Secure transmission of PAN through messaging technologies」だ。
Cardplianceの評価は、クレジットカード情報を扱う等の条件を満たす358アプリ（Google Play）を対象として実施された。結果、98.32%のアプリが適切な処理がされていた。一方で、PANを平文で保存・ログに記録、確認コードを保持、マスキングせずに表示を行っているアプリも発見された。
論文では開発者向けのベストプラクティスについても取りまとめている。支払いに関するロジックはStripe等の3rd partyに委任することや、確認コードを永続ストレージ、ログファイルに書き込まない、SSL/TLSを用い適切な証明書検証を行うことなどが述べられている。
PCI DSSはクレジットカード分野で、すでに実績のある基準だ。開発者が、安全に決済情報を扱えるようサポートできる点やベストプラクティスの共有には大きな意義がある。技術的な面でも、Androidアプリの静的解析を行うAmandroidと、UIセマンティック推論を行うUiRefを組み合わせて実装されており興味深い論文だ。
（文責・恩田[@cipepser]）
●NEARがEthereumとのトラストレスなインターオペラビリティプロトコルRainbow Bridgeを発表
NEARがEthereumとのトラストレスなインターオペラビリティプロトコルであるRainbow Bridgeを発表した。
各ブロックチェーン上に伝達元のブロックチェーンのヘッダーを保持するライトクライアントを実装する。伝達したい情報の検証は、両チェーンともマークルツリーの葉からマークルルートを計算し、ヘッダーに格納されたマークルルートと一致するか検証することで行われる。
NEAR上のEthereumのライトクライアントはステートに情報を保存する場合、ストレージの容量に応じてトークンをロックアップする必要があるため、ヘッダーを保存する期間は独自で設定する（デフォルトでは約7日間）。また、EthereumのPoWの検証にはDAGファイルが必要となるが、メモリーの節約のためにこれは約4年分のDAGファイルを予め計算しマークル化して格納する作業が定期的に行われるためヘッダーだけを伝達すれば良い。
Ethereum上のNEARのライトクライアントは2/3のNEARのバリデータがブロックにステークしていることを検証することでブロックのFinalityの検証を行う。Ethereumへの書き込みはgasが発生し高価になりがちだが、ブロックはEpoch単位(約半日)で伝達すれば良いのでコストを抑えることができる。ただし、NEARの署名アルゴリズムはEd25519であり、これはEVMでprecompileできず、署名検証は500kのgasを必要とする（不可能ではない）。したがって、今回はoptimisticな署名検証方法を採用し、ヘッダーの検証では署名検証は行わず、代替として4時間のチャレンジ期間を用意する。ゆえに常にコミットされるヘッダーをWatchdogで監視する。EIP665が採用されればEd25519の署名検証がEVMで可能になるため、4時間のチャレンジ期間は不要となる。
ブロックチェーンのインターオペラビリティに関する議論は長い間行われている。LayerX社内でも重点的に研究を行っており、エンタープライズブロックチェーン基盤比較レポート-インターオペラビリティ編-も近日公開予定である。トラストレスなインターオペラビリティは実装難易度が高いため実装例が少なく、Rainbow-Bridgeは貴重な実装例である。（文責・北岡）
●Eth2のMedallaテストネットで発生したインシデントの概要と教訓、またPhase 0の今後
先週、Ethereum 2.0のパブリックテストネットMedallaで、ネットワーク全体に及ぶカスケード障害が発生した。原因は、Go言語で記述されたEth2クライアントPrysmの脆弱性とそのパッチに含まれたバグ、そしてリリース対応である。結果的に、Eth2ネットワークの停止を引き起こし、これに関わったPrysmクライアントはステークのほとんどをスラッシングされた。
タイムラインを説明する。発端は、Prysmが内部で用いていた時刻同期プロトコルroughtimeの、Cloudflare社によるクライアントに起因する。時刻配信サーバーと、受け取った時刻を処理する実装に問題があり、Prysmクライアントの時刻が数時間ずれて不正な状態になってしまった。かくして、Medallaのネットワークのバリデータ参加率が著しく減少してしまう。
(引用: https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a)
そこで、Prysm開発チームは、早急にネットワークを回復するべく、roughtimeによる時刻同期をオプション化し、デフォルトでオフにするように緊急修正したバージョン（alpha.21）をリリースした。しかし、リリースされたバージョンが稼働され始めると、大量のスラッシングイベントが発生してしまう。
実は上記の修正パッチにはバグがあり、ノードの初期化処理を誤って削除していた。開発チームはこのミスを発見すると、すぐにalpha.20にロールバックすることをユーザーに依頼した。ところが、この一連のアップデートによるノードの大規模な再起動により、チェーンの情報を持たないノードが増え、ネットワークは大量のチェーンの同期リクエストの処理にスタックした。これがネットワークの回復を長引かせた。
現在は、これらの問題を解決する新しいバージョンがリリースされ、ネットワークは安定している。Prysmの最新バージョンはGitHubにあり、最新情報はDiscordで配信されている。
開発チームは2つの教訓を掲げている。一つは、当然だが修正のマージを急がないことである。ネットワークの安定を前提としたコードを書くのは簡単だが、不良のピア、フォーク、ネットワークパーティションが存在する場合でも問題無く機能させるコードを書くのは難しい。いくら緊急でも修正マージは適切にレビューおよびテストする必要がある。
もう一つは、他のEth2クライアントへの移行を簡単にすることである。Eth2は5つの異なる言語のクライアントを持つ『マルチクライアント』の体制を取っている。今回のように、Prysmがダウンしても、本来であれば他の4つのクライアントがネットワークを維持する。しかし、インシデント発生時には、クライアントの65%以上がPrysmだったため、ネットワークが停止してしまった。今後は、あるクライアントに異常が発生したら、別のクライアントに簡単に切り替えれるスキームを整備するとしている。
(記事公開時のEth2クライアントの稼働割合。引用: https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a)
本インシデントによって、Eth2 Phase 0のローンチ日に影響はないと言う。ただし、Eth2 Phase 0では、新しい技術をいくつも導入するため、このようなリスクは完全に排除できるものではなく、バリデータ参加予定者は「自分がステーキングを本当にすべきかどうか」を慎重に検討すべき、としている。
今回のインシデントは他人事ではない。そもそものインシデントの防止策および、万が一起きてしまった場合の適切なレスポンスを、日々考えなければならないと痛感する。（文責・岡南）
Section2: ListUp
1. Bitcoin
●Lightning Labs、lndのWumbo channelsサポートを発表
●Bitcoinを活用したDeFiについてDG Labの取組紹介記事
2. Ethereum
●SAPのABAPベースのシステムとEthereumを接続したデモソースを公開
3. Smart Contract・Oracle
●Chainlink、中小農家むけに気象条件に応じて自動的に保険金を支払うパラメトリック分散農業保険Arbolに対して気象データ提供開始へ
4. DeFi
●dYdX、L2スケーリング技術のインテグレーションへStarkWareと提携
5. Other Chain
●Digital Asset社、デジタルアセット交換業者Exberryと提携
6. Digital Identity
7. 統計・論考
Disclaimers
This newsletter is not financial advice. So do your own research and due diligence.
