4096bit RSA Keys mit OpenPGP 2.1 Smartcards
Ich bereite die Einführung einer PGP PKI vor. Dazu habe ich mir ein paar Crypto Hardware Artikel beschafft und werde hier meine Erfahrungen verbloggen. Anfangen möchte ich mit den OpenPGP 2.1 Cards (von Zeitcontrol via Cryptoshop). Die Karten lassen sich direkt in dem connected Smart Card reader meines betagten Dell Latitude E6510 unter Windows 7 ansprechen. Dabei kommt der eingebaute Broadcom Reader zum Einsatz:
c:\Program Files\OpenSC Project\OpenSC\tools>opensc-tool -v -l # Detected readers (pcsc) Nr. Card Features Name 0 Yes Broadcom Corp Contacted SmartCard 0 3b:da:18:ff:81:b1:fe:75:1f:03:00:31:c5:73:c0:01:40:00:90:00:0c CryptoStick v1.2 (OpenPGP v2.0) c:\Program Files (x86)\GNU\GnuPG>gpg2.exe --card-status Application ID ...: D27600012401020100050000xxxx0000 Version ..........: 2.1 Manufacturer .....: ZeitControl Serial number ....: 0000xxxx Name of cardholder: Bernd Eckenfels Language prefs ...: en Sex ..............: männlich
Läßt sich also ohne Probleme sowohl mit OpenSC 0.15.0 Win64 sowie GnuPG 2.0.29 (GPG2Win 2.3.0) ansprechen. Ich konnte mit dieser Kombination auch 3072bit RSA Schlüssel erstellen und nutzen. Problematisch wird es allerdings wenn man 4096bit RSA Schlüssel nutzen möchte. Die Karten bieten diese Option an (deswegen habe ich sie auch ausgewählt). Leider kann der eingebaute Reader keine Extended-APDU, somit schlägt der Versuch fehl entsprechende Keys zu erzeugen (eigentlich sollte er die Keys erzeugen können aber es sieht danach aus dass die anschliessende Übertragung fehlschlägt:
tools> openpgp-tool -r 0 -v --verify CHV3 --pin 12345678 --gen-key 1 --key-len 3072 Connecting to card in reader Broadcom Corp Contacted SmartCard 0... Using card driver OpenPGP card. Fingerprint: 9DA81881C7139920120ABBF8C50BD95C 9A7C7684 tools> openpgp-tool -r 0 -v --verify CHV3 --pin 12345678 --gen-key 1 --key-len 4096 Connecting to card in reader Broadcom Corp Contacted SmartCard 0... Using card driver OpenPGP card. ... multiple minutes later... Failed to generate key. Error Transmit failed. c:\Program Files (x86)\GNU\GnuPG> gpg2.exe --card-status Application ID ...: D27600012401020100050000xxxx0000 Version ..........: 2.1 Manufacturer .....: ZeitControl Serial number ....: 0000xxxx Name of cardholder: Bernd Eckenfels Language prefs ...: en Sex ..............: männlich URL of public key : [nicht gesetzt] Login data .......: [nicht gesetzt] Signature PIN ....: nicht zwingend Key attributes ...: 4096R 4096R 4096R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: [none] ...
Ach ja übrigens, noch ein paar Anmerkungen: Es ist wichtig gpg2.exe (nicht gpg.exe) zu verwenden, bei PGP4Win werden beide binaries in unterschiedlichen Versionen parallel installiert. Bei gpg2 muss man darauf achten dass es auf einige Hintergrundprozesse angewiesen ist (pinentry und scdaemon). Das kann schon mal zu Verwirrungen führen (z.b. Unter älteren Linux Varianten kann sich wohl ein Gnome daemon als pgp-agent ausgeben und dann smartcard befehle abweisen. Mit gpg-connect-agent -v
und dem Befehl SCD GETINFO version
lässt sich prüfen welcher Agent verwendt wird. In meinem Setup hängt sich auch die GPA artenverwaltng auch, habe noch nicht herausgefunden woran dies liegt.
Mit der Verwendung eines externen USB Readers der Extended APDU unterstützt (Gemalto IDBridge Ct710) lässt sich der 4096bit Key erstellen und nutzen:
c:\Program Files\OpenSC Project\OpenSC\tools>opensc-tool -v -l # Detected readers (pcsc) Nr. Card Features Name 0 Yes Broadcom Corp Contacted SmartCard 0 failed: Card not present 1 Yes PIN pad Gemalto IDBridge CT7xx 0 3b:da:18:ff:81:b1:fe:75:1f:03:00:31:c5:73:c0:01:40:00:90:00:0c CryptoStick v1.2 (OpenPGP v2.0) c:> echo debug-all > C:\users\eckenfel\AppData\Roaming\GnuPG\scdaemon.conf c:> echo log file c:/temp/scdaemon.log >> C:\users\eckenfel\AppData\Roaming\GnuPG\scdaemon.conf c:> echo reader-port "Gemalto IDBridge CT7xx 0" >> C:\users\eckenfel\AppData\Roaming\GnuPG\scdaemon.conf c:\Program Files (x86)\GNU\GnuPG> gpg2 --card-edit -v Application ID ...: D27600012401020100050000xxxx0000 Version ..........: 2.1 ... gpg/card> admin gpg/card> generate Make off-card backup of encryption key? (Y/n) n gpg: NOTE: keys are already stored on the card! Replace existing keys? (y/N) y What keysize do you want for the Signature key? (3072) 4096 The card will now be re-configured to generate a key of 4096 bits What keysize do you want for the Encryption key? (3072) 4096 The card will now be re-configured to generate a key of 4096 bits What keysize do you want for the Authentication key? (3072) 4096 The card will now be re-configured to generate a key of 4096 bits ... Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o gpg: writing self signature gpg: RSA/SHA256 signature from: "CE551545 [?]" gpg: writing key binding signature gpg: RSA/SHA256 signature from: "CE551545 [?]" gpg: writing key binding signature gpg: RSA/SHA256 signature from: "CE551545 [?]" gpg: writing key binding signature gpg: RSA/SHA256 signature from: "CE551545 [?]" gpg: writing key binding signature gpg: RSA/SHA256 signature from: "CE551545 [?]" gpg: writing public key to `C:/Users/eckenfel/AppData/Roaming/gnupg/pubring.gpg' gpg: writing secret key stub to `C:/Users/eckenfel/AppData/Roaming/gnupg/secring.gpg' gpg: using PGP trust model gpg: key CE551545 marked as ultimately trusted public and secret key created and signed. pub 4096R/CE551545 2016-06-05 [expires: 2016-06-06] Key fingerprint = 1C93 E95E 0486 C55C 0762 3629 20CC CA05 CE55 1545 uid [ultimate] Bernd Eckenfels (test) <test@test> sub 4096R/F738D4AE 2016-06-05 [expires: 2016-06-06] sub 4096R/309D4991 2016-06-05 [expires: 2016-06-06]
Das Erstellen von 3 Schlüsseln (inkl. Signaturen, ohne Encryption Key backup - d.h. auch auf der Karte erstellt) mit 4096 bit dauert (stark schwankend) 30 Minuten, die selbe Prozedur mit 3072 bit Schlüssel erfolgt in 8 Minuten.
Bei der Erstellung der Schlüssel gibt pgp2 wenige Zwischenschritte aus, man kann das ganze aber im scdaemon logfile nachvollziehen. Wie oben zu sehen war es auch notwendig den Klartext Namen des externen Card Readers zu konfigurieren, scdaemon hat reader-port 1
oder reader-port 32769
(trotz Neustart) schlichtweg ignoriert. Auch wenn der richtige Reader verwendet wird scheint die Debug Ausgabe nur den Slot des Readers aber nicht den gewählten Reader auszugeben:
scdaemon[14808] Handhabungsroutine f³r fd -1 gestartet scdaemon[14808] detected reader `Broadcom Corp Contacted SmartCard 0' scdaemon[14808] detected reader `Gemalto IDBridge CT7xx 0' scdaemon[14808] detected reader `' scdaemon[14808] reader slot 0: not connected
Bei der Key-Erstellung hat gnupg2 das externe Keypad des Gemalto readers für die PIN Eingabe (noch) nicht benutzt.
Falschfarben und hängende Eingabe bei Samsung Galaxy Tab 3 10.1 reparieren
Ich habe schon längere Zeit ein Samsung Galaxy Tab 3 10.1 (GT-P5200). Das Gerät ist den ganzen Tag im Einsatz. Nach einem etwas unfreiwilligen Sturz auf das Laminat zeigte das Tab nur noch sehr grob-pixelige Bilder in Falschfarben an. Das scheint ein relativ weit verbreitetes Problem bei den Geräten zu sein. Leider gab es in den diversen Foren keine wirkliche Hilfe (es ist jedenfalls nicht die "Inverted Screen" Android Funktion für erleichterte Bedienung). Meine Hoffnung war eine lockere Steckverbindung, und so habe ich mich dran gemacht das Gerät selbst zu inspizieren.
Zuerst habe ich ein Youtube Video gefunden bei dem beschrieben wird, wie man den Akku in dem Tab austauscht. Das war sehr hilfreich, dort kann man nämlich erkennen wie man das Gehäuse öffnet. Entgegen meiner ersten Annahme hebelt man es von der Vorderseite aus auf. Leider habe ich nicht das gezeigte Plastikwerkzeug, aber mit einem Messer oder flachen Schraubendreher ist es recht einfach den Rand nach außen zu heben und das Innenleben anzuheben. Im Wesentlichen muss man nur darauf achten nicht zu tief einzustechen.
Nach dem Öffnen sieht man auch gleich drei Flachbandkabel. Zwei davon sind für Display und Digitizer zuständig, das dritte führt zu der USB Buchse. Auf dem linken braunen Kabel befindet sich die Bezeichnung MCF-101* - dies ist das Kabel für den Touch Digitizer. Das ist besonders empfindlich da es mehrere Stiftreihen hat. Das rechte schwarze Kabel (ST1_LCD*) ist für die Anzeige.
Wie im Video gezeigt (TC 4:45:00) muss man zuerst die Klebestreifen ablösen, dann einen kleinen Bügel anheben und kann dann die Kabel herausziehen oder wieder ordentlich einstecken. Hat das Display Kabel Kontatprobleme kommt es zu Anzeigefehlern, beim Digitizer reagieren einzelne Bereiche nicht auf Touch oder die Auswahl springt.
Meine Vermutung ist dass eine Erschütterung des Gerätes sich auf die Kabel auswirkt weil diese über den schweren Akku verlaufen, dort teilweise sogar festgeklebt sind. Ich habe entsprechend vermieden die Kabel mit dem Akku zu verkleben.
Facebook messages mit Jitsi nutzen
Facebook bietet (noch) an auf Chat Messages mittels XMPP clients zuzugreifen. Jitsi ist ein Messenger, Sprach- und Video-Konferenz Client, der unter anderem für Facebook Chats schon vorbereitet ist.Als Java Anwendung kann er unter Windows, Linux und OS X genutzt werden.
Um Facebook in Jitsi zu nutzen fügt man ein neues Konto mit dem Typ des Netzwerks "Facebook" aus, und muss dann nur noch Benutzername und Passwort eingeben. Allerdings sollte man beachten, vorher einen Nutzernamen in den Facebook Einstellungen angelegt zu haben.
Ist das eigene Facebook Konto mit einem Codegenerator oder einer Anmeldebestätigung gesichert (was sehr zu empfehlen ist), so lehnt der Facebook XMPP Server die Anmeldung ohne weitere Begründung ab (evtl. wird eine SMS mit XMPP Login Passwort verschickt). In diesem Fall muss ein spezielles Anwendungspasswort erstellt werden. Das ist schon alleine deswegen sinnvoll weil diese Passwörter die auf Rechnern hinterlegt sind getrennt von Konto Passwort verwaltet werden können.
In der Facebook Titelleiste auf den Menu Pfeil clicken, dann auf Einstellungen gehen. In der folgenden Seite den Benutzername prüfen und ggf anlegen.
Dann in der linken Menuleiste auf Sicherheit wechseln, dort "Anwendungspasswörter" bearbeiten, hinter dem "generieren" Link findet sich ein kleiner Dialog.
Dieser fragt nach dem Facebook Anmeldepasswort und dann kann man einen frei gewählten Namen für das Passwort eingeben kann (z.B. "Jitsi auf Notebook").
Dann wird ein zufälliges Passwort angezeigt, dieses kann man in Jitsi verwenden.
In Jitsi ist zu beachten dass der Screen in der Deutschen Version ein Feld namens "E-Mail" hat, dort ist aber der Benutzername einzugeben (Issue#155).
Ein Vorteil der Anwendungspasswörter ist es übrigens, dass man diese widerrufen kann (falls jemand Hoffnungen hatte).
Password hashing in Oxwall (PHP password_hash)
While planning a new social network installation for the customer community of my employer I came across Oxwall as a possible solution. It is an Web application on the PHP/MySQL stack which allows self-hosted communities. It runs with a small footprint on about any web server hosting platform and provides a simple Forum, Chat, Event Stream, User Blogs and Profiles and similar functions. This is a very good fit to our needs (as we have to migrate away from the old Mixxt hosted community platform).
First we had a look a Ning, but as a Company located in Germany it is always complicated to host user-facing systems on US systems. Especially since EU and German data protection regulations for personal identifiable items might apply in this area. So if we cannot find a good German social network provider, we will consider hosting the application in our own data centers.
But before we invite out valuable customers to register on such a platform we do need to make sure their data stays safe. This is a business oriented social platform, so we do not really expect critical top secret information, but we do want to protect the most sensitive information, the users passwords. If you look at recent events in the media this is more than important. Thousands of cracked accounts and millions of leaked password hashes are available on the net. Even technology giants like Sony are not safe from being hacked. So it is absolutely important we protect our users and therefore our reputation - even for a simple application like a forum.
Oxwall password hashing
For this reason I reviewed a few security aspects of Oxwall (1.7.2), and want to talk here especially about how it stores user passwords.
Oxwall stores password hashes in the ow_base_user table in the password column as a 64-digit lower-case hex string. It represents the SHA-256 hash of the static OW_STATIC_SALT pepper concatenated with the user's password. This is all done in the hash_password($password) function, the relevant code looks like:
./ow_system_plugins/base/bol/user_service.php:884: return hash('sha256', OW_PASSWORD_SALT . $password);
OW_PASSWORD_SALT (which is actually a static pepper) is a 13 digit hex string generated at installation time and stored in ow_includes/config.php. It is generated with the PHP uniqid() function (current time in milliseconds in hex). This is not a very strong secret, but you can of course overwrite it (keep in mind, this will invalidate all existing password hashes).
In order to verify a password Oxwall uses the isValidPassword($userid, $password) function, which will SHA-256 hash the provided password (one iteration) and compare it to the stored hash with PHP's === operator (which is not a constant time string comparision operation).
Oxwall does by the way enforce a minimum and maximum password length. The PASSWORD_MAX_LENGTH = 15 and PASSWORD_MIN_LENGTH = 4.
Oxwall Password Protection EvaluationThere are a number of problems with this:
By using a static salt (better known as pepper) all users who have the same password have the same hash (in one Oxwall installation). It also means an attacker can prepare a bit better for attacks, as they can check all user passwords with the same pre-compiled table. A globally unique salt for each password hash should be preferred to this.
By not using a format specifier algorithm flexibility is limited. Oxwall would have to test old and new algorithms (or guess based on the length of the encrypted string).
Although SHA-2 is more complex to calculate compared to DES, SHA-1 or MD5 it is still a comparable fast operation which can be easily optimized in hardware. This is no longer regarded as a safe protection. Instead it is better to have an iterated algorithm (and optionally memory complexity).
The current function for verifying the password hash is not implemented with a constant-time comparison method. This means it could leak some information on the password hashes to remote attackers.
If you compare this with other PHP applications it is not a bad implementation, but it is surely not state of the art anymore. Oxwall really should aim for a modern implementation.
There is absolutely no reason to limit the length of a password to 15 characters. It can be even longer than the hash function. I would remove that limit or at least increase it to a sane value like 100 (or 128 if you want to look techy :). Oxwall should invest some more work into encouraging users to have safe passwords. This can include hooks to check for bad passwords. The current minimum of 4 characters is quite low (and it would be good if one can configure it without changing the code).
Modern PHP password hashing
Luckily PHP 5.5 is providing a password_hash() function. And if you cannot wait for it, there is a compatibility library from Anthony Ferrara which can be used on 5.3. The function supports generating random salts, it uses BCRYPT algorithm by default and uses the standard $2y$... hash format.
I feel it is a bit unfortunate, that PHP does not support an additional pepper argument (in the default implementation). It argues, that there is no official analysis how much additional protection it brings.
The RFC comments, that it is possible to encrypt the hashes in your database (with a pepper). This would add the protection, but it generates additional work. The pepper Oxwall is using is rather low entropy, so I think it is best to just drop it. This will also reduce the risk of losing this value.
Oxwall should use the password_hash function, not specify salt or cost parameters and implement the rehash checks, to make sure it automatically rehashes passwords whenever PHP modifies the settings.