Bereits die alten Römer haben ca. 100 v. Chr. Botschaften mittels Caesar-Verschlüsselung chiffriert. Ziel war es, besonders geheime Informationen nur für denjenigen lesbar zu machen, an den die Nachricht auch tatsächlich gerichtet war. Hierfür kannte der Empfänger eine beliebige Zahl (einen Schlüssel), die die Anzahl Stellen im Alphabet darstellte, um die jeder Buchstabe im verschlüsselten Text verschoben werden musste. Kannte man diesen Schlüssel nicht, so war die Entschlüsselung deutlich erschwert. Dieses Bedürfnis nach Verschlüsselung hält bis heute an.
In der modernen Welt werden täglich Unmengen an Daten über verschiedenste Schnittstellen transportiert. Betrachtet man die Bankenwelt, so kann man das aufstrebende Thema Open Banking als Beispiel dafür nehmen, dass auch immer mehr Daten aus der Bank hinaus an TPPs (Third Party Provider), oder gar an Drittbanken gelangen sollen. Besonders im Fokus sind schlanke APIs (Application Programming Interfaces), welche als leicht zu implementieren und kostengünstig gelten. Dem entgegen stehen APIs im Ruf, im Verhältnis zu lang etablierten Schnittstellen, Einbussen in Punkto Sicherheit in Kauf zu nehmen. Diesem Mythos möchte ich entgegentreten.
Zunächst mal muss man verstehen, wie APIs aufgebaut sind. Nebst der SOAP-Technologie (Simple Object Access Protocol), wird im Kontext von Open Banking die weit verbreitete REST-Technologie (Representational State Transfer), oder auch RESTful APIs genannt, verwendet. REST beschreibt die grundlegenden Aspekte, welche die entsprechende Schnittstelle erfüllen muss. Ein zentraler Punkt bildet HTTP (Hypertext Transfer Protocol) und das in der Transportschicht verwendete TLS (Transport Layer Security).
Beim Aufbau einer TLS-Verbindung werden Zertifikate und unterstützte Verfahren zwischen den Partnern ausgetauscht und darauf basierend eine Session aufgebaut. Diese Session kommt jedoch nur zu Stande, wenn die Vertrauenswürdigkeit durch das Zertifikat gewährleistet wurde.
In einem ersten Schritt wird dem Server mitgeteilt, welcher Verschlüsselungs-Algorithmus verwendet werden soll. Anschliessend übergibt der Client dem Server ein Zertifikat, welches unter anderem einen Public-Key beinhaltet. Während der Public-Key im Besitz des Servers ist und zur Verschlüsselung der Daten dient, verfügt der Client über den dazugehörigen einmaligen Private-Key. Dieser ermöglicht die Entschlüsselung. Eine solche Verschlüsselungsmethode wird auch asymmetrische Verschlüsselung genannt, da verschlüsselte Informationen nur mittels Privat-Key und auch nur in eine Richtung entschlüsselt werden können. Eine Besonderheit hierbei ist, dass die asymmetrische Verschlüsselung nur für den Session Aufbau einer Verbindung zum Zuge kommt. Vereinfacht gesagt, werden sowohl vom Client, als auch vom Server, mittels Public-Key des jeweils anderen, zufällig generierte Zahlenfolgen verschickt. Sind beide Seiten im Besitz der zufällig generierten Zahlenfolgen, wird durch den Client ein Pre-Master-Secret asymmetrisch verschlüsselt an den Server übermittelt.
Nach erfolgreicher Übermittlung können nun beide Seiten (Client und Server), unabhängig voneinander einen finalen Master-Secret berechnen. Dieser Master-Secret ergibt sich aus den beiden zufällig generierten Zahlenfolgen, sowie dem Pre-Master-Secret, welcher durch den Client an den Server übermittelt wurde. Beide Seiten müssen demnach alle zuvor übermittelten Daten während dem Session Aufbau besitzen. So kann die Authentizität beider Parteien sichergestellt werden. Ab diesem Zeitpunkt werden alle Daten innerhalb der aufgebauten Session symmetrisch mittels Master-Secret verschlüsselt.
Was bedeutet das nun konkret für die Datensicherheit über APIs?
TLS gewährleistet nebst der Authentizität von Client und Server, auch die Datensicherheit aller Übertragungsmedien. Dies erfolgt durch eine asymmetrische Übergabe verschiedenster Schlüssel, aus denen wiederum ein finaler Schlüssel generiert wird. Ist man im Stande diesen finalen Schlüssel zu errechnen, so kann man mit hoher Sicherheit davon ausgehen, dass die aufgebaute Verbindung - Point to Point - privat unter Client und Server besteht. Technisch ist dann zwar möglich die Verbindung von aussen zu beeinflussen, bspw. zu kappen oder zu unterbrechen, lesen der Daten, oder sich als Client ausgeben ist jedoch nicht mehr möglich.
Dieser Blog wurde von Julien Rösch gepostet.
0 Kommentare:
Kommentar veröffentlichen