Wie Open-Sourciness das Ledger Seed Problem verhindert

Dom Fora Portfel Trezora Wie Open-Sourciness das Ledger Seed Problem verhindert

Przeglądanie 0 wątki z odpowiedziami
  • Autor
    Posty
    • #4289
      Admin
      Członek
      W górę
      0
      W dół
      ::

      ^(Disclaimer: dies ist nicht nur für ein Trezor-Publikum gedacht, aber die Benutzer fragen hier)

      In dieser Woche gab es viele Threads zu Ledgers kürzlich eingeführter FunktionLedger Recover”. Eine der vielen Beschwerden war, dass diese Funktion von einem [Wired magazine article](https://www.wired.com/story/ftx-crypto-investors-hardware-wallets/) durchgesickert ist und nicht durch eine offizielle Mitteilung von Ledger selbst. Die meisten, die von Ledgers neuer Firmware betroffen sind, sind auf der Suche nach einer HW-Wallet, die zu 100 % ausfallsicher ist. Dies kann ein SEHR schwer zu erreichendes Ziel sein, daher werde ich erörtern, was annähernd auslaufsicher sein kann, auch wenn es nie ganz erreicht wird. Aber hier ist eine grundlegende Skizze, wie ein auslaufsicheres HW-Gerät aussehen würde.

      1. Vollständig quelloffener und reproduzierbarer Software-Stack
      2. Vollständig quelloffener und reproduzierbarer Hardware-Stack
      3. Vollständig offengelegte Mikrocontroller-Spezifikationen
      4. Öffentlicher, kryptographisch signierter Warrant Canary

      Gehen Sie diese Punkte nacheinander durch

      ## Offenes und reproduzierbares Softwarepaket

      Die Idee von Opensource war ursprünglich die Möglichkeit, Software zu verändern, um sie bei Bedarf zu reparieren. Aber in der Kryptographie wird Opensource eher aus Gründen der Überprüfbarkeit eingesetzt. Die Idee der Überprüfbarkeit ist, dass Sie oder jemand wie Sie den gesamten Quellcode lesen und jeden Code finden können, der besagt:

      send_seed(to =hackerman@hackerland.haha”, seed =all your coins belong to us”)

      Eines der berühmtesten Beispiele hierfür war der Diebstahl der Guthaben von [Copay Bitcoin Wallets](https://www.theregister.com/2018/11/26/npm_repo_bitcoin_stealer/) durch die Einführung von Code in einem der öffentlichen Repos. Der Diebstahl kam erst ans Licht, als ein [college student](https://github.com/FallingSnow) den Code sah und ihn meldete. Man beachte, dass das Problem nicht von einem Kunden aufgeworfen wurde, der den Diebstahl meldete, sondern von einem freiwilligen Prüfer, der den Code überprüfte. Für diejenigen, die nicht in der Technologiebranche arbeiten, mag der Gedanke an freiwillige Programmierer komisch klingen, aber es werden weitaus mehr Probleme von freiwilligen Programmierern aufgedeckt als durch Anwendungsbeobachtungen von Nutzern aufgedeckt werden.

      Wenn Sie also ein vollständig quelloffenes Softwareprojekt haben, das von der Gemeinschaft ausreichend geprüft wurde, können Sie die Software erstellen und wissen, dass Sie geprüften Code verwenden. In den meisten Fällen würden normale Benutzer jedoch ladbare Binärdateien dem kompilierbaren Quellcode vorziehen. Um dies zu berücksichtigen, kommt das Konzept derreproduzierbaren Buildsins Spiel. Ein reproduzierbares Build ist eine Software, die von zwei zufälligen Freiwilligen erstellt werden kann und die Byte für Byte identisch ist. Mit einem reproduzierbaren Build können Auditoren der Gemeinschaft klar signalisieren, wenn ihr Build nicht mit dem veröffentlichten Build übereinstimmt. Wenn sie unterschiedlich sind, wird die Veröffentlichung in Frage gestellt.

      Aber selbst bei vollständig reproduzierbaren Builds besteht immer noch die Gefahr einesVertrauensangriffs”. Dabei würde ein Staat absichtlich die Build-Tools, die die Software erstellen, beschädigen, um Spyware in den Build-Prozess selbst einzuschleusen. Das geht ziemlich tief ins Alufolienhut-Land, aber es ist immer noch etwas, das diskutiert werden sollte. Das Bitcoin Core Projekt hat es ernst genug genommen, um zu einem Betriebssystem namens GUIX zu wechseln. Das gesamte Betriebssystem kann aus einer kleinen [357 byte program](https://www.joyofsource.com/we-did-it.html). Dieses kleine Bootstrap-Programm ist so klein, dass der Maschinencode von Hand überprüft werden kann, um sicherzustellen, dass nichts Ungewöhnliches vor sich geht.

      – [Trusting Trust attacks and reproducible builds](https://np.reddit.com/r/Bitcoin/comments/smj1ep/bitcoin_v220_and_guix_stronger_defense_against/)
      – [Bitcoin build reproducibility](https://github.com/bitcoin/bitcoin/blob/10660c0/contrib/guix/README.md#attesting-to-build-outputs)
      – [Trezor build reproducibility](https://github.com/trezor/trezor-firmware/blob/30a77a7/docs/common/reproducible-build.md)
      – [Coldcard build reproducibility](https://github.com/Coldcard/firmware/blob/c9fbe0e/README.md#reproducible-builds)
      – [Bitbox build reproducibility](https://github.com/digitalbitbox/bitbox02-firmware/blob/master/releases/README.md#reproducible-builds)

      ## Open-Source-Hardware

      Genauso wie Open-Source-Software wichtig ist, um den Code zu überprüfen, ermöglicht Open-Source-Hardware Freiwilligen, die Hardware zu überprüfen. Ähnlich wie bei dem bereits erwähnten Angriff auf dasVertrauenbesteht eine Hardware aus vielen vorgefertigten Teilen (LEDs, Mikrocontroller, Widerstände). Wenn eine dieser Komponenten Hintertüren enthält, weiß das nicht einmal der Anbieter der HW-Wallet.

      – [How to build Trezor / Bitbox from specs](https://blog.wasabiwallet.io/diy-hardware-wallets-part-i-building-your-own-trezor-one-model-t-and-bitbox02/)

      ## Mikrocontroller-Spezifikationen

      Selbst bei vollständig quelloffener Software und Hardware muss man wissen, was im Inneren des Mikrocontrollers vor sich geht. Um auch nur die geringste Chance zu haben, in das Innere des Mikrocontrollers einzudringen, benötigen Sie nicht nur den Schaltplan und die Stückliste, sondern auch die vollständigen, öffentlich zugänglichen Spezifikationen für alle Bestandteile des Mikrocontrollers. Einige sichere Elemente sind mehropensourceals andere, während für andere eine NDA erforderlich sein kann, um die Details einzusehen. Aber selbst mit all diesen Informationen gibt es keine Hoffnung, einen eigenen Mikrocontroller zu bauen. An dieser Stelle müssen wir aufgeben und dem Hersteller vertrauen. Es gibt nur sehr wenige Möglichkeiten, zu überprüfen, was in einem Mikrochip steckt.

      – [STM32 microcontroller full specifications](https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus/documentation.html)

      ## Warrant Canary

      A [warrant canary](https://en.wikipedia.org/wiki/Warrant_canary) ist eine Art Gesetzeslücke, die gegen den US Patriot Act und ähnliche Gesetze verstößt. Im Rahmen des Patriot Act kann jeder, der erklärt, dass gegen ihn ermittelt wird, mit strafrechtlichen Sanktionen belegt werden. Im Klartext: Wenn Sie jemandem erzählen, dass die Regierung herumschnüffelt, gehen Sie ins Gefängnis. Das Schlupfloch besteht in dem Unterschied zwischen einerNachrichtensperreund einemRedezwang”. Obwohl es (leider) legal ist, dass ein Gericht jemandem verbietet zu sprechen („gag order”), können Gerichte (noch) niemanden zwingen, öffentlich zu lügen („compelled speech”). Ein Kanarienvogel ist also im Grunde eine Akte, in der steht

      Keine staatliche Schnüffelei diese Woche

      Wenn es dann zu einer staatlichen Schnüffelei kommt, weigern Sie sich einfach, weitere Kanarienvögel zu veröffentlichen. Dann nimmt jeder, der den Vorgang beobachtet, durch Abwesenheit an, dass jetzt staatliche Schnüffelei stattfindet. Die kryptografische Signierung dieser Dateien ist für den Herausgeber nützlich, denn wenn er seine Canary-Schlüssel vernichtet, kann kein Regierungsvertreter einen Canary in seinem Namen fälschen.

      Selbst wenn Sie mit einem Hardware-/Softwarepaket zufrieden sind, sollten Sie wissen, wann Sie das Produkt aufgeben müssen.

      – [Cloudflare canary](https://www.cloudflare.com/transparency/)
      – [Trezor canary](https://trezor.io/transparency/canary.txt)
      – [QubesOS canary](https://github.com/QubesOS/qubes-secpack/blob/77b12f3/canaries/canary-034-2023.txt)

      # Schlussfolgerung

      Da wir dem Mikrocontroller vertrauen müssen, da er nicht vollständig überprüft werden kann, müssen wir mit einem gewissen Maß an Vertrauen leben. Wir werden keine zu 100 % überprüfbaren Builds erreichen, die vollständig erklären können, dass es unmöglich ist, Samen zu extrahieren. Das Beste, worauf wir hoffen können, ist einIch weiß es nichtvon den meisten Hardware-Wallets. Natürlich können einige Hardware-Wallets mit vollständig schreibgeschützten kritischen Schlüsselabschnitten im sicheren Element ausgestattet sein, aber wir werden nie erfahren, ob es geheime, undokumentierte Pin-Manipulationen am Mikrocontroller gibt, die eine Schlüsselexfiltration ermöglichen würden.

      Wir können also nur hoffen, dass wir alle einen HW-Hersteller finden, mit dem wir zufrieden sind und dem wir so selten wie nötig vertrauen können. Aber IMHO ist ein vollständig offengelegter und offener Stack der allererste Schritt. Wenn das nicht der Fall ist, kann nichts anderes folgen.

Przeglądanie 0 wątki z odpowiedziami
  • Aby odpowiedzieć na ten temat, musisz się zalogować.
Przejdź do paska narzędzi