BitboxApp Schlüssel enthält keine vertrauenswürdige Signatur?

Also ich habe wie auf der Github-Seite (Releases · digitalbitbox/bitbox-wallet-app · GitHub) beschrieben das Release verifizieren wollen. Aber scheinbar ist es keine vertrauenswürdige Signatur? Ich bin momentan auf Windows. Was soll ich jetzt tun?

gpg: die unterzeichneten Daten sind wohl in 'BitBox-4.29.1-win64-installer.exe'
gpg: Signatur vom 07.09.2021 18:13:11 Mitteleuropische Sommerzeit
gpg:                mittels RSA-Schlüssel 2D8876810AB092E451DCA894804538928C37EAE8
gpg: Korrekte Signatur von "Marko Bencun <marko@shiftcrypto.ch>" [unbekannt]
gpg:                     alias "Marko Bencun <mbencun+pgp@gmail.com>" [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg:          Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck  = 2260 E482 8888 2C76 AFAA  319D 67A2 B160 F74D B275
Unter-Fingerabdruck  = 2D88 7681 0AB0 92E4 51DC  A894 8045 3892 8C37 EAE8
3 „Gefällt mir“

Die Signatur ist korrekt:

gpg: Korrekte Signatur von "Marko Bencun <marko@shiftcrypto.ch>"

Der Warnhinweis ist völlig normal, da du den Schlüssel nicht validiert hast bzw. euer Trust Level zu niedrig ist, wird hier näher erklärt:

So sieht das dann z.B. mit Trust Level 5 aus - kein Warnhinweis:

Du kannst die BitBox App mit gutem Gewissen nutzen! :slight_smile:

4 „Gefällt mir“

Alles klar vielen Dank dir! :slight_smile:

Stark, dass Du der Software nicht einfach vertraust und die Signatur tatsächlich prüfst! :+1:

Ich kann bestätigen, dass die Signatur korrekt ist:

image

6 „Gefällt mir“

Ja ich mein, wenn man die Möglichkeit bekommt kann man das ja mal machen. Gerade bei einer so wichtigen und sensiblen Sache :smiley:

Und auch danke für die Bestätigung :smiley:

1 „Gefällt mir“

Hi,
ich mach mal diesen Thread wieder auf. Beim letzten Update habe ich natürlich die GPG-Keys heruntergeladen und den Download geprüft. Damals war der Key von security@shiftcrypto.ch (09.01.2022) mit dem Fingerprint 1AA6 2C17 C56D 4275 A541 2320 9CD5 646C 0AD5 161E.

Die aktuelle Release 4.34.0 ist jetzt mit einem anderen Key signiert, auch security@shiftcrypto.ch, aber vom 02.06.2022 mit dem Fingerprint DD09 E413 0975 0EBF AE0D EF63 5092 49B0 68D2 15AE.

Das kommt mir eigenartig vor:

  • Warum ändert sich der Key?
  • Warum wird die Änderung des Keys nicht explizit in den Release Notes erklärt?
  • Warum ist der neue Key nicht mit dem alten signiert (zumindest habe ich keine Beglaubigung auf hkps://keys.openpgp.org gefunden)

Vielleicht mache ich auch einen Anwenderfehler. :person_shrugging:
Vielleicht kann mir @Stadicus weiterhelfen?

2 „Gefällt mir“

Das ist mir auch aufgefallen. Gut dass du da nochmal nachhakst, ich habe das nämlich einfach nur schulterzuckend so hingenommen. :sweat_smile:

Vielleicht war das einfach nur ein Upgrade auf einen 4096 bit Schlüssel, der alte hatte noch 2048 bit.

2 „Gefällt mir“

Ich glaube das fasst das Problem von GPG treffend zusammen. :rofl:
Ich habe mir vorgenommen zu Übungs-Zwecken bei jeder Bitcoin-Software wirklich genau zu sein.

Also auchg SHASUM prüfen und GPG-Schlüssel prüfen. Beim GPG-Schlüssel ist mir schon bei vielen Distributionen aufgefallen, dass Änderungen der Schlüssel mehr schlecht als recht dokumentiert werden.

In diesem Fall steht ja eh in den Release-Notes der neue Schlüssel, was ja prinzipiell eh passt. Aber da frage ich mich schon, was GPG bringt, wenn niemand genau prüft.

Eigentlich müsste es da auch Keysigning-Partys geben. Wäre doch schön, wenn bsps. der Shiftcrypto Key auch durch irgendeinen Bitcoin-Maintainer signiert wäre, oder durch den @Blocktrainer oder andere bekanntere Bitcoiner. Dann könnte ich als User immerhin einen zweiten Weg zur Überprüfung nutzen.

4 „Gefällt mir“

Vielen Dank für dein aufmerksames Auge, @GLN. Wir haben deine Frage als Anregung genommen, den PGP-Key-Wechsel explizit in den Release Notes zu vermerken:

Du hast ein paar interessante Punkte angesprochen, welche ich kurz kommentieren möchte:

  • Warum ändert sich der Key? → Das kann aus unterschiedlichem Anlass passieren und ist nichts aussergewöhnlich. Keys werden regelmässig rotiert, in zeitlichen Abständen oder aus betrieblichen Gründen.

  • Warum wird die Änderung des Keys nicht explizit in den Release Notes erklärt? → Welcher Key aktuell gültig ist, spielt eigentlich keine grosse Rolle. Wir haben in den Release Notes den gültigen Key erwähnt, aber nicht den Wechsel als solches. Das wurde nun nachgeholt.

    Hier muss man sich überlegen, welchen Zweck dieser Schlüssel eigentlich hat. Bei der BitBoxApp selber soll er verhindern, dass dir jemand eine bösartige Version unterjubeln kann. Wenn nun jemand GitHub hacken könnte (dort wird die BitBoxApp publiziert), sollte diese Person nicht auch noch den Schlüssel faken können. Darum hosten wir genau seit dem letzten Release den PGP-Key auf unserer eigenen Website. Jemand müsste nun GitHub UND unsere Website hacken, um eine gültige Signatur veröffentlichen zu können.

  • Warum ist der neue Key nicht mit dem alten signiert? → Den alten Key haben wir „revoked“, also als ungültig gekennzeichnet. Auch geht es weniger um die lückenlose Kontinuität, und der Schlüssel stellt auch keine digitale Identität dar, sondern dient einfach der Validierung des Downloads.

  • ich (frage) mich schon, was GPG bringt, wenn niemand genau prüft → Ich denke, das ist wie bei Open Source-Code & der reproduzierbaren Kompilierbarkeit: es reicht, wenn das einige wenige machen, welche dann im Zweifelsfalle Alarm schlagen können.

    Klar wäre es schön, wenn das mehr Leute machen würden, daher laden wir bei der reproduzierbaren Firmware der BitBox02 (welche viel sensitiver ist als die BitBoxApp, welcher nicht mal die BitBox02 vertraut) die Community dazu ein, die Firmware selber zu kompliieren und via PGP-Signatur zu attestieren. Hier als Beispiel die letzte Bitcoin-only Firmware, mit der Attestation von @sutterseba (vielen Dank dafür!). Da ist klar noch Platz für mehr! :slight_smile:

    Aber es ist meiner Erfahrung nach leider so, dass PGP/GPG für Normalsterbliche (sprich: nicht uns maximal Paranoide) zu umständlich ist.

  • Eigentlich müsste es da auch Keysigning-Partys geben → Ich denke, diese Key Signing-Zeremonien machen vor allem bei Privatpersonen und ihren persönlichen, langlebigen Schlüsseln (ihrer digitalen Identität) Sinn. Wenn’s nur um die Sicherstellung der Download-Integrität geht, ist eine regelmässige Key Rotation aus meiner Sicht wichtiger.

Du sprichst hier ein enorm spannendes Thema an. Vielen Dank für dein konstruktives Feedback. Auch wir lernen immer dazu und wollen unsere Prozesse (auch bezüglich transparenter Kommunikation) stetig verbessern.

9 „Gefällt mir“

Cool, danke für deine ausführliche Antwort!!! :+1:

Und noch viel mehr für die gleich umgesetzten Änderungen! :+1: :+1:

Das mit der Key-Rotation kenne ich tatsächlich nicht, ich habe bis jetzt immer nur an „langlebige Schlüssel“ gedacht, dass es bei betrieblichen Schlüsseln andere Anforderungen gibt, habe ich gar nicht bedacht.

Mein eigener Workflow schaut so aus: Ich importiere einen Key, in dem Fall euren, und versuche zu validieren, ob er überhaupt der richtige ist. Sobald ich das durch eine dritte Quelle (bspw. haben viele OpenSource-Entwickler ihre Keys auf ihrer Website oder auf Twitter publiziert) verifiziert habe beglaube ich ihn selbst, damit ich das nächste Mal, weiß, dass ich die Prüfung bereits gemacht habe. Wenn nun ein neuer Schlüssel kommt, der auch nicht durch den alten signiert ist, muss ich aufs neue Validieren und bin erst einmal skeptisch. Aber vielleicht ist mein Workflow auch nicht so sinnig… :laughing:

Das mit der Firmware-Attestation muss ich in nächster Zeit ausprobieren! Finde ich toll, was ihr alles umsetzt, super!

3 „Gefällt mir“

Danke für die Rückmeldung, so werden wir doch alle schlauer… :slight_smile:

Das ist hautpsächlich dann der Fall, wenn mehrere Personen Zugriff auf bestimmte Schlüssel haben, was zur Vermeidung von „single points of failures“ wichtig ist. Wenn sich die Zugriffsprivilegien ändern, Personen kommen und gehen, dann werden die Keys revoked und rotiert. Oder auch aus anderen Gründen.

Ich glaube dein Workflow ist schon sinnig. Aktuell kann ich nicht versprechen, dass wir künftig den neuen Key mit dem alten signieren, aber mindestens wird’s expliziter erwähnt. Und aktuell ist der Fingerprint ja auf GitHub, und der Key selber auf shiftcrypto.ch gehosted.

3 „Gefällt mir“

You’re in luck… :wink:

3 „Gefällt mir“

Frage: Ich möchte die Signatur der heruntergeladenen Bitboxapp überprüfen. Dafür brauche ich Gpg (für MacOS) oder ähnliches, oder? Aber wie und wo kann ich diese Software sicher herunterladen? Vielen Dank im Voraus.

Am einfachsten ist es wenn du dir erstmal Homebrew (Package Manager für macOS) installierst.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Dafür diesen Befehl einfach in ein Terminal kopieren und den Anweisungen folgen.

Dann kannst du GPG einfach mit

brew install gpg

installieren.

Mit Homebrew kannst du so ziemlich alles installieren, ist also für die Zukunft auch sehr praktisch.

Ansonsten kannst du GPG natürlich auch direkt installieren, inklusive GUI:

2 „Gefällt mir“

Netter Tipp. Wurde vor kurzem von Roman und Basti auch zu einem Arbeits-Macbook genötigt (xD) und kannte Homebrew noch nicht :slight_smile:

2 „Gefällt mir“

Da könnte es doch wirklich schlimmeres geben :grin:

2 „Gefällt mir“