"Regierung schaltet De-Mail ab"
So, können wir jetzt dann bitte flächendeckend GPG oder wenigstens X.509 aka S/MIME einführen? -.-
Schlagwort-Archive: GPG
adlerweb // BitBastelei 2023-06-08 14:24:42
adlerweb // BitBastelei 2023-06-08 14:24:42
adlerweb // BitBastelei 2023-06-08 14:24:42
adlerweb // BitBastelei 2023-06-08 14:24:42
Yubikey: Nicht ganz unkaputtbar
tl;dr: YubiKeys nicht am Schlüsselbund festmachen
Wenn es um Security-Tokens geht, hat YubiCo mit seinem YubiKey klar die Nase vorn. Nicht zuletzt, da diese so ziemlich die ersten Geräte waren, welche die gängigsten Sicherheitsmechanismen in einem Gerät vereinen konnten. Vor allem U2F, TOTP (aka Google Authenticator) und PGP sind bei mir fast dauerhaft im Einsatz. Mit dieser Kombination kann ich 2-Faktor-Anmeldung auf Webseiten nutzen, E-Mails signieren und entschlüsseln, mich auf SSH-Servern anmelden und Zugriff auf lokale Dateien und Programme absichern. Auch Zertifikate, aka X.509, sind eine praktische Sache, können sie doch für Logins in Windows-Netzen, S/MIME oder das signieren von Dokumenten unter Windows genutzt werden. Zwar lassen sich all diese Mechanismen auch ohne Dongle nutzen, dieser bringt jedoch zwei wichtige Sicherheitsverbesserungen mit sich: Der Zugriff ist nur möglich, wenn das Gerät eingesteckt ist, sodass eine „versehentliche“ Nutzung erschwert wird. Zudem sind die privaten Schlüssel auf einem – vorzugsweise sicheren – Microcontroller gespeichert und können das Gerät nicht mehr verlassen.
Ich selbst bin Ende 2016 auf den YubiKey NEO * umgestiegen. Dieser kann per USB oder NFC genutzt werden. Letzteres ist z.B. für Logins oder Mailverkehr am Handy interessant. Etwas bedenken hatte ich, da USB-Sticks bei mir selten lange überleben und ein YK nicht gerade günstig ist. Das Werbesersprechen „unkaputtbar“, die robust aussehende Form und Empfehlungen aus dem Bekanntenkreis überzeugten jedoch am Ende. Seit dem ist er Stammgast an meinem Schlüsselbund, somit ständiger Begleiter und wird entsprechend viel genutzt.
Schnellvorlauf November letzten Jahres, also 2 Jahre nach dem Kauf. Einiges hatte sich getan, aber der YK verrichtete noch anstandslos seine Dienste. Also fast. Von einem Tag auf den Anderen war NFC nicht mehr nutzbar und ich somit auf die Nutzung am PC beschränkt. Kein Beinbruch, Handy-Logins nutze ich eher selten, allerdings auch kein Pluspunkt für mein Vertrauen in die Haltbarkeit. Ich vermutete einen Softwarefehler, alternativ eine Einwirkung durch statische Aufladung. Beides Dinge, die nicht passieren sollten. Auch sonst zeigten sich Schwächen: Aus Sicherheitsgründen ist es nicht möglich die Firmware der Geräte zu aktualisieren. Hierdurch war ich bei PGP auf Keys mit maximal 2048 Bit limitiert. Noch OK, aber auch nicht toll. Einzige Möglichkeit auch in den Genuss neuerer Verfahren zu kommen wäre ein neueres Modell, diese hatten zum damaligen Zeitpunkt jedoch kein NFC und nutzten für PGP nun statt einer Open-Source-Lösung eine Eigenentwicklung des Herstellers, welcher sich nicht einsehen ließ.
Meh. Roughly 2 years after I bought my @yubico #Yubikey Neo it already failed. USB luckily still OK, but NFC completely dead. Really hoped these things would be more durable :<
adlerweb|BitBastelei@adlerweb, 2018-11-21
Da die neueren Modelle für mich keine Option waren wandte ich mich via Twitter an den Hersteller. Unter „unkaputtbar“ verstehe ich etwas Anderes, als 2 Jahre und somit knapp über den regulären Gewährleistungen. Meine Intention: Ich wollte wissen was da schief gelaufen ist, ob es eventuell durch einen Reset o.Ä. behoben werden kann, wie man das verhindern kann und ob bei zukünftigen Modellen dieses Problem umgangen werden kann. Man verwies mich auf das Ticketsystem, antwortete dort jedoch nur mit Textblöcken. Nach meiner Info, dass ich die Diskusion in dem Fall für Sinnlos hielt bot man mir den Austausch gegen einen neuen Neo an. Da auf Grund der alternden PGP-Unterstützung und der unbekannten Fehlerursache das Modell eher auf meiner Abschussliste war lehnte ich dankend ab und nutzte mein Modell per USB weiter.
10 Monate später sprach mich ein Mitglied des lokalen Hackerspace auf den YubiKey an. Ein Arbeitskollege hätte da einen unschönen Ausfall mit seinem Key gehabt. Das ABS-Gehäuse wäre durch den Schlüsselring durchgescheuert und das Gerät hätte den Dienst versagt. Könnte das mit meinem Problem zu tun haben? Sure enough: Auch bei mir ist das Plastik im Bereich des Schlüsselrings schon sehr abgenutzt. Dass das ein technisches Problem verursachen könnte hatte ich gar nicht auf dem Schirm.
Zudem: ABS? Durchscheuern? Ich hatte vermutet, dass unter der Plastik-Packung noch ein Metallring eingearbeitet wäre, welche das ganze etwas verstärkt. Aber jetzt, wo ich das höre – hm, ja, da reflektiert ja etwas. Ein Blick unter dem Mikroskop verrät recht schnell, was mein NFC getötet hat: die Antenne ist um das Schlüsselring-Loch gelegt und inzwischen durchgescheuert. WTF.
Erinnert Ihr euch dran, dass ich ABS sagte? ABS kennt man ja auch von 3D-Druckern, hier ist es üblich mit Aceton das Plastik nach dem Druck anzulösen und zu glätten. Mit entsprechenden Konzentrationen kann man das Plastik aber auch einfach wegschmelzen. Exakt dies hat HexView mit einem YubiKey Neo gemacht, sodass sich das Innenleben in voller Pracht bewundern lässt. Glücklicherweise sieht es so aus, als ob hier wirklich nur die Antennen vorbeilaufen und ein Ausfall eher nicht wahrscheinlich ist. Trotzdem würde ich jedem mit YubiKey NEO raten, an dieser Stelle mit Aceton das Plastik anzulösen und mit mehr ABS oder gar einem Metallring zu verstärken um Ausfälle durch Abnutzung zu vermeiden.
Ich selbst bin etwa an selber Stelle wie vorher: Ich werde den NEO wohl weiter nutzen. Zwar hat man inzwischen den YubiKey 5 NFC * herausgebracht, welcher wieder NFC kann, auch längere Keys für PGP unterstützt und das bei mir ursächliche Schlüsselring-Loch verstärkt hat, allerdings sind mir sowohl die fehlenden Quellen als auch die unschöne Reaktion des Supports doch eher sauer aufgestoßen. Hätte man mir bei meiner Nachfrage geantwortet, dass es vermutlich ein bekanntes Problem wäre und man das in der nächsten Produktversion angehen würde – ich hätte sie vermutlich direkt nach dem Release hier liegen gehabt. Leider mangelt es aber auch an Konkurrenz. Viele Keys wie z.B. Thetis oder Googles TitanKey nutzen ausschließlich U2F. Toll für’s Web, aber meine Hauptanwendung ist eher PGP. TOTP sucht man bei allen vergeblich, ließe sich mit etwas Gebastel aber halbwegs brauchbar in Software nachbilden – freie Standards haben so ihre Vorteile. Etwas besser sieht es bei NitroKey aus, hier ist GPG, TOTP und X.509 verfügbar. Leider ist U2F nur als separates Gerät erhältlich und TOTP mit 15 Einträgen etwas knapp (YubiKey Neo 28, YubiKey 5: 32). Da es sich um einen freien Algorithmus handelt könnte man aber, zumindest bei der TOTP-Limitierung, mit etwas Software nachhelfen. Ein Auge habe ich zudem noch auf Somu. Dieses Crowdfunding-Projekt dreht sich primär um einen U2F und FIDO2-Stick, als Stretch-Goal hat man jedoch GPG und SSH auf dem Plan. Alles soll am Ende Open Source sein, was sich auch eher positiv anhört. Ob sie am Ende liefern können, was sie versprechen, werde ich dann ja sehen.
In eine vorherigen Variante des Artikels wurde angegeben, dass NitroKey kein TOTP könne. Dies ist nicht korrekt, sowohl Nitrokey Pro 2 und Nitrokey Storage 2 können jeweils 15 TOTP-Einträge speichern.
YubiKey: GPG-Kartenfehler / Sharing Violation unter Windows
Ugh – Windows und Sicherheitsfunktionen passt irgendwie immer noch nicht zusammen. Schon länger nutze ich einen YubiKey als GPG-Smartcard um E-Mails zu signieren und entschlüsseln. Das funktionierte mit GPG4Win und Thunderbird bisher auch recht brauchbar – also bis auf den Windows-GPG-Agent-Bug.
Wie gesagt: Bisher. Heute dann ein etwas seltsamer Bug:
# gpg --card-status gpg: selecting openpgp failed: Card error gpg: OpenPGP card not available: Card error
Wat. Schnell nochmal den Daemon durchstarten: Nix. Im Log findet man folgende Info:
scdaemon: pcsc_connect failed: sharing violation (0x8010000b) scdaemon: reader slot 0: not connected
Bild: https://www.adlerweb.info/blog/wp-content/uploads/2017/02/wp-1485952629803-300×225.jpgWait. Sharing violation? Greift sonst noch wer zu? Jepp, natürlich tut das Jemand. Ich hatte zwischenzeitlich auf dem YubiKey für ein anderes System X.509-Zertifikate (aka PIV) eingerichtet. Diese kommen z.B. zur Authentifizierung zum Einsatz und können unter Windows auch z.B. für Remote-Logins und das entschlüsseln von Bitlocker-Festplatten verwendet werden. Entsprechend hat nun also auch Windows die PIV-Smartcard gefunden und belagert das Device dauerhaft – somit ist der Zugriff für gpg nicht mehr möglich. Abhilfe schafft hier den Dienst „CertPropSvc“ (aka „Zertifikatverteilung“) zu beenden bzw. neuzustarten. In letzterem Fall bleibt das Gerät frei bis man die nächste Software mit PIV-Zugriff (z.B. Remotedesktop) startet.
Also als weiterer Punkt auf dem nicht enden wollenden Wunschzettel für einen würdigen Nachfolger für die leider sicherheitstechnisch bedenklich gewordenen YubiKeys: Parallelität der SC-Reader…
Windows/GPG/Smartcard – GPG mit Powershell bei SC-Verbindung neu starten
Beim Thema E-Mail-Verschlüsselung ist GPG weit verbreitet. Die Gundfunktionen sind z.B. mit Thunderbird und Enigmail oder gar eine Appliance auch für Einsteiger nutzbar und durch das WoT erstpart man sich die Abhängigkeit von – teils Zweifelhaften – zentralen Zertifizierungsstellen. Ich selbst nutze seit einiger Zeit keinen Softwareschlüssel sondern ein dediziertes HSM (Hardware Security Module) in Form eines YubiKey. Hiermit befindet sich der Key nicht mehr auf dem PC und auch die Verschlüsselung/Signierung läuft in Teilen auf dem Prozessor des YubiKey. Was unter Linux ohne große Änderungen funktioniert macht bei Windows eher wenig Spaß. Zwar ist auch GPG4Win in der Lage mit CryptoCards & Co umzugehen, häufiges Ein- und Ausstecken führt jedoch schnell zu einem hängenden GPG-Agent oder Absturzen der scdaemon.exe (GPG SmartCard Daemon). Einzige Abhilfe: Alle GPG-Prozesse beenden und neu starten. Da Verschlüsselung und Windows ohnehin eher selten zu finden ist sind auch Informationen dazu dünn gesät. Da ich teilweise um das System aus Redmond nicht herum komme und ein Fix in GPG4Win nicht in Sichtweite ist muss also wieder einmal der Holzhammer her: Irgendwie muss beim Einstecken des USB-Gerätes das GPG-System zurückgesetzt werden.
Also frisch ans Werk. Als Sprache soll mal wieder Powershell herhalten – direkt verfügbar, halbwegs systemnah, sollte passen. Über WMI kann man sich auch über ab- und angesteckte Geräte informieren lassen. Leider konnte ich keine Möglichkeit finden weitere Infos wie z.B. Hersteller oder Treiber gleich mit zu erhalten. Da sonst eher wenig Gerätefluktuation zu erwarten ist ziehe ich die „passt scho“-Karte und werde das GPG-System bei jedem neu auftauchenden Gerät einmal zurücksetzen.
#Requires -version 2.0 Register-WmiEvent -Class Win32_DeviceChangeEvent -SourceIdentifier deviceChange write-host (get-date -format s) " Beginning script..." do { $newEvent = Wait-Event -SourceIdentifier deviceChange $eventType = $newEvent.SourceEventArgs.NewEvent.EventType $eventTypeName = switch($eventType) { 1 {"Configuration changed"} 2 {"Device arrival"} 3 {"Device removal"} 4 {"docking"} } write-host (get-date -format s) " Event detected = " $eventTypeName $newEvent.SourceEventArgs.NewEvent | fl if ($eventType -eq 2) { write-host (get-date -format s) " Starting task in 3 seconds..." start-sleep -seconds 3 taskkill /T /F /IM gpg-agent.exe taskkill /T /F /IM scdaemon.exe taskkill /T /F /IM kleopatra.exe start -FilePath 'C:\Program Files (x86)\GNU\GnuPG\gpg-agent.exe' -ArgumentList '--daemon' -WorkingDirectory 'C:\Program Files (x86)\GNU\GnuPG\' -LoadUserProfile -WindowStyle Minimized } Remove-Event -SourceIdentifier deviceChange } while (1-eq1) #Loop until next event Unregister-Event -SourceIdentifier deviceChange
Das Grundkonstrukt selbst scheint von Andy.L13 zu stammen, die kläglichen versuche von Mass-Storage auf andere USB-Geräte umzustellen stammen von mir. In Zeile 24 kann man für WindowStyle statt Minimized auch Hidden nutzen um das Ganze im Hintergrund laufen zu lassen – ich bevorzuge ein optisches Feedback. Das Script kann passend in Autostart oder als geplanter Task verstaut werden.
Sicher keine saubere Lösung, aber „works for me“.
Edit: Stackoverflow (bzw warriorpostman) liefert…
Das folgende Script reagiert nur noch auf den vom YubiKey emulierten Smartcard-Reader. Das Objekt $Event.SourceEventArgs.NewEvent.TargetInstance sieht wie folgt aus – die Informationen für’s Query sollten sich im Gerätemanager finden lassen:
__GENUS : 2 __CLASS : Win32_PnPEntity __SUPERCLASS : CIM_LogicalDevice __DYNASTY : CIM_ManagedSystemElement __RELPATH : Win32_PnPEntity.DeviceID="USB\\VID_1050&PID_0116&MI_02\\6&***&0&0002" __PROPERTY_COUNT : 24 __DERIVATION : {CIM_LogicalDevice, CIM_LogicalElement, CIM_ManagedSystemElement} __SERVER : TESTRECHNER __NAMESPACE : root\CIMV2 __PATH : \\TESTRECHNER\root\CIMV2:Win32_PnPEntity.DeviceID="USB\\VID_1050&PID_0116&MI_02\\6&***&0&0002" Availability : Caption : Microsoft Usbccid-Smartcard-Leser (WUDF) ClassGuid : {50dd5230-ba8a-11d1-bf5d-0000f805f530} CompatibleID : {USB\Class_0b&SubClass_00&Prot_00, USB\Class_0b&SubClass_00, USB\Class_0b} ConfigManagerErrorCode : 0 ConfigManagerUserConfig : False CreationClassName : Win32_PnPEntity Description : Microsoft Usbccid-Smartcard-Leser (WUDF) DeviceID : USB\VID_1050&PID_0116&MI_02\6&***&0&0002 ErrorCleared : ErrorDescription : HardwareID : {USB\VID_1050&PID_0116&REV_***&MI_02, USB\VID_1050&PID_0116&MI_02} InstallDate : LastErrorCode : Manufacturer : Microsoft Name : Microsoft Usbccid-Smartcard-Leser (WUDF) PNPDeviceID : USB\VID_1050&PID_0116&MI_02\6&***&0&0002 PowerManagementCapabilities : PowerManagementSupported : Service : WUDFRd Status : OK StatusInfo : SystemCreationClassName : Win32_ComputerSystem SystemName : TESTRECHNER PSComputerName : TESTRECHNER
Ich werde mich am Service WUDFRd (aka Gerät mit Windows SmartCard-Treber) orientieren. Prinzipiell könne man aber auch auf die USB-ID triggern uns so Scripte bauen, welche bei einstecken eines USB-Sticks ein Backup durchführen oder bei verbinden einer unbekannten USB-Tastatur entsprechend reagieren (böse Ente). Das zugehörige Script:
$query = "Select * FROM __InstanceCreationEvent WITHIN 2 WHERE TargetInstance ISA 'Win32_PnPEntity' AND TargetInstance.Service = 'WUDFRd'" if( Get-EventSubscriber | Where-Object {$_.SourceIdentifier -eq "YubiHammer"}) { Unregister-Event YubiHammer } Register-WmiEvent -Query $query -SourceIdentifier YubiHammer -Action{ $Global:RemoteProcMon=$event start-sleep -seconds 3 taskkill /T /F /IM gpg-agent.exe taskkill /T /F /IM scdaemon.exe taskkill /T /F /IM kleopatra.exe start -FilePath 'C:\Program Files (x86)\GNU\GnuPG\gpg-agent.exe' -ArgumentList '--daemon' -WorkingDirectory 'C:\Program Files (x86)\GNU\GnuPG\' -LoadUserProfile -WindowStyle Minimized }
[Linux/GnuPG] Key-Erstellung nicht möglich: command get_passphrase failed: Operation cancelled
Beim Versuch einen GPG-Key für eine Backupverschlüsselung zu erzeugen bricht GPG an der Stelle, an der nach einem Kennwort gefragt werden müsste, mit folgender Meldung ab:
can't connect to `/home/user/.gnupg/S.gpg-agent': No such file or directory
gpg-agent[4854]: command get_passphrase failed: Operation cancelled
gpg: cancelled by user
gpg: Key generation canceled.
Grund dafür ist offenbar die Art, mit welcher die aktuelle Shell gestartet wurde. Ich nutzte su um von root, mit dem ich die nötigen Pakete installiert hatte, in den Benutzerkontext des Backupnutzers zu wechseln. Dies seint allerdings etwas Chaos bei der Umgebungsdefinition zu verursachen und wird von GPG offenbar nicht unterstützt. Mann muss sich mit dem User direkt auf der Konsole oder per SSH anmelden, dann lässt sich der Schlüssel fehlerfrei generieren. (via christian-stankowic.de)
E-Mail made in Germany?
Da gerade auf einem meiner alten Accounts Werbung für „E-Mail made in Germany“ aufgeschlagen ist erstelle ich dann hiermit mal meine eigene Zertifizierung:
Verschlüsselung zwischen Server und Endgerät
Alle meine E-Mail werden – wie auch bei „E-Mail made in Germany“ zwischen Server und Endgerät mittels TLS (früher SSL genannt) verschlüsselt. Gegen NSA & Co bringt dies natürlich nichts, da diese sich auf Grund der Zentralen Struktur recht einfach eigene, gültige Zertifikate ausstellen können.
Verschlüsselung zwischen Mailervern
Alle E-Mails werden – wenn von der Gegenseite unterstützt – zwischen den Mailservern verschlüsselt übertragen. Dieses Verfahren ist bereits seit Jahren im Einsatz, ist jedoch ebenfalls für Manipulationen auf Infrastrukturebene anfällig. Bei E-Mail-Provider wie z.B. GMX oder T-Online, welche dieses 1999 spezifizierte Sicherheitsverfahren nicht vollständig unterstützen[1], muss die E-Mail auf dieser Strecke unverschlüsselt übertragen werden.
Sichere Rechenzentren
Alle Server stehen in Rechenzentren, welche über eine Zutrittskontrolle verfügen. Da Angriffe üblicherweise über das Internet erfolgen bzw. Behörden mit richterlichem Beschluss hereingelassen werden müssen hat dies auf die Sicherheits allerdings keine Wirkliche Auswirkung.
Datenspeicherung in Europa
Leider befinden sich nicht alle meine Server in Deutschland, jedoch ist Frankreich beim Thema Datenschutz etwa auf deutschem Niveau. Btw: Meine E-Mails werden fast ausschließlich in Deutschland geschrieben, sind also dennoch „made in germany“ 😉
…und ich lege noch drei Punkte oben drauf:
Keine Speicherung bei Cloud-Diensten
Die Daten werden nicht auf den Speicherdiensten von Cloud-Speichern oder CDNs abgelegt, entsprechend ist zumindest grob bekannt an welcher Stelle die Daten liegen.
Die E-Mail nimmt den kürzesten Weg
Daten werden – sofern möglich – auf dem kürzesten Weg übermittelt und nehmen keinen Umweg über Staaten der „Five Eyes“. [2]
Die Mail kommt verschlüsselt!
Jeder, der GPG nutzt und mir seinen öffentlichen Key bereitstellt erhält meine Kommunikation grundsätzlich in Verschlüsselter form – so lässt sich der Mailtext zwischendurch nicht mitlesen oder Manipulieren.
[1] Beim Test am 26.10.2013 wurden eingehende Mails ohne TLS angeliefert
[2] Alle Rechenzentren sind über DeCix verbunden, Traceroutes zu diversen Testsystemen in Deutschland zeigen – im Gegensatz zum Verhalten einiger anderer Provider – keine Umwege über den Ozean.