[linux-l] Slightly off topic: Jagd auf Spam

[Steffen Dettmer]

* Jan Krueger wrote on Sun, Oct 26, 2003 at 23:32 +0100:
> On Sunday 26 October 2003 21:38, Steffen Dettmer wrote:
> > Leider kommen vermutlich nur 10% der Anwender und 1% der
> > Entscheidungsträger ebenfalls zu dieser Erkenntnis...
> Wie ich im anderen Thread auch zu zeigen versuche bin ich der
> Auffassung, daß es nicht an den Anwendern liegt, IMHO.

Aha. Ich bin der Meinung, daß es an den Kunden liegt. Die geben
Geld für Mist, also kriegen sie Mist. Geiz ist geil und ich bin
doch nicht blöd - Qualität würde man anders vermarkten ;)

> > Das ist ja blöd - dann kann man ja weder Programme nachladen oder
> > entladen und braucht so unheimlich viel Speicher. Gut, kenne das
> > vom Embedded-Bereich, aber für'n PC? Muß man dann bei Booten X,
> > StarOffice und alle Mailprogramme schon mal laden...

> Dabei dachte ich mehr an Server, also an Rechner die
> wohldefinierte Dienste über einen langen Zeitraum
> bereitstellen. bei einem Wuser Desktop ist das quatsch, klar.

Ja, aber ein gutes Konzept müßte auch bei anderen funktionieren
oder bei Serverside-Office :-)

> > Der Anwender muß dann prüfen (wie?!), ob es das richtige Programm
> > ist (secure hash?) - sonst könnte sich ja ein Trojaner über das
> > Mailprogramm mitladen.
> Im Falle eines OS/Anwendung könnte der Hersteller zum Beispiel
> eine Smartcard mitliefern auf welcher die entsprechenden secure
> hashes oder so bereits gespeichert sind, diese könnten dann von
> der Hardware irgendwie verglichen werden woraufhin das Laden
> des Codes freigegeben wird oder auch nicht.

Ja, kann der Klasse-3 Leser dann machen, klar. Aber wie
installiert man sich dann ein eigenes Programm? Oder lebt man
damit, daß es einfach nicht geht? Dann kann man ja ne X-Box
kaufen - da ist auch egal, wenn die gehackt wird, oder? :)

> > Dann geht dynmisches Binden gar nicht mehr...
> Jupp. Hat man gleich ein weiteres Problem, das mit den
> ständigen core-dumps wegen falscher Library Versionen, mit
> gelöst ;) Nachteil beim statischen binden wäre, daß so ein KDE
> binary richtig groß werden kann, also _richtig_ groß, und wen
> man dann mehrere davon hat ...

Jo, X wären 300-400 MB z.B. Und alles was mit K anfängt schnappt
sich vermutlich auch erstmal pauschal > 100 MB. Ich glaub, damit
kann man nicht mehr leben.

> Es gibt Architekturen, welche auf einen Stack im Speicher ganz
> verzichten und dafür irgendwelche Register-Sachen verwenden,
> oder mehrere Counter oder so.  Keine Ahnung, hab ich vergessen
> wie das funtkioniert.

mmm... Hab keine Idee, wie das gehen könnte.

[Flash]
> > Wird langsam, oder?
> Also mein PocketPC ist bei der Ausführung des Codes aus dem Flash-Rom heraus 
> nicht wirklich langsam, nur ist ARM halt direkt für sowas designed und bewegt 
> sich auch noch weit jenseits der Gigahertz-Grenze. Ich denke man könnte das 
> technisch irgendwie lösen.

Ja, per MMU z.B.

> > Na ja, dann mußte ja eben auf dem Klasse-3 Leser die Prüfsumme
> > anzeigen, der Benutzer muß die in einer Liste der vertrauten
> > Anwendungen nachsehen, um zu erkennen, ob jemand versucht,
> > manipulierten Code zu laden. Du hast aber Recht, selbst wenn man
> > das nicht macht, funktionieren gegenwärtige Cracks nicht mehr
> > gut (glaub ich) - wenn es aber alle "haben" gibt's dann auch
> > Cracks dafür :)

> Weiß nicht, kann schon sein. Ist aber per gesetz verboten, hier
> oder da hinterm großen Teich, was aber die auf Pazifik-Insel X
> nicht interessiert...

Verboten? Ist Cracken nicht sowieso verboten?

> > Sowieso, oder? :)
> Klar, 64bit Adressraum ist schon wieder fast Vergangenheit :)

Man, wie hier mit Zahlen geschmissen wird :) Fänd 36 Bit schon
mal nicht schlecht. Und dann kann man auch auch anfangen,
Speicher in 1KB Blöcke zu clustern :)

> > Es gibt solche Architekturen. Mit einer gut implementierten JVM
> > z.B. sollte das schon nicht mehr gehen.
> Daran glaub ich nicht so richtig, so lange die gut implementierte JVM in C(++) 
> geschrieben ist und wegen Java an sich.

Klar, Du hast Recht - aber Gleiches gilt für die Implementierung
Deiner Variante "neue Architektur"...

> > TCPA (oder wie das heißt) ist sogar mehr: der Code muß signiert
> > sein, so daß man nicht alle Prüfsummen kennen muß - man kann dann
> > ausrechnen, ob die stimmen. Für Hardware-Sicherheitsmodule eine
> > gängige Praxis mindestens beim Update: lade nur signierten Code.

> Nach dem der Code geladen ist tut TCPA ja nix mehr zur Sache,
> oder? und falls der Code nicht geschützt ist, freie Bahn BOFs.

Na, wir haben doch die schlaue MMU mit read-only-code. Nein, zur
Laufzeit Hashes nachzurechnen wird bestimmt teuer...

> Das bringt mich zu einer weiteren Verfeinerung: Code ist
> verschlüsselt im Speicher. 

oki, reicht 3-DES im CBC mode?

Mal überlegen. Du hast ein Programm. Der Einfachheit halber haben
wir nur 4 Byte Instruktionen. Nehmen wir ein 2 Instruktionscache
an.

Also, decrypt block, 2 Instruktions geladen. Ausführung,
Ausführung. decrypt block, 2 Instruktionen geladen. Nu sei eine
davon ein Sprung auf plus 48 byte. Also decrypt block, decrypt
block, decrypt block, 2 Instruktions geladen (man kann beim
Entschlüsseln ja nicht beliebig springen, vielleicht kann man
sich auf ein 2KB block clustering einigen, aber nicht-zyklisch
geht wohl kaum noch).  Rückwärtsspringen führt dazu, daß man den
gesammten 2KB Block neu rechnen muß, bis zum Sprungziel. 

Vielleicht reicht ein XOR mit einer 4 Byte Zufallszahl hier. Viel
einfacher und schon recht sicher bei Änderung tötlich. Gut,
Schade das man das nicht so einfach sauber abfangen kann, aber
Crash ist ja besser als Crack.

> Eine Kompromittierung des Verschlüsselten Codes durch Daten
> führt dann unweigerlich zu Code Müll und kann erkannt werden.
> Das wiederum setzt vorraus, daß das Key Management und das
> ganze drumherum irgendwie mit in die CPU müssen. Ah, da gibt es
> ja Ansätze in Form von zb. VIA C3 PadLock welche allerdings
> eine DataEncryption Egnine ist, also noch weit entfernt vom
> Code.

Wenn man verschlüsseln muß (also ne Verschleierung a la XOR nicht
ausreicht), wird es sofort teuer. Das ist langsam, aufwendig,
braucht intern ganze Registersätze... Die Operation selbst muß
man natürlich in Hardware gießen, ist damit leider auch nicht
updatebar. Na ja.

> Müßte man eben mal kurz die Spezifikation lesen _und_ verstehen
> können... ich laß das lieber :)

Vermutlich schützt das vor Angriffen von außen.

> > Du kannst sowas auch einkaufen, gibt's ja.
> Wenn das weiter so geht werde ich durch die nicht gemachten BeLUG Patent 
> Lizenzeinnahmen ja nie reich, dick, von Models umgarnt und Palmwedeln 
> umwedelt, ...
> "James, bitte fahr schon mal den RollsRoyce vor ... Ach nein,
> doch lieber den F40" ...

:) Schade eigentlich, vom Palmwedelplatz am Pool in einen F40 zu
fallen, den der Hauptbutler gerade vorgefahren (vor den Pool
versteht sich) hat, wäre schon nett :)

> > Wird vermutlich teuer
> Egal, so lange teuere Militär-Technik gebaut wird um zu Staub
> zerballert zu werden gibts sicherlich einen der genau das
> glaubt zu brauchen und teuer geld dafür bezahlen möchte.

Militär-Technik wird man vermutlich nicht so billig angreifen
können. Da gibt's dann auch mal ein Adaprogramm (die haben das
schließlich bezahlt :)).

> Dann verzichte ich auf reich, dick, Palmwedel, Autos, behalte
> die Models und verwickle sie in langwierige intellektuelle
> Gespräche :)

Yo, auf sicherheitstheoretische Diskussionen fahren die bestimmt
total ab :-)

oki,

Steffen

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