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
