|
|
|
|
|
|
|
|
|
|
|
|
|
|
Komisch, AVM hab ich jetzt nicht gelesen.
|
|
|
|
|
|
|
|
|
|
|
Staatstrojaner wurde gestern abend beschlossen, ohne Änderung. Letzte Fassung erlaubt auch den Abgriff vergangener Kommunikation für Quellen-TKÜ, also das volle Paket an Verarschung wurde durchgedrückt.
|
|
|
|
|
|
|
|
|
|
|
Sehr empfehlenswert zur Erklärung wie das alles jetzt politisch noch durchgedrückt wurde, wie das technisch funktionieren soll und warum das alles Bullshit ist, ist wieder Logbuch-Netzpolitik 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das wird eh vom BVerfG wieder kassiert, Klagen sind ja wohl schon angekündigt.
Dauert nur leider halt wieder.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Herr der Lage
Das wird eh vom BVerfG wieder kassiert, Klagen sind ja wohl schon angekündigt.
Dauert nur leider halt wieder.
| |
Ich bin da nicht mehr sonderlich zuversichtlich. Von den ganzen Überwachungsgesetzen der letzten Jahre wurde nicht ein einziges wieder kassiert. Ich mein hoffen kann man ja immer, aber naja....
Wenn die schon solche Tricks aus dem Hut ziehen
| | | Um die öffentliche Debatte klein zu halten und den Bundesrat zu umgehen, hat die Große Koalition einen Verfahrenstrick angewendet. Statt eines ordentlichen Gesetzgebungsverfahrens haben SPD und CDU den Staatstrojaner in einem ganz anderen Gesetz über das Fahrverbot als Nebenstrafe versteckt. | |
Dann läuft da mehr quer, als man als Außenstehender sehen kann. Wir haben ja immer noch keine öffentliche Debatte, weil die meisten Journalisten von der technischen Komplexität des Themas einfach überfordert sind. Deshalb schreiben die ab was das öffentliche Statement ist, nämlich "Messenger-Überwachung", was einfach total an der eigentlichen Sache vorbeigeht.
Messenger kann man nunmal nicht mehr einfach so überwachen, ohne wahnsinnige Kollateralschäden (Horten von Sicherheitslücken, Abgreifen vergangener oder noch nicht abgeschickter Kommunikation, Schwächung der Sicherheit der Endgeräte, möglicher Missbrauch i.e. Unterschieben von Beweismitteln ...) anzurichten. Das jemandem zu vermitteln, der weder betroffen noch mit den technischen Details vertraut ist, ist unheimlich schwer.
Es ist einfach alles so eine gigantische Sauerei, nicht mal eine Prüfung der Effektivität ist vorgesehen. Die Implementation kann kein unabhängiges Gremium bewerten, weil der scheiss Forderungskatalog geheim ist und geheim geprüft wird - also man wird sich wieder auf Leaks verlassen müssen. Selbst dieses Gesetz haben wir mal wieder nur im Volltext wegen eines Leaks von Netzpolitik.org. Sowas kriegt man von ner großen Koalition, der Teufel weiß wie viel von dem Schaden überhaupt noch reparierbar ist.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von indifferent am 23.06.2017 21:58]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das sieht zugegebenermaßen verdammt gut aus. Schauen wir mal, wie viel Ressourcen die Provider jetzt reinbuttern um auf der Basis die VDS zu zerlegen. Ich will mich nicht zu früh freuen.
Wichtig an der Stelle ist vielleicht noch, dass die Entscheidung nicht anfechtbar und sehr breit gefasst ist. Quasi ne Einladung um auf die Richtlinie zu kacken und sich dann darauf zu berufen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von indifferent am 26.06.2017 23:45]
|
|
|
|
|
|
|
|
|
|
^ "Die Antragstellerin" ist btw. Spacenet.
|
|
|
|
|
|
|
|
|
|
|
Kann mir bitte jemand mit mehr Ahnung die Konklusion des folgenden Artikels auf deutsch uebersetzen? Es geht um einen Angriff auf die FDE in Qualcomm-Smartphones, und ich bin unschluessig ob er Direktzugang gibt oder nur eine Luecke zum Bruteforcen der Passwoerter. So Geschichten wie "nur 20 moegliche PWs bleiben ueber" wuerde ich auch unter Direktzugang fassen.
Mein Wissen endet da, wo von "Keymaster Keys" geredet wird.
http://bits-please.blogspot.de/2016/06/extracting-qualcomms-keymaster-keys.html
Der Artikel ist sehr lang, ich zitier mal die Teile die vermutlich entscheidend sind. Erstens die Kurzfassung des Angriffes selbst:
| | Finally, we have all the pieces of the puzzle. All we need to do in order to extract the KeyMaster keys is to:
Enable the DACR in the TrustZone kernel to allow us to modify the code cave.
Write a small shellcode stub in the code cave which reads the keys from the KeyMaster application.
Hijack the "qsee_hmac" system-call and point it at our shellcode stub.
Call the KeyMaster's key-generation command, causing it to trigger the poisoned system-call and exfiltrate the keys into the shared buffer.
Read the leaked keys from the shared buffer. | |
Und dann noch nen beispielhaften Angriff mit seinem Exploit:
| | Simply invoke the python script fde_bruteforce.py using:
The crypto footer from the device
The leaked KeyMaster keys
The word-list containing possible passwords
Currently, the script simply enumerates each password from a given word-list, and attempts to match the encryption result with the "scrypted intermediate key" stored in the crypto footer. That is, it passes each word in the word-list through the Android FDE KDF, scrypts the result, and compares it to the value stored in the crypto footer. Since the implementation is fully in python, it is rather slow... However, those seeking speed could port it to a much faster platform, such as hashcat/oclHashcat.
Here's what it looks like after running it on my own Nexus 6, encrypted using the password "secret": | |
| | | Lastly, I've also written a script which can be used to decrypt already-generated KeyMaster key blobs. If you simply have a KeyMaster key blob that you'd like to decrypt using the leaked keys, you can do so by invoking the script km_keymaster.py, like so: | |
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von indifferent am 01.07.2017 20:17]
|
|
|
|
|
|
|
|
|
|
Also so wie ich das jetzt verstanden habe ermöglicht das ganze erst Bruteforce Angriffe mit einfachen Passwörtern. Er schreibt ja selbst dass ein langes/kompliziertes Passwort das ganze langwierig und unattraktiv macht.
|
|
|
|
|
|
|
|
|
|
|
Quicko nitpicks und Korrekturen
| | | Apple has automatically enabled Full Disk Encryption (FDE) using an encryption key which is derived from the user's password. | |
Das wird öfter so lapidar hingeschrieben, ist aber immer falsch bzw. wenn es so ist, sind das sehr fehlerhafte Protokolle. Grundsätzlich werden Schlüssel für sowas wie FDE aus einem guten CSPRNG generiert (Data Encryption Key = DEK), und diese Schlüssel werden dann mit einem Schlüssel (dem Key Encryption Key = KEK) der vom Passwort abgeleitet wird (PB-KDF, z.B. PBKDF2 mit nem HMAC oder scrypt, Argon, ...) verschlüsselt (Key Wrap = KW).
Die danach beschriebene FDE von Apple wurde AFAIK danach nochmal deutlich verbessert (separate Keys für Zones, Key-Derivation & Verschlüsselung komplett in der Enclave außerhalb vom AP [Application Processor]). Die Slides dazu wurden bestimmt im pOT rumgereicht...
| | | So how does Android's FDE scheme fare? | |
Der Knackpunkt ist hier, dass das Schema vom KeyMaster keine Hardwaresicherheit bietet, sondern nur eine Isolation zwischen dem kleinen TrustZone-ARM-Chip und dem AP. Das bietet natürlich schon noch einen Sicherheitsvorteil, ist aber eben nicht vergleichbar mit dem HSM-artigen Ansatz, den Apple fährt.
Der Rest vom Post ist dann Exploitation vom dem TrustZone-Dingens, womit man dann alle Schlüsselkomponenten einfach so vorliegen hat, man also das Smartphone nicht mehr braucht, und fröhlich auf seinem GPU/ASIC-Cluster bruteforcen kann.
Der HSM-Ansatz gibt im Gegensatz dazu die Möglichkeit zu sagen "10 Versuche, dann sind die Schlüssel weg". Die 10 Versuche sind unabhängig von was auch immer das Passwort sein mag.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 01.07.2017 21:00]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich bedanke mich für die Antworten. Also doch: Eher halb so wild, auch wenn der Weg zum Exploit echt beeindruckend ist.
| | Zitat von csde_rats
Der Knackpunkt ist hier, dass das Schema vom KeyMaster keine Hardwaresicherheit bietet, sondern nur eine Isolation zwischen dem kleinen TrustZone-ARM-Chip und dem AP. Das bietet natürlich schon noch einen Sicherheitsvorteil, ist aber eben nicht vergleichbar mit dem HSM-artigen Ansatz, den Apple fährt.
Der Rest vom Post ist dann Exploitation vom dem TrustZone-Dingens, womit man dann alle Schlüsselkomponenten einfach so vorliegen hat, man also das Smartphone nicht mehr braucht, und fröhlich auf seinem GPU/ASIC-Cluster bruteforcen kann.
Der HSM-Ansatz gibt im Gegensatz dazu die Möglichkeit zu sagen "10 Versuche, dann sind die Schlüssel weg". Die 10 Versuche sind unabhängig von was auch immer das Passwort sein mag.
| |
Naaaja.
Der beklagenswerte Ist-Zustand (Zitat Buremeyer: Kann mich nicht erinnern mal ein Telefon gehabt zu haben, was die Behörden nicht aufkriegen) hängt meiner Meinung nach vor Allem daran, dass diesem TrustZone Secure Enclave Kram zu viel Vertrauen geschenkt wird weil is halt bequem. Ansich tolle Technik, sehr effektiv, aber nur solange ein starkes PW oder Token oder wattweißich als Geheimnis dient - nicht so.
Für nen Anwalt, Journalisten oder jemanden mit sensiblen Firmengeheimnissen ist das total unbrauchbar. Und ja, die sollten was Anderes verwenden, tun sie aber fast gar nicht.
iPhones halten so 1-2 Jahre, dann gibts nen Weg für Behörden zu bruteforcen. In Israel hat da grade ne hübsche Firma "Cellebrite" für aufgemacht. Hab nicht mehr im Kopf wie viel man pro Telefon blechen muss, aber Staaten können sich auch direkt ne Flat holen.
https://www.heise.de/mac-and-i/meldung/Ueberwachungsfirma-Cellebrite-kann-angeblich-neuere-iPhones-knacken-3634384.html
https://www.derwesten.de/wirtschaft/iphone-entsperrung-israelische-firma-hat-wohl-fbi-geholfen-id11689477.html
Und es ist zwar zu früh um zu sagen obs so bleibt, aber nach 3 Jahren sind dann halt auch die Billighacks draußen die sich jeder Otto auf dem Schwarzmarkt kaufen kann. Die Truecrypt-Box dagegen hab ich noch nicht gesehen.
Ich finde, die bessere Strategie ist, ein starkes FDE-Kennwort zu haben, was vom Entsperrcode getrennt ist. Das gehört als Standardfeature in jedes Smartphone, im Moment gehts afaik nur mit Root und mit manchen Implementationen von Android 7. Wird auch jedes mal wieder zurückgesetzt, wenn man das Entsperrverfahren anfasst. 
Die Rechnung geht natürlich nur dann auf, wenn das Verfahren keine wiklich kritischen Schwächen aufweist. Erst dann wird alles wirklich unberechenbar.
Klar kann man auch noch Smart Cards, GPG, Multilayer Verschlüsselung usw einsetzen, aber das bringt keinem Menschen was, der kein totaler Nerd ist oder reich genug um sich einen dafür zu halten.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von indifferent am 02.07.2017 5:36]
|
|
|
|
|
|
|
|
|
| | Zitat von indifferent
Ich bedanke mich für die Antworten. Also doch: Eher halb so wild, auch wenn der Weg zum Exploit echt beeindruckend ist.
| | Zitat von csde_rats
Der Knackpunkt ist hier, dass das Schema vom KeyMaster keine Hardwaresicherheit bietet, sondern nur eine Isolation zwischen dem kleinen TrustZone-ARM-Chip und dem AP. Das bietet natürlich schon noch einen Sicherheitsvorteil, ist aber eben nicht vergleichbar mit dem HSM-artigen Ansatz, den Apple fährt.
Der Rest vom Post ist dann Exploitation vom dem TrustZone-Dingens, womit man dann alle Schlüsselkomponenten einfach so vorliegen hat, man also das Smartphone nicht mehr braucht, und fröhlich auf seinem GPU/ASIC-Cluster bruteforcen kann.
Der HSM-Ansatz gibt im Gegensatz dazu die Möglichkeit zu sagen "10 Versuche, dann sind die Schlüssel weg". Die 10 Versuche sind unabhängig von was auch immer das Passwort sein mag.
| |
Naaaja.
Der beklagenswerte Ist-Zustand (Zitat Buremeyer: Kann mich nicht erinnern mal ein Telefon gehabt zu haben, was die Behörden nicht aufkriegen) hängt meiner Meinung nach vor Allem daran, dass diesem TrustZone Secure Enclave Kram zu viel Vertrauen geschenkt wird weil is halt bequem. Ansich tolle Technik, sehr effektiv, aber nur solange ein starkes PW oder Token oder wattweißich als Geheimnis dient - nicht so.
| |
Nein. Das ist schlicht nicht das Design dieser Systeme. TrustZone und Freunde bieten hardwarebasierte Kontrolle, der Grund warum Android da auseinander fällt und die Secure Enclave nicht, ist ein Designfehler in KeyMaster. Unter der Bedingung, dass diese Umgebung keine Backdoor hat ¹, muss man richtig schweres Gerät rankarren um da dran zu kommen.
Cellebrite hält sich bedeckt, was genau sie aufmachen können. Ich würde von iOS<=9 ohne Secure Enclave ausgehen; Apple hat viel zu fähige Leute als das die sich ein neues Design in ein paar Monaten zerlegen lassen würden.
FDE im klassischen Sinne ist auf Smartphones quasi egal, weil das eh aufm AP läuft und du nur root sein brauchst, um den DEK auszulesen. dm-crypt & Froinde bringen nur was gegen Angreifer, die keinen Zugriff auf das laufende System haben.
¹ Das ist der Knackpunkt bzgl. Spionage.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 02.07.2017 11:27]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
dm-crypt & Froinde bringen nur was gegen Angreifer, die keinen Zugriff auf das laufende System haben. | |
Ja, aber das ist doch auch nicht das Szenario vor dem einen ne FDE schützt. Wenn ich eh schon das Gerät verseucht hab, von Root mal ganz zu schweigen, kann ich mir an dem Punkt schon viel leichter direkt nehmen was ich will.
Aus Angreifersicht macht es einfach null Sinn, dann ausgerechnet auf die FDE Keys zu gehen. So ein Typ von Payload hat noch nichtmal nen coolen Kurznamen, weil man gegenüber direktem Angriff sogar noch Zeug verliert - Forward Secrecy, gelöschte Dateien und Nachrichten bis zum physischen Zugriff... oder direkt alles, weil das Ziel sein Handy zwischendurch entsorgt hat.
Insofern sehe ich das auch nicht als die Aufgabe einer FDE. Die kommt zum Tragen, wenn der Angreifer von mir ein verschlüsseltes Gerät bekommt was ausgeschaltet/dismounted ist.
|
|
|
|
|
|
|
|
|
|
|
|
Eben. Wann schaltest du dein Smartphone aus?
|
|
|
|
|
|
|
|
|
|
|
Wenn ich was zu verstecken hätte: Immer dann wenn ich nen Polizisten sehe, bei ner Reise über die Grenze oder im Flugzeug (wenns wer kurz mitnimmt, kommt es in die Tonne, aber die Daten konnten nicht extrahiert werden) ... Oder wenn es in nem Anwaltlichen/Journalistischen/sonstwie Berufsgeheimen Kontext ist immer dann wenn es grad nicht (mehr) gebraucht wird.
Ich halte es nur echt für etwas abwegig, sich mit einer FDE ausgerechnet vor Verseuchung - dem Gegenmittel - schützen zu wollen. Wenn das das Szenario ist, lädt man sich ein ordentliches Livesystem irgendwo runter und benutzt das immer dann wenns kritisch wird.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von indifferent am 02.07.2017 11:59]
|
|
|
|
|
|
|
|
|
|
Was benutzt den der Nerd von heute um seine Festplatten zu verschlüsseln?
|
|
|
|
|
|
|
|
|
|
|
Kann ich so unterschreiben.
|
|
|
|
|
|
|
|
|
|
|
Europaparlament will verschlüsselte Chats gegen Überwachung sichern
Auf europäischer Ebene wird über digitale Sicherheit diskutiert. Die Forderung lautet, Verschlüsselung dürfe nicht durch "Hintertüren", also durch gezielt eingebaute Schwachstellen für Ermittlungsbehörden geschwächt werden.
[... "Dieser Vorschlag] ist eine echte Kampfansage an die EU-Staaten", sagt der grüne EU-Abgeordnete Jan Albrecht. "Die Botschaft ist: Wenn es um den Datenschutz in der elektronischen Kommunikation geht, wollen wir das Niveau eher erhöhen als senken."
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Stryker
Windows? Veracrypt-Partition
Linux? LUKS-Partition, LVM on-top wenn man mehrere Partitionen verschlüsseln will, aber nur einmal PW eingeben.
| |
| | Zitat von indifferent
Kann ich so unterschreiben.
| |
danke!
|
|
|
|
|
|
|
|
|
|
|
ich habe ne frage bezüglich blockieren von bestimmten inhalten und bin hier denke ich am besten aufgehoben:
ich brauche einen wirksamen und zuverässigen filter, um pr0n seiten blockieren zu können. k9 und opendns habe ich bereits getestet, beide haben leider aber lücken bzw. schwächen.
gibt es etwas wirklich sicheres? vielleicht sogar als hardware oder gebührenpflichtig? falls ihr nen tipp habt, freue ich mich!
|
|
|
|
|
|
|
|
|
|
|
Also wenn du mit K9 in Verbindung mit dem OpenDNS FamilyShield nicht zufrieden bist, dann kann dir glaub ich keiner Helfen.
Viel besser wird's nach meinem Kenntnisstand einfach nicht.
|
|
|
|
|
|
|
|
|
|
|
Ah... Sohnemanns erster PC?
Sorry, er wird Porn finden, das kannst du einfach nicht verhindern. 
Tja, Vadder hat mir hier so'n Kindersicherungsprogramm aufgespielt. Keine Ahnung, was das bringen soll, aber wahrscheinlich fühlt er sich damit besser. Zum Glück lässt sich das Ding leicht umgehen, ansonsten hätte ich mir extra für meine Pr0n-Sammlung eine versteckte Linux-Partition anlegen müssen...
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Herr der Lage am 04.07.2017 20:27]
|
|
|
|
|
|
|
|
|
|
Als ob die Gören heutzutage noch Ahnung von PCs hätten. Arschlecken. Da musste dir sowas anhören wie "Was du hast kein Facebook, hast du überhaupt Ahnung vom Internet?"
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Herr der Lage
Ah... Sohnemanns erster PC?
Sorry, er wird Porn finden, das kannst du einfach nicht verhindern. | |
Jenes. Spar dir den Pornofilter. 
|
|
|
|
|
|
|
|
|
|
|
|
Wer gibt den Balgen Adminrechte ?
|
|
|
|
|
|
|
|
|
|
|
Unsere Eltern!
/
Und es war gut!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von monischnucki am 04.07.2017 20:51]
|
|
|
|
|
|
| Thema: Verschlüsselung und Anonymität III ( Privatsphäre jetzt ) |
![AUP [2XS]Nighthawk 04.05.2015](./avatare/upload/U37801--schlafmutze.png)
