[linux-l] GPLv3 erschienen

Steffen Dettmer steffen at dett.de
Di Jul 24 00:02:51 CEST 2007


* Steffen Schulz wrote on Mon, Jul 23, 2007 at 00:16 +0200:
> On 070722 at 23:20, Steffen Dettmer wrote:
> > * Steffen Schulz wrote on Sun, Jul 22, 2007 at 17:17 +0200:
> > > Was man machen kann ist, dass der Anwender 3 rote Knoepfe druecken muss
> > > bevor nicht zertifizierte Software erlaubt wird. Wenn nun ein Trojaner
> > > ein DoS macht und regelmaessig zeigt, dass man doch bitte seinen
> > > Kartenleser updaten soll, dann werden die Leute aber genau das tun.
> > Es geht ja sogar ohne die roten Knoepfe, wenn man nicht
> > zertifizierte Software automatisch laden kann: man flasht die Firmware
> > einfach um; die neue Version bucht halt auf ein neues Konto oder so. 
> > Dabei wird erst der PC gehakt, damit man z.B. Eingaben vom "PC
> > Keyboard" emuliert oder was auch immer man braucht.
> 
> Die roten Knopfe am Klasse-3-Geraet sollten halt einen erweiterter
> Schutz gegenueber kompromittierten PCs darstellen. Wuerden halt
> immernoch problemlos Leute drauf reinfallen, reicht also nicht.

Ja, genau. Vertrauen zu Software traut man nur Sicherheitsbeauftragten
zu und das vier-Augen-Prinzip muss gewahrt sein; finde ich gut. Die in
Deutschland üblichen hohen Sicherheitsanforderungen bleiben hoffentlich
auch in einer SSL und cacert.org Zukunft bestehen ;)

> > > Sicher fallen anteilsmaessig nicht viele darauf rein, aber das Argument
> > > hilft bei Spam und Phishing auch nicht..
> > Das Problem hier wäre doch aber, besonders wenn man noch digitale
> > Unterschrift mit reinnimmt: es würde sich sehr lohnen! Die Auswirkungen
> > sind schon krass, wenn man mal darüber nachdenkt. Meiner Meinung nach
> > übrigens so krass, dass ich gar keine Digitale Unterschrift möglich
> > haben möchte, weil ich selbst einem Gerät, was nur signierten Code
> > ausführt, nicht genug traue!
> 
> Auch weil man bei IT immer mit der totalen Unwissenheit seitens dem
> Richter rechnen muss. Unterschriften kann man faelschen, aber so'ne
> Signatur...ist doch mit Krypto, das ist doch sicher...

jajaja, genau! 

Das ist sogar wirklich üblich. Wie bei elektronic cash damals: 
Richter an Gutachter: "Kann man die PIN erraten?"
Gutachter: "Nein, die Chance wäre sehr gering" [ca. 0.3 - 1% oder so].
Richter: "Kann man die PIN ableiten?"
Gutachter: "Nein, das wird nicht mehr gemacht."
Richter: "Also muss die PIN vermerkt gewesen sein, Schuldig"

Da kenn ich persönlich Betroffene (kam da gar nicht erst zur
Verhandlung).

Später wurde dann bekannt, dass man einfach eine Minikamera an
Geldautomaten kleben kann oder sich hinter den Karteninhaber stellt,
während dieser vom PIN Dialog abgelenkt ist, usw.

> > > Man koennte die Geraete ja mit Sollbruchstelle verkaufen, die bei der
> > > Inbetriebnahme(oder schon im Handel) mit Hinweis auf die Konsequenzen
> > > kaputt gemacht werden soll. Bei Update dann Hardwareaustausch oder so.
> > 
> > Super Idee! Übrigens so gut, dass man es tatsächlich macht! [1]
> 
> Naja fast. :)
> 
> Tamper evident ist mir wenigstens theoretisch bekannt, ich meinte hier
> aber noch was anderes. Wenn die Geraete laut Lizenz Updates erlauben
> muessen, es aber aus Sicherheitsgruenden fuer Hinz und Kunz nachhaltig
> deaktiviert sein soll, koennte man halt ne 'Sollbruchstelle' einfuegen.

Updates muss man erlauben, weil man sonst im Falle eines blöden
Softwarebugs u.U. massig Geräte tauschen müsste, das ist dermassen
teuer, das geht einfach absolut nicht. 

Das kann man nichtmal durch Mega-Testen ausschliessen, weil sich die
Karten ändern, nicht alle bekannt sind und schon gar nicht für Tests zu
Verfügung stehen können. Produktive Tests werden "mit echtem Geld"
gemacht, wie auch sonst, dass muss dann zurücküberwiesen werden und so
(bzw. verrechnet werden), da kann man sich auch nicht beliebig austoben.

Mit 'Sollbruchstelle' wäre aber doch die GPLv3 verletzt, weil:

   "The information must suffice to ensure that the continued
    functioning of the modified object code is in no case prevented or
    interfered with solely because modification has been made."

   "Access to a network may be denied when the modification itself
    materially and adversely affects the operation of the network or
    violates the rules and protocols for communication across the
    network."

   [letzeres verstehe ich als: "... may be denied if and only if ..."]

Sollbruchstelle würde ja das Weiterfunktionieren des modifizierten
Objekt-Codes verhindern "aus dem einzigen Grunde, weil Modifikationen
vorgenommen worden sind" [aus http://www.gnu.de/documents/gpl.de.html].

> Klasse waer natuerlich, wenn man davon unabhaengig jederzeit pruefen
> kann ob gerade zertifizierte Software geladen ist. 

Zunächst gilt, dass man der Software nur trauen kann, solange nie
nicht-zertifizierte geladen war. Sonst könnte nicht-zertifizierte
"simulieren", sie wäre zertifizierte! Das bindet man z.B. an einen
geheimen Schlüssel, der unwiederbringlich gelöscht wird (d.h., er wird
mit Zufallszahlen überschrieben, "nullen" wäre ja fatal, weil dann wäre
der geheime Schlüssel ja bekannt!). Das wäre so eine Sollbruchstelle.
Wenn man danach zertifizierte Software lädt, könnte eine
nicht-zertifizierte Software ein erfolgreiches Laden simulieren und
für den Prüfenden "zertifiziert aussehen". Würde man den Schlüssel
wieder laden, könnte die nicht-zertifizierte Software diesen ja
missbrauchen. Nun könnte man das verhindern wollen, in dem man
entsprechende Hardware nimmt. Funktioniert aber (logisch/theoretisch)
auch nicht, weil die "vorrübergehend" geladene Software notfalls eine
Art virtuelle Maschine für die eigentliche Software schaffen könnte.
Kann man natürlich theoretisch auch wieder messen (z.B.
Antwortzeitverhalten oder so), aber natürlich kann man im Vorfeld rein
praktisch nicht gegen alle Stealth-Techniken vorgehen (Viren
demonstrieren das ja :-)).

> > oder einfach 100 mal schnell an- und ausschalten
> 
> Die Variante ist bestimmt prickelnd..  :)

:) 

   (Wenn ich ehrlich bin, muss ich gestehen, dass ich nicht verstanden
    hab, wie dieser Angriff funktioniert. Muss was statistisches sein.)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l