1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Geheimtreffen: Telekom will Partner…

"Offenlegung" von Quellcode und Wege der Manipulation

  1. Thema

Neues Thema Ansicht wechseln


  1. "Offenlegung" von Quellcode und Wege der Manipulation

    Autor: cpt.dirk 02.02.19 - 17:09

    Von einer "Offenlegung" im Sinne von "quelloffen" kann hier wohl keine Rede sein.

    Sich von der Vorlage eines wie auch immer gearteten, evtl. völlig undokumentierten Quellcodes, in Teilen oder im Ganzen, vor ein kleines Team von staatlichen Prüfern einen nennenswerten Sicherheitsgewinn zu erhoffen, ist wohl reine Selbsttäuschung, bzw. Illusion.

    In ein komplexes System, welches von großen, hochspezialisierten Teams in monate- oder jahrelanger Arbeit entwickelt wurde - auch bei einigermaßen guter Dokumentation - in einer hinreichend kurzen Zeit und hinreichend weit gedanklich vorzudringen, dazu bedarf es erheblicher personeller Resourcen und fachlicher Kompetenz, die so mutmaße ich, die Möglichkeiten einer kleinen staatlichen Behördenabteilung bei weitem übersteigt.

    Hinzu kommt noch die Anforderung, Fälle mit abzuschätzen, die nicht unmittelbar aus untersuchter Dokumentation, dem Code und der Hardware abgeleitet werden können, Bugs, Sollbruchstellen und mögliche Seitenkanalangriffe. Solche werden, selbst bei Open-Source, oft erst durch die kontinuierliche Audition von vielen verschiedenen Teams und Individuen (insgesamt tausende) und manchmal erst nach Jahren entdeckt.

    Völlig illusionär ist es daher wohl, anzunehmen, so etwas könne durch die Pseudoversion einer verdeckten Offenlegung von Quellcode vor eine kleine staatliche Prüfertruppe ersetzt werden.
    Wenn diese Aufgaben dann mangels Resourcen und Kompetenz wieder outgesourced werden müssen, kann man das ganze Procedere ohnehin gleich verwerfen.

    Man sollte auch nicht vergessen, dass zwischen Quellcode und kompilierten Blobs, bzw. dem letztlichen erwarteten Verhalten des Gesamtsystems zu unterscheiden ist, welche sich fundamental von ersterem unterscheiden können:

    - weil das Kompilat vom Hersteller selbst aus manipuliertem Quellcode erzeugt wurde
    - weil das Kompilat dem Quellcode entspricht, dieser sich aber den Prüfern nicht erschließt
    - weil das Kompilat bei der Prüfung dort mit manipuliertem Quellcode erstellt wird
    - weil das Kompilat mittels manipuliertem Compiler erzeugt wurde
    - weil das Kompilat mittels Compiler auf einem manipulierten System erzeugt wurde
    - weil das Kompilat mittels manipuliertem Flasher durch eine manipulierte Version ersetzt wird
    - weil das Kompilat im Nachgang von einem Agenten manipuliert wird
    - weil das Kompilat im laufenden Betrieb per OOB vom Hersteller manipuliert wird
    - weil das Kompilat in (geheimen) Betriebsmodi von der Hardware umgangen / erweitert wird
    ... usw.

    Eine Offenlegung der Hardwareschaltpläne würde auch - wenn überhaupt - nur bei penibler Überprüfung durch eine große Anzahl erfahrener Spezialisten etwas bringen (enorme Komplexität und viele-Augen-Prinzip) und viel Geld und noch mehr Zeit benötigen.

    Auch müsste eine exakte Umsetzung der Schaltpläne in Hardware durch enorm aufwendiges Reverse-Engineering überprüft werden.

    Schlussendlich sind manche Manipulationen auf Chipebene dermaßen subtil, dass ihr Nachweis mit wirtschaftlich vertretbaren Mitteln im Grunde gar nicht machbar ist, etwa die Schwächung von Hardwareverschlüsselungsroutinen durch gezielte Dotierungsverunreinigungen bei der Herstellung.

    s. auch:
    https://securinghardware.com/articles/do-i-have-a-hardware-implant/

  2. Danke für die gute Zusammenfassung (KwT)

    Autor: Kondratieff 08.02.19 - 09:34

    KwT

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Abteilungsleitung IT (m/w/d)
    PVS Limburg-Lahn GmbH, Limburg an der Lahn
  2. Abteilungsleitung (m/w/d) IT-Strategie, Qualitätsmanagement und Entwicklungssteuerung
    Anstalt für Kommunale Datenverarbeitung in Bayern (AKDB), München
  3. IT Specialist Messaging - Exchange (m/w/d)
    Dr. August Oetker Nahrungsmittel KG, Bielefeld
  4. Inhouse SAP Teamleiter & SAP S / 4HANA Projektleiter (m/w/x)
    über duerenhoff GmbH, Raum Weil am Rhein

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. 569,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de