Cryptography Reference
In-Depth Information
Auffällig an diesem Ablauf ist, dass der jeweils angefragte DNS nie den signierten
öffentlichen Schlüssel des untergeordneten DNS liefert, sondern immer nur einen
signierten Hashwert davon. Dies hat unter anderem den Vorteil, dass ein DNS die
Hashwerte aller akzeptierten öffentlichen Schlüssel in einer Konfigurationsdatei
speichern kann, wodurch sich der beschriebene Ablauf in vielen praktischen Fäl-
len abkürzen lässt. So könnte Alices DNS in unserem Beispiel auch direkt den
kryptoboerse.kl-DNS ansprechen, sofern er dessen IP-Adresse und Schlüssel-
Hashwert kennt. Eine weitere Besonderheit von DNSSEC ist, dass ein DNS meh-
rere öffentliche Schlüssel besitzen kann, wobei einer davon als Masterschlüssel
eingesetzt wird. Mit diesem signiert der DNS seine anderen öffentlichen Schlüs-
sel, die wiederum zum Signieren der DNS-Antworten verwendet werden.
TSIG
TSIG
(Transaction Signature) ist eine Alternative zu DNSSEC, die immer dann
interessant ist, wenn nur einige wenige DNS-Systeme miteinander kommunizie-
ren. TSIG ermöglicht es, die Kommunikation zwischen zwei DNS oder zwischen
einem Server und einem DNS abzusichern. Im Gegensatz zu DNSSEC kommen
dabei jedoch keine digitalen Signaturen zum Einsatz, sondern nur schlüsselab-
hängige Hashwerte. Die Schlüssel müssen von den zuständigen Administratoren
manuell eingerichtet werden, da es kein Schlüsselaustausch-Protokoll gibt. Die
verwendete schlüsselabhängige Hashfunktion ist ein HMAC-Verfahren auf Basis
von MD5. TSIG ist in [RFC2845] spezifiziert. [RFC3645] ermöglicht die Nut-
zung der GSS-API für TSIG.
37.5.3
Kryptografie für SAP R/3
R/3 von SAP ist bekanntlich die führende Software für die Ressourcenplanung im
Unternehmen. Aus unserer Sicht ist R/3 in erster Linie ein System von Clients und
Servern, wobei die Clients über ein proprietäres Schicht-7-Protokoll mit den Ser-
vern kommunizieren. Unter diesem proprietären Protokoll wird TCP eingesetzt.
Dass Mallory innerhalb eines R/3-Systems einigen Schaden verursachen kann,
dürfte klar sein. Wenn es ihm gelingt, anstelle der berechtigten R/3-Anwenderin
Alice auf den Server zuzugreifen, dann kann er dort beliebiges Unheil anrichten.
Auch das Abhören von Protokollnachrichten ist eine Gefahr. R/3 unterstützte
zwar von Anfang an Passwörter, aber - wie so viele Systeme - ursprünglich keine
Kryptografie. Natürlich erkannte man bei SAP diese Gefahr und entwickelte ent-
sprechende Gegenmaßnahmen. Die wichtigsten davon sind zwei kryptografische
Schnittstellen [SNCSSF].
