Bank-Transaktion für Authentifizierung verwenden

[pi()]

Hallo Leute!

Ich arbeite gerade für eine große Security Firma und selbst bei dieser gibt es für manche Probleme keine ordentliche Lösung. Deswegen habe ich angefangen, nachzudenken. Der Standard bei dieser Firma ist derzeit, wenn vertrauliche Daten mit einem externen Mitarbeiter ausgetauscht werden: Daten werden über mit PGP verschlüsselte E-Mail übertragen. Das PGP Schlüsselpaar wird nur für den derzeitigen Partner verwendet und die PGP Fingerprints werden, sozusagen um einen zweiten Faktor einzubringen, vorher per SMS abgeglichen. Ich finde dieses Verfahren jedoch stümperhaft und für die gegebene Security auch zu aufwendig.

Deswegen habe ich mir überlegt warum man es nicht ein nicht zum Beispiel auch so machen könnte: nennen wir die zwei kommunizierenden Personen Alice und Bob, kurz A und B.

A ruft B auf seiner Handynummer an. Dabei sagt A zu B eine Nonce. B überweist einen Mikrobetrag (zum Beispiel einen Cent) an A und im Verwendungstext der Überweisung befindet sich diese Nonce und ein PGP Finger Print (Wenn zu lang, dann eben nur ein Hash oä.). Dann sendet B zu A seinen Public Key und dazu den Finger Print in einer unverschlüsselten E-Mail. A hat nun die Möglichkeit, die zwei Fingerprints zu vergleichen. Stimmen diese überein, so sendet A über eine mit dem Public Key von B verschlüsselte E-Mail nun den Public Key von A.

Wäre das nicht um einiges schlauer? Was meint ihr? Wenn sich A und B kennen, oder zumindest wissen, wie ihre Stimme in realo klingt, dann ist auch die Stimme beim Telefonieren ein zusätzlicher, nicht zu unterschätzender Authentifizierungsfaktor imho.

Liebe Grüße und ich bin gespannt auf eure Meinung!

 

[SchwarzeBeere]

Paypal setzt deine Idee zur Identifizierung genau so um, mal von der Telefoniererei abgesehen

Nichtsdestotrotz gibt es einige Punkte, die man im Unternehmenskontext beachten muss:
1. Anforderungen: Warum betreibt man diesen Aufwand? Gibt es Kunden, die diese Art der Kommunikation fordern? Gibt es Richtlinien, die man beachten und forcieren muss? Oder macht man es einfach "nur so"? Welche Maßnahmen gibt es, diese Punkte umzusetzen? Wieviel Geld steht zur Verfügung? Und wer muss das System später benutzen (können)? Bei deinem Vorschlag wirst du z.B. schnell auf das Problem stoßen, dass du nun Bankdaten verarbeiten musst. D.h. hier wirst du es schnell mit Datenschutz und Finanzregularien zu tun bekommen, gerade im internationalen Umfeld. Du kommst damit auch sofort zu Punkt 2.

2. Risiko: Welches Risiko kann/will/darf man eingehen? In welchem Verhältnis steht die Risikobereitschaft zum Aufwand? Anders gesagt: Was kostet mich der Spaß und sind die Kosten überhaupt vertretbar? Um bei dem Beispiel zu bleiben: Wenn der Schutz der Bankdaten mehr kostet, als der Schaden bei einem Diebstahl der Email-Inhalte, dann ist die Lösung schlecht. Wenn die Wahrscheinlichkeit eines Diebstahls klein ist, der Aufwand der Verschlüsselung aber groß, so ist die Lösung ebenfalls schlecht. Usw..

3. Technologie: PGP ist nicht nur eine Technik zur Email-Verschlüsselung. PGP bringt ein eigenes Trust Model mit, welches sich stark von einem hierarchischen Modell (z.B. S/MIME, TLS mit Client-Auth auf Fileshares, ...) unterscheidet: Das Web of Trust, das in der Praxis maßgeblich durch die Keyserver umgesetzt und gestützt wird. Wenn man schon auf PGP setzt - S/MIME ist in der Geschäftswelt weiter verbreitet und bietet imho weitaus effizientere Methoden zur Email-Verschlüsselung, die darüber hinaus auch idR durch Kunden anerkannt werden -, dann sollte man auch die Mittel nutzen, die einem hier zur Verfügung gestellt werden. So könnte man z.B. die eigenen Schlüssel in einem Unternehems-WOT signieren lassen und so gegenüber einem Dritten die Authentizität nachweisen. Dann braucht es auch keine Finanztransaktionen oder SMS mehr.

 

[pi()]

Danke für deine ausführliche Antwort!

Also in meinem Fall (ich bin der ext. Mitarbeiter) geht es darum, dass die Daten ganz sicher geheim bleiben. Und das wird sehr ernst genommen.
Gehen wir deswegen einmal davon aus, dass es die Kosten auf jeden Fall wert ist.

Die Frage die sich mir jetzt stellt ist, wie lässt sich das Trustmodell von PGP nun auf unseren Fall umlegen? Ich hab den Typen für den ich arbeite noch nie gesehen, wir sind viele Kilometer entfernt und ich muss zu ihm einen sicheren Kanal (authentifiziert und vertraulich) aufbauen. Das Ganze soll möglichst ohne bezahlte Zertifikate funktionieren. Beide treten in diesem Protokoll sozusagen nur als Privatpersonen auf.

Die Lösung, die der Mitarbeiter mir vorgeschlagen hat ist deren derzeitiger Standard für solche Fälle (ext. Mitarbeiter, geheime Daten), er hat aber selbst zugegeben, dass diese Methode etwas Stümperhaft ist. Ich wollte einfach wissen, ob meine stümperhafte Methode besser ist, also eine Verbesserung darstellen könnte, oder ob ich irgendetwas wichtiges übersehen habe.

Mag auch sein, dass das Ganze nicht neu ist und das ist ja im Grunde auch egal. Ich möchte es ihm einfach nur vorschlagen aber zur Sicherheit noch einmal nachfragen, denn es könnte ja eben wie gesagt sein, dass sich irgendetwas wichtiges übersehe.

Deswegen hier meine Kernfrage: Habe ich etwas wichtiges übersehen? Wie könnte man das "Protokoll" brechen?

 

[SchwarzeBeere]

Deswegen hier meine Kernfrage: Habe ich etwas wichtiges übersehen? Wie könnte man das "Protokoll" brechen?

Du definierst weder deine Risikobereitschaft (Schaden/Wahrscheinlichkeit), noch ein Angreifermodell. Gegen wen möchtest du dich denn schützen? Welches Interesse hat dieser Angreifer? Und welche Fähigkeiten? Ein staatlicher Angreifer hat ganz andere Möglichkeiten (Telefonüberwachung, Überwachung der Kontobewegungen, ...), als der böse Nachbar, der vielleicht nur Zugriff auf das WLAN hat, deine Gespräche abhören oder dir beim Online-Banking über die Schulter schauen kann.

Diese Analyse bildet jedoch die Grundlage für dein Protokoll. Aktuell ist dein Protokoll daher mehr oder minder nutzlos und lässt viele Fragen offen: Wurden die Bankdaten über einen sicheren Kanal ausgetauscht? Woher kennt Alice die Handynummer von Bob? Wie kann Alice sich sicher sein, dass Bob auch Bob ist und umgekehrt? Eine Identifizierung der Partner ohne Zuhilfenahme von Dritten ist sehr schwer und aufwändig - dagegen ist sie mit Hilfe von Dritten einfach, z.B. Personalausweis, PostIdent, IDNow, PGP, S/MIME, ...

Der Angriff ist einfach: Ich melde mich bei deinem Gesprächspartner und gebe mich als Pi() aus. Sage ihm, dass ich eine neue Handynummer und neue Bankdaten habe, weil ich gerade dabei bin, mein Backoffice umzustellen. Wenn ich nun noch zusätzlich für wenige Minuten in Besitz deines Handys bin, z.B. weil du es hast liegenlassen, hat Bob keine Chance mehr, das zu überprüfen. Schon gibts einen neuen PGP Key und Bob kommuniziert mit mir im Glauben, ich sei du.

Deswegen nochmal: Erfinde nichts neues, sondern nutze das, was da ist. Z.B. hat Paypal garnicht den Anspruch, die Identität des Kontoinhabers zu prüfen, sondern nur die Existenz des Kontos. Und das funktioniert mit einer Überweisung problemlos.
Das PGP Web of Trust bietet dir alles, was du zur Sicherstellung der Authentizität des Keys und des Besitzers bzw. der Besitzerin brauchst. Denk dir auf Basis dieses Trust Models etwas aus, z.B. die persönliche Zustellung eines Yubikeys mit einem PGP Keypair drauf, das vom Admin des Unternehmens erstellt und von ihm/ihr und seinen/ihren KollegenInnen signiert wurde, sofern dies mit dem Angreifermodell zusammenpasst (der Admin also nicht Angreifer ist). Wenn dieser Ansatz nicht anwendbar ist, dann nimmt S/MIME und kauf dir für die paar € ein Zertifikat, das deinem Sicherheitsbedürfnis entspricht (Smartcard-Zertifikat vs. Software-Zertifikat, aufwändiger vs. einfacher Identifizierungsprozess, usw..). Alles andere ist unsicher.

 

[pi()]

Der Angriff ist einfach: Ich melde mich bei deinem Gesprächspartner und gebe mich als Pi() aus. Sage ihm, dass ich eine neue Handynummer und neue Bankdaten habe, weil ich gerade dabei bin, mein Backoffice umzustellen. Wenn ich nun noch zusätzlich für wenige Minuten in Besitz deines Handys bin, z.B. weil du es hast liegenlassen, hat Bob keine Chance mehr, das zu überprüfen. Schon gibts einen neuen PGP Key und Bob kommuniziert mit mir im Glauben, ich sei du.

Das funktioniert ganz sicher nicht!
Dafür ist ja die Banküberweisung da. Du müsstest ein Konto haben, dass unter dem Namen "pi()" läuft. Dafür müsstest du die Bank mit einem gefälschten Ausweis becircen und wenn du das kannst, dann trau ich dir auch gleich ein gefälschtes Zertifikat zu. Übrigens ist in meinem Beispiel der externe Mitarbeiter der, der die Überweisung tätigt. Vielleicht war das ja unklar. Denn dieser muss sich ja auch in erster Linie authentifizieren. Von einem "fremden" "Eindringling" gefälschte Daten zu bekommen ist nämlich idF kaum ein Problem.


Nagut, du möchtest ein Angreifer-Modell:
Logischerweise ist der Angreifer nicht der Staat. Sonst macht es ja überhaupt keinen Sinn, eine Bank zu verwenden. Logischerweise ist der Angreifer auch nicht die- oder in der Bank. Selbes Problem sonst.
Als als ANgreifer modell sähe ich jetzt in erster Linie: Eine Konkurrenzfirma, die gerne über illegalem Wege an die Daten herankommen würde. Natürlich kontrolliert diese Firma normalerweise nicht die Bank und auch nicht das Telefonnetz. Sagen wir, sie könnten das Telefonnetz abhören (obwohl das seit 3G nicht mehr so leicht ist wie früher, oder?). Gut, dann bekommen Sie die Nonce. Sie können aber immer noch nicht ihre Bankdaten ändern, wenn Sie eine überweisung tätigen.


Es geht ganz einfach um Firmengeheimnisse, die von einer FIrma einem externen Mitarbeiter anvertraut werden. Die Firma muss sich sicher sein, dass diese nur bei ihm landen. Was er dann damit macht, da muss die Firma dem Menschen dann vertrauen.

Wurden die Bankdaten über einen sicheren Kanal ausgetauscht?

Natürlich nicht. Wenn ich schon einen sicheren Kanal hätte, könnte ich ja gleich diesen verwenden oder zumindest einen Schlüssel übertragen.

Deswegen nochmal: Erfinde nichts neues, sondern nutze das, was da ist. Z.B. hat Paypal garnicht den Anspruch, die Identität des Kontoinhabers zu prüfen, sondern nur die Existenz des Kontos. Und das funktioniert mit einer Überweisung problemlos.
Das PGP Web of Trust bietet dir alles, was du zur Sicherstellung der Authentizität des Keys und des Besitzers bzw. der Besitzerin brauchst. Denk dir auf Basis dieses Trust Models etwas aus, z.B. die persönliche Zustellung eines Yubikeys mit einem PGP Keypair drauf, das vom Admin des Unternehmens erstellt und von ihm/ihr und seinen/ihren KollegenInnen signiert wurde, sofern dies mit dem Angreifermodell zusammenpasst (der Admin also nicht Angreifer ist). Wenn dieser Ansatz nicht anwendbar ist, dann nimmt S/MIME und kauf dir für die paar € ein Zertifikat, das deinem Sicherheitsbedürfnis entspricht (Smartcard-Zertifikat vs. Software-Zertifikat, aufwändiger vs. einfacher Identifizierungsprozess, usw..). Alles andere ist unsicher.

Gekaufte Zertifikate kommen in diesem Fall einfach nicht in Frage.
Auch der ANsatz mit dem Web of Trust ist imo nicht anwendbar, denn der externe Mitarbeiter ist ja dann noch immer nicht authentifiziert. Aber gerade um diesen geht es ja.

Ich glaube ich habe mich ganz einfach nicht klar ausgedrückt: Das zu lösende Problem ist:
Alice aus der Firma gibt Bob ein Firmengeheimnis in die Hand.
Deswegen will Alice ganz sicher sein, dass Bob Bob ist.


Der Kern meines Konzepts ist, wie ja auch im Titel angetönt, dass du heutzutage keine Überweisung ohne deinen richtigen Namen im "Absender" tätigen kannst (wir gehen von normalen Girokonten aus) und sozusagen die Bank dafür benützt, den Überweiser zu authentifizieren.

 

[Sentrax]

Moin

Der Kern meines Konzepts ist, wie ja auch im Titel angetönt, dass du heutzutage keine Überweisung ohne deinen richtigen Namen im "Absender" tätigen kannst (wir gehen von normalen Girokonten aus) und sozusagen die Bank dafür benützt, den Überweiser zu authentifizieren.

Genau da liegt dein Problem. Du verwendest ein System, das nicht teil deines Sicherheitskonzeptes ist, nicht deiner Kontrolle unterliegt und dir die gewünschten Funktionen nicht garantiert.

Das kann nur schief gehen, wie das m-tan Verfahren ganz deutlich gezeigt hat. Da haben die Banken auch angenommen, das die Mobilfunkprovider die SIM ihrer Kunden auf eine bestimmte Weise behandeln.

Ein Sicherheitssystem kann nur dann sicher sein, wenn alle Komponenten Teil deines Konzeptes sind und du die auch kontrollieren kannst.

Mir ist auch noch immer nicht klar, welche Anforderung Du mit der Banküberweisung erfüllen willst.

Für die sichere Schlüsselübermittlung zwischen 2 bekannten Personen gibt es schon erprobte kryptographische Verfahren. Die müsst ihr nicht neu erfinden.
Das eigentliche Problem ist die Identifizierung der Kommunikationspartner und der erste Schlüsselaustausch. Danach kann man mit dem sicher ausgetauschten Schlüsselpaar beliebig Schlüssel (Stw. Sessionkeys) austauschen.

Sentrax

 

[SchwarzeBeere]

Das funktioniert ganz sicher nicht!
Dafür ist ja die Banküberweisung da. Du müsstest ein Konto haben, dass unter dem Namen "pi()" läuft.

Seit der Einführung von IBAN (und teilweise schon davor) gibt es keine Überprüfung des Namens mehr bei einer Überweisung. Auch könnte ich einfach behaupten, dass das Konto unter dem Namen eines Partners läuft. Damit ist dein System hinfällig.

Natürlich nicht. Wenn ich schon einen sicheren Kanal hätte, könnte ich ja gleich diesen verwenden oder zumindest einen Schlüssel übertragen.

Damit hast du das Problem erfasst. Wenn der Bank-Channel unsicher ist, dann bringt dein System gegenüber dem bisherigen Vorgehen keinen weiteren Nutzen, sondern erhöht nur den Aufwand, denn nun musst du noch zusätzlich eine Nonce per Telefon austauschen. Das macht in der Praxis auch kein Mitarbeiter mit ("Jetzt habe ich dich eh schon am Telefon, lass es uns doch abkürzen und ich geb dir hier den öffentlichen Fingerprint."). Wenn du die Stimme als Authentifizierungsmerkmal hernimmst, dann kannst du auch gleich den Fingerprint austauschen. Das ist dann wieder sicherer als eine einfache SMS. Allgemein stehst aber auch hier wieder vor dem Problem, dass es von Mitarbeitern aufgrund von Faulheit oder Nachlässigkeit umgangen werden kann. Und es ist trotzdem nicht bekannt, wer am anderen Ende der Leitung ist, wenn man sich nie persönlich getroffen hat oder eine vertrauenswürdige dritte Partei die Identität beweist.

Auch der ANsatz mit dem Web of Trust ist imo nicht anwendbar, denn der externe Mitarbeiter ist ja dann noch immer nicht authentifiziert. Aber gerade um diesen geht es ja.

Ich glaube ich habe mich ganz einfach nicht klar ausgedrückt: Das zu lösende Problem ist:
Alice aus der Firma gibt Bob ein Firmengeheimnis in die Hand.
Deswegen will Alice ganz sicher sein, dass Bob Bob ist.

Dein Problem lässt sich auf das Problem des sicheren Schlüsselaustausches reduzieren. Hierfür gibt es zwei grundlegende Lösungen, wenn man mal von esoterischen Ansätzen absieht:
1. Hierarchischer/PKI-Ansatz -> S/MIME
2. Verteilter/WOT-Ansatz -> PGP inkl. Keyserver

Beide Ansätze haben gemein, dass sie die Meinung von Dritten einbeziehen. Bei S/MIME sind das Zertifizierungsstellen, bei PGP das WOT. Du versuchst nun einen eigenen Ansatz - .. ok.. mit PGP als Schlüsselcontainer... - für ein Problem zu entwickeln, das seit gut 40 Jahren in der Wissenschaft erforscht wird. Mit diesem Vorgehen wirst du mit sehr hoher Wahrscheinlichkeit zum Scheitern verurteilt sein.

Dass die Identität des externen Mitarbeiters nicht bekannt ist, ist ein Grund dafür, dass sich PGP nie wirklich weit verbreitet hat, sondern meist ein Inseldasein innerhalb eines Unternehmens fristet. Aber mal eine andere Frage: Warum nicht den Schlüsselaustausch bei Vertragsabschluss durchführen? Mit irgendwem vom Unternehmen musst du doch mal persönlichen Kontakt gehabt haben. Oder läuft alles nur über Mails und Telefon ab? Dann wäre die Herausgabe jedes Firmengeheimnisses grob fahrlässig und der Einsatz von PGP nur nutzlose Makulatur..

 

[pi()]

Danke für eure Zeit.

Also: Vielleicht war ich nicht deutlich genug, aber es ging niemals um den Schlüsselaustausch. Es war von Anfang an nur ein Authentifizierungsproblem. Ich wüsste jetzt aber auch nicht, wie ich es noch deutlicher hätte sagen können, denn sogar der Titel beschreibt es ja.


Dass sich PGP dafür nicht eignet (Authentifizierung!) das glaub ich auch.

Seit der Einführung von IBAN (und teilweise schon davor) gibt es keine Überprüfung des Namens mehr bei einer Überweisung. Auch könnte ich einfach behaupten, dass das Konto unter dem Namen eines Partners läuft. Damit ist dein System hinfällig.

Genau das wollte ich wissen. Danke.
D.h. also, eine Banktransaktion eignet sich zur Authentifizierung auch nicht.



Wie gesagt habe ich den Mitarbeiter noch nie gesehen und wir sind viele Kilometer entfernt. Persönlichen Kontakt hatte ich noch mit niemandem von diesem Unternehmen. Seine Stimme könnte ich aber trotzdem keinen. Ich könnte ihn ja zum Beispiel schon im Fernsehen gesehen haben.


Somit hab ich eigentlich schon meine Antwort. Eine wirklich ordentliche Authentifizierung ohne persönlichen Kontakt gibt es bis heute noch nicht.

Das ist eben ein bis heute ungelöstes Problem. Aber eine sehr interessante Challenge.

Und ich wage es immer noch zu behaupten, dass eine olle Handynummer zur Authentifizierung viel Aufwand für wenig Sicherheit ist und das die Stimme noch eines der besseren Dinge ist. Ich hätte gehofft, dass eine Banktransaktion nicht anonym gemacht werden kann. Schade, dass dem nicht so ist.

Allerdings: wenn auf der Banktransaktion mein Name steht. Wie hoch ist die Wahrscheinlichkeit, dass dies jemand gefälscht hat? Wir könnten ja auch einfach sagen: anonyme Transaktionen sind nicht erlaubt weil sie sich zur Authentifizierung nicht eignen.



Nachtrag:

Ein Sicherheitssystem kann nur dann sicher sein, wenn alle Komponenten Teil deines Konzeptes sind und du die auch kontrollieren kannst.

Bitte verzeih mir meine Direktheit, aber diese Aussage ist völliger Unsinn. Oder aber ich habe dich falsch verstanden. Was meinst du denn genau? Könntest du es noch einmal anders formulieren? Hast du ein Beispiel?

Mir ist auch noch immer nicht klar, welche Anforderung Du mit der Banküberweisung erfüllen willst.

Die Bank authentifiziert Bob.

Für die sichere Schlüsselübermittlung zwischen 2 bekannten Personen gibt es schon erprobte kryptographische Verfahren.

Darum geht es aber nicht. Es geht um Authentifizierung. Das sagt ja auch der Titel des Threads.

 

[SchwarzeBeere]

Die Authentisierung der Kommunikationspartner ist Teil des Schlüsselaustauschproblems in Konstellationen, in denen die Kommunikationspartner unbekannt sind. Und letzten Endes lässt sich dein Problem auf das eines Schlüsselaustausches zurückführen und es mit PGP lösen: Du generierst einen symmetrischen Schlüssel, verschlüsselst damit deine Nachricht und verschlüsselst diesen Schlüssel mit dem öffentlichen Schlüssel des Empfängers. Das ganze unterfüttest du mit einer Signatur, die du mit deinem privaten Schlüssel erstellst. D.h. am Ende ist dein Problem ein klassisches Schlüsselaustauschproblem, bei dem die Authentisierung der Kommunikationspartner eine Rolle spielt. Und hierfür gibt es eben nur zwei bekannte Ansätze.

Dass sich PGP dafür nicht eignet (Authentifizierung!) das glaub ich auch.

Doch, PGP macht genau das! Das Vertrauen in einen Schlüsselbesitzer (owner trust) wird durch den Benutzer gesetzt, der den Schlüssel signiert. Daraus wird die Legitimität des Schlüssels (key legitimacy) berechnet. Mit beiden Werten kannst du sagen, ob der Schlüssel nun zu einem Benutzer gehört und ob dieser Benutzer der ist, für den er sich ausgibt.

Somit hab ich eigentlich schon meine Antwort. Eine wirklich ordentliche Authentifizierung ohne persönlichen Kontakt gibt es bis heute noch nicht.

Das ist eben ein bis heute ungelöstes Problem. Aber eine sehr interessante Challenge.

Ich will dich nicht enttäuschen, aber dieses Problem ist gute 40 Jahre alt und aus theoretischer Sicht in der Praxis mit PGP und S/MIME gelöst. Das Unternehmen, für das du arbeitest, hat leider weder das eine, noch das andere Konzept verstanden und nutzt PGP heute lediglich als Container für RSA Keys, weil es zu geizig zu sein scheint, ein anständiges System zu implementieren (z.B. eine eigene PKI für S/MIME oder Zertifikate von Drittanbietern).

Und ich wage es immer noch zu behaupten, dass eine olle Handynummer zur Authentifizierung viel Aufwand für wenig Sicherheit ist und das die Stimme noch eines der besseren Dinge ist. Ich hätte gehofft, dass eine Banktransaktion nicht anonym gemacht werden kann. Schade, dass dem nicht so ist.

Allerdings: wenn auf der Banktransaktion mein Name steht. Wie hoch ist die Wahrscheinlichkeit, dass dies jemand gefälscht hat? Wir könnten ja auch einfach sagen: anonyme Transaktionen sind nicht erlaubt weil sie sich zur Authentifizierung nicht eignen.

Eine anoyme Transaktion ist nicht nötig. Ich als Angreiferin kann ja durchaus auf dem Kontoauszug genannt werden, nur wie stellt der Leser oder die Leserin des Kontoauszugs sicher, dass das Konto zu mir oder zu dir gehört? Vermutlich wieder über die Telefonleitung - ergo kannst du dir das mit dem Bankkonto auch sparen. Und, wie bereits erwähnt, hat ein Bankkonto auch praktische Probleme, wie z.B. erhöhte Datenschutzvorschriften oder Zugriff auf das Empfängerkonto, was in Großunternehmen üblicherweise nur der Buchhaltung vorbehalten ist. Der Aufwand ist daher extrem hoch, weil unterschiedliche Personen im Unternehmen notwendig sind. Dazu braucht eine Transaktion mind. einen Werktag Zeit.

 

[Sentrax]

Moin

Bitte verzeih mir meine Direktheit, aber diese Aussage ist völliger Unsinn. Oder aber ich habe dich falsch verstanden.

Letzteres.

Angenommen, du hast ein Sicherheitskonzept.
In diesem wird eine wesentliche Funktion (Authentifizierung) an einen externen Dienstleister (Bank) ausgelagert.

Diese Funktion wird aber nicht in deinem Konzept beschrieben und festgelegt. Du triffst nur eine Annahme darüber, das diese Funktion auf eine bestimmte Weise funktioniert (s.d.u.).
Die Funktion ist nicht Bestandteil des Sicherheitskonzepte, sondern wird von diesem nur genutzt.
Du hast über keine Kontrolle darüber, da Du die Funktionsweise weder auf technischer noch auf organisatorischer Ebene überwachen oder kontrollieren kannst.

Die Bank authentifiziert Bob.

Das tut sie eben nicht. Das ist deine Annahme und die ist offensichtlich falsch.

a) Die Bank stellt lediglich sicher, das die Personalien des Antragstellers für die Kontoeröffnung bekannt und wahrscheinlich korrekt sind.
(Kontoeröffnung per Skype als Beispiel ist nicht wirklich sicher)
b) Die Daten des Kontos müssen nicht die des Antragstellers sein (Firmen, Vollmacht, etc.).
c) Der Name auf der Überweisung ist der Name des Kontoinhabers, nicht der des Überweisenden.
d) Die Bank stellt nicht sicher, das nur berechtigte Personen Zugriff auf das Konto haben (Stw. Finanzagenten).

Wie gesagt habe ich den Mitarbeiter noch nie gesehen und wir sind viele Kilometer entfernt. Persönlichen Kontakt hatte ich noch mit niemandem von diesem Unternehmen.

Elektronischer Personalausweis, Postident-Verfahren (o.ä.), ...

Das sind erprobte Verfahren, die ziemlich sicher funktionieren.
Da übernimmt eine vertrauenswürdige 3. Partei die Identitätsfeststellung für euch.

Sentrax

 

[pi()]

Hey!

Bitte entschuldigt die lange Abwesenheit. Ich hatte einen sehr langen Post verfasst, der dann leider verloren ging, weil ich mich noch nicht angemeldet hatte als ich auf "Senden" klickte.
Das hat mich dann für einige Tage demotiviert.


Jedenfalls lange Rede kurzer Sinn:
Ohne Zertifikate geht es nicht - sehe ich das richtig? All die Ausweise und so weiter klingen ja ganz nett, besonders die eID, aber das sind ja alles wiederum eine Art Zertifikat oder?


Ist dann nicht die Banktransaktion immer noch besser als ein Handy? Ne simkarte hat ja, außer dass es ein zweiter Kanal ist, überhaupt keinen Authentifizierungswert, weil sich ja jeder so viele kaufen kann wie er will und auch keine Bindung zur Person besteht (zumindest bei Wertkarten - ich persönlich verwende nur Wertkarten).

 

[gerontimo]

Keep it simple

In diesem Thread verschwimmen ein paar Konzepte und deshalb wir alles etwas unübersichtlich. Mein Vorschlag zur Aufräumungsarbeit. 1. Klar herausarbeiten, was mit Identität gemeint ist: Der Name stimmt? Die Person ist identisch mit mit der, für das unsere Behörden einen Personalausweis ausgegeben haben? oder: Die Person hat tatsächlich die Funktion, die bei der Kundenfirma für den Kontakt mit dir vorgesehen ist ? Sowie ich es verstehe, meist du das dritte mit Identität. Dann sind Melderegister und Banken irrelevant. Wenn du die einbeziehst, vergrösserst du nur die Angriffsfläche und machst alles komplexer. Bei asymmetrischen Kryptosystemen gibt es gegen MITM zwei schwierige Stellen. A) Hat sich ein Angreifer während der Kommunikation reingedrängt? Das kannst durch ein gutes Protokoll verhindern. Das war jetzt aber auch nicht dein Problem, wenn ich das richtig verstanden habe. B) Ist der erste Kontakt mit der richtigen Stelle/Person ? Das kann prinzipell nur von ausserhalb des Protokolls, durch eine TTP(Trusted Third Party) sichergestellt werden. Dafür wolltest du die Bank nehmen (das WOT hättest du auch vorschlagen können.) Aber an dieser Stelle solltest du wieder Umwege vermeiden und genau das als TTP verwenden, was ganz direkt beteiligt ist. Hier sollte das m.E. ganz direkt über die Personen laufen, die den Kontakt ganz analog miteinander eingefädelt haben. Derjenige, der für die Fremdfirma agiert muss ganz konkret den geschützten Kontakt vermitteln, z.B. am Telefon: "Unser Herr XY wird mit Ihnen den Kontakt halten und hat folgenden öffentlichen Schlüssel..." (ob der wirklich XY heisst oder wirklich ein Herr ist, ist dabei völlig irrelevant.) Dein Chef gibt das dann an dich weiter. Wenn die das nicht können, ist das einzig sichere, zu der Firma zu reisen, sich vor Ort dem Kommunikationspartner vorstellen zu lassen und mit dem dann unter vier Augen den Schlüsselaustausch vorzunehmen. Alles andere sind Nebelgranaten und unsichere Verkomplizierungen.

 

[gerontimo]

Zwei Anmerkungen zum ersten Posting: 1) SMS is grottenunsicher. 2) Ich verstehe nicht, wozu für jeden Kunden ein neuer PGP-Schlüssel von deiner Firma erzeugt wird. Das öffnet nur eine weiteren Angriffsstelle bei der Weitergabe des neuen Schlüssels. RSA-Schlüssel nutzen sich nicht durch Verwenden ab. Für die Erstkontakte mit euch wäre ein allgemein gültiger PGP-Schlüssel viel geeigneter, der auf einer https-geschützten Website von Euch abgelegt ist. Für den direkten Person zu Person Kontakt solltet ihr dann eure permanenten Schlüssel nehmen und auch nicht jedesmal einen neuen generieren. Oder wollt ihr manuelle Forward Secrecy realisieren - dafür würde aber noch was fehlen ;-)

 

[pi()]

Hey gerontimo!

Spitzen Posts!
Dem ist imo nichts mehr hinzuzufügen.

Außr vielleicht: Dankesehr.

 

[Chromatin]

What about DANE & OpenPGP Key Deployment?

EDIT:

Denn das ist ja das Problem. PGP ist jetzt erstmal als sicher anzusehen. Unser Problem ist auch nicht starke Verschlüsselung sondern Key-Deployment und Verwaltung. Hier kannst du es drehen und wenden wie du willst - das "sicherste" ist eine Face-to-Face Übergabe der Keys oder andere, weitere Verfahren der 2(++) Faktor Authentifizierung. Und das muss, um der Praxis gerecht zu werden, schnell und (technisch) unaufwaendig zu handhaben sein. SMS ist technisch unsicher, ja. Aber mit der SMS alleine kann man ja auch nichts anfangen.

Was ich sagen will ist, das die akademische Diskussion um Sicherheit vollauf berechtigt ist. Andererseits müssen wir aber als Handwerker praktikable Lösungen umsetzen mit denen andere Leute auch arbeiten können. Und da müssen wir mit wenigstens einem schwachen Glied in der Kette arbeiten (was idR menschliches Verhalten ist).

Good enough is still good enough

 

[SchwarzeBeere]

Hier kannst du es drehen und wenden wie du willst - das "sicherste" ist eine Face-to-Face Übergabe der Keys oder andere, weitere Verfahren der 2(++) Faktor Authentifizierung.

Im genannten Prozess findet zu keiner Zeit eine Sicherstellung der Identität statt, trotzdem erfolgt das Rollout von PGP Keys. Den Prozess machst du nicht sicherer, in dem du noch ein Token, ein Zertifikat oder sonst was dazu packst. Wenn man selbst nicht die Aufgabe der Identifizierung übernehmen will, so muss man das Dritte machen lassen. Und dann gibts aus akademischer Sicht nur hierarchische Systeme oder WOTs.

Good enough is still good enough

Was bedeutet "Good enough"? Die Frage hatte ich schon ganz zu Anfang gestellt: Warum macht man diesen Quatsch überhaupt? Wenn man es muss, dann sollte man auch zu Ausgaben bereit sein, zumal die sich im niedrigen 4-stelligen Bereich bewegen würden. Am Beispiel SSLv2 sieht man derzeit schön, was passiert, wenn man nicht "muss", sondern wenn man "will". Oder aus heutiger Sicht wohl schlicht "wollte". Oder es in den letzten 10 Jahren einfach nur für nötig hielt mit dem PKI-Trend zu schwimmen, aber eigentlich keine Ahnung und auch keine wirkliche Zeit zur Auseinandersetzung hatte.

SMS is grottenunsicher.

SMS ist in den meisten Fällen "Good enough". Inzwischen kann man aber natürlich auch einen Schritt weiter gehen: Mobile ID

Ich verstehe nicht, wozu für jeden Kunden ein neuer PGP-Schlüssel von deiner Firma erzeugt wird.

Z.B. damit beim Disclosure eines Schlüssels nicht die Kommunikation mit anderen Kunden betroffen ist. Oder die PGP Einträge enthalten unterschiedliche Informationen, z.B. Business Unit. Im Consulting bzw. in der Arbeit zwischen Unternehmen, bin ich auch schon öfters auf die Situation gestoßen, dass jeder Kunde eine eigene interne PGP Infrastruktur betreibt und eigene Keys ausstellt bzw. nur eigene Zertifikate zulässt. Eine organisationsübergreifende PGP-Implementierung z.B. unter Einbeziehung öffentlicher Keyserver habe ich dagegen noch nie gesehen. Die Folge davon ist natürlich, dass du für jeden Kunden einen eigenen PGP Key hast, möglicherweise sogar auf einem eigenen Gerät, das vom Kunden gestellt wird.

 

[Chromatin]

Was bedeutet "Good enough"?

Das ist ein altes IETF-Mantra und entstammt dem Sinne nach von Dave Clark (We reject Kings and Presidents....).

Es geht übersetzt darum dass Forschung in einem Bereich niemals zu Ende ist aber irgendwann eben ein Punkt kommt, wo man es zu bauen hat (so interpretiert von Fred Baker).

Good enough is good enough to ship.

RFC 7418 - An IRTF Primer for IETF Participants

Was die Anwendung angeht, so ist das noch wieder ein anderes Level. Und da muessen wir eben nutzen was a) möglich ist und b) was im entsprechenden Umfeld praktikabel ist - und man Kunden haben will.

 

[pi()]

acht Jahre später wissen wir dass ich recht hatte