Capacitor-updater エンドツーエンドの code 暗号化に対応しました。Code 署名により、エンドユーザーのデバイスで実行されるアップデートが改ざんされていないことを保証し、Capacitor-updater の標準的な Web レベルのセキュリティに加えて、追加の保護層を提供します。
Capacitor-updater のデフォルトのセキュリティ
デフォルトでは、Capgo のセキュリティモデルは Web ホスティングプロバイダーのものと似ています。Capgo はアップデートを保存します 保存時に暗号化 最新の暗号方式を用いたHTTPS経由で配信されます。同様に、開発者のコンピュータからアップデートを公開する際も、常にHTTPSが使用されます。
Capgo のデフォルトのセキュリティは、SSL Labs の HTTPS テストで A+ を獲得しています（https://www.ssllabs.com、2022年11月）
最高水準のウェブホストと同様、Capgo は HTTPS でサーバーとエンドユーザーのデバイス間のネットワーク接続のプライバシーと完全性を保護します。これは、Web と Capgo を使う Ionic アプリの両方で十分に機能する、非常に優れたセキュリティレベルです。
クラウドインフラのサプライチェーン
Capgo とほとんどのウェブホストのもう一つの共通点は、多くの場合 AWS、GCP などの人気クラウドプロバイダーが提供する低レイヤーのクラウドインフラ上で動作していることです。これらのクラウドプロバイダーと Capgo またはその他のウェブホストが運用するハードウェアとソフトウェアは、クラウドサプライチェーンの一部です。
クラウドサプライチェーンとそのセキュリティモデルは、膨大な数のウェブサイトやアプリで機能しています。クラウドプロバイダーを利用するすべてのウェブ開発者は、そのプロバイダーを信頼し、アップロードしたファイルが改ざんされることなく実行または配信されることを期待しています。そして、クラウドプロバイダーはインフラのセキュリティを維持するために尽力しています。
しかし、当然ながらハードウェアやソフトウェアの脆弱性は発見されます。クラウドプロバイダーは適切なスケジュールで脆弱性のパッチを適用し、悪意のあるソフトウェアを未然に防いでいます（例： Google の SLSA), 多層防御を構築し、実際、クラウドインフラはほとんどのウェブサイトやアプリのセキュリティニーズを満たすことが示されています。しかし、一部のIonicアプリは、侵害されたクラウドインフラを脅威モデルに含めています。ウェブを超える最高水準のセキュリティ要件を持つこれらの Capacitor JSアプリ向けに、私たちはエンドツーエンドの code 署名を Capgo と Capgo Updates 標準プロトコルに組み込みました。.
Capgo による code のエンドツーエンド署名
Capgo のエンドツーエンド code 署名は、公開鍵暗号を使用して、エンドユーザーのデバイスが Capacitor アプリ開発者による未改変のオリジナルアップデートのみを実行することを保証します。
「エンドツーエンド」とは、開発者がアップデートを公開してから、エンドユーザーのデバイスがそのアップデートを受信して実行するまでの流れを、このセキュリティがカバーすることを意味します。「Code 署名」とは、暗号技術と秘密鍵を使って code に「署名」し、後から信頼できる公開鍵でその署名を検証することです。
仕組みを説明するシンプルな*スキーマは以下の通りです：
- 実運用では複雑で、暗号技術は難しい
定義:
- AES: Advanced Encryption Standard。共通鍵暗号アルゴリズムで、暗号化と復号に1つの鍵を使用します。
- RSA: Rivest–Shamir–Adleman。公開鍵暗号アルゴリズムで、公開鍵と秘密鍵の2つの鍵を使用します。
- Cypher: 暗号化されたデータ。
- セッションキー: データの暗号化と復号に使用されるAESキー。
- チェックサム: ファイルに対して計算されるハッシュ値。
- 署名: 秘密鍵（RSA）で暗号化されたチェックサム。公開鍵（RSA）で検証可能。
AESアルゴリズムを使用してアップデートを暗号化します。各upload時にランダムなAESキーが生成され、そのAESキーとチェックサム（以下「署名」と称する）は開発者のRSA秘密鍵で暗号化されます。アプリ内では、開発者のRSA公開鍵を使用してAESキーと署名を復号し（チェックサムに戻します）。その後、復号されたAESキーでアップデートを復号し、復号後のアップデートのチェックサムを計算して、復号された署名と比較します。
RSAでは大量のデータを暗号化できないため、2つの異なる暗号化アルゴリズムを使用しています。AESでアップデートを暗号化し、RSAでAESキーとチェックサムを暗号化します。
これにより、Capgoであってもバンドルの内容を閲覧できません。これは多くのエンタープライズ顧客が採用している堅牢なセキュリティモデルです。
Update encryption V2 2024-08-27:
- アプリに保存されるキーの種類を変更しました。これにより、秘密鍵（以前は復号に使用）から公開鍵（以前は暗号化に使用）を推測されるのを防ぎます。現在、アプリには公開鍵（現在復号に使用）が保存されています。
- チェックサムをCRC32アルゴリズムからSHA256アルゴリズムに変更しました。また、 バンドルへの署名暗号化V2が設定されている場合、アップデートには有効な署名が必須です。これはプラグインによって厳格に強制されます。
- 暗号化V2の設定時に有効な署名を必須化しました。 これら3つの変更は、コミュニティメンバーによるセキュリティ分析を受けて実施されたものです。アップデート時の暗号学的攻撃を防ぐために追加されました。
暗号化V1を使用している場合は、新しいセキュリティ機能を利用するためにV2へ移行してください。以下の 移行手順.
エンドツーエンドの code 署名により、Capgo は「トラストレス」なクラウドインフラストラクチャとなります。もし Capgo のクラウドプロバイダーや Capgo 自体が code で署名されたアップデートを改ざんしたとしても、エンドユーザーのデバイスはそのアップデートを拒否し、デバイスに既にある信頼済みのアップデートを実行します。
多くのアプリではWebレベルのHTTPSで十分ですが、大規模企業の中には、エンドツーエンドの code 署名による追加のセキュリティ層を魅力的に感じるケースがあります。高額で永続的な取引を行う金融アプリを展開する企業や、脅威モデルにクラウドインフラの侵害を含めるCISOを擁する企業などが該当します。私たちは、こうしたユースケースのために Capgo にエンドツーエンドの code 署名を組み込みました。より高度なセキュリティ要件を持つ企業からのご意見もお待ちしています。
エンタープライズのお客様向けの始め方
セキュリティを極めて重視する大規模企業やプロジェクトのために、code 署名のセットアップと運用を容易にしたいと考えています。そのために、以下の機能を提供しています：
- 証明書の迅速なセットアップと設定
- Capgo と development build の両方で、code 署名付き開発サーバーをサポート
- すべてのアップデートで本番用 code 署名
Capgo code 署名はすべてのお客様が利用できます。始めるには、次の セットアップ手順.
クレジット
多大な感謝： Ionic、この記事は この記事 ChatGPT-3で書き直し、調整したものです。
Code 署名による Capacitor Updater の E2E 暗号化の続きを読む
使用している場合 Code署名によるCapacitor UpdaterのE2E暗号化 セキュリティとコンプライアンスを計画するには、これを以下と連携させてください 暗号化 暗号化の実装詳細について コンプライアンス コンプライアンスの実装詳細について Capgo セキュリティスキャナー Capgo Security Scanner のプロダクトワークフローについて Capgo のセキュリティ Capgo Security のプロダクトワークフロー向け、および Capgo トラストセンター Capgo Trust Center のプロダクトワークフロー向け。
