Home

Eine Sicherheitsarchitektur für eine Informationssystem

Contents

1. getSSLLoginPage Sting getSSLLoginComment String getSSLPortint getS8LKeystorePath String get95LKeystoreType String get 8LKeystorePassword String gel5SLTruststorePath String getSSLTruststoreType String getSSLTruststorePassword String has SLTruststore hoolean get5SLC onfigurationByType S3LConfiguration get5SLConfigurations Vector nit8SLConfigurations vold 8 Configuration 5LWehServerFactory mySSLFactory SSLWehSenerfacto startSSLSerrersivoid S5LWebSernerractony 1 Runnable ssIGonfiguration 98LGonfiguration broker Broker 0 1 gellnstance3L WebServer intS3LContet void getPortint getType String runvold 53LWebSener instance oo lt vereinfacht A HTTPS Connection DefautSSLWebServer String ClientCertificatesSLWebServer TYPE Sting SmartCardCertificateS LWehServer SmanCardCertficateSSLWehSerer de infoasset broker session GenericHandler de infoasset broker handler security SLPasswordLoginHandler de infoasset broker handler security SLCertificateLoginHandler de infoasset broker handler security SS1SmartCardLoginHandler Entwurf der Secure Web Server Architektur SWS Architektur Abb
2. 45 ABB 22 ENTWURF DER SECURE WEB SERVER ARCHITEKTUR 5 5 22 2 22 51 ABB 23 AUTORISIERUNGSARCHITEKTUR 55 29 67 ABB 24 AUTORISIERUNGSARCHITEKTUR SUBJEKTBASIERTE BERECHTIGUNGEN 69 ABB 25 AUTORISIERUNGSARCHITEKTUR 2 299 656 0 6 5 9 72 26 AUTORISIERUNGSARCHITEKTUR GESAMTARCHITEKTUR 75 iv TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform 1 Einleitung Das Internet hat sich in den vergangenen 10 Jahren von einem Tummelplatz f r Computerfreaks zu einem echten Massenmedium entwickelt Es existiert mittlerweile kaum noch jemand der nichts von dem Internet geh rt hat und trotz des Endes des Internet Hypes und des Platzens der dot com Blase an den internationalen Finanzm rkten nimmt die Anzahl der Benutzer die immer wieder neue Dienste im Internet f r sich entdecken kontinuierlich zu Dies zeigt dass das Internet seinen Platz unter den Massenmedien behauptet und ausbaut Das Internet revolutioniert unsere Art zu denken und zu handeln Es tut dies weil es in der Lage ist s mtliche bisher bekannten Medien zu integrieren Online Zeitungen Radio und TV Streaming Videokonferenzen Mailing etc Dar ber hinaus ist es in der L
3. Neveu Jaddeum 1addenNnoyny a pueH addennoynyialpueH IOKBINPAIOIHUIBZIIE UN pox saguoumyapueHyu 1800010 8 004 08 201 UMS IWYN 439907 pIORSSWEWEIPUEHIOPEAISUSIBIPUEHINd 490 00510 40155954900 795560 01 N 18 ayspedsiguauspedsip 5 asseo yurap 5 5 55 pioxjsanbayp emor pioxjsanbayaipuey aysedsiguaysedsip 405595 015595 199010 1 955 9 onseinheiten ti tektur Organisa i h Autorisierungsarc Abb 25 72 TUHH Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform 4 2 3 2 Technischer Entwurf W hrend die deklarative Zuordnung der Zugriffsrechte sehr einfach und anwendungsfreundlich ist ist der programmatische Teil der Architektur der sich dahinter verbirgt umso komplexer Abb 25 zeigt wie die Zuordnung von Handlern die hier durch die generalisierte Klasse GenericHandler repr sentiert werden zu Berechtigungen Authorities programmatisch realisiert wird Die Aufgabe der Zuordnung bernimmt hierbei die Klasse HandlerAuthorityMapper die die Zuordnungstabelle enth lt Na
4. RESTRICTIVE_POLICY Strin mapper HandlerAuthorityMapper authorityPolicy String transientAuthorityMapper Hashtable dispatcher Dispatcher AuthorityReader initvoid putHandlersinsteadOfHandlemames void checkAuthority boolean z reader AuthorityReader authorityNamesAndinstances Hashtable handleRequestvoid forwardRequestvold slave etAuthorityReader AuthorityReader AuthorityReader checkAuthority boolean readAuthoritiesFromfile void extractAuthorityNames void HandlerAuthorityMapper getTransient uthoritMapper Hashtable 1 1 initTransientauthori finalizelnitProcedure singleton pattern vereinfacht L handlerAuthorityMap Hashtable wrapper locked boolean AuthorityManager log Logger getAuthority Authority initHandlerAuthorities void finalizelnitProcedure void HandlerAuthorityMapper de infoasset broker session GenericHandier Authority HandlerAuthorityManper 0 1 authorityUniqueName String getAuthorityName String check boolean cresteComposedAuthority Authority createAuthorityFrornNode Authorit Authority SubjectbasedAmthority ObjectbasedAuthority AndAuthority OrAuthority NotAuthority leftAauthority Authority tert uthority Authority authority Authority EISEN rightAuthority A
5. 2 1 2 1 Authentisierung 2 1 2 2 2 2 123 Vertraulichkeit 2 1 2 4 Integrit t 2 1 2 5 Verbindlichkeit oan 2er ner number 2 1 2 6 Weitere Sicherheitskonzepte 2 1 3 Allgemeine 2 2 EIGENSCHAFTEN DER ZIELPLATTFORM 12 2 3 TECHNOLOGIEN E 231 Authentisier n gs 2 3 1 1 Konzepte zur Authentisierung 2 3 12 Umsetzung webbasierter Authentisierung 17 29 2 22 2 3 2 1 berblick nenn eures 22 2 3 22 Symmetrische 24 2 3 2 3 Asymmeirische Kryptographie 2 4 2w 2 mel 24 2 3 2 4 Ri 25 25 2 3 3 1 26 2 3 3 2 509 Ein Standard f r digitale
6. Engine au Engine i Engine KeyManagerFactory gt KeyStore 4 TrustManagerFactory 1 1 erzeugt Objekte i erzeugt Objekte vom Typ speichert vom Typ Key Material Trust Material verwendet 7 verwendet verwendet verwendet interne Klasse Klasse Klasse interne Klasse DefaultKM MyKM MyTM DefaultTM implementiert implementiert Interface KeyManager ben tigt ben tigt erzeugt SSLContext erzeugt Standardobjekte Standardobjekte erzeugt getDefault Klasse Klasse SSLSocketFactory SSLServerSocketFactory erzeugt Klasse SSLServerSocket accept erzeugt erzeugt ben tigt Klasse Interface Klasse SSLSocket gt SSLSession lt SSLSocket Abb 20 JSSE Aufbau Hauptklassen Betrachtet man erneut die beiden erw hnten Pfade in Abb 20 so repr sentiert der linke Pfad den Einsatz von JSSE als Client w hrend der rechte Pfad den Einsatz als Server repr sentiert Da f r diese Arbeit unter Java lediglich die Serverrolle von Bedeutung ist soll der Einsatz von JSSE ausschlie lich in dieser Rolle betrachtet werden Geht man von einem individuell konfigurierten SSLContext aus so w rde man die betreffende SSLServerSocketFactory ber eben diese SSLContext Instanz erhalten Nutzt man hingegen einen Standard SSLContext so erh lt man eine Instanz der SSLServerSocketFactory direkt ber die Klassenmethode getDefault Da
7. 31 2 3 3 3 Zertifikatsspeicher in Java serverseitige 32 2 3 3 4 Zertifikatsspeicher in Netscape clientseitige 2 34 Das SSE Protokoll au nntnn sie 2 3 4 1 Der Protokollstapel eine statische Betrachtung 2 3 4 2 Der SSL Handshake eine dynamische Betrachtung 2 3 4 3 SSL in Java die Java Secure Socket Extension JSSE 2 3 5 SafeGuard Biometrics SmartCard Produkt der Fa Utimaco Safeware 2 3 5 1 Produkt uswahl ausdehnen 2 3 5 2 Produkteisensch ften E 3 VERTRAULICHKEIT INTEGRIT T UND AUTHENTISIERUNG 47 3 1 KONZEPTE ZUR UMSETZUNG BEIM INFOASSET 0 1 47 3 2 BESCHREIBUNG DES 0 111 3 2 1 Analyse des bestehenden Web 3 2 2 Entwurf berlegungen und Kriterien 3 23 Entwurf Die Gesamtarchitektur 3 3 DETAILS DER IMPLEMENTIERUNG r ucueneseeeensessennssssnnnnnsennnnnsenonsnnennnsnnennnsssennnnssenonsnsennnserennnsssennne 3 3 1 Dynamische Link Erzeugung und
8. if this dispatcher checkAuthority h this documentlId h handleRequest this output documentId else this forwardRequest output security accessDenied htm Man erkennt dass f r den Fall dass die Berechtigungspr fung erfolgreich ist das System wie bisher reagiert Ein abweichendes Verhalten erh lt man f r den Fall dass die Berechtigungspr fung missling Im letzteren Fall wird ein Handler ausgef hrt der ein Template instanziiertt das den Benutzer ber die Zugriffsverletzung informiert JavaScript Alert und die zuvor angezeigte Seite erneut anzeigt History Back 4 2 5 Die Gesamtarchitektur Nachdem auf s mtlich wichtige Aspekte der Autorisierungsarchitektur eingegangen worden ist wird diese um das Bild zu vervollst ndigen als Ganzes dargestellt s Abb 26 Die Hilfsklassen und die Ausnahmeobjekte Exceptions die f r die Implementierung erforderlich sind sind in dieser Darstellung fortgelassen Die Bedeutung der Klassen Broker und AuthorityReader wird im Zusammenhang mit der Initialisierung der Zuordnungstabelle noch erl utert 74 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform de infoasset broker server Broker dispatcher Dispatcher Broker de infoasset broker session Session de infoasset broker session Dispatcher AuthorityManager manager AuthoritYManager
9. der serverseitigen Signatur wird ein serverseitiger Prozess durchgef hrt durch den der Hashwert beim Server direkt signiert wird Beide M glichkeiten haben Vor und Nachteile Eine serverseitige Signatur ist verh ltnism ig leicht zu implementieren da serverseitig ja die gesamte Java Umgebung zur Verf gung steht Denkbar w re einen dezidierten Signatur Keystore mit eigens f r die digitale Signatur geschaffenen Zertifikaten bereitzustellen Bei den verwendeten Zertifikaten k nnten selbstsignierte Zertifikate ausreichen so dass diese mit Hilfe von keytool erstellt werden k nnten und keine zus tzliche Kostenbelastung darstellen w rden Problematisch ist hier u U die Frage nach der juristischen Verbindlichkeit Eine clientseitige Signatur ist erheblich komplizierter Hier muss ber cksichtigt werden dass clientseitig Browser vorliegen deren programmatische M glichkeiten stark eingeschr nkt sind Hier gilt es also zun chst zu analysieren wie ein Hashwert unter Ber cksichtigung der jeweiligen Schnittstelle z B PKCS 11 von dem im Browser verwendeten Sicherheitsger t signiert werden kann Da in diesem Fall die Zertifikate f r die clientseitige Authentisierung bereits vorliegen existiert hier kein zus tzlicher administrativer Aufwand wie es bei der serverseitigen Signatur der Fall w re Dar ber hinaus erf llt dieser Weg wohl eher die juristischen Bedingungen als der zuvor beschriebene Eine weitere M glichkeit das Si
10. 2 1 1 Allgemeines zum Thema Sicherheit Der Begriff Sicherheit ist weit verbreitet Er wird innerhalb v llig verschiedener Themengebiete verwandt so dass seine Semantik stark von dem jeweiligen Kontext abh ngt Um den Begriff in allgemeiner Weise verstehen zu k nnen ist es sinnvoll sich zu vergegenw rtigen dass der Begriff Sicherheit stets im Kontext wohldefinierter Gefahren Bedrohungen oder Risiken zu sehen ist Allgemein l sst sich sagen dass es sich hierbei um unerw nschte Ereignisse handelt deren Eintritt oder deren Eintrittsabfolge nicht deterministisch also lediglich stochastisch vorhergesagt werden k nnen Die Ma nahmen die zur Verh tung des Eintritts eines oder mehrerer solcher Ereignisse dienen sind in ihrer Gesamtheit dem Begriff Sicherheit untergeordnet Oft bauen solche Ma nahmen aufeinander auf greifen ineinander oder sind zueinander komplement r Die Ungewissheit ber die m glicherweise eintretenden Ereignisse ihre Vielfalt und die Vielzahl der unterschiedlichen Ma nahmen die zu ihrer Verh tung einsetzbar sind machen das Thema Sicherheit in allgemeiner Weise sehr komplex Definition Der Begriff Sicherheit umfasst die Gesamtheit der Ma nahmen die zur Verh tung wohldefinierter unerw nschter Ereignisse dienen deren Eintritt oder deren Eintrittsabfolge nicht voraussagbar sind und die zu einer Sch digung von Ressourcen f hren k nnen Die zu betrachtenden Ereignisse die man auch als Unw gba
11. 7 INTEGRIT TSVERIFIZIERUNG VON ZERTIFIKATEN 00008998888 27 8 ZERTIFIKATSSPEICHER IN NETSCAPE SICHERHEITSEINRICHTUNGEN 2 966 999 34 ABB 9 SSE PROTOKOLESTAREL 5 35 10 SSL HANDSHAKE CLIENT UND 0 36 11 SSL HANDSHAKE CLIENTSEITIGE 5 5 5 0 37 12 551 2 58 1 29 38 13 551 SCHREIB UND 755 000000090998 38 14 SSL HANDSHAKE SERVER VERIFY 1 2 2 39 15 SSL HANDSHAKE SERVER VERIFY 2 2 2 39 16 SSL HANDSHAKE REQUEST CERTIFICATE 40 17 SSL HANDSHAKE CLIENT CERTIFICATE 1 3 40 18 SSL HANDSHAKE CLIENT CERTIFICATE 2 3 29 41 19 SSL HANDSHAKE CLIENT CERTIFICATE 3 3 2 41 20 155 AUFBAU 55 0040001 43
12. hitektur Berecht isierungsarc Autor Abb 23 67 Autorisierung 4 2 2 Die Definition von Berechtigungen Innerhalb der Autorisierungsarchitektur erfolgt die Definition von Berechtigungen teilweise programmatisch und teilweise deklarativ Dies soll nun n her erl utert werden 4 2 2 1 Programmatische Definition der Berechtigungen In Abschnitt 4 2 1 ist von elementaren Berechtigungen gesprochen worden die durch Instanzen eines Berechtigungstyps verk rpert werden Jeder Berechtigungstyp implementiert die Methode check auf eine f r ihn charakteristische Weise wobei typischerweise ein Vergleich zwischen den Berechtigungsattributen die die Berechtigung bei einem Initialisierungsvorgang w hrend der Instanziierung erh lt und Eigenschaften die dem Ausf hrungskontext entnommen werden stattfindet Jeder Berechtigungstyp hat hierbei eine f r ihn typische Pr faufgabe durchzuf hren Typische Pr faufgaben sind die Pr fung ob es sich bei dem Benutzer um eine bestimmte Person handelt ob der Benutzer Mitglied in einer festgelegten Gruppe ist etc Abb 24 zeigt die in dieser Arbeit festgelegten subjektbasierten Berechtigungstypen Sie dienen als Beispiel um die programmatische Festlegung von Berechtigungen zu erl utern Neben den genannten Berechtigungstypen findet man in der Abbildung das Personen Gruppen sowie Rollenmodell der Plattform Architektur e Die personenbasierte Berechtigung PersonbasedAuthority pr
13. Sie umfassen zugleich die Analyse der Rahmenbedingungen die durch den infoAsset Broker gegeben sind Schlie lich werden f r die Integration der Sicherheitskonzepte Technologien verwendet die ebenfalls innerhalb dieses Kapitels beschrieben werden Kap 3 widmet sich der Integration der Sicherheitskonzepte Vertraulichkeit Integrit t und Authentisierung Die Behandlung von drei Sicherheitskonzepten innerhalb eines einzigen Kapitels wird durch die Art der Umsetzung bedingt Stark vereinfacht geht es hier um die Integration eines Secure Web Servers mit Client Authentisierung Als Schl sseltechnologie ist hier die Anwendung des SSL Protokolls zu nennen Kap 4 widmet sich der Integration des Sicherheitskonzeptes Autorisierung Innerhalb dieses Kapitels kommt es weniger darauf an bestehende Technologien in die Architektur des infoAsset Broker zu integrieren Vielmehr wird hier anhand des Autorisierungsbegriffs festgelegt welche sch tzenswerte Ressourcen vorhanden sind und durch welche Mittel diese gesch tzt werden sollen Kap 5 fasst schlie lich die Ergebnisse dieser Arbeit zusammen und gibt einen Ausblick auf erkannte M glichkeiten zur Erweiterung und Verbesserung der hier erarbeiteten Sicherheitsarchitektur 1 3 Danksagung Diese Arbeit ist im Rahmen einer Diplomarbeit im Arbeitsbereich Softwaresysteme der Technischen Universit t Hamburg Harburg entstanden Ich danke allen Angeh rigen dieses Arbeitsbereichs die ich w hrend meiner A
14. bertr gt den Hashwert zum Server Der Server f hrt den analogen Vorgang serverseitig durch und vergleicht die beiden Hashwerte Sind beide Hashwerte identisch so kennt der Benutzer das erforderliche Passwort und ist somit authentisiert Eine Kompromittierung des Passworts kann nicht stattfinden da nicht das Passwort sondern ein Hashwert bertragen wird Die R ckgewinnung der zumindest wenn man extreme Ausnahmen wie eineiige Zwillinge ausklammert 10 z B durch die Verwendung einer Hashfunktion je Nonce number once TUHH AB Softwaresysteme 17 Grundlagen Quellinformation aus einem Hashwert ist so gut wie unm glich da es sich bei Hashfunktionen um sog Einwegfunktionen handelt Auch ein Replay Attack ist ausgeschlossen da der Server f r jeden Anmeldevorgang ein neues Nonce verwendet Ein Angreifer m sste somit auf genau das Nonce warten welches dem von ihm gelauschten Hashwert zugrunde liegt Die Wahrscheinlichkeit eines Replay Attacks ist umso n her an der Null je gr er der Zahlenraum ist aus dem das Nonce stammt 1 Nonce Client Server 2 Clientwert 5 Nonce PWD 4 Serverwert 5 PWD Anmerkung MDS5 ist die hier verwendete Hashfunktion 5 Serverwert Clientwert Authentisierung Abb 3 Challenge Response Protokoll Hashfunktion MD5 Das Challenge Response Protokoll stellt eine L sung f r die Verifizierung der Kenntnis eines Passworts ber einen nicht vert
15. 2 3 4 1 Der Protokollstapel eine statische Betrachtung In diesem Abschnitt soll das SSL Protokoll zun chst aus statischer Sicht betrachtet werden um es in Hinblick auf eine Internetsicherheitsarchitektur einzuordnen SSL TLS Abb 9 SSL Protokollstapel Abb 9 zeigt das SSL Protokoll zwischen den TCP IP Schichten und den jeweiligen Internetanwendungsprotokollen Das SSL Protokoll wurde vom Browserhersteller Netscape entwickelt und hat sich als defacto Standard f r Kommunikationssicherheit im Internet etabliert Die aktuelle Version ist SSLv3 Nach der bernahme des Standards durch die IETF wurde SSL in Transport Layer Security TLS umbenannt Die aktuelle Version TLSv1 ist weitestgehend mit SSLv3 identisch Wie erw hnt dient SSL zur Bereitstellung von Kommunikationssicherheit Dies impliziert die in 2 1 2 3 und 2 1 2 4 erl uterten Sicherheitskonzepte Vertraulichkeit und Integrit t der kommunizierten Daten Zus tzlich besteht die M glichkeit das Konzept Authentisierung s 2 1 2 1 mit Hilfe von SSL umzusetzen Die Vielzahl der von SSL umgesetzten Konzepte verdeutlicht die zentrale Bedeutung dieser Technologie f r diese Arbeit Um die genannte Funktionalit t bereitzustellen bedient sich SSL der Einweg Hashfunktionen der symmetrischen und asymmetrischen Kryptographie und der digitalen Zertifikatsarchitektur Dies wiederum stellt den Bezug zu zuvor erl uterten Technologien her Das SSL Protokoll arbeitet hierbei transpa
16. String Dieser Parameter enth lt das Passwort das zum Schutz der Integrit t der Keystore Datei verwendet wird Dieses Passwort sch tzt gleichzeitig auch die Verwendung des in dieser Datei enthaltenen privaten Schl ssels Gem der JSSE Konvention f r die Nutzung des Standard SSLContextes m ssen diese beiden Passw rter identisch sein Bei Keystores die zu einem anderen Zweck verwendet werden muss dies nat rlich nicht so sein truststorePath String Dies ist der vollst ndige Name der Truststore Datei die der betreffende SSL Server verwenden soll Eine Truststore Datei ist die Keystore Datei die ausschlie lich die vertrauensw rdigen Stammzertifikate enth lt die der betreffende Server verwenden soll Ihre Eintr ge dienen somit zur Client Authentisierung Aufgrund der Tatsache dass der Client Zertifikate mit unterschiedlichen Richtlinien verwenden kann kann mit Hilfe der im Truststore installierten Zertifikate eine Unterscheidung der Authentisierungsg te vorgenommen werden F r den Fall dass der SSL Server keine Client Authentisierung via SSL Handshake erfordert kann dieser Parameter auch null sein 99 vgl 01 SSL and HTTPS Keystores and Truststores TUHH AB Softwaresysteme 53 Vertraulichkeit Integrit t und Authentisierung truststoreType String siehe keystoreType angewandt auf Truststore Datei truststorePassword String siehe keystorePassword angewandt auf Truststor
17. Vertraulichkeit Integrit t und Authentisierung 3 3 Details der Implementierung Im vorangegangenen Abschnitt ist die SWS Architektur ausf hrlich erl utert worden ohne jedoch auf die L sung sehr spezieller Probleme in diesem Kontext einzugehen Aufgrund dessen ist u a bisher die Beschreibung der Funktionalit t von vier Klassen des Packages de infoasset broker security ssi in dem sich die Klassen der SWS Architektur befinden ausgeblieben Die speziellen Probleml sungen und die Aufgaben der verbleibenden Klassen sollen in diesem Abschnitt n her beschrieben werden 3 3 1 Dynamische Link Erzeugung und JavaScript In Abschnitt 3 2 ist auf die serverseitige Architektur der SSL Server auf ihre Konfiguration ihre Generierung und auf die Weise wie Anfragen beantwortet werden ausf hrlich eingegangen worden Die Frage wie von einer ungesicherten zu einer gesicherten SSL Verbindung gewechselt wird ist zun chst ausgeklammert worden Die Beantwortung dieser Frage erscheint zwar trivial ist in der programmiertechnischen Praxis allerdings eine erhebliche H rde Um die Problematik zu verstehen sind das Erkennen clientseitiger Eigenschaften und deren Zusammenwirken erforderlich Die erste Eigenschaft betrifft das clientseitige Layout welches mit Hilfe von Frames strukturiert ist Die Nutzung von Frames tritt h ufig auf Der Kerngedanke hierbei ist dass h ufig nur einzelne Ausschnitte der Darstellung ge ndert werden sollen
18. dem Durchf hren des sicheren Verbindungsaufbaus nicht angemeldet gewesen ist und somit keine wichtigen Aktivit ten durchgef hrt haben kann Der Programmcode der Funktion SSLLogin befindet sich zun chst im Template de home default htm kann allerdings sp ter in eine entsprechende JavaScript Datei z B content js ausgelagert werden Die HTML Seite die aus diesem Template generiert wird wird beim Aufrufen des Portals zu Beginn angezeigt Aufgrund dessen bietet sich dieses Template f r den Einbau der dynamischen Verkn pfungen an Der Handler der dieses Template instanziiert ist de infoasset broker handler myportal WelcomeHandler Das Template enth lt somit die Platzhalter die in Abh ngigkeit der Programmlogik des Handlers die entsprechenden Verkn pfungen f r den Aufbau einer sicheren Verbindung generieren Da dieser Sachverhalt etwas komplex ist wird dieser Template Code hier aufgef hrt um ihn zu erl utern isNotLoggedIn 1 lt tr gt lt td gt lt b gt Anmeldung lt b gt lt td gt lt td gt lt td gt lt tr gt S sslServers 55 lt tr align left valign baseline gt lt td gt lt img src skin images bullet gif gt lt a href javascript SSLLogin s sslLoginPage s sslPort gt Anmelden lt a gt 3 lt td gt lt td gt s sslLoginComment lt td gt lt tr gt sslServers lt tr align left valign baseline gt lt td gt lt td gt lt td gt lt p gt Zur Zeit ist leider kein SSL Server
19. jeweiligen Projektverzeichnis befindet In dieser Datei werden die relativen Verkn pfungen die i d R vom Typ Kategorie Aktion bzw Kategorie sind auf vollst ndige Java Klassennamen inkl Package Pfad abgebildet Hierbei muss die spezifizierte Klasse ein Handler sein was technisch bedeutet dass die benannte Klasse eine Spezialisierung der Klasse GenericHandler sein muss Ein solcher Handler muss eine Methode namens handleRequest implementieren Sie enth lt den Programmcode mit der Anwendungslogik der serverseitig ausgef hrt wird wenn eine Verkn pfung clientseitig aufgerufen wird Eine weitere Besonderheit existiert in diesem Kontext da die Architektur der Portalplattform vorsieht dass Projekte aufeinander aufbauen k nnen Als Grundprojekt ist hierbei stets das Basisprojekt Broker zu sehen das bereits eine F lle von Standardfunktionalit t f r Unternehmensportale bereitstellt Die Architektur sieht vor dass jedes Projekt eine eigene handler txt Datei im jeweiligen Projektverzeichnis enth lt Zuordnungen von Verkn pfungen zu Anwendungslogik werden somit auf jeder Projektebene definiert bzw redefiniert Hierbei haben Zuordnungen auf h herer Projektebene Priorit t gegen ber den zugrunde liegenden Projekten Die Zuordnungen im Basis Projektverzeichnis Broker greifen somit erst wenn auf keiner der bergeordneten Projektebenen eine Zuordnung getroffen worden ist Dies sind die verschiedenen Sichten auf d
20. welche digitalen Handlungen von Teilnenmer B mit dem korrespondierenden privaten Schl ssel vorgenommen worden sind Die Aussagekraft der Verifikationen und der Nachweise wird hierbei durch die Zertifizierungsrichtlinie bestimmt Wie aus dem vorangegangenen Abschnitt hervorgeht wird die Zertifikatsintegrit t mit dem betreffenden ffentlichen Schl ssel der CA festgestellt Letztlich handelt es sich somit um die Verifikation der digitalen Handlung eines speziellen Teilnehmers n mlich die der CA Um dieses Problem zu l sen sind digitale Zertifikate eingef hrt worden Es hat somit den Anschein dass die L sung des Problems das Problem selbst zur Folge hat Dies ist in gewissen Grenzen richtig Der ffentliche Schl ssel einer CA bzgl einer definierten Zertifizierungsrichtlinie wird ebenfalls in Form eines digitalen Zertifikats ver ffentlicht Die Integrit t dieses Zertifikats ist folglich mit dem ffentlichen Schl ssel des Ausstellerss des CA Zertifikats berpr fbar dieser ffentliche Schl ssel befindet sich wiederum in einem Zertifikat usw Auf diese Weise erh lt man ein hierarchisch strukturiertes Zertifizierungssystem in dem wenige CA Zertifikate viele Teilnehmerzertifikate akkreditieren Dies ist eines der wesentlichen Merkmale eines Systems das auf digitalen Zertifikaten beruht und das unter dem Sammelbegriff public key infrastructure zusammengefasst wird Das beschriebene Verfahren zeigt wie man Integrit tsschlussf
21. 2 2 ist bereits erl utert worden dass die Zielplattform serverseitig aus einem javabasierten Application Server besteht In Abschnitt 2 3 4 3 wird dar ber hinaus die wesentliche M glichkeit f r die Implementierung des SSL Protokolls in Java erl utert die Nutzung der Java Secure Socket Extension JSSE 5 2 3 4 3 Innerhalb der JSSE wird u a mit dem Zweck der gegenseitigen Authentisierung auf Zertifikate zur ckgegriffen Der zu diesem Zweck in Java bereitgestellte Speichermechanismus soll deshalb in diesem Abschnitt dargestellt werden Zertifikatsspeicher werden in Java als sog Keystores bereitgestellt Hierbei sind zwei wesentliche Umgangsformen mit Keystores zu nennen administrativ und programmatisch F r den administrativen Umgang werden Keystores blicherweise als Keystore Dateien gehalten Diese werden mit einem eigenst ndigen Programm namens keytool verwaltet das im Verzeichnis java_home bin des J2SDK zu finden ist Programmatisch werden Keystores durch die Klasse java security KeyStore verk rpert Diese k nnen durch das Laden aus einer Keystore Datei instanziiert werden Selbstverst ndlich ist auch das Sichern einer KeyStore Instanz in eine Datei m glich Die Klasse KeyStore ist eine Engine Klasse s JSA Engine Klassen definieren eine API f r eine Softwarekomponente so dass verschiedene Implementierungen f r die jeweilige Komponente existieren k nnen Die J2SDK v1 4 stellt f r Keystores drei Implementierungen zur
22. 56 3 3 2 Die Anmeldefunktionalit t sirrcna te 59 3 3 3 Erkannie 62 3 4 ZUSAMMENF SSUNG 62 TUHH Softwaresysteme iii Inhalts und Abbildungsverzeichnis 4 2 E T 63 4 1 KONZEPTION a ee 63 41 1 _ Anforderungen nee en 64 4 2 ENTWURF DER AUTORISIERUNGSARCHITEKTUR 66 4 2 1 Berechlig ng urn au ie reset 66 4 2 2 Die Definition von 68 42 2 1 Programmatische Definition der Berechtigungen 68 42 2 2 Deklarative Definition der Berechtigungen 70 4 2 3 Die Zuordnung von Berechtigungen zu Handlern 71 4 2 3 1 Hachlicher Entw rt ame anti iin 71 4 2 3 2 Technischer Entwurf
23. Chiffrierverfahren Vor und Nachteile besitzen Aus diesem Grund werden sie wie bereits angedeutet in unterschiedlichen Weisen angewandt Die symmetrische Chiffrierung eignet sich aufgrund ihrer hohen Performanz gut f r die Wahrung der Vertraulichkeit zwischen zwei Kommunikationspartnern w hrend einer gesamten Sitzung Der geheime Sitzungsschl ssel der f r eine solche Kommunikation erforderlich ist wird unter Zuhilfenahme eines asymmetrischen Verfahrens vereinbart Da dieser Vorgang einmalig f r jede Sitzung ist spielt die Frage nach der Performanz eine unerhebliche Rolle Diese Strategie wird vom SSL Protokoll umgesetzt auf das weiter unten eingegangen werden soll 2 3 3 Digitale Zertifikate Genau wie die Kryptographie bilden auch digitale Zertifikate eine wichtige Grundlage dieser Arbeit Digitale Zertifikate nutzen die Kryptographie um ihren Zweck zu erf llen Hierbei kommt insbesondere die asymmetrische Kryptographie zum Einsatz In den folgenden Abschnitten werden die zentralen Konzepte im Zusammenhang mit digitalen Zertifikaten pr sentiert der wichtigste Zertifikatsstandard eingef hrt und die f r diese Arbeit besonders wichtigen Zertifikatsspeicher erl utert 17 01 TCTrust FNMT Global DPSign TUHH AB Softwaresysteme 25 Grundlagen 2 3 3 1 Konzepte Digitale Zertifikate sind elektronische Artefakte die das elektronische Pendant zu Ausweisen bilden Ihre wichtigste Aufgabe ist es eine digit
24. Hilfe des Ger te Managers vgl 2 3 3 4 Nach diesem Installationsschritt sind ein Generieren eines asymmetrischen Schl sselpaares auf der Karte und das Ausstellen des korrespondierenden Zertifikates durch eine webbasierte CA m glich F r diese Arbeit wurde zu Testzwecken ein Zertifikat der Fa TC TrustCenter AG www trustcenter de der Klasse 1 auf der SmartCard installiert Um die erarbeitete Sicherheitsarchitektur zu testen ist diese Wahl absolut hinreichend gewesen F r ein Anwendungsszenario ist nat rlich zus tzlich die Frage nach der richtigen Zertifikatsquelle und der richtigen Zertifizierungsrichtlinie zu kl ren 46 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform 3 Vertraulichkeit Integrit t und Authentisierung In diesem Kapitel werden s mtliche Ausf hrungen zu der Umsetzung der Sicherheitskonzepte Vertraulichkeit Integrit t und Authentisierung erl utert Die Tatsache dass drei wichtige Sicherheitskonzepte innerhalb eines einzigen Kapitels abgearbeitet werden h ngt mit der Art ihrer technischen Umsetzung zusammen In diesem Kapitel wird zun chst auf konzeptioneller Ebene erl utert wie die genannten Sicherheitskonzepte der Portalplattform umgesetzt werden Hierbei wird auf die Grundlagen des Kap 2 zur ckgegriffen Im Anschluss wird erl utert welche berlegungen beim Entwurf ma geblich gewesen sind um abschlie end auf s mtliche Detaill sungen der
25. Implementierung einzugehen 3 1 Konzepte zur Umsetzung beim infoAsset Broker Wie bereits in der Darstellung der Zielplattform vgl 2 2 erl utert worden ist handelt es sich hierbei um eine internetbasierte Client Server Architektur bei der es sich serverseiig um einen javabasierten Application Server und clientseitig um handels bliche Web Browser handelt Der wichtigste Standard um bei einer solchen Architektur die obigen Sicherheitskonzepte umzusetzen ist die Nutzung des SSL Protokolls Wie in Abschnitt 2 3 4 2 gezeigt worden ist setzt dieses Protokoll tats chlich die genannten Sicherheitskonzepte um so dass die Umsetzung durch die Wahl dieses L sungsansatzes einen gangbaren Weg darstellt Die wichtigste Begr ndung f r die Nutzung dieses Protokolls liegt in der breiten Unterst tzung durch markt bliche Web Browser Die Umsetzung eines solchen Standardprotokolls w rde blicherweise nicht eine solch umfangreiche Arbeit rechtfertigen da bereits fertige Module f r markt bliche Web Server existieren die das SSL Protokoll schl sselfertig bereitstellen Die Berechtigung f r diese Arbeit liegt in der Tatsache begr ndet dass der serverseitige Application Server eben keinen solchen Web Server nutzt Vielmehr ist der Web Server in den Application Server integriert so dass die Nutzung des SSL Protokolls die Auseinandersetzung mit der Architektur der Portalplattform erfordert Die Plattform infoAsset Broker ist in Java programmiert s
26. Kontext wird durch die Rahmenbedingungen vorgegeben die einerseits in typischen Internet Protokollen verankert sind und die andererseits durch die festgelegten Server bzw Client Applikationen bestimmt sind Hierbei bildet der Application Server der infoAsset Broker f r den die Sicherheitsarchitektur gebaut wird den Mittelpunkt der Betrachtungsweise an dem sich L sungsans tze und verwendete Technologien orientieren Als wesentlicher Ist Zustand zu Beginn dieser Arbeit ist eine sehr geringe Penetration von Sicherheitsaspekten in der infoAsset Broker Architektur zu konstatieren Eine in allgemeiner Weise formulierte Zielsetzung dieser Arbeit ist es diese Sicherheitsaspekte st rker in den Mittelpunkt zu r cken Geht man st rker in die Details so gilt es zun chst zu analysieren wo die Sicherheitsl cken d h die potentiellen Gefahren des Systems liegen Mittel zum Zweck sind innerhalb dieser Arbeit die Festlegung allgemein anerkannter Sicherheitskonzepte anhand derer der Versuch unternommen wird die Sicherheit des Systems anzuheben Im Ergebnis soll man hierdurch die Umsetzung von vier wichtigen Sicherheitskonzepten erhalten Vertraulichkeit und Integrit t der bertragenen Daten zwischen Client und Server eine differenzierte Authentisierung auf der Basis unterschiedlicher Authentisierungskonzepte und eine deklarative und erweiterbare Autorisierung festgelegter Prozesse Geht man ein wenig ber die spezielle Umsetzung der genannt
27. Neben den Gegebenheiten beim Broker die im vorangegangenen Abschnitt teilweise beschrieben worden sind haben beim Entwurf des Secure Web Server vier Kriterien eine tragende Rolle gespielt Erweiterbarkeit Kapselung Konfigurierbarkeit und Wartbarkeit In welcher Weise jedes dieser Kriterien einen Beitrag zu der Secure Web Server Architektur SWS Architektur geleistet hat soll zun chst kurz erl utert werden Das Kriterium Erweiterbarkeit ist unter dem Gesichtspunkt zu verstehen dass mehrere Secure Web Server nebeneinander f r einen Application Server koexistieren k nnen sollen Ein wichtiges Ziel dieser Ma nahme ist es dass unterschiedliche Authentisierungsstrategien erm glicht werden und dass nachtr glich neue Strategien innerhalb des Systems leicht umgesetzt werden k nnen So ist beispielsweise denkbar dass zuk nftig neue Sicherheitsger te zur Client Authentisierung genutzt werden sollen dass eigene Key oder Trust Manager implementiert werden sollen usw Zum Zwecke der Erweiterbarkeit existiert innerhalb der Java Security Architecture JSA das sog Engine Pattern Eine Engine Klasse repr sentiert eine H lle die von vielen m glichen Implementierungen ausgef llt werden kann Diese Implementierungen werden durch sog Provider bereitgestellt die leicht in der Laufzeitumgebung registriert werden k nnen In Kap 2 sind diese Engine Klassen bereits im Kontext der Klasse KeyStore und der Klasse SSLContext erw hnt worden Der in
28. SSLCertificateLoginHandler und SSLSmartCardLoginHandler Jeder dieser Handler f hrt am Ende der Anmeldeprozedur die Instanziierung eines Templates durch die jeweils nichts anderes tun als den clientseitigen Benutzer ber die erfolgreiche Anmeldung zu informieren und eine Umleitung auf die Seite home default htm einzuleiten Da zu diesem Zeitpunkt bereits das gesamte Frameset ber die gesicherte Verbindung geladen worden ist handelt es sich hierbei lediglich um den Austausch des Content Frames Nach dem Laden der Seite home default htm sind somit s mtliche Frames ber die gew hlte gesicherte Verbindung geladen und der Benutzer hat sich auf die von ihm gew nschte Weise gegen ber dem System authentisiert Im Einzelnen sind die SSLxxxLoginHandler sehr hnlich Weil serverseitig nur das Zertifikat aber nicht dessen Herkunft d h die clientseitig verwendete Sicherheitseinrichtung des Browsers gepr ft werden kann sind die Handler SSLCertificateLoginHandler und SSLSmartCardLoginHandler sogar fast identisch Eine Trennung der Programmlogik ist insofern trotzdem gerechtfertigt als dass in dieser Arbeit keine endg ltige Entscheidung bzgl des Unterscheidungskriteriums der Zertifikate getroffen worden ist Die Unterscheidung beruht zun chst allein auf dem vom jeweiligen SSL Server verwendeten Truststore siehe auch Exkurs Grob l sst sich der Ablauf in den SSLxxxLoginHandlern in vier Abschnitte gliedern Verifizierung der Anmeldeannahmen di
29. Server konfiguriert sind wird dies dem Benutzer durch einfache Ausgabe mitgeteilt Wie unschwer zu erkennen sein d rfte bildet der Listenplatzhalter ss LoginPage 3 innerhalb der Funktion SSLLogin ssITarget das Ziel welches innerhalb des Content Frames geladen wird Der Listenplatzhalter ssILoginPage spezifiziert somit den f r die Anmeldeprozedur verwendeten Handler Diese relative Adressierung wird bei der Instanziierung der Verkn pfung dem jeweiligen Konfigurationsobjekt eines SSL Servers entnommen Die Instanziierung des Templates erfolgt wie erw hnt durch den WelcomeHandler Hier ist Programmcode f r die Bearbeitung des ConditionalTemplates isNotLoggedIn und f r das ListTemplate ssIServers hinzugef gt worden Innerhalb des ListTemplates wird ber die vorhandenen Konfigurationsobjekte f r SSL Server iteriert und hieraus die drei ben tigten Parameter entnommen so dass tats chlich nur Verkn pfungen f r existente Konfigurationen generiert werden Der hierf r erforderliche Programmcode folgt der Konvention der Portalplattform bei der Instanziierung von ConditionalTemplates und ListTemplates so dass hier keine Besonderheiten vorhanden sind Aus diesem Grund wird dieser Code nicht weiter erl utert 3 3 2 Die Anmeldefunktionalit t Im vorangegangenen Abschnitt ist erl utert worden wie clientseitig der Wechsel zu einer gesicherten Verbindung eingeleitet wird In diesem Abschnitt wird der Schwerpunkt auf die in diesem Kont
30. Verf gung Java KeyStore JKS JCE KeyStore JCEKS und PKCS 12 Auf die letzte Implementierung kann allerdings nur lesend zugegriffen werden Unabh ngig von der betreffenden Umgangsform haben Keystores die Datenstruktur eines Dictionaries d h dass auf die in einem Keystore abgelegten Eintr ge ber ein Schl sselobjekt zugegriffen wird Bei Keystores sind die Schl sselobjekte einfache Namen vom Typ String Sie werden als Alias bezeichnet Die Eintr ge werden in zwei Kategorien gegliedert Schl sseleintr ge key entries und Zertifikatseintr ge certificate entries Key entries enthalten Schl ssel geheime symmetrische Schl ssel oder private asymmetrische Schl ssel Bei einem asymmetrischen Schl ssel enth lt der Eintrag zus tzlich das korrelierte ffentliche Zertifikat bzw eine ganze Kette ffentlicher Zertifikate an dessen Anfang das korrelierte ffentliche Zertifikat steht und dem die jeweiligen CA Zertifikate folgen Certificate entries hingegen enthalten lediglich ein einzelnes ffentliches Zertifikat ohne den korrelierten privaten Schl ssel 32 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Die Zertifikate die als key entries oder als certificate entries gehalten werden haben hierbei unterschiedliche Aufgaben Bei den Zertifikaten die als key entries gehalten werden handelt es sich um eigene Zertifikate die dazu dienen eigene digitale Handlungen zu verrichte
31. Weise nach dem Initialisierungsvorgang vor unerw nschten Ver nderungen gesch tzt 4 4 Zusammenfassung Innerhalb dieses Kapitels ist die Autorisierungsarchitektur erarbeitet worden Hierbei sind zun chst die Handler die die implementierten Prozesse der Portalplattform verk rpern als sch tzenswerte Ressourcen identifiziert worden Im Anschluss ist auf die Repr sentation der Zugriffsrechte durch deklarative Pr dikate und auf ihre programmatische Umsetzung durch Berechtigungen eingegangen worden Die deklarative Kombinierbarkeit von Pr dikaten und die programmatische Erweiterbarkeit durch neue Berechtigungstypen ist dabei ausf hrlich beschrieben worden Auch auf die Abl ufe w hrend eines Pr fvorgangs ist eingegangen worden Abschlie end ist die technische Umsetzung der Initialisierung von Berechtigungen erkl rt worden TUHH AB Softwaresysteme 81 Eine Sicherheitsarchitektur f r eine Informationssystem Plattform 5 Zusammenfassung und Ausblick 5 1 Zusammenfassung Diese Arbeit zeigt die Integration verschiedener Sicherheitskonzepte in die Portalplattform infoAsset Broker Es sind konkret zwei Komponenten implementiert worden n mlich die SWS und die Autorisierungsarchitektur die insgesamt vier verschiedene Sicherheitskonzepte umsetzen Vertraulichkeit und Integrit t der bertragenen Daten Authentisierung der Kommunikationspartner und Autorisierung beim Aufruf implementierter Prozesse Weitere Sicherheitskonzepte die Beac
32. definiert diese den IT Ressourcen zugeordnet und beim Zugriff auf letztere gepr ft werden Definition Der Begriff Autorisierung umfasst s mtliche Ma nahmen die zur Definition Zuordnung und Auswertung von Zugriffsrechten auf IT Ressourcen dienen 2 1 2 3 Vertraulichkeit Im weitesten Sinne bedeutet der Begriff Vertraulichkeit dass der Informationsgehalt eines Informationstr gers nur einer eingeschr nkten autorisierten Gemeinde TUHH AB Softwaresysteme 7 Grundlagen zug nglich sein soll Bei der bertragung einer Information ber das Internet wird immanent die aus den beiden Kommunikationspartnern bestehende Gemeinde verstanden Wird beispielsweise von der Vertraulichkeit der auf einem Server liegenden Information gesprochen so betrifft diese Fragestellung vordergr ndig die Autorisierung da hier zun chst ber das Zugriffsrecht auf die Information entschieden werden muss Gemeint ist also diejenige Vertraulichkeit die bei der bertragung der Information zwischen den Kommunikationspartnern gew hrleistet sein soll Die Natur des Internets bedingt zun chst dass die bertragene Information ohne gro e Schwierigkeiten einer F lle von Teilnehmern bekannt werden kann Dies liegt darin begr ndet dass die Vermittlung im Internet paketorientiert geschieht Die bertragenen Pakete k nnen von den Knoten die diese Pakete weiterleiten eingesehen werden obwohl die enthaltene Information nur von dem Endempf n
33. der Kodierung ist aus www freesoft org CIE RFC 2065 56 htm entnommen Exkurs Die clientseitig verwendete Sicherheitseinrichtung spielt eine wichtige Rolle bei der Bewertung der Authentisierungsg te Wie bereits erw hnt kann aufgrund der Gegebenheiten beim SSL Handshake serverseitig allerdings lediglich das Zertifikat aber nicht seine Herkunft gepr ft werden Obwohl eine Unterscheidung durch die entsprechende Konfiguration des serverseitigen Truststores vertrauensw rdige Stammzertifikate vorgenommen werden kann ist eine andere M glichkeit X 509 Extensions Zertifikatsmerkmale als Unterscheidungskriterium zu verwenden Die besonderen Merkmale eines Zertifikats k nnten dann ein Charakteristikum einer besonderen Sicherheitseinrichtung sein und sie k nnten innerhalb des betreffenden Handlers im Verbindungsaufbau nachgelagerte Pr fung oder in einem eigenen TrustManager im Verbindungsaufbau vorgelagerte Pr fung vgl 2 3 4 3 verifiziert werden Die Integrit t dieser Zertifikatsmerkmale ist dabei genauso gesichert wie die brige Information innerhalb des Zertifikats n mlich durch die Signatur des Ausstellers TUHH AB Softwaresysteme 61 Vertraulichkeit Integrit t und Authentisierung 3 3 3 Erkannte L sungsdefizite In diesem Abschnitt soll kurz auf identifizierte Probleme eingegangen werden die im Zusammenhang mit der SWS Architektur auftreten und im Rahmen dieser Arbeit nicht gel st worden sind 1 For
34. dikate anzunehmen w re Au erdem kann man nicht davon ausgehen dass die 78 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Pr dikate in der authorities txt stets richtig sortiert sind Dies hat zur Folge dass zum Zeitpunkt in dem die Logik eines zusammengesetzten Berechtigungsausdrucks analysiert wird nicht notwendig alle enthaltenen Pr dikate zu Berechtigungen instanziiert worden sind so dass hierf r eine Zwischenspeicherung und eine Abarbeitungsreihenfolge erforderlich ist Dies wird auf die bereits beschriebene Weise erreicht Im Ergebnis hat man am Ende der Methode readAuthoritiesFromFile alle elementaren Pr dikate zu Berechtigungen instanziiert und f r jeden zusammengesetzten Berechtigungsausdruck ein AuthorityTree Objekt instanziiert Am Ende dieser Methode wird somit eine weitere Methode aufgerufen die das Instanziieren der zusammengesetzten Berechtigungen durchf hrt createComposedAuthorities Die Methode l uft in einer Endlosschleife solange die AuthoritiesTreeCollection nicht leer ist d h solange nicht alle zusammengesetzten Berechtigungen instanziiert sind Innerhalb der Iteration findet zun chst ein Sortiervorgang statt durch den sichergestellt wird dass sich am Anfang der Collection stets ein Ausdruck befindet dessen verwendeten Pr dikate bereits alle zu Berechtigungen instanziiert worden sind Hierdurch kann stets das erste Element ein AuthorityTree aus der
35. ein unterschiedliches Ma an Sicherheit erforderlich sein Diese Unterschiede k nnen durch unterschiedliche Sicherheitsrichtlinien ausgedr ckt sein In diesem Zusammenhang ist hervorzuheben dass durch die Festlegung von Sicherheitsrichtlinien die Benutzer eines technischen Systems f r das bestimmte Sicherheitsma nahmen implementiert werden in dieses System mit einbezogen werden und die durch sie denkbar auszuf hrende Handlungen durch die Sicherheitsrichtlinien eingeschr nkt werden Im Allgemeinen l sst sich somit sagen dass der Faktor Mensch im Umgang mit der Technik durch Sicherheitsrichtlinien Ber cksichtigung findet Ein einfaches Beispiel f r die Einbeziehung des jeweiligen Benutzers in das System ist das Verbot zur Weitergabe von Passw rtern PINs SmartCards etc an Dritte damit diese anstelle des Benutzers die jeweilige Handlung durchf hren k nnen 2 1 3 Allgemeine Methodologie Die vorangegangenen Abschnitte betrachten Sicherheit berwiegend statisch Um ein System allerdings sicher zu machen sollte ein Prozess durchlaufen werden und dieser ggf iterativ um bei jeder Iteration neue Sicherheitsrisiken zu ber cksichtigen Ein wichtiger Schritt eines solchen Prozesses ist die Risikoanalyse In der Risikoanalyse wird zun chst untersucht welche Gefahren die einwandfreie Funktionsweise des Systems in Frage stellen Die erkannten Gefahren m ssen hierbei bewertet werden und es muss festgelegt werden wie hoch der zu erreic
36. eingegangen wird 5 Auf weitere denkbare Kategorien die f r diese Arbeit allerdings ohne Bedeutung sind wird kurz eingegangen 5 Auf digitale Zertifikate wird in einem eigenen Abschnitt n her eingegangen Br mme ehem Wissenschaftlicher Mitarbeiter der Universit t Hamburg 2001 TUHH AB Softwaresysteme 15 Grundlagen Wissensbasierte Authentisierung beruht auf der Tatsache dass ein Geheimnis zwischen der Seite die sich authentisieren m chte Seite A und der Seite die die Authentisierung anfordert Seite vorhanden ist Das Geheimnis wird von A nach bertragen wodurch B feststellt dass A Kenntnis des Geheimnisses hat Daraus folgert B dass A tats chlich A sein muss da ja nur A Kenntnis dieses Geheimnisses hat Typische Beispiele f r derartige Geheimnisse sind Passw rter Pers nliche Identifikations Nummern PINs Transaktions Aktivierungs Nummern 5 Antworten auf vorher festgelegte Fragen verteilte Geheimnisse shared secrets etc Einige der hier genannten Geheimnisse haben allerdings einen anderen Zweck als die Authentisierung wie dies bei TANs und verteilten Geheimnissen der Fall ist Dass diese Art der Authentisierung so weit verbreitet ist hat einen simplen Grund eine wissensbasierte Authentisierung ist mit wenig Aufwand umsetzbar Dies ist wohl die gr te St rke dieses Konzepts Auf der anderen Seite liegen die Schw chen auf der Hand Geheimnisse k nnen leicht weitergegeben oder
37. grundlegenden Projekten definiert worden sind k nnen auch auf h heren Projektebenen wieder verwendet werden Innerhalb einer authorities txt existieren zwei Arten von Definitionen Es werden zun chst diejenigen Pr dikate deklariert die auf elementaren Berechtigungen aufbauen Hierbei wird folgende allgemeing ltige Syntax verwendet Schl sselwort Parameter1 Parameter2 ParameterN voller Klassenname der Berechtigung Das Schl sselwort und die Art und Anzahl der einzutragenden Parameter werden durch die Berechtigungsklasse festgelegt Berechtigungstyp Es liegt in den H nden eines Entwicklers das Schl sselwort sowie die Art und Anzahl der Parameter festzulegen Ein typisches Beispiel f r die Deklaration eines elementaren Pr dikats w re isPerson perera tu harburg de de infoasset broker authorities PersonbasedAuthority Deklarierte elementare Pr dikate k nnen fortan verwendet werden Dies gilt insbesondere f r die Verwendung in der zweiten Art von Definitionen den zusammengesetzten Pr dikaten In diesen Definitionen wird ein beliebiger Pr dikatsname festgelegt dem ein boolscher Ausdruck zugeordnet wird Dieser Ausdruck besteht aus den boolschen Operationen NOT AND und OR die in genau dieser Schreibweise zu verwenden sind Innerhalb eines Ausdrucks hat die Operation NOT die h chste und die Operation OR die geringste Bindungsst rke Die Ausdr cke k nnen durch Klammerung mit den Klammern und beliebig v
38. im Besitz des zum Zertifikat zugeh rigen privaten Schl ssels ist ist er auch als einziger in der Lage das Chiffrat des Hauptsitzungsschl ssels zu dechiffrieren Der clientseitig erzeugte Hauptsitzungsschl ssel dient beiden Seiten zur Erzeugung von Schreib und Leseschl sseln s 5 TUHH AB Softwaresysteme 37 Grundlagen Hauptsitzungs schl ssel 4 Chiffrat Orn Client mit dem ffentlichen Schl ssel des Servers aus Server Anwendung Serverzertifikat entnommen asymmetrisch Anwendung z B Browser chiffrierter Hauptsitzungsschl ssel z B Secure Web Server Abb 12 SSL Handshake Hauptsitzungsschl ssel 5 Sitzungsschl sselerzeugung Der Client ermittelt aus dem erzeugten Hauptsitzungsschl ssel zwei Sitzungsschl ssel einen Schl ssel zum Schreiben ClientWriteKey und einen Schl ssel zum Lesen ClientReadKey Abb 13 Der Server dechiffriert zun chst das empfangene Chiffrat mit seinem privaten Schl ssel und ermittelt so den Hauptsitzungsschl ssel Anschlie end f hrt er die gleiche Prozedur wie der Client durch Auf diese Weise erzeugt er auch zwei Sitzungsschl ssel einen Schl ssel zum Lesen ServerReadKey und einen Schl ssel zum Schreiben ServerWriteKey Abb 13 Man beachte dass der ClientWriteKey und der ServerReadKey identisch sind symmetrische Verschl sselung Gleiches gilt f r den ClientReadKey und den ServerWriteKey Dechiffriervorgang nur der Zertifikatsinhaber Privater Sc
39. kompromittiert werden Ein hoher Standard bei den Sicherheitsrichtlinien s 2 1 2 6 und bei der Vertraulichkeit s 2 1 2 3 ist deshalb notwendig Besitzbasierte Authentisierung beruht auf der Tatsache dass die Seite die sich authentisieren m chte Seite A gegen ber einer anderen Seite Seite B im Besitz eines Gegenstandes oder Information ist wobei die jeweilige Nutzung die Authentisierung hervorruft Der wesentliche Unterschied zur wissensbasierten Authentisierung ist dass ein evtl bestehendes Geheimnis nicht zur Seite B bertragen wird Es wird vielmehr das Anwendungsergebnis des Geheimnisses bertragen In vielen F llen ist ein solches Geheimnis auch nicht einem Anwender der Seite A bekannt da es sich oft in einem Speicher befindet der nicht ohne weiteres eingesehen oder kopiert werden kann Typische Beispiele f r derartige Gegenst nde und Information sind der Zertifikatsspeicher eines Webbrowsers der eigene digitale Zertifikate und die jeweils korrelierten privaten Schl ssel enth lt der Zertifikatsspeicher einer SmartCard der die gleiche Funktion wie der des Webbrowsers erf llt mit der zus tzlichen Sicherheit dass die SmartCard dem System leicht entzogen und wieder hinzugef gt werden kann und dass der private Schl ssel auf einer SmartCard diese nicht verl sst etc Die wesentliche St rke der besitzbasierten Authentisierung liegt in der Tatsache begr ndet dass der zur Authentisierung erforderliche Gegenstand oder d
40. r lediglich zu vergleichen hat ob das aktuelle Datum mit Uhrzeit innerhalb der G ltigkeitsspanne liegt Komplexer kann dieser Vorgang durch ein Konzept werden das es erlaubt digitale Zertifikate vor Ablauf des Datums das das G ltigkeitsende bezeichnet f r ung ltig zu erkl ren Man bezeichnet diesen Vorgang der von der CA durchgef hrt wird die das digitale Zertifikat ausgestellt hat als Zertifikatswiderruf bzw Zertifikatsr cknahme certificate revocation Die M glichkeit Zertifikate widerrufen zu k nnen dient dazu die Sicherheit zus tzlich zu erh hen Hierdurch k nnen Zertifikate die beispielsweise missbr uchlich verwendet wurden deren Benutzer sich nicht an vereinbarte Vorgaben halten oder die einfach aus einem anderen Grund einzuziehen sind vorzeitig f r ung ltig erkl rt werden Die Umsetzung dieses Konzeptes erfolgt mit Hilfe von Listen in die die widerrufenen Zertifikate eingetragen sind Man spricht hierbei von Zertifikatswiderrufslisten bzw Zertifikatsr cknahmelisten certificate revocation list CRL In der Praxis sind in diesen Listen nicht die Zertifikate selbst sondern ihre jeweiligen Seriennummern eingetragen Dabei existiert f r jede Zertifizierungsrichtlinie einer bestimmten CA eine solche Widerrufsliste Die Zertifizierungsrichtlinie einer CA und eine Zertifikatsseriennummer sind ein eineindeutiges Merkmal eines digitalen Zertifikats so dass der Eintrag der Seriennummer in die CRL ausreichend ist um ein
41. rige private Schl ssel ist aus der ffentlichen Information nicht zu ermitteln Abb 15 SSL Handshake Server Verify 2 2 TUHH AB Softwaresysteme 39 Grundlagen Fazit 1 Die Vertraulichkeit der Kommunikation ist durch das geheime Schl sselpaar gew hrleistet Die Integrit t der Kommunikation ist durch die m gliche Bildung von Hashwerten gew hrleistet Die Authentizit t des Servers wird wie in 7 beschrieben geschlussfolgert 8 Request Certificate Ist der Server f r eine Client Authentisierung konfiguriert so schickt er dem Client chifffiert einen neuen Challenge String NeuerChallengeString Der Client antwortet mit einer Fehlermeldung falls er sich nicht authentisieren kann oder will Abb 16 8 ServerWriteKey NeuerChallengeString Fehler falls kein Zertifikat Client Server Anwendung Anwendung z B Browser z B Secure Web Server Abb 16 SSL Handshake Request Certificate 9 Client Certificate Schritt 1 Ist der Client in der Lage ein g ltiges Zertifikat vorzulegen so ermittelt dieser zun chst den neuen Challenge String Ferner ermittelt er einen Hashwert bestehend aus dem ermittelten neuem Challenge String und dem 2 empfangenem Serverzertifikat Diesen signiert der Client mit seinem privaten Schl ssel Man beachte dass durch das Einbringen des neuen Challenge Strings die Signatur des Hashwertes bei unterschiedlichen Sitzungen stets unterschiedliche Werte annimmt Neuer
42. so dass das Gesamtbild der Website einen einheitlichen Eindruck vermittelt Der am h ufigsten wechselnde Frame ist hierbei der sog Content Frame in dem die tats chlich abgerufene Nutzinformation dargestellt wird Hierbei wird die neu geladene HTML Seite innerhalb desselben Frames an Stelle der bisherigen HTML Seite dargestellt Die HTML Seiten der umliegenden Frames m ssen dabei nicht neu geladen werden Bei der Portalplattform funktioniert dies hnlich Der Aufruf einer Verkn pfung verursacht h ufig nur die Aktualisierung des Content Frames Um von einer ungesicherten auf eine gesicherte Verbindung zu wechseln ist der dargestellte Sachverhalt insofern problematisch als das man s mtliche Frames inkl Frameset komplett neu laden muss und hierbei auch den Wechsel der Protokollangabe https statt http und des Ports z B 443 statt 80 durchzuf hren hat Die L sung dieses Problems erscheint zun chst einfach Anstatt f r den Wechsel der Verbindung eine relative Verkn pfung zu verwenden benutzt man eine absolute Verkn pfung die das neu zu verwendende Protokoll und den neu zu verwendenden Port enth lt Zus tzlich gibt man als Ziel der Verkn pfung das oberste Frame des Browsers an so dass das gesamte Frameset neu geladen wird Leider werden in diesem Kontext allerdings weitere Probleme identifiziert Der Grund hierf r ist die Tatsache dass die Verkn pfungen in der Portalplattform keine Hyperlinks sind die eine URL enthalten sonder
43. so dass man zusammenfassend 48 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform sagen kann dass jeder WebServer Thread nichts anderes macht als auf seinem definierten Port zu lauschen und die eintreffende Anfrage durch die Erzeugung eines HttpConnection Objekts zu beantworten Die Behandlung der Ausnahmesituationen ist hier der Einfachheit halber nicht beschrieben worden Die Klasse HttpConnection ist eine Spezialisierung der Klasse Thread so dass innerhalb des WebServer Threads jede Anfrage innerhalb eines eben solchen HttpConnection Threads abgearbeitet wird Hierzu wird am Ende des HttpConnection Konstruktors die Methode start aufgerufen die wiederum dazu f hrt dass die Methode run aufgerufen wird Die Methode run leitet mit Hilfe des als Parameter empfangenen Sockets und der daran gebundenen Streams die Beantwortung der Anfrage ein Im Wesentlichen wird die Anfrage hierbei von der Methode processRequest beantwortet die von der Methode run aufgerufen wird Der HttpConnection Thread stirbt nach dem Beantworten der Anfrage f r die er verantwortlich ist Innerhalb der Methode processRequest wird die Antwort auf die Anfrage des Clients erstellt und bermittelt Sie ist verh ltnism ig umfangreich und komplex so dass hier nicht weiter auf sie eingegangen wird Dort wo es bei Detailfragen erforderlich ist wird auf sie erneut zur ckgekommen 3 2 2 Entwurf berlegungen und Kriterien
44. www BruceEckel com Bruce Eckel MindView Inc 2002 CrypTool PowerPoint Pr sentation www cryptool de Bernhard Esslinger et al Deutsche Bank 2002 F brica Nacional de Moneda y Timbre Real Casa de la Moneda www cert fnmt es Web Site f r e Government in Spanien Offizielle Root CA UML konzentriert Deutsche bersetzung Martin Fowler amp Kendall Scott Addison Wesley Longman Verlag GmbH 1998 GlobalSign NV SA www globalsign com Web Site Root CA SSL Secure Socket Layer Vorlesungszusammenfassung www tfh berlin de toby vs ssi Tobias G tz TFH Berlin 1999 Portal Verbund Whitepaper Rainer H rbe BMI 2002 Sicherheitstechnologien und konzepte f r Enterprise Portals Michael Holman SAP Portals www sap de enterpriseportals SAP AG 2001 infoAsset Broker Kurzschulung infoAsset AG www infoasset de 2000 The infoAsset Broker Technical White Paper infoAsset AG www infoasset de 2001 infoAsset Broker Documentation Together generated documentation 2001 Funktionen infoAsset Broker Excel Dokument infoAsset AG 2002 Der infoAsset Broker Software f r Wissensmanagement und Content Commerce Online Information infoAsset AG www infoasset de Produkte Java 2 SDK Standard Edition Version 1 4 1 Online Dokumentation java sun com Sun Microsystems Inc 2002 JavaScript Programmieranleitung Web Site js tut aardon de TUHH AB Softwaresysteme 87 Literatur und Quellenverz
45. 1 und der eine Portalplattform implementiert Diese Portalplattform die als infoAsset Broker kurz Broker bezeichnet wird ist ein Softwareprodukt der Fa infoAsset AG und stellt ein Framework f r den Aufbau von internetbasierten Unternehmensportalen dar Pr sentationsschicht Templates Handler Prozess Schicht Handler Sessions Abb 1 infoAsset Broker Schichten Beim infoAsset Broker sind Templates im Wesentlichen statische HTML Dokumente die Platzhalter enthalten und beim Abruf durch den Client im jeweiligen Kontext dynamisch ersetzt werden Hierbei existieren unterschiedliche Typen von Platzhaltern die unterschiedliche Aufgaben erf llen Variablen konditionale Platzhalter Listen etc Verkn pfungen innerhalb eines Dokuments werden durch einen mehrstufigen Mechanismus serverseitig auf Handler abgebildet Die Handler enthalten die jeweilige Anwendungslogik Sie rufen neue Handler auf ersetzen Platzhalter in Templates mit aktuellen Daten in Abh ngigkeit der jeweiligen Session und arbeiten auf den Gesch ftprozessobjekten Diese Gesch ftsprozessobjekte Business Objects die Assets genannt werden die persistent gemacht werden k nnen und auf die ber festgelegte Services zugegriffen wird werden durch vordefinierte Datenstrukturen festgelegt Viele in Anwendungen oft ben tigte Gesch ftsprozessobjekte z B Personen Gruppen Mitgliedschaften etc sind beim infoAsset Broker bereits vordefiniert Andere nicht vorha
46. 2 11 Cryptographic Token Security Inc www rsasecurity com 2001 mySAP Enterprise Portals Funktionen Rollen Sicherheit www sap com Deutschland L sungen mySAP Enterprise Portals SAP AG 2001 mySAP Technology Voraussetzung f r eine offene E Business Integration Ein berblick Version 1 0 SAP White Paper SAP AG 2002 mySAP Technology Portal Infrastruktur Benutzerorientierte Integration und Zusammenarbeit Version 1 1 SAP White Paper SAP AG 2002 mySAP Technology Sicherheit Sichere Gesch ftsabwicklung in offenen Umgebungen Version 1 1 SAP White Paper SAP AG 2002 sapinfo net _ NR 82 MAI 2001 Das SAP Magazin SAP AG 2001 Digitale Signatur und Smartcard im E Business mySAP Public Sector SAP AG 2001 Digitale Signaturen PowerPoint Competence Team SAP AG 2001 SmartCards Security and Integration G nter Stecker LOGICO Smartcard Solutions www smartcard solutions com 2002 Trustcenter AG www trustcenter de Web Site Root CA Interface Standard RSA Pr sentation SAP Security TUHH AB Softwaresysteme Utio2a Uti02b Veit00 VeriSign98 Wong00 Zim97 Eine Sicherheitsarchitektur f r eine Informationssystem Plattform SafeGuard Biometrics Version 1 60 Benutzerhandbuch des SmartCard Systems Utimaco Safeware AG www utimaco de 2002 Utimaco Whitepapers Utimaco Safeware AG www utimaco de 2002 Sicherheit im Internet Handout zum Vort
47. 22 51 TUHH AB Softwaresysteme Vertraulichkeit Integrit t und Authentisierung 3 2 3 Entwurf Die Gesamtarchitektur Die im vorangegangenen Abschnitt beschriebenen Kriterien bilden die Grundlage f r den in diesem Abschnitt vorgelegten Entwurf Der Entwurf der SWS Architektur enth lt einige wenige Hauptklassen die bereits im vorangegangenen Abschnitt z T erw hnt worden sind Diese sollen in diesem Abschnitt n her erl utert werden um den Aufbau der SWS Architektur zu verdeutlichen Alle weiteren Klassen die im Kontext der SWS Architektur stehen sind Hilfsklassen die sehr spezifische Aufgaben l sen Auf diese Hilfsklassen wird bei der Erl uterung der Implementierung eingegangen Sie sind in diesem Entwurf nicht enthalten Das Klassendiagramm des Entwurfs Abb 22 zeigt die Hauptklassen der implementierten SWS Architektur Mit Ausnahme der Handler die Spezialisierungen der Klasse GenericHandler sind sind alle dargestellten Klassen Bestandteil des Packages de infoasset broker security ssi Alle Handler der SWS Architektur sind konform mit der Package Hierarcchie des Brokers im Package de infoasset broker handler security enthalten Wie in Abschnitt 3 2 2 Kapselung dargestellt bildet die Klasse SSLWebServerFactory die Schnittstelle ber die die SWS Architektur von au en angesto en wird Ihre Hauptaufgabe ist die Verwaltung der konfigurierten SSL Server sowie die Funktionalit t bereitzustellen die s mtlich
48. 5 Kryptographie konzeptuelle Gliederung TUHH AB Softwaresysteme 23 Grundlagen 2 3 2 2 Symmetrische Kryptographie Bei einer symmetrischen Chiffrierung ist der Funktionsparameter Schl ssel der Verschl sselungsfunktion f r und Dechiffrierschritt identisch Die Chiffrierfunktion F bildet mit Hilfe des Schl ssels K einen Klartext X auf einen chiffrierten Text ab Dies bezeichnet man als Chiffrierschritt x y Die inverse Funktion F bildet mit Hilfe des gleichen Schl ssels den chiffrierten Text auf den Klartext X ab Dies bezeichnet man als Dechiffierschritt F X Eine gute Verschl sselungsfunktion F zeichnet sich dadurch aus dass eine Ermittlung des Klartextes X aus dem chiffrierten Text ohne Kenntnis des Schl ssels nicht ohne erheblichen Aufwand m glich ist im Idealfall ist die Ermittlung unm glich Dar ber hinaus sollten die Funktionswerte der Funktion F sowie ihrer Inversen F mit Kenntnis des Schl ssels K auf einfache Weise zu berechnen sein damit das Chiffrierverfahren performant ist Das Chiffrierverfahren wird durch die Funktion F charakterisiert wobei diese i d R bekannt ist Lediglich der Schl ssel K wird unter den Kommunikationsteilnehmern geheim gehalten Dies ist der Grund warum man im Kontext symmetrischer Kryptographie von geheimen Schl sseln secret key spricht Symmetrische Chiffrierverfahren werden i a zum vertraulichen Informationsausta
49. 73 4 2 4 Die Auswertung von 73 4 25 Die Gesamtarchitekt r s ununes isn aa ne nn In EINE Endes 74 4 3 DETAILS DER IMPLEMENTIERUNG 22 1 2 RER 76 4 3 1 Initialisierung der 76 4 4 ZUSAMMENFASSUNG nannte BR ER REEL SR 81 5 ZUSAMMENFASSUNG UND AUSBLICK 83 5 1 ZUSAMMENFASSUNG sr ES ERDE 83 5 2 AUSBLICK HR BEREIT RBB 83 5 2 1 Sicherheitskonzept 83 5 2 2 Authentisierung Verbesserungsvorschl ge 84 5 23 Autorisierung amp 5 85 LITERATUR UND QUELLENVERZEICHNIS sssssssossssossssonsssonnsssnnssnnsssnnnnsnnnnsnnnnssnnsssnnsnsnnnnsnnnnsnnnne 87 Abbildungsverzeichnis 1 INFOASSET BROKER 5 12 ABB 2 AUTHENTISIERUNGSDREIECK sr e 15 3 CHALLENGE RESPONSE PROTOKOLL HASHFUNKTION 18 4 AUTHENTISIERUNGSPROTOKOLL DIGITALEM ZERTIFIKAT 20 5 KRYPTOGRAPHIE KONZEPTUELLE 2 23 ABB 6 ELEKTRONISCHES ARTEFAKT DIGITALES ZERTIFIKAT 26
50. Begriff Key Material untergeordnet Soll der Server zus tzlich eine Client Authentisierung w hrend des SSL Handshakes durchf hren so ben tigt er zus tzlich die Angabe eines Zertifikatsspeichers das die vertrauensw rdigen Stammzertifikate enth lt Dies ist dem Begriff Trust Material untergeordnet In der vorliegenden Arbeit werden die betreffenden Zertifikatsspeicher durch Systemeigenschaften System Properties festgelegt Eine ausf hrliche Darstellung im Umgang mit der JSSE kann u a der Java Online Dokumentation entnommen werden J2Sun02 gt JSSE Reference Guide 2 3 5 SafeGuard Biometrics ein SmartCard Produkt der Fa Utimaco Safeware AG In diesem Abschnitt wird das eingesetzte SmartCard Produkt vorgestellt das im Rahmen dieser Arbeit verwendet wird 2 3 5 1 Produktauswahl Bei der Wahl des einzusetzenden kommerziellen Produktes sind die Hauptentscheidungskriterien e die M glichkeit das Produkt zur webbasierten Authentisierung einsetzen zu k nnen e die einfache Integrierbarkeit in das bestehende System zu erm glichen e und einen m glichst hohen Sicherheitsgrad zu erreichen Die Entscheidung ist aufgrund der von den jeweiligen Produktherstellern ver ffentlichten Produktbeschreibungen durchgef hrt worden Keines der Systeme hat vor der Entscheidung f r eine Eignungspr fung zur Verf gung gestanden In Anbetracht der relativ hohen Kosten f r jedes der betrachteten SmartCard Systeme und der Tatsache dass die
51. ChallengeString ClientReadKey ServerWriteKey NeuerChallengeString W ClientPrivateKey HASH NeuerChallengeString Serverzertifikat Client Anwendung z B Browser Abb 17 SSL Handshake Client Certificate 1 3 10 Client Certificate Schritt 2 Der Client schickt dem Server verschl sselt den signierten Hashwert und sein Clientzertifikat Abb 18 40 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform 10 ClientWriteKey 7 Clientzertifikat Client Server Anwendung Anwendung z B Browser z B Secure Web Server Abb 18 SSL Handshake Client Certificate 2 3 11 Client Certificate Schritt 3 Der Server ermittelt den signierten Hashwert und das Clientzertifikat aus dem empfangenen Chiffrat Er berpr ft die G ltigkeit des Zertifikats anhand des ffentlichen Schl ssels der CA siehe hierzu auch 3 Um sich zu vergewissern dass der Zertifikatsbesitzer Client auch tats chlich der Zertifikatsinhaber Instanz f r die das Zertifikat ausgestellt worden ist dechiffriert der Server die Signatur des Hashwertes mit dem ffentlichen Schl ssel aus dem Clientzertifikat und bildet seinerseits den Hashwert aus neuem Challenge String und Serverzertifikat Stimmen beide Werte berein schlussfolgert der Server die Authentizit t des Clients Abb 19 Man beachte dass im Gegensatz zum Server der Client die Kenntnis des zum vorgelegten Zertifikat zugeh rigen pri
52. Collection genommen und aus dieser gel scht werden und eine zusammengesetzte Berechtigung durch einfaches Abarbeiten der Struktur des bin ren Baumes generiert werden Da das Sortierkriterium sicherstellt dass zu jedem vorkommenden Pr dikat im bin ren Baum bereits eine Berechtigung existiert k nnen die entsprechenden Berechtigungen in die top down zu generierende zusammengesetzte Berechtigung eingetragen werden Diese Aufgabe wird von der Methode createComposedAuthority AuthorityTree tree innerhalb der Klasse Authority durchgef hrt Nachdem die zusammengesetzte Berechtigung instanziiert ist wird sie wie auch die elementaren Berechtigungen in die authorityNamesAndiInstances Hashtable eingetragen Da bei jeder Iteration ein Element aus der Collection entfernt wird wird die Schleife nach dem Instanziieren der letzten zusammengesetzten Berechtigung verlassen Kommt es w hrend der Instanziierung der zusammengesetzten Berechtigungen zu internen Fehlern so werden diese geloggt Nach dem Durchlaufen der Methode readAuthoritiesFromFile sind auf die beschriebene Weise alle Pr dikate der authorities txt einer Projektebene in entsprechende Berechtigungen berf hrt Die Hashtable authorityNamesAndiInstances akkumuliert dann s mtliche Pr dikate und ihre zugeordneten Berechtigungen ber mehrere Projektebenen hinweg so dass am Ende der Iteration ber die Projektebenen die Hashtable alle verwendbaren Pr dikate enth lt Damit ist die Umwandlung d
53. Integration des Systems in g ngige Browser die nur durch ein umfangreiches Ausprobieren zum Ziel f hrte Insbesondere das Speichern eines Zertifikats einer webbasierten CA ist mit au erordentlichen Schwierigkeiten behaftet gewesen Dar ber hinaus ist die mit dem Produkt mitgelieferte Software in Bezug auf Zertifikatsmanagement wenig hilfreich Abb 21 gibt einen schematischen berblick ber das SmartCard System Die Installation der beiden Treiber erfolgt nach dem Anschlie en des SmartCard Systems Im Anschluss k nnen die ben tigten Anwendungen installiert werden wobei die Enrollment Station und die SmartCard Provider f r diese Arbeit die wichtigste Rolle spielen Die Logon Extensions erm glichen dass sich ein Benutzer mit Hilfe der SmartCard an einem Computer anmelden kann Die SmartCard Administration stellt unter Windows administrative Funktionen f r die SmartCard zur Verf gung Beide zuletzt genannten Anwendungsmodule stehen nur unter Windows 2000 oder Windows XP zur Verf gung Anwendungssoftware SafeGuard Biometrics Logon Enrollment Smartcard Smartcard Extensions Station Administration Provider Treiber USB Kartenleser Precise Biometrics 100 SC SmartCard SafeGuard Biometric Smartcard Hardware Abb 21 SmartCard Architektur 34 yww utimaco de Produktbeschreibung SafeGuard Biometrics 35 Treiber Anwendungen und elektronisches Handbuch TUHH AB Softwaresysteme 45 Grundlagen Die Enrollment Sta
54. Integration eines solchen Systems nicht die einzige Aufgabe dieser Arbeit ist w re eine ausf hrliche Erprobung verschiedener SmartCard Produkte auch unangemessen gewesen Aufgrund der Tatsache dass das Produkt SmartCard Biometrics vom Hersteller Utimaco Safeware AG die obigen Kriterien gem der Produktbeschreibung zu erf llen schien und in Anbetracht der Tatsache dass es sich hierbei insbesondere um ein biometriegesichertes Produkt handelt ist es f r die hier erarbeitete 44 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Sicherheitsarchitektur ausgew hlt worden Insbesondere ist die Angabe des Herstellers ma gebend gewesen dass das Produkt mit Standardanwendungen von Drittherstellern wie Microsoft Internet Explorer Netscape oder Outlook zusammenarbeite 2 3 5 2 Produkteigenschaften Das Produkt SmartCard Biometrics besteht aus einem USB SmartCard Leseger t in dem Fingerabdrucksensor integriert ist einer SmartCard und einer CD ROM Das Handbuch ist stark marketinglastig und gibt insbesondere Entwicklern die eine Anwendung aufbauend auf dem Produkt erstellen m chten nur eingeschr nkte Hilfestellung Dies wird unterstrichen durch den Verweis auf die kostenpflichtige Servicehotline f r Kunden ohne Wartungsvertrag Kap 1 durch die ausf hrliche Darstellung der Probleml sungskompetenz weiterer Utimaco Produkte Kap 3 sowie durch die schwer verst ndliche
55. Projektebene die Instanziierung der Berechtigungen die deklarativ durch Pr dikate in der authorities txt festgelegt worden sind Hierf r stellt der AuthorityManager die Methode readAuthoritiesFromFile zur Verf gung Dieser delegiert diese Aufgabe an den AuthorityReader der hierf r eine gleichnamige Methode bereitstellt Dies ist konsistent mit der Forderung dass der AuthorityManager die Zugriffsschnittstelle f r die Autorisierungsarchitektur bildet Folgende Ver nderung in der Iterationsschleife liest somit die deklarierten Berechtigungen ein for int i roots length 1 i gt 0 i start at broker AuthorityManager getAuthorityManager readAuthoritiesFromFile this services roots i File separator authorities txt dispatcher init roots i File separator handler txt In diesem Zusammenhang ist bemerkenswert dass der Autorisierungsarchitektur das Services Objekt bergeben wird Dieses Objekt bildet die zentrale Schnittstelle innerhalb der Broker Architektur um auf die Persistenzschicht Assets zugreifen zu k nnen Die Ubergabe der Services dient der Initialisierung der elementaren Berechtigungen wann immer diese ben tigt werden Die wichtigsten Aufgaben des AuthorityReaders sind das Instanziieren der deklarierten Berechtigungen und das Zwischenspeichern der Zuordnungen von Pr dikaten String Repr sentationen zu Berechtigungen und zwar ber alle Projektebenen hinweg Diese Zuordnung wird sp ter ver
56. Properties Tabelle her Die Zuordnung von Handlern zu Pr dikaten wird in einer transienten Tabelle zwischengespeichert die innerhalb des AuthorityManagers unter dem Attribut transientAuthorityMapper gehalten wird Nach dem Instanziieren der Handler substituiert die Methode putHandlersinsteadOfHandlernames Hashtable transientTable innerhalb des Dispatchers die zuvor ausgelesenen Klassennamen innerhalb der transienten Tabelle durch die nun vorhandenen Handlerinstanzen Die transiente Tabelle enth lt somit nach dem Aufruf dieser Methode die Zuordnung von Handlerinstanzen zu Pr dikaten von der handler txt einer Projektebene Dieser Vorgang wird im Dispatcher geloggt Zum Abschluss der Iteration in einer Projektebene werden die in der transienten Tabelle zwischengespeicherten Zuordnungen dem HandlerAuthorityMapper bergeben Hierzu wird am Ende der init Methode die Methode initTransientAuthorities der Klasse AuthorityManager aufgerufen Innerhalb dieser Methode wird die transiente Tabelle an den HandlerAuthorityMapper bergeben und diese anschlie end gel scht Der folgende Programmcode zeigt die notwendigen Anpassungen innerhalb der init Methode im Dispatcher Einlesen der handler txt einer Projektebene diese wird in der Properties Tabelle properties gehalten urspr ngliches Format wiederherstellen AuthorityManager getAuthorityManager extractAuthorityNames properties Instanziierung der Handler verwendet pr
57. SHA MD5 etc 2 Server Hello Der Server beantwortet die Anfrage mit einer Best tigung der Cipher Suite Zus tzlich schickt er dem Client das Serverzertifikat und eine Verbindungsidentifikationsnummer connection identifier CID Abb 10 1 Challenge String unterst tzte Kryptoalgorithmen Server 2 Serverzertifikat Cipher Suite CID Zertifikat Client Anwendung Anwendung z B Browser z B Secure Web Server Abb 10 SSL Handshake Client und Server Hello 3 G ltigkeitspr fung Der Client berpr ft die G ltigkeit des Serverzertifikats Dies beinhaltet insbesondere die Pr fung der Zertifikatssignatur Abb 7 Abb 11 ggf aber auch die weiteren erforderlichen Pr fungen wie Datum CRL etc vgl 2 3 3 1 28 VeriSign98 www verisign com repository clientauth ent_ig htm 36 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform CA Root ffentlicher CA Schl ssel Client Anwendung Prozess z B Browser 1 Bildung des Hashwertes des Zertifikatsinhalts 2 Dechiffrierung der CA Signatur Server 3 Vergleich der Werte Zertifikat CA Signatur Abb 11 SSL Handshake Clientseitige Signaturpr fung Das vom Server vorgelegte Zertifikat muss von einer dem Client vertrauensw rdig erscheinenden CA signiert worden sein Eine CA wird als vertrauensw rdig eingestuft wenn ihr Zertifikat oder das einer bergeordneten CA im Browser installiert worden ist v
58. TUHH Technische Universit t Hamburg Harburg Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Diplomarbeit vorgelegt von Cesar Perera Anton Elektrotechnik Technische Universit t Hamburg Harburg Betreuer Prof Dr Florian Matthes AB Software Engineering Betrieblicher Informationssysteme TU M nchen Prof Dr Joachim W Schmidt AB Softwaresysteme Technische Universit t Hamburg Harburg Hamburg den 19 Dezember 2003 Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Hiermit versichere ich dass ich 1 diese Arbeit selbst ndig angefertigt 2 alle w rtlich oder inhaltlich aus anderen Quellen entnommenen Stellen als solche kenntlich gemacht und 3 keine anderen als die angegebenen Hilfsmittel benutzt habe Hamburg den 19 Dezember 2003 Cesar Perera Ant n TUHH AB Softwaresysteme 1 Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Inhalt ichni 1 1 ZIELE DER RBEI ins Brink 2 1 2 GEIEDERUNG DER ARBEIT u RK ar San SR AIR 3 1 3 DANKSAGUNG zus ara RR HINEIN psp a 3 2 1 SICHERHEIT BEGRIFFE KONZEPTE UND METHODEN 00000000000000 000000000000 5 2 1 1 Allgemeines zum Thema 5 2 1 2___
59. Umsetzung derartige Defizite aufweisen dass sie aus technischer Sicht eine weitaus geringere Sicherheitsbewertung findet Wie offenbar klar sein d rfte setzt dies nicht die konzeptionellen berlegungen in Frage sondern ihre technische Umsetzung Ein Beispiel hierf r wird weiter unten aufgef hrt F r die exakte Bewertung einer spezifischen Authentisierungsma nahme sind zwei Messgr en von Bedeutung die Zur ckweisungsrate und die Akzeptanzrate Bei der Zur ckweisungsrate ist zu messen wie oft die Authentisierungsma nahme bei der Verifizierung der Identit t zu einem negativen Ergebnis f hrt obwohl es sich tats chlich um die zu authentisierende Identit t handelt und somit das Ergebnis eigentlich positiv ausfallen m sste Es wird somit die Wahrscheinlichkeit f r die f lschliche Zur ckweisung gemessen Bei der Akzeptanzrate ist hingegen zu messen wie oft die Authentisierungsma nahme bei der Verifizierung der Identit t zu einem positiven Ergebnis f hrt obwohl es sich nicht um die zu authentisierende Identit t handelt und somit das Ergebnis eigentlich negativ ausfallen m sste Es wird somit die Wahrscheinlichkeit f r die f lschliche Akzeptanz gemessen Offenbar f llt eine Ma nahme in ihrer Bewertung besser aus je kleiner diese Gr en sind Solche Betrachtungen sind dann besonders wichtig wenn der Authentisierungsgrad genau quantifiziert werden muss oder wenn bereits ein hoher Authentisierungsgrad erreicht ist und die Ein
60. Zugriff so werden die festgelegten Abl ufe gesch tzt Nur wenn ein Vorgang im jeweiligen Kontext autorisiert ist kann somit eine bestimmte Handlung durchgef hrt werden Sch tzt man die Assets vor nicht autorisiertem Zugriff so werden gespeicherte Informationsinhalte gesch tzt Nur wenn der Informationszugriff im jeweiligen Kontext autorisiert ist kann die gew nschte Information eingesehen oder ggf ver ndert werden Es sei an dieser Stelle erg nzend angemerkt dass bereits eine Autorisierung auf Pr sentationsebene existiert die innerhalb der Templates mit Hilfe von bedingten Platzhaltern stattfindet Die zu sch tzenden Ressourcen sind hierbei die anzuzeigenden oder nicht anzuzeigenden Verkn pfungen Dies wird sp ter weiter ausgef hrt da dies nicht Gegenstand der Konzeption ist Als Gegenstand dieser Arbeit wird der Zugriffsschutz der Ressource Handler vereinbart Die Autorisierung auf Asset Ebene ist somit ausdr cklich nicht Gegenstand dieser Arbeit Diese Aussage legt zun chst fest f r welche Ressourcen Zugriffsrechte definiert werden sollen Nachdem festgelegt ist welche Ressourcen zu sch tzen sind werden als n chstes die Rechte betrachtet Die festzulegenden Rechte sollen bestimmten Kriterien gen gen Dies kann als Anforderungsprofil f r die Gestaltung der Rechte verstanden werden 8 Notiz P Hupe Da die Prozesse Handler den Objekten Assets bergeordnet sind und ein Zugriff auf die Objekte was das We
61. abdecken insbesondere wenn es sich um offene Netze handelt zu denen ein jeder Zugang hat wie dies beim Internet der Fall ist Haupts chlich lassen sich die Risiken in zwei Kategorien gliedern Einbruch und Sabotage Risiken aus der Kategorie Einbruch sind darauf ausgerichtet unerlaubt an Information zu gelangen oder die IT Infrastruktur zu eigenen unerlaubten Zielen zu verwenden Es entsteht hierbei kein offensichtlich sichtbarer Schaden obwohl dieser nat rlich vorhanden ist wenn sensible Information in falsche H nde ger t oder wenn IT Ressourcen zweckentfremdet werden Derjenige der einen solchen Ubergriff begeht hat i d R ein Interesse daran unerkannt und unbemerkt zu bleiben so dass er seine Aktivit ten ber einen l ngeren Zeitraum aus ben kann Ma nahmen die Risiken dieser Kategorie abwenden sollen sind beispielsweise Firewalls die offene Ports sch tzen oder dazu beitragen Trojaner zu finden die Planung der Netzwerkarchitektur unter Ber cksichtigung der Einbruchsm glichkeit demilitarisierte Zonen usw die Verwendung von Intrusion Detection Systemen um Einbr che sichtbar zu machen und evtl zur ckzuverfolgen etc Risiken aus der Kategorie Sabotage sind darauf ausgerichtet die origin re funktionale Nutzung des Systems einzuschr nken oder zu unterbinden Sie sind i d R darauf ausgerichtet den vorhandenen IT Ressourcen einen nachhaltigen Schaden zuzuf hren Beispiele f r Risiken die dieser Kategorie zuzuordn
62. age Abl ufe des t glichen Lebens durch Online Abl ufe zu substituieren Home Banking Online Shopping etc Alle diese Anwendungen stellen f r die Internetnutzer mittlerweile eine gewisse Selbstverst ndlichkeit dar In gleicher Weise wie die Popularit t dieses relativ neuen Mediums zunimmt nimmt auch die Qualit t und die Vielfalt der im Internet angebotenen Dienste kontinuierlich zu W hrend in der Anfangszeit des World Wide Web Internetpr senzen durch statische Inhalte charakterisiert waren erwartet der Benutzer heutzutage hochaktuelle dynamische Inhalte Dies spiegelt sich auch in der technologischen Entwicklung wider W hrend eine statische Web Site serverseitig mit einem einfachen Web Server auskommt erfordert eine interaktive dynamische Web Site zus tzlich mindestens noch einen serverseitigen Datenbank Server mit einer geeigneten Skriptsprache z B MySQL und PHP Komplexe Anwendungen gehen noch einen Schritt weiter Sie bauen oft auf mehrschichtigen serverseitigen Architekturen auf Internet Portale sind typische Anwendungen die von einer mehrschichtigen Architektur gebrauch machen Sie aggregieren und ordnen verschiedene korrelierte Dienste und bieten dem Benutzer auf diese Weise eine einheitliche Plattform an Gleichzeitig stellen sie eine F lle von Funktionen bereit die administrative Aufgaben bernehmen und f r den Benutzer transparent sind Sessions Management Load Balancing etc Funktionen die weniger administra
63. ale Identit t mit einem ffentlichen Schl ssel eines bestimmten asymmetrischen kryptographischen Verfahrens in untrennbarer Weise zu verkn pfen Hierdurch wird erreicht dass digitale Handlungen die die betreffende Identit t mit ihrem komplement ren privaten Schl ssel durchf hrt auf diese Identit t zur ckzuf hren sind Mit diesem Ansatz soll die Vertrauensw rdigkeit der digitalen Handlung untermauert werden Falls n mlich aus dieser Handlung eine evtl Sch digung folgen sollte so kann die hierf r verantwortliche Identit t festgestellt und zur Rechenschaft gezogen werden Abb 6 veranschaulicht das zugrunde liegende Prinzip Uber die hier dargestellten wesentlichen Informationen hinaus k nnen digitale Zertifikate weitere Eintr ge enthalten deren Integrit t ebenfalls gesichert ist Identit tsmerkmale ffentlicher Schl ssel des Inhabers eines definierten asymm Kryptoverf symbolisiert die Sicherung der Integrit t Elektronisches Artefakt Digitales Zertifikat der Zertifikatsinformation Abb 6 Elektronisches Artefakt Digitales Zertifikat Die Identit tsmerkmale eines digitalen Zertifikats k nnen vielschichtig sein Die Art der diesbzgl Eintr ge werden i d R vom jeweiligen Zertifikatsstandard festgelegt Innerhalb des jeweiligen Standards k nnen sie zus tzlich vom konkreten Zertifikatszweck abh ngig sein Der in das Zertifikat eingetragene ffentliche Schl ssel ist einem bestimmten kryptog
64. anager verwendet die eine explizite Verwendung der Klasse SSLContext berfl ssig Wie viele andere Klassen der Java Security Architecture JSA ist auch die Klasse SSLContext als Engine Klasse ausgelegt wodurch sie zwar einem Verwendungsschema unterliegt ihre Implementierung aber offen ist Zus tzliche Implementierungen einer Engine Klasse k nnen einer Laufzeitumgebung auf einfache Weise durch sog Provider bereitgestellt werden s JSA Unterhalb der Klasse SSLContext sieht man in Abb 20 zwei Pfade die jeweils in die Klasse SSLSession m nden Instanzen dieser Klasse repr sentieren Verbindungen zwischen je zwei Teilnehmern In der Praxis dienen diese Instanzen dazu wichtige Information ber die bestehenden Verbindungen bereitzustellen z B Cipher Suites Zertifikate etc Dar ber hinaus stellen diese Instanzen f r jede dieser Sitzungen ein Dictionary bereit der es erm glicht anwendungsspezifische Sitzungsobjekte unter einem Schl sselnamen abzulegen und wieder zu verwenden Zugriff auf das betreffende SSLSession Objekt erh lt man ber den jeweils aktuellen SSLSocket 79 davor 1 2 und 1 3 war JSSE eine optionale Erweiterung 2 55 Reference Guide for J2SDK 1 4 3 Verwendung eines default SSLContext 92 tats chlich ist SSLSession ein Interface der Einfachheit halber wird aber nur von Klassen gesprochen 42 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform
65. artCards findet man hnliche Prinzipien wieder So kann der Zugriff auf die in einer SmartCard gehaltenen Credentials ebenfalls wissensbasiert z B PIN gesicherte SmartCard oder sogar biometriebasiert z B fingerabdruckgesicherte SmartCard gesch tzt werden Wie deutlich wird erweitert der lokale Zugriffsschutz das reine Besitzkonzept des digitalen Zertifikats um andere Authentisierungskonzepte wie Wissen oder Biometrie Oft wird in diesem Kontext dar ber diskutiert welches dieser beiden lokalen Zugriffsschutzkonzepte denn das Bessere sei F r beide Konzepte k nnen jeweils gute Gr nde vorgebracht werden Zugleich k nnen auch die Nachteile des nicht favorisierten Konzepts benannt werden Diese Diskussion soll kurz anhand des Beispiels einer PIN gesicherten und einer fingerabdruckgesicherten SmartCard skizziert werden Die Bef rworter einer PIN gesicherten L sung weisen oft darauf hin dass der entsprechende Fingerabdruck des jeweiligen SmartCard Inhabers leicht der Karte entnommen werden k nne da dieser die Karte ja ber hren m sse und dass diese Fingerabdruckinformation mit entsprechenden technischen Mitteln f r eine Replay Attacke verwendet werden k nne Die Ermittlung der jeweiligen PIN sei im Vergleich zum Fingerabdruck schwieriger zu bewerkstelligen Dem kann man entgegenhalten dass sich zwar das technische Fingerabdruckerfassungssystem m glicherweise t uschen lasse dies aber lediglich schlussfolgern lasse dass solche Syst
66. b Interface angeht nur ber die Prozesse m glich ist impliziert ein Schutz der Prozesse einen Schutz der Objekte Hierbei existieren zwei Einschr nkungen Fehler in den Handlern erlauben einen Zugriff auf Objekte der nicht gestattet w re Schnittstellen die nicht die Handler verwenden WebDAV WebServices nutzen nicht diese Autorisierung TUHH AB Softwaresysteme 63 Autorisierung 4 1 1 Anforderungen Zun chst einmal soll ein Recht durch ein sog Pr dikat in deklarativer Weise festgelegt werden Unter dem Begriff Pr dikat ist hier eine allgemeinverst ndliche Bezeichnung bzw Charakterisierung eines Rechts zu verstehen die zus tzlich in der Lage sein soll Parameter aufzunehmen die das spezielle Recht spezifizieren Ein einfaches Beispiel f r ein solches Pr dikat w re die Bezeichnung isMemberOf Administratoren In diesem Beispiel ist der Schl sselbegriff isMemberOf als Charakteristikum des Pr dikats und die Bezeichnung Administratoren als Spezifizierung Parameter des Rechts zu erkennen Diese Bezeichnung ist insofern allgemeinverst ndlich als dass eine Ressource ein Handler die durch dieses Pr dikat gesch tzt w re lediglich f r Mitglieder einer Administratorengruppe zug nglich w re Diese Pr dikate werden im jeweiligen Kontext in dem sie ausgef hrt werden zu einem boolschem Wert evaluiert Dies ist so zu interpretieren dass f r den Fall dass das Pr dikat im ausgef hrten Kontext zum boolsche
67. bestimmtes Zertifikat f r ung ltig zu erkl ren Ein solcher Widerruf ist somit prinzipiell ein recht simpler Vorgang Die eigentliche Komplexit t entsteht durch die Tatsache dass sich die CRL bei der CA befindet und ber die G ltigkeit bei dem jeweiligen Teilnehmer entschieden werden muss Dar ber hinaus muss bei der Entscheidung ber die G ltigkeit eines Zertifikats prinzipiell nicht nur eine CRL eingesehen werden sondern die CRLs s mtlicher Zertifizierungsrichtlinien derer Zertifikate die die Integrit tsschlussfolgerungskette bilden da prinzipiell ja auch das Zertifikat einer CA f r ung ltig erkl rt werden k nnte und dies die Ung ltigkeit s mtlicher Unterzertifikate zur Folge h tte Zwei Probleme sind somit von zentraler Bedeutung die Aktualit t einer Vielzahl von CRLs und ihre jeweilige Authentizit t Die Authentizit t einer wird hnlich der Integrit t eines digitalen Zertifikats durch eine digitale Signatur erreicht Der Benutzer einer CRL kann sich durch Pr fung der Signatur davon berzeugen dass die CRL tats chlich von der betreffenden CA ausgestellt worden ist und dass ihr Inhalt unverf lscht ist F r die Aktualit t einer CRL gibt es prinzipiell zwei Strategien Bei der ersten Variante wird die CRL als lokale Datei gehalten und muss dementsprechend in regelm igen Abst nden aktualisiert werden Dies kann nat rlich von einem eigenen Prozess automatisiert werden Bei der zweiten Variante wird bei Bedarf e
68. ch Abschluss des Initialisierungsvorgangs kann die zu einem Handler geh rige Berechtigung durch Aufruf der Methode getAuthority GenericHandler handler stets programmatisch erfragt werden Der eigentliche Initialisierungsvorgang der Zuordnungstabelle der die deklarative Zuordnung in der handler txP in eine programmatisch nutzbare Zuordnung in der Zuordnungstabelle vornimmt ist hierbei der komplizierteste Ablauf Er wird in Abschnitt 4 3 erl utert 4 2 4 Die Auswertung von Berechtigungen Das Sicherheitskonzept Autorisierung sieht vor dass vor dem Zugriff auf eine Ressource das entsprechende Zugriffsrecht im jeweiligen Kontext auf Erf llung hin gepr ft wird Zun chst einmal ist es also wichtig zu wissen von welcher Stelle aus auf die Funktionalit t eines Handlers zugegriffen wird Innerhalb der Architektur der Portalplattform findet dieser Zugriff auf einen Handler vom Session Objekt das den jeweiligen Ausf hrungskontext repr sentiert aus statt Das Session Objekt ruft bei dem betreffenden Handler die Methode handleRequest auf die den Handler somit ausf hrt Es ermittelt dabei den betreffenden Handler indem es vorher beim Dispatcher Objekt anfragt Der genannte Aufruf findet innerhalb des Session Objekts an zwei Stellen statt innerhalb der Methoden handleRequest und forwardRequest Der Programmcode f r die Ermittlung des Handlers und seine Ausf hrung ist in beiden F llen identisch GenericHandler h dispatcher getHandler doc
69. cherheitskonzept Verbindlichkeit umzusetzen w re eine nicht integrierte L sung Bei diesem L sungsansatz k me Fremdsoftware zum Einsatz um digitale Dokumente zu signieren bzw um geleistete Signaturen zu verifizieren Der infoAsset Broker w rde in diesem Zusammenhang lediglich die Transportplattform f r derartige Dokumente bilden Zeichnungspflichtige Gesch ftsprozesse w ren der Portalplattform zun chst auf Dokumente abzubilden damit diese wiederum mit der Fremdsoftware signiert werden k nnten Als Beispiel f r den Einsatz von Fremdsoftware sind die Produkte der Fa Mobile Technologies International Ltd zu nennen die ber ihre Website www pdfree de erreichbar ist Dieses Unternehmen bietet Signatursoftware an die eigenen Angaben zufolge die juristischen Bedingungen innerhalb Europas erf llt Bei den signierten Dokumenten handelt es sich dabei um pdf Files Dar ber hinaus ist die Software die zur Verifikation der Signatur dient zeitlich unbegrenzt kostenlos nutzbar 5 2 2 Authentisierung Verbesserungsvorschl ge Durch die in Kap erarbeitete SWS Architektur werden verschiedene Authentisierungskonzepte umgesetzt Wie dort erl utert ist ein entscheidendes Entwurfskriterium die Erweiterbarkeit der Architektur zu erm glichen Eine denkbare Verbesserung betrifft somit die Einf hrung neuer Authentisierungskonzepte Die bereits implementierten SSL Server k nnen hierbei als Referenzimplementierungen verwendet werden um ggf neue
70. chieden werden In dieser Arbeit soll die Unterscheidung aufgrund pers nlicher ressourcenbasierter und authentisierungsbasierter Merkmale vorgenommen werden Dar ber hinaus sind weitere Kategorien denkbar die hier nicht weiter betrachtet werden Pr dikate deren Erf llungsvoraussetzungen auf pers nlichen Merkmalen beruhen betrachten bei ihrer Evaluierung die Identit t des betreffenden Benutzers Pr dikate deren Erf llungsvoraussetzungen auf ressourcenbasierten Merkmalen beruhen betrachten bei ihrer Evaluierung die Zust nde oder Eigenschaften der verwendeten Ressourcen Assets Pr dikate deren Erf llungsvoraussetzungen authentisierungsbasierten Merkmalen beruhen betrachten bei ihrer Evaluierung den Mechanismus der zur Authentisierung der Identit t eines Benutzers gef hrt hat 49 2 S also solche die nicht zusammengesetzt sind 64 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Die Zuordnung der Pr dikate zu ihren zu sch tzenden Ressourcen Handler soll auf deklarative Weise erfolgen Dar ber hinaus sollen Autorisierungen die auf einer grundlegenden Projektstufe erteilt worden sind nicht mehr auf einer dar berliegenden Projektstufe ver nderbar sein Diese letzte Forderung regelt die Verantwortlichkeit f r die Erteilung von Autorisierungen Bei Ressourcen Handler denen kein Pr dikat zugeordnet ist sollen mindestens zwei alternative Strategien existieren die
71. clientseitige Sicherheitsger te in geb hrender Weise zu ber cksichtigen 53 dem Hashwert des Vertragswerkes 84 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Ein wichtiger Punkt bei der zertifikatsbasierten Client Authentisierung ist die serverseitig sichere Unterscheidung der clientseitig verwendeten Sicherheitsger te Da der Server tats chlich nur das vom Client vorgelegte Zertifikat sieht muss er aufgrund der dort enthaltenen Information ber die Gew hrung oder die Ablehnung eines Verbindungsaufbaus entscheiden Hierf r sind im Einzelfall klare Anwendunggsrichtlinien festzulegen Bisher trifft ein Server diese Entscheidung allein aufgrund des jeweils verwendeten Truststores Dies impliziert somit dass die Vertrauensanker f r einen Server der den Softwaresicherheitsdienst nutzt anders als die eines Servers der eine Authentisierung durch die Verwendung einer SmartCard vorsieht sein m ssen Dies muss nicht notwendigerweise so sein Allerdings findet eine sinnvolle Auswahl unter den M glichkeiten nicht allein durch die Betrachtung von technischen sondern auch von betriebswirtschaftlichen Gesichtspunkten statt Die zu verwendenden Client Zertifikate m ssen entweder von einer anerkannten CA stammen oder werden von einem eigenen Certificate Server produziert Beide Wege sind mit nicht zu vernachl ssigenden Kosten verbunden und m ssen einer Abw gung unterzogen werden Es wird an d
72. d der Anpassung der Klasse HttpConnection Die erste Variante w rde bedeuten dass man keine vollst ndige Trennung der SWS Architektur vom restlichen Code mehr h tte und dass man sich dadurch m glicherweise weitere Probleme einhandeln w rde Die zweite Variante beinhaltet eine Klasse mit einem sehr komplexen Verhalten teilweise umzuschreiben und erprobten funktionsf higen Code auf diese Weise zu gef hrden Da offenbar beide L sungen u U neue Probleme schaffen wird ein L sungsansatz gew hlt der sich an der zweiten Variante orientiert ohne diese tats chlich umzusetzen Der L sungsansatz beinhaltet die Wiederverwendung des Codes der Klasse HttpConnection ohne die Klasse wieder zu verwenden Zu diesem Zweck wird der Code dieser Klasse in eine neu geschaffene Klasse HTTPSConnection bertragen und dort entsprechend den Bed rfnissen der SWS Architektur angepasst U a erwartet die Klasse nunmehr ein SSLSocket so dass auch der Name HTTPSConnection gerechtfertigt ist dies ist bei blichen Engines nicht n tig 2 vgl 2 3 4 3 4 Abweichend von dieser Strategie w re es m glich das SSLContext Objekt eigenh ndig zu instanziieren und zu initialisieren Aufgrund des h heren Aufwandes ist dies nur sinnvoll wenn ein vom Standard abweichendes Verhalten erreicht werden m chte Um an dieser Stelle ein konkretes Beispiel zu nennen w re dies beispielsweise sinnvoll wenn man CRLs implementieren m chte TUHH AB Softwaresysteme 55
73. die Autorisierung regeln Im ersten Fall soll der Zugriff auf die Ressource Handler stets gew hrt werden Diese Strategie wird als liberal bezeichnet Sie ist f r die Migration von einem System ohne Autorisierungskonzept zu einem System mit Autorisierungskonzept sinnvoll Im zweiten Fall soll der Zugriff hingegen stets versagt werden Diese Strategie wird als restriktiv bezeichnet Sie ist f r ein System mit Autorisierungskonzept das kontinuierlich um neue Anwendungslogik erweitert wird sinnvoll Es soll nachtr glich nachvollzogen werden k nnen welche Pr dikate in einem Ausf hrungskontext existent und welchen Ressourcen Handlern sie jeweils zugeordnet gewesen sind Dar ber hinaus ist von Interesse in Falle des Zugriffs auf eine Ressource Handler welcher Benutzer den Zugriff get tigt hat und ob dieser gew hrt oder versagt worden ist Diese Funktionalit t wird unter dem Begriff Auditing zusammengefasst TUHH AB Softwaresysteme 65 Autorisierung 4 2 Entwurf der Autorisierungsarchitektur Nachdem das Anforderungsprofil f r die Autorisierungsarchitektur festgelegt worden ist sind die Ma nahmen zur Definition Zuordnung und Auswertung von Zugriffsrechten festzulegen In diesem Kontext werden die Zugriffsrechte als Berechtigungen Authorities bezeichnet Die zuvor betonten Pr dikate sind dabei deklarative Repr sentationen von programmatisch implementierten Berechtigungen 4 2 1 Die Berechtigung Das zentrale Objekt der Au
74. dieser Arbeit erstellte Entwurf orientiert sich an dem Engine Pattern ohne dass dieser tats chlich die Umsetzung des Secure Web Servers als Engine Klasse vorsieht Vielmehr wird ein Zugriffsmuster hnlich dem einer Engine Klasse festgelegt In dem vorgelegten Entwurf sind die Implementierungen allerdings Spezialisierungen einer abstrakten Secure Web Server Klasse Auf diese Weise wird nicht nur die m gliche Erweiterbarkeit gesichert sondern es wird eine wichtige Redesignm glichkeit er ffnet Die Architektur kann demnach zu einem sp teren Zeitpunkt zugunsten von Engines oder zugunsten des hier gew hlten Ansatzes ausgestaltet werden F r diesen Entwurf bedeutet dies 36 Details zu Engines und Provider 01 TUHH AB Softwaresysteme 49 Vertraulichkeit Integrit t und Authentisierung dass f r die Klasse SSLWebServer die den Secure Web Server repr sentiert ffentliche Methodennamen gew hlt wurden die sich an der Namensgebung bei Engines orientiert Ein berschreiben bestimmter Methoden erm glicht es abweichende Implementierungen durch spezialisierte Klassen bereitzustellen Wichtig ist hierbei dass spezialisierte Klassen ein f r Engines blichen Namensattribut enthalten der sie von anderen Implementierungen unterscheidet Das Kriterium Kapselung beinhaltet zum einen die Modularisierung des Secure Web Servers und zum anderen die Zug nglichkeit der Funktionalit t ber wenige definierte Schnittstelle
75. dieser Variante darf das Keystore das das Serverzertifikat und den korrelierten privaten Schl ssel enth lt nur diesen einen key entry enthalten Erfordert der Server eine Client Authentisierung wird die Initialisierung einer zweiten Systemeigenschaft ben tigt Dies geschieht ebenfalls mit dem vollst ndigen Keystore Dateinamen der Keystore Datei die s mtliche f r den betreffenden Server relevanten vertrauensw rdigen Zertifikate enth lt Die erste Datei bildet somit den JSSE Keystore d h den Speicher f r Zertifikate die zum Nachweis der eigenen Identit t dienen und die zweite den JSSE Truststore d h den Speicher f r Zertifikate die als Vertrauensanker zugelassen sind Die Namensgebung ist in diesem JSSE Kontext leider etwas irritierend da beide Dateien jeweils durch ein Keystore implementiert werden 2 3 3 4 Zertifikatsspeicher in Netscape clientseitige Betrachtung Wie bereits in Abschnitt 2 2 erw hnt liegen clientseitig Webbrowser vor wobei f r die Erprobung des programmatischen Teils dieser Arbeit Netscape 7 0 verwendet worden ist Dies ist insbesondere in Hinblick auf die Nutzung der verwendeten SmartCard von Bedeutung s 2 3 5 Wird ein anderer Browser verwendet so wird der betreffende Zertifikatsspeicher des Browsers konzeptionell eine hnliche Struktur aufweisen Um die Anbindung des SmartCard Leseger ts an einen anderen Browser zu bewerkstelligen ist darauf zu achten dass der betreffende Browser eine der SmartCa
76. e Datei Da eine Truststore Datei keine privaten Schl ssel enth lt die zu sch tzen w ren werden hierf r keine Passw rter ben tigt so dass hier die Frage nach der Gleichheit entf llt hasTruststore boolean Dieser Wert ist true wenn beim SSL Handshake eine Client Authentisierung durchgef hrt werden soll zu der ein Truststore ben tigt wird Anderenfalls ist der Wert false Die abstrakte Klasse SSLWebServer die in ihren Schnittstellen einer Engine Klasse gleicht verk rpert wie der Name erahnen l sst das Herzst ck der SWS Architektur Obwohl sie als Objekt nicht instanziierbar ist enth lt sie die vollst ndige Funktionalit t eines SSL Servers Die Implementierungen von instanziierbaren SSL Servern erfolgen durch Spezialisierung dieser abstrakten Klasse Das einzige das die spezialisierten Klassen implementieren m ssen ist eine Konstante mit dem charakteristischen Implementierungsnamen und ein parameterloser Konstruktor Selbstverst ndliich k nnen diese spezialisierten Klassen die Methoden von SSLWebServer berschreiben die vom Standardverhalten abweichen sollen Die in dieser Arbeit erstellten SSL Server Implementierungen behalten alle die Funktionalit t ihrer generalisierten Klasse SSLWebServer bei Die tats chliche Unterscheidung in ihrem Verhalten resultiert somit lediglich aus einer unterschiedlichen Konfiguration Eine Umgestaltung dieser Umsetzung des Erweiterbarkeitsprinzips ist somit auf einfache Weise m
77. e Gewinnung der Anmeldedaten die eigentliche Anmeldung und die Instanziierung des Umleitungstemplates Die Verifizierung der Anmeldeannahmen soll sicherstellen dass der betreffende Handler tats chlich im Anschluss an einen korrelierten SSL Handshake aufgerufen worden ist Hiermit werden somit potentielle Eindringungsversuche abgewehrt Im Fehlerfall wird die Anmeldeprozedur abgebrochen und die Programmlogik auf einen Fehler Handler SSLFailureRedirectHandler umgeleitet Zun chst wird gepr ft ob der betreffende Handler berhaupt ber eine gesicherte Verbindung aufgerufen wird Dies ist der Fall wenn ein SSLSocket f r die Verbindung verwendet wird Anschlie end wird der tats chlich verwendete Port mit dem Port verglichen auf dem die betreffende Anmeldeprozedur erwartet wird Auf diese Weise wird verhindert dass ein Handler durch die Nutzung eines nicht vorgesehenen SSLSockets aufgerufen wird Sind diese beiden Kriterien erf llt so kann davon ausgegangen werden dass der von dem betreffenden Anmelde Handler erwartete SSL Handshake erfolgreich durchgef hrt worden ist Die Gewinnung der Anmeldedaten unterscheidet sich bei den verschiedenen Handlern Im Falle einer Passwort Authentisierung wird das Objekt der Klasse SSLPasswordCredentials geholt das zu der betreffenden Session geh rt Hierbei handelt es sich um ein Hilfsobjekt der SWS Architektur das dazu dient die Credentials die aus User Login und Passwort bestehen f r die Anmelde
78. e konfigurierten SSL Server startet Da diese Aufgaben von einem einzigen Objekt bewerkstelligt werden k nnen wird diese Klasse gem des Singleton Patterns implementiert Die Methode die s mtliche konfigurierten SSL Server startet und die auch das Singleton Objekt generiert ist die Klassenmethode startSSLServers Innerhalb dieser Methode werden die vorhandenen Konfigurationen von der verantwortlichen Klasse erfragt und die SSL Server entsprechend diesen Konfigurationen gestartet Verantwortlich f r die Konfigurationen ist die Klasse SSLConfiguration Diese Klasse ist so konzipiert dass Konfigurationen durch Flags die als Konstanten implementiert sind auf einfache Weise ein oder ausgeschaltet werden k nnen Auf diese Weise wird ein Testen der SWS Architektur unter Ber cksichtigung unterschiedlicher Konfigurationskonstelationen auf einfache Weise erm glicht Instanzen der Klasse SSLConfiguration stellen die Parameter bereit die f r das Initialisieren der SSL Server ben tigt werden Die Objekte dieser Klasse werden dabei von der Klasse selbst in einer linearen Liste verwaltet S mtliche Konfigurationen werden bei einem einmalig stattfindenden Initialisierungsvorgang erstellt und in der genannten Liste abgelegt Diese Initialisierungsprozedur wird durch die Klassenmethode initSSLConfigurations durchgef hrt Innerhalb dieser Initialisierungsmethode werden entsprechend der gesetzten Flags einzelne Konfigurationen erstellt Die daf r
79. eichnis JavaScr02 JavaScript Online Hilfe JavaScrO3 02 Kr g02 Mat00 01 Nets02 01 00 Pist99 Rei02 RSAO1 SAPO1 SAPO2a SAPO2b SAPO2c SAPMag01 SAPPub01 SAPSec01 Ste02 TCTrust 88 Automatische Weiterleitung Web Site www sachen fuer webmaster de printfeature php artid 64 JavaScript Online Hilfe Automatische Weiterleitung www suchmaschinentricks de technik weiterleitungen html IBM WebSphere V4 0 Advanced Edition Security 1st Edition eBook www ibm com redbooks Peter Kovari et al IBM Corporation 2002 Web Site Handbuch der Java Programmierung 3 Auflage HTML Ausgabe www javabuch de Guido Kr ger 1998 2002 E Commerce Concepts and Technologies Vorlesungsunterlagen Florian Matthes TUHH AB Softwaresysteme www sts tu harburg de 2000 netlife banking server amp netlife HBCI Online Client Product White Papers netlife AG www netlife de 2001 Netscape 7 0 Online Hilfe Netscape Communications Ireland Inc www netscape de 2000 2002 Java Security 2nd Ed Scott Oaks O Reilly amp Associates Inc 2001 mySAP com Sicherheit im e Business PowerPoint Pr sentation Sachar Paulus SAP AG 2000 Java 2 Network Security eBook www redbooks ibm com Marco Pistoia et al IBM Corporation 1999 Chipkarten in der IT Sicherheit Seminarvortrag Philipp Reichmuth AB Informatik 3 2002 PKCS 11 v
80. eitig stellt dies keine wesentliche Einschr nkung dar da wichtige Abl ufe zuk nftig ja ber den Secure Web Server abgewickelt werden sollen Nach dem Starten des Web Servers durch Aufruf der Methode serve wird das erzeugte WebServer Objekt einem neu erzeugten Thread bergeben und dieser gestartet Damit dies m glich ist implementiert die Klasse WebServer das Interface Runnable Gem der Konvention l st das Starten des Threads den Aufruf der Methode run innerhalb der Klasse WebServer aus und zwar in nebenl ufiger Weise Zusammenfassend bedeutet dies dass alle konfigurierten Web Server die Methode run in einem eigenen Thread also nebenl ufig ausf hren Innerhalb der Methode run wird ein Objekt der Klasse ServerSocket generiert und durch Aufruf der Methode accept gestartet Dieses Objekt lauscht somit innerhalb des WebServer Threads auf einem definierten Port auf die Anfragen die von au en kommen W hrenddessen ruht der Thread Erfolgt eine Anfrage auf dem vorbestimmten Port erwacht der Thread und die Methode accept liefert als R ckgabewert ein Objekt der Klasse Socket Dieser Socket repr sentiert den Kommunikationsendpunkt zum anfragenden Computer und wird als Parameter einem neu erzeugten Objekt der Klasse HttpConnection de infoasset broker server HttpConnection bergeben das f r die Beantwortung der Anfrage verantwortlich ist Starten des ServerSockets und Beantworten der Anfrage laufen hierbei in einer Endlosschleife
81. ekanntesten wissensbasierten Authentisierungen ist diejenige bei der die Credentials durch eine Benutzerkennung Userlogin und ein Passwort umgesetzt werden Hierbei dient das Userlogin zur Identifikation des Benutzers und das Passwort das ja ausschlie lich diesem Benutzer bekannt sein soll dient zum Nachweis der Identit t d h zur Authentisierung Problematisch bei der webbasierten Implementierung dieses Ansatzes ist die mangelnde Vertraulichkeit auf dem bertragungskanal zwischen Client und Server Wird das Passwort im Klartext bertragen kann jeder der die Kommunikation berwacht sich das Passwort aneignen und sich fortan f lschlicherweise bei dem Zielserver als der urspr ngliche Benutzer ausgeben Wird das Passwort in einer chiffrierten aber stets gleichen Weise bertragen kann die chiffrierte Information f r einen sog Replay Attack verwendet werden Hierbei kennt die unberechtigte Partei zwar das Passwort nicht sie ist aber trotzdem in der Lage eine erfolgreiche Anmeldung durchzuf hren da sie dem Zielserver genau die gleiche chiffrierte Information schicken kann wie der berechtigte Benutzer Eine einfache L sung dieses speziellen Problems wird durch das Challenge Response Protokoll bereitgestellt vgl Abb 3 Hierbei schickt der Server dem Client eine zuf llig generierte Zahl ein sog Der Client h ngt an das Nonce das vom Benutzer eingegebene Passwort an wendet auf das Ergebnis eine Hashfunktion an und
82. ellen Merkmalen ausstatten m chte e die Zertifikate ausschlie lich auf speziellen Speichern bereitstellen m chte z B SmartCards 28 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform In einem solchen Fall wird man vermutlich nur eigene Stammzertifikate als vertrauensw rdig einstufen Welche Zertifikate jeder Teilnehmer als vertrauensw rdig einsch tzt ist letztlich eine pers nliche Ermessensangelegenheit eine Glaubensfrage Den Benutzern herk mmlicher Webbrowser wird diese Entscheidung i d R weitestgehend abgenommen da die Browser bereits mit vorinstallierten vertrauensw rdigen Stammzertifikaten ausgeliefert werden Der Durchschnittsnutzer ist sich i d R nicht einmal ber die Tragweite einer diesbzgl Entscheidung im Klaren F r erfahrenere Teilnehmer stellt sich allerdings schon die Frage welche Zertifikate als vertrauensw rdig einzustufen sind und somit den Anker f r die Integrit tsschlussfolgerungskette bilden sollen Dies gilt insbesondere f r die Serveradministration Werden Zertifikate oberster CAs als vertrauensw rdig eingesch tzt so weisen diese Zertifikate i d R ein gemeinsames Merkmal auf Sie sind selbstsigniert Selbstsignierte Zertifikate werden mit dem privaten Schl ssel signiert dessen komplement ren ffentlichen Schl ssel sie akkreditieren Die Integrit t eines solchen Zertifikats wird somit nicht mit Hilfe eines anderen Zertifikats verifiziert sonder
83. em das Verst ndnis gewisser Sicherheitstechnologien erfordern Auf beide Aspekte Sicherheitskonzepte und erforderliche Technologien wird in den folgenden Abschnitten n her eingegangen Dabei wird der Schwerpunkt zielorientiert auf Sicherheit im Kontext webbasierter Plattformen f r Unternehmensportale gesetzt 2 1 2 Sicherheitskonzepte Im vorangegangenen Abschnitt wurde der Sicherheitsbegriff in allgemeiner Weise und im Kontext der Informationstechnologie erl utert Anschlie end wurde kurz ein allgemeiner Prozess zur Erstellung einer Sicherheitsarchitektur dargestellt Dieser Abschnitt befasst sich mit der Identifikation und der Beschreibung der Sicherheitskonzepte von denen eine Teilmenge die Grundlage f r das Anforderungsprofil der in dieser Arbeit dargestellten Sicherheitsarchitektur bildet Die hier dargestellten Sicherheitskonzepte sind im Kontext webbasierter Unternehmensportale zu sehen Als Anwendungsszenario ist somit von einem Application Server der seine Webdienste via TCP IP v4 der Netzgemeinde anbietet auszugehen Ferner ist davon auszugehen dass es sich bei den Clients um Webbrowser handelt die die angebotenen Dienste mit Hilfe typischer Anwendungsprotokolle HTTP FTP usw ber das weltweite Internet anfordern Die dargestellten Sicherheitskonzepte decken Risiken ab die vordergr ndig und typisch f r eine TCP IP v4 Client Server Architektur sind Diese Auflistung erhebt deshalb keineswegs den Anspruch auf Volls
84. eme noch nicht technisch ausgereift seien Auf konzeptioneller Ebene hingegen sei das Fingerabdruckkonzept besser als das PIN Konzept da der erforderliche 14 hierbei kommen beispielsweise Silikonfingerreproduktionen zum Einsatz TUHH AB Softwaresysteme 21 Grundlagen Zugriffsschutz nicht auf einfache Weise freiwillig an einen Dritten weitergegeben werden k nne Dar ber hinaus k nne der Finger nicht vergessen oder verlegt werden wie es im Falle einer PIN durchaus m glich sei was erhebliche Verwaltungskosten einspare Zu erw hnen bleibt in diesem Kontext dass zertifikatsbasierte Authentisierung von dem wohl verbreitetsten Sicherheitsprotokoll im Internet dem SSL Protokoll unterst tzt wird und zwar sowohl client als auch serverseitig Der Einsatz dieses Standards bildet ebenfalls einen weiteren Eckpfeiler dieser Arbeit Leider ber cksichtigt das SSL Protokoll hierbei nicht den Speicherort und den jeweiligen lokalen Zugriffsschutz der Credentials so dass L sungen hierf r auf dar berliegenden Anwendungsebenen bereitgestellt werden m ssen Biometriebasierte Authentisierung Eine reine biometriebasierte Authentisierung im Kontext webbasierter Authentisierung ist zwar technisch denkbar allerdings kommt sie praktisch nicht bzw noch nicht vor In dieser Arbeit tritt eine biometriebasierte Authentisierung nur als lokaler Zugriffsschutz auf und zwar in der Weise dass digitale Zertifikate und zugeh rige pri
85. en Sicherheitskonzepte hinaus so bildet diese Arbeit ein Grundger st f r die kontinuierliche Erweiterung der Sicherheitsanforderungen und Sicherheitsma nahmen beim infoAsset Broker Aus diesem Grund geht diese Arbeit auf abstrakte Weise auf den Begriff Sicherheit ein Besch ftigt man sich mit Sicherheit so besch ftigt man sich mit Risiken oder Gefahren f r ein definiertes System die es vorausschauend abzuwehren gilt Da f r ein System stets neue Risiken oder Gefahren aufkeimen k nnen muss die Umsetzung von Sicherheit f r ein System stets als Prozess verstanden werden Aus diesem Grund beschr nkt sich die Sichtweise innerhalb dieser Arbeit nicht ausschlie lich auf die Umsetzung der vier genannten Sicherheitskonzepte Diese Sichtweise best tigt sich durch ein Sicherheitskonzept auf das innerhalb dieser Arbeit hingearbeitet worden ist welches allerdings nicht umgesetzt worden ist Verbindlichkeit Non Repudiation Die Umsetzung und die Art der Umsetzung der vier Sicherheitskonzepte bilden eine nachhaltige Grundlage um dieses Sicherheitskonzept erfolgreich umsetzen zu k nnen 2 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform 1 2 Gliederung der Arbeit Kap 2 erfasst die Grundlagen die zum Verst ndnis dieser Arbeit und der aufgezeigten L sungen erforderlich sind Diese umfassen zun chst die allgemeine Analyse des Sicherheitsbegriffs sowie der l sungsorientierten Sicherheitskonzepte
86. en bereits erw hnten Fehler Handler umgeleitet Sind die gew nschten Anmeldedaten allerdings beigebracht so findet die eigentliche Anmeldung statt die sich an der bisherigen Anmeldeprozedur der Portalplattform orientiert Als Besonderheit ist hier lediglich erw hnenswert dass die Anmeldung hier mit dem Instanziieren eines charakteristischen Authentisierungsobjekts abgeschlossen wird Dieses Hilfsobjekt der SWS Architektur repr sentiert den vom Benutzer durchgef hrten Authentisierungsmechanismus Es wird sp ter f r eine authentisierungsbasierte Autorisierung verwendet s Kap 4 bei der eine Autorisierung auch aufgrund der durchgef hrten Authentisierung erfolgen kann Bei jeder Anmeldung wird ein Objekt der Klasse AuthenticationMechanism das SSLSession Objekt gekn pft Aufgrund der in diesem Objekt festgelegten unver nderlichen Eigenschaften kann zu einem sp teren Zeitpunkt die Unterscheidung der durchgef hrten Authentisierung erfolgen Die Instanziierung des WUmleitungstemplates geschieht auf die in der Portalplattform bliche Weise Damit sind alle wichtigen Vorg nge w hrend der Anmeldung erkl rt Die SWS Architektur enth lt eine weitere Klasse namens Base64Decoder Ihre einzige Aufgabe ist die Umwandlung eines base64 kodierten Strings in einen menschlich lesbaren String um die Credentials einer http Authentisierung zu extrahieren Ihre Funktionalit t wird innerhalb des HTTPSConnection Threads verwendet Die Beschreibung
87. en sind sind Viren W rmer und Denial of Service Attacken DoS bzw dDoS Insgesamt kann man zusammenfassen dass die Ma nahmen die Netzwerksicherheit erzwingen sollen nicht prim r einen bestimmten Webdienst betreffen sondern auf die Nutzung zus tzlicher IT Infrastruktur sowie auf die sorgf ltige Planung der Netzwerkarchitektur ausgerichtet sind 10 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Sicherheitsmanagement Dieses Sicherheitskonzept befasst sich mit s mtlichen Ma nahmen die getroffen werden um neue zun chst unerkannte Risiken zu erkennen zu benennen zu analysieren und Strategien zu ihrer Verh tung zu entwickeln Dieses Konzept f hrt zu einem Sicherheitsverst ndnis bei dem Sicherheit nicht nur eine F lle von Ma nahmen ist sondern ein Prozess bei dem die Sicherheitsanforderungen kontinuierlich angehoben werden um das gew nschte System robuster gegen vorhandene Risiken zu machen Sicherheitsrichtlinien Dieses Sicherheitskonzept befasst sich mit der Definition von Vorgehensweisen zum Thema Sicherheit Viele Sicherheitsma nahmen k nnen leicht ausgehebelt werden wenn die betreffenden Personen im Umgang mit diesen Ma nahmen anders vorgehen als dies zun chst vorgesehen ist Sicherheitsrichtlinien versuchen dem entgegenzuwirken indem sie den betreffenden Personen eine eineindeutige Handlungsanweisung erteilen Dar ber hinaus kann f r unterschiedliche Zwecke
88. er Berechtigungen in die Architektur der Portalplattform zu erwirken Dies k nnte beispielsweise durch die Umwandlung von Berechtigungen zu Assets erreicht werden d h die Berechtigung als spezialisiertes Gesch ftsprozessobjekt zu verstehen Hierbei ist allerdings zun chst zu untersuchen ob durch diese Strategie nicht neue Sicherheitsrisiken entstehen k nnen 86 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Literatur und Quellenverzeichnis 01 02 Atmo1 BEASys01 502 85101 DPSign Eck02 5502 FNMT Fow98 Global G tz99 H r02 Holm01 ABO1a 010 2 250 02 01 Die E Business R Evolution Daniel Amor Galileo Press GmbH 2001 Sicherheit und Benutzerverwaltung im _Unternehmensportal PowerPoint Pr sentation Martina Armbruster SAP Portals SAP AG 2002 Atmel Technical SmartCard White Papers Atmel Corporation 2001 BEA WebLogic Portal Security Guide Version 4 0 eBook e docs bea com BEA Systems Inc 2001 BEA WebLogic Server Introduction to WebLogic Security BEA Systems Inc 2002 Theoretische Grundlagen von Sicherheitsstrukturen BMWi BMI BSI www sicherheit im internet de 2001 Deutsche Post Signtrust GmbH www signtrust de Web Site Root CA amp SmartCard Provider Thinking In Java 3rd Edition HTML Ausgabe
89. er Methode checkAuthority statt die die eigentliche Pr fung durch Delegation an die entsprechende Methode check durchf hrt Dar ber hinaus werden innerhalb der Methode checkAuthority die in Abs 4 1 beschriebenen alternativen Strategien liberal restriktiv etc implementiert Eine weitere untergeordnete Besonderheit liegt im Aufruf der Methode checkAuthority Diese k nnte an den ermittelten Pr fstellen prinzipiell direkt vom Session Objekt aus aufgerufen werden da der AuthorityManager ja ein Singleton ist Diesem Aufruf zwischengeschaltet ist allerdings das Dispatcher Objekt das eine gleichnamige Methode implementiert und den Aufruf ledigich an den AuthorityManager weiterdelegiert Die Berechtigung f r diesen scheinbaren Umweg liegt in der Tatsache begr ndet dass hierdurch die Zugriffspfade auf die Autorisierungsarchitektur klarer sind Der Dispatcher muss w hrend des Initialisierungsvorgangs der Zuordnungstabelle mehrmals auf den AuthorityManager zugreifen so dass durch diese Ma nahme die Anzahl der direkten Aufrufer geringer gehalten wird Dar ber hinaus findet in der zwischengeschalteten Methode des Dispatchers das Logging statt das festh lt wer den Zugriffsversuch unternimmt und ob der Zugriff gew hrt oder versagt wird Nachdem die Auswertungslogik von Berechtigungen ausf hrlich erl utert ist werden die genannten Ver nderungen innerhalb des Session Codes kurz skizziert GenericHandler h dispatcher getHandler documentId
90. er deklarativen Pr dikate der authorities txtin operative Berechtigungen hinl nglich erl utert Die Berechtigungszuordnung Nachdem die Instanziierung der deklarierten Berechtigungen erl utert ist soll die Umwandlung der deklarativen Zuordnung innerhalb der Dateien handler txt in die operative Zuordnung innerhalb des HandlerAuthorityMappers erl utert werden Wie bereits dargestellt erfordert diese Umwandlung eine Anpassung der Methode init String handlerTable innerhalb des Dispatchers gt Ein zweistufiger Prozess ist hierbei stets erforderlich 9 nicht verwechseln mit createComposedAuthority TUHH AB Softwaresysteme 79 Autorisierung Die Methode init liest eine handler txt als Properties Tabelle ein Da aufgrund der Autorisierungsarchitektur an den Klassennamen des Handlers das gew nschte Pr dikat angef gt wird wird die bisherige Initialisierung solche Eintr ge nicht bearbeiten k nnen Um den bisherigen Instanziierungscode f r Handler weiterhin verwenden zu k nnen m ssen die Eintr ge der Pr dikate innerhalb der Properties entfernt werden Gleichzeitig ist es allerdings erforderlich diese Zuordnung f r die Autorisierungsarchitektur zwischenzuspeichern Diese Aufgabe wird von der Methode extractAuthorityNames Properties properties der Klasse AuthorityManager durchgef hrt Innerhalb der init Methode wird diese Methode vor dem Instanziieren der Handler aufgerufen Sie stellt das urspr ngliche Format innerhalb der
91. erforderlichen Parameter k nnen an dieser Stelle aus einer Datei einer Datenbanktabelle ausgelesen werden Im vorliegenden Entwurf ist allerdings zun chst eine feste Verdrahtung der Parameter innerhalb dieser Methode vorgesehen Die von einem Konfigurationsobjekt bereitgestellten Parameter dienen zu Initialisierung der betreffenden SSL Server Sie haben im Einzelnen folgende Aufgaben ssIServerType String Dieses Attribut benennt die zu instanziierende SSL Server Implementierung anhand eines charakteristischen Schl sselwortes Die 38 finale Klassenattribute 52 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Instanziierung ber Schl sselw rter ist charakteristisch f r die Instanziierung einer Engine Klasse Aufgrund der vorhandenen SSL Server Implementierungen sind hier Werte aus der Menge default client_certificate smart_card erlaubt Analog einer Engine Klasse wird f r unbekannte Implementierungen die Ausnahme NoSuchAlgorithmException ausgel st 55 1 String Jedem SSL Server ist ein Handler zugeordnet ber den die Anmeldefunktionalit t f r den betreffenden SSL Server implementiert ist Der hierin befindliche String hat die Syntax security ssIXXXLogin htm wobei durch einen f r den SSL Server charakteristischen Namen zu ersetzen ist Dieser String ist au erordentlich wichtig da er zur Generierung einer dynamisch erzeugten Ve
92. erschachtelt sein Die Operanden eines logischen Ausdrucks sind hierbei selbst Pr dikate elementare oder zusammengesetzte Wichtig bei der Verwendung eines Pr dikats innerhalb eines Ausdrucks ist dass das Pr dikat auf der betreffenden Projektebene bereits deklariert ist d h es d rfen keine Pr dikate aus bergeordneten Projektebenen verwendet werden da die bergeordneten Projekte aus Sicht eines grundlegendes Projekts austauschbar sein m ssen Ein einfaches Beispiel f r ein zusammengesetztes Pr dikat w re alleAusserCesar NOT isPerson perera tu harburg de Nat rlich k nnen die boolschen Ausdr cke wesentlich komplexer als das hier genannte Beispiel sein Der Ausdruck alleAusserCesar k nnte nun in einer anderen zusammengesetzten Pr dikatsdefinition weiterverwendet werden 70 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Im Rahmen dieser Arbeit ist eine authorities txt als Referenz umgesetzt worden Sie ist im Projektverzeichnis broker zu finden Dies ist die grundlegende Projektebene f r s mtliche Projekte die mit Hilfe der Portalplattform erstellt werden Die Referenzdatei enth lt als Kommentar eine ausf hrliche Beschreibung ber die Syntax und ber die Art und Weise wie diese zu verwenden ist 4 2 3 Die Zuordnung von Berechtigungen zu Handlern Nachdem die Definition von Berechtigungen ausf hrlich erl utert worden ist wird die Zuordnung von Zugriffsrech
93. ert die in dem Zertifikat eingetragene Identit t und ihren ffentlichen Schl ssel Teilnehmer B schickt Teilnehmer A ein Nonce das von letzterem mit seinem privaten Schl ssel digital signiert werden muss Da nur der Zertifikatsinhaber den privaten Schl ssel kennt ist dieser als einziger in der Lage diese Signatur zu leisten Nun schickt Teilnehmer A Teilnehmer B das signierte Nonce Teilnehmer B wendet den aus dem Zertifikat extrahierten ffentlichen Schl ssel auf das signierte Nonce an F r den Fall dass das urspr nglich an Teilnehmer A gesendete Nonce tats chlich mit dem zum Zertifikat zugeh rigen privaten Schl ssel signiert wurde ergibt die Anwendung des ffentlichen Schl ssels auf das signierte Nonce wieder das urspr ngliche Nonce Da nur der Zertifikatsinnaber diesen privaten Schl ssel kennt und somit als einziger in der Lage gewesen sein kann die erforderliche Signatur zu leisten schlussfolgert Teilnehmer B im erfolgreichen Fall dass Teilnehmer A und der Zertifikatsinnaber miteinander identisch sind wodurch die Authentisierung gegeben ist Es wird erg nzend darauf hingewiesen dass keinerlei geheime Information ber den Kanal bertragen wird und damit kann die Gefahr der Kompromittierung dieser geheimen Information hier privater Schl ssel als deutlich geringer als bei der wissensbasierten Authentisierung eingesch tzt werden Bewertung Die Qualit t der Authentisierung wird in entschiedener Weise durch die Qualit
94. esse die E Mail Adresse der Identit t CN Common Name der volle Name der zertifizierten Identit t OU Organizational die Organisationseinheit der die Identit t zugeordnet Unit wird Organization die Organisation f r die die Identit t t tig ist L Location der Ort in dem sich die Identit t bl befindet S State die Region in dem sich der Ort befindet Country der Staat dem die Region zugeordnet ist Tab 1 Identit tsmerkmale in X 509 Zertifikaten 9 DSDK 1 4 1 21 mittels des Zertifikatsmanagementwerkzeugs keytool 22 www webopedia com TERM X X_500 html TUHH AB Softwaresysteme 31 Grundlagen Welche Variablen tats chlich vorkommen und somit auch Werte haben h ngt von der jeweiligen Zertifizierungsrichtlinie ab Ein X 509 Zertifikat enth lt zwei X 500 DNs ein DN f r den Aussteller certificate issuer der die Identit tsmerkmale der CA inkl der jeweiligen Zertifizierungsrichtlinie wiedergibt und DN f r den Inhaber certificate subject dessen Identit t durch das Zertifikat akkreditiert wird Bei selbstsignierten Zertifikaten sind beide DNs identisch F r diese Arbeit ist letztlich wichtig dass es einen Zertifikatsstandard gibt der von der verwendeten Zielumgebung unterst tzt wird und dessen Dateneintr ge im Rahmen einer Richtlinie als gesichert gelten k nnen Der X 509 Standard ist ein solcher Standard 2 3 3 3 Zertifikatsspeicher in Java serverseitige Betrachtung In Abschnitt
95. ext stehenden serverseitigen Abl ufe gesetzt Macht der Client die Anforderung einer sicheren Verbindung durch Einbeziehung eines https Requests so ist zun chst der SSL Handshake in einer Weise zu erf llen wie dieser durch die Konfiguration des SSL Servers bestimmt ist vgl 2 3 4 3 F r den Client stellt dies insbesondere dann eine H rde dar wenn die Konfiguration Client Authentisierung vorsieht Kommt eine erforderliche Client Authentisierung w hrend des SSL Handshakes nicht zustande so wird die gesamte Verbindung geblockt ohne dass irgendwelche Handler involviert w ren Auf diese Vorg nge hat man programmatisch nur durch die Konfiguration der SSLServerSockets Einfluss Ist nach einem Verbindungsversuch durch den Client der SSL Handshake erfolgreich abgelaufen so wird zun chst derjenige Handler in die Anmeldeprozedur involviert der durch den Target Parameter in der URL und durch den entsprechenden Eintrag in der handler txt festgelegt ist Hierbei existiert f r jeden vorkonfigurierten SSL Server je ein Handler der die entsprechende Anmeldeprozedur durchf hrt F r die drei vorkonfigurierten SSL Server existieren somit drei Anmelde Handler vgl Abb 22 Diese Handler befinden sich in bereinstimmung mit der Konvention beim TUHH AB Softwaresysteme 59 Vertraulichkeit Integrit t und Authentisierung Broker im Package de infoasset broker handler security Die betreffenden Handler hei en SSLPasswordLoginHandler
96. f hrung einer neuen Ma nahme zur Erh hung der Sicherheit diskutiert wird Leider sind solche quantitativen Betrachtungen allerdings hinf llig wenn festgelegte Rahmenbedingungen Sicherheitsrichtlinien nicht eingehalten werden Sind die bisherigen Sicherheitsma nahmen eines Systems als eher gering einzusch tzen so ist es sinnvoller den Sicherheitsgrad einzelner Authentisierungsma nahmen eher qualitativ zu bewerten Authentisierung beruht in vielen F llen darauf dass etwas vorgelegt wird was die vorgegebene Identit t best tigt Oft sind hierbei auch Merkmale vorhanden die sich rein auf die Identifizierung beziehen und nicht zur eigentlichen Verifizierung dienen Als Bezeichnung f r die zur Authentisierung erforderliche Vorlage wird hier der Begriff Credentials gew hlt z B um eine Spezifikation zu erf llen 14 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Definition Der Begriff Credentials bezeichnet die Summe aller Elemente die vorgelegt oder angewandt werden m ssen um eine erfolgreiche Authentisierung zu erm glichen Wie eingangs erw hnt sollen hier im Wesentlichen drei Authentisierungskategorien unterschieden werden die Authentisierung kann grunds tzlich auf Wissen Besitz oder Biometrie beruhen Bei wissensbasierter Authentisierung wird davon ausgegangen dass die sich authentisierende Identit t ber eine geheime Information verf gt die sie authe
97. f r die Anmeldung konfiguriert lt b gt lt td gt lt tr gt SsslServers isNotLoggedIn 2 lt tr gt lt td gt lt b gt Abmeldung lt b gt lt td gt lt td gt lt td gt lt tr gt lt tr align left valign baseline gt lt td gt lt img src skin images bullet gif gt lt a href javascript parent session show security sslLogoff htm gt Abmelden lt a gt lt td gt lt td gt Klicken Sie hier um sich abzumelden lt td gt lt tr gt SisNotLoqggedIn 58 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Zun chst findet eine Unterscheidung statt ob der jeweilige Client bereits angemeldet ist oder nicht Im Template u ert sich dies durch den Platzhalter isNotLoggedin F r den Fall dass der Client nicht angemeldet ist 1 wird der erste Teil des Templates ber cksichtigt Im zweiten Teil des Templates wird f r den Fall dass der Client doch angemeldet ist 2 eine Verkn pfung erzeugt die eine Abmeldeprozedur einleitet Innerhalb des ersten Template Teils befindet sich der Platzhalter ssIServers der im Handler von einem sog ListTemplate bearbeitet wird Auf diese Weise wird dynamisch f r jeden konfigurierten SSL Server eine eigene Verkn pfung erzeugt die wiederum eine eigene Anmeldeprozedur einleitet Wie aus dem Template Code ersichtlich ist ist das Ziel der Verkn pfung die bereits dargestellte Funktion SSLLogin F r den Fall dass keine SSL
98. ft ob es sich bei dem betreffenden Benutzer Ausf hrungskontext um eine ganz bestimmte Person handelt Attribut der Berechtigung Hierdurch k nnen Ressourcen einzelnen Individuen zug nglich gemacht werden w hrend sie f r alle anderen Benutzer unzug nglich sind e Die gruppenbasierte Berechtigung GroupbasedAuthority pr ft ob der betreffende Benutzer Kontext eine Mitgliedschaft in einer festgelegten Gruppe Attribut hat Hierdurch k nnen Ressourcen Gruppen zugeordnet werden w hrend sie f r andere Gruppen unzug nglich sind e Die rollenbasierte Berechtigung RolebasedAuthority pr ft ob der betreffende Benutzer Kontext eine Mitgliedschaft in einer festgelegten Gruppe und hierin eine festgelegte Rolle besitzt Attribute Hierdurch k nnen Zugriffsrechte auf der Basis von Rollen in Gruppen definiert werden e Die kategoriebasierte Berechtigung CategorybasedAuthority pr ft ob der betreffende Benutzer Kontext eine Mitgliedschaft in mindestens einer Gruppe der festgelegten Kategorie Attribut besitzt Hierdurch k nnen Zugriffsrechte f r Gruppenkategorien festgelegt werden Wie unschwer zu erkennen ist k nnen weitere Berechtigungstypen implementiert werden die weitere spezifische Autorisierungskonzepte umsetzen und die beliebig komplex sein k nnen Es ist hierbei auf eine aussagekr ftige Kategorisierung der Berechtigungstypen gem Abb 23 zu achten F r objektbasierte und authentisierungsbasierte Berechtigungen
99. ger einzusehen ist M chte man die Vertraulichkeit der Kommunikation gew hrleisten so ist die in den Paketen enthaltene Information vor dem Einblick der vermittelnden Knoten zu sch tzen Dies kann beispielsweise sinnvoll sein weil die bertragene Information ein Geheimnis darstellt welches zur Authentisierung eines Teilnehmers dient z B Passwort Authentisierung Definition Der Begriff Vertraulichkeit umfasst s mtliche Ma nahmen die eine Information vor der Offenlegung gegen ber nicht autorisierten Personen sch tzen 2 1 2 4 Integrit t Im weitesten Sinne bedeutet der Begriff Integrit t dass die Aufrichtigkeit und die Zuverl ssigkeit i d R einer Person nicht angezweifelt wird Dieser Begriff ist hier in entsprechender Weise auf Informationsinhalte anzuwenden Die Gew hrleistung der Richtigkeit der Information steht hierbei im Vordergrund Dies bedeutet insbesondere dass die Information vor Manipulation durch Dritte aber auch vor zuf lliger Ver nderung gesch tzt wird wie dies bei einer Informations bertragung geschehen kann Analog zum Begriff Vertraulichkeit ist beim Begriff Integrit t wieder haupts chlich die Kommunikation betroffen da bei der Speicherung und dem potentiellen Zugriff wieder Autorisierungsfragen vordergr ndig zu betrachten sind Ebenso wie die Information w hrend der bertragung ber das Internet Unbefugten bekannt werden kann vgl 2 1 2 3 kann die Information ggf auf ihrem Weg ma
100. gitale Handlung Um die Vertrauensw rdigkeit in digitale Zertifikate herzustellen existieren bergeordnete Entit ten die f r die Ausstellung der Zertifikate und die Richtigkeit ihrer Daten in gewissem Umfang verantwortlich sind Diese Entit ten die Zertifikate ausstellen werden Zertifizierungsautorit ten Certificate Authority CA genannt Zu den wichtigsten Aufgaben einer CA z hlen die berpr fung der in ein von ihr ausgestelltes digitales Zertifikat eingetragenen Angaben entsprechend der jeweiligen Zertifizierungsrichtlinie und die Sicherung der Datenintegrit t der Angaben mit ihrer eigenen digitalen Signatur Die Zertifizierungsrichtlinie der CA gibt dabei Auskunft dar ber in welchem Umfang die Angaben des Zertifikats vor seiner Ausstellung berpr ft werden und ggf in welcher Weise die CA f r die Richtigkeit der Angaben haftet Zertifizierungsrichtlinien k nnen sehr verschieden sein so dass dies die qualitative Aussagekraft eines Zertifikats entscheidend pr gt Beispielsweise kann eine einfache Zertifizierungsrichtlinie lediglich die Existenz einer E Mail Adresse unter Ausschluss jeglicher Haftung garantieren w hrend eine umfangreiche Zertifizierungsrichtlinie das pers nliche Erscheinen eines Gesch ftsf hrers bei der CA unter Vorlage eines aktuellen Handelsregisterauszugs fordern kann Unter ein von ihr ausgestelltes Zertifikat leistet die CA mit einem privaten CA Schl ssel der charakteristisch f r die jeweilige Zertifizier
101. gl 2 3 3 1 Die Signatur ist der mit dem privaten Schl ssel der CA asymmetrisch chiffrierte Hashwert des Zertifikatsinhalts Dementsprechend wird zur Signaturpr fung die Signatur mit dem ffentlichen Schl ssel der CA dechiffriert und der Hashwert des Zertifikats gebildet Stimmen beide Werte anschlie end berein so ist die Schlussfolgerung dass das vorgelegte Serverzertifikat tats chlich von der CA unterschrieben worden ist d h dass es nicht manipuliert worden ist Hieraus folgt noch nicht die Server Authentisierung da das vorgelegte Serverzertifikat ffentlich ist und somit im Prinzip von jedem vorgelegt werden kann Ist auf dem Client kein vertrauensw rdiges Zertifikat installiert mit dem eine Integrit tspr fung stattfinden k nnte so wird der Benutzer am Client aufgefordert die Sitzung abzubrechen das vorgelegte Zertifikat f r die anstehende Sitzung zu akzeptieren oder das vorgelegte Zertifikat als stets vertrauensw rdig zu akzeptieren Damit der Vorgang fortgesetzt wird muss sich der Benutzer f r eine der letzten beiden M glichkeiten entscheiden Ansonsten kommt die Verbindung nicht zustande 4 Client Master Key Der Client erzeugt einen Hauptsitzungsschl ssel master session key chiffriert ihn asymmetrisch mit dem ffentlichen Schl ssel des Servers welcher aus dem Serverzertifikat entnommen wird und schickt dem Server das Chiffrat Abb 12 Da der Zertifikatsinhaber n mlich der zertifizierte Server als einziger
102. glich da die bisher vorhandenen spezialisierten Klassen gegenw rtig weitestgehend zur Typisierung dienen Aus Abb 22 kann man entnehmen dass jedem spezialisierten SSL Server ein Handler zugeordnet ist Dieser bernimmt die Anmeldeprozedur f r den spezifischen SSL Server Auf Einzelheiten der Anmeldeprozedur wird im Abschnitt der die Implementierung betrifft eingegangen Die Klasse SSLWebServer implementiert das Interface Runnable damit jeder SSL Server innerhalb seines eigenen Threads l uft Die Implementierung dieses Interfaces erfordert die Implementierung der Methode run Innerhalb dieser Methode l uft eine Endlosschleife die eingehende Anfragen empf ngt und diese bearbeitet Das Prinzip ist somit das gleiche wie bei den Servern ohne SSL Der wesentliche Unterschied liegt hierbei in den verwendeten Sockets und ServerSockets SSL Server verwenden SSLSockets und SSLServerSockets der JSSE Architektur javax net ssl Ein SSL Server enth lt zwei wichtige Attribute ein Konfigurationsobjekt Instanz von SSLConfiguration und ein Objekt der Klasse SSLServerSocket Daneben h lt der SSL Server aus Kompatibilit tsgr nden mit der bisherigen Architektur das Broker Objekt All diese Attribute werden beim Initialisieren des SSL Servers zugeordnet Die Verwendung eines SSL Servers erfolgt gem dem Engine Pattern ber die Klassenmethode getinstance String type Diese liefert die durch den spezifizierte SSL Server Implementier
103. hende Sicherheitsgrad sein soll Nachdem man in der Risikoanalyse eine erste grobe Einsch tzung vorgenommen hat kann man sich den Detailfragen widmen Hierbei sind die zu sch tzenden Ressourcen die Gefahren die auf sie einwirken k nnten und die in Aussicht gestellten Sicherheitsma nahmen genauer zu benennen Bei der Festlegung der Sicherheitsma nahmen ist nat rlich der zuvor festgelegte Sicherheitsgrad zu ber cksichtigen Die festgelegten Sicherheitsma nahmen bilden gewisserma en die Anforderungsspezifikation der zu erstellenden Sicherheitsarchitektur Eine Er rterung der St rken und Schw chen der eingesetzten L sungskonzepte rundet hierbei die Risikoanalyse ab Bei der gesamten Analyse ist auf ausgewogenes Ma zwischen Sicherheitsanforderungen Benutzerfreundlichkeit und Kosten zu achten TUHH AB Softwaresysteme 11 Grundlagen 2 2 Eigenschaften der Zielplattform In diesem Abschnitt wird ein kurzer berblick ber das bestehende Zielsystem gegeben wobei sich der Schwerpunkt der Betrachtung auf diejenigen Aspekte konzentriert die f r diese Arbeit eine besondere Bedeutung haben Dem Zielsystem liegt eine internetbasierte Client Server Architektur zugrunde bei der Clients durch g ngige Browser verk rpert werden F r den programmiertechnischen Teil dieser Arbeit wurde dabei Netscape 7 0 verwendet Der Server besteht aus einem javabasierten Application Server dem eine dreischichtige Architektur zugrunde liegt Abb
104. hl ssel also der zertifizierte Server Chiffrat n ist hierzu in der Lage Client Anwendung Anwendung z B Browser z B Secure Web Server ClientWriteKey Alg 1 On ServerReadKey Alg 1 On ClientReadKey Alg 2 On ServerWriteKey Alg 2 On Abb 13 SSL Handshake Schreib und Leseschl ssel 6 Client Finish Der Client schickt dem Server ein Acknowledgement und wartet auf die Best tigung durch den Server Hierzu wird die CID aus 2 mit dem ClientReadKey symmetrisch verschl sselt und an den Server geschickt Da ClientReadKey und ServerWriteKey identisch sind ist dem Server bekannt dass der Client in der Lage ist die Nachrichten des Servers zu entschl sseln wenn beim Entschl sseln mit dem ServerWriteKey tats chlich die CID herauskommt 7 Server Verify Der Server antwortet dem Client mit dem durch den ServerWriteKey symmetrisch verschl sselten Challenge String aus 1 den der Client mit seinem ClientReadKey entschl sselt Ist der entschl sselte Challenge String mit dem aus 1 identisch so schlussfolgert der Client dass der Server den ServerWriteKey ermitteln konnte Abb 14 Aus der Kenntnis auf Seiten des 38 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Servers des ServerWriteKey folgert der Client weiter dass der Server hierzu vorher den Hauptsitzungsschl ssel hat ermitteln m ssen Da dies aus der bermittelten Information nur mit Hilfe des
105. hl ssel f r den Chiffrierschritt und der Schl ssel f r den Dechiffrierschritt grunds tzlich verschieden Sie sind bzgl des jeweiligen Verfahrens zueinander komplement r d h was man mit dem einen Schl ssel chiffriert wird mit dem komplement ren Schl ssel dechiffriert Mit welchem der beiden Schl ssel eine Chiffrierung stattfindet h ngt von der jeweiligen Anwendung ab Bei asymmetrischen Chiffrierverfahren hat jeder Teilnehmer eines Kommunikationsnetzwerks zwei Schl ssel einen ffentlichen Schl ssel public K pub und einen komplement ren privaten Schl ssel private key Der 24 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform ffentliche Schl ssel eines Teilnehmers ist allen anderen Teilnehmern des Netzwerks zug nglich w hrend der private Schl ssel lediglich dem Teilnehmer selbst bekannt ist Findet eine Chiffrierung mit dem ffentlichen Schl ssel K pub statt so kann das Chiffrat nur von dem Teilnehmer mit dem komplement ren privaten Schl ssel dechiffriert werden Auf diese Weise kann dem betreffenden Teilnehmer eine vertrauliche Nachricht zugesandt werden Findet eine Chiffrierung mit dem privaten Schl ssel priv statt so kann das Chiffrat von allen anderen Teilnehmern unter Zuhilfenahme des jeweiligen ffentlichen Schl ssels dechiffriert werden Auf diese Weise kann die Best tigung eines Sachverhalts durch einen Teilnehmer erfolgen Die Best tigung
106. hl sselw rter NOT AND oder OR so wird geschlussfolgert dass es sich um einen zusammengesetzten Berechtigungsausdruck handelt In diesem Fall wird die Methode createComposedAuthority aufgerufen um den Ausdruck zu parsen F r einen elementaren Berechtigungsausdruck wird die Methode createSimpleAuthority aufgerufen Die Methode createSimpleAuthority instanziert den entsprechenden Berechtigungstyp initialisiert die Berechtigung und tr gt sie unmittelbar in die authorityNamesAndinstances Hashtable ein Der Vorgang und evtl auftretende Fehler werden hierbei geloggt Parsen zusammengesetzter Berechtigungen Handelt es sich um einen zusammengesetzten Berechtigungsausdruck so wird die Methode createComposedAuthority aufgerufen Diese Methode generiert zun chst ein Objekt der Klasse AuthorityTree Hierbei handelt es sich um ein Datenobjekt das zwei Attribute enth lt Das erste Attribut wird von dem Pr dikat selbst gebildet Das zweite Attribut enth lt den Wurzelknoten eines bin ren Baumes welches aus dem Berechtigungsausdruck generiert wird Objekte der Klasse AuthorityTree sind Zwischenrepr sentationen zusammengesetzter Berechtigungen Diese Objekte werden in einer eigens implementierten Collection namens AuthorityTreeCollection gespeichert Sie besitzt zudem einen eigens implementierten Comparator namens AuthorityTreeComparator der ein sehr spezielles Sortierkriterium f r die Collection bereitstellt Zusammenfassend l sst sich sage
107. hmern zu schlie en bzw die Erm glichung von Rechtshandlungen auf digitalem Wege Es d rfte offensichtlich sein dass die bisher genannten Sicherheitskonzepte zur Erf llung dieses Konzepts notwendig sind So muss nat rlich klar sein wer einen Vertrag abschlie t oder eine Rechtshandlung vollzieht Authentisierung es muss im Vorfeld des Abschlusses oder des Rechtshandlungsvollzugs gepr ft werden ob derjenige zu dieser Handlung berechtigt ist Autorisierung und die zu vereinbarenden Bedingungen d rfen w hrend der Verhandlungen bzw die Rechtshandlungen d rfen w hrend ihrer Aus bung weder Unbefugten bekannt Vertraulichkeit noch von Saboteuren manipuliert Integrit t werden Dar ber hinaus m ssen vereinbarte Vertr ge oder vollzogene Rechtshandlungen juristisch ihrem nicht digitalem Pendant gleichgestellt sein Hierbei spielen zwei Dinge eine Rolle Zun chst muss der Gesetzgeber solche digitalen Vereinbarungen bzw Handlungen juristisch uneingeschr nkt akzeptieren d h dass es eine gesetzliche Regelung geben muss damit solche Vereinbarungen oder Handlungen als Gegenstand einer gerichtlichen Auseinandersetzung zugelassen werden k nnen Zum zweiten muss technisch nachvollziehbar sein dass jemand einen solchen digitalen Vertrag eingegangen ist bzw dass jemand eine Rechtshandlung auf digitalem Wege vollzogen hat damit die Durchf hrung der entsprechenden Handlung nicht zur ckgewiesen werden kann Gegenstand dieser Arbeit sind na
108. hode check bei einer zusammengesetzten Berechtigung beschr nkt sich hierbei darauf die Methode n check rekursiv aufzurufen und die Ergebnisse in entsprechender logischer Weise zu einem Resultat zu kombinieren Abb 23 zeigt die abstrakte Klasse Authority die eine Generalisierung einer jeden Berechtigung darstellt Dem untergeordnet sind die drei abstrakten Klassen die zur Kategorisierung der elementaren Berechtigungstypen dienen SubjectbasedAuthority ObjektbasedAuthority und AuthenticationbasedAuthority Elementare Berechtigungstypen sind in der genannten Abbildung nicht sichtbar Ebenfalls der Klasse Authority untergeordnet sind die drei Klassen f r zusammengesetzte Berechtigungen zu sehen die jeweils eine der drei zu implementierenden Operationen repr sentieren NotAuthority AndAuthority und OrAuthority 66 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform SuhjecthasedAuthority check boolean initvoid OhjecthasedAuthority check boolean initvoid A AndAuthority lefAuthority Authority rightAuthority Authority checkboolean AndAuthority AuthenticationhasedAuthority checkhoolean initvoid OrAuthority leftAuthority Authority rightAuthority Authority checkhoolean OrAuthority NotAuthority authority Authority checkhoolean NotAuthority igungen TUHH AB Softwaresysteme
109. hr nkt der gesamten Internetgemeinde zur Verf gung Um einen solchen Dienst zu verwenden muss ein potentieller Client seine Anforderung lediglich an den dienstanbietenden Server unter Verwendung des richtigen Protokolls und des richtigen Ports senden Ob der Client zur Anforderung des gew nschten Dienstes berechtigt ist wird von dem dienstanbietenden Server grunds tzlich in keiner Weise berpr ft In vielen F llen ist es allerdings erforderlich die zur Verf gung stehenden Ressourcen vor der Verwendung zu sch tzen Ein solcher Verwendungsschutz wird in Form von Rechten dargestellt die den einzelnen Ressourcen zugeordnet werden k nnen und den Zugriff auf diese regeln Im Allgemeinen ist es somit erforderlich Rechte durch geeignete Ma nahmen zu definieren die einzelnen Ressourcen auf Rechte abzubilden und die durch das zugeh rige Recht beschriebenen Voraussetzungen beim Zugriff auf eine Ressource zu berpr fen Die durch ein Recht beschriebenen Voraussetzungen k nnen sich auf eine Vielzahl von Eigenschaften beziehen Typische Eigenschaften sind die Identit t des Benutzers bzw seine Stellung innerhalb einer Organisation oder der Zustand der Ressource auf die zugegriffen werden soll Beruht die Autorisierung auf der Identit t des Benutzers oder damit korrelierte Bereiche so ist offensichtlich dass eine Authentisierung des Benutzers hierf r eine Grundvoraussetzung ist Im engeren Sinne bedeutet Autorisierung somit dass Zugriffsrechte
110. ht Hierbei handelt es sich um Java Packages die eine Implementierung von SSL Funktionalit t in Java bereitstellen Seit der Version J2SDK v1 4 ist JSSE Bestandteil der Grundentwicklungsumgebung Die SSL Funktionalit t ist in drei Packages enthalten javax net javax net ssl und javax security cert wobei das Package javax net ssl den Kern bildet javax net enth lt lediglich zwei Klassen die Abstraktionen des Socket Factory bzw des Server Socket Factory Konzepts bilden und javax security cert dient lediglich der R ckw rtskompatibilit t und soll f r zuk nftige Projekte ausdr cklich nicht verwendet werden Abb 20 zeigt die wichtigsten Klassen und Interfaces des JSSE und ihren Wirkungszusammenhang Im Mittelpunkt dieser Darstellung steht die Klasse SSLContext die zum einen die tats chlich verwendete SSL TLS Version charakterisiert und zum anderen das Verbindungsglied zwischen Schl ssel und Vertrauensmaterial sowie Zufallszahlengenerator auf der einen Seite und den Netzwerksockets und ihren Factories auf der anderen Seite bildet In der praktischen Verwendung ist diese Klasse allerdings nur von Bedeutung wenn man selbstprogrammierte KeyManager bzw TrustManager verwenden m chte Da in dieser Arbeit die generelle Sicherheitsarchitektur im Mittelpunkt steht und keine optimierte Verwendung des SSL Protokolls wird zun chst auf die Verwendung selbstprogrammierter Manager verzichtet In dieser Arbeit werden zun chst die Standardm
111. htung verdienen sind innerhalb dieser Arbeit ebenfalls identifiziert worden Zum Teil werden hierf r in 5 2 L sungsans tze vorgeschlagen Dies gilt insbesondere f r das Sicherheitskonzept Verbindlichkeit vgl 5 2 1 Dar ber hinaus sind innerhalb dieser Arbeit eine F lle von sicherheitsrelevanten Grundlagen zusammengetragen worden die eine Sensibilisierung f r das Thema Sicherheit f rdern Im Ergebnis erh lt man eine Portalplattform die gegen ber der Ausgangssituation erheblich sicherer ist und die durch die in dieser Arbeit gemachten Vorschl ge noch sicherer gemacht werden kann 5 2 Ausblick Die im Rahmen dieser Arbeit implementierten Sicherheitsma nahmen bilden beim infoAsset Broker den Grundstein f r die kontinuierliche Weiterentwicklung der Sicherheitsarchitektur Eine solche Weiterentwicklung kann einerseits durch Erweiterung der Sicherheitsarchitektur d h durch das Erkennen neuer Risiken und durch die Implementierung neuer Sicherheitskonzepte stattfinden und andererseits durch die Verbesserung bereits implementierter Ma nahmen In diesem Kapitel sollen Beispiele f r sinnvolle Weiterentwicklungen dieser Architektur genannt werden Dies verdeutlicht auch wieso die Integration von Sicherheitsma nahmen als Prozess zu verstehen ist 5 2 1 Das Sicherheitskonzept Verbindlichkeit Die integrierte Umsetzung des Sicherheitskonzeptes Verbindlichkeit stellt mit Sicherheit eine ganz besondere Herausforderung dar Dies gilt insbes
112. ie Portalplattform die f r diese Arbeit von Bedeutung sind Auf einzelne Details die zus tzlich f r die L sung einzelner Probleme wichtig sind wird dabei an gegebener Stelle eingegangen Kap 3 und Kap 4 3 f r weitere Information zur Portalplattform siehe u a TUHH AB Softwaresysteme 13 Grundlagen 2 3 Technologien In diesem Abschnitt werden s mtliche technologischen Grundlagen der Sicherheitskonzepte dargestellt die f r diese Arbeit eine wichtige Rolle spielen 2 3 1 Authentisierung Dieser Abschnitt gibt zun chst einen berblick wie Authentisierung konzeptionell durchgef hrt werden kann um anschlie end auf prinzipiell technische Umsetzungsm jglichkeiten einzugehen die f r diese Arbeit eine Rolle spielen 2 3 1 1 Konzepte zur Authentisierung Wie in Abschnitt 2 1 2 1 definiert ben tigt man Ma nahmen um eine auf irgendeine Weise vorgegebene Identit t zu verifizieren Unter Identit t ist hier haupts chlich die Identit t einer Person oder die Identit t eines Hosts oder Webdienstes zu verstehen Die wichtigsten Authentisierungsma nahmen lassen sich f r den spezifizierten Problembereich in drei Kategorien gliedern wobei auch Mischformen h ufig vorkommen Jede Kategorie und jede Ma nahme f r sich besitzt hierbei spezifische konzeptionelle Vor und Nachteile Dar ber hinaus kann eine Ma nahme die aus konzeptioneller Sicht als besonders sicher zu bewerten ist in ihrer technischen
113. ie erforderliche Information i d R sehr schwer reproduzierbar ist bzw sein sollte wodurch man gegen ber der wissensbasierten Authentisierung qualitativ einen h heren Sicherheitsgrad erreicht Wie bei der Erl uterung der digitalen Zertifikate noch gezeigt wird ist das Verwenden digitaler Zertifikate mit einem nicht unerheblichen Aufwand verbunden Dar ber hinaus erfordert die Verwendung von Zertifikaten ein gewisses Grundwissen so dass man sagen kann dass ihre Verwendung weniger benutzerfreundlich ist Bei der Verwendung von Zertifikaten auf SmartCards wird zudem noch weitere Hardware ben tigt All diese zuletzt genannten Eigenschaften haben dazu gef hrt dass sich besitzbasierte Authentisierung clientseitig noch nicht durchgesetzt hat Eine zunehmende Sensibilit t f r Sicherheitsaspekte k nnte dies aber ndern Biometriebasierte Authentisierung beruht auf der Tatsache dass ein Benutzer sich mit seinen charakteristischen biometrischen Eigenschaften gegen ber seinem Kommunikationspartner authentisiet Typische Beispiele hierf r sind der Fingerabdruck die Stimmcharakteristik die Gesichtsform die Augen die DNA etc Die besondere St rke biometriebasierter Authentisierung ist die sehr hohe konzeptionelle Sicherheit dieses Ansatzes So sind die genannten biometrischen 8 namentlich zertifikatsbasierte 16 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Merkmale i d R eineindeut
114. ierung verdeutlicht werden Ein digitales Zertifikat verkn pft auf untrennbare Weise eine Identit t mit einem ffentlichen Schl ssel Beide Informationen sind u a in einem Zertifikat eingetragen wobei die Integrit t des Zertifikats gesichert wird Die Integrit t des Zertifikats garantiert die Untrennbarkeit der beiden Informationen wobei hier nicht darauf eingegangen wird wie dies geschieht Zu jedem ffentlichen Schl ssel existiert ein privater Schl ssel s 2 3 2 3 der ausschlie lich dem Zertifikatsinnaber bekannt sein sollte Die Credentials dieses Authentisierungsverfahrens bestehen aus dem digitalen Zertifikat und dem zugeh rigen privaten Schl ssel wobei die Vorlage des Zertifikats zur Identifizierung und die Anwendung des privaten Schl ssels zur Authentisierung dienen Abb 4 verdeutlicht das Authentisierungsprotokoll in generischer Weise 13 Wong00 TUHH AB Softwaresysteme 19 Grundlagen dig Zertifikat N 3 Nonce 5 n Nonce Teilnehmer A Teilnehmer B privater 2 dig Zertifikat Schl ssel A 09 Identit t ffentlicher 4 Schl ssel Om A 6 Omi _m Nonce Nonce Authentisierung Teilnehmer A Identit t Abb 4 Authentisierungsprotokoll mit digitalem Zertifikat Zun chst bertr gt derjenige Teilnehmer A der sich authentisieren m chte sein Zertifikat an denjenigen Teilnehmer B der die Authentisierung anfordert Teilnehmer B extrahi
115. ieser Stelle noch mal darauf hingewiesen dass die in dieser Arbeit zu Testzwecken verwendeten Zertifikate alle kostenlos gewesen sind da die zu ihrer Ausstellung geh rigen Richtlinien praktisch keine echte Identit tsverifikation vorsehen Verwendet man die zertifikatsbasierte Client Authentisierung des infoAsset Brokers f r eine betriebswirtschaftliche Anwendung oder gar im eGovernment Bereich so m ssen nat rlich auch die Ausstellungsrichtliiniien der verwendeten Zertifikate den Bed rfnissen der jeweiligen Anwendung entsprechen Aus rein technischer Sicht ist eine weitere Verbesserung der SWS Architektur denkbar M chte man weitere Konzepte w hrend des SSL Handshakes erm glichen so kann eine Instanziiercung der Klasse SSLContext die von der Standardinstanziierung abweicht durchgef hrt werden Dies ist beispielsweise sinnvoll wenn man eine eigene Implementierung eines TrustManagers nutzen m chte Ein m gliches Anwendungsszenario f r eine solche Ma nahme ist gegeben wenn man Certificate Revocation Lists CRLs implementieren m chte um gesperrte Zertifikate erkennen zu k nnen 5 2 3 Autorisierung Verbesserungsvorschl ge Die Erweiterungsm glichkeiten innerhalb der Autorisierungsarchitektur sind in Kap 4 dargestellt worden Die Architektur sieht vor da weitere Berechtigungstypen programmatisch eingef gt werden Die bereits implementierten Berechtigungstypen k nnen hierbei als Referenzimplementierungen dienen Dies kann le
116. ig f r die betreffende Identit t Die Schw chen liegen im oftmals hohen technischen Aufwand der erforderlich ist um die biometrischen Eigenschaften auf nahezu f lschungssichere Weise festzustellen Dar ber hinaus m ssen die jeweils gemessenen biometrischen Eigenschaftsdaten mit Referenzdaten verglichen werden die ihrerseits in einem sicheren Speicher gehalten werden m ssen Schlie lich m ssen die Messdaten unter Gew hrleistung der Vertraulichkeit vom Messger t zu diesem sicheren Speicher bertragen werden um dort verglichen werden zu k nnen All dies spricht f r eine lokale Anwendung d h einem Verfahren bei dem Messdatengewinnung bertragung und Referenzdatenvergleich in einem Ger t stattfindet Ein solches Ger t w rde bei positivem Vergleich aktiviert werden d h in einen Zustand versetzt werden der einen erfolgreichen Vergleich der Mess mit den Referenzdaten best tigt und durch die Aktivierung die Authentisierung hervorrufen 2 3 1 2 Umsetzung webbasierter Authentisierung Im vorangegangenen Abschnitt sind wesentliche Konzepte der Authentisierung vorgestellt worden In diesem Abschnitt werden diese Konzepte aufgegriffen und es wird diskutiert wie die f r diese Arbeit ma geblichen technischen Umsetzungen im Detail aussehen Hierbei werden im Einzelnen die technischen Prinzipien beschrieben ohne jedoch auf Implementierungsdetails bei der Zielplattform einzugehen Wissensbasierte Authentisierung Eine der wohl b
117. inaus existieren weitere nicht weniger wichtige Sicherheitskonzepte deren Umsetzung nicht Gegenstand der vorliegenden Arbeit ist Sie sollen hier allerdings benannt und kurz erkl rt werden um ein m glichst weitreichendes Bild der Sicherheitskonzepte darzustellen Dar ber hinaus ist es nat rlich denkbar dass bestehende Risiken noch nicht erkannt worden sind und dass deshalb kein zugeordnetes Sicherheitskonzept bekannt ist Aus diesem letzten Grund gibt die folgende Darstellung lediglich den aktuellen Stand der Dinge wieder Physische Sicherheit Dieses Sicherheitskonzept befasst sich mit den Ma nahmen die ergriffen werden um IT Infrastruktur vor physischen Eingriffen oder unerlaubten physischen Zug ngen zu sch tzen Gemeint sind somit Zugangskontrollen zu IT Anlagen der Schutz der Energieversorgung der IT Anlagen sowie evtl K hlvorrichtungen der Schutz der IT Anlagen vor Zerst rung der Schutz der IT Leitungen vor dem potentiellen Anzapfen das Verhindern von Informationsgewinnung aus der elektromagnetischen Abstrahlung Abschirmung und dergleichen Nat rlich sind viele der hier als Beispiel genannten Ma nahmen nur insofern sinnvoll wie der Wert der Information oder des IT Dienstes dies rechtfertigt Die Umsetzung dieser Ma nahmen erfordert zwar IT Kenntnisse sie sind allerdings nicht prim r dem IT Bereich zuzuordnen Netzwerksicherheit Dieses Sicherheitskonzept befasst sich mit Ma nahmen die netzwerkimmanente Risiken
118. ind zwei Dinge sicherzustellen Zun chst muss das zugewiesene Pr dikat auf der betreffenden Projektebene oder darunter deklariert worden sein s 4 2 2 Au erdem darf dem betreffenden Handler nicht schon auf einer grundlegenden Projektebene ein Pr dikat zugewiesen worden sein Diese letzte Forderung stellt sicher dass die Autorisierungsarchitektur nicht durch eine Neuzuordnung der Rechte auf einer Ebene die hierf r keine Kompetenz hat ausgehebelt wird TUHH AB Softwaresysteme 71 isierung Autor 10181045 S Mana Japeayhuouny huoyny pionu 88 004 2942 5 aievea LYU 45 4 592004
119. ine Anfrage an einen CRL Server der CA geschickt Beide Strategien haben jeweils Vor und Nachteile Aus diesem Grund empfiehlt sich der Einsatz einer Mischl sung um diesbzgl den h chsten Sicherheitsgrad zu erreichen Da CRLs f r die vorliegende Arbeit eine untergeordnete Rolle spielen soll hierauf nicht weiter eingegangen werden 19 Richtwert w chentlich 30 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform 2 3 3 2 509 Ein Standard f r digitale Zertifikate Im vorangegangenen Abschnitt sind die Konzepte digitaler Zertifikate in allgemeiner Weise beschrieben worden Die Betrachtungen in diesem Abschnitt konzentrieren sich auf einen speziellen Zertifikatsstandard dem X 509 Standard Obwohl nat rlich auch weitere Standards digitaler Zertifikate existieren wie beispielsweise der Pretty Good Privacy Standard PGP ist der X 509 Standard am weitesten verbreitet und zugleich auch der einzig unterst tzte Standard von der verwendeten Programmierumgebung Vor allem aus dem letzten Grund ist er f r diese Arbeit der einzig bedeutungsvolle Der X 509 Standard existiert seit 1988 in der Version 1 X 509v1 Der 2 7 gebr uchliche Industriestandard ist der X 509v3 Standard Er weicht nur geringf gig von der ersten Version ab In der dritten Version ist es m glich die Zertifikate durch sog Erweiterungen extensions an individuelle Bed rfnisse anzupassen Diese M glichkeit wird bei
120. ingerprints bietet die erforderliche Sicherheit dass das selbstsignierte Zertifikat tats chlich dasjenige der CA ist das es zu sein vorgibt Zusammenfassend kann man sagen dass i d R jeder Teilnehmer eine Ansammlung von vielen selbstsignierten Zertifikaten besitzt die er zu unterschiedlichen Zwecken als vertrauensw rdig eingesch tzt hat und die als Vertrauensanker der Integrit ts berpr fung von Zertifikaten der Kommunikationspartner dienen Zugleich hat jeder Teilnehmer der selbst digitale Handlungen vornehmen muss mindestens ein digitales Zertifikat dessen privaten Schl ssel der Teilnehmer besitzt und das i d R von einer CA fremdsigniert ist 18 implizit oder explizit TUHH AB Softwaresysteme 29 Grundlagen Zertifikatsr cknahme certificate revocation Die bisher dargestellten Sachverhalte beschreiben die wesentlichen Eigenschaften des Paradigmas digitaler Zertifikate Alle weiteren Eigenschaften im Kontext digitaler Zertifikate sind hiervon abgeleitet oder sekund r Ahnlich wie reale Ausweise besitzen auch digitale Zertifikate i d R einen G ltigkeitszeitraum In einem digitalen Zertifikat wird dies durch die Eintragung der Daten die den G ltigkeitsbeginn und das G ltigkeitsende kennzeichnen realisiert Ein Teilnehmer hat also zus tzlich zu der erforderlichen Integrit ts und Vertrauensw rdigkeitspr fung die G ltigkeit des Zertifikats zu beachten Dies ist prinzipiell ein recht simpler Vorgang da er hierf
121. ionsrepr sentation abgebildet Chiffrat und vom berechtigten Empf nger wieder zur ckverwandelt ohne dass die Semantik der Information verloren geht Zu diesem Zweck werden parametrisierte Funktionen eingesetzt bei denen der Funktionsparameter einen Schl ssel f r die jeweilige Transformation bildet s Funktionsabbildung in 2 3 2 2 Die hierf r erforderlichen Abbildungen gliedern sich prinzipiell in zwei Kategorien Bei der symmetrischen Kryptographie sind der Schl ssel f r den Chiffrierschritt und der Schl ssel f r den Dechiffrierschritt identisch so dass dieser sowohl Sender als auch Empf nger bekannt sein muss Bei der asymmetrischen Kryptographie sind die zuvor genannten Schl ssel grunds tzlich verschieden so dass es einen Chiffrierschl ssel und einen komplement ren Dechiffrierschl ssel gibt Ein dritter Bereich der Kryptographie die Kryptoanalyse befasst sich mit der Dechiffrierung ohne Kenntnis des erforderlichen Schl ssels und der Entwicklung von Verfahren die dem dienlich sind Die Kryptoanalyse verfolgt hierbei zwei Absichten Die erste ist die Analyse der Sicherheit der kryptographischen Verfahren die man selbst einsetzt Die zweite ist schlichtweg das Aufdecken fremder Information um sie sich i d R in unberechtigter Weise zunutze zu machen Abb 5 zeigt ein Organigramm mit den beschriebenen Begriffen Die Themen die f r diese Arbeit von besonderer Bedeutung sind wurden in Fettschrift hervorgehoben Abb
122. ist dann auf die genannte Weise durch alle anderen Teilnehmer berpr fbar und nachweisbar Hierauf beruht die Technik f r die Umsetzung digitaler Signaturen Asymmetrische Chiffrierverfahren werden i a zur Vereinbarung geheimer Information w hrend einer Sitzung Vereinbarung des geheimen Schl ssels zur Authentisierung im Zusammenhang digitalen Zertifikaten und f r die digitale Signatur verwendet Typische Schl ssell ngen liegen i d R im Bereich zwischen 512 und 2048 Bit wobei zurzeit 1024 Bit als hinreichend sicher angenommen wird Es existieren weitaus weniger asymmetrische als symmetrische Verfahren Die bekanntesten Verfahren sind Rivest Shamir Adleman RSA Diffie Hellman DH und Digital Signing Algorithm DSA wobei f r diese Arbeit das RSA Verfahren im Vordergrund steht Asymmetrische Verfahren sind weitaus weniger performant als symmetrische Verfahren Es besteht hier allerdings nicht die Notwendigkeit einer Schl sselvereinbarung ber einen sicheren Kanal Ein weiterer Vorteil der asymmetrischen Verfahren ist die Haltbarkeit der Schl sselpaare Diese haben i d R eine erheblich l ngere G ltigkeit z T Jahre als geheime Schl ssel Schlie lich w chst in einem Kommunikationsnetzwerk die Anzahl der Schl ssel linear mit der Anzahl der Teilnehmer was durchaus handhabbar ist 2 3 2 4 Hybride Chiffrierverfahren Die beiden vorangegangenen Abschnitte haben verdeutlicht dass sowohl symmetrische als auch asymmetrische
123. jenigen Werte ersetzt die die Funktion erh lt Der Parameter hostname repr sentiert die Dom ne der unsicheren Verbindung da ja SSL Server und WebServer ohne SSL auf dem gleichen Rechner laufen und somit der Hostname nicht ver ndert werden muss Die Funktion replace berschreibt gleichzeitig auch den History Eintrag im Browser 4 Broker projects broker templates html de home default htm 45 DOM Domain Object Model 5 JavaScript Tutorial http js tut aardon de js tut Anhang TUHH AB Softwaresysteme 57 Vertraulichkeit Integrit t und Authentisierung Der Aufruf der JavaScript Funktion SSLLogin bewirkt somit dass serverseitig der SSL Server mit der entsprechenden Portnummer in den Verbindungsaufbau involviert wird Dieser f hrt zun chst einen SSL Handshake entsprechend seiner Konfiguration durch Bei einem erfolgreichen Handshake kommt eine Verbindung zustande bei einem erfolglosen Handshake zeigt der Browser des Clients hingegen eine Fehlermeldung an die au er einem Fehlercode keine weitere Information ber die Art des Fehlers liefert Ist die Verbindung zustande gekommen so wird das gesamte Frameset ber die sichere SSL Verbindung neu geladen wobei im Content Frame die Seite die durch den Parameter ss Target definiert ist geladen wird Angemerkt sei noch dass bei diesem Vorgang eine neue Sitzung mit einer neuen sessionld eingeleitet wird Dies ist in so fern unproblematisch als dass der Client vor
124. keiten und deren berwindung bei der Implementierung sowie erkannte Probleme erkl rt worden 62 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform 4 Autorisierung In diesem Kapitel wird die Umsetzung des Sicherheitskonzeptes Auftorisierung bei der Portalplattform erl utert Dabei wird gem den Ausf hrungen in Abschnitt 2 1 2 2 zun chst auf konzeptioneller Ebene definiert welche sch tzenswerte Ressourcen mit Zugriffsrechten zu versehen sind und wie mit diesen Rechten umgegangen werden kann Definition Zuordnung Kombination etc Im Anschluss wird erl utert wie die Autorisierungsarchitektur aufgebaut ist Abschlie end wird auf Detailfragen zur Initialisierung von Zugriffsrechten eingegangen 4 1 Konzeption In Abschnitt 2 1 2 2 ist bei der Erl uterung des Sicherheitskonzeptes Autorisierung in abstrakter Weise von Rechten und zu sch tzenden Ressourcen gesprochen worden F r eine Umsetzung ist es erforderlich diese Sichtweise zu konkretisieren und auf die Gegebenheiten bei der Portalplattform anzupassen Betrachtet man das Schichtenmodell der Portalplattform vgl Abb 1 und vergegenw rtigt man sich die Ausf hrungen in Abs 2 2 so kann man unmittelbar zwei sch tzenswerte Arten von Ressourcen erkennen die Anwendungslogik die durch die Handler verk rpert wird und die persistente Information die durch die Assets verk rpert wird Sch tzt man die Handler vor nicht autorisiertem
125. ktur ebenfalls f r die Zuordnung von Pr dikaten verwendet werden und da die bisherige Funktionalit t der Portalplattform f r die Zuordnung von documentlds zu Handlern weiterhin verwendet werden soll ist es erforderlich dass die jeweiligen Zuordnungen von Berechtigungen zu Handlern aus den String Repr sentationen entfernt und f r eine sp tere Verwendung zwischengespeichert werden Dar ber hinaus wird in jedem Iterationsschritt die handler txt einer Projektebene abgearbeitet so dass dieser Mechanismus ebenfalls zum Abarbeiten der betreffenden authorities txt verwendet werden kann Um diese komplexen Sachverhalte n her zu erl utern werden hier wichtige Codefragmente aufgef hrt Diese Initialisierungsprozedur ist Bestandteil des Konstruktors der Klasse Broker Initialisierung der Zuordnung von documentIds zu Handlern roots new String tok countTokens for int i 0 i lt roots length 1 roots il hom t File separator projects File separator tok nextToken log debug broker root roots i roots i enth lt die Namen der jeweiligen Projektpfade ie 0 Anzahl der Projektebenen 1 if automaticHandlerReload this dispatcher new ReloadingDispatcher services else this dispatcher new SimpleDispatcher services dispatcher init definiert den zu verwendenden Dispatcher Dispatcher ist abstrakt und initialisiert diesen vererbte Methode der abstrakten K
126. lasse 76 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform for int i roots length 1 i gt 0 i start at broker dispatcher init roots i File separator handler txt iteriert ber die Projektebenen wobei der Dispatcher mit der handler txt der jeweiligen Projektebene initialisiert wird Die Iteration ber die verschiedenen Projektebenen findet in der letzten for Schleife statt Bis dahin sind somit keine nderungen erforderlich da die bisherige Zuordnung von documentlds zu Handlern unver ndert fortbestehen sol Um den Iterationsmechanismus f r die eigene Architektur zu nutzen Instanziierung der Berechtigungen aus der authorities txt ist der Konstruktor der Klasse Broker innerhalb der for Schleife und ggf dar ber hinaus zu editieren Um auf die ver nderten Gegebenheiten im Zusammenhang mit der handler txt einzugehen Entfernen und Zwischenspeichern der Berechtigung Handler Zuordnungen ist die w hrend der Iteration aufgerufene Methode init String handlerTable im Dispatcher zu editieren Diese Kausalit ten rechtfertigen dass die Klassen Broker und Dispatcher in die Autorisierungsarchitektur eingebunden worden sind vgl Abb 25 Nachdem skizziert ist an welchen Stellen im Programmcode die Autorisierungsarchitektur prozedural anzusetzen ist sollen die erforderlichen Ver nderungen detaillierter analysiert werden Der erste Schritt ist hierbei auf jeder
127. mit eingeflossen Bevor allerdings auf den Entwurf eingegangen wird findet eine Analyse der programmatischen Gegebenheiten beim infoAsset Broker statt um sp tere Erl uterungen verst ndlicher zu gestalten 3 2 1 Analyse des bestehenden Web Servers Die Erweiterung des infoAsset Brokers um einen Secure Web Server impliziert dass eine ausreichende Kenntnis ber die Struktur und das Verhalten des Systems in Bezug auf den vorhandenen Web Server bereits vorliegt In diesem Abschnitt soll diesbez gliche Information zusammengetragen werden Ausgangspunkt der Betrachtung ist die Klasse WebServer de infoasset broker server WebServer die die Hauptklasse des infoAsset Brokers bildet Sie enth lt die Methode main durch die der Application Server gestartet wird Zu den ersten Aufgaben dieser Methode z hlen das Auslesen der Konfigurationen aus einer Konfigurationsdatei sowie das Erzeugen und Starten eines Web Servers f r jede dieser Konfigurationen Unterschiedliche Web Server k nnen hierbei zu Autorisierungszwecken auf der Basis unterschiedlicher Internetadressenbereiche Internet Intranet etc konfiguriert werden Der Einfachheit halber und weil Autorisierung ebenfalls integraler Bestandteil dieser Arbeit ist soll in der weiteren Betrachtung davon ausgegangen werden dass lediglich ein Web Server gestartet wird Dies ist konsistent mit dem Wunsch eine feingranulierte Rechtevergabe zu erm glichen die nicht auf Adressbereichen beruht Gleichz
128. mulardaten JavaScript und SSL Werden Formulardaten des Portals vom Client an den Server bertragen so findet das clientseitig wie bei der Portalplattform blich durch Aufruf einer JavaScript Funktion statt Obwohl f r die Verbindung hierbei das SSL Protokoll verwendet wird und die Daten somit vertraulich bertragen werden findet clientseitig im Browser eine Warnung statt die den Benutzer vor einer nicht vertraulichen bertragung seiner Daten warnt Die Ursache hierf r ist allein durch den Aufruf einer JavaScript Funktion begr ndet Da die Verbindung das SSL Protokoll verwendet stellt dies kein Sicherheitsrisiko statt Allerdings kann die f lschliche Browserwarnung den Benutzer irritieren 2 Konfiguration mehrerer SSL Server Werden mehrere SSL Server parallel gestartet kommt es zu Konflikten die nicht identifiziert werden konnten 3 4 Zusammenfassung Innerhalb dieses Kapitels ist die SWS Architektur erarbeitet worden der Teil der Sicherheitsarchitektur der die Sicherheitskonzepte Vertraulichkeit Integrit t und Authentisierung innerhalb der Portalplattform umsetzt Schrittweise ist mit Hilfe des SSL Protokolls im Allgemeinen und der Java Secure Socket Extension JSSE im Speziellen der L sungsansatz erl utert worden Dabei ist ausf hrlich auf die berlegungen die bei dem Entwurf ma gebend gewesen sind und auf die wesentlichen Aspekte des Entwurfs eingegangen worden Dar ber hinaus sind die wichtigsten Schwierig
129. n Deshalb werden sie auch zusammen mit dem jeweils korrelierten privaten Schl ssel gehalten Bei den Zertifikaten die als certificate entries gehalten werden handelt es sich um Zertifikate die als vertrauensw rdig eingestuft worden sind I d R sind dies selbstsignierte Stammzertifikate der CAs Wie bereits erw hnt werden Keystore Dateien mit einem Programm namens keytool verwaltet Hierbei handelt es um eine befehlszeilenorientierte Anwendung kein GUI Der Umgang mit diesem Programm ist relativ umst ndlich und f r ernsthafte Verwaltungsaufgaben nicht zu empfehlen Dennoch ist es m glich die meisten erforderlichen Aufgaben mit Hilfe von keytool zu bew ltigen So ist es m glich asymmetrische Schl sselpaare und korrelierte selbstsignierte Zertifikate zu generieren X 509 v1 Zertifikatssignierantrf ge an CAs aus selbstsignierten Zertifikaten Certificate Signing Request CSR zu erstellen Zertifikate eingeschr nkt zu importieren und zu exportieren und vieles mehr F r eine ausf hrliche Darstellung der Befehlszeilenkommandos wird auf die Onlinedokumentation und auf die JSA Literatur verwiesen In dieser Arbeit werden die Keystores im Kontext der JSSE ben tigt s 2 3 4 3 Die einfachste M glichkeit einem JSSE Server mitzuteilen welche Zertifikate er verwenden soll ist ber Java Systemeigenschaften System Properties Hierbei wird die entsprechende Eigenschaft mit dem vollst ndigen Keystore Dateinamen initialisiert Bei
130. n Dieses Kriterium wird durch die Tatsache ber cksichtigt dass sich s mtliche relevanten Klassen des Secure Web Servers mit Ausnahme der erforderlichen Handler innerhalb eines Packages befinden de infoasset broker security ssi Zus tzlich existiert eine Klasse namens SSLWebServerFactory die dem umgebenden Programm als Zugriffsschnittstelle dient Sie enth lt eine Methode namens startSSLServers die den Start s mtlicher konfigurierter Secure Server veranlasst Somit findet Konfiguration und Verwaltung der Secure Server innerhalb des Packages statt Ein Benutzer muss lediglich wissen dass er die Server durch die genannte Methode starten kann Das Kriterium Konfigurierbarkeit beinhaltet die M glichkeit im System vorhandene Secure Server individuell zu starten Dar ber hinaus sollen die f r einen einzelnen Secure Server erforderlichen Parameter an einer einzigen Stelle gespeichert werden Ber cksichtigung findet dieses Kriterium durch die Einf hrung der Klasse SSLConfiguration Objekte dieser Klasse enthalten im Wesentlichen die Konfigurationsdaten einzelner Secure Server Sie haben damit den Charakter von Konfigurationsobjekten Wird ein Objekt dieser Klasse instanziiert so soll mit den Parametern die es umfasst auch ein Secure Server gestartet werden Typische Parameter sind beispielsweise der Port des Servers die zu verwendenden Key und Truststores der Servertyp vgl Erweiterbarkeit Namensattribut des Servers u a m Das Krite
131. n dass die zusammengesetzten Berechtigungsausdr cke der authorities txt einer Projektebene jeweils in die Zwischenrepr sentation AuthorityTree berf hrt in der AuthorityTreeCollection gespeichert und mit Hilfe des AuthorityTreeComparator sortiert werden Ein AuthorityTree Objekt enth lt den Wurzelknoten eines bin ren Baumes der den Berechtigungsausdruck repr sentiert Knoten dieses bin ren Baumes werden durch Objekte der Klasse AuthorityBinaryTreeNode verk rpert Hier werden die Berechtigungsausdr cke geparst und die innere Logik des Ausdrucks durch die Struktur des Baums beschrieben Endknoten eines solchen Baums sind stets die Pr dikate die in dem Berechtigungsausdruck verwendet werden Die Knoten die nicht Endknoten sind enthalten eine Typisierung entsprechend der logischen Operation die sie verk rpern NOT AND OR Zusammenfassend l sst sich sagen dass ein AuthorityBinaryTreeNode Wurzelknoten einen Berechtigungsausdruck der authorities txt repr sentiert Jeder Wurzelknoten wird jeweils in einem AuthorityTree Objekt gespeichert das zus tzlich zu dem Berechtigungsausdruck auch das zugeordnete Pr dikat repr sentiert Die Gr nde f r dieses komplexe Vorgehen bei der Instanziierung von zusammengesetzten Berechtigungen sind Zun chst einmal wird die Properties Tabelle die die jeweilige authorities txt einer Projektebene verk rpert nicht notwendig in der Reihenfolge abgearbeitet wie dies aufgrund der Reihenfolge der Pr
132. n Wert true evaluiert die Autorisierung vom System erteilt wird und im Fall dass das Pr dikat zum boolschen Wert false evaluiert die Autorisierung vom System versagt wird F r das genannte Beispiel w rde das Pr dikat isMemberOf Administratoren genau dann zu true evaluieren wenn der Benutzer der Session sich innerhalb der Gruppe der Administratoren befindet F r Benutzer die sich nicht in dieser Gruppe befinden w rde das Pr dikat zu false evaluieren Es soll die M glichkeit bestehen vorhandene Pr dikate in deklarativer Weise logisch miteinander zu kombinieren und hieraus neue komplexere Pr dikate zu generieren Hierbei sollen die Pr dikate zun chst durch die boolschen Operatoren NOT AND und OR miteinander kombiniert sein Wird ein zusammengesetztes Pr dikat innerhalb eines Kontextes evaluiert dann ist das Ergebnis die boolsche Kombination der in diesem Kontext evaluierten Pr dikate aus denen das zusammengesetzte Pr dikat besteht Die rekursive Definition von Pr dikaten muss dabei ausgeschlossen sein In Abschnitt 2 1 2 2 ist angedeutet worden dass die Voraussetzungen f r die Erf llung von Rechten auf unterschiedlichen Arten von Eigenschaften beruhen k nnen Die Eigenschaften eines Pr dikats sind durch die Parameter die das Pr dikat aufnimmt und durch seine programmatische Festlegung bestimmt Elementare Pr dikate k nnen dabei aufgrund der Art von Eigenschaften oder Merkmalen die sie ber cksichtigen unters
133. n clientseitig eingebetteten JavaScript Code aufrufen Ein relativer Hyperlink h tte beispielsweise die Gestalt href kategorie aktion htm Stattdessen haben die Verkn pfungen h ufig die Gestalt href javascript parent session show kategorie aktion htm 56 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Die bergabe einer absoluten Verkn pfungsadresse ber bestehenden JavaScript Code ist somit unm glich Entweder setzt man also eine absolute Verkn pfung ein bricht mit der Konvention der Portalplattform und nimmt daf r m glicherweise weitere Probleme in Kauf oder man erstellt neuen JavaScript Code der die Konvention der Plattform und die spezielle Problematik ber cksichtigt Es d rfte offensichtlich sein dass die zweite Variante unter den gegebenen Umst nden wesentlich eleganter ist Zu diesem Zweck wird die JavaScript Funktion SSLLogin ssI Target ssIPort eingef hrt dessen Code hier aufgef hrt ist function SSLLogin sslTarget sslPort var URL alert SSL Verbindung wird ber Port sslPort eingeleitet URL https top document location hostname sslPort URL URL de main htm t URL URL sslTarget top document location replace URL Diese Funktion soll n her erl utert werden da sie eine Schl sselrolle bei dem Wechsel von einer ungesicherten zu einer gesicherten Verbindung spielt Z
134. n mit dem ffentlichen Schl ssel des Zertifikats selbst Sie sind somit i d R der Ausgangspunkt f r eine Integrit tsschlussfolgerungskette Die Integrit t eines solchen Zertifikats beruht auf den eigenen Angaben seine Vertrauensw rdigkeit auf die berpr fung der Angaben insbesondere des ffentlichen Schl ssels durch denjenigen der ein solches Zertifikat als vertrauensw rdig einzusch tzen hat Zu diesem Zweck enthalten Zertifikate oftmals ein spezielles Merkmal das diese Aufgabe erleichtern soll den Fingerprint Hierbei handelt es sich um den Hashwert des eingetragenen ffentlichen Schl ssels Diese Hashwerte sind weit k rzer als der ffentliche Schl ssel selbst Root CAs ver ffentlichen ihre Fingerprints Derjenige der zu entscheiden hat vergleicht die ver ffentlichten Fingerprints mit denen in den Zertifikaten Sind diese identisch so sind auch die ffentlichen Schl ssel identisch so dass die Gesamtintegrit t des selbstsignierten Zertifikats gewahrt ist Der Entscheidungstr ger hat dann nur noch ber die Vertrauensw rdigkeit der Root CA selbst und ihrer Zertifizierungsrichtlinien zu entscheiden Selbstsignierte Zertifikate bilden einen Mechanismus um die Verankerung von Vertrauensbeziehungen herzustellen F r sich alleine bilden selbstsignierte Zertifikate keinen Vertrauensanker da ein jeder in der Lage ist ein selbstsigniertes Zertifikat mit der Identit t einer namhaften CA zu erstellen Lediglich der Abgleich des F
135. n zwingend die PKCS 11 API unterst tzen und ein entsprechendes Modul Plug In zur Verf gung stellen Die Zertifikate die in registrierten Sicherheitseinrichtungen gespeichert sind k nnen mit Hilfe des Zertifikats Managers verwaltet werden Abb 8 zeigt den dargestellten Sachverhalt schematisch Eine ausf hrliche Darstellung ber den Umgang mit Zertifikaten unter Netscape kann der Netscape Programm Dokumentation entnommen werden Nets02 Einstellungen gt Zertifikate Hilfe Zugriffsschutz durch Master Passw rter Netscape 7 0 Sicherheitseinrichtungen z B Software Sicherheitsdienst Zertifikats SmartCard Leser etc PKCSH11 Module Zertifikate und Gerste Schl ssel Manager verwaltet verwaltet Manager Abb 8 Zertifikatsspeicher in Netscape Sicherheitseinrichtungen 2 3 4 Das SSL Protokoll Das Secure Socket Layer SSL Protokoll ist innerhalb dieser Arbeit die Schl sseltechnologie mit dessen Hilfe ein beachtlicher Teil der Sicherheitskonzepte umgesetzt werden Die meisten der bisher erl uterten Technologien und Mechanismen sind Basistechnologien die im SSL Protokoll wieder verwendet werden 24 auch als Sicherheits Token bezeichnet 25 dieser ist ber den Menupunkt Einstellungen erreichbar gilt auch f r Zertifikats Manager 26 auch als Cryptoki Cryptographic Token Interface bezeichnet 34 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform
136. ndene Typen k nnen dem System nach einem bestimmten Schema hinzugef gt werden Dies beschreibt grob die Funktionsweise des infoAsset Brokers 12 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Neben der dargestellten groben Sichtweise sind weitere Sichten auf den Broker von ma geblicher Bedeutung So sind wesentliche Bestandteile dieser Arbeit Kap 3 vor dem Hintergrund zu verstehen dass der eigentliche Web Server integraler Bestandteil des Brokers ist Dies bedeutet dass serverseitig ankommende Clientanfragen Requests direkt vom Java Programmcode des Brokers verarbeitet und beantwortet werden Zwei weitere f r diese Arbeit wichtige Aspekte der Architektur der Portalplattform u ern sich clientseitig Zum einen basiert das Layout der Webseiten auf Frames zum anderen l st der Aufruf einer Verkn pfung Link im Regelfall die Ausf hrung von JavaScript Programmcode im Browser aus Diese beiden Aspekte scheinen belanglos und ohne wesentliche Auswirkungen auf die Sicherheitsarchitektur zu sein Tats chlich stellen sie eine nicht unwesentliche H rde f r die Integration der Sicherheitsarchitektur in die Portalplattform dar Wie sich die Probleme hierbei konkret u ern und wie diese bew ltigt werden wird in Kap 3 dargestellt Wie bereits erw hnt werden Verkn pfungen serverseitig auf Handler abgebildet Die Zuordnung erfolgt deklarativ durch eine Datei namens handler txt die sich im
137. nipuliert werden Keine Schutzvorrichtung verhindert dass die Information eines Pakets durch einen vermittelnden Knoten ver ndert wird M chte man die Integrit t der Information sichern so muss verhindert werden dass Informationsinhalte der Pakete auf dem Weg vom Sender zum Empf nger ver ndert werden k nnen bzw dass eine Ver nderung f r den Empf nger als solche erkennbar ist damit dieser die Information verwerfen und neu anfordern kann Die Gew hrleistung der Integrit t der bertragenen Information kann beispielsweise deshalb wichtig sein weil ihr Inhalt in eine wichtige Entscheidungsfindung einflie en kann so dass eine falsche Information potentiell falsche Entscheidungen bedingen kann Definition Der Begriff Integrit t umfasst s mtliche Ma nahmen die die Richtigkeit einer Information gew hrleisten insbesondere solche die sie vor Manipulation oder zuf lliger Ver nderung sch tzen 8 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform 2 1 2 5 Verbindlichkeit Im weitesten Sinne bedeutet der Begriff Verbindlichkeit dass unver nderliche Bedingungen festgelegt worden sind die die betreffenden Parteien zu einer Einhaltung und Erf llung derselben verpflichten Wie es dabei zu der Festlegung der Bedingungen gekommen ist ist zun chst zweitrangig Der Gedanke der mit diesem Konzept verfolgt wird ist die Erm glichung einen digitalen Vertrag zwischen den Teilne
138. ntisiert und die keiner anderen Identit t bekannt sein darf Ein typisches Beispiel hierf r ist das Passwort Bei besitzbasierter Authentisierung ist die sich authentisierende Identit t im Besitz eines Gegenstandes oder einer Information deren Nutzung die Authentisierung herbeiruft Ein typisches Beispiel f r diese Art der Authentisierung sind digitale Zertifikate und ihr korrelierter privater Schl ssel Bei biometriebasierter Authentisierung ist die zu authentisierende Identit t grunds tzlich eine Person da Computer oder Dienste keine biometrischen Eigenschaften besitzen Bei dieser Art der Authentisierung werden charakteristische Eigenschaften des Menschen f r eine Authentisierung verwendet Ein typisches Beispiel hierf r ist der Fingerabdruck Diese drei Authentisierungskategorien lassen sich graphisch in einem Authentisierungsdreieck darstellen Abb 2 Biometrie z B Fingerabdruck z B fingerabdruckgesicherte z B Voice Passwort SmartCard Wissen Besitz z B Passwort 7 z B Zertifikat z B PIN gesicherte SmartCard Abb 2 Authentisierungsdreieck ber die in Abb 2 dargestellten Kategorien hinaus sind nat rlich noch weitere denkbar So werden beispielsweise von Br mme die Einbeziehung r umlicher und zeitlicher Aspekte vorgeschlagen Solche Aspekte eignen sich gut um die hier dargestellten Konzepte zu erg nzen Sie spielen f r die vorliegende Arbeit allerdings keine Rolle weshalb auf sie auch nicht weiter
139. ntwurf 4 2 hat die Berechtigung als Verk rperung des Zugriffsrechts auf Handler des infoAsset Broker herausgehoben Es ist dargestellt worden wie Berechtigungen sowohl deklarativ als auch programmatisch festgelegt werden Hierbei ist zun chst offen geblieben wie die deklarative Definition von Pr dikaten in eine operative Instanziierung von Berechtigungen umgewandelt wird Im vorangegangenen Abschnitt ist auch behandelt worden dass die operative Zuordnung von Berechtigungen zu Handlern mit Hilfe einer Zuordnungstabelle stattfindet In diesem Zusammenhang ist offen geblieben wie die deklarative Zuordnung in der handler txt in eine operative Zuordnungstabelle abgebildet wird Diese beiden Fragen sind eng miteinander verkn pft und werden nun durch die Beschreibung des Initialisierungsvorgangs erl utert 4 3 1 Die Initialisierung der Berechtigungen Eine besondere Eigenschaft die im Rahmen der Initialisierung eine wichtige Rolle spielt ist die Tatsache dass die deklarative Zuordnung von Berechtigungen zu Handlern in der handler txt erfolgt Dar ber hinaus werden in der Architektur der Portalplattform die Dateien aller Projektebenen ber cksichtigt Dies u ert sich programmatisch in der Tatsache dass ber die Dateien der verschiedenen Projektebenen iteriert wird um Zuordnungen von documentlds zu Handlern bereitzustellen F r diese Zuordnung hat der Dispatcher die Verantwortung Da die betreffenden Dateien innerhalb der Sicherheitsarchite
140. o dass eine Nutzung des SSL Protokolls eine Umsetzung des Protokolls in Java erforderlich macht Erfreulicherweise stellt die Programmierumgebung ein Paket zur Umsetzung dieses Protokolls zur Verf gung die Java Secure Socket Extension JSSE In der f r diese Arbeit verwendeten Version der Programmierumgebung J2SDK 1 4 1 ist diese Erweiterung bereits enthalten Ihre elementaren Grundlagen sind in Abschnitt 2 3 4 3 erl utert worden Weitergehende Information zum JSSE k nnen dem JSSE Reference Guide der sich innerhalb der J2SDK Online Dokumentation befindet entnommen werden Zusammenfassend l sst sich sagen dass das Konzept zur Umsetzung der Sicherheitskonzepte Vertraulichkeit Integrit t und Authentisierung beim infoAsset Broker die Verwendung der in Java bereitgestellten Erweiterung JSSE ist TUHH AB Softwaresysteme 47 Vertraulichkeit Integrit t und Authentisierung 3 2 Beschreibung des Entwurfs Der vorangegangene Abschnitt zeigt warum die Nutzung der Erweiterung JSSE eine derma en wichtige Rolle f r diese Arbeit spielt In diesem Abschnitt werden der Entwurf des Secure Web Servers sowie die zu seiner Entstehung ma geblichen berlegungen unter Ber cksichtigung der Gegebenheiten bei der JSSE erl utert An dieser Stelle sei angemerkt dass im Rahmen dieser Arbeit ein Prototyp eines Secure Web Servers zur Erprobung der JSSE Technologie erstellt worden ist Die hieraus resultierenden Erkenntnisse sind in den Entwurf
141. oker authorities Categorybased uthority AUTHORITY_STRING_PREFIX String categoryld String check boolean initvoid hitektur Subjektbasierte Berechtigungen isierungsarc Autor Abb 24 69 TUHH Softwaresysteme Autorisierung 4 2 2 2 Deklarative Definition der Berechtigungen W hrend die programmatische Definition von Berechtigungstypen festlegt welche Arten von elementaren Berechtigungen m glich sind legt die deklarative Definition die tats chlich vorhandenen Berechtigungen fest Hierbei spielt analog zur handler txt eine andere Textdatei eine wichtige Rolle die authorities txt Diese Textdatei befindet sich im selben Verzeichnis wie die entsprechende handler txt In ihr findet eine Zuordnung von Pr dikaten zu Berechtigungstypen statt Die authorities txt ist die Textdatei in der deklarativ die verwendbaren Pr dikate definiert werden Hierbei kann auf jeder Projektebene der Portalplattform die Definition neuer Pr dikate stattfinden Eine Redefinition von bereits untergeordneten Projektebenen definierten Pr dikaten ist nicht gestattet Auf diese Weise k nnen bestehende Rechte nicht auf h heren Projektebenen liberalisiert und die Autorisierungsarchitektur so ausgehebelt werden Ahnlich der handler txt existiert somit im Stammverzeichnis eines jeden Projekts eine authorities txt in der die auf der betreffenden Projektebene neuen Pr dikate festgelegt werden Pr dikate die in
142. olgerungsketten bilden kann d h wie man aus der Integrit t eines CA Zertifikats die Integrit t aller untergeordneter Zertifikate schlie en kann Das Verfahren beruht auf zwei Grundannahmen 1 Der Teilnehmer der eine solche Kette verifiziert vertraut darauf dass auf jeder Zertifizierungsebene die entsprechende Zertifizierungsrichtlinie korrekter Weise durchgef hrt wird 2 Der gleiche Teilnehmer vertraut auf die Integrit t des CA Root Zertifikats Wurzel oder Stammzertifikat auf das er seine Schlussfolgerungen st tzt Auf den ersten Punkt hat man wenig Einfluss und praktisch keine M glichkeiten ihn zu berpr fen Es l sst sich hierf r nur die Plausibilit tserkl rung heranf hren dass die CAs auf allen Ebenen ein eigenes Interesse daran haben dass das System funktioniert und sie werden somit daf r Sorge tragen dass ihre eigenen Richtlinien korrekt eingehalten werden Auf den zweiten Punkt hat man hingegen einen entscheidenden Einfluss Dieser Punkt ist im Wesentlichen dadurch bestimmt welche Zertifikate man selbst als Teilnehmer zu einem bestimmten Zweck als vertrauensw rdig einsch tzt In der Regel werden dies die Zertifikate oberster Zertifizierungsautorit ten sein Dies ist allerdings keine Bedingung Denkbar ist beispielsweise dass f r eine eigene verteilte Anwendung auch eine eigene bereitgestellt wird weil man e die Zertifizierungsrichtlinien selbst vorgeben m chte die Zertifikate mit spezi
143. ologie wenn es darum geht die eingangs beschriebenen Sicherheitskonzepte umzusetzen Das Thema Kryptographie ist sehr umfangreich und eine ausf hrliche Behandlung w rde mit Sicherheit den Rahmen dieser Arbeit sprengen Da einige Aspekte allerdings besonders wichtig f r das Verst ndnis dieser Arbeit sind sollen sie kurz dargestellt werden 2 3 2 1 berblick Kryptographie ist eine Wissenschaft die die Verschleierung des Informationsgehaltes einer Botschaft gegen ber Dritten sowie die unberechtigte R ckgewinnung dieses Informationsgehaltes durch Dritte zum Ziel hat Berechtigt ist 5 Umgehung bestehender Sicherheitsrichtlinien 16 f r eine ausf hrliche Darstellung siehe u a Zim97 22 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform hier derjenige f r den die Botschaft oder Information bestimmt ist Es wird ausdr cklich darauf hingewiesen dass nicht die Existenz einer Information oder Botschaft verschleiert wird sondern ihre Semantik Diese Eigenschaft grenzt die Kryptographie gegen ber einer verwandten Wissenschaft der Steganographie ab bei der bereits die Existenz der Information vor unberechtigten Dritten verschleiert wird Beide Wissenschaften sind der Kryptologie untergeordnet die die Verschleierung von Information generell zum Ziel hat Bei kryptographischen Verfahren wird Information in allgemein verst ndlicher Weise Klartext auf eine verschl sselte Informat
144. ondere dann wenn rechtsverbindliche Vertr ge bzw zeichnungspflichtige Gesch ftsprozesse in einer Weise umgesetzt werden sollen dass sie juristisch d h vor einem ordentlichen Gericht Bestand haben Eine Umsetzung dieses Konzeptes w rde somit nicht nur technische Fragestellungen ber hren sondern auch die Gesetzgebung des jeweiligen Staates in dem die Portalplattform zum Einsatz kommen soll Dar ber hinaus kennt der Informationsfluss im Internet keine staatlichen Grenzen so dass bei einem internationalen Einsatz ebenfalls die diesbzgl juristischen Fragen zu kl ren w ren Aus technischer Sicht bilden digitale Zertifikate eine wichtige Grundlage f r die Umsetzung der digitalen Signatur also der Ma nahme die das Sicherheitskonzept Verbindlichkeit umzusetzen vermag Digitale Zertifikate sind innerhalb dieser Arbeit nicht zuletzt aus diesem Grund verwendet und so umfangreich behandelt worden TUHH AB Softwaresysteme 83 Zusammenfassung und Ausblick Geht man st rker in technische Details so ist zu konstatieren dass eine digitale Signatur von einem Zertifikatsinhaber geleistet wird indem dieser einen Hashwert mit seinem privaten Schl ssel asymmetrisch chiffriert M chte das Konzept Verbindlichkeit in integrierter Weise umsetzen so sind prinzipiell zwei Wege m glich die clientseitige und die serverseitige Signatur Bei der clientseitigen Signatur wird der Hashwert clientseitig signiert und zum Server bertragen
145. onsspeicher ist Eine SmartCard ist ein Mikrocontroller im Scheckkartenformat der f r spezifische Aufgaben ausgelegt wird Bei der besitzbasierten Authentisierung soll die SmartCard die jeweiligen Credentials speichern wobei die geheime Information die SmartCard niemals verlassen darf Auf diese Weise ist der Besitz der SmartCard mit dem Besitz der Credentials identisch was bei der besitzbasierten Authentisierung beabsichtigt wird Diese Sichtweise ist bei Credentials die in Dateien gehalten werden aufgrund der Kopierf higkeit der Dateien nicht so eindeutig Besitzbasierte Authentisierung Lokaler Zugriffsschutz Wie zu Beginn des letzten Absatzes angedeutet ist nicht nur die Verk rperung der Credentials entscheidend sondern auch ihr lokaler Zugriffsschutz Damit ist der Mechanismus gemeint der vorhandene Credentials verwendbar macht So werden die Credentials in Dateien h ufig wissensbasiert gesch tzt d h i d R durch die Eingabe eines Passworts Dieses Passwort wird allerdings nicht zum Kommunikationspartner bertragen um eine Authentisierung zu bewirken sondern es wird verwendet um die Credentials die zur Authentisierung verwendet werden lokal freizuschalten Dieses Prinzip wird von g ngigen Browsern verwendet wenn es darum geht eigene Zertifikate und private Schl ssel zu verwenden Es soll sicherstellen dass der lokale Speicherort der Credentials tats chlich seinem Benutzer zuzuordnen ist Auch bei der Verwendung von Sm
146. operties substituiert Handler Klassennamen durch Handler Instanzen this putHandlersInsteadOfHandlernames AuthorityManager getAuthorityManager getTransientAuthorityMapper transiente Tabelle in permanente Zuordnung berf hren und l schen AuthorityManager getAuthorityManager initTransientAuthorities Die eigentliche permanente Zuordnung findet im HandlerAuthorityMapper statt Die bergebene transiente Tabelle wird ausgelesen die hierin vorhandenen Handlerinstanzen werden in der Zuordnungstabelle abgelegt Hierbei werden die in der transienten Tabelle vorhandenen Pr dikate mit Hilfe des AuthorityReaders auf Berechtigungen abgebildet so dass die Zuordnungstabelle schlie lich eine Abbildung von Handlerinstanzen auf Berechtigungen enth lt Der Abbildungsvorgang wird innerhalb der Klasse HandlerAuthorityMapper geloggt Kommt es w hrend dieser Zuordnung zu internen Fehlern aufgrund der Tatsachen dass Pr dikate nicht 80 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform deklariert worden sind oder dass Berechtigungszuordnungen redefiniert werden so werden diese Fehler ebenfalls geloggt Nachdem ber s mtliche Projektebenen iteriert worden ist um Handler und Berechtigungen zu instanziieren Klasse Broken wird eine Abschlussmethode aufgerufen die bewirkt dass auf die Zuordnungstabelle nur noch lesend zugegriffen werden kann Die Autorisierungsarchitektur wird auf diese
147. otentieller Angreifer die Implementierung einer solchen Abfrage einsehen analysieren und daraus Schl sse ziehen Er w re somit in der Lage einen kleinen Teilbereich der Sicherheitsarchitektur zu verstehen und m glicherweise mit weiteren Erkenntnissen auch in der Lage Schwachstellen zu finden Die Vorteile dieses Ansatzes sind die einfache Implementierung eines solchen Formulars und die individuelle gestalterische Freiheit 12 117 sind auch mehr denkbar 18 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Bei dem zweiten Ansatz kann http Headerinformation verwendet werden um dem Browser des Clients mitzuteilen dass eine Passwortauthentisierung erforderlich 151 Hierbei versucht der Client zun chst auf eine Webseite zuzugreifen f r die eine Passwortauthentisierung erforderlich ist Der Server beantwortet die Anforderung der Webseite Request mit einem Fehlercode 401 und mit einer Aufforderung im http Header WWW Authenticate Zus tzlich enth lt der Header Information ber das Schema der erw nschten Authentisierung und ber den Bereich Realm Ein Browser der einen solchen Header interpretieren kann wird mit einer browsertypischen Eingabeaufforderung an den Benutzer reagieren Der Benutzer kann in einem separaten Fenster seine Credentials eingeben und best tigen Nach der Best tigung fordert der Browser genau dieselbe Seite wie zu Beginn an mit dem Unterschied dass im http Heade
148. prozedur im Handler zwischenzuspeichern Das Objekt wird innerhalb des Threads HTTPSConnection erzeugt und innerhalb des Dictionaries des SSLSession Objekts zwischengespeichert Die Gewinnung der erforderlichen Initialisierungsdaten f r die Erzeugung des Objekts erfolgt durch http Authentisierung vgl 2 3 1 2 Nach erfolgreicher Anmeldung wird das Objekt aus der SSLSession entfernt 6 d h keine Client Authentisierung via SSL Handshake 7 nicht zu verwechseln mit dem Session Objekt des Brokers 60 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Bei der zertifikatsbasierten Authentisierung wird ein Hilfsobjekt der Klasse SSLinformationinvestigator die ebenfalls Bestandteil der SWS Architektur ist einbezogen Objekte dieser Klasse stellen eine Schnittstelle zur Verf gung die ben tigte Information ber die SSL Verbindung liefert Komplexe Algorithmen die beispielsweise zur Extraktion von Anmeldedaten aus einem Zertifikat dienen k nnen so durch Methoden dieses Objekts gekapselt werden In der zu dieser Arbeit vorgelegten Implementierung liefert das Objekt konkret die in einem Zertifikat eingetragene E Mail Adresse des Zertifikatsinhabers die in der Architektur der Portalplattform das einzigartige unique User Login repr sentiert Sind bei der Gewinnung der Anmeldedaten die erforderlichen Credentials nicht zu erlangen oder liefern sie unerwartete Ergebnisse so wird ebenfalls auf d
149. r die Credentials enthalten sind WWW Authorisation Wie die Credentials codiert sind h ngt von dem Schema ab Das gebr uchlichste Schema BASIC benutzt hierzu eine sog Base64 Kodierung Bricht der Benutzer hingegen die Eingabe der Credentials ab so wird auf dem Browser die HTML Information der Fehlerseite 401 wiedergegeben die bis dahin zur ckgehalten wurde Ein erneuter Zugriff findet somit im Fall eines Abbruchs nicht statt Bei diesem zuletzt erkl rten Ansatz ist eine clientseitige Informationsgewinnung bzgl der Implementierungsdetails nicht m glich da es sich hierbei um eine vom Browser bereitgestellte Funktion handelt deren Implementierung nicht einsehbar ist Die serverseitige Implementierung dieses Ansatzes ist dabei i d R umst ndlicher wie die Erl uterungen wiedergeben d rften Auf Pr sentationsebene erreicht man hierdurch ein einheitliches Authentisierungsbild da das Eingabefenster browserspezifisch ist und keinerlei Gestaltung zul sst Besitzbasierte Authentisierung Die wohl bekannteste besitzbasierte Authentisier amp ung im Kontext webbasierter Authentisierung beruht auf der Verwendung von digitalen Zertifikaten s 2 3 3 Die Verwendung digitaler Zertifikate die nicht ausschlie lich auf Authentisierung beschr nkt ist bildet einen wichtigen Bestandteil dieser Arbeit weshalb Zertifikate weiter unten in eigenen Abschnitten erl utert werden An dieser Stelle soll lediglich ihr Beitrag zur webbasierten Authentis
150. rag auf der Systems Thomas Veit BSI 2000 Implementing Web Site Client Authentication Using Digital Ids and the Netscape Enterprise Server 2 0 VeriSign Inc www verisign com repository clientauth ent ig htm 1998 HTTP kurz und gut Deutsche Ausgabe Clinton Wong O Reilly Verlag 2000 Kryptologie Sicherheit in Datennetzen Vorlesungsskript Karl Heinz Zimmermann TUHH AB Technische Informatik VI 1997 TUHH AB Softwaresysteme 89
151. raphischen Verfahren zugeordnet Dieses Verfahren wird i d R durch einen weiteren Eintrag im Zertifikat festgelegt k nnte prinzipiell aber auch durch den Zertifikatsstandard festgelegt werden Das in Abb 6 dargestellte Siegel symbolisiert die Datenintegrit t des Zertifikats Sie wird mit Hilfe asymmetrischer Kryptographie gesichert Auf diesen Sicherungsvorgang der einen erheblichen Teil der Komplexit t digitaler Zertifikate ausmacht soll im Folgenden eingegangen werden Das Ziel welches mit dem Einsatz digitaler Zertifikate verfolgt wird ist die Schaffung von Vertrauen zwischen Kommunikationspartnern in get tigte digitale Handlungen Ein Teilnehmer vollzieht digitale Handlungen i d R die digitale Signatur eines Hashwertes eines Nonce etc mit seinem privaten Schl ssel Diese Handlungen k nnen von anderen Teilnehmern mit Hilfe des komplement ren ffentlichen Schl ssels nachvollzogen und nachgewiesen werden Einem digitalen Zertifikat kommt dabei die Aufgabe zu Identit ten und ffentliche Schl ssel untrennbar zu verbinden damit dies auch f r die Identit ten und ihre Handlungen gilt Grunds tzlich 26 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform muss bei jeder Vorlage eines Zertifikats die Frage nach der Vertrauensw rdigkeit des digitalen Zertifikats gestellt werden Schlie lich ist ein vertrauensw rdiges Zertifikat der Garant f r eine vertrauensw rdig durchgef hrte di
152. raulichen Kanal dar In vielen F llen ist es allerdings erforderlich dass die gesamte oder gro e Teile der Kommunikation vertraulich bleiben In solchen F llen wird zun chst die Vertraulichkeit des Kommunikationskanals gesichert Im Internet wird daf r h ufig das SSL Protokoll verwendet auf das in 2 3 4 eingegangen wird Uber einen auf solche Weise gesicherten Kanal k nnen auch Passw rter bertragen werden da die Vertraulichkeit des Kanals die Kompromittierung des Passworts verhindert In diesem Zusammenhang wird klar dass die Qualit t der Authentisierung auf der Qualit t der Kanalvertraulichkeit beruht Dies kann als Beleg f r die eingangs gemachte Behauptung ber die Wechselwirkung von Sicherheitsma nahmen s 2 1 1 gewertet werden Neben der Frage der vertraulichen bertragung der Credentials ist auch die Frage nach der Gewinnung der Credentials zu stellen In einer webbasierten Umgebung k nnen hierf r zwei unterschiedliche Ans tze verfolgt werden Bei dem ersten Ansatz kann ein individuell gestaltbares HTML Formular verwendet werden Das Userlogin und das Passwort werden dabei vom jeweiligen Benutzer in daf r vorgesehene Felder eingetragen Formularvariablen zugeordnet und per POST oder GET Methode an den Server bertragen Dieser Ansatz kann selbstverst ndlich auch im Zusammenhang mit einem Challenge Response Protokoll verfolgt werden Da ein solches Abfrageformular im Prinzip auch nur eine HTML Seite ist kann ein p
153. rbeit kennen lernen durfte und die ein freundliches Arbeitsklima geschaffen haben Ganz besonderer Dank geb hrt meinem Betreuer Dipl Inf Patrick Hupe der mich w hrend meiner Arbeit in zahlreichen Diskussionen fachlich unterst tzt hat Dar ber hinaus hat er durch seine fr hliche Wesensart stets zu meiner Motivation beigetragen TUHH AB Softwaresysteme 3 Eine Sicherheitsarchitektur f r eine Informationssystem Plattform 2 Grundlagen In diesem Kapitel werden zun chst alle Grundlagen beschrieben die zum Verst ndnis der vorliegenden Arbeit erforderlich sind Dabei wird im ersten Hauptabschnitt auf theoretische Grundlagen zum Begriff Sicherheit eingegangen Der zweite Hauptabschnitt widmet sich den wesentlichen Eigenschaften des Zielsystems Im dritten Hauptabschnitt wird schlie lich auf erforderliche Technologien zur Umsetzung der Ziele eingegangen 2 1 Sicherheit Begriffe Konzepte und Methoden Dieser Abschnitt befasst sich konzeptionell mit dem Thema Sicherheit Es wird zun chst auf einer abstrakten Ebene der Begriff Sicherheit definiert und diese Definition anschlie end f r den IT Bereich konkretisiert Im Anschluss werden Sicherheitskonzepte die f r diese Arbeit eine besondere Bedeutung haben ausf hrlich beschrieben wobei auch auf Sicherheitskonzepte in deren Umfeld eingegangen wird Schlie lich wird in allgemeiner Weise auf eine m gliche Vorgehensweise bei der Konstruktion einer Sicherheitsarchitektur eingegangen
154. rd Schnittstellen unterst tzt 23 25 02 gt Security Tool keytool siehe auch 01 TUHH AB Softwaresysteme 33 Grundlagen Netscape 7 0 speichert Zertifikate und ggf korrelierte private Schl ssel in sog Sicherheitseinrichtungen Eine Sicherheitseinrichtung ist somit der physikalische Speicher f r Zertifikate und Schl ssel Die Standard Sicherheitseinrichtung von Netscape ist der sog Software Sicherheitsdienst der eine Speicherung eigener Zertifikate auf der Festplatte in einer nicht n her erw hnten Datei vornimmt Ein weiteres Beispiel f r eine Sicherheitseinrichtung ist ein SmartCard Leseger t in Kombination mit den zu verwendenden SmartCards Allgemein stellen Sicherheitseinrichtungen kryptographische Dienste zur Verf gung so dass es sich hierbei nicht zwingend um Speicher handeln muss Der Zugriff auf jede Sicherheitseinrichtung ist durch ein sog Master Passwort gesch tzt Verwaltet werden die Sicherheitseinrichtungen von Netscape mit Hilfe des Ger te Managers Dieser zeigt s mtliche vorhandenen Sicherheitseinrichtungen an und erlaubt neue hinzuzuladen bzw vorhandene zu entladen Hierbei sind die einzelnen Sicherheitseinrichtungen stets einem sog PKCS 11 Modul untergeordnet Ein solches Modul ist ein Plug In und ist gewisserma en als Treiber f r die Sicherheitseinrichtung unter Netscape zu verstehen Kryptoger te die unter Netscape als Sicherheitseinrichtungen betrieben werden sollen m sse
155. rent f r die bergeordneten und die untergeordneten Protokolle Dies bedeutet dass ein Protokoll aus der Anwendungsschicht http ftp usw keinen Unterschied darin sieht ob es direkt mit dem TCP Protokoll oder mittelbar ber das SSL Protokoll kommuniziert Umgekehrt nimmt das TCP Protokoll keine Unterschiede zwischen einer direkten Kommunikation mit dem betreffenden Anwendungsprotokoll und einer mittelbaren ber das SSL Protokoll wahr Man beachte hierbei dass zwar ein beliebiges Anwendungsprotokoll verwendbar ist dass aber SSL stets voraussetzt und evtl andere Protokolle der Transportschicht schlie en die Verwendung von SSL aus Oft wird SSL im Kontext eines Secure Web Servers verwendet Dies meint die Nutzung von http ber 55 was auch oft zusammenfassend als https bezeichnet wird Der Standardport dieses zusammengefassten Protokolls https ist 443 blicherweise findet bei https eine Authentisierung des Web Servers durch den Clientbrowser statt Hierf r stellt der Server ein SSL Serverzertifikat bereit das von g ngigen Browsern akzeptiert wird d h ein Zertifikat welches vom Browser als 27 Internet Engineering Task Force www ietf org TUHH AB Softwaresysteme 35 Grundlagen vertrauensw rdig anerkannt wird Prinzipiell ist es zwar auch m glich ein Zertifikat zu verwenden welches nicht als vertrauensw rdig anerkannt wird eine SSL Verbindung kann hiermit auch aufgebaut werden der Benutzer
156. rium Wartbarkeit fordert dass eine Umgestaltung von Teilen der Architektur und der Komponenten leicht bewerkstelligt werden kann und dass diese Anderungen eine m glichst geringe Pflege des Systems an einer anderen Stelle erfordert An dieser Stelle ist dieses Kriterium auf die vordefinierten Secure Server zu beziehen Zur Umsetzung dieses Kriteriums ist in dieser Arbeit der Ansatz gew hlt worden f r jeden vordefinierten Secure Server Typ eine eigene Klasse bereitzustellen Gleichzeitig ist jedem Servertyp ein Handler zugeordnet vgl Abb 22 der beim Wechsel von einer ungesicherten zu einer gesicherten Verbindung aufgerufen wird und der die erforderliche Anmeldeprozedur durchf hrt nderungen bei einem Servertyp und dem jeweils korrelierten Handler wirken sich somit lediglich auf einen Anmeldemechanismus aus Andere Mechanismen bleiben hiervon unber hrt 97 die Zuordnung erfolgt im zugeh rigen SSLConfiguration Objekt und der handler txt 50 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform SLConfiguration START_DEFAULT boolean START_CLIENT_GERTIFICATE boolean SMART CARD hoolean Configurations Vector sslLoginCommentString sslPortint keystorePath Strin keystoreType Strin keystorePassword String tuststorePath String tuststoreType String tuststorePassword String hasTruststore boolean
157. rkeiten bezeichnen kann sind stets tnemenimmanent Es ist deshalb sinnvoll sich auf ein jeweiliges Themengebiet zu beschr nken um die jeweiligen Unw gbarkeiten detaillierter benennen zu k nnen In der vorliegenden Arbeit wird Sicherheit im Spannungsfeld der Informationstechnik betrachtet Bei den vor Sch digung zu sch tzenden Ressourcen handelt es sich hierbei um die Information sowie die zu ihrer Verarbeitung n tigen Infrastruktur Die Definition des Begriffs Sch digung nimmt in diesem Kontext besondere Ausma e an da man bereits von einer Sch digung der Ressource Information sprechen kann wenn diese an daf r nicht vorgesehene Empf nger gelangt Vertraulichkeit Autorisierung obwohl die betrachteten Ressourcen der Informationstechnik hierbei unver ndert bleiben TUHH AB Softwaresysteme 5 Grundlagen Definition Bei den vor Sch digung zu sch tzenden Ressourcen im Kontext des Themengebiets Informationstechnik handelt es sich um die Information sowie die zu ihrer Verarbeitung n tigen Infrastruktur Um Sicherheitskonzepte und geeignete Schutzmechanismen erarbeiten zu k nnen ist es erforderlich sich mit denkbaren Sch digungen im jeweiligen Themengebiet auseinanderzusetzen Bei einer zu erstellenden Sicherheitsarchitektur werden anschlie end erkannte Sicherheitskonzepte als Anforderungsgrundlage das zu erstellende System benutzt Die Umsetzung der Sicherheitskonzepte durch geeignete Schutzmechanismen kann zud
158. rkn pfung dient die f r den Aufruf des zugeordneten Handlers sorgt vgl de infoasset broker handler myportal WelcomeHandler ssl Servers ListTemplate 55 1 String Dieser Parameter spielt eine untergeordnete Rolle f r die Funktionsweise der SWS Architektur Er enth lt eine kurze Informationszeile die zur Erl uterung der dynamischen Verkn pfung verwendet wird Durch sie erlangt der Benutzer Kenntnis ber die Art der Anmeldung ssI Port int Dies ist der Port den der betreffende SSL Server ffnet Der hier eingetragene Port wird ebenfalls bei der dynamischen Erzeugung der Verkn pfung verwendet keystorePath String Dies ist der vollst ndige Name der Keystore Datei die der betreffende SSL Server verwenden soll Gem den JSSE Vorgaben bei der Nutzung des Standard SSLContextes soll diese Datei nur ein Zertifikat enthalten Dieses Zertifikat und der korrelierte private Schl ssel dienen zur Server Authentisierung Dementsprechend handelt es sich um ein SSL Server Zertifikat Es sollte von einer bekannten CA ausgestellt worden sein deren Stammzertifikat e in g ngigen Web Browsern vorinstalliert ist bzw sind beispielsweise TC TrustCenter GlobalSign VeriSign etc keystoreType String Dies bezeichnet die Keystore Implementierung die zur Generierung der Keystore Datei verwendet wurde Standardm ig stehen hier drei Varianten zur Verf gung JKS JCEKS oder PKCS12 keystorePassword
159. s Ergebnis ist eine individuell konfigurierte oder standardm ig erzeugte Instanz 3 clientseitig liegt ein SSL f higer Browser vor TUHH AB Softwaresysteme 43 Grundlagen der Klasse SSLServerSocketFactory die durch Aufruf der Methode createServerSocket eine Instanz der Klasse SSLServerSocket liefert Anhand des SSLServerSocket Objekts das f r einen bestimmten Port konfiguriert ist kann durch entsprechende Methodenaufrufe eingestellt werden ob f r zuk nftige Verbindungen eine Client Authentisierung erw nscht oder gar notwendig ist Der Aufruf der Methode accept l sst das SSLServerSocket auf dem betreffenden Port lauschen bis eine Anfrage auf dem betreffenden Port eintrifft Handelt es sich bei der Anfrage um einen neuen Client f r den noch kein SSLSession Objekt existiert so wird der erforderliche SSL Handshake durchgef hrt s 2 3 4 2 und ein neues SSLSession Objekt erzeugt das f r zuk nftige Anfragen wieder verwendet wird Ist der SSL Handshake erfolgreich neuer Client oder liegt bereits ein SSLSession Objekt vor alter Client so erh lt man als Ergebnis des Methodenaufrufs accept eine Instanz von SSLSocket an die auch das SSLSession Objekt gekn pft ist Wie in 2 3 4 1 erw hnt und in 2 3 4 2 dargestellt findet w hrend des SSL Handshakes blicherweise eine Server Authentisierung statt Zu diesem Zweck ben tigt der Server ein SSL Server Zertifikat mit zugeh rigem privatem Schl ssel In Abb 20 ist dies dem
160. s SSL Servers zugewiesen Die vorliegende Implementierung f hrt eine Initialisierung des SSLContextes durch Aufruf der Hilfsmethode initSSLContext durch in der eine Initialisierung des Standard SSLContextes mit Hilfe von Systemeigenschaften System Properties stattfindet Anschlie end wird Standard SSLServerSocket generiert Dies ist die einfachste M glichkeit SSLServerSocket zu erstellen Nachdem der SSL Server initialisiert ist kann dieser gestartet werden Analog der Server Implementierung ohne SSL existiert hierzu die Methode serve die im Wesentlichen die jeweilige SSLWebServer Instanz in einem eigenen Thread startet Innerhalb dieses Threads l uft eine Endlosschleife in der das SSLServerSocket auf dem betreffenden Port auf eingehende Anfragen lauscht Erh lt der SSLServerSocket eine Anfrage so generiert er einen SSLSocket Da in der Java Klassenhierarchie SSLSocket eine Spezialisierung der Klasse Socket ist sollte die in 3 2 1 erw hnte Klasse HitpConnection die Anfrage auch mit einem speziellerem Socket beantworten k nnen Konkret scheitert dies allerdings an einem anderen Parameter der von dem Konstruktor der Klasse HitpConnection erwartet wird Dieser erwartet n mlich zus tzlich das WebServer Objekt als Parameter M chte man somit die Klasse HitpConnection f r die Beantwortung der Anfrage wieder verwenden so gibt es zwei Optionen die Klasse SSLWebServer als Unterklasse der Klasse WebServer auszuf hren un
161. sind im Rahmen dieser Arbeit ebenso spezielle Berechtigungstypen entstanden Beispiele f r authentisierungsbasierte Berechtigungstypen sind die PasswordbasedAuthenticationAuthority CertificatebasedAuthenticationAuthority und SmartCardbasedAuthentication Authority die eine Autorisierung auf der Basis unterschiedlicher Authentisierungsmechanismen erm glichen Als Beispiel f r einen objektbasierten Berechtigungstyp dient die AdministratorDocumentAuthority 68 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform de infoassethroker interfaces Role de infoasset hroker interfaces Membership AUTHO RITY_ STRING PREFIX String SuhjecthasedAnthority check boolean init void Asset de infoasset broker authorities PersonbasedAuthority interface de infoasset hroker interfaces Person AUTHORITY_STRING_PREFIX String person Person check boolean init void Asset Asset de infoasset broker authorities GroupbasedAuthority interface interface group Group check boolean initvoid Asset interface de infoasset hroker interfaces Group de infoasset broker authorities RolebasedAuthority AUTHORITY_STRINGS_PREFIX Strin 0 role Role group Group check boolean init void lt lt DomainYalue gt gt de infoasset broker interfaces Category de infoasset br
162. spielsweise dazu verwendet die Verwendung von Zertifikaten einschr nken zu k nnen hnlich dem Vorbild des tangiblen Ausweises Personalausweis F hrerschein Studentenausweis usw Die M glichkeiten die neuere Versionen f r diese Arbeit bieten k nnten sind allerdings zun chst von geringer Bedeutung da zun chst der Identit tsnachweis des Zertifikatsinhnabers im Mittelpunkt der Betrachtung steht Dar ber hinaus bietet die verwendete Programmierumgebung lediglich die M glichkeit selbstsignierte X 509v1 Zertifikate zu erstellen die zudem nicht in g ngige Browser wie Netscape exportierbar sind Au er den genannten Extensions ist die wichtigste Eigenschaft dieses Zertifikatsstandards erg nzend zu den generischen Zertifikatskonzepten die Art wie Identit tsmerkmale festgelegt werden Diese Identit tsmerkmale sind in einem sog X 500 Distinguished Name DN zusammengefasst Auf Details des X 500 Standards zur Strukturierung globaler Verzeichnisse soll hier nicht eingegangen werden da sie f r diese Arbeit nicht von Bedeutung sind Die einfachste Art einen solchen 500 zu verstehen ist ihn als geordnete Ansammlung von Variablen zu sehen denen Werte zugeordnet sein k nnen Die Variablen repr sentieren Identit tsmerkmale die in ein X 509 Zertifikat aufgenommen werden k nnen Die Tab 1 gibt ein Beispiel welche Variablen blicherweise vorkommen Variable Inhalt Erl uterung b E Mail Adr
163. t ndigkeit Das Erkennen weiterer Risiken kann somit neue Sicherheitskonzepte zur Folge haben 2 1 2 1 Authentisierung Im weitesten Sinne bedeutet der Begriff Authentisierung die Echtheit von etwas zu berpr fen Im Internet ist jeder Rechner durch seine IP Adresse charakterisiert Da IP Adressen ber die Zeit aber unterschiedlichen Teilnehmern zugeordnet werden k nnen ist es f r eine Webanwendung unm glich festzustellen welcher Teilnehmer sich hinter welcher IP Adresse verbirgt Der Teilnehmer kann sich zwar gegen ber der Webanwendung identifizieren d h vorgeben ein bestimmter Teilnehmer zu sein die Webanwendung muss diese Identifikation allerdings verifizieren d h ihren Wahrheitsgehalt berpr fen um sicher zu sein dass tats chlich der vorgegebene Teilnehmer und kein anderer die Webanwendung benutzt Dies kann beispielsweise sinnvoll sein weil die Anwendung personalisierte Dienste anbietet berpr ft ein Server die Identit t eines Clients spricht man von Client Authentisierung Oft ist auch das Pendant hierzu erforderlich Teilnehmer greifen auf Webdienste zun chst durch die Eingabe eines Dom nennamens zu Ein solcher Dom nenname muss in eine IP Adresse aufgel st werden damit die Client Anwendung wei zu Sie sind aus der Analyse verschiedener Quellen hervorgegangen s Literatur und Quellenverzeichnis 6 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform
164. t rlich nicht juristische sondern technische Fragestellungen Im engeren Sinne befasst sich der Begriff Verbindlichkeit somit mit der Beantwortung der Frage wie digitale Vertr ge bzw vollzogene Rechtshandlungen festgehalten werden k nnen um sp ter ggf rechtlich darauf zur ckgreifen zu k nnen und welche technischen Voraussetzungen hierf r notwendig sind damit jemand der einen Vertrag eingegangen ist oder eine Rechtshandlung vollzogen hat diesen Sachverhalt nicht als unzutreffend zur ckweisen kann Dieses Konzept kann beispielsweise dann besonders wichtig sein wenn Wirtschaftsg ter von besonders hohem Wert ber das Internet gehandelt werden sollen z B Immobilien oder wenn politische B rgerrechte auf neue Weise ausge bt werden sollen z B Volksentscheide bei wichtigen Gesetzen vgl Schweiz Definition Der Begriff Verbindlichkeit umfasst s mtliche Ma nahmen die zur Speicherung Wiederverwertung und zum Nachweis der Durchf hrung einer elektronischen Rechtshandlung dienen Ein Vertragsabschlu stellt hierbei eine besondere Rechtshandlung dar 2 In der Bundesrepublik Deutschland hat die Legislative mit dem Gesetz zur digitalen Signatur SigG vom 16 05 2001 hierf r die rechtlichen Voraussetzungen geschaffen vgl bundesrecht juris de bundesrecht sigg_2001 TUHH AB Softwaresysteme 9 Grundlagen 2 1 2 6 Weitere Sicherheitskonzepte ber die zun chst ausf hrlich beschriebenen Sicherheitskonzepte h
165. t des Zertifikats gepr gt Diejenige Kommunikationsseite die die jeweilige Identit t berpr ft hier Teilnehmer B muss anhand des vorgelegten digitalen Zertifikats entscheiden ob dieses Zertifikat eine hinreichende Authentisierung erm glicht Diese Entscheidung ist anhand anderer in das Zertifikat eingetragener Parameter zu treffen wobei sie i d R beruhend auf vorgenommenen Einstellungen in automatisierter Weise erfolgt Auf diesbez gliche Details wird weiter unten eingegangen Die Qualit t der Authentisierung kann sich zus tzlich durch den Speicherort der Credentials sowie durch seine lokale Zugriffssicherung unterscheiden Als Speicherort kann beispielsweise eine verschl sselte Datei auf einer lokalen 20 TUHH AB Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Festplatte auf einer Netzwerkplatte in einer Datenbank auf einer Diskette usw dienen Problematisch bei diesem Ansatz ist die Tatsache dass Dateien leicht zu kopieren sind und dass die Datei die die Credentials enth lt somit leicht dupliziert und missbr uchlich verwendet werden kann Abhilfe schaffen hier Datentr ger die keine Duplizierung zulassen weil die geheime Information hier privater Schl ssel auf den Datentr gern entsteht ausschlie lich in ihnen verwendet wird und diese niemals verl sst Ein typisches Beispiel f r einen solchen Datentr ger ist die SmartCard die tats chlich weit mehr als ein simpler Informati
166. ten Berechtigungen zu Ressourcen Handlern betrachtet 4 2 3 1 Fachlicher Entwurf F r jedes deklarierte Pr dikat elementar oder zusammengesetzt wird eine Berechtigung instanziiert die innerhalb eines Ausf hrungskontextes zu einem boolschen Wert evaluiert werden kann Hieraus resultiert dass Pr dikate die deklarative Repr sentation von vorhandenen Berechtigungen bilden Um eine gew nschte Ressource Handler mit einem Zugriffsrecht Berechtigung zu versehen muss das Zugriffsrecht durch ein Pr dikat festgelegt worden sein Die Zuordnung ist aus Anwendungssicht sehr simpel Innerhalb der betreffenden handler txt die f r das eigene Projekt ma geblich ist findet die Zuweisung in deklarativer Weise statt Hierzu wird dem technischen Klassennamen Doppelpunkt angef gt gefolgt von dem Pr dikat das die entsprechende Berechtigung repr sentiert Die allgemeine Syntax hat somit folgende Gestalt lt Kategorie Aktion gt lt voller Klassenname gt lt Pr dikat gt Diese Syntax wird noch durch ein Beispiel verdeutlicht directories default de infoasset broker handler directories DefaultHandler isPasswordAuthentication Hieraus ist ersichtlich dass der DefaultHandler f r Verzeichnisse nur zug nglich ist wenn der Benutzer eine Passwort Authentisierung durchgef hrt hat Dieses Beispiel ist zwar nicht sonderlich sinnvoll zeigt allerdings wie einfach die deklarative Zuordnung stattfindet Bei dieser Zuweisung s
167. tion erm glicht es die Fingerabdr cke des betreffenden Karteninnabers mit der Karte zu verkn pfen Der Umgang mit diesem Anwendungsmodul ist sehr ausf hrlich im Handbuch beschrieben weshalb hier nicht n her auf Details eingegangen wird Die SmartCard Provider sind der eigentliche Schl ssel um das SmartCard System mit anderen Anwendungen zusammen betreiben zu k nnen Hierin sind u a der PKCS 11 Provider enthalten der es erlaubt das System zusammen mit Netscape zu nutzen oder der Cryptographic Service Provider der gleiches f r den MS Internet Explorer erm glichen soll Betrachtet man beispielsweise den PKCS 11 Provider so dient dieser allgemein dazu von den Eigenschaften des zugrunde liegenden Kryptoger ts zu abstrahieren um sie durch allgemeine Kryptofunktionen zu ersetzen Jede Anwendung die diese Schnittstelle nutzt wie beispielsweise Netscape besitzt also keinerlei Kenntnis ber das tats chlich zugrunde liegende Kryptoger t Aus Sicht des Browsers existieren damit zun chst einmal keine Unterschiede zwischen den Speicherorten von Zertifikaten z B im Rechner auf der SmartCard etc Da eine Unterscheidung zur Umsetzung der verschiedenen Authentisierungskonzepte erforderlich ist kann diese nur aufgrund der Zertifikate und ihrer Ausstellungsrichtliniien geschehen Besonders wichtig f r die einwandfreie Funktionsweise des SmartCard Systems mit Netscape ist die Registrierung des betreffenden PKCS 11 PlugIns pkcs201n dll mit
168. tive Aufgaben und eher sicherheitsorientierte Aspekte ber cksichtigen und die ebenfalls weitestgehend benutzertransparent sind k nnen ebenfalls integraler Bestandteil einer Portal Software sein Hierbei ist anzumerken dass bei dem Thema Sicherheit jeder etwas anderes darunter versteht Die nebul se Frage ob das Internet sicher ist oder nicht l sst sich nicht auf simple Weise beantworten Wenn man sich vergegenw rtigt dass das Internet aus dem ARPA Net hervorgegangen ist und bedenkt dass das Ziel dieses milit rischen Projekts war ein ausfallsicheres Netzwerk zu schaffen so kann mit Fug und Recht behauptet werden dass das Internet sicher sei Das Gesamtsystem Internet steht selbst dann noch zur Verf gung wenn Teilsysteme z B aufgrund eines atomaren Erstschlages zusammengebrochen sind Denkt man bei Sicherheit hingegen an die Sicherheit der eigenen Daten vor dem Einblick unbefugter Personen so ist das Internet in der Hinsicht nicht ohne weiteres sicher Sicherheit spielt berall dort eine Rolle wo wichtige sch tzenswerte G ter existieren sei es die nationale Sicherheit oder die Vertraulichkeit der eigenen Banktransaktion In dieser Arbeit wird das Thema Sicherheit anhand einer spezifischen Portal Software aufgegriffen der Portalplattform infoAsset Broker TUHH AB Softwaresysteme 1 Einleitung 1 1 Ziele der Arbeit Die vorliegende Arbeit widmet sich dem Thema Sicherheit innerhalb eines sehr spezifischen Kontextes Dieser
169. torisierungsarchitektur ist die Berechtigung Authority vgl Abb 23 Unter einer Berechtigung ist ein Objekt zu verstehen das im jeweiligen Kontext in dem es ausgef hrt wird zu einem boolschen Wert evaluiert werden kann Zu diesem Zweck besitzt das Berechtigungsobjekt eine Methode check dessen R ckgabewert vom Typ boolean sein soll Es sind grunds tzlich zwei Arten von Berechtigungen m glich elementare Berechtigungen und zusammengesetzte Berechtigungen Die elementaren Berechtigungstypen sind dabei gem den Merkmalen die sie abpr fen zu kategorisieren Gem zuvor dargestellten Kategorien existieren subjektbasierte objektbasierte und authentisierungsbasierte Berechtigungen Eine elementare Berechtigung ist eine Instanz eines programmatisch festgelegten Berechtigungstyps Jeder Berechtigungstyp implementiert dabei die Methode check auf eine f r ihn charakteristische Weise Dar ber hinaus ist jedem elementaren Berechtigungstyp ein Begriff zugeordnet durch das Pr dikate den jeweiligen Berechtigungstyp der durch sie repr sentiert wird spezifizieren sollen Eine zusammengesetzte Berechtigung repr sentiert einen boolschen Ausdruck von elementaren oder zusammengesetzten Berechtigungen Da die Architektur die Implementierung der drei elementaren boolschen Operationen NOT AND und OR vorsieht existieren demnach drei zusammengesetzte Berechtigungstypen die je eine dieser Operationen repr sentieren Die Aufgabe der Met
170. tztlich soweit gehen da zu jedem Handler die spezifische Berechtigung allein programmatisch definiert wird Eine Weiterentwicklung die wesentlich umfangreicher als die Implementierung einzelner neuer Berechtigungstypen ist w re die Implementierung weiterer Kombinationsm glichkeiten von Pr dikaten Relativ einfach w re hierbei noch die Implementierung weiterer logischer Operatoren z B XOR Eine weitere Schwierigkeitsstufe erreicht man wenn man nicht boolsche Operationen erm glichen m chte z B Mengenoperationen Diese zuletzt genannte Erweiterung w rde nicht nur eine umfangreiche Ver nderung des Programmcodes erfordern sondern m glicherweise auch eine neue Konzeption der Architektur gt eigene TUHH AB Softwaresysteme 85 Zusammenfassung und Ausblick Weitere Verbesserungen aus Autorisierungssicht ergeben sich aus einer ver nderten konzeptionellen Betrachtung In der erarbeiteten Autorisierungsarchitektur besteht die sch tzenswerte Ressource aus den Handlern die die implementierten Abl ufe verk rpern In gleicher Weise k nnte der Ansatz unternommen werden den Zugriff auf die eigentlichen Informationsobjekte beim infoAsset Broker die Assets zu regulieren Die hier erarbeitete Autorisierungsarchitektur kann der Umsetzung dieses weitergehenden Konzepts als Grundlage dienen Um die Administration von vorhandenen Berechtigungen zu erleichtern w re es dar ber hinaus denkbar eine h here Integration d
171. umentlId h handleRequest this output Das Schl sselwort this bezieht sich hierbei auf das Session Objekt welches den Handler aufruft Die genannten Stellen im Programmcode sind somit die Stellen an denen eine Berechtigungspr fung stattzufinden hat und die in entsprechender Weise abzu ndern sind Die Bedeutung des Session und des Dispatcher Objekts f r die Autorisierungsarchitektur sind der Grund daf r dass diese Klassen in Abb 25 wieder zu finden sind Nachdem die wesentlichen Stellen f r die Autorisierungspr fung ermittelt sind w re es ein Einfaches die zu dem jeweiligen Handler geh rige Berechtigung zu ermitteln s 4 2 3 und die erforderliche Pr fung durchzuf hren Die Autorisierungsarchitektur weist diesbez glich allerdings zwei Besonderheiten auf 50 bzw den handler txt Dateien TUHH AB Softwaresysteme 73 Autorisierung Zun chst einmal f hrt der Weg zur Autorisierungsarchitektur stets ber den AuthorityManager der s mtliche administrative Aufgaben dieser Komponente bernimmt bzw weiterdelegiert Dieses Objekt ist gem dem Singleton Pattern zu implementieren In diesem konkreten Fall stellt der AuthorityManager die Methode checkAuthority zur Verf gung in der mit Hilfe der Zuordnungstabelle s 4 2 3 die betreffende Berechtigung ermittelt und diese auf Erf llung hin anhand ihrer Methode check gepr ft wird Somit findet die Auswertung der Berechtigung innerhalb d
172. un chst wird ein URL String mit einem leeren String initialisiert und der Benutzer auf den Wechsel zu einer gesicherten Verbindung ber ein Meldefenster im Browser hingewiesen Dem URL String werden die Protokollbezeichnung https der Dom nenname der aus der JavaScript DOM entnommen wird und der Port ber den die gesicherte Verbindung erfolgen soll zugewiesen Durch die Protokollbezeichnung https erreicht man die Verwendung des SSL Protokolls Das Auslesen des Hostnamens erm glicht dass der Verbindungswechsel flexibel auf unterschiedliche durch die Portalplattform verwendete Dom nen reagiert Die Angabe des Ports erm glicht schlie lich den Zugriff auf den richtigen SSL Server Der Port ist hierbei ein Parameter der Funktion da diese ja f r unterschiedlich konfigurierte SSL Server verwendet werden soll Dem URL String wird im Anschluss der String de main htm t und ein sog Target welches die Funktion ebenfalls als Parameter erh lt angeh ngt Hierdurch wird das komplette Frameset neu geladen Im Content Frame wird hierbei das Target geladen so dass der Parameter ss Target die Syntax kategorie aktion htm haben sollte Abschlie end wird die JavaScript Funktion replace des Objekts location ausgef hrt Diese l dt die mit der bergebenen URL die folgende Gestalt hat https lt hostname gt lt sslIPort gt de main htm t lt ss Target gt Hierbei werden die Parameter ss Port und ss Target durch die
173. ung Ist keine Implementierung eines solchen Namens bekannt so wird die bei Engines f r diesen Fall bliche Ausnahme NoSuchAlgorithmException ausgel st Bei der in dieser Arbeit vorgelegten Implementierung findet ein Vergleich des bergebenen Typnamens mit denen der vorhandenen Implementierungen statt Erweitert man die SWS Architektur um weitere SSL Server Implementierungen so ist dementsprechend diese 0 gt kare 30 Broker ist eine eigene Klasse im infoAsset Broker 54 TUHH Softwaresysteme Eine Sicherheitsarchitektur f r eine Informationssystem Plattform Klassenmethode anzupassen so dass die neuen Implementierungen als existent erkannt werden Wie es oftmals bei Engine Objekten blich ist m ssen diese nach dem Instanziieren initialisiert werden Hierf r existiert kein standardisierter Methodenname wie es f r das Konstruieren des Objektes der Fall ist F r die Initialisierung der SSL Server geschieht dies durch Aufruf der Methode initSSLServers Die wichtigste Aufgabe dieser Methode ist das Erstellen eines richtig konfigurierten SSLServerSockets Diese Aufgabe erfolgt in zwei Schritten Initialisieren des SSLContextes und Kreieren des SSLServerSockets Der SSLServerSocket wird dann als Teil des SSL Servers gehalten und kann von diesem beliebig oft genutzt werden Au er dem generierten SSLServerSocket werden die der Methode bergebenen Parameter bestehend aus Konfigurationsobjekt und Broker Objekt Attributen de
174. ungsrichtlinie ist eine digitale Signatur die die Datenintegrit t des Zertifikats sichert Die Datenintegrit t wird in Abb 6 durch das Siegel symbolisiert Diese Datenintegrit t l sst sich anhand des jeweils komplement ren ffentlichen Schl ssels der betreffenden Zertifizierungsrichtlinie der CA verifizieren Abb 7 zeigt schematisch den beschriebenen Sachverhalt Zertifikat ausgestellt von ver ffentlicht 2 Identit tsangaben von On ffentlicher Schl ssel von vn Digitale Signatur der 7 7 vertraut CA 1 berpr ft Angaben von entsprechend Zertifizierungsrichtlinie a 3 schickt Zertifikat ke 4 berpr ft gt vertraut auf Teilnehmer A Zertifikat die Richtigkeit Teilnehmer B mit Om der Angaben Abb 7 Integrit tsverifizierung von Zertifikaten TUHH AB Softwaresysteme 27 Grundlagen Man beachte dass in Abb 7 nicht die Vertrauensw rdigkeit von Teilnehmer B geschlussfolgert wird sondern lediglich die Richtigkeit der Angaben ber B Dar ber hinaus wird vorausgesetzt dass Teilnehmer A der CA vertraut Nur unter dieser Annahme hat die Schlussfolgerung Bestand Dieser letzte Punkt f hrt zu weiteren Diskussionen Geht man allerdings zun chst davon aus dass der Teilnehmer A eine erfolgreiche Integrit tsverifizierung des Zertifikats durchf hren konnte so kann er anhand der Zertifikatsangaben verifizieren und nachweisen
175. usch w hrend einer Sitzung verwendet Dabei wird der Klartext i d R in festen Blockl ngen chiffriert z B 64 Bit Die L nge des Schl ssels wird dabei h ufig als Ma f r die Sicherheit des Verschl sselungsverfahrens angesehen da bei einem exhaustiven Angriff auf eine verschl sselte Information s mtliche denkbaren Schl ssel ausprobiert werden Die Anzahl der Schl ssel w chst dabei exponentiell mit der Anzahl der Bits die zur Kodierung eines Schl ssels erforderlich sind Zurzeit wird eine Schl ssell nge von 128 Bit als hinreichend sicher angesehen Es existiert eine F lle symmetrischer Chiffrierverfahren von denen hier nur einige benannt werden DES AES RC4 usw Symmetrische Chiffrierverfahren sind i d R gegen ber asymmetrischen Verfahren sehr performant Ihre Schw che liegt in der Notwendigkeit einen geheimen Schl ssel ber einen bereits sicheren Kanal vereinbaren zu m ssen Dar ber hinaus sind Schl ssel der genannten L nge tats chlich nur f r die Dauer einer Sitzung hinreichend sicher ber einen l ngeren Zeitraum k nnten die Schl ssel leicht kompromittiertt werden Schlie lich wird f r je zwei Teilnehmer eines Kommunikationsnetzwerks ein geheimer Schl ssel ben tigt Dies bedeutet eine quadratische Zunahme der Schl ssel mit der Anzahl der Teilnehmer was bei gro en Netzwerken wie dem Internet zu Problemen f hren w rde 2 3 2 3 Asymmetrische Kryptographie Bei einer asymmetrischen Chiffrierung sind der Sc
176. uthority rightAuthority Authority initvoid initvoid check boolean checkboolean NotAuthority AndAuthority OrAuthority Asset de infoasset broker authorities PersonbasedAuthority AuthenticatonbasedAuthority interface de infoasset broker interfaces Person AUTHORITY_ STRING PREFIK String person Person checkboolean initvoid checkboolean initvoid Asset Asset de infoasset broker authoriti GroupbasedAuthority interface de infoasset broker interfaces Membership interface de infoasset broker interfaces Role AUTHORITY_ STRING PREFIXKString group Group 0 1 checkboolean initvoid Asset interface de infoasset broker authorities RolebasedAuthority de infoasset hroker interfaces Group AUTHORITY_ STRING PREFIX Striny 9 role Role group Group checkboolean initwoid lt Domainvalue gt gt de infoasset broker interfaces Category de infoasset broker authorities CategorybasedAuthority AUTHORITY_STRING PREFICStrin eategoryld String check boolean initvoid z 72 AB Softwaresysteme hitektur Gesamtarchitektur isierungsarc Autor Abb 26 Autorisierung 4 3 Details der Implementierung Der vorangegangene Abschnitt ber den E
177. vate Schl ssel auf einer verwendeten SmartCard mit Hilfe von Fingerabdruckdaten gesichert werden Das externe SmartCard Leseger t enth lt zu diesem Zweck einen integrierten Fingerabdrucksensor Bei einer Verwendung der SmartCard Credentials wird der Benutzer aufgefordert sich gewisserma en gegen ber der SmartCard zu authentisieren damit diese die Webauthentisierung einleiten kann Die Referenzdaten der Fingerabdr cke befinden sich auf der SmartCard gespeichert und werden auch auf dieser mit den jeweiligen aktuell ausgelesenen Daten verglichen Damit existiert zwischen dem Benutzer dessen Identit t nachgewiesen werden soll und den Credentials mit denen dies webbasiert bewerkstelligt werden soll folgende Zuordnung Benutzer lt gt Fingerabdruck lt gt SmartCard lt gt Credentials Zertifikat amp priv Schl Die Zuordnungskette verdeutlicht dass nur derjenige Benutzer die Credentials auf der Karte verwenden kann der auch den richtigen Fingerabdruck nachweisen kann und dies kann lediglich derjenige f r den die Karte ausgestellt wurde Der Besitz der Karte alleine erm glicht somit noch keine erfolgreiche Authentisierung Dar ber hinaus ist eine Vervielf ltigung der Credentials so gut wie unm glich da gewisse Information hier priv Schl ssel die Karte niemals verl sst Auf diese Weise wird eine sehr gute Bindung eines Benutzers an seine Credentials erreicht 2 3 2 Kryptographie Die Kryptographie ist eine Schl sseltechn
178. vaten Schl ssels durch die Signatur eines Hashwertes nachweist Analog der Abb 15 w rde man hier die Annahme 2 durch Tatsache 2 ersetzen was die Authentisierungsunsicherheit reduziert berpr fung des Clientzertifikats analog zu 3 9 ClientPublicKey HASH NeuerChallengeString Serverzertifikat Server Anwendung z B Secure Web Server Abb 19 SSL Handshake Client Certificate 3 3 Fazit 2 Die Schritte 8 bis 11 bewirken die Authentisierung des Clients 12 Server Finish Abschlie end schickt der Server dem Client eine symmetrisch verschl sselte Sitzungsidentifikationsnummer session identifier SID Der Handshake ist damit abgeschlossen TUHH AB Softwaresysteme 41 Grundlagen 2 3 4 3 SSL in Java die Java Secure Socket Extension JSSE Die beiden vorangegangenen Abschnitte haben wesentliche Eigenschaften des SSL Protokolls dargestellt Sie bilden die theoretische Grundlage f r das Verst ndnis wie die Sicherheitskonzepte Vertraulichkeit und Integrit t der Kommunikation sowie Client und Serverauthentisierung in der Zielplattform umgesetzt werden Dieser Abschnitt beschreibt die praktischen Grundlagen der Umsetzung Wie in Abschnitt 2 2 dargestellt besteht die Zielplattform serverseitig aus einem hundertprozentig in Java programmierten Application Server Eine M glichkeit das SSL Protokoll in Java umzusetzen wird durch die Nutzung der sog Java Secure Socket Extension JSSE erreic
179. welchem Server sie ihren Request schicken soll Zu diesem Zweck existieren sog Domain Name Server DNS die diese Abbildung vornehmen Es existiert allerdings keine Garantie dass die gew nschte Dom ne auch tats chlich auf die richtige IP Adresse abgebildet wird Unter gewissen Umst nden m chte der Teilnehmer allerdings sicher sein dass er mit der von ihm gew nschten Webanwendung kommuniziert In diesem Falle m chte der Teilnehmer die von ihm vorgegebene Identit t der Webanwendung verifizieren um sicher zu sein dass tats chlich die gew nschte Webanwendung und keine andere die angeforderten Dienste erf llt Dies kann beispielsweise sinnvoll sein weil der Teilnehmer vertrauliche Daten an den Server schicken m chte berpr ft ein Client die Identit t eines Servers spricht man von Server Authentisierung Im engeren Sinne bedeutet Authentisierung somit dass eine Identit t verifiziert wird d h es wird die Echtheit der vorgegebenen Identit t berpr ft Definition Der Begriff Authentisierung umfasst s mtliche Ma nahmen die dazu dienen eine Identit t durch geeignete Mittel zu verifizieren 2 1 2 2 Autorisierung Im weitesten Sinne bedeutet der Begriff Autorisierung dass ein Recht zugebilligt worden ist eine bestimmte Handlung durchzuf hren Woraus sich dieses Recht ableitet kann dabei vielf ltiger Natur sein Die im Internet von einem Server angebotenen Webdienste stehen grunds tzlich zun chst uneingesc
180. wendet um die eigentliche Zuordnung von Handlern zu Berechtigungen durchzuf hren Dar ber hinaus loggt die Klasse die Vorg nge w hrend der Instanziierung um ggf Fehler schnell auffinden zu k nnen Zu Beginn des Initialisierungsvorgangs wird die Methode readAuthoritiesFromfFile des AuthorityReaders aufgerufen Die authorities txt der jeweiligen Projektebene wird zun chst als Properties Tabelle eingelesen hnlich dem Vorgang bei der handler txt Der AuthorityReader h lt eine weitere Tabelle die als Hashtable implementiert ist und die dem Attribut authorityNamesAndiInstances zugewiesen ist Diese letzte Tabelle akkumuliert Pr dikate Key der Hashtable und zugeordnete Berechtigungen Value der Hashtable ber mehrere Iterationen F r jeden Eintrag TUHH AB Softwaresysteme 77 Autorisierung der Properties Tabelle wird zun chst gepr ft ob sich bereits ein gleichnamiges Pr dikat in der Hashtable befindet was unzul ssig ist Eine solche Verletzung wird als Fehler geloggt und ruft den Abbruch der jeweiligen Iteration hervor Ist das Pr dikat nicht in der Hashtable enthalten so kann ein neues Key Value Pair in die Hashtable eingetragen werden wobei der Key das Pr dikat selbst und der Value eine zu generierende Berechtigung ist Ob die Berechtigung zusammengesetzt oder elementar ist h ngt von der Property des Eintrags ab Die Unterscheidung wird aufgrund von enthaltener Schl sselw rter getroffen Enth lt die Property die Sc
181. wird aber in diesem Fall mit einer Vielzahl von Warnungen konfrontiert werden dessen Tragweite er i d R nicht zu beurteilen vermag Der komplement re Vorgang der Clientauthentisierung findet bei SSL hingegen blicherweise nicht statt 2 3 4 2 Der SSL Handshake eine dynamische Betrachtung Im vorangegangenen Abschnitt hat eine Einordnung des SSL Protokolls in den Protokollstapel stattgefunden und es wurde konstatiert dass durch die Zwischenschaltung dieser Sicherheitsschicht viele Sicherheitskonzepte automatisch umgesetzt werden Auf diesen letzten Punkt soll in diesem Abschnitt genauer eingegangen werden in dem gezeigt wird wie das SSL Protokoll die genannten Sicherheitskonzepte s 2 3 4 1 umsetzt Eine wichtige Rolle f r das Verst ndnis der Umsetzung spielt hierbei der Handshake also derjenige Teil des Protokolls der f r den Aufbau der Verbindung verantwortlich ist Er soll deshalb hier detailliert beschrieben werden 1 Client Hello Der Client schickt dem Server einen zuf lligen Challenge String und benennt diejenigen Algorithmen die er f r die Kommunikation bzw ihren Aufbau verwenden m chte Abb 10 Die Gesamtheit der Algorithmen bezeichnet man als Cipher Suite Eine Cipher Suite besteht aus einem Algorithmus zur Schl sselvereinbarung asymmetrisches Chiffrierverfahren z B RSA DH einem Verschl sselungsalgorithmus symmetrisches Chiffrierverfahren z B DES 4 etc und einer Einweg Hashfunktion z B
182. zum Serverzertifikat zugeh rigen privaten Schl ssels m glich ist schlie t der Client hieraus dass sein Kommunikationspartner im Besitz des zum vorgelegten Zertifikat zugeh rigen privaten Schl ssels ist Hieraus folgert der Client die Authentizit t des Servers Diese Tatsache berpr ft der Client bei der G ltigkeitspr fung unter 3 Die zentrale Annahme hierbei ist da Serverzertifikate f lschungssicher sind d h da niemand in der Lage ist die privaten Schl ssel der CAs die die Zertifikate signieren zu ermitteln Tatsache 1 Vorgegebene Identit t in einem Zertifikat des Kommunikationspartners wurde nicht manipuliert Tatsache 2 Server besitzt Kenntnis Diese Tatsache berpr ft der des ServerWriteKey 5 Client durch Dechiffrierung des Challenge String Chiffrats Abb 14 SSL Handshake Server Verify 1 2 Zentrale Annahme PKI Zertifikate sind f lschungssicher Tatsache 2 Server besitzt Kenntnis des ServerWriteKey Annahme 1 Server besitzt Kenntnis des Hauptsitzungsschl ssels und hat mit seiner Hilfe den ServerWriteKey generiert Tatsache 1 Vorgelegtes Serverzertifikat wurde nicht manipuliert Annahme 2 Server besitzt Kenntnis des zum vorgelegten Zertifikat 383 UND zugeh rigen privaten Schl ssels und ER hat mit seiner Hilfe den asymmetrisch I Server Authentisierung chiffrierten Hauptschl ssel dechiffriert Annahme 3 Der zu einem ffentlichen Zertifikat zugeh

Download Pdf Manuals

Related Search

Related Contents

WildSnap IR X12  T4255 T4255 T4255 T4255 T425  リサイクル料金一覧表 - RKC 一般財団法人家電製品協会 家電  Mode d`emploi avant l`affectation  

Copyright © All rights reserved. Failed to retrieve file