// RPM/YUM GPG keys: verification, import, deletion, package signature check and additional notes

I'm fairly new to the Red Hat and Fedora Linux eco-system. Therefore I just wanted to teach myself some details about RPM and YUM today, especially how to use the commands to handle package signatures and repository GPG keys.1) I noticed many unanswered forum postings during my research. That's why I decided to write this little blog entry, helping search-engine users to find more answers than questions. :-)

List and verify keys

  • List all GPG keys on the RPM/YUM keyring:
    rpm -q 'gpg-pubkey-*' | sort

    The GPG keys are handled as gpg-pubkey-XXXXXXXX-YYYYYYYY packages. XXXXXXXX is the key ID in lowercase chars without 0x prefix. YYYYYYYY is the key creation time as unix timestamp in hex without 0x prefix.2) Example usage:

    $ rpm -q 'gpg-pubkey-*' | sort
    gpg-pubkey-00a4d52b-4cb9dd70
    gpg-pubkey-069c8460-4d5067bf

    As you can see, my example RPM knows about the GPG keys 0x00A4D52B and 0x069C8460.

  • List all GPG keys on the RPM/YUM keyring with a brief description:
     rpm -q 'gpg-pubkey-*' --qf '%{name}-%{version}-%{release} -> %{summary}\n'

    The GPG keys are handled as gpg-pubkey-XXXXXXXX-YYYYYYYY packages. XXXXXXXX is the key ID in lowercase chars without 0x prefix. YYYYYYYY is the key creation time as unix timestamp in hex without 0x prefix.3) Example usage:

    $ rpm -q 'gpg-pubkey-*' --qf '%{name}-%{version}-%{release} -> %{summary}\n'
    gpg-pubkey-069c8460-4d5067bf -> gpg(Fedora (15) <fedora@fedoraproject.org>)
    gpg-pubkey-00a4d52b-4cb9dd70 -> gpg(RPM Fusion free repository for Fedora (15) <rpmfusion-buildsys@lists.rpmfusion.org>)

    As you can see, my example RPM knows about the GPG keys 0x00A4D52B and 0x069C8460.

  • List all GPG keys on the RPM/YUM keyring with all details:
    rpm -qi 'gpg-pubkey-*'
  • Check the fingerprint of a GPG key on the RPM/YUM keyring:
    rpm -q 'gpg-pubkey-XXXXXXXX-*' --qf '%{description}\n' | gpg --quiet --with-fingerprint

    XXXXXXXX is the key ID in lowercase chars without 0x prefix. Example usage:

    $ rpm -q 'gpg-pubkey-069c8460-*' --qf '%{description}\n' | gpg --quiet --with-fingerprint
    pub  4096R/069C8460 2011-02-07 Fedora (15) <fedora@fedoraproject.org>
          Key fingerprint = 25DB B54B DED7 0987 F4C1  0042 B4EB F579 069C 8460

Import and remove keys

  • Remove / delete a GPG key from the the RPM/YUM keyring:
    rpm -e --allmatches 'gpg-pubkey-XXXXXXXX-*'

    XXXXXXXX is the key ID in lowercase chars without 0x prefix. Example usage:

    $ rpm -e --allmatches 'gpg-pubkey-00a4d52b-*'

    This command would remove the GPG key with ID 0x00A4D52B.

  • Connect a GPG key to the RPM/YUM keyring:
    rpm --import '/path/to/public-key'

    Recent RPM versions can download keys via HTTP(S) and are even able to find ACSII-armored key blocks within HTML files. Example usage:

    $ rpm --import "http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0x00A4D52B"

    This command would load the the GPG key 0x00A4D52B from a public keyserver and import it into RPM. Please note that SKS keyservers need working TCP connections on Port 11371.

Verify RPM package signatures

Signatures ensure that the packages you install are what was produced by the software maintainer and have not been altered (accidentally or maliciously) by any mirror or third party. YUM should do these checks automatically when installing something out of a repository. However, you may want to check the GPG signature of a RPM package by yourself:

rpm -Kv /path/to/example.rpm

RPM needs the correct public key for this check. If you don't know how to get it, read on to learn what to do.

A perfect real-world example is the RPM Fusion setup to configure the RPM Fusion repositories on your Fedora system. They provide setup packages to install the needed .repo files and GPG keys without hassle. But you should verify them to make sure they are not altered and are really containing the original RPM Fusion keys instead the ones an attacker is using to sign it's malicious packages for his fake repository. ;-)

Let' start. RPM Fusion says we can configure everything with the following command:4)

1)
Existing APT knowledge is pretty useless on Fedora ;-)
2) , 3)
You can make it readable with date -d @$((0xYYYYYYYY)) "+%Y-%m-%d %T"
4)
BTW: yum localinstall is outdated. From the yum manpage: “Note that the install command will do a local install, if given a filename. This option is maintained for legacy reasons only.”

// How to create SSH keys

SSH provides the possibility to use Public Keys to log in to a target system (which is very likely more secure than a password). To make this possible:

  1. The user has to create a Public/Private Key pair
  2. The user's Public Key(s) has/have to be stored on the target system running the SSH Server (normally within ~/.ssh/authorized_keys)
  3. The server's Public Key has to be stored on the local system running the SSH Client (normally within ~/.ssh/known_hosts)

Some popular services like GitHub do not even provide a password based authentication for data exchange, forcing you to use a SSH Public Key. Same for the Fedora Account System (FAS) where I created an account recently.

On a common Linux system, all needed SSH client tools should be installed by default. If not (e.g. because they were removed), simply install the openssh-clients package on Fedora or the openssh-client package on Debian/Ubuntu. After installation, the SSH tool for authentication, key generation, management and conversion is available via terminal: ssh-keygen

Creating a Public/Private Key pair

As already said, ssh-keygen is the tool for creating a key pair. It brings a lot of options, I'm going into detail on the most important ones:5)

  • -b <bits>:
    From the manpage: “Specifies the number of bits in the key to create. For RSA keys, the minimum size is 768 bits and the default is 2048 bits. Generally, 2048 bits is considered sufficient. DSA keys must be exactly 1024 bits[…]”.
  • -t <type>:
    Specifies the type of key to create. The cryptographic algorithm to use will selected through specifying this parameter. For SSH2, you can choose between “rsa” and “dsa”.6)
  • -C "<comment>":
    Provides a comment for the key. The comment is used as “name” for the key in most applications. If not given, username@host will be set by default. You can change the comment later without any problems.

Using a 2048bit long RSA key is a good choice for most use-cases. 1024bit RSA is no longer regarded as indisputably secure, 4096bit RSA is for paranoid person like me. Please make sure you set a passphrase to protect your key. Otherwise everyone who may gets access to it (e.g. because someone steals your laptop and copies the keyfile) is able to get instant access to all systems you used the key for logging in. In contrast, you should have enough time to change the keys on all affected system without any danger if you used a good passphrase for a leaked private key. Additionally, it is no problem to use multiple SSH keys. So if you need a SSH key without password (e.g. for a quickly hacked backup script), create a separate key for this special task but do not use it for logging in to important systems.

Before you start: If you do not answer the question “Enter file in which to save the key” properly, you possibly overwrite an already existing key pair (if any). So take care which filename you are using for storage. The defaults are id_rsa and id_dsa (depending on the used algorithm). You have been warned!

Now open a terminal and let's go:

user@local:~$ ssh-keygen -t rsa -b 2048 -C "user@local"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):

As you can see, the key will be stored into ~/.ssh/id_rsa by default. To choose another file, you have to provide the complete path (→ ~/ normally does not work to point to your home dir). I use the non-default path /home/user/.ssh/mykey in this example.

You should store all SSH keys into the default directory ~/.ssh (no matter which filenames you are using for them). Otherwise, many tools and programs are not able to locate your SSH keys by default, leading to more configuration issues. None the less, it is possible to store your keys in another directory than the default one. ssh-add /path/to/your_key is your friend.

Enter file in which to save the key (/home/user/.ssh/id_rsa): /home/user/.ssh/mykey
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/mykey.
Your public key has been saved in /home/user/.ssh/mykey.pub.
The key fingerprint is:
10:af:1e:58:a3:a2:2a:7e:11:23:52:bf:c2:32:61:fa user@local
The key's randomart image is:
+--[ RSA 2048]----+
| ...     o       |
|     + o         |
|  . o = .        |
| ... o +         |
|.. .  . S        |
| o  .            |
|Bo.  .       .+  |
|E oo.            |
| +o+o            |
+-----------------+

Done. Now you got the needed key pair:

  • /home/user/.ssh/mykey is the private key. Never share this one with someone else. Simply keep the Private Key… well, private. ;-)
  • /home/user/.ssh/mykey.pub is the public key (also called “ID file” or “identity file”). This is the one you have to upload to the remote systems.

Tips and tricks

  • If you never heard about the “randomart image”, you may have a look at “What is randomart produced by ssh-keygen?”.
  • If you need a GUI, have a look at GNOME Seahorse or PuTTY.
  • Have a look at IBM: Shhh ... secrets about SSH and GitHub: Multiple SSH keys if you have trouble when using more than one SSH key.
  • Close ssh if the session is not responding anymore: The command ~. closes the ssh client program if the server hangs (e.g. because it was unexpectedly shut down or your internet connection is not stable).
  • Copy the Public Key(s) to a remote system: ssh-copy-id helps you to copy your SSH Public Key into the ~/.ssh/authorized_keys file of the remote system and/or copy the remote system's public key into your local ~/.ssh/known_hosts file. Usage:
    ssh-copy-id -i "~/.ssh/mykey.pub" remote-user@remote.example.com
  • Change the passphrase of a SSH key: ssh-keygen is also the tool of choice to change a key's password. The -f parameter specifies the private key file you want to change. The -p parameter tells the program that you want to change the password of an existing key, preventing the generation of a new one:
    ssh-keygen -f /path/to/your_key -p
  • Change the comment of a SSH key: ssh-keygen is also the tool of choice to change a key's comment. The -f parameter specifies the private key file you want to change. The -c parameter tells the program that you want to change the comment of an existing key, preventing the generation of a new one:
    ssh-keygen -f /path/to/your_key -c
5)
it is very likely you do not need any others. Consider the manpage otherwise.
6)
Which one is better is arguable. I wrote about this in another context. :lang_de:

// Full disk encryption with Ubuntu (9.04 Jaunty or newer), LVM and LUKS

This article provides a step-by-step guide on how to install an Ubuntu Linux system with full disk encryption (new installation). However, you should take a relaxed day as topical newbie for further reading. You don't have to keep everything in mind but it is never an error to acquaint oneself with something new.

// Vollverschlüsseltes System mit Ubuntu (ab 9.04 Jaunty), LVM und LUKS

Dieser Artikel beschreibt, wie ein vollverschlüsseltes :lang_en: System mit Hilfe von Ubuntu-Linux eingerichtet wird (Neuinstallation). Der gesamte Artikel kann dabei Schritt für Schritt nachvollzogen werden um ans Ziel zu kommen. Dennoch sollte man sich als Neuling einen ruhigen Tag Zeit nehmen, um die Thematik zu erfassen. Man muss sich bei weitem nicht alles merken, sich aber einmal eingelesen zu haben schadet nie.

// GnuPG on Android with APG and K-9 Mail

I'm using a separate7) email address for my Android 2.2 based mobile phone. This makes it possible for close friends and my family to write me when I'm on the road. For free and without the need for crappy SMS phone GUIs. Additionally, it is very handy to mail yourself a grocery list or a quick note before leaving the house. ;-) However: All unencrypted8) mails for your phone are clear for the telco provider and others to see. But there are comfortable applications to change this.

Quick and superficial guide about the needed actions:

  1. Install the needed applications on your phone (click on the app names for QR Codes containing an Android Market search query):
  2. Generate a new key pair for your phone. IMHO, it is a bad idea to place your main private key on an unencrypted mobile device. The risk of theft/loosing it is too high. I created the new key pair on my PC (even it would be possible on Android) because I prefer some kind of key hierarchy :lang_de: and a keyboard makes the creation more comfortable. Additionally, it is not a bad idea to have a backup copy of the new key on your PC.
  3. Export you new key pair into .asc files:
    gpg -ao ~/privkey.asc --export-secret-key KEY-ID
    gpg -ao ~/pubkey.asc --export KEY-ID

    If you don't like the terminal, use Enigmail or another GPG GUI for the export. It is also a good idea to export the public keys of the persons you want to write encrypted mails from your phone. Even APG provides the possibility to use keyservers, it makes no fun to search and import dozens of keys using that way.

  4. Copy the .asc files on your phone (e.g. via USB), the location does not matter (you can delete these files after the import was done).
  5. On your phone:
    1. Open APG→click Menu button→“Manage Public Keys”. The screen changes→click Menu button→“Import Key”. The program is asking where the .asc file containing your public key to import is located. Click on the file browser icon and run the action with “ASTRO”. Browse to the file and click on it. Check “Delete After Import” and click OK.
    2. Open APG→click Menu button→“Manage Private Keys”. The screen changes→click Menu button→“Import Key”. The program is asking where the .asc file to containing your private key to import is located. Click on the file browser icon and run the action with “ASTRO”. Browse to the file and click on it. Check “Delete After Import” and click OK.
    3. Open K-9-Mail→click Menu button→“More”→“Accounts”. The sceen changes→Click and hold on your account→“Advanced”→Cryptography→Select “APG” as the OpenPGP Provider. And check “Auto-sign” if it makes sense for you.

That's all. But you should know that K-9 Mail brings no support for PGP/MIME right now. This means you have to tell your friends to write Inline-PGP encoded mails, not PGP/MIME mails. But this should be default in most environments. If not: Enigmail provides a non-global select box for this setting at the “Per-Recipient Rules” menu.

7)
I don't want all of my emails on my mobile
8)
Only an insignificant amount of unencrypted mails are hitting my mailbox. It was a lot of work LOL but nearly everybody who writes mails to me is using GnuPG. Even my Mom. No excuses for not using it!

// Full disk encryption with Ubuntu (9.04 Jaunty or newer), LVM and LUKS

I wrote a detailed guide on how to install an encrypted Ubuntu Linux:

The setup is using LUKS and Logical Volume Manager (LVM) to get a secure and flexible system. And to make nearly everybody succeed, there is even a crypt-setup bash script, making the installation faster and easier.

Have fun. :-)

// Ebfe's Anti-B00TKIT Project

The “Ebfe's Anti-B00TKIT Project” is a simple but effective protection against Bootkits, suitable for daily usage. It makes it possible to know if your bootloader was manipulated before booting from disk. A really interesting tool for high-security environments and paranoid persons. :-P

Bootkits9) are used to attack a full disk encryption10) (amongst other things). All “common” data is encrypted on such systems except a small, “special” part: the bootloader. Expressed in simplified terms, the bootloader is needed to store a program which prompts the user for the password to decipher the data and start the encrypted operating system. Bootkits are trying to manipulate the bootloader, making it possible to log the password the user enters and store it within the unencrypted part of the disk afterwards. The user does not see this, he simply gets the normal encryption password promt to start the system. This enables the attacker to come back later to read out the plain, unencrypted password the bootkit stored for him.

Ebfe's Anti-B00TKIT provides a CD to boot from before booting from disk. The program on CD reads out the Master Boot Record entries and displays their checksums (this does only need a few seconds). If all checksums are OK, you can going on to boot from disk by pressing a key. If the checksums are not the same as every day, your harddisk's bootloader was manipulated. To make this check more comfortable, you can create a custom CD containing your original MBR checksums. The CD is able to highlight non-matching checksums automatically then.

Visit the project website for screenshots, how-to and download.

9)
for example the Stoned Bootkit on MS Windows
10)
e.g. LUKS on Ubuntu or TrueCrypt on Windows

// Links: IT security and privacy

// HTTP digest authentication with PHP (safe mode enabled)

Doing HTTP digest authentication with PHP is an easy task. The manual entry is providing all needed information as long as you do not skip the last note on the page:

Note: If safe mode is enabled, the uid of the script is added to the realm part of the WWW-Authenticate header.

I just talked to one of my friends who did not notice the safe mode behavior, he had problems because HTTP digest authentication simply did not work on his server where safe mode is active. Unfortunately, the manual is not providing an example working with both active and inactive safe mode, therefore I am releasing one here. You may use the function directly… or better build a nice auth-class for doing the job. However, I think the example should help in both cases providing all needed information for creating your own HTTP digest authentication. Have fun. :-)

http-auth.php
<?php
/**
 * HTTP digest authentication
 *
 * @return true TRUE if everything worked/auth was successful.
 *         In case of errors and/or wrong credentials, the script will be killed
 *         (providing a message to the current client).
 * @author Andreas Haerter
 * @link http://en.wikipedia.org/wiki/Digest_access_authentication
 * @link http://de.wikipedia.org/wiki/HTTP-Authentifizierung
 * @link http://www.php.net/manual/features.http-auth.php
 * @link http://blog.andreas-haerter.com/2010/04/19/http-digest-authentication-with-php-safe-mode-enabled
 * @link http://www.php.net/manual/features.http-auth.php#93427
 */
function http_digest_authentication()
{
	//existing users/credentials
	$users = array("username1" => "password1",
	               "username2" => "password2");
 
	//message to show
	$realm = "Please enter your credentials";
 
	//send needed digest auth headers
	if (empty($_SERVER["PHP_AUTH_DIGEST"])) {
		header("HTTP/1.1 401 Unauthorized");
		header("WWW-Authenticate: Digest realm=\"".$realm."\",qop=\"auth\",nonce=\"".uniqid(mt_rand(), true)."\",opaque=\"".md5($realm."salt-for-opaque")."\"");
		die("unauthorized access");
	}
 
	//parse http digest (inspired through http://www.php.net/manual/features.http-auth.php#93427)
	$mandatory = array("nonce"    => true,
	                   "nc"       => true,
	                   "cnonce"   => true,
	                   "qop"      => true,
	                   "username" => true,
	                   "uri"      => true,
	                   "response" => true);
	$data = array();
	preg_match_all('@(\w+)=(?:(?:\'([^\']+)\'|"([^"]+)")|([^\s,]+))@', $_SERVER["PHP_AUTH_DIGEST"], $matches, PREG_SET_ORDER);
	foreach ($matches as $m) {
		$data[$m[1]] = $m[2] ? $m[2] : ($m[3] ? $m[3] : $m[4]);
		unset($mandatory[$m[1]]); //mandatory part was found, kick it out of the "to do" list (=$mandatory array)
	}
 
	//create valid digest to validate the credentials
	$digest = "";
	if (isset($users[$data["username"]])) {
		$realm_digest = $realm;
		//As mentioned at <http://www.php.net/manual/en/features.http-auth.php>:
		//If safe mode is enabled, the uid of the script is added to the realm part of
		//the WWW-Authenticate header (you cannot supress this!). Therefore we have to
		//do this here, too.
		if (6 > (int)PHP_VERSION //safe_mode will be removed in PHP 6.0
		    && (int)ini_get("safe_mode") !== 0) {
			$realm_digest .= "-".getmyuid();
		}
		$digest = md5(md5($data["username"].":".$realm_digest.":".$users[$data["username"]]) //A1
		              .":".$data["nonce"].":".$data["nc"].":".$data["cnonce"].":".$data["qop"].":"
		              .md5($_SERVER["REQUEST_METHOD"].":".$data["uri"]));                    //A2
	}
	if (empty($digest)
	    || $data["response"] !== $digest) {
		header("HTTP/1.1 401 Unauthorized");
		header("WWW-Authenticate: Digest realm=\"".$realm."\",qop=\"auth\",nonce=\"".uniqid(mt_rand(), true)."\",opaque=\"".md5($realm."salt-for-opaque")."\"");
		die("wrong credentials");
	}
	//if we are here, auth was successful
	return true;
}
?>

// GnuPG-Schlüsselhierarchie: passender Algorithmus für jede Aufgabe, Schlüsselaustausch ohne Verlust des Web of Trust

Vor ein paar Wochen habe ich mir einen neuen Key für GnuPG/PGP (im Folgenden einfach “GPG” genannt) zugelegt, weil mein bisheriger abgelaufen ist. Das habe ich zum Anlass genommen meine Vorgehensweise beim Erstellen eines GPG-Schlüssels zu überarbeiten. Die Erkenntnisse will ich hier festhalten, vielleicht bringt es ja jemandem etwas ;-). Ziel war:

  • Fein granulare Schlüsselhierarchie: Eine GPG-Aufgabe → Ein Schlüssel.
  • Die verschiedenen Schlüssel sollen den jeweils passendsten Algorithmus für die Aufgabe verwenden und bei Bedarf nach relativ kurzer Zeitspanne verfallen dürfen.
  • :!: Der Austausch eines Schlüssels soll NICHT zur Folge haben, dass das eigene Web-of-Trust verloren geht.

Dabei ist der letzte Punkt IMHO der Wichtigste. Er erspart einem, dass man wieder mühsam Signaturen für die neue Schlüssel einsammeln muss (den neuen Key vor Ablauf des alten Key mit selbigen zu signieren ist IMHO nur eine Notlösung, aber besser als nichts). Die Vorteile liegen auf der Hand:

  • Geeignetere Algorithmen und Schlüsselstärken für die jeweilige Aufgabe
    Beispiel: RSA erzeugt irrsinnig lange Signaturen, ist aber gut für Verschlüsselung geeignet. Wenn man dennoch zur Verschlüsselung auf RSA setzen will, kann man seinen Signierschlüssel über DSA realisieren. Zudem kann man die nötige Schlüssellänge (Bit) besser zwischen Aufgabe und Performance abwägen.
  • Mehr Sicherheit
    Selbst wenn mal ein Schlüssel mit brachialer Großrechnerpower über Jahre geknackt werden könnte, so hat der Angreifer bei regelmäßig wechselnden Schlüsseln dann immer nur einen Teil der Daten und muss für weiteren Zugang zu älteren/neueren Daten erneut genausoviel Aufwand in Kauf nehmen. Dies gilt natürlich auch, wenn ein Schlüssel anderweitig kompromittiert wird (was wahrscheinlicher ist als Brute-Force). Es ist ein deutlicher Unterschied, ob jemand ein einziges Jahr oder z.B. fünfzehn Jahre Kommunikation nachvollziehen kann ;-). Oder ob nur ein Webserver-Login ermöglicht wird oder gleich alle jemals verschickten Daten entschlüsselt werden können.

Grundlage

Damit man mit häufiger wechselnden Schlüsseln nicht andauernd sein Web-of-Trust ruiniert, fußt dass im Folgenden beschriebenen Szenario auf einem Hautpsignierschlüssel, welcher ausschließlich dazu verwendet wird, die eigenen und fremden Schlüssel zu zertifizieren (Certify), und nicht11) abläuft. D.h. dieser Schlüssel hat nur den Zweck, Dritten bei Verwendung der nach kürzerer Zeit12) wechselnden Unterschlüssel zu beweisen, dass der neue Schlüssel wirklich unter meiner Kontrolle steht und die damit verschlüsselten Inhalte auch nur mir zugänglich sein werden. Das muss man aber nicht extra “aufdröseln” oder “zusammenfrickeln”, da alle Identitäten immer am Hauptschlüssel hängen.

Die lange Laufzeit dieses Hautpsignierschlüssels ist dabei wenig sicherheitskritisch, da ein Angreifer damit “nur” die Identität fälschen könnte und so Kommunikationspartner ggf. weismachen, er sei ich. Er kommt aber nicht an bereits verschlüsselte Inhalte. Dies steht in keinem Verhältnis einen Großrechner Jahrzehnte zu beschäftigen, um den Hautpsignierschlüssel zu knacken. Man wird die Rechenzeit lieber in das “knacken” der Inhalte investieren als “lediglich” in das fälschen der Identität - es gibt zum Einen sicher billigere Wege, einem Dritten vorzugaukeln, man sei ich und zum Anderen könnte ich sofort einen neuen Key erstellen, nutzen und verbreiten (und damit all die Arbeit des Angreifers zu Nichte machen), sobald mir klar wird, dass jemand Drittes meine Identität zu fälschen versucht.

Nötiges GPG-Wissen

Dieser Text ist kein Anfänger-Tutorial, sondern ein Anwendungsbeispiel für fortgeschrittene GPG-Nutzer: Wer komplett neu ist, sollte sich zunächst 3-4 Tage Zeit nehmen und GPG kennen lernen13). Anschließend sollte die hier beschriebene Hierarchie aber gut umsetzbar sein, denn die Systematik dürfte auch für “neue” GPG-Nutzer Sinn ergeben.

Auch wenn man sich schon ein wenig mit GPG beschäftigt hat, ist es für den folgenden Text unabdingbar, zu 100% zu verstehen, was der Unterschied zwischen den verschiedenen Schlüsselfähigkeiten/Flags “Certify”, “Sign” und “Encrypt” ist. Außerdem sollte man wissen, dass verschiedene Algorithmen nicht mit jedem Flag kombiniert werden können. Daher will ich kurz darauf eingehen.

Die folgenden Flags können auf GPG-Schlüssel angewendet werden:

  • C: “Certify”
    Zertifizierung/Certification. Dient dazu Schlüssel (eigene/von Dritten) zu unterschreiben.
  • S: “Sign”
    Unterschreiben/Signing. Dient dazu Daten (eigene/von Dritten), z.B. eine Datei oder Text, zu unterschreiben.
  • E: “Encrypt”
    Verschlüsselung/Encryption. Dient dazu Daten (eigene/von Dritten), z.B. eine Datei oder Text, zu verschlüsseln.
  • A: “Authenticate”14)
    Authentifizieren. Dient dazu einen Aufrufe/challenge zu signieren. Kann z.B, genutzt werden, wenn der GPG-Schlüssel für einen (wie auch immer gearteten) Login genutzt werden soll, um der Kommunikationsgegenstelle beim challenge zu beweisen, dass man derjenige ist, für den man sich ausgiebt (also Identitätsnachweis), um so Zugriff auf einen Dienst zu erhalten. “Authenticate” ist also vergleichbar mit “Certify”/“Sign”, nur eben nicht für Schlüssel oder Daten, sondern für challenges. Kann je nach Software z.B. den Login via Passwort ersetzen oder ergänzen.

Die verschiedenen Algorithmen sind damit wie folgt kombinierbar:

  • RSA
    Alles. Ein RSA-Key kann mit Certify, Sign, Encrypt und Authenticate geflaggt werden.
  • DSA
    Ein nur zum signieren geeigneter Algorithmus, kann mit Certify, Sign und Authenticate geflaggt werden.
  • ElGamal
    Ein nur zum verschlüsseln geeigneter Algorithmus, kann nur mit Encrypt geflaggt werden.

Will man also verschlüsseln und signieren – was jeder GPG-Nutzer will ;-) – hat man daher die Wahl zwischen einem RSA-Hauptschlüssel mit RSA-Unterschlüssel(n) (⇒ RSA/RSA) oder einem DSA-Hauptschlüssel mit ElGamal-Unterschlüssel(n) (⇒ DSA/ElGamal bzw. DSA/ELG genannt). Auf die verschiedenen Algorithmen will ich hier nicht weiter eingehen, es sei nur gesagt, dass bisher geglaubt wurde (!=bewiesen), dass das dem DSA zu Grunde liegende mathematische Problem (Discrete logarithm problem :lang_en:) schwerer zu lösen sei, als das von RSA (Integer factorization problem), und daher ein RSA-Schlüssel mehr Bits aufweisen muss, um gleiche Sicherheit zu bieten. Allerdings kommen daran mehr und mehr Zweifel auf, und GPG wird u.a. daher in Zukunft auch den Default von DSA/ElGamal 1024/4096bit auf RSA 2048/2048bit ändern15). Es folgt dennoch eine kleine Entscheidungshilfe.

RSA:

  • Pro:
    • Sehr gut untersucht, weit verbreitet.
    • Offen entwickelt.
  • Contra:
    • Sehr lange Signaturen im vgl. mit DSA (fällt vor allem bei kurzen E-Mails ins Gewicht; selbst 4-5 Zeilen Text bringen immer 1-2 Zeilen à 80 Zeichen “Signaturlast” mit).
    • Weniger kompatibel zu sehr alten GPG-Versionen.

DSA:

  • Pro:
    • Kurze Signaturen
    • Hohe Kompatibilität zu sehr alten GPG-Versionen.
  • Contra:
    • Weniger untersucht als z.B. RSA
    • Kleine Keygröße macht DSA ggf. anfällig in Zukunft gebrochen zu werden. Der zu Grunde liegende Hash (SHA-1) ist zwar noch als vertrauenswürdig anzusehen, aber nicht mehr für neue kryptographische Anwendungen empfohlen.

Umsetzung

Genug Prosa, es wird konkreter. Ich will zeigen, wie man das Beschriebene umsetzen könnte. Ich erstelle daher beispielhaft eine Hierarchie, die 1:1 nachvollzogen werden kann (d.h. sie ist 100% praxistauglich):

  • Hautpsignierschlüssel (RSA-4096bit, Flag(s): Certify, Verfällt nie (=0))
    Nur zum zertifizieren eigener und fremder Schlüssel, also dem Aufbau/Erhalt eines Web-of-Trust. Alle Identitäten/User-IDs werden von GPG immer automatisch über den Hauptschlüssel integriert.
    • Unterschlüssel (DSA-1024bit, Flag(s); Sign, verfällt nach zwei Jahren (=2y))
      Dient nur dem Signieren von Daten (z.B. E-Mail). DSA statt RSA da sie Signaturen erheblich kürzer ausfallen.
    • Unterschlüssel (RSA-4096bit, Flag(s); Encrypt, verfällt nach zwei Jahren (=2y))
      Dient nur zum Verschlüsseln von Daten (z.B. E-Mail).
    • Unterschlüssel (RSA-4096bit, Flag(s); Authenticate, verfällt nach einem Jahr (=1y))
      Dient nur Authentifikationsprozessen (z.B. Login via SSH etc.).

Nun haben wir also für jede Aufgabe einen eigenen Schlüssel. Das Ganze funktioniert hervorragend, da GPG automatisch den passenden Schlüssel für die jeweilige Aufgabe auswählt. Das heißt, wenn eine Anwendung beispielsweise an GPG meldet “verschlüsseln eines Textes für den Empfänger john.doe@example.com” wird automatisch der passende Hauptschlüssel über die E-Mail-Identität john.doe@example.com sowie ein Unterschlüssel mit dem Flag Encrypt ausgewählt. Dabei stellt es überhaupt kein Problem dar, wenn der Unterschlüssel ein Verfallsdatum hat, der Hauptschlüssel jedoch nicht.

Dass der/die Unterschlüssel ein Verfallsdatum hat und der Hauptschlüssel nicht, ist im Grunde der Entscheidende Unterschied zu einem Default-Schlüsselpaar, das mit einem Verfallsdatum z.B. wie folgt aussähe:

  • Hautpsignierschlüssel (RSA oder DSA, Flag(s): Certify, Sign, Authenticate, verfällt in x Jahren)
    • Unterschlüssel (RSA oder ElGamal, Flags(s): Encrypt, verfällt in x Jahren)

Da der Hautpsignierschlüssel in der Default-Konfiguration ebenfalls abläuft, wenn man den zur Verschlüsselung genutzten Unterschlüssel aus Sicherheitsgründen ablaufen lässt, sind damit auch die ganzen Unterschriften/das Web of Trust im Eimer, da wie schon erwähnt alle Identitäten immer am Hautpsignierschlüssel hängen.

Der Text ist zwar auf *ix zugeschnitten, die Informationen sollten aber auch Nutzern anderer Betriebssysteme dienlich sein. Die Kommandozeilenausgaben können – je nach verwendeter GPG-Version – leicht variieren.

Per Default legt GPG Signierschlüssel mit den Flags Sign, Certify und Authenticate16) an. Um einen in unserem Aufbau benötigten Certify-only Schlüssel zu erhalten, wird die --expert-Option verwendet. Falls man einen DSA-Schlüssel mit mehr als 1024bit anlegen will, muss --enable-dsa2 verwendet werden (darauf verzichte ich in meinen Beispiel, das hauptsächlich auf RSA fußt und DSA aus Kompatibilitätsgründen “nur” mit 1024bit nutzt).

Erstellen des Hautpsignierschlüssels

Nochmal die Eckdaten: RSA-4096bit, Flag(s): C, Verfällt nie (=0).

Man rufe den passenden GPG-Schlüsseldialog auf:

gpg --gen-key --expert

Man wählt dort (7) RSA (eigene Fähigkeit setzen). GnuPG konfrontiert einen dann mit folgender Ausgabe:

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Zertif. Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben Zertif. Verschlüsseln
[...]

Wie man sieht sind per Default für RSA die Flags Sign Certify Encrypt gesetzt. Wir wollen einen Certify-only 4096bit-Schlüssel, daher schalte ich die entsprechenden Fähigkeiten im Dialog um (→ S, E), so dass man folgende Ausgabe sehen sollte:

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Zertif. Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Zertif. 
[...]

Jetz passen die Flags. Weiter geht's:

Ihre Auswahl? Q
RSA Schlüssel können zwischen 1024 und 4096 Bits lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 0
Schlüssel verfällt nie

Es folgen die persönlichen Angaben der Hauptidentität, d.h. man sollten den Namen und ggf. die “Haupt”-E-Mail-Adresse angeben.17) Alle Identitätsangaben können nachträglich editiert werden, weitere E-Mail-Adressen/Identitäten kann man ebenfalls später hinzufügen. Wenn man also in zwei Jahren die Firma und damit auch die berufliche E-Mail-Adresse wechselt ist das kein Problem.

Die Schlüsselgenerierung kann wirklich sehr lange dauern, u. U. sollte man schon mal 5-10 Minuten mitbringen.18)

Nach der Generierung sollte eine ähnlich lautende Meldung ausgegeben werden:

gpg: Schlüssel <KEYID> ist als uneingeschränkt vertrauenswürdig gekennzeichnet
Öffentlichen und geheimen Schlüssel erzeugt und signiert.

Diese <KEYID> sollte man sich für die folgenden Schritte notieren. Falls man es verpasst hat oder ein paar Tage später etwas ändern will, schlägt man sie einfach kurz via gpg --list-keys nach.19)

Erstellen der Unterschlüssel

Erzeugen der Unterschlüssel, wie direkt unter “Umsetzung” beschrieben.

Sign-only DSA-Unterschlüssel

Erstellen des Sign-only DSA-Unterschlüssels (DSA-1024bit, Flag(s); Sign, verfällt nach zwei Jahren (=2y)).

gpg --edit-key --expert Key-ID-des-Hauptschlüssels
Befehl> addkey

Nun muss man seinen Passphrase eingeben, um den Private-Key zu entsperren und den Unterschlüssel hinzufügen zu können.

Los geht's:

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (2) DSA (nur unterschreiben/beglaubigen)
   (3) DSA (eigene Fähigkeit setzen)
   (4) Elgamal (nur verschlüsseln)
   (5) RSA (nur signieren/beglaubigen)
   (6) RSA (nur verschlüsseln)
   (7) RSA (eigene Fähigkeit setzen)
Ihre Auswahl? 3

Mögliche Aktionen für einen DSA Schlüssel: Unterschreiben Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun setzt/entfernt man also die Flags, die man nicht haben will. Für einen Sign-only-Schlüssel muss man, wie man an der Zeile Derzeitige erlaubte Aktionen: Unterschreiben sieht, nichts mehr ändern. Es kann also direkt weitergehen:

Ihre Auswahl? Q
Das DSA-Schlüsselpaar wird 1024 Bit haben.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 2y
Key verfällt am <DATUM> <UHRZEIT>
Ist dies richtig? (j/N) j
Wirklich erzeugen? (y/N) y
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.

Nun heißt es warten.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln:

Befehl> save

Encrypt-only RSA-Unterschlüssel

Erstellen des Encrypt-only RSA-Unterschlüssels (RSA-4096bit, Flag(s); Encrypt, verfällt nach zwei Jahren (=2y)).

gpg --edit-key --expert Key-ID-des-Hauptschlüssels
Befehl> addkey

Nun muss man seinen Passphrase eingeben, um den Private-Key zu entsperren und den Unterschlüssel hinzufügen zu können.

Los geht's:

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (2) DSA (nur unterschreiben/beglaubigen)
   (3) DSA (eigene Fähigkeit setzen)
   (4) Elgamal (nur verschlüsseln)
   (5) RSA (nur signieren/beglaubigen)
   (6) RSA (nur verschlüsseln)
   (7) RSA (eigene Fähigkeit setzen)
Ihre Auswahl? 7

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun setzt/entfernt man also die Flags, die man nicht haben will. Für einen Encrypt-only-Schlüssel muss man, wie man an der Zeile Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln sieht, noch den “Unterschreiben”/Sign-Flag entfernen und dazu wie folgt vorgehen:

Ihre Auswahl? S

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun passt es. Weiter geht's:

Ihre Auswahl? Q
RSA Schlüssel können zwischen 1024 und 4096 Bits lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 2y
Key verfällt am <DATUM> <UHRZEIT>
Ist dies richtig? (j/N) j
Wirklich erzeugen? (y/N) y
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
[...]

Nun heißt es warten.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln:

Befehl> save

Authenticate-only RSA-Unterschlüssel

Erstellen des Authenticate-only RSA-Unterschlüssels (RSA-4096bit, Flag(s); Authenticate, verfällt nach einem Jahr (=1y)).

gpg --edit-key --expert Key-ID-des-Hauptschlüssels
Befehl> addkey

Nun muss man seinen Passphrase eingeben, um den Private-Key zu entsperren und den Unterschlüssel hinzufügen zu können.

Los geht's:

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (2) DSA (nur unterschreiben/beglaubigen)
   (3) DSA (eigene Fähigkeit setzen)
   (4) Elgamal (nur verschlüsseln)
   (5) RSA (nur signieren/beglaubigen)
   (6) RSA (nur verschlüsseln)
   (7) RSA (eigene Fähigkeit setzen)
Ihre Auswahl? 7

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun setzt/entfernt man also die Flags, die man nicht haben will. Für einen Authenticate-only-Schlüssel muss man, wie man an der Zeile Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln sieht, noch den “Unterschreiben”/Sign-sowie den “Verschlüsseln”/Encrypt-Flag entfernen und den “Authentifizierung”/Authenticate-Flag hinzufügen. Dazu geht man wie folgt vor:

Ihre Auswahl? S

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Ihre Auswahl? E

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Ihre Auswahl? A

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Authentifizieren 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun passt es. Weiter geht's:

Ihre Auswahl? Q
RSA Schlüssel können zwischen 1024 und 4096 Bits lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1y
Key verfällt am <DATUM> <UHRZEIT>
Ist dies richtig? (j/N) j
Wirklich erzeugen? (y/N) y
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
[...]

Jetzt heißt es warten.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln:

Befehl> save

Weitere Identitäten hinzufügen

gpg --edit-key Key-ID-des-Hauptschlüssels
Befehl> adduid

Der folgende Dialog sollte selbsterklärend sein. Falls einem die Identitätsverwaltung via Konsole zu frickelick ist, dem kann ich Seahorse als grafische Oberfläche empfehlen.

Falls man sich mal vertippt hat: Editieren ist nicht möglich. Stattdessen muss man die fehlerhafte Identität löschen und anschließend neu anlegen.

Die Hauptidentität kann mittels

gpg --list-key Key-ID-des-Hauptschlüssels
Befehl> primary
Bitte genau eine User-ID auswählen.

Befehl> <NUMMER>

ausgewählt werden.

<NUMMER> entnimmt man der direkt darüber angezeigten Auflistung. Beispiel

[uneingeschränkt] (1).  John Doe (privat) <foobar@example.com>
[uneingeschränkt] (2)   John Doe (business) <business@example.com>

(1). ist die derzeitige Hauptidentität. Um (2) zur Hauptidentität zu machen, müsste man also

gpg --edit-key Key-ID-des-Hauptschlüssels
Befehl> primary
Bitte genau eine User-ID auswählen.

Befehl> 2

verwenden. Im der folgenden Auflistung ist die neue Hauptidentität mit einem Sternchen gekennzeichnet. Die Nummerierung ändert sich erst nach dem Speichern.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln:

Befehl> save
Befehl> quit

Überprüfen

Alles was man gerade erstellt hat, kann man sich einfach auflisten lassen:

gpg --list-key Key-ID-des-Hauptschlüssels

Es sollte eine Ausgabe, erscheinen, die so ähnlich aussieht wie die Folgende:

pub   4096R/B55A743F <DATUM>
uid                  John Doe (privat) <foobar@example.com>
uid                  John Doe (business) <business@example.com>
sub   1024D/56F9EF32 <DATUM> [verfällt: <DATUM>]
sub   1024R/A99B3881 <DATUM> [verfällt: <DATUM>]
sub   2048R/6D0696AE <DATUM> [verfällt: <DATUM>]

Hinweise zum Verständnis:

  • Hinter pub findet sich der Hauptschlüssel.
  • Hinter sub findet sich jeweils ein Unterschlüssel
  • Hinter uid finden sich and den Hauptschlüssel angehängte Identitäten (User-IDs).
  • Die Bitstärke, Algorhithmus, Key-ID und Erstellungsdatum verstecken sich in hinter <BITS><ALGORHITMUS>/<KEYID> <DATUM>. R steht dabei für RSA, D für DSA und g für ElGamal.20)

Fertig. Die neue Schlüsselhierarchie ist einsatzbereit. Jetzt einfach den Publickey exportieren und wie gewohnt nutzen, unterschreiben lassen etc..

11)
oder erst nach vielen Jahren
12)
z.B. jährlich
13)
am besten die Einstiegs-Weblinks am Ende dieses Textes durcharbeiten und alles einmal ausprobieren
14)
seit GPG 1.4 verfügbar
16)
seit GPG 1.4
17)
es geht aber auch gänzlich ohne
18)
also nicht an der Meldung “Es sind nicht genügend Zufallswerte vorhanden. Bitte führen Sie andere Arbeiten durch, damit das Betriebssystem weitere Entropie sammeln kann!” verzweifeln, sondern einfach dem Rat folgen und ein wenig surfen, bis sich wieder etwas tut.
19)
Aufbau: pub <BITS><ALGORHITMUS>/<KEYID> <YYYY-MM-DD>. Die gesucht ID steht also hinter dem Schrägstrich.
20)
in der hier vorhanden Konfiguration nicht genutzt

// Microsoft und gar nicht so zufällige Zahlen

Bruce Schneier hat einen neuen US-Standard zur Erzeugung von Zufallszahlen und den darin enthaltenen Generator Dual_EC_DRBG schon etwas länger im Visier, da er darin eine Backdoor für die NSA vermutet, die über die ggf. gar nicht so zufälligen Zahlen kryptographische Schlüssel angreifen könnte.

Nun ist Bruce Schneier ein bedeutender Krypto-Experte – um so unverständlicher (außer es ist etwas dran, an Schneiers Vermutung ;-)) ist es, dass Microsoft Dual_EC_DRBG ohne Veränderung im SP1 für Vista eingebaut hat und damit bald an seine Kunden ausliefert. Schneier rät daher allen Programmieren einschlägiger Software ab, Dual_EC_DRBG in den eigenen Programmen zu nutzen. Ein Rat, den man befolgen sollte.

// Adobe spart wohl am falschen Ende...

Irgendwie ging das an mir vorbei, was da Adobe vor rund einer Woche passiert ist: heise.de: Adobes Webserver sperrangelweit offen. Das CGI-Skript zum Download von Dateien hat einfach mal alles ausgeliefert, was man ihm über einen Parameter übergeben hat, z. B.:

  • http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version= ../../../../../../../../../etc/passwd%00
  • http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=../../../../../../../../../usr/local/apache/conf/ssl.key/www.adobe.com.key%00
  • http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version= ../../../../../../../../../usr/local/apache/conf/ssl.crt/www.adobe.com.crt%00

:-O :-O

Ich bin immer wieder erstaunt darüber, wie oft auch bei professionellen Anwendern über trivialste Fallstricke wie “../” gestolpert wird. Klar, Fehler können passieren. Ich meine aber, Adobe hat sicherlich genug Kleingeld um Leute zu engagieren, denen Fehler dieser Kategorie eigentlich nicht passieren sollten. Das Ganze hat IMHO neben der allgemeinen Belustigung aber noch etwas wirklich Positives: es ist ein gutes Beispiel, dass nicht immer PHP schuld ist, wenn Anfänger solche Fehler in Serie produzieren. Man schafft dies in jeder Sprache. Das Problem sitzt eindeutig vor dem Bildschirm.

// Skype, die Vertrauenswürdigkeit und die Alternativen

Keine Frage – Skype hat Erfolg, erfüllt auf zahlreichen Rechnern brav seinen Dienst und ermöglicht vielen Menschen auf dieser Welt komfortabel und kostengünstig zu kommunizieren. Zudem ist es einfach zu bedienen, daher will ich dem Programm sicher nicht seine Daseins-Berechtigung absprechen. Aber Skype hat auch ein paar unschöne Seiten, die dem normalen Nutzer wohl nicht direkt auffallen. Diese sind zum Teil offensichtlich, anderes kann man ob sehr umfangreicher Verschleierungstaktiken nur erahnen. In jedem Falle sollte man sich darüber informieren und dann abwägen, ob der Komfort von Skype die Nachteile aufwiegt.

Kommmen wir zunächst zu den offensichtlichen Dingen:

  • Skype ist sowohl bei der Signalisierung als auch bei der Übertragung proprietär und redet prinzipiell nur mit Produkten des Herstellers. Setzt man einmal auf Skype, bleibt man also zwangsweise auch dabei, sofern man nicht alle seine Kontakte verlieren will. Andere Lösungen setzen auf Standards und können so auch untereinander und Hersteller-übergreifend kommunizieren.
  • Die Firma hinter Skype ist den Kinderschuhen entwachsen, gehört mittlerweile zu eBay und spielt daher in der Liga “der Großen”. Dort gelten andere Regeln. In Zeiten von Vorratsdatenspeicherung & Co. macht dies nicht gerade Hoffnung, dass der Konzern nicht einfach nur in eigenem Interesse handelt statt sich für seine Nutzer einzusetzen. Das die Signalisierung dazu noch über zentrale Server von Skype im Ausland (wo Datenschutzgesetze fehlen) abgewickelt wird, macht das ganze noch schlimmer.

Kommen wir zu den weniger offensichtlichen Dingen:

Kommen wir zu den Problemen mit der Sicherheit:

  • Skype vertraut jedem, der Skype spricht. Soll heißen: Wenn die Software denkt, auf der anderen Seite der Leitung ist ebenfalls ein Skype-Client, entfallen zahlreiche Checks. In Verbindung zu der gut verschleierten und verschlüsselten Datenübertragung sowie dem oben genannten “Lochtrick” bezüglich Firewalls, könnte sich eine Lücke in der Software als ein ultimativer Sicherheits-GAU herausstellen – würden doch Angriffe auch noch wunderbar vor der Entdeckung geschützt. Folie 96 ff. des genannten Vortrags ist diesbezüglich auch ganz interessant.

Genug zu den Nachteilen von Skype für heute. Die Listen würden sich bestimmt noch erweitern lassen, doch widmen wir uns lieber möglichen Alternativen. Für ausführliche Reviews fehlt mir gerade ein wenig die Zeit, Sie folgen ggf. noch. Ich will jetzt aber jemanden, der sich bis hier hin im Text durchgekämpft hat nicht so einfach hängen lassen, und wenigstens ein paar Links zum Einstieg liefern:

Über Erfahrungsberichte zu den genannten Alternativen (gerne auch per Mail) würde ich mich auch freuen…

I'm no native speaker (English)
Please let me know if you find any errors (I want to improve my English skills). Thank you!
Recent Comments
QR Code: URL of current page
QR Code: URL of current page start (generated for current page)