[Crosspost] Neulich, im Krypto-Sumpf... verschlüsseln und signieren mit OpenSSL

[daemotron]

Moin, die u. g. Frage habe ich auch bei BSDForen.de gestellt. Da ich keinen Aspekt übersehen möchte, gibt's sie ausnahmsweise auch hier als Crosspost:

Ich weiß, der Standard-Ratschlag lautet: Finger weg von Krypto. In dem Fall versuche ich allerdings auch "nur", vorgefertigte Komponenten zu nutzen, um Backup-Dateien vor dem Wegspeichern auf einem potenziell unsicheren System zu verschlüsseln und zu signieren. Ich möchte das ganze nur mit OpenSSL umsetzen, da es nur ein Shell-Skript werden soll (damit fallen NaCl oder Sodium leider aus) und ich möglichst dafür kein Third Party Zeugs (z. B. GnuPG) installieren müssen möchte (Recovery soll aus einem Rettungssystem heraus möglich sein).

Folgendes Vorgehen habe ich mir bei Colin Percival und Daniel Bernstein's NaCl Bibliothek abgeguckt (falls ich das alles richtig verstanden habe):

1. Datenstrom komprimieren (ich nutze dazu xz)
2. Erzeugen eines Random Schlüssels, eines Random Salts und eines Random IVs plus ein Random HMAC Passwort
3. Datenstrom verschlüsseln (in Ermangelung einer Salsa20 Implementierung in OpenSSL würde ich dazu aes265-cbc verwenden, mit dem soeben generierten Schlüssel, Salt & IV)
4. Erstellung einer HMAC (in Ermangelung von Salsa20 und Poly1305 mit SHA512)
5. Erstellung einer Signatur (in Ermangelung von Curve 25519 mit SHA512 und RSA)
6. Verpacken von Schlüsseln, Salt und IV zusammen mit dem HMAC in einer Datei
7. Diese Datei mit xz komprimieren
8. Das Komprimat mit RSA verschlüsseln

Im Ergebnis hätte ich also drei Dateien: die eigentlichen Daten gepackt und AES-verschlüsselt, eine Signatur-Datei für die verschlüsselten Daten und eine RSA-verschlüsselte Datei mit den AES Schlüsseldaten und dem HMAC. Der HMAC ist dabei eigentlich doppelt gemoppelt (schließlich gibt es ja eine Signatur-Datei), andererseits gibt der HMAC ein gutes zusätzliches Padding für die AES Schlüsseldaten ab... Die Signatur muss übrigens aus praktischen Gründen in einer separaten Datei bleiben - sie ist einfach zu groß, um per RSA verschlüsselt zu werden.

Vorteil aus meiner Sicht:
Man benötigt immer nur den öffentlichen und privaten RSA Schlüssel zur Backup-Erstellung (verzichtet man auf die Signatur und verlässt sich ausschließlich auf den HMAC, benötigt man sogar nur den öffentlichen Schlüssel für die Backup-Erstellung; der private Schlüssel kann dann schön im Safe bleiben)

Potenzielle Risiken:

• Wenn die Schlüsseldatei beschädigt wird, kommt man an das eigentliche Backup nicht mehr ran.
• Jemand könnte die Schlüsseldateien aufmachen (wie wahrscheinlich ist sowas?) und käme dann an alles heran, könnte auch den Inhalt des Backups in bösartiger Weise manipulieren und mit einem veränderten HMAC Integrität vortäuschen... (insb. wenn auf die Signatur verzichtet wird, was aber das Leak-Risiko für den privaten RSA Schlüssel wiederum senkt...)

Wie bewertet Ihr die Sicherheit und die Praktikabilität bei diesem Vorgehen? Welche Fettnäpfe habe ich übersehen?

Ach ja, AES im CBC Modus zu verwenden halte ich für relativ unbedenklich, da in diesem Fall sowohl Key als auch IV und Salt jedes Mal neu generiert werden, und die Authentizität des Cipher Textes zusätzlich mittels Signatur oder HMAC validiert wird.

[Joe User]

Kannst Du das Vorgehen kurz mal in nackte openssl-Befehlszeilen packen, das macht es etwas nachvollziehbarer, zumindest für mich. Prinzipiell hört es sich für mich aber soweit schon richtig an, eventuell schon etwas too much(?).

[daemotron]

Kannst Du das Vorgehen kurz mal in nackte openssl-Befehlszeilen packen

Aber klar doch

Davon ausgehend, dass meine Daten in der Datei message.txt liegen:

Code: Select all

# RSA Schlüssel erzeugen - muss man nur einmal machen
openssl genrsa -out private.key 8192
openssl rsa -in private.key -out public.key -pubout

Symmetrische Schlüssel erzeugen

Code: Select all

key=$(openssl rand -hex 32)
iv=$(openssl rand -hex 16)
salt=$(openssl rand -hex 64)

Daten komprimieren und verschlüsseln

Code: Select all

xz -zkc message.txt | openssl enc -e -aes-256-cbc -K $key -iv $iv -S $salt -out message.enc

HMAC erzeugen und mit den Schlüsseln in einer Extra Datei ablegen und diese verschlüsseln:

Code: Select all

hmacpw=$(openssl rand -hex 48)
hmac=$(openssl dgst -sha512 -hmac $hmacpw -hex message.enc | sed 's/^.*=[[:space:]]//g')
echo "${key}:${iv}:${salt}:${hmacpw}:${hmac}" | openssl rsautl -inkey public.key -pubin -encrypt -out message.key

(Optional) Signatur erzeugen

Code: Select all

openssl dgst -sha512 -sign private.key -out message.sig  message.enc

Prinzipiell hört es sich für mich aber soweit schon richtig an, eventuell schon etwas too much(?)

Ich spiele mit dem Gedanken, auf die Signatur mittels privatem RSA Schlüssel zu verzichten. Dadurch muss dieser nicht auf dem Server liegen und ist somit weniger exponiert. Allerdings bin ich mir nicht zu 100% sicher, ob der HMAC reicht bzw. ausreichend manipulationssicher ist...

P. S. der RSA Schlüssel ist so monströs groß, da der Schlüssel selbst größer sein muss als die Message, die er verschlüsseln soll. Da in der Shell die Hex-Schlüssel als Zeichenketten behandelt werden, verdoppelt sich deren Größe. Die Message ist also (2x32 + 2x16 + 2x64 + 2x64 + 5) = 357 Bytes = 2856 Bits groß. Der Schlüssel muss also mindestens 4096 Bits haben, sonst funktioniert die Geschichte nicht (OpenSSL weigert sich dann auch und bricht mit einer Fehlermeldung ab).

[daemotron]

Ach ja, und so wäre dann der umgekehrte Vorgang:

Signatur verifizieren

Code: Select all

openssl dgst -sha512 -verify public.key -signature message.sig message.enc

Key-Datei entpacken

Code: Select all

plain=$(openssl rsautl -inkey private.key -decrypt -in message.key)
key=$(echo $plain | awk -F ":" '{print $1}')
iv=$(echo $plain | awk -F ":" '{print $2}')
salt=$(echo $plain | awk -F ":" '{print $3}')
hmacpw=$(echo $plain | awk -F ":" '{print $4}')
hmac=$(echo $plain | awk -F ":" '{print $5}')

Integrität verifizieren

Code: Select all

hmac2=$(openssl dgst -sha512 -hmac $hmacpw -hex message.enc | sed 's/^.*=[[:space:]]//g')
[ "${hmac}" != "${hmac2}" ] && echo "Verification failed" || echo "Verification succeeded"

Entschlüsseln

Code: Select all

openssl enc -d -aes-256-cbc -K $key -iv $iv -S $salt -in message.enc | xz -dc > message2.txt

Kontrolle, ob die Daten noch dieselben sind:

Code: Select all

diff -ru message.txt message2.txt

[Joe User]

Ich habe es mal auf OpenSSL 1.0.1+ upgedated und eine automatische Passworterzeugung/nutzung hinzugefügt, sed de-gnu-ed, Backticks zur Shellkompatibilität:

Code: Select all

echo 'Hello world!' > message.txt

openssl rand -hex 16 | openssl passwd -1 -stdin | tr -cd '[[:alnum:]]' | sed -e 's/^1//' > private.pwd

openssl genpkey -aes-256-cbc -algorithm RSA -pkeyopt 'rsa_keygen_bits:8192' -out private.key -pass 'file:private.pwd'
openssl pkey -in private.key -out public.key -passin 'file:private.pwd' -pubout

key=`openssl rand -hex 32`
iv=`openssl rand -hex 16`
salt=`openssl rand -hex 64`
xz -z -k -c -4e message.txt | openssl enc -e -aes-256-ctr -K $key -iv $iv -S $salt -out message.enc

hmacpw=`openssl rand -base64 48`
hmac=`openssl dgst -sha512 -hmac $hmacpw -hex message.enc | sed -e 's/^.*=[[:space:]]//g'`
echo "${key}:${iv}:${salt}:${hmacpw}:${hmac}" | openssl rsautl -inkey public.key -pubin -encrypt -out message.key -passin 'file:private.pwd'

openssl dgst -sha512 -sign private.key -out message.sig -passin 'file:private.pwd' message.enc

[daemotron]

Einen Bug habe ich schon gefunden... Beim erzeugen einer Signatur mit

Code: Select all

openssl dgst -sha512 -sign <key> ...

darf man das -hex flag nicht mit angeben - sonst failed die Verifizierung. Die kann offenbar nur mit dem Binary-Format umgehen...

[Joe User]

Habs in meinem Post korrigiert, danke.

[Joe User]

Der Rückweg mit dem zuvor automatisch generiertem Passwort:

Code: Select all

openssl dgst -sha512 -verify public.key -signature message.sig message.enc

plain=`openssl rsautl -inkey private.key -decrypt -in message.key -passin 'file:private.pwd'`
key=`echo $plain | awk -F ":" '{print $1}'`
iv=`echo $plain | awk -F ":" '{print $2}'`
salt=`echo $plain | awk -F ":" '{print $3}'`
hmacpw=`echo $plain | awk -F ":" '{print $4}'`
hmac=`echo $plain | awk -F ":" '{print $5}'`

hmac2=`openssl dgst -sha512 -hmac $hmacpw -hex message.enc | sed -e 's/^.*=[[:space:]]//g'`
[ "${hmac}" != "${hmac2}" ] && echo "Verification failed" || echo "Verification succeeded"

openssl enc -d -aes-256-ctr -K $key -iv $iv -S $salt -in message.enc | xz -d -c -4e > message2.txt

diff -dqs message.txt message2.txt

[Joe User]

Beide Wege getestet und sie funktionieren problemfrei.

IMHO sollte es so auch ausreichend sicher sein und somit ein akzeptabler Ersatz für gnupg.

[daemotron]

Prima, danke für die Rückmeldung. Ich zerbreche mir gerade noch den Kopf, ob CBC oder CTR die dümmere Idee sind. CBC braucht Padding und ist daher (zumindest theoretisch) anfällig für Padding Oracle Attacks. Thomas Pornin kommt daher zu dem Schluss, das CTR der bessere Modus sei. Auch Colin Percival nutzt CTR für seine Tarsnap Software. Die OpenSSL Manpage zu enc hingegen empfiehlt, es bei CBC zu belassen, wenn man keinen guten Grund hat, davon abzuweichen. Da hier HMAC und Signatur auf den Ciphertext (nicht auf den Plaintext!) angewendet werden, sollte Padding Oracle eigentlich kein Thema sein, womit der "gute Grund" dann wohl nicht gegeben wäre...

GCM geht übrigens nicht, da enc keine AEAD ciphers unterstützt (OpenSSL selbst schon, aber halt nicht das CLI).

[Joe User]

Ab OpenSSL 1.0.2 kann enc GCM+AEAD wohl, zumindest schmeisst es keine entsprechende Fehlermeldung mehr.

OpenSSH bevorzugt CTR gegenüber CBC falls das die Entscheidung leichter macht.

[Joe User]

Habe einfach mal bei beiden enc aes-256-cbc durch aes-256-gcm ersetzt (ansonsten Alles unverändert) und durchlaufen lassen: Funktioniert, lediglich eine falsche Fehlermeldung (bad decrypt) beim enc -d, aber die message2.txt ist trotzdem korrekt.

[daemotron]

Oh, interessant, hier funktioniert es nicht:

Code: Select all

~ % openssl version
OpenSSL 1.0.2d 9 Jul 2015
~% key=$(openssl rand -hex 32)
~% iv=$(openssl rand -hex 16)
~% salt=$(openssl rand -hex 64)
~% xz -zkc message.txt | openssl enc -e -aes-256-gcm -K $key -iv $iv -S $salt -out message.gcm
AEAD ciphers not supported by the enc utility
~% echo $?
1

GCM benutzt intern übrigens ebenfalls CTR und "würzt" es nur mit einem HMAC Verfahren, wodurch eine zusätzliche HMAC Erzeugung überflüssig würde.

Das mit OpenSSH kannte ich; eigentlich sollte CBC mit SSH gar nicht mehr genutzt werden, da ein bestehender & funktionierender Angriff existiert. Dieser beruht jedoch darauf, wie das Fehler-Handling im SSH-Protokoll funktioniert. Hier noch das Paper dazu: http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf

Für den Fall "lokale Datei" zieht das nicht wirklich, da schenken sich CBC und CTR nicht viel. Am Ende läuft es darauf hinaus:

• CTR bietet Schutz gegen Oracle Padding Angriffe, die aber bei HMAC Einsatz eigentlich keine Gefahr darstellen, gibt dafür aber ein klein wenig mehr Hinweise auf die Größe des originalen Plaintexts als CBC. Verwendet man dieselbe nonce mehrfach, ist das jedoch fatal (kann hier eigentlich nicht passieren, da alle Parameter randomisiert sind).
• CBC gibt weniger Hinweise auf die Größe des Plaintexts als CTR; das Verfahren und besonders seine Implementierung in OpenSSL ist wesentlich älter.

Nach Faktenlage sind beide Modi für mein Szenario kryptographisch sicher, wenn korrekt angewendet und implementiert. Da ich eine Schwäche eher in meiner selbst gebauten Signatur sehe, halte ich theoretisch einen Padding Oracle Angriff für die etwas wahrscheinlichere Schwachstelle in diesem Szenario. Ergo halte ich es wohl mit Colin Percival und benutze CTR...

[Joe User]

Mein Fehler, habe auf dem NAS testweise LibreSSL statt OpenSSL :(
Auch OpenSSL 1.0.2 kann mit enc kein GCM.

Peinlich...

[daemotron]

Eine Geschichte ist mir noch über den Weg gelaufen: Wenn der private Key verschlüsselt werden soll, dann sollte besser PKCS#8 verwendet werden - der Standard (ASN.1 mit DER-Serialisierung und optionaler Base64 Codierung) ist da nicht besonders clever - der IV steht im Klartext in der verschlüsselten Datei, und der Schlüssel selbst wird durch einen einfachen MD5-Aufruf (nicht mal crypt-md5) auf das Passwort erzeugt (mit ein bisschen Padding, aber nichts, was nicht schnell nachzubauen wäre). Da sowohl einfaches MD5 als auch AES ziemlich schnell berechnen (und eine ASN.1 Validierung auch kein Voodoo ist), lässt sich ein solcher Passwort-Schutz ggf. schneller per Bruteforce cracken als eine Shadow-Datei mit moderneren Passwort Hashes. Details finden sich hier: https://martin.kleppmann.com/2013/05/24 ... -keys.html

[Joe User]

Entweder ich bin zu blöd zum Abtippen, oder seine Befehlszeile ist buggy:

Code: Select all

[root@devgate:~] # cat private.key
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIISnzBJBgkqhkiG9w0BBQ0wPDAbBgkqhkiG9w0BBQwwDgQIGsBBFmRbTR0CAggA
MB0GCWCGSAFlAwQBKgQQ15H23EaGMXVwJQQG0TOjQwSCElAU8gJHR42R1AVQeJCe
O6DdX7N/QAJyGDGlO8LMi8yHioi38IQHaf0Pr2EbsIYnC4+7DBSB8GXHKpsaN8Xy
fe6oAKfNuPlHh7We7DruvlyoStgodlpe9JM6+Bh3VNUFO/35rEG3U2dFrzsntizY
0rFg3YYo1lbWTZhbLBuo9qTvl4H3GzVkfrNrIrfI6RnRDs5j2xbztY8TZV0NGorI
NEcqRltmmmIRWpz2k1q6cO7b4anuOFGtbyYbLm+i7XceloraoCAZoThsbEaNFQUt
7W1NF1L1F1ueEQL0oREh8mHJsF183ZRO1AQJQ1wio7BOlhKwsoCcal2bxWPy7QKI
Vva1pBe3VY6+QxjAgiqgenC8iepuCWx8ZAV/V2xUMM7W1dhlEf/3aEzWo7B+nTdE
ZmTmREVM+7jWR+0Wrs0/uAtc7dgFnuSdK3TV+O/jZPN1fMVPhOxQ60P+V5BQsFDx
BZ30QkBgSa9TPKc9SXu21jNLnOufte+cLcqdaP3ypDu2AxMBBAsNsYi5ebVPAmVg
7x8iiYw7GcdmWxEOQ3C5HGDHlPWBw+wytDua/SPlnKp4vojNvd6eQ4r+lK549Mkx
XBxuhyqR68dDEr7Gn6kL4h3DcmDwH6xey6Pxwhh1aokxyQRpWJsrmyrLZ18+fJwC
EC9J/0JZ+07RGvJbEP/m5oZ5guLJFmJzsVUPPXZ2QEgah8DFZXoeWT2T4xxj2bsn
r9grJ90fUXgyK9pS88K/lTqB6xL70YV8Xzn6dvD+7CYwFKiHV/Rk8VAOO3qvpGYD
AelEPYnVY837+gDpl8v0oGXtK5c/MQvPc30b17gUopGJkcjwN5J/LmBgJiH7zxJm
nNgDTPd+SZqXGNSUmQn3ogd07bJcbDRcVd1K00HZIcFvuThAHbF3Zl2qbkVhoQWF
UOr65DIhk7xODw8UiWZynQP8q2HnByt3aZR7I8Wip0UsYyikJgwwgklSpsejnx/A
uVHgMoDCXBpfzcdmhsVoj2mPe6PoeNYxH391YfVm7QSXYkT3yHzQ+dopFBoXiHgi
e3yV1nuMncJPV32S1jn0/ud/W3jzf4UQGHN/tdqkIGrzbpTcgzrdwvx6XDyr0FVl
KADsThMP7YXrQI/UjAmYr/OWg2mDePsEY6CALmi+pKWCHb9vOL1X5DZJKm1zBMJl
Yo4TVXQY2Wp1kc6lFwtyQAzeEjtwliOychw7KM3wdkoQ7mTZlieJr6v3fYugcFnO
R6IYNf/BnttLnQPFETGcejBy/5YIkXNz7aNXQNGOpcOy8gAKR0vNi6WoWduHDbQM
aAHnBj2ge+3Mi6ojAxUgmJnTU2y9LlUO47XYKSNZaSflbSajh1/S0OnsovLdIUZR
OnS/dzBmwByYtgdkDn6vNljFkhqVbObBqZT0m4avBRJCfbEHrGKdvZxEr0a0BJfl
oEIljnQMAtD8fok9XnY2ChF6lTrwvtm6sMvO1S6ml/PiPgH0xS0BjnkrTYWhV9+6
Lm3HGvScx25HsEXZ/VPBaOz4IDpPl++wis/AZVAysBYZvlDXdCJY4D6eCjav9zdp
VAK12rAJrA6+KgGuVLGa6xMLY85ejpsq2iJWCuE54+gDjaAj5XgC7N6fA0H/CuBw
DPBY/andis2IEy+YRnr4UrTBRBOntqBuBlC3bpf0OwX2jsUfHkb6cqRTLFu6mbtH
jmeKuhabGlA3J+tV5UPdQsYQELBeEEfsaanZRxnqIYJtdEMhc0O7IwNnjkhKPSY1
WM+1n99kx/C3EDWLZNOJIZbaJmLKMxm8s0WVcuNsMPEtCP4P0iRyOzM8S9Ygx44w
rfMUdiQ+/eTi0Wcuin9OmGFevBMui6m2TR5cUl54CM6x2S2PS1X486B/trWZFaMy
WnEMBkryRJLaK2ZRil6KhL3sI4L3OA8OOEPOwoMLKxsdkCy8OPkj7+bXWo+zFMZ0
wzcT1xiOfp6j5YrdFNGMPeE01gCYcYp4Y/L5oGf+3DZJV/wslj7zWvuoB+AUzF7M
DfUmHpQZGbelNOxEN+ZxGPH9euzbvWiAAHvaghEFFY5xPyR+ln6bHhWNu9cDW0TR
CaMe0h/XBvuQJS9vToiR1j1681G2cK2rQJVLI/BQorYEVsrPYxjktBYl1cNv5T7+
kawv4Eklcvc5sTuoahKPnuVmHbGwRegDOrGF9Amzx6PKCGS3EM8M4I+5+TPNspXA
PAJOK/wrvLcpSMjrCz66ErKdX9TEi3JFpoFi/gtDPprUMgTWtYE5isVoc5bD/+so
9EZoFdfsk2QUya+qNVsfHOJ3bFpc8mSSLx4hIjqsAGvHe6inOFp2gvgkeY3CX3sq
sEoyerUNxqPaSMlZK2ZqTJbrszUz0IUED2zXA+CZ4JbOo5gYosBNA6EtB0tIOUDq
QJbPbQiDwlfHan4D34edC5iLJ7VHxQjjtBt75BELvJtKhMIL1OGmBunqk9Z9N2WJ
DjJJJP7mlBn8LpMY4t/6apA7OO06cvvtgWjteC5doffEDep/ZUk+78xeaKycA4Ro
aD1bGjD+lSJsT9cULQUN2O3ar2vmAkDK9W+HiFLpk/ONfkqZt2G5w1wgWw8j8uaZ
SMcuRTJS1L9cCnM/umumtcfBS11BspEacu9h7myVi+wRzRXZlg9LVvv+b5m3Ieaq
U7Qdmh+3cbkNzTlKDvTSPBeXMX5042H/5uPZy3ci28UusMh8Mt4IMw4v1sWgh9GH
jx6qgWHFlBThFrWIFV9SoSPA6/hndC5OUe3zC0UvWMIaS9odg/FMJxYFpat1x40c
Gyta1Ka1zUoGBBmBmuXvppwAKBpoyYb8BQ9jtzESmMgukPP+Bigj7TU4lG4ISjC3
q71BnL14yz5B/tt+GmCVvwxtaMpG0eYV8bpOr4TwRzPvEjn6pZi8df/8m8OS8s5Y
YDD9t6bj2Lykr46N8YWflrIPJSr5l9cQwjN/YSkygvpMtfRAGjTJsOjKBuRFqNGu
mq/Ve+dYvt1XPmHLCwOWlDtPqnRdrxuxhV74sKSUda/cy9G9EP7XQJFKNxiHKqtL
2GitDaCIBzBZWO5ElyJGsjYcI2CNHBabca2OJqsVjFhaCKE1C9m1y3Yb8nbtfUiz
7h49+zNfX7c/Y+aa4QckXLWVVxqyh0zasZbrAkdUU1ciHaIvR11Y8cZB6sWQs1G5
ihenwghdL8yQMBtej8vfYaQl67o7GG5D1khR7pQrb3Soe5WAbA/kEXKYN/FD2VIi
E9P1gLZvIqI3attjPY9UWj2FMTcP+7i2ry2YSaCd9LKt2fbV4n7If/yjDoG6+pam
KLmnZBjeg+HByF2kiBjg9pSl+NuKECcdde/q7AMuHkY71u/XCNcTudZunDQvfC2+
/xOraefGiRZMeKDTiCcor+zXarAn19mVkpj0sjV9ZtE7a+h7OpU+NZNNCCjOg6Vs
k0a2vM3PA56nqshtQuxLxjhYuKdfFnPxEtm7qblQUfI8lFg9cxH+wa3yQVn4/UIL
WQynXgNWC3I2kj9UzQl4JgUP30BackeSFX5/L0Gbr0SMcR8NwrmdpcNw8xEnePhy
1dsEdXVEeeZudiUJNfzg0/wrj5wyp6ndcSu0ZOmVgXdwvJqfuMAARKyMpj1bpZGd
Fr8GfynQzmmTAtExaZhsw/Oiqmgt+aqEbfpap9TpqNf4crFBBszVtCIwEPYo9zg8
oQ8uQFP2lAg1Y1ds7EQZJuhUyPUWivNirTI7ZdHurtJRZs6a3WzrctbCxQV/vU/M
All387yOR9JpF8TDvLvNx65NwRjZsKJPVzQeDHfH0gV9X8cDo9vhoqmQgHp36rIt
bGzJMxOq6YWyhzeTl5hjNbJEYvfZyoMAEctyofGujJo3MMvY1SrT1r5LhBc1jdG6
L4WjYADRnxgQRZx6oWvopAGFxQmcyJC10j7mZlCXs/fgXLyAL4otOfajhf022zTF
mnRSELVsEHyexXNaF5eafPJG34dzOi8ij2w4KpnJ0V4yGGVjZcl1DecCMenN1Ya1
W4PBTBBOoiPzjH4p8CKNE4sRLlEzNXtdDyAzW6W3i9vtdG8mn7AQ3P6qgPG7g2l8
NariUOySapnif3ugFaS/J06OiLGPxRq7mlDgCTGimr8E+quDp+edoT/WgEkDWQrD
WJHCtzE9zKPfondfh5xWVLgf3vxOFbduij1OwAGslsNG8RrWx7wLFGxmrkTwyxPf
xcDXfko9GgrCldBS7wU3sa50OJt57u7ZRCPzJh46+h11ptjVLbQ5VkWLE9jF4yZU
eJU6Klt3+DPM3KJEUyUO20QmOga+iDpNsu3sj3NvBDXxLpzJgu36FkML6QNSV2Mv
jPhWXTU8o3iVrdTcZahca9Qioe82ivQ/FjKzRlm6wxLnD702eCLAMMCfFbeQyxu3
SN52PFk0hrurPP9FAePVmWE6Nmevoqb3NEJJ7STA8mcziIevvW5+0Il1zABPjVuZ
gI+s++iUvptqVD2O86kQPv/1lNJW4ZAbuiHMI1r+3oUNhk3I2OuYWdL/HzaazoVO
UKb6cBn13nxymCsNuPDcvp8/6dN29j8M209z0nKgVjHaSSMSCL3QBL2+of5hBVVF
ZaGPoTa77xxmMK/bNJ/oWZzz0IhJM4ENwXfdSXkMcBVrtFe732n3PdaOr7i78frS
HlQHcavAGKAcTIm7e5+F486UmRgwUbl8hiAM29EiumJbNnjUt26In5nsH/eO0beq
aR9+U4R4VmbYXsSJDQh5oA6q+9Zax/o7NKEslDK4Vxw1rzMa2Az3BKL/GxBXfMou
5WvL8FF9xabhzaGXHQFxplq7kux8LDMI8mtnADxEpc43TKf386Aka6ZhPUknwDjc
rVioROV+3sPanowbmaSLmHnLF3hnyDh2nCV532jOjfWyeGx11EUeclgmGtez3Msy
kDQy/v7/IMz3nt2cPMoGYUqvW8aql2SSRImEqAg4JYWzPybIoo7d00pi3wX+YT9p
LBYfjAxVvz0HGFowbK0mGnoaZx4qzT7ugp0+Cl+TTUUs2C7TDWAl/xzlyvLLD8tr
lTwfRITiJr71tDO94sl8Ih77Y6WMxKqXng1s/5awOljqqKd/If2jjKWAq0miuocF
bPhQXrJ0eKBbcb8rRvJDxPulzgHQ20/5SsgsaUXsQnvEJHrSyhH+/Fgw2svvF2le
aeaZ3J0RDqx8fBDXVcnL5+VP6hxySj891VBVwiV3RMaLgJqZnzd3fIVPYcwCLV4h
Zn0QncgQIlRl62/utftL9Wx5bc8OWkiOxblUPTjRE3ADo3vpu2t/RlJd7ve9x40f
1/elM664wgDKGh25GNnI8+cEpbVC0NCHXbQGboAoHmGeoIucPguW++c7Bu8S80Sk
YOqZoPNNot3xbsT1F1ETBHMVBCACS7WzvnT7JrNxZpmSiOCkyv8+oxDQjJJvjLqb
KV6kZNHG5X5ySqOOrlZb8OXeHgg1EfnuyBH5j7OJWznDHTqE1HLOu5xMbywKxB56
46h74AqN1fNCj/DxKEJuLE+sqs9/IY/pH2kytF6w88lzYHuqEWv5IhhP2207XbLQ
7F2ERMBvYJRn5Cpv++PlDTqDT+7VpsHDDMBpGDD+2xiIRAQ1gSft63rjbfYWQ2m8
Mm1NBv+UhURdCZszxh9KyQTuBOWhbv8vG8dP2k4qzKDxymazxjJSWi4uon5WiBuv
16+COZcWIBV2d9AeTJJ5oU0EJU2XW94mSZDweeRaBIEt4DMXvAE29OdjZ9QPCkgH
XljLClmly0I0JNGvJD2j7Odjq5bmpz4TNpOBghrVVOWN9sHu4BpkpjBsHQKkFsNt
qNQny4/FhXQm7Y7qmccbO0pluLDPf4ceV1g36CrBtzC2LEcOolIhyxGEBHWfQJAT
WTs4SOuMp71MCrd99OmTJ5bBgHoFwAaobYw8Wh+zQsh/1hJMVxCK/XwFhCNOTSMT
oh84uP3YkXM3e509dHZguqqsFnv16b8a9/nNaKnyMPxfOHg0Vs5AFLzkuB1zlrtl
63Zz7A5IdO6Fp+nBPcVP65BAlZRJGJ7uF5nuQ2/r1qEvUIaNpFRyCM4/TY0A4UIY
eP51j0W5miBvcirVquHuyH7Ej7kEOz1+m0/tNJWLYAbMPUZjtZX72ILHkKGUnPra
EnzNDPtFbCEXWHOPR4r2vHJtL0gTNVHQpgkQuI/UuL3/Q+4IPKTyOrnET20A7VVP
UjsBnFzjp65U6a2QY9wHyJiZv4uTahQvI7fEYgMsdkhAyPG7cb2BdmjXTdoT1JqX
THve2CCD7SzKfx0TzR5d6OkZLg==
-----END ENCRYPTED PRIVATE KEY-----
[root@devgate:~] # grep -v 'BEGIN ' private.key | grep -v 'END ' | gbase64 -d | /usr/local/bin/openssl enc -d -aes-256-cbc -iv D791F6DC4686317570250406D133A343 -K `ruby -rdigest/md5 -e 'puts Digest::MD5.hexdigest(["ZZf75x7VuauSIZnOZQrwWQtiIXGIL",0xD7,0x91,0xF6,0xDC,0x46,0x86,0x31,0x75].pack("a*cccccccc"))'` | /usr/local/bin/openssl asn1parse -inform DER
bad decrypt
34382894680:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:518:
Error in encoding
34382894680:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:157:
[root@devgate:~] #

FreeBSD 10.2-RC3 / OpenSSL 1.0.2d

[Joe User]

Ah, (meinen) Fehler gefunden:
Dadurch dass ich genpkey mit aes-256-cbc zur Key-Erstellung nutze, habe ich bereits genau das erreicht, was das Ziel des Blogposts ist ;)

Also die Keys so erstellen und Alles passt:

Code: Select all

openssl rand -hex 16 | openssl passwd -1 -stdin | tr -cd '[[:alnum:]]' | sed -e 's/^1//' > private.pwd
openssl genpkey -aes-256-cbc -algorithm RSA -pkeyopt 'rsa_keygen_bits:8192' -out private.key -pass 'file:private.pwd'
openssl pkey -in private.key -out public.key -passin 'file:private.pwd' -pubout

BTW: Meine vorigen Posts (Code-Beispiele) aktualisiert.

[Joe User]

Backups können durch diese Verschlüsselung allerdings erheblich länger dauern:
Script (für tcsh da FreeBSD):

Code: Select all

[root@devgate:~] # cat encbackup.sh
#!/bin/tcsh

# 100MB Random text erzeugen
/usr/local/bin/openssl rand -base64 -out message.txt 77433312
#echo 'Hello world!' > message.txt

/usr/local/bin/openssl rand -hex 16 | /usr/local/bin/openssl passwd -1 -stdin | tr -cd '[[:alnum:]]' | sed -e 's/^1//' > private.pwd

/usr/local/bin/openssl genpkey -aes-256-cbc -algorithm RSA -pkeyopt 'rsa_keygen_bits:8192' -out private.key -pass 'file:private.pwd'
/usr/local/bin/openssl pkey -in private.key -out public.key -passin 'file:private.pwd' -pubout

set key=`/usr/local/bin/openssl rand -hex 32`
set iv=`/usr/local/bin/openssl rand -hex 16`
set salt=`/usr/local/bin/openssl rand -hex 64`
xz -z -k -c -4e message.txt | /usr/local/bin/openssl enc -e -aes-256-ctr -K $key -iv $iv -S $salt -out message.enc

set hmacpw=`/usr/local/bin/openssl rand -base64 48`
set hmac=`/usr/local/bin/openssl dgst -sha512 -hmac $hmacpw -hex message.enc | sed -e 's/^.*=[[:space:]]//g'`
echo "${key}:${iv}:${salt}:${hmacpw}:${hmac}" | /usr/local/bin/openssl rsautl -inkey public.key -pubin -encrypt -out message.key -passin 'file:private.pwd'

/usr/local/bin/openssl dgst -sha512 -sign private.key -out message.sig -passin 'file:private.pwd' message.enc

unset key
unset iv
unset salt
unset hmacpw
unset hmac

/usr/local/bin/openssl dgst -sha512 -verify public.key -signature message.sig message.enc

set plain=`/usr/local/bin/openssl rsautl -inkey private.key -decrypt -in message.key -passin 'file:private.pwd'`
set key=`echo $plain | awk -F ":" '{print $1}'`
set iv=`echo $plain | awk -F ":" '{print $2}'`
set salt=`echo $plain | awk -F ":" '{print $3}'`
set hmacpw=`echo $plain | awk -F ":" '{print $4}'`
set hmac=`echo $plain | awk -F ":" '{print $5}'`

set hmac2=`/usr/local/bin/openssl dgst -sha512 -hmac $hmacpw -hex message.enc | sed -e 's/^.*=[[:space:]]//g'`
[ "${hmac}" != "${hmac2}" ] && echo "Verification failed" || echo "Verification succeeded"

/usr/local/bin/openssl enc -d -aes-256-ctr -K $key -iv $iv -S $salt -in message.enc | xz -d -c -4e > message2.txt

diff -dqs message.txt message2.txt

unset plain
unset key
unset iv
unset salt
unset hmacpw
unset hmac
unset hmac2
[root@devgate:~] #

Scriptaufruf per time:

Code: Select all

[root@devgate:~] # /usr/bin/time -lp ./encbackup.sh
........................................................................................................++
...........................................................................................................................................++
Verified OK
Verification succeeded
Files message.txt and message2.txt are identical
real 51.90
user 50.95
sys 0.38
     50392  maximum resident set size
       158  average shared memory size
        24  average unshared data size
       127  average unshared stack size
     19489  page reclaims
         0  page faults
         0  swaps
         0  block input operations
      2214  block output operations
         2  messages sent
         2  messages received
        29  signals received
     16103  voluntary context switches
     52288  involuntary context switches
[root@devgate:~] #

[daemotron]

Hm, die Erzeugung von 100MB Random Text und die Erzeugung der großen RSA-Schlüssel wäre ja normalerweise nicht Bestandteil der Backup Routine. Ich werde mal einen Test vorbereiten, der das Backup einmal mit und einmal ohne Verschlüsselung erzeugt. Ich bastle allerdings gerade noch an einer Lösung mit tee, um die verschlüsselten Daten nicht lokal zwischenspeichern zu müssen...

[Joe User]

Ohne die message.txt und Keys neu zu erzeugen (die ersten vier Befehlszeilen im Script kommentiert) dauert es immernoch recht lange:

Code: Select all

[root@devgate:~] # /usr/bin/time -lp ./encbackup.sh
Verified OK
Verification succeeded
Files message.txt and message2.txt are identical
real 41.48
user 40.57
sys 0.36
     50392  maximum resident set size
        67  average shared memory size
        24  average unshared data size
       127  average unshared stack size
     18212  page reclaims
         0  page faults
         0  swaps
         0  block input operations
      1414  block output operations
         2  messages sent
         2  messages received
        22  signals received
     16122  voluntary context switches
     41600  involuntary context switches
[root@devgate:~] #

Und einmal nur Packen, Verschlüsseln und Signieren:

Code: Select all

[root@devgate:~] # /usr/bin/time -lp ./encbackup.sh
Verified OK
real 35.61
user 35.06
sys 0.17
     50392  maximum resident set size
        68  average shared memory size
        24  average unshared data size
       128  average unshared stack size
     14752  page reclaims
         0  page faults
         0  swaps
         0  block input operations
       615  block output operations
         2  messages sent
         2  messages received
        11  signals received
     14918  voluntary context switches
     35641  involuntary context switches
[root@devgate:~] #

Und nur Entschlüsseln und Entpacken:

Code: Select all

[root@devgate:~] # /usr/bin/time -lp ./encbackup.sh
Verification succeeded
Files message.txt and message2.txt are identical
real 5.88
user 5.57
sys 0.12
      6412  maximum resident set size
        70  average shared memory size
        25  average unshared data size
       127  average unshared stack size
      3843  page reclaims
         0  page faults
         0  swaps
         0  block input operations
       800  block output operations
         2  messages sent
         2  messages received
        11  signals received
      1315  voluntary context switches
      5868  involuntary context switches
[root@devgate:~] #

[daemotron]

OK, ich habe den Übeltäter wohl gefasst - es ist xz, das die meiste Zeit verraucht. Zu meinem Vorgehen sei vielleicht noch zu erwähnen, dass ich das ganze auf einem Mac Book Pro durchspiele. Hinter dem Shell-Interpreter verbirgt sich eine gepatchte Bourne Again Shell:

Code: Select all

~ % /bin/sh -version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin14)
Copyright (C) 2007 Free Software Foundation, Inc.

Beispiel-Daten und RSA Schlüssel habe ich außerhalb der Test-Skripte generiert:

Code: Select all

/usr/local/bin/openssl genpkey -aes-256-cbc -algorithm RSA -pkeyopt 'rsa_keygen_bits:8192' -out private.key
/usr/local/bin/openssl pkey -in private.key -out public.key -pubout
/usr/local/bin/openssl rand -base64 -out message.txt 77433312

1. Testfall: Verschlüsselung und HMAC
Das Skript sieht hier folgendermaßen aus:

Code: Select all

#!/bin/sh

b_openssl=/usr/local/bin/openssl
b_xz=/usr/local/bin/xz

key=$(${b_openssl} rand -hex 32)
iv=$(${b_openssl} rand -hex 16)
hmacpw=$(${b_openssl} rand -base64 48)

${b_xz} -zkc message.txt | ${b_openssl} enc -e -aes-256-ctr -K $key -iv $iv -out message.enc

hmac=$(${b_openssl} dgst -sha512 -hmac $hmacpw -hex message.enc | sed 's/^.*=[[:space:]]//g')
echo "${key}:${iv}:${salt}:${hmacpw}:${hmac}" | ${b_openssl} rsautl -inkey public.key -pubin -encrypt -out message.key

Dazu ergibt sich folgendes Timing (gemessen mit /usr/bin/time -lp ./skript.sh):

Code: Select all

real        48.54
user        48.38
sys          0.31
  98213888  maximum resident set size
         0  average shared memory size
         0  average unshared data size
         0  average unshared stack size
     28551  page reclaims
        53  page faults
         0  swaps
         0  block input operations
        43  block output operations
         0  messages sent
         0  messages received
         4  signals received
      1409  voluntary context switches
      2414  involuntary context switches
/usr/bin/time -lp ./text_enc.sh  48,38s user 0,31s system 100% cpu 48,550 total

2. Testfall: Kompression (ohne Verschlüsselung) und HMAC
Das Skript sieht hier folgendermaßen aus:

Code: Select all

#!/bin/sh

b_openssl=/usr/local/bin/openssl
b_xz=/usr/local/bin/xz

hmacpw=$(${b_openssl} rand -base64 48)

${b_xz} -zk message.txt

hmac=$(${b_openssl} dgst -sha512 -hmac $hmacpw -hex message.txt.xz | sed 's/^.*=[[:space:]]//g')
echo "${key}:${iv}:${salt}:${hmacpw}:${hmac}" | ${b_openssl} rsautl -inkey public.key -pubin -encrypt -out message.key

Dazu ergibt sich folgendes Timing (gemessen mit /usr/bin/time -lp ./skript.sh):

Code: Select all

real        48.67
user        48.41
sys          0.23
  98197504  maximum resident set size
         0  average shared memory size
         0  average unshared data size
         0  average unshared stack size
     26284  page reclaims
         0  page faults
         0  swaps
         0  block input operations
        20  block output operations
         0  messages sent
         0  messages received
         1  signals received
        14  voluntary context switches
      2661  involuntary context switches
/usr/bin/time -lp ./text_vrf.sh  48,41s user 0,23s system 99% cpu 48,681 total

3. Testfall: Kompression ohne Verschlüsselung und ohne HMAC
Das Skript sieht hier folgendermaßen aus:

Code: Select all

#!/bin/sh

b_openssl=/usr/local/bin/openssl
b_xz=/usr/local/bin/xz

${b_xz} -zk message.txt

Dazu ergibt sich folgendes Timing (gemessen mit /usr/bin/time -lp ./skript.sh):

Code: Select all

real        48.49
user        48.23
sys          0.21
  98197504  maximum resident set size
         0  average shared memory size
         0  average unshared data size
         0  average unshared stack size
     24386  page reclaims
         0  page faults
         0  swaps
         0  block input operations
        11  block output operations
         0  messages sent
         0  messages received
         0  signals received
         7  voluntary context switches
      2306  involuntary context switches
/usr/bin/time -lp ./text_pln.sh  48,24s user 0,22s system 99% cpu 48,502 total

Fazit
Das ist natürlich keine statistisch repräsentative Messreihe; dazu müssten hunderte Messungen auf einem vollständig unbelasteten System gefahren werden. Allerdings weisen die drei verschiedenen Durchgänge keine signifikante Abweichung im Timing auf; daher darf man wohl davon ausgehen, dass xz hier der Zeitfresser schlechthin ist (Disk I/O kann ich weitgehend ausschließen, da hier im Test als Festspeicher ein über PCIe angebundener Flash-Speicher zum Einsatz kam).

Die Kompressionsrate lag mit und ohne Verschlüsselung (ohne Vorgabe einer bestimmten Kompressionsstärke für xz) bei ca. 23%. Für die Backup-Performance wäre also zu prüfen, ob Vorgaben in der Kompressionsstärke hier noch eine Verbesserung herausholen (Kompression und/oder Laufzeit), bzw. ob ggf. ein anderer Kompressor wie etwa bz2 ein besseres Laufzeitverhalten bei gleichzeitig akzeptabler Kompression zeigt.

[daemotron]

Nachtrag: Wer die Test-Skripte aufmerksam liest, wird sehen, dass ich das Salt eingespart habe. Richtigerweise hat mich Ctulhu darauf aufmerksam gemacht, dass das Salt nur benötigt wird, um aus einem Passwort den eigentlichen Schlüssel abzuleiten. Wird enc direkt mit einem Schlüssel und einem IV aufgerufen, ist das Salt also überflüssig.

[Joe User]

Da ist im echo noch ein Bug (wenn das Salt weggelassen werden soll):

Code: Select all

echo "${key}:${iv}:${salt}:${hmacpw}:${hmac}" | ${b_openssl} rsautl ...

EDIT: Ohne Salt reicht dann auch ein 4096 Bit Private Key aus.

[daemotron]

Du hast natürlich recht, der Salt-String muss weg.

Ich bin aber über einen möglichen Ciphertext Forgery Angriffsvektor gestolpert:
Wenn auf eine Signatur des HMAC mit einem privaten Schlüssel verzichtet wird, könnte ein Angreifer einfach auf dem (nicht vertrauenswürdigen) Backup-Server eine Dateikombination (.enc und .key) ersetzen - wer den öffentlichen Schlüssel hat, kann damit als gültig validierende Dateien ablegen. Somit bleibt eine Signatur mit dem privaten Schlüssel leider zwingend erforderlich...

Bezüglich Passwort-Schutz des privaten Schlüssels noch folgender Gedankengang: Um eine automatisierte Verarbeitung zu ermöglichen, muss das Passwort in einer Datei abgelegt werden. Die Sicherheit des Passworts hängt somit nur von der Leseberechtigung für diese Datei ab und davon, dass das OS sie auch durchsetzt. Genauso wäre es, wenn der private Schlüssel unverschlüsselt abgelegt würde - auch in diesem Fall bestimmt die Dateiberechtigung über Wohl und Wehe. Sobald also der Schlüssel automatisiert verarbeitbar abgelegt wird, hängt seine Sicherheit ausschließlich von der Durchsetzbarkeit von Dateizugriffsrechten ab, ob verschlüsselt oder unverschlüsselt wäre somit egal.

[Joe User]

Die automatische Passworterzeugung ist auch eher für vollautomatisierte Backupscripts gedacht und selbstverständlich sollte die Passwortdatei, ebenso wie der private Key und die Signatur, nur temporär während der Backuperstellung/wiederherstellung unter /root mit chmod 0700 abgelegt werden und ansonsten an einem sicheren externen Ort verwahrt werden.

Auch sollten nach dem Kopieren/Verschieben des erzeugten Backups, alle nicht mehr benötigten Dateien (Backupfiles, Passwortdatei, Signatur, Keys) vom System entfernt werden, um einem möglichen Missbrauch vorzubeugen.


Letztlich gilt auch hier wie immer: 100% Sicherheit gibt es nicht, es gibt immer einen potentiellen Angriffsvektor.