1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Whatsapp-Alternative: Warum es okay…

Anonymisierung von Telefonnummern gar nicht möglich

Für Konsolen-Talk gibt es natürlich auch einen Raum ohne nerviges Gedöns oder Flamewar im Freiraum!
  1. Thema

Neues Thema Ansicht wechseln


  1. Anonymisierung von Telefonnummern gar nicht möglich

    Autor: mpw1413 29.01.21 - 13:21

    Im Beitrag wird erklärt, dass Signal Telefonnummern anonymisiere, in dem Hashwerte gebildet werden. Das ist 'ne nette Idee, auf Grund der Tatsache, dass es nach dem Nummernschema aber nur wenige Milliarden Kombinationen gibt, kann man „die paar Kombinationen“ mit 'ner handelsüblichen Grafikkarte einfach durchprobieren.

    Anonymisieren eines in der Anzahl beschränkten Raumes ist auf Grund der heute breit zur Verfügung stehenden Rechenleistung gar nicht mehr möglich. Andere Beispiele sind z. B. Autokennzeichen, die man schlicht nicht anonymisieren kann, weil es nur verhältnismäßig wenige Kombinationsmöglichkeiten gibt.

    Das nennt man Pseudoynomisieren.



    1 mal bearbeitet, zuletzt am 29.01.21 13:22 durch mpw1413.

  2. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: mtr (golem.de) 29.01.21 - 13:41

    Hallo mpw1413,

    tatsächlich steht im Beitrag nur, dass Hashwerte gebildet werden - von anonymisieren ist in diesem Kontext nie die rede. Die Hashes werden anschließend in einer SGX-Enklave abgeglichen, die sicherstellen soll, dass Niemand die Hashes sehen kann.

    Viele Grüße
    Moritz

  3. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: JCL 29.01.21 - 18:35

    Was macht es dann für einen Unterschied, Hashwerte zu benutzen?

  4. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: corruption 29.01.21 - 18:39

    Verstehe den Vorteil auch nicht.

    Die Liste der Hash <> Rufnummer Paare kann man sich sehr einfach Vorberechnen. Ich meine wir sprechen hier von 9-12 Zeichen in denen nur Zahlen von 0-9 vorkommen. Was hindert Signal daran die Hashes auf dem Server zu speichern und dann kurz in die Look-Up Table zu schauen zu welcher Rufnummer nun der Hash gehört?^^

    IMO gibt es keinen direkten Sicherheits/Privacy Vorteil. Oder ich sehe ihn einfach nicht. Evt das Leute nicht einfach die Nummer DIREKT anrufen können und erst ein wenig Vorarbeit leisten müssen^^

    Auch die SGX-Enklave bringt nichts. Die Leute können ja den Endpunkt kontrollieren. TLS schützt nur den Transportweg zwischen Endpunkten. Die können also die Daten abfischen, bevor sie in der Enklave ankommen.

    Das löst halt Threema besser... Einfach UUIDs haben für Accounts und die nicht mit Rufnummern verbinden... der Nachteil liegt auf der Hand: Usability leidet... von daher verstehe ich es das Signal es so macht.



    4 mal bearbeitet, zuletzt am 29.01.21 18:48 durch corruption.

  5. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: thymythos 29.01.21 - 19:03

    Im Prinzip alles richtig, aber man kann einen Salt pro Nummer verwenden, was das Vorberechnen unterbindet und man kann eine sehr große Zahl an Hash-Runden verwenden, so dass es auch bei einer Milliarde Möglichkeiten eine Weile dauert.

  6. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: corruption 29.01.21 - 19:11

    Stimmt. Jetzt müsste man nachschauen wieviele Runden tatsächlich gemacht werden. ;)

  7. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: Panzergerd 29.01.21 - 19:11

    Hier erklären sie, wie das funktioniert: https://signal.org/blog/private-contact-discovery/

  8. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: lumpsum 29.01.21 - 19:30

    In dem Dokument wird beschrieben, wie sie den Hash-Vergleich (offenbar gebatcht) in der SGX-Enclave vornehmen.

    Es ändert aber nichts daran, dass immer noch Hashes übertragen werden bzw. die Hashes der registrierten Nutzer gespeichert sind. Letztere wurden zumindest einmal im Klartext übertragen, da Signal eine Verifizierungs-SMS an diese Nummer schicken muss - dies geschieht über den US-Anbieter Twilio.

    Und es setzt halt voraus, dass SGX (eine proprietäre Erweiterung der x86-Architektur von Intel) auch wirklich sicher ist. Meines Wissens wurde die Technologie von den Forschern hinter Spectre und Meltdown (zumindest als Proof of Concept) geknackt.

  9. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: mambokurt 29.01.21 - 19:51

    thymythos schrieb:
    --------------------------------------------------------------------------------
    > Im Prinzip alles richtig, aber man kann einen Salt pro Nummer verwenden,
    > was das Vorberechnen unterbindet und man kann eine sehr große Zahl an
    > Hash-Runden verwenden, so dass es auch bei einer Milliarde Möglichkeiten
    > eine Weile dauert.

    Das mit dem Salt je Nummer kann man machen aber er muss sich irgendwie aus der Nummer ergeben weil der Client ja den Hash seiner bekannten Nummern abfragen muss. Das Hashen kannste auch nur bedingt langsam machen weils ja auf dem Handy läuft (wobei ich nicht mehr weiß wie lange der Abgleich bei mir gedauert hat, kann sein dass das wirklich langsam war).

    Aber letztendlich heisst das trotzdem so jemand wie die Nsa kann vorberechnen. Unterwandern könnte man das mit false positives, der Client schickt 100.000 Anfragen mit den 100 richtigen Nummern dazwischen und der Server antwortet ja oder nein. Irgendwie so dass die Daten dann an sich nicht mehr so viel wert sind....

  10. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: corruption 29.01.21 - 20:04

    mambokurt schrieb:
    --------------------------------------------------------------------------------
    > thymythos schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Im Prinzip alles richtig, aber man kann einen Salt pro Nummer verwenden,
    > > was das Vorberechnen unterbindet und man kann eine sehr große Zahl an
    > > Hash-Runden verwenden, so dass es auch bei einer Milliarde Möglichkeiten
    > > eine Weile dauert.
    >
    > Das mit dem Salt je Nummer kann man machen aber er muss sich irgendwie aus
    > der Nummer ergeben weil der Client ja den Hash seiner bekannten Nummern
    > abfragen muss. Das Hashen kannste auch nur bedingt langsam machen weils ja
    > auf dem Handy läuft (wobei ich nicht mehr weiß wie lange der Abgleich bei
    > mir gedauert hat, kann sein dass das wirklich langsam war).
    >
    Der Salt muss sich nicht aus der Nummer ergeben: Den Salt kannst du einfach mitschicken, zusätzlich zu den Hashes. Der Salt ist kein Geheimnis oder ähnliches. ;)
    Salts werden lediglich eingesetzt um die Entropie zu erhöhen. Das hat zur Folge das man keine vorgefertigte Tabelle als Loop Up nutzen kann sondern diese für jeden Salt generieren müsste. Ein Salt ist also immer public Information.



    1 mal bearbeitet, zuletzt am 29.01.21 20:05 durch corruption.

  11. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: corruption 29.01.21 - 20:08

    lumpsum schrieb:
    --------------------------------------------------------------------------------
    > In dem Dokument wird beschrieben, wie sie den Hash-Vergleich (offenbar
    > gebatcht) in der SGX-Enclave vornehmen.
    >
    > Es ändert aber nichts daran, dass immer noch Hashes übertragen werden bzw.
    > die Hashes der registrierten Nutzer gespeichert sind. Letztere wurden
    > zumindest einmal im Klartext übertragen, da Signal eine Verifizierungs-SMS
    > an diese Nummer schicken muss - dies geschieht über den US-Anbieter
    > Twilio.
    >
    > Und es setzt halt voraus, dass SGX (eine proprietäre Erweiterung der
    > x86-Architektur von Intel) auch wirklich sicher ist. Meines Wissens wurde
    > die Technologie von den Forschern hinter Spectre und Meltdown (zumindest
    > als Proof of Concept) geknackt.

    Genau. Immerhin hilft die SGX Enclave (sofern sicher implementiert) dagegen, das bei einem erfolgreichen Angriff irgendwelche Daten rausgetragen werden können. Daher schon irgendwo wichtig für Defense in Depth.



    1 mal bearbeitet, zuletzt am 29.01.21 20:11 durch corruption.

  12. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: mambokurt 29.01.21 - 20:59

    corruption schrieb:
    --------------------------------------------------------------------------------
    > mambokurt schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > thymythos schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Im Prinzip alles richtig, aber man kann einen Salt pro Nummer
    > verwenden,
    > > > was das Vorberechnen unterbindet und man kann eine sehr große Zahl an
    > > > Hash-Runden verwenden, so dass es auch bei einer Milliarde
    > Möglichkeiten
    > > > eine Weile dauert.
    > >
    > > Das mit dem Salt je Nummer kann man machen aber er muss sich irgendwie
    > aus
    > > der Nummer ergeben weil der Client ja den Hash seiner bekannten Nummern
    > > abfragen muss. Das Hashen kannste auch nur bedingt langsam machen weils
    > ja
    > > auf dem Handy läuft (wobei ich nicht mehr weiß wie lange der Abgleich
    > bei
    > > mir gedauert hat, kann sein dass das wirklich langsam war).
    > >
    > Der Salt muss sich nicht aus der Nummer ergeben: Den Salt kannst du einfach
    > mitschicken, zusätzlich zu den Hashes. Der Salt ist kein Geheimnis oder
    > ähnliches. ;)
    > Salts werden lediglich eingesetzt um die Entropie zu erhöhen. Das hat zur
    > Folge das man keine vorgefertigte Tabelle als Loop Up nutzen kann sondern
    > diese für jeden Salt generieren müsste. Ein Salt ist also immer public
    > Information.

    Das funzt so nicht, die Nummern liegen doch schon gehashed mit ihren Salts auf dem Server, woher soll der Client wissen mit welchem Salt er welche Nummer aus seinem Telefombuch hashen soll? Gar nicht. Und der Server kanns dem Client nicht sagen weil er die Nummer nicht kennt, nur die ganzen Hashes und ihre Salts...

  13. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: corruption 29.01.21 - 21:32

    mambokurt schrieb:
    --------------------------------------------------------------------------------
    > corruption schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > mambokurt schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > thymythos schrieb:
    > > >
    > >
    > ---------------------------------------------------------------------------
    >
    > >
    > > > -----
    > > > > Im Prinzip alles richtig, aber man kann einen Salt pro Nummer
    > > verwenden,
    > > > > was das Vorberechnen unterbindet und man kann eine sehr große Zahl
    > an
    > > > > Hash-Runden verwenden, so dass es auch bei einer Milliarde
    > > Möglichkeiten
    > > > > eine Weile dauert.
    > > >
    > > > Das mit dem Salt je Nummer kann man machen aber er muss sich irgendwie
    > > aus
    > > > der Nummer ergeben weil der Client ja den Hash seiner bekannten
    > Nummern
    > > > abfragen muss. Das Hashen kannste auch nur bedingt langsam machen
    > weils
    > > ja
    > > > auf dem Handy läuft (wobei ich nicht mehr weiß wie lange der Abgleich
    > > bei
    > > > mir gedauert hat, kann sein dass das wirklich langsam war).
    > > >
    > > Der Salt muss sich nicht aus der Nummer ergeben: Den Salt kannst du
    > einfach
    > > mitschicken, zusätzlich zu den Hashes. Der Salt ist kein Geheimnis oder
    > > ähnliches. ;)
    > > Salts werden lediglich eingesetzt um die Entropie zu erhöhen. Das hat
    > zur
    > > Folge das man keine vorgefertigte Tabelle als Loop Up nutzen kann
    > sondern
    > > diese für jeden Salt generieren müsste. Ein Salt ist also immer public
    > > Information.
    >
    > Das funzt so nicht, die Nummern liegen doch schon gehashed mit ihren Salts
    > auf dem Server, woher soll der Client wissen mit welchem Salt er welche
    > Nummer aus seinem Telefombuch hashen soll? Gar nicht. Und der Server kanns
    > dem Client nicht sagen weil er die Nummer nicht kennt, nur die ganzen
    > Hashes und ihre Salts...

    Wenn er abhängig von der Telefonnummer ist kann man ihn sich wieder sparen. Weil dann kann man wieder alle Tabellen vorberechnen. Dauert halt nur etwas länger, aber ist ein einmalige Vorgang. (Statt 1 Tabelle hast du dann X Tabellen) Dementsprechend wäre ein Salt dann einfach nicht gut für den Anwendungsfall geeignet (Und ggf wird aus dem Grund den du beschreibst auch nichts gesaltet: https://signal.org/blog/private-contact-discovery/).
    Danke für den Punkt, habe ich garnicht drüber nachgedacht!

    Dennoch: Salts machen nur dann einen wirklichen Sinn, wenn sie Random sind. Also in dem Anwendungsfall ist ein Salt dann Schwachsinn.

    Im Signal Private Contact Discovery Whitepaper wird zusätzlich explizit geschrieben:
    "The obvious problem with this method is that the hash of a user identifier can almost always be inverted. Regardless of whether the identifier is a phone number, a user name, or an email address, the “keyspace” of all possible identifiers is too small."

    Die sind sich also bewusst, dass die Telefonnummer eine Schwachstelle ist. ;)



    2 mal bearbeitet, zuletzt am 29.01.21 21:38 durch corruption.

  14. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: corruption 29.01.21 - 21:40

    Panzergerd schrieb:
    --------------------------------------------------------------------------------
    > Hier erklären sie, wie das funktioniert: signal.org


    Danke für den Link! Das erklärt doch den Anspruch sehr gut! Und die sind sich selbst bewusst, dass die Telefonnummer eine Schwachstelle ist:
    "The obvious problem with this method is that the hash of a user identifier can almost always be inverted. Regardless of whether the identifier is a phone number, a user name, or an email address, the “keyspace” of all possible identifiers is too small.

    This method of contact discovery isn’t ideal because of these shortcomings, but at the very least the Signal service’s design does not depend on knowledge of a user’s social graph in order to function. This has meant that if you trust the Signal service to be running the published server source code, then the Signal service has no durable knowledge of a user’s social graph if it is hacked or subpoenaed."

  15. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: BLi8819 29.01.21 - 21:51

    Wäre der Hash anonym, würde er nicht mehr für den Zweck genutzt werden können, für den er erzeugt wurde.

  16. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: Dystopinator 30.01.21 - 06:17

    dann brauchst du keine hashes bilden, wenn die sgx enclave sicher für den datenschutz sorgt ...

  17. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: corruption 30.01.21 - 11:04

    Dystopinator schrieb:
    --------------------------------------------------------------------------------
    > dann brauchst du keine hashes bilden, wenn die sgx enclave sicher für den
    > datenschutz sorgt ...

    Signal selbst weiß das: https://signal.org/blog/private-contact-discovery/

    "The obvious problem with this method is that the hash of a user identifier can almost always be inverted. Regardless of whether the identifier is a phone number, a user name, or an email address, the “keyspace” of all possible identifiers is too small.

    This method of contact discovery isn’t ideal because of these shortcomings, but at the very least the Signal service’s design does not depend on knowledge of a user’s social graph in order to function. This has meant that if you trust the Signal service to be running the published server source code, then the Signal service has no durable knowledge of a user’s social graph if it is hacked or subpoenaed."

  18. Re: Anonymisierung von Telefonnummern gar nicht möglich

    Autor: chefin 01.02.21 - 11:39

    mpw1413 schrieb:
    --------------------------------------------------------------------------------
    > Im Beitrag wird erklärt, dass Signal Telefonnummern anonymisiere, in dem
    > Hashwerte gebildet werden. Das ist 'ne nette Idee, auf Grund der Tatsache,
    > dass es nach dem Nummernschema aber nur wenige Milliarden Kombinationen
    > gibt, kann man „die paar Kombinationen“ mit 'ner
    > handelsüblichen Grafikkarte einfach durchprobieren.
    >
    > Anonymisieren eines in der Anzahl beschränkten Raumes ist auf Grund der
    > heute breit zur Verfügung stehenden Rechenleistung gar nicht mehr möglich.
    > Andere Beispiele sind z. B. Autokennzeichen, die man schlicht nicht
    > anonymisieren kann, weil es nur verhältnismäßig wenige
    > Kombinationsmöglichkeiten gibt.
    >
    > Das nennt man Pseudoynomisieren.


    Ein Hashwert kann aber auch mehrer Telefonummmern repräsentieren. Der Nummernschlüssel umfasst 15 Zahlen maximal. Wobei die ersten 1-3 Zahlen Countrycode sind, danach erfolgen nationale Vorwahlen und Rufnummern. (destination und subscriber).

    Wir haben also 12 Ziffern, davon sind bereits 4 für Mobilfunkzuordnung oder Ortskennungen. Es bleiben 8 Ziffern für die persönliche Nummer. Nehme ich nun mal an, das ich weder Land noch Mobilfunk oder Festnetz weis, muss ich also volle 15 Ziffern abarbeiten.

    Hashwerte die groß genug sind, das ich keine Doppelten habe werde, würde es zum rückrechenbaren Pseudonym machen. Wir haben aber 2^48 Möglichkeiten, davon sind bestenfalls 36 Bit real existent. Ausgehend davon das jeder Mensch eine Telefonnummer hat. Wenn ich also dafür sorge das mein Hashwert nur 40 Bit lang ist, habe ich Überschneidungen. 2^8 Telefonnummern pro Hashwert. Manche sind nicht möglich die verwerfe ich. Es dürften damit wohl immer noch einige über sein, die in Frage kommen.

    Im Grundsatz kann ich während Ermittlungen damit meinen Verdächtigen rausfinden und weiter beobachten. Aber für Beweise reicht das nicht.

    Da wir also nicht wissen, wie die Server sich die Hashwerte speichern, ist es Spekulation welchen Beweiswert man damit erreicht. Gut gemacht ist es höchstens in Indiz um einen Verdächtigen aus der Masse rauszufinden. Das aber setzt voraus, das es noch keinen Verdächtigen gibt. Jedenfalls wenn man richterliche Beschlüsse will, braucht es gute Gründe Daten zu bekommen ohne diese einzugrenzen anhand von Verdachtsmomenten.

    Da muss wohl die Zukunft zeigen, ob Signal damit umgehen kann und welche Informationen sich daraus ergeben. Letztendlich weis man nur, das derjenige Signal installiert hat. Mehr nicht.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. 360 Grad IT GmbH, München
  2. Minebea Intec, Aachen
  3. über duerenhoff GmbH, Raum Frankfurt
  4. Basler Versicherungen, Bad Homburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,19€
  2. 11€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme