MASC-ID mit AMANDA

DieZentrale Delegierungmit dem MASC-ID umzusetzen, erforderte eine eigene Benutzersteuerung, wie sie unter anderem bei Web-Services und XACML vorliegt. Der gesamte Dienst müsste also auf einer Internetanwendung mit eigener Benutzersteuerung basieren. Jeder eingeladene neue Teilneh-mer müsste sich registrieren und bei jedem Zugriff beim System anmelden; das System würde zen-tral verwaltet. Die Richtlinien würden zwar AMANDA-konform von den Teilnehmern selber erstellt, die schlanke Struktur ginge aber verloren. Der große Vorteil der Verwendung derZentralen Delegie-rung ist im Vergleich zum verteilten AMANDA-Pendant die mögliche Nutzung von direkten Grup-penrichtlinien – der Nachteil die große Zentralität der Anwendung. In Abschnitt 5.5.2 wird auf eine Testimplementierung mit XACML eingegangen.

Für den MASC-ID wird folgend AMANDA in der Verteilten Delegierungbetrachtet. Identifizierung und Authentifizierung der Parteien erfolgt gemäß Abschnitt 5.4.2 mit öffentlichen Schlüsseln. Zur Richtlinienübermittlung werden signierte Zertifikate und für die Zugriffsgesuche eine signierte An-frage verwendet, die sich in ihrer Syntax an die Autorisierungen anlegt. Die eingebettete MASC-ID-Zugriffssoftware übernimmt dabei die benötigten Abstraktionen einer GUI.

Wegen der in Abschnitt 5.3.2 genannten Angreifbarkeit sollen die Zertifikate bei der Richtliniener-stellung überprüft werden. Somit ist eine Teilnehmerregistrierung (und Gruppenzuordnung) Pflicht, bevor die Richtlinien in den PIP aufgenommen werden. Es wird dabei offen gelassen, welche Kriterien

bei dieser Registrierung angefragt werden. Lediglich die Zuordnung der möglichen Rollen (Spedition, Transporteur, Shipper, Versicherer) einer Partei muss dabei erfolgen. Die Erstellung von schlafenden Ketten soll wegen der besprochenen Angreifbarkeit (siehe 5.3.2) nicht möglich sein.

Zertifikate

AUSSTELLER Öffentlicher Schlüssel Aussteller (Hash)

SUBJEKT Constraint

AUTORISIERUNG Datenbankautorisierungen SERIENNUMMER eindeutige ID

Tabelle 5.8: AMANDA-Privilegierungszertifikat der MASC-Anwendung

AUSSTELLER Öffentlicher Schlüssel Aussteller (Hash) SERIENNUMMER ID eines Privilegierungszertifikats GÜLTIGKEIT (binär) rückwirkend/zukünftig

Tabelle 5.9: Beispiel: Widerrufszertifikat in AMANDA

Die Tabellen 5.8 und 5.9 stellen dar, wie die AMANDA-Zertifikate in der SPKI-ähnlichen Variante aussehen. Der Aussteller wird gleichermaßen über seinen (Hash vom) öffentlichen Schlüssel identifi-ziert und durch eine angehängte Signatur authentifiidentifi-ziert. Schließlich erhält jedes PZert eine ID, damit es von einem WZert referenziert werden kann.

Die Wahl der ID ist dabei nicht trivial, weil sie vom Zertifikatsaussteller zu wählen ist. Da sich IDs nicht wiederholen dürfen, muss eine Struktur gewählt sein, die eindeutig ist. Durch die Möglichkeit, Zertifi-katsketten erstellen zu können, bevor ein Teilnehmer registriert ist und eine eindeutige Teilnehmer-ID erhalten hat – die Registrierung muss ja erst vor dem Einreichen der Zertifikatskette erfolgen, nicht vor deren Erstellung –, muss ein Teilnehmer ohne ID in der Lage sein, eine systemweit eindeutige Nummer zu vergeben. Folgender Ansatz ist für die Seriennummer gewählt:

Seriennummer: Teilnehmer-ID|Zertifikatszähler|Delegierungszähler1|Delegierungszähler2 Es gibt bei diesem Ansatz drei Zähler: Den Zertifikatszähler und die beiden Delegierungszähler. Ers-terer wird nur von dem Teilnehmer hochgezählt, der in Besitz der Teilnehmer-ID der Seriennummer ist, letztere von Delegierten. Bei Erstellung eines Folgezertifikats einer Zertifikatskette hat der Aus-steller die Wahl auf zwei Weisen eine gültige und eindeutige Seriennummer zu erzeugen. Entweder kann er eine Seriennummer unter der Wahl seiner Teilnehmer-ID, dem nächsten freien Zertifikatszäh-lerund den Delegierungszählern 0|0 generieren oder die Teilnehmer-ID und den Zertifikatszähler des vorhergehenden Zertifikats wiederverwenden und denDelegierungszähler1um 1 inkrementieren. Bei letzterer Variante können beliebig viele¹² Zertifikate erstellt werden, die alle durch die Veränderung

12Obergrenze durch Größe desDelegierungszähler2definiert.

5.4 MASC-ID Zugriffssteuerung

desDelegierungszähler2unterschieden werden können. Damit ist es möglich, Zertifikate zu erstellen, ohne bereits eine Teilnehmer-ID zugeteilt bekommen zu haben. Bei zeitaufwändigeren Registrierungs-prozeduren könnten Teilnehmer unregistriert bereits Privilegierungszertifikate erstellen. Das gültige Einreichen der entstehenden Zertifikatskette ist aber erst nach der Registrierung möglich.

Da in dieser Anwendung auf Zeitstempel verzichtet wird, benötigt der Widerruf ebenfalls kein Zeit-intervall, für das der Widerruf gilt. Dabei wird das WZert ebenfalls in den PIP eingetragen. Es gibt beim Widerruf zwei Optionen. Entweder wird die zu widerrufende Richtlinie gelöscht, was bereits getätigte Delegierungen ebenfalls ungültig macht, oder sie bleiben bestehen und sind damit noch gül-tig. Im zweiten Fall werden keine neuen Delegierungen mehr erlaubt, alte Delegierungen bleiben aber gültig. Dies kann problemlos umgesetzt werden, indem der PDP bei der Richtlinienüberprüfung (der Zeitpunkt, zu dem er Zertifikate des PAP entgegennimmt) überprüft, ob ein Kettenelement bereits wi-derrufen wurde, sprich ob es ein WZert mit der ID eines Kettenelementes gibt. Beim Zugriff und der Auswertung der Richtlinien werden WZerts nicht berücksichtigt, da sie sich auf bereits enthaltene Richtlinien nicht auswirken.

Zu dieser Widerrufregelung sei gesagt, dass sich die Bezeichnungen rückwirkend undzukünftig we-gen der Verteilten Delegierung nicht wirklich auf den Erstellungszeitpunkt der Zertifikate beziehen, sondern auf ihren Einreichungszeitpunkt.

Zugriffsteuerung

Export-Erich, Supersped, China Carriages, Peking Parking, Zoll China

Export-Erich, Supersped, China Carriages, Lu Lings Lasterladen, Zoll China

Export-Erich, Supersped, China Carriages, China Schiene, Zoll China

Supersped; x, y, z;

242400270

Export-Erich; x;

242400271

China Carriages y, z

240900080 Widerruf: Export-Erich; 242400011

Abbildung 5.4: Zugriffsrechte-DB bei AMANDA

DieRichtlinien-Tabelle der Datenbank würde im AMANDA-Fall wie in Abbildung 5.4 abgeändert. Die Richtlinien sind in der TabelleZugriffsrichtliniengespeichert. Sie enthalten inhaltlich die

AMANDA-Zertifikate, nachdem diese überprüft worden sind. Ebenfalls gespeichert sind die Widerrufe, wobei sie auf den Aussteller und die ID beschränkt wurden. Ist ein Widerruf enthalten, wird jede Delegierung, die auf einer das widerrufene Zertifikat enthaltenden Kette basiert, nicht akzeptiert.

Nach der Teilnehmerregistrierung sind alle Teilnehmerglobalen Gruppenzugeordnet. Diese beschrei-ben, welche Rollen die Teilnehmer in einem Transport einnehmen dürfen. Bezüglich des Transports legt der Spediteur oder ein Unterspediteur fest, welche Rolle die Parteien einnehmen, die in die Trans-portkette aufgenommen werden. Dies geschieht mit dem entsprechenden Eintrag in der Transport-kette-Tabelle. Damit ist jedem Teilnehmer eine Rolle zugeordnet. Tritt er mehrfach in verschiedenen Rollen auf, muss es auch mehrere Transportkettenelemente in der Datenbank geben, die sich auf seinen Teilnehmer beziehen.

Wie in Abschnitt 5.3.2 erwähnt, können AMANDA-Constraints auch Bedingungen definieren, indem sie die Bedingung in einer Klammer anfügen: A(Bedingung). Dieses Konzept wird beim MASC-ID mit AMANDA verwendet, um Transportkettenbeteiligungen zuzuweisen. Auf diese Weise können Zu-griffsrechte auf die Sensordaten mit der Bedingung Teilnehmer ist am Teiltransport beteiligt einge-schränkt werden.

Um den Teilnehmern neben ihrer Rolle auch ihre genaue Position in der Transportkette nachweisen zu können, wird der Transport in kleinste Blöcke aufgeteilt. Jeder dieser Blöcke entspricht einem Teiltransport, bei dem genau ein Transporteur für den Container verantwortlich ist, und wird durch Interchanges begrenzt. Für jeden Teiltransport wird eine lokale Gruppeangelegt. Der Gruppe wer-den als Mitglieder alle an diesem Teiltransport beteiligten Parteien zugewiesen: die Shipper, deren Ware im Container ist, die verantwortlichen Spediteure, die Versicherer der Ware und gegebenenfalls des Transports, die Frachtführer und eventuell die Zollbehörden (bei Grenzübertritt). Identifiziert wird jede Gruppe über eine Transportmittel-ID, die jedem MASC-ausgerüsteten Depot, Terminal oder Ver-kehrsmittel eindeutig zugeordnet ist. In Anhang C.3.2 sind lokale Gruppen genauer und mit Hilfe eines Beispiels erklärt.

Durch Verwendung der Constraints mit Bedingungen und den Transportmitteln, die bei der Übertra-gung der Daten ihre ID mit angeben, können alle Ereignisse einer lokalen Gruppe zugeordnet werden.

Auf diese Weise kann für jede Datenübermittlung eine Gruppe der Teilnehmer identifiziert werden, die zugreifen darf. Durch eine Bedingung kann diese Abfrage bei den Zugriffsrechten erzwungen wer-den. Wenn aufeinanderfolgende Transportmittel keine MASC-Infrastruktur anbieten und auch keine identifizierbaren Handlesegeräte verwendet werden, dann können die Zuordnungen von aufgetretenen Sensordaten zu lokalen Gruppen nur über die Zeitangabe und die Angabe der geplanten Interchanges erfolgen, wie sie in der Datenbank enthalten sind. Soll auf die Abfrage der Bedingungen verzichtet werden und jeder für den ganzen Transport berechtigt sein, die geforderten Sensordaten zu lesen, kann die Bedingung im Constraint weggelassen werden.

5.4 MASC-ID Zugriffssteuerung