Capacitor-Updater code-Updater unterstützt nun end-to-end code-Verschlüsselung. Code-Signierung stellt sicher, dass die Updates von den Geräten der Endnutzer nicht manipuliert wurden und bietet einen zusätzlichen Schutz über Capacitor-Updaters Standard-Sicherheit
Die Standard-Sicherheit von Capacitor-Updater
Standardmäßig ähnelt Capgos Sicherheitsmodell dem von Web-Hosting-Anbietern. Capgo speichert Updates verschlüsselt im Ruhezustand und dient sie über HTTPS mit modernen Ziffern. Ebenso verwendet ein Entwickler immer HTTPS, wenn er ein Update von seinem Computer veröffentlicht.
Capgo's Standard-Sicherheit erzielt eine A+ bei der SSL-Labs-HTTPS-Testung (https://www.ssllabs.comNovember 2022)
Ähnlich wie beste Web-Hosts verwendet Capgo HTTPS, um die Privatsphäre und die Integrität von Netzwerkverbindungen zwischen dem Server und den Geräten der Endnutzer zu schützen. Dies ist ein hervorragender Sicherheitsstandard, der sich sowohl für Web- als auch für Ionic-Anwendungen gut bewährt hat, die Capgo verwenden.
Der Cloud-Infrastruktur- Lieferkettenschluss
Ein weiteres gemeinsames Merkmal von Capgo und den meisten Web-Hosts ist, dass sie auf untergeordneter Cloud-Infrastruktur laufen, oft von AWS, GCP oder einem anderen beliebten Cloud-Anbieter. Die Hardware und Software, die von diesen Cloud-Anbietern und Capgo oder anderen Web-Hosts betrieben werden, sind Teil der Cloud-Lieferkette.
Der Cloud-Lieferkettenschluss und sein Sicherheitsmodell funktionieren für eine riesige Anzahl von Websites und Apps. Jeder Web-Entwickler, der einen Cloud-Anbieter verwendet, setzt Vertrauen in diesen Anbieter und erwartet, dass die Dateien, die er hochlädt, die Dateien sind, die ohne Manipulation ausgeführt oder bereitgestellt werden. Und die Cloud-Anbieter arbeiten hart daran, ihre Infrastruktur sicher zu halten.
Aber offensichtlich werden Hardware- und Software-Schwachstellen entdeckt. Cloud-Anbieter beheben Schwachstellen in regelmäßigen Abständen, verhindern proaktiv schädliche Software (z.B. Googles SLSA), bauen Schichten der Verteidigung in der Tiefe und in der Praxis hat sich die Cloud-Infrastruktur bewährt, um die Sicherheitsanforderungen der meisten Websites und Apps zu erfüllen. Allerdings umfassen einige Ionic-Apps die kompromitierte Cloud-Infrastruktur in ihren Bedrohungsmodellen. Für diese Capacitor JS-Anwendungen mit den höchsten Sicherheitsanforderungen über dem Web haben wir end-to-end code-Signierung in Capgo und die Capacitor-Updates-Standardprotokoll implementiert. Capgo-Updates-Standardprotokoll.
End-to-end code-Signierung mit Capgo
Capgo-Signierung mit end-to-end code-Signierung verwendet öffentliche-Schlüssel-Kryptographie, um sicherzustellen, dass die Endgeräte der Endnutzer nur unveränderte, ursprüngliche Updates vom Capacitor-App-Entwickler ausführen.
“End-to-end” bedeutet, dass diese Sicherheit den Fluss von der Zeit, zu der ein Entwickler ein Update veröffentlicht, bis zur Zeit, zu der ein Endgerät des Endnutzers das Update erhält und ausführt, umfasst. “Code-Signierung” ist die Verwendung von Kryptographie und einem geheimen privaten Schlüssel, um code zu “signen”, und später die Verwendung eines vertrauenswürdigen öffentlichen Schlüssels, um die Signatur zu überprüfen.
Hier ist ein einfaches* Schema, um zu erklären, wie es funktioniert:
- Komplex in der Praxis, Kryptographie ist schwierig
Definition:
- AES: Advanced Encryption Standard, ein symmetrischer Verschlüsselungsalgorithmus, ein Schlüssel für Verschlüsselung und Entschlüsselung.
- RSA: Rivest–Shamir–Adleman, ein asymmetrischer Verschlüsselungsalgorithmus, zwei Schlüssel werden verwendet: ein öffentlicher Schlüssel und ein privater Schlüssel.
- Cypher: Die verschlüsselte Daten.
- Session key: An AES key used to encrypt and decrypt data.
- Prüfsumme: Ein Hash, der für ein Datei berechnet wird.
- Signatur: Ein Prüfsummenwert, der mit einer privaten RSA-Schlüssel verschlüsselt wurde. Er kann mit einem öffentlichen RSA-Schlüssel überprüft werden.
Wir verwenden das AES-Algorithmus, um die Aktualisierung zu verschlüsseln. Ein zufälliger AES-Schlüssel wird für jeden Upload generiert, dann werden der AES-Schlüssel und die Prüfsumme (im Folgenden „Signatur“) mit dem privaten RSA-Schlüssel des Entwicklers verschlüsselt. Der öffentliche RSA-Schlüssel des Entwicklers wird im App verwendet, um den AES-Schlüssel und die Signatur (wieder in eine Prüfsumme umgewandelt) zu entschlüsseln. Später wird der entschlüsselte AES-Schlüssel verwendet, um die Aktualisierung zu entschlüsseln; eine Prüfsumme der entschlüsselten Aktualisierung wird berechnet, und sie wird mit der entschlüsselten Signatur verglichen.
Wir verwenden zwei verschiedene Verschlüsselungsalgorithmen, weil RSA nicht verwendet werden kann, um große Datenmengen zu verschlüsseln. AES wird verwendet, um die Aktualisierung zu verschlüsseln, und RSA wird verwendet, um den AES-Schlüssel und die Prüfsumme zu verschlüsseln.
Mit diesem können sogar Capgo nicht den Inhalt Ihres Bundles lesen. Dies ist ein robustes Sicherheitsmodell, das von vielen Unternehmen verwendet wird.
Aktualisierungsverschlüsselung V2 2024-08-27:
- Wir haben den Schlüsseltyp, der im App gespeichert wird, gewechselt. Dies wurde getan, um das Inferieren der öffentlichen Schlüssel (früher verwendet für die Verschlüsselung) aus dem privaten Schlüssel (früher verwendet für die Entschlüsselung) zu verhindern. Jetzt speichert das App den öffentlichen Schlüssel (jetzt verwendet für die Entschlüsselung).
- Wir haben den Prüfsummenalgorithmus von CRC32 auf den SHA256-Algorithmus gewechselt. Wir haben auch begonnen, den Bundle zu signieren. BundelsignierungWenn die Aktualisierung V2 konfiguriert ist, muss eine Aktualisierung eine gültige Signatur haben. Dies wird streng durch den Plugin durchgesetzt.
- Wir setzen nun eine gültige Signaturverschlüsselung V2 durch. Diese 3 Änderungen wurden nach einer Sicherheitsanalyse von einem Mitglied der Community durchgeführt. Sie dienen dazu, kryptographische Angriffe während der Aktualisierung zu verhindern.
Wenn Sie Verschlüsselung V1 verwendet haben, migrieren Sie zu V2, um die neuen Sicherheitsfunktionen zu nutzen. Folgen Sie den Anweisungen. Anleitung zur Migration.
With end-to-end code signing, Capgo becomes a “trustless” cloud infrastructure. If one of Capgo’s cloud providers or even Capgo itself were to modify a code-signed update, end users’ devices would reject that update and run the previous, trusted update that’s already on the device.
While web-level HTTPS is sufficient for many apps, some large companies find the extra level of security from end-to-end code signing appealing. Some of these companies make finance apps that issue high-value, permanent transactions. Other companies have CISOs who include compromised cloud infrastructure in their threat models. We built end-to-end code signing in to Capgo for these use cases and are interested in hearing more from companies with higher-level security needs.
Getting started for enterprise customers
For large companies or projects who care deeply about security, we want to make code signing easy to set up and maintain. To that end, we now provide the following features:
- Schnelle Zertifikatskonfiguration
- Unterstützung für die Signierung von code-Entwicklungs-Servern mit sowohl Capgo- als auch Entwicklungsbuilds
- Produktions code-Signierung bei jedem Update
Capgo code-Signierung ist für alle Kunden verfügbar. Um loszulegen, folgen Sie den Setupanleitungen.
Krediten
Vielen Dank an Ionic, dieses Artikel basiert auf diesem Artikel erstellt mit chat-gpt-3 und angepasst.
Fortsetzen Sie mit E2E-Verschlüsselung für Capacitor-Updater über Code-Signierung
Wenn Sie Capgo verwenden E2E-Verschlüsselung für Capacitor-Updater über Code-Signierung um Sicherheit und Compliance zu planen, verbinden Sie es mit Verschlüsselung für die Implementierungsdetails in der Verschlüsselung, Kongruenz Kongruenz für die Implementierungsdetails in Kongruenz, Capgo Sicherheits-Scanner für den Produktworkflow in Capgo Sicherheits-Scanner, Capgo Sicherheit Capgo Sicherheit für den Produktworkflow in Capgo Sicherheit und Capgo Vertrauenszentrum für den Produktworkflow im Capgo Trust Center.
