B2B向けElectronセキュリティ設計：署名検証の優先順位と対策の裏側

難読化やバイトコード化にどれだけ手間をかけても、配布経路そのものに穴が空いていれば意味がありません。Electronアプリのソースコード秘匿を検討する過程で、本当に塞ぐべき穴は別の場所にあることが分かりました。

k.watanabeです。Electronアプリの改ざん防止を検討していたら、実は自動アップデートの署名検証漏れという穴のほうが深刻だと気づきました。この記事では、その気づきから対策の優先順位をどう組み直したかを紹介します。

前提・用語

本題に入る前に、いくつか前提を共有しておきます。Electronは、JavaScript・HTML・CSSでデスクトップアプリを構築できるフレームワークです。Chromiumのレンダリングエンジンと Node.js ランタイムを組み合わせて動くため、Webの技術スタックのままデスクトップアプリを配布できる点が特徴です。

Bytenodeは、JavaScriptのソースをV8エンジンのバイトコードに変換し、配布物からソースコードを読み取りにくくする仕組みです。CrackProofは実行ファイルへの改ざんを検知・防止するためのツールで、逆コンパイルやパッチ当てへの耐性を高める目的で使われます。

一方、本記事で扱う自動アップデートは、クライアントがサーバーへ新バージョンの有無を問い合わせ、更新ファイルを取得してインストールまで自動で行う機能を指します。Electron自体は、公開GitHubリポジトリとコード署名済みビルドを持つアプリ向けにupdate.electronjs.orgというホスト型の更新サービスを提供していますが、プライベートなアプリの場合は独自の更新サーバーを用意し、autoUpdaterモジュールなどを介して配布する必要があります^[1]。なお、このautoUpdaterモジュールが正式にサポートするのは現時点でmacOSとWindowsのみで、Linuxには組み込みの仕組みがありません^[2]。

ここで重要になるのが三つの検証概念です。コード署名は、配布物の発行元が正当であることを証明し、改ざんされたバイナリを識別可能にします。チェックサム検証は、ダウンロードしたファイルのハッシュ値を照合し、通信経路上での破損や差し替えを検知するものです。証明書ピニングは、通信相手のTLS証明書をあらかじめ固定しておくことで、中間者攻撃による通信のすり替えを防ぐ仕組みを指します。自動アップデートの安全性は、この三つがそろって初めて成立します。

難読化検討の裏で見えてきた配布経路の課題

検討のきっかけは単純でした。あるElectronアプリは法人向けにB2B展開しており、ソースコードの中に顧客固有のロジックや内部APIの呼び出し規約が含まれています。逆コンパイルで中身が読めてしまう状態は避けたい、という要望から、JS+Bytenode、さらにCrackProofによる実行ファイル保護を組み合わせる方針を検討し始めました。

ただし議論を進めるうちに、B2Bソフトウェアという性質上、ソースコードの秘匿だけでは足りないという点に行き着きました。一般消費者向けアプリであれば、被害は端末単位にとどまりやすい構図です。しかし法人向けに配布するアプリは、社内の複数端末に同一バイナリが展開されます。配布経路そのものが汚染されれば、被害は一台の端末では終わりません。

そこで、この検討における成功基準を明確にしました。「偽インストーラーが正規のアップデートとして実行されない」ことです。ソースを読めなくすることは攻撃者の手間を増やしますが、配布経路の安全性を保証するものではありません。この二つは別の課題として扱う必要があると判断しました。

メジャーアプリの対策水準とB2B向けアプリで求められる水準の違い

難読化の検討と並行して、広く使われているElectron製アプリがどこまで対策しているかも調べました。VS Code、Discord、Slackといった知名度の高いアプリは、Minification(コードの圧縮・変数名の短縮)とASAR(Electron独自のアーカイブ形式でファイルを一つにまとめる仕組み)程度の対策にとどまっているのが実態です。逆コンパイル耐性を極端に高めるような対策は行われていません。

これは手を抜いているわけではなく、思想の違いだと捉えています。一般消費者向けアプリは起動速度や配布サイズ、開発イテレーションの速さを優先する設計になっており、逆コンパイル耐性よりも実行環境の軽快さが重視されます。一方、法人向けB2Bソフトウェアは事情が異なります。侵害が発生した際の影響範囲が、個人端末一台ではなく顧客企業のネットワーク全体に及ぶ可能性があるためです。

設計上の脆弱性の特定

難読化・暗号化の実装方式を詰めている最中、自動アップデートの仕組みそのものに検証プロセスが存在しないケースがあることに気づきました。最初はBytenodeとCrackProofの組み合わせを強化すれば十分ではないかと考えていましたが、これは見当違いでした。ソースを隠す・実行ファイルの改ざんを検知するという対策は、あくまで「配布された後」のバイナリを守るものであり、「配布そのもの」を守るものではなかったのです。

洗い出した結果、二つのリスクが浮かび上がりました。

特に前者は、一台の端末が汚染されるだけでなく、社内配布網を経由して他の端末にも同じ偽バイナリが広がる構図になりえます。CrackProofで実行ファイルの改ざんを検知できたとしても、それは「正規に配布されたファイルが後から書き換えられていないか」を見るものです。配布時点で偽物にすり替わっていた場合には機能しません。この違いに気づけたことが、優先順位を組み立て直す転換点でした。

優先順位の組み立て直しと段階的アプローチ

この洗い出しを受け、対策の優先順位を見直しました。結論は、ダウンロード時の署名検証を最優先で実装するというものです。逆コンパイル耐性を高める作業は、配布経路が汚染されていない前提の上に成り立つ対策です。土台が崩れていては意味がありません。

Electron公式のセキュリティガイドでも、常に最新バージョンのElectronを使うこと、リモートコンテンツに対してNode.js統合を有効にしないこと、コンテキスト分離とプロセスサンドボックスを有効にすること、信頼できないリモートコンテンツはHTTPSなど安全なプロトコル経由で読み込むことが推奨されています^[3]。これらは自動アップデートの検証とは別レイヤーの対策ですが、通信経路全体の安全性を底上げする意味で、あわせて見直す価値がありました。

この段階的アプローチを選んだ理由は、全対策を同時に完成させようとすると、最も致命的なリスクへの着手が後回しになりかねないと判断したためです。まずJS+Bytenodeのみでリリースし、署名検証の実装を並行して進める。CrackProofは後追いで導入し、逆コンパイル耐性が本当に必要な処理については、長期的にRustなどネイティブ言語側への移行も選択肢として残す、という順序にしました。

現状の制約と未対応の項目

証明書ピニングについては、実装の優先度を署名検証・チェックサム検証より下げる選択肢もあります。中間者攻撃はHTTPS通信であれば発生条件が限定されますが、社内ネットワークのプロキシ環境や公衆Wi-Fiでの利用を考えると、リスクをゼロにはできません。

また、独自の更新サーバーを運用する場合の署名鍵管理体制や、鍵漏洩時のロールバック手順についても、検討が必要です。Electron公式のupdate.electronjs.orgはGitHub公開リポジトリを前提とした仕組みであり^[1]、非公開のB2Bアプリではそのまま利用できないため、独自運用に伴う鍵管理の設計は別途必要になります。

よくある質問

まとめと公開前の確認事項

本記事で解説したのは、致命的なリスクはソースコードの可読性ではなく、自動アップデートの配布経路そのものに存在しうるという視点です。署名検証・チェックサム検証・証明書ピニングのいずれも組み込まれていない状態では、どれだけ実行ファイルを難読化しても、偽インストーラーが正規のアップデートとして実行される穴は塞がりません。

この気づきをもとに、対策の優先順位を署名検証の実装を最優先に置く形へ組み直し、JS+Bytenodeのみでの先行リリース、CrackProofの後追い導入、将来的な重要部分のRust移行という段階的な進め方が考えられます。証明書ピニングをはじめ、独自更新サーバーの鍵管理体制など検討すべき課題もありますが、何を先に守るべきかという優先順位の付け方自体は、他のElectronアプリを運用する現場でも参考になる視点だと思います。

🔗 参考リンク

1. docs/tutorial/updates.md
2. docs/api/auto-updater.md
3. docs/tutorial/security.md at main · electron/electron