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.