【コラム】Web3の成功はセキュリティ対策の修正にかかっている

今回は「【コラム】Web3の成功はセキュリティ対策の修正にかかっている」についてご紹介します。

関連ワード （ウェイ、各自、教訓等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、TechCrunch様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

Web 1.0とWeb 2.0はともに、セキュリティモデルがアプリケーションアーキテクチャーともに変更され、まったく新しい経済の扉を開いた。Web 1.0では、Secure Socekts Layer（SSL、セキュリティ・ソケット・レイヤー）がNetscape（ネットスケープ）によっていち早く開発され、ユーザーのブラウザーとさまざまなサーバーとの間の堅牢なコミュニケーションを可能にした。Google（グーグル）、Microsoft（マイクロソフト）、Amazon（アマゾン）などのWeb 2.0の信頼できる仲介者と認証機関は、SSLの後継となるTransport Layer Security（TLS、トランスポート・レイヤー・セキュリティ）の実装を加速する中心的役割を果たした。

同じことがWeb3でも起きようとしている。これが、新しいWeb3セキュリティ会社への投資が2021年10倍以上増えて10億ドル（約1兆1500万円）を超えた主な理由だ。

Web3の成功は、さまざまなアプリケーションアーキテクチャーが生み出す新たなセキュリティ問題を解決するイノベーションにかかっている。Web3では、分散型アプリケーション（dApps）が、Web 2.0に存在する伝統的アプリケーションロジックやデータベースレイヤーに依存することなく作られている。代わりにブロックチェーン、ネットワークノード、スマートコントラクトなどのプロトコルがロジックと状態の管理に使われている。

ユーザーは今までと変わらずにフロントエンドをアクセスし、そこからノードにつながってデータの更新、たとえば新しいコンテンツの公開や商品の購入などを行う。この手順では、ユーザーが各自のプライベートキー（秘密鍵）を使って取引を承認する必要があり、通常秘密鍵はウォレットで管理される。これはユーザーのコントロールとプライバシーを保護することを目的としたモデルだ。ブロックチェーンを利用した取引は完全に公開されていて、誰もがアクセス可能でイミュータブル（改変不可能）だ。

どんなシステムでも同じだが、このデザインにはセキュリティとのトレードオフがある。ブロックチェーンでは、Web 2.0のように行為者が信頼されている必要がなく、セキュリティ問題に対応するための更新がより困難だ。ユーザーはアイデンティティに関する制御を自ら維持することができるが、アタックを受けたり、キーを悪用された時に助けてくれる仲介者は存在しない（Web 2.0プロバイダーは、盗まれた財産を復活させたりパスワードをリセットできる）。ウォレットも、Ethereum（イーサリアム）アドレスなどの重要情報を漏らす可能性がある。ソフトウェアである限り完璧にはなりえない。

こうしたトレードオフは、当然ながら重大なセキュリティ上の懸念を喚起しているが、それによってWeb3の機運が削がれるべきではなく、実際その可能性は低い。

改めてWeb 1.0、Web 2.0との類似点を見てみよう。SSL/TLSの初期バージョンには致命的な脆弱性があった。かつてのセキュリティツールはよくいって原始的であり、時間とともに堅牢になっていった。Web3のセキュリティ会社やプロジェクト、たとえばCertik（サーティック）、Forta（フォータ）、Slither（スリザー）、Securify（セキュリファイ）などは、Web 1.0やWeb 2.0アプリケーションのために当初開発されたコードスキャニングやアプリケーションセキュリティテスティングのツールに相当する。

しかし、Web 2.0では、セキュリティモデルの中心はレスポンスだった。Web3では、いったん実行された取引は変更不可能なので、その取引がそもそも実行されるべきかどうかを検証する機構が組み込まれている必要がある。言い換えると、セキュリティは予防に関して並外れて優秀でなければならない。
つまりこれは、Web3コミュニティは、系統的脆弱性に正確に対応し、暗号プリミティブからスマート・コントラクトの脆弱性まであらゆるものをターゲットにする新たな攻撃手段を阻止する方法を見つけなければならないことを意味している。現在、予防型Web3セキュリティモデルを推進するイニシアチブが少なくとも4つ、進行している。

Web3の既知の脆弱性や弱点に関する信頼できる情報源が必要だ。現在、National Vulnerability Database（NVD、脆弱性情報データベース）が脆弱性管理プログラムのために基本データを提供している。

Web3には、分散型の同等品が必要だ。現在は、不完全な情報がSWC Registry（SWCレジストリー）、Rekt（レクト）、Smart Contract Attack Vectors（スマート・コントラクト・ベクターズ）、DeFi Threat Matrix（ディーファイ・スレット・マトリクス）などさまざまな場所に散らばっている。Immunefi（イミュニファイ）などが実施しているバグバウンティプログラムは、新しい弱点を発見することを目的にしている。

重要なセキュリティデザインの選択や、Web3の個々の事象に関する意思決定モデルは今のところ知られていない。分散型というのは、誰も問題の責任をもたないという意味なので、ユーザーにとって予期せぬ大問題がおきることがある。最近のLog4j脆弱性のような事例は、セキュリティを分散型コミュニティに委ねる危険性の教訓だ。

関連記事：米FTC、Log4jの脆弱性を修正しない組織に対する法的措置を警告

自律分散型組織（DAO）やセキュリティ専門家Alchemy（アルケミー）やInfura（インフーラ）などのプロバイダーなどが、差し迫るセキュリティ問題にどのように協力して取り組むかを明確にしておく必要がある。大規模なセキュリティコミュニティが協力し、OpenSSF（オープンSSF）やいくつものCNCFアドバイザリーグループを結成してセキュリティ問題に取り組むプロセスを確立したという良い事例がある。

現在ほとんどのdAppは、最も著名なものを含め、APIのレスポンスに認証や署名を行っていない。これは、ユーザーのウォレットがこれらのアプリからデータを取得したとき、レスポンスが意図したアプリから来たものであり、データが何からの方法で改ざんされていないことを検証するまでに時間のずれが生じることを意味している。

アプリが基本的なセキュリティのベストプラクティスを実施していない世界では、アプリのセキュリティに対する姿勢と信頼性を確かめる仕事はユーザーに任されているが、それは事実上不可能だ。最低限、リスクをユーザーに知らせるもっとよい方法が必要だ。

暗号化キーは、Web3パラダイムの下でユーザーが取引を行う仕組みを支えるものだ。暗号化キーは、正しく管理することが困難であることでも悪名高い。ビジネス全体がキー管理を中心に作られている必要があり、今後もそれは変わらない。

秘密鍵の管理に関わる複雑さとリスクは、ユーザーが自己管理ウォレット（non-custodial wallet）よりもホスト型ウォレット（hosted wallet）を選びたがる主要な理由だ。しかし、ホスト型ウォレットの利用には2つのトレードオフがある。Coinbase(コインベース）のような新たな「intermediaries」（仲介者）を生み、Web3の完全分散型への方向性を阻害すること。そして、ユーザーがWeb3の提供するものすべてを利用する機会を奪うことだ。理想は、さらなるセキュリティイノベーションによって自己管理ウォレットの使いやすさとセキュリティの両方が改善されることだ。

最初の2つのイニシアチブは人間とプロセスが中心なのに対して、3番目と4番目のイニシアチブはテクノロジーの変化が必要であることは注目に値する。新しい技術と生まれつつあるプロセス、さらに膨大な数のユーザーを調整しなければならないことが、Web3セキュリティの解決を難しくしている。

一方で、最も勇気づけられる変化の1つは、Web3のセキュリティイノベーションが開かれた場で起きていることだ。これがどれほど創造的ソリューションにつながるかを決して過小評価してはならない。

編集部注：本稿の執筆者Wei Lien Dang（ウェイ・リエン・ダン）氏はセキュリティ、インフラストラクチャー・ソフトウェアおよび開発ツールへの投資で知られるUnusual Venturesのゼネラルパートナー。クラウドネイティブセキュリティ会社で後にRed Hatに買収された、StackRoxを共同設立した。

画像クレジット：Westend61 / Getty Images

【原文】

In both Web 1.0 and Web 2.0, security models changed in tandem with application architectures to help unlock entirely new economies. In Web 1.0, Secure Sockets Layer (SSL) was pioneered by Netscape to provide secure communication between user browsers and those servers. Trusted Web 2.0 intermediaries such as Google, Microsoft, Amazon and certificate authorities played a central role in driving implementation of Transport Layer Security (TLS), the successor to SSL.

The same will happen for web3. This is the key reason why investment in new web3 security companies increased last year more than 10x to over $1 billion.

The success of web3 hinges on innovation to solve new security challenges created by different application architectures. In web3, decentralized applications or “dApps” are built without relying on the traditional application logic and database layers that exist in Web 2.0; instead, a blockchain, network nodes, and smart contracts are used to manage logic and state.

Users still access a front end, which connects to those nodes, to update data such as publishing new content or making a purchase. These activities require users to sign transactions using their private keys, typically managed with a wallet, a model that is intended to preserve user control and privacy. Transactions on the blockchain are fully transparent, publicly accessible and immutable (meaning they cannot be changed).

Like any system, this design has security trade-offs. The blockchain does not require actors to be trusted as in Web 2.0, but making updates to address security problems is harder. Users get to maintain control over their identities, but no intermediaries exist to provide recourse in the event of attacks or key compromises (e.g., how Web 2.0 providers can revert stolen funds or reset passwords). Wallets can still leak sensitive information like an Ethereum address – it’s still software, which is never perfect.

The success of web3 hinges on innovation to solve new security challenges created by different application architectures.

These trade-offs rightfully prompt significant security concerns, but they should not stymie web3 momentum and, practically speaking, they are unlikely to.

Consider the parallels to Web 1.0 and Web 2.0 again. The initial versions of SSL/TLS had critical vulnerabilities. Early security tooling was rudimentary at best and became more robust over time. Web3 security companies and projects like Certik, Forta, Slithe, and Securify are the equivalents of the code-scanning and application security testing tools that were originally developed for Web 1.0 and Web 2.0 applications.

However, in Web 2.0, a substantial part of the security model is about response. In web3, where transactions cannot be changed once executed, mechanisms must be built in to verify if transactions should happen in the first place. In other words, security has to be exceptionally good at prevention.

This means the web3 community has to figure out how best to technically address systemic weaknesses to head off new attack vectors that target everything from cryptographic primitives to smart contract vulnerabilities. In parallel, there are at least four initiatives that would advance a preventative web3 security model:

Source-of-truth data for vulnerabilities

There needs to be a source of truth for known web3 vulnerabilities and weaknesses. Today, the National Vulnerability Database provides the core data for vulnerability management programs.

Web3 needs a decentralized equivalent. For now, incomplete information lives scattered across places such as SWC Registry, Rekt, Smart Contract Attack Vectors and DeFi Threat Matrix. Bug bounty programs such as those run by Immunefi are meant to surface new weaknesses.

Security decision-making norms

The decision-making model for critical security design choices and individual incidents in web3 is currently unknown. Decentralization means that no one owns the problems, and the ramifications for users can be significant. Examples such as the recent Log4j vulnerability are cautionary tales for leaving security up to a decentralized community.

There needs to be greater clarity regarding how decentralized autonomous organizations (DAOs), security experts, providers such as Alchemy and Infura, and others collaborate to manage emergent security issues. There are applicable lessons from how large open source communities have formed the OpenSSF and CNCF advisory groups and established processes to tackle security issues.

Authentication and signing

Most dApps, including the most prominent ones, today do not authenticate or sign their API responses. This means that when a user’s wallet retrieves data from these apps, there is a gap in verifying that the response is coming from the intended app and that the data has not been tampered with in some way.

In a world where apps do not employ basic security best practices, it is left to users to determine their security posture and trustworthiness, a task that is practically impossible. At a minimum, there need to be better methods to surface risks to users.

Easier, user-controlled key management

Cryptographic keys underpin users’ ability to transact in the web3 paradigm. Cryptographic keys are also notoriously hard to manage properly; entire businesses have been and continue to be built around managing keys.

The complexity and risk involved with managing private keys is the primary consideration that drives users to choose hosted wallets rather than non-custodial ones. However, the use of hosted wallets leads to two tradeoffs: they result in new “intermediaries” like Coinbase, which detract from the fully decentralized direction of web3; and they restrict users’ ability to take advantage of all that web3 has to offer. Ideally, further security innovation will provide users with both better usability and protections for non-custodial scenarios.

It is worth noting that the first two initiatives center more around people and processes, while the third and fourth initiatives will require technological changes. Getting new technology, nascent processes, and a large number of users aligned is what makes figuring out web3 security hard.

At the same time, one of the most encouraging changes is that web3 security innovation is happening in the open, and we should never underestimate how that can lead to creative solutions.

（文：Wei Lien Dang、翻訳：Nob Takahashi / facebook ）