Dietz schrieb: > Gerade eben nicht. Ich muß bei Verisign kein Zertifikat kaufen und die > Webbrowser welche ich verwende enthalten Mechanismen, alle mitgelieferten > CA-Keys abzuschalten. So wie ich das verstanden habe sind bei den derzeitigen > Plänen eben Keys "fest" und unabschaltbar eingebaut.
Dann hast du das falsch verstanden. Stichwort TCPA im Bios abschalten, stichwort TPM resetten (so das auch die Keys neu erzeugt werden), und so weiter. Nachzulesen: in der Spec. (oops. jetzt müsste ich zitieren, wo genau. bin zu faul :-) > > bei tcpa gibts genau eine zertifikatkette, und die attestiert > > das ein rechner wirklich gebaut wurde, und nicht nur eine > > simulation ist. diese kette geht von der TCPA über den hersteller > > Diese Kette dient welchem Ziel? Na steht da doch: "das ein Rechner wirklich gebaut wurde, und nicht nur eine simulation ist". > > bis zu deinem rechner. wenn es dir nicht gefällt: schlüsselpaar > > löschen und neu erzeugen. > > Und genau das geht eben soweit ich weiß nicht. na genaues steht irgendwo in der spec. evtl. war es einer der teile, die vom hersteller einstellbar sind. aber selbst wenn nicht: was stört es? hier ist wozu der schlüssel benutzt wird (und darüber wie hersteller das vermutlich managen steht auch was drinn): www.inet-one.com/cypherpunks/dir.2002.07.29-2002.08.04/msg00289.html ich muss also zugeben, das es evtl. rechner geben wird, die nicht neu initialisierbar sind. Welche auswirkungen wird das haben? was ist daran schlecht? (ja, ich sollte in der spec nachlesen, ob das wirklich so ist. sorry, zu faul. daher gebe ich es einfach mal so zu.) > > die tpm gibt den secret key nicht raus. gemein aber auch. > > Nein. Daß sie ihn nicht herausgeben ist vollständig in Ordnung. Daß sie sein > Gegenpart fest in meine Maschine einbauen wo er keinem von mir verlangten > Zweck dient ist genau der Punkt. welches gegenpart? da ist nur ein schlüsselpaar, und das wird in deinem rechner erzeugt. nagut, es wird einmalig zertifiziert, und das zertifikat wird mit in die TPM gelegt. was ist daran schlimm? Du musst den schlüssel ja nicht nutzen. > Abgesehen davon, ja, genau solche Mechanismen haben eben auch Weiterungen > welche mir ganz und garnicht zusagen. Ich möchte z.B. ein ebook auf einer von > *mir* gewählten Plattform lesen. Ich möchte in der Lage sein, mit *mir* > genehmer Software Musik abzuspielen und zu vervielfältigen. Ich möchte, last > not least, problemlos den Datenbestand auf Maschine A nach Maschine B > übernehmen können, auch wenn Maschine A gerade verstorben ist.. wie kommst du darauf, das TCPA mit diesen sachen was zu tun hat? erste lektion: kauf dir keine sachen mit seltsamen verträgen. CDs kann man kaufen, runde scheiben die nur manchnal musik machen lässt man liegen. Bücher kann man kaufen, PDF files ohne DRM sind auch ok, aber wenn schon im vertrag eingeschränkt wird, an welchen rechnern du ein ebook lesen darfst: lass es sein. ebooks gibts schon heute. runde kopierdingens auch. was ändert TCPA daran? aber tcpa ist eindeutig: hast du heute sound files und software dafür, so kannst du das dein leben lang geniessen. zumindest wenn du keines der beiden löschst, und solange du einen rechner mit OS hast der mit beidem zurechtkommt. Microsoft plant keine änderungen, die probleme machen könnten (naja, wobei ich nicht weis was mit software ist, die auf soundblaster ports alla dos zugreift. wenn der support dafür mal stirbt, das könnte ich verstehen). und last, but not least: speicher halt keine daten im "diese daten wird nur die hardware/software combo a-b-c-d-e lesen können" format ab. Es zwingt dich ja niemand, das zu tun (ausser irgendwelcher video on demand software, die willst du aber eh nicht, also was soll es). Aber die gute nachricht ist: falls du den fehler machst, dann mach erstmal regelmässig backups, auch vom TPM speicher. Und wenn der rechner den geist auf gibt: wende dich an den hersteller, damit du das TPM backup von rechner A auf rechner B einspielen darfst. wenn der dir hilft: klappt doch. <side note> Alle befürchtungen die NSA könnte hintertüren in die TPM einbauen halte ich übrigens deshalb für eher langweilig: ob ein hersteller der NSA wohl helfen wird, ein backup deines rechners in einen anderen rechner zurückzuspielen? :-) </side note> Und natürlich nochmal der hinweis: schalten TCPA im bios ab oder kauf einen rechner ohne. Irgendwo muss man doch auch mal selbst verantwortlich handeln. wenn jemand etwas verschlüsselt, aber schlüssel oder passwort verliert, dann ist man doch selbst schuld. wer software nutzt um daten verschlüsselt mit TCPA methode abzuspeichern, so das eine andere software-hardware combo das nicht lesen kann, und dann software oder hardware ändert - na, fällt sowas nicht unter um probleme betteln? > Weil "neu" durchaus nicht zwingend mit "gut" oder "wünschenswert" > gleichzusetzen ist? *moep* Ich sage ja nur, das "neu" (gemeint ist TCPA) nicht per se schlecht ist, sondern wenn das so sein soll, es auch sauber begründet werden muss. Ich werfe also den TCPA gegnern das fehlen einer sauberen begründung vor. Mich deswegen zum TPCA befürworter machen zu wollen, das halte ich für sehr gewagt. "ich möchte mir *mir* genehmer software musik abspielen" drückt bestenfalls deine angst aus, es könnte anders werden. hmm. angst. wie fear. fügen wir noch uncertanity und doubt hinzu, und wir haben: fud. und genau das werfe ich c't, ccc, anderson und green vor, das verbreiten die, und nicht zu knapp. dein obiger satz ist übrigens viel zu ungenau, um ihn ernsthaft zu diskutieren. willst du mit vi musik abspielen? natürlich nicht. es muss schon etwas präziser sein, damit man sich mit deinen befürchtungen überhaupt beschäftigen kann. und du musst begründen, warum du sowas befürtchtest. sonst kann ich ja lediglich lapidar antworten "es gibt keinen grund das zu befürchten", und wir sind keinen schritt weiter. > Wie lange wird es Deiner Meinung nach dauern bis bei breiter Verfügbarkeit > nicht-trivial umgehbaren DRMs die Rechte-"inhaber" die Bereitstellung > nicht-drmkonformer Abspielgeräte/-programme gerichtlich zu verbieten > versuchen z.B.? hey! das thema hatten wir doch schon mal, oder? Meine meinung brauche ich dazu gar nicht anbringen, ich zitiere einfach mal jemand, der sich dazu schon vor einem jahr geäussert hat: www.inet-one.com/cypherpunks/dir.2002.07.15-2002.07.21/msg00083.html - Legislating DRM would be extremely expensive in the current environment as it would require phasing out all computers presently in use. This provides a huge practical burden and barrier for any legislation along these lines. ... (habs ja schon mal gepasted in der heutigen diskussion, will die ML dazu nicht weiter belasten). Da beim punkte gesetz und DRM erzwingen der CBDTPA gerne erwähnt wird, will ich lieber dazu auch noch was zitieren: www.inet-one.com/cypherpunks/dir.2002.07.15-2002.07.21/msg00225.html The CBDTPA, available in text form at http://www.politechbot.com/docs/cbdtpa/hollings.s2048.032102.html does not explicitly call for legislating DRM. In fact the bill is not very clear about what exactly it does require. Generally it calls for standards that satisfy subsections (d) and (e) of section 3. But (d) is just a list of generic good features: "(A) reliable; (B) renewable; (C) resistant to attack; (D) readily implemented; (E) modular; (F) applicable in multiple technology platforms; (G) extensible; (H) upgradable; (I) not cost prohibitive; and (2) any software portion of such standards is based on open source code." There's nothing in there about DRM or the analog hole specifically. In fact the only phrase in this list which would not be applicable to any generic software project is "resistant to attack". And (e) (misprinted as (c) in the document) is a consumer protection provision, calling for support of fair use and home taping of over the air broadcasts. Neither (d) nor (e) describes what exactly the CBDTPA is supposed to do. ... (nur mal zum widerholen: die urls sind leider nicht mehr im netz, aber es gibt ja noch mehr archive von cypherpunks, und ich verschicke auch gerne ein tar mit meinem "wget" archiv.) > Read my lips. Bitte. Das Problem ist die oben von > DIr erwähnte Vorbelegung! das wort "absegnen" hat Heiko Recktenwald ins spiel gebracht, nicht ich. Warum verwendest du es, wenn du mir dann nicht sagen kannst, was du damit meinst? Ich habe ja versucht zu erraten, was du meinst, und dazu was geschrieben, aber wenn das daneben geraten war, dann wäre eine klarere formulierung angebracht. weiter bemühe ich mich um leicht verständliche beispiele. der pseudo videokarten treiber fürs video grabben sollte ein solches sein. videoverleihe die tcpa nutzen könnten das dafür nutzen, das sowas erkannt und der film dann nicht ausgeliefert wird. es ist ein beispiel, keine anschuldigung, vorwurf oder unterstellung. falls das falsch verstanden wurde, so tut es mir leid. und ein erneutes lesen meines postings zeigt eigentlich auch keine zweideutige formulierung. ich will mich ja gerne mit "oben geschilderten dingen" befassen, allein mir fehlt eine klare aussage, um was es dir geht. ja, ich weis, es ist recht lächerlich wenn zwei seite sich gegenseitig vorwerfen, sie würden zu schwammig formulieren. also bitte ich dich für mich nochmal langsam und ausführlich zu formulieren, worum es dir geht, und ich werde auch gerne jeden meiner text überarbeiten und unklarheiten beseitigen. > Und für die Dinge welche ich an TCPA interessant finde > benötigt man keine vorgegebene Zertifikatkette. na, ich will nochmal ein paar infos beitragen. www.inet-one.com/cypherpunks/dir.2002.08.05-2002.08.11/msg00006.html erklärt lange und ausführlich was PRIVKEY / Endorsement key ist und wie das verwendet wird. ganz am ende steht noch ein Satz, der meine abneigung gegen das TCPA faq gut zusammenfasst: Maybe someone could ask Ross why his FAQ blames TCPA for a feature that he admits isn't really related! aber zurück zu deinem statement: "welche ich an TCPA interessant finde". Nun, wenn ich an einem Auto nur den sound interessant finde, dann kann man das auto natürlich massiv umbauen, und den sound dabei erhalten. vielleicht fährt es dann nicht mehr, aber das feature das ich will ist weiter da. macht keinen sinn? also fragen wir doch mal, wozu TCPA eigentlich da ist (nicht was wir persönlich interessant finden, sondern ganz allgemein), und dann können wir schauen ob wir das ziel auch anders erreichen können: www.inet-one.com/cypherpunks/dir.2002.08.05-2002.08.11/msg00147.html I'd like the Palladium/TCPA critics to offer an alternative proposal for achieving the following technical goal: Allow computers separated on the internet to cooperate and share data and computations such that no one can get access to the data outside the limitations and rules imposed by the applications. ... viele weitere kommentare, wie genau und was, aber eigentlich reicht der eine absatz. es gab unmengen an antworten zu der aufforderung, ich habe sie heute morgen nochmal durchgeschaut und nicht eine sinnvolle alternative zu TCPA darin entdeckt. bin schon auf die antworten hier sehr gespannt. Ja, eine andere, aber verwandte, frage ist: soll sowas möglich sein. Ich habe den eindruck, das alle eigentlich nur über diese frage diskutieren, und nicht über tpca, Pd oder NGSCB. Und wenn man ganz gemein ist, kann man fragen: wenn etwas technisch machbar ist, hat es sinn das verbieten zu wollen, oder sollte man nicht lieber gleich zum thema regulieren übergehen? <my opinion> DRM gibts schon, X-Box (also rechner der nur bestimmte sachen abspielt) auch, DRM in eBook readern, mp3 playern, video on demand, und spezielle sachen in bank automaten. TCPA, Pd und NGSCB sind einfach die nächsten schritte, alle auch recht natürlich, und die verhindern macht keinen Sinn. Regulieren viel mehr. Leider haben da erstmal "die Bösen" momentan die Oberhand: DMCA und neues urheberrecht. Den spiess kann man aber auch umdrehen: fordern das jeder technischer apparat gewisse sachen weiter ermöglicht. Z.B. die privatkopie, auch bei online video diensten. Darin sehe ich *viel* interessantere Ziele, als gegen technik A vorzugehen, die meiner ansicht nach viel harmloser als technik B, C, D und E ist, um dann am ende vielleicht A zu verhindern, und mit B, C, D, E und A2 leben zu müssen. </my opinion> Tschüss, Andreas
