SSH/SCP - Sicherheit und Geschwindigkeit

• http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_09.htm
• DSA- und ECDSA-Signaturen

Zur Zeit ist das ED25519-Schlüsselformat, das sicherste verfügbare SSH-Schlüsselformat!
RSA mit großer Schlüssellänge ist der zweitsicherste, die DSA-Schlüssel sind alle NSA-optimiert und somit als unsicher anzusehen.

ACHTUNG
Die ED25519-Schlüssel werden erst seit Ubuntu 14.04 (ab OpenSSH 6.5) unterstützt!

Der ED25519-Schlüssel hat eine feste Länge von 256 Bit, hier wird die Option "-b" ignoriert:

> ssh-keygen -o -t ed25519 -a 256

Die Option -a beschreibt, mit wieviel Rotationen die Passphrase verschlüsselt wird.
Je größer diese Anzahl ist, desto stärker ist die Passphrase gegen Brut-Force-Angriffe gesichert aber desto langsammer ist auch der Verbindungsaufbau.
Die gleiche Wartezeit, die zum generieren des Schlüssels benötigt wird, fällt auch bei einem Verbindungsaufbau mit dem generierten Schlüssel an.
Also wenn das generieren eines Schlüssels mit 65536 Runden ca. 10 Minuten dauert, dann wird der Vebindungsaufbau mit diesem Schlüssel von diesem Rechner aus, auch ca. 10 Minuten benötigen!

In soeinem Fall sollte man die Anzahl der Runden auf einen Wert reduzieren, bei dem die Zeit zum generieren bzw. für den Verbindungsaufbau, in einem verträglichen Zeitrahmen liegt.

Auf einem Rechner mit einer "Intel Core i7-2620M 2.70GHz"-CPU, dauert der Login mit einem ED25519-Schlüssel mit 1024 Runden, ca. 10 Sekunden und mit 65536 Runden ca. 10 Minuten. Mit 128 Runden dauert der Verbindungsaufbau auf einem Rechner mit einer "Intel Core i7-2620M 2.70GHz"-CPU, ca. eine Sekunde.

Um das Problem zu beheben, müssen einmalig zwei Zeilen an die ~/.bashrc unten angefügt werden:

> echo 'eval $(ssh-agent)' >> ~/.bashrc
> echo "ssh-add" >> ~/.bashrc

Ab jetzt wird beim öffnen eines Terminal-Fensters die Passphrase abgefragt und die Schlüssel (auch der Ed25519-Schlüssel) ordentlich aufgenommen. Und ein passwortloser Login ist jetzt auch mit dem Ed25519-Schlüssel möglich.

Stand: Mai 2011

RSA war mal durch Patente geschützt, die sind jetzt aber abgelaufen. Der ECDSA-Algorithmus stammt noch aus der Zeit und sollte eine freie Alternative zum durch Patent geschützten RSA sein.

Vor kurzem wurde der ECDSA-Algorithmus geknackt. ECDSA-Schlüssel sollte man als "veraltet" und "unsicher" betrachten.

Schlüsselstärkenvergleich (Brutforce-Angriff, kein Strukturangriff!):

1. 160 Bit ECDSA-Schlüssel ⇒ 1024 Bit RSA-Schlüssel
2. 224 Bit ECDSA-Schlüssel ⇒ 2048 Bit RSA-Schlüssel
3. 256 Bit ECDSA-Schlüssel ⇒ 3072 Bit RSA-Schlüssel
4. 521 Bit ECDSA-Schlüssel ⇒ 15360 Bit RSA-Schlüssel

1. da die RSA-Patente abgelaufen sind, ist RSA jetzt frei;
2. einen RSA-Schlüssel kann man mit einer beliebigen Schlüssellänge generieren;
3. Signaturen werden schneller verifiziert als erzeugt;
4. um die Sicherheit eines 1024 Bit DSA-Schlüssels zu erzielen, muss der RSA-Schlüssel ca. 1232 Bit lang sein;
5. RSA kann zum Signieren und zum Verschlüsseln verwendet werden (das tut OpenSSH aber nicht, da es aus kryptografischer Sicht ungünstig ist);

1. einen DSA-Schlüssel kann man nur mit einer maximalen Schlüssellänge von 1024 Bit generieren (das alte DSS konnte auch längere);
2. DSA hängt wohl doch sehr von guten Zufallszahlen ab, die man unter Windows wohl nicht bekommt;
3. bei der Implementierung von DSA, kann man wohl viele Fehler machen die die Sicherheit des Verfahrens stark gefährden, dem entsprechend gibt es angeblich auch viele problematische DSA-Implementierungen;
4. Signaturen werden schneller erzeugt als verifiziert;
5. DSA kann nur zum Signieren, nicht zum Verschlüsseln verwendet werden;

Auf dieser Seite wurden Transfervergleiche mit unterschiedlichen Cipher (Kodes) gefahren:

• http://blog.famzah.net/2010/06/11/openssh-ciphers-performance-benchmark/

Da die Pakete bei FTP unbearbeitet über das Netz gehen, ist es die schnellste aber auch unsicherste Methode, Daten zu übertragen. Aus diesem Grunde verwendet man heute SSH/SCP/SFTP zur verschlüsselten Datenübertragung. Hier kann man die Daten auf verschiedene Weise verschlüsseln/kodieren. Jeder von SSH unterstützte Kode hat seine besonderen Eigenschaften, deshalb ergibt sich auch ein Unterschied in der Datenübertragungsrate und der Sicherheit in Abhängigkeit vom verwendeten Kode:

1. Standard ist der Kode "3DES", es ist der langsamste aber nicht der sicherste;
2. der schnellste ist "ARCFOUR" (kompatibel zu "RC4");
3. "AES" ist langsam aber sicherer als "3DES";
4. als einen sehr guten Kompromiss zwischen Sicherheit und Geschwindigkeit kann man den "Blowfish"-Kode ansehen;
5. die FreeBSD-Version von SSH2 beherrscht sogar den "Twofish"-Kode, ihn kann man als den sichersten Kode ansehen, von allen die SSH unterstützt;

Welche Kodes (Cipher) von der eingesetzten SSH-Version unterstützt werden, kann man sich wie folgt anzeigen lassen:

# man ssh_config

• ⇒ siehe in der Sektion Ciphers

Beispiel:

# ssh -c blowfish -X fritz@rechner
# scp -c blowfish testdatei.txt fritz@rechner:

Es ist auch möglich mehrere Kodes (Cipher) kommasepariert anzugeben:

# ssh -c blowfish,blowfish-cbc,aes256-ctr,aes192-ctr,aes128-ctr,3des,arcfour,arcfour256,arcfour128 -X fritz@rechner
# scp -c blowfish,blowfish-cbc,aes256-ctr,aes192-ctr,aes128-ctr,3des,arcfour,arcfour256,arcfour128 testdatei.txt fritz@rechner:

Man kann die bevorzugten Kodes (Cipher) auch in der Konfigurationsdatei vom SSH-Client dauerhaft eintragen und spart sich so das aufführen auf der Kommandozeile.

# vi /etc/ssh/ssh_config
....
Ciphers blowfish,blowfish-cbc,aes256-ctr,aes192-ctr,aes128-ctr,3des,arcfour,arcfour256,arcfour128
....

RSA basiert darauf, dass man Primzahlen nicht erraten kann, weil man davon ausgeht, dass sie im Zahlenraum unvorhersehbar verteilt sind… Geht man von existierenden mathematischen Beweisführungen aus, dann liegt man da gar nicht so falsch… Aber wenn man die empirischen Erfahrungen im gesamten Zahlenraum, die von heutigen Computern bearbeitet werden, betrachtet, dann ist das komplett falsch!

Siehe dazu den Vortrag über die Riemannsche Vermutung.

Riemann hatte vor Jahrhunderten schon vermutet, dass die Primzahlen, im Zahlenraum, nur auf einem schmalen Streifen liegen. Das wurde mathematisch noch nicht bewiesen (darauf berufen sich alle) aber es wurde im gesamten Zahlenraum, den Computer bearbeiten können, schon empirisch nachgewiesen. Demnach sind auch RSA-Schlüssel (egal wie lang) nicht mehr sicher. Nun kann man sagen, dass RSA ja schon durch die Kosinusfunktionen abgelöst wurden… aber da haben wir das gleiche Problem, wie bei DSA, diese Schlüssel (z.B. ed25519) sind in ihrer Länge auf nur 256Bit beschränkt.

Soviel zu Sicherheit, heutzutage!!!