DOCSLIB.ORG

Formal Verification of the Internet Key Exchange (Ikev2) Security Protocol Tristan Ninet

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Formal Verification of the Internet Key Exchange (Ikev2) Security Protocol Tristan Ninet Formal verification of the Internet Key Exchange (IKEv2) security protocol Tristan Ninet To cite this version: Tristan Ninet. Formal verification of the Internet Key Exchange (IKEv2) security protocol. Cryptogra- phy and Security [cs.CR]. Université Rennes 1, 2020. English. NNT : 2020REN1S002. tel-02882167 HAL Id: tel-02882167 https://tel.archives-ouvertes.fr/tel-02882167 Submitted on 26 Jun 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Thèse de doctorat de L’UNIVERSITÉ DE RENNES 1 École Doctorale No 601 Mathématiques et Sciences et Technologies de l’Information et de la Communication Spécialité : Informatique Par Tristan NINET Formal verification of the Internet Key Exchange (IKEv2) security protocol Thèse présentée et soutenue à Rennes, le 9 mars 2020 Unité de recherche : Inria Rapporteurs avant soutenance : Caroline FONTAINE Directrice de Recherche, CNRS, LSV / ENS Paris-Saclay Steve KREMER Directeur de Recherche, Inria, LORIA Nancy Composition du Jury : Président : Steve KREMER Directeur de Recherche, Inria, LORIA Nancy Examinateurs : Pierre-Etienne MOREAU Professeur, Université de Lorraine, École des Mines de Nancy Thomas GENET Maître de conférence, Université de Rennes 1 Dir. de thèse : Stéphanie DELAUNE Directrice de Recherche, CNRS, IRISA Rennes Co-dir. de thèse : Olivier ZENDRA Chargé de Recherche, Inria Rennes Invité(s) : Romaric MAILLARD Architecte Equipements, Thales SIX GTS France Acknowledgment Je tiens à remercier Olivier, pour m’avoir accompagné du (presque) début à la fin, et en particulier pour avoir toujours su trouver les mots pour me rassurer et me remotiver. J’adresse également toute ma gratitude à Stéphanie, pour avoir accepté de reprendre ma thèse, et sans qui la qualité des travaux accomplis ne serait pas ce qu’elle est. Je remercie bien sûr Romaric et Frédéric pour m’avoir accueilli au sein de Thalès. Merci à toi Romaric, pour ton investissement et pour toutes ces discussions qui m’ont tant ap- pris. Merci Frédéric, pour m’avoir fait confiance et pour m’avoir laissé toute la liberté de travailler sur ma thèse. J’adresse également ma reconnaissance aux rapporteurs, Caroline Fontaine et Steve Kre- mer, pour avoir pris le temps de lire et corriger le manuscrit, et plus largement aux membres du jury, dont Pierre-Etienne Moreau et Thomas Genet, pour l’intérêt que vous avez porté à mes travaux. Je remercie du fond du cœur toute l’équipe TAMIS. Tous nos moments passés ensemble ont été à la fois passionnants et réconfortants. Tout cela m’a été indispensable. Je remercie enfin ma famille et mes amis pour leur soutien sans faille, et plus particuliè- rement Tita, pour avoir traversé la France en train, malgré la montée du COVID-19 en France, afin d’assister à la soutenance de ton petit-fils. 3 Résumé Cette thèse se situe au croisement de deux domaines de l’informatique. Le premier domaine est celui de l’architecture réseaux IPsec et son protocole d’échange de clés IKEv2, et le second domaine est la vérification formelle de protocoles de sécurité. Cette thèse viseà appliquer à IKEv2 les dernières avancées en vérification formelle. Dans ce résumé, nous présentons d’abord le contexte de cette thèse, puis nous intro- duisons le lecteur aux protocoles de sécurité et à leurs potentielles attaques, puis nous abordons la vérification formelle de protocoles de sécurité, et enfin nous présentons nos contributions. Contexte Les protocoles de sécurité sont des protocoles de communication dont l’un des objectifs est de garantir des propriétés de sécurité à des agents. Auparavant, ces protocoles étaient principalement utilisés par les armées afin d’échanger des informations sans que l’ennemi ne puisse les intercepter. Aujourd’hui les protocoles de sécurité sont sortis du seul contexte militaire et sont devenus omniprésents. Le protocole TLS [27] est probablement l’un des protocoles de sécurité les plus im- portants. TLS est le protocole utilisé pour sécuriser le protocole HTTP, ce qui est alors indiqué par le préfixe « https:// » dans les URLs. Grâce à TLS, il est notamment pos- sible d’effectuer des achats en ligne, d’accéder à un réseau social, ou encore de consulter son compte bancaire, et ce de manière sécurisée, c’est-à-dire sans qu’un attaquant puisse écouter nos conversations ou apprendre notre numéro de carte bancaire et nos mots de passe. Un autre exemple de protocole de sécurité utilisé au quotidien est le protocole Wi-Fi [40]. Ce protocole permet d’accéder à un réseau local sans utiliser de câble, en utilisant des ondes électromagnétiques comme moyen de communication. Or par nature, les ondes électromagnétiques peuvent être interceptées par toute machine se situant suffisamment proche de la machine émettrice. Il est donc nécessaire que le protocole Wi-Fi garantisse la confidentialité et l’authenticité des données échangées. Pour cela, le protocole effectue 5 des opérations cryptographiques telles que le chiffrement. Nous avons vu que les protocoles de sécurité jouent un rôle essentiel dans la sécurité de nos infrastructures modernes. Pourtant, de nombreuses failles ont été découvertes dans ces protocoles, même des années après leur mise en place. Par example, un attaquant possédant la clé secrète (clé WPA) d’un point d’accès Wi-Fi (le routeur Wi-Fi) peut aujourd’hui déchiffrer les communications de toutes les autres machines qui communiquent avec le routeur. Pour cela l’attaquant écoute les signaux Wi-Fi, intercepte l’échange de clés qui s’effectue à l’établissement d’une connection, puis déduit de cet échange la clé quisera utilisée pour chiffrer la connection (la « clé de session »). La méthode est décrite dans [89] par exemple. Le fait que l’attaquant puisse déduire aussi aisément la clé de session provient d’une faille logique dans la conception du protocole Wi-Fi. Dans cette thèse, nous nous concentrons sur le cas des réseaux privés virtuels (ou VPN, pour Virtual Private Network). Un VPN permet à plusieurs machines distantes de communiquer à travers Internet comme s’ils se situaient dans le même réseau local. Les VPNs sont par exemple utilisés par les entreprises pour relier leur site de travail, ou pour permettre à leurs employés d’accéder à leur réseau privé depuis n’importe quel endroit. Les VPNs sont également utilisés par les armées pour sécuriser les connexions entre les sites militaires, ou encore par les citoyens de certains pays pour échapper à la censure. L’une des architectures (i.e. ensemble de protocoles) utilisées pour créer des VPNs est Internet Protocol Security (IPsec) [76]. Or, préalablement à la mise en place d’un VPN IPsec entre deux machines distantes, il est nécessaire que le deux machines établissent entre elles une clé secrète (i.e. connue seulement des ces deux machines) qui servira à chiffrer et à authentifier leurs communications. Le protocole chargé de générer cetteclé secrète pour IPsec est Internet Key Exchange version 2 (IKEv2) [46]. La sécurité d’un VPN repose donc sur la sécurité de IKEv2. Il est alors crucial que la sécurité de IKEv2 soit assurée. Dans cette thèse, nous utilisons des techniques modernes de verification formelle pour tenter de répondre à cet enjeu. Protocoles et attaques Regardons maintenant de plus près à quoi ressemble un protocole de sécurité. Ces proto- coles sont des programmes qui manipulent des primitives cryptographiques afin de per- mettre à deux machines distantes de communiquer de manière sécurisée. Les attaques qui ne cassent pas les primitives cryptographiques mais exploitent un assemblage incorrect de 6 ces dernières sont appelées attaques logiques. Jusque dans les années 1970, la seule primitive existante était le chiffrement symé- trique. En chiffrement symétrique, la même clé est utilisée pour le chiffrement etpour le déchiffrement. Utilisée seule, cette méthode de chiffrement présente le problème que chaque machine doit garder en mémoire une clé pour chaque autre machine avec laquelle elle soit communiquer. Cela devient difficile à gérer lorsque le nombre de machines croît. Les travaux de Diffie et Hellman publiés en 1976 [28] marquent un tournant dansla cryptographie en introduisant la cryptographie asymétrique. Dans cette méthode, chaque machine possède une clé privée et une clé publique. La clé publique est connue de tout le monde, tandis que la clé privée n’est connue que de son propriétaire. Pour communiquer avec une machine, on chiffre notre message avec la clé publique de cette machine, et l’algorithme de chiffrement assure que seul le détenteur de la clé privée associée peut déchiffrer le message. L’avantage de cette méthode est que chaque machine ne doitgarder en mémoire que sa clé privée et sa clé publique. Avant chaque communication, les machines communiquent alors leur clé publique à quiconque veut communiquer avec elles. Notons qu’il existe bien d’autres primitives cryptographiques. Par exemple, la signa- ture numérique permet à une machine d’authentifier un message à l’aide de sa clé privée. La vérification se fait avec la clé publique. Le Message Authentication Code (MAC)rem- plit la même fonction que la signature numérique, mais la même clé est utilisée pour la génération du MAC et pour sa vérification. De manière informelle, un protocole est un ensemble de rôles qui effectuent des actions. Les rôles sont appelés « initiateur », « répondeur », « client », « serveur », etc. Les actions sont du type : générer un nombre aléatoire, appliquer une primitive cryptographique, envoyer un message, ou encore recevoir un message. De plus il est courant de diviser les messages en entités logiques appelés payloads, et de diviser les payloads en champs.
Load more

Recommended publications
  • Efficient, Dos-Resistant, Secure Key Exchange
    Efficient, DoS-Resistant, Secure Key Exchange for Internet Protocols∗ William Aiello Steven M. Bellovin Matt Blaze AT&T Labs Research AT&T Labs Research AT&T Labs Research [email protected] [email protected] [email protected] Ran Canetti John Ioannidis Angelos D. Keromytis IBM T.J. Watson Research Center AT&T Labs Research Columbia University [email protected] [email protected] [email protected] Omer Reingold AT&T Labs Research [email protected] Categories and Subject Descriptors While it might be possible to “patch” the IKE protocol to fix C.2.0 [Security and Protection]: Key Agreement Protocols some of these problems, it may be perferable to construct a new protocol that more narrorwly addresses the requirements “from the ground up.” We set out to engineer a new key exchange protocol General Terms specifically for Internet security applications. We call our new pro- Security, Reliability, Standardization tocol “JFK,” which stands for “Just Fast Keying.” Keywords 1.1 Design Goals We seek a protocol with the following characteristics: Cryptography, Denial of Service Attacks Security: No one other than the participants may have access to ABSTRACT the generated key. We describe JFK, a new key exchange protocol, primarily designed PFS: It must approach Perfect Forward Secrecy. for use in the IP Security Architecture. It is simple, efficient, and secure; we sketch a proof of the latter property. JFK also has a Privacy: It must preserve the privacy of the initiator and/or re- number of novel engineering parameters that permit a variety of sponder, insofar as possible.
    [Show full text]
  • Network Access Control and Cloud Security
    Network Access Control and Cloud Security Raj Jain Washington University in Saint Louis Saint Louis, MO 63130 [email protected] Audio/Video recordings of this lecture are available at: http://www.cse.wustl.edu/~jain/cse571-17/ Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse571-17/ ©2017 Raj Jain 16-1 Overview 1. Network Access Control (NAC) 2. RADIUS 3. Extensible Authentication Protocol (EAP) 4. EAP over LAN (EAPOL) 5. 802.1X 6. Cloud Security These slides are based partly on Lawrie Brown’s slides supplied with William Stallings’s book “Cryptography and Network Security: Principles and Practice,” 7th Ed, 2017. Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse571-17/ ©2017 Raj Jain 16-2 Network Access Control (NAC) AAA: Authentication: Is the user legit? Supplicant Authenticator Authentication Server Authorization: What is he allowed to do? Accounting: Keep track of usage Components: Supplicant: User Authenticator: Network edge device Authentication Server: Remote Access Server (RAS) or Policy Server Backend policy and access control Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse571-17/ ©2017 Raj Jain 16-3 Network Access Enforcement Methods IEEE 802.1X used in Ethernet, WiFi Firewall DHCP Management VPN VLANs Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse571-17/ ©2017 Raj Jain 16-4 RADIUS Remote Authentication Dial-In User Service Central point for Authorization, Accounting, and Auditing data ⇒ AAA server Network Access servers get authentication info from RADIUS servers Allows RADIUS Proxy Servers ⇒ ISP roaming alliances Uses UDP: In case of server failure, the request must be re-sent to backup ⇒ Application level retransmission required TCP takes too long to indicate failure Proxy RADIUS RADIUS Network Remote Access User Customer Access ISP Net Server Network Server Ref: http://en.wikipedia.org/wiki/RADIUS Washington University in St.
    [Show full text]
  • Kommentarer Till Utgåvan Debian 10 (Buster), 64-Bit PC
    Kommentarer till utgåvan Debian 11 (bullseye), 64-bit PC The Debian Documentation Project (https://www.debian.org/doc/) 5 oktober 2021 Kommentarer till utgåvan Debian 11 (bullseye), 64-bit PC Detta dokument är fri mjukvara; du kan vidaredistribuera det och/eller modifiera det i enlighet med villkoren i Free Software Foundations GNU General Public License version 2. Detta program är distribuerat med förhoppning att det ska vara användbart men HELT UTAN GARAN- TIER; inte ens underförstådd garanti om SÄLJBARHET eller att PASSA ETT SÄRSKILT SYFTE. Läs mer i GNU General Public License för djupare detaljer. Du borde ha fått en kopia av GNU General Public License tillsammans med det här programmet; om inte, skriv till Free Software Foundation, Inc., 51 Franklin Street. Fifth Floor, Boston, MA, 02110-1301 USA. Licenstexten kan också hämtas på https://www.gnu.org/licenses/gpl-2.0.html och /usr/ share/common-licenses/GPL-2 på Debian-system. ii Innehåll 1 Introduktion 1 1.1 Rapportera fel i det här dokumentet . 1 1.2 Bidra med uppgraderingsrapporter . 1 1.3 Källor för det här dokumentet . 2 2 Vad är nytt i Debian 11 3 2.1 Arkitekturer med stöd . 3 2.2 Vad är nytt i distributionen? . 3 2.2.1 Skrivbordsmiljöer och kända paket . 3 2.2.2 Utskrifter och scanning utan drivrutiner . 4 2.2.2.1 CUPS och utskrifter utan drivrutiner . 4 2.2.2.2 SANE och scannrar utan drivrutiner . 4 2.2.3 Nytt generellt kommando ”open” . 5 2.2.4 Control groups v2 . 5 2.2.5 Beständig systemd-journal .
    [Show full text]
  • Lecture 12: Security Systems Using Public Keys 11.1 PGP 11.2 SSL/TLS 11.3 IPSEC Stallings: Ch 16,17
    T-79.4501 Cryptography and Data Security Lecture 12: Security systems using public keys 11.1 PGP 11.2 SSL/TLS 11.3 IPSEC Stallings: Ch 16,17 1 Pretty Good Privacy • Email encryption program • Bottom–up approach to the distribution of trust • Each user acts as his/her own CA and signs the public keys of other users • User can accept authenticity of a public key based on recommendation by a third trusted user • RSA public key encryption used for distribution of session keys *) • Digital signatures produced by RSA or DSA signature algorithms • Hash functions are MD5 and SHA-1 • Symmetric encryption performed using IDEA in CFB mode (self- synchronising stream cipher) • Public keys held in ”Key-ring” • Revocation of public keys is a problem *) A data encryption protocol, where the data is encrypted using symmetric encryption, and the symmetric encryption key is encrypted using public key encryption, is called as ”hybrid encryption” 2 1 Secure Sockets Layer /Transport Layer Security • SSL (by Netscape) adds security to the TCP level of the Internet Protocol stack • Reliable end-to-end service. • TLS developed by IETF is basically equivalent to SSL v 3.1 Structure: SSL SSL Change SSL Handshake Cipher Spec Alert HTTP Protocol Protocol Protocol SSL Record Protocol TCP IP • Hypertext Transfer Protocol (Web client/server interaction) can operate on top of SSL (https://...) 3 SSL Record Protocol Application data fragment compressed fragment MAC added encrypted SSL record header appended 4 2 SSL Record Protocol Crypto • The MAC is similar to HMAC (indeed, an early version of HMAC) with the difference that OPAD and IPAD fields are concatenated to the key data (not xored as in HMAC).
    [Show full text]
  • Digital Safety & Security Lt Cdr Mike Rose RN ©
    RNIOA Article 15 [17/05/2020] characteristics linked to their IP address to enable ‘tracking.’ Where internet-based criminality is Digital Safety & Security involved, the acquisition of banking and credit card Lt Cdr Mike Rose RN © data is often the main objective. Introduction The aim of this article is to help people understand Prior to the introduction of the internet, personal the risks they face and how to attempt to mitigate computers for home use were self-contained in that them. So, whether you’re accessing the internet the operating system was bought and installed by with your mobile phone, PC, tablet or laptop, you’re the supplier/user, and external communications potentially exposed to every hacker, digital thief and using the PC were not yet technically developed. spammer across the globe. Not to mention that The most likely risk therefore was the possibility of viruses, trojan horses, spyware and adware are someone switching on unattended, non-password- always just one click away. You wouldn’t drive protected computers and copying sensitive without insurance, a seat belt and a GPS device, information onto an external memory device. so, similarly, when you “surf the net”, you need to Essentially, users were in control of their computing make sure that you are well “buckled up” and well- equipment and paid real money for the services informed. This article is written as a guide to “safe and software they used to a known vendor. surfing” and is just as important for personal users as it is for large tech companies. Malicious websites Spyware, which is software that steals your sensitive data without consent, lurks in many corners of the internet; often in places where you'd least expect it.
    [Show full text]
  • FIPS 140-2 Non-Proprietary Security Policy Oracle Linux 7 Libreswan
    FIPS 140-2 Non-Proprietary Security Policy Oracle Linux 7 Libreswan Cryptographic Module FIPS 140-2 Level 1 Validation Software Version: R7-2.0.0 Date: April 06, 2018 Document Version 1.2 © Oracle Corporation This document may be reproduced whole and intact including the Copyright notice. Title: Oracle Linux 7 Libreswan Cryptographic Module Security Policy April 06, 2018 Author: Atsec Information Security Contributing Authors: Oracle Linux Engineering Oracle Security Evaluations – Global Product Security Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright © 2018, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Oracle specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may reproduced or distributed whole and intact including this copyright notice. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Oracle Linux 7 Libreswan Cryptographic Module Security Policy i
    [Show full text]
  • Nist Sp 800-77 Rev. 1 Guide to Ipsec Vpns
    NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel Karen Scarfone Paul Wouters This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 C O M P U T E R S E C U R I T Y NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel* Computer Security Division Information Technology Laboratory Karen Scarfone Scarfone Cybersecurity Clifton, VA Paul Wouters Red Hat Toronto, ON, Canada *Former employee; all work for this publication was done while at NIST This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 June 2020 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority.
    [Show full text]
  • Guidelines for the Secure Deployment of Ipv6
    Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
    [Show full text]
  • Nanosec™ ] Mocana’S Comprehensive Ipsec and Ikev1/V2 Solution with Integrated Certificate Management Functionality
    Security of Things Connectivity [ NanoSec™ ] Mocana’s comprehensive IPsec and IKEv1/v2 solution with integrated certificate management functionality. Features & Benefits • Small footprint, high performance • Full NIST USGv6 compliant implementation of IETF IPsec version 3 • FIPS 140-2 Level 1 validated (optional) • Guaranteed “GPL-Free” code protects your • Complete IPSec & IKEv1/v2 solution with intellectual property certificate management • Zero-threaded, asynchronous architecture • Dramatically speeds integration & testing of IPsec and certificate management • Expert development support from Mocana engineers •NIST-Approved “Suite B” cryptography included IPsec/IKE is a standard designed by IETF to provide interoperable, high quality, cryptographically- based security for IP communication. It’s useful for providing authentication (to ensure peers are communicating with the intended trusted parties), data confidentiality (to ensure data cannot be read in transit) and message integrity (to ensure traffic has not been altered in transit). These security services are provided at the IP layer, offering protection to all the protocols carried over PI . IPsec provides a great deal of flexibility and granular control over the security services offered. The most popular application of IPsec is the VPN (Virtual Private Network) which creates a secure encrypted “tunnel” over the unsecured Internet. Once a VPN is established, the two ends can run virtually any data, voice and video application securely. IPsec is terrific for reducing the threat of packet sniffers or man-in-the-middle attacks. Unfortunately, most IPsec packages are designed for PC’s, not embedded devices. That means that they can be somewhat unwieldy in memory-constrained device environments...and the performance of typical commercial or open-source IPsec offerings can be pretty disappointing, as well.
    [Show full text]
  • Bohrende Fragen Wireguard
    01/2018 VPN mit Wireguard aufsetzen Titelthema Bohrende Fragen Wireguard 38 Wer ein Virtual Private Network einrichten möchte, kämpft oftmals mit einer nicht ganz simplen Konfiguration. Wireguard verspricht, dass der Tunnelbau auch einfacher und flinker gelingen kann. Falko Benthin www.linux-magazin.de Quelltext und setzt auf starke Verschlüs- selungsalgorithmen, wofür Donenfeld Trevor Perrins Noise Protocol Framework [9] ins Boot nimmt. Für Zertifikate setzt das Wireguard-Protokoll auf Ed25519, für den Schlüsselaustausch auf Curve25519 (ECDHE) und für den Datentransport auf Chacha20-poly1305. Wireguard unterstützt allerdings nur eine kryptografische Suite, die sich je- doch bei Problemen ohne Weiteres aus- tauschen lässt. Anwender müssen ihre Verschlüsselungs-Suite also nicht mehr aus verschiedenen Chiffren selbst zusam- menbasteln. Das reduziert die Komple- xität und vermindert das Risiko von Si- cherheitslücken. Wireguard arbeitet aus © Péter Gudella, 123RF © Péter Sicht des Administrators zustandslos und bringt einen integrierten Schutz gegen VPNs (Virtual Private Networks) gelten In freien Wildbahn treffen Admins Wire- Denial-of-Service-Attacken mit. als sichere Nummer, wenn es darum guard bislang noch eher selten an. Das geht, das Home Office mit dem Firmen- dürfte vor allem daran liegen, dass das Installation und netz, Firmensitze mit der Zentrale oder Projekt noch nicht im offiziellen Linux- Inbetriebnahme Geschäftsreisende mit ihrer Kundenda- Kernel steckt und aktuell nur für Linux tenbank zu verbinden. Privatnutzer ver- und OS X verfügbar ist. Daneben feh- Die Repositories zahlreicher Distributio- wenden VPNs, um beispielsweise sicher len Sicherheits-Audits und das Protokoll nen bieten Wireguard bereits an, sodass über das Internet auf die heimische Wet- kann sich noch ändern. Experimentierfreudige es leicht mit Hilfe terstation mit angeschlossenem Daten- Trotzdem haben es manche VPN-Provi- der entsprechenden Paketverwaltung in- bankserver zuzugreifen.
    [Show full text]
  • Linux Ipsec Tutorial
    Linux IPsec Tutorial Sowmini Varadhan (Oracle) & Paul Wouters (Redhat) Netdev0x12, July 2018, Montreal, Canada Agenda • Background: brief introduction to IPsec and IKE terminology • IPsec datapath walk-through: trace the life of a UDP packet for the transmit and receive path as it passes through the Linux kernel’s network stack (Sowmini Varadhan) • IPsec control plane walk-through: everything you wanted to know about the IKE control plane (Paul Wouters) Netdev0x12, July 2018, Montreal, Canada First, a review of IPsec/IKE terminology/definitions Netdev0x12, July 2018, Montreal, Canada What is IPsec? • IP Security • Suite of protocols for encryption (adding a “ESP” header) and Authentication (adding a “AUTH” header) • Encryption parameters (e.g., key, algorithm) are determined from two databases: – Security Policy database (SPD) – Security Association database (SADB) Netdev0x12, July 2018, Montreal, Canada SPD and SADB • SPD: Security Policy Database – What must be done: e.g., “for packets in 13.0.0.0/24, perform IPsec ESP processing”, “discard packets in 192.168.0.0/16” – Multiple transforms may be specified, e.g., “for packets from 12.0.0.1→12.0.0.2, apply ESP, then apply compression” – May need to create/lookup a Security Association to perform the action defined the SPD entry • SADB: Security Association Database – How to apply the security transform(s): e.g., “for packets from 13.0.0.1 → 13.0.0.2, apply AES-GCM-256 with the key 0x1234.. and a 128 bit IV” – IKE (Internet Key Exchange) protocol for negotiating and establishing SADB parameters
    [Show full text]
  • Implementation of Ipv6 in Internet Key Exhange Version 2
    Implementation of IPv6 in Internet Key Exhange version 2 Marko Salkić, Stjepan Groš, Vlado Glavinić Department of Electronics, Microelectronics, Computer and Intelligent Systems Faculty of Electrical Engineering and Computing Address: Unska 3, 10000 Zagreb, Croatia Telephone: +385 1 6129-935 E-mail: [email protected] Summary ± IKEv2 is a protocol for key exchange in Internet concluded in section five, followed by a list of references security architecture. We have implemented first, stripped- in section six. down version of IKEv2 that supported only IPv4 addresses. The implementation had some provisions that have been introduced in order to make later implementation of IPv6 II. IKEV2 PROTOCOL easier. Currently, we are extending IKEv2 implementation with missing functionality in order to make it fully IP security (IPsec) is a suite of security protocols and functional. In this paper we describe implementation details open standards developed by the Internet Engineering of IPv6 introduction into IKEv2 protocol implementation. Task Force (IETF) for secure transmission over unprotected networks, such as Internet. IPsec is required I. INTRODUCTION for IPv6 and optional for IPv4, but has not yet been widely deployed. Using cryptographic security services, IPsec IPv4 address architecture [1] is currently dominating provides confidentiality, data integrity, authenticity and on the Internet. This version has been in use for over 20 availability. Setting the parameters of an IPsec security years and during this period of time many deficiencies association (SA) manually does not scale well [4], so were discovered and identified. This led to a new version, another protocol ± Internet Key Exchange (IKE) ± is used IPv6 architecture [2], that has been in active development to automate and enhance negotiation of parameters and for over a decade.
    [Show full text]