Big Brother heißt unter anderem TCPA und Palladium

[Trasher]

Zur Signatur:

Mein Rechner (A) verschlüsselt mit dem mir unbekannten (weil ja hardwareimplementiert) private key seine Signatur und schickt sie an meinen Fake-Server (B). B kann jetzt sichergehen, daß die Nachricht von A kommt. Super.
Jetzt schickt B eine Signatur zurück an A, verschlüsselt mit einem ausgesponnenen private key. Zu diesem ausgesponnenen private key habe ich vorher einen public key erstellt, den ich an A geschickt habe, damit er einerseits meine Sig überprüfen kann und andererseits mir verschlüsselte Nachrichten schicken kann.

Der Signaturaustausch ist also auch sichergestellt. Wo liegt das Problem?

 

[Trasher]

das der entsprechende öffentliche Schlüssel des anderen Teilnehmers entweder schon in der Hardware hinterlegt ist oder von einem Server bezogen wird, der die Echtheit des öffentlichen Schlüssels über Signaturen (Zertifikate) sicherstellt.

Ah, jetzt wirds langsam kniffelig
Das wäre natürlich das Aus für meine Idee, wenn der public key fest im Chip integriert wäre. Ich glaube aber, daß aus Gründen der Sicherheit kein Dienstleister den Deal eingeht, über Jahrzehnte den gleichen private key benutzen zu müssen, weil der entsprechende public key festverdrahtet auf den Boards der user liegt.

 

[Trasher]

@ Trasher

Unter dem Link findest du alles was relevant sein dürfte (falls du ihn wirklich noch nicht gelesen haben solltest). Falls du wirklich einen Fehler entdecken solltest der die ganze Idee unbrauchbar macht, schön. Ich kann jedenfalls keinen finden.

http://www.heise.de/ct/02/22/204/

Das System hat ursprünglich erst einmal keinen Fehler. Wenn du meinst, ich hätte einen Fehler gefunden, dann irrst du dich.

Aber es gibt immer einen Schwachpunkt bei einem verschlüsselten Datenaustausch: Die Schlüsselübergabe.
Wenn ich dir weis machen kann, ich sei der Bundeskanzler und wir daraufhin einen Schlüssel austauschen, dann wirst du, wenn du meine Signatur bekommst immer dein Leben darauf verwetten, daß die Nachricht tatsächlich vom Bundeskanzler gekommen ist. Die Signatur bestätigt es dir ja.

 

[zian]

Zur Signatur:

Mein Rechner (A) verschlüsselt mit dem mir unbekannten (weil ja hardwareimplementiert) private key seine Signatur und schickt sie an meinen Fake-Server (B). B kann jetzt sichergehen, daß die Nachricht von A kommt. Super.
Jetzt schickt B eine Signatur zurück an A, verschlüsselt mit einem ausgesponnenen private key. Zu diesem ausgesponnenen private key habe ich vorher einen public key erstellt, den ich an A geschickt habe, damit er einerseits meine Sig überprüfen kann und andererseits mir verschlüsselte Nachrichten schicken kann.

Der Signaturaustausch ist also auch sichergestellt. Wo liegt das Problem?

nee, nee, das läuft anders:

dein Rechner A schickt eine Nachricht an deinen Fake-Server B (irgendeine TCPA-Abfrage) und signiert diese mit dem privaten Schlüssel (von A). B überprüft die Signatur anhand des öffentlichen Schlüssels von A. Dafür benötigt aber irgendwoher diesen öffentlichen Schlüssel.
Um das ganze für Hacker nicht so einfach zu machen, wäre es sinnvoll die öffentlichen Schlüssel auf speziellen Servern C abzulegen, an denen sich B erstmal ausweisen muss. Dafür müsste B nun eine signierte Nachricht an C schicken. Dummerweise würde C dann aber merken, das B ein Fake-Server ist (weil dessen Schlüssel nicht in der Liste der erlaubten enthalten ist) und an B keinen öffentlichen Schlüssel herausgeben.
Nun könnte man sagen, das dies egal ist, weil B ja sowieso nur ein Fake-Server ist und deshalb auch einfach intern so tun kann, als hätte er die Signatur von A überprüft.
Das Problem entsteht nun aber, wenn B nun die Antwort an A schickt. Denn dafür muss B die Nachricht wieder signieren. Er signiert also mit seinem privaten Schüssel, dummerweise kennt A aber nicht den öffentlichen Schlüssel von B und kann deshalb die Echtheit nicht bestätigen. Wird also den Dienst verweigern.

Hab ich etwas übersehen?
Das Problem ist jetzt nur, der öffentliche Schlüssel vom echten B (ich nenne den mal D). Woher bekommt A diesen?

Ah, jetzt wirds langsam kniffelig
Das wäre natürlich das Aus für meine Idee, wenn der public key fest im Chip integriert wäre. Ich glaube aber, daß aus Gründen der Sicherheit kein Dienstleister den Deal eingeht, über Jahrzehnte den gleichen private key benutzen zu müssen, weil der entsprechende public key festverdrahtet auf den Boards der user liegt.

Das könnte man über Zertifikate regeln. A muss sich den öffentlichen Schlüssel von D besorgen, diese könnte frei verfügbar im Internet liegen. (B kann den noch immer nicht zwangsentfremden, da er keinen privaten Schlüssel von D hat) Und werden entsprechend mit einem Zertifikat von der Oberinstanz E versehen. Um das Zertifikat zu überprüfen, ist der entsprechende öffentliche Schlüssel von E in der Hardware hinterlegt.
Damit kommen wir zu deinem Punkt zurück. Die Lösung dafür könnte darin bestehen, das man alle x Jahre entweder einen neuen Prozessor kaufen muss oder diesen für einen Schlüsselwechsel einschicken muss.
Oder viel einfacher: Programme, die zum Knacken von Schlüsseln programmiert worden, laufen einfach nicht auf Rechner mit TCPA. Damit können dann auch keine virtuellen Großrechner zum Schlüssel knacken eingesetzt werden und die Schlüssel sind auch für 5-10 Jahre sicher.
Wäre jetzt jedenfalls mal so eine Idee

 

[zian]

Aber es gibt immer einen Schwachpunkt bei einem verschlüsselten Datenaustausch: Die Schlüsselübergabe.
Wenn ich dir weis machen kann, ich sei der Bundeskanzler und wir daraufhin einen Schlüssel austauschen, dann wirst du, wenn du meine Signatur bekommst immer dein Leben darauf verwetten, daß die Nachricht tatsächlich vom Bundeskanzler gekommen ist. Die Signatur bestätigt es dir ja.

Und genau diesen Schwachpunkt versuchen asymmetrische Verfahren ja auszuschließen, da die Schlüssel für alle verfügbar sind und ich den Schlüssel nicht über einen sicheren Kanal übermitteln muss.
Zusätzlich kommen die Signaturen hinzu, die die Echtheit bestätigen sollen. Sonst kann sich jeder als Bundeskanzler ausgeben. Eine Signatur, die behauptet, ich bin der Bundeskanzler, sagt leider auch noch nichts aus. Deshalb geht man einen Schritt weiter und arbeitet mit Zertifikaten, wo dann jemand (den wir beide kennen oder beide vertrauen) bestätigt, das ich wirklich der Bundeskanzler bin. Der Angriffspunkt wäre nun der Aussteller der Zertifikate. Aber da wüßte ich außer Brute-Force keine ernsthafte Möglichkeit (wobei ich die Ernsthaftigkeit von Brute-Force bei großen Schlüsselstärken mal anzweifeln würde)

 

[I3leach]

zian wrote:

Damit kommen wir zu deinem Punkt zurück. Die Lösung dafür könnte darin bestehen, das man alle x Jahre entweder einen neuen Prozessor kaufen muss oder diesen für einen Schlüsselwechsel einschicken muss.


Hm, hab mich immer gefragt wofür "rekonfigurierbare Schalkreise" gut sein sollen, plötzlich geht mir sowas wie ein Licht auf...

 

[Trasher]

Zur Signatur:

Mein Rechner (A) verschlüsselt mit dem mir unbekannten (weil ja hardwareimplementiert) private key seine Signatur und schickt sie an meinen Fake-Server (B). B kann jetzt sichergehen, daß die Nachricht von A kommt. Super.
Jetzt schickt B eine Signatur zurück an A, verschlüsselt mit einem ausgesponnenen private key. Zu diesem ausgesponnenen private key habe ich vorher einen public key erstellt, den ich an A geschickt habe, damit er einerseits meine Sig überprüfen kann und andererseits mir verschlüsselte Nachrichten schicken kann.

Der Signaturaustausch ist also auch sichergestellt. Wo liegt das Problem?

nee, nee, das läuft anders:

dein Rechner A schickt eine Nachricht an deinen Fake-Server B (irgendeine TCPA-Abfrage) und signiert diese mit dem privaten Schlüssel (von A). B überprüft die Signatur anhand des öffentlichen Schlüssels von A. Dafür benötigt aber irgendwoher diesen öffentlichen Schlüssel.

So meine ich es ja auch. Das Wort "Super" in meinem Satz deutet nur darauf hin, daß es völlig unerheblich ist, ob B die Signatur überprüft, das muß er ja gar nicht, weil er mein eigener Fake-Server ist

Bisher gehe ich davon aus, daß keine Drittrechner beteiligt sind. Ist das der Fall, muß A irgendwann mal seinen public key rausrücken, und den fängt B dann halt ab.

Um das ganze für Hacker nicht so einfach zu machen, wäre es sinnvoll die öffentlichen Schlüssel auf speziellen Servern C abzulegen, an denen sich B erstmal ausweisen muss.
Dafür müsste B nun eine signierte Nachricht an C schicken. Dummerweise würde C dann aber merken, das B ein Fake-Server ist (weil dessen Schlüssel nicht in der Liste der erlaubten enthalten ist) und an B keinen öffentlichen Schlüssel herausgeben.

Das ist in der Tat ein Problem. Dann müsste ich nämlich an den private key eines echten Servers herankommen oder meinen öffentlichen irgendwie mit auf die Liste von C bekommen. Beides erscheint aussichtslos.

Nun könnte man sagen, das dies egal ist, weil B ja sowieso nur ein Fake-Server ist und deshalb auch einfach intern so tun kann, als hätte er die Signatur von A überprüft.
Das Problem entsteht nun aber, wenn B nun die Antwort an A schickt. Denn dafür muss B die Nachricht wieder signieren. Er signiert also mit seinem privaten Schüssel, dummerweise kennt A aber nicht den öffentlichen Schlüssel von B und kann deshalb die Echtheit nicht bestätigen. Wird also den Dienst verweigern.

Hab ich etwas übersehen?

Ja, und zwar, daß zusätzlich zur Signatur mein Fake Server erst gar keine Nachricht an A senden kann, denn er hat ja C nicht überreden können, den öffentlichen Schlüssel von A herauszurücken.

Das Problem ist jetzt nur, der öffentliche Schlüssel vom echten B (ich nenne den mal D). Woher bekommt A diesen?

Ich hoffe ja mal, er fragt blind in den Raum und mein B kann ihm einfach einen geben
In Realität geht das aber sicher auch über C. Setzt wiederum voraus, daß C sicherstellen kann, daß A ein unmanipulierter Computer ist. Jeder TCPA hat also einen festen private Key und sein dazugehöriger public key wird noch während des Produktionsprozesses des Boards bei C registriert.
Somit kann A sich bei C ausweisen und bekommt den public key von D

Ah, jetzt wirds langsam kniffelig
Das wäre natürlich das Aus für meine Idee, wenn der public key fest im Chip integriert wäre. Ich glaube aber, daß aus Gründen der Sicherheit kein Dienstleister den Deal eingeht, über Jahrzehnte den gleichen private key benutzen zu müssen, weil der entsprechende public key festverdrahtet auf den Boards der user liegt.

Das könnte man über Zertifikate regeln. A muss sich den öffentlichen Schlüssel von D besorgen, diese könnte frei verfügbar im Internet liegen. (B kann den noch immer nicht zwangsentfremden, da er keinen privaten Schlüssel von D hat) Und werden entsprechend mit einem Zertifikat von der Oberinstanz E versehen. Um das Zertifikat zu überprüfen, ist der entsprechende öffentliche Schlüssel von E in der Hardware hinterlegt.
Damit kommen wir zu deinem Punkt zurück. Die Lösung dafür könnte darin bestehen, das man alle x Jahre entweder einen neuen Prozessor kaufen muss oder diesen für einen Schlüsselwechsel einschicken muss.
Oder viel einfacher: Programme, die zum Knacken von Schlüsseln programmiert worden, laufen einfach nicht auf Rechner mit TCPA. Damit können dann auch keine virtuellen Großrechner zum Schlüssel knacken eingesetzt werden und die Schlüssel sind auch für 5-10 Jahre sicher.
Wäre jetzt jedenfalls mal so eine Idee

Jetzt kommt auch noch E ins Spiel, neiiiin
Nimm mir nicht auch noch die letzte Hoffnung.

Was aber, wenn ich auch diese Zwischeninstanzen selbst simuliere? Wie du schon ansprichst, darf dann natürlich kein public key im Chip integriert sein. Denn dann krieg ich ja die Sig nicht hin, um A weis zu machen, daß ich E bin.

 

[Trasher]

...wobei ich die Ernsthaftigkeit von Brute-Force bei großen Schlüsselstärken mal anzweifeln würde

Ich hab hier noch ein par 486'er rumstehen. Lass uns anfangen, einen Riesencluster zu bauen. 2048 bit sind doch auch nicht die Welt

 

[zian]

In Realität geht das aber sicher auch über C. Setzt wiederum voraus, daß C sicherstellen kann, daß A ein unmanipulierter Computer ist. Jeder TCPA hat also einen festen private Key und sein dazugehöriger public key wird noch während des Produktionsprozesses des Boards bei C registriert.
Somit kann A sich bei C ausweisen und bekommt den public key von D

genau dafür wird aber ja der Krypto-Coprozessor mit in die CPU integriert.

steht in dem Link, der gepostet wurde, drin.
http://www.heise.de/ct/02/22/204/default.shtml

Alles andere würde ja auch keinen Sinn machen

 

[sint]

hab 'n spruch den ich gut finde:

-
monokulturen sterben in der natur von alleine aus!
-


monokultur ist genau das was M$ da vorhat.