Dateiname verwendet in den Programmen ... cfsd, cmkdir, cpasswd ..c cattach, cmkdir, cpasswd ..k cattach, cmkdir, cpasswd ..s cattach, cmkdir, cpasswd ..n cpasswd ..o cpasswd ..data cattach, cpasswd, cmkkey
Je nach Verfahren (DES, 3DES, ...) kann jeder der beiden Keys aus mehreren Teil-Keys bestehen. Der Sekundär-Schlüssel dient der Erzeugung zweier pseudozufälliger Strom-Chiffren. Diese beiden Strom-Chiffren sowie der Primär-Schlüssel kommen bei der blockweisen Ver- und Entschlüsselung von Dateinamen und -inhalten zum Einsatz:
Die beiden Strom-Chiffren S1 und S2 werden in der Funktion genmasks() der Datei cfs_adm.c erzeugt. Diese Routine stützt sich dabei ihrerseits auf die Funktion mask_cipher(), die konsequent immer nur auf die Sekundär-Schlüssel zurückgreift. Die beiden Funktionen cipher() und mask_cipher() unterscheiden sich lediglich darin, daß erstere immer den Primär-, letztere dagegen immer den Sekundär-Schlüssel beachtet.
Es gibt ein altes und ein neues Verfahren zur Verschlüsselung der Dateiinhalte und -namen. Das neue Verfahren wurde mit der Release 1.3.0 eingeführt.
Beim alten Verfahren werden die zur Chiffrierung der Nutzdaten benötigten und nachfolgend zusammen als KD bezeichneten Primär- und Sekundär-Schlüssel unter Verwendung eines DES-basierten Hash-Verfahrens in der Funktion old_pwcrunch() direkt aus der Paßphrase abgeleitet. Damit wird die Datei ..k weder benötigt noch verwaltet. Nebeneffekt: Eine Änderung der Paßphrase mittels cpasswd ist nicht möglich. Macht sich eine Änderung der Paßphrase dennoch nötig, müssen alle Dateien von Hand mit den alten Keys entschlüsselt und mit den neuen wieder verschlüsselt werden.
Das neue Verfahren nutzt die aus der Paßphrase abgeleiteten Schlüssel nicht direkt zur Verschlüsselung der Nutzerdaten und entkoppelt so die Keys KD von der Paßphrase. Unter Verwendung des SHS (Secure Hash Standard) werden aus der Paßphrase je nach Chiffre zwei oder drei Schlüssel (k1, k2 und ggf. k3) generiert, aus denen wiederum die Keys KP (auch wieder ein aus Primär- und Sekundär-Schlüssel bestehendes Paar) abgeleitet werden. Die KP dienen der Verschlüsselung der KD und diese wiederum der Verschlüsselung der Nutzdaten. Damit ist ein Wechsel der Paßphrase leicht möglich. Die Operation bezieht sich nur auf die Administrations-Dateien. Die Schlüssel KD für die Daten bleiben unverändert, sie werden lediglich neu verschlüsselt und in der Datei ..k abgelegt.
Die Keys KD werden beim neuen Verfahren durch cmkdir nach folgendem Algorithmus bestimmt:
Ableitung der Schlüssel KP aus der Paßphrase unter Nutzung von SHS in der Funktion new_pwcrunch().
Bilden eines 32 Bit langen pseudozufälligen Strings EKEY durch XOR-Verknüpfung der Keys KP (konkateniert zu einem einzigen Bytestring) mit 32 zufälligen Bytes, die durch die Funktion randbyte() erzeugt werden.
Verschlüsselung der ersten n Bytes von EKEY mit den Keys KP in der Funktion encrypt_key(). Das hierbei entstehende Resultat der Länge 32 Byte (n Bytes verschlüsselt, Rest unverschlüsselt) wird in der Datei ..k abgelegt. Die Zahl n hängt vom konkret genutzten Verschlüsselungsverfahren ab (n=24 bei echtem 3DES, n=16 bei den restlichen Verfahren).
Aus dem Inhalt der 32 Byte langen Datei ..k können jederzeit unter Nutzung der Schlüssel KP die Schlüssel KD ermittelt werden. Die Kommandos cmkdir, cattach und cpasswd verwenden hierfür die Funktion decrypt_key(). Diese dechiffriert die ersten n Bytes von ..k, so daß wieder der von cmkdir generierte String EKEY vorliegt. Aus dessen ersten n Bytes leitet decrypt_key() die Schlüssel KD ab. So dienen z.B. bei Standard-DES die ersten 8 Byte des Klartexts als Primär-Schlüssel, die folgenden 8 Byte als Sekundär-Schlüssel. Diese Keys KD werden anschließend zur Ver- und Entschlüsselung der Nutzdaten eingesetzt.
Die Schlüssel KD werden beim neuen Verfahren also immer aus dem String EKEY gebildet, wobei dieser durch die Dechiffrierung des Inhalts von ..k unter Nutzung der aus der Paßphrase abgeleiteten Schlüssel KP ermittelt wird. Die oben beschriebenen Zusammenhänge soll folgendes Bild noch einmal verdeutlichen:
Die Datei ... enthält eine mit KD verschlüsselte Zeichenkette der Länge 8 Byte, deren Anfang der String "qua!" ist. Die restlichen 4 Byte werden pseudozufällig gebildet:
Die Funktion copykey() realisiert die für die jeweils verwendete Chiffre spezifische Key Schedule bzw. Key Expansion, bildet also aus dem angegebenen Key des Nutzers die für die tatsächliche Ver- und Entschlüsselung im Inneren der Chiffre verwendeten Keys, deren konkrete Werte den Nutzer nicht interessieren dürften. Nach dieser Funktion ist die Chiffre initialisiert und kann anschließend zur Bearbeitung der Daten eingesetzt werden.
cattach übergibt per RPC-Call den entschlüsselten KD an den CFS-Dämon. Dieser dechiffriert den Inhalt der Datei ... zum Zwecke der Verifikation von KD. Beginnt die dabei entstehende Klartext-Zeichenfolge nicht mit "qua!", so wird KD als inkorrekt betrachtet. Da KD je nach Verfahren direkt oder indirekt von der Paßphrase abhängt, wird im Fehlerfall die Paßphrase zurückgewiesen:
Anmerkung: Wie bereits erwähnt, unterscheiden sich der Primär- und der Sekundär-Schlüssel lediglich bei reiner DES-Verschlüsselung voneinander. Bei anderen Chiffren sind sie identisch. Daher entsteht bei diesen Verfahren als Ergebnis der im obigen Bild gezeigten Abfolge
cipher() mask_cipher() cipher()dasselbe Resultat wie bei einmaliger Anwendung der Operation cipher().
Es ist natürlich möglich, die Administrations-Dateien gezielt auszutauschen, so daß beim cattach eine andere Paßphrase akzeptiert wird. Ein Zugriff auf die Klartexte wird aber dadurch nicht möglich, da sowohl die Namen als auch die Inhalte der Dateien mit einem anderen Schlüssel chiffriert wurden.
In der Regel kann bei Verwendung eines falschen Schlüssels überhaupt nicht per CFS auf die Dateien zugegriffen werden, da beim NFS-lookup() korrekte Klartext-Namen angegeben werden müssen, also jene, deren zugehörige Chiffrate in den CFS-Teilbäumen gespeichert sind. Diese Klartexte erhält man aber beim NFS-readdir() im Normalfall nicht, da es sich bei den durch den falschen Schlüssel dechiffrierten Klartexten meist um keine gültigen Pfadkomponenten (durch Nullbyte abgeschlossene, nur aus 7-Bit-ASCII-Zeichen bestehende Strings) handelt. Mit hoher Wahrscheinlichkeit wird daher ein Klartext-Name zurückgeliefert, dessen Chiffrat nicht mit dem im CFS-Teilbaum gespeicherten Chiffrat des Dateinamens übereinstimmt.
Die typischen Ausgaben beim Kommando ls lauten daher in etwa so:
> ls
???:J;x;s!t5WXpD ?ehI}M?3 8r??'?-%B?SQD@:U AM2??JNF}?? K#?A7?-+mCV?7T|J q2.?J'J??^?%?oH?
> ls -l
ls: q2.J'Jsb^`%yoHo: No such file or directory
ls: |ehI}M3: No such file or directory
ls: K#
A7#-+mCVb7T|J: No such file or directory
ls: AM2`pJNF}yu: No such file or directory
ls: 8re'{-%B|SQD@:U: No such file or directory
ls: pe:J;x;s!t5WXpD: No such file or directory
total 0
| ..c | Angabe der verwendeten Chiffre als ganze Zahl (dargestellt als
ASCII-Zeichen), siehe cfs.h:
0 ... STD_DES (2 key hybrid single DES)
1 ... THREE_DES (2 key hybrid 3DES) usw. |
| ... | verschlüsselter bekannter Klartext (known
plaintext) zur Verifikation einer vom Nutzer angegebenen
Paßphrase
known plaintext: Zeichenkette, die mit "qua!" beginnt; danach folgen 4 zufällige Bytes Der in der Manual-Seite verwendete Begriff "Hash" ist irreführend, da eine Umkehrabbildung nicht nur möglich ist, sondern benötigt und deshalb auch realisiert wird. |
| ..k | Enthält den von cmkdir generierten String EKEY, wobei dessen erste n Bytes, aus denen die zur Chiffrierung der Nutzdaten verwendeten Keys KD abgeleitet werden, mit KP verschlüsselt sind. Der String EKEY und damit die Nutzdaten-Keys KD selbst bleiben nach ihrer Generierung unverändert, allerdings ändert sich mit jeder Änderung der Paßphrase das in ..k abgelegte Chiffrat. Die zur Verschlüsselung von EKEY benutzten Keys KP werden mittels SHS aus der Paßphrase abgeleitet. |
| ..s | Angabe der Größe (als ganze Zahl in Bytes) der 2 pseudozufälligen Ströme für die beiden Stromchiffren S1 und S2, die bei cattach durch den CFS-Server dynamisch vorausberechnet werden und bei der Verschlüsselung der Nutzdaten zum Einsatz kommen. |
| ..n ..o |
Diese beiden Dateien werden temporär von cpasswd
beim Wechsel der Paßphrase genutzt. ..n stellt die neue ..k-Datei dar, solange die alte noch existiert. Die Umbenennung erfolgt "ultra paranoid" in 3 Schritten:
|
| ..data | Hierbei handelt es sich um einen symbolischen Link. Er ist
optional und dient dazu, auf dasjenige Verzeichnis zu verweisen, in
dem sich die verschlüsselten Nutzdaten befinden. Im
Standardfall, d.h. wenn der Link ..data entweder nicht
existiert oder nicht mittels des Systemrufs chdir()
verfolgt werden kann, wird immer angenommen, daß sich die
verschlüsselten Nutzdaten in demselben Verzeichnis befinden,
in dem auch die Administrations-Dateien gepeichert sind.
Durch die Einführung des Links ..data (den es bis CFS 1.3.3 noch nicht gab) wurde es möglich, unter Verwendung unterschiedlicher Paßphrasen auf ein und dieselben verschlüsselten Nutzdaten zuzugreifen, sofern diese unter Verwendung des neuen Verfahrens (d.h. unter Nutzung indirekter Schlüssel) chiffriert wurden. Wenn sich z.B. verschiedene Nutzer ein und dieselben CFS-Nutzdaten teilen, benötigen sie nicht mehr zwangsläufig dieselbe Paßphrase. Jeder Nutzer kann seine individuelle Paßphrase wählen und verwenden. Hierfür steht das Kommando cmkkey zur Verfügung. Es legt ein neues Verzeichnis an, kopiert eine bereits existierende CFS-Schlüssel-Datei ..k dorthinein und kreiert einen Link ..data, der auf die verschlüsselten Nutzdaten verweist. Die Paßphrasen zum Schutz der in diesen beiden (zunächst identischen) Dateien ..k gespeicherten Informationen, aus denen die Keys KD abgeleitet werden, können unabhängig voneinander verändert werden, da bei einem Wechsel der Paßphrase die durch sie geschützten Informationen unverändert bleiben. Aus der individuellen Paßphrase der einzelnen Nutzer können jeweils die von ihnen gemeinsam genutzten Schlüssel KD abgeleitet werden, so daß die Nutzer gemeinsam auf dieselben chiffrierten CFS-Nutzdaten zugreifen können. |
25. Mai 2000