Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Sicherheitsloch im SSL-Protokoll

Secure Design...

  1. Thema

Neues Thema Ansicht wechseln


  1. Secure Design...

    Autor: Siga9876 05.11.09 - 16:13

    Wenn man seine Handy-Nummern oder MP3s verwaltet, sind Beweise egal.

    Wenn hingegen um Protokolle und Sicherheits-Krams geht, sollte die totale Sicherheit und möglichst bewiesene Sicherheit herrschen. Und keine Fake-Pseudo-Möchtegern-Klappt-Doch-PHP-PseudoHohlProgger-Pseudo-Sicherheit.

    Soll heissen: Man tut genau das, was in solchen Lehrbüchern wie Applied Cryptography und sonstwo steht. Und dann geht man NICHT hin, und patcht und "optimiert" und macht was anders, weil man es besser findet usw. Wer vom schmalen Grat der als sicher eingestuften Protokollen abweicht, fällt ins Wasser bzw. dessen Daten fallen heraus, von wo sie überall hin schwimmen/diffundieren können. z.b. bis zur OstEuropaMafia.

    Bei solchen Protokollen und Anwendungen (Gesundheitskarte, Online-banking) gibt es keine Ausreden und es gibt kein Vertun. Die müssen ultrasicher durch Beweis und garantiert sicher designed und programmiert werden. Vorher denken statt nacher patchen wie bei PatchyHtmlProgger-Sprache oder M$.
    Das ist "heiliger" super-code. Bevor da was geändert wird (siehe Debian-Patch der schwache Passworte oder sowas erzeugte) muss doppelt und dreifach und zehnfach drübergeschaut werden ob das korrekt ist. Und nicht von einem PseudoHohlProgger sondern von mehreren Leuten, die Ahnung haben. Die Zahl der betroffenen Libs ist allerdings gering (SSL, SSH, crypt-Libs usw...). Das man woanders die Passworte unverschlüsselt ins Logfile schreibt usw. sind dann andere Fehler-Sorten. Aber der Kern muss erst mal bewiesen sauber und sicher sein.

    Problem: Hacken ist ja viel kewler als sichere Systeme designen.
    Ich habe meine Scripte gegen (SQL|Script|...)-Injection gesichert, da kannte ich den Begriff der "Injection" noch gar nicht. Aber ich wusste: Wenn ich nicht sauber die Argumente in die Abfrage reinmache und absichere, können Spacken was injecten. Und Taint-Perl hilft dabei auch nicht wirklich weil die Raushol-Regexprs ja von Spacken gemacht sein können. Es sichert bestenfalls gegen Schlampigkeit und zwingt, das man gezielte Übergabe macht. Aber es verhindert das Kernproblem der Injection nicht wirklich.

    Noch was in der Richtung also nicht ganz-Off-Topic: HDMI wurde als insecure geoutet. Der Prof wurde eingeschüchtert und redet nicht (mehr) (darüber). Also könnte man mal die HDMI-Protokolle ansehen und genau schauen, was anders als in den Lehrbüchern gemacht wird.
    Wieso wäre das relevant ? Weil einem dann AACS usw. egal sein können, wenn man ein FPGA mit HDMI-"Protokoll" designed, das alle Daten am Player-Ausgang abrippt. Allerdings entpackt abrippt, was nicht so ganz optimal ist. Weil verlustbehaftet gepackt und damit verlustmäßig entpackt nicht besser ist, als es (verlustig) gepackt zu lassen. Sieht man auch wenn man Elektronik auspackt und nur die Chinesen aus der Fabrik wieder alles in die eigentlich zu kleine Pappkiste reingefuddelt kriegen.
    Bei png/gif/bmp usw. (verlustfrei) wäre es etwas anderes.
    Ein HDMI-Ripper ist also nicht wirklich etwas brauchbares wenn man die Qualität nicht (durch verlustiges Re-Compressen) schlechter machen will.
    Ausserdem ist sowas ja verboten durch DMCA. Beim Bund gibts Verleiten zum Diebstahl. Bei Digitalen Pseudo-Crypt-Systemen wie CSS gilt eigentlich dasselbe. Und mehr als 1 Jahr bräuchte der Schutz auch nicht zu sein. Dann kauft man für Linux die BluRays ein Jahr später und kriegt die Keys des Vorjahres alle 6 Monate. Bis dahin hat die Schulhof-Mafia und Press-Werk-Mafia usw. den Film nämlich ausgelutscht und ausgebeutet. Da ist ein Schutz zum Nachteil von Linux-BluRay-Besitzern nicht mehr nötig.

  2. Re: Secure Design...

    Autor: Wer anders 05.11.09 - 16:40

    Interessant. "Beweis" doch mal die Sicherheit von RSA, AES oder einem anderen aktuell eingesetzten Verschlüsselungsstandard bzw. einem darauf aufbauenden Protokoll. Oder zeig mir einfach einen solchen Beweis, der nicht irgendwo in der RSA-Annahme o.ä. mündet.

    Alternativ überleg mal, ob du nicht doch noch ein bisschen mehr in die Materie einsteigen willst, bevor du solche allgemeinen "Beweise" forderst. Weder AES noch RSA sind bewiesen sicher. Und auf solchen und ähnlichen (unbewiesenen) Verfahren bauen nunmal unsere heutigen Protokolle alle auf.

    Oh, und wenn dir beides nicht gefällt: Beschreib mal, wie du Onlinebanking mit dem beweisbar sicheren Vernam-System machst :-)

  3. Re: Secure Design...

    Autor: Bubu Joe 05.11.09 - 16:41

    Wieviele Softwareprodukte kennst Du denn, die einen solchen Beweis wie Du ihn da forderst nachgewiesen haben?

    Ich kenne keine einzige und würde mal munter davon ausgehen, dass es auch keine gibt. Computersicherheit ist kein Produkt, sie ist ein Prozess (Bruce Schneier, Counterpane). Ein Algorithmus, der heute als absolut sicher gilt kann in wenigen Tagen zur Lachnummer verkommen, wenn es jemanden gelingt eine Berechnungsvorschrift zur Problemlösung zu finden, die bisher noch keiner überlegt hat. Aber selbst ohne einen solchen Quantensprung, ist die zunehmende Rechengeschwindigkeit auch immer wieder Ursache dafür, dass sichere Verfahren als unsicher eingestuft werden müssen.
    Hier einen Beweis einzufordern ist die Forderung nach dem Unmöglichen und da ist noch nicht mal berücksichtigt, dass Fehler oftmals auch durch die Implementierung ihren Weg ins Produkt finden.

  4. Re: Secure Design...

    Autor: Siga9876 05.11.09 - 18:44

    Wer anders schrieb:
    --------------------------------------------------------------------------------
    > Interessant. "Beweis" doch mal die Sicherheit von RSA, AES oder einem
    > anderen aktuell eingesetzten Verschlüsselungsstandard bzw. einem darauf
    > aufbauenden Protokoll. Oder zeig mir einfach einen solchen Beweis, der
    > nicht irgendwo in der RSA-Annahme o.ä. mündet.

    Mir geht es nicht um die Verschlüsselung. Mir geht es um die Implementierung und ! um Protokolle. Und das man Protokolle beweisen kann, denke ich schon.

    Du hast bei AES usw. natürlich Recht, das diese soweit mir bekannt "Faktorisierung-ist-schwer" als Voraussetzung haben.
    Das ist natürlich auch ein Problem.
    Aber nur weil ein Loch im Reifen ist, lässt man das Auto nicht am Parkplatz mit offener Dach-Luke stehen weil zwei Löcher das Auto genau so unbenutzbar machen. Man holt einen Ersatzreifen und sichert vorher das Auto total.

    Protokolle haben sicher zu sein. Aus die Maus.
    Und Protokolle (nicht zu verwechseln mit Verschlüsselungs-Algorithmen wo jedes Jahr ein paar Bits abgeknapst werden) sind vermutlich beweisbar.
    Und die Implementierung hat auch beweisbar zu erfolgen.

    Ist ja auch peinlich, wenn man ein n^2-Problem hat, aber der eigene primitive Algorithmus n^3 oder 2^n als O()-Klasse hat.

    Bei Gesundheitsdaten und Onlinebanking gehts nicht um Peanuts. Vermutlich sind diese Spammer-Online-Casinos besser gesichert als Gesundheitskarte oder Onlinebanking wie wir bei OpenSSL heute gesehen haben.

    Oder verlangst Du, das man für die Allianz-Arena oder wo Du arbeitest keine Statik berechnen braucht, weil Godzilla oder Hurrican das Stadion oder deinen Arbeitsplatz eh plattmachen könnten ?

  5. Re: Secure Design...

    Autor: Siga9876 05.11.09 - 18:51

    Bubu Joe schrieb:
    --------------------------------------------------------------------------------
    > Wieviele Softwareprodukte kennst Du denn, die einen solchen Beweis wie Du
    > ihn da forderst nachgewiesen haben?

    Ein kleines Betriebssystem wurde neulich bewiesen. War bei golem Thema. Interessiert ausser mir natürlich kaum wen.
    Ich habe Informatik bei Mathematikern und nicht bei ProlloHohlProggern gelernt.

    Beweisbarkeit vieler Aspekte dürfte inzwischen möglich sein.
    Und das geilste: Wenn der Beweiser sich die Hucke wund arbeitet, kann man ja beweiserfreundlicher programmieren.
    Z.b. eine for-Schleife die drei Sachen macht oder drei for-Schleifen die jeweils eine Sache machen je nachdem wie vor/nachbedingungen leichter zu beweisen gehen.
    Hier gehts nicht darum, gewürfelten Code zu beweisen. Sondern !einfach! nur darum, etwas beweisbares zu programmieren weil der Auftraggeber (Bank, Öffentliche Verwaltung,...) einen Beweis für die Kern-Routinen will.

    Man kann Zahlen ohne Beleg in die Steuererklärung reinschreiben und sich mit Finanzamt herumärgern. Oder einfach Excel-Tabellen mit der offensichtlichen Kalkulierung von Einnahmen/Ausgaben mitschicken und denen bleibt dann meist wenig übrig.

    > da ist noch nicht mal berücksichtigt, dass Fehler oftmals auch durch die
    > Implementierung ihren Weg ins Produkt finden.
    Genau um sowas geht es mir auch.
    Das meinte ich mit "keine Optimierungen oder Änderungen die man selber ganz lustig findet".

    Und bei Protokollen kann man vermutlich beweisen. Siehe auch andere Antwort von mir.

  6. Re: Secure Design...

    Autor: Sinnfrei 05.11.09 - 19:02

    Sicherheit ist eine Illusion. Es gibt keine absolut sichere Software.

    Das Beispiel TLS/SSL beweist es ja nur zu gut - den Standard gibt es seit 1999 oder länger, und jetzt nach 10 Jahren und hundertausenden Anwendungen fällt noch ein kritischer Designfehler auf.

  7. Re: Secure Design...

    Autor: Lolmaster 05.11.09 - 19:41

    Siga9876 schrieb:
    --------------------------------------------------------------------------------
    > Ich habe Informatik bei Mathematikern und nicht bei ProlloHohlProggern


    Mathematiker können keine Informatik. ROFL!

  8. Re: Secure Design...

    Autor: Siga9876 05.11.09 - 19:50

    Lolmaster schrieb:
    --------------------------------------------------------------------------------
    > Siga9876 schrieb:

    > > Ich habe Informatik bei Mathematikern und nicht bei ProlloHohlProggern

    > Mathematiker können keine Informatik. ROFL!

    Mathematiker SIND Informatik.

    Und solche Sprüche beweisen nur, das alle Eure Daten bald jeder hat. Denn das Progger-Niveau ist blamabel.
    Progger-IQ ist eine Naturkonstante oder wächst bestenfalls logarithmisch. Progger-Anzahl wächst aber linear oder schneller (quadratisch, exponentiell,...) .
    Kurzum: Der Durchschnitts-Progger-IQ sinkt jedes Jahr.
    Statt IQ kann man alle anderen sinnvollen geistigen Skill-Metriken nutzen.

  9. Re: Secure Design...

    Autor: Lolmaster 05.11.09 - 20:05

    Siga9876 schrieb:
    --------------------------------------------------------------------------------
    > Lolmaster schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Siga9876 schrieb:
    >
    > > > Ich habe Informatik bei Mathematikern und nicht bei ProlloHohlProggern
    >
    > > Mathematiker können keine Informatik. ROFL!
    >
    > Mathematiker SIND Informatik.

    Sind sie ganz sicher nicht.

    > Und solche Sprüche beweisen nur, das alle Eure Daten bald jeder hat. Denn
    > das Progger-Niveau ist blamabel.

    Ich bin kein Progger.

  10. Re: Secure Design...

    Autor: Unbekannt 05.11.09 - 21:14

    Lolmaster schrieb:
    --------------------------------------------------------------------------------
    > Siga9876 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Lolmaster schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Siga9876 schrieb:
    > >
    > > > > Ich habe Informatik bei Mathematikern und nicht bei
    > ProlloHohlProggern
    > >
    > > > Mathematiker können keine Informatik. ROFL!
    > >
    > > Mathematiker SIND Informatik.
    >
    > Sind sie ganz sicher nicht.

    Dennoch besteht jedes Informatik-Studium zum Großteil aus Mathematik (und das zurecht).

  11. Re: Secure Design...

    Autor: redwolf_ 05.11.09 - 22:02

    Ich als Nicht-Fake-Pseudo-Möchtegern-Klappt-Doch-PHP-PseudoHohlProgger empfehle dir den kryptochef http://kryptochef.net/index.htm . Denn nur eine Vollbitverschlüsselung ist der Wahrheit.

  12. Re: Secure Design...

    Autor: _UPPERcase 05.11.09 - 22:04

    lernt man bei dem ganzen informatik/mathematik zahlengehoppse auch das menschen mit dem computer arbeiten die was anders zu tun haben als über begriffdefinitionen zu klugscheißen und eine andere arbeitsweise haben als evtl. angenommen ?

  13. Re: Secure Design...

    Autor: nf1n1ty 06.11.09 - 00:51

    redwolf_ schrieb:
    --------------------------------------------------------------------------------
    > Ich als Nicht-Fake-Pseudo-Möchtegern-Klappt-Doch-PHP-PseudoHohlProgger
    > empfehle dir den kryptochef kryptochef.net . Denn nur eine
    > Vollbitverschlüsselung ist der Wahrheit.

    YMMD

    ___________________________________________________________
    Wenn einer fuddelt, dann klatscht et. Echt jetzt Junge!

  14. Re: Secure Design...

    Autor: IhrName9999 06.11.09 - 14:01

    na DA hat jemand aber viel Fantasie ... naja, nach der Schule wirst du ganz schön staunen

  15. Re: Secure Design...

    Autor: IhrName9999 06.11.09 - 14:05

    > (durch verlustiges Re-Compressen)

    Ich hab den Text (gottseidank) nicht gelesen - und diese Worte bestätigen meine Vermutung.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. DLR Deutsches Zentrum für Luft- und Raumfahrt e.V., Oberpfaffenhofen
  2. Deutsches Krebsforschungszentrum (DKFZ), Heidelberg
  3. alanta health group GmbH, Hamburg
  4. DAN Produkte GmbH, Raum Schleswig-Holstein, Niedersachen, Hamburg, Bremen (Home-Office)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 399€ (Wert der Spiele rund 212€)
  2. 94,90€ + Versand mit Gutschein QVO20


Haben wir etwas übersehen?

E-Mail an news@golem.de


Openbook ausprobiert: Wie Facebook, nur anders
Openbook ausprobiert
Wie Facebook, nur anders

Seit gut drei Wochen ist das werbe- und trackingfreie soziale Netzwerk Openbook für die Kickstarter-Unterstützer online. Golem.de ist dabei - und freut sich über den angenehmen Umgangston und interessante neue Kontakte.
Ein Test von Tobias Költzsch

  1. Hack Verwaiste Twitter-Konten posten IS-Propaganda
  2. Openbook Open-Source-Alternative zu Facebook versucht es noch einmal
  3. Klage eingereicht Tinder-Mitgründer fordern Milliarden von Mutterkonzern

Batterieherstellung: Kampf um die Zelle
Batterieherstellung
Kampf um die Zelle

Die Fertigung von Batteriezellen ist Chemie und damit nicht die Kernkompetenz deutscher Autohersteller. Sie kaufen Zellen bei Zulieferern aus Asien. Das führt zu Abhängigkeiten, die man vermeiden möchte. Dank Fördergeldern soll in Europa eine Art "Batterie-Airbus" entstehen.
Eine Analyse von Dirk Kunde

  1. US CPSC HP muss in den USA nochmals fast 80.000 Akkus zurückrufen
  2. Erneuerbare Energien Shell übernimmt Heimakku-Hersteller Sonnen
  3. Elektromobilität Emmanuel Macron will europäische Akkuzellenfertigung fördern

Leistungsschutzrecht: Das Lügen geht weiter
Leistungsschutzrecht
Das Lügen geht weiter

Selbst nach der Abstimmung über die EU-Urheberrechtsreform gehen die "Lügen für das Leistungsschutzrecht" weiter. Auf dieser Basis darf die Regierung nicht final den Plänen zum Leistungsschutzrecht zustimmen.
Eine Analyse von Friedhelm Greis

  1. Urheberrechtsreform Was das Internet nicht vergessen sollte
  2. Urheberrecht Uploadfilter und Leistungsschutzrecht endgültig beschlossen
  3. Urheberrecht Merkel bekräftigt Zustimmung zu Uploadfiltern

  1. Lokaler Netzbetreiber: Inexio baut Glasfaser, auch wenn es sich nicht lohnt
    Lokaler Netzbetreiber
    Inexio baut Glasfaser, auch wenn es sich nicht lohnt

    Der Glasfaser-Ausbau bis an die Straßenecke kostet 2.000 Euro pro Kunde, bis ins Haus sind rund 5.000 Euro fällig. Dennoch setzt Inexio verstärkt auf FTTH, auch wenn sich dem Kunden dafür nicht viel mehr berechnen lässt.

  2. Volkswagen: 5G bietet flexible Software-Betankung in der Produktion
    Volkswagen
    5G bietet flexible Software-Betankung in der Produktion

    Volkswagen will mit 5G in der Produktion flexibel große Datenmenge in die Fahrzeuge einspielen. Campusnetze könnten auch zusammen mit Netzbetreibern laufen.

  3. Amazon vs. Google: Youtube kommt auf Fire TV, Prime Video auf Chromecast
    Amazon vs. Google
    Youtube kommt auf Fire TV, Prime Video auf Chromecast

    Fire-TV-Geräte erhalten erstmals eine offizielle Youtube-App von Google. Dafür integriert Amazon eine Chromecast-Unterstützung in die Prime-Video-App. Andere Streitpunkte zwischen Amazon und Google bleiben hingegen bestehen.


  1. 19:10

  2. 18:20

  3. 17:59

  4. 16:31

  5. 15:32

  6. 14:56

  7. 14:41

  8. 13:20