Kommunikation zweier Geräte - Welche mitgesendete Identitäten sind vertrauenswürdig?

Hey,

wenn zwei Partner kommunizieren (Endgeräte sind erstmal egal) und man will anhand einer Identität einen Schlüssel erzeugen (Mechanismus ist klar), welche Eigenschaften eines Gerätes lassen sich heranziehen, um auf dessen Basis eine geeignete Identität zu erstellen?

Ich dachte erst an einer MAC, aber die sind auch nicht Fälschungsresistent. (Hier gehe ich mal von einer MAC aus, die durch die verbauten Hardwarecodes generiert wird)

Existieren noch Elemente, die wirklich "nachvollziehbar, glaubwürdig und eindeutig" sind? Welche ID wird bei der identitätsbasierten Kryptographie häufig oder standardisiert genutzt?
 
Willst du immer zwischen zwei selben Geräte die Identität nachweisen oder zwischen ("Bau")gleichen Geräten?
 
Ich versuche die Identitätsbasierte Verschlüsselung nachzuvollziehen. Dabei wird der Begriff "ID_A" und "ID_B" verwendet, was als Identität für die Kommunikationspartner A und B synonym steht. Da eine ID möglichst einzigartig und fälschungssicher sein sollte, weiß ich nicht genau, was sich für solch einen Parameter eignet. Da der Kommunikationsschlüssel extern erzeugt wird und A, sowie B nur ihre Identität übermitteln, kann es praktisch alles sein. Selbst ausgewählte Zahl, oder Hardwarebasiert, wenn keine aktive Anfrage möglich ist.

Das TPM scheint eine sinnvolle Erweiterung eines Systems.
 
Das hängt von der Situation hast. Manchmal hat man zwei Bluetoothgeräte, die untereinander kommunizieren und den Traffic dazwischen verschlüsseln. Hier kann der Nutzer ja nicht aktiv werden. Es bietet sich natürlich an im EEPROM einen Key zu hinterlegen, aber sobald der kompromittiert wurde, taugt die Verschlüsselung dazwischen nicht mehr soo viel.
Allerdings sind in den Fällen, die ich gerade betrachte, noch eine dritte Person (eine TA/Trusted Authority) involviert. Diese erhält jeweils diese identitätsbasierten Keys "ID_A" und "ID_B". Wirft eine Hashfunktion (eine Abbildung in die elliptischen Kurven) drauf und multipliziert das Ergebnis mit einem Masterkey, die nur die TA kennt. Anschließend erhalten beide Kommunikationspartner genau diesen Wert S_A bzw. S_B zurück. Die Kommunikationspartner können die Hashfunktion auch selber nutzen. Berechnet wird dann auf beiden Seiten

K_A = e( S_A, H(ID_B) ) = e( H(ID_A), S_B) = K_B, wobei "e" eine Paarung ist. (D.h. K ist dann ein Element eines endlichen Körpers, was beliebig verwendet werden kann.)

Ich bin der Annahme, dass diese Identitäten einzigartig sein sollten, sodass die Kommunikationen von Runde zu Runde nicht durch ältere Angriffe kompromittiert werden konnten. Man stelle sich ein Telefonat zwischen Merkel und Trump vor, welches einen alten Key nutzt und entsprechend einfach abgehört werden könnte.

PGP Keys taugen schon, gerade bei solchen Geräten mit begrenzten Ressourcen oder keiner Updateconnectivität. Daher dachte ich auch eher dran, dass die verbauten Bauteile eine eigene Hardware-ID hinterlegt haben, quasi eine eigene Signatur. Aus den gesamten Signaturen wird dann die ID des Gerätes berechnet und anhand anderer Zufallsvariablen manipuliert. Dieses Konzept zeigt aber: Ist die ID nicht permanent gleich, kann der Gegenüber nicht verifizieren, ob es sich dabei auch um das Gerät handelt, mit dem man kommunizieren wollte. Also müssen feste Werte hinterlegt sein, was wieder für eine EEPROM mit PGP spricht. (vermutlich günstiger, als ein stärkerer Prozessor..)
 
Du sprichst von Identitäten mit einer hohen "Identity Assurance" und einem hohen "Level of Assurance", nicht nur von beliebigen Identäten. D.h. dein Vorhaben setzt eine (oder mehrere) vertrauenswürdige dritte Partei voraus - z.B. in hierarchischen Vertrauensmodellen auch eine CA, oder bei PGP das WoT -, der beide Kommunikationspartner vertrauen. In deinem Fall wäre also die TA diejenige, in dessen Kontext Identitäten eine Gültigkeit haben und die in der Lage sein muss diese Assurance zu bieten (z.B. mit Zertifikaten, Signaturen oder über eine Blockchain). Siehe auch Zooko's triangle - Wikipedia oder auch As I May Think...: The Persistence of Identity (Updating Zooko's Pyramid).

Ohne vertrauenswürdige Dritte ist es schwer. Natürlich kann man so Dinge machen wie Browser oder Machine Fingerprinting (z.B. Technical analysis of client identification mechanisms - The Chromium Projects), aber auch das lässt sich fälschen oder ist relativ instabil (z.B. abhängig von Systemlast, Browserversion, usw..). Außerdemusst du auch hier wieder Vertrauen aufbauen (z.B. Trust On First Use), was ebenfalls wieder Probleme an Angriffe mit sich bringt.

Warum die Einzigartigkeit dieses Identifiers im Verhältnis zur Qualität des kryptographischen Verfahrens stehen sollte, ist mir allerdings nicht klar.
 
Zuletzt bearbeitet:
@Shalec

Du beschreibst eigentlich ein rein technisch-organisatorisches Problem.

Es gibt starke PGP Keys die man verwenden kann. Das ist sogar insofern besser weil es letztlich um die Identität einer Person/Organisation gehen soll und nicht um die Identität eines Gerätes.
Selbst wenn du Geräte einwandfrei identifizierst und die Kommunikation einwandfrei verschlüsselst, so ist noch immer keine _Sicherheit_ per se gewährleistet. Tatsächlich sind wir in diesem Bereich kaum einen Schritt weiter, denn entweder kennst du den für die Verschlüsselung notwendigen Teil, VOR der Kommunikation oder du beziehst ihn aus anderer (sie Beere) Dritten Quelle, deren Verlässlichkeit man selbst immer nur bedingt annehmen kann.

DNSSEC/DANE, WoT, CAs - das sind alles ähnliche Ansätze das organisatorische Problem technisch zu umgehen.


Diese erhält jeweils diese identitätsbasierten Keys "ID_A" und "ID_B". Wirft eine Hashfunktion (eine Abbildung in die elliptischen Kurven) drauf und multipliziert das Ergebnis mit einem Masterkey, die nur die TA kennt. Anschließend erhalten beide Kommunikationspartner genau diesen Wert S_A bzw. S_B zurück. Die Kommunikationspartner können die Hashfunktion auch selber nutzen. Berechnet wird dann auf beiden Seiten

K_A = e( S_A, H(ID_B) ) = e( H(ID_A), S_B) = K_B, wobei "e" eine Paarung ist. (D.h. K ist dann ein Element eines endlichen Körpers, was beliebig verwendet werden kann.)


Egal was du treibst - ein limitierender Faktor ist die Maschine, deren algorithmische Tätigkeiten und Ergebnisse letztendlich immer formal (notwendig) beschreibbar und somit nachvollziehbar sind. Die schlichte Erkenntnis ist, dass es nichts wirklich zufälliges gibt und am Ende steht die Anzahl der Möglichkeiten gegen das technische Vermögen einer Maschine die korrekte zu "finden". Aber angenommen dir gelingt die Erstellung eines absolut kollisionsfreien Merkmals. Es bleibt die Frage was es beweist, solange dein Gegenüber nicht weiß, dass es eben das kollisionsfreie Merkmal des richtigen Gegenübers ist.


Bei all der Diskussion ist unser Problem, oder vielmehr die Frage ist: wie kann mir mein Gegenüber beweisen der zu sein, der er vorgibt zu sein.
In der Realität geht das dadurch, dass er etwas "weiss" von dem ich weiss dass nur er es wissen kann. Oder er besitzt etwas definitiv einzigartiges, von dem ich weiss dass nur er es besitzen kann.


Aber lass dich von der Tatsache nicht abschrecken dass jeder 5 Jährige mit Leichtigkeit kollisionsfreie Merkmale erzeugen kann, was alle Mathematiker der Welt zusammen (praktisch) nicht schaffen ;)

Ich glaube mal gelesen zu haben dass es daran liegt dass alles, was sich mathematisch formal beschreiben lässt eben auch formal erklären lässt - im Gegensatz zu einem Gedanken.
 
Genau das Problem
Chromatin hat gesagt.:
Wie kann mir mein Gegenüber beweisen der zu sein, der er vorgibt zu sein.

ist mir bei meinen Überlegungen ebenfalls aufgefallen. Man kann noch so viel Energie aufwenden, um einen TRNG (True Random Number Generator) und eine absolut kollisionsfreie Hashfunktion zu generieren, Am Ende bleibt das Problem, wie ich meinem Gegenüber davon überzeugen kann, dass ich das auch wirklich bin. Auch das Konzept der Public- & Private-key Kryptographie hinkt in der Hinsicht.

Tatsächlich ist für mich die einzige Lösung, jemanden davon zu überzeugen, dass ich ich bin, indem ich ein pre-shared-secret integriere, womit ich entsprechend dem Prinzip genüge
Chromatin hat gesagt.:
[...] etwas "weiss", von dem ich weiss, dass nur er es wissen kann.


Das kann eine verifizierbare Signatur sein. Oder wie Beere bereits notierte

SchwarzeBeere hat gesagt.:
Natürlich kann man so Dinge machen wie Browser oder Machine Fingerprinting, aber auch das lässt sich fälschen oder ist relativ instabil (z.B. abhängig von Systemlast, Browserversion, usw..). Außerdemusst du auch hier wieder Vertrauen aufbauen (z.B. Trust On First Use), was ebenfalls wieder Probleme an Angriffe mit sich bringt.


womit man eben sieht, dass eine erste Kommunikation unter vertrauenswürdigen Bedingungen stattfinden muss.

Es gibt ja auch einen PGP-Server, auf dem Public-keys geladen werden können (vergleiche die Enigmailerweiterung von Thunderbird). Nun kann dies aber wirklich jeder machen und man hat entsprechend das Problem von oben. Vertrauenswürdigkeit zur TA und Verifizierung der Gesprächsteilnehmer.


Ich konkretisiere mal ein wenig, in die Richtung, in die ich gerne denken würde. Wir haben zwei mobile Geräte. Sagen wir Smartphone und Headset. Man telefoniert über das Headset mit einem Gesprächspartner. Das Headset sendet folglich die Worte zum Handy. Die Verbindung muss verschlüsselt sein, sobald der Inhalt als vertraulich eingestuft wird. Ein Headset hat nur wenig Platz für solche Technik zur Verfügung. Häufig werden Cryptounits für sowas verwendet, in denen ist der AES128 hardware-implementiert. Zur Verschlüsselung würde mir jetzt die Idee kommen, einfach einen Kommunikationskey auszutauschen, indem beide Teilnehmer entsprechend ein Geheimnis konstruieren, dieses mit einem vordefinierten Wert verschleiern und zum Schluss beide entsprechend den Key haben. D.h. hier wäre ein Key-exchange-Protokoll am Werke, vermutlich mit Signatur/Blind-Signatur. Dann kann das Gespräch mittels AES Blockweise mit geringer, nicht merklicher, Latenz verschlüsselt übertragen werden. Da hier die Nachricht beliebig groß wird, machen Parallelisierungsbetriebsmodi (Counter-Mode, Galois-Counter-Mode, ...) oder Stromshiffreneigenschaftenerzeugungsmodien (Cipher-Block-Chaining) keinen Sinn. (Beim letzten läuft man sogar in die Gefahr, dass die Kommunikation durch Übertragungsfehlern in einem Bit bereits nach 2 Blöcken nicht mehr verständlich ist. (Wäre allerdings ein guter Check, bzgl. Parity, ob die Kommunikation unterwandert/manipuliert wurde..)
Anstelle des AES lässt sich auch das obige Verfahren nutzen (Pairings). Allerdings bezweifle ich, dass das für diesen Zweck geeignet ist.

Da kommt mir die Idee, erstmal ein tatsächliches Einsatzszenario zu identifizieren und anhand dessen die Praktikabilität auszuloten.

Ein Einsatz wäre z.B. die Übertragung von Bildern, aufgenommen mit einem Bluetooth-fähigen Gerät, auf ein anderes Gerät. Die Kamera hat keine Internetschnittstelle und kann nur vom PC über eine USB-Schnittstelle geupdatet werden. Gehen wir also von einer nicht erneuerbaren Software aus. Einzige Möglichkeiten für das Gerät einen Rundenschlüssel zu erzeugen, sind Zufallswerte die mindestens kryptographisch sicher sein müssen, damit nicht in jeder Runde der gleiche Key genutzt wird. Dann sollte ein Secret-Key auf dem Gerät gespeichert und ein Public Key im Treiber enthalten sein. Man kann ja durchaus redundante Informationen mitsenden, in dem Fall der Zufallswert, welcher nur zum Verschleiern dient, aber sonst keinen Nutzen hat. Ist aber solch ein Public-Key-System überhaupt notwendig?
 
womit man eben sieht, dass eine erste Kommunikation unter vertrauenswürdigen Bedingungen stattfinden muss.


Und damit schließt sich der Kreis, denn wir haben im Netz keine anderen Möglichkeiten außer die Bestätigung eines Dritten oder zwei Kommunikationspartner haben zuvor auf anderem Wege den Schlüssel getauscht.


 
Zurück
Oben