Angesichts der zentralen Rolle der Root-Zertifizierungsstellen als Vertrauensanker der Web PKI und der in der Vergangenheit aufgetretenen Vorfälle mit unberechtigt oder inkorrekt ausgestellten Zertifikaten, ist die Transparenz und Verantwortlichkeit dieser Root CAs von großer Bedeutung. Seit der Einführung von Certificate Transparency Logs werden alle von Certificate Authorities ausgestellten Zertifikate in diese öffentlichen Logs eingetragen. Die Arbeit stellt die Problematik der eingeschränkten Zugänglichkeit dieser Daten für die Wissenschaft dar und entwickelt ein Werkzeug, dass eine unabhängige Aufzeichnung und Auswertung von Certificate Transparency Logs ermöglicht. Das entwickelte System nutzt eine containerbasierte Architektur und Elasticsearch zur effizienten Speicherung und Analyse der Daten. Es bewältigt ein hohes Datenaufkommen von durchschnittlich 25 Millionen Log-Einträgen pro Tag und ermöglicht eine anpassbare Datenverarbeitung und -auswertung. Die Vorverarbeitung und Indexierung sowie die Auswertung der Daten erfolgte mit Python, was eine flexible Anpassung des Systems an unterschiedliche Forschungsfragen erlaubt. Über einen Zeitraum von 42 Tagen wurden insgesamt 645 Millionen CT Log-Einträge aufgezeichnet und analysiert. Aus den Auswertungen geht hervor, wie verschiedene CAs und deren Root-Zertifikate genutzt werden und wie stark die unterschiedlichen CT Logs von CAs verwendet werden. Die Arbeit identifiziert jedoch auch Herausforderungen, wie den hohen Speicherbedarf und notwendige Optimierungen in der Datenindexierung.:1 Einleitung 1.1 Problemstellung 1.2 Zielstellung 2 Grundlagen 2.1 X509-Zertifikate 2.1.1 Felder 2.1.2 Erweiterungen 2.2 Certificate Transparency 2.2.1 Certificate Transparency Log 2.2.2 Überprüfung durch User Agents 2.2.3 Überprüfung durch Monitors 2.2.4 Eintragung durch Certificate Authorities 3 Konzeptionierung 3.1 Abfrage der CT Logs 3.2 Verarbeitung der Zertifikate 3.3 Speicherung & Auswertung der Daten 3.4 Überwachung 3.5 Docker 4 Implementierung 4.1 Plattform 4.2 Überwachung 4.3 certstream-server 4.4 Verarbeitung 4.4.1 Pufferung (stream-to-queue-publisher) 4.4.2 Vorverarbeitung (cert-indexer) 4.5 Elasticsearch 4.5.1 Speicherverbrauch 4.5.2 Field Mappings 5 Auswertung 5.1 Logs & Log-Betreiber 5.2 Certificate Authorites 5.3 Zertifikats-Größe 5.4 Gültigkeitsdauer 6 Schluss 6.1 Fazit 6.2 Ausblick A Beispiel X509 Leaf-Zertifikat B Beispiel X509 Root-Zertifikat C Beispiele Elasticsearch Abfragen Literatur Abbildungsverzeichnis Tabellenverzeichnis / In view of the central role of the root certification authorities as trust anchors of the Web PKI and the incidents that have occurred in the past with unauthorised or incorrectly issued certificates, the transparency and accountability of these root CAs is of great importance. With the introduction of Certificate Transparency Logs, all certificates issued by Certificate Authorities are now entered in public logs. The work presents the problem of the limited accessibility of this data for science and develops a tool that enables an independent recording and evaluation of Certificate Transparency Logs. The developed system uses a container-based architecture and Elasticsearch to efficiently store and analyse the data. It can handle a high volume of data, averaging 25 million log entries per day, and enables customisable data processing and analysis. Python was used to pre-process, index and analyse the data, allowing the system to be flexibly adapted to different research questions. A total of 645 million CT log entries were recorded and analysed over a period of 42 days. The analyses show how different CAs and their root certificates are used and how much the different CT logs are used by CAs. However, the work also identifies challenges, such as the high memory requirements and necessary optimisations in data indexing.:1 Einleitung 1.1 Problemstellung 1.2 Zielstellung 2 Grundlagen 2.1 X509-Zertifikate 2.1.1 Felder 2.1.2 Erweiterungen 2.2 Certificate Transparency 2.2.1 Certificate Transparency Log 2.2.2 Überprüfung durch User Agents 2.2.3 Überprüfung durch Monitors 2.2.4 Eintragung durch Certificate Authorities 3 Konzeptionierung 3.1 Abfrage der CT Logs 3.2 Verarbeitung der Zertifikate 3.3 Speicherung & Auswertung der Daten 3.4 Überwachung 3.5 Docker 4 Implementierung 4.1 Plattform 4.2 Überwachung 4.3 certstream-server 4.4 Verarbeitung 4.4.1 Pufferung (stream-to-queue-publisher) 4.4.2 Vorverarbeitung (cert-indexer) 4.5 Elasticsearch 4.5.1 Speicherverbrauch 4.5.2 Field Mappings 5 Auswertung 5.1 Logs & Log-Betreiber 5.2 Certificate Authorites 5.3 Zertifikats-Größe 5.4 Gültigkeitsdauer 6 Schluss 6.1 Fazit 6.2 Ausblick A Beispiel X509 Leaf-Zertifikat B Beispiel X509 Root-Zertifikat C Beispiele Elasticsearch Abfragen Literatur Abbildungsverzeichnis Tabellenverzeichnis

Actuellement, de plus en plus d'ordinateurs sont interconnectés à l'Internet ou à des réseaux locaux. Il est donc indispensable de partager et de protéger l'information de façon performante. Pour accélérer et favoriser le développement de nouvelles applications et services autour des transactions électroniques, la sécurité devient une priorité. L'infrastructure de gestion de clés (IGC) est une réponse conçue pour assurer la sécurité des transactions électroniques et permettre l'échange de renseignements sensibles entre des parties qui n'ont pas établi au préalable de liens. La signature électronique est un service de base des IGC qui permet l'authentification, la confidentialité, l'intégrité et la non-répudiation de la transaction électronique. Elle devient une composante fondamentale des transactions sécurisées. Elle pourra bientôt se substituer légalement à la signature écrite. Dans ce contexte, notre objectif est de contribuer au développement et à la création de nouveaux e-services nécessaires à la croissance des transactions électroniques: la certification de rôles associés à la signature (pour connaître les privilèges du signataire aux moyens de la définition d'un rôle), l'habilitation et la délégation de signature (pour que quelqu'un puisse donner l'autorisation à quelqu'un d'autre d'exercer un pouvoir à sa place et donner l'autorisation de transférer ce pouvoir à un tiers), la signature électronique contrôlée (pour indiquer qui peut signer un document et contrôler la séquence et les priorités des signatures) et enfin les métadonnées de droits d'accès (pour définir les droits d'accès à un document indépendamment du système d'exploitation utilisé). Une infrastructure de confiance est nécessaire pour prendre en compte ces e-services. Nous proposons l'infrastructure ICARE-S2 (Infrastructure de Confiance sur des Architectures de RésEaux pour les Services de Signature évoluée ) basée sur les principes associés à l'infrastructure de gestion de privilèges et l'infrastructure de gestion de clés, un certificat d'attribut encodé en XML supporté par cette architecture, ainsi que la spécification de ces différents e-services utilisant ce type de certificat. Concrètement, l'infrastructure ICARE-S2 propose un système couvrant les principales fonctions de sécurité nécessaires à un processus transactionnel. De l'authentification et la gestion des droits des utilisateurs et des composants, en passant par le chiffrement des informations, et la gestion de l'intégrité des messages par le biais de certificats électroniques. Une partie de ces travaux a été financée par le projet RNRT ICARE.

With an increase in performance, dependency and ubiquitousness, the necessity for secure mobile device functionality is rapidly increasing. Authentication of an individual's identity is the fundamental component of physical and logical access to secure facilities and information systems. Identity management within the Department of Defense relies on Public Key Infrastructure implemented through the use of X.509 certificates and private keys issued on smartcards called Common Access Cards (CAC). However, use of CAC credentials on smartphones is difficult due to the lack of effective smartcard reader integration with mobile devices. The creation of a mobile phone derived credential, a new X.509 certificate and key pair based off the credentials of the CAC certificates, would eliminate the need for CAC integration with mobile devices This thesis describes four architectures for securely and efficiently generating and delivering a derived credential to a mobile device for secure communications with mobile applications. Two architectures generate credentials through a software cryptographic module providing a LOA-3 credential. The other two architectures provide a LOA-4 credential by utilizing a hardware cryptographic module for the generation of the key pair. In two of the architectures, the Certificate Authority']s (CA) for the new derived credentials is the digital signature certificate from the CAC. The other two architectures utilize a newly created CA, which would reside on the DoD network and be used to approve and sign the derived credentials. Additionally, this thesis demonstrates the prototype implementations of the two software generated derived credential architectures using CAC authentication and outlines the implementation of the hardware cryptographic derived credential. / Master of Science

The Network Service Ochestrator (NSO) is a network automation system provided by Cisco that is used to automate large network changes with the ability to roll back in case of errors. It provides a rich northbound interface to communicate with the user and a southbound interface to orchestrate network devices securely. On these northbound and southbound interfaces, NSO supports NETCONF and RESTCONF, which is an IETF standard for network automation. NSO native implementation of NETCONF and RESTCONF lacks support for Public-Key Infrastructure (X.509) (PKIX) infrastructure and SSH and SSL/TLS as transport. Instead, Cisco suggests that customers use external relay agents such as PKIX-SSH for SSH and GNUTLS for TLS for NETCONF. The certificates and keys are saved on the hard drive and loaded for every connection via RESTCONF. This workaround solution provides authentication and authorization without audit logging within NSO. In this work, a native implementation of the X509 certification with PKIX infrastructure on SSH and SSL/TLS for NETCONF and RESTCONF is investigated. The project evaluates design alternatives with respect to security, computational complexity, maintainability, and user-friendliness, and concludes by highlighting the pros and cons of both native and workaround implementation. / Ciscos NSO är en nätverksorkestreringsplatform som används för att automatisera stora ändringar i nätverk med egenheten att ändringarna kan backas tillbaka om inte samtliga kan kan utföras. NSO tillhandahåller användare gränssnitt (northbound) för att säkert kommunicera (southbound) med nätverksenheterna. Gränssnitten stödjer de standardiserade protokollen Netconf och Restconf. Båda dessa protokoll saknar inbyggts stöd för PKIX över SSH, SSL och TSL. När detta önskas rekommenderar Cisco sina kunder att externa klienter som PKIX-SSH eller GNUTLS. När detta görs sparas certifikat och nyklar lokalt för varje Restconf koppel och ingen läggning av flödet kommer att ske i NSO. I detta arbete presenteras ett inbyggt stöd för X509 certifiering med PKIX för SSH, SSL, och TLS. Stödet kan användas för Netconf och Restconf. Olikheter mellan dagens tillgängliga stöd och det inbyggda stödet med avseende på säkerhet, komplexitet, underhållbarhet, och användarvänlighet jämförs. Avslutningsvis belyses för- respektive nackdelar med de olika implementateringarna.