Re: [FYI] "Trusted Computing' Frequently Asked Questions" by Ross

[Peter Ross <Peter.Ross@alumni.tu-berlin.de>]

Hi,

danke Lutz fuer das Szenario. Ich glaube Dir gern, dass Du nicht
unbedingt "TCPA-Fan" bist..

Sehe ich es richtig, dass das Operating System des Rechners, um Auswege
wie Drucken oder Auslesen des Bildschirmspeichers oder was immer zu
unterbinden, das Hostbetriebssystem des Rechners sein muss, so dass nicht
TCPA-Anwendungen oder -Betriebssysteme lediglich in einer Emulation wie
VMWare ablaufen koennen?

Andreas Jellinghaus schrieb:
> Nun, einen Rechner auszuliefern auf dem die Software nicht veraendert
> werden kann, das ist auch heute schon moeglich. Wird das heute schon
> gemacht, und warum wird gewartet, bis TCPA verfuegbar ist? Ist
> der vorteil von TCPA in punkto Sicherheit notwendig?

Ich "liefere" seit geraumerzeit Rechner aus, auf dem Software nicht
veraendert werden kann. Es handelt sich hierbei um Server in
firmenkritischen Umgebungen, die mehr oder minder "Ein-Zweck-Maschinen"
sind.

Wenn DRM mittels TCPA erfolgreich sein soll, dann muss zwingend dieses
Feature beim Endanwender zuhause vorhanden sein. Das ist schon eine
Restriktion, die den Personal Computer, der ja unter anderem so attraktiv
im Heimbereich ist, weil er durch Hard- und Software erweiterbar ist,
erheblich veraendern wuerde.

Ich predige seit Jahr und Tag, dass Personal Computer & Heim-OS im
Firmenumkreis der falsche Ansatz sind, vergleichbar einem Versuch, eine
Spedition mit Personenkraftfahrzeugen zu betreiben.

Hier ist es fuer mich sehr von Vorteil, wenn das System nicht taeglich den
Installationsversuchen von Mohrhuhnanwendern ausgesetzt ist.

Tausende von Admins sind weltweit dabei, so etwas zu unterbinden und zu
kontrollieren, weil ueberall eine Hard- und Software im Einsatz ist, die
nicht fuer den Firmeneinsatz geschaffen wurde.

Ein im Einsatz befindliches Szenario mit IPSec und Radius etc. zur
Sicherung einer WLAN-Umgebung an einer Uni ist uebrigens in einer der
letzten Ausgaben des Magazns SysAdmin beschrieben. Dort ist auch
begruendet, warum es nett waere, wenn man MAC-Adressen nicht aendern
koennte.

Nichtsdestotrotz kann uebrigens eine geschlossene Liste gueltiger
MAC-Adressen zur Erhoehung der Sicherheit genauso sinnvoll sein wie die
(ebenfalls nicht faelschungssicheren) ISDN-Nummern eines Einwahlservers:
in beiden Faellen muss ich erst einmal wissen, welche MAC-Adresse oder
ISDN-Nummer gueltig ist, und es verhindert Eindringen schon in einem
fruehen Stadium, bevor ueberhaupt eine IP-Verbindung steht.

In beiden Fallen (MAC oder ISDN) ist es aber sicher keine gute Idee, das
als einzige Sicherheitshuerde fuer Eindringlinge zu haben.

> Wer ein Scenario vertritt, der muss es begruenden koennen.

Ich denke, ich habe meine Szenarien in nachvollziehbaren Gedankengaengen
begruendet, da ich aber, wie ich eingangs geschrieben habe, nicht
allumfassend ueber TCPA informiert bin, sind doch Zweifel angebracht,
laden meine Szenarien zum Bestaetigen, Widerreden und Weiterentwickeln
ein.

Das Zweifeln ist eine menschliche Eigenschaft. Sie gehoert zumindest zu
mir, da ich mit knapp zwanzig Jahren I.T-Erfahrung immer noch eine "etwas
begrenzte Sicht" habe. Deshalb unter anderem unterhalte ich mich mit
Freunden und Bekannten, lese Mailinglisten, schreibe auch gelegentlich, um
meine Sicht etwas zu erweitern.

Ich bitte Dich, mit Deinen Diskussionspartnern respektvoll umzugehen.

Ich gehoere sonst zumeist eher in die Kategorie "Verweigerer", ich ziehe
mich zurueck. Mir kommt es wenig darauf an, Recht zu haben. Genauso wenig
Interesse habe ich, irgendwem mit meinen Geldausgaben zu schaden. ich
moechte das Geld, was ich verdiene, zu meiner Freude ausgeben, nicht um
EMI oder was weiss ich wem zu schaden. Entschuldigung, bin in einer
Gesellschaft aufgewachsen, wo Konsumieren nicht erste staatsbuergerliche
Pflicht ist..

> > IPSec bietet schlicht einen Layer2 Link.
> Ist zum Beispiel falsch.

Wenn es Dir wichtig ist: Welche Layer 2 meinst Du eigentlich? Schon TCP/IP
und OSI unterscheiden da, und es ist nicht unueblich, das OSI-Modell auf
TCP/IP abzubilden.

Keine der Definitionen aber sagt etwas ueber Interfaces, das ist
Sache einer Implementierung. Bei IPSec unterscheiden sich schon *BSD- und
FreeSWAN da ganz kraeftig. Ich glaube, im RFC ueber den IP-Transport
mittels Brieftauben kommt das Wort "Interface" nicht vor (bin mir aber
auch nicht sicher, habe aber auch den RFC nicht zur Hand. Ist aber unter
www.ietf.org zu finden)

Nach OSI ist (aus dem Gedaechtnis geschrieben, da ich ein paar Buecher
nicht mehr besitze - "Umzugsschaden" - z.B. Santifaller "TCP/IP und NFS",
hier findest Du es mit Sicherheit) Layer 1 die physikalische Schicht,
Layer 2 die Sicherungsschicht (z.B die Kollisionserkennung und
Uebertragungwiederholung des Ethernet-Protokolls), Layer 3 Verbindung
(z.B. IP)..

Ich mache mir mal die Muehe, Dir zwei Stichpunkte aus W. Richard Stevens
"TCP/IP Illustrated", Vol.1, Introduction, page 2 abzuschreiben:

"1. The link layer, sometimes called the data-link layer or network
interface, normally includes the device driver in the operating system and
the corresponding network interface card in the computer. Together they
handle all the hardware details of physically interfacing with the cable
(or whatever type of media is being used).

2. The network layer (sometimes called the internet layer) handles the
movement of packets around the network. Routing of packets, for example,
takes place here. IP, ICMP and IGMP provide the network layer in the
TCP/IP protocol suite."

Sorry, die Linux-2.6-IPSec-Implementierung kenne ich noch nicht. Nach
vollstaendig umgekrempelten Netzwerkcode in 2.0, 2.2 und 2.4 bin ich ein
bisschen muede, mich auf das naechste Abentheuer mit Linux im Netzwerk
einzulassen. Ich ahne aber, dass ich es werde tun muessen..

Es gruesst
Peter

--
To unsubscribe, e-mail: debate-unsubscribe@lists.fitug.de
For additional commands, e-mail: debate-help@lists.fitug.de