Entwicklung einer dezentralisierten SharkComponent für das Erstellen von digital signierte Bestätigung für Paketübergaben

Entwicklung einer dezentralisierten SharkComponent f¨ ur das Erstellen von digital signierte Best¨ atigung f¨ ur Paket¨ ubergaben Abschlussarbeit zur Erlangung des akademischen Grades: Bachelor of Science (B.Sc.) an der Hochschule f¨ ur Technik und Wirtschaft (HTW) Berlin Fachbereich 4: Informatik, Kommunikation und Wirtschaft Studiengang Angewandte Informatik 1. Gutachter: Prof. Dr. -Ing. Thomas Schwotzer 2. Gutachter: Prof. Dr. Alexander Huhn Eingereicht von My Linh Dao [571438] 07. August 2023 Zusammenfassung Zusammen mit einem Startup der HTW Berlin hat Professor Dr. Schwotzer ein Projekt namens SharkHedwig entwickelt. Dabei handelt es sich um ein Netzwerk von Hedwigs, die Pakete an den Endempf¨ anger weiterleiten. Hedwigs k¨ onnen menschliche Boten oder Drohnen sein. Um die Paket¨ ubergaben zwischen Hedwigs sicher und unanfechtbar zu machen, muss daf¨ ur ein Kommunikationsprotokoll entwickelt werden, mit dem Hedwigs die ¨ Ubergaben mit ihrer digitalen Signatur best¨ atigen. In der Arbeit soll daher folgende Frage beantwortet werden: Wie sollte ein Kommunikationsprotokoll aufgebaut sein, damit Paket¨ ubergaben im SharkHedwig-Projekt mit diesem Protokoll sicher und unabstreitbar durchgef¨ uhrt werden k¨ onnen? Um diese Frage zu beantworten, wurden die theoretischen Grundlagen der Kryptographie untersucht und darauf aufbauend ein Kommunikationsprotokoll entwickelt. Bei der Entwicklung wurden die Funktionalit¨ aten des ASAP/Shark-Frameworks und der SharkPKI einbezogen. Nach der Analyse der Anforderungen wird ein Entwurf des Kommunikationsprotokolls vorgestellt, in dem der Ablauf dieses Protokolls erl¨ autert wird. Anschließend werden wichtige Details f¨ ur die Implementierung der auszutauschenden Nachrichten beschrieben. Abstract Together with a startup at HTW Berlin, Professor Dr. Schwotzer has developed a project called SharkHedwig. This is a network of Hedwigs that forward packets to the final recipient. Hedwigs can be human messengers or drones. In order to make the packet transfers between Hedwigs secure and non-repudiable, a communication protocol must be developed for this purpose, with which Hedwigs confirm the transfers with their digital signature. Therefore, the following question will be answered in the paper: How should a communication protocol be structured so that packet handoffs in the SharkHedwig project can be performed securely and non-repudiatably using this protocol? To answer this question, the theoretical basis of cryptography was studied and a communication protocol was developed based on it. The development included the functionalities provided by the ASAP/Shark framework and SharkPKI. After the analysis of the requirements, the design is carried out, in which the flow of the protocol is explained. Subsequently, the implementation of the messages to be exchanged is presented. 1 Eidesstattliche Erkl¨ arung Ich erkl¨ are hiermit an Eides statt, dass •ich die vorliegende wissenschaftliche Arbeit selbst¨ andig und ohne unerlaubte Hilfe angefertigt habe, •ch andere als die angegebenen Quellen und Hilfsmittel nicht benutzt habe, •ich die den benutzten Quellen w¨ ortlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe, •die Arbeit in gleicher oder ¨ ahnlicher Form noch keiner anderen Pr¨ ufbeh¨ orde vorgelegen hat. Berlin, 07. August 2023 2 Inhaltsverzeichnis 1 Einleitung 5 1.1 HintergrundderArbeit ............................... 5 1.2 Aufgabenstellung und Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 AufbauundArbeitsweise .............................. 7 2 Theoretische Grundlagen 8 2.1 Verschl¨ usselungsverfahren .............................. 8 2.1.1 Symmetrische Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2 Asymmetrische Verfahren (Public-Key-Verfahren) . . . . . . . . . . . . 9 2.1.3 HybrideVerfahren .............................. 10 2.2 Einweg-Hashfunktionen ............................... 11 2.3 DigitaleSignatur................................... 11 2.3.1 Angabe der Zeitstempel . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.2 Digitale Signatur und Verschl¨ usselung ................... 13 2.3.3 Gef¨ alschte Signatur durch Entschl¨ usselung................. 14 2.4 Public-Key-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4.1 Bestandteile einer PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4.2 PKITrustmodelle .............................. 15 2.4.3 DigitalesZertifikat.............................. 16 3 ASAP/Shark und SharkPKI 19 3.1 ASAP-Nachrichten.................................. 19 3.2 ASAPKryptophaphie ................................ 20 3.2.1 Ver-/ Entschl¨ usselung ............................ 20 3.2.2 DigitaleSignatur............................... 21 3.3 SharkPKI ....................................... 21 3.3.1 Schl¨ usselpaargenerieren........................... 21 3.3.2 Erstellung von Zertifikaten . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3.3 Austausch von Zertifikaten . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.4 Berechnung der Korrektheit eines ¨ offentlichen Schl¨ ussels . . . . . . . . . 22 4 Entwicklung des Kommunikationsprotokolls 23 4.1 Analyse ........................................ 23 4.1.1 Anforderungen aus dem Projekt SharkHedwig . . . . . . . . . . . . . . . 23 4.1.2 Sicherheitsanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2 L¨ osungskonzept.................................... 25 4.2.1 Einsatz von digitalen Signaturen und hybriden Verschl¨ usselungen . . . . 25 4.2.2 Hedwigs Rollenverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.3 Registrierungsprozess bei CA-Hedwig . . . . . . . . . . . . . . . . . . . 26 4.3 Entwurf von Delivery Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4 Hauptfunktionalit¨ aten ................................ 28 4.4.1 Sendungsinitiierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4.2 ¨ Ubergabeprotokoll .............................. 29 4.4.3 Empfangsbest¨ atigung ............................ 31 4.5 Sicherheitsanalyse des Protokollentwurfs . . . . . . . . . . . . . . . . . . . . . . 31 3 4.5.1 Erf¨ ullung der geforderten Sicherheitseigenschaften . . . . . . . . . . . . 32 4.5.2 Potentielle Angriffe und Probleme . . . . . . . . . . . . . . . . . . . . . 33 4.6 Entwurf und Implementierung von SharkHedwigComponent . . . . . . . . . . . 36 4.6.1 Verwendung von ASAP/Shark und SharkPKI . . . . . . . . . . . . . . . 37 4.6.2 Nachrichten-Typen.............................. 37 4.6.3 SharkHedwigComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5 Fazit 42 5.1 Beantwortung der Fragestellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2 Ausblick........................................ 42 4 1 Einleitung 1.1 Hintergrund der Arbeit Der Drohnenmarkt ist seit einigen Jahren in stetigem Wachstum. Drohnen werden nicht nur in Branchen wie Filmproduktion und Fotografie eingesetzt, sondern finden auch in der Transportund Logistikbranche Anwendung[21]. Transportdrohnen sind vor allem als L¨ osung f¨ ur kleinformatige Sendungen auf der letzten Meile attraktiv. Die kurze Lieferzeit durch hindernisfreie und staufreie Flugrouten z¨ ahlt zu den Vorteilen von autonomen Drohnen. Die Luftfahrzeuge k¨ onnen f¨ ur dringende Sendungen verwendet werden[6]. Potenzielle Einsatzgebiete sind Lieferungen von Medikamenten [20], medizinischen Laborproben [15] , Lebensmittel[8] oder Versorgungsmittel f¨ ur unzug¨ angliche Katastrophengebiete [16]. In Deutschland wurden bereits mehrere Projekte gestartet, bei denen Drohnen f¨ ur schnelle Transport von medizinischen G¨ utern eingesetzt werden. Ein Konsortium bestehend aus der RKH (Regionale Kliniken Holding) in Ludwigsburg, den Helios-Kliniken und dem Unternehmen German Copters arbeitet schon daran, Drohnen f¨ ur Blutund Gewebeprobentransport zu optimieren. Im August 2023 soll die erste Drohnenlieferung auf einer 30 km langen Strecke zwischen den Helios-Kliniken Breisach und M¨ ullheim durchgef¨ uhrt werden[18]. An der HTW Berlin wurde ein Logistik-Startup gegr¨ undet, das den Transport von Last-MileSendungen bedienen will. Das Unternehmen hat zusammen mit Professor Dr. Schwotzer eine Idee entwickelt: Der Transport von kleinformatigen Paketen soll mithilfe von transportf¨ ahigen Drohnen und menschlichen Boten realisiert werden. Das daf¨ ur initiierte Projekt wurde von der Post-Eule von Harry Potter inspiriert und hat den Namen SharkHedwig. Teilnehmer in diesem Netzwerk werden Hedwigs genannt. Sie k¨ onnen sowohl menschliche Boten als auch Transportdrohnen sein. Wenn ein Start-Sender eine Sendung an den Endempf¨ anger senden m¨ ochte, muss diese Sendung ¨ uber eine Lieferkette aus Hedwigs weitergeleitet werden. Die Abbildung 1 illustriert das Routing von einem Paket vom Start-Sender zum Endempf¨ anger. Auf einer Lieferroute wird ein Paket mehrmals zwischen jeweils zwei Entit¨ aten ¨ ubergeben. Dabei kann das Paket auf der Route verloren gehen. Falls dies passiert, sollte es f¨ ur die nachfolgenden rechtlichen Maßnahmen nachvollziehbar sein, welche Drohne oder Mensch das Paket als letztes bekommen hat und an welche Hedwigs das Paket auf seiner Route ¨ uberreicht wurde. Deshalb m¨ ussen von Anfang an alle durchgef¨ uhrten ¨ Ubergaben wahrheitsgem¨ aß erfasst, von beiden involvierten Hedwigs best¨ atigt und gespeichert werden. 1.2 Aufgabenstellung und Zielsetzung In dieser Arbeit soll ein Kommunikationsprotokoll implementiert werden, um die ¨ Ubergaben zwischen Hedwigs festzuhalten. Der Inhalt der Arbeit soll folgende Fragestellung beantworten: Wie sollte ein Kommunikationsprotokoll strukturiert werden, sodass mit diesem Protokoll Pakets¨ ubergaben in dem Projekt SharkHedwig sicher und nicht-abstreitbar durchgef¨ uhrt werden k¨ onnen? Dabei soll das Protokoll bei der ¨ Ubergabe zwischen den Teilnehmern in der Lieferungskette sicherstellen, dass diese ¨ Ubergabe nicht abgestritten werden kann, weder vom ¨ Ubergeber noch 5 Abbildung 1: Routing eines Pakets von Start-Sender zum Endempf¨ anger. vom Empf¨ anger. Kann der Empf¨ anger die abgeschlossene ¨ Ubergabe abstreiten, kann er das Paket ohne rechtliche Konsequenzen f¨ ur sich behalten, w¨ ahrend der ¨ Ubergeber f¨ ur den Verlust des Pakets verantwortlich ist. Um Verwechslungsgefahr zwischen den Begriffen ¨ Ubergeber und Sender als auch zwischen Empf¨ anger und Endempf¨ anger zu vermeiden, werden die folgenden Begriffe eingef¨ uhrt. •Sender: der Start-Sender, von dem das zu versendende Paket kommt. •Empf¨ anger: der Hedwig, der das Paket am Ende bekommen soll. Bei ¨ Ubergaben von einem Hedwig zum n¨ achsten Hedwig werden folgende Rollen eingef¨ uhrt: •Transferor: Paket¨ ubergeber. Er hat die Aufgabe, das Paket an Transferee zu leiten. Er kann auch der Sender selbst sein. •Transferee: Zwischenempf¨ anger. Er nimmt Pakete vom Transferor an. Auch der Endempf¨ anger kann die Rolle der Transferee annehmen. Jede Transferee soll nachweisen k¨ onnen, von wem sie das Paket bekommen hat, und jeder Transferor soll sp¨ ater einen Nachweis dar¨ uber haben, wem er das Paket ¨ uberlassen hat. Wenn der Transferor Alice ein wertvolles Paket an Bob weitergereicht hat und Bob sp¨ ater dies verleugnet, soll Alice in der Lage sein, einen g¨ ultigen Beweis f¨ ur diese Tatsache vorzulegen. Die anderen Hedwigs sollen diesen Beweis ¨ uberpr¨ ufen und erkennen k¨ onnen, dass Alice recht hat. Dies verhindert, dass Bob das Paket einfach f¨ ur sich beh¨ alt und Alice anschließend mit der Verantwortung f¨ ur das verschwundene Paket belastet. Als Beweis soll Alice einen ¨ Ubergabevertrag vorzeigen, der von ihr und Bob best¨ atigt wurde. Dieser Ansatz ist der gleiche wie bei der g¨ angigen Postzustellung. Wenn eine Postbote das Paket zu einem Empf¨ anger vor die Haust¨ ur bringt, soll der Empf¨ anger die Annahme mittels einer Unterschrift best¨ atigen. Da handgeschriebene Unterschriften leicht zu f¨ alschen sind und 6 digital nur schwer verifiziert werden k¨ onnen [17], soll der ¨ Ubergabevertrag mit digitalen Signaturen von Alice und Bob best¨ atigt werden. Das SharkHedwig-Projekt soll auch Last-Mile-Sendungen abwickeln. Das Lieferungsnetzwerk soll auch Bereiche ohne Internetverbindung ¨ uberspannen. Das Protokoll muss daher auch ohne Funkverbindung funktionieren. Es ist naheliegend, eine Applikation mit dem Framework ASAP/Shark (SharedKnowledge) zu entwickeln. Mit dem Prinzip SharedKnowledge (geteiltes Wissen) erm¨ oglicht das System eine Kommunikation ohne Internet, indem einzelne Peer ihre empfangenen Nachrichten immer an andere Peer weitergeben, bis die Nachricht ihren dedizierten Empf¨ anger erreicht [10]. 1.3 Aufbau und Arbeitsweise In diesem Kapitel wurde das Projekt SharkHedwig erl¨ autert und die Aufgabenund Zielstellung formuliert. Um das Ziel der Arbeit, n¨ amlich die Entwicklung des Kommunikationsprotokolls zu erreichen, werden in Kapitel 2 die notwendigen Grundlagen der Kryptographie erl¨ autert. In Kapitel 3 werden die Softwares, die f¨ ur die Implementierung verwendet werden, vorgestellt. Dazu geh¨ oren das Framework ASAP/Shark und die Shark-Komponente SharkPKI. Anschließend folgt die Entwicklung des Protokolls in Kapitel 4. Hier werden in der Analyse die Anforderungen ermittelt, die das Kommunikationsprotokoll erf¨ ullen muss, um eine sichere und unabstreitbare ¨ Ubergabe zu erm¨ oglichen. Dazu geh¨ oren funktionale Anforderungen und nicht-funktionale Sicherheitsanforderungen. Basierend auf diesen Anforderungen wird ein Konzeptentwurf f¨ ur das Protokoll erstellt. Anschließend werden die wichtigen Methoden und Klassen in der Implementierung erl¨ autert. 7 2 Theoretische Grundlagen 2.1 Verschl¨ usselungsverfahren Verschl¨ usselungsverfahren (Chiffrierverfahren) sind Gegenstand der Kryptographie und werden f¨ ur die Geheimhaltung von vertraulichen Nachrichten verwendet. M¨ ochte ein Benutzer A eine Nachricht an einen Benutzer B senden, ohne dass die Nachricht auf dem Weg zu B von anderen Benutzer gelesen werden kann, muss er diese verschl¨ usseln. Wenn der Benutzer B diese Nachricht bekommt, muss er sie entschl¨ usseln, um sie zu lesen. Bei der Verschl¨ usselung (Chiffrierung) wandelt eine Verschl¨ usselungsmethode durch Eingabe eines Verschl¨ usselungsschl¨ ussels den Klartext in Chiffretext um. Aus diesem Chiffretext kann wieder der Klartext berechnet werden. Der Vorgang wird als Entschl¨ usselung (Dechiffrierung) bezeichnet. Sowohl f¨ ur jede Verschl¨ usselungsmethode als auch f¨ ur jeden Verschl¨ usselungsschl¨ ussel gibt es eine Entschl¨ usselungsmethode beziehungsweise einen Entschl¨ usselungsschl¨ ussel. Um den Chiffretext wieder in Klartext umzuwandeln, werden diese Entschl¨ usselungsmethode und -schl¨ ussel auf den Chiffretext angewendet [13]. Die graphische Modellierung der beschriebenen Vorg¨ ange wird in Abbildung 2 visualisiert. Die Geheimhaltung eiAbbildung 2: Prozess der Verschl¨ usselung und Entschl¨ usselung ner verschl¨ usselten Nachricht darf nicht von der Geheimhaltung des verwendeten Algorithmus abh¨ angen, sondern ausschließlich auf der Geheimhaltung der Schl¨ ussel basieren. Dies besagt das Kerckhoffs’sche Prinzip. Daher ist ein gutes Schl¨ usselmanagement f¨ ur alle Verschl¨ usselungsverfahren von großer Bedeutung[13]. Grundlegend k¨ onnen Verschl¨ usselungsverfahren in zwei Kategorien eingeordnet werden, n¨ amlich in symmetrischen und asymmetrischen (oder auch Public-Key-) Verfahren. 2.1.1 Symmetrische Verfahren Bei symmetrischen Verfahren sind Entund Verschl¨ usselungsschl¨ ussel gleich. Sei feine symmetrische Verschl¨ usselungsfunktion, meine Nachricht und kder Schl¨ ussel, dann erh¨ alt man die verschl¨ usselte Nachricht cmit c=f(k, m). Zu der Funktion fmuss eine Umkehrfunktion f−1f¨ ur die Entschl¨ usselung existieren, sodass f−1(k, c) = m, [4]. Folgende Abbildung 3 stellt die Verund Entschl¨ usselungsprozesse dar. 8 •Directory Service: Directory Service bezeichnet den Speicherort f¨ ur g¨ ultige Zertifikate und ung¨ ultige Zertifikate. Wenn der private Schl¨ ussel eines Benutzers verloren geht, ung¨ ultig oder von Dritten kompromittiert wird, wird auch das f¨ ur ihn erstellte Zertifikat ung¨ ultig. •Personal Security Environment (PSE): Ein PSE ist das Aufgewahrungsmedium von privaten Schl¨ usseln eines Benutzers. Der PSE bietet eine Schnittstelle f¨ ur die Verwendung von ausgew¨ ahlten Sicherheitstechnologien. •Sicherheitstechnologie: Sie umfasst kryptographische Verfahren, die f¨ ur die Kommunikationssicherheit eingesetzt werden. 2.4.2 PKI Trustmodelle In diesem Abschnitt werden M¨ oglichkeiten vorgestellt, wie die Korrektheit einer Schl¨ usselzuordnung m¨ oglichst gew¨ ahrleistet wird. Die Abbildung 7 visualisiert folgende Modelle: •Hierarchisches Modell: Das System hat eine Baumstruktur. Es wird eine zentrale Vertrauensinstanz, der Root CA, als Baumwurzel ben¨ otigt. Jeder Peer hat Kenntnis ¨ uber den ¨ offentlichen Schl¨ ussel des Root CAs. Die Aufgabe von Root CA besteht darin, die unter ihm hierarchisch geordneten CAs zu zertifizieren. Diese CAs zertifizieren wiederum die Benutzer im System. Daraus entsteht f¨ ur jedes Benutzer-Zertifikat eine Zertifizierungskette, die aus dem Root CA ausgeht und am Benutzer endet. Bei der Verifizierung eines Zertifikats m¨ ussen alle Zertifikate in der Zertifizierungskette einer Pr¨ ufung unterzogen werden. •Verteiltes Trustmodell: Hierbei handelt es sich um eine Zusammenf¨ uhrung mehrerer hierarchischer Modelle zu einem großen System. Zus¨ atzlich sollen sich die Root CAs gegenseitig zertifizieren. Mit dem Zertifikat von CA1 f¨ ur CA2 k¨ onnen die Benutzer im gelben Bereich die Zertifikate der Benutzer im lila Bereich nachpr¨ ufen(siehe Abbildung 7). Die Verifizierungsvorgang ist wie beim hierarchischen Modell, da auch hier eine Zertifizierungskette vorliegt. •Hub Modell: Dieses Modell ist ¨ ahnlich wie das verteilte Trustmodell mit einem Unterschied: die normalen CAs in einer Hub Dom¨ ane stellen auch dem Hub CA (bei verteiltes Trustmodell Root CA genannt) Zertifikate aus. Hier muss bei der Verifizierung eines Zertifikats gepr¨ uft werden, ob der ausstellende CA und Hub CA sich gegenseitig zertifiziert haben. •Flaches Modell: Hier gibt es keine Verbindung zwischen den CAs. Jeder Peer kann sich bei einem CA seiner Wahl zertifizieren lassen und kennt auch die ¨ offentlichen Schl¨ ussel aller CAs. Jeder CA wird als vertrauensw¨ urdig erachtet. •Benutzer Trustmodell (Web of Trust): Bei diesem Ansatz gibt es keine CAs. Die Benutzer verifizieren sich gegenseitig. Jeder ist f¨ ur den eigenen Aufbau der Vertrauenskette und Schl¨ usselverwaltung verantwortlich. Dieses Modell bietet die Grundlage f¨ ur die Komponente SharkPKI. 15 Abbildung 7: Trustmodelle in der Reihenfolge: Hierarchische Modell, Verteiltes Trustmodell, Hub Modell, Flaches Modell, Benutzer Trustmodell 2.4.3 Digitales Zertifikat Aus den vorherigen Abschnitten wurde eindeutig, dass digitale Zertifikate eine essentielle Rolle in einem PKI haben. Ein Zertifikat ist eine digitale Best¨ atigung, die die Verkn¨ upfung zwischen einem ¨ offentlichen Schl¨ ussel und seinem Besitzer best¨ atigt. Die Erteilung eines Zertifikats von einem Peer namens Alice f¨ ur einen Peer namens Bob durchl¨ auft folgende Schritte [14]: 1. Bob wird von Alice authentifiziert. Dabei muss Bob seine Identit¨ at nachweisen, z.B. mit einem Ausweis oder anderen eindeutigen Merkmalen. Außerdem ¨ ubergibt Bob Alice seinen ¨ offentlichen Schl¨ ussel. 2. Alice pr¨ uft Bobs vorgelegte Identit¨ atsnachweise. Wenn sie Bobs Identit¨ at best¨ atigen kann, erstellt sie ein Zertifikat als Best¨ atigung, dass der ¨ offentliche Schl¨ ussel Bob geh¨ ort. Alice signiert dieses Dokument mit ihrer digitalen Signatur und sendet das Ganze an Bob. 3. Das von Alice erstellte Zertifikat kann Bob nun an andere Peers versenden. Wenn Alice eine vertrauensvolle und zuverl¨ assige Person ist, dann wird ein anderer Peer Bobs Schl¨ ussel glauben schenken und diesen bei der Kommunikation mit Bob nutzen. Digitale Zertifikate k¨ onnen zudem zwischen Benutzerund CA-Zertifikaten unterschieden werden. Benutzer-Zertifikat Benutzer-Zertifikate haben nach dem weit verbreitete X.509 Standard (IETF – Internet Engineering Task Force)[14] den folgenden Grundaufbau: 16 •Standard Informationen: Informationen, die f¨ ur ein Zertifikat wesentlich sind. Dazu geh¨ oren: Serial Number eindeutige Identifikationsnummer des Zertifikats Signature das vom Erzeuger verwendete Signaturverfahren Issuer ID und Name des Erzeugers Validity G¨ ultigkeitszeitraum Subject ID und Name des Verifizierten Subject Public Key Info Signaturalgorithmus, verwendete Parameter, Public Key •Extensions: Dieses Feld enth¨ alt optionale Zusatzinformationen zum Zertifikat wie Nutzungszweck, Certificate Policies, Subject Alternative Name etc. •Issuer Signature: Dieses Feld inkludiert den Signaturwert und den Signaturalgorithmus sowie die daf¨ ur verwendete Parameter. CA-Zertifikat Diese Zertifikate werden f¨ ur die Certificate Authorities erstellt. Sie sind vom Aufbau her wie die Benutzer-Zertifikate. Jedoch kommen in den Extensions weitere Felder hinzu. •Basic Constraints: Das Feld gibt an, ob der entsprechende Schl¨ ussel f¨ ur die Verifikation benutzt werden darf. Hinzu kommt die maximal erlaubte L¨ ange der Vertrauenskette, die vom Zertifikataussteller bis zum Benutzer reicht. •Name Constraints: Hier werden die geforderten oder verbotenen Namensbereiche definiert. Dadurch werden manche CAs aus der Vertrauenskette ausgegrenzt. Die Benutzer im Bereich des zertifizierten CAs d¨ urfen keine Benutzer authentifizieren, wenn die Vertrauenskette zwischen diesen beiden Benutzern einen ausgegrenzten CA enth¨ alt. •Policy Constraints: Dieses Feld kann verwendet werden, um bestimmte Policies (Vorschriften) zu verlangen. Beispiel: Manche ¨ offentliche Schl¨ ussel k¨ onnen nur f¨ ur Emails verwendet werden. Revokationsliste Es kann vorkommen, dass ein digitales Zertifikat f¨ ur ung¨ ultig erkl¨ art werden muss. Daf¨ ur gibt es verschiedene Gr¨ unde: •Das Zertifikat ist abgelaufen. •Der private Schl¨ ussel des Zertifizierten Benutzers oder des ausstellenden CAs wurde kompromittiert. •Das Zertifikat wurde mit dem falschen ¨ offentlichen Schl¨ ussel erstellt. •Der Besitzer hat ein neues Schl¨ usselpaar generiert. Jedoch gibt es immer noch Dokumente, die mit dem nun ung¨ ultigen ¨ offentlichen Schl¨ ussel signiert wurden und noch weiterhin verifizierbar sein m¨ ussen. Folglich m¨ ussen diese Zertifikate weiterhin aufbewahrt werden. In einem PKI-System werden ung¨ ultige Zertifikate in einer Revokationsliste aufbewahrt. Es besteht die Gefahr, dass ein Angreifer einen noch g¨ ultigen ¨ offentlichen Schl¨ ussel in einer Revokationsliste ver¨ offentlicht. Der Grund daf¨ ur k¨ onnte sein, dass es von dem Angreifer 17 gewollt ist, dass ein Benutzer keine weiteren verschl¨ usselten Nachrichten empfangen kann. Ein anderer Grund w¨ are, dass der Angreifer seinen eigenen ¨ offentlichen Schl¨ ussel als neuen Schl¨ ussel von einem anderen Benutzer publizieren will. Um unbefugte Revokation zu vermeiden, wird f¨ ur diese Aufgabe eine vertrauensw¨ urdige Instanz gebraucht. Es ist naheliegend, dass der CA f¨ ur die Aufgabe sehr geeignet ist, da er bereits als authentisch angesehen wird. Die ung¨ ultigen Zertifikate werden in einer Liste mit zus¨ atzlichen Informationen zusammengef¨ ugt und als sogenannte Certificate Revocation List (CRL) publiziert. Die CRL hat nach dem Standard X.509 v.3 [14] den folgenden Aufbau: •Standard Informationen: Informationen, die f¨ ur die Revokationsliste von Bedeutung sind. Dazu z¨ ahlen: Signature Signaturverfahren Issuer Ausgeber der Liste Update time Zeitpunkt der aktuellen und n¨ achsten Herausgabe der Liste Revoked Certificates Die Liste der ung¨ ultigen Zertifikate. Zus¨ atzlich kann zu jedem Zertifikat eine Erweiterung angeh¨ angt werden, die Informationen wie Grund der Ung¨ ultigkeit oder den Zeitpunkt, ab dem das Zertifikat f¨ ur ung¨ ultig erkl¨ art wurde. •Erweiterungen: Zusatzdaten, die erg¨ anzt werden k¨ onnen. Beispiel: eindeutige Identifikationsnummer, Ort der Ausstellung, alternativer Name des Ausstellers. •Signatur: Signatur des Ausstellers auf der CRL [14]. . 18 3 ASAP/Shark und SharkPKI ASAP/Shark (Shared Knowledge) ist ein Open-Source-Framework, das als Basis f¨ ur die Implementierung von dezentralisierten Anwendungen eingesetzt werden kann. Das Grundprinzip der Kommunikation mit ASAP/Shark ist ¨ ahnlich wie die Nachrichtenvermittlung in der menschlichen Gesellschaft. Wenn Menschen sich begegnen, k¨ onnen sie die ihnen bekannten Informationen weitergeben. Auf diese Weise k¨ onnen Botschaften verbreitet werden, bis sie die Empf¨ anger erreichen. ASAP(Asynchronous Semantic Ad-Hoc Protocol) ist ein Routingprotokoll und bildet den Kern einer ASAP/Shark-Applikation. Es wird im OSI-Modell auf Schicht 3 zugeordnet. Ein Ger¨ at, welches ASAP/Shark implementiert, wird ASAP Peer genannt. Wenn zu einem bestimmten Zeitpunkt mehrere ASAP Peers miteinander Verbindung aufgebaut haben (bspw. durch Bluetooth oder Wifi-Direct), was als Ad-Hoc-Netzwerk bezeichnet wird, k¨ onnen sie Nachrichten miteinander austauschen. Diese Nachrichten k¨ onnen sowohl von ihnen selbst als auch von anderen ASAP Peers stammen [10]. Wenn ein ASAP Peer eine Nachricht von einem anderen ASAP Peer bekommt, welche nicht f¨ ur ihn bestimmt ist, dann kann diese gespeichert und bei der n¨ achsten M¨ oglichkeit des Datenaustauschs weiter an andere ASAP Peers geleitet werden. Die Kommunikationsverbindung zwischen ASAP Peers wird ASAP Encounter genannt [3]. Shark ist das Framework, mit welchem ASAP-Anwendungen entwickelt werden k¨ onnen. Shark stellt Methoden zur Verf¨ ugung, die f¨ ur den Start-Prozess solcher Anwendungen ben¨ otigt werden. Alle Shark-Anwendungen auf einem Ger¨ at teilen sich den gleichen ASAP Peer und k¨ onnen miteinander kommunizieren. Shark definiert Formate f¨ ur verschiedene ASAP/SharkAnwendungen und unterst¨ utzt dadurch die Separation von ASAP Nachrichten. Folgende Abbildung 8 modelliert die Beziehung zwischen ASAP Peers und Shark-Applikationen sowie die ¨ Ubertragung von einer Nachricht der Applikation B bei einer bestehenden Verbindung[1]. . Abbildung 8: ¨ Ubertragung der Nachricht B zwischen zwei ASAP Peers 3.1 ASAP-Nachrichten ASAP-Nachrichten k¨ onnen in zwei unterschiedliche Kategorien aufgeteilt werden, wobei sie sich grundlegend in der Routingart unterscheiden: 19 1. Assimilate-Nachricht: Diese Nachrichten werden von ASAP mit dem Prinzip Store-AndForward behandelt. Wenn ein ASAP Peer eine Assimilate-Nachricht an einen anderen ASAP Peers versendet, wird die Nachricht zuerst lokal in seinem Ger¨ at gespeichert. Wenn dieser ASAP Peer in einem Ad-Hoc-Netzwerk steht, das heißt, dass eine Kommunikationsverbindung (z.B. durch Bluetooth oder Wifi-Direct) zu anderen ASAP Peer besteht, werden die gespeicherten Nachrichten asynchron weitergeleitet. Bekommt ein ASAP Peer eine Nachricht, pr¨ uft er nach, ob diese an ihn adressiert wurde. Ist dies nicht der Fall, dann speichert er die Nachricht und leitet sie bei der n¨ achsten Verbindung an andere Peers weiter. Dadurch, dass jeder ASAP Peer seine Nachrichten immer weiter vermittelt, ist es f¨ ur jeden ASAP Peer m¨ oglich, ohne direkte Verbindung oder Internet Nachrichten an einen entfernten ASAP Peer zu versenden. 2. Transient-Nachricht: Im Gegensatz zu Assimilate-Nachrichten werden Transient-Nachrichten nach dem Erhalten nicht gespeichert und weitergeleitet. Sie sind nur f¨ ur die ASAP Peers bestimmt, die sich aktuell in Verbindung mit dem Sender befinden. Diese Art von Nachrichten kann ein ASAP Peer verwenden, wenn seine Botschaft nur an die aktuell mit ihm in Verbindung stehenden ASAP Peers zu versenden ist. [2] 3.2 ASAP Kryptophaphie Das Framework ASAP stellt neben dem Routingprotokoll auch kryptographische Methoden f¨ ur das Verund Entschl¨ usseln von Nachrichten sowie f¨ ur digitale Signaturen zur Verf¨ ugung. Die gemeinsame Basis von diesen beiden Verfahren ist der ASAPKeyStore. Darin wird der private Schl¨ ussel eines ASAP Peers und alle bekannten ¨ offentlichen Schl¨ ussel der anderen ASAP Peers gespeichert. Die kryptographischen Algorithmen werden in der Klasse ASAPCryptoAlgorithms bereitgestellt[7]. Die Verschl¨ usselung basiert auf dem hybriden Verschl¨ usselungsverfahren. Hierf¨ ur wurden die Verfahren AES (symmetrisch) und RSA (asymmetrisch) implementiert. 3.2.1 Ver-/ Entschl¨ usselung Der folgende Programmcode in Listing 1 zeigt wie eine Nachricht f¨ ur den Empf¨ anger Bob (mit der ID “bobID”) mit der Methode produceEncryptedMessagePackage() und decrypteMessage() verschl¨ usselt und entschl¨ usselt wird. 1byte[] message = " Hello " ; 2CharSequence receiverID = " bobID " 3//Verschluesselung 4byte[] encryptedMessage = 5ASAPCryptoAlgorithms . produceEncryptedMessagePackage ( message . getBytes () , receiverID , asapKeyStore ); 6//Entschluesselung 7ASAPCryptoAlgorithms.EncryptedMessagePackage 8encryptedMessagePackage = ASAPCryptoAlgorithms. parseEncryptedMessagePackage ( encryptedMessage ); 9byte[] decryptedMessage = 10 ASAPCryptoAlgorithms . decryptPackage ( encryptedMessagePackage , asapKeyStore); Listing 1: Verund Entschl¨ usselungsfunktionen in ASAP Bei Aufruf der Methode produceEncryptedMessagePackage() wird der ¨ offentliche Schl¨ ussel von Bob aus dem ASAPKeyStore gesucht. Sollte dieser nicht in ASAPKeyStore existieren, wird 20 ein ASAPSecurityException ausgeworfen. Mit dem gefundenen ¨ offentlichen Schl¨ ussel von Bob wird die Nachricht hybrid verschl¨ usselt. Um die Nachricht (mit Datentyp byte-Array) wieder zu entschl¨ usseln, muss sie erst in ein EncryptedMessagePackage-Objekt formatiert werden. Danach muss der Empf¨ anger die Methode decryptPackage() aufrufen, um seinen privaten Schl¨ ussel aufzurufen und damit die Nachricht zu entschl¨ usseln[7]. 3.2.2 Digitale Signatur F¨ ur digitale Signaturen wird der Hash-Algorithmus SHA-256 und die Verschl¨ usselung RSA implementiert. Die Methode sign() generiert eine Signatur f¨ ur eine Klartext-Nachricht. Nach dem der Empf¨ anger die Signatur mit der Klartext-Nachricht bekommen hat, kann er diese mit der Methode verify() verifizieren(Listing 2) : 1// signieren 2byte[] signature = ASAPCryptoAlgorithms . sign ( content , asapKeyStore ); 3//verifizieren 4boolean verified = ASAPCryptoAlgorithms.verify( 5signedContent , signature , senderID , asapKeyStore ); Listing 2: Digitale Signatur in ASAP: Signierung und Verifizierung 3.3 SharkPKI Wie in Kapitel 2 erkannt wurde, wird f¨ ur die Verwendung von asymmetrischen Kryptoverfahren ein PKI-System f¨ ur die Schl¨ usselverwaltung ben¨ otigt. SharkPKI ist eine auf ASAP/Shark basierende Komponente, die diese Aufgabe ¨ ubernimmt. Die in [11] angegebenen Funktionalit¨ aten von SharkPKI werden in den folgenden Abschnitten erl¨ autert. 3.3.1 Schl¨ usselpaar generieren Die Methode createNewKeyPair() von SharkPKIComponent generiert ein neues asymmetrisches Schl¨ usselpaar f¨ ur den ASAP Peer, das f¨ ur Verschl¨ usselung und digitale Signatur eingesetzt werden kann. Dabei wird das alte Schl¨ usselpaar gel¨ oscht. 3.3.2 Erstellung von Zertifikaten SharkPKI hat die Struktur eines Benutzer-Trustmodells. Jeder Peer ist in der Lage, ein Zertifikat f¨ ur einen anderen Peer auszustellen. Hat ein Peer Alice den ¨ offentlichen Schl¨ ussel von einem Peer Bob bekommen und ist sicher, dass Bob diesen Schl¨ ussel tats¨ achlich besitzt, kann sie mit der folgenden Methode ein Zertifikat f¨ ur Bob erstellen: 1ASAPCertificate acceptAndSignCredential ( CredentialMessage credentialMessage ) throws IOException , ASAPSecurityException ; Listing 3: Methode f¨ ur das Ausstellen des digitalen Zertifikats in SharkPKI CredentialMessage ist eine Nachricht von Bob, die Alice mitteilt, welchen ¨ offentlichen Schl¨ ussel Bob hat. Das von Alice erzeugte Zertifikat, das die Identit¨ at von Bob mit seinem ¨ offentliche Schl¨ ussel verkn¨ upft, wird gleich an Bob weitergegeben. 21 3.3.3 Austausch von Zertifikaten Wenn zwei ASAP Peers sich treffen und beide SharkPKI integriert haben, tauschen sie automatisch ihre gespeicherten Zertifikate aus. Dazu geh¨ oren sowohl die von ihnen selbst erzeugten Zertifikate als auch Zertifikate, die von anderen ASAP Peers erstellt worden sind. Daher k¨ onnen Peers auch Zertifikate von ASAP Peers bekommen, mit denen sie selbst noch nie in Verbindung getreten sind. 3.3.4 Berechnung der Korrektheit eines ¨ offentlichen Schl¨ ussels ASAP Peers bestimmen f¨ ur jeden anderen ASAP Peer, dem sie begegnet sind, eine SignatureFailure-Stufe, die ausdr¨ uckt, wie oft dieser Peer Fehler beim Zertifizieren macht. Hierf¨ ur wird folgende Methode benutzt: 1void setSigningFailureRate ( CharSequence personID , int failureRate) throws ASAPSecurityException; Listing 4: Methode zur Zuweisung von Signing-Failure-Stufen in SharkPKI Die Signature-Failure-Stufe ist eine nat¨ urliche Zahl im Wertebereich 0 bis 10. Bewertet Alice Bob mit einer Signature-Failure-Stufe von 7, bedeutet dies f¨ ur Alice, dass 70% der von Bob ausgestellten Zertifikate falsch und 30% korrekt sind. Die Stufe 0 ist der niedrigste Stufe und bedeutet, dass ein Peer keinen Fehler macht, w¨ ahrend die Stufe 10 impliziert, dass alle Zertifikate von diesem Peer falsch sind. Jeder Peer ordnet die Stufe 0 nur sich selbst zu. Mit Signature-Failure-Stufen kann Alice die Identity-Assurance-Stufe eines ¨ offentlichen Schl¨ ussels berechnen, die in einem Zertifikat steht. Die Identity-Assurance-Stufe pr¨ asentiert die Korrektheit eines Zertifikats aus der Sicht eines Peers. Diese wird wie folgt berechnet: Sei X1,X2, . . . , Xn-1 , Xneine Menge von Peers und sei sf eine Funktion, die die SignatureFailure-Stufe aus der Sicht von X1angibt. Um die Berechnung von Identity-Assurance ¨ ubersichtlicher zu gestalten, nimmt man als Wertebereich von sf die Menge 0, 0.1, 0.2, . . . , 1 anstatt 0,1,....,10 von SharkPKI. Weiter sei eine Zertifikatskette C(X1, X2), C(X2, X3),..., C(Xn-1 , Xn). Dann kann die IdentityAssurance-Stufe von Xnaus Sicht von X1wie folgt berechnet werden: IA(Xn) = (1 −sf(X1)) ∗(1 −sf(X2)) ∗... ∗(1 −sf(Xn)) Die Rechnung wird durch folgendes Beispiel veranschaulicht. Alice hat eine mit ihr angefangene Zertifikatkette: C(Alice, Bob), C(Bob, Clara), C(Clara, David) Alice will die Identity-Assurance-Stufe von David berechnen. Gleichzeitig hat Alice den in der Zertifikatskette vorkommenden Peers die folgenden Signing-Failure-Werte zugewiesen: Peer sf(Peer) Alice 0 Bob 0.3 Clara 0.5 David 0.1 Alice berechnet die Identity-Assurance-Stufe von David wie folgt: IA(David) = (1 −0) ∗(1 −0.3) ∗(1 −0.5) = 1 ∗0.7∗0.5=0.35 22 Das Ergebnis wird am Ende gerundet. Es gilt IA(David) = 0.4, spricht 4 in SharkPKI. Diese Berechnung wird beim folgenden Methodenaufruf ausgef¨ uhrt. Bei Vorhandensein von mehrere Zertifikatsketten wird die h¨ ochste Identity-Assurance-Stufe als R¨ uckgabewert ausgegeben. 1int getIdentityAssurance ( CharSequence userID ) throws ASAPSecurityException; Listing 5: Methode f¨ ur Berechnung von Identity-Assurance-Stufe in SharkPKI Die Zertifikatskette mit h¨ ochster Identity-Assurance-Stufe gibt die folgende Methode aus: 1List < CharSequence > getIdentityAssurancesCertificationPath ( CharSequence userID) Listing 6: Methode f¨ ur Ausgabe von Zertifikatskette in SharkPKI 4 Entwicklung des Kommunikationsprotokolls 4.1 Analyse 4.1.1 Anforderungen aus dem Projekt SharkHedwig Wie in Kapitel 1 erw¨ ahnt, besteht das Ziel dieser Arbeit darin, ein dezentrales Kommunikationsprotokoll f¨ ur das Projekt SharkHedwig zu entwickeln. Bei dem Projekt handelt es sich um eine Gruppe von Drohnen und Menschen, die Pakete entgegennehmen und an den Empf¨ anger ausliefern sollen. Diese Paketboten werden Hedwigs genannt. Will ein Hedwig ein Paket an einen anderen Hedwig versenden, kann er dieses Paket durch eine Kette von liefernden Hedwigs an den Empf¨ anger weiterleiten, das bedeutet, dass das Paket mehrmals von einem Hedwig zum n¨ achsten Hedwig ¨ ubergeben wird. Wird dabei die Route des Pakets nicht erfasst, ist bei Paketverlust keine Nachverfolgung m¨ oglich. Demzufolge muss eine L¨ osung entwickelt werden, um relevante Informationen zu jeder ¨ Ubergabe in Form eines ¨ Ubergabevertrags zu erfassen. Außerdem muss f¨ ur jeden ¨ Ubergabevertrag die Best¨ atigung sowohl vom Transferor als auch von der Transferee festgehalten werden, als Nachweis , dass die ¨ Ubergabe auch tats¨ achlich stattgefunden hat. Diese Vertr¨ age sollen bei jeder n¨ achsten ¨ Ubergaben weitergereicht werden, sodass der Empf¨ anger am Ende nachvollziehen kann, welche Hedwigs sich an der Lieferungskette beteiligt haben. F¨ ur den Fall, dass das Paket besch¨ adigt ankommt oder falls alle beteiligten Hedwigs f¨ ur ihre Dienste verg¨ utet werden m¨ ussen, ist die Kenntnis der Lieferungskette entscheidend. Da das Projekt SharkHedwig Auslieferungen auf der letzten Meile bedient und ¨ Ubergaben auch in Gebieten ohne Funksignal durchf¨ uhrbar sein sollen, muss die Kommunikation zwischen Hedwigs auch ohne Internetverbindung m¨ oglich sein. Auf der Lieferungskette k¨ onnen folgende Anwendungsszenarien ermittelt werden: 1. Normale ¨ Ubergabe zwischen zwei Hedwigs 23 2. Initiale ¨ Ubergabe vom Sender-Hedwig: Vor der ersten ¨ Ubergabe muss der Sender die Sendung initiieren. Er erzeugt ein Lieferungsetikett mit wichtigen Informationen ¨ uber die Sendung wie Empf¨ anger, Sender und Paket-ID. Danach erfolgt alles wie bei einer normalen ¨ Ubergabe. 3. Finale ¨ Ubergabe an einen Empf¨ anger-Hedwig: Nach der normalen ¨ Ubergabe ¨ uberpr¨ uft die Transferee, ob sie der Endempf¨ anger ist. Wenn das der Fall ist, verschickt sie eine Nachricht an den Sender. Abbildung 9: Die drei Anwendungsszenarien in SharkHedwig-Projekt Es soll ein Kommunikationsprotokoll entworfen werden, das f¨ ur die ¨ Ubergabe bei allen drei ausgef¨ uhrten Anwendungsszenarien verwendet werden kann. Das Protokoll soll sicherstellen, dass die ¨ Ubergabe eines Pakets zu keinem sp¨ ateren Zeitpunkt vom jeweiligen Transferor oder Transferee abgestritten werden kann. Zudem soll gezeigt werden, wie dieses Kommunikationsprotokoll implementiert werden kann. Das Kommunikationsprotokoll soll SharkHedwigProtokoll und die Implementierung SharkHedwigComponent genannt werden. 4.1.2 Sicherheitsanforderungen Es lassen sich aus der obigen Projekt-Beschreibung die folgenden Sicherheitsanforderungen identifizieren: 1. Verbindlichkeit: Bevor die Transferee ein Paket von dem Transferor bekommt, muss sie ihm eine Best¨ atigung zusenden, die mit ihrer Identit¨ at verbunden ist. Auch der Transferor muss die ¨ Ubergabe best¨ atigen. Die abgegebenen Best¨ atigungen werden von beiden Partner gespeichert und dienen sp¨ ater als Nachweis der ¨ Ubergabe. 2. Nachricht-Authentizit¨ at: Nachdem ein Hedwig eine ¨ Ubergabebest¨ atigung von einem anderen Hedwig mit ID-Nummer X erhalten hat, soll er auch nachweisen k¨ onnen, dass diese auch wirklich von diesem Hedwig X erzeugt worden ist. 3. Hedwig-Authentizit¨ at: Beide Parteien m¨ ussen vor dem Datenaustausch sicher sein, dass ihr aktueller Kommunikationspartner wirklich derjenige ist, der angibt zu sein. 4. Integrit¨ at: Die Nachrichten zwischen Hedwigs sollen nicht manipulierbar sein. Hat Hedwig A eine Nachricht von Hedwig B bekommen, die durch ein Angreifer Hedwig C ge¨ andert wurde, sollte diese unerlaubte ¨ Anderung f¨ ur Hedwig A sichtbar sein. 24 Vertragsphase In dieser Phase werden Informationen f¨ ur die ¨ Ubergabe kommuniziert und signiert. Als Erstes ruft der Transferor den Delivery Contract f¨ ur das Paket aus seinem lokalen Speicher auf. Dann erzeugt er einen neuen Transit-Contract und f¨ ullt die ben¨ otigten Felder mit aktuellen Informationen aus. Anschließend signiert der Transferor den Transit-Contract, f¨ ugt diesen in die Liste in dem Delivery Contract hinzu und verschickt den Delivery Contract hybrid verschl¨ usselt an die Transferee. Wenn die Transferee den Delivery Contract erh¨ alt, muss sie diesen anhand der folgenden Kriterien ¨ uberpr¨ ufen: •Die Signatur des Senders auf dem Shipment-Label l¨ asst sich verifizieren. •In dem ersten Transit-Contract der Liste ist der Transferor ebenfalls der Sender. Dieser Transit-Contract hat die Ordnungsnummer 1. •Die Transit-Contract-Liste weist hinsichtlich der Ordnungsnummer keine L¨ ucken auf. Transit-Contracts werden in aufsteigender Reihenfolge nach ihrer Ordnungsnummer und ¨ Ubergabezeit sortiert. •Die Transferee in einem Transit-Contract mit Ordnungsnummer n ist auch der Transferor in dem Transit-Contract mit Ordnungsnummer n+1 (n ist eine nat¨ urliche Zahl). •Die Signaturen auf allen Transit-Contracts lassen sich verifizieren. •Die Informationen in der letzten Transit-Contract der Liste entsprechen der aktuellen ¨ Ubergabe. Die angegebene ¨ Ubergabezeit und -ort d¨ urfen nicht wesentlich von der aktuellen Zeit und dem Ort der Transferee abweichen. Die angegebene Paket-ID muss mit der Angabe auf dem Shipment-Label ¨ ubereinstimmen. Die Signatur des Transferors auf diesem Transit-Contract l¨ asst sich verifizieren. Hat der Delivery Contract die oben genannten Kriterien erf¨ ullt, signiert die Transferee den aktuellen Transit-Contract. Da der Transferor den Inhalt des Transit-Contracts bereits kennt, muss die Transferee den Transit-Contract nicht nochmal an den Transferor zur¨ uckschicken. Die Transferee muss ihre Signatur mit dem ¨ offentlichen Schl¨ ussel vom Transferor hybrid verschl¨ usseln und an ihn senden. Kann der Transferor die Signatur der Transferee f¨ ur den aktuellen Transit-Contract verifizieren, ¨ ubergibt er das Paket an die Transferee. Nach der ¨ Ubergabe speichern beide Hedwigs den Delivery Contract mit dem neuen Transit-Contract lokal bei sich. Die Transferee ¨ uberpr¨ uft nun, ob sie der Empf¨ anger des Pakets ist. Wenn dies der Fall ist, sendet sie eine Empfangsbenachrichtigung an den Sender. 4.4.3 Empfangsbest¨ atigung Hat eine Transferee nach der ¨ Ubergabe festgestellt, dass das Paket an sie adressiert wurde, generiert sie eine Empfangsbest¨ atigungsnachricht mit dem Delivery Contract als Inhalt. Die Nachricht wird vor dem Versenden vom Empf¨ anger signiert, dann mit dem ¨ offentlichen Schl¨ ussel des Senders hybrid verschl¨ usselt und anschließend an den Sender verschickt. 4.5 Sicherheitsanalyse des Protokollentwurfs In diesem Abschnitt werden die Sicherheitsaspekte des entworfenen Kommunikationsprotokolls ausf¨ uhrlich untersucht. 31 4.5.1 Erf¨ ullung der geforderten Sicherheitseigenschaften Das entworfene ¨ Ubergabeprotokoll erf¨ ullt folgende aufgez¨ ahlte Sicherheitsanforderungen aus der Analyse. Verbindlichkeit Haben Transferor und Transferee einen Transit-Contract signiert und die Signaturen ausgetauscht, haben sie damit die ¨ Ubergabe best¨ atigt. Der signierte Transit-Contract dient zu jedem sp¨ ateren Zeitpunkt als Nachweis. Authentizit¨ at der Nachricht Wenn der Transferor und die Transferee die digitalen Signaturen voneinander verifizieren k¨ onnen, dann k¨ onnen diese Signaturen nicht von anderen Hedwigs erzeugt worden sein. Bei Geheimhaltung der privaten Schl¨ ussel und zuverl¨ assigen Verschl¨ usselungsverfahren ist es kaum m¨ oglich, eine digitale Signatur zu f¨ alschen. Integrit¨ at der Nachricht Eine ¨ Anderung des Transit-Contracts nach dem Signieren f¨ uhrt dazu, dass diese Signatur f¨ ur den Inhalt nicht mehr verifiziert werden kann. Die digitale Signatur ist mit dem signierten Inhalt verbunden. Auch die hybrid verschl¨ usselte Kommunikation garantiert die Integrit¨ at der Nachrichten. Nicht-Wiederverwendbarkeit Dadurch, dass die Zeitund Ordnungsnummer der ¨ Ubergabe auch in dem Transit-Contract festgehalten wird, kann folgendes Angriffsszenario verhindert werden: Alice, Bob und Clara sind Hedwigs. Alice ¨ ubergibt ein Paket an Bob. Beide best¨ atigen diese Tatsache in einem Transit-Contract ohne Zeitangaben oder Ordnungsnummer. Danach gibt Bob das Paket an Clara. Clara gibt das Paket am n¨ achsten Tag wieder an Alice, weil sie z.B. keine M¨ oglichkeit findet, es an den Empf¨ anger zu routen. Alice hat jetzt wieder das Paket. Sie kann nun den Transit-Contract, den sie am vorigen Tag mit Bob unterschrieben hat, kopieren und nochmal als Beweis nehmen, dass sie das Paket nochmal an Bob gegeben hat. Das wird funktionieren, da der TransitContract f¨ ur die ¨ Ubergabe an Bob f¨ ur diesen Tag exakt die gleichen Informationen enth¨ alt wie der Transit-Contract am vorigen Tag. Dieses Problem wird bei dem Entwurf des Transit-Contracts durch Zeitstempel und Ordnungsnummer gel¨ ost. Hedwigs k¨ onnen einen mit Zeitangaben signierten Transit-Contract nicht f¨ ur zwei unterschiedliche ¨ Ubergaben verwenden. Authentizit¨ at der Hedwigs Zu Beginn des ¨ Ubergabeprotokolls wird eine Response-Challenge in der Identifikationsphase ausgef¨ uhrt. Diese dient der Authentifizierung der Hedwigs vor dem eigentlichen Datenaustausch. Wenn die Identifikationsphase nicht zuerst durchgef¨ uhrt wird, kann das folgende Problem auftreten. Dabei wird davon ausgegangen, dass Hedwigs wie Smartphones ihre Uhrzeit ¨ uber einen NTP-Server und ihren Ort ¨ uber GPS-Signale oder andere Datentransmitter beziehen und diese Signale anf¨ allig gegen Spoofing sind. 32 Alice und Bob sind Hedwig-Drohnen. Sie k¨ onnen beim GPSund NTP-Spoofing nicht merken, dass die Signale gef¨ alscht sind. Alice will eine Sendung an Bob ¨ ubergeben. Sie trifft aber statt Bob zuerst Mallory, der sich als Bob ausgibt. Alice generiert einen neuen Transit-Contract, signiert diesen und schickt ihn an Mallory in dem Glauben, dass Mallory Bob sei. Nachdem Mallory den Transit-Contract bekommen hat, bricht er die Verbindung mit Alice ab. Mallory hat das Paket von Alice schon gesehen und kennt auch die Paket-ID. Er kann das Paket verf¨ alschen. Zudem kann Mallory die Zeitund Ortsangabe in dem Transit-Contract erraten, da er weiß, wo und wann Alice den Transit-Contract erstellt hat. Mit einem gef¨ alschten Paket trifft Mallory sich mit Bob und gibt sich als Alice aus. Mallory f¨ uhrt dabei GSPund NTPSpoofing aus, sodass Bob denkt, dass die Zeitund Ortsangaben auf dem Transit-Contract immer noch stimmen. Die Signatur von Alice auf den Transit-Contract kann Bob verifizieren, da diese auch tats¨ achlich von Alice stammte. Bob erzeugt darauf seine Signatur f¨ ur den Transit-Contract, sendet an Mallory und bekommt von ihm das falsche Paket. Nun kann Mallory zu Alice gehen und bei ihr GSPund NTP-Spoofing ausf¨ uhren, sodass sie glaubt, dass sie sich in der gleichen Ort und Zeit befindet wie in dem von ihr signierte Transit-Contract angegeben. Mallory behauptet wieder, dass er Bob sei. Der Transit-Contract, den Alice nun f¨ ur die ¨ Ubergabe an Bob erzeugen will, ist durch F¨ alschung der GPSund NTP-Signale der gleiche wie der, den Mallory vorher bekommen hat. Dadurch ist auch die Signatur von Bob auf diesem Transit-Contract g¨ ultig. Nun kann Mallory die Signatur von Bob an Alice senden und bekommt das Paket von Alice ausgeh¨ andigt. Mit der Einf¨ uhrung der Identifikationsphase kann dieses Problem vermieden werden. Wenn Mallory sich als Bob ausgeben will, muss er erstmal die Response-Challenge-Nachricht von Alice an Bob in einer kurzen Zeitspanne von drei Sekunden entschl¨ usseln. Das kann er nicht, da er den privaten Schl¨ ussel von Bob nicht kennt. 4.5.2 Potentielle Angriffe und Probleme Gefahr der Signaturf¨ alschung bei Verwendung von gleichen Schl¨ usselpaar f¨ ur Verschl¨ ussung und Signatur ASAP/Shark ist eine Open-Source-Bibliothek. Jeder kann damit dezentralisierte Applikationen bauen. ASAP/Shark-Applikationen auf einem Ger¨ at teilen einen ASAP KeyStore, indem der private und ¨ offentliche Schl¨ ussel des Ger¨ ats gespeichert werden. Das bedeutet, dass diese Applikationen das gleichen Schl¨ usselpaar teilen. Das gleiche Schl¨ usselpaar wird sowohl f¨ ur die Verschl¨ usselung als auch f¨ ur die Signierung verwendet. Dieses Merkmal kann vom Angreifer ausgenutzt werden, um unbemerkt an Signaturen der teilnehmenden Hedwigs zu kommen. Es entsteht folgendes Problem: Ein Angreifer Malory implementiert eine andere ASAP-Shark-Applikation namens SharkAuthentification, die Response-Challenge-Authentifizierung mit asymmetrischer Verschl¨ usselung als Funktionalit¨ at anbietet. Die Applikation benutzt die RSA-Verschl¨ usselung f¨ ur ResponseChallenge. Das ist auch das Verfahren, das die Signaturfunktion ASAPCryptoAlgorithms.sign() von ASAP ebenfalls implementiert. Wenn Alice Bobs Identit¨ at pr¨ ufen will, verschl¨ usselt sie einen Zufallscode mmit der asymmetrischen Verschl¨ usselungsfunktion fd, die von Bobs ¨ offentlichem Schl¨ ussel dabh¨ angt. Folgendes 33 Ergebnis schickt sie an Bob: fd(m) Um sich bei Alice zu authentifizieren, dechiffriert Bob die Nachricht mit der Entschl¨ usselungsfunktion fe, die von seinem privaten Schl¨ ussel abh¨ angt. Bob schickt Folgendes an Alice zur¨ uck: fe(fd(m)) = m Wird SharkAuthentication auch von Bob benutzt, kann Malory Bobs Signatur f¨ ur ein TransitContract cabfragen. Sei hdie Hashfunktion SHA-256, die in ASAPCryptoAlgorithms.sign() implementiert wurde. Da Bob den gleichen privaten Schl¨ ussel und das gleiche Verfahren (RSA) f¨ ur Signatur und Entschl¨ usselung benutzt, ist die Signatur von Bob Folgende: signBob =fe(h(c)) Nun kann Malory signBob bekommen, indem er mit SharkAuthentication eine ResponseChallenge an Bob sendet. Das Sequenzdiagramm (Abbildung 14) illustriert den Prozess. Abbildung 14: Sequenzdiagramm: Malory sendet Bob unverschl¨ usselte Nachricht als Challenge Anstatt eine verschl¨ usselte Nachricht an Bob zu schicken, kann Malory seine SharkAuthentificationApp bei sich ¨ andern und stattdessen den verschl¨ usselten Hashwert vom Transit-Contract h(c) an Bob senden. Bob erkennt nicht, dass die Nachricht kein verschl¨ usselter Zufallscode, sondern der Hashwert eines Transit-Contracts ist. Er entschl¨ usselt die Nachricht mit seinem privaten Schl¨ ussel. Als Output bekommt Bob eine Zeichenfolge, die er f¨ ur den von Malory zuf¨ allig generierten Code h¨ alt. Er schickt diese Zeichenfolge an Malory, um sich als Bob zu authentifizieren. Diese Zeichenfolge ist fe(h(c)) und entspricht der Signatur signBob von Bob f¨ ur Transit-Contract c. Bob hat somit unbewusst den Transit-Contract von Malory signiert. Um diesen Angriff zu vermeiden, sollte das Schl¨ usselpaar, das f¨ ur die Erzeugung von digitalen Signaturen verwendet wird, nicht f¨ ur andere Anwendungen zug¨ anglich sein. Andernfalls muss immer sichergestellt werden, dass alle ASAP/Shark-Applikationen nur hybriden anstatt asymmetrischen Verschl¨ usselungsverfahren f¨ ur die Chiffrierung von Nachrichten verwenden. 34 In der Identifikationsphase im ¨ Ubergabeprotokoll wurde die Response-Challenge mit hybrider anstatt asymmetrischer Verschl¨ usselung realisiert. Angreifer k¨ onnen die Identifikationsphase nicht nutzen, um die Signatur des Benutzers abfragen. Sei fedie Entschl¨ usselungsfunktion mit privaten Schl¨ ussel e,gdie symmetrische Entschl¨ usselungsfunktion. Bekommt Bob eine hybrid verschl¨ usselte Nachricht mmit dem verschl¨ usselten Schl¨ ussel k, dann berechnet Bob den Klartext m′mit: k′=fe(k) m′=gk′(m) Die Antwort, die Bob zur¨ uckschickt, ist m′. Dadurch, dass Bob seine Entschl¨ usselungsfunktion nur auf den Schl¨ ussel kanwendet und das Ergebnis k′nicht weitergibt, ist hybride Verschl¨ usselung vor dem beschriebenen Angriff sicher. Der Angreifer kennt m′,mund k, hat jedoch keine Kenntnis ¨ uber k′. Ung¨ ultige Signatur nach Ablauf des Zertifikats SharkPKI Zertifikate sind f¨ ur ein Jahr g¨ ultig. L¨ auft das Zertifikat f¨ ur die ¨ offentlichen Schl¨ ussel eines Transit-Hedwigs ab, kann der Transit-Contract mit der Signatur von diesem Hedwig nicht mehr verifiziert werden. Single-Point-of-Failure durch die Rolle CA-Hedwig Eine Herausforderung des SharkHedwig-Projekts besteht darin, dass die Anzahl der Hedwigs im Lieferungsystem f¨ ur einen gut abgedeckten Lieferbereich sehr hoch werden kann. Mit der Anzahl von Hedwigs steigt auch die Anzahl der ¨ offentlichen Schl¨ usseln, die verwaltet werden m¨ ussen. Dadurch, dass alle Zertifikate im System nur von einem einzigen CA-Hedwig ausgestellt werden, kann dieser Hedwig als Single-Point-of-Failure betrachtet werden. Sollte es einem Angreifer gelungen sein, den privaten Schl¨ ussel des CA-Hedwigs zu kompromittieren, kann auch dieser Angreifer Zertifikate unter dem Namen des CA-Hedwigs erzeugen. Der Angreifer kann ein Zertifikat ausstellen, das seinen ¨ offentlichen Schl¨ ussel mit der Identit¨ at eines anderen Hedwigs verkn¨ upft. Demnach ist es f¨ ur ihn m¨ oglich, Transit-Contracts f¨ ur diesen Hedwig zu signieren, die Pakete an sich zu nehmen und die Verantwortung dem kompromittierten Hedwig zu ¨ uberlassen. Damit solche Angriffe keine Folge auf das gesamte System mit sich ziehen, kann das Netzwerk der Hedwigs in Subnetze aufgeteilt werden. Jedes Subnetz hat einen CA-Hedwig und eine Gruppe von Transit-Hedwigs, die ihren CA-Hedwig kennen und vertrauen. CA-Hedwigs stellen CA-Zertifikate f¨ ur einander und Benutzer-Zertifikate f¨ ur Transport-Hedwigs in ihrem Subnetz aus. Diese Struktur entspricht dem verteilten Trustmodell, das im Kapitel 2 vorgestellt wurde. Die folgende Abbildung 15 beschreibt die Verbindung zwischen Hedwig Alice im Subnetz A und Hedwig Bob im Subnetz B sowie die Kette von Zertifikaten, die Alice kennen muss, um Bob zu authentifizieren. Die Notation C(X, Y ) bedeutet ein von Hedwig Xausgestelltes Zertifikat f¨ ur Hedwig Y. CA-Hedwigs m¨ ussen einander kennen und CA-Zertifikate f¨ ur einander ausstellen. Wenn sie Transport-Hedwigs in ihrem Subnetz treffen, teilen sie ihnen alle CA-Zertifikate mit, die sie 35 Abbildung 15: Die Zertifikatskette zwischen zwei Hedwigs in verschiedene Subnetze A und B ausgestellt haben. Bekommt ein Hedwig ein CA-Zertifikat f¨ ur eine CA-Hedwig, weist er dieser CA-Hedwig eine niedrige Signature-Failure-Stufe zu. So kann er sich merken, dass diese CAHedwig vertrauensw¨ urdige Zertifikate f¨ ur andere Hedwigs ausstellt. Um einen Hedwig Bob in einem anderen Subnetz zu authentifizieren, muss Hedwig Alice die folgende Zertifizierungskette zu Bob haben: C(Alice, CA-Hedwig A), C(CA-Hedwig A, CA-Hedwig B), C(CA-Hedwig b, Bob) Mit dieser Kette kann Alice die Identity-Assurance-Stufe von Bob in dem Zertifikat C(CAHedwig B, Bob) mit SharkPKI bestimmen sowie das Zertifikat verifizieren. Wenn der Schl¨ ussel von einem Hedwig-CA kompromittiert wird, so sind nur Zertifikate und Hedwigs in seinem Subnetz betroffen. Probleme k¨ onnen nur entstehen, wenn Hedwigs in diesem Subnetz nach der Kompromittierung in die Lieferungskette eingebunden werden. Wenn der kompromittierte Hedwig-CA den Angriff fr¨ uhzeitig bemerkt, kann er andere Hedwigs benachrichtigen, sodass keine weiteren Pakete ¨ uber sein Subnetz ¨ ubertragen werden. 4.6 Entwurf und Implementierung von SharkHedwigComponent Im letzten Abschnitt wurde der Entwurf des SharkHedwig-Kommunikationsprotokolls vorgestellt. In diesem Abschnitt werden Funktionalit¨ aten, die f¨ ur die Durchf¨ uhrung dieses Protokolls erforderlich sind, in einem ASAP/Shark-Komponent implementiert und spezifiziert. Die Schnittstelle (API) des Komponents wird durch das Interface SharkHedwigComponent pr¨ asentiert. 36 4.6.1 Verwendung von ASAP/Shark und SharkPKI Da die Kommunikation auch ohne Internet funktionieren soll, bietet sich das Framework ASAP/Shark von Prof. Dr. Schwotzer als eine sehr passende L¨ osung. Das Framework erm¨ oglicht die Bluetooth-Kommunikation zwischen Hedwigs, ohne dass eine Internetverbindung erforderlich ist. Aus diesem Grund sollte das Kommunikationsprotokoll zur Paket¨ ubergabe als ASAP/Shark-Komponent implementiert werden. Da das Protokoll auf hybrider Verschl¨ usselung und digitaler Signatur basiert, spielt die Verwaltung von ¨ offentlichen Schl¨ ussel eine bedeutende Rolle. Unabdingbar ist somit, dass SharkPKI in die Komponente SharkHedwig integriert wird. 4.6.2 Nachrichten-Typen Die im SharkHedwig-Protokoll ausgetauschten Nachrichten k¨ onnen entsprechend ihrer zugeh¨ orige Phasen (Identifikationsphase und Vertragsphase) in zwei Typen unterteilt werden: Contract-Message in der Vertragsphase und Identification-Message in der Identifikationsphase. Damit SharkHedwigKomponent diese Nachricht-Typen unterscheiden kann, werden die Typen als URI definiert in konstanten Variablen festgehalten. Außerdem wird f¨ ur die Empfangsbest¨ atigung von End-Empf¨ anger an Sender eine andere Art von Nachricht ben¨ otigt. Sie wird in der konstanten Variable URI DELIVERY DONE festgehalten: 1@ASAPFormats ( formats = { SharkHedwigComponent . SHARK_HEDWIG_FORMAT }) 2public interface SharkHedwigComponent extends SharkComponent { 3String SHARK_HEDWIG_FORMAT = " shark / hedwig "; 4String URI_IDENTIFICATION_MESSAGE = "sn2://identification"; 5String URI_CONTRACT_MESSAGE = " sn2 :// contract "; 6String URI_DELIVERY_DONE = " sn2 :// delivery_done "; 7.... 8} Listing 7: F¨ ur SharkHedwigComponent definierte URI Identification-Message Nachrichten mit dem URI URI IDENTIFICATION MESSAGE sind Objekte der Klasse IdentificationMessage. Das folgende Klassendiagramm (Abbildung 16) zeigt die Attribute und Methoden dieser Klasse. Abbildung 16: Klassendiagramm: IdentificationMessage Jedem IdentificationMessage-Objekt wird eines der drei IdentificationMessageType 37 IDENT REQUEST, IDENT ANSWER oder IDENT CHECKED zugeordnet. Die Typen entsprechen jeweils den Schritten der Identifikationsphase in dem SharkHedwig-Protokoll. Die Methode getContent() gibt den Zufallscode, den die Nachricht enth¨ alt, zur¨ uck. Contract-Message Nachrichten, die in der Vertragsphase ausgetauscht werden, werden Contract-Message genannt und mit dem URI URI CONTRACT MESSAGE versendet. Wie in dem SharkHedwigProtokoll bereits beschrieben wurde, sendet zuerst der Transferor einen signierten Delivery Contract an die Transferee. Dieser Delivery Contract wird in eine Klasse DeliveryContract implementiert. DeliveryContract-Objekte haben zwei Attribute: ein ShipmentLabel-Objekt und die ArrayList von TransitContract-Objekte . Der Aufbau der Klassen DeliveryContract, ShipmentLabel und TransitContract sowie ihre Zusammenh¨ ange stellt das Klassendiagramm in Abbildung 17 dar. Klasse ShipmentLabel Abbildung 17: Klassendiagramm: DeliveryContract und abh¨ angige Klassen Ein ShipmentLabel-Objekt beinhaltet alle Informationen ¨ uber Sender und Empf¨ anger des Pakets. Diese Informationen werden als Attribute in dem ShipmenLabelContent-Objekt festgehalten. Die Signatur des Senders auf den ShipmentLabelContent-Objekt stellt die CharSequence signatureSender dar. Mit der Methode verifySignature() k¨ onnen Hedwigs pr¨ ufen, ob diese Signatur wirklich vom Sender stammt. Klasse TransitContract Die Klasse TransitContract steht in einer Aggregation-Beziehung zu der Klasse DeliveryContract. Ein DeliveryContract-Objekt kann mehrere TransitContract-Objekte besitzen. Bei jeder neuen ¨ Ubergabe wird ein neues TransitContract-Objekt generiert. Transit-Contract38 Objekte haben einen Attribut content von Typ TransitContractContent. Die Signaturen des Transferor und der Transferee auf einem TransitContract-Objekt werden in den Attributen signatureTransferor und signatureTransferee festgehalten. Mit der Methode signAsTransferor() und signAsTransferee() k¨ onnen Hedwigs nach ihrer entsprechende Rolle die digitale Signatur auf den Vertrag setzen. Klasse DeliveryContract Die Methoden in der Klasse DeliveryContract haben folgenden Funktionalit¨ aten: addCurrentTransitContract(TransitContract): f¨ ugt eine neues TransitContract-Objekt f¨ ur die aktuelle Paket¨ ubergabe in den Delivery-Contract hinzu. removeCurrentTransitContract(): die Methode wird aufgerufen, wenn die Kommunikationssession abgebrochen wurde und der daf¨ ur erstellte Transit-Contract entfernt werden muss. getCurrentTransitContract(): gibt das TransitContract-Objekt f¨ ur die aktuelle ¨ Ubergabe aus, um darauf die Methoden f¨ ur Signieren aufzurufen oder die Signaturen zu verifizieren. verify(): Bei Aufruf werden die Signaturen auf ShipmentLabel-Objekt und alle TransitContractObjekte (außer das aktuelle Transit-Contract-Objekt) ¨ uberpr¨ uft. Die Signaturen auf dem aktuelle TransitContract-Objekt werden, wie in obigem Abschnitt erl¨ autert wurde, abh¨ angig von Rolle des Hedwigs (Transferor oder Transferee) verifiziert. 4.6.3 SharkHedwigComponent Gem¨ aß dem f¨ ur das SharkHedwig-Protokoll ermittelten Anwendungsdiagramm soll das Interface SharkHedwigComponent folgenden Methoden beinhalten: 1public interface SharkHedwigComponent extends SharkComponent { 2void identifyHedwig ( CharSequence hedwigID ); 3 4void sendDeliveryContract ( CharSequence hedwigID , CharSequence packageID ); 5 6DeliveryContract createDeliveryMessage ( CharSequence e2eReceiver , CharSequence packageID , Location e2eReceiverLocation ) throws DeliveryContractlreadyExistsException; 7 8void confirmPackageReceived (); 9} Listing 8: Methoden der Interface SharkhedwigComponent Um die Nutzung dieser Methoden f¨ ur alle drei Anwendungsszenarien, die in der Analyse ermittelt wurden, zu erl¨ autern, wird im folgenden Sequenzdiagramm (Abbildung 18) ein Szenario beschrieben, das alle drei Anwendungsf¨ alle umfasst. In diesem Szenario ¨ ubergibt ein Sender das Paket direkt an den Empf¨ anger. Sendung-Initialisierung 39 Abbildung 18: Sequenzdiagramm: Ablauf des SharkHedwig-Protokolls mit Methodenaufruf Um eine Sendung zu initiieren, ruft der Sender die Methode createDeliveryMessage(...) mit Eingabe vom Empf¨ anger-ID, Paket-ID und Empfangsort auf. Die Methode erstellt ein DeliveryContract-Objekt mit einem ShipmentLabel-Objekt, das die eingegebene Informationen enth¨ alt. Die Liste der TransitContract-Objekte bleibt zun¨ achst leer und wird erst sp¨ ater bei der ¨ Ubergabe mit TransitContract-Objekt bef¨ ullt. Das ShipmentLabel-Objekt wird mit dem privaten Schl¨ ussel vom Sender, die im ASAPKeyStore gespeichert wurde, signiert. Das DeliveryContract-Objekt wird anschließend lokal gespeichert. Falls es schon ein DeliveryContract f¨ ur die gleiche Paket-ID im Speicher gibt, soll ein DeliveryContractAlreadyExistsException geworfen werden. ¨ Ubergabeprotokoll Bevor das Protokoll startet, muss ein DeliveryMessage-Objekt mit dem Paket ID im Speicher vorhanden sein. Dies kann durch vorherige Sendung-Initialisierung generiert oder bei der letzten ¨ Ubergabe vom Transferor mitgeteilt worden sein. Identifikation-Messages werden mit dem URI URI IDENTIFICATION und Contract-Messages mit dem URI URI CONTRACT 40